@c4a/context-cli 0.6.0-beta.8 → 0.6.1-beta.2

package/providers/context/resources/manuals/reference/template-variables.md

@@ -0,0 +1,247 @@
+---
+id: context.sdk.template-variables
+kind: procedure
+mediaType: text/markdown
+---
+
+# Template Variables
+
+Context package templates are rendered with Handlebars during `context build`.
+
+This reference covers the template variables available to files under
+`src/package-templates/**`. Templates can render values, loop over arrays,
+branch with conditionals, and use template-only comments. They cannot run
+JavaScript.
+
+## Syntax
+
+### Value
+
+```md
+Package: {{packageName}}
+Approved pages: {{knowledgeCount}}
+```
+
+Values support dotted paths:
+
+```md
+{{context.package}}
+```
+
+### Loop
+
+```md
+{{#each knowledgeItems}}
+- [{{title}}]({{href}}) - {{type}}
+{{/each}}
+```
+
+Nested loops are supported:
+
+```md
+{{#each knowledgeGroups}}
+## {{title}}
+
+{{#each items}}
+- [{{title}}]({{href}})
+{{/each}}
+{{/each}}
+```
+
+Inside a loop, `{{@index}}` is zero-based. Use the built-in `inc` helper when
+you need a one-based number:
+
+```md
+{{#each knowledgeItems}}
+{{inc @index}}. [{{title}}]({{href}})
+{{/each}}
+```
+
+### Conditional
+
+```md
+{{#if description}}
+Description: {{description}}
+{{/if}}
+```
+
+The block renders when the value exists, is not `false`, and is not an empty
+string or empty array.
+
+### Template-only Comments
+
+Use Handlebars comments, or HTML comments that start with `context:template`,
+for guidance that should not appear in the generated package:
+
+```md
+{{! This comment is removed by Handlebars. }}
+
+<!-- context:template
+Explain why this section exists and where to edit it.
+Read node_modules/@c4a/context/docs/reference/template-variables.md.
+-->
+```
+
+`context build` strips these comments from rendered output.
+
+## Helpers
+
+| Helper | Example | Meaning |
+|---|---|---|
+| `inc` | `{{inc @index}}` | Adds 1 to a numeric value. Useful for numbered lists. |
+| `json` | `{{json knowledgeGroups}}` | Renders a value as formatted JSON for debugging or machine-readable docs. |
+
+## Built-in Variables
+
+| Variable | Type | Meaning |
+|---|---|---|
+| `packageName` | string | Package name from `kbPackage()` / `llmsPackage()`. |
+| `packageKind` | string | `kb` or `llms`. |
+| `knowledgeNamespace` | string | KB knowledge namespace; defaults to the package name and may be explicitly overridden. Empty for non-KB packages. |
+| `namespacedKnowledge` | boolean | Whether the KB package has a knowledge namespace. |
+| `skillsRoot` | string | Skills root, currently `skills`. |
+| `wikisRoot` | string | Final wikis root, such as `wikis/component-lib-kb` or `wikis/platform/component-lib`. |
+| `guidesRoot` | string | Final guides root, such as `guides/component-lib-kb` or `guides/platform/component-lib`. |
+| `rulesRoot` | string | Final rules root, such as `rules/component-lib-kb` or `rules/platform/component-lib`. |
+| `featsRoot` | string | Final feats root, such as `feats/component-lib-kb` or `feats/platform/component-lib`. |
+| `skillName` | string | Author-maintained name of the Skill currently being rendered. Empty outside a `skills/<name>/...` template. |
+| `skillPath` | string | Final package-relative `SKILL.md` path for the Skill currently being rendered. Empty outside a Skill template. |
+| `knowledgeCount` | number | Selected approved Markdown file count. |
+| `knowledgeTimestamp` | string | Latest selected approved Markdown `timestamp`, or epoch when empty. |
+| `knowledge` | string | Concatenated selected approved Markdown bundle. Use carefully; it can be large. |
+| `approvedKnowledge` | string | Alias for `knowledge`. |
+| `knowledgeItems` | array | One record per selected approved Markdown page. |
+| `knowledgeGroups` | array | Selected pages grouped by OKF root and the first directory segment under that root; each item also exposes `internal_collection`. |
+| `knowledgeTreeNodes` | array | Nested path tree for selected pages. Useful for custom navigation. |
+| `knowledgeTree` | string | Markdown tree preview of selected pages. |
+| `knowledgeItemsMarkdown` | string | Markdown list of up to 50 selected pages. |
+| `knowledgeGroupsMarkdown` | string | Markdown navigation for the current index. Folded directories render direct page links; expanded directories render links to generated indexes. |
+| `buildInventory` | object | Deterministic package build inventory, including selected files, selected-by reasons, collection summaries, and package-visible edge records. |
+| `buildInventoryJson` | string | Pretty JSON form of `buildInventory`. |
+| `buildInventoryPath` | string | Package-relative inventory path, currently `context-build-inventory.json`. |
+| `knowledgeStructure` | object or null | Selected-package projection derived from workspace `knowledge/structure.yaml` at build time. It contains only selected views, their nodes, and package-visible edges. Templates may inspect it, but the default package consumer should rely on `context-build-inventory.json`. |
+| `knowledgeStructureJson` | string | Pretty JSON form of `knowledgeStructure`, or `null`. |
+| `knowledgeStructurePath` | string | Workspace source structure path, currently `knowledge/structure.yaml`; the variable itself is not copied into the package unless a template renders selected structure data. |
+
+Custom variables from `template.vars` are also available.
+
+`buildInventory.structure.edge_records` contains typed edge records whose
+endpoints are visible in the selected package. Use those records when a
+template or generated skill needs package-local relationship evidence. The
+workspace `knowledge/structure.yaml` is not automatically copied into the
+package unless a project-specific template explicitly renders it.
+
+## `knowledgeItems`
+
+Each item contains:
+
+| Field | Meaning |
+|---|---|
+| `path` | Package-relative OKF path, for example `wikis/component-lib/symbol/button.md`. |
+| `sourcePath` | Approved knowledge path before OKF output mapping, for example `architecture/entity/button.md`. |
+| `approved_path` | Alias for `sourcePath`. |
+| `dist_path` | Alias for `path`. |
+| `internalCollection` | Internal approved collection, for example `architecture`. |
+| `internal_collection` | Alias for `internalCollection`. |
+| `collection` | Internal approved collection; alias for `internalCollection`. |
+| `okf_root` | OKF output root, for example `wikis`, `guides`, `rules`, or `feats`. |
+| `okf_root_path` | Final package-relative OKF root; for KB packages it includes the distribution namespace. |
+| `node_ref` | Stable NodeRef from approved frontmatter, for example `entity/button`. |
+| `view_ref` | Stable ViewRef from approved frontmatter, for example `architecture:entity/button`. |
+| `pathWithinCollection` | Path below the OKF root, for example `component-lib/symbol/button.md`. |
+| `href` | Link relative to the template file currently being rendered. Use this in custom templates. |
+| `hrefFromTemplate` | Alias for `href`. |
+| `hrefFromPackageRoot` | Link from a package-root file such as `AGENTS.md`, for example `./wikis/component-lib/symbol/button.md`. |
+| `hrefFromCollectionIndex` | Link from the current OKF root index, for example `./component-lib/symbol/button.md` for a `wikis` item. |
+| `title` | Page title from frontmatter, or a title derived from the file name. |
+| `type` | OKF `type` from frontmatter. |
+| `description` | OKF `description` from frontmatter, when present. |
+| `timestamp` | OKF `timestamp` from frontmatter, when present. |
+| `source` | First top-level `sources` entry without the `repo:` prefix, or the group name. |
+| `group` | First path segment under the OKF root. |
+| `parentPath` | Parent path below the OKF root. |
+| `depth` | Segment count below the OKF root. |
+| `segments` | Path segments below the OKF root. |
+| `tags` | Comma-separated tags from frontmatter. |
+
+Example:
+
+```md
+{{#each knowledgeItems}}
+- [{{title}}]({{href}}) — {{type}}{{#if description}}: {{description}}{{/if}}
+{{/each}}
+```
+
+## `knowledgeGroups`
+
+Each group contains:
+
+| Field | Meaning |
+|---|---|
+| `name` | First directory segment under the OKF root, or `root` for pages directly under the OKF root. |
+| `collection` | Internal approved collection for this group. |
+| `internalCollection` | Internal approved collection; alias for `collection`. |
+| `internal_collection` | Alias for `internalCollection`. |
+| `okf_root` | OKF output root for this group, for example `wikis`, `guides`, `rules`, or `feats`. |
+| `okf_root_path` | Final package-relative OKF root; for KB packages it includes the distribution namespace. |
+| `title` | Display title; defaults to `name`, or the OKF root title for a root group. |
+| `count` | Number of selected pages in this group. |
+| `hasIndex` | Whether the active package navigation policy generates `indexPath`. |
+| `has_index` | Alias for `hasIndex`. |
+| `indexPath` | OKF-root-aware index path, for example `wikis/component-lib/index.md`, `guides/component-lib/index.md`, or `rules/index.md` for a root group. |
+| `indexHrefFromTemplate` | Link from the template file currently being rendered to `indexPath`. Check `hasIndex` before rendering it. |
+| `indexHrefFromCollectionIndex` | Link from the OKF root index to `indexPath`. |
+| `items` | `knowledgeItems` in the group. |
+
+Example:
+
+```md
+{{#each knowledgeGroups}}
+## {{title}} ({{count}})
+
+{{#if hasIndex}}
+[Open directory index]({{indexHrefFromTemplate}})
+{{/if}}
+{{#each items}}
+- [{{title}}]({{href}}) - {{type}}
+{{/each}}
+{{/each}}
+```
+
+## `knowledgeTreeNodes`
+
+`knowledgeTreeNodes` is a nested representation of selected pages. Each node
+contains:
+
+| Field | Meaning |
+|---|---|
+| `name` | Path segment name. |
+| `title` | Display title derived from `name`. |
+| `path` | Path below the OKF root. |
+| `depth` | Depth below the OKF root. |
+| `count` | Number of pages under this node. |
+| `items` | Pages directly under this node. |
+| `children` | Child nodes. |
+
+Use it when a package needs navigation by source, module, category, or symbol
+folder. Handlebars does not include recursive partials by default, so keep
+starter templates shallow or add project-specific sections for the levels you
+care about.
+
+## Starter `wikis/index.md`
+
+The default KB template uses the variables above to generate a starter index:
+
+- bundle count and timestamp in OKF frontmatter;
+- direct page links for directories folded by the active navigation policy;
+- links to generated directory indexes when a directory exceeds the configured
+  inline-entry threshold.
+
+`context build` always provides selected OKF root indexes. By default, a
+non-root directory gets its own index only when it contains more than 50
+descendant knowledge pages. Configure this with
+`kbPackage({ navigation: { foldDirectoryIndexes, maxInlineEntries } })`.
+
+The output is only a starter. Edit
+`src/package-templates/kb/wikis/index.md` to add project-specific reading
+paths, API entry points, or task-focused navigation before `context build`.

package/providers/context/resources/procedures/close-and-build.md

@@ -0,0 +1,20 @@
+---
+id: procedure.close-and-build
+kind: procedure
+mediaType: text/markdown
+---
+
+# Close and build
+
+Close deterministically derives `knowledge/structure.yaml` from approved
+Markdown and the confirmed structure snapshots. It validates the rebuilt
+projection; it does not rewrite approved page bodies.
+
+Build runs only after close and verification are current. It writes declared
+packages under `dist/` and records an inventory receipt with added, updated,
+removed, and index changes.
+
+Run only the current route command, then evaluate again. A successful build
+means the currently declared scope is current; newly captured or newly declared
+targets can reopen earlier graph nodes.
+

package/providers/context/resources/procedures/code-extraction.md

@@ -0,0 +1,30 @@
+---
+id: procedure.code-extraction
+kind: procedure
+mediaType: text/markdown
+---
+
+# Code extraction
+
+Code extraction operates on user-confirmed repository modules and source
+patterns. A source registration identifies the repository or module; the
+extraction declaration defines the code scope inside it.
+
+`include` filters files inside a selected source; it is not a package/module
+selector. Use source declarations to select repository modules. Use configured
+entry patterns when entry-led traversal is meaningful, or scan mode when the
+selected module intentionally has no package entry. Do not require source-code
+rewrites merely to create an extraction entry.
+
+Use a dry-run when the current route requests scope inspection. Report
+discovered files, AST-analyzed files, skipped files, symbols, and relations
+separately. Use resolved entry files, exported/internal counts, and symbol-kind
+counts as structural scope evidence only. Resolve TypeScript/JavaScript
+configuration and aliases through the extractor rather than guessing paths
+from imports. Explain the scope without treating filenames or symbol kinds as
+semantic knowledge. After confirmation, process exactly one pending extraction
+target and evaluate again.
+
+Do not open Review while another extraction target in the same batch remains.
+Unchanged approved symbols do not need another decision; new, changed, or
+unapproved candidates remain subject to the current Review policy.

package/providers/context/resources/procedures/document-capture.md

@@ -0,0 +1,31 @@
+---
+id: procedure.document-capture
+kind: procedure
+mediaType: text/markdown
+---
+
+# Document capture
+
+Capture creates a reproducible local snapshot of a registered document source.
+It does not classify, summarize, approve, or build knowledge.
+
+Before capture:
+
+1. every registered document module must have a matching capture declaration;
+2. the user must have allowed the external read in the current conversation;
+3. execute only the current route command.
+
+An explicit request to capture, ingest, fetch, or read named file/remote
+documents grants source-read permission for those named modules. A mention,
+possible-source discussion, or register-only request does not. An explicit
+refusal always wins.
+
+Capture targets are a batch. Process one current target, evaluate status again,
+and continue until the graph reports the batch complete. Never treat one
+successful module as completion of the whole batch.
+
+The CLI owns normalization, snapshot identity, hashes, manifests, and
+idempotency. Never hand-write or repair captured snapshots. If a selected local
+boundary is a documentation site rather than plain Markdown, use the
+Context-provided processor/configuration diagnostic; do not invent rendered
+text or scan outside the confirmed boundary.

package/providers/context/resources/procedures/document-classification.md

@@ -0,0 +1,20 @@
+---
+id: procedure.document-classification
+kind: procedure
+mediaType: text/markdown
+---
+
+# Document classification
+
+Classification chooses the main knowledge collection for a captured document.
+The choice must follow evidence investigation, not the URL, file name, a user
+example, or a fixed content-specific prompt.
+
+Read the current collection-neutral evidence view, explain a short
+evidence-backed recommendation and its output implications, then obtain the
+user decision unless the current session explicitly delegates this gate.
+
+After the decision, declare the complete align, compile, and review lifecycle
+for the same canonical source and collection. Re-evaluate instead of assuming
+the declaration closed every document target.
+

package/providers/context/resources/procedures/evidence-maintenance.md

@@ -0,0 +1,21 @@
+---
+id: procedure.evidence-maintenance
+kind: procedure
+mediaType: text/markdown
+---
+
+# Evidence maintenance
+
+Approved knowledge can outlive a moved or temporarily unavailable source, but
+the resulting evidence state must stay explicit.
+
+- Re-pin only when the approved body still matches current source content and
+  only the evidence location changed.
+- Create a new candidate when source content changed.
+- Deprecate knowledge that should no longer be used.
+- Keep source-orphaned knowledge only after an explicit user decision and retain
+  the evidence warning.
+
+Use the affected `view_ref` values from the current diagnostic resource. Do not
+target maintenance by guessed paths or node names.
+

package/providers/context/resources/procedures/knowledge-review.md

@@ -0,0 +1,25 @@
+---
+id: procedure.knowledge-review
+kind: procedure
+mediaType: text/markdown
+---
+
+# Knowledge Review
+
+Review is the authority boundary between candidates and approved knowledge.
+Open one report for the complete current candidate set and apply only a payload
+that matches its collection scope and candidate-set digest.
+
+Without explicit session-managed authority:
+
+- open the report returned by the route;
+- let the user approve or reject candidates;
+- apply the exact returned decision payload.
+
+With explicit session-managed authority, Context may approve the complete
+current batch atomically. The authority exists only in the current
+conversation. It does not bypass source permission, validation, close, or
+verify.
+
+After apply, re-evaluate. Do not infer that close or package output is current.
+

package/providers/context/resources/procedures/package-output.md

@@ -0,0 +1,31 @@
+---
+id: procedure.package-output
+kind: procedure
+mediaType: text/markdown
+---
+
+# Package output
+
+Package selection decides how approved knowledge is presented to downstream
+agents or text consumers. Explain the available Context package kinds and their
+directory shape before asking the user to choose.
+
+After confirmation, declare the package in `src/index.ts` using the SDK schema
+resource. Templates may customize presentation, but they must not overwrite
+approved knowledge paths or remove required indexes.
+
+An Agent knowledge-base package uses its package name as a stable single-level
+knowledge namespace by default. Explain that default after the package name is
+confirmed. Ask for a custom namespace only when the user needs another value;
+it may contain several concise lowercase path segments, such as
+`group/package` or `personal-user.123/package`, with letters and numbers joined
+by hyphens or dots. Declare an override as
+`kbPackage({ distribution: { knowledgeNamespace } })`; do not derive it from
+an unstated downstream identity or rewrite template prose.
+
+Ask separately whether the author wants a short optional Skill prefix. If so,
+maintain the complete final Skill directory name in the template, such as
+`skills/android-query/`. Knowledge namespaces never rename Skills.
+
+Package output is incremental: a built package is current only for the approved
+knowledge and template digests recorded by its receipt.

package/providers/context/resources/procedures/project-configuration.md

@@ -0,0 +1,22 @@
+---
+id: procedure.project-configuration
+kind: procedure
+mediaType: text/markdown
+---
+
+# Project configuration
+
+Use the current route facts and Context SDK documentation to make only the
+declaration requested by the route in `src/index.ts`.
+
+- Do not invent sources, modules, collections, or output types.
+- Ask for a user decision when the route is gated and no current-session
+  authority is present.
+- Keep source registration, capture, extraction, align, compile, review, and
+  package declarations paired by their canonical source and collection.
+- After editing, run `context status --format json` again. The workspace facts,
+  not the edit itself, determine whether the route is complete.
+
+The Context SDK API reference is a discoverable resource. Do not guess an API
+shape from older prompts or cached plugin text.
+

package/providers/context/resources/procedures/prose-align.md

@@ -0,0 +1,23 @@
+---
+id: procedure.prose-align
+kind: procedure
+mediaType: text/markdown
+---
+
+# Prose structure alignment
+
+Alignment proposes source-bound knowledge structure. It does not write approved
+knowledge.
+
+Follow the current route's evidence view and input schema. Prefer source heading
+and block boundaries when they preserve coherent reading units; fixed line
+windows are only a fallback for unstructured text. A page may contain multiple
+sections, each with its own continuous evidence span.
+
+Stage all required source/collection slots before batch Review. Structure
+confirmation is an explicit gate. A confirmation applies only to the staged
+slot digest shown by the route; if the digest changes, confirm again.
+
+Independent read-only evidence views may run in parallel. Structure stage,
+confirmation, compile writes, and Review application are serial lifecycle
+mutations; execute them in the order selected by `workflow.current`.

package/providers/context/resources/procedures/prose-compile.md

@@ -0,0 +1,20 @@
+---
+id: procedure.prose-compile
+kind: procedure
+mediaType: text/markdown
+---
+
+# Source-bound prose compilation
+
+Compile materializes review candidates from confirmed structure and source
+evidence. It never writes directly to approved knowledge.
+
+The CLI derives this projection mechanically from the confirmed section ids,
+kinds, and source spans. Run only the revision-bound compile command returned
+by the current Route. Do not create compile-action payloads or rewrite source
+content.
+
+One compile command validates every owned view first, then atomically
+materializes the source/collection candidate batch. Re-evaluate the workspace
+afterward so another structure slot can be routed to its own phase. Do not open
+a partial Review while planned views remain.

package/providers/context/resources/procedures/source-boundary.md

@@ -0,0 +1,37 @@
+---
+id: procedure.source-boundary
+kind: procedure
+mediaType: text/markdown
+---
+
+# Source boundary
+
+A source boundary is a user decision about which repositories, modules, or
+documents may become approved knowledge. It affects extraction scope,
+provenance, output paths, and freshness checks.
+
+Do not infer this boundary from the current directory, monorepo layout, package
+names, or Git remotes. Explain the decision in the user's language, obtain the
+specific paths or documents, then use the Context source schema and conditional
+registration command selected by the route. The command uses `--input -`; after
+the current conversation contains the required confirmation, send one YAML or
+JSON payload matching the selected schema to its standard input. Do not run the
+command before confirmation and do not replace it with a command remembered
+from another route.
+
+Context source identity has two parts:
+
+- a calendar date identifies one capture batch and directory;
+- a module identifies one concrete repository, local document boundary, or
+  remote document inside that batch.
+
+Several modules may share one date. Do not invent date suffixes to separate
+them. A date-only inspection addresses the batch; `<date>/<module>` addresses
+one source. Register a confirmed multi-source request as one serial batch
+mutation instead of running registry writes in parallel.
+
+Repository readiness checks are mechanical and may run after the boundary is
+registered. Clone, fetch, checkout, install, build, test, and other external
+repository operations need separate authority. File and remote-document
+registration records metadata only; reading their bodies requires source-read
+permission for the exact pending modules.

package/{plugins/codex/skills/continue/references/internal-procedures/skill-source-scope/references/capture-source.md → providers/context/resources/procedures/source-capture-detailed.md}

@@ -1,4 +1,8 @@
 ---
+id: procedure.source-capture-detailed
+kind: procedure
+media-type: text/markdown
+context_resource: procedures/source-capture-detailed
 name: capture-source
 description: >
   Capture local Markdown or Lark/Feishu document sources through registered
@@ -22,8 +26,9 @@ registration plus the declared capture phase flow:
 
 Use only commands surfaced by the current status output or capture phase.
 For a user-confirmed multi-document batch, `context status --format json`
-returns every uncaptured module in `routing.command_plan`. Run the complete
-list in order; a successful module is omitted from the next status result.
+selects the next uncaptured module in `workflow.current.commands`. Execute the
+returned command, reevaluate, and continue until the route leaves capture; a
+successful module is omitted from the next status result.
 When the user explicitly asks to capture, ingest, fetch, read, or include exact
 file/Lark paths or URLs, that request is the read permission for those sources;
 do not repeat the question after registration. A mere mention, possible-source
@@ -41,7 +46,8 @@ it to finish and retry rather than editing registry files.
 
 Capture is entirely CLI-driven — your role is to register the right source,
 declare the matching capture phase, run the current `context run capture:*`
-command, and relay its output. Never hand-write captured source snapshots: the
+command, and preserve its machine fields while summarizing the outcome in the
+user's language. Never hand-write captured source snapshots: the
 CLI owns normalisation (NFC, BOM strip, line endings) and the `content_hash`
 contract, so any manual edit breaks idempotency.
 
@@ -98,8 +104,8 @@ Before choosing a local Markdown capture route, honor the surrounding task conte
   rerun the same declared capture phase. The CLI appends a new snapshot only
   when content changes and never overwrites prior snapshots.
 - Code package extraction is not document capture. Route code source selection
-  through `skill-source-scope` extraction preview and the declared extract
-  phase. Do not invent a document capture path for code.
+  through the current code-extraction Route, its selected procedure, and the
+  declared extract phase. Do not invent a document capture path for code.
 - Conversation notes, decisions, and revision intents are not document capture
   sources in the current workflow unless the CLI status or project-specific
   phase exposes an explicit note source contract. If absent, record the user
@@ -112,22 +118,25 @@ registration; do not read file bodies before capture permission is clear.
 
 ### Output Handling
 
-Report the CLI output verbatim. If the CLI reports `N sources changed`, suggest the right next step:
+Preserve commands, reason codes, ids, and diagnostics exactly; summarize
+successful capture results for the user instead of dumping raw JSON. After any
+capture result:
 
-- Run `context status --format json` and use its `state`, `routing`, and
-  `command_plan`; if status returns `needs-capture-phase`, first perform the
-  exact `routing.configuration` edit and rerun status.
-- While status remains `needs-capture`, execute every returned capture command
-  for the already confirmed batch before asking another naming, collection, or
+- Run `context status --format json` and treat `workflow.current` as the
+  current-step authority; if the route returns `configuration`, perform only
+  that declared project edit and rerun status.
+- If `workflow.current.commands` contains another capture command for the
+  confirmed batch, execute it before asking another naming, collection, or
   read-permission question.
-- If status reports `captured-ready-to-investigate`, suggest the returned
-  `context run align:<type>:<source>:<collection> --view read-plan --format json`
-  command and hand off to `skill-prose-align`.
-- If status reports `needs-structure` or `structure-ready`, follow the returned
-  align/compile command instead of naming a generic slash command.
-- If status reports `compile-ready-for-review`, route to the review gate.
-- If the source was code-only and status reports pending code projection,
-  follow the CLI-owned extract/compile route returned by status.
+- If the current Route selects align, compile, Review, or code extraction,
+  follow only that Route's commands and required resources. Do not branch on
+  deprecated top-level `needs-*` status names.
+- If `workflow.current` is a Gate, use its `inspection_action` and selected
+  dialogue resource before requesting a decision. Read an Inspection Action's
+  nested Skill or Schema only when performing that inspection. After explicit
+  confirmation, use the `resolution_action` command and load only that Action's
+  nested Skill or Schema. These conditional resources are intentionally absent
+  from the Route's ordinary `resources.required`.
 
 Never suggest prose compile or hand-built document knowledge for a code-only
 source. Code sources become active knowledge only through the declared

package/providers/context/resources/procedures/verify-and-repair.md

@@ -0,0 +1,20 @@
+---
+id: procedure.verify-and-repair
+kind: procedure
+mediaType: text/markdown
+---
+
+# Verify and repair
+
+Verification failures are grouped by root cause. Read the current diagnostic
+resource before changing anything.
+
+If approved Markdown is valid and only the deterministic structure projection
+is stale, the legal repair is `context close --format json`. Otherwise, repair
+the source-bound candidate or project declaration named by the root diagnostic,
+then run verification again.
+
+Do not delete candidates, approved pages, snapshots, or structure slots to make
+verification pass. Derived diagnostics should not be handled as independent
+root failures.
+

package/{plugins/codex/skills/continue/references/internal-procedures/skill-prose-align/references/internal-procedures/structure-planning/references → providers/context/resources/semantic/align}/candidate-resolution.md

@@ -1,4 +1,17 @@
+---
+id: context.semantic.align.candidate-resolution
+kind: procedure
+media-type: text/markdown
+applies-to:
+  - duplicate
+  - conflict
+  - stable_id
+  - path
+  - unresolved
+---
+
 # Candidate Resolution Rules
+<!-- Context workflow semantic resource. -->
 
 Use these rules after reading the current align evidence views and before
 authoring `context.structure.v1`. They define how current anomaly diagnostics