@c4a/context 0.7.5 → 0.7.9

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

@@ -1,12 +1,70 @@
 # Indexer Provider protocol
 
 Context defines one Provider manifest, `context-indexer.yaml`, with protocol
-`context.indexer.provider/v1`. Code and Markdown Providers use the same field
+`context.indexer.provider/v1`. Code, Markdown, Note and Sessions Providers use the same field
 tree; `domains`, profiles and declared operations describe their applicable
 inputs.
 
 This page documents the protocol surface currently exposed by `@c4a/context`.
-It does not imply that the 0.7.0 CLI Route or its release channel is complete.
+Use the current CLI Route for executable inputs, schemas and selected resources.
+A protocol validator exported by the SDK is not a separate production workflow.
+
+## Articles supported by approved knowledge
+
+An article plan may declare `knowledge_dependencies`: stable `artifact_ref`,
+optional `section_refs` (empty means the approved article), and `required`.
+Use references supplied by Context; reader titles and output paths are not
+article identities. Each article keeps its existing primary subject and owned
+members. Referencing another article does not assign its members again.
+
+The current Partition/Author workflow delivers ready upstream articles before
+dependent required articles. An unavailable dependency remains visible in the
+structure preview; `request-adjustment` returns to planning. It cannot finish
+as an empty Author wave. Optional Composer output does not satisfy a required
+article plan.
+
+Review saves the approved fact payloads, evidence coordinates and versions with
+the approved Markdown transaction. These remain in `knowledge/structure.yaml`
+after close and temporary-cache cleanup. Author receives authorized supporting
+facts separately from approved interpretation. Current source captures, the
+Provider's accepted evidence kinds and the approved article version constrain
+that projection. A stored snapshot alone never expands source access.
+
+Previously approved dependencies can reuse their registered source reader even
+when that source has no owned Partition group in the current wave. Only the
+referenced authorized files enter the supporting projection. Missing or changed
+source files remain an upstream update task.
+
+An approved dependency change produces a verification warning for downstream
+articles. Use the existing `context revise` action on an affected article; its
+current route exposes `knowledge_input` with supporting facts and interpretations.
+Review accepts the refreshed supporting version even when the Agent confirms
+that the wording can stay the same. A plain edit with unavailable support does
+not clear the warning. `--regenerate` remains the existing program-block rebuild
+option, not a prerequisite for revising a prose synthesis.
+
+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
 
@@ -76,6 +134,15 @@ config against the Bundle's closed data-only schema, binds the project-local
 customization fingerprint and requires a policy digest for executable
 resources. Missing, duplicate, stale or extra inputs fail closed.
 
+Selection validation is not an upgrade gate on an instruction-only bundled
+Provider. On resume, the CLI resolves that Provider by Skill and portable
+distribution from the current installation, checks the required capabilities,
+and refreshes instruction delivery without comparing it to the registry's
+historical version/integrity. Compatible persisted tasks keep their original
+request/result identities. The current Route revision still prevents stale
+submissions. This does not change staged program execution authorization or
+allow results to be reused across changed source, config or result contracts.
+
 The final stable report excludes transport paths, delivery timestamps and
 runtime receipt digests. Those values remain in a separate runtime receipt
 projection, so rematerializing identical content does not make the selection
@@ -375,6 +442,19 @@ 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.
+
+These continuation rules do not relax executable program authorization or allow
+an Agent to select undeclared sources.
+
 `context.indexer.controlled-invocation/v1` binds:
 
 - the exact Indexer, Provider, version, Bundle integrity and stable Provider
@@ -387,7 +467,7 @@ temporary Provider path.
 - a stable trust-policy and authority digest;
 - timeout and stdin/stdout/stderr byte limits.
 
-The 0.7.0 built-in Host capability is `sandboxed_program: false`. A first-party,
+The built-in Host capability is `sandboxed_program: false`. A first-party,
 verified or exact project-authorized program may use the `trusted-program` path,
 which is not an isolation claim. An untrusted program without a real sandbox is
 not executable.
@@ -535,8 +615,11 @@ children, cycles, path collisions and unregistered files fail. Reader bodies
 over 1500 lines produce a non-blocking advisory only. Total physical Artifact
 count has no global maximum.
 
-An initial layout does not create a structural Gate. A content-only increment
-reuses the existing Artifact identity and also skips the Gate. Adding reader
+An initial layout does not create the protected `confirm-layout-change` Gate.
+The main lifecycle still reviews its semantic structure before Author in
+ordinary mode; new topics in an update receive that structure review too.
+A content-only increment reuses the existing Artifact identity and skips the
+protected layout-change Gate. Adding reader
 fan-out to an already approved Node, removing or renaming an Artifact,
 splitting/merging its declared lineage, moving a logical Section, or changing
 an approved collection/path is represented by a digest-bound layout change
@@ -585,9 +668,11 @@ ledger, answer workset, or special close route for them.
 Newly captured Markdown, tool snapshots, or other authorized material re-enter
 the normal `main-index` operation. The affected Partition and Author worksets
 run again, reconciliation is recomputed, and the user reviews the resulting
-knowledge Candidate once. Successful close writes only approved knowledge and
-the recovery metadata in `knowledge/structure.yaml`, then clears transient
-Indexer runtime state.
+knowledge Candidate through the existing content Review. Review apply writes
+approved Markdown; close projects `knowledge/structure.yaml` and verifies it.
+Delivery retains accepted work while more pages remain, then cleans completed
+transient state. Durable `processed_scopes` advance only after the selected
+scope's required work and build complete, not after one page in that scope.
 
 ## Detector and inspector
 
@@ -698,7 +783,7 @@ 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` or `json-code-block` renderers;
+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.
@@ -713,12 +798,13 @@ 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.
 
-Before a Candidate can enter Review, Context rejects unknown directives,
-unresolved variables, template comments, example placeholders, standalone or
-bracketed `TODO`/`TBD`/`待补充`/`待生成` markers, title-only Sections and budget
-overflow. A source-backed sentence that discusses a known TODO is not treated
-as a placeholder merely because it contains that token; it remains semantic
-prose and therefore requires Agent Review. The rendered
+Context validates template-program directives, declared variable types and
+expansion limits before rendering. Supplied variable values and Section prose
+are content, not template programs: JSX, braces, comments, TODOs, headings and
+example placeholders do not cause a content-validation failure. Missing or
+invalid structured input is distinct from an author's choice of words.
+Unfilled authoring placeholders can be mentioned during the existing Agent or
+user Review, but are not an additional CLI gate. The rendered
 Section content, ordered content-layer ledger and evidence receive stable
 digests. Deterministic blocks contribute catalog completeness but never
 semantic-prose density. Later `build` projects this approved body; it does not
@@ -732,10 +818,37 @@ 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.
 
-Main-run validation derives
-`context.indexer.generated-authoring-audit/v1`. It reports controlled generated
-placeholder and empty emitted-Section hard findings, proves that every emitted
-structured claim passed owner-local evidence coverage, and lists every
-semantic-prose block or direct authored template variable as
-`semantic-prose-agent-review-required`. It does not scan free prose to claim
-that unsupported natural-language assertions were mechanically detected.
+Main-run validation does not produce a prose-quality audit. Content usefulness,
+completeness and faithfulness belong to the existing Agent or user Review.
+Structured owner/source checks still run, but no keyword, punctuation, heading
+or sentence-pattern scan can reject an otherwise valid Result. Physical output
+checks distinguish a missing or blank body from an authored body; they do not
+decide whether headings, comments or short prose are sufficient knowledge.
+
+### Groups narrowed by a scope decision
+
+The CLI may attach `scope_change.removed_member_ids` to a derived PartitionPlan
+group after excluding only part of its membership. This is runtime provenance,
+not an extra field Provider authors should invent in semantic Partition results.
+The remaining identity stays stable; the old page form/template is no longer a
+binding choice. Author receives the change in `page_plan.scope_change` and must
+reassess the residual sources, title and reader task. It can choose an allowed
+page form or an applicable non-publishing outcome. This metadata does not belong
+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.
+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
+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.

package/docs/reference/package-templates.md

@@ -182,7 +182,7 @@ Built-in variables:
 | `{{displayName}}` | Display name. Defaults to a title-cased `packageName`; override with `template.vars.displayName`. |
 | `{{knowledgeCount}}` | Number of selected approved Markdown files. |
 | `{{knowledgeTimestamp}}` | Latest `timestamp` from selected approved Markdown, or `1970-01-01T00:00:00.000Z` when empty. |
-| `{{knowledge}}` | Concatenated selected approved Markdown bundle. |
+| `{{knowledge}}` | Concatenated consumer projection of selected approved pages, with path headings and without lifecycle metadata. |
 | `{{approvedKnowledge}}` | Alias for `{{knowledge}}`. |
 | `{{knowledgeItems}}` | Array of selected approved knowledge page metadata for loops. |
 | `{{knowledgeGroups}}` | Selected approved knowledge pages grouped by OKF root and first directory segment; each item also exposes `internal_collection`. |
@@ -322,7 +322,7 @@ Approved Markdown under `knowledge/` and its deterministic
   revision, or build. Do not copy a compact page as a new page without using a
   Context authoring command;
 - do not nest Context production metadata under `context`; fields such as
-  `context.sources` and `context.code_symbols` are not part of the 0.6 profile;
+  `context.sources` and `context.code_symbols` are not accepted production fields;
 - section provenance lives in `<!-- context:section ... source_ref="..." -->`
   comments. When a Section needs more than one citation, the CLI preserves the
   complete set in its adjacent `context:source_refs` block;
@@ -352,8 +352,9 @@ treat the complete `source_ref` as opaque. Production pages do not expose
 Candidate fingerprints, Indexer digests, or `code_origin`.
 
 `#span:` refs retain source snapshot line ranges for human review, diffing, and
-stable re-pinning. They resolve against committed file/lark document snapshots,
-not the code symbol index.
+stable re-pinning. They resolve against the stored file/Lark snapshot or the saved
+Note/Sessions Markdown, not the code symbol index. A session's optional commit/MR
+association stays in its source file; knowledge does not duplicate those fields.
 
 The kb package root may contain agent files such as `AGENTS.md` and `skills/`.
 The OKF-compatible surface is the selected `wikis/`, `guides/`, `rules/`, and
@@ -373,11 +374,11 @@ The OKF-compatible surface is the selected `wikis/`, `guides/`, `rules/`, and
 6. Writes output under `dist/<package-name>/`.
 
 `context-build-inventory.json` records what was selected and why. Each selected
-file includes `selected_by` entries such as `{ "kind": "collection" }` and a
-`production_metadata` object for selected page-level production fields. Child
-and relationship records use the inventory's canonical structure projection,
-`{ "kind": "okf_root" }`, `{ "kind": "include" }`, or
-`{ "kind": "default" }`. The inventory also exposes package-visible typed
+file includes `selected_by` entries such as `{ "kind": "collection" }`,
+`{ "kind": "okf_root" }`, `{ "kind": "include" }`, or `{ "kind": "default" }`,
+and a `production_metadata` object for selected page-level production fields.
+Child and relationship records use the inventory's canonical structure
+projection. The inventory exposes package-visible typed
 edges under `structure.edge_records`; these records are filtered to edges whose
 endpoints are present in the selected package. Use those edge records for
 relationship citations inside the package instead of assuming the workspace

package/docs/reference/project-api.md

@@ -26,14 +26,30 @@ state.
 
 ```ts
 const repo = source("20260901", "component-lib");
-const docs = source("product-docs", { type: "file" });
-const handbook = source("handbook", { type: "lark" });
-const everyRepo = allSources("repo");
+const docs = source("20260901/product-docs", { type: "file" });
+const handbook = source("20260901/handbook", { type: "lark" });
+const note = source("20260908/decision-context.md", { type: "note" });
+const session = source("20260908/design-discussion.md", { type: "sessions" });
+const everyRepo = allSources("repo"); // array: use ...everyRepo inside sources
+const everySession = allSources("sessions");
 ```
 
-References resolve against `sources/repo/index.yaml`,
-`sources/file/index.yaml`, and `sources/lark/index.yaml`. Register or refresh
-sources through `context source ...`; do not invent snapshot directories.
+Repo, file and Lark references resolve against their respective
+`sources/<type>/index.yaml`. Their names include the registration date and module.
+Register or refresh them through `context source ...`.
+
+Note and Sessions references resolve directly to saved Markdown under
+`sources/note/YYYYMMDD/topic.md` and `sources/sessions/YYYYMMDD/topic.md`.
+Use `context source import` to save them; they have no separate registry or
+capture phase. Explicitly include the desired typed references in `sources`,
+for example `sources: [note, session]`, or use `sources: [...everySession]`
+when all saved sessions are intended. Merely saving a source does not select it.
+
+A project's source list enables acquisition and initial selection; requirements
+and the selected Indexer's target/read scopes determine what it owns and may read.
+Supporting text does not require a separate page or primary Indexer. See
+[note preparation](../guides/note.md), [sessions preparation](../guides/sessions.md)
+and [knowledge updates](../guides/knowledge-updates.md).
 
 ## Capture phases
 
@@ -44,8 +60,55 @@ captureLark({ source: handbook });
 ```
 
 Capture only creates a deterministic readable snapshot. Classification,
-partitioning, authoring, Candidate creation, and Review belong to the selected
-Markdown Indexer.
+partitioning and authoring use the selected Provider's guidance. The CLI owns
+worksets, Candidate creation, Review application and delivery. Code, Markdown,
+Note and Sessions Providers can use authorized supporting documents without
+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:
+
+```ts
+import { fileURLToPath } from "node:url";
+import {
+  allSources, captureLark, defineProject, loadSourcesRegistry, source,
+} from "@c4a/context";
+
+const workspaceRoot = fileURLToPath(new URL("../", import.meta.url));
+const registry = await loadSourcesRegistry({ rootDir: workspaceRoot });
+const documents = registry.larks.map(entry =>
+  source(entry.name, { type: "lark" }),
+);
+
+export default defineProject({
+  sources: [...allSources("repo"), ...documents],
+  phases: documents.map(document => captureLark({ source: document })),
+  packages: [],
+});
+```
+
+Merge this pattern into existing declarations; preserve unrelated phases and
+package outputs. Adjust the root calculation if the entry lives elsewhere.
+Registry loading only reads local registrations; it does not fetch documents.
+
+- `sources/lark/index.yaml` owns document identities, URLs and titles. The project
+  selects those identities and declares capture settings. This example includes
+  future registrations too; use it only when the entire registered set is intended.
+- For a subset, filter registry entries by the intended namespace or names before
+  mapping. Apply exceptional resource settings within the same map instead of
+  declaring a second phase for the same document.
+- File documents use `registry.files`, `source(entry.name, { type: "file" })`
+  and `captureFile`. Group by actual processor needs; do not apply `mdxJsonDocs()`
+  indiscriminately to all file sources.
+- `allSources("lark")` selects a collection; its array contains a collection
+  reference, not individual documents. It neither expands capture phases nor
+  supports mapping its entries into `captureLark`.
+- 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.
 
 ## `customPhase`
 
@@ -65,6 +128,7 @@ kbPackage({
   name: "component-kb",
   template: "src/package-templates/kb",
   select: { collections: ["codeindex", "architecture"] },
+  site: { title: "Component knowledge", lang: "en-US", base: "/" },
 });
 
 llmsPackage({
@@ -77,10 +141,19 @@ llmsPackage({
 Package selection reads approved `knowledge/` only. `dist/` is generated and
 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
+`src/knowledge-map.yaml` independently of KB directories; see
+[Package Outputs](../guides/package-outputs.md#optional-static-documentation-website).
+
 ## Indexer registry
 
-The Agent and CLI maintain `src/indexers.yaml` through typed proposals and
-Review gates. Each selected Indexer binds requirements and scopes to one
+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.
@@ -90,6 +163,20 @@ current workflow Route when it is needed.
 
 ## Persistent versus runtime state
 
-Commit source registries, `src/index.ts`, `src/indexers.yaml`, package templates,
-and approved knowledge. Do not commit `.tmp/context-runtime/`; it contains
-recoverable execution state and is cleaned after a successful close.
+Source registries and snapshots, saved notes/summaries, project declarations,
+package templates and approved knowledge are durable inputs. Version them only
+when Git operations are authorized. Keep `.tmp/context-runtime/` out of Git;
+it contains unfinished execution state, not the sole source of recovery truth.
+
+`knowledge/structure.yaml` keeps shared page/source metadata and compact
+`processed_scopes` for completed requirement/source/module ranges. A partial
+update or failed build does not advance the whole range's processed version.
+Session commit/MR associations stay in the saved source frontmatter, not copied
+into every knowledge page. Use the CLI to adjust or roll back current work;
+do not edit these baselines or remove runtime files to simulate completion.
+
+## Source visual conversion preference
+
+Workspace `package.json` accepts `context.convertVisuals` (boolean, default `true`). Initialization writes it explicitly; older workspaces without the field also default to enabled. This lets a capable Author Agent attempt faithful structural diagram/table conversion. Explicit session instructions override the saved preference. It does not disable native table capture or existing Mermaid when false.
+
+Diagram style follows the workspace’s editable `AGENTS.md`; newly initialized workspaces default to minimal theme-aware diagrams without decorative colors. If the Agent cannot read the image or cannot preserve its meaning, it retains the original through the existing asset workflow. Source-based reuse avoids rereading unchanged visuals; file integrity and package hashes continue to reflect actual output changes.

package/docs/reference/template-variables.md

@@ -19,7 +19,7 @@ Approved pages: {{knowledgeCount}}
 Values support dotted paths:
 
 ```md
-{{context.package}}
+{{buildInventory.package.name}}
 ```
 
 ### Loop
@@ -102,7 +102,7 @@ Read node_modules/@c4a/context/docs/reference/template-variables.md.
 | `skillPath` | string | Final package-relative `SKILL.md` path for the Skill currently being rendered. Empty outside a Skill template. |
 | `knowledgeCount` | number | Selected approved Markdown file count. |
 | `knowledgeTimestamp` | string | Latest selected approved Markdown `timestamp`, or epoch when empty. |
-| `knowledge` | string | Concatenated selected approved Markdown bundle. Use carefully; it can be large. |
+| `knowledge` | string | Concatenated consumer projection of selected approved pages, with path headings. It omits lifecycle metadata and can be large. |
 | `approvedKnowledge` | string | Alias for `knowledge`. |
 | `knowledgeItems` | array | One record per selected approved Markdown page. |
 | `knowledgeGroups` | array | Selected pages grouped by OKF root and the first directory segment under that root; each item also exposes `internal_collection`. |
@@ -131,7 +131,7 @@ Each item contains:
 
 | Field | Meaning |
 |---|---|
-| `path` | Package-relative OKF path, for example `wikis/component-lib/symbol/button.md`. |
+| `path` | Package-relative OKF path, for example `guides/architecture/entity/button.md`. |
 | `sourcePath` | Approved knowledge path before OKF output mapping, for example `architecture/entity/button.md`. |
 | `approved_path` | Alias for `sourcePath`. |
 | `dist_path` | Alias for `path`. |
@@ -142,11 +142,11 @@ Each item contains:
 | `okf_root_path` | Final flat package-relative OKF root. |
 | `node_ref` | Stable NodeRef from approved frontmatter, for example `entity/button`. |
 | `view_ref` | Stable ViewRef from approved frontmatter, for example `architecture:entity/button`. |
-| `pathWithinCollection` | Path below the OKF root, for example `component-lib/symbol/button.md`. |
+| `pathWithinCollection` | Path below the OKF root, for example `architecture/entity/button.md`. |
 | `href` | Link relative to the template file currently being rendered. Use this in custom templates. |
 | `hrefFromTemplate` | Alias for `href`. |
-| `hrefFromPackageRoot` | Link from a package-root file such as `AGENTS.md`, for example `./wikis/component-lib/symbol/button.md`. |
-| `hrefFromCollectionIndex` | Link from the current OKF root index, for example `./component-lib/symbol/button.md` for a `wikis` item. |
+| `hrefFromPackageRoot` | Link from a package-root file such as `AGENTS.md`, for example `./guides/architecture/entity/button.md`. |
+| `hrefFromCollectionIndex` | Link from the current OKF root index, for example `./architecture/entity/button.md` for a `guides` item. |
 | `title` | Page title from frontmatter, or a title derived from the file name. |
 | `type` | OKF `type` from frontmatter. |
 | `description` | OKF `description` from frontmatter, when present. |
@@ -182,7 +182,7 @@ Each group contains:
 | `count` | Number of selected pages in this group. |
 | `hasIndex` | Whether the active package navigation policy generates `indexPath`. |
 | `has_index` | Alias for `hasIndex`. |
-| `indexPath` | OKF-root-aware index path, for example `wikis/component-lib/index.md`, `guides/component-lib/index.md`, or `rules/index.md` for a root group. |
+| `indexPath` | OKF-root-aware index path, for example `wikis/codeindex/index.md`, `guides/architecture/index.md`, or `rules/index.md` for a root group. |
 | `indexHrefFromTemplate` | Link from the template file currently being rendered to `indexPath`. Check `hasIndex` before rendering it. |
 | `indexHrefFromCollectionIndex` | Link from the OKF root index to `indexPath`. |
 | `items` | `knowledgeItems` in the group. |

package/index.d.ts

@@ -1,3 +1,5 @@
+import { type PackageSiteDefinition } from "./packageSite.js";
+export { packageSiteSchema, type PackageSiteDefinition } from "./packageSite.js";
 import type { PackageNavigationDefinition, PackageSelectDefinition } from "./contracts.js";
 import type { PhaseDefinition, PhaseResourceReference } from "./phases.js";
 import type { ProjectSourceDefinition } from "./sources.js";
@@ -109,6 +111,7 @@ export type KbPackageDefinition = BasePackageDefinition & {
     navigation: PackageNavigationDefinition;
     distribution?: PackageDistributionDefinition;
     assets?: PackageAssetDefinition;
+    site?: PackageSiteDefinition;
 };
 export type LlmsPackageDefinition = BasePackageDefinition & {
     kind: "package.llms";
@@ -131,9 +134,21 @@ export declare const kbPackage: (definition: {
     navigation?: Partial<PackageNavigationDefinition>;
     distribution?: PackageDistributionDefinition;
     assets?: PackageAssetDefinition;
+    site?: PackageSiteDefinition;
 }) => KbPackageDefinition;
 export declare const llmsPackage: (definition: {
     name: string;
     template: PackageTemplateInput;
     select?: PackageSelectDefinition;
 }) => LlmsPackageDefinition;
+export { projectIndexerPublicContractTable } from "./indexerPublicContractTable.js";
+export { processedScopeSchema, processedScopesSchema, processedScopeKey, readProcessedScopes, mergeProcessedScopes, processedVersionForScope, type ProcessedScope } from "./processedScopes.js";
+export { assertManagedDocumentName, assertManagedDocumentPath, discoverManagedDocuments } from "./managedSources.js";
+export type { ManagedDocumentSourceType, ManagedDocumentSourceEntry } from "./managedSources.js";
+export { sessionChangeSchema, sessionChangesSchema, readSessionChanges, writeSessionChanges } from "./sessionMetadata.js";
+export type { SessionChange } from "./sessionMetadata.js";
+export { indexerArticleKeySchema, indexerArticlePlanSchema, validateIndexerArticlePlan, indexerArticleSectionKey, validateIndexerPlannedArticles } from "./indexerArticlePlan.js";
+export type { IndexerArticlePlan } from "./indexerArticlePlan.js";
+export * from "./knowledgeMap.js";
+export * from "./indexerKnowledgeDependency.js";
+export * from "./indexerApprovedKnowledge.js";