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

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

@@ -13,8 +13,10 @@ 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.
+Read every Route-selected `context.source-body/*` resource in full. Index and
+heading metadata support navigation but are not evidence that the document
+body was read.
 
 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

@@ -18,4 +18,3 @@ the resulting evidence state must stay explicit.
 
 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

@@ -22,4 +22,3 @@ 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

@@ -11,21 +11,27 @@ 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
+resource. The current Route's `configuration.contract` lists the supported
+output choices, required fields, mechanical defaults, and follow-up status
+command; do not infer another factory or hidden default. 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.
+Generated generic templates carry a mechanical digest marker. Before the first
+build, replace or edit the declared template source, or explicitly accept the
+unchanged generic default through the current Route. Editing the template
+changes its digest and resolves the review without a separate command.
+Acceptance records only that decision; Context does not judge template prose
+or infer audience, scope, or navigation semantics.
 
-Ask separately whether the author wants a short optional Skill prefix. If so,
+An Agent knowledge-base package writes flat package-relative roots such as
+`wikis/`, `guides/`, `rules/`, and `feats/`. The package name already provides
+the surrounding `dist/<package-name>/` boundary. Do not ask the user for a
+distribution namespace or add `distribution.knowledgeNamespace` to a new
+declaration.
+
+Ask 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.
+`skills/android-query/`. Package-root layout never renames 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

@@ -19,4 +19,3 @@ declaration requested by the route in `src/index.ts`.
 
 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

@@ -14,10 +14,55 @@ 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.
 
+The default `read-plan` is the authoring packet for ordinary documents. It
+includes the payload contract, a compact canonical source-ref map, exact source
+body resources, the recommended scratch path, and the direct stage command.
+Do not separately request `schema`, `source-index`, or `existing-knowledge`
+unless the packet reports truncation or the task specifically needs an existing
+approved identity. Those views are diagnostics and large-source fallbacks, not
+mandatory workflow steps.
+
+Every `context.source-body/*` item selected in `workflow.current.resources`
+is source evidence, not supporting metadata. Read the complete Markdown file
+when its `read_state` is `read-required`. A source index, heading tree, token
+count, or successful capture never substitutes for body reading. A matching
+content digest receipt may be reused only while that text remains available in
+the current conversation. After reading every selected direct path, execute the
+single `resources.after_read.command`. For a generated Context View, execute
+its materialization command, read its complete file, then execute its exact
+`next_action.command`. Context carries the merged receipt file forward. A Route
+revision change does not invalidate unchanged bytes, but every lifecycle
+command remains revision-bound.
+
+When the route returns `payload_target`, write the Agent-authored structure input
+to its recommended `.tmp/agent-payloads/` path. This scratch area is separate
+from CLI-owned `.tmp/context-runtime/` and can be discarded after a successful
+stage. The recommendation does not restrict an explicit user-selected path.
+
 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.
 
+When the current Route exposes `batch`, author every listed target payload in
+one Agent planning pass, then write the small batch manifest to `batch.input`.
+Use `batch.validate.command` for a read-only all-target check or
+`batch.stage.command` to validate every target before any stage begins and then
+write the ready slots serially. The manifest contains only each `phase_id` and
+its structure payload `input` path; it does not merge document semantics or let
+the CLI choose page structure. A failed preflight writes no slot. If a later
+filesystem write fails, the result identifies completed slots and the Route
+remains recoverable.
+
+`--stage` performs the same validation and deterministic self-repair as
+`--validate`; use the separate validation command only for a diagnostics-only
+pass. In a managed conversation, a valid stage also records structure
+confirmation in the same write. Validation states are literal: `ready` may
+stage, `repair-required` may not, and `invalid` contains errors. `valid` is true
+only for `ready`; `error_free` distinguishes a blocker-only result from one
+containing errors. `self_healed` reports the input and output Section counts,
+how many original Sections were split, and the structural reason codes used by
+the repair.
+
 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/verify-and-repair.md

@@ -17,4 +17,3 @@ 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/providers/context/resources/semantic/align/candidate-resolution.md

@@ -45,8 +45,10 @@ Known anomaly kinds:
 Use stable `node_ref`, `view_ref`, and `section_ref` values from the current
 `context.structure.v1` payload for in-payload references. A NodeRef should be
 safe, lower-case, and path-shaped, such as `entity/rspack` or
-`domain/build-tooling`. `slug` and `path` are derived fields in the current
-flow; do not invent alternate reference aliases.
+`domain/build-tooling`. `slug` is the required stable filename choice for a
+View. `path` is derived from collection, optional containment, and slug; omit
+it or use the exact CLI-derived value. Do not invent alternate reference
+aliases.
 
 When an edge or section points at knowledge:
 

package/providers/context/resources/semantic/align/structure-planning.md

@@ -34,9 +34,9 @@ Run `context run align:<type>:<source>:<collection> --view read-plan --format js
 - Schema names and enum values come from
   `context run align:<type>:<source>:<collection> --view schema --format json`. Use
   that schema as the authoring contract for `context.structure.v1`.
-- Existing approved knowledge and `knowledge/structure.yaml` are the lookup
-  registry exposed through current CLI/status/query views. Do not read
-  `knowledge/**` or create a separate registry file.
+- Existing approved knowledge is the lookup registry exposed by the current
+  align `existing-knowledge` View. Do not read `knowledge/**`, guess a top-level
+  query command, or create a separate registry file.
 - Code projection Nodes are reusable knowledge handles. When document evidence belongs on a code symbol, reuse the code slug instead of creating a parallel document Node.
 - Validation diagnostics are the mechanical structure ownership source of
   truth. Non-content spans such as navigation references, placeholders, front
@@ -55,7 +55,10 @@ Run `context run align:<type>:<source>:<collection> --view read-plan --format js
   placeholder/relation source is skipped entirely, leave its relation clues in
   `unresolved[]` only when they still matter; otherwise omit them.
 - `views[]` and diagnostics distinguish citable evidence from supporting context. Do not promote supporting/context-only material into cited Sections unless a later ownership correction makes it citation-eligible.
-- Keep cache-friendly prompt order: fixed protocol/schema first, existing knowledge lookup second, source evidence views third, current semantic payload last. Preserve CLI JSON order and do not add timestamps, random ids, scratch paths, or host paths to generated payloads.
+- Keep cache-friendly prompt order: fixed protocol/schema first, source evidence
+  views second, targeted existing-knowledge results third, and the current
+  semantic payload last. Preserve CLI JSON order and do not add timestamps,
+  random ids, scratch paths, or host paths to generated payloads.
 - Structure digests and snapshot hashes are stale guards. Follow returned
   `next_action.command` and do not invent digest values.
 - Node type, tag, fake-Entity, `domain`, and `action` gates are in `structure-planning/references/gates.md`.
@@ -91,8 +94,9 @@ or `next_command`.
 
 `read-plan` is the navigation surface. It chooses whether the next evidence read
 is `source-index`, `span-detail`, `span-text`, or another current evidence view.
-Read those views and then author the requested
-`context.structure.v1` payload yourself. Never pipe evidence text into validate.
+Read those views and then author the requested `context.structure.v1` payload
+yourself after completing the targeted lookup in Step 3. Never pipe evidence
+text into validate.
 
 If an evidence view is truncated, `page.has_more: true`, or the CLI returns a
 `next_command`, run that command before authoring.
@@ -107,7 +111,19 @@ is explicitly needed, otherwise return to the CLI-designated navigation view.
 
 ### Step 3 — Reuse Existing Knowledge
 
-Query existing knowledge for reusable names before proposing new term/service/system/action Nodes. Exact title/slug/alias hits should usually become references to the existing Node, not duplicate candidates.
+After source evidence identifies a candidate title or stable ref, run:
+
+```bash
+context run align:<type>:<source>:<collection> --view existing-knowledge --query <title-or-stable-ref> --format json
+```
+
+Use the returned pagination command when present. Exact title, NodeRef, or
+ViewRef hits should usually reuse the existing Node instead of creating a
+duplicate candidate. The lookup returns only the best title/NodeRef/ViewRef
+identity tier. Shared tag matches are summarized separately and never require
+walking the related subgraph merely to determine whether a root identity
+exists. The lookup is deterministic identity discovery; the Agent still
+decides whether the source evidence describes the same concept.
 
 When a code projection Node already represents the object, reuse its slug for prose evidence and plan only prose-owned Sections for the current source evidence.
 
@@ -311,6 +327,6 @@ editing CLI-managed files.
 - [ ] Node classification used the semantic gates in `structure-planning/references/gates.md`. If not, return to **Step 4**.
 - [ ] URL/reference ownership followed CLI diagnostics, not static prompt rules. If not, return to **Step 5**.
 - [ ] The requested align payload passed `context run align:<type>:<source>:<collection> --validate --input - --format json` before stage. If not, return to **Step 6**.
-- [ ] No `sources/`, `unapproved/`, `knowledge/`, `dist/`, `.tmp`, host tool-results, or CLI-managed files were read or written with generic tools. If violated, restart from **Step 1**.
+- [ ] No `sources/`, `knowledge/`, `dist/`, `.tmp`, host tool-results, or CLI-managed files were read or written with generic tools. If violated, restart from **Step 1**.
 
 </procedures>

package/providers/context/schemas/prose-structure-batch.schema.json

@@ -0,0 +1,35 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.prose.structure-batch.v1",
+  "title": "Context prose structure batch",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema", "items"],
+  "properties": {
+    "schema": {
+      "const": "context.prose.structure-batch.v1"
+    },
+    "items": {
+      "type": "array",
+      "minItems": 1,
+      "maxItems": 100,
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["phase_id", "input"],
+        "properties": {
+          "phase_id": {
+            "type": "string",
+            "minLength": 1,
+            "description": "One declared phase.align.prose id from the current pending structure targets."
+          },
+          "input": {
+            "type": "string",
+            "minLength": 1,
+            "description": "Project-relative or absolute YAML/JSON context.structure.v1 payload path for this target."
+          }
+        }
+      }
+    }
+  }
+}