# Workflow Status Service - Integration Examples
## How Other Workflows Can Use the Enhanced workflow-status Service
### Example 1: Simple Validation (product-brief workflow)
Replace the old Step 0:
```xml
Search {output_folder}/ for files matching pattern: bmm-workflow-status.md
Find the most recent file...
```
With the new service call:
```xml
mode: validate
calling_workflow: product-brief
Continue anyway? (y/n)
Exit workflow
Store {{status_file_path}} for later updates if needed
```
### Example 2: Getting Story Data (create-story workflow)
Replace the complex Step 2.5:
```xml
Read {output_folder}/bmm-workflow-status.md (if exists)
Navigate to "### Implementation Progress (Phase 4 Only)" section
Find "#### TODO (Needs Drafting)" section
```
With the new service call:
```xml
mode: data
data_request: next_story
Fall back to legacy story discovery
Use {{todo_story_id}} as story to draft
Use {{todo_story_title}} for validation
Create file: {{todo_story_file}}
```
### Example 3: Getting Project Configuration (solution-architecture workflow)
```xml
mode: data
data_request: project_config
No status file. Run standalone or create status first?
Use {{project_level}} to determine architecture complexity
Use {{project_type}} to select appropriate templates
Use {{field_type}} to know if brownfield constraints apply
```
### Example 4: Quick Init Check (any workflow)
```xml
mode: init-check
```
## Benefits of This Approach
1. **DRY Principle**: No more duplicating status check logic across 50+ workflows
2. **Centralized Logic**: Bug fixes and improvements happen in one place
3. **Backward Compatible**: Old workflows continue to work, can migrate gradually
4. **Advisory Not Blocking**: Workflows can proceed even without status file
5. **Flexible Data Access**: Get just what you need (next_story, project_config, etc.)
6. **Cleaner Workflows**: Focus on core logic, not status management
## Available Modes
### `validate` Mode
- **Purpose**: Check if this workflow should run
- **Returns**:
- `status_exists`: true/false
- `should_proceed`: true (always - advisory only)
- `warning`: Any sequence warnings
- `suggestion`: What to do
- `project_level`, `project_type`, `field_type`: For workflow decisions
- `status_file_path`: For later updates
### `data` Mode
- **Purpose**: Extract specific information
- **Parameters**: `data_request` = one of:
- `next_story`: Get TODO story details
- `project_config`: Get project configuration
- `phase_status`: Get phase completion status
- `all`: Get everything
- **Returns**: Requested fields as template outputs
### `init-check` Mode
- **Purpose**: Simple existence check
- **Returns**:
- `status_exists`: true/false
- `suggestion`: Brief message
### `interactive` Mode (default)
- **Purpose**: User-facing status check
- **Shows**: Current status, options menu
- **Returns**: User proceeds with selected action
## Migration Strategy
1. Start with high-value workflows that have complex Step 0s
2. Test with a few workflows first
3. Gradually migrate others as they're updated
4. Old workflows continue to work unchanged
## Next Steps
To integrate into your workflow:
1. Replace your Step 0 with appropriate service call
2. Remove duplicate status checking logic
3. Use returned values for workflow decisions
4. Update status file at completion (if status_exists == true)