@c4a/context-cli 0.7.36 → 0.7.38

package/providers/context/resources/procedures/knowledge-review.md

@@ -8,7 +8,6 @@ mediaType: text/markdown
 
 Agent policy: `context.gate.knowledge_review`. An instance-specific Bot may
 override the managed default and require the ordinary HTML review decision.
-The report-inaccessible exception is `context.gate.force_review_approval`.
 
 Review is the authority boundary between candidates and approved knowledge.
 Open one report for the complete current candidate set and apply only a payload
@@ -25,20 +24,22 @@ an approved path is a migration within the user's requested scope; do not ask
 again when that scope is already clear. The resulting Candidate still enters
 Review.
 
-Without explicit session-managed authority:
-
-- open the report returned by the route;
-- let the user approve, reject, or request revisions to candidates;
-- apply the exact copied review code through the returned review apply command; and
-- retain the exact report reference and reviewed scope in this conversation for
-  the final completion summary.
-
-The ordinary Route also carries a revision-bound force-approval resolution
-Action as an escape path. Do not advertise it when first presenting Review.
-Use it only after the user cannot use the report and explicitly replies with
-the exact phrase `强制批准` in the current conversation. That reply is the
-decision; do not ask a second confirmation. It approves the complete
-current scope atomically; no candidate-specific decisions are inferred.
+Without explicit session-managed authority, open the report returned by the
+Route and request confirmation or revision notes through the host user-question
+tool. Follow the selected knowledge-review dialogue to distinguish feedback,
+approval and approval-after-repair. Keep the exact report reference, presented
+scope and user intent in this conversation. The HTML contains reading progress
+and plain revision notes, not approval authority. Normal explicit confirmation
+uses the Route's revision-bound resolution Action and the report's scope snapshot.
+No review code or special approval phrase is required.
+
+For old automation, `review approve-all --force` remains a deprecated explicit
+approval alias and applies the current candidate scope without requiring a new
+report. Prefer `--confirmed` for new calls. The CLI also accepts existing legacy
+review files and translates their decisions and repair notes, retaining scope,
+content and baseline checks. Compatibility notices go to stderr, preserving JSON
+stdout. Never request or generate a review code; the page exposes only reading
+progress and revision notes. Existing pending repairs must still be resolved.
 
 With explicit session-managed authority, materialize the required
 `context.review-current` Markdown Resource once. Read its index and every
@@ -80,16 +81,19 @@ all candidate pages as New. Existing unchanged pages show titles only; changed
 blocks and previous text remain available for comparison. Navigation without a
 Git baseline is labelled as current context, not an invented historical diff.
 
-Approve accepts a candidate. Reject durably omits it; it does not request a
-rewrite or retire an approved article. Entering revision instructions requests
-repair and locks the other choices for that page until cancelled. Bulk approval
-requires confirmation and affects only undecided pages. When the report contains
-new top-level categories, the dialog lists them and requires explicit
-acknowledgment plus an eight-second wait before confirmation is enabled.
-New descendant pages under an existing category do not trigger this extra step. The copied code binds
-the candidate scope, exact content, displayed baseline and revision instructions;
-the CLI validates these together before writing any decision. Follow returned
-repair commands, then obtain review of the repaired candidates.
+Opening a candidate marks it READ once for that browser and content version.
+Read counts and revision notes are local convenience state, never approval or
+required CLI receipts. The total includes only current candidates. Typing notes
+immediately marks a page for revision; clearing notes preserves its READ state.
+The revision counter opens a card list of titles and notes, with links back to
+the articles. Copy exports plain notes with article IDs and titles. After copying,
+a five-second dialog previews the text; only that preview is truncated at 400px.
+
+The Agent converts conversation intent into current scoped CLI decisions or
+revision instructions. A rejection durably omits a candidate; it does not request
+a rewrite or retire an approved article. Repair first, inspect the actual result,
+and obtain a new decision unless the user already explicitly authorized approval
+after the correction. The latter applies only to the same agreed article scope.
 
 Use the affected page's `Repair` command in the review material, replacing only
 the correction instruction. Current candidates are repaired within this batch;

package/providers/context/resources/procedures/knowledge-updates.md

@@ -324,16 +324,20 @@ assembled page and previous text without accepting the edit. Submit the same
 input without that flag to continue. A preview is not approval and does not make
 a stale revision valid.
 
-Review can approve checked pages while leaving repair pages pending. The HTML
-report shows the current site navigation, candidate changes and expected file
-paths. Unchanged approved pages retain their titles with omitted bodies. Enter
-revision instructions directly in the report; the copied code and following
-instruction lines must be returned together without edits. The CLI binds them to
-the reviewed content and baseline and returns repair commands while leaving
-those pages pending. Changed candidates require a fresh review. The HTML
-review code includes pending positions; managed Review provides the same current
-scope as a JSON template. Send decisions only for pages actually reviewed. Omit
-means a durable exclusion, not repair. Partial approval alone does not build.
+Review can approve checked pages while leaving repair pages pending. The report
+shows current navigation, candidate changes and expected file paths. Its READ
+progress is local to the browser. Enter revision notes in the article input,
+then copy the plain notes back to the conversation or simply confirm there.
+No review code is needed. Feedback alone leads to repair and an updated report;
+explicit approval continues the workflow. If the user asks to fix the notes and
+then proceed, verify the fix and approve only that authorized scope without
+another question. A request to edit and show the result still waits for review.
+
+The Agent uses the current resource's scoped JSON template, with explicit
+candidate decisions or repairs containing candidate_id and instruction. The CLI
+checks scope, content and displayed baseline before applying changes. Pending
+instructions survive a session restart. Omit means durable exclusion, not repair.
+Partial approval alone does not build.
 
 When the user requests an earlier delivery, use the Route's `context run
 --deliver` request. Independently approved pages can pass close/build while

package/providers/context/resources/procedures/production-requirements.md

@@ -52,6 +52,9 @@ writing batches are declared in the temporary investigation plan.
 
 After editing, run `context status --format json` and consume its current Route.
 
+Read `context action prepare-current --schema --format json` for the complete
+known-task input contract before creating a stage; no workspace or revision is required.
+
 When article targets and source grouping are already clear, put the existing
 plan fields (`capabilities`, `articles`, optional `indexer_usage`) in a file under
 `.tmp/agent-work/`, omitting only `stage`, which does not exist yet. Each article
@@ -60,27 +63,17 @@ contains `path`, `question`, `sources` and `batch`, with optional `brief` and
 command to prepare those tasks without a separate investigation-plan submission.
 This does not approve the report or permit writing before its applicable scope
 decision.
-When targets are unclear, use normal preparation and investigate the skeletons.
-
-## Configured coverage and the current request
-
-`src/indexers.yaml` describes the workspace's standing coverage configuration.
-Source registration or presence in that configuration does not, by itself, mean
-that the source needs investigation again for this request. For a bounded document
-addition or revision, identify its reader task and actual evidence dependencies;
-reuse existing approved articles and applicable completed work. Do not broaden a
-document task to unrelated code repositories merely because they are configured.
-
-In planning and completion reports distinguish:
-- work requested and completed in this task;
-- specific content gaps established by reading, with their affected reader tasks;
-- source/environment failures, and whether this task depends on those sources.
+When targets are unclear, repeat `--source <source-ref>` on the preparation command
+for the sources selected by this request. Without a selection, only a sole
+configured target is inferred; multiple targets require the Agent to select
+from the user's request, not to ask the user to understand CLI source IDs.
+The CLI prepares only this scope. A source in `evidence_source_scope` remains
+available without becoming an investigation assignment. A later article plan
+can select it in `articles[].sources`; the CLI validates and prepares that
+actual dependency before allowing writing. Missing required evidence still
+blocks the dependent article.
 
-A `pending_scopes` count is workflow state, not a count of missing topics,
-repositories to rewrite, or articles to produce. A Git spawn/baseline-read error
-means source availability could not be checked; it does not prove that existing
-knowledge is absent or obsolete. If unrelated configured sources remain blocked,
-say so as a workflow limitation rather than announcing new investigation work.
-Do not delete configured sources, invent exclusions, clear stage files, or mark
-unread material investigated to make the current task appear complete. Follow the
-returned resolution action when the workflow still needs a decision.
+Long-term configuration additions do not restart an unchanged stage. Plans and
+refreshes track this request's selected investigation and actual article inputs.
+Preserve genuinely unfinished work when extending a multi-stage request; do not
+turn an incremental addition into a whole-workspace refresh.

package/providers/context/resources/procedures/production-stage-files.md

@@ -11,7 +11,9 @@ directories. Read relevant source text before writing; a skeleton is navigation,
 not semantic evidence. Skill names guide work, not article ownership or versions.
 
 Use the [reader organization guidance](knowledge-updates.md#reader-tasks-names-and-reading-order)
-for article names, placement and manually arranged navigation. Check the draft's
+for article names, placement and manually arranged navigation.
+Use `context task adjust --inspect --format json` to obtain current categories,
+reading order and the exact revision before preparing a navigation adjustment. Check the draft's
 main reader task against its planned title and group; adjust through the existing
 plan, revision or knowledge-map flow when needed. A navigation change alone does
 not call for rewriting valid prose.
@@ -57,7 +59,7 @@ current task does not mean other authorized work is finished. New source or purp
 authorization still follows the current Route.
 
 Write results under the returned Agent directory. All submission paths are
-relative to that stage directory, even when the manifest is in `submissions/`.
+relative to `.tmp/agent-work/production-stages/<stage>/`, even when the manifest is in `submissions/`. They are never relative to `.tmp/context-runtime/` or to the manifest location. Each task lists the complete workspace-relative Markdown and reference output paths.
 Copy the CLI's submission template, keep completed tasks only, and keep each
 task's prefilled `input`. Submit the manifest using the returned command.
 Do not edit submitted files until the command returns.

package/providers/context/resources/procedures/work-start-report.md

@@ -184,32 +184,20 @@ a top-level navigation change already required by this procedure.
 
 ## Configured coverage and the current request
 
-`src/indexers.yaml` describes the workspace's standing coverage configuration.
-Source registration or presence in that configuration does not, by itself, mean
-that the source needs investigation again for this request. For a bounded document
-addition or revision, identify its reader task and actual evidence dependencies;
-reuse existing approved articles and applicable completed work. Do not broaden a
-document task to unrelated code repositories merely because they are configured.
-
-In planning and completion reports distinguish:
-- work requested and completed in this task;
-- specific content gaps established by reading, with their affected reader tasks;
-- source/environment failures, and whether this task depends on those sources.
-
-A `pending_scopes` count is workflow state, not a count of missing topics,
-repositories to rewrite, or articles to produce. A Git spawn/baseline-read error
-means source availability could not be checked; it does not prove that existing
-knowledge is absent or obsolete. If unrelated configured sources remain blocked,
-say so as a workflow limitation rather than announcing new investigation work.
-Do not delete configured sources, invent exclusions, clear stage files, or mark
-unread material investigated to make the current task appear complete. Follow the
-returned resolution action when the workflow still needs a decision.
-
-For a bounded addition inside an existing production stage, completed articles can
-enter Review with `context run --deliver --format json`. This retains pending
-configured scopes and unfinished tasks; it does not authorize approval or publish.
-Use this existing delivery path when remaining source failures are unrelated to
-the requested articles. If the selected articles need the missing repository, use
-`context source recovery-plan` and `context source restore` with an explicit local
-checkout or clone decision. Do not ask users to investigate unrelated repositories
-just to deliver saved notes, and do not clear gaps to imitate task completion.
+Long-term source configuration is the authorized reading boundary, not the work
+requested in every conversation. Prepare this request's selected investigation
+sources or known article tasks. Keep unused supporting material available for
+later article plans without treating it as unfinished work. For an addition to
+an existing article, prefer the existing article-revision workflow with the
+selected supporting sources rather than starting unrelated production.
+
+Report this request's planned and completed work. Restore missing sources that
+its investigation or articles actually require. Reference material not selected
+for this work does not need restoration just to complete an independent note.
+Never infer missing knowledge merely from unavailable source-code checkouts.
+
+For an explicitly requested partial delivery, `context run --deliver --format json`
+reviews completed articles while retaining genuine remaining tasks and selected
+investigation. It does not approve or publish articles, and is unnecessary for
+an otherwise completed bounded request. Do not clear unfinished work to force
+completion; ordinary source authorization and citation checks still apply.

package/providers/context/actions/apply-forced-review.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: apply-forced-review
-runner: host
-effect: write
-handler: context.review.force-approve-current