@c4a/context 0.7.8 → 0.7.10-alpha.1

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,
@@ -235,27 +254,19 @@ continue with a warning, and counts above 300 return the non-Gate
 partial outcome reopens the owning semantic step; it does not create a profile
 revision ledger or an override route.
 
-Artifact content has three mechanically separate layers. `facts[]` contains
-canonical, source-bound values and never reader prose. A structured
-`deterministic-block` contains only a registered renderer and `fact_refs`; the
-CLI resolves those Facts and derives both Markdown and evidence, so a Provider
-cannot relabel arbitrary JSON or prose as a catalog. A `semantic-prose` block
-contains evidence-bound Markdown and cannot cite Facts as a way to increase
-deterministic coverage. The normalized rendered Section retains ordered
-`content_blocks` with the layer, Fact refs, evidence refs and per-block digest;
-its Section digest covers that ledger and the exact reader-visible Markdown.
-
-`ArtifactResult` also carries
-`context.indexer.capability-group-evidence/v1`. It repeats the complete member
-set bound by the author workset even when no capability group is selected. A
-non-empty capability group has a stable ref derived only from the logical unit
-and capability key, at least two explicit member-to-evidence bindings, and one
-or more actual Artifact Section evidence bindings. A member cannot belong to
-two capability groups. Every member evidence ref must be a current Result
-evidence binding and must be visible in one of the declared Sections. Unknown
-members or Sections, page-level evidence without Section consumption, and
-workset/member-set drift are rejected. This protocol does not assign projection
-dispositions to members outside capability groups.
+Artifact content contains reader Markdown and actual source-region references.
+Each semantic-prose block supplies at most three positions using `source_ref`
+and a file/line `locator`; the Host verifies the current authorized source and
+computes the region `content_digest`. The limit applies to an output fragment,
+not the whole article. Select necessary references or split the writing by
+meaning; never truncate necessary references or merge disjoint source regions.
+An article has no Fact table, evidence ID table, or per-binding ledger.
+Parser output remains a reading aid, not a required submission representation.
+
+The Host retains the current workset's inventory accounting in the internal
+Result. Author supplies member dispositions, not member-to-evidence bindings
+or an independent capability evidence graph. This accounting is not copied
+into the approved article index.
 
 ## Full-path example identity
 
@@ -275,35 +286,14 @@ for the same complete example identity are a hard
 forge an empty collision list. Candidate disposition and linkage are separate
 downstream contracts.
 
-## SubjectKey schema authority
-
-Community profile identity rules have one authority: the top-level
-`subject_key_schemas` array in the CLI profile contract. A community Provider
-manifest cannot copy or replace that schema. A namespaced additional profile
-has the other allowed authority: the exact owner Provider's
-`composition.extensions[].subject_key_schema`. The extension declaration is
-required and may use only the CLI's closed namespace/local-key derivation
-operators, kind identifiers and normalization rules.
-
-Final selection resolves both forms to
-`context.indexer.resolved-subject-key-schema/v1`. The record binds the Indexer,
-profile, base-contract or Provider authority, schema digest and resolution
-digest. Its canonical set digest is part of the stable final selection report;
-transport paths and runtime receipts are not. Subject keys must match a kind in
-the resolved schema and satisfy its normalization before they can become a
-canonical NodeRef.
-
-An unchanged schema is equivalent. Adding a kind while preserving the existing
-namespace, normalization and local-key operators is compatible. Removing or
-changing an existing identity derivation is identity-breaking: the owning
-authority must advance its major version and the schema version must increase.
-When approved Nodes exist, Context requires a non-delegable
-`confirm-subject-reidentification` authorization bound to the exact old/new
-schema digests, approved catalog, complete deterministic mapping and report.
-Missing mappings, one old Node mapping to multiple Nodes, multiple old Nodes
-colliding on one new Node, stale authorization or digest drift blocks
-activation. With no approved Node, the human Gate is omitted but conformance
-and major-version checks still apply.
+## Article identity and source scope
+
+Production does not build a subject graph or require SubjectKey schemas.
+Provider extensions declare their reading and writing capabilities without
+namespace/kind normalization or subject re-identification gates. Context keeps
+article identity and fragment identity separately from reader titles and paths.
+Sources remain registered and authorized; removing graph modeling does not
+permit reading an undeclared source or changing another article's identity.
 
 ## Requirement change authority
 
@@ -404,7 +394,7 @@ identity, operations, scopes, profile composition, requirement bindings, owner
 closure and read authority are byte-identical. It revalidates overlay
 conformance,
 reuses the exact staged Bundles, and reruns both static and final selection
-against the target requirement digest. Provider and SubjectKey authority must
+against the target requirement digest. Provider authority must
 remain unchanged. Final selection resolves every CLI-base question back to its
 exact selected profile contract and requires one current validation proof
 for every overlay question; forged bindings and duplicate, stale, or unused
@@ -412,7 +402,7 @@ proofs fail before the final report is issued. The report binds the resulting
 question authority set digest. The resulting
 `context.indexer.overlay-question-registry-apply-proposal/v1` contains the full
 target `src/indexers.yaml` snapshot and binds the amendment, confirmation,
-overlay validation, rebound selection, SubjectKey schema set and finalized reports.
+overlay validation, rebound selection and finalized reports.
 The proposal goes through the same `stage-indexer-project-proposal` and
 `apply-indexer-project` Actions as ordinary registry/customization proposals.
 The latter dispatches this typed proposal to one expected-base CAS, project
@@ -423,15 +413,12 @@ temporary Provider path.
 
 ## Controlled invocation
 
-Author result acceptance checks the actual task, source/module, subject and
-Provider layer. Provider integrity, bundle/config/customization fingerprints
-remain recorded metadata, not byte-equality gates between a resumed request and
-its result. Selected Facts are resolved by their supplied identity and source
-references; their current values are recorded without comparing a previous
-parser payload digest. Source-span line ranges may expand within the same file
-content. Structured declarations resolve actual file/item identities, not a
-previous inventory or signature fingerprint. Source file content checks,
-unknown-reference rejection and atomic write protection remain in force.
+Author result acceptance checks the actual task, source/module and selected
+Provider authority, including its current bundle and configuration. Article
+content supplies actual source regions, not selected Fact IDs or structured
+claim ledgers. The Host computes region fingerprints from the current captured
+text. Unknown or unauthorized paths, source-version drift and write conflicts
+remain errors.
 
 These continuation rules do not relax executable program authorization or allow
 an Agent to select undeclared sources.
@@ -558,24 +545,18 @@ may route different Sections to different collections only by declaring
 separate Artifacts in its validated Bundle; the CLI does not silently split or
 merge reader pages to repair a Provider Result.
 
-The compile-internal resolver emits `context.indexer.layout-proposal/v1`. It
-binds the exact Artifact Result, profile contract, validated SubjectKey schema
-set and exact schema digest, Indexer and source. The resolver validates the
-SubjectKey against the selected schema normalization before deriving NodeRef;
-a caller-supplied digest is not accepted as schema authority. NodeRef plus the
-logical Artifact id/kind derives ArtifactRef. NodeRef, owner Indexer, Artifact
-kind and Section key derive a stable logical Section identity; its placement
-under one Artifact derives SectionRef. This lets a diff distinguish a moved
-Section from new content without allowing the same logical Section to have two
-primary placements. The ViewRef is an internal projection. Output paths are
-derived under `knowledge/<collection>/` and never accepted from a Provider.
+The compile-internal resolver emits `context.indexer.layout-proposal/v1`.
+It binds the accepted Result, profile contract, Indexer and source. A stable
+article reference derives from the accepted writing group and artifact identity;
+the fragment key belongs to that article. There is no independent Node or View
+identity. Output paths live under `knowledge/<collection>/`; layout validates
+article ownership, fragment placement and path collisions before writing.
 
 Template Artifacts enter layout only after validated rendering. Only rendered
 Sections exist; an omitted optional projection does not create an empty
 Section, while a retained material gap remains unresolved without
 reader-visible placeholder content. Artifact Bundle purpose and `split_of`
-lineage are retained in the proposal. A proposal set rejects duplicate Node
-owners, Artifact identities, logical Section identities, Section placements
+lineage are retained in the proposal. A proposal set rejects duplicate Artifact identities, logical Section identities, Section placements
 and output paths across Indexers, as well as missing, nested or kind-changing
 semantic-split parents.
 
@@ -760,24 +741,16 @@ a rendered byte budget. Every body Section uses exact markers:
 <!-- /context:indexer-section -->
 ```
 
-Only `{{variable:<id>}}` and `{{block:<id>}}` are accepted. Direct variables are
-semantic prose. A block source variable is a deterministic Fact projection,
-must bind canonical `fact_refs`, and must equal the CLI's normalized projection
-of those Facts. Blocks select one of
-the CLI-owned `bullet-list`, `key-value-table`, `json-code-block` or `public-contract-table` renderers;
-templates cannot register code or helpers. A block directive occupies its own
-template line so the renderer can retain an exact content-layer boundary. The
-contract and body must declare exactly the same Sections and placeholders.
-
-`ArtifactResult` binds every template variable to current evidence refs and
-binds every declared Section to `section_key`, owner Indexer, document kind,
-reader goal and Artifact kind. Rendering validates the Provider/customization
-fingerprints, template digest, current CLI-owned applicability conditions,
-variable types and expansion limits, per-variable evidence boundary and exact
-CLI-owned question target. An optional Section without data
-or sufficient evidence is absent from the rendered Candidate. A required
-Section in the same state becomes the already-declared material-question
-transition and makes `review_ready` false.
+Only `{{variable:<id>}}` and `{{block:<id>}}` are accepted. Variables carry
+their declared typed values and actual source-region references. Registered
+block renderers format those values; authors do not construct canonical Fact
+records or bind Fact IDs. Templates cannot register executable helpers.
+The contract and body must declare the same sections and placeholders.
+
+`ArtifactResult` binds each fragment to its owner and article classification.
+Rendering validates the current template, variable types and expansion limits.
+Optional sections without data are omitted; an unresolved required section
+uses the existing material-question path rather than fabricated prose.
 
 Context validates template-program directives, declared variable types and
 expansion limits before rendering. Supplied variable values and Section prose
@@ -791,13 +764,9 @@ digests. Deterministic blocks contribute catalog completeness but never
 semantic-prose density. Later `build` projects this approved body; it does not
 perform a first render or change its structure.
 
-An ArtifactResult may emit
-`context.indexer.structured-claim-set/v1`. Every claim binds a stable claim
-kind and subject to one real Artifact/Section owner and one or more evidence
-refs carried by that exact Section. The subject must be the current logical
-unit, one of its CLI-owned inventory members, or an authorized target-resolution
-identity. Missing owners, outside subjects, unknown evidence and evidence that
-is known globally but absent from the owner Section all fail Result validation.
+Articles do not submit structured claims, subject identities or evidence-binding
+tables. Actual source references support traceability and change detection;
+their existence does not prove semantic correctness.
 
 Main-run validation does not produce a prose-quality audit. Content usefulness,
 completeness and faithfulness belong to the existing Agent or user Review.
@@ -820,16 +789,16 @@ in knowledge frontmatter and is not proof that remaining material is useful.
 ## Incremental planning handoff
 
 A semantic Partition group may declare `ready_for_author: true` when the Agent
-has resolved its subject, primary ownership, reader task and shared dependencies.
+has resolved the writing boundary, primary ownership, reader task and shared dependencies.
 The CLI can then deliver an initial wave before all Partition tasks are accepted.
 This is an optional scheduling declaration, not a new evidence or approval gate.
 Absent/false groups wait; every inventory member still needs a final disposition.
 The original Partition ledger resumes after normal structure review, Author,
 Composer, content Review, close and successful build. Later material for the same
-subject reuses its page identity and approved prose. A wave finishing never means
+article reuses its identity and approved prose. A wave finishing never means
 the remaining source scope is complete.
 
 Known code-symbol planning views provide member overviews with immutable full
 fact links and bounded captured-source access. Providers must inspect details
 when semantic boundaries are uncertain; unknown payload formats retain full
-reading. Author receives full selected facts and source material.
+reading. Author reads the selected source material and cites the regions actually used.