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

package/providers/context/skills/run-indexer-lifecycle/SKILL.md

@@ -1,220 +1,43 @@
 ---
 name: context-run-indexer-lifecycle
-description: Continue the sole Context registry-and-Provider indexing route; use only when the workspace Graph selects route.indexer.lifecycle-required.
+description: Continue Context investigation and article production only when selected by the workspace Route.
 metadata:
   agent-graph: path:../../provider.yaml
   agent-graph.graph: workspace
   agent-graph.entry: context
 ---
 
-# Run The Indexer Lifecycle
+# Continue current knowledge work
 
-This Action continues the sole registry-and-Provider indexing route. Use the
-current Indexer subroute for semantic partitioning, structure review, authoring,
-composition, layout, Candidate compilation, and repair. Existing approved
-knowledge is an input to incremental planning, never a parallel authoring path.
+Use the current Route's command, resources and file contract. This outer action
+has no submission of its own. Reuse the user's settled reader purpose and source
+scope; ask only about a missing decision that changes the work, including in
+managed mode. Explain decisions in the user's conversation language.
 
-Read
-the `context.indexer.provider-guide` resource at the exact path in the current Route,
-then follow the root `context` Skill's Indexer instructions and the exact
-structured outcomes returned by `context indexer ...`. Start by forming and
-confirming requirements when `src/indexers.yaml` is absent or stale. When the
-Route returns `configuration`, edit the named project file and re-evaluate;
-do not submit a lifecycle Result or repeatedly run an unconfigured project. Otherwise
-continue the current registry selection, Provider resolution, execution,
-reconciliation, mechanical validation, layout, and Candidate compile subroute. The Indexer
-Graph is the authority for each substep. Never skip directly to compile and
-never synthesize a Provider Result or a default plan.
+Start with authorized code skeletons and document outlines. Read original text
+selectively to decide article topics and writing batches, then more deeply for
+the actual claims being written. Skill guidance is optional assistance with
+discovery and writing, not a version-bound production credential.
 
-A large `complete-current` reply may use `context.action.completion-summary/v1`.
-Read its `result_file` for complete task diagnostics and `next_route.file` for the
-exact next Route. Counts and shortened messages are only a summary; never resubmit
-committed tasks to obtain missing output. If `next_preparation` failed, use its
-recovery command; committed tasks remain saved. For a long submission use a UTF-8
-JSON/YAML file in `.tmp/` with `--input <file>` rather than feeding a long line into
-an interactive PTY. Keep the Route revision and completion command unchanged.
+Submit the lightweight plan, present the work-start report and wait for explicit
+user feedback before writing. Use the report resources selected by the Route;
+unchanged scope does not need another report merely because a batch ends.
 
-After the registered source overview and representative reading, resolve only
-missing reader purpose and substantive scope before planning. Reuse the user's
-explicit request and existing goals; a missing `purpose` alone is not a reason
-to ask. Source-read authorization does not settle purpose, depth or version scope.
-Fully managed execution does not authorize choosing an unclear purpose. Ask and
-wait when these choices remain unresolved, without re-asking explicit decisions.
-Ask at most three questions in one round, without filling unused slots: combine
-reader and task into one question, then clarify substantive scope, then only a
-real tradeoff. Use the current conversation language and a shared human/Agent
-knowledge package by default; do not ask about reading audience or language.
-Recommend organization and templates, and test that recommendation with the
-first small delivery instead of asking abstract classification questions.
-Save the short conclusion as `purpose` in the existing requirement, with scopes
-and exclusions in their existing fields. When an agreed exclusion maps to exact
-repository files or directories, set `exclusions[].paths` to those repository-relative
-paths and retain its `scope` and `reason`. No wildcards are accepted. Context filters
-these before Parser/Partition work; an omitted `paths` means the whole stated scope.
-Do not translate a vague age or naming clue into an exclusion. A shared Indexer
-retains files still needed by another applicable requirement. Confirm the scope
-before bulk work: unnecessary inputs consume tokens and slow useful delivery. Do not store a questionnaire or add
-another confirmation after an explicit answer. Silence is not approval.
-During the authorized source overview and representative reading, actively assess
-which regions serve the reader's task, which only support it, and which appear
-unnecessary. Check available entrypoints, maintained guidance and lifecycle or
-version notices; deprecation is one possible scope concern, not the sole trigger.
-Names, age, file counts and generated status are clues, not exclusion rules.
-Propose concrete boundaries with reasons. Explain a material tradeoff once:
-including large irrelevant regions increases token use and processing time and
-can dilute useful knowledge with repetitive or conflicting pages. Do not claim
-measured savings or reduce requested coverage merely to make the run faster.
-Resolve meaningful unanswered scope choices with the user before dependent bulk
-work, including in managed mode, unless the user explicitly delegated that scope
-choice. General managed/no-review permission alone is not that delegation. Reuse
-an applicable inclusion/exclusion decision in later structure previews; do not
-turn the same decision into another human gate. Ask only about material new
-findings and describe the wait as a scope question, not a CLI failure. Carry out settled choices within existing
-authorization without asking per file. Use available counts with their unit and
-coverage, not an exhaustive scan just to obtain a number. If the relevant boundary
-is not yet checked, say what remains to inspect rather than declaring it absent.
-Preserve decisions in existing requirements and the report when applicable.
-Revisit only material new findings on continuation; do not restart accepted work
-or delete existing knowledge to implement a proposed scope reduction.
-Read authorized captured sources before raising material gaps; only unresolved
-core questions requiring new sources or human knowledge need another question.
+Write in the issued Agent directories and submit completed subsets using the
+returned file contract. Reuse available shared materials and follow the next
+directory or recovery command; do not query full status between ready batches.
+Only receipts establish acceptance. Distinguish drafted, accepted, reviewed and
+built articles when reporting progress; no slice count proves whole-task completion.
 
-After those decisions, use the Route's `procedure.work-start-report` and
-`template.work-start-report` Resources for substantial new work or material
-choices worth preserving. Write the readable report at `.tmp/work-start-report.md`
-before semantic planning, using the existing requirement reference and actual
-settings. Lightweight work keeps a short conversational summary. This is a scratch
-document written with the Host file tool, not another Gate or Action payload;
-follow the procedure's first-report reading invitation and conversational pause,
-including in managed mode unless the user explicitly waived that pause. Then
-continue the same Route; do not add a report approval state or polling loop.
-Reuse it on continuation rather than generating a report for every batch.
+Use multiple workers only when the current host supports them and the invocation
+declares that capability. The coordinator owns shared CLI writes and each worker
+uses its assigned draft directory. Keep all process state in `.tmp`.
 
-When the current subroute is a Gate, follow `gate.resolution_action` rather
-than looking for a top-level `action`. Read its Skill and output schema, use its
-Route input, and submit the resulting value through the Route completion
-command. The Indexer Graph owns the Gate identity, authority, delegation and
-resolution Action; do not replace them with an inferred command or handler.
+For explicitly requested early delivery, use `context run --deliver --format json`
+and follow Review, close and build. A successful delivery resumes remaining work;
+`context run --resume-writing --format json` cancels the pause without discarding
+drafts. Do not automatically request delivery after every subset submission.
 
-Stop on the first Host permission, non-delegatable Gate, validation failure, or
-human decision. Once current Candidates have been compiled, return control to
-`context status --format json`; the workspace Graph will select Knowledge
-Review. This outer Action has no payload of its own and must never be submitted
-through `complete-current`. Context projects it to the one current Indexer
-subroute; follow that Route's command and output schema exactly. If project
-configuration was edited, re-run `context status --format json` to obtain the
-new revision instead of inventing a lifecycle continuation result.
-
-## Readable delivery batches
-
-Planning can pause at a settled ready-theme wave while unfinished Partition
-entries remain saved. After the wave's structure/content Review, close and build,
-resume the fresh Route back to planning. Never call the workspace complete from
-one wave's Author or build count. The `planning` progress block includes the
-suspended remainder. Later material may improve an already delivered subject;
-retain its identity and approved prose instead of treating it as a new page.
-
-
-Follow the current Context Route through Review, close, and build as soon as a
-page delivery is ready. Automatic theme waves grow as 3, 7, 10, 20, 30, 30,
-then 50. A fully planned scope with fewer than 10 themes stays together. A final
-remainder may be smaller. Each wave completes Review/close/build before the
-next; repairs or build failures hold the next wave at the current step.
-Theme targets are not guaranteed output-page counts. For an explicit user
-preference, `context run --delivery-size 20 --format json` sets future waves
-for this task; `--delivery-size auto` restores automatic sizing. Existing active
-waves remain intact. Fixed sizes accept 1–50.
-Count pages, not Author calls or worksets. An accepted multi-page Result can
-span deliveries without resubmission. A successful package build is a delivery
-checkpoint, not evidence that every Author task is complete: evaluate the Route
-again and continue pending work. Never manually clear accepted runtime state.
-
-If the user explicitly asks to inspect the current work earlier, run
-`context run --deliver --format json`, then follow its current Route. This asks
-for an earlier checkpoint; it does not authorize content or bypass Review.
-The Author Route exposes this user-requested alternative under `delivery`,
-including accepted pages waiting and the actual waiting condition. It is not an
-automatic command to run on every batch. If Author work is already running,
-finish that current batch; the next lifecycle advance selects complete accepted
-pages before starting another batch. Follow any required Composer, Review,
-close and build steps, then resume the remaining Author work with its new Route.
-`delivery_boundary: false` only means no explicit reader-task boundary; it does
-not disable the automatic delivery-wave checkpoint. Never predict all tasks must
-finish from that flag. A user asking when pages will appear needs this
-explanation; asking to see them now authorizes the early-delivery request.
-Ordinary mode retains the current batch's approval Gate. Existing managed
-approval covers delegatable batch Gates without another mode questionnaire.
-A failed build retains the same current pages; fix the reported build problem
-and rerun the returned command before authoring another batch.
-
-At workflow completion, return to the Context entry and reconcile the user's
-remaining requests with delivered pages and registered maintenance targets.
-Composer tasks are derivation checks, not a list of queued page revisions.
-Empty proposals may finish an already delivered scope without another Review or
-build. Continue authorized, unregistered revisions through the normal entry;
-do not resubmit accepted Composer tasks or treat an empty queue as proof that
-every conversational request was completed.
-
-## Continue the current handoff
-
-An `agent-required` handoff asks you to do the next task in this authorized
-conversation. Read the current Route, perform its task and follow its returned
-`next_route.file`; do not end after a successful small batch just because the
-CLI returned. Stop for a real missing decision, external blocker, completion or
-a Host limit, and state the exact continuation point. Reuse material whose
-content digest and source scope are unchanged and which is still available in
-your context; a new Route revision alone does not require reading it all again.
-
-`batch_budget` describes a transport batch, not a delivery or approval boundary.
-For Partition its input-byte scope excludes optional detail files and independent
-source exploration. It is not an actual token bill or the total eventual reading
-cost. Read linked details where the compact overview cannot resolve the task.
-The input bytes include shared instructions and deduplicated material; they are
-not tokens. A task cap, input/output budget, View budget or Provider boundary can
-limit the batch without indicating an error. Keep every task's authorized input
-and outcome complete.
-
-For generated APIs, `table-complete` permits omitting a declaration already
-expressed by the table, `component-wrapper` omits only the redundant wrapper,
-and `not-provided` means these facts contain no separate declaration. None
-proves that a page meets its purpose. Verify the actual changed rows and sources;
-resolve an explicit request for a complete declaration with the user instead
-of repeatedly repairing identical inputs or silently changing that request.
-
-## 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 uses `slice`. 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.
-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.
-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.
+Continue authorized work until its actual delivery boundary or a real missing
+decision, source, permission or host limit. After cleanup, a new request starts
+fresh production from formal articles and sources, not an old process ledger.

package/providers/context/skills/work-production-stage/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: work-production-stage
+description: Investigate or write within the current Context production directory, or present its work-start report, when selected by the workflow Route.
+---
+
+Use only the current Route's stage and authorized materials. Explain decisions
+in the user's conversation language.
+
+For investigation, use the supplied directory and its submission schema. Start
+with code skeletons and document outlines; selectively read original material
+where needed to decide reader topics, source grouping and writing batches.
+Indexer guidance discovers a skeleton, not a mandatory deep parse or a ledger
+of every symbol. Declare relevant available skills and record planned uses;
+do not collect skill hashes, versions or article ownership credentials.
+Submit the plan before presenting the work-start report. Planning does not
+authorize writing or approve the report.
+
+At the work-start-report Gate, read the planned topics and selected report
+resources, present the proposal, and wait for explicit user feedback. Managed
+execution does not replace this confirmation. Submit approval only after that
+feedback; requested changes belong in the plan before writing.
+
+For writing, read the stage entry and issued batch directories. Choose how to
+read and write within those tasks. Use child Agents only when the current host
+supports them and the call explicitly enables multi-agent scheduling; otherwise
+finish the one issued batch. Workers edit their assigned drafts, and one
+coordinator submits completed task subsets.
+
+Follow the file contract selected by the Route. Keep long content in the Agent
+temporary directory, not CLI arguments. Use the returned task handles unchanged.
+Follow the returned next directory or preparation-retry command after submission;
+do not repeat accepted tasks or query full workspace status between ready batches.
+
+Drafts, candidate receipts, skill choices and process state stay in `.tmp`.
+A cleared temporary directory means a new production run, not recovery from Git.

package/indexers/bundles/context-code-indexer/templates/article-programs/adapter-integration-c01-page.md

@@ -1,232 +0,0 @@
----
-{
-  "protocol": "context.indexer.template/v1",
-  "template_id": "adapter-integration-c01-page",
-  "profile": "adapter-integration",
-  "reader_goal": "integrate-capability",
-  "applicability": {
-    "artifact_policy_variants": [
-      "compact",
-      "standard",
-      "expanded"
-    ],
-    "condition_refs": []
-  },
-  "variables": [
-    {
-      "id": "scope",
-      "type": "string",
-      "content_layer": "semantic-prose",
-      "required": false,
-      "evidence_required": true
-    },
-    {
-      "id": "capabilities",
-      "type": "string",
-      "content_layer": "semantic-prose",
-      "required": false,
-      "evidence_required": true
-    },
-    {
-      "id": "dependencies",
-      "type": "string",
-      "content_layer": "semantic-prose",
-      "required": false,
-      "evidence_required": true
-    },
-    {
-      "id": "index",
-      "type": "string",
-      "content_layer": "semantic-prose",
-      "required": false,
-      "evidence_required": true
-    },
-    {
-      "id": "tasks",
-      "type": "string",
-      "content_layer": "semantic-prose",
-      "required": false,
-      "evidence_required": true
-    },
-    {
-      "id": "sources",
-      "type": "string",
-      "content_layer": "semantic-prose",
-      "required": false,
-      "evidence_required": true
-    }
-  ],
-  "deterministic_blocks": [],
-  "sections": [
-    {
-      "section_key": "scope",
-      "presence": "optional",
-      "question_ref": "question:c01-scope",
-      "reader_goal": "integrate-capability",
-      "variable_ids": [
-        "scope"
-      ],
-      "deterministic_block_ids": [],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
-      "on_missing": "omit",
-      "deletion_condition": "Omit when not applicable or no supported value is supplied."
-    },
-    {
-      "section_key": "capabilities",
-      "presence": "optional",
-      "question_ref": "question:c01-capabilities",
-      "reader_goal": "integrate-capability",
-      "variable_ids": [
-        "capabilities"
-      ],
-      "deterministic_block_ids": [],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
-      "on_missing": "omit",
-      "deletion_condition": "Omit when not applicable or no supported value is supplied."
-    },
-    {
-      "section_key": "dependencies",
-      "presence": "optional",
-      "question_ref": "question:c01-dependencies",
-      "reader_goal": "integrate-capability",
-      "variable_ids": [
-        "dependencies"
-      ],
-      "deterministic_block_ids": [],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
-      "on_missing": "omit",
-      "deletion_condition": "Omit when not applicable or no supported value is supplied."
-    },
-    {
-      "section_key": "index",
-      "presence": "optional",
-      "question_ref": "question:c01-index",
-      "reader_goal": "integrate-capability",
-      "variable_ids": [
-        "index"
-      ],
-      "deterministic_block_ids": [],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
-      "on_missing": "omit",
-      "deletion_condition": "Omit when not applicable or no supported value is supplied."
-    },
-    {
-      "section_key": "tasks",
-      "presence": "optional",
-      "question_ref": "question:c01-tasks",
-      "reader_goal": "integrate-capability",
-      "variable_ids": [
-        "tasks"
-      ],
-      "deterministic_block_ids": [],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
-      "on_missing": "omit",
-      "deletion_condition": "Omit when not applicable or no supported value is supplied."
-    },
-    {
-      "section_key": "sources",
-      "presence": "optional",
-      "question_ref": "question:c01-sources",
-      "reader_goal": "integrate-capability",
-      "variable_ids": [
-        "sources"
-      ],
-      "deterministic_block_ids": [],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
-      "on_missing": "omit",
-      "deletion_condition": "Omit when not applicable or no supported value is supplied."
-    }
-  ],
-  "page_policy": {
-    "split_suggestion": "Split by independently useful reader task when supported; preserve stable article identities.",
-    "semantic_boundaries": [
-      "reader-task",
-      "source-boundary"
-    ],
-    "keep_single_page_conditions": [
-      "one-reader-subject"
-    ]
-  },
-  "anonymous_section_examples": [
-    "A source-backed explanation that names an entry and the next investigation step."
-  ],
-  "anti_examples": [
-    "Invented relationships or current runtime values inferred from names alone."
-  ],
-  "forbidden_outputs": [
-    "Unresolved internal identifiers in reader-facing prose."
-  ],
-  "maximum_rendered_bytes": 1048576
-}
----
-<!-- context:indexer-section scope -->
-## 定位与边界
-
-{{variable:scope}}
-<!-- /context:indexer-section -->
-
-<!-- context:indexer-section capabilities -->
-## 核心能力
-
-{{variable:capabilities}}
-<!-- /context:indexer-section -->
-
-<!-- context:indexer-section dependencies -->
-## 技术与依赖摘要
-
-{{variable:dependencies}}
-<!-- /context:indexer-section -->
-
-<!-- context:indexer-section index -->
-## 知识索引
-
-{{variable:index}}
-<!-- /context:indexer-section -->
-
-<!-- context:indexer-section tasks -->
-## 任务导航
-
-{{variable:tasks}}
-<!-- /context:indexer-section -->
-
-<!-- context:indexer-section sources -->
-## 来源与适用版本
-
-{{variable:sources}}
-<!-- /context:indexer-section -->