git:20260913.a425dec to git:20260913.75579c5

- description: Execute one bounded batch of Context-authorized Indexer worksets using the current Route input, shared Provider instructions, and each task's authorized View.

- agent-graph.entry: agent-step

- # Run one bounded Indexer Agent batch

-

- Before dependent bulk work, follow

- [the shared homogeneous-source review](../../resources/procedures/homogeneous-source-review.md).

- Reuse explicit group decisions; when a newly observed group needs user choice,

- present its concrete scope and pause before parsing or submitting dependent work.

-

-

- Read the current Route action input and required shared instructions. Every

- Resource marked `read-required` must be read by the Agent responsible for that

- work; delegation does not waive reading or permit fabricated receipts.

- For `stage: approved-revision`, follow `procedure.approved-revision`: read the

- supplied approved page and return the revised Markdown using that action's schema.

- The batch instructions below apply to Partition, Author, and Composer worksets.

-

- For Partition and Author, follow the current Route's

- `procedure.parallel-agent-batch` before reading task material. When the Host and

- current permissions allow delegation, use 2–4 read-only workers for independent

- tasks; otherwise complete them in this Agent. The coordinator owns all Context

- commands and file writes. This is execution within the selected batch, not a new

- lifecycle or permission to overlap stages. Use `template.indexer-agent-worker`

- for each assignment and the procedure's bounded fallback on worker failure.

-

- Use the readable `resolved-indexer-instructions` and each task's

- `authorized-indexer-workset-view/task-NNN`, including its goals, constraints and source material.

- Each task has its own reading file. Read its referenced shared files once;

- relative links resolve beside that task file. Shared resources are also listed

- in the Route. A shared file does not authorize another task to use its references.

- Match each result to its task's own goals, source material and allowed references.

- If the file tool truncates its output, continue with the unread part of that same file;

- do not mistake tool truncation for missing source material or restart the Context task.

- Match Views and outputs only through

- the short `task_key`; do not copy internal digests into the semantic result. The reading contains the

- recommended source material, supplementary facts, Provider fragments, and authority for each task. Do not

- construct evidence read requests, manage pages or cursors, discover another Skill, read a

- Provider path, widen source scope, run an unauthorized Indexer or parser, or invent missing

- evidence.

-

- Return exactly one `results[]` entry for every task in the current batch, in task-key order. Each

- entry carries its `task_key` and the existing stage-specific semantic Result. A single-task batch

- still uses the same array shape. Prepare distinct results together and submit the batch once;

- do not turn it into a separate CLI round trip for each page. Author group_key may be omitted to inherit the group selected by this current task_key; an explicit different group is rejected. The CLI preview and completion apply the same inheritance. Inventory facts in the reading map exact members to parser names/kinds and usable references; they do not decide coverage. Copy dynamic authority values only from the Route input or that

- task's authorized View.

-

- At the start of Partition, preserve new settled purpose/scope findings in the

- existing work-start report when the earlier setup did not already cover them.

- The current Route exposes `procedure.work-start-report`

- and `template.work-start-report` for that handoff, including the scratch write

- boundary. Reuse an applicable report on continuation; do not recreate it for each

- workset. When planning tasks first become countable, ensure the report's task and

- module breakdown has been shown before bulk planning; for more than 50 planning

- tasks, wait for the required first report feedback before continuing. This

- threshold wait occurs once per continuing production task; later recounts or

- revisions reshow the report without repeating that wait unless a new unresolved

- user choice requires it. Follow the procedure's feedback rules. Unchanged

- continuations reuse the prior handoff. Report text is context, not evidence or authority. Author follows the

- accepted page plan and does not reread these resources or rewrite the report

- unless a material task decision changes.

-

- For Partition, apply the grouping rules in `resolved-indexer-instructions` to each

- task's View. Check its material against the settled reader purpose and scope;

- inventory membership is not a requirement to publish a page. A newly discovered

- region with materially different relevance, version or lifecycle may require a

- scope discussion before dependent output, even in managed mode. Explain the

- specific impact and preserve accepted work; refresh the Route after an authorized

- configuration change. Do not silently exclude unresolved work or replay all tasks.

- Context handles strategy selection and retries; do not look up a separate

- strategy definition or submit strategy metadata. Report missing source material or

- unresolvable semantic boundaries through the current Result schema.

-

- During Partition, read the whole inventory overview and each member's identity,

- not every implementation body. `partition-navigation` shows the surrounding scope;

- `consumer-anchor overview` links to complete immutable fact details. Open those

- files and the bounded `source-access` paths whenever ownership, lifecycle, a

- shared dependency or the reader task is unclear. Sampling helps orient you but

- cannot justify excluding uninspected members or asserting behavior. Unknown

- material formats remain full required reading. Author can access complete selected

- facts and source text; reduced planning input is not evidence for a final claim.

-

- Set a group's `ready_for_author: true` only after its scope, material ownership,

- reader task and relevant shared dependencies are resolved well enough to write

- an independently useful page. A sample, file boundary or large fact count is

- not sufficient. Leave it absent/false when neighboring material could change the

- boundary. This declaration permits an early wave; it does not mark the remaining

- inventory complete or bypass normal structure/content review. After a wave's

- build, follow the fresh Route back to remaining Partition tasks. Later material

- for an existing article must retain its identity and improve its approved content,

- not create duplicates. All inventory members still need final dispositions.

-

- Read `partition-authority` for available article intents and templates.

- Choose a stable, readable `group.key` for each writing topic and keep existing

- article keys on updates. Source scope and group key determine the writing group;

- title changes do not create a new identity. Context preserves approved paths.

- Do not submit SubjectKey, subject_intent, node types, graph relations or mounting

- matrices. Material that has no publishable reader purpose belongs in the member

- dispositions, not an artificial topic. Path collisions use the existing layout

- decision, not guessed identity merges.

-

- For an Author Result, write reader-facing `title`, `summary`, and `sections` only when publishing.

- Read the main task and its shared material, then expand details for the claims and

- member decisions you need to make; do not open every optional file as a checklist.

- Style-name rows locate captured CSS, not public interfaces or runtime behavior.

- Rows use the supplied column names; row numbers are never source or member IDs.

- All inventory IDs remain explicit. Supporting style rows without a ref can be

- traced through the source or full parser detail when a fact citation is needed.

- A stylesheet path or inventory ID is not a requirement to read the whole file.

- Use the accepted plan and supplied evidence for supporting/catalog decisions;

- open the relevant rules only when a planned claim or unresolved member decision

- needs layout/state/theme/override/accessibility detail. Do not add visual prose

- merely to cover style records, or infer exclusions from selector names alone.

- Package briefs support the fields explicitly shown. Open the full manifest only

- when a needed import condition, dependency or build detail is missing. Do not

- reread either source solely because it appears in navigation.

- `members_from` reuses an identical Props member list within the same source file;

- combine it with the component's own parameters/defaults and retain any uncertainty.

- Inherit `page_plan.artifact_intent`; omitting `artifact_intent` also uses the saved plan.

- Use `primary_artifact_options` when selecting a policy; derived-page intents are not additional pages to write.

- For mechanical assembly, copy the current Route's recommended `indexer-author-scaffold`

- JSON resource to workspace `.tmp/agent-payloads/`; do not edit the runtime resource.

- It already contains the current task keys, planned intent, unambiguous policy and member IDs.

- Write the prose, references and member decisions. Use a fresh scaffold when the Route's

- revision or task set changes; never reuse accepted tasks from an earlier batch.

- `context action scaffold-current --revision <current-revision>` remains available to

- explicitly recreate the skeleton, but is not an additional required command.

- Empty states are intentional:

- the scaffold never chooses coverage or a publishing decision on your behalf.

- Members with the same state, section and reason can share one disposition entry:

- `{items: [<member-id>, ...], state: covered, section: <section-key>}`.

- Do not also list these members individually. Context expands the groups and performs

- the same per-member ownership and coverage validation.

- For uncertain submissions, add `--preview` to the current Author completion command.

- It validates and renders the current result without accepting tasks or advancing the Route;

- this is optional, not another required round trip. Read failures, repair the payload,

- then submit normally. Preview input errors include `issues` with paths relative to

- each task entry (starting at `result`) and section/member identifiers when available.

- Use those paths to locate edits; errors from conversion or rendering keep their

- original message and do not imply a payload field location. Preview does not replace Review or guarantee a later unchanged revision.

- Each output fragment records only the source regions actually used in its prose:

- `references: [{source_ref, locator: {path, start_line, end_line}}]`.

- Use the source identity and captured path supplied for this task. Locations are

- inclusive line ranges in that captured text. The CLI computes the region digest;

- do not submit fact IDs, evidence IDs, binding digests or duplicate source lists.

- Each fragment has at most three distinct source positions, not three per article.

- Choose necessary regions or split the prose by meaning; do not truncate necessary

- references or merge unrelated line ranges to evade the limit.

-

- Catalog-only and unsupported results publish no article. Record truthful member

- dispositions without dummy prose or a fact ledger. Empty references are not proof:

- only omit them when the fragment genuinely has no source-derived claim.

-

- For behavior, read source text. The task's `source-access` lists captured files

- under `captured_root`; read relevant ranges directly when excerpts are insufficient.

- Do not switch to a live checkout or unrelated sources. Cite the exact ranges used.

- A signature or call name alone does

- not establish behavior absent from those lines. Do not copy process-only carriers into reader Markdown.

- Read shared instructions once while they remain available in the current conversation;

- unchanged instructions do not need rereading for each task. Read every task's own goals and member overview. Large captured files may be linked

- rather than inlined: read the relevant implementations and dependencies by range;

- if scope or behavior is unclear, expand the whole file. Navigation, CSS selectors

- and AST signatures do not establish behavior by themselves. Full parser detail

- files are optional unless needed to resolve a relationship or ambiguity. Known

- carrier metadata may be omitted from the overview; all submission references and

- canonical facts remain available. Never treat absent overview text as absent capability.

- If an explanation needs a dependency body, first read its captured file directly. Only when

- the supplied source access cannot provide the body, use `request-material` with

- specific repository-relative file or directory paths in `material_gaps[].source_hints`.

- Context expands available registered source bodies through the same completion command.

- On `material-expanded`, read the returned task's added material and finish the preserved draft;

- do not recollect, repartition, or repeat accepted peers. Re-requesting supplied files is safe and

- returns usable material again. If a path is unavailable, correct it or describe the remaining gap.

- Installed guidance can be newer than a resumed task. Context owns this compatibility decision;

- follow the current Route without comparing Provider fingerprints or regenerating task identities.

- Do not invent or manually copy read-receipt, execution-receipt, or stable-result digests. Submit

- the stage-specific input described by the current Action schema through the Route's completion command; Context

- derives internal envelopes and performs dependency, schema, owner, scope, and per-workset validation

- before reporting each task accepted. Read the completion's `outcomes` and

- `next_route.file` (the exact next Route). Read `result_file` when `details_required`

- is true, output was truncated or the outcome is unclear; an ordinary successful

- summary does not require rereading the full result, which embeds the same Route.

- Continue directly from that Route and ready Resource paths. Do not run `context status` or either Resource materializer

- between successful batches. A failed item is retried from its returned task-only skeleton; already

- accepted peers are not repeated. Never report success merely because the envelope or prose looks valid.

- If `next` is null and `next_preparation` reports failure, the committed outcomes

- are still saved: run its recovery command, not the previous submission. A stage's

- `progress.stop=complete` does not mean Review, close or package build is finished.

-

- For Indexer files that need no read receipt, reuse a fully read resource in this

- conversation only when its source/Provider identity and content digest are unchanged

- and its contents remain available. A new revision alone does not require rereading

- those files. Always read the new Route and task-specific changes; after context loss

- or truncated output, read the missing content. Never invent a receipt or mark an

- unread file as read.

-

- ## Reader purpose and saved page plans

-

- Use the bound requirement's `purpose` and open `reader_goals` throughout planning,

- authoring and review. During Partition, select `artifact_intent` and `template_id`

- from the current partition authority, retain `reader_task` and `outline`, and use

- `priority` (lower first) and `delivery_boundary` to identify a complete reader task.

- Choose a first representative module of roughly one to three pages. Do not group

- unrelated types because they share a file, or treat every export as a page.

- Author uses the saved choice; do not change it on retries or Provider refresh.

- Integration and maintenance purposes may share contracts without duplicating prose.

- Identify actual module roles from registrations and consumption: a client is not

- a server, a runtime is not a module role, and an application component is not

- a published component library. Preserve behavior needed for the reader's task.

-

- For `stage: source-update`, follow the selected source-update procedure and action schema. Read current approved pages and the fixed source changes before deciding which pages need revision, including any new topics absent from existing page references.

-

- ## Semantic judgment and narrowed scope

-

- Scripts may assemble references, serialize an Agent-authored result and submit it.

- Do not use the first path to name an entire mixed group, classify all inventory

- members as one topic, or generate identical API prose and unconditional publish

- results. Reading a View with a script is not a substitute for understanding its

- sources. Reuse mechanics, not unsupported content claims.

-

- When the selected template supplies a program-generated API table, bind the

- applicable source-derived values and use the available formatter for rows, types and defaults.

- Do not write a second equivalent table or restate every row in prose. Explain

- usage decisions, composition, pitfalls and migration boundaries; mention a

- parameter or default when it helps explain that behavior. This does not waive

- source reading or member coverage. If a generated value conflicts with source,

- identify the field and source location through the current repair flow; do not

- patch the generated block or add a competing answer in prose. Without a suitable

- program block, follow the selected template and write the source-backed explanation

- needed by the reader rather than omitting it.

-

- Keep each parameter and default attached to its own callable or type. Missing

- extracted members do not establish that an API has no parameters or callbacks;

- read the referenced source when inherited types or static methods matter to the

- reader. Before extending a first batch, check that its pages answer the promised

- reader tasks, including document-grounded integration or troubleshooting where

- required, rather than only listing exports.

-

- For Composer, inspect the selected task's primary page and remaining material

- before choosing an empty proposal list. A script must not decide that every

- Composer is unnecessary. Existing API tables may remove duplicate table work

- without answering the task's examples or usage questions.

-

- Use one production driver for this workspace. If a submission process is still

- running, await its completion instead of starting another lifecycle driver from

- an observed status. A local content repair or truncated read is not a reason to

- run `task prepare --apply`: that command ends the old task. When scope decisions

- change, update the existing applicable requirement/report without extending a

- one-task exclusion into a permanent policy.

-

- When `page_plan.scope_change` is present, reassess the residual group before

- Author: the previous title, reader task and outline describe the original scope.

- Excluded members remain excluded. Publish only when the remaining sources support

- a useful page, with an accurate title, summary and an allowed artifact intent.

- The old template/intent restriction has been released for this changed group.

- If it should not be a page, use a supported non-publishing outcome and truthful

- member dispositions; catalog-only does not publish prose. Zero extracted facts

- alone does not prohibit a source-grounded document, and does not establish an API.

- Do not restart unrelated accepted tasks to repair this group's interpretation.

-

- ## User-facing progress

-

- 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 describes the current action, using `slice` counts

- when available. Internal wave/slice names need not appear in user-facing text. 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.

- Before counters exist or after task cleanup, describe the known stage and current

- action instead of repeatedly saying counters are unavailable. For example:

- **[总体进展：正在准备知识工作区]**

- **[当前进展：已读取启动清单，正在整理仓库与文档范围]**

- During review or packaging, name that action rather than a nonexistent slice.

- 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.

-

- ### Planned articles

-

- When the current Partition authority supports an article plan, keep one writing group

- and one inventory owner for the topic. Plan stable article keys, the reader task,

- allowed intent and template, required or optional articles and sections, and one

- required article responsible for each primary question target. A shared source

- member may support several articles without being owned several times.

-

- For an accepted `page_plan.articles`, submit per-article content using those keys

- and the current Author question identifiers. Keep the group member dispositions

- unique; a covered member identifies its article and section. Follow the current

- schema and returned diagnostics when a required article or its evidence is

- missing. Change the accepted plan through the existing structure adjustment

- route before adding articles or changing their purpose. Legacy single-page

- plans continue to use the single-page submission.

-

- For a selected page program, use its variable catalog and article guidance.

- Variables carry `value` and direct `references`; do not attach parser facts or

- repeat equivalent prose to satisfy a binding requirement. Use supported formatters

- or source-grounded Markdown. The selected intent still describes the reader task.

-

- Choose the article form before filling variables. For L03, a system overview

- uses scope, packages, foundations, components, configuration, adoption and

- references; a foundation topic uses purpose, catalog, mapping, consumption,

- rules, platforms and references; runtime adoption uses environment, globals,

- inheritance, resources, ssr, platforms and verification. These are alternatives,

- not a request to fill all slots or produce a page for every token. Use only forms

- supported by the selected source and reader task.

- For F11, a directory emphasizes scope, catalog, contracts and details; a child

- application detail emphasizes ownership, integration, capabilities, navigation

- and delivery. Link common host contracts rather than repeat them in each detail.

- Read each selected article's guidance for chapter responsibilities and examples.

- If a supported chapter does not fit an available variable, submit it in that

- article's `sections` with source evidence; do not put it in an unknown variable,

- which is warned about and ignored. Preserve accepted section identities where

- applicable. Empty scaffolds are input skeletons, never finished reader content.

-

- Treat article outlines, writing slots and size recommendations as guidance.

- Keep useful evidence-backed content when a slot is unavailable; assess whether

- to merge, omit or add a chapter. A template or source version difference alone

- does not require approval or a restart: retain the versions, explain relevant

- uncertainty and continue work that the evidence supports. Agent review decides

- relevance, completeness and compatibility; the CLI checks reference identity,

- authorized scope, parseable inputs and concurrent revisions. A missing promised

- article remains unfinished until delivered or the accepted plan is adjusted.

-

- Integrate relevant examples into ordinary article fragments with their actual

- source regions. Read their contents; filenames do not establish runtime behavior.

- Do not maintain a separate example/fact binding ledger.

-

- ### Useful article content

-

- Choose one primary location for each explanation. An overview states actual

- capabilities and links to specialist articles; do not fill it with a promise

- that another page has the information. Keep summaries short plain text, not

- source tables. Merge a small overview and source-entry task when they would

- repeat the same file list and reading instructions. Source-entry articles

- should explain why each entry matters and name the next inspection action.

-

- For C02 feature details use prerequisites, operations, exceptions, acceptance

- and version when supported. For D04 engineering guides use scope, commands,

- delivery and conventions; operational diagnostics remain separate.

- For Q01 prefer systems/navigation/development/tools for a testing-domain map.

- Q02 lasting strategy uses layers/coverage/collaboration; a change plan uses

- risks/scenarios/environment/execution. Q04 regression selection uses

- smoke/selection/prerequisites/records; results/failures/conclusion describe

- actual recorded runs, never substitute for the selection baseline. Q07

- confirmed incident reviews use triggers/cause/repair/prevention; unresolved

- FAQ answers may omit these and retain investigation/followup.

-

- When planning an entry article, mark the source-supported entry and next-step

- sections as suggested required sections in the accepted article outline.

- Existing outline-gap diagnostics are advisory; explain missing material or

- add the supported content, without treating prose warnings as a new gate.

- Template section question_refs label writing responsibilities; actual reader

- coverage and its single primary carrier come from accepted question_targets.

- Do not count template section labels as additional answered user questions.

-

- For a deterministic API table, select the authorized contracts relevant to

- that article's task. A page task needs its page inputs and consumed contract

- entries, not every exported constant in the module. Keep caller/route context

- in source-backed prose; a declared API does not prove a live call.

-

- ### Diagrams in reader articles

-

- Use the selected Provider diagram instructions and the article guidance to choose a diagram only when useful. Put fenced Mermaid in an evidence-backed semantic section; use text trees for hierarchy and tables for exact contracts. Explain the diagram in prose and retain source/next-step coordinates for consumers without rendering. Diagram syntax or missing optional graphics never establish a new completion gate. During review, check the meaning and provenance of arrows, not the diagram count.

-

- ### Existing visual sources

- For Author/Review involving source images or tables, consume the selected Provider `references/visual-source-processing.md`. Read current workspace AGENTS.md and `context.convertVisuals`; explicit user instructions override defaults. Use authorized `visual_resources` and sections[].visuals; reuse accepted unchanged results. Capability absence or unsuitable content retains originals without a new gate. Never edit source snapshots or delete assets yourself.

- ### Knowledge-map placement during structure review

- Structure approval includes `knowledge_map`. Read the preview's `knowledge_map_coverage`

- and `article_targets`. Add article entries beneath the agreed category nodes,

- with `target.artifact_ref` and an optional `section_key`; categories alone do not

- place articles. Preserve prior-wave entries. An unchanged knowledge-map revision does

- not imply the new articles are covered. Resolve the CLI's missing/invalid target

- list before resubmitting approval; classification remains your responsibility.

- Report article delivery and navigation coverage separately.

- For new and revised pages, decide placements against the user's current knowledge

- map: retain, add, move or create a category when the reader purpose warrants it.

- Preserve unrelated entries and stable article identities. The coordinator owns

- map edits; workers may suggest placements but never write the map. Recheck new

- article bindings each wave, even when the map itself has not changed. Website

- navigation and LLMS consume this same accepted map.