@c4a/context-cli 0.7.9 → 0.7.10-alpha.2

package/plugins/skills/context/SKILL.md

@@ -190,13 +190,12 @@ or scope; discussion and save-only requests can end without production.
   condition and do not register the same request repeatedly.
 - When the user asks to compile, build or deliver a batch, use the current Route
   to choose early delivery or rebuilding; do not guess a command name.
-- **Delivery batch size:** use `context run --delivery-size <1–50|auto> --format json`
-  for an explicit user preference; it applies to future theme waves in this task.
-- **Earlier delivery of newly authored pages:** use the Author Route's
-  `delivery.request.command` (`context run --deliver --format json`). Finish any
-  running command first. Complete the current Author batch, then follow the
-  returned composition, Review and build steps. This does not approve content
-  or merely rebuild old approved pages; all Author tasks need not finish first.
+- **Earlier delivery of completed articles:** when explicitly requested, finish
+  any running command, then use `context run --deliver --format json` and follow
+  its Review, close and build routes. This pauses further writing without
+  approving content. Successful delivery resumes remaining tasks; an explicit
+  `context run --resume-writing --format json` cancels the pause without losing
+  drafts or approvals. Batch grouping belongs to the current Agent plan.
 - **An independent new task while work remains:** explain saved results,
   unfinished scope and concrete rollback losses. Reuse or obtain the user's
   choice to finish the current task or roll back an explicit scope. Do not

package/plugins/skills/context-code-indexer/SKILL.md

@@ -1,56 +1,31 @@
 ---
 name: context-code-indexer
-description: Context-managed Provider for source-grounded code knowledge. Use only when the Context Indexer lifecycle selects this Provider, not as a standalone workflow.
+description: Investigate code skeletons and write source-grounded Context articles for an authorized module. Use when selected for the current planning or writing task, not as a standalone repository audit.
 metadata:
   context-role: "indexer-provider"
   context-public-entry: "false"
-  context-provider-version: "1.2.1"
 ---
 
 # Context Code Indexer
 
-Provider authors must satisfy
-`node_modules/@c4a/context/docs/guides/code-indexer-skill-authoring.md` and the
-shared Provider/customization guide before publishing or extending this Skill.
-Those documents are authoring contracts; the current workset and Route remain
-execution authority.
+Follow the current Context stage's purpose, module boundary and file submission
+schema. Read [investigation and writing guidance](references/indexer.md).
+The skill helps discover a useful skeleton and explain code; it does not own
+the module, its articles or their permanent provenance.
 
-Use this Provider only through the Context Indexer lifecycle. The workspace registry selects an exact profile, version, integrity, scope, and operation. Consume evidence only from the single Context-supplied Authorized Workset View; do not scan outside the supplied workset, construct pagination/receipt requests, or write project files directly.
+During planning, start with the supplied directory and file navigation.
+Identify relevant technology and visible capability families, optionally
+inspect representative source, and propose reader topics and writing batches.
+Do not start full-repository parsing, enumerate every symbol or build a
+relationship graph to satisfy planning. Name partial counts as partial.
 
-Keep machine identity and reader content deliberately small. A durable Fact
-locator may identify a relation or declaration, but must never embed a source
-expression, implementation body, complete tool response, credential-like value,
-or other source text; keep such material in the process-local protected payload.
-Write for a consumer outside the indexed module: show what the module is
-responsible for, when and how to enter it through stable interfaces, where it
-hands off, and which core state, failure, operation, or source-of-truth facts are
-needed for correct use and attribution. Effective coverage means answering these
-supported reader questions across stable capabilities, not maximizing the number
-of symbols or paths mentioned.
-Every reader Artifact must answer the selected profile's concrete questions from
-current facts. A symbol/path list, generic module summary, workflow explanation,
-or internal Fact/View/digest count is not useful knowledge and must not be emitted.
-Before emitting an Artifact, identify the concrete selected-profile question
-that its logical unit answers. Formal question refs may close required coverage,
-but a group label, Partition Subject, or large Fact volume alone is not a reader
-purpose; a unit with no applicable profile question is catalog-only.
-Bind each reader claim only to the smallest relevant evidence set; never attach
-an entire workset inventory to a generic summary.
-Close inventory members with their actual boundary evidence or a legal
-catalog/exclusion disposition. Never reuse one unrelated fallback evidence
-binding merely to make the disposition denominator appear complete.
-When a large module exposes stable route, capability, protocol, runtime, or
-storage boundaries, partition on those boundaries before authoring. Do not put
-the whole module in one catch-all logical unit, and do not replace semantic
-partitioning with numbered batches.
+A module may use several selected Indexer skills for different technology or
+content. Their findings can support the same article. Do not register a
+primary/extension binding, verify skill hashes or versions, or record skill
+identity in articles. The plan's temporary skill guidance is sufficient.
 
-When revising existing knowledge, start from the supplied current page and the
-confirmed reader purpose. Update changed API facts and parameter/type tables
-without replacing still-valid explanations or prior confirmed contributions.
-When code is unchanged, useful new context can be a local explanatory revision
-without partitioning the whole source again.
-Keep additions within the selected modules; identify newly public objects as
-well as changes to already documented ones. Recommend a retirement or move only
-for the affected content and explain the reader consequence.
-
-The machine-readable authority is `context-indexer.yaml`. Detailed authoring guidance is materialized by Context from the registered Bundle after its file ledger and integrity have been verified.
+During writing, inspect the actual implementation and contracts needed for
+each reader question. Put complete new Markdown and reference files, or
+fragment edits for a supplied base article, in the Agent temporary directory.
+Submit through the current CLI action; do not write formal knowledge or modify
+the source repository. Missing material blocks only the affected scope.

package/plugins/skills/context-code-indexer/context-indexer.yaml

@@ -1,6 +1,6 @@
 protocol: context.indexer.provider/v1
 id: context-code-indexer
-version: 1.2.1
+version: 1.2.2-alpha.1
 domains:
   - code
 activation:
@@ -95,8 +95,6 @@ provides:
       contract:
         instruction: references/composers/public-contract.md
         primary_requirements:
-          fact_kinds:
-            - code-symbol
           artifact_kinds:
             - content
         derived_artifact_policy:
@@ -127,8 +125,6 @@ provides:
       contract:
         instruction: references/composers/protocol-boundary.md
         primary_requirements:
-          fact_kinds:
-            - protocol-operation
           artifact_kinds:
             - contract
         derived_artifact_policy:
@@ -159,8 +155,6 @@ provides:
       contract:
         instruction: references/composers/cross-module-chain.md
         primary_requirements:
-          fact_kinds:
-            - module-dependency
           artifact_kinds:
             - content
         derived_artifact_policy:
@@ -193,9 +187,6 @@ provides:
       contract:
         instruction: references/composers/contracts-and-chains.md
         primary_requirements:
-          fact_kinds:
-            - contract-binding
-            - module-dependency
           artifact_kinds:
             - contract
         derived_artifact_policy:
@@ -222,8 +213,6 @@ provides:
       contract:
         instruction: references/composers/event-flow.md
         primary_requirements:
-          fact_kinds:
-            - event-binding
           artifact_kinds:
             - content
         derived_artifact_policy:
@@ -248,8 +237,6 @@ provides:
       contract:
         instruction: references/composers/persistence-boundary.md
         primary_requirements:
-          fact_kinds:
-            - persistence-binding
           artifact_kinds:
             - content
         derived_artifact_policy:
@@ -282,8 +269,6 @@ provides:
       contract:
         instruction: references/composers/examples-and-documentation.md
         primary_requirements:
-          fact_kinds:
-            - example-candidate
           artifact_kinds:
             - content
         derived_artifact_policy:
@@ -316,8 +301,6 @@ provides:
       contract:
         instruction: references/composers/development-and-delivery.md
         primary_requirements:
-          fact_kinds:
-            - development-entry
           artifact_kinds:
             - content
         derived_artifact_policy:
@@ -336,7 +319,7 @@ provides:
     - operational-source
   logical_units:
     - id: semantic-subject
-      identity: canonical-subject-key
+      identity: stable-article
       artifacts:
         recommended:
           - content

package/plugins/skills/context-code-indexer/references/composers/contracts-and-chains.md

@@ -10,7 +10,7 @@ Use only when `contracts-and-chains` is present in the effective composer set.
 Consume the exact primary view and return post-author proposals, never another
 complete Indexer Result.
 
-Require both `contract-binding` and `module-dependency` facts plus a primary
+Use the supplied primary article and its regional references to establish the connection between a source contract and its implementation/consumer. Require a primary
 `contract` Artifact. A derived `contract` Artifact may summarize how a stable
 contract identity is produced, transported, implemented, consumed, and traced
 across registered modules. Preserve the authoritative schema and distinguish
@@ -18,6 +18,11 @@ generated bindings from source contracts.
 
 Use the existing target, the `standard` policy, and evidence already bound to
 the view. Do not merge unrelated protocols merely because they share a
-transport. If either fact, the primary Artifact, or an evidenced end-to-end
+transport. If the source relationship, the primary Artifact, or an evidenced end-to-end
 binding is absent, return `context.indexer.layer-fragment-result/v1` with an
 empty `fragments` array.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/cross-module-chain.md

@@ -7,10 +7,10 @@ media-type: text/markdown
 # Cross-module chain composer
 
 Run only for the selected composer and the supplied `PrimaryResultView`.
-Derived output supplements an existing target Node; it cannot create scope,
+Derived output supplements an existing article target; it cannot create scope,
 change ownership, or replace the primary Result.
 
-Require an evidenced `module-dependency` fact and primary `content` Artifact.
+Use the primary article and its regional references to establish a demonstrated dependency between the participating modules. Require primary `content` Artifact.
 Propose derived `content` only when a stable reader question crosses at least
 two registered module boundaries and every hop has an unambiguous identity and
 evidence. Describe trigger, ordered boundaries, transformations, outcome,
@@ -20,3 +20,8 @@ Use the `standard` policy and view evidence only. Import adjacency, directory
 proximity, or a guessed runtime call is insufficient. Missing requirements,
 an incomplete chain, or an already answered question yields the structured
 empty result: the accepted layer-fragment result with `fragments: []`.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/development-and-delivery.md

@@ -10,13 +10,18 @@ Run only for an effective `development-and-delivery` workset. It supplements
 the primary target and cannot own repository scope, release authority, or the
 final Indexer Result.
 
-Require an evidenced `development-entry` fact and primary `content` Artifact.
+Use the primary article and its regional references to establish a demonstrated development or delivery entry. Require primary `content` Artifact.
 Propose derived `content` only for module-owned setup, build, test, packaging,
 deployment, release, rollback, or recovery behavior that answers a stable
 reader question. Distinguish local commands from CI orchestration and record
 configuration inputs without copying secret-like values.
 
-Use the existing Node, `standard` policy, and view evidence. Workspace-wide
+Use the existing article, `standard` policy, and view evidence. Workspace-wide
 processes belong on a container target, not every module. If the required input
 is absent or the view contains no module-owned development/delivery contract,
 return `fragments: []` in the ordinary structured result.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/event-flow.md

@@ -9,13 +9,18 @@ media-type: text/markdown
 Run only from an effective `event-flow` workset. The supplied primary view is
 the complete authority boundary for this invocation.
 
-Require an evidenced `event-binding` fact and primary `content` Artifact.
+Use the primary article and its regional references to establish a demonstrated event binding. Require primary `content` Artifact.
 Propose derived `content` only when a stable event identity connects producer,
 transport or dispatch, consumer, state effect, retry/idempotency behavior, and
 failure handling. Timers and scheduled triggers qualify only when their
 registration and downstream behavior are explicit.
 
-Keep the current target Node, use `standard`, and cite view evidence. Do not
+Keep the current article target, use `standard`, and cite view evidence. Do not
 invent a producer from a consumer name or infer delivery guarantees from a
 library default. Missing requirements, an unpaired boundary, or no additional
 reader value must return the normal result envelope with `fragments: []`.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/examples-and-documentation.md

@@ -10,13 +10,18 @@ Run only when selected for the current profile. The workset-scoped primary
 view is the sole input; documentation files outside that view are not implicit
 authority.
 
-Require an evidenced `example-candidate` fact and primary `content` Artifact.
+Use the primary article and its regional references to establish a representative, maintained public usage example. Require primary `content` Artifact.
 Propose an `examples` Artifact only for maintained usage that demonstrates a
 supported public target, meaningful setup, expected outcome, and important
 constraints. Merge scenario variants and exclude fixtures, generated samples,
 and demos that do not represent supported use.
 
-Use the existing target Node and `standard` policy. Evidence must come from the
+Use the existing article target and `standard` policy. Evidence must come from the
 view. When no representative example closes the reader question, or either
 required input is missing, return the structured empty fragment-set result;
 never invent tutorial steps.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/persistence-boundary.md

@@ -7,9 +7,9 @@ media-type: text/markdown
 # Persistence boundary composer
 
 Run only for an effective `persistence-boundary` selection. Consume the exact
-`PrimaryResultView` and keep all proposals subordinate to its Node and Result.
+`PrimaryResultView` and keep all proposals subordinate to its article and Result.
 
-Require an evidenced `persistence-binding` fact and primary `content`
+Use the primary article and its regional references to establish a demonstrated persistence boundary. Require primary `content`
 Artifact. Derived `content` may connect the domain operation to repository or
 store, model/schema authority, transaction or consistency boundary, caching,
 migration, failure, and recovery. Separate authoritative schema sources from
@@ -19,3 +19,8 @@ Use `standard` and existing evidence. Do not infer storage semantics from a
 driver dependency or method name. If the binding, required Artifact, or a
 source-backed persistence question is absent, return a valid empty fragment
 set rather than reading outside the workset.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/protocol-boundary.md

@@ -10,13 +10,18 @@ Run only for an effective `protocol-boundary` composer workset and consume its
 exact `PrimaryResultView`. Never discover new scope or claim final Result
 authority.
 
-Require an evidenced `protocol-operation` fact and a primary `contract`
+Use the primary article and its regional references to establish a demonstrated protocol operation. Require primary `contract`
 Artifact. A derived `contract` proposal may connect a stable operation identity
 to transport, request/response or message shapes, provider and consumer,
 errors, compatibility, and authoritative schema evidence. Keep generated
 clients and bindings pointed at their source contract.
 
-Use the existing target Node and `standard` policy. Do not infer operations
-from names or import adjacency. If the required fact/Artifact is missing, the
+Use the existing article target and `standard` policy. Do not infer operations
+from names or import adjacency. If the required source explanation or Artifact is missing, the
 provider/consumer pairing is ambiguous, or the primary contract already
 answers the reader question, return a valid result with `fragments: []`.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.

package/plugins/skills/context-code-indexer/references/composers/public-contract.md

@@ -10,20 +10,20 @@ Run only for an effective `public-contract` composer workset. Consume the
 workset-scoped `PrimaryResultView`; do not inspect a broader repository or
 replace the primary Result.
 
-Require an evidenced `code-symbol` fact and its owning primary `content`
+Use the primary article and its regional references to establish a public declaration and its supported behavior. Require primary `content`
 Artifact. Propose a `contract` Artifact only when the view establishes stable
 consumer identities, entrypoints, behavior, constraints, and evidence. Group
 related exports, commands, routes, or extension points by the public concept a
 consumer uses; do not enumerate incidental symbols.
 
-Every proposal must retain the existing target Node, use the `standard`
+Every proposal must retain the existing article target, use the `standard`
 Artifact policy variant, and cite evidence already present in the view. Return
 only a post-author `derived-artifact-proposal` fragment. If either required
 input is absent or no independent reader question is supported, return the
 normal layer-fragment result with `fragments: []`.
 
-The `code-symbol` kind is the parser-backed fact carrier, not a guarantee that
-an independent contract page is useful. Check its public entrypoints, visibility,
+A public declaration does not guarantee that an independent contract page is
+useful. Check its public entrypoints, visibility,
 types and resolution limits. Do not turn declaration-only information into a
 runtime guarantee, or duplicate an API table already present in the primary page.
 
@@ -33,3 +33,8 @@ derived page; it does not certify that a primary table is correct. Report a
 concrete discrepancy for the existing Review/repair flow, without replacing the
 primary Result or silently changing its generated rows. Stay within this
 Composer's declared result schema and actions.
+
+Use only the supplied primary artifacts and their actual regional references.
+Do not require a primary Fact table, evidence IDs, or graph nodes. Each derived
+output fragment retains at most three real source locations; no reference
+ledger is reconstructed from the full inventory.