Release Context 0.7.10

package.json

@@ -1,6 +1,6 @@
 {
   "name": "context",
-  "version": "0.7.10-alpha.2",
+  "version": "0.7.10",
   "packageManager": "bun@1.3.9",
   "repository": {
     "type": "git",

packages/context-cli/context-workflow/provider.yaml

@@ -1,6 +1,6 @@
 schema: agent-graph.provider.v1
 id: c4a/context
-version: 0.7.10-alpha.2
+version: 0.7.10
 name: Context workflow
 description: Internal work contract for Context knowledge workspaces.
 graphs:

packages/context-cli/context-workflow/resources/dialogue/code-extraction.md

@@ -7,8 +7,8 @@ Explain the flow in user terms:
 
 1. confirm the repository or module boundary;
 2. confirm the reader questions and visible knowledge scope;
-3. select the smallest applicable Provider profile;
-4. let the Provider choose its parsers and build semantic subjects;
+3. investigate the skeleton with relevant skills and propose reader topics;
+4. confirm the work-start report, then read and write the issued tasks;
 5. show readable Candidate pages for approval.
 
 Do not ask the user to choose internal parser calls, evidence IDs, digest
@@ -17,10 +17,9 @@ required technology is unsupported or executable customization needs approval.
 
 One source file or symbol is not automatically one knowledge page. Prefer
 stable capabilities, contracts, flows, and components as subjects. A Provider
-may use deterministic symbol, route, dependency, or protocol facts internally,
+may use selected symbol, route, dependency, or protocol facts internally,
 but Review should show the reader-facing result and useful source paths.
 
 When coverage is incomplete, report the missing reader question or source
-boundary. Do not create a project-local parallel extraction phase. Extend or
-configure the selected Provider through the declared customization ladder.
-
+boundary in the current plan. Use task.md, sources.md and the current submission
+schema; do not seek a profile registration or a separate extraction phase.

packages/context-cli/context-workflow/resources/manuals/guides/indexer-provider-and-customization.md

@@ -34,7 +34,6 @@ production assignments. For example, replace the source and goals with the
 user's actual scope:
 
 ```yaml
-protocol: context.indexer.registry/v1
 requirements:
   - id: integration-guide
     purpose: Help application developers understand and integrate the system.
@@ -47,7 +46,6 @@ requirements:
     evidence_source_scope:
       targets:
         - source_ref: repo:sample
-indexers: []
 ```
 
 Use registered source identities, not guessed paths or URLs. Keep any confirmed

packages/context-cli/context-workflow/resources/manuals/guides/knowledge-updates.md

@@ -22,6 +22,22 @@ and continues through Review and delivery. Expression-only changes need no
 source capture or Parser. Preserve prior confirmed contributions; distinguish
 actual behavior, a confirmed decision, and a proposal that is not implemented.
 
+## Keep planning local to the change
+
+For one or two documents or a clearly bounded module, retain the useful planning
+decision: add or revise which articles, and place them where readers expect them.
+Do not expand this into a whole-workspace taxonomy, full navigation redesign or
+multi-wave plan. Read related existing topics first and expand only as needed.
+One module can contain several topics; scope and ambiguity, not source count,
+determine how much investigation is useful.
+
+Reuse an approved stage's plan for in-scope additions through its existing amendment
+route. Keep completed work and unrelated pending investigation intact. If article
+targets are already decided before approval, the preparation route supports a
+known-task input to combine preparation and task creation. It still prepares
+navigation and retains report confirmation; it is not a bypass for new source
+authorization. Planning depth is an Agent judgment, not an additional CLI gate.
+
 ## First-task intake budget
 
 Before registration and capture, the Agent uses the user's task instructions and
@@ -62,7 +78,14 @@ progress under `.tmp/` never causes a version increase.
 Version recording runs at completed-scope delivery after Review, Close and package
 configuration/template approval, before the final build. The record response
 returns the next workspace Route, so no extra status call is needed. Build retries
-reuse the recorded version when formal content is unchanged. Intermediate batches
+reuse the recorded version when formal content is unchanged. If build preparation
+or rendering fails and formal corrections are needed, `version inspect` returns
+`reusable_version` for the current entry only while it has no successful build or
+publication receipt. Submit that same version with the complete iteration's title,
+changes and triggers, including the repair; this replaces the pending changelog
+entry rather than appending another version. Do not submit only the repair and
+lose the original delivery description. Once built or published, the version is
+sealed and further formal changes require an increase. Intermediate batches
 do not each receive a version.
 
 The workspace AGENTS.md and version-writing instructions require each entry's
@@ -91,7 +114,10 @@ actor:
 ```
 
 `actor` is optional; omit it to use local Git `user.name` when configured. Use a
-Lark display name only when explicitly known from the conversation. Trigger kinds
+Lark display name only when explicitly known from the conversation. Amending an
+unbuilt entry preserves its actor unless a replacement is explicitly supplied.
+If neither the conversation nor Git identifies the user, omit the actor and
+mention the missing identity in the delivery summary; never guess it. Trigger kinds
 are `initial`, `note`, `sessions`, `mr`, `module`, `document`, `navigation`,
 `repair`, `dist`, and `other`. Agent-written fields describe the actual diff and
 conversation; they must not expose credentials, raw transcripts or private IDs.

packages/context-cli/context-workflow/resources/manuals/guides/workspace-prepare.md

@@ -42,6 +42,23 @@ reports, unique material, unknown files and modified checkouts unless their
 specific loss is authorized. Do not delete locks, transaction records or active
 tool directories. Empty task directories can remain.
 
+Prefer cleanup after successful delivery, not immediately after close: version
+recording, build and retries may still need the current task. Completed production
+drafts and Review state are removed by delivery cleanup. Do not invoke
+`task resume` merely to make a completed workspace advance; it starts a new task
+and requires an actual new user request.
+
+Keep repository checkouts referenced by registered sources, including fixed
+commits: removing them can force a costly clone before the next update. Keep
+pending telemetry and source-region baselines; losing the latter reduces the
+ability to distinguish relocated text from changed text. Debug and historical
+views may be archived or removed after diagnosis when no operation is active,
+but unknown Agent files are not automatically disposable.
+
+After all scratch state is lost, an existing build receipt defaults the workspace
+to waiting for an explicit new task. This does not restore lost drafts or prove
+sources and outputs are current. Use the recovery checks below before resuming.
+
 ## Restore usable sources
 
 For repositories, run `context source recovery-plan --format json` and read

packages/context-cli/context-workflow/resources/manuals/reference/project-api.md

@@ -10,8 +10,8 @@ The project has two durable declarations with separate responsibilities:
 
 - `src/index.ts`: source references, document capture, custom non-knowledge
   orchestration, and package outputs.
-- `src/indexers.yaml`: knowledge requirements, Provider selection, target/read
-  scopes, profiles, and Provider customization.
+- `src/indexers.yaml`: long-term reader requirements, authorized target/supporting
+  sources and confirmed exclusions. Skill choices belong to the temporary plan.
 
 Do not describe the same knowledge transformation in both files.
 
@@ -59,6 +59,19 @@ and [knowledge updates](../guides/knowledge-updates.md).
 
 ## Capture phases
 
+For ordinary acquisition, add `--configure` to `context source add repo`, `file`,
+`lark` or `batch`. The command registers the selected inputs and generates explicit
+source references and default document capture phases in `src/index.ts`. It does
+not fetch content, select other registrations or change package outputs.
+
+Generation supports a literal `defineProject` with literal source/phase arrays
+and recognizable SDK calls. Existing capture settings are preserved, repeated
+registration is idempotent, and custom/dynamic entries remain untouched with a
+`configuration.status: manual` hint. Registration is still saved; edit only the
+needed declarations through the normal configuration path. For special processors
+or resource options, configure them before following the capture Route. Omitting
+`--configure` keeps registration-only behavior.
+
 ```ts
 captureFile({ source: docs });
 captureFile({ source: docs, processor: mdxJsonDocs() });
@@ -73,24 +86,27 @@ creating a second capture or knowledge pipeline.
 
 ### Batch capture from the source registry
 
-When all registered Lark documents are intended for this project and share capture
-settings, read the registry once instead of copying its module names into
-`src/index.ts`. For the standard `src/index.ts` entry:
+For documents with shared capture settings, prefer registry-driven configuration
+over repeating source declarations and capture calls, even for two documents.
+Select the task's intended registrations first. The example below assumes all
+registered Lark documents are in scope, with the standard `src/index.ts` entry:
 
 ```ts
 import { fileURLToPath } from "node:url";
 import {
-  allSources, captureLark, defineProject, loadSourcesRegistry, source,
+  captureLark, defineProject, loadSourcesRegistry, source,
 } from "@c4a/context";
 
 const workspaceRoot = fileURLToPath(new URL("../", import.meta.url));
 const registry = await loadSourcesRegistry({ rootDir: workspaceRoot });
+// For a subset, filter registry.larks by the authorized namespace/names here.
 const documents = registry.larks.map(entry =>
   source(entry.name, { type: "lark" }),
 );
 
 export default defineProject({
-  sources: [...allSources("repo"), ...documents],
+  sources: documents,
+  // Shared settings, independent source identities and capture phases.
   phases: documents.map(document => captureLark({ source: document })),
   packages: [],
 });
@@ -115,6 +131,10 @@ Registry loading only reads local registrations; it does not fetch documents.
 - The map declares one phase per document. It does not fetch URLs, change capture
   permissions, or request parallel execution. Run the declared phases through the
   existing CLI flow so each document retains independent refresh and retry behavior.
+  This reduces configuration repetition, not the number of capture operations.
+- Capture boundaries do not dictate article boundaries. During planning and
+  writing, combine related captured documents around reader tasks when useful;
+  do not create one article or a complete production cycle per source by default.
 
 ## `customPhase`
 
@@ -154,18 +174,18 @@ from the package name, if present. Omit it for KB-only output. It accepts `title
 `src/knowledge-map.yaml` independently of KB directories; see
 [Package Outputs](../guides/package-outputs.md#optional-static-documentation-website).
 
-## Indexer registry
+## Knowledge requirements and Indexer Skills
 
-When this file is absent, the configuration Route supplies the initial schema:
-write confirmed `requirements` with `indexers: []`, then re-evaluate. The Provider
-selection Action supplies its own completion schema; that payload is not the
-configuration file. Subsequent changes use typed proposals and applicable gates. Each selected Indexer binds requirements and scopes to one
-primary Provider, with optional declared layers or composers. Provider code
-must return the current Indexer result protocol; it must not write Candidate,
-knowledge, or Review files directly.
+When `src/indexers.yaml` is absent, the configuration Route supplies its schema.
+Write `requirements` only; do not add `protocol`, `indexers`, Provider selections
+or profiles. Re-evaluate after changing confirmed requirements.
 
-Detailed Provider protocol and customization guidance is selected by the
-current workflow Route when it is needed.
+Installed Indexer Skills guide investigation and writing. Relevant Skill choices
+and optional configuration use `indexer_usage` in the temporary production plan,
+not this durable file. There is no separate Provider selection or resolution gate.
+The Agent writes task drafts and reference files under the returned temporary
+directory; the CLI accepts them and owns Candidate, Review and formal output.
+See [Indexer guidance](../guides/indexer-provider-and-customization.md).
 
 ## Persistent versus runtime state