@c4a/context-cli 0.5.29-alpha.2 → 0.5.29-beta.17

package/plugin/commands/compile.md

@@ -1,76 +1,96 @@
 ---
-description: "Compile the confirmed align plan into knowledge articles: draft, semantic reconciliation, apply, then compile-close."
+description: "Compile the confirmed align plan into knowledge articles: draft, semantic reconciliation, apply, then close."
 argument-hint: "[--plan]"
-allowed-tools: Read, Bash(context:*)
+allowed-tools: Bash(context:*)
 ---
 
 <!--
 This command is slightly over the 30-line default because it carries
 the default-mode vs `--plan`-mode comparison inline; the mode contrast
 belongs here rather than split across skill references.
-The agent protocol itself still delegates to the compile-draft /
-compile-close skills.
+The agent protocol itself still delegates to internal packaged procedures.
 -->
 
 ## Your task
 
-Synthesise the align plan into the workspace `knowledge/` directory. The agent produces compile draft JSON per Node; the CLI writes everything. Workspace reads go through `context workspace`; workflow writes go through `context compile` / `context mdrive`, never through direct file tools.
+Synthesise the finalized align plan into knowledge through semantic CLI operations. The agent produces compile draft JSON per Node; the CLI owns storage, rendering, verification, and workflow payload persistence. Read workflow payloads with `context workflow show`; write through `context compile`, `context reconcile`, and `context mdrive` operations, never through direct workspace file tools.
+
+Naming convention:
+
+- `/context:*` names user slash commands.
+- `context ...` names CLI primitives.
+- Internal packaged procedures invoked by slash workflows are not user slash commands. Do not invent extra slash-command entrypoints for draft or close stages.
 
 Modes:
 
 - **Default (no flag)** — draft plan + semantic reconciliation + apply writes + close.
-- **`--plan`** (opt-in when `$ARGUMENTS` contains `--plan`) — per Node, run `context compile --draft <slug> --input <file> --plan` so the CLI validates without touching `knowledge/`; surface a user-facing change list (new knowledge, replaced knowledge, unchanged knowledge, and why) while keeping internal Section ids / source refs in details only when needed, then **stop at the end of the per-Node loop — do NOT run close**. The user re-runs `/context:compile` without `--plan` to apply; that run does the real writes + close.
+- **`--plan`** (opt-in when `$ARGUMENTS` contains `--plan`) — per Node, run `context compile --draft <slug> --input - --plan` so the CLI validates stdin draft content without writing active knowledge; surface a user-facing change list (new knowledge, replaced knowledge, unchanged knowledge, and why) while keeping internal Section ids / source refs in details only when needed, then **stop at the end of the per-Node loop — do NOT run close**. The user re-runs `/context:compile` without `--plan` to apply; that run does the real writes + close.
 
-Language policy: your explanatory prose and final reports follow the user's conversation language. CLI stdout/stderr, the canonical `processing <slug>` lines, paths, slugs, source refs, issue codes, flags, and command names stay as printed.
+Language policy: your explanatory prose and final reports follow the user's conversation language. Knowledge drafts, Section `content` / `detail`, and Node-facing summaries follow `NodeContext.generation_policy.language` when the CLI provides it; preserve product names, code identifiers, CLI flags, slugs, `source_ref` tokens, and exact quoted evidence as printed. CLI stdout/stderr, the canonical `processing <slug>` lines, paths, slugs, source refs, issue codes, flags, and command names stay as printed.
+
+Stable prompt/output policy: keep fixed protocol, schema, mount matrix, and workspace lookup context before per-Node payloads. For repeated Nodes, use the same command order and consume CLI JSON as-is. Do not add current timestamps, random ids, storage paths, or host absolute paths to draft payloads or reports unless the CLI explicitly returned them as semantic workspace facts.
 
 Preflight:
 
-1. Run `context workspace locate --format json` and use `ctxDir` from that JSON as `WORKSPACE_DIR`. In embedded layout it is the `.context/` directory; in root layout it is the current knowledge repo root. Use `WORKSPACE_DIR/output/...` and `WORKSPACE_DIR/knowledge/...` below; do not assume `.context/...`.
-2. Require `output/align.md` + `output/bind.yaml`; check them with `context workspace list output --format json`. If missing, tell the user to run `/context:align` and stop.
-3. Run `context doctor`; output-align group must be green. Incremental cache group warnings are informational here; only output-align errors block compile. Run `context mdrive workspace stats --format json`, `context source list --format json`, and `context status --format json`; record the before counts and `STATUS.semantic.refreshed_source_pending_compile.source_ids[]`.
-4. Read `output/align.md` with `context workspace read output/align.md --format text`. Record Nodes in the order they appear in `frontmatter.nodes[]` — do NOT re-sort.
-5. Run `context compile --changes --format json` and parse the JSON as `COMPILE_WORKSET`.
-   - If `COMPILE_WORKSET.reason` is `no-changed-nodes` and there are no refreshed sources pending compile, report `no changed nodes`; stop before reading `compile-draft`, running any draft command, or running close.
+1. Run `context doctor`; output-align group must be green. If it reports missing aligned knowledge, tell the user to run `/context:align` and stop. Incremental cache group warnings are informational here; only output-align errors block compile.
+2. Run `context mdrive workspace stats --format json`, `context source list --format json`, and `context status --format json`; record the before counts and `STATUS.semantic.refreshed_source_pending_compile.source_ids[]`.
+3. Run `context compile --scan-changes --format json` and parse the JSON as `COMPILE_WORKSET`. `--scan-changes` is the only workset scan flag; `--plan` is reserved for draft validation.
+   - If `context workflow status --format json` has `current: null` but `last_published` is present, continue with `context compile --scan-changes`; the published finalized ownership is still the workspace structure truth. Use `context workflow list --format json` only when you need lineage/history diagnostics.
+   - Compile JSON may include `source_finalize`; use it as lineage for the finalized ownership that produced the current Node set and citation ownership.
+   - If `COMPILE_WORKSET.reason` is `no-changed-nodes` and there are no refreshed sources pending compile, report `no changed nodes`; stop before invoking the draft procedure, running any draft command, or running close.
    - If `COMPILE_WORKSET.status` is `unknown-input`, continue conservatively using the Nodes listed in `COMPILE_WORKSET.nodes`; keep the `unknown_inputs[]` reasons in the final report.
-   - Otherwise process only `COMPILE_WORKSET.nodes`, preserving the `frontmatter.nodes[]` order. Per-Node `processing <slug>` echoes must match this order.
+   - Otherwise process only `COMPILE_WORKSET.nodes`, preserving the CLI order. Per-Node `processing <slug>` echoes must match this order.
+
+Review input rule: normal compile flow passes the prepare payload by digest: `context reconcile review --prepare-digest <digest> --decisions - --view status`. Never pass prepare files or hand-edited review output to apply; once review writes a ready artifact for the current workflow scope, plain `context reconcile apply` consumes it.
 
-Review stdin rule: `context reconcile review` accepts at most one `-` input. If either the prepared context or the decisions document is passed through stdin, write the other payload to a temporary scratch file outside `WORKSPACE_DIR`, or reuse a durable CLI scratch file. Valid shapes are `context reconcile review --context - --decisions <scratch-file> --format json` or `context reconcile review --context <prepare-file> --decisions - --format json`; never pass `-` to both flags in the same command.
+Semantic decision schema discovery: run `context schema semantic-decisions` for JSON, or `context schema semantic-decisions --format yaml` for readable YAML. Do not infer it from memory, and do not hand-edit review output; once `context reconcile review` writes a ready review artifact for the current workflow scope, plain `context reconcile apply` consumes it without re-reading any decisions file.
+
+`source_ref` values are opaque citation tokens. Copy them from CLI payloads into draft/reconcile decisions exactly as printed; do not parse, normalize, or dereference them as file paths.
+
+Do not use Python, Node.js, shell, or other ad-hoc scripts to preprocess, filter, summarize, or inspect ReconcileContext / review payloads. Do not use `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect workspace storage or temporary workflow artifacts. Consume the structured output from `context reconcile prepare` and `context reconcile review` directly, and pass agent-authored draft/decision payloads through stdin rather than scratch files. Never extract `review.apply_document` manually; the CLI applies the ready review artifact stored under the current workflow scope.
 
 Refreshed-source loop:
 
 1. If `STATUS.semantic.refreshed_source_pending_compile.source_ids[]` is non-empty, process each source id before the per-Node draft loop.
-2. Run `context reconcile prepare --mode refresh --source <source-id> --format json`. Feed that JSON to `${CLAUDE_PLUGIN_ROOT}/skills/semantic-reconcile/SKILL.md`.
-3. Pass the skill output to `context reconcile review`, following the review stdin rule above: one input may be `-`, the other must be a scratch file. Resolve questions exactly like the per-Node loop.
-4. Default mode only: run `context reconcile apply --input <confirmed-decisions>`. In `--plan` mode, stop after review and report the not-written refresh decisions.
-5. After all refreshed sources are applied in default mode, run `context compile --changes --format json --ignore-source <source-id>` with one `--ignore-source` flag for each refresh-applied source. Use that filtered result for the per-Node loop. This does not rebuild section fingerprints early; it only removes Nodes whose remaining changed blocks came entirely from sources already handled by refresh reconciliation. If a Node still has changed blocks from other sources, unknown inputs, or full-context reasons, keep it in the ordinary per-Node loop.
+2. Run `context reconcile prepare --mode refresh --source <source-id> --format json`. Feed stdout to packaged `context:skill-semantic-reconcile`; the output includes `workflow_payload.digest` for review. Do not reconstruct the semantic decision shape from memory.
+   - The prepare output omits refresh sections whose evidence block hash is unchanged. If it returns a single `status: "unchanged"` / `change_status: "unchanged"` item, report that no semantic refresh decisions are needed for that source and continue with the filtered compile workset.
+3. Pass the skill output to `context reconcile review --prepare-digest <prepare-digest> --decisions - --view status`. Use stdout for readiness/issues/questions; apply reads the ready review artifact from the workflow scope. Resolve questions exactly like the per-Node loop, including `support_confirmation`, `scope_review_required`, and `omit_confirmation` handling.
+4. Default mode only: run plain `context reconcile apply` after `context reconcile review` returns `ready_to_apply: true`; the CLI loads the unique ready review for the current workflow scope. If questions were answered, rerun review on the updated decisions to refresh the ready artifact, then run `context reconcile apply` again. In `--plan` mode, stop after review and report the not-written refresh decisions.
+5. After all refreshed sources are applied in default mode, run `context compile --scan-changes --format json --ignore-source <source-id>` with one `--ignore-source` flag for each refresh-applied source. Use that filtered result for the per-Node loop. This does not rebuild section fingerprints early; it only removes Nodes whose remaining changed blocks came entirely from sources already handled by refresh reconciliation. If a Node still has changed blocks from other sources, unknown inputs, or full-context reasons, keep it in the ordinary per-Node loop.
 
 Per-Node loop:
 
-1. For every workset Node, run `context compile --context <slug> --changed-only --save-output`. If the refreshed-source loop applied any source, append the same `--ignore-source <source-id>` flags used for the filtered workset. Use the JSON stdout as the NodeContext for the draft skill. When the workset requires full context, the CLI returns `incremental.status: "full-context"` with the `unknown_inputs[]` reasons while still using the changed-only entrypoint. The CLI stores the durable context scratch copy under `output/`. Do not expand the context with direct file tools; the NodeContext is the evidence boundary.
-2. Read `${CLAUDE_PLUGIN_ROOT}/skills/compile-draft/SKILL.md` and follow its procedures; keep the emitted draft JSON/YAML in memory.
-3. Pass the draft to `context compile --draft <slug> --input - --save-input --plan`. This validates schema, source refs, and mount matrix without touching `knowledge/`. On CLI rejection, read the error verbatim, fix the draft via the skill's self-verify, and retry up to 3 times.
-4. Run `context reconcile prepare --mode compile --node <slug> --draft WORKSPACE_DIR/output/compile.<slug>.draft.yaml --format json`. Feed that JSON to `${CLAUDE_PLUGIN_ROOT}/skills/semantic-reconcile/SKILL.md`.
-5. Pass the skill output to `context reconcile review`, following the review stdin rule above: one input may be `-`, the other must be a scratch file. If questions are returned, ask the user in business language and convert unresolved `ask_user` items into final actions before applying.
-6. Default mode only: run `context reconcile apply --input <confirmed-decisions>`. This writes active knowledge, verifies, and records `decisions/semantic.yaml`. In `--plan` mode, stop after review and report the not-written decisions.
-7. Persistent failure → stop and surface the full rejection list; never edit rendered files to bypass.
+Process Nodes sequentially. `/context:compile` may cover a multi-Node workset, but each Node must finish its own `context → draft → prepare → review → apply` loop before you apply another Node. Do not run multiple Node draft/reconcile/apply chains in parallel or bury several Node failures inside one shell batch. Capture/align can be broad; compile write decisions must be per-Node and complete.
+
+1. For every workset Node, run `context compile --context <slug> --format json`. If the refreshed-source loop applied any source, append the same `--ignore-source <source-id>` flags used for the filtered workset. The JSON stdout is a compact summary with `node_context_payload.scope_id` and `node_context_payload.digest`. First inspect citation handles with `context workflow show --payload node-context --scope <scope-id> --digest <digest> --view source-refs --unwrap --format json` or `context compile --source-refs <slug> --format json`; only read the full durable NodeContext once when you are ready to pass its returned `.value` object to the draft skill. NodeContext is derived only from finalized ownership: `primary_evidence` and citation-eligible `shared_evidence` may be cited; `context_only` and every secondary shared snippet are background only and must not be cited. If NodeContext includes `generation_policy`, apply it to every generated title, summary, Section content/detail, and user-facing draft explanation; do not default to English scaffolding when the workspace language is not English. `context compile --context <slug> --request-full-text <block_id> --format json` may expose full text for inspection, but it does not promote secondary shared evidence into citation eligibility; if the block should support this Node, emit `pending_ownership_challenge` or `structure_challenge` instead of writing a Section. When the workset requires full context, the NodeContext payload has `incremental.status: "full-context"` with the `unknown_inputs[]` reasons from the same entrypoint. `incremental.locator_only_changes[]` entries with `agent_action: "none"` are close-time maintenance only; do not draft them. The CLI stores the durable NodeContext and coverage candidates as workflow payloads, not root scratch files. Do not expand the context with direct file tools; the NodeContext payload is the evidence boundary. Prefer citation-eligible refs for citeable evidence and treat `context_only` as background. Do not repeatedly slice saved NodeContext JSON manually; use the compact `source-refs`, `summary`, and coverage views returned by the CLI.
+2. Invoke packaged `context:skill-compile-draft` and follow its procedure to emit draft JSON. Do not reconstruct the draft shape from memory. Cite raw via `source_refs: [...]` chosen from `raw_snippets[].source_ref`; use a single-element array for one citation. The CLI rejects singular `source_ref` and quoted-evidence fields with canonical repair hints. If a note or changed raw snippet should be reviewed but intentionally not written, emit `op: "skip"` with the relevant `source_refs: [...]`; a bare skip is only for deterministic no-op cases. If a NodeContext contains only navigation or placeholder evidence (`Parent` / `Children` / `Related` / `Relations`, "no detailed content", etc.), emit `skip`; do not create a low-value `description` Section from that navigation line just to satisfy the workflow.
+3. Fast path: pass the draft to `context compile --node-cycle <slug> --input - --accept-safe-defaults --format json`. This validates the draft, prepares reconcile, reviews mechanically safe defaults, and applies only when no semantic judgment remains. If stdout returns `status: "applied"`, continue to the next Node. If it returns `status: "review-required"`, use the returned `prepare` / `review` handles and continue with the manual path below; do not rerun the earlier context/source-ref reads.
+4. Manual path: pass the draft to `context compile --draft <slug> --input - --plan --prepare --format json`. This validates schema, source refs, and mount matrix, stores the compile draft as a workflow payload, and prepares the semantic reconcile payload without writing active knowledge. Default stdout is a compact prepare summary; use it to inspect readiness and capture `workflow_payload.digest` / `scope_id`. If semantic judgment is needed, load the full prepare payload with `context workflow show --payload prepare --scope <scope-id> --digest <digest> --unwrap --format json` and feed that full payload to packaged `context:skill-semantic-reconcile`. For triage-only inspection, use `context workflow show --payload prepare --scope <scope-id> --digest <digest> --view issues --unwrap --format json`; add `--status unsupported`, `--status weak`, `--item-id <claim-id>`, or `--page-size <n>` instead of expanding huge prepare payloads. If all pending items are mechanically safe defaults, prefer `context reconcile review --prepare-digest <digest> --scope <scope-id> --accept-safe-defaults --view status` instead of invoking the skill. If most items are safe and only a few need explicit decisions, combine `--accept-safe-defaults` with `--decisions -` and submit only those explicit decisions. If the CLI returns draft revision hints, use `context compile --draft-status <slug> --format json` and `context compile --draft-patch <slug> --input - --payload-digest <digest> --plan` so only the affected action is revised, then rerun `context compile --draft ... --plan --prepare`. On hard rejection before a draft session exists, read the error verbatim, fix the draft via the skill's self-verify, and retry up to 3 times.
+5. Review the prepared context before accepting defaults. If it reports unsupported `source_support`, repair/split evidence before review; unsupported items cannot be accepted with `accept_default` or user confirmation. Treat `temporal_prior` and candidate `temporal_disposition` as context for your rationale only; they do not change `default_decision` or make merge/supersede mechanically safe. If the prepare output has `items: []`, use its `next_decisions_template` as the decisions document for review; do not pass the whole prepare context as `--decisions`.
+   - If `agent_hints[]` contains `compact-source-low-coverage` or `dense-source-low-coverage`, return to the same compile draft and add actions for the suggested uncovered evidence before semantic review. Treat the reported coverage count (`covered/total`, remaining snippets) as a required self-check, not polish. A supported first quote only proves that one action is valid; it does not prove the Node is complete.
+   - If close later reports `coverage-high-signal-unresolved` for a dense document and every unresolved candidate in that node-scoped payload is intentionally excluded for the same reason, use `context compile --coverage-skip-unresolved --coverage-disposition-node <slug> --payload-digest <digest> --reason "<reason>"` instead of hand-writing a long disposition JSON. Use targeted `coverage-disposition` only when candidates need different outcomes.
+6. Pass the skill output to `context reconcile review --prepare-digest <prepare-digest> --decisions - --view status`. Use stdout for compact readiness/issues/questions. If questions are returned, ask the user in business language and convert unresolved `ask_user` items into final actions before applying. For `support_confirmation`, use `question.group_key` when present: group only questions that share that key and are all ordinary summary/compression checks; ask once with a compact list of claims and cited evidence. If the user confirms the group, keep each final write action and add `decided_by: user`. Do not group questions that add new facts, have missing hard facts, or have different source/evidence boundaries. If review reports unsupported evidence, choose or split the draft `source_refs[]` so each action is independently supported (use `source_support.evidence_block_candidates` to pick prepared evidence blocks or split unrelated claims), then rerun review. For `scope_review_required`, run `context:skill-semantic-reconcile` once more over the prepare context and current decisions before asking the user; if it still cannot resolve the scope, ask the user. For `omit_confirmation`, ask the user; only a confirmed no-write answer may become `action: omit` with `decided_by: user`. Never mark `decided_by: user` on your own; auto mode or permission to continue is not user confirmation.
+7. Default mode only: run plain `context reconcile apply` after `context reconcile review --prepare-digest ... --view status` returns `ready_to_apply: true`; the CLI applies the unique ready review for the current workflow scope. If questions were answered, rerun review on the updated decisions, then run `context reconcile apply` again. This writes active knowledge, verifies, and records the semantic ledger. In `--plan` mode, stop after review and report the not-written decisions.
+8. Persistent failure → stop and surface the full rejection list; never edit rendered files to bypass.
 
 Close (default mode only — skip entirely in `--plan` mode):
 
-1. Read `${CLAUDE_PLUGIN_ROOT}/skills/compile-close/SKILL.md` and follow its procedures; it triggers `context compile --close`, which verifies the workspace, refreshes locator-only evidence, rebuilds section fingerprints, and refreshes the incremental cache.
+1. Invoke packaged `context:skill-compile-close`; it triggers `context compile --close`, which refreshes locator-only evidence, canonicalizes source refs, compacts derived knowledge files, verifies the final workspace, rebuilds section fingerprints, and refreshes the incremental cache.
 2. Run `context verify` as a second pass if the skill escalated any issue. Run `context mdrive workspace stats --format json` and `context source list --format json` and diff against the before counts.
-3. Run `context mdrive node list --format json` to collect generated knowledge file paths for the final report. Use each item's `filePath` for clickable markdown links. Also include `WORKSPACE_DIR/knowledge/_index.md` and `WORKSPACE_DIR/knowledge/changelog.md`.
+3. Run `context mdrive node list --format json` to collect semantic node handles for the final report. Use `node_class` to keep concrete entities, term definitions, domains, and actions visibly separated. If the user explicitly asks for file links, use an explicit human/report view when available; those links are user inspection aids, not workflow inputs.
 
-`context compile --close` archives `compile.*` scratch files under `WORKSPACE_DIR/output/archive/` and copies the consumed `align.md` + `bind.yaml` into that archive, while keeping the current `align.md` + `bind.yaml` at the output root for future recompile/status. Do not move, delete, or archive workspace `output/` files yourself; the CLI owns that lifecycle.
+`context compile --close` may archive explicit debug scratch files through the CLI-owned output lifecycle. Normal compile state lives in workflow-scoped payloads. Current align state is internal CLI state, not a file protocol. Do not move, delete, or archive workspace output files yourself; the CLI owns that lifecycle.
 
 In plan mode, your final report is the aggregated user-facing change list across all Nodes + "re-run `/context:compile` without `--plan` to apply"; do not run `context compile --close` or `context verify` (they only make sense against a real write).
 
-Never claim success unless `context compile --close` exited 0 and `context verify` is green. The only exception is the `no-changed-nodes` gate, where you report that compile stopped before draft and no files were written. Never hand-write anything under workspace `knowledge/`, `_index.md`, or `changelog.md` — the CLI is the sole writer.
-Never use Read / Glob / Grep / Write against `WORKSPACE_DIR`; use `context workspace`, `context compile`, and `context mdrive`.
-For large draft payloads, feed stdin directly into the `context compile` command with a heredoc. Do not pipe a heredoc through another command and do not redirect generated content into workspace files:
+Never claim success unless `context compile --close` exited 0 and `context verify` is green. The only exception is the `no-changed-nodes` gate, where you report that compile stopped before draft and no files were written. Never hand-write rendered knowledge, index, or changelog files — the CLI is the sole writer.
+Never use Read / Glob / Grep / Write against workspace storage; use `context workflow`, `context compile`, `context reconcile`, `context source`, `context query`, and `context mdrive`.
+For large draft payloads, feed stdin directly into the `context compile` command with a heredoc. Do not pipe a heredoc through another command and do not redirect generated content into workspace files. Do not pipe `context ... --format json` through `python3`, `node`, `jq`, `sed`, `cat`, `2>&1`, or shell fallback wrappers. For draft schema discovery, run `context schema compile-draft` for readable YAML or `context schema compile-draft --format json` for machine-readable JSON:
 
 ```bash
-context compile --draft billing-api --input - --save-input --plan <<'JSON'
+context compile --draft billing-api --input - --plan --prepare --format json <<'JSON'
 {
+  "schema_version": "compile.draft.v2",
   "target_node": "billing-api",
   "actions": [
     { "op": "skip", "reason": "no new evidence in changed snippets" }
@@ -79,15 +99,50 @@ context compile --draft billing-api --input - --save-input --plan <<'JSON'
 JSON
 ```
 
+For reviewed no-write material, keep the evidence in the skip action so semantic review can record it:
+
+```bash
+context compile --draft billing-api --input - --plan --prepare --format json <<'JSON'
+{
+  "schema_version": "compile.draft.v2",
+  "target_node": "billing-api",
+  "actions": [
+    {
+      "op": "skip",
+      "reason": "reviewed; intentionally not written",
+      "source_refs": ["src-1#reviewed-note L12-14@ab12cd34ef56"]
+    }
+  ]
+}
+JSON
+```
+
+For navigation-only or placeholder-only context, no active Section is the correct result:
+
+```bash
+context compile --draft billing-api --input - --plan --prepare --format json <<'JSON'
+{
+  "schema_version": "compile.draft.v2",
+  "target_node": "billing-api",
+  "actions": [
+    {
+      "op": "skip",
+      "reason": "navigation-only context; align graph already preserves parent/child/related structure"
+    }
+  ]
+}
+JSON
+```
+
 Final report contract (default mode):
 
 - Report in the user's conversation language.
 - Keep a stable structure with these semantic sections; translate section headings into the user's conversation language instead of copying these English labels verbatim:
   1. Completion headline.
-  2. Semantic apply table. Include refreshed-source rows first in source-id order when the refreshed-source loop ran, then one row per Node in align frontmatter order. Columns: target (source id or Node title/slug), type (`refresh` or Node type), and the `context reconcile apply --format json` counts: `applied`, `skipped`, `merged`, `superseded`, `kept_separate`, and `questions_resolved`. Include `reanchored`, `removed_unsupported`, and `split_then_reanchored` only when non-zero.
-  3. Close stage with `context compile --close` result, final node/section totals, verify status, changelog stamp, incremental counts (`recompiled`, `locator_updates`, `rebuilt`), section fingerprint rebuild count, and archive directory for compile scratch files when present. Do not use close output as the semantic apply summary; aggregate the per-Node `context reconcile apply` results from Step 6.
+  2. Semantic apply table. Include refreshed-source rows first in source-id order when the refreshed-source loop ran, then one row per Node in align frontmatter order. Columns: target (source id or Node title/slug), type (`refresh` or Node type), and the `context reconcile apply --format json` counts: `applied`, `skipped`, `merged`, `superseded`, `kept_separate`, `omitted`, and `questions_resolved`. Include `reanchored`, `removed_unsupported`, and `split_then_reanchored` only when non-zero.
+  3. Close stage with `context compile --close` result, final node/section totals, verify status, changelog stamp, incremental counts (`recompiled`, `locator_updates`, `canonical_source_ref_updates`, `rebuilt`), section fingerprint rebuild count, and archive status / archived file count when reported by CLI. Do not use close output as the semantic apply summary; aggregate the per-Node `context reconcile apply` results from Step 6.
   4. Before/after status diff table with at least total nodes, node counts by type, total sections, and last compile time.
-  5. Knowledge files as clickable markdown links. Use absolute path targets without `file://`, for example `[knowledge/entity/vmok.md](/abs/path/.context/knowledge/entity/vmok.md)`. Include `_index.md`, `changelog.md`, and every Node article returned by `context mdrive node list --format json`. Use the path relative to `WORKSPACE_DIR` as the link label.
+  5. Knowledge objects by semantic handle. Include every Node slug and `node_class` returned by `context mdrive node list --format json`; group or label term definitions separately from concrete entities when useful. Include human-readable links only when an explicit human/report view returns them, and state that they are not workflow inputs.
   6. Optional next step only when there is a concrete useful follow-up (for example recapture stale material or run `/context:align` to revise structure).
 - Do not say the user can inspect files without providing links.
 

package/plugin/commands/context.md

@@ -1,7 +1,7 @@
 ---
 description: "Fuzzy router for context operations. Inspect the argument and route to the correct /context:* subcommand."
 argument-hint: "<free text | url | source-id | question>"
-allowed-tools: Read, Bash(context:*)
+allowed-tools: Bash(context:*)
 ---
 
 ## Your task
@@ -10,14 +10,16 @@ Inspect `$ARGUMENTS` and delegate to the most appropriate subcommand. Route with
 
 Any prose you speak to the user (clarifying questions, "routing to …" notes) follows the user's conversation language. Sub-command names (`/context:capture`, `/context:compile`), flag names, and source-ids stay English.
 
+Naming convention: `/context:*` names user slash commands and `context ...` names CLI primitives. Internal packaged procedures are workflow-only; this router dispatches only slash commands and does not call packaged procedures directly.
+
 Routing rules (first match wins):
 
 1. **Empty arguments** → run `/context:status`.
 2. **Starts with `http://` or `https://`, or ends in `.md`** → `/context:capture $ARGUMENTS`.
 3. **Equals `--inbox` or `--refresh`** → `/context:capture $ARGUMENTS`.
 4. **Matches `init`, `initialize`, `new workspace`, or looks like a plain workspace name** → `/context:init $ARGUMENTS`.
-5. **Matches `capture-aspect` or a bare `aspect` keyword** → `/context:capture-aspect $ARGUMENTS`. This rule must sit BEFORE the `code` rule below, because `capture-aspect code` is a stub (exits non-zero with "planned for a future release") and must NOT silently fall through to `/context:capture-code`.
-6. **Mentions `code`, `extract`, or `capture-code`** → `/context:capture-code` (extract debug → `/context:extract`).
+5. **Mentions `code` or source-code capture** → `/context:capture --code $ARGUMENTS`.
+6. **Mentions `aspect` without a concrete supported capture flag** → ask one clarification; code aspect capture is exposed as `/context:capture --code`.
 7. **Matches `align`, `structure`, `plan`, `node tree`** → `/context:align $ARGUMENTS`.
 8. **Matches `compile`, `recompile`, `synthesize`, or `build knowledge`** → `/context:compile $ARGUMENTS`.
 9. **Matches `drop`, `retract`, `delete source`, or passes a known source-id pattern (`feishu:*` / `local:*` / `aspect:*` / `oncall:*` / `meeting:*`)** → `/context:drop $ARGUMENTS`.
@@ -26,5 +28,6 @@ Routing rules (first match wins):
 12. **Anything else** (likely a knowledge question) → `/context:query $ARGUMENTS`.
 
 If multiple rules apply, pick the most specific (URL beats word match). When in doubt, ask one clarifying question before dispatching.
-Never use Read / Glob / Grep / Write against `WORKSPACE_DIR`; plugin docs may be read via `${CLAUDE_PLUGIN_ROOT}`, but workspace content must go through `context` CLI commands.
+Never use Read / Glob / Grep / Write against `WORKSPACE_DIR`; route to packaged `/context:*` commands and skills instead of opening plugin or workspace files manually.
+Never use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect or preprocess `WORKSPACE_DIR`, `.context`, or `/tmp` workflow artifacts.
 Do not use `context workspace` search/read as this router's knowledge fallback; route likely knowledge questions to `/context:query` so the query skill owns retrieval and citations.

package/plugin/commands/drop.md

@@ -1,17 +1,25 @@
 ---
-description: "Drop a source: CLI plans cleanup, runs semantic reconciliation, then applies with decisions."
-argument-hint: "<source-id|raw-path|url> [--reason <text>] [--yes]"
-allowed-tools: Read, Bash(context:*)
+description: "Drop a source: CLI plans cleanup, reconciles affected Sections when needed, then applies safely."
+argument-hint: "<source-id|url> [--reason <text>] [--yes]"
+allowed-tools: Bash(context:*)
 ---
 
 ## Your task
 
 Retract a source without losing the audit trail. The CLI owns source resolution, impact planning, semantic decision application, knowledge cleanup, source stamp, changelog append, and verify; the agent presents the impact plan and waits for confirmation.
 
-Read `${CLAUDE_PLUGIN_ROOT}/skills/drop/SKILL.md` and follow its procedures end to end, including the self-verify checklist at the end.
+Naming convention:
 
-Parse `$ARGUMENTS` for `<source-id|raw-path|url>`, optional `--reason <text>`, and optional `--yes`. Source validation is done by `context drop --plan`; if absent or already `dropped`, relay the CLI's error and stop. If `--reason` is missing but the user gave a clear natural-language reason, infer a concise reason; otherwise ask for it before applying the plan. `--yes` skips the original drop impact confirmation only; it never skips semantic `ask_user` questions.
+- `/context:*` names user slash commands.
+- `context ...` names CLI primitives.
+- Internal packaged procedures invoked by slash workflows are not user slash commands.
+
+Use packaged `context:skill-drop` end to end, including the self-verify checklist at the end.
+
+Parse `$ARGUMENTS` for `<source-id|url>`, optional `--reason <text>`, and optional `--yes`. Source validation is done by `context drop --plan`; if absent or already `dropped`, relay the CLI's error and stop. If `--reason` is missing but the user gave a clear natural-language reason, infer a concise reason; otherwise ask for it before applying the plan. `--yes` skips the original drop impact confirmation only; it never skips semantic `ask_user` questions.
 
 Language policy: any prose you speak directly to the user follows the user's conversation language. CLI output, source-ids, command names, file paths, flags, and issue codes stay as printed.
 
-Never Read / Glob / Grep / Write workspace files directly. All workspace access goes through `context drop --plan`, `context reconcile prepare --mode drop`, `context reconcile review`, `context drop --apply-plan --decisions`, `context source`, `context workspace`, and other `context` CLI commands.
+Never Read / Glob / Grep / Write workspace files directly. All workspace access goes through semantic CLI commands such as `context drop --plan`, `context reconcile prepare --mode drop`, `context reconcile review`, `context drop --apply-plan`, and `context source`. If you need the semantic decision shape, run `context schema semantic-decisions` for JSON or `context schema semantic-decisions --format yaml` for readable YAML; do not infer it from memory.
+Never use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect or preprocess workspace storage or temporary workflow artifacts. Consume CLI JSON/YAML/text outputs directly. Do not pipe `context ... --format json` through `python3`, `node`, `jq`, `sed`, `cat`, `2>&1`, or shell fallback wrappers.
+Plan handoff is workflow-scoped. Run `context drop --plan <target> --format json`; the CLI stores the drop-plan payload in the current workflow. `--save-output` is only for an explicit human-readable scratch copy and must not be passed to later steps.

package/plugin/commands/extract.md

@@ -8,11 +8,11 @@ allowed-tools: Bash(context:*)
 
 Run `context extract $ARGUMENTS` and stream the CLI's stdout back to the user.
 
-- The command is **state-required**: it runs only from inside a directory tree that already contains an embedded `.context/` workspace or root-layout workspace. Outside a workspace the CLI exits with a workspace-not-found error — relay it and suggest `/context:init`, do not try to guess a workspace location.
+- The command is **state-required**: it runs only from inside an initialized context workspace. Outside a workspace the CLI exits with a workspace-not-found error — relay it and suggest `/context:init`, do not try to guess a workspace location.
 - It is strictly read-only — never writes into workspace files.
 - Default format is `json`; `--format jsonl` is line-delimited per entity; `--format pretty` is human-readable.
-- Useful for inspecting what `/context:capture-code` would capture without creating a bucket.
+- Useful for inspecting what `/context:capture --code` would capture without creating a bucket.
 
-If the user wants to persist the extraction as a raw snapshot, redirect them to `/context:capture-code`.
+If the user wants to persist the extraction as a raw snapshot, redirect them to `/context:capture --code`.
 
 Language policy: stream CLI stdout/stderr verbatim. Any explanation you add follows the user's conversation language; paths, JSON keys, command names, flags, and error tokens stay as printed.

package/plugin/commands/init.md

@@ -1,6 +1,6 @@
 ---
 description: "Initialize a context workspace in the current directory."
-argument-hint: "[name] [--layout embedded|root] [--language <text>] [--with-aspects <names>] [--with-all-aspects] [--minimal] [--focus <text>]"
+argument-hint: "[name] [--layout embedded|root] [--language <text>] [--with-aspects <names>] [--with-all-aspects] [--minimal|--no-aspects] [--focus <text>]"
 allowed-tools: Bash(context:*)
 ---
 
@@ -14,11 +14,13 @@ length exemption for self-contained slash commands.
 
 Initialize a context workspace, including layout, default-language, and focus confirmation before creating it.
 
+Language rule: ask every question, option label, option description, and final summary in the user's current conversation language. The English question blocks below are semantic templates, not text to copy unless the conversation itself is English. Keep CLI tokens, file paths, aspect names, and stored values such as `Chinese`, `English`, `embedded`, and `root` unchanged.
+
 ### Step 1 — Ask about workspace layout (unless `$ARGUMENTS` already has `--layout`)
 
 Use the host's native multi-choice tool when available (Claude Code `AskUserQuestion`, Codex `ask_user_question`, Cursor Plan Mode `AskQuestion`); fall back to markdown choices otherwise.
 
-Question shape. Do not expose `embedded` / `root` as user-facing option labels; those are CLI tokens only. User-facing option labels may be localized (for example, Chinese labels can be `默认（.context/）` and `当前目录`):
+Question shape. Do not expose `embedded` / `root` as user-facing option labels; those are CLI tokens only. Translate the user-facing labels and descriptions:
 
 ```
 Q. Where should C4A store this workspace?
@@ -26,7 +28,7 @@ Q. Where should C4A store this workspace?
   B. Current directory — use the current directory itself as the C4A data root.
 ```
 
-Explain the tradeoff before asking:
+Explain the tradeoff in the user's conversation language before asking:
 - Default (`.context/`) is for normal code repositories; C4A files live under `.context/`.
 - Current directory is only for a dedicated knowledge repository. The current directory must not already contain `.context/`, `config.yaml`, `raw/`, `knowledge/`, `output/`, `aspects/`, or `inbox/`. Existing `AGENTS.md` / `CLAUDE.md` in the selected C4A data root are kept rather than overwritten.
 
@@ -36,7 +38,7 @@ Map the answer to CLI flags:
 
 ### Step 2 — Ask about default language (unless `$ARGUMENTS` already has `--language`)
 
-Ask one multi-choice question:
+Ask one multi-choice question in the user's conversation language:
 
 ```
 Q. What default language should agents use for user-facing replies in this workspace?
@@ -45,13 +47,13 @@ Q. What default language should agents use for user-facing replies in this works
   C. Other — please describe.
 ```
 
-The option label may be localized (for example `中文`), but the stored CLI value should remain stable. Pass the answer as `--language "Chinese"`, `--language "English"`, or the user's custom text.
+The option label must be localized, but the stored CLI value should remain stable. Pass the answer as `--language "Chinese"`, `--language "English"`, or the user's custom text.
 
 ### Step 3 — Ask about workspace focus (unless user already passed `--focus`)
 
 Before running `context init`, ask the user **one** multi-choice question about the workspace's focus (the primary intent of this knowledge base). Use the host's native multi-choice tool when available (Claude Code `AskUserQuestion`, Codex `ask_user_question`, Cursor Plan Mode `AskQuestion`); fall back to markdown `A/B/C/D` choices otherwise. Keep it to one question with 2–4 options plus "Other" escape hatch; never dump 5+ at once.
 
-The question shape (adapt labels to the user's conversation language, keep machine tokens English):
+The question shape (translate all user-facing text to the user's conversation language; keep machine tokens English):
 
 ```
 Q. What will this workspace mainly hold?
@@ -73,13 +75,49 @@ Interpret the answer:
 - User says "skip" / "don't care" → run `context init` without `--focus`.
 - `$ARGUMENTS` already contains `--focus "..."` → skip this step entirely.
 
-### Step 4 — Run init
+### Step 4 — Choose aspects (unless `$ARGUMENTS` already has aspect flags)
+
+Skip this step if `$ARGUMENTS` already includes `--with-aspects`, `--with-all-aspects`, `--minimal`, or `--no-aspects`.
+
+If the user request names specific aspects, map that directly:
+- "only code aspect" / "仅启用 code aspect" → append `--with-aspects code`
+- "all aspects" / "全部 aspect" → append `--with-all-aspects`
+- "no aspects" / "不安装 aspect" / "minimal" → append `--no-aspects`
+
+Otherwise ask **one** multi-select question. The first option **must** be a `skip` choice so the user can always submit (host multi-choice tools such as Claude Code `AskUserQuestion` refuse to submit when zero boxes are checked). Pre-check `code` as the recommended default.
+
+```
+Q. Which aspects should be installed? (multi-select)
+  A. skip — install no aspects now; add later with `context init --with-aspects <name>`
+  B. code — scripted local source-code capture. (Recommended; pre-checked)
+  C. design-system — placeholder aspect template.
+  D. openapi — placeholder aspect template.
+  E. graphql — placeholder aspect template.
+```
+
+Hard rules when mapping into the host UI:
+
+- The `skip` option **must** be present as the **first** choice. Do not relabel it `Other`, do not omit it, do not assume the host's auto-injected `Other` covers it. `Other` (if present) is a free-text escape hatch and is unrelated to "skip".
+- Pre-check `code` so the user can submit immediately to get the recommended setup.
+- The user cannot submit zero boxes — they always pick at least `skip` or one aspect. If they pick `skip` together with any aspect, treat `skip` as the winner and ignore the others.
+
+Map the answer:
+
+- `skip` selected → append `--no-aspects`.
+- One or more aspects selected (without `skip`) → append `--with-aspects <comma-separated names>`, e.g. `--with-aspects code,openapi`.
+- Host auto-injected `Other` selected → ignore it, fall back to the recommended default `--with-aspects code`.
 
-Run `context init $ARGUMENTS` with the selected `--layout`, `--language`, and `--focus` appended when those flags were not already present. The CLI handles skeleton build, `.gitignore`, `AGENTS.md`, `CLAUDE.md -> AGENTS.md`, and aspect templates inside the selected C4A data root.
+Do not silently install all aspects when the user asked for a code-only workspace.
+
+### Step 5 — Run init
+
+Run `context init $ARGUMENTS` with the selected `--layout`, `--language`, `--focus`, and aspect flags appended when those flags were not already present. The CLI handles skeleton build, `.gitignore`, `AGENTS.md`, `CLAUDE.md -> AGENTS.md`, and aspect templates inside the selected C4A data root.
 
 If the CLI errors (e.g. an existing workspace without `--with-aspects`, or root layout blockers), surface the error and the CLI's remediation hint.
 
-### Step 5 — Summarize
+To add aspects later in an existing workspace, run `context init --with-aspects <name>` from the workspace root. Use comma-separated names for multiple aspects, for example `context init --with-aspects code,openapi`. Append mode only copies missing aspect templates and does not rewrite workspace config, raw data, or knowledge.
+
+### Step 6 — Summarize
 
 Briefly state in the user's conversation language:
 - Workspace name
@@ -88,6 +126,7 @@ Briefly state in the user's conversation language:
 - Installed aspects
 - Whether `AGENTS.md` was created and whether `CLAUDE.md` was linked
 - Whether focus was recorded (show the first line if yes; mention the user can edit `config.yaml` later if not)
+- If the CLI prints a Claude local permission hint, tell the user that `Bash(context:*)` is the recommended scoped allow for heredoc-heavy context workflows. Do not edit `.claude/settings.local.json` unless the user explicitly asks.
 - Suggest `/context:capture` as the natural next step
 
 CLI output, file paths, aspect names, flags, and command names stay as printed.

package/plugin/commands/purge.md

@@ -7,16 +7,16 @@ allowed-tools: Bash(context:*)
 ## Your task
 
 Purge the workspace archive. This is destructive: it deletes all restorable
-artifacts under `archive/` that were created by `context drop --apply-plan`.
-It does not modify active `raw/` or active `knowledge/`.
+source/knowledge artifacts created by `context drop --apply-plan`.
+It does not modify active sources or active knowledge.
 
-It does not delete `output/archive/`. Compile/align scratch archives are kept
-under the output lifecycle so prior agent inputs remain inspectable; clean them
+It does not delete compile/align scratch archives. Those are kept under the
+output lifecycle so prior agent inputs remain inspectable; clean them
 manually or via a future output-retention policy, not with `context purge`.
 
 Run `context purge $ARGUMENTS`. If `--yes` is absent, the CLI prints a summary
 and asks for confirmation. Relay that summary in the user's language and do not
-try to inspect `archive/` yourself.
+try to inspect archive storage yourself.
 
 Never Read / Glob / Grep / Write workspace files directly. All workspace access
-goes through `context purge`, `context source`, or `context workspace`.
+goes through semantic CLI commands such as `context purge` and `context source`.

package/plugin/commands/query.md

@@ -1,13 +1,21 @@
 ---
 description: "Answer a local knowledge question through context query hit/miss/select results and cited supplemental views."
 argument-hint: "<question>"
-allowed-tools: Read, Bash(context:*)
+allowed-tools: Bash(context:*)
 ---
 
 ## Your task
 
-Read `${CLAUDE_PLUGIN_ROOT}/skills/context-query/SKILL.md` and follow it end to end for `$ARGUMENTS`.
+Naming convention:
+
+- `/context:*` names user slash commands.
+- `context ...` names CLI primitives.
+- Internal packaged procedures invoked by slash workflows are not user slash commands.
+
+Use packaged `context:skill-context-query` end to end for `$ARGUMENTS`.
 
 This command is intentionally a thin entrypoint. Do not duplicate the query protocol here; the skill owns the hit/miss/select handling, supplemental lookup, citation, gap, and broad-query rules.
 
-Never use direct workspace file tools for local knowledge. Workspace context must come from `context query` commands only.
+Never use direct workspace file tools for local knowledge. Workspace evidence must come from `context query` commands only; the packaged skill may run its documented `context query --intent orientation` or empty `context query` command before querying, but that output is not evidence.
+Never use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect `WORKSPACE_DIR`, `.context`, or `/tmp` workflow artifacts while answering a query.
+Use the default `context query` text output. Cite returned `node` and `section` handles; do not invent source provenance or inspect workspace files.

package/plugin/commands/status.md

@@ -6,16 +6,18 @@ allowed-tools: Bash(context:*)
 
 ## Your task
 
-Run `context status` from the workspace root only: for embedded layout, the project directory that contains `.context/`; for root layout, the data root itself. `status` is intentionally local-only and does not walk up from child directories. If you need to discover the workspace from a child directory, run `context workspace locate --format json`.
+Run `context status` from the active workspace root only. `status` is intentionally local-only and does not walk up from child directories. If the CLI reports `workspace-not-found`, relay that error and ask the user to rerun from the workspace root or initialize with `/context:init`; do not probe storage paths to discover a workspace.
 
 Surface the CLI's output verbatim — its trailing suggestions are already actionable. Do not invent additional suggestions; the CLI decides what to recommend based on the workspace state. Typical recommendations you will see:
 
 - Run `/context:align` when there is active raw material but no align plan yet (compile's Stage 1 prerequisite).
 - Run `/context:compile` when align plan exists and raw is newer than the last compile.
-- Run `/context:capture-code` when the repo is a git checkout but no source-code snapshot has been captured yet.
+- Run `/context:capture --code` when the repo is a git checkout but no source-code snapshot has been captured yet.
 
 Recent CLI output may include `incremental.cache_status`, `incremental.pending_align`, and `incremental.pending_compile`. Surface those fields verbatim. If the user asks what they mean, explain that they show the local incremental cache health and queued align/compile work; cache warnings are informational unless the CLI output includes a blocking error or an explicit next action.
 
+Workflow lineage helpers are exposed through `context workflow status --format json` and `context workflow list --format json`. If status returns `current: null` with `last_published`, the published finalized ownership is still the workspace structure truth; compile may continue from it without rerunning align.
+
 If the CLI exits with a workspace-not-found error, stop and invite the user to run `/context:init` instead of guessing a workspace location.
 
 Language policy: surface the CLI output verbatim. Any extra explanation or workspace-not-found invitation follows the user's conversation language; command names, paths, status labels, source-ids, and issue codes stay as printed.

package/plugin/skills/skill-align-workflow/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: context-align-workflow
+description: "Internal procedure for /context:align. Read align workflow schemas, operate candidate ledger payloads, and produce an align-structure-decision for CLI finalize."
+---
+
+# Align Workflow Procedure
+
+## TL;DR
+
+Run the align workflow through the CLI-owned beta.8 payload chain: scan segments, prepare neutral candidate operations, finalize an `align-structure-decision`, and let the CLI write finalized ownership.
+
+<reference>
+
+## Canonical Data
+
+- Schema names are exposed by `context schema <name>`.
+- Candidate ledger and aggregate payloads are mechanical inputs only.
+- Finalized structure is represented by `align-structure-decision`.
+- Retired payloads include candidate tables, decision patches, and full-tree finalize documents.
+- Existing knowledge is the lookup registry. Use `context mdrive glossary match <name>` / `context mdrive node list --format json` for term/entity reuse; do not read `knowledge/**` and do not create a separate registry file.
+- Keep cache-friendly prompt order: fixed protocol and schemas first, existing knowledge lookup second, source-shared payload views third, current candidate batch last. Preserve CLI JSON order and do not add timestamps, random ids, scratch paths, or host paths to generated payloads.
+- `align-segments.generation_policy` is the workspace language contract for generated Node titles, summaries, rationale prose, and planned Section wording. Preserve product names, code identifiers, slugs, flags, and `source_ref` tokens exactly when needed.
+- Gate rules for `domain` and `action` proposals are in `references/gates.md`.
+- Coarse-read density and neutral signal rules are in `references/density-profile.md`.
+- Candidate anomaly handling, `label_hint`, and `llm_slug_hint` reference rules are in `references/candidate-resolution.md`.
+
+</reference>
+
+<procedures>
+
+Use this only inside `/context:align`.
+
+1. Start from `align-segments`.
+2. Inspect it through compact CLI views, not shell parsing: `context workflow show --payload align-segments --view segment --unwrap --format json`, `--view blocks`, and `--view windows`. Read and obey `generation_policy` before authoring any title, summary, rationale, or planned Section wording. The default `blocks` view is a structure summary; drill into content with `--window <window-id>`, `--heading <prefix>`, `--range <start:end>`, or `--token-budget <n>`. `--unwrap` only removes the workflow metadata envelope; it does not change summary/detail behavior.
+3. Query existing knowledge for reusable names before proposing new term/service/system/action Nodes. `context mdrive glossary match <name>` returns deterministic `match.kind`, `match.matched`, and `match.rank`; exact title/slug/alias hits should usually become references to the existing Node, not duplicate candidates.
+4. Produce coarse-read anchors and neutral content signals as JSON. Pick `density_profile` using `references/density-profile.md`; content signals describe text shape only, not final Node type. Submit the artifact through stdin with `context align --coarse-read - --format json`. The latest `align-coarse-read` payload is only the most recent checkpoint; durable multi-source reading notes live in `align-candidate-ledger.source_readings`. Submit coarse-read payloads serially within one workflow; workflow payload writes are not a parallel ingestion API.
+5. Produce candidate ops batches as JSON. Before each batch, refresh the Term Entity Boundary in `references/gates.md`; its TTL is one batch or about ten candidates, whichever comes first. Use `local:<name>` only inside the current batch; submit each batch through stdin with `context align --ops - --format json` and pass `--ledger-digest <digest>` after the first batch. The CLI reducer assigns durable candidate ids. For `merge_into`, `supersede`, and `reject`, include the required `*_label_hint` fields from the visible candidate labels.
+6. Read the CLI-written candidate ledger and aggregate with `context workflow show --payload align-candidate-ledger --view ledger --unwrap --format json` and `context workflow show --payload align-candidate-aggregate --view aggregate --unwrap --format json`. To revisit one source's coarse-read notes, add `--source <source-id>` to the ledger view; candidates do not carry source ids, so add `--status` or `--candidate-id` only when you also need candidate rows. Treat aggregate fields as mechanical statistics and warnings, not semantic recommendations. Resolve every `anomaly_signals[]` entry as accept, dismiss, or unresolved before finalizing.
+7. If the CLI returns `agent_hints[]`, follow them before retrying. Legacy-protocol hints mean the submitted payload/schema is retired; switch to the beta.8 schema named in the hint instead of reshaping old fields.
+8. Before producing `align-structure-decision`, refresh and apply `references/gates.md`: re-run the Term Entity Boundary decision tree, every `action` needs the five action probes plus structured `inference_sources`, and every `domain` needs `scope_blocks`, resolvable `child_refs`, and `grouping_reason`.
+9. Produce `align-structure-decision` as JSON with finalized nodes, `contains_parent`, `depends_on`, and one `block_ownership[]` entry per coverable block. Node titles and summaries must follow the latest `generation_policy` language; do not default to English scaffolding such as "How-To", "Strategy", or "Architecture" when the workspace language is not English. Submit it through stdin with `context align --finalize - --digest <segments-digest>`. Prefer stable `llm_slug_hint` values for `contains_parent_ref`, `from_ref`, `to_ref`, owners, and section owners while the final slug is still being normalized.
+
+   If `align-segments.incremental.mode` is `incremental`, finalize is a delta merge. Submit only the Nodes and ownership supported by the current scanned sources; reference previous finalized Nodes when they are parents, dependencies, domain children, owners, or visibility targets. Absence of an old Node or edge is not a delete signal. Do not redeclare an old parent/domain just to attach a new child. `sections[].owner` must be a Node declared in the current payload; previous finalized Nodes can be referenced structurally but do not receive new section plans from this incremental payload. Existing or previously removed Node slugs cannot change `node_type`; `context align --scan --full` does not bypass that guard. Use a new slug for a different type, or retire the old slug through `context drop` or explicit structure correction before re-aligning.
+
+   For large finalize decisions, use `block_ownership_defaults[]` instead of enumerating every block. Each default names a `source_id` plus the same ownership fields as a block-level entry except `block_id`; the CLI expands it across that source's coverable blocks. Put only exceptions in `block_ownership[]`, which override defaults for their `block_id`. Keep the payload on stdin; do not generate temp JSON files just to list hundreds of ownership rows.
+
+   If a finalized Node is intentionally navigation-only or placeholder-only, set `planned_sections: []` and keep its relation/placeholder blocks as `context_only` or `ignored`; do not assign `owned` evidence or plan a description solely to keep the Node alive. Compile close will create an empty placeholder Node with no active Sections.
+
+   Each `block_ownership[]` entry sets `ownership_role` to one of five values, and the **shape of the rest of the entry depends on the role**. Set `ownership_role` first and only include the fields that role requires; surplus fields trigger schema errors. The CLI returns `agent_hints[].correct_shape` with the canonical JSON skeleton on any role/field mismatch — reshape that entry to match it instead of guessing.
+
+   - `owned`: exactly one slug in `owners[]`, plus `visible_to[]` and `reason`. Do not include `primary_owner`, `context_prefix`, or `question_id`.
+   - `shared`: at least two slugs in `owners[]`, `primary_owner` chosen from those owners (the Node that authors cited Sections from this block; secondaries receive compact context and must request full text or raise an ownership challenge before citing it), `visible_to[]`, `reason`. Do not include `context_prefix` or `question_id`.
+   - `context_only`: **omit `owners` and `primary_owner` entirely.** Required: `context_prefix` (short summary travelling with citing Sections), `visible_to[]`, `reason`. Do not include `question_id`.
+   - `ignored`: **omit `owners`, `primary_owner`, `context_prefix`, and `visible_to`.** Required: `reason`. Use for outdated markers, navigation/external-link blocks, and placeholders without independent knowledge. Do not include `question_id`.
+   - `unresolved`: **omit `owners`, `primary_owner`, and `context_prefix`.** Required: `question_id` (matching a top-level `unresolved[].question_id`) and `reason`. Use when classification is blocked by missing evidence.
+
+   After finalize, a second `context align --finalize` is rejected with `workflow-finalize-locked`; follow the returned `remediation_options[]` instead of resubmitting into the finalized workflow. Use `context workflow list --format json` when you need to audit finalize history.
+
+Never write raw, cache, knowledge, `/tmp`, or workspace scratch files. Never pipe `context ... --format json` through `jq`, `head`, `tail`, `sed`, `cat`, `2>&1`, Python, Node.js, or shell scripts. Never read host persisted output files such as Claude `tool-results/**`; rerun a narrower `context workflow show` command instead. Never submit old candidate-table, decision-patch, or full-tree payloads.
+
+</procedures>