@drafthq/draft 3.5.0 → 3.5.2

package/.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "draft",
       "source": "./",
       "description": "Context-Driven Development: draft specs and plans before implementation. Structured workflows for features and fixes.",
-      "version": "3.5.0",
+      "version": "3.5.2",
       "author": {
         "name": "mayurpise"
       },

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "draft",
   "description": "Context-Driven Development: draft specs and plans before implementation. Structured workflows for features and fixes.",
-  "version": "3.5.0",
+  "version": "3.5.2",
   "author": {
     "name": "mayurpise"
   },

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "draft",
   "displayName": "Draft",
   "description": "Context-Driven Development: draft specs and plans before implementation. Structured workflows for features and fixes.",
-  "version": "3.5.0",
+  "version": "3.5.2",
   "skills": "./skills/",
   "agents": "./core/agents/",
   "author": {

package/core/templates/okf/ai-context-index.md

@@ -8,7 +8,7 @@ draft_init_mode: okf
 
 # {PROJECT_NAME} — AI Context Index
 
-> Index root for the OKF taxonomy bundle (`wiki/`). Read **Synopsis** for broad
+> Index root for the project wiki (`wiki/`). Read **Synopsis** for broad
 > tasks (they usually terminate here). For focused tasks, route through the
 > **Concept Map** to ≤N concept pages — each lists `x-grounded-paths`. This is
 > both the cheap broad-context path AND the progressive-disclosure entry point.

package/core/templates/okf/index.md

@@ -1,8 +1,8 @@
 ---
 type: Subsystem
-title: "{PROJECT_NAME} — Knowledge Bundle"
+title: "{PROJECT_NAME} — Wiki"
 description: >
-  Root index of the OKF taxonomy bundle. Start here, then route into
+  Root index of the project wiki. Start here, then route into
   overview/, systems/, features/, reference/, or entrypoints/ via the
   Concept Map. Open a concept only when its description matches the task.
 resource: .
@@ -12,10 +12,10 @@ okf_version: "0.1"
 okf_types_version: "0.1"
 ---
 
-# {PROJECT_NAME} — Knowledge Bundle
+# {PROJECT_NAME} — Wiki
 
-> OKF v0.1 bundle. One concept per file; cross-links form the graph. The
-> live call graph (`codebase-memory-mcp`) is the grounding source; this bundle
+> Project wiki. One concept per file; cross-links form the graph. The
+> live call graph (`codebase-memory-mcp`) is the grounding source; this wiki
 > is the navigable serialization. `../ai-context.md` is the consumption entry point.
 
 ## Sections

package/core/templates/okf/section-index.md

@@ -12,14 +12,14 @@ timestamp: "{ISO_TIMESTAMP}"
 
 # {SECTION_TITLE}
 
-> Section of the OKF bundle. Back to [bundle root](../index.md).
+> Section of the project wiki. Back to [wiki root](../index.md).
 
 ## Concepts
 
-<!-- One row per concept page in this section. `description` is the routing key
-     copied from each page's frontmatter. Regenerated on every init/refresh. -->
-
-| Concept | Type | Routing description |
-|---------|------|---------------------|
-| [{concept-a}]({concept-a}.md) | Module | {one-line routing desc} |
-| [{concept-b}]({concept-b}.md) | Feature | {one-line routing desc} |
+<!-- TOOL-OWNED: regenerated deterministically by okf-render-views.sh
+     (--section-indexes) from the concept pages in this directory. One row per
+     page; `description` is the routing key copied from each page's frontmatter.
+     Do not hand-edit between the markers — links here are guaranteed to resolve
+     because they are built only from files that actually exist. -->
+<!-- CONCEPT-MAP:START -->
+<!-- CONCEPT-MAP:END -->

package/integrations/agents/AGENTS.md

@@ -341,7 +341,7 @@ The tier-gated default rests on **maintainability/readability** (one navigable c
 1. `okf-plan-concepts.sh` ran and the expected/required/deferred counts were logged **before** any page was written (the concept boundary is a tool output, not an in-context guess).
 2. Every `required` entry in `concept-plan.json` has a non-stub page.
 3. `okf-validate-all.sh … --plan … --strict` exits 0 (structure + per-type quality + coverage all pass).
-4. `systems/coverage.md` was generated by tooling (verify the `<!-- okf:coverage-generated -->` marker) — no required package with `fan_in ≥ floor` is **MISSING**.
+4. `systems/coverage.md` was generated by tooling (verify the `<!-- okf:coverage-generated -->` marker) — **every** package/module the graph found is required by default (the fan-in floor only types Subsystem-vs-Module, it does not exempt), so none may be **MISSING**. Section `index.md` tables are regenerated by `okf-render-views.sh --section-indexes`, never hand-authored, so their links cannot dangle.
 5. On any failure: **do not** atomic-rename; surface `.state/validation-report.json`.
 
 > **Red flag:** writing concept pages without first running `okf-plan-concepts.sh`, or finishing generation while any `required` plan entry is unwritten, is a **completeness failure** — not a stylistic one.
@@ -3398,17 +3398,21 @@ Derive concepts from the graph, not by hand:
 ```
 1. Survey        → existing draft init 5-phase + graph snapshot (graph-snapshot.sh)
 2. Plan          → DETERMINISTIC. okf-plan-concepts.sh derives the expected-concept
-                   set from the graph (every package with fan_in ≥ floor → required
-                   Subsystem/Module; entrypoints → required; below-floor / allow-defer
-                   → deferred with a reason) and writes draft.tmp/.state/concept-plan.json.
+                   set from the graph. EVERY package the graph knows about is
+                   required (fan_in ≥ floor → Subsystem; below floor → Module — the
+                   floor only types/orders, it never exempts); entrypoints → required;
+                   only --allow-defer matches are deferred (with a reason). Writes
+                   draft.tmp/.state/concept-plan.json.
                      okf-plan-concepts.sh --repo . [--scope PATH] \
                        [--manifest FILE] [--min-fan-in 2] [--allow-defer GLOB]... \
                        --out draft.tmp/.state/concept-plan.json
                    This replaces the old in-context concept enumeration — the boundary
                    of the work is now a tool output, not an LLM judgment, so modules
-                   cannot be silently dropped. LOG the counts (expected/required/
-                   deferred) BEFORE writing any page. `generated_order` is topo-ish
-                   (required + high-fan-in first) so forward cross-links resolve.
+                   and sub-modules cannot be silently dropped. (Legacy fan-in
+                   exemption is opt-in via --defer-below-floor.) LOG the counts
+                   (expected/required/deferred) BEFORE writing any page.
+                   `generated_order` is topo-ish (required + high-fan-in first) so
+                   forward cross-links resolve.
 3. Generate      → iterate concept-plan.generated_order; write ONE page per REQUIRED
                    entry, grounding each from the graph:
                      x-callers        ← graph-callers.sh --symbol <c>
@@ -3428,9 +3432,11 @@ Derive concepts from the graph, not by hand:
                            --plan draft.tmp/.state/concept-plan.json \
                            --path-index draft.tmp/.state/path-to-concept.json \
                            --strict --report draft.tmp/.state/validation-report.json
-                   It runs, in order: okf-validate.sh (structure + reverse index),
-                   okf-validate-quality.sh (per-type anti-stub / depth / mermaid lint),
-                   okf-coverage-check.sh (every required plan entry → real page).
+                   It runs, in order: okf-validate.sh (structure + reverse index +
+                   empty/untyped-page + leftover-template-token + dangling-link checks),
+                   okf-validate-quality.sh (per-type anti-stub / depth / per-section
+                   content / mermaid lint), okf-coverage-check.sh (every required plan
+                   entry → real page).
                    ANY layer failing ⇒ exit non-zero ⇒ DO NOT atomic-rename.
                    coverage.md (systems/coverage.md) is regenerated by the coverage
                    layer; it is tool-owned (marker <!-- okf:coverage-generated -->) —
@@ -3469,6 +3475,7 @@ regenerated on every init/refresh so they never drift from the bundle:
 ```bash
 okf-render-views.sh draft/wiki \
   --arch-out draft/architecture.md \
+  --section-indexes \
   --concept-map-into draft/wiki/index.md \
   --concept-map-into draft/.ai-context.md \
   --web draft/wiki/web/index.html
@@ -3476,6 +3483,11 @@ okf-render-views.sh draft/wiki \
 
 - `--arch-out` renders the linear `architecture.md` (banner + TOC + every concept
   page in canonical section order, frontmatter stripped, Mermaid preserved).
+- `--section-indexes` rebuilds each `<section>/index.md` concept table (between its
+  `CONCEPT-MAP` markers) from the pages that actually exist in that directory. This
+  is mandatory: section indexes are NOT hand-authored — building them from real
+  files is what makes their links impossible to dangle. Never write a section
+  index "Concepts" table by hand.
 - `--concept-map-into` rebuilds the routing table between the
   `<!-- CONCEPT-MAP:START -->` / `:END` markers from each concept's `title` +
   `type` + `description` (section `index.md` pages excluded).
@@ -22642,9 +22654,9 @@ List down alerting thresholds on those metrics:
 
 ---
 type: Subsystem
-title: "{PROJECT_NAME} — Knowledge Bundle"
+title: "{PROJECT_NAME} — Wiki"
 description: >
-  Root index of the OKF taxonomy bundle. Start here, then route into
+  Root index of the project wiki. Start here, then route into
   overview/, systems/, features/, reference/, or entrypoints/ via the
   Concept Map. Open a concept only when its description matches the task.
 resource: .
@@ -22654,10 +22666,10 @@ okf_version: "0.1"
 okf_types_version: "0.1"
 ---
 
-# {PROJECT_NAME} — Knowledge Bundle
+# {PROJECT_NAME} — Wiki
 
-> OKF v0.1 bundle. One concept per file; cross-links form the graph. The
-> live call graph (`codebase-memory-mcp`) is the grounding source; this bundle
+> Project wiki. One concept per file; cross-links form the graph. The
+> live call graph (`codebase-memory-mcp`) is the grounding source; this wiki
 > is the navigable serialization. `../ai-context.md` is the consumption entry point.
 
 ## Sections
@@ -22775,17 +22787,17 @@ timestamp: "{ISO_TIMESTAMP}"
 
 # {SECTION_TITLE}
 
-> Section of the OKF bundle. Back to [bundle root](../index.md).
+> Section of the project wiki. Back to [wiki root](../index.md).
 
 ## Concepts
 
-<!-- One row per concept page in this section. `description` is the routing key
-     copied from each page's frontmatter. Regenerated on every init/refresh. -->
-
-| Concept | Type | Routing description |
-|---------|------|---------------------|
-| [{concept-a}]({concept-a}.md) | Module | {one-line routing desc} |
-| [{concept-b}]({concept-b}.md) | Feature | {one-line routing desc} |
+<!-- TOOL-OWNED: regenerated deterministically by okf-render-views.sh
+     (--section-indexes) from the concept pages in this directory. One row per
+     page; `description` is the routing key copied from each page's frontmatter.
+     Do not hand-edit between the markers — links here are guaranteed to resolve
+     because they are built only from files that actually exist. -->
+<!-- CONCEPT-MAP:START -->
+<!-- CONCEPT-MAP:END -->
 
 </core-file>
 
@@ -22805,7 +22817,7 @@ draft_init_mode: okf
 
 # {PROJECT_NAME} — AI Context Index
 
-> Index root for the OKF taxonomy bundle (`wiki/`). Read **Synopsis** for broad
+> Index root for the project wiki (`wiki/`). Read **Synopsis** for broad
 > tasks (they usually terminate here). For focused tasks, route through the
 > **Concept Map** to ≤N concept pages — each lists `x-grounded-paths`. This is
 > both the cheap broad-context path AND the progressive-disclosure entry point.

package/integrations/copilot/.github/copilot-instructions.md

@@ -341,7 +341,7 @@ The tier-gated default rests on **maintainability/readability** (one navigable c
 1. `okf-plan-concepts.sh` ran and the expected/required/deferred counts were logged **before** any page was written (the concept boundary is a tool output, not an in-context guess).
 2. Every `required` entry in `concept-plan.json` has a non-stub page.
 3. `okf-validate-all.sh … --plan … --strict` exits 0 (structure + per-type quality + coverage all pass).
-4. `systems/coverage.md` was generated by tooling (verify the `<!-- okf:coverage-generated -->` marker) — no required package with `fan_in ≥ floor` is **MISSING**.
+4. `systems/coverage.md` was generated by tooling (verify the `<!-- okf:coverage-generated -->` marker) — **every** package/module the graph found is required by default (the fan-in floor only types Subsystem-vs-Module, it does not exempt), so none may be **MISSING**. Section `index.md` tables are regenerated by `okf-render-views.sh --section-indexes`, never hand-authored, so their links cannot dangle.
 5. On any failure: **do not** atomic-rename; surface `.state/validation-report.json`.
 
 > **Red flag:** writing concept pages without first running `okf-plan-concepts.sh`, or finishing generation while any `required` plan entry is unwritten, is a **completeness failure** — not a stylistic one.
@@ -3398,17 +3398,21 @@ Derive concepts from the graph, not by hand:
 ```
 1. Survey        → existing draft init 5-phase + graph snapshot (graph-snapshot.sh)
 2. Plan          → DETERMINISTIC. okf-plan-concepts.sh derives the expected-concept
-                   set from the graph (every package with fan_in ≥ floor → required
-                   Subsystem/Module; entrypoints → required; below-floor / allow-defer
-                   → deferred with a reason) and writes draft.tmp/.state/concept-plan.json.
+                   set from the graph. EVERY package the graph knows about is
+                   required (fan_in ≥ floor → Subsystem; below floor → Module — the
+                   floor only types/orders, it never exempts); entrypoints → required;
+                   only --allow-defer matches are deferred (with a reason). Writes
+                   draft.tmp/.state/concept-plan.json.
                      okf-plan-concepts.sh --repo . [--scope PATH] \
                        [--manifest FILE] [--min-fan-in 2] [--allow-defer GLOB]... \
                        --out draft.tmp/.state/concept-plan.json
                    This replaces the old in-context concept enumeration — the boundary
                    of the work is now a tool output, not an LLM judgment, so modules
-                   cannot be silently dropped. LOG the counts (expected/required/
-                   deferred) BEFORE writing any page. `generated_order` is topo-ish
-                   (required + high-fan-in first) so forward cross-links resolve.
+                   and sub-modules cannot be silently dropped. (Legacy fan-in
+                   exemption is opt-in via --defer-below-floor.) LOG the counts
+                   (expected/required/deferred) BEFORE writing any page.
+                   `generated_order` is topo-ish (required + high-fan-in first) so
+                   forward cross-links resolve.
 3. Generate      → iterate concept-plan.generated_order; write ONE page per REQUIRED
                    entry, grounding each from the graph:
                      x-callers        ← graph-callers.sh --symbol <c>
@@ -3428,9 +3432,11 @@ Derive concepts from the graph, not by hand:
                            --plan draft.tmp/.state/concept-plan.json \
                            --path-index draft.tmp/.state/path-to-concept.json \
                            --strict --report draft.tmp/.state/validation-report.json
-                   It runs, in order: okf-validate.sh (structure + reverse index),
-                   okf-validate-quality.sh (per-type anti-stub / depth / mermaid lint),
-                   okf-coverage-check.sh (every required plan entry → real page).
+                   It runs, in order: okf-validate.sh (structure + reverse index +
+                   empty/untyped-page + leftover-template-token + dangling-link checks),
+                   okf-validate-quality.sh (per-type anti-stub / depth / per-section
+                   content / mermaid lint), okf-coverage-check.sh (every required plan
+                   entry → real page).
                    ANY layer failing ⇒ exit non-zero ⇒ DO NOT atomic-rename.
                    coverage.md (systems/coverage.md) is regenerated by the coverage
                    layer; it is tool-owned (marker <!-- okf:coverage-generated -->) —
@@ -3469,6 +3475,7 @@ regenerated on every init/refresh so they never drift from the bundle:
 ```bash
 okf-render-views.sh draft/wiki \
   --arch-out draft/architecture.md \
+  --section-indexes \
   --concept-map-into draft/wiki/index.md \
   --concept-map-into draft/.ai-context.md \
   --web draft/wiki/web/index.html
@@ -3476,6 +3483,11 @@ okf-render-views.sh draft/wiki \
 
 - `--arch-out` renders the linear `architecture.md` (banner + TOC + every concept
   page in canonical section order, frontmatter stripped, Mermaid preserved).
+- `--section-indexes` rebuilds each `<section>/index.md` concept table (between its
+  `CONCEPT-MAP` markers) from the pages that actually exist in that directory. This
+  is mandatory: section indexes are NOT hand-authored — building them from real
+  files is what makes their links impossible to dangle. Never write a section
+  index "Concepts" table by hand.
 - `--concept-map-into` rebuilds the routing table between the
   `<!-- CONCEPT-MAP:START -->` / `:END` markers from each concept's `title` +
   `type` + `description` (section `index.md` pages excluded).
@@ -22642,9 +22654,9 @@ List down alerting thresholds on those metrics:
 
 ---
 type: Subsystem
-title: "{PROJECT_NAME} — Knowledge Bundle"
+title: "{PROJECT_NAME} — Wiki"
 description: >
-  Root index of the OKF taxonomy bundle. Start here, then route into
+  Root index of the project wiki. Start here, then route into
   overview/, systems/, features/, reference/, or entrypoints/ via the
   Concept Map. Open a concept only when its description matches the task.
 resource: .
@@ -22654,10 +22666,10 @@ okf_version: "0.1"
 okf_types_version: "0.1"
 ---
 
-# {PROJECT_NAME} — Knowledge Bundle
+# {PROJECT_NAME} — Wiki
 
-> OKF v0.1 bundle. One concept per file; cross-links form the graph. The
-> live call graph (`codebase-memory-mcp`) is the grounding source; this bundle
+> Project wiki. One concept per file; cross-links form the graph. The
+> live call graph (`codebase-memory-mcp`) is the grounding source; this wiki
 > is the navigable serialization. `../ai-context.md` is the consumption entry point.
 
 ## Sections
@@ -22775,17 +22787,17 @@ timestamp: "{ISO_TIMESTAMP}"
 
 # {SECTION_TITLE}
 
-> Section of the OKF bundle. Back to [bundle root](../index.md).
+> Section of the project wiki. Back to [wiki root](../index.md).
 
 ## Concepts
 
-<!-- One row per concept page in this section. `description` is the routing key
-     copied from each page's frontmatter. Regenerated on every init/refresh. -->
-
-| Concept | Type | Routing description |
-|---------|------|---------------------|
-| [{concept-a}]({concept-a}.md) | Module | {one-line routing desc} |
-| [{concept-b}]({concept-b}.md) | Feature | {one-line routing desc} |
+<!-- TOOL-OWNED: regenerated deterministically by okf-render-views.sh
+     (--section-indexes) from the concept pages in this directory. One row per
+     page; `description` is the routing key copied from each page's frontmatter.
+     Do not hand-edit between the markers — links here are guaranteed to resolve
+     because they are built only from files that actually exist. -->
+<!-- CONCEPT-MAP:START -->
+<!-- CONCEPT-MAP:END -->
 
 </core-file>
 
@@ -22805,7 +22817,7 @@ draft_init_mode: okf
 
 # {PROJECT_NAME} — AI Context Index
 
-> Index root for the OKF taxonomy bundle (`wiki/`). Read **Synopsis** for broad
+> Index root for the project wiki (`wiki/`). Read **Synopsis** for broad
 > tasks (they usually terminate here). For focused tasks, route through the
 > **Concept Map** to ≤N concept pages — each lists `x-grounded-paths`. This is
 > both the cheap broad-context path AND the progressive-disclosure entry point.

package/integrations/copilot/.github/copilot-instructions.md.7iDz8X

@@ -0,0 +1,91 @@
+# Draft - Context-Driven Development
+
+You are operating with the Draft methodology for Context-Driven Development.
+
+**Measure twice, code once.**
+
+## Core Workflow
+
+**Context -> Spec & Plan -> Implement**
+
+Every feature follows this lifecycle:
+1. **Setup** - Initialize project context (once per project)
+2. **New Track** - Create specification and plan
+3. **Implement** - Execute tasks with TDD workflow
+4. **Verify** - Confirm acceptance criteria met
+
+## Project Context Files
+
+When `draft/` exists in the project, always consider:
+- `draft/.ai-context.md` - Source of truth for AI agents (dense codebase understanding)
+- `draft/architecture.md` - Human-readable engineering guide (derived from .ai-context.md)
+- `draft/product.md` - Product vision and goals
+- `draft/tech-stack.md` - Technical constraints
+- `draft/workflow.md` - TDD and commit preferences
+- `draft/tracks.md` - Active work items
+
+## Available Commands
+
+| Command | Purpose |
+|---------|---------|
+| `draft` | Show overview and available commands |
+| `draft init` | Initialize project (run once) |
+| `draft index [--init-missing]` | Aggregate monorepo service contexts |
+| `draft new-track <description>` | Create feature/bug track |
+| `draft decompose` | Module decomposition with dependency mapping |
+| `draft implement` | Execute tasks from plan |
+| `draft coverage` | Code coverage report (target 95%+) |
+| `draft bughunt [--track <id>]` | Systematic bug discovery |
+| `draft review [--track <id>]` | Three-stage code review |
+| `draft deep-review [module]` | Exhaustive production-grade module audit |
+| `draft learn [promote\|migrate]` | Discover coding patterns, update guardrails |
+| `draft adr [title]` | Architecture Decision Records |
+| `draft status` | Show progress overview |
+| `draft revert` | Git-aware rollback |
+| `draft change <description>` | Handle mid-track requirement changes |
+| `draft jira-preview [track-id]` | Generate jira-export.md for review |
+| `draft jira-create [track-id]` | Create Jira issues from export via MCP |
+
+## Intent Mapping
+
+Recognize these natural language patterns:
+
+| User Says | Action |
+|-----------|--------|
+| "set up the project" | Run init |
+| "index services", "aggregate context" | Run index |
+| "new feature", "add X" | Create new track |
+| "break into modules", "decompose" | Run decompose |
+| "start implementing" | Execute implement |
+| "check coverage", "test coverage" | Run coverage |
+| "hunt bugs", "find bugs" | Run bug hunt |
+| "review code", "review track", "check quality" | Run review |
+| "deep review", "production audit", "module audit" | Run deep-review |
+| "learn patterns", "update guardrails", "discover conventions" | Run learn |
+| "what's the status" | Show status |
+| "undo", "revert" | Run revert |
+| "requirements changed", "scope changed", "update the spec" | Run change |
+| "preview jira", "export to jira" | Run jira-preview |
+| "create jira", "push to jira" | Run jira-create |
+| "document decision", "create ADR" | Create architecture decision record |
+| "help", "what commands" | Show draft overview |
+| "the plan" | Read active track's plan.md |
+| "the spec" | Read active track's spec.md |
+
+## Tracks
+
+A **track** is a high-level unit of work (feature, bug fix, refactor). Each track contains:
+- `spec.md` - Requirements and acceptance criteria
+- `plan.md` - Phased task breakdown
+- `metadata.json` - Status and timestamps
+
+Located at: `draft/tracks/<track-id>/`
+
+## Status Markers
+
+Recognize and use these throughout plan.md:
+- `[ ]` - Pending
+- `[~]` - In Progress
+- `[x]` - Completed
+- `[!]` - Blocked
+

package/integrations/copilot/.github/copilot-instructions.md.DoBdtd

@@ -0,0 +1,91 @@
+# Draft - Context-Driven Development
+
+You are operating with the Draft methodology for Context-Driven Development.
+
+**Measure twice, code once.**
+
+## Core Workflow
+
+**Context -> Spec & Plan -> Implement**
+
+Every feature follows this lifecycle:
+1. **Setup** - Initialize project context (once per project)
+2. **New Track** - Create specification and plan
+3. **Implement** - Execute tasks with TDD workflow
+4. **Verify** - Confirm acceptance criteria met
+
+## Project Context Files
+
+When `draft/` exists in the project, always consider:
+- `draft/.ai-context.md` - Source of truth for AI agents (dense codebase understanding)
+- `draft/architecture.md` - Human-readable engineering guide (derived from .ai-context.md)
+- `draft/product.md` - Product vision and goals
+- `draft/tech-stack.md` - Technical constraints
+- `draft/workflow.md` - TDD and commit preferences
+- `draft/tracks.md` - Active work items
+
+## Available Commands
+
+| Command | Purpose |
+|---------|---------|
+| `draft` | Show overview and available commands |
+| `draft init` | Initialize project (run once) |
+| `draft index [--init-missing]` | Aggregate monorepo service contexts |
+| `draft new-track <description>` | Create feature/bug track |
+| `draft decompose` | Module decomposition with dependency mapping |
+| `draft implement` | Execute tasks from plan |
+| `draft coverage` | Code coverage report (target 95%+) |
+| `draft bughunt [--track <id>]` | Systematic bug discovery |
+| `draft review [--track <id>]` | Three-stage code review |
+| `draft deep-review [module]` | Exhaustive production-grade module audit |
+| `draft learn [promote\|migrate]` | Discover coding patterns, update guardrails |
+| `draft adr [title]` | Architecture Decision Records |
+| `draft status` | Show progress overview |
+| `draft revert` | Git-aware rollback |
+| `draft change <description>` | Handle mid-track requirement changes |
+| `draft jira-preview [track-id]` | Generate jira-export.md for review |
+| `draft jira-create [track-id]` | Create Jira issues from export via MCP |
+
+## Intent Mapping
+
+Recognize these natural language patterns:
+
+| User Says | Action |
+|-----------|--------|
+| "set up the project" | Run init |
+| "index services", "aggregate context" | Run index |
+| "new feature", "add X" | Create new track |
+| "break into modules", "decompose" | Run decompose |
+| "start implementing" | Execute implement |
+| "check coverage", "test coverage" | Run coverage |
+| "hunt bugs", "find bugs" | Run bug hunt |
+| "review code", "review track", "check quality" | Run review |
+| "deep review", "production audit", "module audit" | Run deep-review |
+| "learn patterns", "update guardrails", "discover conventions" | Run learn |
+| "what's the status" | Show status |
+| "undo", "revert" | Run revert |
+| "requirements changed", "scope changed", "update the spec" | Run change |
+| "preview jira", "export to jira" | Run jira-preview |
+| "create jira", "push to jira" | Run jira-create |
+| "document decision", "create ADR" | Create architecture decision record |
+| "help", "what commands" | Show draft overview |
+| "the plan" | Read active track's plan.md |
+| "the spec" | Read active track's spec.md |
+
+## Tracks
+
+A **track** is a high-level unit of work (feature, bug fix, refactor). Each track contains:
+- `spec.md` - Requirements and acceptance criteria
+- `plan.md` - Phased task breakdown
+- `metadata.json` - Status and timestamps
+
+Located at: `draft/tracks/<track-id>/`
+
+## Status Markers
+
+Recognize and use these throughout plan.md:
+- `[ ]` - Pending
+- `[~]` - In Progress
+- `[x]` - Completed
+- `[!]` - Blocked
+