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

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

@@ -22,6 +22,49 @@ 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
+
+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
+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.
+
+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
@@ -62,7 +105,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 +141,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.
@@ -402,11 +455,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

@@ -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/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`
 
@@ -134,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({
@@ -150,22 +185,26 @@ 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).
 
-## 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
 

package/providers/context/resources/procedures/close-and-build.md

@@ -9,10 +9,31 @@ mediaType: text/markdown
 At completed-scope delivery, follow the version-recording Route. The coordinator
 writes the semantic changelog from formal diffs and the conversation, including
 the triggering source and an explicitly known user (Git name is the default).
+Pass `actor` explicitly when the conversation identifies the triggering user,
+including a known Lark display name. If Git has no name and the conversation
+does not identify the user, leave it absent and mention that in the delivery
+summary; do not infer identity from paths, logins or source authors. Amending
+an unbuilt entry preserves its actor unless an explicit replacement is supplied.
 Record after Close and package/template approval, before the final build, so the
 selected outputs are built with the new version once. Build records hashes without
 increasing versions. Never count temporary progress or a build retry as a change.
 
+For formal repairs before a successful build, use `version inspect`'s
+`reusable_version` when present. Submit the same version and a complete updated
+changelog covering the original work plus repairs, not a repair-only replacement.
+The CLI updates the pending entry in place. A successful build or publication
+seals that version; subsequent changes require an increase. Do not delete build
+or publication receipts to reopen history.
+
+Successful delivery clears completed task drafts. Do not empty `.tmp` or call
+`task resume` as a finalization step. Retain registered repository checkouts,
+source-region baselines and queued logs for reuse; optional historical-cache
+cleanup follows the workspace preparation guide after delivery, not after close.
+
+Website rendering must preserve literal code and template examples. Do not revise
+valid source-grounded JSX or template syntax merely to avoid Vue interpolation;
+report a rendering defect if the website compiler cannot display it literally.
+
 Before an authorized external publication, run `context version publish-check
 --format json`. If `needs_version` is true, inspect with `context version inspect
 --publish --format json`, record a patch changelog using a `dist` trigger, and

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

@@ -22,6 +22,49 @@ 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
+
+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
+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.
+
+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
@@ -62,7 +105,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 +141,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.
@@ -402,11 +455,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,11 +10,46 @@ 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.
 Read related code as needed within the user's authorized sources.
 
+Keep planning proportional to this request. For a short document task or one
+bounded module, decide whether to add or revise related articles and their reading
+position; do not redesign unrelated modules or the whole site. Start with relevant
+existing topics, not every navigation page. Expand investigation when the material
+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
+another article is ready to write. Keep remaining investigation explicit; a small
+current task does not mean other authorized work is finished. New source or purpose
+authorization still follows the current Route.
+
 Write results under the returned Agent directory. All submission paths are
 relative to that stage directory, even when the manifest is in `submissions/`.
 Copy the CLI's submission template, keep completed tasks only, and keep each