bmad-module-skill-forge 0.6.0 → 0.7.0

package/docs/workflows.md

@@ -1,11 +1,11 @@
 ---
 title: Workflows
-description: All 10 SKF workflows with commands, steps, and connection diagram
+description: All 12 SKF workflows with commands, steps, and connection diagram
 ---
 
 # Workflows Reference
 
-SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.md), the AI agent that runs everything. Each workflow handles a specific part of the skill lifecycle — from analyzing source code to packaging for distribution. If any terms are unfamiliar, see the [Concepts](../concepts.md) page for plain-English definitions.
+SKF has 12 workflows. You trigger them by typing commands to [Ferris](../agents/), the AI agent that runs everything. Each workflow handles a specific part of the skill lifecycle — from analyzing source code to packaging for distribution. If any terms are unfamiliar, see the [Concepts](../concepts/) page for definitions.
 
 ---
 
@@ -19,7 +19,7 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** First time using SKF in a project. Run once per project.
 
-**Key Steps:** Detect tools → CCC index check (Forge+) → Determine tier → Write forge-tier.yaml → QMD hygiene (Deep)
+**Key Steps:** Detect tools + Determine tier → CCC index check (Forge+) → Write forge-tier.yaml → QMD + CCC registry hygiene (Deep/Forge+) → Status report
 
 **Agent:** Ferris (Architect mode)
 
@@ -33,7 +33,7 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** Before `Create Skill` when you want maximum control over what gets compiled.
 
-**Key Steps:** Gather intent → Analyze target → Define scope → Scripts/assets intent → Write skill-brief.yaml
+**Key Steps:** Gather intent → Analyze target → Define scope → Confirm brief → Write skill-brief.yaml
 
 **Agent:** Ferris (Architect mode)
 
@@ -47,7 +47,7 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** After Brief Skill, or with an existing skill-brief.yaml.
 
-**Key Steps:** Load brief → Ecosystem check → AST extract → Scripts/assets detect → QMD enrich → Compile → Validate → Generate
+**Key Steps:** Load brief → Ecosystem check → Extract (AST + scripts/assets) → QMD enrich (Deep) → Compile → Validate → Generate
 
 **Agent:** Ferris (Architect mode)
 
@@ -61,7 +61,7 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** After source code changes when an existing skill needs updating.
 
-**Key Steps:** Load existing → Detect changes (incl. scripts/assets) → Re-extract → Merge (preserve MANUAL) → Validate → Write
+**Key Steps:** Load existing → Detect changes (incl. scripts/assets) → Re-extract → Merge (preserve MANUAL) → Validate → Write → Report
 
 **Agent:** Ferris (Surgeon mode)
 
@@ -87,11 +87,13 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **Command:** `@Ferris SS`
 
-**Purpose:** Consolidated project stack skill with integration patterns.
+**Purpose:** Consolidated project stack skill with integration patterns. Supports two modes: **code-mode** (analyzes a codebase) and **compose-mode** (synthesizes from existing skills + architecture document, no codebase required).
 
-**When to Use:** When you want your agent to understand your entire project stack — not just individual libraries.
+**When to Use:** When you want your agent to understand your entire project stack — not just individual libraries. Use code-mode for existing projects; compose-mode activates automatically after the VS → RA verification path when skills exist but no codebase is present.
 
-**Key Steps:** Detect manifests → Rank dependencies → Scope confirmation → Parallel extract → Detect integrations → Compile stack → Generate references
+**Key Steps (code-mode):** Detect manifests → Rank dependencies → Scope confirmation → Parallel extract → Detect integrations → Compile stack → Generate references
+
+**Key Steps (compose-mode):** Load existing skills → Confirm scope → Detect integrations from architecture doc → Compile stack → Generate references
 
 **Agent:** Ferris (Architect mode)
 
@@ -105,7 +107,9 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** Brownfield onboarding of large repos or multi-service projects.
 
-**Key Steps:** Scan project → Identify units → Map exports → Detect integrations → Recommend → Generate briefs
+**Key Steps:** Init → Scan project → Identify units → Map exports & detect integrations → Recommend → Generate briefs
+
+**Note:** Supports resume — if the session is interrupted mid-analysis, re-run `@Ferris AN` and Ferris will resume from where it left off.
 
 **Agent:** Ferris (Architect mode)
 
@@ -119,7 +123,7 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** To check if a skill has fallen out of date with its source code.
 
-**Key Steps:** Load skill → Re-index source → Structural diff → Script/asset drift → Semantic diff (Deep) → Classify severity → Report
+**Key Steps:** Load skill → Re-index source → Structural diff (incl. script/asset drift) → Semantic diff (Deep) → Classify severity → Report
 
 **Agent:** Ferris (Audit mode)
 
@@ -133,23 +137,53 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 **When to Use:** After creating or updating a skill, before exporting.
 
-**Key Steps:** Load skill → Detect mode → Coverage check → Coherence check → Score → Gap report
+**Key Steps:** Load skill → Detect mode → Coverage check → Coherence check → External validation (skill-check, tessl) → Score → Gap report
+
+**Agent:** Ferris (Audit mode)
+
+---
+
+## Architecture Verification Workflows
+
+### Verify Stack (VS)
+
+**Command:** `@Ferris VS`
+
+**Purpose:** Pre-code stack feasibility verification. Cross-references generated skills against architecture and PRD documents with three passes: coverage, integration compatibility, and requirements.
+
+**When to Use:** After generating individual skills with CS/QS, before building a stack skill — to verify the tech stack can support the architecture.
+
+**Key Steps:** Load skills + docs → Coverage analysis → Integration verification → Requirements check → Synthesize verdict → Present report
 
 **Agent:** Ferris (Audit mode)
 
 ---
 
+### Refine Architecture (RA)
+
+**Command:** `@Ferris RA`
+
+**Purpose:** Evidence-backed architecture improvement. Takes the original architecture doc + generated skills + optional VS report, fills gaps, flags contradictions, and suggests improvements — all citing specific APIs.
+
+**When to Use:** After VS confirms feasibility, before running SS in compose-mode. Produces a refined architecture ready for stack skill composition.
+
+**Key Steps:** Load inputs → Gap analysis → Issue detection → Improvement detection → Compile refined doc → Present report
+
+**Agent:** Ferris (Architect mode)
+
+---
+
 ## Utility Workflows
 
 ### Export Skill (EX)
 
 **Command:** `@Ferris EX`
 
-**Purpose:** Package for distribution + platform-aware context injection into CLAUDE.md/AGENTS.md.
+**Purpose:** Validate package structure, generate context snippets, and inject managed sections into CLAUDE.md/AGENTS.md/.cursorrules.
 
-**When to Use:** When a skill is ready for distribution or CLAUDE.md integration.
+**When to Use:** When a skill is ready for CLAUDE.md/AGENTS.md integration. Also provides distribution instructions for `npx skills publish`.
 
-**Key Steps:** Load skill → Package → Generate snippet → Update CLAUDE.md → Token report → Summary
+**Key Steps:** Load skill → Validate package → Generate snippet → Update context file (CLAUDE.md/AGENTS.md/.cursorrules) → Token report → Summary
 
 **Agent:** Ferris (Delivery mode)
 
@@ -157,34 +191,48 @@ SKF has 10 workflows. You trigger them by typing commands to [Ferris](../agents.
 
 ## Workflow Connections
 
+**Standard path (code-mode):**
+
+```mermaid
+flowchart TD
+    SF[Setup Forge — one-time] --> AN[Analyze Source]
+    SF --> QS[Quick Skill]
+    SF --> SS_code[Stack Skill — code-mode]
+
+    AN --> BS[Brief Skill]
+    BS --> CS[Create Skill]
+    AN -->|direct| CS
+
+    CS --> TS[Test Skill — quality gate]
+    QS --> TS
+    SS_code --> TS
+
+    TS --> EX[Export Skill]
+    TS --> AS[Audit Skill]
+    AS --> US[Update Skill]
+    US --> TS
 ```
-                    setup-forge (one-time)
-                         │
-          ┌──────────────┼──────────────┐
-          │              │              │
-     analyze-source  quick-skill  create-stack-skill
-          │              │              │
-     brief-skill         │              │
-          │              │              │
-     create-skill        │              │
-          │              │              │
-          └──────┬───────┘──────────────┘
-                 │
-            test-skill (quality gate)
-                 │
-          ┌──────┼──────┐
-          │             │
-     export-skill  audit-skill
-                        │
-                   update-skill (loops back to test)
+
+**Pre-code verification path (compose-mode):**
+
+```mermaid
+flowchart TD
+    GEN["Create Skill | Quick Skill ×N<br/>(per library)"] --> VS[Verify Stack — feasibility report]
+    VS --> RA[Refine Architecture — refined doc]
+    RA --> SS_compose[Stack Skill — compose-mode]
+    SS_compose --> TS[Test Skill]
+    TS --> EX[Export Skill]
 ```
 
 ---
 
-## Build Priority
+## Workflow Categories
 
-| Phase | Workflows | Notes |
-|-------|-----------|-------|
-| 1a (Core Engine) | setup-forge, create-skill, test-skill, export-skill | Must build first |
-| 1b (Entry Points) | quick-skill, brief-skill, create-stack-skill | Complete v1.0 |
-| 2 (Lifecycle) | audit-skill, update-skill, analyze-source | Post-launch |
+| Category | Workflows | Description |
+|----------|-----------|-------------|
+| Core | SF, BS, CS, US | Setup, brief, create, and update skills |
+| Feature | QS, SS, AN | Quick skill, stack skill, and analyze source |
+| Quality | AS, TS | Audit skill completeness and test skill accuracy |
+| Architecture Verification | VS, RA | Pre-code architecture feasibility and refinement |
+| Utility | EX | Package and export for consumption |
+| In-Agent | WS, KI | WS: show lifecycle position, active briefs, and forge tier; KI: list knowledge fragments (both in-agent, no file-based workflow) |

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-module-skill-forge",
-  "version": "0.6.0",
+  "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",

package/src/agents/forger.agent.yaml

@@ -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

@@ -7,7 +7,8 @@ tools:
   gh_cli: ~
   qmd: ~
   ccc: ~
-  security_scan: ~
+  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 | Forge = + ast-grep | Forge+ = + ast-grep + ccc | Deep = + ast-grep + gh + QMD

package/src/forger/preferences.yaml

@@ -8,10 +8,8 @@ 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

@@ -19,7 +19,7 @@ The key architectural constraint: ccc discovers, ast-grep verifies. Discovery me
 
 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 available at **Forge+** and **Deep** tiers (when `tools.ccc: true` in forge-tier.yaml).
+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
 

package/src/knowledge/confidence-tiers.md

@@ -27,6 +27,17 @@ With confidence tiers:
 | 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"  // valid values: "quick", "forge", "forge+", "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,21 +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/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, CS, SS, AS, US, BS             |
+| [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

@@ -94,8 +94,9 @@ 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.
 

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

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

@@ -10,4 +10,5 @@ provenance-tracking,Provenance Tracking,"Provenance mechanism — provenance-map
 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