@drafthq/draft 3.3.1 → 3.5.0

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.3.1",
+      "version": "3.5.0",
       "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.3.1",
+  "version": "3.5.0",
   "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.3.1",
+  "version": "3.5.0",
   "skills": "./skills/",
   "agents": "./core/agents/",
   "author": {

package/core/shared/draft-context-loading.md

@@ -117,6 +117,15 @@ Apply relevance scoring when ALL of these conditions are true:
 
 Do NOT apply relevance scoring for commands that need full context (`/draft:init`, `/draft:deep-review`, `/draft:decompose`).
 
+### Retrieval Path Selection (okf vs monolith)
+
+Relevance scoring has two implementations; pick by output mode:
+
+- **okf mode** — if `draft/wiki/` exists, use **tree-search retrieval** (`core/shared/okf-retrieval.md`): navigate the OKF Concept Map by reasoning over each concept's routing `description`, descending only the matching subtrees. This is the vectorless, reasoning-based path (PageIndex-style) and supersedes the static section table below for okf bundles.
+- **monolith mode** — if `draft/wiki/` does not exist, use the static **Scoring Procedure** below against `.ai-context.md` sections.
+
+The minimum context floor (`META`, `INVARIANTS`, `TEST`, `FILES`) applies to both paths.
+
 ### Scoring Procedure
 
 1. **Extract key concepts** from the active task:

package/core/shared/okf-retrieval.md

@@ -0,0 +1,94 @@
+# OKF Tree-Search Retrieval
+
+Reasoning-based retrieval over the OKF knowledge bundle. When a project was emitted in `okf` mode (`draft/wiki/` exists), agents locate relevant context by **navigating the concept tree** — reading routing descriptions and descending only the matching subtrees — instead of loading sections by a static heuristic. No embeddings, no chunking, no similarity search: relevance is decided by reasoning over the tree, the same way a human expert scans a table of contents.
+
+Referenced by: `core/shared/draft-context-loading.md` (Relevance-Scored Context Loading). Applies to every command that loads focused project context (`/draft:implement`, `/draft:bughunt`, `/draft:review`, `/draft:debug`, `/draft:change`).
+
+> **Prior art.** This adapts the navigation model of [PageIndex](https://github.com/VectifyAI/PageIndex) (vectorless, reasoning-based RAG) to Draft's self-authored artifacts. Draft already builds the tree — the OKF bundle (`index.md` → section indexes → concept pages) is a table-of-contents whose `description` frontmatter is the per-node routing key. What this procedure adds is the **retrieval loop**: a reasoning descent over that tree. Draft does not need PageIndex's tree-*generation* engine (it authors the tree itself) and stays vectorless by design.
+
+## When this applies
+
+Apply tree-search retrieval when ALL of these hold:
+
+1. `draft/wiki/` exists (project emitted in `okf` mode) **and** `draft/wiki/index.md` carries a populated `<!-- CONCEPT-MAP:START -->…:END -->` block.
+2. A specific track or task is active (focused retrieval — broad tasks terminate at the Synopsis, see below).
+3. The command benefits from focused context (the relevance-scoring conditions in `draft-context-loading.md`).
+
+If `draft/wiki/` does **not** exist (monolith mode), skip this procedure entirely and use the static section-scoring table in `draft-context-loading.md`. The two are mutually exclusive: tree-search is the okf-mode retrieval path; section-scoring is the monolith path.
+
+## The retrieval loop
+
+The bundle is a tree: `.ai-context.md` (index root: Synopsis + Concept Map) → section indexes (`systems/`, `features/`, `reference/`, `entrypoints/`, `overview/`) → concept pages. Each node advertises a `description` routing key. Navigate it, do not flatten it.
+
+```
+1. Frame the query
+   Extract routing terms from the active task: domain nouns from spec.md
+   acceptance criteria, file paths / module names / tech terms from plan.md,
+   and the primary concern (data flow, API, security, perf, config, …).
+
+2. Enter at the root
+   Read draft/.ai-context.md. The Synopsis is the cheap broad-context path —
+   for a BROAD task (onboarding, architecture overview, "how does X work
+   end-to-end") it is sufficient: TERMINATE here, do not descend.
+   For a FOCUSED task, read the Concept Map (the root routing table).
+
+3. Select subtrees (reason, don't match strings)
+   For each Concept Map row, judge the `description` as a ROUTING DECISION:
+   "does opening this concept help THIS task?" Score each candidate:
+     - strong   — description names the task's responsibility or its own terms
+     - possible — adjacent/depends-on the task area
+     - skip     — unrelated
+   Descend `strong` first; hold `possible` as a frontier for step 5.
+
+4. Descend to leaves
+   For a selected section, open its index.md and repeat step 3 against the
+   section's concept rows (one routing description per concept). Open the
+   matching concept page(s). A concept page is a LEAF — its `x-grounded-paths`
+   are the exact source files the task should open; `Used by` / `x-callers`
+   give the next hop if the task spans callers.
+
+5. Expand only if under-covered
+   If the opened leaves do not cover the task's routing terms, expand the
+   highest-scored `possible` frontier node (step 3) and recurse. Otherwise stop.
+```
+
+## Routing decision criteria
+
+The `description` frontmatter is load-bearing — it is written as a routing decision, not a summary (`core/templates/okf/concept.md`). Judge each node by:
+
+| Signal | Descend when… |
+|--------|---------------|
+| Responsibility match | The description names the capability/module the task changes |
+| Term overlap | Task's domain nouns / file paths appear in the description or `x-grounded-paths` |
+| Caller/blast-radius reach | Task modifies a symbol whose `x-callers` / `Used by` point at this node |
+| Concern alignment | Task's primary concern (security, perf, data flow) is this node's stated focus |
+
+Reason about relevance — do not keyword-match. A concept whose description does not justify opening it for the task at hand is skipped even if a term coincidentally overlaps (similarity ≠ relevance).
+
+## Termination & budget
+
+- **Broad task** → terminate at the Synopsis (step 2). Do not open concept pages.
+- **Focused task** → terminate when opened leaves cover the task's routing terms, or when **≤ 5 concept pages** have been opened (default budget; raise only if the task explicitly spans many subsystems, e.g. a cross-cutting refactor).
+- **Depth** → the tree is shallow by construction (root → section → concept ≈ 2 hops). If a descent has not reached a leaf in 3 hops, stop and open the best leaf seen so far.
+- **No match** → if no Concept Map row scores above `skip`, fall back to the Synopsis plus `## INVARIANTS` / `## FILES` / `## TEST` floor from `draft-context-loading.md`.
+
+The minimum context floor from `draft-context-loading.md` (`META`, `INVARIANTS`, `TEST`, `FILES`) still applies and is always loaded regardless of the descent.
+
+## Output contract (traceability)
+
+Tree-search retrieval is explainable by construction — record the path taken, mirroring PageIndex's node-ID grounding:
+
+- **Opened concepts** — the leaf pages selected, each with the one-line reason it was opened.
+- **Grounded paths** — the union of `x-grounded-paths` across opened leaves: the precise source files the task will read or modify.
+- **Skipped frontier** — `possible` nodes held but not expanded (so a follow-up task can resume from them).
+
+Surface this trace when the command reports which context it loaded (e.g. `/draft:implement` plan preamble, `/draft:review` scope note). It replaces "loaded sections A, B, C" with "navigated to concepts X, Y because …".
+
+## Degradation
+
+| Scenario | Behavior |
+|----------|----------|
+| `draft/wiki/` missing | Skip; use monolith section-scoring in `draft-context-loading.md` |
+| Concept Map markers empty/absent | Fall back to reading `wiki/*/index.md` section tables directly; if those are missing, use the Synopsis + floor |
+| Routing descriptions thin/uninformative | Open the section `index.md` and skim concept titles; flag for `/draft:init refresh` to regenerate descriptions |
+| Task is broad | Terminate at Synopsis — descending is over-fetch (a Red Flag per `red-flags.md`) |

package/core/templates/okf/concept.md

@@ -52,3 +52,12 @@ so a focused task knows exactly which source files to open.
 ## See also
 
 - [Related concept](../systems/other.md)
+
+<!-- okf:concept-template v1
+A stub or redirect-only page (e.g. "see architecture.md", an unreplaced
+{PLACEHOLDER} token, or a body below the per-type minimum) FAILS
+okf-validate-quality.sh and therefore does NOT satisfy okf-coverage-check.sh —
+the bundle will not be promoted. Diagram types (Subsystem/Module/Feature/
+Entrypoint) require ≥1 valid Mermaid block and ≥2 x-grounded-paths.
+-->
+

package/integrations/agents/AGENTS.md

@@ -336,6 +336,16 @@ DRAFT_INIT_MODE="${DRAFT_INIT_MODE:-auto}"
 
 The tier-gated default rests on **maintainability/readability** (one navigable concept per file, cleaner PRs, a generated `architecture.md` preserved for linear onboarding) — not on the A/B benchmark, which was accuracy-parity (`docs/audit/okf-benchmark.md`). `monolith` is **retained, not retired**: it is the tier-1/2 default, the A/B baseline, and the fallback. If `DRAFT_INIT_MODE` is unset, do not commit to a mode until **Step 1.4.5** has computed the tier.
 
+**OKF Completeness Verification (blocking — tier 3+ `okf` mode).** Completeness is enforced by tooling, not honor system, so the wiki is generated completely for every module/sub-module/component on every run. Before promoting `draft.tmp/` → `draft/`, ALL must hold (see `references/okf-emitter.md` for the pipeline):
+
+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**.
+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.
+
 ### Route Explicit Modes Before Initialization
 
 If the user explicitly invoked a specialist mode, route directly:
@@ -3291,7 +3301,10 @@ esac
 Everything else in `draft init` (5-phase analysis, graph snapshot, `.state/`
 hashing, scope detection, atomic staging) is **reused unchanged**. This mode adds
 a decomposition + serialization stage. It introduces **no new LLM analysis
-engine** and exactly **one** new deterministic helper, `okf-validate.sh`.
+engine**; its deterministic helpers are `okf-plan-concepts.sh` (expected-concept
+set), `okf-validate.sh` (structure), `okf-validate-quality.sh` (per-type
+anti-stub), `okf-coverage-check.sh` (completeness), and `okf-validate-all.sh`
+(the single promotion gate that runs all three), plus `okf-render-views.sh`.
 
 ## Target layout
 
@@ -3384,25 +3397,64 @@ Derive concepts from the graph, not by hand:
 
 ```
 1. Survey        → existing draft init 5-phase + graph snapshot (graph-snapshot.sh)
-2. Plan          → derive the concept list (above) from graph clusters +
-                   entrypoints + features. Topo-sort by dependency so pages that
-                   others link to (overview, core subsystems) generate FIRST —
-                   forward cross-links resolve.
-3. Generate      → per concept, pull grounding from the graph and write the page:
+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.
+                     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.
+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>
                      x-grounded-paths  ← graph-impact.sh  --symbol <c>  (blast radius)
                      x-hotspot-score   ← hotspot-rank.sh
                      overview diagrams ← mermaid-from-graph.sh
                    Record each source path → page in .state/path-to-concept.json.
+                   Loop post-condition: every required concept_id has an output file.
+                   ⚠ Writing pages via shell heredoc without reading x-grounded-paths
+                   sources, or finishing while any required entry is unwritten, is a
+                   completeness failure — not a stylistic one.
 4. Render views  → ai-context.md (synopsis + Concept Map), architecture.md
-                   (concatenated view), wiki/log.md  (see M4).
-5. Validate      → okf-validate.sh draft/wiki \
-                     --path-index draft/.state/path-to-concept.json
-                   FAIL the build (do not atomic-rename) on any dangle, missing
-                   field, bad type, or path-index gap.
-6. Emit          → mv draft.tmp/ draft/ ; update .state/.
+                   (concatenated view + coverage banner), wiki/log.md  (see M4).
+5. Validate      → the promotion gate. Run all layers via the orchestrator:
+                     5a. okf-validate-all.sh draft.tmp/wiki \
+                           --repo . \
+                           --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).
+                   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 -->) —
+                   never hand-author it except deferral reasons in the manifest.
+6. Emit          → mv draft.tmp/ draft/  ONLY IF step 5 exit 0 ; update .state/.
+                   On failure keep draft.tmp/ and surface validation-report.json.
+```
+
+### Validation report schema (`.state/validation-report.json`)
+
+```json
+{ "valid": false, "bundle": "draft.tmp/wiki",
+  "layers": { "structure": "pass", "quality": "pass", "coverage": "fail" } }
 ```
 
+### Component manifest (optional — `--manifest FILE`)
+
+When the graph engine is unavailable (or a repo wants an authoritative list), pass
+a plain-text manifest: one component name per line, `#` comments and blanks ignored.
+Every listed component becomes a REQUIRED concept; `--allow-defer GLOB` still moves
+matches to deferred. Without a manifest the plan comes from the graph, and only if
+both are unavailable does it fall back to a heuristic top-level-dir scan (which it
+marks `degraded: true`).
+
 Page bodies are LLM-narrated for readability **but** the graph-derived
 frontmatter and the `Blast radius`/`Used by` sections are deterministic. To keep
 incremental carry-forward byte-identical (open decision 2), cache the narrated
@@ -3456,17 +3508,22 @@ section `index.md` tables are the injection slots for the routing tables.
 `draft init refresh` under `okf` mode:
 
 ```
-1. Diff hashes.json vs working tree     → changed source paths
-2. path-to-concept.json                 → affected concept pages
-3. Regenerate ONLY affected concepts; carry the rest verbatim (cached narration)
-4. Re-render ai-context.md / architecture.md / log.md (cheap; always regenerated)
-5. Re-validate: okf-validate.sh on the bundle + path-index (cross-links touching
-   changed concepts must still resolve)
-6. Append log.md; update hashes.json + path-to-concept.json
+1. Re-derive the plan: okf-plan-concepts.sh (modules added since last run become
+   REQUIRED — a new package can't slip through a refresh either)
+2. Diff hashes.json vs working tree     → changed source paths
+3. path-to-concept.json                 → affected concept pages
+4. Regenerate ONLY affected concepts; carry the rest verbatim (cached narration)
+5. Re-render ai-context.md / architecture.md / log.md (cheap; always regenerated)
+6. Re-validate (full gate): okf-validate-all.sh on the bundle with --plan and
+   --path-index. Refresh re-runs structure + quality + coverage — a changed
+   concept must still clear the quality bar, and a newly-required module must
+   still be present.
+7. Append log.md; update hashes.json + path-to-concept.json
 ```
 
 A 1-file change regenerates only the concept(s) that file grounds. Unchanged
-concepts are byte-identical across runs.
+concepts are byte-identical across runs. The full gate still runs, so refresh
+cannot promote a bundle that a newly-added module left incomplete.
 
 ## Backward compatibility (§9)
 
@@ -16274,6 +16331,15 @@ Apply relevance scoring when ALL of these conditions are true:
 
 Do NOT apply relevance scoring for commands that need full context (`draft init`, `draft deep-review`, `draft decompose`).
 
+### Retrieval Path Selection (okf vs monolith)
+
+Relevance scoring has two implementations; pick by output mode:
+
+- **okf mode** — if `draft/wiki/` exists, use **tree-search retrieval** (`core/shared/okf-retrieval.md`): navigate the OKF Concept Map by reasoning over each concept's routing `description`, descending only the matching subtrees. This is the vectorless, reasoning-based path (PageIndex-style) and supersedes the static section table below for okf bundles.
+- **monolith mode** — if `draft/wiki/` does not exist, use the static **Scoring Procedure** below against `.ai-context.md` sections.
+
+The minimum context floor (`META`, `INVARIANTS`, `TEST`, `FILES`) applies to both paths.
+
 ### Scoring Procedure
 
 1. **Extract key concepts** from the active task:
@@ -17647,6 +17713,109 @@ The engine indexes C/C++, Go, Python, TypeScript/JS, and more (tree-sitter, 159
 
 ---
 
+## core/shared/okf-retrieval.md
+
+<core-file path="core/shared/okf-retrieval.md">
+
+# OKF Tree-Search Retrieval
+
+Reasoning-based retrieval over the OKF knowledge bundle. When a project was emitted in `okf` mode (`draft/wiki/` exists), agents locate relevant context by **navigating the concept tree** — reading routing descriptions and descending only the matching subtrees — instead of loading sections by a static heuristic. No embeddings, no chunking, no similarity search: relevance is decided by reasoning over the tree, the same way a human expert scans a table of contents.
+
+Referenced by: `core/shared/draft-context-loading.md` (Relevance-Scored Context Loading). Applies to every command that loads focused project context (`draft implement`, `draft bughunt`, `draft review`, `draft debug`, `draft change`).
+
+> **Prior art.** This adapts the navigation model of [PageIndex](https://github.com/VectifyAI/PageIndex) (vectorless, reasoning-based RAG) to Draft's self-authored artifacts. Draft already builds the tree — the OKF bundle (`index.md` → section indexes → concept pages) is a table-of-contents whose `description` frontmatter is the per-node routing key. What this procedure adds is the **retrieval loop**: a reasoning descent over that tree. Draft does not need PageIndex's tree-*generation* engine (it authors the tree itself) and stays vectorless by design.
+
+## When this applies
+
+Apply tree-search retrieval when ALL of these hold:
+
+1. `draft/wiki/` exists (project emitted in `okf` mode) **and** `draft/wiki/index.md` carries a populated `<!-- CONCEPT-MAP:START -->…:END -->` block.
+2. A specific track or task is active (focused retrieval — broad tasks terminate at the Synopsis, see below).
+3. The command benefits from focused context (the relevance-scoring conditions in `draft-context-loading.md`).
+
+If `draft/wiki/` does **not** exist (monolith mode), skip this procedure entirely and use the static section-scoring table in `draft-context-loading.md`. The two are mutually exclusive: tree-search is the okf-mode retrieval path; section-scoring is the monolith path.
+
+## The retrieval loop
+
+The bundle is a tree: `.ai-context.md` (index root: Synopsis + Concept Map) → section indexes (`systems/`, `features/`, `reference/`, `entrypoints/`, `overview/`) → concept pages. Each node advertises a `description` routing key. Navigate it, do not flatten it.
+
+```
+1. Frame the query
+   Extract routing terms from the active task: domain nouns from spec.md
+   acceptance criteria, file paths / module names / tech terms from plan.md,
+   and the primary concern (data flow, API, security, perf, config, …).
+
+2. Enter at the root
+   Read draft/.ai-context.md. The Synopsis is the cheap broad-context path —
+   for a BROAD task (onboarding, architecture overview, "how does X work
+   end-to-end") it is sufficient: TERMINATE here, do not descend.
+   For a FOCUSED task, read the Concept Map (the root routing table).
+
+3. Select subtrees (reason, don't match strings)
+   For each Concept Map row, judge the `description` as a ROUTING DECISION:
+   "does opening this concept help THIS task?" Score each candidate:
+     - strong   — description names the task's responsibility or its own terms
+     - possible — adjacent/depends-on the task area
+     - skip     — unrelated
+   Descend `strong` first; hold `possible` as a frontier for step 5.
+
+4. Descend to leaves
+   For a selected section, open its index.md and repeat step 3 against the
+   section's concept rows (one routing description per concept). Open the
+   matching concept page(s). A concept page is a LEAF — its `x-grounded-paths`
+   are the exact source files the task should open; `Used by` / `x-callers`
+   give the next hop if the task spans callers.
+
+5. Expand only if under-covered
+   If the opened leaves do not cover the task's routing terms, expand the
+   highest-scored `possible` frontier node (step 3) and recurse. Otherwise stop.
+```
+
+## Routing decision criteria
+
+The `description` frontmatter is load-bearing — it is written as a routing decision, not a summary (`core/templates/okf/concept.md`). Judge each node by:
+
+| Signal | Descend when… |
+|--------|---------------|
+| Responsibility match | The description names the capability/module the task changes |
+| Term overlap | Task's domain nouns / file paths appear in the description or `x-grounded-paths` |
+| Caller/blast-radius reach | Task modifies a symbol whose `x-callers` / `Used by` point at this node |
+| Concern alignment | Task's primary concern (security, perf, data flow) is this node's stated focus |
+
+Reason about relevance — do not keyword-match. A concept whose description does not justify opening it for the task at hand is skipped even if a term coincidentally overlaps (similarity ≠ relevance).
+
+## Termination & budget
+
+- **Broad task** → terminate at the Synopsis (step 2). Do not open concept pages.
+- **Focused task** → terminate when opened leaves cover the task's routing terms, or when **≤ 5 concept pages** have been opened (default budget; raise only if the task explicitly spans many subsystems, e.g. a cross-cutting refactor).
+- **Depth** → the tree is shallow by construction (root → section → concept ≈ 2 hops). If a descent has not reached a leaf in 3 hops, stop and open the best leaf seen so far.
+- **No match** → if no Concept Map row scores above `skip`, fall back to the Synopsis plus `## INVARIANTS` / `## FILES` / `## TEST` floor from `draft-context-loading.md`.
+
+The minimum context floor from `draft-context-loading.md` (`META`, `INVARIANTS`, `TEST`, `FILES`) still applies and is always loaded regardless of the descent.
+
+## Output contract (traceability)
+
+Tree-search retrieval is explainable by construction — record the path taken, mirroring PageIndex's node-ID grounding:
+
+- **Opened concepts** — the leaf pages selected, each with the one-line reason it was opened.
+- **Grounded paths** — the union of `x-grounded-paths` across opened leaves: the precise source files the task will read or modify.
+- **Skipped frontier** — `possible` nodes held but not expanded (so a follow-up task can resume from them).
+
+Surface this trace when the command reports which context it loaded (e.g. `draft implement` plan preamble, `draft review` scope note). It replaces "loaded sections A, B, C" with "navigated to concepts X, Y because …".
+
+## Degradation
+
+| Scenario | Behavior |
+|----------|----------|
+| `draft/wiki/` missing | Skip; use monolith section-scoring in `draft-context-loading.md` |
+| Concept Map markers empty/absent | Fall back to reading `wiki/*/index.md` section tables directly; if those are missing, use the Synopsis + floor |
+| Routing descriptions thin/uninformative | Open the section `index.md` and skim concept titles; flag for `draft init refresh` to regenerate descriptions |
+| Task is broad | Terminate at Synopsis — descending is over-fetch (a Red Flag per `red-flags.md`) |
+
+</core-file>
+
+---
+
 ## core/shared/parallel-analysis.md
 
 <core-file path="core/shared/parallel-analysis.md">
@@ -22575,6 +22744,15 @@ so a focused task knows exactly which source files to open.
 
 - [Related concept](../systems/other.md)
 
+<!-- okf:concept-template v1
+A stub or redirect-only page (e.g. "see architecture.md", an unreplaced
+{PLACEHOLDER} token, or a body below the per-type minimum) FAILS
+okf-validate-quality.sh and therefore does NOT satisfy okf-coverage-check.sh —
+the bundle will not be promoted. Diagram types (Subsystem/Module/Feature/
+Entrypoint) require ≥1 valid Mermaid block and ≥2 x-grounded-paths.
+-->
+
+
 </core-file>
 
 ---