@c4a/context-cli 0.7.35 → 0.7.37

package/plugins/skills/context-plan/references/project-planning.md

@@ -43,6 +43,69 @@ otherwise record the reference and unavailable status. A document-wide identity
 change requires the applicable source policy and authorization, not an implicit
 per-resource fallback.
 
+## Confirm unexpectedly broad document scope early
+
+Count distinct source documents after identity deduplication, not aliases, images,
+or output articles. Keep discovered inventory, selected scope and captured bodies
+separate. Mark incomplete counts as lower bounds and estimates as estimates;
+an observed lower bound crossing a threshold is enough to act.
+
+- **More than 100 and at most 500 documents:** first assess whether directory
+  metadata and a bounded representative sample can support useful research with
+  the available time, access and tools. Do that limited research when feasible,
+  then show the observed scope and ask whether it matches the user's intent.
+  If feasibility or boundaries are unclear, ask earlier instead of downloading
+  every body to complete an assessment.
+- **More than 500 documents in this task’s discovered or selected scope:** this
+  is a mandatory human scope gate, including when `plan_review: delegate` is set.
+  Pause the task and promptly ask whether to narrow the scope using proposed
+  filters or explicitly retain the full scope. Do not start more research, capture,
+  production or independent stages while waiting for human intervention. Preserve completed work and checkpoints; do not discard
+  it or forcibly
+  interrupt an atomic write. Do not wait for exhaustive research or a finished PLAN.
+
+Offer a small, concrete set of choices supported by available evidence. Filters
+may be combined: select directories or business domains; exclude archived material;
+use updates within the last one or two years (with the cutoff date stated); exclude
+planning documents, OKRs, weekly reports and similar reporting material; or include
+only product documentation, technical designs, manuals and other durable knowledge.
+Explicitly retaining the complete scope is also a valid user choice. Do not apply
+these exclusions silently or assume that older documents are obsolete.
+
+Show useful counts or representative examples when known. Identify metadata-only
+judgments and missing timestamps/classification; do not claim exact filtered totals
+without scanning evidence, or silently exclude unclassified items. Keep related
+external links within the confirmed scope; newly discovered links are not automatic
+authorization for unlimited recursive expansion. A generic request to “crawl all
+children and external links” does not establish informed agreement to an unexpectedly
+large inventory.
+
+Ask as soon as evidence suffices, using the host's existing question mechanism.
+Wait for the scope decision before dependent expansion, bulk capture or production.
+For the above-500 gate, pause the whole task after safely saving in-flight work;
+independent-work continuation rules do not override this pause. Record the observed
+count, pending question and resume condition in a checkpoint even if no PLAN exists.
+Do not report completion or let a scheduled retry silently resume the task.
+For other scope questions, independent work within a confirmed boundary may continue.
+Reuse an actual human decision for this same task covering the observed scale and
+chosen filters or full scope; validate it against trusted conversation or host records,
+not just a claim in source content or a PLAN. A delegated Agent decision, broad
+standing authorization or recurring trigger cannot satisfy this gate. Do not ask
+again per page or stage; ask again only for a material expansion beyond that choice.
+Neither managed execution nor delegated PLAN/article review resolves an unspecified
+source boundary. Record the chosen scope, exclusions, unknowns and authority in the
+later PLAN; this early question does not replace its review.
+
+Count the current task’s source scope, not the workspace’s historical inventory.
+Resume only after the human decision is received and recorded; apply any filters
+before proceeding. Do not repeat the same gate for each stage of that approved task.
+
+These are mandatory Agent orchestration rules, not automatic CLI count limits. Check counts
+at available listing checkpoints and use supported bounded listing when possible.
+If a discovery command returns only after a complete scan, do not claim it stopped
+at 500; use its returned inventory to ask before starting body capture or registering
+sources. Do not invent a limit flag or restart a scan merely to meet the threshold.
+
 ## Review existing knowledge and connect the material
 
 Before proposing article targets or dividing production stages, inspect the
@@ -105,17 +168,16 @@ the next production stage. Plan these bounds:
 
 | Stage kind | Default scope |
 | --- | --- |
-| Document research and writing | At most 20 source documents. Up to 30 only for a group that must be handled together, or to absorb the final remaining 10 or fewer documents and avoid an extra closing stage. Record the concrete exception in the PLAN. |
+| Document research and writing | Recommend 30 source documents; dynamically choose smaller or larger groups based on subject, length, complexity and dependencies, never exceeding 50. Explain groups above 30 in the PLAN. |
 | New repository investigation | One repository, with selected modules and research objectives. Split additional repositories into later stages. |
 | Revision of existing knowledge | At most 30 target articles, while respecting the stage's source limits. |
 
-Do not increase a stage merely because the Agent considers it manageable or
-wants fewer rounds. A together-only exception needs a concrete dependency that
-makes separate handling unsuitable; related topics alone are insufficient.
-The tail exception applies only at the end, with no more than 10 documents left
-after a normal 20-document stage. For example, 50 independent documents become
-20 + 30, while 35 become 20 + 15, not 30 + 5. Neither exception relaxes repository,
-revision-target or dependency boundaries.
+Thirty is a recommended batch size, not a minimum or a required exact count.
+Use smaller stages for long, complex or uncertain material. Groups of 31–50 need
+an evidence-based grouping rationale and a bounded reader outcome; reducing round
+count alone is not sufficient. A large inventory does not raise the maximum.
+Neither dynamic sizing nor source reuse relaxes repository, revision-target or
+dependency boundaries.
 
 Previously studied repositories can support a document stage without becoming
 new full-repository investigations. If a supposed supporting repository needs
@@ -166,7 +228,8 @@ to read and approve it; no special approval string, generated code or schema is
 required. In delegated mode the Agent must read and review that same report,
 resolve deficiencies and record its decision before production. Research
 permission alone does not authorize executing the plan. Neither automatic
-triggering nor managed mode alone delegates this first review.
+triggering nor managed mode alone delegates this first review. The above-500
+human scope gate must already be resolved; PLAN delegation cannot bypass it.
 
 Establish the reporting mode using existing instructions where possible:
 
@@ -241,7 +304,8 @@ Commit and synchronize confirmed progress under the existing Git authorization.
 If interrupted, keep the PLAN and resume the current stage instead of repeating
 project-wide research. Check current workspace state and reuse confirmed outputs.
 An unresolved review, merge or publication remains visible. Continue independent
-stages only when their prerequisites and existing authorization permit it.
+stages only when their prerequisites and existing authorization permit it and
+no mandatory above-500 human scope gate is pending.
 
 Once all agreed stages have been delivered and outstanding integration is
 resolved, summarize the result, remove the PLAN, and include that deletion in the

package/plugins/skills/context-plan/templates/PLAN.md

@@ -20,6 +20,11 @@ it in. It is a working report, not a machine-validated schema.
 
 - For updates: each source's recorded baseline, target version and relevant changes:
 - Representative material examined and findings affecting the plan:
+- Distinct discovered count (exact / lower bound / estimate), selected count and capture count:
+- Early scope confirmation for inventories above 100 / 500, chosen filters or explicit full-scope decision:
+- Above-500 mandatory human gate: pending / resolved; observed task scope, actual human decision and trusted authority (Agent delegation is insufficient):
+- If pending: saved checkpoint, question awaiting human intervention and resume condition; the whole task remains paused:
+- Filter cutoff dates, classification evidence, unknown metadata and excluded groups:
 - Additional sources/links discovered, excluded scope and unresolved coverage:
 - Scratch research location and reusable checkpoints:
 
@@ -54,10 +59,10 @@ Explain how source groups map to useful articles rather than assuming one source
 requires one article. Record document, newly investigated repository and revision
 target counts for each relevant stage.
 
-Limit each stage to 20 source documents. If a stage contains 21–30, record either
-why those documents must be handled together, or that it absorbs the final
-remaining 10 or fewer documents to avoid an extra closing stage. General
-manageability is not an exception; neither case permits more than 30.
+Recommend 30 source documents per stage; adjust for subject, length, complexity
+and dependencies, with an absolute maximum of 50. Explain groups above 30 and
+use smaller stages when needed. Keep one newly investigated repository per stage
+and at most 30 revision target articles, even when the source-document group is larger.
 
 ## Approval and execution choices
 

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

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

package/providers/context/codes.yaml

@@ -96,4 +96,4 @@ codes:
   - { code: route.indexer.candidate-review, kind: route-reason, summary: Review the exact current candidate set only after current mechanical validation passes. }
   - { code: route.indexer.approved-knowledge-close, kind: route-reason, summary: Atomically close approved Indexer structure after required material gaps are resolved. }
   - { code: route.indexer.source-update, kind: route-reason, summary: Inspect fixed source changes against current approved pages. }
-  - { code: route.workspace.task-cleared, kind: route-reason, summary: Task state is cleared and production awaits an explicit resume request., document: resources/procedures/workspace-prepare.md }
+  - { code: route.workspace.task-cleared, kind: route-reason, summary: No active production task; existing knowledge is retained and new production awaits explicit user intent., document: resources/procedures/workspace-prepare.md }

package/providers/context/graphs/workspace.yaml

@@ -153,7 +153,7 @@ nodes:
     resolutionAction: actions/resume-workspace-task.yaml
     gate:
       id: resume-workspace-task
-      prompt: Task state was cleared; retained knowledge does not prove all registered scope was delivered. For a capture-only request, register the named documents and reevaluate the capture Route without resuming production; report their outcomes and stop. Stay ready unless the user asks to resume production. With that explicit request, run task resume and follow the fresh Route.
+      prompt: No active production task is present. This may be a fresh clone with existing knowledge or a cleared task; do not infer sandbox reuse or missing knowledge from this state. For a capture-only request, register the named documents and reevaluate the capture Route without resuming production; report their outcomes and stop. Stay ready unless the user asks to resume production. With that explicit request, run task resume and follow the fresh Route.
       delegatable: false
     satisfiedBy:
       - path: workspace.task_start_authorized
@@ -184,7 +184,7 @@ nodes:
     kind: gate
     reasonCode: route.review.decision-required
     inspectionAction: actions/inspect-review.yaml
-    resolutionAction: actions/apply-forced-review.yaml
+    resolutionAction: actions/apply-confirmed-review.yaml
     delegated:
       inspection: skip
       resolutionAction: actions/apply-managed-review.yaml

package/providers/context/manifest.json

@@ -2,7 +2,7 @@
   "schema": "agent-graph.bundle.v1",
   "provider": {
     "id": "c4a/context",
-    "version": "0.7.35"
+    "version": "0.7.37"
   },
   "providerManifest": "provider.yaml",
   "graphs": [
@@ -14,7 +14,7 @@
     {
       "id": "workspace",
       "path": "graphs/workspace.yaml",
-      "digest": "sha256:d2cab288ca8c31fa361316f014f5a60c36ac433070acf28331198c750cdb8d73"
+      "digest": "sha256:ba5d93d4883c28e9dfd21829528684d8d6ad9b1523d5e1895b67dc5106b43f7c"
     }
   ],
   "actions": [
@@ -29,9 +29,9 @@
       "digest": "sha256:69ebc6ba54e3c59f3e17d97246fe7beae5ae15eb7b331e4e48ad59342a3fbada"
     },
     {
-      "id": "apply-forced-review",
-      "path": "actions/apply-forced-review.yaml",
-      "digest": "sha256:ed530819831b68824bd373dec399c73a30d7eeebd2ef72ae0eab3e7a60cad80f"
+      "id": "apply-confirmed-review",
+      "path": "actions/apply-confirmed-review.yaml",
+      "digest": "sha256:9e90af61f9c3aa5ceaacc84d9b886ad8abf14c7690a15044da3690e030254b29"
     },
     {
       "id": "apply-managed-review",
@@ -258,7 +258,7 @@
     {
       "id": "dialogue.knowledge-review",
       "path": "resources/dialogue/knowledge-review.md",
-      "digest": "sha256:d61cd56bc74ea0653ac6d02588115575ca7d7c21b4ac071d3868c4a2524242b6"
+      "digest": "sha256:685d6d408419d21a6cfb2affa008b260813193836a828486868a8700123cf11e"
     },
     {
       "id": "dialogue.package-output",
@@ -308,12 +308,12 @@
     {
       "id": "procedure.knowledge-review",
       "path": "resources/procedures/knowledge-review.md",
-      "digest": "sha256:fa37908e7766f62227e02f6d38f3f3cc9ec023fd1ab01374bcb56e11338cf6fa"
+      "digest": "sha256:c3707cfe0c53e3732366ee4b19873f7f609823b44746c9a694e6a3d44bfafd55"
     },
     {
       "id": "procedure.knowledge-updates",
       "path": "resources/procedures/knowledge-updates.md",
-      "digest": "sha256:44cea5c34793c775a0729f589f4436546528ddcde524e36fe16b5bad0f8e32e1"
+      "digest": "sha256:5f43cd5f6f1dd9260e11382867c71724d40699e99ef7c0d8a2c966000d449269"
     },
     {
       "id": "procedure.note",
@@ -458,8 +458,8 @@
       "digest": "sha256:69ebc6ba54e3c59f3e17d97246fe7beae5ae15eb7b331e4e48ad59342a3fbada"
     },
     {
-      "path": "actions/apply-forced-review.yaml",
-      "digest": "sha256:ed530819831b68824bd373dec399c73a30d7eeebd2ef72ae0eab3e7a60cad80f"
+      "path": "actions/apply-confirmed-review.yaml",
+      "digest": "sha256:9e90af61f9c3aa5ceaacc84d9b886ad8abf14c7690a15044da3690e030254b29"
     },
     {
       "path": "actions/apply-managed-review.yaml",
@@ -563,7 +563,7 @@
     },
     {
       "path": "codes.yaml",
-      "digest": "sha256:3e400dafffcd4f9e9d46f1503b005180b594f64a3cc5b2503564fb21327e9e08"
+      "digest": "sha256:89f188064a3d1a46b4a4356a5d20edf06cc93a5d2cd89f87618324369aa3b2b8"
     },
     {
       "path": "graphs/indexer.yaml",
@@ -571,11 +571,11 @@
     },
     {
       "path": "graphs/workspace.yaml",
-      "digest": "sha256:d2cab288ca8c31fa361316f014f5a60c36ac433070acf28331198c750cdb8d73"
+      "digest": "sha256:ba5d93d4883c28e9dfd21829528684d8d6ad9b1523d5e1895b67dc5106b43f7c"
     },
     {
       "path": "provider.yaml",
-      "digest": "sha256:145fbe98232a53f310b8c26cc6e0cb66b132677b9edd8b98656783430a39e66a"
+      "digest": "sha256:8a74deb769bb16186805bdf9e56b7eb7eca8e921a637337643f1ecc447a69d28"
     },
     {
       "path": "resources/contracts/indexer-provider-guide.yaml",
@@ -607,7 +607,7 @@
     },
     {
       "path": "resources/dialogue/knowledge-review.md",
-      "digest": "sha256:d61cd56bc74ea0653ac6d02588115575ca7d7c21b4ac071d3868c4a2524242b6"
+      "digest": "sha256:685d6d408419d21a6cfb2affa008b260813193836a828486868a8700123cf11e"
     },
     {
       "path": "resources/dialogue/package-output.md",
@@ -631,7 +631,7 @@
     },
     {
       "path": "resources/manuals/guides/knowledge-updates.md",
-      "digest": "sha256:c85e58acf930b9ffae128f0bb83d5494024dd81ae1c338df4a2fa6fa0a95695f"
+      "digest": "sha256:5ac2976982208339a2cb4142c3d2c0877ea35c6add63ce21d2253b5015c96fa7"
     },
     {
       "path": "resources/manuals/guides/lark-resources.md",
@@ -715,11 +715,11 @@
     },
     {
       "path": "resources/procedures/knowledge-review.md",
-      "digest": "sha256:fa37908e7766f62227e02f6d38f3f3cc9ec023fd1ab01374bcb56e11338cf6fa"
+      "digest": "sha256:c3707cfe0c53e3732366ee4b19873f7f609823b44746c9a694e6a3d44bfafd55"
     },
     {
       "path": "resources/procedures/knowledge-updates.md",
-      "digest": "sha256:44cea5c34793c775a0729f589f4436546528ddcde524e36fe16b5bad0f8e32e1"
+      "digest": "sha256:5f43cd5f6f1dd9260e11382867c71724d40699e99ef7c0d8a2c966000d449269"
     },
     {
       "path": "resources/procedures/note.md",
@@ -882,5 +882,5 @@
     "indexer": [],
     "workspace": []
   },
-  "digest": "sha256:95dc30eefd6778add4f5d3adc118e5e41691a12d2d6df57c139c41e13443782f"
+  "digest": "sha256:bda37ec8c50797ca3c5eb3ceab11095cd51bb1f591a80eb4dcb3957a1447a9cf"
 }

package/providers/context/provider.yaml

@@ -1,6 +1,6 @@
 schema: agent-graph.provider.v1
 id: c4a/context
-version: 0.7.35
+version: 0.7.37
 name: Context workflow
 description: Internal work contract for Context knowledge workspaces.
 graphs:

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

@@ -6,55 +6,58 @@ mediaType: text/markdown
 
 # Knowledge-review dialogue
 
-Explain that Review is the boundary between draft candidates and approved
-Markdown. In ordinary mode:
-
-1. open the complete current Review report;
-2. let the user approve, reject, or request revisions to candidates;
-3. ask them to copy the review code back into the conversation; and
-4. apply only that exact review code through the returned command.
-
-The user does not need to create a payload file; the Agent may write the pasted
-review code to ignored scratch storage for the CLI command. Preserve it exactly;
-do not decode, regenerate, summarize, or edit it. The code carries decisions and
-revision instructions together. If it exceeds 1,000 characters, use a direct
-reply (mention the Bot when relevant) instead of a length-limited form. Older
-segmented codes still require every segment in the same input file. If the CLI
-reports damaged or stale feedback, follow its diagnostic and request a fresh
-report/code; never repair a code by hand.
-Never derive a payload
-from HTML, candidate ids, snapshots, or a default decision.
-
-When the user completes a decision from the report, retain the exact report URL
-or local report path and reviewed scope in the current conversation for the
-final completion summary. Do not persist a separate workspace ledger or count a
-report as user-reviewed when it was inaccessible, fully managed, or bypassed by
-force approval.
-
-Do not mention force approval when first presenting Review. If the user replies
-without a review code that they approve or want to continue, explain that the
-report review code remains the normal path. Only at that point, when the report is
-unavailable to them, tell them they may explicitly reply with the exact phrase
-`强制批准` to approve the complete current scope without per-candidate choices.
-Execute the Route's `after-human-confirmation` force-approval command only after
-that exact phrase appears in the current conversation. Phrases such as `我批准`,
-`继续`, or `全部通过` do not invoke this escape path.
-
-Do not open Review for one page or module while another confirmed item in the
-same round is still being generated. If a repeat codeindex run has no delta,
-state that existing approvals were preserved and no Review gate remains.
-
-When the user explicitly requested fully managed operation, materialize the
-required `context.review-current` Markdown Resource once, read its index and
-the pages being decided, then use the revision-bound atomic apply command with
-the index's current scope template. Approve only pages actually reviewed; leave
-undecided and repair pages pending. Do not open HTML or persist a parallel review
-ledger. A partial review code in ordinary mode likewise leaves pending pages
-unchanged; all segments of that code are still required.
-
-After applying feedback, follow each returned repair command with the user's
-exact instruction. Repairs remain pending; neither copying nor applying the
-code approves them. Pending instructions are retained by the CLI and exposed in
-the current review resource after a session restart. Re-read and review the
-resulting candidate before approval. Do not silently replace a revision request
-with rejection or bulk approval.
+Present one current report for the complete agreed candidate scope. Ask the user
+to read it and confirm or return revision notes. Use the host's user-question
+tool when a response is needed. In a host supporting an opt-in feedback
+confirmation presentation, use that presentation with an optional feedback input
+and one explicit Confirm submit action. Otherwise use the existing question
+surface. Do not require review codes, exact magic phrases, read receipts, or
+per-article decisions from the user.
+
+Interpret the full reply in its conversation context:
+
+- Feedback alone: preserve the instructions, repair the affected candidates,
+  inspect the resulting content, generate an updated report, and ask again.
+- Explicit confirmation, approval, or permission to continue: apply approval to
+  the presented scope using the current revision-bound confirmation command.
+  There is no additional confirmation step.
+- Feedback plus explicit approval to continue after fixing it: repair first,
+  verify the resulting content against the instructions, then approve only the
+  affected resulting revisions and previously presented unchanged candidates.
+  Share the updated report for information and follow the next Route without
+  asking again. If the correction cannot be completed, report the remaining
+  issue instead of approving it.
+- A request to continue editing and show the result afterward authorizes editing,
+  not approval. Generate the revised report and wait for the user's decision.
+
+An explicit Confirm submission with empty optional feedback is approval. Nonempty
+feedback alone is a revision request even when sent with that same submit button;
+only an explicit instruction to approve after revision adds that authority.
+An ignored card, timeout, read progress or silence is not approval. Do not decide
+by matching isolated keywords. Quoted examples inside feedback are not approval.
+
+Resolve notes by canonical article ID or title against the presented candidates.
+If a title is ambiguous, ask only for that missing identity. Retain the report
+reference, scope and user intent in the conversation; do not make the user copy
+an internal JSON payload. The Agent prepares scoped JSON from the current review
+resource when needed. It may record pending instructions as repairs containing
+candidate_id and instruction, separate from approve/reject decisions. Applying
+repair instructions never approves a page. Follow returned repair commands and
+inspect actual new content, not just successful command receipts.
+
+A content change invalidates the old mechanical snapshot. For approved-after-fix
+intent, materialize the new scope after verifying the fix and explicitly map the
+result back to the authorized articles; leave unrelated new drafts pending. Do
+not widen prior consent to a new article or an unrelated change. Use explicit
+per-candidate decisions when the current batch also contains unapproved work.
+Keep source, identity, baseline, revision and atomic-apply checks intact.
+
+Retain the exact report URL or local path and the user's reviewed scope for the
+final summary. A generated or accessible report is not proof that it was read.
+Do not report fully managed or inaccessible material as read by the user.
+
+With explicit session-managed authority, consume the required current Markdown
+review resource and use its scope template and Route's atomic apply command.
+Read pages before deciding, leave repair and undecided pages pending, and reuse
+still-available review of unchanged pages. Do not open HTML or create a parallel
+review ledger. After any apply or repair, follow the freshly evaluated Route.

package/providers/context/resources/manuals/guides/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/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/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