@open-agent-toolkit/cli 0.2.73 → 0.2.75

package/dist/validation/project-state.js

@@ -7,8 +7,15 @@ const EXPLAINER_SOURCES = [
     'interactive',
     'kickoff_prompt',
     'autonomous_policy',
+    'capability_probe',
+    'failed_attempt',
+];
+const EXPLAINER_DECISION_KEYS = [
+    'decision',
+    'source',
+    'decided_at',
+    'failed_attempt_evidence',
 ];
-const EXPLAINER_DECISION_KEYS = ['decision', 'source', 'decided_at'];
 const EXPLAINER_ALLOWED_PAIRS = {
     oat_project_explainer: new Set([
         'generate:interactive',
@@ -19,6 +26,8 @@ const EXPLAINER_ALLOWED_PAIRS = {
         'generate:interactive',
         'skip:interactive',
         'generate:autonomous_policy',
+        'skip:capability_probe',
+        'skip:failed_attempt',
     ]),
 };
 const ISO_TIMESTAMP_PATTERN = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d+)?(?:Z|[+-]\d{2}:\d{2})$/;
@@ -60,13 +69,15 @@ function readExplainerDecision(frontmatter, key, errors) {
     if (keys.some((entry) => !EXPLAINER_DECISION_KEYS.includes(entry))) {
         errors.push({
             code: 'invalid-explainer-decision-keys',
-            message: `${key} must contain only decision, source, and decided_at`,
+            message: `${key} contains an unsupported decision field`,
         });
         return null;
     }
     const decision = record.decision;
     const source = record.source;
     const decidedAt = record.decided_at;
+    const hasFailedAttemptEvidence = Object.hasOwn(record, 'failed_attempt_evidence');
+    const failedAttemptEvidence = record.failed_attempt_evidence;
     let valid = true;
     if (typeof decision !== 'string' ||
         !EXPLAINER_DECISIONS.includes(decision)) {
@@ -80,7 +91,7 @@ function readExplainerDecision(frontmatter, key, errors) {
         !EXPLAINER_SOURCES.includes(source)) {
         errors.push({
             code: 'invalid-explainer-source',
-            message: `${key}.source must be interactive, kickoff_prompt, or autonomous_policy`,
+            message: `${key}.source must be interactive, kickoff_prompt, autonomous_policy, capability_probe, or failed_attempt`,
         });
         valid = false;
     }
@@ -101,14 +112,42 @@ function readExplainerDecision(frontmatter, key, errors) {
         });
         valid = false;
     }
+    const isFailedAttempt = key === 'oat_project_recap' &&
+        decision === 'skip' &&
+        source === 'failed_attempt';
+    if ((isFailedAttempt &&
+        !isFailedAttemptEvidenceLocator(failedAttemptEvidence)) ||
+        (!isFailedAttempt && hasFailedAttemptEvidence)) {
+        errors.push({
+            code: 'invalid-failed-attempt-evidence',
+            message: `${key}.failed_attempt_evidence is required only for skip/failed_attempt and must name explainers/<run-slug>/manifest.json or failure.json`,
+        });
+        valid = false;
+    }
     return valid
         ? {
             decision: decision,
             source: source,
             decided_at: decidedAt,
+            ...(isFailedAttempt && {
+                failed_attempt_evidence: failedAttemptEvidence,
+            }),
         }
         : null;
 }
+function isFailedAttemptEvidenceLocator(value) {
+    if (typeof value !== 'string')
+        return false;
+    const parts = value.split('/');
+    const runSlug = parts[1];
+    const fileName = parts[2];
+    return (parts.length === 3 &&
+        parts[0] === 'explainers' &&
+        typeof runSlug === 'string' &&
+        /^[a-z0-9][a-z0-9._-]*$/.test(runSlug) &&
+        typeof fileName === 'string' &&
+        ['manifest.json', 'failure.json'].includes(fileName));
+}
 function readKind(frontmatter) {
     const rawKind = readStringField(frontmatter, 'oat_kind');
     return rawKind && isProjectStateKind(rawKind) ? rawKind : 'implementation';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@open-agent-toolkit/cli",
-  "version": "0.2.73",
+  "version": "0.2.75",
   "private": false,
   "description": "Open Agent Toolkit CLI",
   "homepage": "https://github.com/voxmedia/open-agent-toolkit/tree/main/packages/cli",
@@ -34,7 +34,7 @@
     "ora": "^9.0.0",
     "yaml": "2.8.2",
     "zod": "^3.25.76",
-    "@open-agent-toolkit/control-plane": "0.2.73"
+    "@open-agent-toolkit/control-plane": "0.2.75"
   },
   "devDependencies": {
     "@types/node": "^22.10.0",

package/assets/docs/contributing/explainer-kit-verification.md

@@ -1,133 +0,0 @@
----
-title: Verifying Explainer Kit
-description: 'Maintainer runbook for semantic golden cases, temporary real-Chromium evidence, and release validation.'
----
-
-# Verifying Explainer Kit
-
-Explainer Kit uses portable behavioral goldens and a real-browser release gate.
-The goal is not pixel identity: output may change markup, spacing, and
-composition when it preserves the same meaning, topology, interactions, and
-evidence quality.
-
-## Golden cases
-
-The suite under
-`.agents/skills/explainer-kit/tests/fixtures/golden/` contains three
-portable semantic cases:
-
-| Case                           | What it proves                                             |
-| ------------------------------ | ---------------------------------------------------------- |
-| `simple`                       | Viewport-sized lead evidence and a cohesive baseline recap |
-| `non-linear`                   | Exact branch, fan-in, and cycle preservation               |
-| `explainer-authoring-redesign` | Archive-only rebuild from a dense completed project record |
-
-Every case retains only its descriptor, source input, and content-addressed
-source record. The three cases share one rubric. Generated artifacts, browser
-evidence, screenshots, manifests, catalogs, and review results stay in a
-temporary test directory and are never committed. Paths are
-repository-relative; machine roots, home-relative paths, `file://` URLs,
-Windows drive paths, and UNC paths are rejected.
-
-## Prerequisites
-
-- Install workspace dependencies.
-- Ensure the repository-supported Chromium runtime is installed and launchable.
-- Run from the repository root.
-
-The end-to-end benchmarks require an actual launched Chromium session. A
-deterministic fixture session is valid only for bounded unit/integration tests
-and cannot satisfy a golden production path.
-
-## Run the golden suite
-
-```bash
-node --test \
-  .agents/skills/explainer-kit/tests/golden-conformance.test.mjs
-```
-
-A passing run proves:
-
-- one planner-owned hub, architecture view, and deck;
-- source and terminology cohesion;
-- exact topology and catalog parity;
-- mobile, tablet, and desktop Chromium evidence;
-- one independent critic invocation; and
-- a passing terminal review without correction.
-
-The focused integration suites below separately exercise the one-correction
-ceiling.
-
-The suite recomputes semantic-input hashes, grounds every claim in retained
-source evidence, and evaluates the shared rubric against live runtime output.
-A prose claim or status label without runtime proof does not pass.
-
-The existing three-case, 27-capture golden suite is intentionally unchanged by
-the prose-led visual-review work. Simplifying it is a separate follow-up: first
-audit each case's unique coverage, runtime cost, and flakiness, then remove or
-replace fixtures only with evidence that the same behavior remains protected.
-
-## Inspect generated evidence
-
-The suite materializes each case's runtime package under its temporary working
-directory, validates it, and removes it at test completion. Add a local
-debugger breakpoint or temporarily disable cleanup when diagnosing a failure;
-do not add generated runtime output to the fixture directories.
-
-## Focused integrity suites
-
-Use these when changing browser identity, immutable evidence, resume, or archive
-contracts:
-
-```bash
-node --test \
-  .agents/skills/explainer-kit/tests/records.test.mjs \
-  .agents/skills/explainer-kit/tests/run.integration.test.mjs
-
-node --test \
-  .agents/skills/explainer-kit/tests/browser-runtime.test.mjs \
-  .agents/skills/explainer-kit/tests/qa.test.mjs \
-  .agents/skills/explainer-kit/tests/contracts.test.mjs \
-  .agents/skills/explainer-kit/tests/durability.test.mjs \
-  .agents/skills/explainer-kit/tests/rebuildability.test.mjs
-
-pnpm --filter @open-agent-toolkit/cli exec vitest run \
-  src/commands/project/archive/archive-utils.test.ts \
-  src/release/public-package-contract.test.ts
-
-node --test tools/smoke/explainer-kit/*.test.mjs
-```
-
-## Release gate
-
-The required publishable-package gate is:
-
-```bash
-pnpm release:validate
-```
-
-It validates all five lockstep public package tarballs and then runs the bounded
-curated-style/template matrix in real Chromium. The visual gate retains 65
-machine-readable viewport, clipping, motion, keyboard, no-JavaScript, and print
-measurements. Missing Chromium or untrusted retained evidence fails closed.
-
-For the full repository closeout, also run the standard checks documented in
-the root `AGENTS.md`:
-
-```bash
-pnpm check
-pnpm type-check
-pnpm test
-pnpm build
-pnpm run check:skill-bumps
-pnpm release:check-versions
-pnpm release:validate
-pnpm build:docs
-pnpm lint
-pnpm format
-git diff --check
-```
-
-Do not treat an isolated transient timeout as a product pass or failure without
-reproducing the failing test. Preserve the exact-head successful rerun evidence
-used for release closure.

package/assets/docs/workflows/skills/explainer-kit-providers.md

@@ -1,155 +0,0 @@
----
-title: Explainer Provider Integration
-description: 'Provider-neutral planner, author, browser-session, and visual-critic contracts for Explainer Kit integrators.'
----
-
-# Explainer Provider Integration
-
-Explainer Kit keeps model and browser providers outside its retained request
-contracts. Integrators supply executable seams in process or through validated
-module exports; the core owns schemas, evidence binding, and terminal outcomes.
-
-For recipes, authoring behavior, themes, and lifecycle policy, start with
-[Explainer Kit](explainer-kit.md).
-
-## Provider boundaries
-
-Use exactly one form for each required role:
-
-| Role               | Direct input     | Module-path input          | Required export                     |
-| ------------------ | ---------------- | -------------------------- | ----------------------------------- |
-| Set planning       | `planSet`        | `planSetModulePath`        | `planSet` function                  |
-| Artifact authoring | `author`         | `authorModulePath`         | `author` function                   |
-| Browser evidence   | `browserSession` | `browserSessionModulePath` | branded `browserSession` descriptor |
-| Whole-set review   | `visualCritic`   | `visualCriticModulePath`   | `visualCritic` function             |
-
-`project-recap` requires all four roles. Other recipes require the author and
-use their recipe-specific planning behavior. Direct-plus-module conflicts,
-missing files, and invalid exports fail at the adapter boundary before core
-execution.
-
-Do not place browser or visual-review providers in `coreOptions`. Executable
-callbacks, descriptors, and module paths are transient and never enter
-`ExplainerRunRequestV1`, `run-request.json`, or immutable package hashes.
-
-## Set planner
-
-The provider-neutral `planSet` callback runs once after fact reconciliation and
-before any author callback. It returns the complete portfolio and one shared
-claim ledger.
-
-For a new project recap, the portfolio must contain the required navigational
-hub. A diagram, deck, or deep dive is optional and must use a recipe-licensed
-profile, remain inside recipe and per-profile limits, and answer a distinct
-reader question with source evidence and a medium rationale. Version 1 recap
-plans remain readable for replay with their historical three-artifact floor.
-Duplicate identities, undeclared sources, conflicting shared terms, and
-unjustified optionals fail validation.
-
-Every author request receives the immutable set context and its matching planned
-artifact. Authors cannot add, remove, replace, or rename portfolio entries.
-
-## Artifact author
-
-The core invokes `author` once per planned artifact with
-`explainer-kit.author-request/v3`. Version 2 requests remain readable for
-replay. The current request contains:
-
-- artifact identity, type, and authoring path;
-- the versioned brief and bundled medium-specific guidance;
-- reconciled facts and the shared set context;
-- the matching planned artifact;
-- the resolved theme; and
-- the bundled shell for artistic HTML; and
-- canonical artifact links ending in explicit `index.html` paths.
-
-Return `explainer-kit.author-result/v2` with exactly one of
-`content.markdown` or `content.html` and non-secret provenance. The core
-validates source overlap, path ownership, script identity, and structural
-contracts after the callback returns.
-
-The author, fact critic, browser probe, and visual critic must have distinct
-callback identities. One provider implementation may back multiple roles, but
-the adapter still requires separate executable boundaries.
-
-## Trusted browser session
-
-Create a direct session with the compatible core:
-
-```js
-const browserSession = await core.createBrowserProbeSession();
-
-try {
-  await runOatExplainer(request, {
-    planSet,
-    author,
-    browserSession,
-    visualCritic,
-  });
-} finally {
-  await browserSession.close();
-}
-```
-
-The factory launches Chromium and derives the runtime name and version from the
-actual browser instance. A private in-memory brand prevents a plain object with
-caller-authored `{name, version}` metadata from impersonating a trusted
-session. Module providers export the already branded descriptor as
-`browserSession`, not a bare callback.
-
-For unattended project recaps, the core chooses 320, 768, and 1440 widths and
-requires default-scenario PNGs. It validates the PNG signature, decoded
-dimensions, and pixel payload, then writes paired
-`explainer-kit.browser-evidence/v2` metrics. Every record retains:
-
-- launched Chromium name and version;
-- fixed capture settings;
-- one derived capture identity;
-- viewport and scenario;
-- screenshot path and byte binding; and
-- measured overflow, clipping, readability, motion, keyboard, deck, and theme
-  behavior.
-
-All records in one review chain must carry the same runtime and capture
-identity. Deterministic fixture sessions are explicit test helpers and are
-rejected by unattended production recap paths.
-
-## Whole-set visual critic
-
-The `visualCritic` receives one
-`explainer-kit.visual-review-request/v1` plus a confined evidence reader. The
-request binds:
-
-- every rendered artifact and its exact content hash;
-- every viewport-matched screenshot and metrics hash;
-- cohesion observations from the shared ledger; and
-- the trusted browser runtime and capture identity.
-
-Return `explainer-kit.visual-review-result/v1` with the exact request identity,
-all reviewed artifact IDs, structured findings, and one disposition:
-
-- `pass` completes the review gate;
-- `correct` requests one bounded correction and one final review; or
-- `fail` terminates the gate.
-
-Judge typography, hierarchy, composition, density, medium leverage, template
-repetition, diagram semantics, and cross-artifact cohesion from the bound
-browser evidence. `pass` means no required correction remains. `correct`
-findings name concrete artifact-scoped actions that can be completed in the
-single bounded correction round. Keep this judgment in prose; do not invent
-numeric scores or geometry thresholds.
-
-The critic must not mutate rendered files or evidence. The core revalidates all
-bound bytes after each callback.
-
-## Terminal behavior
-
-There is never a second correction or third review. Missing, malformed, forged,
-stale, cross-record-mismatched, or mutated evidence; a thrown callback; a
-`fail`; or an unresolved correction produces `built-needs-review`.
-
-That outcome retains available artifacts and review evidence for diagnosis, but
-invokes neither durability nor publication. It cannot be finalized, archived,
-attested, or pushed as a successful recap.
-
-See [Troubleshooting](../../reference/troubleshooting.md) for recovery steps.

package/assets/skills/explainer-kit/briefs/deep-dive.md

@@ -1,35 +0,0 @@
-# Deep-dive author brief
-
-## Audience
-
-Write for a technical reader who already understands the parent project recap
-and needs enough detail to evaluate or work on one subsystem.
-
-## Voice
-
-Be precise without becoming encyclopedic. Start with the question this page
-answers and the boundary it covers. Use evidence tables, code or data examples,
-and diagrams where they reduce explanation time. Define assumptions and call
-out unresolved behavior.
-
-## Section intent
-
-Structure the page around:
-
-1. the subsystem's purpose and boundary;
-2. its inputs, outputs, and dependencies;
-3. the important execution or data flow;
-4. the decisions and trade-offs that shaped it;
-5. failure modes, operational concerns, and validation evidence.
-
-## Floor
-
-Produce a self-contained Markdown explainer that adds information not already
-present in the parent hub. Include at least one structured evidence block and
-link claims back to durable sources when available.
-
-## Expansion license
-
-Depth is licensed, repetition is not. Add inline diagrams, examples, tables,
-and callouts when they make a difficult mechanism easier to verify. Keep
-adjacent topics in the parent hub or a separate justified artifact.

package/assets/skills/explainer-kit/briefs/project-page.md

@@ -1,38 +0,0 @@
-# Program project-page author brief
-
-## Audience
-
-Write for a program reader who followed a link from the program recap and now
-needs the evidence and decisions for one project.
-
-## Voice
-
-Keep program terminology and statuses consistent with the parent hub. Be
-specific about this project's scope, dependencies, and outcome. Avoid
-repeating program-wide context unless it changes how this project should be
-understood.
-
-## Section intent
-
-Cover:
-
-- the project's objective and place in the program;
-- delivered scope and current status;
-- architecture or dependency details unique to this project;
-- load-bearing decisions and their consequences;
-- validation evidence and known limits;
-- remaining work, owner or owning group, and next action.
-
-## Floor
-
-Produce a self-contained Markdown explainer with a clear route back to the
-program story. Include at least one structured table for delivery or
-validation evidence and enough source references for a reader to verify the
-status.
-
-## Expansion license
-
-Use inline diagrams, callouts, and evidence blocks when this project's
-substance warrants them. Stay within the single-project boundary. If a detail
-applies across the program, improve the parent recap instead of duplicating it
-here.

package/assets/skills/explainer-kit/briefs/supporting-diagram.md

@@ -1,28 +0,0 @@
-# Supporting diagram author brief
-
-## Audience
-
-Create a visual for a reader who understands the parent explainer but needs one
-boundary, flow, dependency, or state transition made unmistakable.
-
-## Voice and visual intent
-
-Lead with the visual. Use short labels, consistent terminology, and a clear
-reading direction. Make the title state the question the diagram answers.
-Include a concise legend or annotation only when the visual vocabulary is not
-self-evident.
-
-## Floor
-
-Compose a complete, accessible HTML diagram from the supplied
-`diagram-shell`. Preserve its required anchors, theme tokens, and core scripts.
-The diagram must have an explicit title, meaningful labels, a visible primary
-flow, and a short text explanation that remains useful to screen-reader users.
-Do not encode essential meaning through color alone.
-
-## Expansion license
-
-Elaborate the shell's non-script markup and SVG freely when needed for
-legibility. Keep the scope to one coherent question. If the visual needs
-several unrelated panels or long prose to make sense, recommend a deep-dive
-instead.

package/assets/skills/explainer-kit/briefs/walkthrough-deck.md

@@ -1,35 +0,0 @@
-# Walkthrough deck author brief
-
-## Audience
-
-Build for a live or self-guided walkthrough with teammates who need the project
-story in a deliberate sequence rather than a reference document.
-
-## Voice and sequence
-
-Use one claim per slide and a clear narrative arc: context, change, system,
-evidence, outcome, next action. Keep text brief enough to scan at presentation
-distance. Use diagrams, comparisons, and evidence excerpts instead of
-shrinking prose to fit.
-
-## Floor
-
-Compose a complete HTML deck from the supplied `deck-shell`. Preserve required
-anchors, theme tokens, keyboard navigation, progress behavior, print behavior,
-and all core scripts exactly. Include:
-
-- an opening frame that states the project and reader promise;
-- a before/after or request/outcome frame;
-- a high-level architecture or execution-flow visual;
-- a decision or trade-off frame;
-- a validation-evidence frame;
-- a closing frame with outcome and next actions.
-
-Every slide must have a useful heading, readable contrast, and a sensible
-no-JavaScript and print order.
-
-## Shell-composition license
-
-The shell supplies safety and presentation mechanics. You may recompose and
-extend non-script markup and styling to fit the story. Do not add scripts,
-external active content, or inline event handlers.

package/assets/skills/explainer-kit/examples/project-explainer/content.md

@@ -1,31 +0,0 @@
-# Signal Relay project explainer
-
-## Planned architecture
-
-Signed events enter through a narrow HTTP boundary. The service validates each
-envelope before placing it on a durable queue; workers own downstream delivery
-and isolate exhausted retries in a review queue.
-
-## Decisions
-
-- Keep ingestion stateless so instances can scale independently.
-- Persist accepted events before acknowledging them.
-- Use bounded retries and a separate review queue instead of retrying forever.
-
-## Risks
-
-The primary risk is an incompatible producer envelope. Contract tests and a
-shadow-ingestion period detect that drift before cutover.
-
-## Phases
-
-1. Validate contracts against fixtures.
-2. Run shadow ingestion without downstream delivery.
-3. Enable canary delivery and compare outcomes.
-4. Move remaining traffic after recovery drills pass.
-
-## Validation approach
-
-The release gate combines contract tests, duplicate-delivery tests, queue
-recovery drills, and operator sign-off. Supporting evidence is linked from
-[the example validation plan](https://docs.example.com/signal-relay/validation).

package/assets/skills/explainer-kit/examples/project-explainer/fact-base.md

@@ -1,22 +0,0 @@
-# Example fact base: Signal Relay
-
-This fictional example demonstrates a pre-implementation project explainer. All
-organizations, systems, and links are illustrative.
-
-## Reconciled claims
-
-- **F-001 — Planned architecture:** The relay accepts signed events, validates
-  their envelopes, and writes accepted events to a durable queue.
-  Source: [architecture proposal](https://docs.example.com/signal-relay/architecture).
-- **F-002 — Delivery:** Workers retry transient delivery failures with bounded
-  backoff and move exhausted events to a review queue.
-  Source: [delivery design](https://docs.example.com/signal-relay/delivery).
-- **F-003 — Validation:** Contract, retry, and recovery tests must pass before
-  traffic can move from the existing path.
-  Source: [validation plan](https://docs.example.com/signal-relay/validation).
-
-## Reconciliation notes
-
-The proposal gives the queue ownership to the platform team while an older
-meeting note assigns it to the application team. The proposal is newer, so
-F-001 follows it and records the older assignment as superseded.

package/assets/skills/explainer-kit/examples/project-recap/content.md

@@ -1,77 +0,0 @@
-# Atlas Index project recap
-
-## Original request
-
-Every correction to the fictional Atlas Index corpus had to wait for the next
-overnight window, and the cost of that window grew with the corpus. The team was
-asked to make indexing continuous without asking a single caller to change how
-they query.
-
-> [!IMPORTANT]
-> The query contract was frozen for the whole engagement. Any option that would
-> have reshaped a response was out of scope before it was evaluated.
-
-## Key agent decisions
-
-| Decision                     | Alternative weighed          | Why it won                                         |
-| ---------------------------- | ---------------------------- | -------------------------------------------------- |
-| Checkpoint each partition    | A single global checkpoint   | Replay after a crash stays inside one partition    |
-| Make writes idempotent first | Deduplicate in each consumer | Retry safety belongs to the writer, not the reader |
-| Keep the rebuild as recovery | Delete it after cutover      | A proven fallback costs almost nothing to retain   |
-
-Each row records what was chosen and what it was chosen over, so a later reader
-can reconstruct the reasoning rather than just the result.
-
-## As-built architecture
-
-```diagram
-graph TD
-  reader[Change reader] --> queue(Batch queue)
-  queue --> worker[Index worker]
-  worker --> index[Search index]
-  audit{Drift beyond threshold} -->|yes| recovery[Recovery task]
-  index --> audit
-```
-
-The reader resumes from whichever checkpoint its partition last committed, so a
-restart repeats at most one batch. Workers apply batches by key, which makes a
-repeated batch indistinguishable from a first delivery. The audit closes the
-loop by sampling both sides on a schedule and opening a recovery task only when
-the difference clears the accepted threshold.
-
-## Implementation record
-
-```timeline
-2026-02-03 — Checkpoint persistence landed behind a flag
-2026-02-17 — Replay-safe workers replaced the batch writer
-2026-03-02 — Drift audit and the recovery runbook shipped
-```
-
-- The first milestone changed only bookkeeping, so it could ship dark.
-- The second made retries safe, which is what unlocked automatic recovery.
-- The third added the observability the operators asked for before cutover.
-
-## Validation evidence
-
-| Suite              | Scope                                       | Result    |
-| ------------------ | ------------------------------------------- | --------- |
-| Contract           | Query responses across the fixture corpus   | Unchanged |
-| Restart            | Interruption at every checkpoint boundary   | No gaps   |
-| Duplicate delivery | The same batch applied twice                | No drift  |
-| Parity sampling    | Scheduled samples against the source record | In budget |
-
-The full logs sit in the fictional
-[evidence index](https://docs.example.com/atlas-index/evidence).
-
-> [!NOTE]
-> How long audit samples should be retained is still an open governance
-> question, and it is tracked outside this recap.
-
-## Outcome
-
-Corrections now reach readers in minutes instead of waiting for a nightly
-window, and the operational surface got smaller rather than larger.
-
-1. Continuous indexing is the normal path.
-2. The rebuild remains documented, exercised, and unused.
-3. Drift is a monitored quantity rather than an assumption.