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

package/providers/context/skills/prepare-indexer-customization-project/SKILL.md

@@ -1,31 +0,0 @@
----
-name: prepare-indexer-customization-project
-description: Resolve the exact validated customization selection and stage its CAS-bound project proposal.
----
-
-# Prepare Indexer customization project
-
-Read
-the `context.indexer.provider-guide` resource at the exact path in the current Route
-before staging a project proposal. If validation reports an invalid local
-resource or upstream drift, preserve the exact
-`indexer-customization-invalid`/`indexer-customization-upstream-changed`
-diagnostic and return to reconciliation; do not silently drop or overwrite the
-affected override.
-
-Consume only the current `context.indexer.customization-validation-result/v1`.
-
-1. Pass `selection_proposal_input` to `context indexer validate-indexer-selection-proposal`.
-2. Resolve every emitted Provider request through `context indexer resolve-indexer-providers`; never scan a
-   plugin cache or substitute another version. Stage each resolved Bundle with
-   `context indexer stage-indexer-provider-bundle`.
-3. Build `context.indexer.customization-project-preparation-input/v1` with the exact validation digest,
-   static report, resolved/staged Bundle inputs, and current CLI operator/profile contracts. Run
-   `context indexer prepare-indexer-customization-project`.
-4. If the result is `program-authorization-required`, stop at the independent program-execution authority.
-   Do not invent the authority receipt and do not apply any source file.
-5. If the result is `project-confirmation-required`, preserve the returned proposal digest and staging
-   validation unchanged for the confirmation/apply route.
-
-Never copy Provider files into the project, widen requirement scope, add dependency intents, or bypass the
-content-addressed customization stage.

package/providers/context/skills/propose-indexer-customization/SKILL.md

@@ -1,40 +0,0 @@
----
-name: context-propose-indexer-customization
-description: Propose one minimal dependency-free extend customization only after the Context CLI has emitted a final capability-gap proof.
-metadata:
-  agent-graph: path:../../provider.yaml
-  agent-graph.graph: indexer
-  agent-graph.entry: provider-selection
----
-
-# Propose Indexer Customization
-
-Read
-the `context.indexer.provider-guide` resource at the exact path in the current Route
-and follow its six-level ladder. This Action handles the
-`indexer-customization-required` outcome only; it must not reinterpret
-`indexer-customization-invalid` or
-`indexer-customization-upstream-changed` as permission to replace upstream
-resources.
-
-Use this Action only when its exact input is a
-`context.indexer.provider-route-report/v1` whose route outcome is
-`indexer-customization-required` and whose `capability_gap_proof` is present. Copy the
-exact route input and report into `capability_gap`, and copy the proof's
-`gap_digest` into the draft. Close every smaller ladder step in order with its
-CLI/provider evidence digest. Never infer a gap from prose, a Provider manifest,
-or an earlier route attempt.
-
-Propose the smallest `extend` change that can close only the reported owner
-cells and affected scopes. First close Provider-only and config levels with the
-route evidence; then prefer appended instructions, one exact template
-override, and a fixed local program extension in that order. Include only files
-under `src/indexer/<indexer-id>/` and preserve the required Provider origin
-comment. Do not create a `replace` draft, widen source scope, weaken the
-requirement, or add dependency intents.
-
-The output is an untrusted draft for the next CLI validation Action. Do not
-write project source, install dependencies, execute local code, or claim that
-the customization is applied. If no dependency-free `extend` can close the
-exact gap, report the limitation and stop for human/dependency/program
-authorization instead of emitting a conforming-looking draft.

package/providers/context/skills/resolve-current-indexer-provider/SKILL.md

@@ -1,20 +0,0 @@
----
-name: context-resolve-current-indexer-provider
-description: Resolve the exact Host-backed Provider request selected by the current Context workflow Route.
-metadata:
-  agent-graph: path:../../provider.yaml
-  agent-graph.graph: indexer
-  agent-graph.entry: current-provider-resolution
----
-
-# Resolve the current Indexer Provider
-
-Use only the Host Action Resource required by the current Route. Materialize that Resource once and
-return one `context.indexer.current-action-input/v2` value with `stage` set to
-`provider-resolution` and `result` set to the complete Host Action result. If the Host also returns
-the managed output named by the Route, include it as `managed_output` without changing its ref,
-digest, or value.
-
-Do not discover another Provider, substitute a version, read Provider files directly, or recreate
-the Host result. Submit the value to the Route's only `complete-current` command and then follow the
-newly returned Route.

package/providers/context/skills/run-indexer-post-author-composer/SKILL.md

@@ -1,122 +0,0 @@
----
-name: context-run-indexer-post-author-composer
-description: Execute one bounded batch of CLI-authorized post-author composer tasks without changing primary facts, identity, scope, or composer selection.
-metadata:
-  agent-graph: path:../../provider.yaml
-  agent-graph.graph: indexer
-  agent-graph.entry: post-author-composer-step
----
-
-# Run a post-author composer batch
-
-Read both required Route resources before acting:
-
-- `resolved-indexer-instructions` defines the selected Composer's job;
-- each `authorized-indexer-workset-view/task-NNN` is one complete, bounded PrimaryResult View.
-
-Use only the target aliases and source aliases exposed by that View and the current Route.
-The reading shows full fact values and page bodies; evidence bindings and runtime
-receipts remain in CLI storage. `fact:N` and `artifact:N` refer only to this task's
-View. Declared missing input kinds are settled by the CLI as empty results before
-delegation; whether available material supports a useful derived page is your decision.
-Do not discover another Skill or Composer, scan project files outside the View, change a
-SubjectKey, rewrite the primary Result, or widen the target set.
-
-Return exactly one result for every task key in the Action input. Keep task results
-independent: one empty or failed result must not replace another task's proposal.
-
-Return only the minimal semantic JSON accepted by the current Route:
-
-```json
-{
-  "stage": "post-author",
-  "results": [
-    {
-      "task_key": "task-001",
-      "result": {
-        "stage": "post-author",
-        "outcome": "complete",
-        "proposals": [
-          {
-            "target": "target:1",
-            "artifact_kind": "content",
-            "title": "Reader-facing title",
-            "summary": "Why this derived page is useful",
-            "sections": [
-              {
-                "key": "overview",
-                "heading": "Overview",
-                "markdown": "Reader-facing content",
-                "source_refs": ["fact:1"]
-              }
-            ]
-          }
-        ],
-        "diagnostics": []
-      }
-    }
-  ]
-}
-```
-
-If a task needs no derived Artifact, return `outcome: "complete"` with an empty
-`proposals` array for that task. If one bounded input cannot be processed, return
-`outcome: "failed"` with at least one diagnostic for that task and still return the
-other task results. Context expands aliases, validates evidence and policy, creates
-internal fragments and digests, then resumes the same production state machine.
-
-An accepted empty proposal does not regenerate an approved page. Use the returned
-workflow summary and registered maintenance targets to distinguish production
-completion from outstanding user requests; Composer task names are not a revision
-queue. If the Graph is complete, return to the Context entry to handle any
-remaining authorized requests rather than declaring a missing Review/build.
-
-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.
-
-## 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.