@c4a/context-cli 0.6.1 → 0.6.3

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

@@ -0,0 +1,48 @@
+---
+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.
+
+To retire a registered source, first run `context source remove <source-id>
+--format json`. This is a read-only preview that lists every project, candidate,
+or approved-knowledge reference. Only after those references are intentionally
+resolved may the route use `--yes`; the CLI never silently deletes referenced
+knowledge or another source's materialized files. Execute the exact
+digest-bound command returned by the preview. For a shared document batch, the
+manifest entry is the ownership boundary: removal deletes only that entry and
+its explicitly listed files/assets. An uncaptured module has no manifest entry,
+so removal is registry-only; the shared date directory is never inferred as
+module-owned.
+
+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,10 +46,37 @@ 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.
 
+Lark capture obtains the structured XML representation and produces two
+separate artifacts: XML audit evidence and a deterministic readable Markdown
+projection. Do not treat raw XML as Markdown and do not rewrite it yourself.
+The CLI also materializes supported embedded resources and returns a closed
+`resource_materialization` report. Required images, attachments, Sheets, Bases,
+whiteboards, diagrams, and synced blocks must be materialized before downstream
+Review. Polls and navigation references remain explicit non-interactive
+projections; video is reference-only unless the project SDK opts into bundling.
+If the remote API explicitly confirms that a referenced whiteboard or diagram
+no longer exists, preserve the unresolved placeholder and the structured
+`document.resource.source-missing` warning, then continue through the Route.
+This is an audited source-side deletion, not successful materialization. Access,
+network, parameter, and unknown resource failures still block downstream work.
+Do not manually download resources or patch links. Approved resources move to
+`knowledge/assets/`, and package build projects selected resources to
+`others/assets/`.
+Inspect `evidence_status` and `projection_status` separately. An evidence error
+means the source body, external content, or a stable resource locator could not
+be preserved, so the workflow must not proceed to Align, Compile, or Review.
+A projection warning or `generic` status means the original XML is preserved
+and a deterministic non-interactive Markdown fallback was emitted; report the
+diagnostic, but continue through the Route. The CLI, not the plugin, parses the
+document. The plugin only displays the structured counts and diagnostics
+returned by the current source resource. Do not patch the CLI or edit snapshots
+to add a renderer from a user workspace.
+
 ### Code capture diagnostics
 
 Do not run hand-written dependency preflight commands before code extraction or
@@ -98,8 +130,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 +144,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,31 @@
+---
+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.
+
+When every blocking finding is an approved document `source_ref` drift or an
+unresolved required-resource placeholder, and each affected source already has
+a declared pending structure target, the current prose align/compile round is
+the repair path. Continue that Route before running verification again. This
+exception does not apply to missing sources, malformed approved knowledge,
+unrelated verification errors, or findings without a matching pending target.
+
+When a complete replacement candidate batch is ready for Review, stable prose
+candidate ids may intentionally match their currently approved pages. Review
+that batch before deterministic close and final verification; the pending
+replacement is not an approved-identity conflict.
+
+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/claude/skills/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
@@ -32,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/{plugins/claude/skills/skill-prose-align/references/internal-procedures/structure-planning/references → providers/context/resources/semantic/align}/density-profile.md

@@ -1,4 +1,15 @@
+---
+id: context.semantic.align.density-profile
+kind: procedure
+media-type: text/markdown
+applies-to:
+  - coverage
+  - reading_density
+  - structure
+---
+
 # Evidence Density Selection
+<!-- Context workflow semantic resource. -->
 
 Use density as a private reading and section-planning strategy. It is not a
 separate payload, not a quality score, and not a workflow stage. Persist only

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

@@ -1,4 +1,17 @@
+---
+id: context.semantic.align.align-gates
+kind: procedure
+media-type: text/markdown
+applies-to:
+  - node_type
+  - domain
+  - action
+  - edges
+  - tags
+---
+
 # Node Classification Gates
+<!-- Context workflow semantic resource. -->
 
 Use these gates before every structure draft and before authoring the align
 payload described by the current schema view.

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

@@ -1,4 +1,15 @@
 ---
+context_resource: semantic/align/structure-planning
+id: context.semantic.align.structure-planning
+kind: procedure
+media-type: text/markdown
+applies-to:
+  - node_type
+  - title
+  - tags
+  - ownership
+  - edges
+  - structure
 name: structure-planning
 description: "Internal procedure for the current align gate. Reads CLI-guided align evidence, applies semantic Node classification gates, and emits context.structure.v1 payloads for CLI validation/stage."
 ---
@@ -7,7 +18,7 @@ description: "Internal procedure for the current align gate. Reads CLI-guided al
 
 ## TL;DR
 
-Run `context run align:<type>:<source>:<collection> --view read-plan --format json`, follow the top-level `next_action.command` to read the CLI-selected evidence path, produce a `context.structure.v1` structure payload, and continue following top-level `next_action`. The CLI owns route, validation, repair commands, and stage guards; this skill owns only semantic classification and source-bound structure judgment.
+Run `context run align:<type>:<source>:<collection> --view read-plan --format json`, follow the top-level `next_action.command` to read the CLI-selected evidence path, produce a `context.structure.v1` structure payload, and continue following top-level `next_action`. The CLI owns route, validation, repair commands, and stage guards; the Agent owns only semantic classification and source-bound structure judgment.
 
 <reference>
 
@@ -23,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
@@ -44,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`.
@@ -80,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.
@@ -96,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.
 
@@ -196,6 +223,11 @@ snapshot hash. Section identities are part of the structure gate: choose stable
 section ids such as `overview`, `behavior`, `constraints`, or a source-backed
 domain-specific name when the evidence supports it.
 
+For an independent collection entry, omit `containment`; the CLI derives
+`<collection>/<slug>.md`. Set `containment` only when the confirmed structure
+intentionally places the View under a parent path. Do not add a source/module
+wrapper merely to make every page use the same directory depth.
+
 Use only CLI-provided `source_refs[]` for section and edge evidence. Continuity
 is a per-Section constraint, not a per-View constraint: one View may contain
 many independently retrievable Sections, each with its own continuous mirror.
@@ -218,7 +250,8 @@ otherwise repair source refs from CLI evidence views or move unsupported
 material to `unresolved[]`.
 
 For pure suggested-split repairs, prefer the CLI repair view before hand-editing:
-`context run align:<type>:<source>:<collection> --repair suggested-splits --input <structure.yaml> --format json`.
+Deterministic source-boundary repairs are applied internally by validate/stage
+and are not a separate Agent command.
 It splits non-contiguous Section mirrors and can expand a broad cross-heading
 Section into Markdown structural groups within the same View. Apply the
 non-blocking repair hint when the groups should be independently retrievable;
@@ -252,14 +285,31 @@ mention without a dependency predicate. `edges[].source_refs[]` must include the
 source ref that states the dependency; if the relationship matters but evidence
 is missing, leave the edge unresolved instead of guessing.
 
-Prefer the strongest source-backed `section_kind` using the current schema's `section_kind_priority` and `section_kind_triggers`; avoid planning an entire dense source as `description` when the evidence clearly contains fenced examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Use `example` for fenced command/config/code or literal sample blocks, not ordinary scenario prose. Use `incident` only for dated or timestamped failure evidence with impact scope plus root cause, mitigation, or handling record. Use `decision` only when the source surfaces two or more alternatives or options plus the chosen path and rationale. Treat kind precision as a drafting quality preference, not a reason to block an otherwise source-backed write. Keep only raw-backed semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
+Prefer the strongest source-backed `section_kind` using the current schema's
+`section_kind_priority` and the semantic rules below; avoid planning an entire
+dense source as `description` when the evidence clearly contains fenced
+examples, comparison tables, Q&A, decisions, specs, warnings, or principles.
+Use `example` for fenced command/config/code or literal sample blocks, not
+ordinary scenario prose. Use `comparison` for two or more subjects compared
+across two or more dimensions. Use `faq` for a question-and-answer pair. Use
+`incident` only for dated or timestamped failure evidence with impact scope
+plus root cause, mitigation, or handling record. Use `changelog` for a
+versioned or dated change record. Use `decision` only when the source surfaces
+two or more alternatives or options plus the chosen path and rationale. Use
+`spec` for a verifiable rule, threshold, requirement, constraint, or checkable
+target; `warning` for an explicit caveat, risk, hazard, or limitation;
+`principle` for a stable invariant, design rule, or core mechanism without a
+check method; and `description` only as the narrative fallback. Treat kind
+precision as a drafting quality preference, not a reason to block an otherwise
+source-backed write. Keep only raw-backed semantic decisions in the payload;
+leave mechanical repair and patch routing to CLI diagnostics.
 
 There is no parallel candidate-body authoring path. Emit only the
 `context.structure.v1` payload accepted by the current schema view.
 
 ### Step 6 — Validate And Submit
 
-Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns `repair_confirmation_blockers`, follow its repair route and rerun validate without asking for preliminary approval. `--repair suggested-splits` handles non-contiguous source mirror Sections. For oversized Views, apply the returned child-View and contains-edge suggestions while classifying child Nodes from evidence. Resolve other blockers from evidence; ask the user only when evidence supports multiple incompatible semantic choices, and state that this is not final review. Stage only after `confirmation_ready=true`. The stage result opens the final HTML report and is the human review gate: show the structure to the user through `structure_report.file_url`, `structure_report.absolute_path`, and the compact summary before asking for confirmation. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
+Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. The CLI applies deterministic boundary repairs internally and returns only remaining blockers. For oversized Views, apply the returned child-View and contains-edge suggestions while classifying child Nodes from evidence. Resolve other blockers from evidence; ask the user only when evidence supports multiple incompatible semantic choices. Stage only after validation state is `ready`. The stage result opens the final HTML report for the Route-selected structure-confirmation gate. Execute the revision-bound confirmation command returned by `workflow.current`; managed session authority may resolve that gate without another question.
 
 After stage succeeds, do not rerun the same write command to confirm success.
 Use `context status --format json` or the returned result for read-only
@@ -277,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/resources/semantic/compile/index.md

@@ -0,0 +1,31 @@
+---
+context_resource: semantic/compile/index
+id: context.semantic.compile.index
+kind: procedure
+media-type: text/markdown
+applies-to:
+  - diagnostic-routing
+  - evidence-repair
+name: compile-reference-index
+description: "Optional index for non-mechanical structure and evidence diagnostics; normal compile does not require it."
+---
+
+# Compile semantic reference index
+
+Normal source-bound compile is deterministic and does not require these
+references. Read this index only when a structure or evidence diagnostic asks
+for a non-mechanical decision, then open only the matching procedure:
+
+- [Compile action contract](compile-actions.md)
+- [Action and domain gates](action-domain-gates.md)
+- [Notes and caveats](notes.md)
+- [Refresh and update](refresh-and-update.md)
+- [Structural challenges](structural-challenges.md)
+- [Compile judgment](compile-judgment.md)
+- [Semantic judgment](semantic-judgment.md)
+- [Disposition semantics](disposition-semantics.md)
+- [Temporal evidence](temporal-and-evidence.md)
+- [Leakage and ownership](leakage-and-ownership.md)
+- [Scope review and omission](scope-review-and-omit.md)
+- [User confirmation](user-confirmation.md)
+- [Close gate](close-gate.md)

package/providers/context/resources/views/package-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.package-current
+kind: context-view
+mediaType: text/markdown
+description: Current package declarations, freshness, and output counts.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/review-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.review-current
+kind: context-view
+mediaType: text/markdown
+description: Current complete review scope and candidate-set identity.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/source-boundary.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.source-boundary
+kind: context-view
+mediaType: text/markdown
+description: Stable registered source identities and boundaries without lifecycle progress.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/source-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.source-current
+kind: context-view
+mediaType: text/markdown
+description: Current repository and document source readiness and pending capture or extraction targets.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/structure-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.structure-current
+kind: context-view
+mediaType: text/markdown
+description: Current multi-document structure slots, declarations, and compile batch.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/verification-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.verification-current
+kind: context-view
+mediaType: text/markdown
+description: Current verification, evidence, and deterministic close diagnostics.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/workspace-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.workspace-current
+kind: context-view
+mediaType: text/markdown
+description: Current workspace counts, route, diagnostics, and declared lifecycle coverage.
+materializer: actions/materialize-context-view.yaml

package/providers/context/schemas/evidence-maintenance-input.schema.json

@@ -0,0 +1,30 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.evidence-maintenance.v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema", "decisions"],
+  "properties": {
+    "schema": {
+      "const": "context.evidence-maintenance.v1"
+    },
+    "decisions": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["view_ref", "action"],
+        "properties": {
+          "view_ref": {
+            "type": "string",
+            "minLength": 1
+          },
+          "action": {
+            "enum": ["re-pin", "deprecate", "keep-orphaned"]
+          }
+        }
+      }
+    }
+  }
+}

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."
+          }
+        }
+      }
+    }
+  }
+}

package/providers/context/schemas/repository-source-recovery.schema.json

@@ -0,0 +1,40 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.repository-source-recovery.v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema", "repositories"],
+  "properties": {
+    "schema": {
+      "const": "context.repository-source-recovery.v1"
+    },
+    "repositories": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "oneOf": [
+          {
+            "type": "object",
+            "additionalProperties": false,
+            "required": ["source", "mode", "path"],
+            "properties": {
+              "source": { "type": "string", "minLength": 1 },
+              "mode": { "const": "local" },
+              "path": { "type": "string", "minLength": 1 }
+            }
+          },
+          {
+            "type": "object",
+            "additionalProperties": false,
+            "required": ["source", "mode"],
+            "properties": {
+              "source": { "type": "string", "minLength": 1 },
+              "mode": { "const": "clone" },
+              "path": { "type": "string", "minLength": 1 }
+            }
+          }
+        ]
+      }
+    }
+  }
+}