@c4a/context-cli 0.7.10 → 0.7.12

package/providers/context/resources/manuals/guides/knowledge-updates.md

@@ -24,6 +24,25 @@ actual behavior, a confirmed decision, and a proposal that is not implemented.
 
 ## Keep planning local to the change
 
+Before starting production, compare the proposed content with the workspace's
+reader purpose. For clearly unrelated anecdotes or personal rankings, briefly
+recommend leaving them out of the formal manual or saving them separately because
+they can dilute useful retrieval. Attribution alone does not make content relevant.
+This is advice, not a CLI gate: honor the user's informed choice without repeated
+objections, while preserving subjective attribution and normal Review.
+
+Registered repositories are not prerequisites for every new request. Restore only
+sources needed to investigate or write the current task, including unchanged code
+when its implementation needs checking. Notes, document-only work, wording edits
+and navigation changes do not require unrelated checkouts. Retained article
+references alone do not require restoring every referenced repository. Missing
+material remains a gap; it must not be treated as investigated or permanently
+excluded. Independent available material can proceed through planning and delivery.
+For required code, use `context source recovery-plan <registered-name> --format json`.
+Reuse a valid local checkout or obtain clone authorization for the returned pinned
+version, then submit the decision using the returned recovery command and schema.
+Do not restore all registered sources merely because a checkout is missing.
+
 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
@@ -38,6 +57,14 @@ 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.
 
+For broad work, distinguish the whole requested outcome, the current batch and
+remaining capability families or document tasks. Entry-first knowledge should
+locate a checked file/symbol or source section and a concrete next step; a module
+name alone is not problem coverage. When merging or revising, preserve useful
+existing detail rather than replacing it with lookup advice. Review checks the
+promised reader task; task completion and navigation binding only describe the
+declared articles, not semantic coverage of all source material.
+
 ## First-task intake budget
 
 Before registration and capture, the Agent uses the user's task instructions and
@@ -385,6 +412,13 @@ and the same Review/build route.
 
 ## Adjust or roll back current work
 
+Read `context task adjust --schema --format yaml` for the source-adjustment
+and knowledge-map input variants; no workspace or input file is required.
+After restoring an unavailable source, follow the recovery result's
+`next_action` to refresh the captured planning materials. Preparation can return
+a new stage: use its paths and identity when resubmitting your plan. Restoring
+the checkout alone does not replace an existing stage's captured material.
+
 For an explicit same-task change to native Indexer source inputs, use
 `context task adjust --input <file|-> --format json` with `scopes` containing the
 selected `source_ref` and optional `module_refs`, plus an `instruction` explaining
@@ -428,11 +462,61 @@ knowledge structure and packages.
 
 To move an approved page, use `context revise "<old path>" --move-to "<new path>"
 --instruction "<requested move and content changes>" --format json`. The new
-path stays in the same collection. The revision retains the page identity,
+path may use another supported knowledge collection. The revision retains the page identity,
 rebases outgoing links and updates incoming Markdown links at approval. A new
 subject name alone only needs a title/content revision; do not create duplicate
-pages. Retirement is a content decision: explain the inapplicable material and
-supported replacement before changing its page and referring navigation.
+pages. Changing a website group alone does not require moving or reclassifying an article.
+
+### Restructure existing knowledge
+
+Read the affected approved articles and current sources before deciding what to
+keep, deepen, split, merge, retain as history or retire. Reuse the current plan
+and remaining scope; a new article plan does not prove old content was preserved.
+Work by reader task, not source or menu count.
+
+For a split or merge, first approve destination content, then revise the original
+and incoming links. Preserve useful details until their destination is available.
+Same-page fragments use ordinary revision edits; cross-page work uses new/revision
+tasks and explicit retirement. Finish each coherent batch's content and navigation
+before delivery; inspect both new content and the old articles' disposition.
+
+Preview approved-page retirement with `context task retire --input <file> --format json`:
+
+```yaml
+reason: These reader tasks are now covered by the approved guide.
+targets:
+  - path: architecture/old-guide.md
+    replacement: sop/current-guide.md
+```
+
+`replacement` is optional and must already be approved, outside the retirement set.
+Use several targets for a batch. Read affected files and blockers, then execute
+the returned digest-bound apply command within the user's authorization; do not
+ask for another confirmation when that retirement is already authorized.
+`context task retire --schema --format yaml` describes the input.
+
+Retirement removes selected Markdown and structure entries together, updates
+page-level incoming Markdown links to explicit replacements, and rebinds page
+navigation or removes retired navigation targets while retaining groups.
+Repair fragment links explicitly first: the CLI cannot infer where a split moved
+a paragraph. Without a replacement, repair incoming links before applying.
+Finish active drafts/revisions first; unfinished production targeting a selected
+page must be finished or amended rather than discarded.
+
+Follow status and the normal close/version/build flow before delivery. Sources
+and shared assets are not deleted. The response provides a temporary restore
+input for the existing rollback preview, including exact previous article,
+structure and modified navigation/link bytes. Retain that input or a Git baseline
+if restoration is needed after temporary cleanup. Retry an interrupted apply
+with the same input and digest; never delete runtime files to recover. Later
+conflicting edits require inspection instead of blind rollback.
+
+Historical pages with continuing reader value should normally retain their
+applicable version. Source read failure, shorter new text or a changed menu is
+not sufficient reason to retire an article.
+Retirement does not narrow the registered production scope. If the user also
+excludes the underlying topic from future work, record that through the existing
+requirements/exclusion flow rather than assuming file removal changes the goal.
 
 ### Adjust inputs while a local update is unfinished
 

package/providers/context/resources/manuals/guides/package-outputs.md

@@ -46,13 +46,51 @@ prefixes only, not filesystem output paths.
 kbPackage({
   name: "project-kb",
   template: "src/package-templates/kb",
-  site: { title: "Project knowledge", lang: "en-US", base: "/" },
+  site: {
+    title: "Project knowledge",
+    lang: "en-US",
+    base: "/",
+    home: {
+      title: "Project knowledge",
+      slogan: "Find the context behind the work",
+      description: "Browse the approved knowledge map and supporting resources.",
+      resources: [{
+        title: "Project workspace",
+        description: "Open the repository that maintains this knowledge.",
+        href: "https://example.com/project",
+        featured: true,
+      }],
+    },
+  },
 });
 ```
 
 `site` is opt-in; omission keeps the existing KB-only output. Optional fields
 are `title` (defaults to the package name), `description`, `lang` (defaults to
 `en-US`), and `base` (defaults to `/`; use `/docs/` when hosted under that path).
+`home` optionally customizes the landing-page `title`, `slogan`, `description`
+and action buttons. Its `resources` list adds only configured repository,
+service or support cards; each item requires a safe `href`, a copyable
+`command`, or both. Set `featured: true` on a linked resource to also place it
+between the Browse knowledge and LLM Docs hero actions. Do not add placeholders
+for unknown destinations.
+
+Configure resources from confirmed project settings, repository remotes or
+successful publication receipts. If a service has not been created or its URL is
+unknown, omit the resource object; empty strings are not placeholders. Missing
+optional resources do not block building the site or authorize creating services.
+After an authorized deployment succeeds, add its returned destination to the
+existing resource list, avoiding duplicates. Rebuild when this changes the
+configuration; updating the hosted site still requires publication authorization.
+
+The homepage uses the first-level knowledge map as a complete site map. Each
+section card previews a bounded number of page links and retains a link to the
+full section, so large knowledge bases remain scannable without hiding top-level
+coverage. LLM Docs and Changelog remain dedicated generated resources. On wide
+screens the homepage content aligns with article content while preserving the
+sidebar rail; on narrow screens it uses the available width. Motion is limited
+to short card entrance and hover feedback and is disabled when the reader asks
+the operating system to reduce motion.
 The website uses a full-width VitePress theme with system fonts, compact navigation,
 a wide reading area and a smaller article outline. It starts in
 light mode regardless of the operating system; an explicit reader choice is

package/providers/context/resources/manuals/guides/workspace-prepare.md

@@ -67,6 +67,9 @@ workflow bundle: `repository-source-recovery.md` beside this guide and
 `../../schemas/repository-source-recovery.schema.json`. Reuse a matching local
 checkout or, when authorized, clone into a bounded location using
 `context source restore --input <workspace-input-file> --format json`.
+Follow its `next_action` before resuming a plan: an active production stage may
+need preparation to refresh previously unavailable material. Use the stage and
+paths returned by preparation, not a payload's previous stage identity.
 Group modules sharing a remote and fixed commit; do not clone per module.
 Check registered commit and module paths. Never reset a supplied dirty checkout.
 Authentication or checkout problems can be diagnosed with Host Git tools;

package/providers/context/resources/manuals/reference/project-api.md

@@ -154,7 +154,22 @@ kbPackage({
   name: "component-kb",
   template: "src/package-templates/kb",
   select: { collections: ["codeindex", "architecture"] },
-  site: { title: "Component knowledge", lang: "en-US", base: "/" },
+  site: {
+    title: "Component knowledge",
+    lang: "en-US",
+    base: "/",
+    home: {
+      title: "Component knowledge",
+      slogan: "Build with the public contract in view",
+      description: "Browse components, usage guidance and implementation boundaries.",
+      resources: [{
+        title: "Project workspace",
+        description: "Open the repository that maintains this knowledge.",
+        href: "https://example.com/project",
+        featured: true,
+      }],
+    },
+  },
 });
 
 llmsPackage({
@@ -170,7 +185,11 @@ may be rebuilt; it is not an authoring source.
 `kbPackage.site` optionally adds a VitePress website at `dist/<base>-site/` in
 the same build, beside the KB directory. `<base>` removes one trailing `-kb`
 from the package name, if present. Omit it for KB-only output. It accepts `title`, `description`,
-`lang` and a deployment `base` path. Knowledge map is projected from
+`lang`, a deployment `base` path, and an optional `home` presentation. `home`
+accepts `title`, `slogan`, `description`, hero `actions`, and `resources` shown
+below the generated site map. Each resource needs an `href`, a copyable
+`command`, or both. Omit unknown resources; the builder never invents service
+or repository links. Knowledge map is projected from
 `src/knowledge-map.yaml` independently of KB directories; see
 [Package Outputs](../guides/package-outputs.md#optional-static-documentation-website).
 

package/providers/context/resources/procedures/knowledge-review.md

@@ -51,6 +51,13 @@ were read.
 After apply, re-evaluate. Do not infer that close or package output is current.
 Do not persist a duplicate review-report ledger in the workspace.
 
+For restructuring, compare replacement content with the affected approved pages:
+useful conditions, steps and explanations must have a destination before removal.
+Review omission rejects a candidate; it does not retire an approved article.
+Use the explicit retirement preview after replacement delivery, and repair its
+reported incoming references. Navigation removal alone does not remove content
+from search or packages. A renamed menu does not require a new article identity.
+
 The Review UI names the internal `rejected` decision **Omit** because it is a
 durable content decision, not a request to rewrite the page. When a page needs
 changes, leave that page pending and use `context revise` so the owning
@@ -103,8 +110,11 @@ and the Route returns to their Review/repair after the selected output builds.
 ## Check usefulness as well as factual accuracy
 
 Use the current requirements and agreed scope to check whether a reader can
-complete the promised task with these pages. Source citations and a valid API
-table alone do not establish that. Compare representative pages with their
+complete the promised task with these pages. For navigation, check a specific
+file/symbol or source section and an actionable next hop; for explanations or
+procedures, check the necessary conditions, steps and examples. Source citations,
+task acceptance and navigation bindings alone do not establish either outcome.
+Compare representative pages with their
 actual definitions: keep defaults and members attached to the correct callable
 or type; inspect inherited members and static entry points when needed for the
 reader's task. Do not infer that an unexpanded type has no options or callbacks.
@@ -116,3 +126,9 @@ not an automatic rejection rule. If the source is insufficient, identify what
 is unavailable and its effect on the reader instead of inventing content or
 forcing another identical regeneration. Keep correct pages eligible for the
 partial approval and delivery path above.
+
+Compare the batch with the agreed whole scope and remaining investigation, not
+only its own titles. When revising or merging, preserve useful existing detail
+instead of replacing it with generic lookup advice. Repair affected pages or
+use the current planning route for missing topics. These are Agent judgments,
+not minimum article counts, a new coverage ledger or an extra CLI approval gate.

package/providers/context/resources/procedures/knowledge-updates.md

@@ -24,6 +24,25 @@ actual behavior, a confirmed decision, and a proposal that is not implemented.
 
 ## Keep planning local to the change
 
+Before starting production, compare the proposed content with the workspace's
+reader purpose. For clearly unrelated anecdotes or personal rankings, briefly
+recommend leaving them out of the formal manual or saving them separately because
+they can dilute useful retrieval. Attribution alone does not make content relevant.
+This is advice, not a CLI gate: honor the user's informed choice without repeated
+objections, while preserving subjective attribution and normal Review.
+
+Registered repositories are not prerequisites for every new request. Restore only
+sources needed to investigate or write the current task, including unchanged code
+when its implementation needs checking. Notes, document-only work, wording edits
+and navigation changes do not require unrelated checkouts. Retained article
+references alone do not require restoring every referenced repository. Missing
+material remains a gap; it must not be treated as investigated or permanently
+excluded. Independent available material can proceed through planning and delivery.
+For required code, use `context source recovery-plan <registered-name> --format json`.
+Reuse a valid local checkout or obtain clone authorization for the returned pinned
+version, then submit the decision using the returned recovery command and schema.
+Do not restore all registered sources merely because a checkout is missing.
+
 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
@@ -38,6 +57,14 @@ 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.
 
+For broad work, distinguish the whole requested outcome, the current batch and
+remaining capability families or document tasks. Entry-first knowledge should
+locate a checked file/symbol or source section and a concrete next step; a module
+name alone is not problem coverage. When merging or revising, preserve useful
+existing detail rather than replacing it with lookup advice. Review checks the
+promised reader task; task completion and navigation binding only describe the
+declared articles, not semantic coverage of all source material.
+
 ## First-task intake budget
 
 Before registration and capture, the Agent uses the user's task instructions and
@@ -385,6 +412,13 @@ and the same Review/build route.
 
 ## Adjust or roll back current work
 
+Read `context task adjust --schema --format yaml` for the source-adjustment
+and knowledge-map input variants; no workspace or input file is required.
+After restoring an unavailable source, follow the recovery result's
+`next_action` to refresh the captured planning materials. Preparation can return
+a new stage: use its paths and identity when resubmitting your plan. Restoring
+the checkout alone does not replace an existing stage's captured material.
+
 For an explicit same-task change to native Indexer source inputs, use
 `context task adjust --input <file|-> --format json` with `scopes` containing the
 selected `source_ref` and optional `module_refs`, plus an `instruction` explaining
@@ -428,11 +462,61 @@ knowledge structure and packages.
 
 To move an approved page, use `context revise "<old path>" --move-to "<new path>"
 --instruction "<requested move and content changes>" --format json`. The new
-path stays in the same collection. The revision retains the page identity,
+path may use another supported knowledge collection. The revision retains the page identity,
 rebases outgoing links and updates incoming Markdown links at approval. A new
 subject name alone only needs a title/content revision; do not create duplicate
-pages. Retirement is a content decision: explain the inapplicable material and
-supported replacement before changing its page and referring navigation.
+pages. Changing a website group alone does not require moving or reclassifying an article.
+
+### Restructure existing knowledge
+
+Read the affected approved articles and current sources before deciding what to
+keep, deepen, split, merge, retain as history or retire. Reuse the current plan
+and remaining scope; a new article plan does not prove old content was preserved.
+Work by reader task, not source or menu count.
+
+For a split or merge, first approve destination content, then revise the original
+and incoming links. Preserve useful details until their destination is available.
+Same-page fragments use ordinary revision edits; cross-page work uses new/revision
+tasks and explicit retirement. Finish each coherent batch's content and navigation
+before delivery; inspect both new content and the old articles' disposition.
+
+Preview approved-page retirement with `context task retire --input <file> --format json`:
+
+```yaml
+reason: These reader tasks are now covered by the approved guide.
+targets:
+  - path: architecture/old-guide.md
+    replacement: sop/current-guide.md
+```
+
+`replacement` is optional and must already be approved, outside the retirement set.
+Use several targets for a batch. Read affected files and blockers, then execute
+the returned digest-bound apply command within the user's authorization; do not
+ask for another confirmation when that retirement is already authorized.
+`context task retire --schema --format yaml` describes the input.
+
+Retirement removes selected Markdown and structure entries together, updates
+page-level incoming Markdown links to explicit replacements, and rebinds page
+navigation or removes retired navigation targets while retaining groups.
+Repair fragment links explicitly first: the CLI cannot infer where a split moved
+a paragraph. Without a replacement, repair incoming links before applying.
+Finish active drafts/revisions first; unfinished production targeting a selected
+page must be finished or amended rather than discarded.
+
+Follow status and the normal close/version/build flow before delivery. Sources
+and shared assets are not deleted. The response provides a temporary restore
+input for the existing rollback preview, including exact previous article,
+structure and modified navigation/link bytes. Retain that input or a Git baseline
+if restoration is needed after temporary cleanup. Retry an interrupted apply
+with the same input and digest; never delete runtime files to recover. Later
+conflicting edits require inspection instead of blind rollback.
+
+Historical pages with continuing reader value should normally retain their
+applicable version. Source read failure, shorter new text or a changed menu is
+not sufficient reason to retire an article.
+Retirement does not narrow the registered production scope. If the user also
+excludes the underlying topic from future work, record that through the existing
+requirements/exclusion flow rather than assuming file removal changes the goal.
 
 ### Adjust inputs while a local update is unfinished
 

package/providers/context/resources/procedures/package-output.md

@@ -58,6 +58,24 @@ changed. A request to generate a documentation website follows this same route,
 including after initial delivery. Inspect existing declarations before editing;
 do not register the request itself as source material or re-index unchanged knowledge.
 
+For a new website or a requested homepage redesign, configure `site.home` from
+the confirmed audience and scope: a concise title, slogan and description, plus
+only useful hero actions. The generated homepage already supplies the complete
+top-level site map, LLM Docs and Changelog. Add `home.resources` for verified
+repositories, services, support channels or copyable install commands. Omit
+unknown destinations instead of inventing links or showing empty cards; they
+can be added later without re-indexing knowledge.
+
+When configuring the homepage, reuse confirmed project declarations, repository
+remotes, deployment configuration and successful publication receipts. Known
+resource types do not prove that a destination exists. Omit unavailable resources
+entirely rather than passing empty strings; note missing optional destinations in
+the existing work summary without blocking knowledge production or requesting
+new services. After an authorized publication or service setup succeeds, use its
+returned URL and package identity to update the corresponding resource. Preserve
+existing entries, avoid duplicates, and rebuild only when configuration changes.
+Republish the changed site only within the existing publication authorization.
+
 Validate reading targets before build. Website navigation uses the approved reading
 structure; repair missing bindings through the current structure adjustment action.
 Build cost is rendering and local search generation, not another Indexer run.

package/providers/context/resources/procedures/production-stage-files.md

@@ -10,6 +10,16 @@ The stage entry links CLI-owned requirements, planned skill guidance and task
 directories. Read relevant source text before writing; a skeleton is navigation,
 not semantic evidence. Skill names guide work, not article ownership or versions.
 
+Restore repository checkouts only when needed for the current investigation or
+article. Independent notes/documents can proceed while unavailable code remains
+an explicit gap. For a required repository, read the
+[recovery procedure](repository-source-recovery.md) and inspect only its registered
+name, not every repository. Never claim missing material was checked.
+
+Plan article paths are relative to `knowledge/`, for example `business/example.md`.
+`indexer_usage.scopes` contains stage source refs, not collection names. Declare
+selected skills through the plan; no separate Indexer registration is required.
+
 Choose relevant code directories while planning or writing. A task brief may
 name useful reading scope; module labels do not imply directory permissions.
 No module mapping file, version receipt or article-level scope fields are needed.
@@ -22,6 +32,17 @@ existing topics, not every navigation page. Expand investigation when the materi
 requires it, not to fill a planning template. One batch is sufficient unless real
 dependencies or useful parallel work call for more. Source count is not a page
 count or a CLI threshold.
+For a broad request, identify its major capability families and document tasks;
+lightweight planning limits initial depth, not the authorized range. Use existing
+questions and briefs to distinguish checked entry points from explanations and
+keep unplanned work visible. A first batch is not the whole requested outcome.
+
+For restructuring, assess existing articles as well as proposed additions.
+Preserve useful text until approved destinations carry it; then repair links and
+navigation. Splitting/merging uses ordinary article tasks and fragment edits.
+After their delivery, explicitly obsolete approved pages can use the retirement
+preview described in the knowledge-updates guide. Removing a plan task or menu
+entry does not retire its approved article.
 
 During an approved stage, use the existing plan-amendment path for in-scope
 additions and preserve completed work. Do not restart planning solely because

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/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.
@@ -48,11 +50,14 @@ 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
@@ -96,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

@@ -67,6 +67,9 @@ workflow bundle: `repository-source-recovery.md` beside this guide and
 `../../schemas/repository-source-recovery.schema.json`. Reuse a matching local
 checkout or, when authorized, clone into a bounded location using
 `context source restore --input <workspace-input-file> --format json`.
+Follow its `next_action` before resuming a plan: an active production stage may
+need preparation to refresh previously unavailable material. Use the stage and
+paths returned by preparation, not a payload's previous stage identity.
 Group modules sharing a remote and fixed commit; do not clone per module.
 Check registered commit and module paths. Never reset a supplied dirty checkout.
 Authentication or checkout problems can be diagnosed with Host Git tools;

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.