bmad-module-skill-forge 0.5.0 → 0.7.0

package/src/workflows/refine-architecture/steps-c/step-05-compile.md

@@ -0,0 +1,200 @@
+---
+name: 'step-05-compile'
+description: 'Produce the refined architecture document by annotating the original with gaps, issues, and improvements'
+
+nextStepFile: './step-06-report.md'
+outputFile: '{output_folder}/refined-architecture-{project_name}.md'
+---
+
+# Step 5: Compile Refined Architecture
+
+## STEP GOAL:
+
+Produce the refined architecture document by starting with the original as a base, adding gap-fill subsections, issue callout blocks, and improvement suggestions. Append a Refinement Summary. Present for user review before finalizing.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 📖 CRITICAL: Read the complete step file before taking any action
+- ⚙️ TOOL/SUBPROCESS FALLBACK: 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
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an architecture refinement analyst compiling the final refined document
+- ✅ Additive, not destructive — preserve every word of the original, only add refinements
+- ✅ The document must be in `{document_output_language}`
+
+### Step-Specific Rules:
+
+- 🚫 FORBIDDEN to discover new gaps, issues, or improvements — use only what Steps 02-04 produced
+- 🚫 FORBIDDEN to delete, reword, or rearrange original architecture content
+- 💬 Present compiled document for user review (Gate checkpoint)
+
+## EXECUTION PROTOCOLS:
+
+- Compile refined architecture from original + findings from Steps 02-04
+- Write output to {outputFile}, wait for user approval before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- From Steps 01-04: Architecture document, skill inventory, gap/issue/improvement findings
+- This step produces: The refined architecture document at {outputFile}
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Prepare the Original as Base
+
+Load the complete original architecture document.
+
+This is the base. Every line of the original MUST appear in the refined document, unmodified.
+
+**Context recovery check:** If gap, issue, or improvement findings from Steps 02-04 are not available in context (e.g., due to context degradation in long runs), attempt to read the durability state from `{forge_data_folder}/ra-state-{project_name}.md`. Parse the `<!-- [RA-GAPS] -->`, `<!-- [RA-ISSUES] -->`, and `<!-- [RA-IMPROVEMENTS] -->` comment blocks to recover the complete formatted findings (each block contains full citation text with evidence, not just counts). If a section is still missing or contains only summary counts after recovery, HALT: "⚠️ Context for the [Gaps|Issues|Improvements] analysis was lost and the durability state is insufficient to reconstruct findings. Re-run [RA] from the beginning — step 01 will reset the state file, then steps 02-04 will rebuild all findings."
+
+### 2. Insert Gap-Fill Subsections
+
+For each gap finding from Step 02:
+
+**Locate the most relevant section** in the original architecture where this integration would logically belong.
+
+**Insert a gap-fill subsection** one heading level deeper than the parent section:
+
+```markdown
+#### RA: {Library A} <-> {Library B} Integration Path
+
+> [!NOTE] **Gap Identified by Refine Architecture**
+> This integration path was not documented in the original architecture but is supported by skill API evidence.
+
+{Gap description with full evidence citation from Step 02}
+
+**Proposed Integration:**
+{Suggested architecture content describing how the libraries connect}
+```
+
+If no clear parent section exists, collect orphan gaps into a new section: "## RA: Additional Integration Paths"
+
+### 3. Insert Issue Annotations
+
+For each issue finding from Step 03:
+
+**Locate the section** containing the contradicted claim.
+
+**Insert an issue callout block** immediately after the contradicted text:
+
+```markdown
+> [!WARNING] **Issue Detected by Refine Architecture** ({severity})
+> Architecture states: "{quoted claim}"
+> Skill reality: {contradicting evidence from skill}
+> {IF VS report}: VS verdict: {verdict} for {pair}
+>
+> **Suggested Correction:** {specific correction with API evidence}
+```
+
+**Placement priority:** Place each issue callout immediately after the contradicted text in its original location. If the contradicted claim is inside a Markdown list item, code block, or table row where inserting a callout block would break syntax, place the callout immediately after the enclosing block instead. If the contradicted claim cannot be precisely located, collect into "## RA: Additional Issues Detected" at the end of the document, ordered by severity (Critical first, then Major, then Minor).
+
+### 4. Insert Improvement Suggestions
+
+For each improvement finding from Step 04:
+
+**Locate the section** where the library is discussed.
+
+**Insert an improvement subsection** one heading level deeper:
+
+```markdown
+#### RA: Enhancement — {Improvement Title}
+
+> [!TIP] **Improvement Suggested by Refine Architecture** ({value} value)
+> {skill_name} provides `{api}` which is not currently leveraged.
+
+{Full improvement description with evidence citation from Step 04}
+
+**How to Incorporate:**
+{Specific suggestion for updating the architecture}
+```
+
+**Order by value:** High value improvements first, then Medium, then Low.
+
+**Placement fallback:** If the library's only architecture mention is inside a table, code block, or Mermaid diagram where inserting a subsection would break syntax, collect into `## RA: Additional Improvements Suggested` at the end of the document.
+
+### 5. Add Refinement Summary Section
+
+Append a `## Refinement Summary` section containing:
+
+- **Header:** "Produced by: Refine Architecture workflow using {skill_count} skills" and date
+- **Changes Made table** with the following rows:
+
+| Category | Count | Breakdown |
+|----------|-------|-----------|
+| Gaps Filled | {gap_count} | — |
+| Issues Flagged | {issue_count} | Critical: {critical_count}, Major: {major_count}, Minor: {minor_count} |
+| Improvements Suggested | {improvement_count} | High: {high_count}, Medium: {medium_count}, Low: {low_count} |
+| Skills Used as Evidence | {skill_count} | — |
+- **Evidence Sources table:** Each skill name and how many refinements cite it
+- **Next Steps:** Review `[!WARNING]` issues, `[!NOTE]` gaps, `[!TIP]` improvements; then run **[SS] Stack Skill** to compose your individual skills into a unified stack skill, providing this refined architecture doc when prompted
+
+### 6. Write the Refined Document
+
+Write the complete refined architecture to `{outputFile}`.
+
+### 7. Present Compiled Document for Review
+
+"**Refined architecture compiled. Please review:**
+
+---
+
+{Display the Refinement Summary section only — not the full document}
+
+---
+
+**The full refined document has been written to:** `{outputFile}`
+
+Please review the refinements:
+- {gap_count} gap-fill subsections added
+- {issue_count} issue annotations inserted
+- {improvement_count} improvement suggestions included
+- Original architecture content preserved in full
+
+**Does the refinement look correct?**"
+
+### 8. Present MENU OPTIONS
+
+Display: **Select:** [C] Continue to Final Report
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting compilation
+- ONLY proceed to next step when user approves and selects 'C'
+
+#### Menu Handling Logic:
+
+- IF C: Load, read entire file, then execute {nextStepFile}
+- IF Any other: Process as feedback, adjust specific refinements in the document, rewrite {outputFile}, redisplay preview, then [Redisplay Menu Options](#8-present-menu-options)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Original architecture document preserved in full without modifications
+- Gap-fill subsections inserted at logical locations with evidence citations
+- Issue callout blocks inserted adjacent to contradicted claims with severity
+- Improvement suggestions inserted with value ratings and evidence
+- Refinement Summary section appended with accurate counts
+- Refined document written to {outputFile}
+- User reviewed and approved compilation
+- Proceeded to step 06 only after user selected C
+
+### ❌ SYSTEM FAILURE:
+
+- Deleting, rewording, or rearranging original architecture content
+- Discovering new findings not from Steps 02-04
+- Inserting refinements without evidence citations
+- Proceeding without user review (Gate checkpoint)
+- Not writing the document to {outputFile} before presenting for review
+- Hardcoded paths instead of frontmatter variables
+
+**Master Rule:** Additive only. Preserve the original. Get user approval before proceeding.

package/src/workflows/refine-architecture/steps-c/step-06-report.md

@@ -0,0 +1,147 @@
+---
+name: 'step-06-report'
+description: 'Present refinement summary to user with counts, next steps, and review options'
+
+outputFile: '{output_folder}/refined-architecture-{project_name}.md'
+---
+
+# Step 6: Present Report
+
+## STEP GOAL:
+
+Present the complete refinement summary to the user. Display counts of gaps filled, issues flagged, and improvements suggested. Provide the output file path and recommend next steps. Offer the user options to review changes in detail or exit. This is the FINAL step — no nextStepFile.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 📖 CRITICAL: Read the complete step file before taking any action
+- ⚙️ TOOL/SUBPROCESS FALLBACK: 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
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an architecture refinement analyst delivering the final summary
+- ✅ Present findings clearly and concisely — the user needs to decide which refinements to keep
+- ✅ Next step recommendations must be specific and actionable
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on presenting the completed refinement — no new analysis
+- 🚫 FORBIDDEN to discover new gaps, issues, or improvements
+- 🚫 FORBIDDEN to modify the refined document — only read and present
+- 📋 This is the FINAL step — no nextStepFile
+
+## EXECUTION PROTOCOLS:
+
+- Load and present the refinement summary from the compiled document
+- No new content written — document was finalized in Step 05
+- Present summary, next steps, and review options clearly
+- Read-only presentation — do not alter document data
+
+## CONTEXT BOUNDARIES:
+
+- Available: Complete {outputFile} with all refinements from Steps 02-05
+- Focus: Clear, actionable presentation of refinement results
+- Limits: Do not add new analysis or change any refinements
+- Dependencies: All previous steps must be complete (Steps 01-05)
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Load Refined Document
+
+Read the `{outputFile}` to have all data available for presentation.
+
+Verify the `## Refinement Summary` section is present. If it is absent, HALT: "⚠️ Refinement Summary not found in `{outputFile}`. Step 05 may not have completed successfully. Re-run [RA] from the beginning."
+
+**Extract metrics from the Refinement Summary section:** Parse `gap_count`, `issue_count`, `improvement_count`, `critical_count`, `major_count`, `minor_count`, `high_count`, `medium_count`, `low_count`, and `skill_count` from the Changes Made table and Evidence Sources table. Use these extracted values in the summary table and next-steps sections below.
+
+### 2. Display Summary
+
+"**Refine Architecture — Refinement Complete**
+
+---
+
+| Metric | Count |
+|--------|-------|
+| **Gaps Filled** | {gap_count} |
+| **Issues Flagged** | {issue_count} (Critical: {critical_count}, Major: {major_count}, Minor: {minor_count}) |
+| **Improvements Suggested** | {improvement_count} (High: {high_count}, Medium: {medium_count}, Low: {low_count}) |
+| **Skills Used as Evidence** | {skill_count} |
+
+**Evidence Sources:** (which skills contributed evidence)
+
+{Display the Evidence Sources table from the Refinement Summary section of the document}
+
+---
+
+**Your refined architecture is at:** `{outputFile}`
+
+The original architecture content is fully preserved. All refinements are clearly marked with `[!NOTE]`, `[!WARNING]`, and `[!TIP]` callout blocks that you can accept, modify, or remove."
+
+### 3. Present Next Steps
+
+"**Recommended next steps:**
+
+1. **Review the refined document** — accept, modify, or remove individual refinements
+2. **[SS] Stack Skill** — compose-mode activates automatically when SS detects existing individual skills without a codebase; provide this refined architecture doc as the architecture document when prompted
+3. **Re-run [VS] Verify Stack** if you made changes based on issue corrections — to confirm resolution
+
+{IF issues with Critical severity were found:}
+**⚠️ Attention:** {critical_count} critical issue(s) were flagged. These indicate fundamental contradictions between your architecture and the verified API surfaces. Address these before proceeding to stack skill composition."
+
+### 4. Present Menu
+
+Display: "**[R] Review changes in detail** | **[X] Exit refinement**"
+
+#### Menu Handling Logic:
+
+- **IF R:** Walk through each refinement with its full evidence citation:
+  1. First, all gaps with their evidence and proposed integration paths
+  2. Then, all issues ordered by severity with architecture claim vs. skill reality
+  3. Finally, all improvements ordered by value with untapped capability details
+  After completing the walkthrough, redisplay the menu.
+
+- **IF X:** "**Refined architecture saved to:** `{outputFile}`
+
+Re-run **[RA] Refine Architecture** anytime after updating your skills or architecture document.
+
+**Architecture refinement complete.**"
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting the menu
+- R may be selected multiple times — always walk through all refinements
+- X ends the workflow
+
+## CRITICAL STEP COMPLETION NOTE
+
+This is the final step of the refine-architecture workflow. When the user selects X, the workflow is complete. The refined architecture at `{outputFile}` contains the full original content plus all gap-fills, issue annotations, and improvement suggestions backed by skill API evidence.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Refined document loaded and verified for Refinement Summary section
+- Summary displayed with accurate counts for gaps, issues, and improvements
+- Output file path displayed prominently
+- Next steps presented with specific workflow recommendations
+- Critical issues highlighted if present
+- Menu presented with R and X options
+- Detailed review walkthrough available on R selection with full evidence citations
+- Workflow exits cleanly on X with saved file path
+
+### ❌ SYSTEM FAILURE:
+
+- Discovering new findings or changing refinements in this step
+- Modifying the refined document content
+- Not presenting the menu
+- Not displaying the document save path on exit
+- Inaccurate counts in the summary
+- Hardcoded paths instead of frontmatter variables
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/refine-architecture/workflow.md

@@ -0,0 +1,61 @@
+---
+name: refine-architecture
+description: Improve architecture doc using verified skill data and VS feasibility findings
+web_bundle: true
+installed_path: '{project-root}/_bmad/skf/workflows/skillforge/refine-architecture'
+---
+
+# Refine Architecture
+
+**Goal:** Take an original architecture document + generated skills + optional VS feasibility report, and produce a refined architecture with gaps filled, issues flagged, and improvements suggested — all backed by specific API evidence from the generated skills.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are also an architecture refinement analyst operating in Ferris Architect mode. You bring expertise in API surface analysis, integration gap detection, and evidence-backed architecture improvement, while the user brings their architecture vision and generated skills. Execute with analytical precision — every suggestion must cite specific APIs from the generated skills. Evidence-backed suggestions, not speculation.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self-contained instruction file that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory — never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **Additive, Not Destructive**: This workflow enhances the original architecture — it never deletes original content, only adds annotations, subsections, and suggestions
+- **Evidence-Backed Refinement**: Every gap, issue, or improvement must cite specific APIs, types, or function signatures from the generated skills
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+- ⚙️ **TOOL/SUBPROCESS FALLBACK**: 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
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- 📝 **DOCUMENT-PRODUCING**: This workflow outputs a refined architecture markdown file
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Module Configuration Loading
+
+Load and read full config from {project-root}/_bmad/skf/config.yaml and resolve:
+
+- `project_name`, `user_name`, `communication_language`, `document_output_language`
+- `skills_output_folder`, `forge_data_folder`, `output_folder`
+
+### 2. First Step Execution
+
+Load, read the full file and then execute `./steps-c/step-01-init.md` to begin the workflow.

package/src/workflows/setup-forge/data/tier-rules.md

@@ -7,16 +7,20 @@
 | ast-grep | `ast-grep --version` | Returns version string without error |
 | gh | `gh --version` | Returns version string without error |
 | qmd | `qmd status` | Returns status indicating initialized and operational |
+| ccc | Step A: `ccc --help` Step B: `ccc doctor` | Step A: exits 0 (binary exists). Step B: daemon running, version string, model check OK |
 
-**Important:** Use verification commands, not existence checks (`which`, `command -v`). A tool must be functional, not just present on PATH.
+**Important:** Use verification commands, not existence checks (`which`, `command -v`). A tool must be functional, not just present on PATH. For daemon-based tools (ccc), verify both binary existence and daemon health.
 
 ## Tier Calculation
 
-| Tier | Required Tools | Rule |
-|------|---------------|------|
-| Quick | None | Default when no tools are available |
-| Forge | ast-grep | ast-grep available, regardless of gh/qmd |
-| Deep | ast-grep + gh + qmd | All three tools available and functional |
+| Priority | Tier | Required Tools | Rule |
+|----------|------|---------------|------|
+| 1 (highest) | Deep | ast-grep + gh + qmd | All three core tools available and functional |
+| 2 | Forge+ | ast-grep + ccc | ast-grep AND ccc available, regardless of gh/qmd |
+| 3 | Forge | ast-grep | ast-grep available, without ccc/gh/qmd |
+| 4 (default) | Quick | None | Default when no tools are available |
+
+**Evaluation order:** Check Deep first, then Forge+, then Forge. The first match wins. This ensures Deep always takes priority when all tools are present.
 
 **Override:** If `tier_override` is set in preferences.yaml, use that value instead of calculated tier.
 
@@ -24,6 +28,9 @@
 - gh available but no ast-grep → Quick (gh alone doesn't unlock Forge)
 - ast-grep + gh but no qmd → Forge (qmd required for Deep)
 - ast-grep + qmd but no gh → Forge (gh required for Deep)
+- ccc available but no ast-grep → Quick (ccc alone doesn't unlock Forge+)
+- ast-grep + ccc + gh but no qmd → Forge+ (qmd required for Deep)
+- ast-grep + gh + qmd + ccc → Deep (Deep subsumes Forge+; ccc enhances transparently)
 
 ## Tier Capability Descriptions
 
@@ -35,6 +42,9 @@ Use these for positive-framing in the report step. Describe what the tier GIVES,
 ### Forge Tier
 "Forge tier active. You have AST-backed structural code analysis with line-level citations, plus template-driven generation. Every skill instruction traces to verified source code."
 
+### Forge+ Tier
+"Forge+ tier active. Semantic-guided precision compilation — cocoindex-code maps the codebase semantically before AST extraction runs. Every skill begins with a ranked discovery pass that surfaces the most relevant source regions, then AST-backed verification gives each export its line-level citation."
+
 ### Deep Tier
 "Deep tier active. Full capability unlocked — AST-backed code analysis, GitHub repository exploration, and QMD knowledge search with cross-repository synthesis. Maximum provenance and intelligence."
 

package/src/workflows/setup-forge/steps-c/step-01-detect-and-tier.md

@@ -2,7 +2,7 @@
 name: 'step-01-detect-and-tier'
 description: 'Detect available tools and determine forge capability tier'
 
-nextStepFile: './step-02-write-config.md'
+nextStepFile: './step-01b-ccc-index.md'
 tierRulesData: '../data/tier-rules.md'
 ---
 
@@ -10,7 +10,7 @@ tierRulesData: '../data/tier-rules.md'
 
 ## STEP GOAL:
 
-Verify availability of the three forge tools (ast-grep, gh, qmd), read any existing configuration for re-run comparison, check for tier override, and calculate the capability tier.
+Verify availability of the four forge tools (ast-grep, gh, qmd, ccc), read any existing configuration for re-run comparison, check for tier override, and calculate the capability tier.
 
 ## MANDATORY EXECUTION RULES (READ FIRST):
 
@@ -30,7 +30,7 @@ Verify availability of the three forge tools (ast-grep, gh, qmd), read any exist
 
 - 🎯 Focus only on tool detection and tier calculation
 - 🚫 FORBIDDEN to write any files — that is step-02's job
-- 🚫 FORBIDDEN to skip any tool check — all 3 must be verified
+- 🚫 FORBIDDEN to skip any tool check — all 4 must be verified
 - 💬 Tool command failures are NOT errors — they indicate unavailability
 
 ## EXECUTION PROTOCOLS:
@@ -38,13 +38,14 @@ Verify availability of the three forge tools (ast-grep, gh, qmd), read any exist
 - 🎯 Follow the MANDATORY SEQUENCE exactly
 - 💾 Store all results in memory for step-02
 - 📖 Load tier-rules.md for calculation reference
-- 🚫 FORBIDDEN to proceed without checking all 3 tools
+- 🚫 FORBIDDEN to proceed without checking all 4 tools
 
 ## CONTEXT BOUNDARIES:
 
 - This is the first step — no prior context exists
 - Available: forge-tier.yaml and preferences.yaml may exist from prior runs
 - Focus: tool verification and tier calculation only
+- Produces: `{detected_tools}`, `{calculated_tier}`, `{previous_tier}`, `{tier_override}` for downstream steps
 - Dependencies: none — this step bootstraps everything
 
 ## MANDATORY SEQUENCE
@@ -95,22 +96,38 @@ Check if the `SNYK_TOKEN` environment variable is set:
 
 This is informational only — security scan availability does NOT affect the tier level. It is recorded in forge-tier.yaml so that create-skill's validation step can report actionable guidance when security scanning is unavailable.
 
-### 7. Calculate Tier
+### 7. Verify Tool: ccc (cocoindex-code)
 
-**If `{tier_override}` is set and valid (Quick, Forge, or Deep):**
+**Step A — Binary existence:** Run `ccc --help`
+
+- If exits 0: binary confirmed. Continue to Step B.
+- If fails (command not found or error): record `{ccc: false}`. Skip Step B.
+
+**Step B — Daemon health:** Run `ccc doctor`
+
+- If daemon is running and model check OK: record `{ccc: true, ccc_daemon: "healthy"}` and store version string from output
+- If daemon is not running: record `{ccc: true, ccc_daemon: "stopped"}` — binary available, daemon needs starting. Step-01b will handle this.
+- If error or timeout: record `{ccc: true, ccc_daemon: "error"}` — binary works but daemon has issues.
+
+ccc availability gates the Forge+ tier and enhances Deep tier when present.
+
+### 8. Calculate Tier
+
+**If `{tier_override}` is set and valid (Quick, Forge, Forge+, or Deep):**
 - Use `{tier_override}` as `{calculated_tier}`
 - Note that override is active for the report step
 
-**If no override, apply tier rules from {tierRulesData}:**
+**If no override, apply tier rules from {tierRulesData} in order — the first matching rule wins. Do not continue checking once a match is found:**
 - `{ast_grep}` AND `{gh_cli}` AND `{qmd}` all true → **Deep**
-- `{ast_grep}` true (regardless of gh/qmd) → **Forge**
+- `{ast_grep}` AND `{ccc}` both true (regardless of gh/qmd) → **Forge+**
+- `{ast_grep}` true (regardless of ccc/gh/qmd) → **Forge**
 - Otherwise → **Quick**
 
 **If `{tier_override}` is set but invalid:** ignore it, use detected tier, flag for warning in report.
 
-### 8. Auto-Proceed
+### 9. Auto-Proceed
 
-"**Proceeding to write configuration...**"
+"**Proceeding to CCC index check...**"
 
 #### Menu Handling Logic:
 
@@ -123,7 +140,7 @@ This is informational only — security scan availability does NOT affect the ti
 
 ## CRITICAL STEP COMPLETION NOTE
 
-ONLY WHEN all 3 core tools have been verified, optional security scan checked, and the tier calculated will you load and read fully `{nextStepFile}` to execute the configuration write step.
+ONLY WHEN all 4 core tools have been verified, optional security scan checked, and the tier calculated will you load and read fully `{nextStepFile}` to execute the CCC index check step.
 
 ---
 
@@ -131,19 +148,20 @@ ONLY WHEN all 3 core tools have been verified, optional security scan checked, a
 
 ### ✅ SUCCESS:
 
-- All 3 tools checked via verification commands (not existence checks)
+- All 4 tools checked via verification commands (not existence checks)
 - Existing forge-tier.yaml read for re-run comparison (if present)
 - Existing preferences.yaml read for tier_override (if present)
 - Tier correctly calculated from tool results or override applied
-- All results stored in context for step-02
-- Auto-proceeded to step-02
+- All results stored in context for step-01b and step-02
+- Auto-proceeded to step-01b
 
 ### ❌ SYSTEM FAILURE:
 
-- Skipping any tool verification
+- Skipping any tool verification (ast-grep, gh, qmd, ccc — all 4 must be checked)
 - Using `which` or `command -v` instead of verification commands
 - Assuming tool availability without running the command
 - Writing files in this step (that is step-02)
 - Not checking for existing configuration on re-runs
+- Not checking ccc availability (both binary and daemon health)
 
 **Master Rule:** Every tool MUST be verified empirically. No assumptions, no shortcuts.