@c4a/context-cli 0.5.35-beta.3 → 0.5.36-beta.1

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

@@ -1,30 +1,29 @@
 ---
 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.
+- `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 +32,53 @@ 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.
-
-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. 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>

package/plugin/skills/skill-align-workflow/references/candidate-resolution.md

@@ -57,4 +57,4 @@ block_ownership:
   - owners: [local:data-region]
 ```
 
-Refs may point to `llm_slug_hint` or final `slug`; prefer `*_ref` fields when a schema provides them. If the CLI rejects an unknown ref, use the returned `agent_hints[].available_node_refs` and resubmit a corrected `align-structure-decision`.
+Refs may point to `llm_slug_hint` or final `slug`; prefer `*_ref` fields when a schema provides them. If the CLI rejects an unknown ref, use the top-level envelope diagnostics (`issues[].expected_shape.available_node_refs`, `diagnostics.*.available_node_refs`, or the returned repair view) and resubmit the corrected `align-structure-decision` payload. `agent_hints[]`, when present, is only a cutover mirror and must not be the source of truth.

package/plugin/skills/skill-align-workflow/references/density-profile.md

@@ -2,6 +2,8 @@
 
 Use `density_profile` in `align-coarse-read` to describe how much structure the document needs before candidate discovery. This is a reading strategy, not a quality score.
 
+This reference applies only when the current envelope asks for `next_action.kind: "submit_coarse_read"`. A small or moderate direct route should follow `validate_align_decision`; do not emit a `single_pass` coarse-read payload unless the CLI requested coarse-read.
+
 | Profile | Use When | Agent Behavior |
 |---|---|---|
 | `macro` | A long source has many headings, sections, or broad topic shifts. | Create section proposals around major headings and preserve document-level anchors so later passes do not flatten scope. |

package/plugin/skills/skill-compile-close/SKILL.md

@@ -32,7 +32,7 @@ command. It does not hand-edit rendered knowledge.
   - Source issues (`dropped-source-reference`) → user runs `/context:drop <id>` to complete the drop
 - Exit 0 → summarise node/section totals, verify, `recompiled`, `locator_updates`, `rebuilt`, fingerprint rebuild count, archive status / archived file count, and any `ready_with_debt` coverage warnings when printed; then stop.
 - Exit 2 → report the full issue list verbatim + point at the right re-entry command above. Do not hand-open the affected rendered article.
-- Coverage warning choice: `ready_with_debt` means close succeeded and unresolved coverage remains visible. First inspect `context workflow show --payload coverage-candidates --view coverage-summary --token-budget 2000 --unwrap --format json`; use each group's neutral `available_actions[]` and narrow with `--view coverage --type <issue-type>` or `--node <slug>` when needed. You may either continue with the warning recorded, or run an uncovered-only repair/skip round. If all unresolved candidates are intentionally excluded for the same reason, use `context compile coverage <slug> --skip-unresolved --reason "<reason>"`; otherwise inspect `context schema coverage-disposition`.
+- Coverage warnings are CLI-owned diagnostics. `ready_with_debt` means close succeeded and unresolved coverage remains visible; report the warning and follow returned coverage view commands / `available_actions[]` only if the user chooses a repair or skip round.
 - Materialized knowledge means either a CLI-written knowledge article, or an explicit no-write placeholder from align: `planned_sections: []` plus source/context/graph support. A compile skip action records reviewed evidence, but it does not by itself materialize an arbitrary finalized Node.
 - Never re-run `context compile draft` from close to paper over verify failures. Draft failures belong in the draft loop.
 - Do not use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect `WORKSPACE_DIR`, `.context`, knowledge files, or `/tmp` workflow artifacts.
@@ -63,7 +63,7 @@ Close is one in-process command with one exit code:
 | Outcome | Agent action |
 |---|---|
 | Exit 0, 0 issues | Summarise those counts in the user's language: Nodes touched; Sections added / updated / superseded / deprecated / skipped; `recompiled`; `locator_updates`; `rebuilt`; verify green. Stop. |
-| Exit 0, warnings only | Summarise + list warnings verbatim. For coverage warnings, name both choices: continue with `ready_with_debt`, or run an uncovered-only repair/skip round through `context compile coverage <slug> --skip-unresolved --reason "<reason>"` or `context schema coverage-disposition`. Stop. |
+| Exit 0, warnings only | Summarise + list warnings verbatim. For coverage warnings, surface the CLI-returned coverage view commands / `available_actions[]` instead of inventing a local decision matrix. Stop. |
 | Exit 2, Section / content issue | Surface the full issue list; point the user at re-running `/context:compile` (the draft loop owns Section writes). Do NOT Edit the affected rendered article. |
 | Exit 2, `compile-close-finalized-node-missing-knowledge` | If the missing Node has real citation evidence, point the user at `/context:compile` for that Node. If it is intentionally navigation-only or placeholder-only, point the user at `/context:align` to make it explicit no-write with `planned_sections: []` and context-only/ignored relation or placeholder blocks. |
 | Exit 2, structural issue (cycle, duplicate slug, `invalid-node-type`, `domain-same-file-child`) | Surface the full issue list; point the user at `/context:align` to revise structure. Do not re-run compile. |
@@ -118,12 +118,8 @@ Summarise in the user's language:
 
 Stop. Do not auto-invoke follow-on commands.
 
-### Step 5 — Self-verify
+### Step 5 — Final guardrails
 
-- [ ] `context compile close` ran exactly once per close call — if not, **Step 1**.
-- [ ] If exit 2, every error is surfaced to the user with a re-entry command (compile / align / drop); no silent ignores — **Step 3**.
-- [ ] No agent-hand edits to rendered knowledge — if any, revert; the close stage is read-only for knowledge content.
-- [ ] No Read / Glob / Grep / Write was used against `WORKSPACE_DIR`; CLI-owned output archival is allowed.
-- [ ] No ad-hoc script or shell file traversal was used against `WORKSPACE_DIR`, `.context`, or `/tmp` workflow artifacts.
+Run close once, surface every error with its re-entry command, and never inspect or edit rendered knowledge outside the CLI.
 
 </procedures>

package/plugin/skills/skill-compile-draft/SKILL.md

@@ -5,8 +5,8 @@ description: >
   the CLI-provided `NodeContext` (planned metadata, raw snippets, and
   existing Sections if any), classifies every raw fragment into a Section
   kind via the priority chain, writes `content` + optional `summary` + `source_refs[]`,
-  and emits a compile draft JSON document. The CLI
-  validates the actions via `context compile draft <slug> --input -`.
+  and emits a compile draft JSON document for the caller to submit to the current envelope's
+  `next_action.command`.
   Activates when `/context:compile` iterates across the confirmed align plan.
 tools:
   - Bash
@@ -19,16 +19,16 @@ Classify raw evidence for one Node into `add` / `skip` (and on refresh: `update`
 ## TL;DR — Non-negotiables
 
 - One Node per invocation — `target_node` MUST equal `node.slug`; no cross-Node writes. Finish the current Node's draft quality checks before the caller moves to another Node's review/apply loop.
-- Agent emits JSON only; no markdown, no direct workspace file writes. The caller passes the JSON to `context compile draft <slug> --input - --prepare`; the CLI stores workflow payloads. `--save-input` is only for an explicit debug scratch copy.
-- Evidence boundary: treat `raw_snippets[]` as complete. Only `raw_snippet_indexes.citation_eligible` may be cited; `context_only` and secondary-shared snippets are background. `request_full_text` may expose full visible evidence text for inspection, but use the narrow text view (`context compile context <slug> --request-full-text <block_id> --view text --format json`) and read `items[].text`; long blocks are paged, so follow `items[].next_command` when present. `request_full_text.pages[].text` and `raw_snippets[].quote` may mirror the same page text in full NodeContext outputs, and it does not change citation eligibility. If a secondary-shared or `context_only` block holds facts that need citation, emit `pending_ownership_challenge` or `structure_challenge` — see [references/structural-challenges.md](references/structural-challenges.md). Never `grep` / `sed` / `jq` / `cat` / `head` raw `--format json` stdout or workflow scratch files in `/tmp` or `.context/.cache/` to recover a token. Instead: for the digest of any workflow payload use `context workflow show --payload <name> --digest-only --format text` (prints just the digest); for substructure use explicit semantic views such as `context compile context <slug> --view source-refs --token-budget 2000 --format json`, `context workflow show --payload node-context --view source-refs --token-budget 2000 --unwrap --format json`, or `context workflow show --payload prepare --view issues --unwrap --format json`; follow returned `next_command` for paged views and `how_to_explore[]` when the view is truncated. For write commands that take `--payload-digest`, omit the flag entirely and let the CLI auto-resolve the latest payload for the current workflow scope.
+- Agent emits JSON only; no markdown, no direct workspace file writes. The caller submits the JSON to the current envelope's `next_action.command`; the CLI validates and stores workflow payloads.
+- Evidence boundary: treat the CLI-provided NodeContext and evidence views as complete. Cite only refs surfaced in `citable_source_refs[]` or `raw_snippet_indexes.citation_eligible`; treat `supporting_context_refs[]`, `context_only`, and secondary-shared snippets as background. `request_full_text` may expose visible text for inspection through the narrow text view (`context compile context <slug> --request-full-text <block_id> --view text --format json`), and it does not change citation eligibility. If supporting/context-only evidence is needed as a citation, emit `pending_ownership_challenge` or `structure_challenge` — see [references/structural-challenges.md](references/structural-challenges.md). Never `grep` / `sed` / `jq` / `cat` / `head` raw `--format json` stdout or workflow scratch files in `/tmp` or `.context/.cache/`; use semantic views and follow returned `next_command` / `how_to_explore[]`. For write commands that take `--payload-digest`, omit the flag unless the CLI explicitly asks for a stale guard.
 - Actions are candidate write actions, not final semantic decisions; `context reconcile prepare` re-derives near-duplicate / conflict / merge relations from `candidates[]` on its own. Op naming is scoped by schema: compile-draft `actions[]` already targets Sections, so Section lifecycle ops are verb-only (`add`, `update`, `supersede`, `deprecate`, `skip`). Do not use align-style names such as `add_section`, `write_section`, or `propose_section`.
 - Source support passing is not completion. Before emitting, estimate coverage from the provided `raw_snippets[]`: if there are 3+ citation-eligible snippets, a one-action draft is valid only when the later snippets are duplicates, navigation, placeholders, or continuations of the same fact. Small dense docs still need multiple actions when later snippets state distinct capabilities, constraints, examples, risks, FAQ, or usage notes. Large manuals/design docs should compile to several orthogonal actions in the same draft. Do not switch into "speed mode" because the first action validates; coverage is part of the draft task.
-- Pick `kind` by the [Section Kind Canon](#section-kind-canon), also exposed as `section_kind_priority` in `context schema compile-draft`. First matching form wins. A `decision` needs at least two surfaced alternatives plus a reason; bare "we use X because Y" is `spec`. Reach `description` only after every more specific kind fails.
+- Pick `kind` from the CLI's `context schema compile-draft` contract, especially `section_kind_priority` and the mount matrix. First matching form wins. A `decision` needs at least two surfaced alternatives plus a reason; bare "we use X because Y" is `spec`. Reach `description` only after every more specific kind fails.
 - `node.planned_sections[]` is an align-time scaffold hint, not a hard completion gate. Prefer a planned kind when the evidence fits; if a source-backed stronger kind differs, emit it and let the CLI warning guide review.
 - `kind × node.type` must satisfy the CLI Section mount matrix; mismatches get rejected at write time. When the strongest kind is blocked by mount matrix, fall to the next legal kind whose form actually fits — do not collapse to `description` just because it mounts everywhere, and do not invent thin precision (e.g. one-line `spec`) just to avoid `description` either. See [Description anti-abuse gates](#description-anti-abuse-gates) for the classification checks at the description boundary.
 - Every write action cites raw via `source_refs[]`, choosing values from `raw_snippets[].source_ref`. Use a single-element array for one citation. Treat each source ref as an opaque citation token; never fabricate, parse, dereference, or cite navigation-only blocks as evidence for a content Section.
 - Use `content` for the Section text the reader should see. It may be long and may contain URLs, tables, commands, config, or code fences. Add `summary` for long content or when it helps readers/query output; omit it when content is short. Summary quality checks are warning hints only, not schema or evidence failures. The CLI rejects retired fields (`body`, `detail`, `raw`, singular `source_ref`, quoted-evidence) with canonical repair hints — read those hints rather than memorising the blacklist. Omit optional fields when empty.
-- Preserve documentation/reference URL blocks. If a citation-eligible raw block is primarily links (官网 / docs / reference / related links), create a small `description` Section such as "相关链接" and keep every URL in `content`; do not drop link-only evidence just because it is not prose. If the URL block is only `context_only`, keep it as background and emit an ownership/structure challenge instead of citing it.
+- Preserve literals required by the CLI. When source-refs or scaffold output lists `required_preserved_literals[]`, keep those URL, code identifier, `source_ref`, or `block_id` literals visible in the relevant `content`, `summary`, skip reason, or repair challenge. Do not rely on memorized URL rules; let CLI literal fields and citation diagnostics define what must be preserved.
 - `refers_to_nodes[]` only carries slugs present in the context's glossary, existing Sections, or the current align plan; never invent one.
 - `skip` is the honest default when raw adds nothing. Bare `skip` (no `source_refs[]`) is only for deterministic no-ops such as unchanged input or pure navigation. When a snippet was reviewed and intentionally not written, emit `skip` with `source_refs[]` from that snippet so semantic review can record `reviewed_no_write`.
 - Any Node may legitimately compile to no Sections when the provided snippets contain only navigation (`Parent` / `Children` / `Related` / `Relations`) or placeholder text that explicitly says no detailed content is available. Emit `skip`; do not turn align summaries, parent/child lists, sibling links, or placeholders into `description` Sections. The align graph and Node metadata preserve structure; active Sections need citation-eligible content.
@@ -69,57 +69,15 @@ Main-path ops are **`add`** and **`skip`**. A typical new Section action is `{ o
 
 `source_refs[]` values are copied verbatim from `raw_snippets[].source_ref`; a single citation is still a single-element array. When one Section summarises contiguous multi-block evidence, list only the source refs the `content` actually consumes. If the CLI reports `compile-source-refs-auto-narrowed`, it safely reduced an over-wide citation; removed refs are still uncovered, so add separate actions for distinct knowledge or leave them to an evidence-carrying `skip`. Preserve raw wording in `content` when it is already clear. Preserving a cited prose/bullet list as the Section's user-facing content is allowed when that list is the actual knowledge; the anti-pattern is copying raw text only as traceability or lexical-score padding. For `example` Sections that cite command / config / code fences, include the relevant fenced block in `content`.
 
-## Section Kind Canon
-
-Walk this priority chain and stop at the first form that fits:
-
-```
-example -> comparison -> faq -> incident -> changelog ->
-decision -> spec -> warning -> principle -> description
-```
-
-| kind | Use when | `content` should contain | Positive / negative boundary |
-|---|---|---|---|
-| `example` | fenced code, config, or command sample | what the sample does plus the full snippet when useful | `<AppProvider />` sample or `bun run build`; plain "wrap with AppProvider" is `description` |
-| `comparison` | at least two subjects across at least two dimensions | compared subjects, dimensions, and table/matrix | `X vs Y vs Z` table; "two options have tradeoffs" is `description`; "choose X over Y" is `decision` |
-| `faq` | one explicit question-answer pair | question plus answer | Q/A block; an "X FAQ collection" is several `faq` Sections on X, not a container Node |
-| `incident` | happened event with time, impact, and root cause / handling | time, severity/impact, root cause, timeline/actions | dated outage postmortem; "risk may happen" is `warning` |
-| `changelog` | version/date plus change description | version, change type, migration notes if present | `v1.2.0 added X`; "X supports Y" without version is `spec` or `description` |
-| `decision` | text surfaces at least two alternatives plus a reason | selected option, alternatives, reason, impact | "choose async rather than sync because..."; bare "use X because..." is `spec` |
-| `spec` | verifiable behavior, threshold, default, limit, or check method | object, condition, value/constraint | retry max 3; vague "consider concurrency" is `principle` or `description` |
-| `warning` | factual risk, caveat, or negative consequence | trigger condition and consequence | "without warmup first 30s timeout"; "don't change config" without consequence is too vague |
-| `principle` | stable design invariant / philosophy with no check method and no choice action | invariant and reason | "single way to write UI"; retry max 3 is `spec`; "choose X over Y" is `decision` |
-| `description` | fallback definition, overview, or plain narrative | definition, purpose, scope, distinction | only after the nine kinds above fail; do not use it to hide lists, rules, tables, samples, risks, or decisions |
-
-Mount matrix:
-
-| kind | domain | entity | action |
-|---|:---:|:---:|:---:|
-| `description` | yes | yes | yes |
-| `spec` | no | yes | yes |
-| `warning` | yes | yes | yes |
-| `principle` | yes | yes | no |
-| `decision` | yes | yes | yes |
-| `incident` | no | yes | yes |
-| `example` | no | yes | no |
-| `changelog` | no | yes | no |
-| `comparison` | no | yes | no |
-| `faq` | yes | yes | yes |
-
-When the strongest kind is not mountable on this Node type, choose the next legal kind that the evidence truly supports, or `skip` with a structural challenge reason. Do not force `description` just because it mounts everywhere.
-
-## Confidence rubric
-
-Four legal values; pick per raw evidence strength.
-
-| `confidence` | When |
-|---|---|
-| `verified` | Raw shows the fact already happened or held — recorded run output, observed metric value, incident timestamp, benchmark result, or explicit "ran X, got Y" log. Executable form alone is not enough; without execution evidence, downgrade to `confirmed`. |
-| `confirmed` | Raw states the fact in normative voice or as a documented spec / config / example, without showing the run that confirmed it. This is the default for code blocks, configuration samples, feature lists, and design rules. |
-| `inferred` | You combined ≥2 raw fragments into a load-bearing conclusion that no single fragment states. |
-| `speculative` | Raw only hints; the Section is a best-effort reading that may not survive review. |
+## Section Kind Choice
+
+Use `context schema compile-draft --view minimal --format json` (or yaml) for the current legal kind list, priority order, and mount matrix. This skill adds only semantic guardrails:
+
+- Stop at the first kind whose source-backed form fits.
+- Do not choose `description` to hide lists, rules, tables, samples, risks, choices, or Q+A evidence that has a more precise kind.
+- When the strongest kind is not mountable on this Node type, choose the next legal kind that the evidence truly supports, or `skip` with a structural challenge reason.
 
-Don't game the rubric. Compile-close flags Nodes dominated by `speculative` Sections, and a Node whose Sections are uniformly `verified` despite raw containing only specs / samples is the symptom of a misread rubric, not strong evidence.
+Confidence is optional. Omit it for ordinary confirmed claims; set it only when the evidence is clearly verified, inferred, or speculative according to the schema enum.
 
 ## Description anti-abuse gates
 
@@ -160,20 +118,14 @@ Check edge case conditions from the routing table at the top of this skill. If a
 
 Estimate coverage from the provided `raw_snippets[]` before writing actions. Treat "the first quote is supported" as only a validation result, not a completion signal.
 
-Coverage self-check:
-
-1. Count citation-eligible, non-navigation snippets and group them by `block_locator_id` heading prefix.
-2. For 3-11 such snippets, read each snippet once. If later snippets are distinct facts, emit separate actions before moving to the next Node. Do not stop after one supported description just because the file is short.
-3. For roughly 12+ citation-eligible snippets or 5+ distinct locator areas, plan multiple Sections in this single draft. Large manuals/design docs usually need several orthogonal actions.
-4. This is not a quota: skip duplicates, navigation-only blocks, placeholders, and unsupported fragments. The goal is coverage of distinct source-backed knowledge, not maximum Section count.
-5. If `context reconcile prepare` returns `compact-source-low-coverage` or `dense-source-low-coverage`, revise the same draft to cover the suggested uncovered evidence candidates before review/apply. Do not treat those warnings as ignorable polish.
+Use the CLI-provided citation-eligible snippets and diagnostics as the coverage contract. Distinct source-backed facts should become distinct actions or evidence-carrying skips; duplicates, navigation-only blocks, placeholders, and unsupported fragments can be skipped. If later CLI diagnostics report low coverage, repair the same draft through the returned `next_action`.
 
 ### Step 2 — Classify each raw snippet
 
 For each `raw_snippets[]` entry:
 
 1. If the snippet only contains navigation or placeholder evidence (`Parent` / `Children` / `Related` / `Relations`, sibling links, "no detailed content", etc.), emit `skip`. Do not create a Section whose content is just "Children: ..." or "Related: ..." and do not summarize facts that are not present in the snippet.
-2. Walk the Section kind priority chain from [Section Kind Canon](#section-kind-canon); stop at the first kind whose trigger fires.
+2. Pick kind using [Section Kind Choice](#section-kind-choice); stop at the first kind whose trigger fires.
 3. Verify the kind against the mount matrix for `node.type`. Mismatch → pick the next legal kind down the chain, or emit `skip` with a reason pointing at a better Node. Never "fall through to description" just to place evidence.
 4. If you land on `description`, walk the [Description anti-abuse gates](#description-anti-abuse-gates). Any gate fires → split or `skip`.
 
@@ -190,9 +142,9 @@ For each classified snippet:
    - There is no separate default `evidence-echo` warning. Treat "echo" as an anti-pattern: raw copied only to show basis/evidence, while `source_ref` already provides traceability.
    - For `description` / `spec`, a concise summary plus the cited bullet list is acceptable when the bullets are the useful user-facing knowledge. It becomes echo only when the copied text is not meant to be read as active knowledge.
    - For `example` Sections that cite a code, config, or command fence, keep `content` centered on the cited fenced block. Put framing prose such as "basic configuration example" in `summary`, or cite a separate prose block in a separate action when that prose is itself source-backed knowledge.
-3. If `content` is longer than 200 characters, add `summary`. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, about `content.length / 10`, minimum 10 characters, recommended maximum 120. The CLI reports missing, long, short, or formatted summaries as warning hints only; it does not auto-generate them and does not treat them as evidence failures. `source_support` hard-term matching checks `content` (and legacy `detail` when present), not `summary`; keep summaries faithful to `content`, but do not copy raw-only keywords into `summary` for lexical scoring.
-4. If the cited block contains documentation/reference URLs, preserve them in `content`. Link-only blocks are still useful knowledge; use `kind: description` with a concise "相关链接" identity when no more specific kind applies.
-5. Omit `confidence` for ordinary confirmed claims. Assign `confidence` per the [Confidence rubric](#confidence-rubric) only when the evidence is not confirmed.
+3. For long `content`, add `summary` when it helps readers or query output. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, and should stay compact. The CLI only reports advisory hints for missing summaries on long content, Markdown/multi-paragraph formatting, or clearly overlong summaries; it does not enforce a content-length ratio and does not treat summary quality as an evidence failure. `source_support` hard-term matching checks `content` (and legacy `detail` when present), not `summary`; keep summaries faithful to `content`, but do not copy raw-only keywords into `summary` for lexical scoring.
+4. Preserve `required_preserved_literals[]` from the CLI evidence view. For link-heavy citation-eligible evidence, keep the listed URLs in `content` when the action writes knowledge; for supporting-only literals, keep them in the repair/challenge context instead of citing them.
+5. Omit `confidence` for ordinary confirmed claims. Assign it only when the evidence is clearly verified, inferred, or speculative according to the schema enum.
 6. Fill `refers_to_nodes[]` per [Glossary and refers_to_nodes](#glossary-and-refers_to_nodes).
 7. Cite evidence with `source_refs[]`, picking values from `raw_snippets[].source_ref`. When one Section summarizes contiguous multi-block evidence, list only the source refs consumed by that Section content; the CLI verifies that the refs can collapse to one canonical citation token and may auto-narrow over-wide citations. If the evidence is non-contiguous or contains separable claims, split the draft into separately cited actions instead of stretching one action across unrelated blocks. For `skip`, include `source_refs[]` only when the skip represents reviewed no-write material; omit evidence for purely deterministic no-ops such as unchanged input. Never submit singular `source_ref` or quoted-evidence fields; the CLI rejects them.
 
@@ -200,15 +152,8 @@ Rendered knowledge starts with optional `c4a:summary`, then the active `content`
 
 ### Step 4 — Emit the JSON
 
-Emit one compile draft JSON document for the caller to pass to `context compile draft <slug> --input - --prepare`. No markdown wrapper, no leading prose, no trailing commentary.
-
-### Step 5 — Self-verify
+Emit one compile draft JSON document for the caller to submit to the current envelope's `next_action.command`. No markdown wrapper, no leading prose, no trailing commentary.
 
-- [ ] Every action's `target_node` equals `node.slug`, with a legal `kind × node.type` combination and `content` + optional `summary` + `source_refs[]` only (no singular `source_ref`, no `body` / `detail` / `raw`, no quoted-evidence or extractive-contract fields, no new terms absent from the cited raw). If not, return to **Step 2** for kind/mount-matrix issues, otherwise **Step 3**.
-- [ ] Every `description` action survives the [Description anti-abuse gates](#description-anti-abuse-gates). If not, **Step 2** to split or `skip`.
-- [ ] Coverage matches evidence density: dense raw with one broad action returns to **Step 2** unless remaining snippets are duplicates / navigation / placeholders / already covered. Citation-eligible URL blocks are either preserved or `skip`-with-evidence.
-- [ ] `skip` semantics: bare `skip` only for deterministic no-op (unchanged input or pure navigation); reviewed-no-write `skip` carries `source_refs[]` from the cited snippet. When raw adds nothing, exactly one `op: skip` with a reason — not `actions: []`. If not, **Step 3**.
-- [ ] If any edge case condition applies (action/domain Node, note snippets, existing Sections, non-changed-only incremental, or structural defect), the relevant reference's Self-verify items were also satisfied.
-- [ ] NodeContext was the only evidence source — no Read / Glob / Grep / Write / ad-hoc script or shell file traversal against `WORKSPACE_DIR`, `.context`, `/tmp` workflow artifacts, or CLI `--format json` stdout. If any was used, restart from the CLI-provided NodeContext.
+Before returning, ensure `target_node` matches `node.slug`, fields conform to `context schema compile-draft`, `required_preserved_literals[]` are preserved or carried into an evidence-backed skip/repair challenge, and NodeContext was the only evidence source.
 
 </procedures>

package/plugin/skills/skill-compile-draft/references/structural-challenges.md

@@ -62,7 +62,7 @@ Supported `structure_challenge.kind` values: `missing_action_node`, `extra_actio
 }
 ```
 
-Different `kind` values demand different sub-fields. The CLI returns `agent_hints[].correct_shape` on shape errors; follow that hint rather than guessing.
+Different `kind` values demand different sub-fields. On shape errors, follow the CLI's top-level diagnostics / `expected_shape` / returned repair `next_action` instead of guessing. `agent_hints[]`, when present, is only a cutover mirror and must not be the source of truth.
 
 ## What these are NOT
 

package/plugin/skills/skill-compile-judge/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: skill-compile-judge
 description: >
-  Packaged skill invoked by `/context:compile`; not a user slash command. Consumes the full compile prepare payload,
-  judges each draft action's source support and relation to listed candidates,
-  and emits a compile.judge-decisions.v1 document for `context reconcile review`.
+  Packaged skill invoked by `/context:compile`; not a user slash command. Consumes the budget-safe compile prepare summary
+  and candidate detail views, judges each draft action's source support and relation to listed candidates,
+  and emits a compile.judge-decisions.v2 document for `context reconcile review`.
 tools:
   - Bash
 ---
@@ -16,9 +16,10 @@ decisions only; the CLI reviews, applies, and writes every workspace change.
 
 ## TL;DR — Non-negotiables
 
-- Input is the full compile prepare payload. Compact summaries are only a pointer; if needed, load the full payload with the `workflow_payload.show_command` from `context compile draft ... --prepare`.
+- Invoke this skill only when the caller's top-level envelope has `next_action.kind: "review_reconcile_decisions"` or the prepare payload contains `judge_handoff`. If the active envelope asks for `patch_compile_draft`, `continue_compile_cycle`, or another action, stop and follow that `next_action.command` instead.
+- Input is the budget-safe compile prepare summary. For items with candidates, load only that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`.
 - Do not inspect workspace storage directly or run ad-hoc scripts to reconstruct candidates. Use only `items[]`, `evidence[]`, `source_support` diagnostics, `candidates[]`, `previous_decisions[]`, and `judge_handoff`.
-- Output exactly one JSON or YAML document with `schema_version: "compile.judge-decisions.v1"` and `decisions[]`.
+- Output exactly one JSON or YAML document with `schema_version: "compile.judge-decisions.v2"` and `decisions[]`.
 - Keep one decision per prepared `item_id`, preserving prepare order.
 - For support, output `support_verdict: supported | weak | unsupported` plus `support_reason`.
 - For relation, output `relation_verdict: new | duplicate | supersede | conflict | merge_into` plus `relation_reason`.
@@ -35,7 +36,7 @@ decisions only; the CLI reviews, applies, and writes every workspace change.
 ## Output Shape
 
 ```yaml
-schema_version: "compile.judge-decisions.v1"
+schema_version: "compile.judge-decisions.v2"
 mode: compile
 decisions:
   - item_id: claim-001
@@ -50,7 +51,7 @@ decisions:
 For a relation against an existing candidate:
 
 ```yaml
-schema_version: "compile.judge-decisions.v1"
+schema_version: "compile.judge-decisions.v2"
 mode: compile
 decisions:
   - item_id: claim-002
@@ -80,10 +81,11 @@ decisions:
 
 <procedures>
 
-### Step 1 — Load Full Prepare Payload
+### Step 1 — Load Prepare Summary And Candidate Details
 
-If the caller gave compact prepare output, use its workflow payload command to
-load the full `prepare` payload. Do not infer missing candidates from memory.
+Use the caller-provided compact prepare output. For every item with candidates,
+load its candidate detail view before judging relation. Do not infer missing
+candidates from memory or bypass the candidate detail view.
 
 ### Step 2 — Judge Support
 
@@ -101,7 +103,7 @@ candidate list is empty, emit `new` with an empty compared list and
 
 ### Step 4 — Emit Judge Decisions
 
-Return only the `compile.judge-decisions.v1` document. The caller passes it
+Return only the `compile.judge-decisions.v2` document. The caller passes it
 directly to `context reconcile review --decisions -`.
 
 </procedures>

package/plugin/skills/skill-semantic-reconcile/SKILL.md

@@ -19,7 +19,7 @@ only; the CLI performs every write.
 
 ## TL;DR — Non-negotiables
 
-- Input is the full `context reconcile prepare` payload. If the caller handed you a compact prepare summary or `--view issues` payload, load the full payload first with `context workflow show --payload prepare --unwrap --format json` (add `--digest` only as an explicit stale guard). Never `grep` / `sed` / `jq` / `cat` / `head` workflow scratch files or `--format json` stdout to recover prepare fields, and do not Read / Glob / Grep / Write workspace `raw/` / `knowledge/` / `archive/` / `decisions/` — the prepare payload and review output are the only inputs.
+- Input is the budget-safe `context reconcile prepare` summary or issues view. When an item lists candidates, load that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`; request broader detail only when a CLI `next_action` or detail command explicitly asks for it. Never `grep` / `sed` / `jq` / `cat` / `head` workflow scratch files or `--format json` stdout to recover prepare fields, and do not Read / Glob / Grep / Write workspace `raw/` / `knowledge/` / `archive/` / `decisions/` — the prepare payload and review output are the only inputs.
 - Ordinary compile prepare judgment belongs to `skill-compile-judge`. Use this skill for refresh/drop/non-compile reconcile, or when compile review asks for scope/omit/user-confirmation reasoning that is outside the judge handoff.
 - Output: one YAML or JSON document conforming to `context schema semantic-decisions --format yaml`. The schema defines canonical `relation` and `action` enums and the per-action required fields; do not memorise the enum list from this skill.
 - Accept a prepared `default_decision` with the compact form `{ item_id, accept_default: true }` (optionally `decided_by` / `rationale`); the CLI hydrates `target` / `proposed`. Empty `decisions: []` means "no items in prepare," not "accept all defaults." Without `--accept-safe-defaults`, emit one compact accept entry per safe default you intend to accept. With `--accept-safe-defaults`, the CLI auto-accepts mechanically safe no-candidate supported writes and reviewed-no-write skips, so emit only the manual decisions that still need judgment.
@@ -37,7 +37,7 @@ only; the CLI performs every write.
 |---|---|
 | `prepare.mode` is `drop` or `refresh` (covers `remove_unsupported` mode semantics, `reanchor`, `split_then_reanchor`) | [references/mode-semantics.md](references/mode-semantics.md) |
 | review returned `support_confirmation`, `omit_confirmation`, `scope_review_required`, or any `ask_user` you need to upgrade to an executable decision | [references/user-confirmation.md](references/user-confirmation.md) |
-| review returned `agent_hints[]` with `code: "context-only-leakage-high"` | [references/leakage-and-ownership.md](references/leakage-and-ownership.md) |
+| review diagnostics or cutover hints returned `code: "context-only-leakage-high"` | [references/leakage-and-ownership.md](references/leakage-and-ownership.md) |
 | items carry `temporal_prior` / `source_captured_at` / `temporal_disposition`, `source_support.evidence_block_*`, or prepared long `proposed.content` / `proposed.summary` | [references/temporal-and-evidence.md](references/temporal-and-evidence.md) |
 | considering `action: omit`, or items look redundant / low-value / scope-wrong | [references/scope-review-and-omit.md](references/scope-review-and-omit.md) |
 
@@ -122,7 +122,7 @@ Drop-mode-only branches (`reanchor`, `split_then_reanchor`, `remove_unsupported`
 
 Emit one document with `schema_version: "1.0"` and `decisions[]`. Include only executable final decisions plus unresolved `ask_user` questions. Do not include prose outside the document.
 
-If the latest review rejected the batch with `context-only-leakage-high`, do not convert it into a generic `ask_user`. Follow [references/leakage-and-ownership.md](references/leakage-and-ownership.md): regenerate the affected decision using one of the review hint's explicit repair options and cited item ids, then rerun `context reconcile review`.
+If the latest review rejected the batch with `context-only-leakage-high`, do not convert it into a generic `ask_user`. Follow [references/leakage-and-ownership.md](references/leakage-and-ownership.md): regenerate the affected decision using the review diagnostic's explicit repair options and cited item ids, then rerun `context reconcile review`.
 
 ### Step 4 — Self-verify
 

package/plugin/skills/skill-semantic-reconcile/references/leakage-and-ownership.md

@@ -1,6 +1,6 @@
 # Context-only leakage and ownership upgrades
 
-Consult this reference when `context reconcile review` returns `agent_hints[]` with `code: "context-only-leakage-high"`. For runs without that hint, ignore this file.
+Consult this reference when `context reconcile review` returns diagnostics or cutover hints with `code: "context-only-leakage-high"`. For runs without that code, ignore this file.
 
 ## What the hint means