@c4a/context-cli 0.7.8 → 0.7.9

package/plugins/codex/skills/context-indexer-create/references/guides/indexer-provider-and-customization.md

@@ -10,6 +10,35 @@ Context is registry-only by default. The durable selection lives in
 resolved transport paths and runtime staging directories are not selection
 authority. A Provider-only project does not create `src/indexer/`.
 
+
+## Large sources and planning depth
+
+Use directory/manifests, route or service registration and representative code to
+select Providers and plan reader subjects. Do not run a complete symbol index
+just to decide the initial article menu. Application/service file-inventory
+batches describe reading scope; they are not business module boundaries or a
+requirement to publish one article per directory. Inspect the supplied source
+access and converge related batches into reader subjects. A file with no supplied
+symbol facts has not been deeply parsed; this is not evidence that it has no APIs.
+Accepted application batches acquire parser facts before Author. Existing
+request-material remains the next action for implementation outside the initial
+reading scope. Public-contract-led profiles, including component libraries,
+retain their contract preparation because those facts define their reader targets.
+
+A read scope is an authorization ceiling. Each Indexer should own its actual
+module, with other sources as supporting evidence only when needed. Mixed
+frameworks require per-module Provider choices; do not disable a relevant
+extension to avoid fixing an oversized source boundary. Framework facts are
+still prepared at Author after the selected code has been parsed. For large
+IDL sources, first follow the selected applications' concrete protocol references
+and required includes; an entire protocol monorepo is not a default target.
+
+Parser progress is on stderr; stdout remains the command's JSON result. Report
+actual phase, source and available counts without estimating a percentage from
+elapsed time. A preparation-cache hit only reuses parser work, not proof of
+completed articles. After interruption use the current Route; do not clear state
+or increase memory automatically to retry the same oversized scope.
+
 ## Selection flow
 
 Follow `workflow.current` from `context status --format json` or `context run`.
@@ -31,8 +60,9 @@ configuration or semantic input boundary; it does not make those decisions.
    installed-Skill inventory, discovery report, or discovery-only confirmation
    is required. Use the supplied exact identity and cli-bundled distribution
    for shipped Providers, even when their Skills are also visible to the Host.
-   For a relevant external Skill, read only its exact Host-exposed frontmatter
-   and sibling `context-indexer.yaml` needed for selection. Do not guess versions
+   For a relevant external Skill, read its exact Host-exposed `SKILL.md`
+   and sibling `context-indexer.yaml`, then only the linked framework references
+   needed to evaluate observed module signals. Do not guess versions
    or scan `.claude`, `.codex`, `.agents` or arbitrary user directories. Different
    versions remain distinct; discovery order is not selection precedence.
 3. Submit the semantic `indexers` and any relevant non-CLI `host_visible_skills`
@@ -57,6 +87,31 @@ For CLI-bundled instruction Providers, these fields record the original
 selection; they are not a requirement to reinstall old bytes when resuming.
 The current CLI supplies its installed Provider's guidance automatically.
 
+### Select technology profiles per module
+
+A registered repository is a source boundary, not a single technology profile.
+Different modules may need different primary profiles and extension layers. Use
+the current selection contract's supported module and target/read scopes; never
+assign one module's stack to the entire repository merely because it was
+registered as one source.
+
+An observed framework dependency, configuration, entry or adapter signal is a
+reason to load the relevant Provider Skill and its applicable reference during
+selection. Reading this guidance is not activation or permission to execute the
+Provider. Follow its evidence rules to verify the signal within authorized source
+material, then bind the applicable profile only to the supported modules. A name
+alone may justify investigation without proving a framework is active.
+
+If boundaries are still unclear, identify the relevant modules and inspect their
+configuration and entries in the existing selection flow. Do not reject a
+relevant Provider solely because the repository contains mixed stacks, or defer
+investigation until generic authoring happens to report a capability gap. Record
+unresolved evidence and the concrete next inspection when it cannot yet be
+obtained. Keep unrelated modules on their appropriate primary profiles; multiple
+compatible, proven extensions may support one module without becoming duplicate
+primary owners. These are Agent selection responsibilities, not CLI semantic
+checks or new review gates.
+
 ## Resuming after a tool update
 
 Continue with the current Route and its supplied source material. Agents do not
@@ -110,18 +165,19 @@ indexers:
     providers:
       - id: community
         role: primary
-        skill: "<catalog.skill>"
-        version: "<catalog.version>"
-        integrity: "<catalog.integrity>"
-        distribution:
-          kind: cli-bundled
-          locator: "<catalog.distribution.locator>"
+        catalog_skill: "<catalog.skill>"
 ```
 
 - Choose `component-library` only if it matches the reader task and appears in
   the selected catalog entry's `capabilities.profiles`. For captured documents,
   notes or conversation summaries, select a profile from the corresponding
-  compatible Provider. Copy the actual catalog identity.
+  compatible Provider. `catalog_skill` selects exactly one bundled entry from the
+  current Action catalog. The CLI fills its version, integrity and distribution
+  after checking the Route revision; a changed catalog invalidates that revision.
+  Do not combine this reference with identity overrides. Full identities remain
+  available for explicitly pinned entries and external Providers, which retain
+  their resolution and authorization requirements. The persisted registry always
+  contains complete identities, never `catalog_skill` references.
 - Bind each selected requirement and all required coverage domains it owns;
   the single-domain template is not permission to drop other required domains.
   `owned_scope` names the target being described. `read_scope` may also include
@@ -347,17 +403,16 @@ Existing `reader_goals` remain valid when it is absent. Context passes this
 requirement through Partition, Author, and Review; it does not classify free
 text against a fixed vocabulary.
 
-After representative reading and necessary scope discussion, substantial new work
-can preserve the decisions in `.tmp/work-start-report.md` before Partition.
-The current workflow supplies `procedure.work-start-report` and
-`template.work-start-report`: a readable report with its existing requirement
-reference, use scenarios, scope choices, proposed classifications, first delivery
-and actual execution settings. Lightweight edits keep a short summary. The report
-is scratch context, not a published Artifact, a new approval or a condition for
-advancing the workflow. On its first presentation, invite the user to read and
-correct it and pause for that response, including in managed mode, unless they
-explicitly waived this reading opportunity. Reuse the response and report when
-continuing the same task; do not add a per-batch pause or report-status field.
+For the first production task in a new workspace, the source-boundary Route
+requires `.tmp/work-start-report.md` before source registration. The current
+workflow supplies `procedure.work-start-report` and `template.work-start-report`:
+a readable report covering readers, purpose, source families, language, settings,
+delivery outputs, first delivery and proposed organization. The Agent reads the
+brief and representative authorized material with Host tools, presents the report
+and resolves its missing choices before registration or capture. The CLI only
+checks the Route payload references a real non-empty report and records its digest;
+it does not judge prose or infer semantic decisions. Reuse and update the report
+with actual Provider choices before Partition rather than adding a per-batch report.
 
 Partition may select `artifact_intent` and `template_id` from the current
 Provider catalog, along with `reader_task`, `outline`, `priority`, and

package/plugins/codex/skills/context-indexer-create/references/reference/indexer-provider-protocol.md

@@ -47,6 +47,25 @@ Writing style, chapter drift and ordinary Provider version differences remain
 guidance. Changed source/approval identities invalidate an in-flight supporting
 projection; they are not semantic content judgments.
 
+## Current CLI Author batches
+
+Use the current Route's task keys and supplied scaffold. Within a CLI batch,
+`group_key` may be omitted: preview and completion inherit it from the selected
+current task. An explicitly different group is rejected. Standalone SDK semantic
+results still require `group_key`. Intent and eligible policy use the existing
+page-plan defaults; changing a page's purpose is not a metadata repair.
+
+The inventory reading joins exact member/fact identities to parser names, kinds
+and explicit `propsType` values. These are navigation references, not proof that
+a symbol is public or a member has been covered. Keep semantic dispositions and
+source evidence explicit.
+
+On a stale revision, the CLI exposes a current Route snapshot and current tasks,
+plus accepted identities available from the current main ledger and its Composers.
+Task keys are local to each Route. Compare stable workset/request identities,
+read the new Route and do not replay accepted work. Missing historical records
+are not evidence that old work is unaccepted.
+
 ## Resources and execution
 
 A Provider may contain a controlled program, profile-bound instructions,

package/plugins/cursor/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "c4a",
   "displayName": "C4A Context",
-  "version": "0.7.8",
+  "version": "0.7.9",
   "description": "Start or continue a project-local knowledge workspace through one graph-routed entry.",
   "author": {
     "name": "Context4AI",

package/plugins/cursor/commands/c4a-context.md

@@ -1,5 +1,5 @@
 ---
-description: "Use when the user explicitly invokes Context or continues an explicitly started Context workflow in this conversation to build, inspect, update or package knowledge from code, documents, notes and conversation summaries. Do not auto-start for ordinary planning, design or coding."
+description: "Use when the user explicitly invokes Context, asks to reorganize an existing Context knowledge map or website navigation, or continues a Context workflow to build, inspect, update, recover or package knowledge. Do not auto-start for ordinary planning, design or coding."
 ---
 
 # Context
@@ -10,6 +10,8 @@ reading; use it for workspace writes.
 
 Activate this entry only when the user invokes the Context command or Skill,
 or explicitly starts a Context knowledge workflow in this conversation.
+An explicit request to adjust an existing Context website's navigation or
+knowledge map also activates this entry, including after production is complete.
 Related follow-up requests need no repeated invocation. Ordinary planning,
 design, coding, document editing or discussion of Context implementation does
 not activate it. A workspace, source file, MR or matching phrase alone is not
@@ -27,12 +29,14 @@ Within an active Context workflow, requests include, but are not limited to:
 | Intent | Scope |
 | --- | --- |
 | Build a knowledge base | Clarify the audience and source scope, then create or continue knowledge from selected repositories and documents. |
+| Recover a stuck Context task | Use `context task recover --format json` in the existing workspace; read its recovery Skill even if normal status/Route fails. Repair authorized drafts or restore an available planning baseline; report unresolved failures with the supplied sanitized issue template. |
 | Check progress and results | Explain what is done, where delivered pages are, and what is waiting. |
 | Save notes | Save supplied observations, excerpts or decisions; stop after saving if that is all the user requested. |
 | Preserve conversation insights | Save or use a summary of supplied discussion, not an entire session history. Code-change links are optional. |
 | Update knowledge from source changes | Assess a selected commit, MR/PR or document change against a fixed source version; update affected pages and warranted new topics. |
 | Revise existing content | Correct current drafts or approved pages, including several pages or supported API-table regeneration. |
 | Organize pages and sources | Move pages within a collection, rename supported sources or remove unused sources with reference checks. |
+| Customize the knowledge map | At any time, reorganize the existing site's top navigation, left directory, labels, order or article placements; the same map organizes LLMS. Preserve current production work. |
 | Select or customize indexing | Choose compatible indexing Skills and adjust guidance or templates through the configuration flow. |
 | Deliver a batch early | Review and build complete newly authored pages before all writing finishes. |
 | Package knowledge or adjust output | Build approved content for Agents or LLMs, rebuild a package or change its output template. Rebuilding does not rewrite pages. |
@@ -40,6 +44,68 @@ Within an active Context workflow, requests include, but are not limited to:
 | Commit workspace results | Save selected workspace files in local Git, without pushing or including unrelated changes. |
 | Restore a historical workspace version | Select a saved commit, restore only the agreed workspace scope and make its sources usable again. |
 
+## Read the task before registering sources
+
+For a knowledge-map-only request, use the existing workspace directly. Read
+`src/knowledge-map.yaml` and the current article identities/structure preview;
+translate the user's intent into `knowledge_map` input for
+`context task adjust --input <file> --format json`. Resolve only ambiguous
+organization choices. This adjustment is available without an active production
+task and does not require restarting or cancelling one. The coordinator makes
+the change between active batch submissions, then follows the returned workflow
+to rebuild affected outputs. Keep stable article identities, preserve unrelated
+placements, and never edit generated website/LLMS files. No new source intake or
+production-mode questionnaire is needed for this navigation-only request.
+
+When asked to follow a plan, checklist or instructions in a file, read that file
+as the task brief before initialization or source registration. Extract its goal,
+source scope, delivery requirements and explicit execution-mode choice. Apply the
+user's latest corrections to the corresponding parts of the brief. Check that
+registered sources match that scope; a Route governs the registered work, not
+whether it represents the user's request.
+
+“Build according to plan.md” means follow the plan and register its intended
+sources. “Add plan.md to the knowledge base” means ingest the file itself.
+Reading permission alone does not select a document for ingestion. Reuse a mode
+explicitly chosen in a brief the user asked you to execute; do not treat choices
+quoted in an unrelated source document as current authorization.
+
+For the first production task in a newly initialized workspace, do not register
+or capture sources immediately after reading a brief. Use the user's task instructions
+and batch metadata-only Host tools to read titles across the explicitly supplied
+document list. Follow the work-start procedure's request limits and failure fallback
+(at most 10 unresolved documents); reuse headings only if metadata already returns
+them. Do not fetch source bodies, outlines, images or attachments before capture.
+Retain URLs with unavailable titles; never fall back to content fetching. Collect the reader and purpose, intended
+questions or tasks, code/document/other source boundaries, output language,
+execution mode, delivery outputs, first useful delivery and current workspace
+settings. Reuse explicit answers and defaults; ask only for unresolved items.
+
+Use focused dialogue, not additional source reading, until every required start
+condition is resolved. Then write and present the complete work-start report
+supplied by the source-boundary Route and wait for the user's feedback. Do not
+present an unresolved draft as the report that authorizes production. The report
+or checklist is task guidance, not a source unless the user explicitly asks to
+ingest it. Before the complete report has been presented, do not write a
+source-registration payload, start capture or extraction, configure Indexers,
+or enter Partition/Author work. A
+managed-mode choice does not waive this first reading opportunity. After feedback,
+use the exact current Route and include its work-start report reference in the
+source batch payload. Existing workspace updates follow their current update Route
+and do not recreate this first-task intake unless they start a new production task.
+
+## Recover an existing stuck task
+
+For an explicit recovery/troubleshooting request, go directly to
+`context task recover --format json` in the intended existing workspace. Do not
+initialize, ask for a production mode again, or pass a saved `--workflow-revision`.
+Read the returned internal recovery Skill and issue template. This entry remains
+available when normal status cannot evaluate. If even recovery cannot run, use
+`issue/YYYY-MM-DD-short-description.md` to record sanitized expected/actual behavior,
+versions, command shape, error code, attempted remedies and preserved work; never
+copy credentials, raw logs or private source text. Do not send the report externally
+without the user's authorization.
+
 ## Enter the workspace
 
 Once the activation condition is met, run:
@@ -167,7 +233,14 @@ authority; do not reconstruct commands from earlier steps.
 the complete returned file and any required direct files it names. If a resource
 has a `command`, execute it and read its output; materializing is not reading.
 Current Indexer Partition, Author, Composer and structure-review files need no
-read receipt: use their immediate completion command after reading. For other
+read receipt: use their immediate completion command after reading.
+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.
+For other
 resources, follow the returned receipt instructions, keep receipts in this
 conversation, and use the latest `next_action.command` carrying that context.
 When only direct files remain, `resources.after_read.command` acknowledges them
@@ -255,11 +328,11 @@ must not resolve or install the Provider again.
 
 ## Progress reporting format
 
-Every user-facing progress update, in conversation or in a report, must use
-these two bold lines in this order, with the actual values inside the brackets:
+For production progress updates, use two bold lines in this order. Describe
+the actual stage when counters are unavailable; include counts only when supplied:
 
-**[总体进度：已交付 33/125 页]**
-**[当前分片：已规划 3/8 项]**
+**[总体进展：已交付 33/125 页]**
+**[当前进展：已规划 3/8 项]**
 
 Use CLI `progress.scopes` (or `indexerProgress.scopes` in status) as the
 single source for progress in conversation and reports. It separates:
@@ -281,9 +354,10 @@ number of currently prepared tasks. Revisions can overlap delivered pages;
 do not add wave tasks to delivered pages to invent a page total.
 
 Use two bold progress lines. The first combines `overall` and a clearly labelled
-`wave` supplement; the second uses `slice`. For example, with matching CLI values:
-**[总体进度：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
-**[当前分片：补充内容检查 0/8 项]**
+`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
@@ -291,8 +365,12 @@ reporting submission success and the latter when announcing the next slice.
 Never combine their numerators and denominators. A null slice means no active
 Agent task slice, not that the workflow is complete. During Review/build, state
 the returned Route action briefly rather than inventing a slice ratio.
-If progress is unavailable after task cleanup, say the counters are unavailable;
-do not turn the last wave into the overall scope or report delivery as zero.
+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.

package/plugins/cursor/skills/context-indexer-create/references/guides/indexer-provider-and-customization.md

@@ -10,6 +10,35 @@ Context is registry-only by default. The durable selection lives in
 resolved transport paths and runtime staging directories are not selection
 authority. A Provider-only project does not create `src/indexer/`.
 
+
+## Large sources and planning depth
+
+Use directory/manifests, route or service registration and representative code to
+select Providers and plan reader subjects. Do not run a complete symbol index
+just to decide the initial article menu. Application/service file-inventory
+batches describe reading scope; they are not business module boundaries or a
+requirement to publish one article per directory. Inspect the supplied source
+access and converge related batches into reader subjects. A file with no supplied
+symbol facts has not been deeply parsed; this is not evidence that it has no APIs.
+Accepted application batches acquire parser facts before Author. Existing
+request-material remains the next action for implementation outside the initial
+reading scope. Public-contract-led profiles, including component libraries,
+retain their contract preparation because those facts define their reader targets.
+
+A read scope is an authorization ceiling. Each Indexer should own its actual
+module, with other sources as supporting evidence only when needed. Mixed
+frameworks require per-module Provider choices; do not disable a relevant
+extension to avoid fixing an oversized source boundary. Framework facts are
+still prepared at Author after the selected code has been parsed. For large
+IDL sources, first follow the selected applications' concrete protocol references
+and required includes; an entire protocol monorepo is not a default target.
+
+Parser progress is on stderr; stdout remains the command's JSON result. Report
+actual phase, source and available counts without estimating a percentage from
+elapsed time. A preparation-cache hit only reuses parser work, not proof of
+completed articles. After interruption use the current Route; do not clear state
+or increase memory automatically to retry the same oversized scope.
+
 ## Selection flow
 
 Follow `workflow.current` from `context status --format json` or `context run`.
@@ -31,8 +60,9 @@ configuration or semantic input boundary; it does not make those decisions.
    installed-Skill inventory, discovery report, or discovery-only confirmation
    is required. Use the supplied exact identity and cli-bundled distribution
    for shipped Providers, even when their Skills are also visible to the Host.
-   For a relevant external Skill, read only its exact Host-exposed frontmatter
-   and sibling `context-indexer.yaml` needed for selection. Do not guess versions
+   For a relevant external Skill, read its exact Host-exposed `SKILL.md`
+   and sibling `context-indexer.yaml`, then only the linked framework references
+   needed to evaluate observed module signals. Do not guess versions
    or scan `.claude`, `.codex`, `.agents` or arbitrary user directories. Different
    versions remain distinct; discovery order is not selection precedence.
 3. Submit the semantic `indexers` and any relevant non-CLI `host_visible_skills`
@@ -57,6 +87,31 @@ For CLI-bundled instruction Providers, these fields record the original
 selection; they are not a requirement to reinstall old bytes when resuming.
 The current CLI supplies its installed Provider's guidance automatically.
 
+### Select technology profiles per module
+
+A registered repository is a source boundary, not a single technology profile.
+Different modules may need different primary profiles and extension layers. Use
+the current selection contract's supported module and target/read scopes; never
+assign one module's stack to the entire repository merely because it was
+registered as one source.
+
+An observed framework dependency, configuration, entry or adapter signal is a
+reason to load the relevant Provider Skill and its applicable reference during
+selection. Reading this guidance is not activation or permission to execute the
+Provider. Follow its evidence rules to verify the signal within authorized source
+material, then bind the applicable profile only to the supported modules. A name
+alone may justify investigation without proving a framework is active.
+
+If boundaries are still unclear, identify the relevant modules and inspect their
+configuration and entries in the existing selection flow. Do not reject a
+relevant Provider solely because the repository contains mixed stacks, or defer
+investigation until generic authoring happens to report a capability gap. Record
+unresolved evidence and the concrete next inspection when it cannot yet be
+obtained. Keep unrelated modules on their appropriate primary profiles; multiple
+compatible, proven extensions may support one module without becoming duplicate
+primary owners. These are Agent selection responsibilities, not CLI semantic
+checks or new review gates.
+
 ## Resuming after a tool update
 
 Continue with the current Route and its supplied source material. Agents do not
@@ -110,18 +165,19 @@ indexers:
     providers:
       - id: community
         role: primary
-        skill: "<catalog.skill>"
-        version: "<catalog.version>"
-        integrity: "<catalog.integrity>"
-        distribution:
-          kind: cli-bundled
-          locator: "<catalog.distribution.locator>"
+        catalog_skill: "<catalog.skill>"
 ```
 
 - Choose `component-library` only if it matches the reader task and appears in
   the selected catalog entry's `capabilities.profiles`. For captured documents,
   notes or conversation summaries, select a profile from the corresponding
-  compatible Provider. Copy the actual catalog identity.
+  compatible Provider. `catalog_skill` selects exactly one bundled entry from the
+  current Action catalog. The CLI fills its version, integrity and distribution
+  after checking the Route revision; a changed catalog invalidates that revision.
+  Do not combine this reference with identity overrides. Full identities remain
+  available for explicitly pinned entries and external Providers, which retain
+  their resolution and authorization requirements. The persisted registry always
+  contains complete identities, never `catalog_skill` references.
 - Bind each selected requirement and all required coverage domains it owns;
   the single-domain template is not permission to drop other required domains.
   `owned_scope` names the target being described. `read_scope` may also include
@@ -347,17 +403,16 @@ Existing `reader_goals` remain valid when it is absent. Context passes this
 requirement through Partition, Author, and Review; it does not classify free
 text against a fixed vocabulary.
 
-After representative reading and necessary scope discussion, substantial new work
-can preserve the decisions in `.tmp/work-start-report.md` before Partition.
-The current workflow supplies `procedure.work-start-report` and
-`template.work-start-report`: a readable report with its existing requirement
-reference, use scenarios, scope choices, proposed classifications, first delivery
-and actual execution settings. Lightweight edits keep a short summary. The report
-is scratch context, not a published Artifact, a new approval or a condition for
-advancing the workflow. On its first presentation, invite the user to read and
-correct it and pause for that response, including in managed mode, unless they
-explicitly waived this reading opportunity. Reuse the response and report when
-continuing the same task; do not add a per-batch pause or report-status field.
+For the first production task in a new workspace, the source-boundary Route
+requires `.tmp/work-start-report.md` before source registration. The current
+workflow supplies `procedure.work-start-report` and `template.work-start-report`:
+a readable report covering readers, purpose, source families, language, settings,
+delivery outputs, first delivery and proposed organization. The Agent reads the
+brief and representative authorized material with Host tools, presents the report
+and resolves its missing choices before registration or capture. The CLI only
+checks the Route payload references a real non-empty report and records its digest;
+it does not judge prose or infer semantic decisions. Reuse and update the report
+with actual Provider choices before Partition rather than adding a per-batch report.
 
 Partition may select `artifact_intent` and `template_id` from the current
 Provider catalog, along with `reader_task`, `outline`, `priority`, and

package/plugins/cursor/skills/context-indexer-create/references/reference/indexer-provider-protocol.md

@@ -47,6 +47,25 @@ Writing style, chapter drift and ordinary Provider version differences remain
 guidance. Changed source/approval identities invalidate an in-flight supporting
 projection; they are not semantic content judgments.
 
+## Current CLI Author batches
+
+Use the current Route's task keys and supplied scaffold. Within a CLI batch,
+`group_key` may be omitted: preview and completion inherit it from the selected
+current task. An explicitly different group is rejected. Standalone SDK semantic
+results still require `group_key`. Intent and eligible policy use the existing
+page-plan defaults; changing a page's purpose is not a metadata repair.
+
+The inventory reading joins exact member/fact identities to parser names, kinds
+and explicit `propsType` values. These are navigation references, not proof that
+a symbol is public or a member has been covered. Keep semantic dispositions and
+source evidence explicit.
+
+On a stale revision, the CLI exposes a current Route snapshot and current tasks,
+plus accepted identities available from the current main ledger and its Composers.
+Task keys are local to each Route. Compare stable workset/request identities,
+read the new Route and do not replay accepted work. Missing historical records
+are not evidence that old work is unaccepted.
+
 ## Resources and execution
 
 A Provider may contain a controlled program, profile-bound instructions,