ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

standardize workflow and PRD step markdown formatting 

- Improve consistency across workflow validation steps
- Standardize PRD innovation step structure
- Fix formatting in CIS module.yaml

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Brian Madison 2026-01-09 19:38:14 +08:00
parent 27538e6ff2
commit 2b7e542a8f
16 changed files with 674 additions and 611 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
src/modules/bmb/workflows/workflow/steps-c/step-06-design.md
View File

@ -15,6 +15,7 @@ outputFormatStandards: '../data/output-format-standards.md'
inputDiscoveryStandards: '../data/input-discovery-standards.md'
workflowChainingStandards: '../data/workflow-chaining-standards.md'
trimodalWorkflowStructure: '../data/trimodal-workflow-structure.md'
subprocessPatterns: '../data/subprocess-optimization-patterns.md'
---
# Step 6: Workflow Structure Design
@ -175,6 +176,47 @@ Design quality assurance:
- How can users recover from errors?
- What constitutes successful completion?
### 6a. Subprocess Optimization Design
Load {subprocessPatterns} to understand subprocess optimization patterns that can save context and improve performance during workflow execution.
Ask the user:
"**Should we design this workflow to leverage subprocess optimization patterns?** Consider:
- **Pattern 1 (Grep/Regex):** Will any step search across many files or documents for patterns?
- **Pattern 2 (Deep Analysis):** Will any step analyze multiple files for prose, logic, quality, or flow?
- **Pattern 3 (Data Operations):** Will any step load large reference data, knowledge bases, or datasets?
- **Pattern 4 (Parallel Execution):** Can any validation or analysis checks run in parallel instead of sequentially?
If **YES** to any of these, we should design those steps with subprocess optimization in mind."
**If subprocess optimization is applicable:**
For each step that could benefit from subprocesses:
- Identify which pattern(s) apply (Pattern 1, 2, 3, or 4)
- Design what the subprocess should return (findings only, not full content)
- Plan graceful fallback for LLMs without subprocess capability
- Document optimization strategy in the build plan
**Example subprocess integration:**
```markdown
### Step-Specific Rules:
- 🎯 Analyze X files for Y - use subprocess per file (Pattern 2)
- 💬 Subprocess returns structured findings, not full content
- ⚙️ If subprocess unavailable: Perform analysis in main thread
```
**Document in the plan:**
For each step identified for subprocess optimization, record:
- Step number and name
- Pattern type(s) to apply
- What the subprocess will analyze
- Expected return structure
- Fallback approach
### 7. Special Features Design
Identify unique requirements:

44
src/modules/bmb/workflows/workflow/steps-c/step-08-build-step-01.md
View File

@ -11,6 +11,7 @@ frontmatterStandards: '../data/frontmatter-standards.md'
menuHandlingStandards: '../data/menu-handling-standards.md'
outputFormatStandards: '../data/output-format-standards.md'
inputDiscoveryStandards: '../data/input-discovery-standards.md'
subprocessPatterns: '../data/subprocess-optimization-patterns.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
@ -266,6 +267,49 @@ Display continuation status and offer to proceed.
**If supporting files are needed, create them in `data/` folder and update step-01 frontmatter to reference them.**
### 5a. Apply Subprocess Optimization (If Designed)
**Check the approved design from step 6:** Was subprocess optimization identified for step-01?
**If YES, apply the appropriate pattern(s):**
Load {subprocessPatterns} and implement the subprocess optimization:
1. **Identify the pattern(s) from the design:**
- Pattern 1: Single subprocess for grep/regex across many files
- Pattern 2: Per-file subprocess for deep analysis
- Pattern 3: Subprocess for data file operations
- Pattern 4: Parallel execution of independent operations
2. **Add subprocess-specific Step-Specific Rules:**
```markdown
### Step-Specific Rules:
- 🎯 [Brief description of which pattern applies]
- 💬 Subprocess must either update report OR return findings to parent
- 🚫 DO NOT BE LAZY - [specific guidance if Pattern 2]
- ⚙️ TOOL/SUBPROCESS FALLBACK: If subprocess unavailable, perform in main thread
```
3. **Implement subprocess directives in the MANDATORY SEQUENCE:**
- Use appropriate subprocess language:
- Pattern 1: "Launch a subprocess that runs [command] across all files, returns [results]"
- Pattern 2: "DO NOT BE LAZY - For EACH file, launch a subprocess that [analyzes], returns [findings]"
- Pattern 3: "Launch a subprocess that loads [data file], performs [operation], returns [results]"
- Pattern 4: "Launch subprocesses in parallel that [operations], aggregate results"
4. **Ensure return patterns are specified:**
- Subprocess updates report directly OR
- Subprocess returns structured findings to parent for aggregation
5. **Verify graceful fallback is documented:**
- Universal fallback rule in Universal Rules
- Step-specific fallback in Step-Specific Rules
- Clear instructions for LLMs without subprocess capability
**If NO subprocess optimization was designed for step-01:**
Skip this section and proceed to document build in plan.
### 6. Document Build in Plan
Append to {workflowPlanFile}:

44
src/modules/bmb/workflows/workflow/steps-c/step-09-build-next-step.md
View File

@ -11,6 +11,7 @@ frontmatterStandards: '../data/frontmatter-standards.md'
menuHandlingStandards: '../data/menu-handling-standards.md'
outputFormatStandards: '../data/output-format-standards.md'
csvDataFileStandards: '../data/csv-data-file-standards.md'
subprocessPatterns: '../data/subprocess-optimization-patterns.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
@ -97,6 +98,49 @@ Confirm: "The next step to build is **step-{N}-{name}** which is a [step type].
**Load {outputFormatStandards}** if this step outputs to document.
### 2a. Apply Subprocess Optimization (If Designed for This Step)
**Check the approved design from step 6:** Was subprocess optimization identified for this step?
**If YES, apply the appropriate pattern(s):**
Load {subprocessPatterns} and implement the subprocess optimization for this step:
1. **Identify the pattern(s) from the design for this step:**
- Pattern 1: Single subprocess for grep/regex across many files
- Pattern 2: Per-file subprocess for deep analysis
- Pattern 3: Subprocess for data file operations
- Pattern 4: Parallel execution of independent operations
2. **Add subprocess-specific Step-Specific Rules to this step:**
```markdown
### Step-Specific Rules:
- 🎯 [Brief description of which pattern applies]
- 💬 Subprocess must either update report OR return findings to parent
- 🚫 DO NOT BE LAZY - [specific guidance if Pattern 2]
- ⚙️ TOOL/SUBPROCESS FALLBACK: If subprocess unavailable, perform in main thread
```
3. **Implement subprocess directives in the MANDATORY SEQUENCE:**
- Use appropriate subprocess language:
- Pattern 1: "Launch a subprocess that runs [command] across all files, returns [results]"
- Pattern 2: "DO NOT BE LAZY - For EACH file, launch a subprocess that [analyzes], returns [findings]"
- Pattern 3: "Launch a subprocess that loads [data file], performs [operation], returns [results]"
- Pattern 4: "Launch subprocesses in parallel that [operations], aggregate results"
4. **Ensure return patterns are specified:**
- Subprocess updates report directly OR
- Subprocess returns structured findings to parent for aggregation
5. **Verify graceful fallback is documented:**
- Universal fallback rule in Universal Rules
- Step-specific fallback in Step-Specific Rules
- Clear instructions for LLMs without subprocess capability
**If NO subprocess optimization was designed for this step:**
Skip this section and proceed to build the step file.
### 3. Build the Step File
**Load {stepTemplate}** for base structure.

118
src/modules/bmb/workflows/workflow/steps-v/step-01-validate.md
View File

@ -23,28 +23,22 @@ To create the validation report and check that the workflow has correct file str
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
- 🎯 Create validation report with header structure
- 🚫 DO NOT skip checking any file
- 💬 Append findings to report, then auto-load next step
- 🎯 Create validation report with header structure using subprocess optimization when available
- 🚫 DO NOT skip checking any file - DO NOT BE LAZY
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
- 🚪 This is validation - systematic and thorough
## EXECUTION PROTOCOLS:
- 🎯 Load and check EVERY file in the workflow
- 💾 Append findings to validation report
- 🎯 Load and check EVERY file in the workflow using subprocess optimization when available - single subprocess for bash/grep operations, separate subprocess per file for size analysis
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
- 📖 Save report before loading next validation step
- 🚫 DO NOT halt for user input - validation runs to completion
## CONTEXT BOUNDARIES:
- Workflow has been built in steps-c/
- Check the entire folder structure
- Verify all required files exist
- Check file sizes against limits
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
@ -119,9 +113,18 @@ Load {stepFileRules} to understand:
### 3. Check Folder Structure
**DO NOT BE LAZY - List EVERY folder and file:**
**Launch a single subprocess that:**
Use bash commands to list the entire structure:
1. Lists the entire folder structure using bash commands
2. Verifies all required folders and files exist
3. Returns structured findings to parent for aggregation
```bash
# List folder structure
find {targetWorkflowPath} -type f -name "*.md" | sort
```
**Expected structure:**
```
{targetWorkflowPath}/
├── workflow.md
@ -140,53 +143,34 @@ Use bash commands to list the entire structure:
**Check:**
- ✅ workflow.md exists
- ✅ steps-c/ folder exists with all step files
- ✅ data/ folder exists (may be empty)
- ✅ templates/ folder exists (may be empty)
- ✅ No unexpected files
- ✅ Folder names follow conventions
- ✅ step files are in a well organized folder
- ✅ non step reference files are organized in other folders such as data, templates, or others that make sense for the workflow
- ✅ Folder names make sense
### 4. Check File Sizes
**DO NOT BE LAZY - Check EVERY step file:**
**DO NOT BE LAZY - For EACH step file in steps-c/, launch a subprocess that:**
For each file in `steps-c/`:
1. Read the file
2. Count lines
3. Check against limits:
- < 200 lines: ✅ Good
- 200-250 lines: ⚠️ Approaching limit
- > 250 lines: ❌ Exceeds limit
1. Loads that step file
2. Counts lines and checks against size limits
3. Returns structured findings to parent for aggregation
**Check for Large Data Files:**
**Limits:**
- < 200 lines: ✅ Good
- 200-250 lines: ⚠️ Approaching limit
- > 250 lines: ❌ Exceeds limit
For each file in `data/` folder:
1. Check file size in lines
2. If > 500 lines: ⚠️ WARNING - Large data file detected
3. If > 1000 lines: ❌ ERROR - Data file too large for direct loading
**Subprocess returns:** File name, line count, status (Good/Approaching limit/Exceeds limit), and any issues found.
**For large data files, recommend:**
- Create an index/csv/yaml so LLM knows what's available and can load specific sections
- Use sharding technique (core module has sharding tool) to split large files
- Consider if all data is needed or if lookup/reference pattern would work better
**Subprocess must either:**
- Update validation report directly with findings, OR
- Return structured findings to parent for aggregation into report
**Report format:**
```markdown
### File Size Check
| File | Lines | Status |
|------|-------|--------|
| step-01-init.md | 180 | ✅ Good |
| step-02-*.md | 245 | ⚠️ Approaching limit |
| step-03-*.md | 267 | ❌ Exceeds limit - should split |
### Data File Size Check
| Data File | Lines | Status |
|-----------|-------|--------|
| reference-data.csv | 150 | ✅ Good |
| large-data.md | 2500 | ❌ Too large - use sharding or create index |
```
**Document findings in validation report:**
- List all step files checked with their line counts
- Note any files approaching or exceeding size limits (<200 recommended, 250 max)
- Check data and reference files for size issues (large files should be sharded or indexed)
- Identify specific size violations and recommendations
### 5. Verify File Presence
@ -200,28 +184,12 @@ From the design in {workflowPlanFile}, verify:
Replace the "## File Structure & Size" section in {validationReportFile} with actual findings:
```markdown
## File Structure & Size
### Folder Structure
[Report findings - is structure correct?]
### Files Present
[Report findings - are all required files present?]
### File Size Check
[Table as shown above]
### Issues Found
[List any issues:
- Missing files
- Extra files
- Size violations
- Naming convention violations]
### Status
✅ PASS / ❌ FAIL / ⚠️ WARNINGS
```
**Document the following:**
- Folder structure assessment
- Required files presence check
- File size analysis results
- List of any issues found (missing files, extra files, size violations, naming issues)
- Overall validation status (PASS/FAIL/WARNINGS)
### 7. Save Report and Auto-Proceed

85
src/modules/bmb/workflows/workflow/steps-v/step-02-frontmatter-validation.md
View File

@ -18,23 +18,24 @@ To validate that EVERY step file's frontmatter follows the frontmatter standards
### Universal Rules:
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
- 🛑 DO NOT BE LAZY - VALIDATE EVERY FILE'S FRONTMATTER
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
### Step-Specific Rules:
- 🎯 Load and validate EVERY step file's frontmatter
- 🚫 DO NOT skip any files or checks
- 💬 Append findings to report, then auto-load next step
- 🚪 This is validation - systematic and thorough
- 🎯 Validate EVERY step file's frontmatter using subprocess optimization - each file in its own subprocess
- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
- 🚪 This is validation - systematic and thorough using per-file deep analysis (Pattern 2)
## EXECUTION PROTOCOLS:
- 🎯 Load frontmatter standards first
- 💾 Check EVERY file against standards
- 📖 Append findings to validation report
- 🎯 Load frontmatter standards first, then validate each file in its own subprocess for deep analysis
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
- 📖 Aggregate all findings into validation report before loading next step
- 🚫 DO NOT halt for user input - validation runs to completion
## CONTEXT BOUNDARIES:
@ -63,9 +64,19 @@ Load {frontmatterStandards} to understand validation criteria.
- `./...` - use `./step-XX.md`
- `{workflow_path}/templates/...` - use `../template.md`
### 2. Validate EVERY Step File - Systematic Algorithm
### 2. Validate EVERY Step File - Systematic Algorithm with Subprocess Optimization
**DO NOT BE LAZY - For EACH step file:**
**DO NOT BE LAZY - For EACH step file, launch a subprocess that:**
1. Loads that file
2. Loads {frontmatterStandards} to understand validation criteria
3. Performs all frontmatter validation checks on that file (extract variables, check usage, validate paths)
4. **EITHER** updates the validation report directly with its findings
5. **OR** returns structured findings to parent for aggregation
**SUBPROCESS ANALYSIS PATTERN:**
For each file, the subprocess performs the following deep analysis:
#### Step 2.1: Extract Frontmatter Variables
@ -125,34 +136,29 @@ if path contains "{project-root}" and is internal workflow reference:
MARK_AS_VIOLATION("Internal paths must be relative, not project-root")
```
### 3. Document Findings
**RETURN FORMAT:**
Create report table:
Subprocess returns file name, frontmatter compliance status, unused variables found, path violations, and overall status (PASS/FAIL). Include specific variable names and violation details for documentation.
```markdown
### Frontmatter Validation Results
Check ALL files systematically. Return findings for compilation and appendage to validation report.
| File | Required | All Vars Used | Relative Paths | No Forbidden | Status |
| ----------------- | -------- | ------------------------------------ | -------------- | ------------ | ------ |
| step-01-init.md | ✅ | ❌ Unused: thisStepFile, workflowFile | ✅ | ✅ | ❌ FAIL |
| step-02-vision.md | ✅ | ✅ | ✅ | ✅ | ✅ PASS |
```
### 3. Aggregate Findings and Document Results
Document frontmatter validation results in the validation report showing:
- Which files were checked
- Frontmatter compliance status for each file
- Unused variables found in each file
- Path violations detected
- Overall pass/fail status for each file
### 4. List All Violations
For EACH file with violations:
```markdown
### Violations Found
**step-01-init.md:**
- ❌ Unused variable: `thisStepFile` (defined but {thisStepFile} never appears in body)
- ❌ Unused variable: `workflowFile` (defined but {workflowFile} never appears in body)
- ❌ Forbidden pattern: `workflow_path` variable found (use relative paths instead)
**step-02-vision.md:**
- ✅ All checks passed
```
Document all violations found in the validation report, including:
- Specific files with violations
- Unused variable names and why they're unused
- Forbidden patterns detected with explanation
- Path format violations with details
- Files that passed all checks
### 5. Append to Report
@ -173,20 +179,21 @@ Then immediately load, read entire file, then execute {nextStepFile}.
### ✅ SUCCESS:
- EVERY step file's frontmatter validated using systematic algorithm
- Each variable checked for usage in step body
- Each path checked for proper relative format
- EVERY step file validated using subprocess optimization (Pattern 2: per-file deep analysis)
- Each subprocess validates frontmatter, checks variable usage, validates paths
- Structured findings returned to parent OR report updated directly by subprocesses
- All violations documented with specific variable names
- Findings appended to report
- Findings aggregated into validation report
- Report saved before proceeding
- Next validation step loaded
### ❌ SYSTEM FAILURE:
- Not checking every file
- Not systematically checking each variable for usage
- Not validating every file using subprocess optimization
- Not systematically checking each variable for usage in subprocess
- Missing forbidden pattern detection
- Not documenting violations with specific details
- Not returning structured findings OR updating report from subprocess
- Not saving report before proceeding
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. For EACH variable in frontmatter, verify it's used in the body. For EACH path, verify it's relative. Auto-proceed through all validation steps.
**Master Rule:** Validation is systematic and thorough using subprocess optimization. DO NOT BE LAZY. For EACH file, launch a subprocess that validates frontmatter, checks variable usage, validates paths, and returns findings. Auto-proceed through all validation steps.

83
src/modules/bmb/workflows/workflow/steps-v/step-03-menu-validation.md
View File

@ -22,19 +22,20 @@ To validate that EVERY step file's menus follow the menu handling standards - pr
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
- 🎯 Load and validate EVERY step file's menus
- 🚫 DO NOT skip any files or checks
- 💬 Append findings to report, then auto-load next step
- 🚪 This is validation - systematic and thorough
- 🎯 Validate EVERY step file's menus using subprocess optimization - per-file deep analysis pattern (Pattern 2)
- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
- 🚪 This is validation - systematic and thorough, leveraging per-file subprocess for menu structure analysis
## EXECUTION PROTOCOLS:
- 🎯 Load menu standards first
- 💾 Check EVERY file's menu structure
- 📖 Append findings to validation report
- 💾 Check EVERY file's menu structure using subprocess optimization when available - per-file deep analysis for menu structure validation
- 📖 Append findings to validation report (subprocesses either update report OR return findings for parent aggregation)
- 🚫 DO NOT halt for user input - validation runs to completion
## CONTEXT BOUNDARIES:
@ -64,11 +65,15 @@ Load {menuHandlingStandards} to understand validation criteria:
### 2. Check EVERY Step File
**DO NOT BE LAZY - For EACH file in steps-c/:**
**DO NOT BE LAZY - For EVERY file in steps-c/, launch a subprocess that:**
1. Load the file
2. Find the menu section (if present)
3. Validate against each rule:
1. Loads that step file
2. Loads {menuHandlingStandards} to understand validation criteria
3. Validates menu structure deeply (handler section, execution rules, A/P appropriateness, reserved letter compliance)
4. **EITHER** updates validation report directly with findings
5. **OR** returns structured validation findings to parent for aggregation
**SUBPROCESS VALIDATION PATTERN - Each subprocess checks for:**
**Check 1: Handler Section Exists**
- ✅ Handler section immediately follows Display
@ -92,39 +97,35 @@ Load {menuHandlingStandards} to understand validation criteria:
- Validation sequences should auto-proceed, not have menus
- ❌ If A/P in wrong place: mark as violation
### 3. Document Findings
**RETURN FORMAT:**
Each subprocess should return validation findings for its assigned file including:
- File name
- Whether a menu is present
- Results of all 5 checks (handler section, execution rules, redisplay menu, C sequence, A/P appropriateness)
- List of any violations found
- Overall status (PASS/FAIL/WARN)
Create report table:
**Context savings estimate:** Each subprocess returns structured findings vs full file content. Parent aggregates all findings into final report table.
```markdown
### Menu Handling Validation Results
### 3. Aggregate Findings and Document Results
| File | Has Menu | Handler Section | Exec Rules | A/P Appropriate | Status |
|------|----------|----------------|------------|-----------------|--------|
| step-01-init.md | ✅ (C-only) | ✅ | ✅ | N/A | ✅ PASS |
| step-02-*.md | ✅ (A/P/C) | ✅ | ✅ | ✅ | ✅ PASS |
| step-03-*.md | ✅ (C-only) | ❌ Missing | ⚠️ Incomplete | N/A | ❌ FAIL |
| step-04-*.md | ❌ No menu | N/A | N/A | Should have A/P/C | ⚠️ WARN |
```
After ALL files have been validated (either via subprocess or main context), document the menu handling validation results in the validation report, including:
- Overall assessment of menu handling compliance across all step files
- Summary of files checked and their menu status
- Files that passed all menu validation checks
- Files with warnings or issues that need attention
- Files that failed validation with specific violations
### 4. List Violations
```markdown
### Menu Violations Found
Compile and document all violations found during validation, organizing them by file and providing clear descriptions of each issue, such as:
**step-03-[name].md:**
- Missing handler section after menu display
- EXECUTION RULES section incomplete
**step-04-[name].md:**
- No menu found - this is a collaborative content step, should have A/P/C menu
**step-05-[name].md:**
- A/P options don't specify "redisplay menu" after execution
**step-06-[name].md:**
- All checks passed ✅
```
- Missing handler sections
- Incomplete execution rules
- Improper A/P usage
- Missing redisplay menu instructions
- Any other menu handling standard violations
### 5. Append to Report
@ -145,9 +146,10 @@ Then immediately load, read entire file, then execute {nextStepFile}.
### ✅ SUCCESS:
- EVERY step file's menus validated
- All violations documented
- Findings appended to report
- Menu standards loaded and understood
- EVERY step file's menus validated via subprocess (per-file deep analysis) OR main context
- All violations documented across handler sections, execution rules, A/P appropriateness
- Findings aggregated into validation report (subprocesses either updated report OR returned findings)
- Report saved before proceeding
- Next validation step loaded
@ -157,5 +159,6 @@ Then immediately load, read entire file, then execute {nextStepFile}.
- Skipping menu structure checks
- Not documenting violations
- Not saving report before proceeding
- Loading full file contents into parent context instead of using subprocess analysis
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY file's menus. Auto-proceed through all validation steps.
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Use subprocess optimization (Pattern 2) - each file in its own subprocess for deep menu structure analysis. Subprocess returns only findings to parent. Auto-proceed through all validation steps.

107
src/modules/bmb/workflows/workflow/steps-v/step-04-step-type-validation.md
View File

@ -23,19 +23,20 @@ To validate that each step file follows the correct pattern for its step type -
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
- 🎯 Load and validate EVERY step against its type pattern
- 🚫 DO NOT skip any files or checks
- 💬 Append findings to report, then auto-load next step
- 🎯 Load and validate EVERY step against its type pattern - use subprocess optimization (Pattern 2: per-file deep analysis) when available
- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
- 🚪 This is validation - systematic and thorough
## EXECUTION PROTOCOLS:
- 🎯 Load step type patterns first
- 💾 Check EACH file follows its designated type pattern
- 📖 Append findings to validation report
- 🎯 Load step type patterns first (use subprocess for data operations when available)
- 💾 Check EACH file follows its designated type pattern - use per-file subprocesses for deep analysis when available
- 📖 Append findings to validation report (subprocess updates report OR returns findings to parent)
- 🚫 DO NOT halt for user input - validation runs to completion
## CONTEXT BOUNDARIES:
@ -50,7 +51,21 @@ To validate that each step file follows the correct pattern for its step type -
### 1. Load Step Type Patterns
Load {stepTypePatterns} to understand the pattern for each type:
**Load {stepTypePatterns} to understand the pattern for each type:**
**If subprocess capability available:**
```markdown
Launch a subprocess that:
1. Loads {stepTypePatterns}
2. Extracts all pattern definitions deeply
3. Returns summary of patterns to parent (not full file - saves context)
```
**If subprocess unavailable:**
```markdown
Load {stepTypePatterns} in main context
# Larger context but still functional - demonstrates graceful fallback
```
**Step Types:**
1. **Init (Non-Continuable)** - Auto-proceed, no continuation logic
@ -66,16 +81,21 @@ Load {stepTypePatterns} to understand the pattern for each type:
### 2. Check EACH Step Against Its Type
**DO NOT BE LAZY - For EACH file in steps-c/:**
**DO NOT BE LAZY - For EACH file in steps-c/, launch a subprocess that:**
1. Determine what type this step SHOULD be from:
1. Determines what type this step SHOULD be from:
- Step number (01 = init, 01b = continuation, last = final)
- Design in {workflowPlanFile}
- Step name pattern
2. Load the step file
2. Loads the step file
3. Validate it follows the pattern for its type:
3. Validates it follows the pattern for its type
4. **EITHER** updates the validation report directly with its findings
5. **OR** returns structured findings to parent for aggregation
**SUBPROCESS ANALYSIS PATTERN - Validate each step file for:**
**For Init Steps:**
- ✅ Creates output from template (if document-producing)
@ -114,42 +134,46 @@ Load {stepTypePatterns} to understand the pattern for each type:
- ✅ Completion message
- ✅ No next step to load
### 3. Document Findings
**RETURN FORMAT:**
Return a concise summary containing:
- File name analyzed
- What type the step should be
- What type it actually is
- Whether it follows the correct pattern
- List of any violations found
- Overall pass/fail status
Create report table:
**Context savings:** Each subprocess returns only validation findings, not full file contents. Parent receives structured analysis objects instead of 10+ full step files.
```markdown
### Step Type Validation Results
### 3. Aggregate Findings and Document
| File | Should Be Type | Follows Pattern | Issues | Status |
|------|----------------|-----------------|--------|--------|
| step-01-init.md | Init (Continuable) | ✅ | None | ✅ PASS |
| step-01b-continue.md | Continuation | ✅ | None | ✅ PASS |
| step-02-*.md | Middle (Standard) | ✅ | None | ✅ PASS |
| step-03-*.md | Middle (Simple) | ❌ | Has A/P (should be C-only) | ❌ FAIL |
| step-04-*.md | Branch | ⚠️ | Missing custom menu letters | ⚠️ WARN |
| step-N-final.md | Final | ✅ | None | ✅ PASS |
```
**After ALL files analyzed, aggregate findings from subprocesses and document results:**
**Document the following in the validation report:**
- Overall summary of step type validation (how many steps checked, pass/fail counts)
- For each step file:
- File name
- What type the step should be (based on design, step number, naming)
- What type it actually is
- Whether it follows the correct pattern for its type
- Any violations or issues found
- Pass/fail/warning status
**Format:** Create a clear, readable section in the validation report that shows the validation results for each step file.
### 4. List Violations
```markdown
### Step Type Violations Found
**Compile and document all violations found:**
**step-03-[name].md:**
- Designated as Middle (Simple) but has A/P menu
- Should have C-only menu
**Document the following for any violations:**
**step-04-[name].md:**
- Designated as Branch but missing custom menu letters
- Handler doesn't route to different steps
- File name with violation
- What the violation is (specifically what doesn't match the expected pattern)
- What should be changed to fix it
- Severity level (error/warning)
**step-05-[name].md:**
- Designated as Validation Sequence but has user menu
- Should auto-proceed
**All other steps:** ✅ Follow their type patterns correctly
```
**For files that pass validation:** Briefly note they follow their type patterns correctly.
### 5. Append to Report
@ -170,11 +194,12 @@ Then immediately load, read entire file, then execute {nextStepFile}.
### ✅ SUCCESS:
- EVERY step validated against its type pattern
- All violations documented
- Findings appended to report
- EVERY step validated against its type pattern (ideally using per-file subprocess optimization)
- All violations documented with structured findings
- Findings aggregated from subprocesses into report
- Report saved before proceeding
- Next validation step loaded
- Context saved: parent receives only findings, not full file contents
### ❌ SYSTEM FAILURE:

81
src/modules/bmb/workflows/workflow/steps-v/step-05-output-format-validation.md
View File

@ -23,12 +23,13 @@ To validate that the workflow's output format matches the design - correct templ
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
### Step-Specific Rules:
- 🎯 Validate output format against design specifications
- 🚫 DO NOT skip any checks
- 💬 Append findings to report, then auto-load next step
- 🎯 Validate output format using subprocess optimization - per-file subprocess for step-to-output validation
- 🚫 DO NOT skip any checks - DO NOT BE LAZY
- 💬 Subprocess must either update validation report OR return findings to parent for aggregation
- 🚪 This is validation - systematic and thorough
## EXECUTION PROTOCOLS:
@ -36,6 +37,7 @@ To validate that the workflow's output format matches the design - correct templ
- 🎯 Load output format standards first
- 💾 Check template type matches design
- 📖 Check for final polish step if needed
- 🔍 Use subprocess optimization for step-to-output mapping validation - per-file subprocess for deep analysis
- 🚫 DO NOT halt for user input - validation runs to completion
## CONTEXT BOUNDARIES:
@ -114,11 +116,32 @@ From {workflowPlanFile}, identify:
### 5. Validate Step-to-Output Mapping
**For EACH step that outputs to document:**
**DO NOT BE LAZY - For EACH step that outputs to document, launch a subprocess that:**
1. Check the step has `outputFile` in frontmatter
2. Check the step appends/writes to output before loading next
3. Check the menu C option saves to output before proceeding
1. Loads that step file
2. Analyzes frontmatter for `outputFile` variable
3. Analyzes step body to verify output is written before loading next step
4. Checks menu C option saves to output before proceeding
5. Returns structured findings to parent for aggregation
**SUBPROCESS EXECUTION PATTERN:**
**For EACH step file, launch a subprocess that:**
1. Loads the step file
2. Performs deep analysis of output operations (frontmatter, body, menu options)
3. Returns findings to parent for aggregation
**RETURN FORMAT:**
Each subprocess should return:
- Step filename
- Whether output variable exists in frontmatter
- Whether output is saved before loading next step
- Whether menu option C saves to output before proceeding
- Output order number (if applicable)
- Any issues found
- Overall status (PASS/FAIL/WARNING)
**Parent aggregates findings into:**
**Steps should be in ORDER of document appearance:**
- Step 1 creates doc
@ -128,36 +151,15 @@ From {workflowPlanFile}, identify:
### 6. Document Findings
```markdown
### Output Format Validation Results
Document your output format validation findings in the validation report. Include:
**Workflow Produces Documents:** [Yes/No]
**Template Type:** [Free-form/Structured/Semi-structured/Strict]
**Template File Check:**
- Template exists: ✅/❌
- Matches designed type: ✅/❌
- Proper frontmatter: ✅/❌
**Final Polish Step:**
- Required: [Yes/No - based on template type]
- Present: ✅/❌
- Loads entire document: ✅/❌
- Optimizes flow: ✅/❌
**Step-to-Output Mapping:**
| Step | Has Output Variable | Saves Before Next | Status |
|------|-------------------|-------------------|--------|
| step-01-init.md | ✅ | ✅ | ✅ |
| step-02-*.md | ✅ | ✅ | ✅ |
| step-03-*.md | ❌ | N/A | ❌ FAIL |
**Issues Found:**
[List any issues with template, polish step, or mapping]
**Status:** ✅ PASS / ❌ FAIL / ⚠️ WARNINGS
```
- **Document Production**: Whether the workflow produces documents and what template type it uses
- **Template Assessment**: Template file existence, whether it matches the designed type, and frontmatter correctness
- **Final Polish Evaluation**: Whether a final polish step is required (for free-form workflows) and if present, whether it properly loads the entire document and optimizes flow
- **Step-to-Output Mapping**: For each step that outputs to the document, document whether it has the output variable in frontmatter, saves output before loading the next step, and properly saves in menu option C
- **Subprocess Analysis Summary**: Count of total steps analyzed, steps with output, steps saving correctly, and steps with issues
- **Issues Identified**: List any problems found with template structure, polish step, or output mapping
- **Overall Status**: Pass, fail, or warning designation
### 7. Append to Report
@ -180,10 +182,11 @@ Then immediately load, read entire file, then execute {nextStepFile}.
- Template type matches design
- Final polish step present if needed
- Step-to-output mapping validated
- Step-to-output mapping validated via subprocess optimization
- All findings documented
- Report saved before proceeding
- Next validation step loaded
- Subprocess pattern applied correctly (per-file analysis for step-to-output validation)
### ❌ SYSTEM FAILURE:
@ -191,5 +194,7 @@ Then immediately load, read entire file, then execute {nextStepFile}.
- Missing final polish step for free-form
- Not documenting mapping issues
- Not saving report before proceeding
- Not using subprocess optimization for step-to-output validation
- Loading all step files into parent context instead of per-file subprocess
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check template, polish step, and mapping. Auto-proceed through all validation steps.
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check template, polish step, and mapping. Use subprocess optimization for step-to-output validation - per-file subprocess returns analysis, not full content. Auto-proceed through all validation steps.

105
src/modules/bmb/workflows/workflow/steps-v/step-06-validation-design-check.md
View File

@ -23,18 +23,20 @@ To check if the workflow has proper validation steps when validation is critical
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
- 🎯 Check if workflow needs validation steps
- 🚫 DO NOT skip any validation step reviews
- 💬 Append findings to report, then auto-load next step
- 🎯 Check if workflow needs validation steps - use subprocess optimization (per-file deep analysis for Pattern 2)
- 🚫 DO NOT skip any validation step reviews - DO NOT BE LAZY
- 💬 Subprocess must either update validation report directly OR return findings to parent for aggregation
- 🚪 This is validation - systematic and thorough
## EXECUTION PROTOCOLS:
- 🎯 Determine if validation is critical for this workflow
- 💾 Check validation steps exist and are well-designed
- 🎯 Determine if validation is critical for this workflow - use subprocess optimization when available
- 💾 Check validation steps exist and are well-designed - launch subprocess for per-file deep analysis (Pattern 2)
- 💬 Subprocesses must either update validation report OR return findings for parent aggregation
- 📖 Append findings to validation report
- 🚫 DO NOT halt for user input - validation runs to completion
@ -67,11 +69,13 @@ From {workflowPlanFile}, check:
### 2. If Validation Is Critical, Check Validation Steps
**DO NOT BE LAZY - For EACH validation step in the workflow:**
**DO NOT BE LAZY - For EVERY validation step file, launch a subprocess that:**
1. Find the step (usually named with "validate", "check", "review")
2. Load the step file
3. Check for:
1. Loads that validation step file
2. Reads and analyzes the step's content deeply (prose, logic, quality, flow, anti-lazy language)
3. Returns structured analysis findings to parent for aggregation
**SUBPROCESS ANALYSIS PATTERN - Check each validation step file for:**
**Proper Validation Step Design:**
- ✅ Loads validation data/standards from `data/` folder
@ -93,7 +97,27 @@ From {workflowPlanFile}, check:
- ⚠️ For non-critical flows (entertainment, therapy, casual): validation may be inline
- ❌ ERROR if critical validation is mixed into create steps
### 3. Check Validation Data Files
**RETURN FORMAT:**
Return a structured analysis containing:
- Step file name
- Proper design checklist (loads data, systematic checks, auto-proceeds, clear criteria, reports findings)
- Anti-lazy language check (has mandate, mandate text, comprehensive coverage)
- Critical flow check (location, segregation, independence)
- Any issues found
- Overall status (PASS/FAIL/WARN)
**Context savings:** Each subprocess returns analysis (~30 lines), not full step file (~200 lines). Parent gets structured findings, not file contents.
### 3. Aggregate Findings from All Subprocesses
After all validation step files have been analyzed in subprocesses, aggregate findings:
**Process subprocess results:**
- Compile all structured analysis findings
- Identify patterns across validation steps
- Note any critical issues or warnings
### 4. Check Validation Data Files
**If workflow has validation steps:**
@ -103,57 +127,42 @@ From {workflowPlanFile}, check:
- Markdown files have clear criteria
- Data is referenced in step frontmatter
### 4. Document Findings
### 5. Document Findings
```markdown
### Validation Design Check Results
**Create/Update "Validation Design Check" section in {validationReportFile} using aggregated subprocess findings:**
**Workflow Requires Validation:** [Yes/No]
Document the following information:
**Workflow Domain Type:** [Critical/Compliance/Creative/Entertainment/Therapy/Casual]
**Whether validation is required:** Indicate if this workflow needs validation steps based on its domain type (critical/compliance/safety workflows vs. creative/exploratory ones)
**If Yes:**
**List of validation steps found:** Provide the names/paths of all validation step files in the workflow
**Validation Steps Found:**
- [List each validation step]
**Validation step quality assessment:** For each validation step, document:
- Whether it loads validation data/standards from the data/ folder
- Whether it has a systematic check sequence
- Whether it auto-proceeds through checks (vs. stopping for user input)
- Whether it includes "DO NOT BE LAZY" or similar anti-lazy language mandates
- Whether it has clear pass/fail criteria
- Overall status (PASS/FAIL/WARN)
**Validation Step Quality:**
| Step | Loads Data | Systematic | Auto-proceed | DO NOT BE LAZY | Criteria | Status |
|------|-----------|------------|--------------|----------------|----------|--------|
| step-04-validate.md | ✅ | ✅ | ✅ | ✅ | ✅ Clear | ✅ PASS |
| step-07-check.md | ❌ | ⚠️ Vague | ❌ User choice each | ❌ | ❌ Unclear | ❌ FAIL |
**"DO NOT BE LAZY" language presence:** For each validation step, note whether anti-lazy language is present and what it says
**"DO NOT BE LAZY" Language Check:**
| Step | Has Anti-Lazy Language | Status |
|------|----------------------|--------|
| step-04-validate.md | ✅ "DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE" | ✅ PASS |
| step-07-check.md | ❌ No anti-lazy language found | ⚠️ WARN |
**Critical flow segregation:** For workflows requiring validation, document:
- The workflow domain type
- Whether validation steps are in the steps-v/ folder (tri-modal structure) or inline with create steps
- Whether this segregation is appropriate for the workflow type
**Critical Flow Check:**
- Workflow domain: [Critical/Creative/Therapy/etc.]
- Validation location: [steps-v/ folder / inline with create]
- For [critical] workflows: Validation is in steps-v/ ✅ / ❌ mixed in create
- Status: ✅ Properly segregated / ⚠️ Consider segregation / ❌ Should be in steps-v/
**Validation data files:** List any validation data files found in the data/ folder, or note if they are missing
**Validation Data Files:**
- [List data files found, or note if missing]
**Issues identified:** List any problems found with the validation design, missing data files, or quality concerns
**Issues Found:**
[List issues with validation design]
**Overall status:** Provide final assessment (PASS/FAIL/WARN/N/A) with reasoning
**If No (Validation Not Required):**
- Workflow is [creative/exploratory/type]
- Validation is user's responsibility
- No validation steps needed ✅
### 6. Append to Report
**Status:** ✅ PASS / ❌ FAIL / ⚠️ WARNINGS / N/A (not applicable)
```
Update {validationReportFile} - replace "## Validation Design Check *Pending...*" with actual findings from subprocess aggregation.
### 5. Append to Report
Update {validationReportFile} - replace "## Validation Design Check *Pending...*" with actual findings.
### 6. Save Report and Auto-Proceed
### 7. Save Report and Auto-Proceed
**CRITICAL:** Save the validation report BEFORE loading next step.

103
src/modules/bmb/workflows/workflow/steps-v/step-07-instruction-style-check.md
View File

@ -23,20 +23,22 @@ To validate that workflow instructions use appropriate style - intent-based for
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
- 🎯 Review EVERY step's instruction style
- 🚫 DO NOT skip any files or style checks
- 💬 Append findings to report, then auto-load next step
- 🎯 Review EVERY step's instruction style using subprocess optimization - separate subprocess per file for deep analysis
- 🚫 DO NOT skip any files or style checks - DO NOT BE LAZY
- 💬 Subprocess must either update validation report OR return structured findings to parent for aggregation
- 🚪 This is validation - systematic and thorough
## EXECUTION PROTOCOLS:
- 🎯 Load intent vs prescriptive standards
- 💾 Check EACH step's instruction style
- 💾 Check EACH step's instruction style using subprocess optimization - each file in its own subprocess
- 📖 Validate style is appropriate for domain
- 🚫 DO NOT halt for user input - validation runs to completion
- 💬 Subprocesses must either update validation report OR return findings for parent aggregation
## CONTEXT BOUNDARIES:
@ -84,11 +86,17 @@ From {workflowPlanFile}, identify the workflow domain:
### 3. Check EACH Step's Instruction Style
**DO NOT BE LAZY - For EACH step file:**
**DO NOT BE LAZY - For EACH step file, launch a subprocess that:**
1. Load the step
2. Read the instruction sections (MANDATORY SEQUENCE)
3. Classify style:
1. Loads that step file
2. Reads the instruction sections (MANDATORY SEQUENCE)
3. Analyzes and classifies instruction style deeply
4. **EITHER** updates validation report directly with findings
5. **OR** returns structured analysis findings to parent for aggregation
**SUBPROCESS ANALYSIS PATTERN:**
Each subprocess performs deep analysis of instruction prose to classify style:
**Intent-Based Indicators:**
- ✅ Describes goals/outcomes, not exact wording
@ -108,6 +116,17 @@ From {workflowPlanFile}, identify the workflow domain:
- Some steps prescriptive (critical/required)
- Others intent-based (creative/facilitative)
**RETURN FORMAT:**
Each subprocess should return findings including:
- Step file identifier
- Instruction style classification (Intent-based/Prescriptive/Mixed)
- Style indicators observed
- Appropriateness assessment (PASS/WARN/FAIL)
- Specific notes and observations
- Examples of good and concerning instruction patterns
**Parent aggregates all subprocess findings into unified report section.**
### 4. Validate Appropriateness
**For Intent-Based Domains:**
@ -118,47 +137,41 @@ From {workflowPlanFile}, identify the workflow domain:
- ✅ Instructions should be prescriptive where compliance matters
- ⚠️ May have intent-based sections for creative elements
### 5. Document Findings
### 5. Aggregate Findings and Document
```markdown
### Instruction Style Check Results
After ALL subprocesses have analyzed their respective step files, aggregate findings and create/update section in {validationReportFile}.
**Domain Type:** [Creative/Personal/Exploratory OR Legal/Medical/Compliance]
Document the following:
**Appropriate Style:** [Intent-based/Prescriptive/Mixed]
**Workflow Domain Assessment:**
- Document the domain type (creative/interactive vs compliance/legal)
- State the appropriate instruction style for this domain
**Step Instruction Style Analysis:**
| Step | Style Type | Appropriate | Notes | Status |
|------|-----------|-------------|-------|--------|
| step-01-init.md | Intent-based | ✅ | Goals described, flexible | ✅ PASS |
| step-02-*.md | Intent-based | ✅ | "Think about response" | ✅ PASS |
| step-03-*.md | Prescriptive | ❌ | Domain is creative, too rigid | ⚠️ WARN |
| step-04-*.md | Intent-based | ✅ | Good facilitation language | ✅ PASS |
| step-05-*.md | Mixed | ✅ | Prescriptive for compliance, intent elsewhere | ✅ PASS |
**Instruction Style Findings:**
- List each step and its instruction style classification (intent-based/prescriptive/mixed)
- Note whether the style is appropriate for the domain
- Document specific examples of instruction language that demonstrate the style
- Identify any steps with inappropriate style (e.g., prescriptive in creative domain)
**Issues Found:**
**Issues Identified:**
- List any steps that are overly prescriptive for their domain
- List any steps that should be more prescriptive (for compliance domains)
- Note any style inconsistencies across steps
**Overly Prescriptive Steps:**
- [List steps that are too prescriptive for their domain]
- Example: "step-03-*.md says 'Ask exactly: X, Y, Z' but this is a creative workflow"
**Positive Findings:**
- Highlight steps with excellent instruction style
- Note effective use of intent-based facilitation language
- Identify appropriate use of prescriptive instructions (if applicable)
**Overly Flexible Steps (if prescriptive domain):**
- [List steps that should be more prescriptive]
- Example: "step-04-*.md is vague but this is a compliance workflow"
**Overall Status:**
- Provide final assessment (PASS/FAIL/WARN)
- Summarize key findings
**Style Inconsistencies:**
- [List steps where style doesn't match domain]
**Context Savings Note:** Using subprocess pattern (Pattern 2: per-file deep analysis), parent context receives only structured analysis findings (~50-100 lines per file) instead of full file contents (~200+ lines per file). For 10 steps: ~500-1000 lines received vs ~2000+ lines if loading all files in parent.
**Good Examples Found:**
- [Highlight steps with excellent intent-based instructions]
- [Highlight steps with appropriate prescriptive language]
### 6. Update Report with Aggregated Findings
**Status:** ✅ PASS / ❌ FAIL / ⚠️ WARNINGS
```
### 6. Append to Report
Update {validationReportFile} - replace "## Instruction Style Check *Pending...*" with actual findings.
Update {validationReportFile} - replace "## Instruction Style Check *Pending...*" with actual aggregated findings from all subprocesses.
### 7. Save Report and Auto-Proceed
@ -175,18 +188,22 @@ Then immediately load, read entire file, then execute {nextStepFile}.
### ✅ SUCCESS:
- EVERY step's instruction style reviewed
- EVERY step's instruction style reviewed via subprocess optimization (Pattern 2: per-file deep analysis)
- Each step analyzed in its own subprocess for style classification
- Style validated against domain appropriateness
- Issues documented with specific examples
- Findings appended to report
- Subprocess findings aggregated into unified report section
- Context savings achieved (~500-1000 lines received vs ~2000+ if loading all files)
- Report saved before proceeding
- Next validation step loaded
### ❌ SYSTEM FAILURE:
- Not checking every step's style
- Not checking every step's style via subprocess
- Not analyzing each file in its own subprocess
- Not validating against domain
- Not documenting style issues
- Not aggregating subprocess findings
- Not saving report before proceeding
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY step's instruction style. Auto-proceed through all validation steps.
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. For EACH step file, launch a subprocess to analyze instruction style deeply. Aggregate findings. Auto-proceed through all validation steps. Use graceful fallback if subprocess unavailable.

11
src/modules/bmb/workflows/workflow/steps-v/step-08b-subprocess-optimization.md
View File

@ -72,11 +72,16 @@ Load {subprocessPatterns} in main context
**DO NOT BE LAZY - For EVERY step file, launch a subprocess that:**
1. Loads the step file
2. Reads entire step to understand operations
3. Identifies ALL subprocess optimization opportunities
1. Loads that step file
2. ALSO loads {subprocessPatterns} to understand all patterns deeply (subprocess needs full context!)
3. Analyzes the step against each pattern looking for optimization opportunities
4. Returns specific, actionable suggestions to parent
**Subprocess gets full context:**
- The step file being analyzed
- The subprocess-optimization-patterns.md reference (all examples and patterns)
- Returns only findings to parent (context savings!)
**SUBPROCESS ANALYSIS PATTERN - Check each step file for:**
**Pattern 1: Single subprocess for grep/regex** - Operations that check/search multiple files for patterns (frontmatter validation, menu checks, path searches). Suggest: "Use single grep subprocess, return only matches"

117
src/modules/bmb/workflows/workflow/steps-v/step-09-cohesive-review.md
View File

@ -22,17 +22,21 @@ To perform a cohesive "ultra-think" review of the entire workflow - walk through
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step, ensure entire file is read
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
- 🎯 Review the workflow as a cohesive whole
- 🚫 DO NOT skip any aspect of the review
- 💬 Think deeply about quality and facilitation
- 🎯 Review the workflow as a cohesive whole - **NOTE: This step loads ENTIRE workflow for holistic review (different pattern from other validation steps)**
- 🚫 DO NOT skip any aspect of the review - DO NOT BE LAZY
- 💬 Subprocess optimization: When available, can use subprocesses to load individual step files and return structured summaries to parent for aggregation
- 💬 However, since cohesive review requires understanding the COMPLETE workflow as one unit, parent may need full context for proper holistic assessment
- 🚪 This is the meta-review - overall assessment
## EXECUTION PROTOCOLS:
- 🎯 Walk through the ENTIRE workflow end-to-end
- 🎯 Walk through the ENTIRE workflow end-to-end using subprocess optimization when available
- 💬 When using subprocesses: Each subprocess loads one step file, performs deep analysis, returns structured findings to parent for aggregation
- 💬 Subprocess must either update validation report directly OR return findings to parent for compilation
- 💾 Assess overall quality, not just individual components
- 📖 Think deeply: would this actually work well?
- 🚫 DO NOT halt for user input - validation runs to completion
@ -50,13 +54,32 @@ To perform a cohesive "ultra-think" review of the entire workflow - walk through
### 1. Load the Entire Workflow
**DO NOT BE LAZY - Load EVERY step file:**
**DO NOT BE LAZY - Load EVERY step file using subprocess optimization when available:**
**SUBPROCESS APPROACH (when available):**
For EACH workflow file (workflow.md + all step files in order), launch a subprocess that:
1. Loads that single file
2. Performs deep analysis of content, flow, quality, and connection points
3. Returns structured findings to parent for holistic aggregation
**Subprocess should return:**
- File name analyzed
- Purpose and flow position within the workflow
- How it connects to previous and next steps
- Quality indicators and any issues found
- Voice and tone consistency assessment
**FALLBACK APPROACH (if subprocess unavailable):**
Load workflow.md and EVERY step file in steps-c/ sequentially in main context:
1. Load workflow.md
2. Load EVERY step file in steps-c/ in order
3. Read through each step
4. Understand the complete flow
**CRITICAL:** Whether using subprocess or main context, you must understand the COMPLETE workflow as one cohesive unit before proceeding to assessment.
### 2. Walk Through the Workflow Mentally
**Imagine you are a user running this workflow:**
@ -93,16 +116,9 @@ To perform a cohesive "ultra-think" review of the entire workflow - walk through
### 4. Assess Overall Quality
**Rate the workflow on:**
**Evaluate the workflow across key dimensions:**
| Aspect | Rating (1-5) | Notes |
|--------|-------------|-------|
| Clear Goal | ⭐⭐⭐⭐⭐ | Is the purpose clear? |
| Logical Flow | ⭐⭐⭐⭐⭐ | Do steps progress logically? |
| Facilitation Quality | ⭐⭐⭐⭐⭐ | Does it facilitate well? |
| User Experience | ⭐⭐⭐⭐⭐ | Would users enjoy this? |
| Goal Achievement | ⭐⭐⭐⭐⭐ | Does it accomplish what it set out to? |
| Overall Quality | ⭐⭐⭐⭐⭐ | Total assessment |
Consider goal clarity, logical flow, facilitation quality, user experience, and goal achievement. Provide an overall quality assessment based on these dimensions.
### 5. Identify Strengths and Weaknesses
@ -122,80 +138,15 @@ To perform a cohesive "ultra-think" review of the entire workflow - walk through
### 6. Provide Recommendation
**Overall Assessment:**
- ✅ **EXCELLENT** - Ready to use, exemplifies best practices
- ✅ **GOOD** - Solid workflow, minor improvements possible
- ⚠️ **NEEDS WORK** - Has issues that should be addressed
- ❌ **PROBLEMATIC** - Major issues, needs significant revision
**Assess overall workflow readiness:**
**Recommendation:**
- [Ready for use / Ready with minor tweaks / Needs revision / Major rework needed]
Determine if the workflow is excellent (ready to use, exemplifies best practices), good (solid with minor improvements possible), needs work (has issues to address), or problematic (major issues requiring significant revision). Provide a clear recommendation on readiness for use.
### 7. Document Findings
```markdown
### Cohesive Review Results
**Document your cohesive review findings in the validation report:**
**Overall Assessment:** [EXCELLENT/GOOD/NEEDS WORK/PROBLEMATIC]
**Quality Ratings:**
| Aspect | Rating | Notes |
|--------|--------|-------|
| Clear Goal | ⭐⭐⭐⭐⭐ | [Notes] |
| Logical Flow | ⭐⭐⭐⭐⭐ | [Notes] |
| Facilitation Quality | ⭐⭐⭐⭐⭐ | [Notes] |
| User Experience | ⭐⭐⭐⭐⭐ | [Notes] |
| Goal Achievement | ⭐⭐⭐⭐⭐ | [Notes] |
| **Overall Quality** | **⭐⭐⭐⭐⭐** | [Total assessment] |
**Cohesiveness Analysis:**
**Flow Assessment:**
- [Describe the overall flow - does it work?]
- [Are there any jarring transitions?]
- [Does each step connect to the next?]
**Progression Assessment:**
- [Does the workflow build toward its goal?]
- [Is there a clear arc?]
- [Would a user feel they're making progress?]
**Voice and Tone:**
- [Is the voice consistent throughout?]
- [Does the AI persona work well?]
- [Is the collaboration style appropriate?]
**Strengths:**
1. [Major strength #1]
2. [Major strength #2]
3. [What makes this workflow excellent]
**Weaknesses:**
1. [Issue #1 that could be improved]
2. [Issue #2 that could be improved]
3. [What doesn't work as well]
**Critical Issues (if any):**
- [List any show-stopper problems]
- [Or note: No critical issues]
**What Makes This Work Well:**
- [Describe the excellent elements]
- [What should other workflows learn from this?]
**What Could Be Improved:**
- [Specific actionable improvements]
- [Priority: High/Medium/Low]
**User Experience Forecast:**
- [How would a user experience this workflow?]
- [Would they feel: guided/confused/satisfied/frustrated?]
**Recommendation:**
- [Ready for use / Ready with minor tweaks / Needs revision / Major rework needed]
**Status:** ✅ EXCELLENT / ✅ GOOD / ⚠️ NEEDS WORK / ❌ PROBLEMATIC
```
Include your overall assessment (excellent/good/needs work/problematic), quality evaluation across key dimensions, cohesiveness analysis (flow, progression, voice and tone), identified strengths and weaknesses, any critical issues, what makes the workflow work well, what could be improved, user experience forecast, and your recommendation on readiness for use.
### 8. Append to Report

150
src/modules/bmb/workflows/workflow/steps-v/step-10-report-complete.md
View File

@ -21,6 +21,7 @@ To check if a plan file exists (and run plan validation if it does), then summar
- 📖 CRITICAL: Read the complete step file before taking any action
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
### Step-Specific Rules:
@ -64,109 +65,39 @@ After plan validation (if applicable), load {validationReportFile} and read ALL
### 3. Create Summary Section
At the end of {validationReportFile}, replace "## Summary *Pending...*" with:
At the end of {validationReportFile}, replace "## Summary *Pending...*" with a comprehensive summary that includes:
```markdown
## Summary
- Validation completion date
- Overall status assessment (based on all validation steps)
- List of all validation steps completed with their individual results
- Summary of critical issues that must be fixed (or note if none found)
- Summary of warnings that should be addressed (or note if none found)
- Key strengths identified during validation
- Overall assessment of workflow quality
- Recommendation on readiness (ready to use / needs tweaks / needs revision / major rework needed)
- Suggested next steps for the user
**Validation Completed:** [current date]
Present this information in a clear, readable format - the exact structure is flexible as long as it covers all these points.
**Overall Status:**
[Based on all validation steps, determine overall status]
### 4. Update Report Status
**Validation Steps Completed:**
1. ✅ File Structure & Size - [PASS/FAIL/WARN]
2. ✅ Frontmatter Validation - [PASS/FAIL/WARN]
3. ✅ Path Violations Check - [PASS/FAIL/WARN]
4. ✅ Menu Handling Validation - [PASS/FAIL/WARN]
5. ✅ Step Type Validation - [PASS/FAIL/WARN]
6. ✅ Output Format Validation - [PASS/FAIL/WARN]
7. ✅ Validation Design Check - [PASS/FAIL/WARN/N/A]
8. ✅ Instruction Style Check - [PASS/FAIL/WARN]
9. ✅ Collaborative Experience Check - [PASS/FAIL/WARN]
10. ✅ Subprocess Optimization Analysis - [OPPORTUNITIES IDENTIFIED/NONE]
11. ✅ Cohesive Review - [EXCELLENT/GOOD/NEEDS WORK/PROBLEMATIC]
12. ✅ Plan Quality Validation - [FULLY IMPLEMENTED/PARTIALLY/MISSING/N/A]
Update the frontmatter of {validationReportFile} to set validationStatus to COMPLETE and add the completionDate. Keep existing fields like validationDate, workflowName, and workflowPath unchanged.
**Issues Summary:**
### 5. Present Summary to User
**Critical Issues (Must Fix):**
- [List any critical issues from all validation steps]
- [If none, state: No critical issues found]
Present a clear summary to the user that includes:
**Warnings (Should Fix):**
- [List any warnings from all validation steps]
- [If none, state: No warnings found]
- Confirmation that validation is complete
- Overall status of the workflow
- Quick results overview showing each validation step and its result
- Count of critical issues and warnings (or note if none found)
- Recommendation on workflow readiness
- Path to the full validation report
- Options for next steps (review detailed findings, make changes, explain results, or other actions)
**Strengths:**
- [List key strengths identified in validation]
Present this information in a natural, conversational way - the exact format doesn't matter as long as all this information is clearly communicated.
**Overall Assessment:**
[Summarize the overall quality of the workflow]
**Recommendation:**
- [Ready to use / Ready with minor tweaks / Needs revision / Major rework needed]
**Next Steps:**
- Review the detailed findings above
- Decide what changes to make
- Either fix issues directly or use edit workflow (if tri-modal)
```
### 3. Update Report Status
Update frontmatter of {validationReportFile}:
```yaml
---
validationDate: [original date]
completionDate: [current date]
workflowName: {new_workflow_name}
workflowPath: {targetWorkflowPath}
validationStatus: COMPLETE
---
```
### 4. Present Summary to User
"**✅ Validation Complete!**
I've completed extensive validation of your workflow. Here's the summary:"
**Overall Status:** [Overall status from summary]
**Quick Results:**
| Validation Step | Result |
|-----------------|--------|
| File Structure & Size | [emoji] [result] |
| Frontmatter | [emoji] [result] |
| Path Violations | [emoji] [result] |
| Menu Handling | [emoji] [result] |
| Step Types | [emoji] [result] |
| Output Format | [emoji] [result] |
| Validation Design | [emoji] [result or N/A] |
| Instruction Style | [emoji] [result] |
| Collaborative Experience | [emoji] [result] |
| Subprocess Optimization | [emoji] [result] |
| Cohesive Review | [emoji] [result] |
| Plan Quality | [emoji] [result or N/A] |
**Issues Found:**
- **Critical:** [count or "none"]
- **Warnings:** [count or "none"]
**Recommendation:** [Ready to use / Needs tweaks / Needs revision]
"**The full validation report is available at:**
`{validationReportFile}`
**Would you like me to:**
1. Review the detailed findings with you
2. Make specific changes to address issues
3. Explain any validation result in detail
4. Something else"
### 5. Present MENU OPTIONS
### 6. Present MENU OPTIONS
Display: **Validation Complete! Select an Option:** [R] Review Detailed Findings [F] Fix Issues [X] Exit Validation
@ -182,34 +113,19 @@ Display: **Validation Complete! Select an Option:** [R] Review Detailed Findings
- IF X: "Validation complete. Your workflow is at: {targetWorkflowPath}. You can make changes and re-run validation anytime."
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
### 6. If User Wants to Fix Issues
### 7. If User Wants to Fix Issues
**Options for fixing:**
Explain the available options for fixing issues:
**Option A: Manual Edits**
- User edits files directly
- Re-run validation to check fixes
- Manual edits: User edits files directly, then re-runs validation
- Guided edits: User specifies what to fix, help create specific edits for user approval
- Edit workflow: If the workflow has steps-e/, use the edit workflow to make systematic changes
**Option B: Guided Edits**
- User specifies what to fix
- Help create specific edits for user approval
- User applies edits
The exact format doesn't matter - just ensure the user understands their options for addressing issues.
**Option C: Edit Workflow (if tri-modal)**
- If workflow has steps-e/, use edit workflow
- Edit workflow can make systematic changes
### 8. Update Plan with Validation Status
### 7. Update Plan with Validation Status
Update {workflowPlanFile} frontmatter:
```yaml
---
validationStatus: COMPLETE
validationDate: [current date]
validationReport: {validationReportFile}
---
```
If a plan file exists at {workflowPlanFile}, update its frontmatter to include the validation status (COMPLETE), the current validation date, and a reference to the validation report file.
## CRITICAL STEP COMPLETION NOTE

190
src/modules/bmb/workflows/workflow/steps-v/step-11-plan-validation.md
View File

@ -20,18 +20,19 @@ To validate that a workflow plan (if it exists) has been fully implemented - all
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
- 📖 CRITICAL: Read the complete step file before taking any action
- ✅ This validation step only runs if a plan file exists
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
### Step-Specific Rules:
- 🎯 Load the complete plan file
- 🚫 DO NOT skip checking any requirement from the plan
- 💬 Validate that built workflow matches plan specifications
- 🎯 Validate plan requirements using subprocess optimization - separate subprocess per requirement area for deep analysis
- 🚫 DO NOT skip checking any requirement from the plan - DO NOT BE LAZY
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
- 🚪 This ensures the build actually delivered what was planned
## EXECUTION PROTOCOLS:
- 🎯 Load plan and extract all requirements/intent
- 💾 Check built workflow against plan
- 🎯 Load plan and extract all requirements/intent using subprocess optimization when available - separate subprocess per requirement area for deep analysis
- 💾 Subprocesses validate implementation against plan requirements and return findings for aggregation
- 📖 Document gaps and quality issues
- 🚫 Only run this step if workflowPlanFile exists
@ -61,126 +62,148 @@ First, check if {workflowPlanFile} exists:
**DO NOT BE LAZY - Extract EVERY requirement from the plan:**
From {workflowPlanFile}, extract:
**SUBPROCESS EXECUTION PATTERN:**
**From Discovery Section:**
- User's original idea/vision
- Core problem being solved
Launch a subprocess that:
1. Loads {workflowPlanFile}
2. Extracts all requirements from each section (Discovery, Classification, Requirements, Design, Tools)
3. Returns structured requirements list to parent
**From Classification Section:**
- 4 key decisions (document output, module, continuable, tri-modal)
- Target path
- Workflow name
**SUBPROCESS RETURNS:**
Structured requirements list organized by section (discovery, classification, requirements, design, tools) with all extracted items and a count of total requirements.
**From Requirements Section:**
- Flow structure (linear/looping/branching)
- User interaction style
- Inputs required
- Output specifications
- Success criteria
**If subprocess unavailable:** Load {workflowPlanFile} in main context and extract requirements (larger context but still functional - demonstrates graceful fallback).
**From Design Section:**
- Step outline with names and purposes
- Flow diagram
- Interaction patterns
- File structure requirements
**From Tools Section:**
- Tools configured
- Data files specified
---
### 3. Validate Each Requirement Against Built Workflow
**For EACH requirement extracted:**
**DO NOT BE LAZY - For EACH requirement area, launch a subprocess that:**
Check the built workflow to see if it was implemented:
1. Loads relevant workflow files (workflow.md, step files, etc.)
2. Validates that specific requirement area is implemented correctly
3. Assesses quality of implementation
4. **EITHER** updates validation report directly with findings
5. **OR** returns structured validation results to parent for aggregation
**Discovery Validation:**
**PATTERN 2: Separate subprocess per requirement area for deep analysis**
Each subprocess gets full context to deeply understand that requirement area and validate implementation quality:
---
**SUBPROCESS 1: Discovery Validation**
**Subprocess analyzes:**
- ✅ Built workflow addresses the original problem?
- ✅ Vision from discovery is reflected in final workflow?
**Classification Validation:**
**Subprocess returns:**
Discovery validation results indicating whether the original problem and vision from the plan are addressed in the built workflow, with quality assessment, status (✅/❌), and any gaps identified.
---
**SUBPROCESS 2: Classification Validation**
**Subprocess analyzes:**
- ✅ Document output matches plan (yes/no)?
- ✅ Module affiliation correct?
- ✅ Continuable support as specified?
- ✅ Tri-modal structure as specified?
**Requirements Validation:**
**Subprocess returns:**
Classification validation results for each classification attribute (document output, module, continuable, tri-modal) comparing what was specified vs what was implemented, with overall quality assessment, status (✅/❌), and any gaps.
---
**SUBPROCESS 3: Requirements Validation**
**Subprocess analyzes:**
- ✅ Flow structure matches plan?
- ✅ User interaction style as specified?
- ✅ All required inputs configured?
- ✅ Output format matches specification?
- ✅ Success criteria achievable?
**Design Validation:**
**Subprocess returns:**
Requirements validation results for flow structure, interaction style, inputs, outputs, and success criteria comparing what was specified vs what was implemented, with overall quality assessment, status (✅/❌), and any gaps.
---
**SUBPROCESS 4: Design Validation**
**Subprocess analyzes:**
- ✅ All steps from design present in workflow?
- ✅ Step purposes match design?
- ✅ Flow follows design diagram?
- ✅ Interaction patterns as specified?
**Tools Validation:**
**Subprocess returns:**
Design validation results for each step from the plan checking if it exists in the workflow and if the purpose matches, along with whether the flow follows the design diagram and interaction patterns match, with overall quality assessment, status (✅/❌), and any gaps.
---
**SUBPROCESS 5: Tools Validation**
**Subprocess analyzes:**
- ✅ Specified tools configured in workflow?
- ✅ Data files created as specified?
### 4. Check Implementation Quality
**Subprocess returns:**
Tools validation results checking which specified tools are configured and which data files were created, with overall quality assessment, status (✅/❌), and any gaps.
For each implemented requirement, assess quality:
---
**Quality Questions:**
- Is the implementation high quality or minimal/barely working?
- Would this actually facilitate well?
- Are there obvious gaps or issues?
**If subprocess unavailable:** Validate each requirement area sequentially in main context (larger context but still functional - demonstrates graceful fallback).
**Example:**
- Plan: "Highly collaborative, intent-based facilitation"
- Implementation: Has A/P menus, uses intent-based language ✅
---
- Plan: "Continuable workflow with session resume"
- Implementation: Has step-01b-continue.md, tracks stepsCompleted ✅
### 4. Aggregate Findings and Update Report
### 5. Document Findings
After ALL requirement area subprocesses complete, aggregate findings into validation report.
```markdown
### Plan Quality Validation Results
Document the following information:
**Plan File:** {workflowPlanFile}
**Plan Exists:** ✅ Yes
**Requirements Extracted:** [number] requirements from plan sections
**Plan Information:**
- Plan file location
- Whether a plan was found
- Total number of requirements extracted from the plan
**Implementation Coverage:**
For each requirement area from the plan (Discovery/Vision, Classification attributes, Requirements specifications, Design elements, Tools):
- What was specified in the plan
- Whether it was implemented in the workflow
- Quality assessment (High/Medium/Low)
- Implementation status
| Requirement Area | Specified | Implemented | Quality | Status |
|------------------|-----------|--------------|---------|--------|
| Discovery/Vision | [summary] | ✅/❌ | High/Med/Low | ✅/❌ |
| Document Output | [yes/no] | ✅/❌ | High/Med/Low | ✅/❌ |
| Continuable | [yes/no] | ✅/❌ | High/Med/Low | ✅/❌ |
| Tri-Modal | [yes/no] | ✅/❌ | High/Med/Low | ✅/❌ |
| Flow Structure | [type] | ✅/❌ | High/Med/Low | ✅/❌ |
| Interaction Style | [style] | ✅/❌ | High/Med/Low | ✅/❌ |
| [Step 01] | [purpose] | ✅/❌ | High/Med/Low | ✅/❌ |
| [Step 02] | [purpose] | ✅/❌ | High/Med/Low | ✅/❌ |
| ... | ... | ... | ... | ... |
**Missing Implementations:**
- [List any requirements from plan that are NOT in the built workflow]
**Implementation Gaps:**
List any requirements from the plan that are NOT present in the built workflow
**Quality Issues:**
- [List any requirements that are implemented but with poor quality]
List any requirements that are implemented but with quality concerns
**Gaps Between Plan and Reality:**
- [List where the built workflow doesn't match the plan]
**Plan-Reality Alignment:**
Describe where the built workflow doesn't match what was planned
**Plan Implementation Score:** [X]%
**Overall Assessment:**
- Plan implementation score (percentage)
- Overall status (Fully Implemented/Partially Implemented/Poorly Implemented/Missing Critical Items)
**Status:** ✅ FULLY IMPLEMENTED / ⚠️ PARTIALLY IMPLEMENTED / ❌ POORLY IMPLEMENTED / ❌ MISSING CRITICAL ITEMS
```
**Quality Assessment Framework:**
For each implemented requirement, assess quality:
- **High Quality**: Implementation follows best practices, would facilitate effectively
- **Medium Quality**: Functional but has issues or gaps
- **Low Quality**: Minimal/barely working, would not facilitate well
### 6. Append to Report
Examples:
- Plan specifies "Highly collaborative, intent-based facilitation" and implementation has A/P menus with intent-based language = High Quality
- Plan specifies "Continuable workflow with session resume" and implementation has step-01b-continue.md tracking stepsCompleted = High Quality
Append findings to {validationReportFile} after the "## Cohesive Review" section.
### 5. Append to Report
### 7. Save and Complete
Append the aggregated findings to {validationReportFile} after the "## Cohesive Review" section.
### 6. Save and Complete
Save the validation report. This is the final validation step.
@ -193,17 +216,22 @@ Save the validation report. This is the final validation step.
### ✅ SUCCESS:
- Plan file loaded completely
- Every requirement extracted and validated
- Implementation gaps documented
- Plan file loaded completely (in subprocess or main context)
- Every requirement extracted and validated using subprocess optimization when available
- Each requirement area analyzed in separate subprocess (or main context with graceful fallback)
- Implementation gaps documented with structured findings
- Quality assessed for each requirement
- Findings appended to report
- Findings aggregated and appended to report
- Context saved via subprocess pattern (return only findings, not full file contents)
### ❌ SYSTEM FAILURE:
- Not loading complete plan
- Skipping requirement checks
- Not validating each requirement area deeply
- Not using subprocess optimization when available
- Not documenting implementation gaps
- Not assessing quality
- Loading full file contents into parent instead of returning only findings
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY requirement from the plan. Document all gaps.
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY requirement from the plan. Use subprocess optimization (Pattern 2: per-requirement deep analysis) when available. Document all gaps. Return only findings to parent, not full file contents.

4
src/modules/bmm/workflows/2-plan-workflows/prd/steps-c/step-06-innovation.md
View File

@ -174,11 +174,11 @@ If no genuine innovation signals are found after exploration:
Display: "**Select:** [A] Advanced Elicitation - Let's try to find innovative angles [C] Continue - Skip innovation section and move to Project Type Analysis (Step 7 of 11)"
#### Menu Handling Logic:
### Menu Handling Logic:
- IF A: Proceed with content generation anyway, then return to menu
- IF C: Skip this step, then load, read entire file, then execute {nextStepFile}
#### EXECUTION RULES:
### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'

1
src/modules/cis/module.yaml
View File

@ -4,7 +4,6 @@ header: "Creative Innovation Suite (CIS) Module"
subheader: "No custom configuration required - uses Core settings only"
default_selected: false # This module will not be selected by default for new installations
# Variables from Core Config inserted:
## user_name
## communication_language