@c4a/context-cli 0.7.30 → 0.7.35

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

@@ -0,0 +1,250 @@
+# Project research and staged delivery
+
+## Project boundary and research materials
+
+Work in the knowledge project selected by the user. Find its Git root and reuse
+the existing workspace; a matching PLAN may be outside a nested Context working
+directory. If the target project is not established, resolve that choice before
+writing its plan. Do not create another repository merely to hold research.
+
+Use this local layout when new scratch material is needed:
+
+```text
+<project-git-root>/
+  PLAN-YYYYMMDD-slug.md
+  .tmp/context-plans/YYYYMMDD-slug/
+    repos/
+    documents/
+    research/
+    stage-inputs/
+```
+
+Reuse authorized local checkouts in their existing locations first. For a source
+requiring a new checkout, place it in `repos/`. Keep retrieved document bodies
+and resources in `documents/`, inventory and investigation notes in `research/`,
+and the current production handoff in `stage-inputs/`. These paths are conventions;
+no file names or directory layout become a new command gate. Keep scratch data
+out of Git and never force-add ignored files. The committed PLAN must retain
+source identities and enough context to resume if local scratch files disappear.
+
+Begin with directory metadata, source type, available versions and existing
+knowledge coverage. Read representative bodies and relevant code entrypoints
+to estimate scope and dependencies. Expand only where needed to identify useful
+stages; a project inventory need not download every body before planning.
+Save listing progress and failed branches, deduplicate sources by their actual
+identity, and retry affected subsets using supported tools. Reading a directory
+does not establish that its contents or outgoing links have been read.
+
+Maintain the selected identity for each source and its embedded resources.
+Record inaccessible items and their effect on the proposed scope. Do not prompt
+for user authorization or switch a resource to a different identity simply
+because one attachment failed. Reuse permitted representations when available;
+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.
+
+## Review existing knowledge and connect the material
+
+Before proposing article targets or dividing production stages, inspect the
+selected knowledge workspace's current organization, relevant approved articles,
+registered sources and available source references. Reuse the workspace's
+supported read-only views or search the authorized approved knowledge, then read
+the relevant sections in context. Titles, directory placement and search snippets
+alone do not establish either duplication or a coverage gap.
+
+Compare the incoming material with that existing knowledge by reader task and
+behavior, not only by names. Look for the same subject under different terms,
+complementary explanations, changed behavior, conflicts, shared prerequisites
+and relationships between code and documents. Follow relevant article links and
+source references to understand those connections within the authorized scope;
+an unread citation is not evidence, and a link does not authorize expanding into
+an unrelated source. Keep approved pages, pending drafts, older package output
+and previous PLAN deliveries distinct; a draft is pending work, not an approved
+answer or a reason to produce the same page again.
+
+Record a compact coverage-and-relationship map in the PLAN, grouping related
+sources where useful. For each proposed topic, identify the existing page or
+section, the new material, the actual overlap or gap, useful connections and
+the proposed disposition:
+
+- **Reuse unchanged:** existing knowledge already covers the reader task;
+  link to it and avoid another article or unnecessary rewriting.
+- **Revise or extend:** update the relevant existing article while retaining
+  its identity and still-correct coverage.
+- **Consolidate:** propose where overlapping material belongs and which
+  article will carry it; any move, merge or retirement follows the existing
+  production, review and authorization rules later.
+- **Add:** create a new article only for a distinct reader need or confirmed
+  gap, and suggest its place within the existing organization.
+- **Investigate:** record an unresolved conflict, unread material or missing
+  access without treating it as proof that no knowledge exists.
+
+Use these findings to choose stage dependencies and handoffs. Shared concepts
+and supporting sources can serve several stages; this does not require copying
+the same explanation into every article or creating one article per source.
+Research remains read-only for managed workspace content: do not merge, delete
+or rewrite knowledge while preparing the PLAN. For a genuinely empty workspace,
+record that no existing coverage was found and plan initial coverage; for an
+unavailable workspace, record the limit and keep deduplication conclusions
+provisional instead of silently treating it as empty.
+
+## Resolve versions and organize stages
+
+For each repository selected for substantive research, resolve a requested
+`latest` or branch to an actual commit before using it as evidence. Record that
+ref in the PLAN and production handoff. A later update is a deliberate version
+comparison; do not silently move the source baseline while writing a stage.
+For document updates, retain available source revision or capture time and any
+limits on historical comparisons. These research records do not belong in
+reader-facing article prose unless a version difference explains behavior.
+
+Group by reader task, related subject and delivery dependencies, considering
+existing approved articles before proposing new ones. Source count is not
+article count. Separate discovery-only records from the source set selected for
+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. |
+| 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.
+
+Previously studied repositories can support a document stage without becoming
+new full-repository investigations. If a supposed supporting repository needs
+substantial new exploration, schedule that research explicitly. Include shared
+dependencies and reusable evidence so subsequent stages do not repeat the same
+investigation. Order stages to make the first useful delivery possible early.
+
+Identify the configured destinations and inherited review, managed execution
+and publication settings. Do not preassign package release versions to future
+stages; resolve the appropriate version through the normal publishing process
+when that stage is ready.
+
+## Compare updates across sources
+
+For each source, locate its existing registered ref or captured snapshot and
+the approved articles that actually reference it. Resolve the user's requested
+version, or the intended branch's `latest`, to an explicit target ref. Record
+each source's own baseline/target pair; do not transfer one repository's version
+label to another source or assume every article uses the same baseline.
+
+For repositories, examine the relevant Git change range and its relationship
+to the articles' actual cited paths, symbols and reader-facing behavior. A
+changed file is a candidate for investigation, not proof that an article needs
+rewriting. Keep unrelated changes and still-correct knowledge out of the
+revision scope. Explain additions or removals through the behavior and coverage
+they affect, including cross-repository dependencies when material.
+
+For documents, classify the findings as new, changed, deleted or invalidated,
+unchanged, or currently unreadable. A permission failure is an access gap, not
+evidence of deletion. Use available revisions and saved bodies for comparison;
+without an old snapshot, explain the observable current state and do not claim
+a line-by-line historical diff. Treat unsupported resource representations as
+coverage limits rather than silently considering the document fully read.
+
+Summarize the proposed article changes, unchanged coverage and uncertain cases
+in the PLAN. If the user asked only to inspect changes or provide a comparison,
+stop at that report. Agreement with the findings alone does not authorize
+production: obtain explicit authorization to execute the staged update, complete PLAN review
+under its effective policy, then hand
+only the selected stage to the existing Context workflow.
+
+## Approve the project report
+
+Present a readable PLAN with the proposed outcome, source boundaries, coverage
+gaps, stages and delivery expectations. Apply `context.gate.plan_review` and the
+Skill's authorized task-scoped override. The default is `ask`: invite the user
+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.
+
+Establish the reporting mode using existing instructions where possible:
+
+- **After all stages:** continue authorized work and summarize at the end;
+  report actual blockers requiring user action when they arise.
+- **After each stage:** send a stage summary and follow the explicitly selected
+  continuation policy, either continue automatically or wait for a reply.
+
+Reporting frequency does not change the existing Context article review mode.
+An ordinary review still needs its normal user decision, and managed review
+still requires its existing authority and complete reading. If the user requests
+publication-free work, record the narrower deliverable explicitly; label it
+reviewed or locally built as appropriate, never published. Do not enable a
+remote publishing destination just to satisfy a planning checklist.
+
+After approval, commit the report and attempt integration using the user's
+authorized branch and repository process. Respect required checks and protected
+branches. If direct integration is unavailable, create a PR/MR when authorized
+and report its link. Keep the plan's actual merge state; an open review request
+does not cancel authorized research or unrelated stages. Without Git mutation
+authorization, retain the local report and continue work already authorized.
+
+## Hand one stage to production
+
+Provide the installed `context` Skill with:
+
+- the approved PLAN path and selected stage ID;
+- that stage's user outcome and specific source set;
+- fixed repository refs, reusable research and unresolved evidence gaps;
+- target existing articles and warranted new topics;
+- relevant existing sections, the planned reuse/revision/consolidation decisions,
+  and source or article relationships that this stage must preserve;
+- dependencies and the inherited review, managed and publishing settings;
+- its reporting and continuation policy;
+- the effective PLAN/article review policies and the trusted authorization for
+  any task-scoped overrides, without modifying the Bot or workspace defaults.
+
+The handoff states that this is one stage of an approved project plan. The
+production Skill follows its fresh Route for that scope, without applying the
+large-project threshold again to the full PLAN. Do not register the complete
+discovery inventory or turn every discovered item into a capture phase. Reuse
+available supported stage scoping/configuration; do not hand-edit protected
+registries, clear another task, or invent an unavailable CLI switch to restrict
+the scope. If the current workspace cannot isolate the selected stage, preserve
+its active work and report the concrete configuration issue before production.
+
+Stage planning does not replace production's semantic planning, source checks,
+candidate review or publication. Pass a bounded task into that existing process
+and consume its actual receipts when it finishes.
+
+Before starting each later stage, recheck only the affected knowledge and pending
+work against the current workspace, including articles delivered by earlier
+stages or other contributors. Refresh the overlap decisions and next-stage
+targets in the PLAN rather than repeating the full investigation. Preserve
+unrelated changes; follow the existing approval rules for any material change
+to the agreed project scope.
+
+## Progress, interruption and completion
+
+Update the PLAN after a meaningful checkpoint or stage transition, distinguishing
+discovered, registered, captured, written, reviewed, built and published work.
+Record the active command/job, current source or page, persistent input location,
+last confirmed result, remaining work and next action. Never infer success from
+an absent process or from the task runner's overall completion status.
+
+For a completed production stage, record the actual delivered pages, publication
+destination and receipt, resolved version, and associated commits/PRs/MRs. Check
+its delivery box only when the agreed delivery is confirmed. Keep merge and
+publication status separate; work may be awaiting one while the other succeeded.
+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.
+
+Once all agreed stages have been delivered and outstanding integration is
+resolved, summarize the result, remove the PLAN, and include that deletion in the
+authorized final commit and synchronization. Do not delete before the completion
+criteria are met or erase its Git history. If final integration is pending,
+retain the PLAN with the outstanding action so another session can finish it.

package/plugins/skills/context-plan/references/resource-tools.md

@@ -0,0 +1,100 @@
+# Tools for planning research
+
+Use tools and credentials already available in the selected environment. Inspect
+their advertised commands and help before invoking an unfamiliar operation;
+capabilities can vary by installation. A missing command is a capability gap,
+not permission to invent an endpoint or bypass the source's access controls.
+
+## Source inventory and selective capture
+
+Prefer supported directory listing, batch capture, persistent progress and
+resume capabilities. Store reusable output in the plan's scratch directory.
+Keep listing results distinct from captured bodies and capture failures distinct
+from denied resources. Source type determines the appropriate document, table,
+board or file adapter; do not force every source through a document-only API.
+
+Where the installed tool supports bounded concurrency and rate-limit handling,
+let it schedule independent reads and honor its retry/backoff results. Avoid
+agent-written parallel shell loops that bypass those controls or concurrently
+write shared Context state. If only narrower operations are available, use
+bounded batches, persist their receipts, and report the capability limitation.
+
+Continue using the existing Context entry and its returned commands for official
+registration, capture and knowledge production. Planning scratch downloads are
+research inputs, not a substitute for an accepted source snapshot. Do not put
+research files directly into `sources/` or `knowledge/`.
+
+## Capture once and reuse in a production stage
+
+For an authorized Lark document, download a complete local snapshot before a
+Context workspace exists:
+
+```bash
+context source fetch lark https://example.larkoffice.com/docx/example-token \
+  --output .tmp/context-plans/20260101-handbook/documents/handbook \
+  --as bot --format json
+```
+
+The destination must be new. This operation does not register a source, create
+a production task, or write managed workspace state. It uses one fixed identity
+(Bot by default), including embedded resources; it never switches to User on
+failure. Use `--as user` only when authorized to read with that identity. Existing
+host authorization may then require consent. Inspect the fidelity and resource
+diagnostics: a retained reference or preview is not the complete missing resource.
+Rate-limit handling and supported same-identity representations use the ordinary
+capture machinery.
+
+Keep the whole returned `snapshot_dir`, including `snapshot.json`, document,
+raw responses and assets. The receipt is local integrity and capture provenance,
+not a platform signature or proof that the upstream document is still current.
+Do not replace a response with a summary or edit the receipt to hide gaps.
+
+After plan approval, register only the selected stage's source through the
+existing workflow. Then use the matching registered name in an import file:
+
+```json
+{
+  "type": "lark",
+  "name": "20260101/handbook",
+  "snapshot_dir": ".tmp/context-plans/20260101-handbook/documents/handbook"
+}
+```
+
+```bash
+context source import --input .tmp/context-plans/20260101-handbook/stage-inputs/import.json --format json
+```
+
+Paths in the payload are relative to the selected Context workspace; use its
+actual registered source name and an allowed local location. When moving between
+workspaces, copy or move the complete snapshot to the selected workspace's
+scratch directory. Snapshot entries must be real files, not symbolic links.
+Import validates the source identity, saved responses, digests and resource
+files through the normal capture write path. It preserves the original capture
+time and revision and makes no remote calls, including for structured resources.
+If the stage has a different resource policy, use its normal capture operation
+or explicitly reconcile that configuration; do not edit the saved receipt to
+pretend it was captured under a different policy.
+If the stage needs a newer source revision, fetch a new snapshot to a new directory
+instead of describing the saved one as fresh. Existing `response_files` import
+remains available, but may still fetch resources absent from those responses;
+use an intact `snapshot_dir` for complete local reuse.
+
+`context source discover lark` provides resumable Wiki directory discovery in an
+existing Context workspace. It does not fetch bodies or register the inventory.
+When no workspace exists, use the available source platform's authorized listing
+capability; do not invent a workspace-free discovery flag or initialize a full
+production scope only to list a directory. Batch registration and its checkpoints
+belong to the selected production stage, not the full planning inventory.
+
+## Repository research
+
+Reuse an existing authorized checkout at the requested revision. Read metadata
+and selected paths before deciding whether more objects or files are needed.
+For a new checkout, use the source platform's supported clone/read capabilities
+and save the resolved commit in the PLAN. Keep remote read results tied to that
+same commit, and fetch additional content only when the research requires it.
+
+Respect uncommitted work in reused checkouts. Do not reset, replace, rebase or
+switch a user's active worktree just to change the planning baseline. Use an
+available read-only view or an authorized separate research checkout when the
+required revision is unavailable locally.

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

@@ -0,0 +1,113 @@
+# Project plan: <project name>
+
+This report records the agreed project scope and stage progress. Complete the
+relevant sections in ordinary Markdown; remove template guidance when filling
+it in. It is a working report, not a machine-validated schema.
+
+## Outcome and current position
+
+- Reader/audience and requested outcome:
+- Knowledge workspace and Git root:
+- Current project state and active stage:
+- Last confirmed result:
+- Next action:
+
+## Research scope and findings
+
+| Source or subject | Kind and identity | Resolved version / capture context | Scale and coverage | Access or evidence gaps |
+| --- | --- | --- | --- | --- |
+| | | | | |
+
+- For updates: each source's recorded baseline, target version and relevant changes:
+- Representative material examined and findings affecting the plan:
+- Additional sources/links discovered, excluded scope and unresolved coverage:
+- Scratch research location and reusable checkpoints:
+
+## Existing knowledge and material relationships
+
+- Workspace organization and relevant approved sections actually inspected:
+- Existing source references and connections followed:
+- Pending drafts, earlier stage deliveries or concurrent work to account for:
+- Inspection coverage and any unavailable knowledge; do not treat unread as absent:
+
+| Topic / reader task | Existing article and section | Incoming documents / repositories | Overlap, gap or conflict | Proposed disposition and reason | Related knowledge / source dependencies |
+| --- | --- | --- | --- | --- | --- |
+| | | | | Reuse / revise / consolidate / add / investigate | |
+
+Group related material where useful; this is not a one-row-per-source inventory.
+Support decisions with sections actually read. For new coverage, suggest an
+existing section or explain the needed addition. Consolidation here is a proposal,
+not permission to modify or retire approved articles during research.
+
+## Proposed stages
+
+Use stable stage names. For a stage requiring publication, a delivery checkbox
+stays empty while only registration, capture, writing, review or a local build
+has completed. An explicitly publication-free stage may be marked delivered
+when its agreed deliverable is complete; do not label it published.
+
+| Delivered | Stage | Reader outcome and article targets | Selected sources and fixed refs | Scope counts and reason for any exception | Prerequisites | Current state |
+| --- | --- | --- | --- | --- | --- | --- |
+| [ ] | S01 | | | | | planned |
+
+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.
+
+## Approval and execution choices
+
+- First report presented to the user:
+- Effective PLAN review policy (`ask` / `delegate`) and task-scoped override authority:
+- Human approval or Agent review result, deficiencies resolved and scope adjustments:
+- Execution authorization (separate from permission to research/review):
+- Reporting: after all stages / after each stage:
+- If reporting by stage: continue automatically / wait for a reply:
+- Existing article review and managed execution settings:
+- Agreed delivery destination and inherited publishing settings:
+- Authorized Git branch, commit and PR/MR/integration process:
+- Decisions still needed:
+
+Do not assign release versions in advance. A project plan approval does not
+stand in for article review, publishing permission or source authorization.
+
+## Current stage handoff
+
+- Approved plan and selected stage ID:
+- Bounded task passed to the existing Context Skill:
+- Selected sources, pinned refs and relevant research:
+- Existing article targets / new topics:
+- Reuse, revision or consolidation decisions and relationships to preserve:
+- Affected knowledge rechecked before this stage, including prior stage deliveries:
+- Effective task-scoped review overrides and their trusted authorization:
+- Inherited publishing and reporting choices:
+- Evidence gaps or dependencies that affect this stage:
+
+Project planning is already complete for this handoff. Production uses only this
+stage's scope and its normal Route; the full inventory is not a new task input.
+
+## Results and synchronization
+
+| Stage | Confirmed production/review result | Actual delivery and receipt/version | Commit / PR / MR | Merge state | Remaining action |
+| --- | --- | --- | --- | --- | --- |
+| | | | | | |
+
+## Resume notes
+
+- Active job/command and current processing position:
+- Persistent input/checkpoint and confirmed completed work:
+- Outstanding review, integration or publication:
+- Next executable action within the approved scope:
+- Independent work that can continue:
+
+A saved policy is a recovery record, not authorization by itself. On a resumed
+session, validate delegation against trusted task instructions; otherwise retain
+the default review policy until authorization is available.
+
+Keep this report while any agreed delivery or integration remains pending.
+After actual completion, remove it in the authorized final commit and synchronize
+that commit; Git history preserves the approved plan and progress.

package/plugins/skills/context-sessions-indexer/references/writing.md

@@ -61,3 +61,20 @@ answer the selected question without reconstructing the conversation? Check
 that the article answers its planned reader question. Keep remaining investigation
 and real gaps visible in the stage; do not submit a per-passage disposition ledger. A generic overview that drops the actual decision,
 exception or resolution is incomplete even if its headings look correct.
+
+## Source provenance and article prose
+
+Keep capture baselines, repository commit hashes, inspected branch revisions and
+verification timestamps in structured source references or citation destinations,
+not in article headings, introductions, tables or standalone evidence paragraphs.
+Do not add sentences such as “the backend baseline is repository@commit” merely
+to describe how the article was researched. Preserve exact source links and
+reference metadata; removing this prose must not weaken traceability.
+
+Retain business or API versions, compatibility constraints, migration differences
+and performance comparison baselines when they explain behavior or reader actions.
+A commit belongs in the prose only when the requested topic is that specific
+change, regression or reproduction and its identity is necessary. Apply editorial
+cleanup only to the current authorized writing or revision scope; do not scan or
+rewrite unrelated approved articles. This is writing guidance, not a keyword-based
+CLI rejection rule.

package/plugins/skills/context-sessions-indexer/templates/articles/c01.md

@@ -28,7 +28,7 @@ This is a writing blueprint, not a completion gate. Adapt the headings and level
 3. **技术与依赖摘要**：仅在有技术材料且影响读者选择入口时出现；纯产品资料不强制此节。
 4. **知识索引**：主题、何时阅读、目标文章／代码位置。
 5. **任务导航**：开发、接口对接、排障、交付分别从哪里继续。
-6. **来源与适用版本**：文档身份／定位与适用版本；代码材料记录仓库、模块路径和证据版本。
+6. **来源与适用版本**：文档身份、代码仓库和模块入口；正文仅说明影响使用的业务或兼容版本，取证提交号保留在来源引用元数据中。
 
 最低产出：对象身份、可信资料／起始文件／注册点和下一步阅读位置。浅索引模块可作为父级表格中的记录，不强制单页。禁止链接到尚未产出的模板占位文件。
 

package/plugins/skills/context-sessions-indexer/templates/articles/c07.md

@@ -20,7 +20,7 @@ This is a writing blueprint, not a completion gate. Adapt the headings and level
 
 适用：入口优先的业务知识包，尤其是只持有 dist 的消费 Agent。建议章节为 **问题到入口的映射 → 源码身份与版本 → 推荐阅读顺序 → 外部边界 → 何时需要进一步证据**。
 
-定位记录：仓库身份、仓内路径／符号、证据版本、已证明到哪一层、接着读什么。在包内返回可执行的阅读指引；工作区 inspect 与包外源码归因遵循各自现有能力和授权，不声称普通 dist query 会自动 clone。无需在每篇文章重复整套工作流，只保留本篇起点和相关指引链接。
+定位记录：仓库身份、仓内路径／符号、已证明到哪一层、接着读什么。取证版本保留在来源引用元数据中，不在正文重复仓库提交基线。在包内返回可执行的阅读指引；工作区 inspect 与包外源码归因遵循各自现有能力和授权，不声称普通 dist query 会自动 clone。无需在每篇文章重复整套工作流，只保留本篇起点和相关指引链接。
 
 ## 图示选择
 

package/plugins/skills/context-sessions-indexer/templates/articles/l02.md

@@ -56,7 +56,7 @@ Toast 类家族可以先给成员选择表，再按成员或调用方式分节
 | 行为与组合规则 | 状态谁控制、如何交互、配置如何叠加 | 受控／非受控、回调、数据结构、覆盖顺序、关闭／清理、组合约束；具体内容由组件能力决定 |
 | 样式与设计系统 | 哪些是组件可覆盖项、哪些来自全局系统 | 变体、尺寸、slot、token、逻辑方向等具体差异；公共基础规范链接到设计系统，不整篇复制 |
 | 运行环境、可访问性与限制 | 在什么条件下可用、有什么已知边界 | SSR／Portal／宿主／移动端限制；已证实键盘、焦点、role、对比度相关行为；实际测试与静态观察区分 |
-| 相关组件与源码入口 | 继续查哪里、换用谁、哪份证据支持本页 | 相关能力、实现／类型／示例／文档定位，明确证据版本；关键行为的定位尽量贴近对应章节 |
+| 相关组件与源码入口 | 继续查哪里、换用谁、哪份证据支持本页 | 相关能力、实现／类型／示例／文档定位，取证版本保留在引用元数据中；关键行为的定位尽量贴近对应章节 |
 
 章节可以有组件特定的小节，例如“选择后是否关闭”“清理时机”“嵌套分组”。固定公共章节不要求把每个组件的业务特点改成相同文案，也不改变事实的原有语义。
 

package/providers/context/actions/repair-project-entry.yaml

@@ -5,6 +5,7 @@ effect: write
 handler: context.project.repair-entry
 # Supporting SDK manuals remain available through links, without mandatory reads.
 files:
+  - resources/manuals/guides/source-batches.md
   - resources/manuals/reference/code-extractors.md
   - resources/manuals/guides/knowledge-updates.md
   - resources/manuals/guides/note.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. Stay ready unless the user asks to resume production. With that explicit request, run task resume and follow the fresh Route.
+      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.
       delegatable: false
     satisfiedBy:
       - path: workspace.task_start_authorized