@c4a/context-cli 0.5.35-beta.3 → 0.5.38

package/plugin/commands/compile.md

@@ -1,170 +1,99 @@
 ---
-description: "Compile the confirmed align plan into knowledge articles: draft, semantic reconciliation, apply, then close."
-argument-hint: "[--plan|code <slug>]"
+description: "Compile the confirmed align plan into source-linked knowledge through CLI-guided workflow steps."
+argument-hint: "[--plan|--aspect code [slug]|--aspect <name>|--all]"
 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 internal packaged procedures.
--->
-
 ## Your Task
 
-Synthesise the finalized align plan into knowledge through semantic CLI operations. If the user explicitly authorized托管/全自动/delegated mode at the start of this conversation, create the compile workflow with `--delegated`; otherwise stay in manual/default mode. 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.
+Synthesize finalized align structure into knowledge. The CLI owns workflow routing, validation, reconciliation, apply, close, payload storage, and recovery commands. The agent reads evidence and emits semantic payloads only when `next_action` asks for them.
 
 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.
+- `context:skill-*` names packaged internal procedures, not user slash commands.
 
 ### 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 -` 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.
-- **`code [slug]`** — run the CLI-owned code projection route directly with `context compile code [slug]`, report its output, then stop. This route does not enter doctor/draft/reconcile and uses the same deterministic implementation as `context align --code`. It materializes code snapshots into package/category/symbol Nodes; run `context compile close` afterward only when the CLI asks for close.
-
-### Delegated Workflow Mode
+- **Default** — follow `context compile scan --format json` and the returned `next_action` until compile is closed or no work remains.
+- **`--plan`** — validate per-Node draft changes without closing or writing active knowledge; stop after the planned changes are reported.
+- **`--aspect code [selector]`** — run `context compile --aspect code [selector]`, report the CLI result, and stop unless the CLI asks for a follow-up close. The selector may be omitted to process all actionable code sources; when present, the CLI resolves source slug, package name, or module path.
+- **`--aspect <name>`** — run deterministic custom aspect projection for one configured aspect. Use `context compile --aspect <name> --allow-large-deprecate` only when the CLI rejected a large deprecate and the user confirms the runner output is intentionally empty or reduced.
+- **`--all`** — run `context compile --all` to materialize code projection first and then custom aspect projections in deterministic order.
+- **Delegated** — add `--delegated` only when the user explicitly authorized delegated/automatic mode at the start of this conversation. Do not infer it from vague "continue" permission.
 
-- If the user explicitly authorized托管/全自动/delegated mode at the start of this conversation, add `--delegated` to the first compile workflow-creating command, preferably `context compile scan --delegated --format json`. Do not add it for vague "continue" / "继续" permission.
-- `--delegated` is a workflow-level authorization, not a per-review override. It only lets the CLI auto-accept low-risk defaults: weak lexical support with empty `source_support.missing_hard_terms`, or supported `keep_separate` decisions whose candidates have no duplicate/conflict/archive/reanchor risk and no pinned target Section. Missing hard facts, type drift, schema errors, ownership/structure challenges, user-confirmation gates, and destructive gates still block.
-- Never hand-author `decided_by: delegated_agent`; the CLI injects it only inside a delegated compile workflow.
+### Core Rules
 
-### Shared Policies
+- Follow top-level `next_action.kind` and `next_action.command` for every write.
+- Use `views[].command` for evidence reads, prioritizing `expected: true`.
+- Treat `allowed_actions[]` as permission for read-only insertions; it is not a menu of alternate write paths.
+- Treat `agent_hints[]`, when present, as a temporary mirror or diagnostic. If it conflicts with `next_action`, follow `next_action`.
+- Do not use direct file tools, shell scripts, `jq`, `sed`, `cat`, `head`, `tail`, Python, or Node.js to inspect workspace storage, workflow payload files, or `--format json` stdout.
 
-Language policy: your explanatory prose and final reports follow the user's conversation language. Node titles, Node summaries, and user-facing draft explanations follow `NodeContext.generation_policy.language` when the CLI provides it. Source-bound compile draft `content` should stay close to the cited source language when it differs from the workspace language; do not translate cited English facts into Chinese just to match the workspace. Section `summary` is a compact reader/query aid derived from `content` and may follow either the workspace language or the source-bound `content` language; do not patch it merely to switch languages. source_support hard-term matching checks `content`, not `summary`. For `example` Sections that cite a code/config/command fence, keep `content` centered on the cited fenced block and put framing prose in `summary`; split prose into a separate action only when it cites its own evidence. Preserve product names, code identifiers, CLI flags, slugs, `block_id` / `source_ref` tokens, and exact quoted evidence as printed. CLI stdout/stderr, the canonical `processing <slug>` lines, paths, slugs, block ids, source refs, issue codes, flags, and command names stay as printed.
+Protocol discovery:
 
-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.
+- `context schema workflow.next-action-envelope.v2 --view minimal --format json`
+- `context protocol show align-compile --format json`
+- command-specific `context schema <name> --view minimal --format json`
 
 ## Preflight
 
-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[]`. This status means newer raw snapshots exist; it does not mean finalized ownership or `node.sources[]` are already refreshed.
-3. Run `context compile scan --format json` and parse the JSON as `COMPILE_WORKSET`. If delegated workflow mode is explicitly authorized, run `context compile scan --delegated --format json` for this first scan instead. `context compile scan` is the only workset scan entrypoint; `/context:compile --plan` controls whether the workflow stops before writing.
-   - If `COMPILE_WORKSET.compile_route` is present, treat it as the current advisory route. It does not replace evidence inspection: for every Node that needs a draft, read that Node's source-refs view before writing content, then use `context compile cycle` as the default write path. Enter manual review only when cycle returns it.
-   - If `context workflow status --format json` has `current: null` but `last_published` is present, continue with `context compile scan`; 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 CLI order. Per-Node `processing <slug>` echoes must match this order.
-
-Review input rule: normal compile flow reads the current prepare payload automatically: pass decisions with `context reconcile review --decisions - --view status`. Add `--prepare-digest` only when you intentionally want an explicit stale guard. 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.
-
-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
-
-Skip this section unless `STATUS.semantic.refreshed_source_pending_compile.source_ids[]` is non-empty or `context compile scan` returns a refresh-related next action. This is a real recovery path, not the default compile path.
-
-For each refreshed source id, run `context reconcile prepare --mode refresh --source <source-id> --format json`, pass the payload to packaged `context:skill-semantic-reconcile`, review with `context reconcile review --decisions - --view status`, then apply with plain `context reconcile apply` when ready. If the prepare output says the source is unchanged, report no refresh decisions and continue. After applying refreshed sources in default mode, rerun `context compile scan --format json --ignore-source <source-id>` for each refresh-applied source and use that filtered workset for the per-Node loop.
-
-## Per-Node Loop
-
-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. Prepare evidence for every workset Node.
-   - **1a. Get NodeContext.** 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 workflow payload handles; do not extract digests by hand. Only expand the durable NodeContext when you are ready to pass its returned `.value` object to the draft skill.
-   - **1b. Inspect citation refs.** First inspect citation handles with `context compile context <slug> --view source-refs --token-budget 2000 --format json` or `context workflow show --payload node-context --view source-refs --token-budget 2000 --unwrap --format json`; this source-refs view is only a projection of `NodeContext.raw_snippets[]`, not a separate data source. Planned Section rows may include `quote_full_text` for example code fences and long paragraph/table evidence already counted in the view budget; use it directly instead of doing a second full-text request for the same row. If the view returns `page.next_token` or `next_command`, follow `next_command` to continue the same source-refs view. If it returns `truncated: true`, follow `how_to_explore[]` to narrow by `--source` / `--heading` or expand the budget.
-   - **1c. Request full text only when needed.** `context compile context <slug> --request-full-text <block_id> --view text --format json` exposes visible evidence text through the narrow text view; read expanded page text from `items[].text`. Long blocks are returned as line-bounded pages with `items[].next_command`; follow that command to continue reading the same block. `request_full_text.pages[].text` and `raw_snippets[].quote` may appear in full NodeContext outputs as mirrors, but the agent-facing expansion path is `--view text`. Do not use file tools to bypass the page.
-   - **1d. Respect evidence boundaries.** 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. Full-text inspection 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. If NodeContext includes `generation_policy`, apply it to generated titles, summaries, and user-facing explanations; for source-bound draft `content`, prefer the cited source language when it differs. Do not default Node titles/summaries to English scaffolding such as "How-To", "Strategy", or "Architecture" when the workspace language is not English.
-   - **1e. Use workflow views instead of files.** 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 source-refs, coverage-summary, coverage detail filters, and returned `how_to_explore[]`.
-2. Invoke packaged `context:skill-compile-draft` and follow its procedure to emit draft JSON. Do not reconstruct the draft shape or Section classification rules from memory; the draft skill carries the canonical kind priority, mount matrix, examples, and reflection gates. Section writes use `content` plus optional `summary`; new Sections do not need `section_id`, and the op is exactly `op: "add"` because compile-draft `actions[]` already targets Sections. Do not use align-style op names such as `add_section` or `propose_section`. Cite raw via `source_refs: [...]` chosen from `raw_snippets[].source_ref`; use a single-element array for one citation, and use multiple refs only when the Section content actually consumes all of them. The CLI may report over-wide citation narrowing; `removed_lead_in_source_refs` are framing/navigation refs to keep unless you verify they add no meaning, while `removed_redundant_source_refs` are cleanup candidates. The CLI rejects retired `body` / `detail` / `raw`, 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 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: "partial-applied"` or `status: "review-required"`, use the returned `prepare` / `review` handles and continue with the manual path below for only the remaining questions/issues; do not rerun the earlier context/source-ref reads. When you need to patch a remaining action after prepare, run `context compile draft-status <slug> --format json`; each action backed by the latest prepare payload includes `reconcile_item_id` and `source_support`, so use that claim id instead of guessing. To patch and continue in one call, pass a compile draft-patch payload to the same node-cycle command; use `op: "replace_action"`, `action_id`, and `action`, not align-style `op/path/value`.
-4. Conditional manual path: enter this only when `cycle` returns `partial-applied`, `review-required`, a draft revision hint, or a coverage/source-support issue that cannot be resolved by a compile draft-patch. Use the returned `prepare` / `review` handles and CLI `agent_hints[]`; do not restart the Node from context reads. If semantic judgment is needed, load `context workflow show --payload prepare --unwrap --format json`, feed it to packaged `context:skill-compile-judge`, then pass the judge decisions to `context reconcile review --decisions - --view status`. Apply with plain `context reconcile apply` only when review says `ready_to_apply: true`. If questions are returned, ask the user in business language; never mark `decided_by: user` on your own.
-5. Coverage repair: if compile or close reports uncovered required evidence, first inspect `context workflow show --payload coverage-candidates --view coverage-summary --token-budget 2000 --unwrap --format json`, then narrow with `--view coverage` filters. Use `context compile context <slug> --cover-uncovered-only --format json` for targeted repair drafts. Use coverage skip/disposition only when the candidate is intentionally excluded and the CLI exposes that action.
-6. 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. 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 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` 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.
-
-Close only projects finalized Nodes that materialize as a CLI-written knowledge article or as an explicit no-write placeholder declared by align with `planned_sections: []`. A compile skip action records reviewed no-write evidence, but it does not by itself turn an arbitrary finalized Node into a placeholder.
-
-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 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 - --prepare --format json <<'JSON'
-{
-  "schema_version": "compile.draft.v2",
-  "target_node": "billing-api",
-  "actions": [
-    {
-      "op": "add",
-      "kind": "description",
-      "content": "Billing API exposes invoice lookup and payment capture endpoints.",
-      "source_refs": ["src-1#billing-api L10-18@7a6f4c9d2e10"]
-    }
-  ]
-}
-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 - --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@7a6f4c9d2e10"]
-    }
-  ]
-}
-JSON
-```
-
-For navigation-only or placeholder-only context, no active Section is the correct result:
-
-```bash
-context compile draft billing-api --input - --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
-
-- 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`, `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 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.
-
-## Plan Mode Final Report Contract
-
-- Use the same stable shape where possible, but make the headline clearly indicate that this was a plan-only run.
-- Replace the close-stage section with a not-written section and tell the user to re-run `/context:compile` without `--plan` to apply.
-- Do not include knowledge file links for files that were not written.
+1. Run `context doctor`. If output-align errors block compile, tell the user to run `/context:align` and stop.
+2. Run `context status --format json` and `context mdrive workspace stats --format json` for before/after reporting.
+3. Run `context compile scan --format json` (or `context compile scan --delegated --format json` only for explicit delegated mode).
+4. If the scan returns `stop_noop` or no changed work, report that compile stopped before draft and no files were written.
+
+Run `context compile scan` only for this initial preflight unless the CLI explicitly returns it as the next command after a terminal/no-work state. During an active compile workflow, discover the next node from the current envelope (`next_action`, `views[]`, `workset_progress`) and follow returned commands; do not rerun scan between node cycles to probe for the next node.
+
+## Main Loop
+
+Repeat until the CLI returns `stop_noop`, `close_compile` succeeds, or a blocking user question remains.
+
+Carry the latest envelope forward between iterations. After a successful node cycle, continue from its returned `next_action.command` / `workset_progress` rather than restarting at `context compile scan`.
+
+### Step 1 — Read Expected Views
+
+Run expected view commands from the envelope before writing. For compile evidence, prefer the CLI-returned source-ref/scaffold views. They may expose:
+
+- `source_refs_index_command` / `source_refs_command` — compact block-id evidence index for drafting; use `items[].block_id` in `source_block_ids[]`.
+- `source_refs_detail_command` — detailed source refs with quote previews; open only when the compact index is not enough.
+- `citable_source_refs[]` — detailed-view refs eligible for draft citations; prefer `block_id` values in `source_block_ids[]`.
+- `supporting_context_refs[]` — background/framing only.
+- `required_preserved_literals[]` — URL, code identifier, `source_ref`, or `block_id` literals that must stay visible in the generated content or repair report.
+- diagnostics such as citation eligibility, source support, coverage, engagement, and advisory foldbacks.
+
+Follow `page.next_command` for pagination. Use `how_to_explore[]` for narrow reads. Do not expand workflow payloads through host tool-results. Node-cycle receipts are compact by default; `actions_meta[]` exposes current draft action handles for patching without an extra status read.
+
+### Step 2 — Produce Payloads Only When Requested
+
+For `submit_compile_cycle`, load the Node evidence via the returned command/views, invoke packaged `context:skill-compile-draft` for exactly one Node, and pass the emitted JSON on stdin to the returned `next_action.command`.
+
+For `continue_compile_cycle`, do not invoke the draft skill and do not attach `--input`; execute the returned `next_action.command` exactly. `--continue` resumes a saved draft session. If it returns `status: "noop"`, follow the returned `close_compile` next action.
+
+For `patch_compile_draft`, submit only the patch schema requested by the CLI. Use `actions_meta[].action_id` for `replace_action` / `remove_action`, or `add_action` with `before` / `after`; do not use generic `op/path/value` aliases.
+
+For `review_reconcile_decisions`, load the prepare payload through CLI views such as `context workflow show --payload prepare --unwrap --format json`, invoke packaged `context:skill-compile-judge` when semantic judgment is needed, run `context reconcile validate --mode compile --node <slug> --decisions - --format json`, repair any blocking diagnostics, then pass validated decisions to the returned review command.
+
+Invoke `context:skill-compile-judge` only when the top-level `next_action.kind` is exactly `review_reconcile_decisions`. If `questions` are present but `next_action.kind` is `patch_compile_draft`, patch the draft first; do not infer judge mode from question counts.
+
+For `apply_reconcile_review`, `close_compile`, `finish_current_node`, `submit_coverage_disposition`, or `abandon_or_rescan`, execute the returned command exactly. If it rejects, follow the new `next_action` and `reason_code`.
+
+### Step 3 — Repair From Diagnostics
+
+Use typed diagnostics as the repair contract:
+
+- `reason_code`, `path`, and `missing[]` identify what to fix.
+- `diagnostics.auto_repaired[]` records mechanical repairs; warning severity must be surfaced in the final report.
+- `diagnostics.warnings[]` with info/advisory severity are not write blockers unless `blocking: true` or the next action says so.
+- `agent_recommended_action` classifies warning handling: `ignore` means continue unless the user asks for cleanup, `respond_optional` means repair only when semantically useful, and `respond_required` means resolve before the returned write action can succeed.
+- `source_support` is advisory lexical diagnostics, not a keyword gate. Do not patch drafts only to satisfy term overlap. Blocking evidence checks should come from invalid source refs, changed evidence boundaries, URL preservation, split-by-evidence candidates, or explicit top-level `next_action`.
+- stale prepare refresh returns `review_reconcile_decisions` with `reason_code: "prepare_refreshed"`; reread the new prepare result before reviewing.
+
+Do not recover by replaying an old manual path, editing rendered files, or guessing schema aliases.
+
+## Close And Report
+
+When `next_action.kind` is `close_compile`, execute `context compile close` through packaged `context:skill-compile-close` or the returned command. Never claim success unless close exits 0 and verify is green, except the explicit no-work path.
+
+Report in the user's conversation language. Include semantic apply counts, close/verify status, warning-level `auto_repaired[]`, `ready_with_debt` coverage/review-debt summaries when present, and before/after workspace totals. Do not surface internal workflow payload digests, source-ref hashes, archive paths, or absolute file paths unless a user-facing report view explicitly returns them.

package/plugin/commands/init.md

@@ -70,7 +70,10 @@ Q. What will this workspace mainly hold?
 Interpret the answer:
 - Chose A–D → generate a 2–3 line focus description in the user's language. Phrase it as
   "primarily X; supporting materials such as Y may also be filed here" rather than exclusion
-  language — workspaces absorb auxiliary material in practice. Pass it as `--focus "..."`.
+  language — workspaces absorb auxiliary material in practice. Show the exact generated focus
+  text to the user and ask for one confirmation before running `context init`. If the user
+  approves, pass it as `--focus "..."`; if the user edits it, pass the edited text as
+  `--focus "..."`; if the user declines or says to skip, run without `--focus`.
 - Chose E or described freely → pass the user's text verbatim as `--focus "..."`.
 - User says "skip" / "don't care" → run `context init` without `--focus`.
 - `$ARGUMENTS` already contains `--focus "..."` → skip this step entirely.
@@ -84,28 +87,27 @@ If the user request names specific aspects, map that directly:
 - "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.
+Otherwise ask **one** short single-choice question. Keep the option count to three or fewer; host question tools reject longer option lists. Use the host's free-text `Other` escape hatch when the user needs a custom comma-separated aspect list.
 
 ```
-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.
+Q. Which aspects should be installed?
+  A. code — scripted local source-code capture. (Recommended)
+  B. all built-in aspects — code, design-system, openapi, graphql.
+  C. skip — install no aspects now; add later with `context init --with-aspects <name>`.
 ```
 
 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.
+- Do not present separate options for every built-in aspect; that exceeds host option limits once `skip` is included.
+- Put `code` first and mark it as recommended.
+- Treat the host auto-injected `Other` as a free-text custom list such as `code,openapi`, not as "skip".
 
 Map the answer:
 
+- `code` selected → append `--with-aspects code`.
+- `all built-in aspects` selected → append `--with-all-aspects`.
 - `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`.
+- Host auto-injected `Other` selected → parse the user's comma-separated aspect names and append `--with-aspects <names>`. If the custom text is empty or invalid, ask once for clarification rather than silently installing all aspects.
 
 Do not silently install all aspects when the user asked for a code-only workspace.
 

package/plugin/commands/status.md

@@ -11,8 +11,10 @@ Run `context status` from the active workspace root only. `status` is intentiona
 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:align` when JSON status reports `incremental.pending_align.status: "pending"` with `count > 0`. This structural signal takes precedence over a previous finalized align workflow's compile hint.
 - 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 compile --aspect code` when code projection is pending, or `context compile --aspect <name>` when a custom aspect projection is pending. JSON status includes `aspect_projection` and `code_projection` summaries for these deterministic paths.
 
 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.
 

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

@@ -1,30 +1,30 @@
 ---
 name: skill-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."
+description: "Internal procedure for /context:align. Reads CLI-guided align evidence, applies semantic Node classification gates, and emits align structure-decision payloads for CLI validation/finalize."
 ---
 
 # Align Workflow Procedure
 
 ## TL;DR
 
-Run `context align --scan --format json`, inspect the needed evidence, and follow `align_route.next_command`. Direct routes skip coarse-read/candidate-ops and finalize immediately; only `batched_review_required` routes use the coarse-read and candidate ledger path.
+Run `context align scan --format json`, read expected evidence views, produce semantic structure payloads, and follow 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.
 
 <reference>
 
 ## Canonical Data
 
-- Schema names are exposed by `context schema <name>`.
-- `align_route` is authoritative. It defines whether this scan is direct-finalize or batched-review, and the CLI rejects route-incompatible submissions.
-- 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.
-- Code projection Nodes are existing knowledge handles. When document evidence belongs on a code symbol, reuse the code slug instead of creating a parallel document Node. If the slug exists only as projected code knowledge and is not yet in finalized prose ownership, declare that same slug in the current `nodes[]`, add the prose `planned_sections`, and route `sections[].owner` plus `block_ownership[].owners` to it.
-- 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, Node summaries, rationale prose, and planned Section wording. Source-bound Section wording should stay close to the cited source language when it differs from the workspace language. Section summaries may later follow either workspace language or source-bound content language. Preserve product names, code identifiers, slugs, flags, `block_id` handles, and `source_ref` tokens exactly when needed.
-- Source titles and headings are ordinary evidence, not structural authority. Do not automatically copy them into Node titles or aliases; classify the evidence referent first, then generate a title that fits the final Node type.
+- `workflow.next-action-envelope.v2` is authoritative. Branch on `next_action.kind`, execute `next_action.command` for writes, and use `views[].command` for budget-safe evidence reads.
+- `allowed_actions[]` may permit extra read-only work before the next write; it is not a menu of alternate write paths.
+- `agent_hints[]`, when still present, is a short-term cutover mirror or diagnostic. Do not prefer it over top-level `next_action`.
+- Schema names and enum values come from `context schema <name>`; use `--view minimal` for protocol discovery before full schema reads.
+- Existing knowledge is the lookup registry. Use `context mdrive glossary match <name>` and `context mdrive node list --format json`; do not read `knowledge/**` 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.
+- `diagnostics.automatic_ownership_adjustments[]` and validation diagnostics are the mechanical external-reference ownership source of truth. Independent reference definitions, pure URLs, relation kind blocks, and multiline reference-only lists default to context_only; submit an explicit `block_ownership[]` owned/shared entry only when such a reference block is primary citation evidence.
+- When `pending-relation-refs` is present, inspect it before finalizing graph structure. Use existing matches for `contains_parent_ref` or `domain_gate.child_refs`; keep unresolved target slug hints deferred and do not write dangling parent or edge refs.
+- `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.
 - Node type, tag, fake-Entity, `domain`, and `action` gates are in `references/gates.md`.
-- Coarse-read density and neutral signal rules are in `references/density-profile.md`.
+- Coarse reading 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>
@@ -33,97 +33,55 @@ Run `context align --scan --format json`, inspect the needed evidence, and follo
 
 Use this only inside `/context:align`.
 
-### Step 1 — Start From Align Scan
+### Step 1 — Start From The Envelope
 
-Start with `context align --scan --format json`. Read `align_route.mode`, `align_route.next_command`, and `align_route.reasons` before choosing any write path.
+Run `context align scan --format json`. Confirm `schema_version: "workflow.next-action-envelope.v2"`, then identify `next_action`, `views`, `workflow`, `route`, and `diagnostics`.
 
-### Step 2 — Inspect Views
+If no envelope is present, stop and surface the CLI output; do not reconstruct an align route from old prompt memory.
 
-Inspect it through semantic CLI views, not shell parsing: `context workflow show --payload align-segments --view segment --unwrap --format json`, `context workflow show --payload align-segments --view source-mapping --unwrap --format json`, `context workflow show --payload align-segments --view blocks --token-budget 8000 --unwrap --format json`, and `context workflow show --payload align-segments --view windows --page-size 10 --compact-hints --unwrap --format json`. Read and obey `generation_policy` before authoring any title, summary, rationale, or planned Section wording. Default `source-mapping` is a compact per-source index; add `--source <source-id>` only when you need that source's block id map. `blocks` is the text-bearing view: budgeted rows include full block `text` plus `text_preview`, so do not call another full-text path just to read selected align blocks. Use `window_read_plan`, `windows[].read_strategy`, `windows[].content_size`, `windows[].selector`, and `windows[].batch_selector` to skip low-signal windows, use inline tiny windows, batch neighboring small windows, or drill only selected large windows. Drill into content with `--source <source-id>`, `--heading <prefix>`, `--window <window-id|src-N:M[,selector...]>` (`src-N:M` means the M-th window under `source_alias` src-N from `--view windows`; comma-separated selectors fetch several windows in one call), or a larger `--token-budget <n>`. Prefer one focused read around 15K-30K chars / 4K-8K tokens; treat 50K chars / 12K tokens as the upper band for a single focused read. Rerun the windows view without `--compact-hints` only when exact per-row commands are needed. `--unwrap` only removes the workflow metadata envelope; it does not change the selected view.
+### Step 2 — Inspect Expected Views
 
-### Step 3 — Reuse Existing Knowledge
-
-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.
-
-### Step 4 — Default Path: Direct Finalize
-
-When `align_route.next_command` points to `context align --finalize -`, do not run coarse-read, candidate ops, ledger, or aggregate. Inspect the evidence you need, produce one `align-structure-decision`, and submit it to the returned finalize command. Do not infer route thresholds from source count, token count, or window size; the CLI already made that decision.
-
-Before producing `align-structure-decision`, refresh and apply `references/gates.md`: classify Node type in order (`action` scale + process evidence, then concrete/term `entity`, then child-bearing `domain`), reject fake Entities only when at least two suspicious signals match, keep `term` separate from concrete A/B tags, and provide required `action_gate` / `domain_gate` fields. Classification is about the content referent, not the source title. After type is chosen, rewrite the Node title to fit that type: Entities name concrete objects or atomic terms, Domains name grouping scopes, and Actions name executable processes.
-
-### Step 5 — Staged Path: Batched Review
-
-Use this path only when `align_route.next_command` points to `context align --coarse-read -` or the CLI explicitly returns a batched-review hint. This path is for large or ambiguous scans where the CLI requires a checkpoint before final structure.
+Run `views[].command` entries marked `expected: true` before writing. Use additional `show_view` commands only when listed in `allowed_actions[]` or returned in `how_to_explore[]`.
 
-Submit coarse-read anchors and neutral content signals with `context align --coarse-read - --format json`. Pick `density_profile` using `references/density-profile.md`; content signals describe text shape only, not final Node type. Prefer omitting `schema_version`; the CLI infers single-source vs batch from shape. The latest `align-coarse-read` payload is only the most recent checkpoint; durable multi-source reading notes live in `align-candidate-ledger.source_readings`. For multiple sources, submit one envelope with `coarse_reads[]`; each entry must use the current coarse-read fields (`source_id`, `density_profile`, `reading_anchors`, `section_proposals`), not retired `reading_notes` / `block_readings`.
+Read evidence through semantic CLI views, not shell parsing. Follow `page.next_command` for pagination. Use `--source`, `--heading`, `--window`, and `--token-budget` as view filters only. `--unwrap` removes workflow metadata; it does not expand a compact view into full detail.
 
-After coarse-read is stored, submit candidate ops with `context align --ops - --format json`. Before each batch, refresh the Node classification gates in `references/gates.md`; their TTL is one batch or about ten candidates, whichever comes first. Candidate slugs/titles are provisional: if a source heading says "方案", "架构", "流程", "策略", "演练", or similar scope/process language, do not preserve that wording unless the final Node type really needs it. Use `local:<name>` only inside the current batch. Prefer omitting `schema_version`; the CLI normalizes candidate ops to the current schema. `--ledger-digest <digest>` is optional; usually omit it and pass it only when you intentionally want stale-batch rejection for a high-assurance retry. The CLI reducer assigns durable candidate ids. For `merge_into`, `supersede`, and `reject`, include the required `*_label_hint` fields from the visible candidate labels.
+If a blocks view returns `align-blocks-read-incomplete`, `page.has_more`, or `truncated: true`, treat that response as a partial read. Do not finalize source-wide ownership or dense planned Sections from source-mapping/headings alone; follow `page.next_command` or the `how_to_explore[]` source full-read / expand-budget command first, then decide whether to write, split, or leave evidence as context.
 
-Then read the candidate state 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. Review `anomaly_signals[]`; address clear mistakes with another ops batch, otherwise continue to finalize. These signals are warnings and do not by themselves block finalizing.
-
-### Step 6 — Follow Hints
-
-At any point, if the CLI returns `agent_hints[]`, follow the provided `command` / `next_action` before retrying. Legacy-protocol hints mean the submitted payload/schema is retired; switch to the named current schema instead of reshaping old fields.
-
-### Step 7 — Finalize Structure
-
-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. Do not automatically add the original source title as an alias. Submit it through stdin with `context align --finalize -`; the CLI resolves the current align-segments payload. 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.
+### Step 3 — Reuse Existing Knowledge
 
-   For code-projection Nodes, "existing knowledge file" and "previous finalized prose ownership" are different states. A freshly projected code Node can be reused by declaring the same slug in the current finalize payload and planning only prose-owned Sections for the current evidence. Compile merges the prose source and Sections into the existing code Node while preserving code metadata and code-owned Sections. Prose Sections must cite document evidence, not `aspect:code:*` source refs.
+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.
 
-   `nodes[].planned_sections` is the distinct set of Section kinds used as compile scaffolding for that Node, not a hard completion gate. List each kind at most once; do not copy `sections[].section_kind` one-for-one when a Node has multiple Sections of the same kind.
+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.
 
-   Each `sections[].block_ids` entry must be one contiguous run of citation-eligible blocks from one source. If one conceptual Section spans gaps, split it into multiple `sections[]` plans or include the intervening citation-eligible blocks. The CLI rejects non-contiguous plans at finalize so compile does not have to rediscover the split later.
+### Step 4 — Classify Semantic Structure
 
-   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.
+Apply `references/gates.md` before authoring Nodes: classify Node type in order (`action` scale + process evidence, then concrete/term `entity`, then child-bearing `domain`), reject fake Entities only when at least two suspicious signals match, keep `term` separate from concrete tags, and provide required gate evidence.
 
-   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. This is the expected placeholder-domain shape when the graph/slug is useful but the source has no citation-worthy body content. Compile close will create an empty placeholder Node with no active Sections.
+Source titles and headings are ordinary evidence, not structural authority. Choose titles and summaries that fit the final Node type and the CLI-provided generation policy.
 
-   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.
+For large or batched payloads, use `references/density-profile.md` and `references/candidate-resolution.md` only when the CLI `next_action` asks for coarse-read or candidate-op payloads. Do not choose those stages yourself.
 
-   - `owned`: exactly one slug in `owners[]`, plus `visible_to[]` and `reason`. Do not include `primary_owner` 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 raw preview and must request full text or raise an ownership challenge before citing it), `visible_to[]`, `reason`. Do not include `question_id`.
-   - `context_only`: **omit `owners` and `primary_owner` entirely.** Required: `visible_to[]`, `reason`. Do not include `question_id`. Also use this for **external-URL reference-link blocks** (orphan `[label]: https://...` / `[label]: http://...` definitions, including ByteDance internal hosts and Lark / docs wikis) when no Node in this batch clearly owns the references — the URLs themselves are unique knowledge not duplicated in body prose, so they must stay reachable downstream even if no inline body usage exists. `context_only` keeps those URLs as raw background only; compile must not cite them as active Sections unless a later ownership patch upgrades the block to `owned` / primary `shared`.
-   - `ignored`: **omit `owners`, `primary_owner`, and `visible_to`.** Required: `reason`. Use for outdated markers, **intra-workspace navigation lines** (`Parent:` / `Children:` / `Related:` / `Relations:` rows whose targets are other Nodes already represented in the align graph), and placeholders without independent knowledge. **Do not put external-URL reference-link blocks here** — those carry unique URLs that the align graph cannot reconstruct; route them to `context_only` (or `owned` / `shared` if a Node should author a citation-eligible "相关链接" Section). Do not include `question_id`.
-   - `unresolved`: **omit `owners` and `primary_owner`.** Required: `question_id` (matching a top-level `unresolved[].question_id`) and `reason`. Use when classification is blocked by missing evidence.
+### Step 5 — Build The Payload Requested By `next_action`
 
-   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.
+Use `next_action.input_schema` or the matching `context schema <name> --view minimal --format json` output to shape the payload.
 
-   If finalize returns an `align-finalize-draft` payload, patch the saved draft instead of rewriting the whole finalize document. Use JSON Pointer paths from the returned issues and submit only the corrections. Patch paths are relative to `raw_decision`, so use `/nodes/...`, `/sections/...`, or `/block_ownership/...`, not `/raw_decision/...`:
+For `submit_structure_decision`, produce one structure-decision document with finalized Nodes, document edges, planned Sections, and ownership. Planned Sections must carry the strongest source-backed `section_kind` that fits the current schema priority chain; do not plan an entire dense source as `description` when the evidence clearly contains examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Keep only source-supported semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
 
-   ```json
-   {
-     "schema_version": "align.finalize-patch.v1",
-     "operations": [
-       { "op": "replace", "path": "/block_ownership/3/primary_owner", "value": "rspack" }
-     ]
-   }
-   ```
+For coarse-read, candidate-op, patch, ownership, or rescan actions, follow the command and schema in the returned `next_action`. Do not carry old candidate-table, decision-patch, or full-tree payload shapes forward.
 
-   Submit it with `context align patch draft --input - --format json`. Add `--payload-digest` only when you intentionally want an explicit stale guard. If issues remain, patch the remaining issue paths; if validation passes, the CLI commits the finalized workflow artifacts.
+### Step 6 — Validate And Submit
 
-   After finalize has succeeded, do not resend the full structure just to correct a few block roles. Submit a narrow ownership patch against the current finalized ownership digest:
+Before finalizing a structure decision, run `context align validate --input - --format json`. If validate returns blocking diagnostics, repair the exact paths it reports and rerun validate. If validate returns a finalize `next_action`, submit the same validated payload to that command.
 
-   ```json
-   {
-     "schema_version": "align.ownership-patch.v1",
-     "base_digest": "sha256:<finalized-ownership-digest>",
-     "block_ownership": [
-       {
-         "block_id": "<block-id>",
-         "ownership_role": "owned",
-         "owners": ["<node-slug>"],
-         "visible_to": ["<node-slug>"],
-         "reason": "Why this block is citation evidence for the node."
-       }
-     ]
-   }
-   ```
+If any write is rejected, follow the returned `next_action` and `reason_code`. Do not retry by guessing direct/batched stages, forcing route bypasses, or editing workflow files.
 
-   Submit it with `context align patch ownership --input - --format json`. Keep `base_digest` in the patch body when you want stale ownership rejection. Use `context schema align-ownership-patch` when uncertain.
+### Step 7 — Self-verify
 
-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.
+- [ ] All writes followed top-level `next_action.command`. If not, return to **Step 1**.
+- [ ] Evidence was read through `views[].command`, `how_to_explore[]`, or CLI schema/protocol commands only. If not, return to **Step 2**.
+- [ ] Node classification used the semantic gates in `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**.
+- [ ] Structure decisions passed `context align validate --input - --format json` before finalize. If not, return to **Step 6**.
+- [ ] No raw, cache, knowledge, `/tmp`, host tool-results, or workflow scratch files were read or written with generic tools. If violated, restart from **Step 1**.
 
 </procedures>