@c4a/context-cli 0.7.4 → 0.7.8

package/plugins/claude/commands/context.md

@@ -1,244 +1,320 @@
 ---
-description: "Build or continue structured, traceable Agent knowledge from documents and code. Use the local `context` CLI for workspace writes."
+description: "Use when the user explicitly invokes Context or continues an explicitly started Context workflow in this conversation to build, inspect, update or package knowledge from code, documents, notes and conversation summaries. Do not auto-start for ordinary planning, design or coding."
 argument-hint: "[project-dir or user intent]"
-allowed-tools: Bash(context:*), Bash(bun:*), Bash(cd *)
+allowed-tools:
+  - Bash(context:*)
+  - Bash(bun:*)
+  - Bash(cd *)
 ---
 
-## Your Task
+# Context
 
-Context is a knowledge management tool built for Agent knowledge workflows. It
-compiles Feishu/Lark documents, local Markdown, repository code, and manually
-curated business material into structured, traceable knowledge, then produces
-knowledge packages, LLM-ready documents, or Agent Skills. The CLI packages all
-workflow guidance, knowledge-building procedures, and code-indexing capabilities
-needed to produce that knowledge; follow its returned commands and resources
-for the next action.
+Context turns selected sources into reviewed knowledge and packages for readers
+and Agents. The CLI supplies the current workflow, commands and required
+reading; use it for workspace writes.
 
-Use this as the single conversational entry for Context. Let the CLI locate an
-existing workspace, relocate into it, initialize a requested workspace, or
-evaluate its current workflow. Do not infer the workspace state yourself.
+Activate this entry only when the user invokes the Context command or Skill,
+or explicitly starts a Context knowledge workflow in this conversation.
+Related follow-up requests need no repeated invocation. Ordinary planning,
+design, coding, document editing or discussion of Context implementation does
+not activate it. A workspace, source file, MR or matching phrase alone is not
+an activation signal; unrelated work stays outside an active Context task.
 
-### Enter the workspace
+Workspace knowledge queries and source attribution have a separate, explicitly
+invoked `context-inspect-search` entry. Do not auto-launch it from production
+progress or ordinary questions. When the user accepts its update suggestion,
+use this production workflow's current Route and preserve existing work.
 
-Run:
+## Supported requests
 
-```bash
-context entry [project-dir] --language <language> --format json
-```
+Within an active Context workflow, requests include, but are not limited to:
+
+| Intent | Scope |
+| --- | --- |
+| Build a knowledge base | Clarify the audience and source scope, then create or continue knowledge from selected repositories and documents. |
+| Check progress and results | Explain what is done, where delivered pages are, and what is waiting. |
+| Save notes | Save supplied observations, excerpts or decisions; stop after saving if that is all the user requested. |
+| Preserve conversation insights | Save or use a summary of supplied discussion, not an entire session history. Code-change links are optional. |
+| Update knowledge from source changes | Assess a selected commit, MR/PR or document change against a fixed source version; update affected pages and warranted new topics. |
+| Revise existing content | Correct current drafts or approved pages, including several pages or supported API-table regeneration. |
+| Organize pages and sources | Move pages within a collection, rename supported sources or remove unused sources with reference checks. |
+| Select or customize indexing | Choose compatible indexing Skills and adjust guidance or templates through the configuration flow. |
+| Deliver a batch early | Review and build complete newly authored pages before all writing finishes. |
+| Package knowledge or adjust output | Build approved content for Agents or LLMs, rebuild a package or change its output template. Rebuilding does not rewrite pages. |
+| Prepare the workspace for a new task | Explicitly discard unfinished task state, retain approved work and restore registered source access. |
+| Commit workspace results | Save selected workspace files in local Git, without pushing or including unrelated changes. |
+| Restore a historical workspace version | Select a saved commit, restore only the agreed workspace scope and make its sources usable again. |
 
-If the request does not already choose ordinary review or fully managed
-operation, first use the read-only entry result to state a short execution
-plan, then ask the user to choose once. Explain that ordinary review pauses at
-human Gates and presents HTML reports, while fully managed operation resolves
-delegatable Gates within this conversation but still stops for permissions,
-hard validation, or non-delegatable decisions. Prefer the host's native choice
-UI. When initialization already needs a confirmation or missing option, combine
-the mode choice with that question instead of adding another round. Keep the
-answer only in this conversation and do not ask again after initialization,
-capture, or resume. An explicit request for review, human confirmation, fully
-managed work, or no further review already resolves this choice.
-
-Use the user's explicit language choice when present; otherwise pass `zh-CN`
-for a Chinese conversation and `en` for an English conversation. Pass
-`project-dir`, `--name`, `--dev`, or `--debug` only when the user explicitly
-requested that initialization choice. Pass `--managed` only after the user
-explicitly authorizes fully managed operation in this conversation.
-
-If the `context` process itself cannot start because the command is missing
-(`ENOENT`, or shell exit 127 explicitly identifying `context` as the missing
-command, such as `command not found: context` or `context: command not found`),
-explain that the global CLI is not installed and ask the user to install or
-authorize installation with:
+## Enter the workspace
+
+Once the activation condition is met, run:
 
 ```bash
-npm install -g @c4a/context-cli@latest
-context plugin install
+context entry [project-dir] --language <language> --format json
 ```
 
-Stop after giving that recovery. Do not run an installation preflight, install
-automatically, or mistake a normal Context `not found` diagnostic for a missing
-executable.
+Use the requested language, otherwise `zh-CN` for Chinese or `en` for English.
+Pass `project-dir`, `--name`, `--dev` and `--debug` only when requested. Add
+`--managed` only with explicit fully managed authorization in this conversation.
 
-Execute only `next_action.command` returned by `context entry`:
+Follow the returned `next_action.command`:
 
-- `initialize-workspace` writes a new workspace. Execute it immediately only
-  when the user explicitly requested initialization through this entry;
-  otherwise explain the target root and ask for confirmation. Preserve the
-  `init-target-nonempty` confirmation.
-- `enter-workspace` and `evaluate-workflow` are read-only and need no additional
-  confirmation.
-- After initialization, execute the exact setup command returned by `context
-  init`, enter the project root, read the generated `AGENTS.md`, and run this
-  entry again.
+- `enter-workspace` and `evaluate-workflow` are read-only.
+- `initialize-workspace` may run immediately if the user requested initialization;
+  otherwise confirm the target. Preserve any `init-target-nonempty` confirmation.
+- After initialization, execute its exact setup command, enter the project root,
+  read the generated `AGENTS.md`, then run the entry again.
 
-If the user asks to correct a current Candidate before approval, first let
-`context entry` relocate into the workspace and evaluate its current Route.
-Start the correction with:
+Use that root as the working directory for every workflow command, including
+after compaction. A previous `cd` may not persist, and an input-file path does
+not select the workspace. A parent directory may be a different Context project.
+Follow workspace-mismatch recovery before refreshing its Route.
 
-```bash
-context revise "<candidate title, path, or id>" --instruction "<requested correction>" --format json
-```
+For production, if the user has not chosen a mode, state the short plan from
+the read-only result and ask once: ordinary review pauses at human Gates with
+HTML reports; fully managed operation delegates eligible Gates within this
+conversation. Combine this choice with any necessary initialization question.
+Reuse an explicit review/managed choice across capture and continuation. Neither
+mode settles unclear purpose, missing permissions or non-delegatable decisions.
+Status, discussion and save-only requests need no production-mode question.
 
-When the target is unique, Context invalidates only its derived outputs and
-reopens the owning Author workset. Run the returned status command and follow
-the current Route. If the target is ambiguous, ask which Candidate the user
-means. Never edit `knowledge/`, `dist/`, or create a side-channel revision page.
+Enable debug only when requested: use `entry --debug` for initialization or
+`context debug enable` in an existing workspace. It records diagnostics under
+`.tmp/context-runtime/debug/`; it grants no authority and is not source evidence.
 
-### Conversation modes
+If the executable cannot start (`ENOENT` or exit 127 naming `context`), explain
+that the CLI is missing and ask the user to install or authorize installation:
 
-Enable debugging only when the user explicitly requests it. If initialization
-is required, pass `--debug` to `context entry` and execute its returned
-`context init ... --debug` command; do not run a workspace-only debug command
-before initialization. For an existing workspace, run `context debug enable`
-before workflow evaluation. Debugging records traces below
-`.tmp/context-runtime/debug/` but does not grant workflow authority or provide
-source evidence.
+```bash
+npm install -g @c4a/context-cli@latest
+context plugin install
+```
 
-For explicitly authorized fully managed operation, use:
+Stop with that recovery. Do not run an installation preflight or auto-install;
+a normal Context `not found` diagnostic does not mean the executable is missing.
+
+## Match the request to the current work
+
+A status question is read-only; an explicit continuation follows the current
+Route. A new write request must first register its target through the relevant
+entry below. The old Route does not incorporate that request or authorize
+continuing unrelated work. Ask only when missing information changes the action
+or scope; discussion and save-only requests can end without production.
+
+- **Sources, notes, sessions or changed upstream material:** read
+  `guidance.knowledge_updates.path` returned by `context entry`, then use its
+  source/update action. This installed guide also covers page/source organization,
+  same-task source adjustments, rollback and optional upstream corrections.
+- **Prepare, commit or restore the workspace:** read the matching
+  `guidance.workspace_prepare.path`, `guidance.workspace_commit.path` or
+  `guidance.workspace_restore.path` from `context entry`. Lead these tasks with
+  Host tools and the supplied checks; do not continue unrelated production merely
+  because entry also offers a status command. Context owns task-state cleanup;
+  Git target selection, commits and environment recovery remain Agent-led.
+- **One page correction:** use the current text through:
+
+  ```bash
+  context revise "<candidate title, path, or id>" --instruction "<requested correction>" --format json
+  ```
+
+  Resolve an ambiguous target with the user. A current Candidate reopens its
+  owning Author workset; an approved page uses the local revision flow. Follow
+  the returned status command and its new Route.
+- **Several approved pages, program regeneration or a rebuild during production:**
+  read the maintenance procedure linked by the knowledge-updates guide and use
+  its registration input. Queued means saved, not revised; explain its waiting
+  condition and do not register the same request repeatedly.
+- When the user asks to compile, build or deliver a batch, use the current Route
+  to choose early delivery or rebuilding; do not guess a command name.
+- **Delivery batch size:** use `context run --delivery-size <1–50|auto> --format json`
+  for an explicit user preference; it applies to future theme waves in this task.
+- **Earlier delivery of newly authored pages:** use the Author Route's
+  `delivery.request.command` (`context run --deliver --format json`). Finish any
+  running command first. Complete the current Author batch, then follow the
+  returned composition, Review and build steps. This does not approve content
+  or merely rebuild old approved pages; all Author tasks need not finish first.
+- **An independent new task while work remains:** explain saved results,
+  unfinished scope and concrete rollback losses. Reuse or obtain the user's
+  choice to finish the current task or roll back an explicit scope. Do not
+  promise arbitrary task suspension. Same-task adjustments and local maintenance
+  preserve unrelated work and use their own routes, not an independent-task reset.
+
+Never hand-edit `knowledge/` or `dist/`, create a side-channel revision page, or
+clear runtime state to force a transition. Explicit historical restoration may
+restore exact Git-saved workspace files after the preparation guide has ended
+old task state; it is not an alternative content-writing path. Do not infer sources, extraction
+scope, review decisions or package choices from surrounding files. Operations on
+source repositories—clone, checkout, reset, fetch, install, build or test—require
+explicit authorization for that scope.
+
+## Follow the current Route
+
+`workflow.current` is the current-step authority. Preserve returned revisions,
+authority flags and payload contracts. Keep managed authority only in this
+conversation, reuse it for resumed evaluations of the authorized request, and
+stop using it when revoked. Additional `--authority` values also require an
+explicit grant.
+
+After continuation is authorized or the new target is registered, both modes
+may use `context run --until blocked-or-complete` for consecutive mechanical
+steps. With explicit managed authorization:
 
 ```bash
 context run --managed --until blocked-or-complete --format json
 ```
 
-Use `--managed` for every resumed workflow evaluation in the same active
-request. Never persist or reuse that authority in another conversation, and
-stop using it when the conversation ends or the user revokes it. Pass any
-additional `--authority` only when the user explicitly grants that authority in
-this conversation.
-
-The managed loop executes only Route-selected work and returns the current
-`workflow.current` whenever Agent reading, project configuration, a human Gate,
-host execution, diagnostics, or a non-unique plan needs attention. Resume from
-that returned Route; never reconstruct a command from an earlier step.
-
-Code knowledge is published under `codeindex`. Context mechanically audits each
-module's input analysis, stable boundaries, facts, explanation, evidence scope,
-and page shape without producing a total score. Blocking mechanical failures
-reopen the owning Author or Composer workset; advisory metrics remain warnings
-and do not create a retry ledger or override Gate. If a legacy workspace returns
-`route.extract.codeindex-migration-required`, execute only its migration
-command; do not rename `codegraph` paths manually.
-
-### Discover Indexer Providers before selection
-
-For `indexer-provider-required`, `indexer-provider-unavailable`,
-`indexer-customization-required`, `indexer-customization-invalid`, or
-`indexer-customization-upstream-changed`, read
-`node_modules/@c4a/context/docs/guides/indexer-provider-and-customization.md`
-before proposing a selection or project change. It defines the registry-only
-default, six-level customization ladder, upgrade conflict handling, debugging
-commands, and the exit condition for each level. Do not replace it with a
-remembered or host-specific workflow.
-
-When the current Route starts a new Code or Markdown indexing task, its
-`configure-indexer-providers` Action input already contains the exact applied
-requirements and CLI-bundled Provider catalog. Report those bundled entries
-together with every other Indexer Skill already visible through the current
-host. The conversational report must
-include each Skill name, readable exact version when available, and source type
-(CLI-bundled community, workspace, installed plugin, or authorized marketplace
-result). When the host already exposes an exact Skill root or `SKILL.md` path,
-read only its YAML frontmatter and sibling `context-indexer.yaml` during
-discovery. The manifest version is authoritative;
-`metadata.context-provider-version` is a readable copy that must match it. Do
-not load the Provider body or other guidance until the Route selects it. If the
-host exposes no readable root or exact version, report the version as
-unavailable rather than guessing it.
-
-Group observations with the same Skill name and exact version into one
-conversational item and list all observed source types on that item. An
-installed projection of an identical CLI-bundled identity is not a second
-Provider. Keep different versions separate; never use source count or discovery order as
-selection precedence. Do not search arbitrary directories, infer host cache
-paths, install a plugin, or query a marketplace unless the user separately
-authorizes it. Keep this discovery report only in the conversation: do not
-write it to `src/`, `package.json`, lifecycle state, receipts, audit output, or
-`dist/`. Do not repeat it during an unchanged task resume; repeat it only for a
-new indexing task, a changed host-visible Skill set, or an explicit diagnostic
-request.
-
-Return only `stage: provider-selection`, the non-CLI
-`host_visible_skills`, and the selected semantic `indexers` through the exact
-`context action complete-current` command returned by the Route. The CLI owns
-construction of the full registry payload, fallback/conflict checks, static
-validation, Provider resolution and staging, final validation, and atomic
-application of `src/indexers.yaml`. Do not call their low-level commands as a
-second production workflow.
-
-If a selected external Provider needs Host resolution, the next current Route
-contains one `context.resolve-indexer-provider/v1` Host Action and its exact
-request. Invoke that Host Action once, then submit
-`stage: provider-resolution` with the returned Host result through the Route's
-`complete-current` command. If the Bundle carries a non-allowlisted program,
-the following current Route presents the existing program-execution Gate; wait
-for its user/session-authority decision and submit that decision through
-`complete-current`. A recovered `provider-finalization` Route consumes
-only its fixed Action input; it must not resolve or install the Provider again.
-
-### Follow the current Route
-
-Treat `workflow.current` as the current-step authority:
-
-1. Read every `resources.required` item whose `read_state` is `read-required`.
-   Read a returned `path` completely, or execute a returned resource `command`
-   and read its complete output file. For a current Indexer Partition, Author,
-   Composer or structure-review Route, read the materialized files and then use
-   the Route's immediate completion command; do not create or submit a read
-   receipt. Other workflow resources may still require the returned receipt
-   command. Materializing a resource is not reading it. Keep those receipts only
-   in this conversation and submit them with
-   the exact returned `context status --resource-receipts @<file>` command. Use
-   `after_read_receipts` only after the full resource has been read. The exact
-   `resources.after_read.command` already returns the re-evaluated
-   `workflow.current`; continue from it without an additional status call.
-2. At a Gate, keep inspection and resolution phase-local. Read an
-   `inspection_action` resource only while inspecting the decision, and read a
-   `resolution_action` resource only after the user confirms the Gate. Neither
-   replaces ordinary required resources.
-   For ordinary Knowledge Review, follow the Route-selected dialogue: do not
-   advertise force approval in the initial prompt. If the user cannot access
-   the report, only their exact current-conversation reply `强制批准` authorizes
-   the returned force-approval resolution command; generic approval wording
-   does not.
-3. Execute only `commands` returned by the Route, preserving revision and
-   authority flags exactly. A command marked `after-human-confirmation` waits
-   for the current Gate decision. Run a command whose `execution.target` is `agent-host`
-   as an exact top-level host action with the required host access,
-   not inside a restricted child sandbox. Follow the Route-selected procedure
-   for its audit and approval contract; never invent a payload, destination, or
-   substitute command.
-   A Context command is complete only after its process returns an exit code and
-   receipt. If the host reports that it is still running, keep polling that same
-   invocation; never start a second Context write command in parallel.
-   Treat a code-extraction batch preview as one Route action. Read its complete
-   index-unit report and keep same-kind capability or scale decisions in the
-   single returned Gate; do not ask about modules one by one. A non-delegatable
-   extraction Gate must stop even in fully managed mode.
-4. If `configuration` is present, edit only the named project file and use the
-   selected resources as its contract.
-5. After every action or configuration change, run status again. The managed
-   loop performs this re-evaluation internally. A phase-local `next_action` can
-   continue that operation but never replaces the workspace Route.
-
-Explain, ask, confirm, and summarize in the user's current conversation
-language. Keep commands, flags, paths, ids, status values, JSONL keys,
-`source_ref` values, and copied CLI tokens unchanged.
-
-Keep a conversation-local list of HTML review reports that the user actually
-used to make a review decision. Preserve each exact report URL or local path
-and its reviewed scope when the Route provides them. In the final completion
-summary, include one compact `Review reports` section containing those exact
-references. Do not scan workspace internals to reconstruct the list, persist a
-second ledger, invent a public URL, or describe an inaccessible report or a
-fully managed/force approval as user-reviewed.
-
-When the user explicitly asks to publish a completed build, treat publication
-as a downstream distribution step outside the Context Route. Use only an
-explicitly installed distribution tool and its documented complete-output
-upload command. If no such tool is available, stop after the local build and
-explain that Context itself does not publish to a hosted service.
-
-Do not infer repo sources, extraction scope, review decisions, or package output
-choices from surrounding files. Do not call source-repo operations such as
-clone, checkout, reset, fetch, install, build, or test without explicit user
-approval.
+The CLI loop returns when Agent work, configuration, a Gate, host execution or
+a blocker needs handling. A return for Agent work hands execution to you; it
+does not end the authorized task. Follow the returned Route within existing
+authority; do not reconstruct commands from earlier steps.
+
+**Read.** Read each `resources.required` item marked `read-required`, including
+the complete returned file and any required direct files it names. If a resource
+has a `command`, execute it and read its output; materializing is not reading.
+Current Indexer Partition, Author, Composer and structure-review files need no
+read receipt: use their immediate completion command after reading. For other
+resources, follow the returned receipt instructions, keep receipts in this
+conversation, and use the latest `next_action.command` carrying that context.
+When only direct files remain, `resources.after_read.command` acknowledges them
+together. Do not assemble receipts or reuse an older after-read command.
+
+**Act.** Execute the Route's commands. A command marked
+`after-human-confirmation` waits for the current Gate decision. Keep Gate
+inspection and resolution separate: inspection resources apply while inspecting;
+resolution resources apply once the decision is authorized. Neither replaces
+ordinary required reading. For ordinary Knowledge Review, use its selected
+dialogue; only the exact reply `强制批准` authorizes the report-inaccessible
+force-approval route. Do not offer that shortcut initially or treat generic
+approval as equivalent.
+
+For `execution.target: agent-host`, use the exact top-level host action with
+its required access, not a restricted child sandbox. For `configuration`, edit
+only the named file using the selected resources. A code-extraction preview is
+one batch decision: read its whole index-unit report and group same-kind
+capability/scale questions rather than asking module by module. Non-delegatable
+Gates still stop managed execution.
+
+A write is complete only when its process returns an exit code and receipt.
+Poll the same running invocation; never start a second workspace writer.
+Mechanical blockers follow the returned repair/recovery action; advisory
+warnings do not independently require rewriting content. Migration also uses
+its returned command, not manual path renames.
+
+**Continue.** Read `next_route.file` for the full Route after a compact receipt;
+`result_file` is for full diagnostics. Otherwise use the returned workspace
+Route (`next`, `continuation.next` or `workflow.current`). Do not call status
+again when that Route is present; refresh after configuration changes or when
+none was returned. A phase-local `next_action` is not a workspace Route.
+If `next_preparation` fails after committed outcomes, execute its recovery
+without resubmitting accepted work. Stage completion is not workspace completion:
+Changed delivery content must finish Review, close and build through their Routes.
+An empty Composer result is a decision not to add derived content, not an API
+regeneration or proof that existing pages meet a later revision request. Do not
+infer maintenance targets from Composer task names or count.
+
+When the Graph reports complete, compare the user's original and subsequent
+requests with actual delivered results and registered maintenance targets.
+`next: null` alone can also mean next-step preparation failed; inspect the receipt.
+A complete registered workflow or empty queue does not settle unregistered
+conversational requests. Continue already authorized outstanding work through the
+normal Context revision/update entry and its fresh Route, respecting existing
+Gates. Do not ask for another "continue" solely because production finished.
+Report a blocker only when a required input, permission or actual entry failure
+prevents progress; do not invent a missing Review/build after an empty Composer.
+
+For an authorized end-to-end task, continue while the current Route is actionable
+within that authority. Report batch progress during execution, without ending
+the turn to wait for another “continue”. End when the requested scope is complete,
+the user asks to pause, or a required decision, permission, unresolved blocker or
+actual Host limit prevents further work. If ending early, state the specific
+reason and remaining work; do not describe a CLI return or batch completion as
+that reason. Fully managed mode does not waive required human decisions.
+
+When the user's full production scope has finished close/build with no remaining
+work, mention once that the workspace results can be committed locally. This is
+optional, not a Gate or an automatic commit; omit it for intermediate deliveries
+and when the user declined it. Use the commit guide if the user chooses it.
+
+## When selecting or customizing Indexers
+
+Read `context.indexer.provider-guide` at the path supplied by the Route and the
+selected Action's instructions. They own the selection schema, layer rules,
+customization ladder, program authorization and upgrade recovery.
+
+Use the supplied requirements and CLI-bundled catalog. Discover relevant
+external Providers only among Host-visible `context-…-indexer…` Skills and read
+their exposed manifest. Host switches and installation channels determine
+availability; the catalog does not override a disabled Skill or a chosen
+business replacement. Do not scan caches, run a discovery preflight, or create
+a second enabled-Skill registry.
+
+Copy bundled Provider identities from the catalog, even if the same version
+is Host-visible. Read only selected Provider guidance. Keep one primary for an
+existing page; supporting note/session material belongs in its evidence/read
+scope, with compatible extension guidance when needed. Source type alone does
+not require a new page. Submit the selection through the Route's
+`complete-current` contract; the CLI validates, resolves and applies it. Follow
+returned Host-resolution and program Gates without calling low-level commands
+as a parallel workflow. Provider finalization consumes its existing input and
+must not resolve or install the Provider again.
+
+## Progress reporting format
+
+Every user-facing progress update, in conversation or in a report, must use
+these two bold lines in this order, with the actual values inside the brackets:
+
+**[总体进度：已交付 33/125 页]**
+**[当前分片：已规划 3/8 项]**
+
+Use CLI `progress.scopes` (or `indexerProgress.scopes` in status) as the
+single source for progress in conversation and reports. It separates:
+- `overall`: delivered pages and cumulative planning for the current Indexer run;
+- `wave`: writing tasks, observed pages and composition for the current wave;
+- `slice`: tasks in the currently active Route slice.
+
+Planning completed counts currently valid accepted tasks, not lifetime effort.
+When overall.planning.needs_recheck is nonzero, report “规划当前有效 X/Y 项；Z 项因任务绑定变化待复核”.
+Do not describe a lower valid count as lost pages or silently restarting from zero.
+The CLI reason identifies binding changes, not proof that source code changed;
+do not invent a more specific cause.
+
+Keep these scopes separate. A wave or pause target never replaces the overall
+scope. Preserve overall planning across Author, Composer and Review transitions.
+Use each counter's `unit`: task means 项/任务, page means 页. A writing task is
+not automatically one page. A null total means 总数待确定, not zero or the
+number of currently prepared tasks. Revisions can overlap delivered pages;
+do not add wave tasks to delivered pages to invent a page total.
+
+Use two bold progress lines. The first combines `overall` and a clearly labelled
+`wave` supplement; the second uses `slice`. For example, with matching CLI values:
+**[总体进度：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
+**[当前分片：补充内容检查 0/8 项]**
+
+A completion receipt's `submitted_slice` describes the slice just submitted;
+`progress.scopes.slice` can already describe the next Route. Use the former when
+reporting submission success and the latter when announcing the next slice.
+Never combine their numerators and denominators. A null slice means no active
+Agent task slice, not that the workflow is complete. During Review/build, state
+the returned Route action briefly rather than inventing a slice ratio.
+If progress is unavailable after task cleanup, say the counters are unavailable;
+do not turn the last wave into the overall scope or report delivery as zero.
+Continue authorized work after an update; only the agreed delivery stop or an
+actual unresolved blocker permits stopping. This format governs progress, not
+answers, review findings or necessary questions.
+
+## Report the actual outcome
+
+Use the conversation language for explanations and questions; preserve commands,
+flags, paths, ids, `source_ref` values and copied CLI tokens. Distinguish saved
+sources, accepted drafts and delivered pages. Use the required two-label format
+above for every progress summary.
+
+Keep the exact HTML review report links the user actually used in this
+conversation. Include those links in a compact final `Review reports` section
+when applicable; do not reconstruct them from runtime files or describe managed,
+force-approved or inaccessible reports as user-reviewed.
+
+Publication is outside the Context production Route. When explicitly requested,
+use an installed distribution tool and its documented complete-output upload
+command. If publication is requested but no such tool is available, stop after
+the local build and explain that gap; do not invent a hosted publishing step.