@c4a/context-cli 0.7.8 → 0.7.9

package/plugins/skills/context-code-indexer/templates/articles/q05.md

@@ -2,6 +2,18 @@
 id: context.article.q05
 kind: procedure
 media-type: text/markdown
+program:
+  article: q05
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    requirements: 数据需求
+    preparation: 准备入口
+    isolation: 环境和隔离
+    lifecycle: 数据生命周期
+    verification: 验证和清理
 ---
 
 # Q05 测试数据与环境

package/plugins/skills/context-code-indexer/templates/articles/q06.md

@@ -2,6 +2,18 @@
 id: context.article.q06
 kind: procedure
 media-type: text/markdown
+program:
+  article: q06
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    tasks: 任务到工具
+    prerequisites: 接入前提
+    operations: 常用操作
+    results: 结果解释
+    references: 代码与文档入口
 ---
 
 # Q06 工具与排障工具箱

package/plugins/skills/context-code-indexer/templates/articles/s01.md

@@ -2,6 +2,20 @@
 id: context.article.s01
 kind: procedure
 media-type: text/markdown
+program:
+  article: s01
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    scope: 服务定位
+    startup: 接入和启动
+    architecture: 架构分层
+    capabilities: 核心能力与接口
+    dependencies: 模型和依赖摘要
+    index: 知识索引
+    sources: 源码位置
 ---
 
 # S01 服务概览

package/plugins/skills/context-code-indexer/templates/articles/s02.md

@@ -2,6 +2,19 @@
 id: context.article.s02
 kind: procedure
 media-type: text/markdown
+program:
+  article: s02
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    scope: 协议与范围
+    catalog: 能力与入口表
+    authority: 权威契约
+    implementation: 调用方与实现
+    references: 详情导航
+  contract_table: contract_api
 ---
 
 # S02 API 目录

package/plugins/skills/context-code-indexer/templates/articles/s03.md

@@ -2,6 +2,21 @@
 id: context.article.s03
 kind: procedure
 media-type: text/markdown
+program:
+  article: s03
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    entry: 用途与入口
+    validation: 请求和边界校验
+    steps: 处理步骤
+    downstream: 数据与下游操作
+    response: 响应与错误
+    concurrency: 并发与幂等
+    references: 调用方与入口
+  contract_table: contract_api
 ---
 
 # S03 API／操作详情

package/plugins/skills/context-code-indexer/templates/articles/s04.md

@@ -2,6 +2,20 @@
 id: context.article.s04
 kind: procedure
 media-type: text/markdown
+program:
+  article: s04
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    scope: 领域范围
+    catalog: 实体与概念表
+    entities: 核心实体
+    relations: 已证实关系
+    states: 状态与转移
+    rules: 业务约束
+    references: 实现与资料
 ---
 
 # S04 领域模型

package/plugins/skills/context-code-indexer/templates/articles/s05.md

@@ -2,6 +2,19 @@
 id: context.article.s05
 kind: procedure
 media-type: text/markdown
+program:
+  article: s05
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    scope: 存储职责
+    models: 表与持久化对象
+    queries: 查询和索引
+    cache: 缓存与锁
+    consistency: 事务与一致性
+    references: 读写入口
 ---
 
 # S05 数据模型

package/plugins/skills/context-code-indexer/templates/articles/s06.md

@@ -2,6 +2,19 @@
 id: context.article.s06
 kind: procedure
 media-type: text/markdown
+program:
+  article: s06
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    overview: 依赖概览
+    requests: RPC 与 HTTP
+    events: 事件与任务
+    storage: 存储及配置服务
+    initialization: 初始化与选择
+    failures: 故障边界和下一步
 ---
 
 # S06 外部依赖

package/plugins/skills/context-code-indexer/templates/articles/s07.md

@@ -2,6 +2,20 @@
 id: context.article.s07
 kind: procedure
 media-type: text/markdown
+program:
+  article: s07
+  policies:
+    - compact
+    - standard
+    - expanded
+  sections:
+    triggers: 职责与触发源
+    registration: 注册与订阅
+    payload: Payload 与过滤
+    processing: 处理链路
+    retry: 重试幂等与并发
+    reconciliation: 检查点补偿与对账
+    operations: 运行和观测入口
 ---
 
 # S07 事件、任务与对账

package/plugins/skills/context-code-indexer/templates/contract-source.md

@@ -71,3 +71,52 @@ must contain exact contract identities and source locators, not just filenames.
 
 Revise or stop when authority cannot be distinguished from a generated copy,
 imports or versions are unresolved, or compatibility claims are not declared.
+
+## Overview maps for a selected contract family
+
+When the user chooses a bounded overview, organize the page as scope/version,
+contract-family map, representative operations, active consumers, lookup procedure,
+change/generation entrypoints and unread boundaries. Separate API entry schemas,
+domain contracts, runtime RPC/message boundaries and common models when the source
+actually distinguishes them. Do not force these layers onto an unrelated schema.
+
+A useful family row contains purpose, authoritative directory/file, known consumer
+and the next lookup. A representative operation row can connect reader action,
+external operation identity, schema Service/Method and implementation locator;
+mark an unknown hop as a question, never a proven call. Count only with a recorded
+file-set boundary or reproducible inventory; a few examples cannot establish
+complete coverage or a total operation count. Cross-file imports needed to explain
+a selected type are supporting evidence, not automatic new article subjects.
+
+For large groups, directory routes with scoped searches are preferable to thousands
+of file rows. Give an actual lookup example and what to do when no match is found.
+A short article does not imply cheap extraction: the confirmed overview treatment
+must first be expressible in the actual source/production configuration. This
+writing template does not change parser depth. If the current contract profile
+would still prepare the entire source, resolve that scope before proceeding;
+do not silently select another profile or claim deferred parsing already happened.
+
+## Prefer linked definitions over schema transcription
+
+For entry-first knowledge, avoid exhaustive IDL reading and rewriting. Start with
+consumer/generator configuration and known operation identities; inspect only the
+definitions needed for the actual claim. A file locator does not prove its fields
+or runtime use. Keep complete schema bodies out of Markdown unless a short excerpt
+is necessary to explain the reader's question. Do not modify authoritative IDL.
+
+A source-backed attachment is useful only when an article explicitly needs and
+links that exact definition. Repository presence alone never selects an asset.
+If a supported source-resource projection exists, use its registered source,
+revision, relative path and byte digest; never copy the entire IDL tree or hand-write
+knowledge/assets. Otherwise retain a versioned source locator and state that the
+offline attachment is unavailable. The existing document-attachment mechanism is
+not proof that repository files have been registered as source assets.
+
+An attached IDL remains source evidence, not a second authoritative contract or
+an instruction to create another article. Include dependencies are added only
+when needed for the documented use; distinguish a readable excerpt from a complete,
+compilable schema bundle. Do not claim the attachment compiles unless verified.
+Source byte changes must invalidate the affected resource and dependent evidence;
+unchanged bytes can reuse the resource. A repository revision change alone does
+not prove a changed definition, and source bytes changing do not prove a breaking
+API change. Preserve source identity even when identical bytes share storage.

package/plugins/skills/context-code-indexer/templates/derived-generated-source.md

@@ -115,3 +115,18 @@ material-question proposal until the missing authority is provided.
 - the plan duplicates upstream reference material without consumer value;
 - legacy replacement or deprecation claims are inferred rather than evidenced;
 - generated symbols dominate projected pages.
+
+## Compact collection map
+
+For a confirmed homogeneous collection, group by observed purpose and consumers,
+not one page per generated file. Explain the source of truth, local output boundary,
+representative shapes, scoped lookup, regeneration and what remains unread. Count
+physical copies separately from unique contracts: the same model copied into several
+applications is not several independent interfaces. An import path containing an
+upstream repository name does not prove an additional checkout or runtime call.
+
+A generator marker is evidence of provenance, not proof that the whole tree is
+irrelevant. Preserve the supported consumer surface and maintained overlays.
+Handwritten homogeneous handlers/configurations use their own semantic profile;
+do not call them generated just to compress their article output. The same map
+style can be used without changing provenance or pretending all files were read.

package/plugins/skills/context-code-indexer/templates/monorepo-container.md

@@ -122,3 +122,12 @@ but should not override declared workspace ownership or package boundaries.
 - child ownership or source-of-truth boundaries are ambiguous;
 - generated/cache/vendor directories dominate projected output;
 - dependencies are inferred solely from names without manifest or graph proof.
+
+## Uneven depth without losing navigation
+
+Give important modules a concrete responsibility and first source entry; group
+less central modules into a categorized directory map with lookup instructions.
+State which were inspected deeply and which only have inventory/manifest evidence.
+Do not force all modules to have equally long pages or fabricate handler, DAO,
+configuration or test directories from framework conventions. Keep this shared
+map as the topology owner; child articles explain their differences and link back.

package/plugins/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/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,