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

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

@@ -1,229 +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
 
-Before dependent bulk work, follow
-[the shared homogeneous-source review](../../resources/procedures/homogeneous-source-review.md).
-Reuse explicit group decisions; when a newly observed group needs user choice,
-present its concrete scope and pause before parsing or submitting dependent work.
+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.
 
+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.
 
-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.
+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.
 
-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.
+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.
 
-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.
+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`.
 
-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.
+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.
 
-The first production task in a new workspace already has a work-start report from
-the source-boundary Gate. Reuse and update that report with the confirmed
-requirements, actual Provider choices and later task inventory before semantic
-planning. Do not replace it or create another report per Indexer or batch. For an
-existing workspace task that legitimately had no first-task report, follow the
-Route's `procedure.work-start-report` and `template.work-start-report` when the
-task is substantial or preserves material choices. The source-boundary Gate owns
-the initial user feedback; do not add a second report approval state here.
-
-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.
-
-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 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.
+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-markdown-indexer/tests/fixtures/migration-equivalence.json

@@ -1,186 +0,0 @@
-{
-  "protocol": "context.indexer.markdown-migration-equivalence-fixture-set/v1",
-  "anonymized": true,
-  "cases": [
-    {
-      "id": "evidence-first",
-      "rule_id": "evidence-first",
-      "authority": "community-instructions",
-      "source_shape": "A captured page has an operations-looking path but its body is a product acceptance specification.",
-      "expected_decision": "classify-from-body-authority-and-reader-task",
-      "forbidden_decision": "classify-from-path",
-      "recovery": "Read the complete authorized evidence before returning a Section intent."
-    },
-    {
-      "id": "complete-evidence-read",
-      "rule_id": "complete-evidence-read",
-      "authority": "community-instructions",
-      "source_shape": "A long page preview shows only headings while the required evidence view still has unread pages.",
-      "expected_decision": "continue-current-evidence-read",
-      "forbidden_decision": "decide-from-heading-preview",
-      "recovery": "Follow the current workset evidence continuation before authoring."
-    },
-    {
-      "id": "mixed-section-intents",
-      "rule_id": "mixed-section-intents",
-      "authority": "community-instructions",
-      "source_shape": "One document contains product behavior, technical design, and a recovery procedure.",
-      "expected_decision": "classify-each-section",
-      "forbidden_decision": "force-one-document-classification",
-      "recovery": "Split along continuous reader-task boundaries and return registered intents."
-    },
-    {
-      "id": "reuse-exact-subject",
-      "rule_id": "reuse-exact-subject",
-      "authority": "community-instructions",
-      "source_shape": "The target-resolution view contains an exact current subject with matching evidence.",
-      "expected_decision": "reuse-existing",
-      "forbidden_decision": "create-title-alias",
-      "recovery": "Use the supplied target identity and leave identity derivation to Context."
-    },
-    {
-      "id": "independent-subject",
-      "rule_id": "independent-subject",
-      "authority": "community-instructions",
-      "source_shape": "A separately named component has its own contract, lifecycle, and standalone reader questions.",
-      "expected_decision": "create-independent",
-      "forbidden_decision": "merge-into-unrelated-parent",
-      "recovery": "Bind the independent decision to current evidence and a permitted SubjectKey schema."
-    },
-    {
-      "id": "local-heading-stays-section",
-      "rule_id": "local-heading-stays-section",
-      "authority": "community-instructions",
-      "source_shape": "A local heading contains one warning that only makes sense inside the parent guide.",
-      "expected_decision": "retain-section-group",
-      "forbidden_decision": "create-thin-subject",
-      "recovery": "Keep the warning as a source-backed Section under the owning Artifact."
-    },
-    {
-      "id": "navigation-only",
-      "rule_id": "navigation-only",
-      "authority": "community-instructions",
-      "source_shape": "A page contains labels and unresolved links but no citable reader content.",
-      "expected_decision": "request-material",
-      "forbidden_decision": "publish-empty-artifact",
-      "recovery": "Return the registered missing-material or unsupported disposition."
-    },
-    {
-      "id": "density-only-guides-reading",
-      "rule_id": "density-only-guides-reading",
-      "authority": "community-instructions",
-      "source_shape": "A fragmented note contains many short independent claims.",
-      "expected_decision": "use-micro-reading",
-      "forbidden_decision": "infer-quality-from-density",
-      "recovery": "Keep evidence windows narrow, then apply the normal semantic gates."
-    },
-    {
-      "id": "duplicate-same-boundary",
-      "rule_id": "duplicate-same-boundary",
-      "authority": "community-instructions",
-      "source_shape": "Two paragraphs repeat the same claim for the same reader task and authority.",
-      "expected_decision": "collapse-duplicate",
-      "forbidden_decision": "publish-repeated-sections",
-      "recovery": "Retain one canonical statement with its evidence boundary."
-    },
-    {
-      "id": "conflicting-evidence",
-      "rule_id": "conflicting-evidence",
-      "authority": "community-instructions",
-      "source_shape": "Two current sources disagree and the workset supplies no precedence.",
-      "expected_decision": "keep-unresolved",
-      "forbidden_decision": "choose-by-file-order",
-      "recovery": "Return a material question or supported diagnostic instead of guessing."
-    },
-    {
-      "id": "source-backed-relation",
-      "rule_id": "source-backed-relation",
-      "authority": "community-instructions",
-      "source_shape": "A cited Section explicitly states that one authorized component consumes another component's output.",
-      "expected_decision": "emit-owned-cited-claim",
-      "forbidden_decision": "emit-endpoint-only-relation",
-      "recovery": "Keep the claim only under the Section carrying relation evidence."
-    },
-    {
-      "id": "source-authored-uncertainty",
-      "rule_id": "source-authored-uncertainty",
-      "authority": "community-instructions",
-      "source_shape": "The source explicitly describes a possible cause, while the structured schema has no confidence field.",
-      "expected_decision": "preserve-uncertainty-in-prose",
-      "forbidden_decision": "invent-confidence-field",
-      "recovery": "Keep Agent uncertainty unresolved and preserve only source-authored uncertainty."
-    },
-    {
-      "id": "canonical-layout-identity",
-      "rule_id": "canonical-layout-identity",
-      "authority": "context-layout",
-      "source_shape": "An accepted Result carries a current SubjectKey and Section projection intents.",
-      "expected_decision": "derive-node-artifact-view-section-and-path",
-      "forbidden_decision": "accept-hand-authored-path",
-      "recovery": "Recompute the proposal from the current Result and contract."
-    },
-    {
-      "id": "layout-collision",
-      "rule_id": "layout-collision",
-      "authority": "context-layout",
-      "source_shape": "Two proposals claim the same Node, Artifact, Section, or output path.",
-      "expected_decision": "reject-collision",
-      "forbidden_decision": "resolve-with-alias",
-      "recovery": "Return to current subject resolution instead of mutating a path."
-    },
-    {
-      "id": "destructive-layout-change",
-      "rule_id": "destructive-layout-change",
-      "authority": "context-layout",
-      "source_shape": "A current Artifact would be removed or moved after a new Result.",
-      "expected_decision": "require-confirm-layout-change",
-      "forbidden_decision": "apply-destructive-change-silently",
-      "recovery": "Bind one human confirmation to the exact base and target digests."
-    },
-    {
-      "id": "eligible-omission",
-      "rule_id": "eligible-omission",
-      "authority": "community-instructions",
-      "source_shape": "A Section is only an unanswered placeholder and the analyzer supplies an eligible omission reason.",
-      "expected_decision": "omit-with-exact-reason",
-      "forbidden_decision": "publish-placeholder",
-      "recovery": "Use the exact eligible omission reason and preserve lifecycle audit in Context."
-    },
-    {
-      "id": "protected-knowledge-retention",
-      "rule_id": "protected-knowledge-retention",
-      "authority": "community-instructions",
-      "source_shape": "A question has an evidence-backed answer and a deprecation names its replacement.",
-      "expected_decision": "retain-knowledge",
-      "forbidden_decision": "omit-by-label",
-      "recovery": "Repair or reshape without removing the answer or replacement."
-    },
-    {
-      "id": "missing-input",
-      "rule_id": "missing-input",
-      "authority": "community-instructions",
-      "source_shape": "A Section contains an ambiguous owner or link purpose that current evidence cannot recover.",
-      "expected_decision": "request-input",
-      "forbidden_decision": "keep-to-avoid-pause",
-      "recovery": "Ask one concise batched question after completing independent safe work."
-    },
-    {
-      "id": "stale-recovery",
-      "rule_id": "stale-recovery",
-      "authority": "context-layout",
-      "source_shape": "The workset, profile contract, or source digest changes before layout acceptance.",
-      "expected_decision": "reject-stale-and-recompute",
-      "forbidden_decision": "patch-digest-or-path",
-      "recovery": "Resume from the fresh Context route and recompute the bound Result and layout."
-    },
-    {
-      "id": "three-attempt-guidance",
-      "rule_id": "three-attempt-guidance",
-      "authority": "context-revision",
-      "source_shape": "The same current quality problem survives three accepted revision attempts while other Sections pass.",
-      "expected_decision": "request-aggregated-guidance",
-      "forbidden_decision": "restart-passing-sections",
-      "recovery": "Ask for content organization, source fidelity, or missing material once."
-    }
-  ]
-}