bmad-module-skill-forge 0.5.0 → 0.7.0

package/package.json

@@ -1,8 +1,8 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-module-skill-forge",
-  "version": "0.5.0",
-  "description": "BMAD module — Turn code and docs into instructions AI agents can actually follow. Progressive capability tiers (Quick/Forge/Deep).",
+  "version": "0.7.0",
+  "description": "BMAD module — Turn code and docs into instructions AI agents can actually follow. Progressive capability tiers (Quick/Forge/Forge+/Deep).",
   "keywords": [
     "bmad",
     "bmad-method",

package/src/agents/forger.agent.yaml

@@ -15,7 +15,7 @@ agent:
       Skill compilation specialist who transforms code repositories, documentation, and developer discourse into verified agent skills.
       Manages the full lifecycle: source analysis, skill briefing, AST-backed compilation,
       integrity testing, and ecosystem-ready export across progressive capability tiers
-      (Quick/Forge/Deep).
+      (Quick/Forge/Forge+/Deep).
 
     identity: |
       The forge master — a precision-focused craftsman who works through four modes:
@@ -41,11 +41,11 @@ agent:
       - "Agent-level knowledge informs judgment across workflows — consult knowledge/ when a step directs, not from memory"
 
   critical_actions:
-    - "Load COMPLETE file {project-root}/_bmad/_memory/forger-sidecar/preferences.yaml"
-    - "Load COMPLETE file {project-root}/_bmad/_memory/forger-sidecar/forge-tier.yaml"
-    - "ONLY read/write files in {project-root}/_bmad/_memory/forger-sidecar/"
-    - "Consult {project-root}/_bmad/skf/knowledge/skf-knowledge-index.csv to select knowledge fragments under knowledge/ and load only the files needed for the current task"
-    - "Load the referenced fragment(s) from {project-root}/_bmad/skf/knowledge/ before giving recommendations"
+    - "Load COMPLETE file {sidecar_path}/preferences.yaml"
+    - "Load COMPLETE file {sidecar_path}/forge-tier.yaml"
+    - "ONLY write STATE files to {project-root}/_bmad/_memory/forger-sidecar/ — reading from knowledge/ and workflow files is expected"
+    - "When a workflow step directs knowledge consultation, consult {project-root}/_bmad/skf/knowledge/skf-knowledge-index.csv to select the relevant fragment(s) and load only those files"
+    - "Load the referenced fragment(s) from {project-root}/_bmad/skf/ using the path in the fragment_file column (e.g., knowledge/overview.md resolves to {project-root}/_bmad/skf/knowledge/overview.md) before giving recommendations on the topic the step directed"
 
   menu:
     - trigger: SF or fuzzy match on setup-forge
@@ -80,6 +80,14 @@ agent:
       workflow: "{project-root}/_bmad/skf/workflows/skillforge/audit-skill/workflow.md"
       description: "[AS] Audit Skill — check for drift"
 
+    - trigger: VS or fuzzy match on verify-stack
+      workflow: "{project-root}/_bmad/skf/workflows/skillforge/verify-stack/workflow.md"
+      description: "[VS] Verify Stack — validate tech stack feasibility against architecture and PRD"
+
+    - trigger: RA or fuzzy match on refine-architecture
+      workflow: "{project-root}/_bmad/skf/workflows/skillforge/refine-architecture/workflow.md"
+      description: "[RA] Refine Architecture — improve architecture doc using verified skill data"
+
     - trigger: TS or fuzzy match on test-skill
       workflow: "{project-root}/_bmad/skf/workflows/skillforge/test-skill/workflow.md"
       description: "[TS] Test Skill — verify completeness"
@@ -88,6 +96,10 @@ agent:
       workflow: "{project-root}/_bmad/skf/workflows/skillforge/export-skill/workflow.md"
       description: "[EX] Export Skill — package for distribution"
 
+    - trigger: KI or fuzzy match on knowledge-index
+      action: "Load and display {project-root}/_bmad/skf/knowledge/skf-knowledge-index.csv — cross-cutting knowledge fragments available for JiT loading"
+      description: "[KI] Knowledge Index — list available knowledge fragments"
+
     - trigger: WS or fuzzy match on workflow-status
       action: "Show current lifecycle position, active skill briefs, and forge tier status"
       description: "[WS] Workflow Status — show current lifecycle position"

package/src/forger/README.md

@@ -9,7 +9,7 @@ Cross-session state for the SKF module's skill compilation lifecycle.
 ## Files
 
 - `preferences.yaml` — User preferences: language defaults, output format settings
-- `forge-tier.yaml` — Tool availability (ast-grep, gh, QMD) and derived capability tier
+- `forge-tier.yaml` — Tool availability (ast-grep, gh, QMD, ccc), derived capability tier, CCC index state, and QMD collection registry
 
 ## Runtime Access
 

package/src/forger/forge-tier.yaml

@@ -6,8 +6,25 @@ tools:
   ast_grep: ~
   gh_cli: ~
   qmd: ~
+  ccc: ~
+  ccc_daemon: ~
+  security_scan: ~ # Detected but not yet consumed by downstream workflows — reserved for future validation pre-check
 
 # Capability tier (derived from tool availability)
-# Quick = no tools required | Forge = + ast-grep | Deep = + ast-grep + gh + QMD
+# Quick = no tools | Forge = + ast-grep | Forge+ = + ast-grep + ccc | Deep = + ast-grep + gh + QMD
 tier: ~
 tier_detected_at: ~
+
+# CCC semantic index state (managed by setup-forge and extraction workflows)
+ccc_index:
+  indexed_path: ~
+  last_indexed: ~
+  status: "none"
+  staleness_threshold_hours: 24
+
+# CCC index registry (tracks which source paths have been indexed for skill workflows)
+ccc_index_registry: []
+
+# QMD collection registry (populated by create-skill, consumed by audit/update-skill)
+# Each entry tracks a QMD collection created during skill workflows
+qmd_collections: []

package/src/forger/preferences.yaml

@@ -2,16 +2,14 @@
 # Created by setup-forge workflow on first run
 # Edit this file to customize Ferris behavior
 
-# Override detected tier (set to Quick, Forge, or Deep to force a tier)
+# Override detected tier (set to Quick, Forge, Forge+, or Deep to force a tier)
 tier_override: ~
 
 # Passive context injection (set to false to skip snippet generation and CLAUDE.md updates during export)
 passive_context: true
 
-# Language defaults
-output_language: ~
-skill_format_version: ~
-
-# Output preferences
-citation_style: ~
-confidence_display: ~
+# Reserved for future use — these fields are not yet consumed by any workflow step
+# output_language: ~
+# skill_format_version: ~
+# citation_style: ~
+# confidence_display: ~

package/src/knowledge/agentskills-spec.md

@@ -63,7 +63,7 @@ The format implements a three-phase loading model:
 | Phase | What Loads | Token Cost | When |
 | --- | --- | --- | --- |
 | Discovery | `name` + `description` from frontmatter | ~50-100 tokens | Agent startup, all skills |
-| Activation | Full `SKILL.md` body | < 5000 tokens | Task matches skill description |
+| Activation | Full `SKILL.md` body | < 5000 tokens (~500 lines guideline) | Task matches skill description |
 | Execution | Files from `scripts/`, `references/`, `assets/` | Variable | SKILL.md directs agent to load |
 
 ## Pattern Examples

package/src/knowledge/architecture-verification.md

@@ -0,0 +1,102 @@
+# Architecture Verification
+
+## Principle
+
+A tech stack is only as strong as its weakest integration point. Architecture verification cross-references generated skills against architecture documents to produce evidence-backed feasibility verdicts — before a single line of application code is written. Every verdict must cite specific APIs, types, or function signatures from the generated skills. Speculation is labeled; evidence is cited.
+
+## Rationale
+
+Architects commonly evaluate tech stacks by reading documentation, building proof-of-concepts, or asking on forums. This process is slow, incomplete, and leaves integration risks undiscovered until implementation. SKF's pre-code verification pipeline replaces guesswork with systematic cross-referencing:
+
+1. Generate skills for each candidate library (CS/QS) — producing T1/T2 extraction data
+2. Run Verify Stack (VS) — cross-reference extracted APIs against architecture integration claims
+3. Run Refine Architecture (RA) — improve the architecture doc with verified API evidence
+4. Run Stack Skill compose mode (SS) — synthesize a consolidated integration playbook
+
+Without architecture verification:
+- Integration risks surface during implementation (costly, late)
+- Architecture documents describe intent without evidence
+- Library selection is based on feature lists, not API compatibility
+
+With architecture verification:
+- Integration feasibility is validated pre-code with API-level evidence
+- Architecture documents become evidence-backed engineering artifacts
+- Library swaps happen in minutes (regenerate skill, re-run VS) not days
+
+## Verification Passes
+
+### Pass 1: Coverage Verification
+
+Check that a generated skill exists for every technology referenced in the architecture document. Coverage gaps mean unverified assumptions about library capabilities.
+
+- **Covered**: Skill exists — APIs are known
+- **Missing**: Referenced but no skill — capabilities are assumed, not verified
+
+### Pass 2: Integration Verification
+
+For each integration claim in the architecture document, cross-reference the API surfaces of both libraries:
+
+- **Verified**: APIs demonstrably connect — matching types, documented bridge, or shared protocol
+- **Plausible**: Compatible types or protocols but no documented integration path
+- **Risky**: Type mismatch, protocol gap, or language boundary requiring a bridge
+- **Blocked**: Fundamental incompatibility — no feasible integration path
+
+Cross-reference protocol:
+1. Language boundary check (same language → direct calls; TypeScript↔Rust → needs FFI/IPC)
+2. Protocol compatibility (in-process, HTTP, WebSocket, shared filesystem)
+3. Type compatibility (does A export something B accepts?)
+4. Documentation cross-reference (does either library mention the other?)
+
+### Pass 3: Requirements Verification
+
+If a PRD/vision document is provided, verify the stack covers stated capability requirements:
+
+- **Fulfilled**: Stack capabilities demonstrably address the requirement
+- **Partially Fulfilled**: Some aspects covered, gaps remain
+- **Not Addressed**: No library in the stack covers this requirement
+
+## Iteration Loop
+
+The core value of architecture verification is the iteration loop:
+
+1. VS produces verdicts → user reads RISKY/BLOCKED items
+2. User swaps a library → generates new skill via CS/QS
+3. User re-runs VS → sees delta: "Previously RISKY, now VERIFIED"
+4. Repeat until FEASIBLE
+
+Each VS run should produce a diff from the previous run when a prior feasibility report exists. This makes the iteration cycle visible and measurable.
+
+## Evidence Citation Format
+
+All verdicts cite evidence from generated skills:
+
+```
+Library A exports: `function_name(params) → return_type` [from skill: skill-name]
+Library B accepts: `function_name(params)` [from skill: skill-name]
+Compatibility: {explanation}
+```
+
+## Lifecycle Position
+
+Architecture verification sits between individual skill generation and stack skill synthesis:
+
+```
+(CS|QS)×N → VS → RA → SS (compose) → TS → EX → Implementation → SS (code-mode)
+```
+
+VS and RA are pre-code workflows. SS compose-mode synthesizes the implementation playbook. After the codebase grows, SS code-mode (the standard stack-skill mode that analyzes manifests and source) captures actual usage patterns — completing the lifecycle.
+
+## Anti-Patterns
+
+- Treating VS verdicts as absolute — they are evidence-based assessments, not guarantees
+- Running VS without generating skills first — VS reads skills, it does not create them
+- Skipping the iteration loop — the first VS run often reveals gaps that require library swaps
+- Using VS output as a SKILL.md — VS produces a feasibility report, not a skill; use SS compose-mode for the stack skill
+
+## Related Fragments
+
+- [confidence-tiers.md](confidence-tiers.md) — T1/T2/T3 trust model for verdict evidence
+- [skill-lifecycle.md](skill-lifecycle.md) — end-to-end pipeline and workflow connections
+- [progressive-capability.md](progressive-capability.md) — tier philosophy for skill generation
+
+_Source: synthesized from verify-stack/workflow.md, refine-architecture/workflow.md, and create-stack-skill compose-mode-rules.md_

package/src/knowledge/ccc-bridge.md

@@ -0,0 +1,110 @@
+# CCC Bridge
+
+## Principle
+
+`ccc_bridge.*` references in workflow steps are **conceptual interfaces**, not callable functions. They describe a semantic code discovery operation to perform. Use the `ccc` MCP server tools (when available) or `ccc` CLI commands to execute these operations. See the TOOL/SUBPROCESS FALLBACK rule — if ccc is unavailable, the calling step falls back to direct ast-grep or source reading without ccc pre-discovery.
+
+## Rationale
+
+Without ccc pre-discovery, extraction steps scan all source files uniformly — processing them in directory order or entry-point-first order. On large codebases (500+ files), this means AST extraction in CLI streaming mode uses `head -N` cutoffs that may miss relevant exports in files that appear late in the scan. Integration detection in Stack Skill relies on grep-based co-import counting, which misses semantic relationships between libraries that don't appear in the same file.
+
+With ccc pre-discovery:
+- Extraction steps receive a relevance-ranked file queue — the most semantically important files are processed first, before any streaming cutoff
+- Integration detection gains semantic augmentation — pairs below the 2-file co-import threshold can be evaluated via natural language queries
+- Audit workflows can detect renamed/moved exports via semantic search before classifying them as deleted
+
+The key architectural constraint: ccc discovers, ast-grep verifies. Discovery method is orthogonal to confidence tier. This keeps the 4-tier confidence system (T1/T1-low/T2/T3) clean and avoids tier proliferation.
+
+## When ccc Is Used
+
+ccc is a **discovery layer only**. It answers "where should I look?" — it does not produce citations or structural claims. Every path or symbol returned by ccc_bridge must be verified by `ast_bridge` (T1) or source reading (T1-low) before it enters the extraction inventory. ccc results never appear in provenance citations.
+
+ccc is **required** at the Forge+ tier (it defines Forge+) and **optionally available** at the Deep tier as an enhancement (when `tools.ccc: true` in forge-tier.yaml).
+
+## Availability
+
+ccc_bridge operations are available when:
+- `tools.ccc: true` in forge-tier.yaml (verified by `ccc --help` + `ccc doctor` in setup-forge)
+- `ccc_index.status` is `"fresh"` or `"stale"` in forge-tier.yaml (an index exists for the project)
+
+When either condition is false, calling steps skip ccc discovery silently and proceed with direct ast-grep or source reading. This is standard Forge tier behavior — not a degradation.
+
+## Operations
+
+### `ccc_bridge.search(query, path?, top_k?)`
+
+**Resolves to:** `ccc search "{query}" --path {path} --top {top_k}` (CLI) or the `ccc` MCP search tool (preferred)
+
+Returns: list of `{file, score, snippet}` entries ranked by semantic relevance to the query. These are **candidates** for ast-grep extraction — not verified exports.
+
+**Usage context:** Called before ast-grep in Forge+ and Deep tier extraction steps to discover semantically relevant source regions. Results pre-rank the file extraction queue so ast-grep processes the most relevant files first.
+
+### `ccc_bridge.ensure_index(path)`
+
+**Resolves to:** Check `ccc_index.status` in forge-tier.yaml. If `"none"` or the indexed_path does not match, run `ccc init {path}` then `ccc index` and update forge-tier.yaml.
+
+**Usage context:** Called by setup-forge step-01b to ensure the project root is indexed. Called lazily by extraction steps when `ccc_index.status` is `"none"` but ccc is available.
+
+### `ccc_bridge.status()`
+
+**Resolves to:** Two-step verification:
+1. `ccc --help` — confirms binary exists (exit 0)
+2. `ccc doctor` — confirms daemon is running, extracts version string, validates embedding model
+
+**Usage context:** Called exclusively by setup-forge step-01 during tool detection. Downstream workflows read the result from forge-tier.yaml — they do not re-verify.
+
+## Confidence
+
+ccc discovery does not produce a confidence tier. The provenance chain is:
+
+1. ccc discovers candidate files (internal hint — not cited)
+2. ast-grep verifies exports in those files → **T1** citation `[AST:file:Lnn]`
+3. Or source reading verifies → **T1-low** citation `[SRC:file:Lnn]`
+
+The ccc search is invisible in the output artifact. A Forge+ skill's citations are indistinguishable from a Forge skill's citations — the difference is in extraction coverage, not citation format.
+
+## Indexing Lifecycle
+
+### When Indexing Happens
+
+1. **setup-forge step-01b:** Indexes the project root when setup-forge runs. This is the primary indexing point.
+2. **Workflow discovery steps:** If `ccc_index.status` is `"stale"` or `"none"`, discovery steps trigger a re-index and warn the user. They do not block.
+3. **ccc daemon:** Incremental indexing means re-indexing unchanged files is a near-no-op.
+
+### Freshness
+
+- Staleness threshold: 24 hours (configurable via `ccc_index.staleness_threshold_hours` in forge-tier.yaml)
+- A stale index still produces useful results — the workflow proceeds with the stale index and notes the staleness
+- setup-forge is the designated refresh authority
+
+### Relationship to QMD Registry
+
+ccc_index and qmd_collections are **orthogonal**:
+- `ccc_index` in forge-tier.yaml tracks the persistent source code index (one per project)
+- `qmd_collections[]` in forge-tier.yaml tracks per-skill workflow artifact collections
+- ccc indexes source code for semantic search; QMD indexes curated artifacts for temporal/knowledge search
+- The janitor role for QMD (setup-forge step-03) operates independently of ccc_index
+
+## Query Volume Bounds
+
+To prevent excessive daemon calls, workflow steps cap ccc queries:
+- **create-skill extraction:** max 2 queries per skill (discovery + optional scope refinement)
+- **analyze-source mapping:** max 1 query per qualifying unit
+- **create-stack-skill integration detection:** max 1 query per library pair
+- **audit-skill re-index:** max 1 query per export missing from its recorded location
+
+## Anti-Patterns
+
+- Using ccc_bridge results as citations without ast-grep verification — ccc output is never a provenance citation
+- Blocking a workflow because ccc is unavailable — ccc is always optional
+- Running ccc_bridge.ensure_index() without checking ccc_index.status first — unnecessary re-indexing
+- Passing ccc results directly to the extraction inventory — they are candidates, not extractions
+- Listing ccc as "unavailable" in reports for Quick/Forge tiers — ccc is a Forge+ capability, not something Quick/Forge tiers are missing
+
+## Related Fragments
+
+- [progressive-capability.md](progressive-capability.md) — Forge+ tier definition and positive framing
+- [confidence-tiers.md](confidence-tiers.md) — why ccc does not create a new confidence tier
+- [qmd-registry.md](qmd-registry.md) — the parallel but separate registry for QMD collections
+
+_Source: designed as part of the Forge+ tier integration for cocoindex-code semantic code search_

package/src/knowledge/confidence-tiers.md

@@ -22,11 +22,22 @@ With confidence tiers:
 
 | Tier | Label | Source | Extraction Method | Available At |
 | --- | --- | --- | --- | --- |
-| T1 | AST-verified | Source code | ast-grep structural parsing | Forge, Deep |
-| T1-low | Source-read | Source code | Pattern matching, file reading | Quick, Forge, Deep |
+| T1 | AST-verified | Source code | ast-grep structural parsing | Forge, Forge+, Deep |
+| T1-low | Source-read | Source code | Pattern matching, file reading | Quick, Forge, Forge+, Deep |
 | T2 | QMD-enriched | Knowledge base | QMD semantic search + synthesis | Deep |
 | T3 | External reference | Docs, URLs | External documentation lookup | All tiers |
 
+## T2 Sub-Types
+
+T2 enrichment content maps to temporal scopes that control where annotations surface:
+
+| Sub-type | Content | Surface Level |
+| --- | --- | --- |
+| T2-past | Closed issues, merged PRs, changelogs — historical context explaining why the API looks the way it does | `references/` (full temporal context) |
+| T2-future | Open PRs, deprecation warnings, RFCs — forward-looking context about upcoming changes | `SKILL.md` Section 4b (Migration & Deprecation Warnings) + `references/` |
+
+The T2-past/T2-future distinction is operationally significant: T2-future annotations trigger the presence of a Migration & Deprecation Warnings section in SKILL.md, while T2-past annotations live in progressive disclosure reference files only.
+
 ## Citation Formats
 
 Each tier has a defined citation format used consistently across all skill output:
@@ -131,7 +142,7 @@ Every generated skill includes a confidence distribution in `metadata.json`:
     "t2": 12,
     "t3": 3
   },
-  "extraction_tier": "deep"
+  "confidence_tier": "Deep"  // valid values: "Quick", "Forge", "Forge+", "Deep"
 }
 ```
 

package/src/knowledge/doc-fetcher.md

@@ -13,7 +13,7 @@ T3 external documentation fetching retrieves content from URLs specified in the
 All content obtained through doc fetching is classified as **external, untrusted** and subject to quarantine constraints:
 
 1. **Citation format** — every doc-fetched claim uses `[EXT:{url}]` citation format
-2. **Conflict resolution priority** — T3 has the lowest priority: `T1 > T2 > source reading > T3`
+2. **Conflict resolution priority** — T3 has the lowest priority: `T1 > T1-low > T2 > T3`
 3. **Source authority cap** — T3 content forces `source_authority: community` in metadata; it never qualifies as `official`
 4. **No structural claims** — T3 cannot assert verified signatures or line-level precision
 

package/src/knowledge/manual-section-integrity.md

@@ -106,12 +106,12 @@ Runs pending database migrations in sequence.
 | Severity | Condition | Resolution |
 | --- | --- | --- |
 | HIGH | Regenerated content overlaps \[MANUAL\] position | Present both versions, user chooses |
-| WARNING | Parent section deleted, \[MANUAL\] block orphaned | Flag orphaned block, user decides to keep or remove |
+| HIGH | Parent section deleted, \[MANUAL\] block orphaned | Flag orphaned block, user decides to keep or remove |
 | MEDIUM | \[MANUAL\] references a deleted export | Flag stale reference for user review |
 | LOW | New export generated adjacent to \[MANUAL\] block | Auto-resolve: place new content before the block |
 
 **Key Points:**
-- HIGH and WARNING conflicts always require user input — never auto-resolved
+- HIGH conflicts always require user input — never auto-resolved
 - MEDIUM conflicts are flagged but do not block the update
 - LOW conflicts are auto-resolved with a deterministic rule (new content before block)
 

package/src/knowledge/overview.md

@@ -6,7 +6,7 @@ Agent-level knowledge files capture cross-cutting principles and patterns that F
 
 ## Rationale
 
-The SKF module has 10 workflows containing 19 operational `data/` files embedded in step directories. These data files define schemas, templates, scoring formulas, and extraction rules tightly coupled to individual steps. But several principles — zero hallucination, confidence tiers, provenance — cut across multiple workflows and need a single authoritative source rather than fragmented repetition.
+The SKF module has 12 workflows containing numerous operational `data/` files embedded in step directories. These data files define schemas, templates, scoring formulas, and extraction rules tightly coupled to individual steps. But several principles — zero hallucination, confidence tiers, provenance — cut across multiple workflows and need a single authoritative source rather than fragmented repetition.
 
 Without a knowledge folder:
 - Cross-cutting principles get duplicated across workflow steps
@@ -22,20 +22,24 @@ With knowledge files:
 
 | File                                                       | Purpose                                                           | Key Workflows                      |
 |------------------------------------------------------------|-------------------------------------------------------------------|------------------------------------|
-| [zero-hallucination.md](zero-hallucination.md)             | Every claim traces to source; uncitable content excluded          | AN, BS, CS, QS, SS, US, AS, TS     |
-| [confidence-tiers.md](confidence-tiers.md)                 | T1/T1-low/T2/T3 trust model and citation formats                  | AN, BS, CS, QS, SS, US, AS, TS, EX |
-| [progressive-capability.md](progressive-capability.md)     | Quick/Forge/Deep tier philosophy and behavior adaptation          | All 10                             |
+| [zero-hallucination.md](zero-hallucination.md)             | Every claim traces to source; uncitable content excluded          | AN, BS, CS, QS, SS, US, AS, TS, RA |
+| [confidence-tiers.md](confidence-tiers.md)                 | T1/T1-low/T2/T3 trust model and citation formats                  | AN, BS, CS, QS, SS, US, AS, TS, EX, RA, VS |
+| [progressive-capability.md](progressive-capability.md)     | Quick/Forge/Forge+/Deep tier philosophy and behavior adaptation          | SF, AN, BS, CS, QS, SS, US, AS, TS, EX, VS, RA |
 | [agentskills-spec.md](agentskills-spec.md)                 | agentskills.io output format principles and compliance            | CS, QS, SS, US, TS, EX             |
-| [skill-lifecycle.md](skill-lifecycle.md)                   | End-to-end pipeline, artifact flow, workflow selection            | All 10                             |
+| [skill-lifecycle.md](skill-lifecycle.md)                   | End-to-end pipeline, artifact flow, workflow selection            | All 12                             |
 | [provenance-tracking.md](provenance-tracking.md)           | Provenance-map.json entries and file_entries, evidence reports, claim traceability | CS, QS, SS, US, AS, TS             |
 | [manual-section-integrity.md](manual-section-integrity.md) | \[MANUAL\] marker preservation and merge algorithm                | CS, US, AS, TS, EX                 |
 | [qmd-registry.md](qmd-registry.md)                         | Progressive QMD collection registry and collection gate principle | SF, BS, CS, US, AS                 |
+| [ccc-bridge.md](ccc-bridge.md)                             | ccc_bridge interface, indexing lifecycle, Forge+ discovery-before-extraction | SF, AN, CS, SS, US, AS             |
+| [architecture-verification.md](architecture-verification.md) | Pre-code verification pipeline, integration verdicts, iteration loop | VS, RA, SS                        |
+| [doc-fetcher.md](doc-fetcher.md)                           | T3 external documentation fetching, quarantine rules, tool-agnostic | CS, QS                             |
 | [split-body-strategy.md](split-body-strategy.md)           | Selective vs full split-body, detection pattern, agent accuracy   | CS, QS, US, TS, EX                |
+| [overview.md](overview.md)                                 | Knowledge map and JiT loading protocol (this file)               | All (entry point)                  |
 
 ## JiT Loading Protocol
 
 1. Ferris receives a task or workflow activation
-2. Consult `skf-knowledge-index.csv` to identify relevant knowledge fragments by tags or description
+2. Consult `skf-knowledge-index.csv` to identify relevant knowledge fragments by tags or description. The `tier` column classifies fragments as `core` (always relevant when the domain applies) or `extended` (load only when the specific scenario is active — e.g., `doc-fetcher.md` only when `doc_urls` are present in the brief)
 3. Load only the files needed for the current task — never bulk-load all knowledge
 4. Apply knowledge principles during workflow execution alongside step-specific `data/` files
 

package/src/knowledge/progressive-capability.md

@@ -2,7 +2,7 @@
 
 ## Principle
 
-Every capability tier — Quick, Forge, and Deep — produces legitimate, useful skills. Tiers describe what tools are available, not a quality hierarchy. A Quick skill is complete at its tier; a Deep skill adds depth, not correctness. Framing is always positive: describe what each tier enables, never what it lacks.
+Every capability tier — Quick, Forge, Forge+, and Deep — produces legitimate, useful skills. Tiers describe what tools are available, not a quality hierarchy. A Quick skill is complete at its tier; a Deep skill adds depth, not correctness. Framing is always positive: describe what each tier enables, never what it lacks.
 
 ## Rationale
 
@@ -24,6 +24,7 @@ With progressive capability:
 | --- | --- | --- | --- |
 | Quick | No tools required | Fast, template-driven, package-name resolution | Speed-first skill creation |
 | Forge | ast-grep available | AST-backed structural analysis, line-level citations | Precision-focused compilation |
+| Forge+ | ast-grep + ccc | Semantic discovery + AST verification, pre-ranked extraction | Intelligent precision compilation |
 | Deep | ast-grep + gh + qmd | AST + GitHub exploration + QMD synthesis, maximum provenance | Full intelligence pipeline |
 
 ## Pattern Examples
@@ -35,12 +36,13 @@ With progressive capability:
 **Implementation:** Each tool is verified by executing its version command — presence in PATH is insufficient. The tier is the highest level where all required tools pass verification:
 
 ```
-ast-grep --version  → required for Forge
+ast-grep --version  → required for Forge and above
+ccc --help + ccc doctor → required for Forge+
 gh --version        → required for Deep
 qmd status          → required for Deep
 ```
 
-If ast-grep passes but gh fails, the tier is Forge (not a "degraded Deep").
+If ast-grep passes but gh fails, the tier is Forge (not a "degraded Deep"). If ast-grep and ccc pass but gh and qmd fail, the tier is Forge+ (not a "degraded Deep").
 
 **Key Points:**
 - Tools must be functional, not just installed
@@ -59,6 +61,10 @@ Quick:  "Fast, template-driven skill creation — package-name resolution and
 Forge:  "AST-backed structural analysis — line-level citations with verified
          signatures. Precision-focused compilation."
 
+Forge+: "Semantic-guided precision compilation — cocoindex-code maps the codebase
+         semantically before AST extraction runs. Every skill begins with a ranked
+         discovery pass, then AST-backed verification."
+
 Deep:   "Full intelligence pipeline — AST verification plus GitHub exploration
          and QMD knowledge synthesis. Maximum provenance depth."
 ```
@@ -75,6 +81,7 @@ Deep:   "Full intelligence pipeline — AST verification plus GitHub exploration
 **Implementation:**
 - **Quick:** Reads source files, applies pattern matching for exports and signatures, produces T1-low citations. Uses `gh_bridge` for file structure when available as a convenience, not a requirement.
 - **Forge:** Uses `ast_bridge.scan_definitions()` for structural parsing, produces T1 citations with exact AST node types. Falls back to source reading for files ast-grep cannot parse.
+- **Forge+:** Identical extraction to Forge, plus ccc semantic pre-discovery narrows the file set before ast-grep runs. For large codebases, `ccc_bridge.search()` produces a ranked candidate list. ast-grep operates on that list rather than the full tree. All results remain T1 (AST-verified) — ccc is upstream, not in the extraction chain.
 - **Deep:** Identical extraction to Forge, plus QMD enrichment in a separate step. T2 annotations layer on top of the T1 base without replacing it.
 
 **Key Points:**
@@ -87,8 +94,10 @@ Deep:   "Full intelligence pipeline — AST verification plus GitHub exploration
 **Context:** The test-skill workflow adjusts scoring weights based on the forge tier.
 
 **Implementation:**
-- **Quick (Naive mode):** Export Coverage 45%, Signature Accuracy 25%, Type Coverage 20%, External Validation 10%. No coherence check — AST verification unavailable. When external validation tools (skill-check, tessl) are unavailable, their 10% is redistributed proportionally across the remaining categories.
-- **Forge (Contextual mode):** Export Coverage 40%, Signature Accuracy 25%, Type Coverage 15%, Coherence 20%. Full AST-backed verification.
+- **Forge/Deep (Naive mode — individual skill):** Coherence weight (18%) redistributed to remaining categories: Export Coverage 45%, Signature Accuracy 25%, Type Coverage 20%, External Validation 10%. All four active categories are scored with AST-backed data.
+- **Quick (any mode):** Signature Accuracy and Type Coverage are skipped (no AST available). Their weights redistribute proportionally to remaining active categories. For a Quick-tier individual skill (naive mode): after both adjustments (coherence removal + AST-dependent category removal), only Export Coverage and External Validation remain active — approximate redistributed weights: Export Coverage ~82%, External Validation ~18% (exact values depend on proportional redistribution; see scoring-rules.md for the calculation). When external validation tools (skill-check, tessl) are also unavailable, their weight is further redistributed, leaving Export Coverage as the sole scoring axis.
+- **Forge (Contextual mode):** Export Coverage 36%, Signature Accuracy 22%, Type Coverage 14%, Coherence 18%, External Validation 10%. Full AST-backed verification. When external validation tools are unavailable, their 10% is redistributed proportionally.
+- **Forge+ (Contextual mode):** Same weights as Forge. The improved extraction coverage (from ccc pre-ranking) may increase T1 count and reduce gaps, but the scoring weights themselves do not change.
 - **Deep (Contextual mode):** Same weights as Forge, plus cross-repo verification and QMD coherence checks feed into the coherence score.
 
 **Key Points:**
@@ -104,7 +113,7 @@ When a tool becomes unavailable mid-session (e.g., ast-grep uninstalled between
 3. New extractions use the current tier's capabilities
 4. The tier change is logged in the sidecar for audit trail
 
-When source is remote (GitHub URL) and tier is Forge or Deep:
+When source is remote (GitHub URL) and tier is Forge, Forge+, or Deep:
 1. AST extraction requires local files — ast-grep cannot operate on remote URLs
 2. The extraction step attempts an **ephemeral shallow clone** to a system temp path (if `git` is available)
 3. If the clone succeeds: AST extraction proceeds on the local clone, then the temp directory is cleaned up

package/src/knowledge/qmd-registry.md

@@ -48,6 +48,7 @@ qmd_collections:
 | --- | --- | --- | --- |
 | `extraction` | create-skill step-07 | Compiled SKILL.md, references, context-snippet — structured, confidence-rated exports | audit-skill (drift detection), update-skill (T2 enrichment) |
 | `brief` | brief-skill step-05 | skill-brief.yaml — intent, scope, target repository metadata | Portfolio-level search (cross-skill deduplication) |
+| `temporal` | create-skill step-03b | GitHub issues, PRs, releases, changelogs — historical and planned context at T2 confidence | step-04 enrichment (temporal annotations per exported function) |
 | `docs` | create-skill step-03c | Fetched external documentation — API references, guides, usage examples (T3 confidence) | step-04 enrichment (cross-reference doc context with source-extracted functions) |
 
 ### Lifecycle
@@ -55,11 +56,13 @@ qmd_collections:
 ```
 brief-skill writes brief → indexes {name}-brief → registers in forge-tier.yaml
     ↓
+create-skill fetches temporal context → indexes {name}-temporal → registers in forge-tier.yaml (Deep only)
+    ↓
 create-skill fetches docs → indexes {name}-docs → registers in forge-tier.yaml (Deep only)
     ↓
 create-skill compiles skill → indexes {name}-extraction → registers in forge-tier.yaml
     ↓
-audit-skill reads registry → queries {name}-extraction for temporal context
+audit-skill reads registry → queries {name}-extraction for drift baseline
 update-skill reads registry → queries {name}-extraction for T2 enrichment
     ↓
 setup-forge reads registry + QMD state → cleans orphans, removes stale entries
@@ -95,6 +98,20 @@ Human readability alone is not sufficient justification — the file is already
 
 **Rejection reason:** Decision artifact, not a compilation input. The analyze-source report tells users which skills to create, but create-stack-skill works from individual skill artifacts, not the analysis report. The only consumer would be a human reading the file — which they can do directly.
 
+## Relationship to CCC Index Registry
+
+The `ccc_index_registry` array in forge-tier.yaml is a **parallel but separate** registry from `qmd_collections`. They track different things:
+
+| Aspect | QMD Collections | CCC Index Registry |
+|--------|----------------|-------------------|
+| **What is indexed** | Curated workflow artifacts (SKILL.md, briefs, temporal data) | Source code (the actual codebase) |
+| **Index engine** | QMD (BM25 + optional vector search) | cocoindex-code (AST + vector embeddings) |
+| **Lifecycle** | Per-skill: created by create-skill, consumed by audit/update-skill | Per-project: created by setup-forge, verified by create-skill |
+| **Janitor** | setup-forge step-03 (orphan/stale QMD collection cleanup) | setup-forge step-03 section 5b (stale path cleanup) |
+| **Availability** | Deep tier only | Forge+ and Deep tiers |
+
+These registries are orthogonal — they never reference each other, and their janitor sections operate independently.
+
 ## Pattern Examples
 
 ### Example 1: Producer Registration (create-skill)

package/src/knowledge/skf-knowledge-index.csv

@@ -2,11 +2,13 @@ id,name,description,tags,tier,fragment_file
 overview,Knowledge Overview,"Entry point — knowledge map, JiT loading protocol, relationship to workflow data/ files","knowledge,navigation,jit-loading",core,knowledge/overview.md
 zero-hallucination,Zero Hallucination Principle,"Foundational principle — uncitable content is excluded not guessed, every claim traces to source","integrity,provenance,extraction",core,knowledge/zero-hallucination.md
 confidence-tiers,Confidence Tiers,"Trust model — T1/T1-low/T2/T3 labels, citation formats, tier interaction rules","confidence,citations,evidence,tiers",core,knowledge/confidence-tiers.md
-progressive-capability,Progressive Capability,"Quick/Forge/Deep philosophy — every tier is legitimate, positive framing, graceful degradation","tiers,quick,forge,deep,capability",core,knowledge/progressive-capability.md
+progressive-capability,Progressive Capability,"Quick/Forge/Forge+/Deep philosophy — every tier is legitimate, positive framing, graceful degradation","tiers,quick,forge,forge+,deep,capability",core,knowledge/progressive-capability.md
+ccc-bridge,CCC Bridge,"cocoindex-code semantic discovery — ccc_bridge interface, indexing lifecycle, Forge+ tier, discovery-before-extraction principle","ccc,cocoindex,semantic,discovery,forge+,bridge",core,knowledge/ccc-bridge.md
 agentskills-spec,agentskills.io Specification,"Format principles — frontmatter, progressive disclosure, directory structure, compliance rules, MCP tool naming, script quality, development methodology","agentskills,format,compliance,output,mcp,scripts,methodology",core,knowledge/agentskills-spec.md
 skill-lifecycle,Skill Lifecycle,"End-to-end pipeline — workflow connections, artifact flow, decision rules for workflow selection","lifecycle,pipeline,workflows,artifacts",core,knowledge/skill-lifecycle.md
 provenance-tracking,Provenance Tracking,"Provenance mechanism — provenance-map.json entries and file_entries, evidence reports, claim traceability","provenance,evidence,traceability,citations,file-entries",core,knowledge/provenance-tracking.md
 manual-section-integrity,Manual Section Integrity,"[MANUAL] preservation — marker format, merge algorithm, orphan detection","manual,preservation,merge,markers",core,knowledge/manual-section-integrity.md
 qmd-registry,QMD Collection Registry,"Progressive registry architecture — producer/consumer/janitor roles, collection gate principle, forge-tier.yaml registry schema","qmd,registry,collections,deep,indexing",core,knowledge/qmd-registry.md
 doc-fetcher,Doc Fetcher,"T3 external documentation — tool-agnostic URL fetching, quarantine rules, conflict resolution","doc-fetcher,t3,external,documentation,quarantine",extended,knowledge/doc-fetcher.md
+architecture-verification,Architecture Verification,"Pre-code verification pipeline — VS/RA/SS-compose lifecycle, integration verdicts, coverage analysis, iteration loop","architecture,verification,stack,feasibility,integration,vs,ra,ss,compose",core,knowledge/architecture-verification.md
 split-body-strategy,Split-Body Strategy,"Selective split guidance — detection pattern, recommended approach, impact on tessl scores and snippet anchors","split-body,selective-split,references,body-size",core,knowledge/split-body-strategy.md