@c4a/context-cli 0.6.1-beta.2 → 0.6.1-beta.4

package/providers/context/resources/diagnostics/projection-stale.md

@@ -0,0 +1,13 @@
+---
+schema: agent-graph.resource.v1
+id: diagnostic.projection-stale
+kind: diagnostic
+mediaType: text/markdown
+---
+
+# Approved projection is stale
+
+Approved Markdown changed successfully. Its derived `knowledge/structure.yaml`
+projection has not been rebuilt yet. Run only the revision-bound close command
+selected by the current Route. This is an expected lifecycle transition, not a
+content verification failure.

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

@@ -7,7 +7,8 @@ mediaType: text/markdown
 # Document-classification dialogue
 
 Do not recommend a collection before reading the collection-neutral evidence
-view. Summarize the observed document shape, explain one evidence-backed
+view and every required source-body resource. Summarize the observed document
+shape, explain one evidence-backed
 recommendation, and describe its package root:
 
 | Collection | Use when the evidence primarily represents | Package root |

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

@@ -19,13 +19,11 @@ with more than the configured threshold gets its own child index. Templates
 under `src/package-templates/` are editable presentation, not a second factual
 source.
 
-After the user chooses an Agent knowledge-base package, explain that the
-package name is its default single-level knowledge namespace. Ask for an
-override only when the user needs another single- or multi-segment path. Each
-segment may use lowercase letters and numbers joined by hyphens or dots. Ask
-separately whether Skills need a short optional prefix, then maintain their
-complete final names in the template. Do not expose downstream layout-version
-terminology or ask for platform-specific identity fields.
+After the user chooses an Agent knowledge-base package, explain that its
+knowledge roots are flat inside `dist/<package-name>/`; do not ask for a second
+package namespace. Ask whether Skills need a short optional prefix, then
+maintain their complete final names in the template. Do not expose downstream
+layout terminology or ask for platform-specific identity fields.
 
 Do not offer a hidden `both` shortcut. If the user wants multiple outputs,
 declare and inspect one first, then obtain confirmation for the next. Mention

package/providers/context/resources/manuals/guides/package-outputs.md

@@ -49,8 +49,7 @@ least one `SKILL.md` and `wikis/index.md`.
 The default `src/package-templates/kb/` template is only a starting point.
 Inspect the generated `dist/<package-name>/` before calling it usable.
 
-KB packages use their package name as a single-level knowledge namespace by
-default:
+KB packages use flat package-relative knowledge roots:
 
 ```ts
 kbPackage({
@@ -59,44 +58,43 @@ kbPackage({
 });
 ```
 
-This keeps the build folder name independent from install paths and produces
-paths such as:
+The package name already identifies the surrounding build folder, so the
+output does not repeat it inside each root:
 
 ```text
 skills/knowledge-query/SKILL.md
-wikis/component-lib-kb/index.md
-guides/component-lib-kb/...
-rules/component-lib-kb/...
-feats/component-lib-kb/...
+wikis/index.md
+guides/...
+rules/...
+feats/...
 ```
 
-Ask for a custom namespace only when the user needs something other than the
-package name. An explicit value may contain multiple safe lowercase path
-segments:
-
-```ts
-distribution: { knowledgeNamespace: "platform/component-lib" }
-```
-
-Each segment may contain letters and numbers joined by hyphens or dots; keep
-the complete value concise and stable. Context treats it as an opaque knowledge
-path and does not infer downstream platform identifiers or classify package
-content.
+Do not ask for another distribution namespace. Older workspaces may still
+contain `distribution.knowledgeNamespace`; Context accepts that legacy input
+without using it to shape the package.
 
 Skill names are separate. Ask whether the author wants a short optional Skill
 prefix, then maintain the complete final template directory name directly—for
-example `skills/android-query/SKILL.md`. Context never prepends the knowledge
-namespace to a Skill name.
+example `skills/android-query/SKILL.md`. Package-root layout never renames a
+Skill.
 
-The default `knowledge-query` skill carries the structure-first query
-discipline: start from OKF directory indexes, use
+The default `knowledge-query` Skill is a complete generic query entry. It
+carries the structure-first query discipline: start from OKF directory indexes, use
 `context-build-inventory.json` edge records for package-visible relationships,
 inspect page `sources` / `context:section` source_ref metadata, cite
 page/section evidence, and report explicit gaps when the package does not cover
 a requested fact. It does not treat direct grep over bundled OKF root
-directories as the primary discovery path. Users can edit any template file
-under `src/package-templates/kb/` before build to create their own skills,
-prompts, routing rules, or package instructions.
+directories as the primary discovery path. Its final template-author section
+requires package authors to replace or edit the generic routing when the
+package needs project-specific terminology, entry points, known limits, or
+task workflows. Authors may explicitly accept the generic default when it is
+intentionally sufficient.
+
+The same inventory exposes `structure.relationship_coverage`. It records
+whether selected codegraph pages have current source-backed AST relationship
+metadata, how many codegraph views were selected, and how many package-visible
+edges were emitted. An empty edge list is therefore explicit evidence of a
+coverage state, not permission to invent a dependency.
 
 The generated `wikis/` directory is the default OKF root and follows the C4A OKF
 Profile. Internal production collections are mapped into package OKF roots such
@@ -109,9 +107,8 @@ contain Markdown with OKF fields and C4A extension fields at the top level, plus
 `visibility`, and `code_symbols` are not nested under `context`, and page
 frontmatter does not contain `source_refs`. The package root is an agent
 package; the OKF-compatible interchange surface is the selected OKF root
-subtrees under `dist/<package-name>/`. The required logical template entry is
-`wikis/index.md`; a namespaced package writes it to
-`wikis/<knowledge-namespace>/index.md`.
+subtrees under `dist/<package-name>/`. The required template entry and final
+output path are both `wikis/index.md`.
 
 Current collection mapping:
 
@@ -142,7 +139,8 @@ occupies `wikis/**/index.md`.
 Tell the user it can be edited before build to describe the package scope,
 intended users, and query guidance.
 
-The default root index is a starter, not a finished information architecture.
+The default root index is a usable generic entry, not a project-specific
+information architecture.
 It links directly to pages in small child directories and to a child
 `index.md` when that directory exceeds the configured navigation threshold.
 The default threshold is 50 selected knowledge pages. Use Handlebars variables such as
@@ -150,6 +148,13 @@ The default threshold is 50 selected knowledge pages. Use Handlebars variables s
 custom navigation. Before customizing it, read
 `node_modules/@c4a/context/docs/reference/template-variables.md`.
 
+Newly initialized generic templates must be replaced, edited, or explicitly
+accepted before the first build. `context status` exposes that choice as a
+package template Review Gate. Use only the revision-bound command returned by
+that Route to accept an unchanged generic default; edit files under
+`src/package-templates/` when customizing. Context compares file digests and
+records the decision without evaluating the meaning of template prose.
+
 Template paths are rendered before selected knowledge is copied. A rendered
 template path must not collide with a selected knowledge path. If the build
 reports a collision, rename the template file or exclude that knowledge path
@@ -236,12 +241,10 @@ We can also skip package output for now and keep only knowledge/.
 Which one should I declare first?
 ```
 
-If the user chooses the Agent knowledge-base package, explain that its package
-name is already the default knowledge namespace. Ask for an override only when
-the user needs a different single- or multi-segment path. Ask separately whether
-its Skills need a short prefix. Treat these as independent choices: the
-knowledge namespace controls only OKF roots, while the author maintains final
-Skill names.
+If the user chooses the Agent knowledge-base package, explain that its OKF
+roots are flat within `dist/<package-name>/`; do not ask for a second namespace.
+Ask whether its Skills need a short prefix. The author maintains final Skill
+names independently from package paths.
 
 Do not offer `both` as a shortcut. If the user wants multiple outputs, add one
 package first, verify the shape, then add another package after confirmation.

package/providers/context/resources/manuals/reference/package-templates.md

@@ -58,20 +58,15 @@ llmsPackage({
 | `template` | yes | Project-relative template directory or `{ path, vars }`. |
 | `select` | no | Approved knowledge selector. Omit to include all approved knowledge. Supports internal `collections`, OKF `okfRoots`, and `include` / `exclude` path patterns relative to `knowledge/`. |
 | `navigation` | no | KB directory-index policy. Defaults to `{ foldDirectoryIndexes: true, maxInlineEntries: 50 }`. |
-| `distribution` | no | Final knowledge-root namespace for a KB package. Defaults to `{ knowledgeNamespace: name }`; set it explicitly for a custom single- or multi-segment path. |
+| `distribution` | no | Legacy input accepted from older workspaces. It no longer changes package paths and should not be added to new declarations. |
 
 `template` is required. Do not call `kbPackage({ name })` or
 `llmsPackage({ name })`.
 
-## Knowledge Distribution Namespace
+## Flat Package Roots
 
-`name` identifies the build folder under `dist/` and is also the default
-single-level `distribution.knowledgeNamespace`. An explicit namespace may be
-one segment or a slash-separated sequence of safe lowercase path segments. A
-segment may contain letters and numbers joined by hyphens or dots, allowing
-identifiers such as `personal-user.123/package`. Keep every segment short,
-stable, and recognizable. Context treats the complete value as an opaque
-knowledge path and does not assign downstream meanings to individual segments.
+`name` identifies the package boundary under `dist/`. Context does not repeat
+that name inside the package's knowledge roots.
 
 Templates keep a logical, consumer-neutral layout:
 
@@ -83,39 +78,32 @@ rules/...
 feats/...
 ```
 
-For `name: "component-lib-kb"` with no explicit distribution, `context build`
-writes:
+For `name: "component-lib-kb"`, `context build` writes:
 
 ```text
 skills/knowledge-query/SKILL.md
-wikis/component-lib-kb/index.md
-guides/component-lib-kb/...
-rules/component-lib-kb/...
-feats/component-lib-kb/...
+wikis/index.md
+guides/...
+rules/...
+feats/...
 ```
 
-The builder applies the knowledge mapping to template paths, copied knowledge,
-generated indexes, links, and inventory records. It does not apply the
-knowledge namespace to `skills/`, rewrite Markdown prose, or infer path
-segments from downstream platform identifiers. An explicit
-`distribution: { knowledgeNamespace: "platform/component-lib" }` produces the
-same shape under that multi-segment namespace instead.
-
-Because every KB package has a knowledge namespace, Skill templates must not
-hard-code flat package paths such as `wikis/index.md` or
-`rules/standards/index.md`.
-Use `{{wikisRoot}}`, `{{rulesRoot}}`, `{{guidesRoot}}`, or `{{featsRoot}}`
-instead. `context build` and `context status` reject flat Markdown links and
-inline-code paths in `skills/**/*.md` with
-`package/template-namespace-reference-flat`. This check is generic package
-validation; it does not depend on a downstream registry or distribution tool.
+The builder maps copied knowledge, generated indexes, links, and inventory
+records into these roots without rewriting Markdown prose or inferring a
+downstream registry identity. New declarations should omit `distribution`.
+Older declarations that still contain `distribution.knowledgeNamespace` remain
+loadable, but the value does not change output paths or the build fingerprint.
+
+Use `{{wikisRoot}}`, `{{rulesRoot}}`, `{{guidesRoot}}`, or `{{featsRoot}}` in
+Skill templates so references share the package-root contract. These variables
+render to the flat root names above.
 
 Each rendered Skill must live at `skills/<skill-name>/SKILL.md`, and its YAML
 frontmatter `name` must equal `<skill-name>`. Use `{{skillName}}` in custom
 Skill templates. Skill names are author-maintained: when a short prefix is
 useful, rename the template directory to the complete final name, such as
 `skills/android-query/`; Context does not derive it from
-`knowledgeNamespace`.
+the package name.
 
 ## Template Variables
 
@@ -128,8 +116,8 @@ Built-in variables:
 |---|---|
 | `{{packageName}}` | Package name from the declaration. |
 | `{{packageKind}}` | `kb` or `llms`. |
-| `{{knowledgeNamespace}}` | Final KB knowledge namespace. Defaults to the package name; empty only for non-KB packages. |
-| `{{namespacedKnowledge}}` | Whether the package is a KB package with a knowledge namespace. |
+| `{{knowledgeNamespace}}` | Legacy configured namespace when an older workspace still declares one; otherwise empty. Do not use it for new output paths. |
+| `{{namespacedKnowledge}}` | Always `false`; retained only so older templates remain renderable. |
 | `{{skillName}}` | Current author-maintained Skill directory name. |
 | `{{skillPath}}` | Current Skill's final package-relative `SKILL.md` path. |
 | `{{wikisRoot}}`, `{{guidesRoot}}`, `{{rulesRoot}}`, `{{featsRoot}}` | Final package-relative OKF root paths. |
@@ -187,14 +175,14 @@ The default kb template includes:
   query copied knowledge pages structure-first, cite page/section evidence, use
   `context-build-inventory.json` edge records for package-visible
   relationships, and report gaps instead of inventing unsupported answers. The
+  build inventory also exposes `structure.relationship_coverage` so a consumer
+  can distinguish an observed zero-edge result from unknown relationship
+  coverage. The
   default entry OKF root is `wikis/`; packages that select additional internal
   collections expose
   `guides/`, `rules/`, or `feats/` indexes when those roots are selected.
 - `wikis/index.md`, the editable OKF bundle entry page for the generated
-  `dist/<package-name>/wikis/<knowledge-namespace>/` directory.
-
-These are logical template paths. The package distribution namespace changes
-their final output paths as described above.
+  `dist/<package-name>/wikis/` directory.
 
 During `context build`, the root `wikis/index.md` is rendered from the template.
 The builder always provides an index for every selected OKF root. With the
@@ -205,7 +193,7 @@ its pages instead of producing one index per path segment.
 ## OKF Directory Indexes
 
 The generated
-`dist/<package-name>/wikis/<knowledge-namespace>/` tree is the required default
+`dist/<package-name>/wikis/` tree is the required default
 KB entry surface. Internal collections are mapped into OKF roots during build:
 `codegraph`, `business`, and `product` go to `wikis/`; `architecture`, `sop`,
 `faq`, `decision`, and `incident` go to `guides/`; `standards` and `test` go to
@@ -241,11 +229,13 @@ Default navigation rules:
   an index path selected by the current navigation policy are rejected during
   build/status preflight.
 
-Users are expected to customize these template files. Edit
-`src/package-templates/kb/**` before `context build` to define project
-specific skills, prompts, routing rules, and package instructions. Do not add a
-package-name skill by default; add one only when the user wants project-specific
-behavior beyond knowledge lookup.
+The generated templates are complete generic defaults. Before publishing,
+package authors should replace or edit `src/package-templates/kb/**` when the
+package needs project-specific skills, prompts, routing rules, terminology, or
+package instructions. If the generic behavior is intentionally sufficient,
+explicitly accept the unchanged default through the package-template Review
+Route. Do not add a package-name Skill by default; add one only when the user
+wants project-specific behavior beyond knowledge lookup.
 
 ## C4A OKF Profile
 
@@ -307,11 +297,9 @@ relationship citations inside the package instead of assuming the workspace
 `knowledge/structure.yaml` file is bundled.
 
 For KB packages, the inventory records `package.distribution` as
-`layout: "namespaced"` with the final `knowledge_namespace` and OKF root paths.
-Non-KB package types can remain `layout: "flat"`. Selected file and group
-records expose both the logical `okf_root` and final `okf_root_path`, so
-installers can inspect the layout without parsing paths or rewriting package
-content.
+`layout: "flat"`, `knowledge_namespace: null`, and the four package-relative
+OKF roots. Selected file and group records expose both the logical `okf_root`
+and final `okf_root_path`, so consumers do not need to infer paths.
 
 Build expects approved knowledge to be closed when the project has source-bound
 document knowledge. When `workflow.current.reason_code` is

package/providers/context/resources/manuals/reference/project-api.md

@@ -55,10 +55,11 @@ knowledge/codegraph/module-a/...
 knowledge/codegraph/module-b/...
 ```
 
-For prose Views, omit `containment` when the page is an independent collection
-entry. The CLI then derives `knowledge/<collection>/<slug>.md`. Set
-`containment` only when the approved structure intentionally places the page
-under a parent path; it is not a required source/module wrapper.
+For prose Views, provide a stable filename `slug` and omit `path`; the CLI
+derives the path. Omit `containment` when the page is an independent collection
+entry, producing `knowledge/<collection>/<slug>.md`. Set `containment` only
+when the approved structure intentionally places the page under a parent path;
+it is not a required source/module wrapper.
 
 The registry stores this as one date entry containing several `modules` entries,
 and materializes each module at `sources/repo/<date>/<module>`.
@@ -185,7 +186,10 @@ with the next declared command in `workflow.current.commands`.
 Each command item declares its effect and availability. The current route's
 `gate` identifies the decision and authority boundary. Write commands are bound
 to the workflow revision; after one succeeds, rerun status instead of reusing
-the old command.
+the old command. An external command also declares
+`execution.target: agent-host`; execute it as a top-level Agent-host action so
+network and credential-store access are not lost inside a restricted child
+sandbox.
 
 ### `allSources("repo")`
 
@@ -251,11 +255,26 @@ context review approve-all <collection> --managed --format json
 context review approve-all --all --managed --format json
 ```
 
+The default JSON result reports counts and change totals without listing every
+candidate id or materialized path. Add `--verbose` only when debugging requires
+the complete candidate and page details.
+
 Managed structure confirmation and Review use only the revision-bound commands
 returned by `workflow.current`. Source boundaries and unread source bodies,
 external operations, payload validation, deterministic close, and verification
 errors are never bypassed.
 
+For consecutive mechanical routes, the Agent may run:
+
+```bash
+context run --managed --until blocked-or-complete --format json
+```
+
+This is a bounded host loop over the same revisioned routes. It stops before
+read-only interpretation, project configuration, unresolved authority,
+diagnostics, or a non-unique command plan; it does not add another workflow
+entry or make semantic decisions.
+
 ### `captureFile`
 
 Capture a registered file source into a committed normalized document snapshot.
@@ -360,6 +379,7 @@ context run align:file:<source-name>:architecture --view read-plan --format json
 context run align:file:<source-name>:architecture --view source-index --compact --format json
 context run align:file:<source-name>:architecture --view span-detail --span <source-ref> --format json
 context run align:file:<source-name>:architecture --view span-text --span <source-ref> --format json
+context run align:file:<source-name>:architecture --view existing-knowledge --query <title-or-stable-ref> --format json
 context run align:file:<source-name>:architecture --view schema --format json
 context run align:file:<source-name>:architecture --view semantic-rules --format json
 context run align:file:<source-name>:architecture --validate --input <structure.yaml> --format json
@@ -368,15 +388,64 @@ context run align:file:<source-name>:architecture --view structure-summary --inp
 context run align:file:<source-name>:architecture --stage --input <structure.yaml> --format json
 ```
 
+When `workflow.current.batch` is present, several independent document slots
+can be prepared in one Agent pass and validated or staged through one command:
+
+```yaml
+schema: context.prose.structure-batch.v1
+items:
+  - phase_id: align:file:<source-a>:architecture
+    input: .tmp/agent-payloads/<source-a>-structure.yaml
+  - phase_id: align:file:<source-b>:architecture
+    input: .tmp/agent-payloads/<source-b>-structure.yaml
+```
+
+```bash
+context run --batch-input .tmp/agent-payloads/prose-structure-batch.yaml --validate --format json
+context run --batch-input .tmp/agent-payloads/prose-structure-batch.yaml --stage --managed --format json
+```
+
+Batch preflight validates every payload before writing. Stage writes ready
+slots serially; it does not merge documents or decide their semantic shape.
+
+Align results expose a recommended `payload_target.path` under
+`.tmp/agent-payloads/`. Agents should use it for transient structure inputs and
+may remove the file after a successful stage. The CLI continues to accept an
+explicit alternative path; this is an authoring convention, not validation.
+
+For the ordinary path, `read-plan` is a complete authoring packet: it includes
+the payload contract, a budgeted canonical source-ref map, exact source-body
+resources, and a direct `--stage` command. Read the bodies, author the payload,
+and run that stage command. Request `source-index` only when the packet reports
+omitted refs, and request `existing-knowledge` only when reusing or checking an
+approved identity. The separate schema and validate views are optional
+diagnostic tools, not required lifecycle steps.
+
 `--validate`, `--stage`, and `--confirm` are mutually exclusive operations. An
 `--input` without an operation is rejected unless the selected view explicitly
 consumes that input. Deterministic boundary repairs run internally before the
-result is returned. Successful validation returns a stage command with the
+result is returned. `self_healed` includes input/output Section counts, the
+number of original Sections split, and structural reason codes. Stage performs validation before writing and returns the
+same diagnostics on failure; in managed mode, a valid stage also confirms the
+structure. Successful standalone validation returns a stage command with the
 same file path. JSON run output keeps `next_action` first;
 schema and full reports stay behind explicit Views, while `--verbose` restores
 the full phase result and repeated contracts. Long diagnostics return a compact
 first page plus an exact diagnostics continuation command.
 
+Validation returns `state: ready | repair-required | invalid`. Only `ready`
+sets `valid: true` and may proceed to stage. `error_free: true` with
+`state: repair-required` means no error diagnostic remains, but a declared
+confirmation blocker still requires repair; it is not a successful result.
+
+`existing-knowledge` is the authoring-time lookup for approved identities. It
+returns stable NodeRefs, ViewRefs, titles, tags, collections, and section counts
+without exposing workspace storage paths. `--query` performs deterministic
+case-insensitive exact/prefix/substring matching; `--collection`,
+`--node-type`, `--page-size`, and the returned continuation command narrow or
+page the same View. Use it after reading source evidence and before introducing
+a new Node identity. Structure validation remains the final duplicate gate.
+
 Align and compile evidence results include `semantic_rules`. Its `required`
 array is the rule subset selected for the current judgment, with a selection
 reason and content digest for each rule. `handle`, `digest`, and
@@ -400,7 +469,20 @@ After capture, the capture phase itself exposes collection-neutral `read-plan`,
 Status selects `route.document.classification-required` until every captured
 target has an evidence-backed, user-confirmed align declaration. Align then
 adds `schema` and `structure-summary` for structure work. Agents should not
-inspect `sources/` or `.tmp` directly.
+scan `sources/` or `.tmp` to invent evidence. They may read only the exact
+source-body files selected as required resources by the current Route; those
+files carry stable content digests and must be read in full before a receipt is
+reported. Read all required direct paths, then execute the Route's single
+`resources.after_read.command`; the CLI writes and carries the merged receipt
+set without requiring Agent-authored JSON. That acknowledgement response
+already contains the re-evaluated `workflow.current`, so no additional status
+command is needed.
+
+Generated Context Views use the same content-addressed rule. Materialization
+returns a receipt-set path and an exact post-read command. Read the complete
+file, then execute that command; unchanged content remains current across
+workflow revisions, while write and external commands still require the exact
+current revision.
 
 Compile `read-plan`, `blockers`, and `diagnostics` Views are workspace-read-only
 and may run concurrently. Compile `--validate`, compile `--stage`, structure
@@ -437,9 +519,9 @@ compile:file:<source-name>:architecture
 compile:lark:<source-name>:architecture
 ```
 
-Compile requires confirmed `unapproved/structure.yaml`. It freezes the current
-structure for the compile round; if the user wants to change nodes, section
-ownership, or relationships, return to the align/structure gate.
+Compile requires confirmed CLI-managed lifecycle structure. It freezes the
+current structure for the compile round; if the user wants to change nodes,
+section ownership, or relationships, return to the align/structure gate.
 
 Common commands:
 
@@ -523,7 +605,7 @@ package from a larger monorepo source.
 Use `context source inspect <date>/<module>` to list detected module/package
 boundaries before choosing the source. Use `context run <phase-id> --dry-run
 --format json` to check the resolved modules, file counts, symbol counts, and
-candidate estimate before writing `unapproved/entities.jsonl`. The dry-run
+candidate estimate before writing the ignored lifecycle candidate ledger. The dry-run
 preview also includes `knowledgeTree` and `knowledgePathExamples`, which show
 where approved Markdown will land after review apply.
 Its module and total summaries distinguish `discoveredFiles`, `analyzedFiles`,
@@ -605,7 +687,8 @@ structure slots and every declared `pendingStructureTargets` item in the round;
 codegraph waits for every pending extract phase in the confirmed module round.
 Candidate count/hash therefore describes the complete current batch rather than
 one page, source slot, or module. Deterministic close later merges all active
-slots into `knowledge/structure.yaml`.
+slots into `knowledge/structure.yaml`, retains only their source, collection,
+and consumed snapshot hash as `source_inputs`, then removes the lifecycle slots.
 
 `status.structureBatch` lists unclassified, configuration-required, pending,
 and active structure slots together with the execution policy for the round.

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

@@ -97,13 +97,13 @@ Read node_modules/@c4a/context/docs/reference/template-variables.md.
 |---|---|---|
 | `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. |
+| `knowledgeNamespace` | string | Legacy configured namespace when an older workspace still declares one; otherwise empty. It does not change output paths. |
+| `namespacedKnowledge` | boolean | Always `false`; retained so older templates remain renderable. |
 | `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`. |
+| `wikisRoot` | string | Final wikis root: `wikis`. |
+| `guidesRoot` | string | Final guides root: `guides`. |
+| `rulesRoot` | string | Final rules root: `rules`. |
+| `featsRoot` | string | Final feats root: `feats`. |
 | `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. |
@@ -145,7 +145,7 @@ Each item contains:
 | `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. |
+| `okf_root_path` | Final flat package-relative OKF root. |
 | `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`. |
@@ -183,7 +183,7 @@ Each group contains:
 | `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. |
+| `okf_root_path` | Final flat package-relative OKF root. |
 | `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`. |
@@ -242,6 +242,7 @@ 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`.
+The output is only a starter. Edit the files under
+`src/package-templates/kb/` when the package needs different reading paths or
+navigation before `context build`. An unchanged generated starter must instead
+be explicitly accepted through the current package-template Review Route.

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

@@ -8,7 +8,9 @@ mediaType: text/markdown
 
 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.
+projection; it does not rewrite approved page bodies. Before removing the
+transient snapshots, it retains only each closed prose target's source,
+collection, and consumed snapshot hash under `source_inputs`.
 
 Build runs only after close and verification are current. It writes declared
 packages under `dist/` and records an inventory receipt with added, updated,
@@ -17,4 +19,3 @@ 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

@@ -26,5 +26,19 @@ 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.
+Unchanged approved or rejected symbols do not need another decision; new or
+changed candidates remain subject to the current Review policy.
+
+For TypeScript sources, Context also carries extractor-reported AST relations
+between selected symbols. A relation is projected only when both endpoints
+resolve uniquely inside the selected module; external, unselected, and
+ambiguous endpoints are counted as omissions instead of guessed. The extract
+receipt reports `relationships.detected`, `emitted`, and omission counts.
+Review materializes those source-backed relations with the approved symbol,
+and deterministic close refreshes the typed edge projection.
+
+Zero edges remain a valid result. Read `close.relationshipCoverage` or the
+package inventory's `structure.relationship_coverage` to distinguish a current
+source-backed extraction that found no approved edges from an older or
+otherwise unknown relationship mode. Never infer missing edges from symbol
+co-occurrence, filenames, or package size.

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

@@ -20,6 +20,20 @@ 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.
 
+When that permission is already present in the conversation, execute the
+Gate's returned authority-carrying command. In managed mode it runs the
+deterministic capture batch until the next real blocker; in ordinary mode it
+reevaluates status with `context.source-read`. The authority remains in the
+current command chain and is never persisted in the project. Never bypass the
+Route by running a bare capture phase.
+
+Document capture is an external action. Execute a returned command with
+`execution.target: agent-host` through the Agent host so its network and
+credential-store access remain available; do not nest it inside a restricted
+child sandbox. If the CLI reports an external-environment requirement, retry
+the same returned command through the host. Never downgrade credential
+protection as a recovery step.
+
 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.