@c4a/context 0.7.10-alpha.2 → 0.7.11

package/docs/getting-started.md

@@ -17,7 +17,7 @@ Use the dependency-install command returned by initialization if it differs.
 Initialization creates the project configuration, source directories, package
 templates and workspace rules. Read the generated `AGENTS.md`. It does not create
 an empty `src/indexers.yaml`: the later configuration Route supplies its schema
-and asks for the confirmed requirements with `indexers: []`.
+and asks for confirmed `requirements` only, without `protocol` or `indexers` keys.
 
 Run workspace commands inside this initialized directory. Route paths and
 `.tmp/` belong to this workspace, not the surrounding repository.
@@ -27,8 +27,8 @@ Run workspace commands inside this initialized directory. Route paths and
 This example uses a code module and a local documentation directory:
 
 ```bash
-context source add repo 20260901 --module component-lib --local ../component-lib
-context source add file 20260901 --module product-docs --local ../docs
+context source add repo 20260901 --module component-lib --local ../component-lib --configure
+context source add file 20260901 --module product-docs --local ../docs --configure
 ```
 
 Replace the date and paths with the actual inputs. Both commands register a
@@ -40,17 +40,21 @@ Do not exclude content merely because a filename looks old.
 For an authorized Lark document, registration instead looks like:
 
 ```bash
-context source add lark 20260901 --module handbook --doc-token "<actual-token>"
+context source add lark 20260901 --module handbook --doc-token "<actual-token>" --configure
 ```
 
-Use `captureLark()` for that registered document. Notes and conversation summaries
+`--configure` adds explicit source and default capture declarations to a simple
+project entry without fetching content. Existing custom settings are preserved;
+a `manual` configuration result asks for a focused edit, not a registration retry.
+Omit the flag when you only want registration. Notes and conversation summaries
 use `context source import`, without a source registry or capture phase. Read
 [note preparation](guides/note.md) or [sessions preparation](guides/sessions.md)
 for the actual input. Saving them alone does not start knowledge production.
 
 ## 3. Declare capture and output
 
-For the code and local-document example, `src/index.ts` contains:
+The generated source/capture declarations can be combined with the selected output
+configuration. For the code and local-document example, `src/index.ts` contains:
 
 ```ts
 import { captureFile, defineProject, kbPackage, source } from "@c4a/context";
@@ -76,27 +80,26 @@ see [Package Outputs](guides/package-outputs.md) for alternatives. Repo sources
 need no capture phase. For saved text, declare an explicit typed `source()` or
 `allSources()` selection as described in [Project API](reference/project-api.md).
 
-## 4. Follow requirements and Provider selection
+## 4. Plan the requested knowledge
 
 The Agent researches representative material, reuses the user's stated goals,
 and asks about missing information that would change the scope or useful output.
 Fully managed mode does not authorize guessing those answers. For substantial
 new work, the selected workflow provides an opening report under `.tmp/`, with
-scope, Provider choices and the first pages to expect. The Agent invites the user
-to read it before continuing unless that pause was explicitly waived; this is
-conversation coordination, not a new approval record.
-
-The configuration Route supplies the initial registry schema and guide. Declare
-requirements with no selected Indexers, re-read the Route, then submit Provider
-selection through its completion command. The shipped Code, Markdown, Note and
-Sessions Providers share the same lifecycle. A compatible business Provider may
-replace a default; installation alone does not enable it.
-
-Partition organizes the selected material into reader topics. Its task batches
-are planning work, not finished-page deliveries. After the outline is reviewed,
-Author writes complete pages, selected Composers contribute where applicable,
-and the CLI compiles Candidates. Do not create a second knowledge pipeline in
-`src/index.ts`.
+scope, relevant Skills and the first pages to expect. The report requires user
+confirmation before writing, including in managed mode.
+
+The configuration Route supplies the requirements schema and guide. Record the
+reader purpose and authorized sources in `src/indexers.yaml`. The Agent chooses
+relevant installed Code, Markdown, Note, Sessions or custom Indexer Skills during
+planning; their use is recorded in the temporary plan, not a persistent Provider
+registry. There is no separate Provider selection gate.
+
+Plan reader topics, reusing related existing articles. Keep small document or
+single-module tasks local; do not redesign the whole workspace. Once the report
+is approved, write Markdown and references in the returned task directories and
+submit their manifest. The CLI creates Candidates. Do not create a second
+knowledge pipeline in `src/index.ts`.
 
 ## 5. Review and deliver pages
 
@@ -109,9 +112,8 @@ Review shows readable titles, paths, summaries and content. Approval applies the
 pages to `knowledge/`; rejection or revision follows the current Route back to
 writing. `close` rebuilds `knowledge/structure.yaml` and verifies the approved
 knowledge without rewriting its prose. Build produces `dist/<package-name>/`.
-The first readable delivery normally contains 1–3 pages, followed by batches of
-30–50 pages or a smaller remaining tail. Each delivery completes review, close
-and build before continuing. These page counts do not count Partition tasks.
+Delivery scope follows the agreed task and current Route, not fixed page-count
+waves. Each delivery completes review, close and build before continuing.
 
 ## 6. Continue or update
 
@@ -133,8 +135,8 @@ explains their inputs, same-task adjustment and explicit rollback.
 
 - Fix a missing or stale source through the source commands returned by the Route.
 - Fix capture and output configuration in `src/index.ts`.
-- Fix requirements or Provider selection through the current configuration or
-  proposal Route; use its supplied schema rather than guessing payload fields.
+- Fix requirements through the current configuration Route; use its supplied
+  schema rather than adding Skill selections to the requirements file.
 - Correct page content through revision and Review. Change Provider guidance when
   the same writing problem affects future pages.
 - Keep temporary input files under this workspace's `.tmp/`. Never use `dist/`

package/docs/guides/agent-guide.md

@@ -38,24 +38,18 @@ those mechanical operations or invent state to declare a step complete.
 ## Authoring boundary
 
 `src/index.ts` owns source capture and package output. `src/indexers.yaml` owns
-knowledge requirements and Provider selection. Keep these responsibilities
+long-term reader requirements and authorized sources. Keep these responsibilities
 separate.
 
-Code, Markdown, Note, Sessions and compatible business Providers receive controlled worksets and return typed
-results. They do not write Candidate, Review, `knowledge/`, or `dist/` files.
-Context validates and persists their result before the next action consumes it.
-Initial Provider selection follows the same rule: use the requirements and
-CLI-bundled catalog in the current Action input, return only non-CLI visible
-Skill identities and semantic Indexer entries, and let the CLI perform routing,
-resolution, staging, validation, and atomic registry apply. External resolver
-results and non-allowlisted program decisions resume through subsequent
-`complete-current` Routes; do not invoke the low-level Provider commands.
-For Partition and Author steps, one Route may contain several independent
-`tasks`. Read the shared instructions once, read each task's Authorized Workset
-View, and return one `results[]` item for every task key in that batch. Submit
-the whole batch with the Route's single `context action complete-current`
-command. Use a workspace `.tmp/` JSON or YAML input file for a large payload,
-then submit with `--input <file>`; avoid long JSON through an interactive PTY.
+Code, Markdown, Note, Sessions and custom Indexer Skills guide source investigation
+and writing. Record relevant Skill use in the temporary plan's `indexer_usage`,
+not `src/indexers.yaml`; there is no Provider resolution or registry-apply step.
+Read shared instructions once, then the relevant task materials. Write Markdown
+and reference files in the returned Agent directory and submit the short manifest
+with the current `context action complete-current` command. Completed subsets
+may be submitted without repeating accepted tasks. The CLI validates and persists
+Candidates and owns Review, `knowledge/` and `dist/` writes. Do not fill retired
+workset `results[]` protocols or put full article bodies in command arguments.
 A shortened completion may point to `result_file` and `next_route.file`; read
 them before deciding what was accepted. If preparing the next Route fails,
 keep accepted results and use the supplied refresh action. Retry only tasks

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

@@ -28,7 +28,6 @@ production assignments. For example, replace the source and goals with the
 user's actual scope:
 
 ```yaml
-protocol: context.indexer.registry/v1
 requirements:
   - id: integration-guide
     purpose: Help application developers understand and integrate the system.
@@ -41,7 +40,6 @@ requirements:
     evidence_source_scope:
       targets:
         - source_ref: repo:sample
-indexers: []
 ```
 
 Use registered source identities, not guessed paths or URLs. Keep any confirmed

package/docs/guides/knowledge-updates.md

@@ -16,6 +16,49 @@ and continues through Review and delivery. Expression-only changes need no
 source capture or Parser. Preserve prior confirmed contributions; distinguish
 actual behavior, a confirmed decision, and a proposal that is not implemented.
 
+## Keep planning local to the change
+
+Before starting production, compare the proposed content with the workspace's
+reader purpose. For clearly unrelated anecdotes or personal rankings, briefly
+recommend leaving them out of the formal manual or saving them separately because
+they can dilute useful retrieval. Attribution alone does not make content relevant.
+This is advice, not a CLI gate: honor the user's informed choice without repeated
+objections, while preserving subjective attribution and normal Review.
+
+Registered repositories are not prerequisites for every new request. Restore only
+sources needed to investigate or write the current task, including unchanged code
+when its implementation needs checking. Notes, document-only work, wording edits
+and navigation changes do not require unrelated checkouts. Retained article
+references alone do not require restoring every referenced repository. Missing
+material remains a gap; it must not be treated as investigated or permanently
+excluded. Independent available material can proceed through planning and delivery.
+For required code, use `context source recovery-plan <registered-name> --format json`.
+Reuse a valid local checkout or obtain clone authorization for the returned pinned
+version, then submit the decision using the returned recovery command and schema.
+Do not restore all registered sources merely because a checkout is missing.
+
+For one or two documents or a clearly bounded module, retain the useful planning
+decision: add or revise which articles, and place them where readers expect them.
+Do not expand this into a whole-workspace taxonomy, full navigation redesign or
+multi-wave plan. Read related existing topics first and expand only as needed.
+One module can contain several topics; scope and ambiguity, not source count,
+determine how much investigation is useful.
+
+Reuse an approved stage's plan for in-scope additions through its existing amendment
+route. Keep completed work and unrelated pending investigation intact. If article
+targets are already decided before approval, the preparation route supports a
+known-task input to combine preparation and task creation. It still prepares
+navigation and retains report confirmation; it is not a bypass for new source
+authorization. Planning depth is an Agent judgment, not an additional CLI gate.
+
+For broad work, distinguish the whole requested outcome, the current batch and
+remaining capability families or document tasks. Entry-first knowledge should
+locate a checked file/symbol or source section and a concrete next step; a module
+name alone is not problem coverage. When merging or revising, preserve useful
+existing detail rather than replacing it with lookup advice. Review checks the
+promised reader task; task completion and navigation binding only describe the
+declared articles, not semantic coverage of all source material.
+
 ## First-task intake budget
 
 Before registration and capture, the Agent uses the user's task instructions and
@@ -56,7 +99,14 @@ progress under `.tmp/` never causes a version increase.
 Version recording runs at completed-scope delivery after Review, Close and package
 configuration/template approval, before the final build. The record response
 returns the next workspace Route, so no extra status call is needed. Build retries
-reuse the recorded version when formal content is unchanged. Intermediate batches
+reuse the recorded version when formal content is unchanged. If build preparation
+or rendering fails and formal corrections are needed, `version inspect` returns
+`reusable_version` for the current entry only while it has no successful build or
+publication receipt. Submit that same version with the complete iteration's title,
+changes and triggers, including the repair; this replaces the pending changelog
+entry rather than appending another version. Do not submit only the repair and
+lose the original delivery description. Once built or published, the version is
+sealed and further formal changes require an increase. Intermediate batches
 do not each receive a version.
 
 The workspace AGENTS.md and version-writing instructions require each entry's
@@ -85,7 +135,10 @@ actor:
 ```
 
 `actor` is optional; omit it to use local Git `user.name` when configured. Use a
-Lark display name only when explicitly known from the conversation. Trigger kinds
+Lark display name only when explicitly known from the conversation. Amending an
+unbuilt entry preserves its actor unless a replacement is explicitly supplied.
+If neither the conversation nor Git identifies the user, omit the actor and
+mention the missing identity in the delivery summary; never guess it. Trigger kinds
 are `initial`, `note`, `sessions`, `mr`, `module`, `document`, `navigation`,
 `repair`, `dist`, and `other`. Agent-written fields describe the actual diff and
 conversation; they must not expose credentials, raw transcripts or private IDs.
@@ -396,11 +449,61 @@ knowledge structure and packages.
 
 To move an approved page, use `context revise "<old path>" --move-to "<new path>"
 --instruction "<requested move and content changes>" --format json`. The new
-path stays in the same collection. The revision retains the page identity,
+path may use another supported knowledge collection. The revision retains the page identity,
 rebases outgoing links and updates incoming Markdown links at approval. A new
 subject name alone only needs a title/content revision; do not create duplicate
-pages. Retirement is a content decision: explain the inapplicable material and
-supported replacement before changing its page and referring navigation.
+pages. Changing a website group alone does not require moving or reclassifying an article.
+
+### Restructure existing knowledge
+
+Read the affected approved articles and current sources before deciding what to
+keep, deepen, split, merge, retain as history or retire. Reuse the current plan
+and remaining scope; a new article plan does not prove old content was preserved.
+Work by reader task, not source or menu count.
+
+For a split or merge, first approve destination content, then revise the original
+and incoming links. Preserve useful details until their destination is available.
+Same-page fragments use ordinary revision edits; cross-page work uses new/revision
+tasks and explicit retirement. Finish each coherent batch's content and navigation
+before delivery; inspect both new content and the old articles' disposition.
+
+Preview approved-page retirement with `context task retire --input <file> --format json`:
+
+```yaml
+reason: These reader tasks are now covered by the approved guide.
+targets:
+  - path: architecture/old-guide.md
+    replacement: sop/current-guide.md
+```
+
+`replacement` is optional and must already be approved, outside the retirement set.
+Use several targets for a batch. Read affected files and blockers, then execute
+the returned digest-bound apply command within the user's authorization; do not
+ask for another confirmation when that retirement is already authorized.
+`context task retire --schema --format yaml` describes the input.
+
+Retirement removes selected Markdown and structure entries together, updates
+page-level incoming Markdown links to explicit replacements, and rebinds page
+navigation or removes retired navigation targets while retaining groups.
+Repair fragment links explicitly first: the CLI cannot infer where a split moved
+a paragraph. Without a replacement, repair incoming links before applying.
+Finish active drafts/revisions first; unfinished production targeting a selected
+page must be finished or amended rather than discarded.
+
+Follow status and the normal close/version/build flow before delivery. Sources
+and shared assets are not deleted. The response provides a temporary restore
+input for the existing rollback preview, including exact previous article,
+structure and modified navigation/link bytes. Retain that input or a Git baseline
+if restoration is needed after temporary cleanup. Retry an interrupted apply
+with the same input and digest; never delete runtime files to recover. Later
+conflicting edits require inspection instead of blind rollback.
+
+Historical pages with continuing reader value should normally retain their
+applicable version. Source read failure, shorter new text or a changed menu is
+not sufficient reason to retire an article.
+Retirement does not narrow the registered production scope. If the user also
+excludes the underlying topic from future work, record that through the existing
+requirements/exclusion flow rather than assuming file removal changes the goal.
 
 ### Adjust inputs while a local update is unfinished
 

package/docs/guides/package-outputs.md

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

package/docs/guides/workspace-prepare.md

@@ -36,6 +36,23 @@ reports, unique material, unknown files and modified checkouts unless their
 specific loss is authorized. Do not delete locks, transaction records or active
 tool directories. Empty task directories can remain.
 
+Prefer cleanup after successful delivery, not immediately after close: version
+recording, build and retries may still need the current task. Completed production
+drafts and Review state are removed by delivery cleanup. Do not invoke
+`task resume` merely to make a completed workspace advance; it starts a new task
+and requires an actual new user request.
+
+Keep repository checkouts referenced by registered sources, including fixed
+commits: removing them can force a costly clone before the next update. Keep
+pending telemetry and source-region baselines; losing the latter reduces the
+ability to distinguish relocated text from changed text. Debug and historical
+views may be archived or removed after diagnosis when no operation is active,
+but unknown Agent files are not automatically disposable.
+
+After all scratch state is lost, an existing build receipt defaults the workspace
+to waiting for an explicit new task. This does not restore lost drafts or prove
+sources and outputs are current. Use the recovery checks below before resuming.
+
 ## Restore usable sources
 
 For repositories, run `context source recovery-plan --format json` and read

package/docs/reference/project-api.md

@@ -4,8 +4,8 @@ The project has two durable declarations with separate responsibilities:
 
 - `src/index.ts`: source references, document capture, custom non-knowledge
   orchestration, and package outputs.
-- `src/indexers.yaml`: knowledge requirements, Provider selection, target/read
-  scopes, profiles, and Provider customization.
+- `src/indexers.yaml`: long-term reader requirements, authorized target/supporting
+  sources and confirmed exclusions. Skill choices belong to the temporary plan.
 
 Do not describe the same knowledge transformation in both files.
 
@@ -53,6 +53,19 @@ and [knowledge updates](../guides/knowledge-updates.md).
 
 ## Capture phases
 
+For ordinary acquisition, add `--configure` to `context source add repo`, `file`,
+`lark` or `batch`. The command registers the selected inputs and generates explicit
+source references and default document capture phases in `src/index.ts`. It does
+not fetch content, select other registrations or change package outputs.
+
+Generation supports a literal `defineProject` with literal source/phase arrays
+and recognizable SDK calls. Existing capture settings are preserved, repeated
+registration is idempotent, and custom/dynamic entries remain untouched with a
+`configuration.status: manual` hint. Registration is still saved; edit only the
+needed declarations through the normal configuration path. For special processors
+or resource options, configure them before following the capture Route. Omitting
+`--configure` keeps registration-only behavior.
+
 ```ts
 captureFile({ source: docs });
 captureFile({ source: docs, processor: mdxJsonDocs() });
@@ -67,24 +80,27 @@ creating a second capture or knowledge pipeline.
 
 ### Batch capture from the source registry
 
-When all registered Lark documents are intended for this project and share capture
-settings, read the registry once instead of copying its module names into
-`src/index.ts`. For the standard `src/index.ts` entry:
+For documents with shared capture settings, prefer registry-driven configuration
+over repeating source declarations and capture calls, even for two documents.
+Select the task's intended registrations first. The example below assumes all
+registered Lark documents are in scope, with the standard `src/index.ts` entry:
 
 ```ts
 import { fileURLToPath } from "node:url";
 import {
-  allSources, captureLark, defineProject, loadSourcesRegistry, source,
+  captureLark, defineProject, loadSourcesRegistry, source,
 } from "@c4a/context";
 
 const workspaceRoot = fileURLToPath(new URL("../", import.meta.url));
 const registry = await loadSourcesRegistry({ rootDir: workspaceRoot });
+// For a subset, filter registry.larks by the authorized namespace/names here.
 const documents = registry.larks.map(entry =>
   source(entry.name, { type: "lark" }),
 );
 
 export default defineProject({
-  sources: [...allSources("repo"), ...documents],
+  sources: documents,
+  // Shared settings, independent source identities and capture phases.
   phases: documents.map(document => captureLark({ source: document })),
   packages: [],
 });
@@ -109,6 +125,10 @@ Registry loading only reads local registrations; it does not fetch documents.
 - The map declares one phase per document. It does not fetch URLs, change capture
   permissions, or request parallel execution. Run the declared phases through the
   existing CLI flow so each document retains independent refresh and retry behavior.
+  This reduces configuration repetition, not the number of capture operations.
+- Capture boundaries do not dictate article boundaries. During planning and
+  writing, combine related captured documents around reader tasks when useful;
+  do not create one article or a complete production cycle per source by default.
 
 ## `customPhase`
 
@@ -128,7 +148,22 @@ kbPackage({
   name: "component-kb",
   template: "src/package-templates/kb",
   select: { collections: ["codeindex", "architecture"] },
-  site: { title: "Component knowledge", lang: "en-US", base: "/" },
+  site: {
+    title: "Component knowledge",
+    lang: "en-US",
+    base: "/",
+    home: {
+      title: "Component knowledge",
+      slogan: "Build with the public contract in view",
+      description: "Browse components, usage guidance and implementation boundaries.",
+      resources: [{
+        title: "Project workspace",
+        description: "Open the repository that maintains this knowledge.",
+        href: "https://example.com/project",
+        featured: true,
+      }],
+    },
+  },
 });
 
 llmsPackage({
@@ -144,22 +179,26 @@ may be rebuilt; it is not an authoring source.
 `kbPackage.site` optionally adds a VitePress website at `dist/<base>-site/` in
 the same build, beside the KB directory. `<base>` removes one trailing `-kb`
 from the package name, if present. Omit it for KB-only output. It accepts `title`, `description`,
-`lang` and a deployment `base` path. Knowledge map is projected from
+`lang`, a deployment `base` path, and an optional `home` presentation. `home`
+accepts `title`, `slogan`, `description`, hero `actions`, and `resources` shown
+below the generated site map. Each resource needs an `href`, a copyable
+`command`, or both. Omit unknown resources; the builder never invents service
+or repository links. Knowledge map is projected from
 `src/knowledge-map.yaml` independently of KB directories; see
 [Package Outputs](../guides/package-outputs.md#optional-static-documentation-website).
 
-## Indexer registry
+## Knowledge requirements and Indexer Skills
 
-When this file is absent, the configuration Route supplies the initial schema:
-write confirmed `requirements` with `indexers: []`, then re-evaluate. The Provider
-selection Action supplies its own completion schema; that payload is not the
-configuration file. Subsequent changes use typed proposals and applicable gates. Each selected Indexer binds requirements and scopes to one
-primary Provider, with optional declared layers or composers. Provider code
-must return the current Indexer result protocol; it must not write Candidate,
-knowledge, or Review files directly.
+When `src/indexers.yaml` is absent, the configuration Route supplies its schema.
+Write `requirements` only; do not add `protocol`, `indexers`, Provider selections
+or profiles. Re-evaluate after changing confirmed requirements.
 
-Detailed Provider protocol and customization guidance is selected by the
-current workflow Route when it is needed.
+Installed Indexer Skills guide investigation and writing. Relevant Skill choices
+and optional configuration use `indexer_usage` in the temporary production plan,
+not this durable file. There is no separate Provider selection or resolution gate.
+The Agent writes task drafts and reference files under the returned temporary
+directory; the CLI accepts them and owns Candidate, Review and formal output.
+See [Indexer guidance](../guides/indexer-provider-and-customization.md).
 
 ## Persistent versus runtime state
 

package/index.js

@@ -10889,11 +10889,35 @@ var coerce = {
 };
 var NEVER = INVALID;
 // src/packageSite.ts
+var siteHrefSchema = exports_external.string().trim().min(1).refine((value) => /^(?:https?:\/\/|mailto:|\/(?!\/)|#)/u.test(value), "Use an https URL, mailto URL, root-relative path, or page anchor");
+var packageSiteHomeActionSchema = exports_external.object({
+  text: exports_external.string().trim().min(1),
+  link: siteHrefSchema,
+  theme: exports_external.enum(["brand", "alt"]).optional()
+}).strict();
+var packageSiteHomeResourceSchema = exports_external.object({
+  title: exports_external.string().trim().min(1),
+  description: exports_external.string().trim().min(1).optional(),
+  href: siteHrefSchema.optional(),
+  action: exports_external.string().trim().min(1).optional(),
+  command: exports_external.string().trim().min(1).optional(),
+  featured: exports_external.boolean().optional()
+}).strict().refine((value) => value.href !== undefined || value.command !== undefined, {
+  message: "A homepage resource requires href or command"
+});
+var packageSiteHomeSchema = exports_external.object({
+  title: exports_external.string().trim().min(1).optional(),
+  slogan: exports_external.string().trim().min(1).optional(),
+  description: exports_external.string().trim().min(1).optional(),
+  actions: exports_external.array(packageSiteHomeActionSchema).optional(),
+  resources: exports_external.array(packageSiteHomeResourceSchema).optional()
+}).strict();
 var packageSiteSchema = exports_external.object({
   title: exports_external.string().trim().min(1).optional(),
   description: exports_external.string().optional(),
   lang: exports_external.string().min(1).default("en-US"),
-  base: exports_external.string().regex(/^\/(?:[a-zA-Z0-9_-]+\/)*$/, "Use / or a slash-delimited deployment path, such as /docs/").default("/")
+  base: exports_external.string().regex(/^\/(?:[a-zA-Z0-9_-]+\/)*$/, "Use / or a slash-delimited deployment path, such as /docs/").default("/"),
+  home: packageSiteHomeSchema.optional()
 }).strict();
 function normalizePackageSite(value) {
   return value === undefined ? undefined : packageSiteSchema.parse(value);
@@ -15959,7 +15983,7 @@ function validateIndexerArtifactResult(input) {
       capability_group_ref: group.capability_group_ref,
       member_ids: group.member_evidence.map((member) => member.member_id)
     })),
-    material_gap_proposal_refs: result.material_question_proposals.map((proposal) => proposal.proposal_ref)
+    material_gap_proposal_refs: result.question_target_dispositions.flatMap((disposition) => disposition.state === "material-gap" ? [disposition.material_question_proposal_ref] : [])
   });
   const targets = new Map(input.allowed_question_targets.map((target) => [target.question_target_key, target.question_ref]));
   assertUnique(result.question_target_dispositions.map((item) => item.question_target_key), "question targets");

package/indexerArtifactPolicy.d.ts

@@ -10,11 +10,11 @@ export declare const indexerArtifactPolicyEligibilitySchema: z.ZodObject<{
         path: z.ZodString;
         value: z.ZodType<IndexerJson, z.ZodTypeDef, IndexerJson>;
     }, "strict", z.ZodTypeAny, {
-        value: IndexerJson;
         path: string;
-    }, {
         value: IndexerJson;
+    }, {
         path: string;
+        value: IndexerJson;
     }>, "many">;
     provider_supported_variants: z.ZodArray<z.ZodEffects<z.ZodString, string, string>, "many">;
     eligible_variants: z.ZodArray<z.ZodObject<{
@@ -71,8 +71,8 @@ export declare const indexerArtifactPolicyEligibilitySchema: z.ZodObject<{
     profile_id: string;
     profile_contract_digest: string;
     canonical_facts: {
-        value: IndexerJson;
         path: string;
+        value: IndexerJson;
     }[];
     provider_supported_variants: string[];
     eligible_variants: {
@@ -94,8 +94,8 @@ export declare const indexerArtifactPolicyEligibilitySchema: z.ZodObject<{
     profile_id: string;
     profile_contract_digest: string;
     canonical_facts: {
-        value: IndexerJson;
         path: string;
+        value: IndexerJson;
     }[];
     provider_supported_variants: string[];
     eligible_variants: {