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

package/providers/context/resources/procedures/repository-source-recovery.md

@@ -10,7 +10,9 @@ Repository checkout contents and materialized module links are local runtime
 inputs. Git stores their recovery recipe in `sources/repo/index.yaml`; it does
 not store the checkout, local aliases, or `sources/repo/<date>/<module>` links.
 
-Run the route's inspection action first. It groups logical modules by registered
+Recover only repositories required by the current task, not all registered
+checkouts before an unrelated document or Note update. Run
+`context source recovery-plan <registered-name> --format json` first. It groups logical modules by registered
 remote and pinned commit, so one physical checkout can restore every module in
 that group. Do not create one clone per module. Groups already marked `ready`
 need no decision; when every group is ready, the plan has no recovery action.
@@ -39,5 +41,5 @@ materializes module links.
 
 Repository sources are ready only when every selected module resolves to the
 registered remote and pinned commit, every registered subpath exists, no local
-path was overwritten, Context materialization succeeds, and the current route
-no longer reports `route.source.repository-not-ready`.
+path was overwritten, Context materialization succeeds, and the selected recovery
+plan reports them ready.

package/providers/context/resources/procedures/source-capture-detailed.md

@@ -121,6 +121,14 @@ manager or version.
 
 ### Route by source boundary
 
+For explicitly selected sources needing ordinary capture settings, use
+`source add ... --configure` (also supported by `source add batch`) to register
+and generate explicit `src/index.ts` declarations in one call. This does not
+capture, select unrelated registrations, or change output settings. Inspect the
+returned configuration result: custom/dynamic entries return `manual` and remain
+unchanged; preserve them and make a focused edit. If special processors/resources
+are needed, configure those before capture. Do not retry generation in a loop.
+
 Before choosing a local Markdown capture route, honor the surrounding task context. Driver documents such as run instructions, handbooks, READMEs, plans, feedback issues, corpus/index/manifests, and batch lists are not Context sources unless the user explicitly asks to ingest them. Capture only ingest targets that are already explicit in the user request; if they are missing, ask one clarification instead of capturing the driver document.
 
 - One or more local `.md` / `.mdx` files or a local documentation folder to ingest →
@@ -147,15 +155,21 @@ Before choosing a local Markdown capture route, honor the surrounding task conte
 - A Lark/Feishu URL, doc token, or wiki token → register one Lark source:
   `context source add lark [YYYYMMDD] --module <module> --url <url>` or the
   matching token flag. Register every requested document under the same date;
-  do not ask for `YYYYMMDD-2`. Declare
+  do not ask for `YYYYMMDD-2`. For multiple documents, use the shared configuration
+  pattern below rather than repeating declarations. For a single document, declare
   `captureLark({ source: source("<date>", "<module>", { type: "lark" }) })`,
-  then run `context run capture:lark:<date>/<module> --format json`.
+  then follow the current Route to execute capture.
 - For a registered document batch with shared capture settings, use
   [Batch capture from the source registry](../manuals/reference/project-api.md#batch-capture-from-the-source-registry)
   to load the registry and generate typed references and phases. Do not transcribe
   the full YAML module list into `src/index.ts`. Select only the intended entries;
   use the entire registry only when all its documents are in scope. Preserve
   existing phases/packages and keep processor or resource exceptions per document.
+  Prefer this pattern even for two documents with the same settings. It reduces
+  configuration repetition, not capture operations or permission boundaries.
+  Independent source identities do not require independent articles: plan and
+  write across related captured documents by reader task, not one production
+  cycle per input document.
 - Mixed local document and Lark document batches are separate sources unless
   the current CLI explicitly offers a combined source contract. Mapping registered
   entries into declarative SDK phases is supported; writing an Agent-side loop

package/providers/context/resources/procedures/task-recovery.md

@@ -15,6 +15,12 @@ its progress is changing. Never start a competing writer or delete a writer lock
 
 ## Choose the smallest applicable action
 
+- Orphan writer lock: preview `task recover --operation writer-lock`. Before
+  applying its current digest, pause new workspace commands and confirm no child
+  writer or other host/container still uses the workspace. Apply archives only
+  the unchanged lock whose owner is no longer running; it does not complete any
+  capture. Run recovery inspection again for interrupted transactions, then
+  refresh the Route. Unknown or active ownership must not be bypassed.
 - Wrong current payload: use the reported schema/evidence to correct it and refresh
   the Route when available. A current candidate can use its ordinary revise action.
 - Interrupted transaction: preview `task recover --operation transactions`, inspect

package/providers/context/resources/procedures/work-start-report.md

@@ -27,8 +27,10 @@ first, then use documents and selectively read business definitions to correct
 reader topics. Directory names are orientation, not verified business semantics.
 Documents need not fit a code-shaped menu.
 
-Code investigation returns bounded feature names, counts where complete, entry
-paths and checked/remaining ranges, not full symbols or call graphs. Document
+Code investigation identifies the authorized capability families, checked entry
+paths and remaining ranges, not full symbols or call graphs. Broad scope calls for
+horizontal discovery, not deep reading of every implementation before writing.
+Document
 overviews include titles, bounded introductory text, the full H2/H3 hierarchy and
 full-text access. Read more when the overview cannot settle a semantic choice.
 Do not run additional parsers merely to populate counts or tables.
@@ -38,17 +40,24 @@ confirmed/provisional topics, unchecked ranges and delivery implications. If
 document acquisition is blocked, ask whether a limited first scope is acceptable;
 do not silently omit supplied documents or claim full coverage from partial scans.
 
-Small, clearly scoped revisions, notes and conversation summaries can use a short
-handling proposal. Do not invent an independent planning phase to fill a report;
-do not use this exception to bypass feedback on a bulk build.
+Small, clearly scoped document tasks, single-module work, revisions, notes and
+conversation summaries can use a short handling proposal: which related articles
+to add or revise, their reading position and the intended result. A module with
+several reader topics may need more planning within that module, not a redesign
+of the whole knowledge base. Do not invent an independent investigation, batch
+hierarchy or dependency analysis to fill a report. This changes report depth, not
+the current Route's approval boundary.
 
 ## Explain the proposed work
 
-Write in the user's language. Open with the reader's task and first useful
-delivery, not protocol IDs. Explain purpose, source/version boundaries, proposed
-topics, reuse or revision of existing articles, cross-source articles, suggested
-batches, dependencies and first delivery. Separate material counts from planned
-article counts; unknown totals are not zero or confirmed final counts.
+Write in the user's language. Open with the reader's task and whole requested
+outcome, then distinguish the current delivery and remaining work. Explain source
+versions, topics, reuse or revision of existing articles and useful dependencies,
+not protocol IDs. State which topics provide checked problem-level entry points
+and which explain behavior or operations. Package names alone are not that depth.
+Keep material, planned article and investigated-scope counts separate; unknown
+totals are not zero. Describe remaining capability families or document tasks in
+the existing plan/report, without a per-file ledger or another confirmation step.
 
 Explain relevant conflicts, gaps, exclusions and decisions requiring feedback.
 Access permission alone does not approve a semantic exclusion. Distinguish user
@@ -60,12 +69,14 @@ per-module ownership tables. One module may use several Indexers and one article
 may combine their materials. Optional specialist absence does not exclude sources.
 
 Reuse selected KB, website and LLMS delivery channels. For website delivery,
-include a compact proposed menu and layout: top-level groups, a representative
+for a new site or requested navigation redesign, include a compact proposed menu and layout: top-level groups, a representative
 left menu, article chapters and on-page outline. Explain mobile behavior briefly
 when relevant. This is a sketch, not a built site; do not create empty articles,
 temporary websites or promise deployment. Link the existing requirement or
 workspace configuration rather than creating a permanent report identity.
 Estimate timing or savings only when supported by measurements and conditions.
+For a small addition to an existing site, describe only the affected reading
+position; reuse its layout and delivery choices instead of proposing them again.
 
 ## Mandatory feedback
 
@@ -90,6 +101,8 @@ pause. Actual scale belongs in the report whose pre-writing feedback is mandator
 Use current CLI task and stage progress; distinguish accepted candidates, approved
 articles and delivered outputs. The current batch is not the whole goal. Do not
 treat input rechecks as loss of formal articles or candidates as delivered pages.
+Task completion concerns the declared plan; navigation coverage concerns existing
+articles. Neither proves that all authorized source topics have been explained.
 
 Reports, plans, skills, candidates, confirmation and transaction process stay in
 `.tmp`. Only formal results and necessary long-term source/requirement decisions

package/providers/context/resources/procedures/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

package/providers/context/resources/templates/work-start-report.md

@@ -10,11 +10,11 @@ Write `.tmp/work-start-report.md` in the user's language after lightweight
 investigation and planning. Adapt this outline; omit empty sections and template
 instructions. Headings are not a questionnaire or mandatory schema.
 
-## Readers and first useful delivery
+## Readers, whole goal and current delivery
 
-Explain who will use the knowledge, what they need to do and what the first
-reviewed delivery enables. Reuse confirmed purpose, scope, priorities, language
-and delivery choices. Describe execution/settings implications only when useful.
+Explain who will use the knowledge, the whole requested outcome and what this
+reviewed delivery enables. Distinguish a first useful batch from the final scope.
+Reuse confirmed purpose, priorities, language and delivery choices.
 
 ## What the materials support
 
@@ -33,6 +33,9 @@ Use this table only when several groups need comparison:
 Keep material counts separate from article counts. Do not produce a per-file
 accounting table. One article may use several sources and Indexers. Batches are
 execution groupings, not fixed article templates or mandatory route transitions.
+State the useful depth for each topic: a specific investigation entry, an
+explanation or an executable procedure. Name still-unplanned capability families
+and document tasks rather than hiding them behind completion of this table.
 
 ## Reading organization and delivery
 
@@ -43,8 +46,10 @@ duplicating bodies. Retain existing KB, website and LLMS delivery choices.
 
 For website delivery, add a compact sketch showing the site title, top-level
 groups, a representative left menu, article chapters and on-page outline.
-Briefly explain mobile menus when relevant. A sketch is not a built website or
-permission to create empty pages. Do not infer business semantics from code paths.
+For a new homepage or requested redesign, also propose a short title, slogan,
+description and the verified optional resource cards. Briefly explain mobile
+menus when relevant. A sketch is not a built website or permission to create
+empty pages. Do not infer business semantics from code paths or invent links.
 
 ## Relevant indexing guidance
 

package/providers/context/actions/inspect-repository-recovery.yaml

@@ -1,6 +0,0 @@
-schema: agent-graph.action.v1
-id: inspect-repository-recovery
-description: Group missing repository modules by physical checkout and show recovery choices.
-runner: command
-effect: read
-command: context source recovery-plan --format json

package/providers/context/actions/restore-repository-sources.yaml

@@ -1,7 +0,0 @@
-schema: agent-graph.action.v1
-id: restore-repository-sources
-description: Restore registered repository sources from user-confirmed local paths or explicit clones.
-runner: command
-effect: external
-command: context source restore --input .tmp/agent-payloads/repository-source-recovery.json --format json
-inputSchema: schemas/repository-source-recovery.schema.json

package/providers/context/resources/dialogue/repository-source-recovery.md

@@ -1,23 +0,0 @@
----
-id: dialogue.repository-source-recovery
-kind: procedure
-mediaType: text/markdown
----
-
-# Repository source recovery dialogue
-
-Explain that the Context project is intact: only Git-ignored source checkouts
-or local links are missing. Show one choice per physical repository, not per
-logical module.
-
-For an existing checkout, ask for its path or ask the user to authorize a
-specific parent directory for a bounded scan. Show matching candidates with
-their origin, HEAD, dirty state, and required subpath coverage before the user
-selects one. Do not modify, switch, clean, or pull the selected checkout.
-
-For a clone, show the registered remote, pinned commit, target directory, and
-the logical modules that will share it. The clone restores the recorded source
-version; it does not silently advance to the latest branch.
-
-After recovery, summarize reused and cloned checkouts, actual commits, restored
-module links, and any remaining permission or missing-subpath blockers.

package/providers/context/schemas/repository-source-recovery.schema.json

@@ -1,40 +0,0 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "context.repository-source-recovery.v1",
-  "type": "object",
-  "additionalProperties": false,
-  "required": ["schema", "repositories"],
-  "properties": {
-    "schema": {
-      "const": "context.repository-source-recovery.v1"
-    },
-    "repositories": {
-      "type": "array",
-      "minItems": 1,
-      "items": {
-        "oneOf": [
-          {
-            "type": "object",
-            "additionalProperties": false,
-            "required": ["source", "mode", "path"],
-            "properties": {
-              "source": { "type": "string", "minLength": 1 },
-              "mode": { "const": "local" },
-              "path": { "type": "string", "minLength": 1 }
-            }
-          },
-          {
-            "type": "object",
-            "additionalProperties": false,
-            "required": ["source", "mode"],
-            "properties": {
-              "source": { "type": "string", "minLength": 1 },
-              "mode": { "const": "clone" },
-              "path": { "type": "string", "minLength": 1 }
-            }
-          }
-        ]
-      }
-    }
-  }
-}