@c4a/context-cli 0.5.41-beta.7 → 0.6.0-alpha.6

package/plugin/commands/compile.md

@@ -1,112 +0,0 @@
----
-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:*)
----
-
-## Your Task
-
-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.
-- `context:skill-*` names packaged internal procedures, not user slash commands.
-
-### Modes
-
-- **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 mode at the start of this conversation. Treat requests such as "全托管执行", "全自动托管", "fully managed", "delegated execution", or "use delegated mode" as explicit delegated authorization. Delegated mode records scoped authority for low-risk reconcile/review/apply defaults; it does not auto-draft Node content or replace agent evidence reading. Do not infer it from vague "continue", "继续", or "后面不用问我" permission.
-
-### Core Rules
-
-- 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.
-- Workflow write digest flags are stale guards. Omit `--payload-digest` unless the returned command explicitly requires one; when an explicit digest is needed, use `context workflow show --payload <name> --digest-only --format text` instead of parsing JSON stdout.
-
-Protocol discovery:
-
-- `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`
-
-## Start
-
-1. Run `context compile scan --format json` (or `context compile scan --delegated --format json` when the user explicitly authorized delegated mode, including "全托管执行" / "fully managed").
-2. If the scan returns `close_compile`, run the returned close command even when there are no changed Nodes; finalized no-write/container Nodes may still need close materialization.
-3. If the scan returns `stop_noop` or no changed work, report that compile stopped before draft and no files were written.
-4. Run `context status --view summary --format json` or `context mdrive workspace stats --format json` only when needed for the final before/after report or when the CLI asks for diagnostics. Do not run doctor/status/source-list as a required preflight before following a valid compile scan or align-finalize handoff.
-
-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 Node Evidence From The Envelope
-
-Run the evidence command returned by the envelope before writing. `views[].expected` identifies the default compact evidence entry, not a separate checklist to exhaust. For compile evidence, prefer the CLI-returned source-ref/scaffold views. They may expose:
-
-- `source_refs_index_command` / `source_refs_command` — compact Node-scoped citation index for drafting; use `items[].block_id` in `source_block_ids[]` when the row is the evidence you will cite. Multiple block ids in one action must be one same-source contiguous citation-eligible run; split around skipped citation-eligible rows or use `--draft-scaffold` when unsure.
-- `source_refs_detail_command` — detailed source refs with quote previews; open only when the compact index is not enough.
-- `request_full_text_command` / `--view text` — narrow text view for one block when quote preview is not enough; this is still Node-scoped, not a workspace evidence bundle.
-- `citable_source_refs[]` — detailed-view refs eligible for draft citations; prefer `block_id` values in `source_block_ids[]`.
-- `supporting_context_refs[]` — background/framing only.
-- diagnostics such as citation eligibility, coverage, engagement, stale raw/source_ref pointers, 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. When advisory foldbacks say `agent_recommended_action: ignore`, do not inspect each detail row unless the user asks for cleanup or the cited source appears to lose meaning.
-
-### 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`.
-
-Prefer heredocs for small payloads. If large or parallel draft payloads need staging, use the workspace AGENTS.md scratch path (`.context/.tmp/agent-payloads/<run-id>/...` in embedded workspaces, `.tmp/agent-payloads/<run-id>/...` in root-layout workspaces) and redirect stdin from that file. Never reuse fixed names like `/tmp/c4a-draft-<node>.json`, and never use scratch paths as workflow handoff or CLI-managed storage.
-
-Use `op: deprecate` only when an existing active Section is no longer supported by its source, is factually wrong, has been superseded, or the user explicitly asked to retire it. Do not deprecate an existing true Section merely because it is low-relevance to the current narrow task; leave it unchanged and use `op: skip` / omit only for the current proposed evidence.
-
-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`, first inspect the returned command and prepare summary. If the command is `context reconcile review --accept-safe-defaults ...` with no `--decisions -`, run it directly; the CLI is accepting only mechanical defaults. If manual decisions remain, load the prepare payload through CLI views such as `context workflow show --payload prepare --view issues --unwrap --format json`, accept default_decision items with compact `{ item_id, accept_default: true }` when you can verify they are appropriate, and invoke packaged `context:skill-compile-judge` only for items that still need support/relation judgment. For hand-authored decision payloads, run `context reconcile validate --mode compile --node <slug> --decisions - --format json`, repair any blocking diagnostics, then pass validated decisions to the returned review command.
-
-Do not treat every `review_reconcile_decisions` envelope as a judge request. Invoke `context:skill-compile-judge` only when the prepare summary includes `judge_handoff` or the returned diagnostics explicitly ask for support/relation judgment. 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`, execute the returned plain apply command exactly, typically `context reconcile apply --format json`; do not add `--decisions` or stdin. For `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.
-- Raw/source_ref pointer diagnostics are mechanical evidence checks, not content-quality judges. Do not patch drafts only to satisfy URL/style/term-overlap preferences. Blocking evidence checks should come from invalid source refs, stale raw mirrors, changed evidence boundaries, 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.
-- If close reports a finalized Node that needs only block ownership/support repair, use `context compile repair ownership --input - --format json` with the `align.ownership-patch.v2` shape. This is the compile-family repair path and preserves completed node-cycle progress. Do not abandon the active compile workflow just to run `context align patch ownership`.
-
-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.
-
-Treat close as a terminal gate, not a blind final step:
-
-- If close reports `code_projection_followup` / `compile-close-code-projection-followup`, run the returned `context compile --aspect code ...` command, then run `context compile close` again before reporting final success.
-- If close reports `ready_with_debt`, do not enter export/query/report-as-complete unless the user explicitly accepts the remaining debt. Otherwise repair or skip coverage debt through the returned coverage commands, then run close again.
-- Coverage disposition commands mutate workflow state. Run one `context compile coverage ...` command at a time, or use the returned `--skip-unresolved` bulk command for one Node; never submit multiple coverage disposition writes concurrently.
-- Use `context query --intent recall` only as a smoke-test query. Do not use recall as a deterministic full-workspace export path.
-
-Report in the user's conversation language. Include semantic apply counts, close/verify status, warning-level `auto_repaired[]`, `ready_with_debt` coverage 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/context.md

@@ -1,36 +0,0 @@
----
-description: "Fuzzy router for context operations. Inspect the argument and route to the correct /context:* subcommand."
-argument-hint: "<free text | url | source-id | question>"
-allowed-tools: Bash(context:*)
----
-
-## Your Task
-
-Inspect `$ARGUMENTS` and delegate to the most appropriate subcommand. Route without running anything of your own first — let the target subcommand drive.
-
-Any prose you speak to the user (clarifying questions, "routing to …" notes) follows the user's conversation language. Sub-command names (`/context:capture`, `/context:compile`), flag names, and source-ids stay English.
-
-Naming convention: `/context:*` names user slash commands and `context ...` names CLI primitives. Internal packaged procedures are workflow-only; this router dispatches only slash commands and does not call packaged procedures directly.
-
-Routing rules (first match wins):
-
-1. **Empty arguments** → run `/context:status`.
-2. **Starts with `http://` or `https://`** → `/context:capture $ARGUMENTS`.
-3. **Ends in `.md` and is explicitly presented as source material to ingest/capture** → `/context:capture $ARGUMENTS`.
-   Driver documents such as run instructions, handbooks, READMEs, plans, feedback issues, corpus/index/manifests, and batch lists are not capture targets unless the user explicitly asks to ingest them. Capture only ingest targets that are already explicit in the user request; if they are missing, ask one clarification.
-4. **Equals `--inbox` or `--refresh`** → `/context:capture $ARGUMENTS`.
-5. **Matches `init`, `initialize`, `new workspace`, or looks like a plain workspace name** → `/context:init $ARGUMENTS`.
-6. **Mentions `code` or source-code capture** → `/context:capture --code $ARGUMENTS`.
-7. **Mentions `aspect` without a concrete supported capture flag** → ask one clarification; code aspect capture is exposed as `/context:capture --code`.
-8. **Matches `align`, `structure`, `plan`, `node tree`** → `/context:align $ARGUMENTS`.
-9. **Matches `compile`, `recompile`, `synthesize`, or `build knowledge`** → `/context:compile $ARGUMENTS`.
-10. **Matches `build`, `export`, `package`, `publish`, `deploy`, `release`, `ops`, `operations`, or `运维` as an operational/package task** → `/context:ops $ARGUMENTS`.
-11. **Matches `drop`, `retract`, `delete source`, or passes a known source-id pattern (`feishu:*` / `local:*` / `aspect:*` / `oncall:*` / `meeting:*`)** → `/context:drop $ARGUMENTS`.
-12. **Matches `purge`, `clear archive`, `delete archive`, or `清理归档`** → `/context:purge $ARGUMENTS`.
-13. **Equals `status`, `health`, `overview`, `summary`, or asks for workspace/cache/plugin health** → `/context:status`.
-14. **Anything else** (likely a knowledge question) → `/context:query $ARGUMENTS`.
-
-If multiple rules apply, pick the most specific (URL beats word match). When in doubt, ask one clarifying question before dispatching.
-Never use Read / Glob / Grep / Write against `WORKSPACE_DIR`; route to packaged `/context:*` commands and skills instead of opening plugin or workspace files manually.
-Never use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect or preprocess `WORKSPACE_DIR`, `.context`, or `/tmp` workflow artifacts.
-Do not use `context workspace` search/read as this router's knowledge fallback; route likely knowledge questions to `/context:query` so the query skill owns retrieval and citations.

package/plugin/commands/drop.md

@@ -1,38 +0,0 @@
----
-description: "Drop a source: CLI plans cleanup, reconciles affected Sections when needed, then applies safely."
-argument-hint: "<source-id|url> [--reason <text>] [--yes]"
-allowed-tools: Bash(context:*)
----
-
-## Your Task
-
-Retract a source without losing the audit trail. The CLI owns source resolution, impact planning, semantic decision application, knowledge cleanup, source stamp, changelog append, and verify; the agent presents the impact plan and waits for confirmation.
-
-Naming convention:
-
-- `/context:*` names user slash commands.
-- `context ...` names CLI primitives.
-- Internal packaged procedures invoked by slash workflows are not user slash commands.
-
-Use packaged `context:skill-drop` end to end, including the self-verify checklist at the end.
-
-Parse `$ARGUMENTS` for `<source-id|url>`, optional `--reason <text>`, and optional `--yes`. Source validation is done by `context drop --plan`; if absent or already `dropped`, relay the CLI's error and stop. If `--reason` is missing but the user gave a clear natural-language reason, infer a concise reason; otherwise ask for it before applying the plan. `--yes` skips the original drop impact confirmation only; it never skips semantic `ask_user` questions.
-
-Language policy: any prose you speak directly to the user follows the user's conversation language. CLI output, source-ids, command names, file paths, flags, and issue codes stay as printed.
-
-Never Read / Glob / Grep / Write workspace files directly. All workspace access goes through semantic CLI commands such as `context drop --plan`, `context reconcile prepare --mode drop`, `context reconcile review`, `context drop --apply-plan`, and `context source`. If you need the semantic decision shape, run `context schema semantic-decisions` for JSON or `context schema semantic-decisions --format yaml` for readable YAML; do not infer it from memory.
-Never use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect or preprocess workspace storage or temporary workflow artifacts. Consume CLI JSON/YAML/text outputs directly. Do not pipe `context ... --format json` through `python3`, `node`, `jq`, `sed`, `cat`, `2>&1`, or shell fallback wrappers.
-Plan handoff is workflow-scoped. Run `context drop --plan <target> --format json`; the CLI stores the drop-plan payload in the current workflow. `--save-output` is only for an explicit human-readable scratch copy and must not be passed to later steps.
-
-## Final Report
-
-Report in the user's conversation language. Translate section headings into the user's language instead of copying the English labels below verbatim. Optimize for human readability: name the dropped source by its title, use Node titles instead of slugs, and use Section kind plus heading for each archived Section. Do not surface source ids, content hashes, archive directory paths, semantic ledger ids, or workflow payload identifiers.
-
-Stable structure:
-
-1. Completion headline. Single line naming the dropped source by title plus verify status (for example "「<source title>」 dropped, verify ok"). Capture data from `context drop --apply-plan --format json`.
-2. Affected Node tree. Group archived Sections by their owning Node. Each Node entry shows the Node title and Node type; below it list the archived Sections with their kind plus a short heading/preview that identifies which Section was archived (not the section id). Include Nodes whose alias mappings or visibility changed even when no Section was archived. Omit the tree entirely when the plan was a no-op or alias-reindex-only.
-3. Variance summary. Bullet list of counts: archived Sections, affected Nodes, semantic decisions applied, and the final verify status. Show every counter so the user can verify nothing unexpected fired, including zeros.
-4. Next step. Single command suggestion: `/context:status` to inspect the current knowledge distribution, or `/context:purge` when the user wants to permanently clear the archived snapshots.
-
-Do not include raw drop-plan digests, archive directory paths, or workflow payload identifiers in the report. Those belong in earlier troubleshooting output, not in the completion summary.

package/plugin/commands/extract.md

@@ -1,18 +0,0 @@
----
-description: "Debug helper: run extraction against a path and print structured results (no files written)."
-argument-hint: "<path> [--format json|jsonl|pretty]"
-allowed-tools: Bash(context:*)
----
-
-## Your Task
-
-Run `context extract $ARGUMENTS` and stream the CLI's stdout back to the user.
-
-- The command is **state-required**: it runs only from inside an initialized context workspace. Outside a workspace the CLI exits with a workspace-not-found error — relay it and suggest `/context:init`, do not try to guess a workspace location.
-- It is strictly read-only — never writes into workspace files.
-- Default format is `json`; `--format jsonl` is line-delimited per entity; `--format pretty` is human-readable.
-- Useful for inspecting what `/context:capture --code` would capture without creating a bucket.
-
-If the user wants to persist the extraction as a raw snapshot, redirect them to `/context:capture --code`.
-
-Language policy: stream CLI stdout/stderr verbatim. Any explanation you add follows the user's conversation language; paths, JSON keys, command names, flags, and error tokens stay as printed.

package/plugin/commands/ops.md

@@ -1,47 +0,0 @@
----
-description: "Run operational package tasks such as local build/export, with future publish commands kept under the same entry."
-argument-hint: "build [--format llms|skills]"
-allowed-tools: Bash(context:*)
----
-
-## Your Task
-
-Run operational tasks for the current context workspace. This command owns packaging/export work and is the future home for platform publish. It does not capture, align, compile, query, drop, or purge knowledge.
-
-Supported subcommands:
-
-- `build`: build a local knowledge package by running `context build`.
-
-Unsupported but reserved subcommands:
-
-- `publish`: reserved for future platform publish. Do not invent a CLI command for it.
-- `package`: reserved for future offline package-only publish flow. Do not invent a CLI command for it.
-
-### Build
-
-If `$ARGUMENTS` is empty, treat it as `build --format skills`.
-
-If `$ARGUMENTS` starts with `build`, run `context build` with the requested format:
-
-- `build --format skills` -> `context build --format skills`
-- `build --format llms` -> `context build --format llms`
-- `build skills` -> `context build --format skills`
-- `build llms` -> `context build --format llms`
-- `build` -> `context build --format skills`
-
-If the user asks for both formats, run the two CLI commands separately:
-
-1. `context build --format skills`
-2. `context build --format llms`
-
-Do not pass unsupported flags to `context build`. If the user supplies an unknown build format, explain that the supported formats are `skills` and `llms`, then stop.
-
-Before running build, do not inspect workspace files with generic tools. The CLI performs workspace verification and prints blocking issues if the workspace is not ready.
-
-After build succeeds, surface the CLI output verbatim, especially the package path under `output/skills-pkg/` or `output/llms-pkg/`. If build fails because verification failed, relay the error and let the CLI's issue list drive remediation; do not inspect `raw/`, `knowledge/`, or `output/` yourself.
-
-### Reserved Publish
-
-If `$ARGUMENTS` starts with `publish`, `package`, `deploy`, or `release`, do not run any command. Explain briefly that platform publish/package-only is reserved under `/context:ops` but not implemented yet. For now, the available operational command is `/context:ops build`.
-
-Language policy: CLI stdout/stderr stays verbatim. Any explanation you add follows the user's conversation language; command names, flags, paths, package formats, and issue codes stay as printed.

package/plugin/commands/purge.md

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

package/plugin/commands/query.md

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

package/plugin/commands/status.md

@@ -1,25 +0,0 @@
----
-description: "Print the current workspace overview (sources, raw counts, knowledge counts, last compile) and suggested next actions."
-argument-hint: ""
-allowed-tools: Bash(context:*)
----
-
-## Your Task
-
-Run `context status` from the active workspace root only. `status` is intentionally local-only and does not walk up from child directories. If the CLI reports `workspace-not-found`, relay that error and ask the user to rerun from the workspace root or initialize with `/context:init`; do not probe storage paths to discover a workspace.
-
-Surface the CLI's output verbatim — its trailing suggestions are already actionable. Do not invent additional suggestions; the CLI decides what to recommend based on the workspace state. Typical recommendations you will see:
-
-- Run `/context:align` when there is active raw material but no align plan yet (compile's Stage 1 prerequisite).
-- Run `/context: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.
-
-Workflow lineage helpers are exposed through `context workflow status --format json` and `context workflow list --format json`. If status returns `current: null` with `last_published`, the published finalized ownership is still the workspace structure truth; compile may continue from it without rerunning align.
-
-If the CLI exits with a workspace-not-found error, stop and invite the user to run `/context:init` instead of guessing a workspace location.
-
-Language policy: surface the CLI output verbatim. Any extra explanation or workspace-not-found invitation follows the user's conversation language; command names, paths, status labels, source-ids, and issue codes stay as printed.

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

@@ -1,110 +0,0 @@
----
-name: skill-align-workflow
-description: "Internal procedure for /context:align. Reads CLI-guided align evidence, applies semantic Node classification gates, and emits align structure-intent payloads for CLI validation/finalize."
----
-
-# Align Workflow Procedure
-
-## TL;DR
-
-Run `context align scan --format json`, follow the top-level `next_action.command` to read the CLI-selected evidence path, produce semantic structure payloads, and continue following top-level `next_action`. The CLI owns route, validation, repair commands, and stage guards; this skill owns only semantic classification and source-bound structure judgment.
-
-<reference>
-
-## Canonical Data
-
-- `workflow.next-action-envelope.v2` is authoritative. Branch on `next_action.kind`, execute `next_action.command`, and treat `views[].command` as detail reads rather than a checklist.
-- `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` first; for authoring schemas such as `align-structure-intent`, the minimal view includes required fields, enums, and a minimal payload example. Read the full schema only when you need extended notes or edge-case examples.
-- 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 structural-block ownership source of truth. Source-wide owned/shared defaults automatically demote non-content blocks such as navigation references, placeholders, front matter, marker quotes, embed tags, and embedded assets to `context_only` or `ignored`; submit an explicit `block_ownership[]` owned/shared entry only when such a block is primary citation evidence.
-- When `pending-relation-refs` is present, inspect it before finalizing graph structure. Use existing/current matches for `contains_parent_ref` or `domain_gate.child_refs`; keep unresolved target slug hints deferred and do not write dangling parent, child, or edge refs. For navigation-only / placeholder-only sources, first preserve useful source/page identities as no-write Nodes with root-level `planned_sections: []` when an explicit retrieval need, graph need, or atomic/concrete title gives the page standalone retrieval value; this no-write Entity priority can apply even when every child ref is unresolved. Never put `planned_sections` inside `domain_gate`. Those kept placeholders need support through `context_only` blocks with `visible_to`, owned/shared evidence, or finalized graph support. If a placeholder/relation source is skipped entirely, still classify its coverable blocks with a source-wide `ownership_groups[]` rule, usually `ignored` for pure placeholders. `ignored` only disposes unused material and does not support a placeholder by itself. Domain placeholders may have `domain_gate.child_refs: []` when every child is still deferred. Only use `entity[term]` when the source title is an atomic term.
-- `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.
-- Workflow digest flags are stale guards. Follow returned `next_action.command` and omit optional digest flags unless the CLI asks for one; if an explicit digest is needed, recover it with `context workflow show --payload <name> --digest-only --format text`, not JSON parsing.
-- Node type, tag, fake-Entity, `domain`, and `action` gates are in `references/gates.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>
-
-<procedures>
-
-Use this only inside `/context:align`.
-
-### Step 1 — Start From The Envelope
-
-Run `context align scan --format json`. Confirm `schema_version: "workflow.next-action-envelope.v2"`, then identify `next_action`, `views`, `workflow`, `route`, and `diagnostics`.
-
-If the host truncates scan stdout but the preview includes top-level `next_action.command`, run that command. If `next_action` is not visible, rerun the scan command; do not recover host tool-result files.
-
-If no envelope is present, stop and surface the CLI output; do not reconstruct an align route from old prompt memory.
-
-### Step 2 — Follow The Evidence Read Path
-
-Run the returned `next_action.command`. For structural align work this is normally `read-plan`; after that, follow the `read-plan` / `source-bundle` response's `next_action.command`.
-
-`read-plan` is the navigation surface. It chooses whether the next evidence read is a whole-batch `source-bundle`, a scoped source/window bundle, or an existing coarse-read route. `source-bundle` is annotated source text; read it and then author the requested align JSON yourself, normally `align-structure-intent`. Never pipe bundle text into `context align validate`.
-
-If `source-bundle` omits text for budget, `read_scope_complete: false`, `page.has_more: true`, or the final `source-bundle:end` annotation is missing, run its `next_action.command` before authoring.
-
-Read evidence through semantic CLI views, not shell parsing. Follow `page.next_command` for pagination. If the command contains `--read-cursor`, treat it as opaque continuation state and run it exactly; do not replace it with hand-written `--source`, `--heading`, `--window`, or `--range` selectors. Use `--source`, `--heading`, `--window`, `--range`, and `--token-budget` as view filters only. `--unwrap` removes workflow metadata; it does not expand a compact view into full detail.
-
-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; continue the current detail view only when `page.next_command` is explicitly needed, otherwise return to the read-plan/source-bundle continuation.
-
-### Step 3 — Reuse Existing Knowledge
-
-Query existing knowledge for reusable names before proposing new term/service/system/action Nodes. Exact title/slug/alias hits should usually become references to the existing Node, not duplicate candidates.
-
-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.
-
-### Step 4 — Classify Semantic Structure
-
-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.
-
-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.
-
-For `node.title` and `node.summary`, follow `align-segments.generation_policy.language`. In Chinese workspaces, translate descriptive scaffold words such as architecture, strategy, lifecycle, overview, scheduling, high availability, and warning into Chinese while preserving product names, code identifiers, CLI flags, slugs, block_id tokens, and citation tokens exactly when needed. Do not copy an English source title into `node.title` merely because the source is English.
-
-Do not classify a broad architecture/system/方案 source as `domain` just because the title sounds like a scope. If it has writable Sections but no resolvable current/existing child Nodes, use an `entity` tag such as `system` or `application`; reserve `domain` for grouping child Nodes through `domain_gate.child_refs`.
-
-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.
-
-### Step 5 — Build The Payload Requested By `next_action`
-
-Use `next_action.input_schema` and the matching `context schema <name> --view minimal --format json` output to shape the payload. If the minimal view exposes `required`, `enums`, `minimal_example`, and `field_guidance`, treat it as the authoring contract; read the full schema only when those fields are insufficient for an edge case.
-
-For the default `align-structure-intent` path, produce one intent document with semantic Nodes, `section_groups[]`, `ownership_groups[]`, and edges. Let CLI generate `section_id` values and expand ownership groups into canonical defaults/exceptions. For long sources, do not hand-enumerate the largest ownership range; use one `{ source_id }` ownership group for the majority owner, then use `{ block_ids }` ownership groups for semantic exceptions. `block_ownership[]` is an advanced single-block patch path only when schema output or CLI diagnostics explicitly ask for it; it uses singular `block_id` and never `scope` or `block_ids`. Do not add `{ source_id, structural_role }` groups merely to mark front matter, navigation, placeholders, marker quotes, embed tags, or embedded assets as non-citation material; the source-wide default's automatic demotion handles those.
-
-Use only `block_ids[]` in `section_groups[]`. Do not invent heading/range/window selectors inside the intent. Treat source heading changes as section-planning signals: sibling sub-headings under a shared parent may stay in one Section when they form one coherent semantic topic; headings with no shared parent should usually split unless you intentionally want one Section to span them. The CLI reports cross-heading groups but does not rewrite your semantic grouping. If one semantic section spans non-contiguous citation-eligible blocks, align may accept the grouping, but finalized ownership will split it into compile draft-ready contiguous runs; hard citation-gap templates should stay separate. Every block you leave as `owned` or `shared` citation evidence must appear in some section group; otherwise reclassify it as `context_only` or `ignored`. If a no-write/navigation-only/placeholder-only Node is kept, set root-level `planned_sections: []` explicitly so the CLI knows this was intentional, and keep at least one supporting block as `context_only` with `visible_to` unless the Node already has owned/shared evidence or finalized graph support. `planned_sections` is a node field, not a `domain_gate` child. `ignored` is valid for skipped material or extra placeholder lines, but it does not create `context_sources` or unblock close by itself. If you skip a relation-only, navigation-only, or placeholder-only source after ruling out resolved Domain support and standalone retrieval or graph value, you still must classify every coverable block; use one source-wide `ownership_groups[]` rule with `ownership_role: "ignored"` or `context_only` instead of leaving the source absent from ownership. For Domain placeholders, put only resolved current/existing targets in `domain_gate.child_refs`; if all child refs are unresolved relation clues, use `child_refs: []` and leave the unresolved rows in pending-relation-refs. Do not turn a container placeholder into `entity[term]` unless the title itself is a useful atomic term.
-
-Emit `depends_on` edges only when cited source blocks explicitly say one Node consumes, requires, calls, is configured by, or is downstream of another Node as a prerequisite, capability provider, upstream input, runtime dependency, or data-flow source. Direction is consumer/downstream -> provider/upstream. Do not create `depends_on` for parent/child containment, `Related`/`See also` lists, sibling co-occurrence, shared table membership, name similarity, or a plain mention without a dependency predicate. `edges[].evidence_blocks[]` must include the block that states the dependency; if the relationship matters but evidence is missing, leave the edge out or add an unresolved question instead of guessing.
-
-Prefer the strongest source-backed `section_kind` using the current schema's `section_kind_priority` and `section_kind_triggers`; avoid planning an entire dense source as `description` when the evidence clearly contains examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Ordinary typical scenarios, case studies, and impact/result examples are `example`, not `incident`, unless the source is explicitly an outage, incident review, postmortem, or dated fault-handling timeline. Treat kind precision as a drafting quality preference, not a reason to block an otherwise source-backed write. Keep only raw-backed semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
-
-Canonical `align-structure-decision` is not a parallel authoring path. Use it only when `next_action.input_schema` explicitly asks for it or when auditing/repairing canonical output returned by the CLI.
-
-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.
-
-### Step 6 — Validate And Submit
-
-Before finalizing, run `context align validate --input - --format json` with the payload matching `next_action.input_schema`. 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; do not copy compiled canonical JSON from validation output unless the CLI explicitly asks for canonical input.
-
-After finalize succeeds, do not rerun the finalize submit command to confirm success. Use returned `payloads.*.show_command` values, or `context workflow show --payload finalized-ownership --unwrap --format json`, for read-only confirmation; then continue with the returned `next_action.command`, normally `context compile scan --format json`.
-
-If finalize reports node reclassification hints, the submitted Node was changed by a semantic gate. Treat finalized ownership as the source of truth; status counts finalized Nodes, not submitted proposals.
-
-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.
-
-### Step 7 — Self-verify
-
-- [ ] All writes followed top-level `next_action.command`. If not, return to **Step 1**.
-- [ ] Evidence was read through returned `next_action.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**.
-- [ ] The requested align payload 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

@@ -1,60 +0,0 @@
-# Candidate Resolution Rules
-
-Use these rules after reading candidate ledger and aggregate payloads, before authoring the align payload requested by `next_action.input_schema`.
-
-## Anomaly Signals
-
-`anomaly_signals[]` are mechanical warnings. Do not ignore them and do not treat them as recommendations.
-
-For each anomaly, choose one outcome and record the reasoning in either the next ledger op rationale, the final node summary/audit warning, or `unresolved[]`:
-
-| Outcome | Use When |
-|---|---|
-| `accept` | The anomaly points to a real correction. Apply a concrete op or final structure choice. |
-| `dismiss` | The warning is mechanically true but semantically harmless. Keep the candidate and state why. |
-| `unresolved` | The warning changes structure but the source evidence is insufficient. Add an unresolved question instead of guessing. |
-
-Known anomaly kinds:
-
-| Kind | Meaning | Required Handling |
-|---|---|---|
-| `missing_evidence` | An active candidate has no evidence block. | Add evidence, reject the candidate, or mark the structure unresolved. |
-| `ledger_churn` | A candidate was renamed, merged, superseded, or rejected during discovery. | Confirm the final title/slug/target or mark unresolved if the shape is still ambiguous. |
-| `duplicate_block` | The same evidence block appears more than once on a candidate. | Dedupe the evidence or explain why repeated evidence is harmless. |
-| `general_review_recommended` | The CLI collapsed more than eight anomalies. | Review the affected candidate broadly; do not finalize solely from aggregate ordering. |
-
-## Label Hints
-
-For `merge_into`, `supersede`, and `reject`, include the visible label hint fields:
-
-- `source_label_hint` and `target_label_hint` for `merge_into`
-- `source_label_hint` and `target_label_hint` for `supersede`
-- `candidate_label_hint` for `reject`
-
-These hints are for audit and Agent DX. Copy them from ledger labels/titles when available. Do not invent a label that contradicts the visible candidate.
-
-## `llm_slug_hint` And Refs
-
-Use `llm_slug_hint` as the stable reference inside one align payload when final slugs may be normalized by the CLI.
-
-Recommended pattern:
-
-```yaml
-nodes:
-  - llm_slug_hint: local:data-region
-    slug: data-region
-    node_type: entity
-    tags: [term]
-  - llm_slug_hint: local:failover
-    contains_parent_ref: local:data-region
-edges:
-  - edge_type: depends_on
-    from_ref: local:failover
-    to_ref: local:data-region
-sections:
-  - owner: local:data-region
-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 top-level envelope diagnostics (`issues[].expected_shape.available_node_refs`, `diagnostics.*.available_node_refs`, or the returned repair view) and resubmit the corrected payload using the same `next_action.input_schema`. `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

@@ -1,16 +0,0 @@
-# Coarse Read Density Selection
-
-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"`. In normal direct routes, read-plan/source-bundle already selected the evidence path; 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. |
-| `meso` | Default for normal product, design, or operational documents with several related sections. | Produce section proposals for meaningful local units and preserve evidence anchors. |
-| `micro` | The source is fragmented, note-like, or dense with short independent claims. | Keep section proposals narrow and avoid bundling unrelated blocks into one candidate. |
-| `single_pass` | The source is short enough that one read can safely discover all relevant structure. | Still emit the `align-coarse-read` artifact, but keep anchors minimal and avoid over-segmentation. |
-
-Treat Markdown heading changes as section-planning hints, not hard boundaries. Sibling sub-headings under a shared parent can remain in one `section_groups[]` entry when they form one coherent semantic topic for that parent. Headings with no shared parent should usually split unless you intentionally want one Section to span them. When a dense source has many headings, split by heading first, then merge adjacent or sibling groups only when the merged Section is still one coherent fact group.
-
-Do not emit kind/tag/content signals from coarse-read. Action/domain gates are decided later from the source-bundle evidence and schema gate fields, not from density metadata.