@c4a/context-cli 0.7.1 → 0.7.5

package/providers/context/schemas/indexer-materialize-request.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "context.indexer.materialize-request/v1",
+  "$id": "context.indexer.materialize-request/v2",
   "type": "object",
   "additionalProperties": false,
   "required": [
@@ -12,9 +12,7 @@
     "provider_fingerprint",
     "provider_integrity",
     "manifest_digest",
-    "requirement_set_digest",
-    "workset_ref",
-    "workset_digest",
+    "stage",
     "profile",
     "composer_id",
     "instruction_set_digest",
@@ -22,7 +20,7 @@
     "request_digest"
   ],
   "properties": {
-    "protocol": { "const": "context.indexer.materialize-request/v1" },
+    "protocol": { "const": "context.indexer.materialize-request/v2" },
     "handler": { "const": "context.materialize-indexer-instructions/v1" },
     "resource_id": { "const": "resolved-indexer-instructions" },
     "indexer_id": { "type": "string", "minLength": 1 },
@@ -30,9 +28,7 @@
     "provider_fingerprint": { "$ref": "#/$defs/digest" },
     "provider_integrity": { "$ref": "#/$defs/digest" },
     "manifest_digest": { "$ref": "#/$defs/digest" },
-    "requirement_set_digest": { "$ref": "#/$defs/digest" },
-    "workset_ref": { "type": "string", "minLength": 1 },
-    "workset_digest": { "$ref": "#/$defs/digest" },
+    "stage": { "enum": ["partition", "author", "post-author"] },
     "profile": { "type": "string", "minLength": 1 },
     "composer_id": {
       "oneOf": [

package/providers/context/schemas/indexer-materialized-resource.schema.json

@@ -23,7 +23,14 @@
         "additionalProperties": false,
         "required": ["kind", "resource_ref", "digest", "content"],
         "properties": {
-          "kind": { "enum": ["provider", "customization-append"] },
+          "kind": {
+            "enum": [
+              "provider",
+              "template",
+              "composer",
+              "customization-append"
+            ]
+          },
           "resource_ref": { "type": "string", "minLength": 1 },
           "digest": { "$ref": "#/$defs/digest" },
           "content": { "type": "string" }

package/providers/context/schemas/indexer-overlay-question-proposal-input.schema.json

@@ -23,10 +23,59 @@
     },
     "validation_result": {
       "type": "object",
-      "required": ["protocol", "outcome", "result_digest"],
+      "additionalProperties": false,
+      "required": [
+        "protocol",
+        "outcome",
+        "graph_outcome",
+        "validation_input_digest",
+        "project_ref",
+        "overlay",
+        "effective_profile",
+        "conformance_report",
+        "validation_receipt",
+        "result_digest"
+      ],
       "properties": {
         "protocol": { "const": "context.indexer.contract-overlay-validation-result/v1" },
-        "outcome": { "const": "trusted" },
+        "outcome": { "const": "valid" },
+        "graph_outcome": { "const": "completed" },
+        "validation_input_digest": { "$ref": "#/$defs/digest" },
+        "project_ref": { "type": "string", "minLength": 1 },
+        "overlay": { "type": "object" },
+        "effective_profile": { "type": "object" },
+        "conformance_report": {
+          "type": "object",
+          "required": ["protocol", "report_digest"],
+          "properties": {
+            "protocol": { "const": "context.indexer.overlay-conformance-report/v1" },
+            "report_digest": { "$ref": "#/$defs/digest" }
+          }
+        },
+        "validation_receipt": {
+          "type": "object",
+          "additionalProperties": false,
+          "required": [
+            "protocol",
+            "project_ref",
+            "overlay_digest",
+            "base_contract_digest",
+            "provider_integrity",
+            "operator_contract_digest",
+            "conformance_report_digest",
+            "receipt_digest"
+          ],
+          "properties": {
+            "protocol": { "const": "context.indexer.overlay-validation-receipt/v1" },
+            "project_ref": { "type": "string", "minLength": 1 },
+            "overlay_digest": { "$ref": "#/$defs/digest" },
+            "base_contract_digest": { "$ref": "#/$defs/digest" },
+            "provider_integrity": { "$ref": "#/$defs/digest" },
+            "operator_contract_digest": { "$ref": "#/$defs/digest" },
+            "conformance_report_digest": { "$ref": "#/$defs/digest" },
+            "receipt_digest": { "$ref": "#/$defs/digest" }
+          }
+        },
         "result_digest": { "$ref": "#/$defs/digest" }
       }
     },

package/providers/context/schemas/indexer-workset-view-materialization-request.schema.json

@@ -0,0 +1,35 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.indexer.workset-view-materialization-request/v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "protocol",
+    "handler",
+    "resource_id",
+    "workset_digest",
+    "execution_request_digest",
+    "view_digest",
+    "payload_digest",
+    "request_digest"
+  ],
+  "properties": {
+    "protocol": { "const": "context.indexer.workset-view-materialization-request/v1" },
+    "handler": { "const": "context.materialize-indexer-workset-view/v1" },
+    "resource_id": {
+      "type": "string",
+      "pattern": "^authorized-indexer-workset-view(?:/task-[0-9]{3})?$"
+    },
+    "workset_digest": { "$ref": "#/$defs/digest" },
+    "execution_request_digest": { "$ref": "#/$defs/digest" },
+    "view_digest": { "$ref": "#/$defs/digest" },
+    "payload_digest": { "$ref": "#/$defs/digest" },
+    "request_digest": { "$ref": "#/$defs/digest" }
+  },
+  "$defs": {
+    "digest": {
+      "type": "string",
+      "pattern": "^sha256:[a-f0-9]{64}$"
+    }
+  }
+}

package/providers/context/skills/authorize-current-indexer-provider-program/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: context-authorize-current-indexer-provider-program
+description: Resolve the current Context Gate for an exact non-sandboxed Indexer Provider program.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: current-provider-program-authorization
+---
+
+# Authorize the current Provider program
+
+Read the exact program report in `gate.resolution_action.input`. Resolve only the current Gate:
+
+- return `stage: provider-program-authorization`;
+- return `decision: approved` only when the user approved it or the Route says the Gate is resolved
+  by session authority;
+- otherwise return `decision: rejected`.
+
+Do not change Provider identity, program content, scope, limits, or authority. Submit the value to
+the Route's only `complete-current` command and then follow the newly returned Route.

package/providers/context/skills/configure-indexer-providers/SKILL.md

@@ -17,42 +17,56 @@ completion conditions. This Action is the entry for
 the guide's `indexer-provider-unavailable` handling instead of substituting a
 different version or cache.
 
-Report the exact CLI-bundled catalog together with other Indexer entry Skills
-already visible in this conversation. For an exact Skill root already exposed
-by the Host, read only `SKILL.md` frontmatter and the sibling
-`context-indexer.yaml`: the manifest version is authoritative and
-`metadata.context-provider-version` must match it. Do not load Provider guidance
-until selection. Group the same Skill name and exact version into one
-conversation item with all observed source types; an installed copy of the
-same CLI-bundled identity is not another Provider. Preserve distinct source
-observations in `visible_skills`, keep different versions separate, and never
-use source count or discovery order as precedence. Do not scan plugin caches or
-persist this discovery list.
+The current Action input already contains the exact requirements and
+CLI-bundled catalog. Select applicable Providers using that input and the Skills
+already visible in this conversation. Do not run a separate catalog command,
+enumerate every installed Skill, or require a discovery report/confirmation.
+For a selected shipped Provider, copy its exact version, integrity and
+cli-bundled distribution from the supplied catalog. The same Skill/version
+visible in the Host is a projection, not another Provider or a reason for Host
+resolution. If selecting a relevant external Skill, read only its exact
+Host-exposed frontmatter and sibling `context-indexer.yaml` needed to identify
+it; manifest version is authoritative. Do not guess missing versions, substitute
+a different version, or scan caches. Read Provider guidance only when selected.
 
 When the Graph enters through `markdown-provider`, first require the completed
-capture report and report the visible `context-markdown-indexer*` Skills before
-building the route input. Treat only the report's exact `source_inputs` as
+capture report. Treat only the report's exact `source_inputs` as
 current evidence. Do not infer semantic ownership from filenames, titles, or
 headings, and do not persist the discovery list. Capture proves byte/currentness
 only; the selected Markdown Provider remains responsible for semantic indexing.
 
-Produce `context.indexer.provider-route-input/v1` for the current, unchanged
-requirement set. Select portable distribution locators and exact versions and
-integrities. Each required requirement/domain/source/module owner cell needs one
-primary Indexer; overlapping read scope is allowed for enrichers. One Indexer
-may combine a primary layer, supporting profiles, extension layers, and
-composers, but Provider array order is not precedence.
-
-On the first pass set `community_fallback_attempted: false`. If the CLI records
-the route Action as `partial`, retry with the applicable CLI-bundled community
-profile and set it to `true`. If the CLI reports conflicting primary owner cells,
-do not choose one by name order: present the exact conflict and wait for a
-decision. If fallback still leaves an unowned required cell, preserve the exact
-CLI `capability_gap_proof` and record `blocked`; never invent a Provider or
-weaken the requirement. Only the following `propose-indexer-customization`
-Action may use that proof to draft a dependency-free minimal `extend`.
-
-Record the CLI Route Action outcome exactly from `route.graph_outcome`. Only a
-`completed` report may pass its `selection_proposal_input` to
-`validate-indexer-selection-proposal`. Provider resolution and execution remain
-separate Actions.
+Return only the compact current-Action result:
+
+```yaml
+stage: provider-selection
+host_visible_skills: []
+indexers:
+  - <one complete selected Indexer registry entry>
+```
+
+`host_visible_skills` contains only relevant non-CLI observations already
+visible to the Host; leave it empty for a CLI-bundled selection without external
+observations. It is not an inventory of installed Skills. `indexers` contains
+the semantic registry entries selected for the
+unchanged requirements in the Action input. Select portable distribution
+locators and exact versions and integrities. Each required
+requirement/domain/source/module owner cell needs one primary Indexer;
+overlapping read scope is allowed for enrichers. One Indexer may combine a
+primary layer, supporting profiles, extension layers, and composers, but
+Provider array order is not precedence.
+
+Choose the applicable CLI-bundled community profile directly when no visible
+specialized Provider is required. The CLI constructs the full route input,
+performs fallback/conflict checks, validates the proposal, resolves and stages
+bundles, and atomically applies `src/indexers.yaml`. If the current Route reports
+a primary owner conflict or an uncovered required cell, present that exact
+problem and wait; never invent a Provider or weaken the requirement.
+
+Submit the result only through the exact `context action complete-current`
+command returned by the Route. Never call the low-level route, validation,
+resolution, staging or apply commands as a production workflow. If a selected
+external Provider needs Host resolution, the next current Route exposes that
+existing Host Action and its exact request; invoke it once and submit its Host
+result through the next `complete-current` command. If the resolved Bundle carries a
+non-allowlisted program, continue through the returned existing program-execution
+Gate; never bypass it or fall back to its low-level command.

package/providers/context/skills/resolve-current-indexer-gate/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: context-resolve-current-indexer-gate
+description: Resolve the current Indexer structure or layout Gate using the exact current Route input and output schema.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: current-lifecycle
+---
+
+# Resolve the current Indexer Gate
+
+Use this Skill only when the current Indexer Route exposes it as
+`gate.resolution_action`. Read the Route input and the resolution Action output
+schema before deciding.
+
+For `stage: structure-review`, inspect the complete semantic structure Resource
+and return either `approved` or `request-adjustment`. Include specific feedback
+when requesting adjustment.
+
+For `stage: layout-confirmation`, use the supplied change reports and the
+user's decision. Return either `approved` or `rejected`. Include specific
+feedback when rejecting. A non-delegatable layout Gate must not be approved on
+the user's behalf.
+
+Submit exactly one existing `context.indexer.current-action-input/v2` value to
+the Route's completion command. Do not invent a lifecycle continuation
+envelope, a second approval protocol, or additional audit data.

package/providers/context/skills/resolve-current-indexer-provider/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: context-resolve-current-indexer-provider
+description: Resolve the exact Host-backed Provider request selected by the current Context workflow Route.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: current-provider-resolution
+---
+
+# Resolve the current Indexer Provider
+
+Use only the Host Action Resource required by the current Route. Materialize that Resource once and
+return one `context.indexer.current-action-input/v2` value with `stage` set to
+`provider-resolution` and `result` set to the complete Host Action result. If the Host also returns
+the managed output named by the Route, include it as `managed_output` without changing its ref,
+digest, or value.
+
+Do not discover another Provider, substitute a version, read Provider files directly, or recreate
+the Host result. Submit the value to the Route's only `complete-current` command and then follow the
+newly returned Route.

package/providers/context/skills/run-indexer-agent-step/SKILL.md

@@ -1,20 +1,59 @@
 ---
 name: context-run-indexer-agent-step
-description: Execute one Context-authorized Indexer workset using only the current Route input and resolved Provider instructions.
+description: Execute one bounded batch of Context-authorized Indexer worksets using the current Route input, shared Provider instructions, and each task's authorized View.
 metadata:
   agent-graph: path:../../provider.yaml
   agent-graph.graph: indexer
   agent-graph.entry: agent-step
 ---
 
-# Run one Indexer Agent step
+# Run one bounded Indexer Agent batch
 
 Read the current Route action input and every required Resource marked `read-required`.
-Use only the materialized `resolved-indexer-instructions` content, the supplied workset,
-composition input, and Context-authorized evidence. Do not discover another Skill, read a
-Provider path, widen source scope, run a program, or invent missing evidence.
-
-Return exactly `context.indexer.agent-step-result/v1`. Preserve the supplied input and
-execution request digests, bind the materialized instruction payload digest, and include
-the current Host execution receipt. Context performs the final schema, evidence, owner,
-scope, and workset validation; never report success merely because the prose looks valid.
+Use only the materialized `resolved-indexer-instructions`, the supplied transport worksets,
+and each task's `authorized-indexer-workset-view/task-NNN`. Match Views and outputs only through
+the short `task_key`; do not copy internal digests into the semantic result. Each View contains the
+exact facts, dependencies, Provider fragments, and Author authority authorized for that task. Do not
+construct evidence read requests, manage pages or cursors, discover another Skill, read a
+Provider path, widen source scope, run an unauthorized Indexer or parser, or invent missing
+evidence.
+
+Return exactly one `results[]` entry for every task in the current batch, in task-key order. Each
+entry carries its `task_key` and the existing stage-specific semantic Result. A single-task batch
+still uses the same array shape. Copy dynamic authority values only from the Route input or that
+task's authorized View.
+
+For a Partition Result, read `partition-authority` before choosing each group subject. A string
+changes only the local key and preserves `base_subject_key` namespace and kind. Use an explicit
+subject object only when its kind is listed in `subject_key_contract.kinds`; never invent a kind
+from a page title, operation name, framework term, or business vocabulary.
+
+`subject_intent` describes the reader-subject outcome, not the source file's role. Use `primary`
+when the group owns a reader subject. Use `enrich-or-independent` for a publishable supplemental
+view such as test or example behavior: Context reuses a matching subject when available and creates
+an independent subject otherwise. Do not emit `supporting`; material that must never become a reader
+subject must not be emitted as a group.
+
+For an Author Result, a selected parser Fact is an immutable projection, not material for a new
+Fact shape. Build it only from the matching View items:
+
+- `fact_ref` = the `fact` item's `value.fact_ref`;
+- `fact_kind` = the `fact` item's `value.kind`;
+- `subject_key` = `author-authority.expected_subject_key`;
+- `value` = the `fact` item's `value.payload` exactly, without wrapping, renaming, or adding fields;
+- `evidence_refs` = the source-span evidence refs reached through the matching `selected-fact`
+  dependency node.
+
+Build each EvidenceBinding from that same source-span dependency's `evidence_ref`, `source_ref`,
+`module_ref`, `locator`, and `content_digest`. Do not infer a new locator or digest from prose.
+For behavior, read the Author View's `source-text` items. Their `spans` contain the authorized
+source lines; `source_span_refs` link back to existing dependency nodes, not new evidence identities.
+Overlapping ranges appear once. A signature or call name alone does not establish behavior absent
+from those lines. Do not copy these process-only carriers into reader Markdown.
+Do not invent or manually copy read-receipt, execution-receipt, or stable-result digests. Submit
+exactly `context.indexer.current-action-input/v2` through the Route's completion command; Context
+derives internal envelopes and performs dependency, schema, owner, scope, and per-workset validation
+before reporting each task accepted. Read the completion's `outcomes`, then continue directly from
+its `next` Route and ready Resource paths. Do not run `context status` or either Resource materializer
+between successful batches. A failed item is retried from its returned task-only skeleton; already
+accepted peers are not repeated. Never report success merely because the envelope or prose looks valid.

package/providers/context/skills/run-indexer-lifecycle/SKILL.md

@@ -9,28 +9,34 @@ metadata:
 
 # Run The Indexer Lifecycle
 
-This Action replaces the retired extraction, document-classification, align,
-structure-confirmation, and prose default-plan routes. Do not invoke those
-paths and do not turn existing approved knowledge into an indexing fallback.
+This Action continues the sole registry-and-Provider indexing route. Use the
+current Indexer subroute for semantic partitioning, structure review, authoring,
+composition, layout, Candidate compilation, and repair. Existing approved
+knowledge is an input to incremental planning, never a parallel authoring path.
 
 Read
 `node_modules/@c4a/context/docs/guides/indexer-provider-and-customization.md`,
 then follow the root `context` Skill's Indexer instructions and the exact
 structured outcomes returned by `context indexer ...`. Start by forming and
-confirming requirements when `src/indexers.yaml` is absent or stale; otherwise
+confirming requirements when `src/indexers.yaml` is absent or stale. When the
+Route returns `configuration`, edit the named project file and re-evaluate;
+do not submit a lifecycle Result or repeatedly run an unconfigured project. Otherwise
 continue the current registry selection, Provider resolution, execution,
-reconciliation, layout, audit, and Candidate compile subroute. The Indexer
+reconciliation, mechanical validation, layout, and Candidate compile subroute. The Indexer
 Graph is the authority for each substep. Never skip directly to compile and
 never synthesize a Provider Result or a default plan.
 
+When the current subroute is a Gate, follow `gate.resolution_action` rather
+than looking for a top-level `action`. Read its Skill and output schema, use its
+Route input, and submit the resulting value through the Route completion
+command. The Indexer Graph owns the Gate identity, authority, delegation and
+resolution Action; do not replace them with an inferred command or handler.
+
 Stop on the first Host permission, non-delegatable Gate, validation failure, or
 human decision. Once current Candidates have been compiled, return control to
 `context status --format json`; the workspace Graph will select Knowledge
-Review. The Action output is only:
-
-```json
-{
-  "protocol": "context.indexer.lifecycle-continuation/v1",
-  "outcome": "follow-indexer-route"
-}
-```
+Review. This outer Action has no payload of its own and must never be submitted
+through `complete-current`. Context projects it to the one current Indexer
+subroute; follow that Route's command and output schema exactly. If project
+configuration was edited, re-run `context status --format json` to obtain the
+new revision instead of inventing a lifecycle continuation result.

package/providers/context/skills/run-indexer-post-author-composer/SKILL.md

@@ -1,21 +1,62 @@
 ---
 name: context-run-indexer-post-author-composer
-description: Execute one CLI-authorized post-author composer request without changing primary facts, identity, scope, or composer selection.
+description: Execute one bounded batch of CLI-authorized post-author composer tasks without changing primary facts, identity, scope, or composer selection.
 metadata:
   agent-graph: path:../../provider.yaml
   agent-graph.graph: indexer
   agent-graph.entry: post-author-composer-step
 ---
 
-# Run one post-author composer
+# Run a post-author composer batch
 
-Read the current Route input and the exact `context.indexer.layer-fragment-request/v1`.
-Use only its bounded `primary_result_view`, selected `composer_ref`, allowed target refs,
-and the resolved instructions supplied by Context. Do not discover another Skill or
-composer, read project files outside the request, change a SubjectKey, create a complete
-primary Result, or widen the target set.
+Read both required Route resources before acting:
 
-Return exactly `context.indexer.layer-fragment-result/v1`. Preserve the request digest,
-composer ref, and consumed PrimaryResultView digest. Return only zero or more
-`derived-artifact-proposal` fragments for allowed targets. Context performs final schema,
-identity, evidence, policy, layer, and receipt validation before accepting the Result.
+- `resolved-indexer-instructions` defines the selected Composer's job;
+- each `authorized-indexer-workset-view/task-NNN` is one complete, bounded PrimaryResult View.
+
+Use only the target aliases and source aliases exposed by that View and the current Route.
+Do not discover another Skill or Composer, scan project files outside the View, change a
+SubjectKey, rewrite the primary Result, or widen the target set.
+
+Return exactly one result for every task key in the Action input. Keep task results
+independent: one empty or failed result must not replace another task's proposal.
+
+Return only the minimal semantic JSON accepted by the current Route:
+
+```json
+{
+  "stage": "post-author",
+  "results": [
+    {
+      "task_key": "task-001",
+      "result": {
+        "stage": "post-author",
+        "outcome": "complete",
+        "proposals": [
+          {
+            "target": "target:1",
+            "artifact_kind": "content",
+            "title": "Reader-facing title",
+            "summary": "Why this derived page is useful",
+            "sections": [
+              {
+                "key": "overview",
+                "heading": "Overview",
+                "markdown": "Reader-facing content",
+                "source_refs": ["fact:1"]
+              }
+            ]
+          }
+        ],
+        "diagnostics": []
+      }
+    }
+  ]
+}
+```
+
+If a task needs no derived Artifact, return `outcome: "complete"` with an empty
+`proposals` array for that task. If one bounded input cannot be processed, return
+`outcome: "failed"` with at least one diagnostic for that task and still return the
+other task results. Context expands aliases, validates evidence and policy, creates
+internal fragments and digests, then resumes the same production state machine.

package/docs/document-optimization.md

@@ -1,82 +0,0 @@
-# Document revisions
-
-New workspaces enable source-constrained editorial revision by default. It is a
-build phase for source-backed prose that improves publication value and
-readability without changing the approved knowledge page or inventing facts.
-
-To opt out during initialization:
-
-```bash
-context init context --no-optimize-docs
-```
-
-Existing workspaces retain their current setting. Change it explicitly with:
-
-```bash
-context optimize-docs enable
-context optimize-docs disable
-context status --format json
-```
-
-When enabled, the workflow plans only new or changed source Sections. For each
-Section the CLI reports mechanical signals and allowed actions. The Agent may
-keep it, repair local presentation, reshape it within the same source boundary,
-or omit it when the CLI confirms a non-knowledge reason. Only changed pages
-receive a full revision beside their approved page:
-
-Signals are review leads rather than a complete readability verdict. The Agent
-must read every Section. Keeping a signaled Section requires a concrete,
-decision-only assessment explaining why each signal is a false positive or why
-editing would reduce source fidelity. The assessment names every reported
-signal code so the CLI can verify complete coverage; it is never published.
-Time, cost, workload, batch size, or delivery pressure are not valid keep or
-defer reasons. Fully managed operation applies all safe repairs, reshapes, and
-eligible omissions autonomously; only genuinely unavailable semantic input is
-batched for the user. A large fragment set must meet the same quality standard
-as a single fragment.
-
-```text
-knowledge/guides/setup.md
-knowledge/guides/setup__revision.md
-```
-
-The `__revision.md` suffix is reserved. Default knowledge discovery, structure,
-search, and package selection exclude revision files. Validation and build
-associate a revision with its sibling base page and apply it under the original
-package path. A revision stores only the base digest that cannot be inferred;
-its path and revised Sections are derived. Unchanged Sections inside a full
-revision are inferred. A page with no changes stores only one derived negative
-cache key below `.tmp/context-runtime/document-optimization/`; replacement
-prose and Section metadata are not duplicated there.
-
-Typical repair candidates are Markdown syntax, spacing, empty table rows, and
-descriptive labels for links whose purpose is already present. Reshape handles
-wide tables, long cells, mixed images and links, or long prose by creating a
-clearer structure inside the same Section. Unanswered question sets, empty
-placeholders, decision-free drafts, duplicates, and obsolete-only Sections may
-be omitted. Questions with answers, limitations with an action, and
-deprecations with a replacement remain knowledge. Link targets, images, code,
-commands, numbers, identifiers, conditions, and source references are protected
-through validation. Ambiguous currency, ownership, or sensitive values appear
-together in the plan's `input_requests` and require one batched user decision.
-
-After capture, review, or build, a user may ask conversationally to correct one
-existing knowledge page. Start the correction by title, approved path, or
-ViewRef:
-
-```bash
-context revise "<title, approved path, or ViewRef>" --format json
-```
-
-Context starts `route.document-revision.requested` only after resolving one
-page. Ambiguous requests return candidates instead of guessing. Edit
-reader-visible prose within existing `context:section` boundaries without
-changing provenance or protected values, then run `context optimize-docs
-validate`. A valid correction ends
-the request and the next Route offers a package build when output is stale. If
-broad document optimization was disabled, this entry activates only the target
-page and keeps every other eligible page out of the pending batch. If upstream
-content changes, the revision becomes a conflict and must be reviewed again.
-
-Disabling moves active revision pages to Context runtime recovery storage. The
-next build uses approved knowledge directly.