@c4a/context 0.7.8 → 0.7.9

package/docs/guides/agent-dialogue.md

@@ -67,7 +67,8 @@ again. Resolve essential missing goals or source boundaries before production.
 
 `grill-me` is targeted clarification, not a fixed questionnaire. Research what the
 available material can answer, then ask about consequential unknowns. A required
-schema field is not automatically a question for the user. For substantial new
-work, the opening report summarizes the agreed purpose, scope and first delivery;
-invite the user to read it unless they waived that pause. A report should not
-silently substitute guessed decisions for unanswered questions.
+schema field is not automatically a question for the user. For the first production
+task in a new workspace, the work-start report must resolve and display the agreed
+purpose, source families, language, settings, outputs and first delivery before
+source registration. Present it and wait for feedback even in managed mode. A
+report must not silently substitute guessed decisions for unanswered questions.

package/docs/guides/agent-guide.md

@@ -96,11 +96,17 @@ delivery batches do complete their applicable content review, close and build;
 they are distinct from Partition transport batches. The first delivery normally
 contains 1–3 pages, followed by 30–50-page batches or a smaller remaining tail.
 
-For substantial new work, follow the selected opening-report procedure after
-research and necessary questions, before Partition. Explain what the first pages
-will help the reader do and invite them to read the report, unless that pause was
-explicitly waived. Neither the report nor an invitation creates a new approval
-state; fully managed mode still reports its decisions and delivered page paths.
+For the first production task in a new workspace, follow the selected work-start
+report procedure using the user's task instructions and batch metadata titles for
+the supplied list, falling back to at most 10 unresolved title lookups if unavailable.
+Do not fetch source bodies or outlines before
+capture; missing titles may remain unknown. Detailed plans are provisional until
+captured evidence is available.
+Resolve its required start conditions, present it and wait for feedback before
+source registration or capture. Reuse explicit answers and defaults instead of
+asking a fixed questionnaire. Existing-workspace lightweight changes may keep a
+short conversational summary. The source-boundary Gate remains the confirmation
+authority; fully managed mode does not bypass the first report handoff.
 
 ## Quality bar
 

package/docs/guides/indexer-provider-and-customization.md

@@ -10,6 +10,35 @@ Context is registry-only by default. The durable selection lives in
 resolved transport paths and runtime staging directories are not selection
 authority. A Provider-only project does not create `src/indexer/`.
 
+
+## Large sources and planning depth
+
+Use directory/manifests, route or service registration and representative code to
+select Providers and plan reader subjects. Do not run a complete symbol index
+just to decide the initial article menu. Application/service file-inventory
+batches describe reading scope; they are not business module boundaries or a
+requirement to publish one article per directory. Inspect the supplied source
+access and converge related batches into reader subjects. A file with no supplied
+symbol facts has not been deeply parsed; this is not evidence that it has no APIs.
+Accepted application batches acquire parser facts before Author. Existing
+request-material remains the next action for implementation outside the initial
+reading scope. Public-contract-led profiles, including component libraries,
+retain their contract preparation because those facts define their reader targets.
+
+A read scope is an authorization ceiling. Each Indexer should own its actual
+module, with other sources as supporting evidence only when needed. Mixed
+frameworks require per-module Provider choices; do not disable a relevant
+extension to avoid fixing an oversized source boundary. Framework facts are
+still prepared at Author after the selected code has been parsed. For large
+IDL sources, first follow the selected applications' concrete protocol references
+and required includes; an entire protocol monorepo is not a default target.
+
+Parser progress is on stderr; stdout remains the command's JSON result. Report
+actual phase, source and available counts without estimating a percentage from
+elapsed time. A preparation-cache hit only reuses parser work, not proof of
+completed articles. After interruption use the current Route; do not clear state
+or increase memory automatically to retry the same oversized scope.
+
 ## Selection flow
 
 Follow `workflow.current` from `context status --format json` or `context run`.
@@ -31,8 +60,9 @@ configuration or semantic input boundary; it does not make those decisions.
    installed-Skill inventory, discovery report, or discovery-only confirmation
    is required. Use the supplied exact identity and cli-bundled distribution
    for shipped Providers, even when their Skills are also visible to the Host.
-   For a relevant external Skill, read only its exact Host-exposed frontmatter
-   and sibling `context-indexer.yaml` needed for selection. Do not guess versions
+   For a relevant external Skill, read its exact Host-exposed `SKILL.md`
+   and sibling `context-indexer.yaml`, then only the linked framework references
+   needed to evaluate observed module signals. Do not guess versions
    or scan `.claude`, `.codex`, `.agents` or arbitrary user directories. Different
    versions remain distinct; discovery order is not selection precedence.
 3. Submit the semantic `indexers` and any relevant non-CLI `host_visible_skills`
@@ -57,6 +87,31 @@ For CLI-bundled instruction Providers, these fields record the original
 selection; they are not a requirement to reinstall old bytes when resuming.
 The current CLI supplies its installed Provider's guidance automatically.
 
+### Select technology profiles per module
+
+A registered repository is a source boundary, not a single technology profile.
+Different modules may need different primary profiles and extension layers. Use
+the current selection contract's supported module and target/read scopes; never
+assign one module's stack to the entire repository merely because it was
+registered as one source.
+
+An observed framework dependency, configuration, entry or adapter signal is a
+reason to load the relevant Provider Skill and its applicable reference during
+selection. Reading this guidance is not activation or permission to execute the
+Provider. Follow its evidence rules to verify the signal within authorized source
+material, then bind the applicable profile only to the supported modules. A name
+alone may justify investigation without proving a framework is active.
+
+If boundaries are still unclear, identify the relevant modules and inspect their
+configuration and entries in the existing selection flow. Do not reject a
+relevant Provider solely because the repository contains mixed stacks, or defer
+investigation until generic authoring happens to report a capability gap. Record
+unresolved evidence and the concrete next inspection when it cannot yet be
+obtained. Keep unrelated modules on their appropriate primary profiles; multiple
+compatible, proven extensions may support one module without becoming duplicate
+primary owners. These are Agent selection responsibilities, not CLI semantic
+checks or new review gates.
+
 ## Resuming after a tool update
 
 Continue with the current Route and its supplied source material. Agents do not
@@ -110,18 +165,19 @@ indexers:
     providers:
       - id: community
         role: primary
-        skill: "<catalog.skill>"
-        version: "<catalog.version>"
-        integrity: "<catalog.integrity>"
-        distribution:
-          kind: cli-bundled
-          locator: "<catalog.distribution.locator>"
+        catalog_skill: "<catalog.skill>"
 ```
 
 - Choose `component-library` only if it matches the reader task and appears in
   the selected catalog entry's `capabilities.profiles`. For captured documents,
   notes or conversation summaries, select a profile from the corresponding
-  compatible Provider. Copy the actual catalog identity.
+  compatible Provider. `catalog_skill` selects exactly one bundled entry from the
+  current Action catalog. The CLI fills its version, integrity and distribution
+  after checking the Route revision; a changed catalog invalidates that revision.
+  Do not combine this reference with identity overrides. Full identities remain
+  available for explicitly pinned entries and external Providers, which retain
+  their resolution and authorization requirements. The persisted registry always
+  contains complete identities, never `catalog_skill` references.
 - Bind each selected requirement and all required coverage domains it owns;
   the single-domain template is not permission to drop other required domains.
   `owned_scope` names the target being described. `read_scope` may also include
@@ -347,17 +403,16 @@ Existing `reader_goals` remain valid when it is absent. Context passes this
 requirement through Partition, Author, and Review; it does not classify free
 text against a fixed vocabulary.
 
-After representative reading and necessary scope discussion, substantial new work
-can preserve the decisions in `.tmp/work-start-report.md` before Partition.
-The current workflow supplies `procedure.work-start-report` and
-`template.work-start-report`: a readable report with its existing requirement
-reference, use scenarios, scope choices, proposed classifications, first delivery
-and actual execution settings. Lightweight edits keep a short summary. The report
-is scratch context, not a published Artifact, a new approval or a condition for
-advancing the workflow. On its first presentation, invite the user to read and
-correct it and pause for that response, including in managed mode, unless they
-explicitly waived this reading opportunity. Reuse the response and report when
-continuing the same task; do not add a per-batch pause or report-status field.
+For the first production task in a new workspace, the source-boundary Route
+requires `.tmp/work-start-report.md` before source registration. The current
+workflow supplies `procedure.work-start-report` and `template.work-start-report`:
+a readable report covering readers, purpose, source families, language, settings,
+delivery outputs, first delivery and proposed organization. The Agent reads the
+brief and representative authorized material with Host tools, presents the report
+and resolves its missing choices before registration or capture. The CLI only
+checks the Route payload references a real non-empty report and records its digest;
+it does not judge prose or infer semantic decisions. Reuse and update the report
+with actual Provider choices before Partition rather than adding a per-batch report.
 
 Partition may select `artifact_intent` and `template_id` from the current
 Provider catalog, along with `reader_task`, `outline`, `priority`, and

package/docs/guides/knowledge-updates.md

@@ -16,18 +16,116 @@ 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.
 
-## Edit one section or review part of a batch
+## First-task intake budget
+
+Before registration and capture, the Agent uses the user's task instructions and
+reads batch metadata titles across the explicitly supplied document list. Lark
+metadata requests accept at most 200 entries each, not 200 words or 200 documents
+overall. H1/H2 may be reused only when metadata returns them without
+body retrieval; Lark batch metadata returns titles, not headings. Batch failure
+falls back to at most 10 unresolved document title lookups total, unless a shared
+authentication failure makes those calls redundant. The Agent does not fetch
+source bodies, outlines, images or attachments. Missing title metadata is
+optional: preserve the original URL without falling back to body retrieval or
+changing credentials. Resolve intent from the conversation; refine provisional
+chapters and module boundaries from evidence after formal capture.
+
+## Workspace versions and changelog
+
+`package.json.version` is the workspace SemVer. At completed-scope delivery the
+workflow asks the Agent to inspect formal changes and record an increasing version
+with a concise changelog. Added modules or expanded material coverage increment
+minor; corrections, existing-module updates, navigation and persistent status
+changes increment patch. Major requires an explicit user instruction. Temporary
+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
+do not each receive a version.
+
+The workspace AGENTS.md and version-writing instructions require each entry's
+details to stay within 1500 visible characters, including punctuation across the
+title, changes, trigger descriptions and actor display name, excluding protocol
+keys, version and date. The Agent compresses longer drafts before submission,
+preserving main changes, impact and triggers instead of truncating text or splitting
+the iteration into extra versions. This is an Agent writing rule, not a prose-quality
+CLI gate.
+
+`context version inspect --format json` returns changed paths and a digest. The
+coordinator submits `context version record --input <file> --format json` with:
+
+```yaml
+expected_digest: "<digest returned by inspect>"
+version: 0.2.0
+title: Add module recovery guidance
+changes:
+  - Document recovery conditions and the supported retry flow.
+triggers:
+  - kind: module
+    description: Additional module material requested in this iteration.
+actor:
+  kind: lark
+  name: Example User
+```
 
-For a reading-directory-only change, use the existing `context task adjust
---input <file|-> --format json` action with `reading_structure`. Supply its
+`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
+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.
+
+The CLI writes `changelog.yaml`, generated `CHANGELOG.md`, `package.json` and the
+`.context-version.json` content baseline together. Keep these formal files with
+the workspace; do not hand-edit generated baselines. Git-managed and unignored
+new files are compared (without Git, non-runtime workspace files are compared).
+Version metadata itself, `dist`, `.tmp` and dependencies do not cause changes.
+
+Successful builds record version and per-package hashes in `.context-builds.json`.
+They do not increase versions. Before publishing, `context version publish-check
+--format json` compares against `.context-published.json`. A same-version changed
+output requires a patch using `version inspect --publish` and a `dist` trigger,
+then a rebuild. Record `version published --hash <checked-hash> --receipt
+<successful-publication-reference> --format json` only after external success.
+No command commits, tags or uploads automatically.
+
+Website history is available at `changelog.html`: cards are newest first, the
+latest three expanded and older cards collapsed. The History button beside the
+theme switch and footer update timestamps link there. KB and LLMS outputs carry
+the same workspace version and changelog.
+
+## Customize the knowledge map at any time
+
+For a knowledge-map-only change, use the existing `context task adjust
+--input <file|-> --format json` action with `knowledge_map`. Supply its
 current `expected_revision`, explicit `upsert` entries and `remove` keys. Each
 entry retains its stable key, parent, title and order; optional targets use
 article identity and section key. The current structure preview supplies those
-identities. Use `expected_revision: null` only when no reading structure exists.
+identities. Read the persistent `src/knowledge-map.yaml`; use
+`expected_revision: null` only when no knowledge map exists.
 After adjustment, follow status to rebuild affected packages. This changes the
 reading organization without capturing sources or rewriting approved prose.
 Do not directly edit generated package navigation or use titles as identities.
 
+Users can ask in conversation to move a topic, rename a directory, change order,
+or organize the same articles for another reader task. Handle this during ongoing
+production or after completion through the same adjustment; no active Indexer
+task, source recapture or new mode choice is required. Finish or revoke active
+worker assignments before changing the map. Preserve unrelated entries and page
+identities. The map controls website navigation and LLMS organization together.
+
+For each new or changed article, the Agent decides whether to retain its current
+placement, add another placement, move it, or create a warranted category. Check
+these choices against the user's settled organization before structure approval
+and delivery. New articles must be bound even if the map revision has not changed;
+modifying a title alone is not a reason to change article identity. Never satisfy
+coverage by mechanically placing every new page under an unrelated catch-all.
+Build reports missing bindings for the Agent to resolve; it does not classify
+content. Moving a menu entry does not change the article URL.
+
+## Edit one section or review part of a batch
+
 The current approved-revision Route accepts either full `markdown` or explicit
 `sections` edits. Use an existing `writing_context.current_sections` ID and an
 ordered `content` list of `{ "markdown": "new text" }` and/or

package/docs/guides/package-outputs.md

@@ -15,11 +15,85 @@ close is required, run deterministic close before build. Current close derives
 final verify gate without rewriting approved Markdown. References, changelog,
 package index, and section fingerprint rebuilds are not current close output.
 
-## Recommended First Output: Agent Knowledge-Base Package
+## Default New-Workspace Outputs: Knowledge Base + Website
 
-Choose an agent knowledge-base package first when the knowledge should help
-Coding Agents work with the project. After the user chooses this semantic
-output shape, implement it with `kbPackage()`.
+Output channels support multiple selection. In a new workspace without explicit
+preferences, the Agent proposes and configures KB + website as the default. Honor
+user feedback, session authority and existing workspace declarations; LLMS is an
+additional selectable channel. This is an Agent configuration default, not an SDK
+change that silently enables websites for existing packages.
+
+### Static documentation website
+
+To include the default browser-readable site, enable `site` on the same
+package. The normal `context build` produces both the Agent KB and a standalone
+`dist/<base>-site/` directory containing `index.html`, article HTML,
+local search, scripts, styles and the selected bundled resources.
+
+`<base>` is the package name with one trailing `-kb` removed, when present.
+For example, `project-kb` produces `dist/project-kb/` and `dist/project-site/`;
+`project` produces `dist/project/` and `dist/project-site/`. Output directories
+must not collide with another package or website. `site.base` controls URL
+prefixes only, not filesystem output paths.
+
+```ts
+kbPackage({
+  name: "project-kb",
+  template: "src/package-templates/kb",
+  site: { title: "Project knowledge", lang: "en-US", base: "/" },
+});
+```
+
+`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).
+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
+remembered in browser storage. Search runs locally, without a search service.
+Mermaid renders in the browser with a restrained theme; invalid diagrams retain
+their source instead of blocking publication. Code samples and raw HTML are
+displayed as content, not executed as Vue components or scripts.
+
+The accepted `src/knowledge-map.yaml` controls sidebar organization. Entries
+bind to `artifact_ref` and optionally `section_key`; the builder resolves these
+against this package's selected approved articles. Navigation labels and parent
+groups do not determine website paths. One article may have several navigation
+placements while keeping one URL. Pending/excluded targets generate warnings
+and no invented link. Every selected article with an artifact identity must have
+a valid reading target before packaging, including packages without a website.
+Missing bindings or invalid section references block the staged output and
+return the missing article list plus a navigation-only task adjustment input.
+Category nodes can remain empty while future articles are planned. The builder
+does not infer business categories or alter article content.
+
+Top navigation contains the first-level reading directories. Selecting
+a section shows only its descendants in the left sidebar; opening an article
+directly selects its section. Skills and their Markdown references remain
+reachable as linked read-only pages, but have no automatically added navigation
+section. A reader-facing usage guide can link them where appropriate.
+Section landing pages have stable URLs separate from article URLs.
+
+`dist/<base>-site/context-site-map.json` records each article's approved path, KB path and
+site path, plus the projected menu and unresolved targets. URLs are derived from
+article identity; legacy pages without `artifact_ref` use their approved path,
+so moving those legacy files changes their URL. The shared knowledge map,
+KB layout and production Markdown remain unchanged.
+
+Article pages include a small source footer from recorded article source references and the source registry. Repository entries link to the recorded revision and module (or an explicitly referenced file); document entries link to their registered HTTP(S) URL. Unrecorded associations are not inferred from prose. Source-footer changes participate in the website build fingerprint without modifying knowledge Markdown.
+
+The website reuses resource delivery already performed for the KB: bundled
+resources are copied into the site's `resources/`; Git raw links remain remote,
+and explicit resource omission remains omission. It does not copy source trees
+or capture audits. Website generation completes in a sibling staging directory
+before either output is published, so a failed website build preserves the
+previous KB and website. The website is not included in the KB directory.
+Disabling the option removes the old site on the next successful package build.
+
+Preview through an HTTP static server. Deploy the **contents of `dist/<base>-site/`** using
+the user's chosen static hosting tool; no hosting SDK, login, deployment or
+platform-specific skill is part of Context's build. Keep hosting credentials
+out of package templates and published content.
 
 Typical output:
 
@@ -205,7 +279,9 @@ Typical output:
 
 ```text
 dist/<package-name>/
-└── llms.txt
+├── llms.txt                  # knowledge-map index
+├── llms-full.txt             # consolidated approved text
+└── llms/pages/<identity>.txt # individual approved articles
 ```
 
 Choose this when the user wants:
@@ -226,49 +302,139 @@ knowledge/
 └── ...
 ```
 
-## How To Ask The User
-
-When `workflow.current.reason_code` is `route.package.output-required`,
-explain the choices with the output tree. Do not ask the user to pick from
-unexplained labels.
-Use the host's native multi-choice tool when available. If unavailable, fall
-back to a short Markdown A/B/C question. The option labels should be:
-agent knowledge-base package, LLM text bundle, and skip package output for now.
-
-Recommended question shape:
+## Agent configuration and delivery recipe
+
+Use this guide when the user asks to generate a documentation website, selects
+outputs in the work-start report, or the current Route asks for package output.
+Read the current Route and existing `src/index.ts` first. Reuse settled choices;
+follow its configuration/read-acknowledgement contract rather than replaying a
+previous revision. The Agent edits SDK configuration; the user need not write code.
+
+1. Record all selected channels together. For new workspaces with no explicit
+   preference, use KB + website. Preserve existing declarations and explicit
+   KB-only, LLMS-only or deferred-delivery choices.
+2. Configure the existing KB declaration below, substituting the actual name,
+   title and workspace language. Retain its sources, phases, selection and resource
+   policy. This is one KB package with an additional website channel, not two KBs.
+3. If LLMS is selected, add its declaration and import in the same edit. Ensure
+   both template directories exist and resolve generic-template review using the
+   current Route. Do not independently ask approval for each already selected channel.
+4. Refresh `context status --format json`. Follow the returned continuation for
+   knowledge-map adjustment, required review, close, verification and build.
+   Missing article bindings require explicit targets from current CLI diagnostics;
+   do not classify articles from `wikis/` or `codeindex/` directory names alone.
+5. Run `context build` when ready. Verify each selected output and report its
+   actual location; a failed selected website is not completed delivery.
+6. Preview the generated website directory through a local HTTP server. Verify HTTP succeeds
+   before giving its URL. Publishing requires the user's chosen hosting tool and
+   authorization; do not install a hosting SDK merely to build the website.
 
-```text
-The reviewed knowledge is approved. The next decision is how to package it.
-
-Recommended: agent knowledge-base package
-dist/<name>-kb/
-├── AGENTS.md
-├── skills/knowledge-query/SKILL.md
-└── wikis/
-    ├── index.md
-    ├── <group-page>.md
-    └── <large-group>/index.md
-
-This is best if agents should use the knowledge as a reusable knowledge base.
-
-Alternative: LLM text bundle
-dist/<name>-llms/
-└── llms.txt
-
-This is best if you need one text bundle for model/RAG import.
-
-We can also skip package output for now and keep only knowledge/.
-
-Which one should I declare first?
+```ts
+import { defineProject, kbPackage, llmsPackage } from "@c4a/context";
+
+// Edit only the packages field of the existing defineProject declaration.
+// Keep the actual project's other declarations intact.
+const packages = [
+  kbPackage({
+    name: "project-kb",
+    template: "src/package-templates/kb",
+    site: { title: "Project knowledge", lang: "en-US", base: "/" },
+  }),
+  // Include this entry only when LLMS text is selected.
+  llmsPackage({ name: "project-llms", template: "src/package-templates/llms" }),
+];
+// Existing defineProject({ ...existing declarations, packages }).
 ```
 
-If the user chooses the Agent knowledge-base package, explain that its OKF
-roots are flat within `dist/<package-name>/`; do not ask for a second namespace.
-If its Skills need a short prefix, the author maintains those final names
-independently from package paths; this is not a mandatory question.
+The configuration is a small source edit, not custom frontend implementation.
+Website output reuses approved articles, knowledge map and packaged assets;
+rendering/search generation adds build time and size, not another indexing pass.
+Measure actual cost instead of quoting a universal estimate.
+
+| User request | Agent action |
+| --- | --- |
+| KB + website | One `kbPackage` with `site` enabled |
+| KB only / disable website | Omit `site` on that KB and rebuild; old site output is removed |
+| Add website later | Add `site` to existing KB, repair missing reading bindings, rebuild |
+| Website only for distribution | Explain the KB is still built; share only the sibling website directory |
+| Also produce LLMS | Add `llmsPackage` alongside the KB in the same change |
+| Keep current knowledge only | Postpone packaging; do not label it completed package delivery |
+
+```sh
+python3 -m http.server 8000 --bind 127.0.0.1 --directory dist/project-site
+```
 
-If the user requests multiple outputs, declare and verify each requested package.
-There is no additional confirmation just because two outputs were already chosen.
-The default adaptive index policy avoids one-page directory indexes. Configure
-`kbPackage().navigation` when a package needs a different inline-entry
-threshold or a fully expanded index at every directory.
+The completion report lists KB root, website directory and LLMS file separately,
+with generated/failed/not-selected status. Include website navigation coverage,
+verified preview URL when running, and any remaining errors. The website contains
+source cards and article update times; it does not imply an article history browser.
+
+## How To Present The Choice
+
+Include a compact multi-select list in the work-start report, and reuse it later:
+
+- [x] Agent knowledge-base package — default for a new workspace.
+- [x] Documentation website — default with the KB, local preview or later hosting.
+- [ ] LLMS text — optional model-context or RAG input.
+
+Explicit choices override defaults. When current Route authority requires a user
+decision, ask once for the combination rather than a sequence of mutually exclusive
+questions. If the host tool supports only single selection, let the user state the
+combination in text instead of presenting it as multi-select. There is no `both`
+factory, separate website skill, or second permission per selected output.
+
+## Website deployment handoff after every successful build
+
+After every successful website build, including intermediate delivery and an
+unchanged output reused by build, tell the user the website can be deployed with
+a deployment skill. Include the actual `dist/<base>-site/` directory and whether
+it contains only the currently delivered scope. This notice does not wait for the
+whole knowledge task to finish and does not block its next Route.
+
+Reuse existing publishing configuration and the user's chosen target. Otherwise,
+inspect the available deployment skills, recommend a compatible static-site skill,
+or let the user specify one. Do not invent installed skills or a deployed URL.
+If no compatible skill is available, report that and provide the site directory
+for the user's deployment tool. Do not install a deployment dependency by default.
+
+When publishing is already authorized for that target, follow the selected skill
+with the built site directory; otherwise offer deployment and wait for the user's
+publishing instruction. Preserve the configured base path; rebuild if the target
+requires a different base. Pass only the website output, not sources, private
+workspace state or the entire KB package. Report success only after checking the
+hosting result and published URL. A failed deployment leaves the local build valid;
+report the deployment failure and its next step separately.
+
+
+### Persistent knowledge map and report proposals
+
+`src/knowledge-map.yaml` is the persistent knowledge map; retain it after delivery.
+Its protocol is `context.knowledge-map/v1`; structure and adjustment inputs use
+`knowledge_map`, and SDK functions use `KnowledgeMap` naming. It organizes website
+navigation and LLMS without changing article identities or section bindings.
+
+The work-start report explains the proposed directory and chapters, followed by
+a text wireframe of the website. Material changes are communicated with the updated
+report link and a short explanation. This does not build a temporary website or
+create a persistent article-plan file. Website packaging uses the accepted knowledge map
+and approved articles; the report is not a configuration input.
+
+### Website LLM Docs
+
+Every website build also builds LLMS from the same selected approved articles and
+knowledge map. The final top-navigation item is always **LLM Docs**, opening
+`llms/index.html`. This page links to `llms.txt`, the structured index,
+`llms-full.txt`, the complete approved text, and raw Markdown text articles under
+`llms/pages/`. These files ship inside the sibling website directory and use the configured site base.
+No separate LLMS package declaration or additional build command is required.
+Website LLMS text files include a UTF-8 BOM so browsers can identify the encoding
+when a static host omits the charset. Hosting should serve them as
+`text/plain; charset=utf-8`. The HTML landing page shows one index/full-text
+toolbar followed by the knowledge map; Changelog is available in the site navbar.
+
+The index preserves knowledge-map grouping, order and repeated placements. The
+full text includes each selected article only once, in first-placement order.
+Only approved selected content is exported. A map or article change invalidates
+both website and LLMS outputs; failure preserves the previous staged package.
+Standalone `llmsPackage()` uses the same map organization and supplies the full
+text and raw article files alongside its template-rendered `llms.txt` index.

package/docs/reference/indexer-provider-protocol.md

@@ -47,6 +47,25 @@ Writing style, chapter drift and ordinary Provider version differences remain
 guidance. Changed source/approval identities invalidate an in-flight supporting
 projection; they are not semantic content judgments.
 
+## Current CLI Author batches
+
+Use the current Route's task keys and supplied scaffold. Within a CLI batch,
+`group_key` may be omitted: preview and completion inherit it from the selected
+current task. An explicitly different group is rejected. Standalone SDK semantic
+results still require `group_key`. Intent and eligible policy use the existing
+page-plan defaults; changing a page's purpose is not a metadata repair.
+
+The inventory reading joins exact member/fact identities to parser names, kinds
+and explicit `propsType` values. These are navigation references, not proof that
+a symbol is public or a member has been covered. Keep semantic dispositions and
+source evidence explicit.
+
+On a stale revision, the CLI exposes a current Route snapshot and current tasks,
+plus accepted identities available from the current main ledger and its Composers.
+Task keys are local to each Route. Compare stable workset/request identities,
+read the new Route and do not replay accepted work. Missing historical records
+are not evidence that old work is unaccepted.
+
 ## Resources and execution
 
 A Provider may contain a controlled program, profile-bound instructions,