@c4a/context-cli 0.6.0-beta.4 → 0.6.0-beta.6

package/plugins/claude/skills/skill-prose-align/SKILL.md

@@ -54,7 +54,7 @@ Use semantic labels, not SDK function names:
 
 Use these rules in the current phase-runner flow:
 
-- Follow the top-level state, `routing.next_commands`, CLI `next_action`, and
+- Follow the top-level state, `routing.command_plan`, CLI `next_action`, and
   CLI-returned `next_command` values for every write. Treat `allowed_actions[]`
   as permission for read-only insertions; it is not a menu of alternate write
   paths.
@@ -200,9 +200,12 @@ context run align:<type>:<source>:<collection> --validate --input <structure.yam
 ```
 
 Validation returns `structure_summary` and writes a temporary HTML report under
-`.tmp/context-runtime/reports/`. Use `structure_report.file_url` as the primary
-user-facing link, and include `structure_report.absolute_path` as a copyable
-fallback. Do not ask the user to confirm a structure they cannot click or open.
+`.tmp/context-runtime/reports/`. A validation report with
+`confirmation_ready=false` is an Agent repair artifact, not a user review gate:
+do not ask the user to approve it. The staged report produced after
+`confirmation_ready=true` is the final review surface; use its
+`structure_report.file_url` as the primary user-facing link and include
+`structure_report.absolute_path` as a copyable fallback.
 If the user needs a focused view, run:
 
 ```bash
@@ -225,14 +228,21 @@ Repair diagnostics by routing them to the right decision:
   structure or keep the relation unresolved;
 - stale structure -> regenerate from the current snapshot hash.
 
-When validation returns a new `next_action.command`, follow that exact command.
-When it returns blocking diagnostics without a write command, repair and
-validate again. Do not stage a structure just because the YAML shape looks
-valid.
+When validation returns `repair_confirmation_blockers`, follow its exact repair
+route without stopping for human confirmation. `--repair suggested-splits`
+mechanically splits non-contiguous source mirror Sections; write its
+`repaired_payload` to a scratch YAML file and validate again. For oversized
+Views, use the returned child-View and contains-edge suggestions, but classify
+each child Node from evidence instead of mechanically inheriting the parent
+type. Repair other diagnostics from evidence and validate again. Ask the user only when evidence
+supports multiple incompatible semantic choices, and label that question as a
+structure-design choice rather than final review. Do not stage until
+`confirmation_ready=true`.
 
 ### Step 4 — Review Structure Before Confirmation
 
-After validation, and again after a draft structure is staged, show the user:
+After validation reports `confirmation_ready=true`, stage the draft. The stage
+command opens the final report. Then show the user:
 
 - node list and planned paths;
 - section ownership;
@@ -250,6 +260,12 @@ hard stop for structure review. Do not ask for a blind "confirm structure"
 reply. Surface the report `file_url`, absolute path, and enough structured
 summary for the user to inspect what will be confirmed.
 
+Do not turn `confirmation_blockers` into a preliminary approval round. A
+validator-required page split, continuous-source split, ref repair, or
+structure-spine connection is work to resolve before staging. If a genuinely
+ambiguous semantic choice needs the user, ask only that choice and then resume
+repair; it does not replace the final report-based confirmation.
+
 Use the host's multi-choice question tool when available. If unavailable, use a
 short Markdown fallback. Good options are:
 

package/plugins/claude/skills/skill-prose-align/references/internal-procedures/structure-planning.md

@@ -216,8 +216,10 @@ material to `unresolved[]`.
 
 For pure suggested-split repairs, prefer the CLI repair view before hand-editing:
 `context run align:<type>:<source>:<collection> --repair suggested-splits --input <structure.yaml> --format json`.
-It only rewrites section ids/source_refs inside the same view. It does not
-create child nodes/views or decide semantic regrouping for you.
+It splits non-contiguous Section mirrors. Oversized Views still require the
+Agent to apply the returned child-View and contains-edge suggestions while
+classifying every child Node from evidence. The repair command does not resolve
+orphan ownership, unsupported evidence, or competing semantic groupings.
 
 When the cited source sentence itself is uncertain, preserve that uncertainty on
 the edge with `confidence: possible` or `confidence: hypothesis`. This is only
@@ -251,7 +253,7 @@ There is no parallel candidate-body authoring path. Emit only the
 
 ### Step 6 — Validate And Submit
 
-Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns blocking diagnostics, repair the exact paths it reports and rerun validate. After validation, show the structure to the user with the structure summary, `structure_report.file_url`, and `structure_report.absolute_path`. If validation returns `confirmation_blockers[]` or `will_block_confirmation`, repair those blockers before asking the user to confirm. If you stage a draft structure first, the stage result is still a human review gate: show the returned report link/summary and ask the user to inspect it before confirming. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
+Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns `repair_confirmation_blockers`, follow its repair route and rerun validate without asking for preliminary approval. `--repair suggested-splits` handles non-contiguous source mirror Sections. For oversized Views, apply the returned child-View and contains-edge suggestions while classifying child Nodes from evidence. Resolve other blockers from evidence; ask the user only when evidence supports multiple incompatible semantic choices, and state that this is not final review. Stage only after `confirmation_ready=true`. The stage result opens the final HTML report and is the human review gate: show the structure to the user through `structure_report.file_url`, `structure_report.absolute_path`, and the compact summary before asking for confirmation. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
 
 After stage succeeds, do not rerun the same write command to confirm success.
 Use `context status --format json` or the returned result for read-only

package/plugins/claude/skills/skill-prose-compile/SKILL.md

@@ -60,7 +60,7 @@ Use semantic labels, not SDK function names:
 
 ## Runtime Discipline
 
-- Follow `context status`, `routing.next_commands`, compile view
+- Follow `context status`, `routing.command_plan`, compile view
   `next_action`, and validation diagnostics. Treat CLI commands as the source
   of truth.
 - Use only the returned `next_action.command` for the next required write.
@@ -75,6 +75,9 @@ Use semantic labels, not SDK function names:
   views.
 - Run one write at a time. Do not parallelize compile stage, review apply,
   close, or build writes.
+- One write still means one View, not one human Review. Stage every View in the
+  same confirmed structure sequentially, follow `continue_compile_batch`, and
+  open Review only after the CLI reports that the whole batch is prepared.
 - Compile does not get a second, looser rule set. If a rule conflicts with the
   current CLI schema or diagnostics, follow the CLI and repair the payload.
 - Write digest/hash flags are stale guards. Use values returned by the CLI; do
@@ -226,13 +229,21 @@ Stage only after validation has no errors:
 context run compile:<type>:<source>:<collection> --stage --input <compile-actions.yaml> --format json
 ```
 
-After staging, return to `context status`. If status reaches
-`compile-ready-for-review`, delegate review to
-`${CLAUDE_PLUGIN_ROOT}/skills/skill-review-gate/SKILL.md`.
+After staging, follow `next_action` exactly:
+
+- `continue_compile_batch` with `human_gate=false`: move to the returned next
+  View and repeat **Step 2–4**. Do not open Review yet.
+- `review_candidates` with `human_gate=true`: every planned View in this
+  confirmed structure is prepared; return to `context status`, then delegate
+  one collection-level Review to
+  `${CLAUDE_PLUGIN_ROOT}/skills/skill-review-gate/SKILL.md`.
+
+The CLI blocks Review and close while confirmed Views remain unprepared. Do not
+turn sequential View writes into sequential user approvals.
 
 ### Step 5 — Close Handoff
 
-After review apply, return to `context status`. If status says
+After the single batch review apply, return to `context status`. If status says
 `compile-close-needed`, run deterministic close:
 
 ```bash
@@ -257,6 +268,7 @@ Then route to package output when status reaches `ready-to-build`.
   verbatim text.
 - [ ] No direct edits were made to `sources/`, `.tmp`, `unapproved/`,
   `knowledge/`, review HTML, or `dist/`.
+- [ ] Every planned View was staged before opening the one batch Review.
 
 ### Final Report
 

package/plugins/claude/skills/skill-review-gate/SKILL.md

@@ -2,7 +2,7 @@
 name: skill-review-gate
 description: >
   Internal procedure invoked by the public Context continuation entry; not a user slash command.
-  Opens the review UI, waits for user decisions, applies copied JSONL payloads,
+  Opens the review UI, waits for user decisions, applies copied review decision Payloads,
   and prevents agent-authored approval/rejection decisions unless the user
   explicitly requests the scoped quick-decision path.
 tools:
@@ -16,19 +16,32 @@ Run the human review gate. The user decides approval or rejection.
 ## TL;DR
 
 - The agent never approves or rejects candidates on the user's behalf.
-- Use `context review html <collection> --open` for visual review.
+- Enter this skill only when the preceding command returns
+  `next_action.human_gate=true`. A no-delta codegraph run returns false and does
+  not need Review.
+- For prose, enter only after every View in the confirmed compile batch is
+  prepared. For codegraph, enter only after all pending extract phases in the
+  confirmed module round are complete. The CLI blocks partial-batch Review.
+- Use `context review html <collection> --open --format json` for visual review.
 - `<collection>` is an internal production collection such as `architecture`,
   `sop`, `decision`, or `standards`; it is not an OKF package root such as
   `wikis`, `guides`, or `rules`.
 - Always surface the CLI-printed `file_url`. If browser opening fails or the
   host cannot make a path clickable, also provide `absolute_path`.
-- Apply only the JSONL payload copied by the user from the review UI.
+- Apply only the review decision Payload copied by the user from the review UI.
 - Do not parse `unapproved/entities.jsonl`, `.tmp`, or HTML internals with
   scripts to synthesize decisions.
 - If the user explicitly asks for quick or automated approval/rejection, use
   `context review approve <candidate-id> --collection <collection>` /
   `context review reject <candidate-id> --collection <collection>` or `--all`;
   these commands still enforce the current scoped candidate-id gate.
+- `context run <extract-phase-id> --auto-promote` is a separate, explicit
+  codegraph-only CI/CD policy. It may apply code add/update/remove deltas and
+  refresh deterministic close, and verify them without this gate; it never
+  applies to semantic knowledge. Package build remains an explicit later step.
+- `approved-source-ref-ambiguous` on beta.5 approved codegraph pages is an
+  evidence migration, not a new review decision. Rerun the declared codegraph
+  extraction, then run `context review migrate-codegraph-refs` and verify.
 
 <procedures>
 
@@ -37,12 +50,14 @@ Run the human review gate. The user decides approval or rejection.
 For the internal collection reported by status, run:
 
 ```bash
-context review html <collection> --open
+context review html <collection> --open --format json
 ```
 
-Tell the user where the page opened and include the CLI-printed `file_url` as a
-clickable link plus `absolute_path` as a copyable fallback. Do not assume a
-fixed review filename; review scope is collection or `--all`.
+Inspect the returned `opened` field. When it is `true`, tell the user the page
+was opened. When it is `false`, do not claim it opened; report `open_error` and
+provide `file_url` as the primary clickable link plus `absolute_path` as a
+copyable fallback. Do not drop `--open`, and do not assume a fixed review
+filename; review scope is collection or `--all`.
 Do not substitute OKF package roots (`wikis`, `guides`, `rules`) for this
 argument; review scope is the internal collection namespace.
 
@@ -54,7 +69,8 @@ must not choose these states.
 ### Step 2 — Wait For Payload
 
 Ask the user to review candidates in the HTML page, open Payload, copy the
-compact JSONL payload, and paste it into the agent chat. The payload records the
+compact review decision Payload, and paste it into the agent chat. Uniform
+decisions produce one JSON line; exceptions add JSONL lines. The Payload records the
 user's decisions, usually as a default decision plus exceptions, so it should
 not be expanded into pretty JSON unless the user asks.
 
@@ -62,7 +78,7 @@ The user should not need to create a payload file manually. Do not continue
 until the user supplies that payload.
 
 If the user instead explicitly asks the agent to use the quick approval or
-rejection path, do not synthesize JSONL. Run the scoped quick command with the
+  rejection path, do not synthesize a decision Payload. Run the scoped quick command with the
 candidate id shown by review/list/status and either `--collection <collection>`
 or `--all`.
 
@@ -85,6 +101,19 @@ commands to store this payload.
 Run `context status` after apply. If it reports package output choice, return to
 `${CLAUDE_PLUGIN_ROOT}/skills/skill-continue-workflow/SKILL.md`.
 
+If status instead reports `approved-source-ref-ambiguous` for a pre-file-aware
+codegraph ref, explain that the user's decisions remain approved. Rerun its
+declared extraction phase to refresh the symbol index, then run:
+
+```bash
+context review migrate-codegraph-refs
+context verify
+```
+
+Do not reopen Review, synthesize another payload, delete approved pages, or
+filter conflicting symbols. If the ref is already file-aware, report a
+duplicate extract-index defect rather than running the metadata migration.
+
 ### Step 5 — Self-verify Checklist
 
 - [ ] Every decision came from the user's copied payload. If not, stop and