openmerit 0.1.7-preview.2 → 0.1.7-preview.3

package/docs/site-domain-migration.md

@@ -1,57 +0,0 @@
-# Primary domain migration
-
-## Production migration — 12 October 2026
-
-The primary website is `https://openmerit.ai`, with the hosted terminal at `https://dash.openmerit.ai`. The domain stays registered at GoDaddy; DNS is delegated to `anton.ns.cloudflare.com` and `elinore.ns.cloudflare.com` in the existing Cloudflare account. Public TLS, email delivery, memo sign-in, and redirect cutover were verified separately.
-
-The production main site is newer than the main checkout's `demo/worker.mjs` and `wrangler.jsonc`. It includes the protected memo, D1-backed email OTP, a newer interactive demo, and the engineering article. **Do not deploy the root Wrangler configuration to production during this migration.** Doing so would replace the deployed application with older source and omit its auth bindings. The migration instead preserves the downloaded deployed application, every existing asset, all secret bindings, D1, Durable Object namespaces, and container configuration.
-
-The preserved branch `codex/main-before-terminal-2026-10-12` at `d89ebc4` contains the newer memo auth source and binding configuration. Reconcile that source with the promoted terminal branch before resuming root application deployments; do not replace the running app from this checkout simply to publish domain metadata.
-
-`demo/domain-migration.mjs` is the tested domain layer. `demo/domain-router.mjs` and `wrangler.domains.jsonc` deploy a separate Worker with service bindings to `openmerit-site` and `openmerit-terminal-preview`. This ensures all public page and asset requests pass through the domain layer even when the application serves static assets before its own Worker code. The domain router owns the public domains and redirects. The application Workers remain the owners of their content, authentication, and APIs.
-
-The main application also uses the domain layer around its preserved production entry point, with redirects disabled there. It selects the exact memo auth origin from the serving domain. Auth secrets, cookie protections, expiry, rate limits, administrator allowlist, reader records, and OTP verification remain unchanged. Cookies are host-bound: visitors must authenticate again on `.ai`; database users and reader history are retained.
-
-## Cutover contract
-
-- Website pages on `openmerit.site` and `www.openmerit.site` redirect to the same path and query on `openmerit.ai`; `www.openmerit.ai` also redirects to the apex.
-- Dashboard pages on `dash.openmerit.site` redirect to the same path and query on `dash.openmerit.ai`.
-- Redirects use HTTP 308 with `Cache-Control: no-store` to make an operational rollback effective without a long cached redirect.
-- Existing `/demo/api/`, `/demo/internal/`, and `/memo/auth/` requests on `.site` keep their original application handlers and origin checks. This preserves already-open tabs and in-flight container callbacks. New page loads and new sign-ins use `.ai`.
-- Existing dashboard `/api/` requests on `dash.openmerit.site` keep serving the same read-only API so already-open dashboard tabs can continue updating. Upgraded connections pass through intact.
-- Cloudflare serves its managed `robots.txt` directly on each domain before the Worker. Those files remain available on the legacy hosts. Search, agent, and training bot policies are set to Block on both zones; the new domain's robots responses match the originals.
-- HTML and Markdown served on `.ai` use `.ai` links, canonical metadata, social-image URLs, and email addresses. Binary assets and API data pass through unchanged.
-- The four existing inbound aliases (`lazim`, `akhil`, `praveen`, and `invest`) are recreated on `.ai` with the same verified destination mailboxes. Existing `.site` aliases and MX records remain valid, avoiding a mail-forwarding chain or loss of old addresses. Catch-all stays disabled.
-- The OTP sender changes to `memo@openmerit.ai` only after Email Sending has verified SPF, DKIM, DMARC, and bounce-domain DNS. Inbound routing and outbound email sending require separate Cloudflare setup.
-
-There is no OpenMerit Cloudflare Pages project in this account. The pages are served by Workers static assets. The existing `openmerit-site.listenlater-lazim.workers.dev` address remains an application fallback; the public custom domains are the canonical entry points.
-
-## Verification and rollback
-
-Before enabling redirects, check valid public TLS on every `.ai` host; compare live pages and linked assets to the pre-migration capture; test memo delivery, valid OTP, invalid OTP, logout, protected Markdown, and administrator restrictions; check dashboard APIs and its read-only boundary; verify each inbound alias has the same destination and a ready email zone. Do not reset auth limits or storage to make checks pass. A configuration-only or successful send response is not proof of inbox delivery.
-
-Deploy the domain router with `npx --yes wrangler@4.136.3 deploy --config wrangler.domains.jsonc`. Its build hook runs the domain tests and documentation checks. Keep domain ownership in that configuration, rather than adding the same routes back to the application configurations.
-
-Run `node --test demo/test/domain-migration.test.mjs`, `npm run check:docs`, and applicable `npm run verify` checks. Public docs remain generated from Markdown; generated `site/docs/` files are not edited. Homepage product/FAQ claims are unchanged by the domain migration.
-
-Local rollback material and before/after evidence are under `/private/tmp/openmerit-domain-migration/` (private directory). The original main application version is `294f810c-5c46-4353-ab13-67ab0aa89464`; the original terminal version is `111171c5-34bb-4a25-91bc-60f8e96f371e`. The recorded `.site` routes, mail rules, binding metadata, and original deployed modules are preserved there. Restore the previous route ownership and application version together if rollback is needed; keep both domains' mail delivery configured.
-
-## Publication status
-
-The zone activated on 12 October 2026 at 16:45 UTC. Inbound Email Routing is enabled, synchronized, and ready. Email Sending is enabled with configured DNS. A real OTP from `memo@openmerit.ai` reached the owner's inbox with SPF, DKIM, and DMARC passing. A second OTP sent to `lazim@openmerit.ai` reached the same inbox through its `code@lazim.one` destination, verifying the new inbound route.
-
-The main application now uses the verified `.ai` sender while preserving both request origins. The terminal deployment changed only its canonical/social metadata and generated social image; the application JavaScript, CSS, favicon, and flow stylesheet were compared byte-for-byte with production before publishing.
-
-The domain-reference audit covers the README, public guide links, website and memo generators, canonical/Open Graph/Twitter metadata, sharing-image notes, the engineering article's metadata/navigation, hosted dashboard tests, and the demo's provider attribution URLs. GitHub's repository website field is empty. Historical deployment records, compatibility handlers/tests, legacy redirect routes, and the old generated memo snapshot retain their original domains. The two production `HTTP-Referer` constants are changed from `.site` to `.ai` without rebuilding the application or replacing its assets. Both application configurations have empty `routes` arrays; all six public hosts are managed by `wrangler.domains.jsonc`.
-
-All 88 captured legacy URLs retain their original status codes after staging. 83 response bodies are byte-identical; the remaining five are the two intentionally updated dashboard HTML documents and three time-dependent sample API responses. `npm run verify` passed; all seven domain-layer tests and the documentation checks passed.
-
-Valid public HTTPS on all three `.ai` hosts was confirmed at 17:43 UTC. The `.ai` URL comparison retained all 88 original status codes. After matching Cloudflare's crawler policies, 83 bodies match the originals after document-domain substitution; the five exceptions are the two intentionally updated dashboard HTML documents and three time-dependent sample API responses.
-
-A real `.ai` OTP login succeeded in the browser. The protected memo and its 53,283-byte Markdown download were accessible after sign-in, the non-admin reader account was denied the reader list, and sign-out returned to the email gate. Expired/invalid codes and untrusted origins were rejected. Documentation search and its section links, dashboard Activity navigation, and demo initialization worked without browser console errors. Dashboard mutations remain HTTP 405 and the private snapshot route remains 404.
-
-Redirects are enabled. The router owns the old apex/www routes, all three new custom domains, and the old dashboard custom domain. All 88 legacy URLs retain their original final status after cutover and reach the expected host, allowing for the documented API and managed-robots exceptions. HTTP 308 redirects preserve encoded query strings and paths; browser checks also preserved the dashboard fragment. Both email zones remain enabled, synchronized, and ready, with all four new aliases enabled and the catch-all disabled.
-
-Active versions: main application `08a1ad0f-ae83-4179-a4e9-a174ba746b71`; terminal `49abf964-8633-466a-a4c6-29cdc8007f55`; domain router `7e5cbee3-1c26-4cb8-afd6-07b6a092ee31`.
-
-One user-approved live demo request completed with all four comparison cases passing through OpenAI and produced the expected proposed assignment; the session was then ended. OpenRouter candidates returned HTTP 400 from the inference gateway during that run. Their underlying provider error was not exposed, and its cause was not established. This check does not establish that every provider integration is healthy. No additional paid experiment was run, no proposed setup was approved, and no provider credentials, model request bodies, limits, or budgets were changed.

package/docs/site-dynamic-og.md

@@ -1,35 +0,0 @@
-# Page sharing images
-
-Separate page images are disabled for now at the user's request. The homepage and all documentation page sources use `https://openmerit.ai/assets/openmerit-og-v1.png` for Open Graph and Twitter cards. See the [domain migration status](site-domain-migration.md) for activation and cutover verification. No entries in `scripts/docs.config.mjs` currently enable `socialImage`.
-
-The optional template and workshop artwork remain available for later use. Normal docs builds do not render a separate page card. The previously published `/docs/og.png` path serves a copy of the default image so cached sharing metadata still resolves.
-
-The shared-image configuration is live as Cloudflare version `90bd0c29-5d32-4386-93df-a53e680d9cc5` (2026-09-23). All 11 documentation checks passed. Live Facebook/Twitter crawler checks confirmed default-image metadata and valid image responses on both domains; 54 deployed URLs matched local output.
-
-## Optional template and build
-
-`scripts/social-image.mjs` renders a reusable SVG template to PNG with the pinned `@resvg/resvg-js` development dependency. It combines the text-free workshop asset at `site/assets/openmerit-og-workshop-v1.png` with a heading in the existing `site/assets/inter-latin.woff2` font. The font's SIL Open Font License is retained. There are no network requests, system-font dependencies, or image-generation API calls during builds. The source artwork and exact edit prompt are recorded in [the workshop background notes](site-og-workshop.md).
-
-For an entry with `socialImage: true`, `scripts/build-docs.mjs` passes the maintained page metadata into the renderer, which draws the page title over the workshop. The page description remains in the Open Graph and Twitter description tags. `npm run build:docs` and `npm run check:docs` generate enabled cards, and the existing Cloudflare deployment runs the latter before publishing.
-
-Enabled cards are generated during the build and served as PNGs. They are not rendered separately for each visitor or sharing request. Both default and custom images have an absolute `og:image` URL, PNG type, dimensions, alt text, and a Twitter large-image card. Page titles and descriptions stay specific to each documentation page.
-
-## URLs and future pages
-
-When enabled for the overview, a custom image is written to `site/docs/og.png`, alongside the generated page, and assigned through `https://openmerit.ai/docs/og.png?v=<content-hash>`. The hash comes from the rendered PNG, so changing the title, workshop artwork, font, or template changes the URL when it changes the pixels. Rebuilding the same card produces the same URL. Description or package-version updates do not invalidate an unchanged custom image; those details are not printed on the card.
-
-The physical PNG path stays stable. Previously shared image URLs with an older query parameter still resolve after a deployment instead of pointing to a deleted filename. Social platforms control their own preview caches and may retain a previously fetched card.
-
-To re-enable the optional template after a future user request, add `socialImage: true` to a page's entry in `scripts/docs.config.mjs` and rebuild; the generator assigns an image under that page's route. Do not edit `site/docs/og.png` or the generated HTML.
-
-The template measures and wraps the heading into at most two lines in the upper-left area. If a future title cannot fit, the build fails rather than silently cropping the text or covering the makers. Review new cards at full size and as thumbnails when expanding the rollout.
-
-## Verification and references
-
-The documentation checks validate the assigned Open Graph/Twitter URLs, PNG signature and 1200 × 630 dimensions, image hash, alt text, deterministic regeneration, heading updates, stable artwork when unprinted metadata changes, escaping, and rejection of text that cannot fit. The rendered `/docs/` card is visually reviewed before publishing.
-
-The initial generic card shipped on 2026-09-23 as Cloudflare version `e7791e53-4f0c-4666-89d6-f7d9bc72ae4d`; it was then restyled to match the default workshop OG image at the user's request. Current deployment and live verification are recorded in [site design notes](site-design.md).
-
-The workshop revision shipped as `921eb118-0539-4959-ad5f-e9b928e76d70`, with assigned image `https://openmerit.site/docs/og.png?v=b8404648c9bd`. Full-size and 600 × 315 previews were reviewed against the default image. All 11 documentation checks and script syntax checks passed. Live metadata and image bytes matched for Facebook and Twitter crawler user agents on both domains, older query URLs still resolved, and 54 deployed URLs matched the local build.
-
-Implementation references: [Open Graph metadata and image properties](https://ogp.me/) and [resvg-js](https://github.com/thx/resvg-js). Font provenance and license are recorded in the site assets and [site design notes](site-design.md).

package/docs/site-faq-maintenance.md

@@ -1,317 +0,0 @@
-# Website FAQ maintenance
-
-The public FAQ lives in `site/index.html`. Its answers describe implemented behavior verified against main and the published package, including known limitations. Appearance differences between npm 0.1.6 and the hosted/source interface are identified separately in the terminal guide.
-
-## Current factual review — 14 October 2026
-
-Reviewed main against the published `openmerit@0.1.6` artifact and the hosted dashboard/demo. Stable installation includes `openmerit dash`; Pi is optional for the separate comparison workflow. The homepage now introduces the standalone terminal and links the demo guide, which distinguishes fictional hosted samples from the recorded player retained in main.
-
-Updated background scheduling, durable pause, challenger-budget accounting, and terminal data-handling claims. The macOS LaunchAgent requires confirmed persistent execution and infrastructure permission, a logged-in user, and headless Pi authentication. Pause gates automatic work but does not cancel active intents or disable explicit commands. Budget admission and result validation use reported challenger costs; they are not provider billing controls. The terminal indexes supported source/configuration declarations, reads existing application evidence, and retains selected metadata in memory. It does not invoke the coordinator, make inference calls, or mutate model configuration.
-
-Removed obsolete 0.1.5 comparisons and preview release chronology from current public guides. Retained uncertainty, incomplete coverage, supervised-validation limits, and npm-versus-hosted appearance disclosure. The following dated entries are historical records, not the current release contract. The docs and website were subsequently published on 14 October; npm was not changed. See the [publication record](site-publication-2026-10-14.md). Direct root-configuration deployments still require production-source reconciliation.
-
-## Historical reviews
-
-Last factual review: 2026-09-23, against npm `openmerit@0.1.5`, the Pi 0.87 adapter, and the current source. The FAQ contains 13 questions. The earlier audit reproduced a task-triggered assessment while `/openmerit status` reported paused and confirmed the same dispatch path in the published package.
-
-Source review on 2026-09-27: unreleased post-build target detection, harness-inferred user-confirmed metric sampling plans, incumbent and comparison handoffs, setup-time model leads, deterministic core baseline-window checks, macOS Pi LaunchAgent provisioning, and durable pause are under development. The homepage intentionally continues to describe published npm `openmerit@0.1.5`; update it only when a release containing those changes is published and verified.
-
-The experimental `npm run demo` sandbox is a repository-local live-provider demonstration, not a released package workflow. Its end-to-end result and tiny pilot sample do not change the homepage's shipping-behavior or reliability claims.
-
-## Sources to review when behavior changes
-
-| FAQ anchor | Claims to verify | Primary sources |
-| --- | --- | --- |
-| `faq-agent` | Harness responsibility; limits of result validation | `packages/pi/src/index.ts` (`privateIntentMessage`), `packages/core/src/index.ts` (`interpretIntentResult`), `docs/architecture.md` |
-| `faq-harnesses` | Implemented adapters; supported Pi versions | `packages/`, root `package.json` peer dependencies, `docs/adapter-guide.md` |
-| `faq-evaluations` | Interactive setup; task-specific instrumentation | Pi `session_start`, core `establish_evals` outcome and observability validation, `docs/getting-started.md` |
-| `faq-comparisons` | User objectives; candidate tradeoffs; no promised savings | Core `verifyFrontierSnapshot`, `docs/pareto-spec.md` |
-| `faq-evidence` | Required samples; unresolved candidates; evidence trust | Core feasibility and frontier verification, `docs/metrics-and-evidence.md`, `docs/security.md` |
-| `faq-approval` | Opt-in automation; zero-capable graduation threshold; post-swap evaluation | Core `nextImprovementAction`, `packages/protocol/src/schemas.ts` (`SupervisedGraduationPolicySchema`), Pi `approve` command |
-| `faq-regressions` | Post-swap regression handling; conditional rollback | Core `interpretIntentResult` and `nextImprovementAction`, `docs/lifecycle.md` |
-| `faq-background` | CLI lifetime; authorized macOS LaunchAgent; other-platform gaps; product-validation limits | Pi `PI_HARNESS_DESCRIPTOR`, core `buildAutomationPlan`, `docs/automation.md` |
-| `faq-pause` | Which automatic dispatches stop; restart behavior; active work | Pi `reportAutomationSignal`, `createInitialUiState`, completion handler and `pause` command; `docs/operations.md` |
-| `faq-data` | Project files; Pi session entries; harness/provider data flows | `packages/core/src/store.ts`, Pi `appendEntry` and `privateIntentMessage`, `docs/security.md` |
-| `faq-cost` | License; npm availability; provider and infrastructure costs | `LICENSE`, published npm metadata, harness execution path |
-| `faq-budget` | Reported challenger ledger, admission/result checks, separate costs, no independent provider-billing cutoff | Core `createOpenMeritIntent`, budget consumers across `packages/` |
-| `faq-readiness` | Implemented, tested, and product-validated behavior | `docs/testing.md`, `docs/roadmap.md`, actual product-trial evidence |
-
-## Review during releases and website updates
-
-1. Check the current published npm version and compare its behavior with the answers above. Keep unreleased behavior clearly labeled; update version-specific caveats only when the relevant release is available.
-2. Review affected answers whenever adapters, setup, evidence checks, approval, rollback, scheduling, pause, storage, budget handling, or readiness change. Read implementation and meaningful test evidence before strengthening a claim.
-3. Keep the linked operational documentation consistent. In particular, a pause fix needs coverage for task signals, measurement signals, session-start signals, lifecycle follow-ups, and restart behavior before the FAQ can promise a complete pause.
-4. Check the expanded disclosures at desktop and narrow mobile widths, including keyboard operation, links, and JavaScript-disabled reading. Verify the served FAQ after publishing.
-5. Record the reviewed version, date, and any remaining limits here.
-
-## Wording boundaries
-
-- Separate issuing a request from the harness successfully executing it.
-- Distinguish structured-result and comparison validation from independent proof that evidence is authentic.
-- Describe a budget as a harness constraint until metering and spending cutoffs exist.
-- Describe verification as post-swap evaluation, not a guarantee that a change is safe before it is applied.
-- Claim local storage only for the relevant OpenMerit files; account for Pi session history and configured external systems.
-- Keep ordinary coding checkpoints distinct from task-specific product measurements.
-
-## Inference Terminal — unreleased source, 7 October 2026
-
-Reviewed the homepage evidence, background, data, cost, and readiness claims against the new terminal. It reads existing project metadata and loopback runtime inventory on a bounded interval and samples whole-machine CPU/memory. It makes no inference calls, routes no traffic, runs no evaluations, and stops collecting when its CLI exits. Sample data is labeled and separate. Credential-variable detection reveals provider names only; it never uses credentials for provider calls.
-
-Deployments, reported path hops, shared pools, additional hosts, sites, and racks come from explicit configuration or bounded exports. Source timestamps determine freshness. Agent/task names come only from recorded metadata; source code alone does not establish execution. Full local hostnames are system-reported. Missing identities and readings remain explicit. No network discovery, model verification, routing enforcement, available-headroom guarantee, or per-agent resource attribution is implied.
-
-Top navigation, shared dropdowns, model/service images, path colors, chart interactions, and denser source rows change presentation only. Images and animation libraries are bundled locally. This remains an unreleased command; published package behavior and homepage FAQ claims are unchanged. No homepage wording changes are needed before release.
-
-## Hosted terminal sample — 7 October 2026
-
-The separate `dash.openmerit.site` preview serves generated fictional data and terminal assets only. It has no collector, filesystem access, provider credentials, inference endpoint, upload path, or connection to a visitor's local environment. Public access is by link; noindex is a search-engine request, not authentication. The root site's FAQ and published npm claims remain unchanged. The deployment uses its own Worker and exact custom domain, and does not redeploy the main site or its demo/memo services.
-
-The hosted preview’s dedicated sharing card and `Inference Terminal by OpenMerit` title change presentation only. Its social description still identifies the environment as fictional; homepage FAQ and package claims are unchanged.
-
-## Inference service identity — unreleased source, 8 October 2026
-
-Baseten and Cerebras credential-name detection joins Groq and the existing services. Known HTTPS endpoint overrides identify configuration independently of SDK vendor; unknown overrides suppress credential-name attribution. Only inherited variables are checked, and no credential values or raw URLs reach the snapshot. No cloud calls, account access, source-code scanning, `.env` loading, or physical hardware inference is introduced. Model creators, deployment modes, and accelerator vendor/kind come from explicit metadata. Configured services remain distinct from observed requests. The hosted sample uses fictional examples; package and homepage claims remain unchanged.
-
-## Services inventory — unreleased source, 8 October 2026
-
-Reviewed the new Services view against evidence, background, data, and readiness claims. It reorganizes existing metadata into a service inventory and a secondary environment map. Model creators alone never establish service connections; registry roles are subordinate to explicit roles. Selected-window service counts are nonadditive and configured-only entries remain distinct from activity. Recognized endpoint hostnames can now appear as evidence; deployment identifiers, URL paths, queries, and credential values remain excluded. Collection stays passive. This does not release the CLI or change the homepage FAQ's published-package claims.
-
-## Automatic terminal discovery — unreleased source, 8 October 2026
-
-Reviewed data, evidence, approval, background, and readiness claims. The terminal now checks four fixed project declaration files and bounded known loopback API candidates automatically. SDK presence never establishes usage. Optional Pi session-format-3 metadata needs explicit CLI consent saved outside the repository and tied to canonical project/source paths; session files containing conversation text are parsed only after consent, and only usage metadata is retained. Revocation clears it on the next poll. Activity exports, Pi history, and audit summaries use precedence rather than additive totals. There are no cloud usage calls or general filesystem/process scans. This supersedes the earlier source-only note that `.env` and home history were never read. Published-package behavior, hosted-sample isolation, and homepage claims remain unchanged; no FAQ wording change is needed before release.
-
-
-## Native-history request counts — unreleased source, 8 October 2026
-
-Reviewed evidence and readiness claims after the dedicated Linux VM run. Overview and model request counts now recognize approved Pi history and retained requests from partially covered sources. Collection and permissions are unchanged. The real run is bounded local-model test evidence, not a claim of universal discovery or production readiness. Published-package and homepage FAQ claims remain unchanged.
-
-
-## Pi connection names — unreleased source, 9 October 2026
-
-Reviewed evidence and data claims. Pi's existing assistant-message provider ID now supplies its recorded connection name; classification uses the existing unambiguous inventory/runtime matcher. Generic serving-provider fields still do not establish routes, and physical deployments, hidden hops, timing, and agent names remain uninferred. No additional files, credentials, inference calls, or permissions are introduced. Published-package and homepage FAQ claims remain unchanged.
-
-
-## Environment map coverage — unreleased source, 9 October 2026
-
-Reviewed evidence and readiness claims. The map now selects representatives around every recorded entry connection in the selected window or agent scope. It no longer drops connections behind workload or model layout caps. Larger maps scroll, and represented request/workload coverage remains explicit. This changes presentation only; no inference, discovery, permission, billing, or published-package behavior changes. Homepage FAQ wording is unchanged.
-
-
-## Complete environment map — unreleased source, 9 October 2026
-
-The map no longer selects representative workloads or models. It groups all retained activity by identical recorded entry connections and lets users expand every member. Request counts and relationships stay complete in collapsed and expanded views. Compact stacks preserve the original map scale and show a real member name with a count of remaining members. Model nodes display reported services and explicitly matched deployment information; absent deployment identities are explained in inspectors. No source scanning, inferred topology, new permissions, or inference calls are introduced. Homepage FAQ claims about the published package remain unchanged.
-
-
-## Optional graph component experiment — unreleased source, 9 October 2026
-
-The `map=flow` URL flag enables a separately bundled React Flow + ELK renderer over the same retained metadata. The existing map remains the default, with immediate return through Original map. Search and member highlighting change presentation only; grouping, request totals, source collection, permissions, and sample/live separation are unchanged. This is an opt-in experiment, not a claim of production scale or released package behavior. Homepage FAQ wording remains unchanged.
-
-
-## Existing activity audit — unreleased source, 9 October 2026
-
-Reviewed homepage evidence, data, background, approval, and readiness claims against automatic bounded project JSONL readers and multi-source reconciliation. The terminal now reads supported existing request logs inside the selected project and combines their metadata with approved native Pi usage and explicit feeds. Shared recorded identities prevent double counting; unresolved overlaps and conflicting measurements are disclosed. Pi's bounded file selection increases to 128 sessions; permission scope and revocation are unchanged. No inference calls, provider account ingestion, arbitrary process/database scanning, or framework-wide automatic support is implied. Published package and homepage FAQ claims remain unchanged. VM acceptance evidence is recorded in the internal terminal notes only after the run succeeds.
-
-
-## Application-only terminal scope — unreleased source, 9 October 2026
-
-Reviewed evidence, data, approval, and readiness claims. The terminal now excludes coding-harness usage: the Pi history reader, saved-grant lookup, and access prompts are removed. Prior history-related entries in this audit are historical and superseded. Application agents, jobs, evaluations, supported request logs, and OpenMerit product-task evidence remain in scope. Explicit development-scoped records are rejected, but unmarked request data cannot be classified by purpose automatically. Runtime inventories and whole-machine measurements remain shared infrastructure evidence, not project-exclusive usage. Published package and homepage FAQ wording remain unchanged; the terminal is still unreleased.
-
-
-## Terminal test installation — preview, 9 October 2026
-
-Reviewed setup, background, data, and readiness claims. A prebuilt test package on the existing sample domain supports a single global npm install, followed by `openmerit dash` in the selected application directory. The CLI opens the default desktop browser, keeps a printed URL for headless sessions, and falls back to a free loopback port only when no explicit port was requested. Collection scope, file access, and consent boundaries are unchanged. This does not publish or change the stable npm release; homepage FAQ claims remain about the published package. Platform URL-handler code is tested separately from actual desktop acceptance, and preview verification must not be presented as broad production readiness.
-
-
-## npm terminal preview delivery — published, 9 October 2026
-
-The terminal prerelease is published in the existing `openmerit` npm package as `0.1.6-preview.0` under the `preview` tag. Registry metadata and integrity match the tested package; `latest` remains `0.1.5`. Registry-install acceptance is recorded in the terminal preview deployment record. The compiled package retains core/protocol/Pi exports and uses an explicit dist-directory allowlist so a sample-site build cannot accidentally add hosted assets or a nested installer archive. The standalone domain-hosted packaging path is removed from the source build. This changes delivery only: collection behavior, browser launch, consent, and application scope remain unchanged. Homepage stable-package claims are unchanged.
-
-
-## Historical terminal activity — published preview, 9 October 2026
-
-Reviewed retention, source coverage, and readiness claims. Published `0.1.6-preview.1` removes the 24-hour age cutoff and offers 7d, 30d, and default All time with earliest/latest retained request dates. Existing byte, file, and record caps remain; All time describes available evidence, never a guaranteed project-lifetime archive. It neither queries provider accounts nor adds persistent collection. Registry metadata and integrity match the tested artifact, and a direct npm installation passed the existing-application and dormant-log acceptance checks in the isolated VM. The `preview` tag now resolves `0.1.6-preview.1`; `latest` remains `0.1.5`. Homepage stable-package claims remain unchanged.
-
-
-## Project-linked runtime inventory — unreleased source, 9 October 2026
-
-Reviewed application scope, data access, automatic discovery, and compute claims. The source correction removes unconditional Ollama and standard-port probes. A project declaration or explicit terminal configuration must identify the local endpoint before inventory is requested; installed SDKs, inherited shell endpoints, and historical runtime names alone do not establish it. Once linked, the runtime’s available models remain shared inventory, with usage separately sourced from request records. Local compute omits this machine unless an endpoint or explicit deployment links it; declared hardware exports remain supported. The legacy machine snapshot is labeled whole-machine context. npm `0.1.6-preview.1` still has the previous automatic probes until another preview is published. Homepage stable-package claims are unchanged.
-
-### Evidence integrity corrections — unreleased source, 9 October 2026
-
-Reviewed project scope, usage accuracy, passive collection, hardware placement, and completeness claims. The terminal now ignores inherited shell services, requires explicit host links for endpoint placement, retains task summaries separately from all request metrics, preserves unknown status/currency/cost basis, discloses inventory count limits with partial coverage and omitted counts, and distinguishes missing request evidence from a measured zero. These corrections are source-only until another preview is published; npm `0.1.6-preview.1` retains the earlier behavior. Main-site FAQ claims describe the stable package and remain unchanged. No deployment or npm publication is implied by verification.
-
-
-## Evidence corrections — published preview.2, 9 October 2026
-
-Published `0.1.6-preview.2` with the project-scope and evidence-integrity corrections above; this supersedes the earlier source-only status of those corrections. The release guide and changelog describe this version explicitly; earlier previews retain their documented behavior. The existing VM acceptance preserved 240 original request records and all 125 original project files; two separate, real local Ollama calls were picked up from an application log during passive refresh. A project without declarations exposed no runtime inventory, while an explicit host link matched the VM hostname and Ollama residency response. Registry metadata and artifact integrity were verified, and a direct npm update in the VM retained all 242 current requests and 126 project files across passive refresh. The `preview` tag resolves `0.1.6-preview.2`. The stable `latest` channel and homepage FAQ remain about `0.1.5`; no homepage wording or website deployment is needed for this preview release.
-
-
-## Terminal review corrections — unreleased source, 10 October 2026
-
-Reviewed homepage evidence, data, background, and readiness claims against the log continuity, request outcome, multi-host residency, and model-detail coverage corrections. Collection remains passive and project-local. Bounded checkpoint verification adds up to 8 KiB of reads per cached JSONL file per poll and retains hashes, not another raw-content cache. It does not guarantee detection of every in-place edit to a large file; the terminal guide states the sampled-region limitation. Conflict reporting preserves source precedence, residency still requires fresh exported evidence, and missing usage stays unavailable. These fixes are source-only; npm `0.1.6-preview.2`, the hosted sample, and stable-package homepage claims remain unchanged. No FAQ wording change is needed.
-
-
-## Hugging Face endpoint discovery — unreleased source, 10 October 2026
-
-Reviewed evidence, data, background, and readiness claims. Selected-project endpoint declarations can identify Hugging Face dedicated endpoints and its inference router separately. Generic Hub credentials, SDK presence, downloaded models, and inherited shell settings do not establish inference use. Dedicated endpoint subdomains and URL paths/queries are excluded from the snapshot. Detection makes no remote requests or account-history calls and creates no request, model, hardware, or deployment measurements. Recorded names retain their original attribution. The official service mark is bundled locally. These changes are source-only; npm `0.1.6-preview.2`, the VM installation, the hosted sample, and stable homepage claims are unchanged. No FAQ wording change is needed.
-
-## Expanded endpoint discovery — unreleased source, 10 October 2026
-
-Reviewed evidence, data, background, and readiness claims for the shared 39-service endpoint registry. Only selected-project literal declarations are indexed; provider-specific credential names establish configuration, and general cloud credentials or SDK dependencies alone do not establish inference. Endpoint overrides suppress SDK-vendor fallback. Dedicated resource labels and all path/query/fragment data are excluded from snapshots. The service inventory uses the same identity registry, while explicit roles, reported paths, model creators, and actual request metadata remain authoritative. The change adds no cloud calls, account history access, source-code execution, or guessed usage. Custom domains and unlisted forms remain coverage gaps. This is unreleased source work; npm preview.2 and homepage published-behavior wording remain unchanged.
-
-
-## Endpoint coverage release preparation — 10 October 2026
-
-Prepared `0.1.6-preview.3` to include the three source-only changes above. The public terminal guide now describes this version explicitly, while registry publication remains pending verification. The latest source build passed 47 focused Linux tests in the isolated VM, preserved all 242 saved requests, 41 agent IDs, and 122 task IDs across passive refresh, and left all 126 project files unchanged. Separate endpoint fixtures did not enter the real dashboard. No new inference calls were made. Stable `latest` and homepage FAQ wording remain about `0.1.5`; neither the main site nor hosted sample is deployed by this package release.
-
-
-## Endpoint coverage — published preview.3, 10 October 2026
-
-Published `0.1.6-preview.3` and verified its npm integrity and `preview` dist-tag, superseding the source-only and release-preparation status above. Direct registry installation on the VM retained all 242 requests, 41 agent IDs, 122 task IDs, and 126 unchanged application files through passive refresh. Endpoint fixtures remained separate from actual history; no inference calls were made. Stable `latest` remains `0.1.5`; no homepage FAQ wording or site deployment changed.
-
-
-## Repository index — unreleased source, 10 October 2026
-
-Reviewed data handling, evidence, background collection, and readiness claims. The terminal now reads bounded Python/JS/TS and structured configuration syntax within the selected project, including nested dotenv declarations. No code execution, cloud calls, or network probes are added by the index. Local snapshots expose narrow identifiers and relative file/line evidence; a separate opt-in diagnostics command outputs counts only. Declarations, examples, candidates, aliases, and unresolved references remain distinct from actual application usage. Existing activity adapters and runtime-probe authorization remain unchanged. The guide explicitly marks this as unreleased source; npm preview.3 and the stable-package homepage FAQ keep their published scope. No main-site or hosted-sample deployment is implied by local verification.
-
-
-## Repository index release preparation — 10 October 2026
-
-Prepared `0.1.6-preview.4` to deliver repository indexing and counts-only diagnostics through the existing npm preview channel. The public guide identifies the minimum version and retains the boundaries on static references, recorded usage, supported syntax, and bounded scans. Registry publication and registry-install verification are pending. The VM source-build acceptance retained the existing 242 records; a separate real HF smoke workload added three successful requests and one credit-related failure. Its provider and route metadata were explicitly logged by the test application, not reconstructed from network traffic. Stable-package homepage FAQ claims remain unchanged; no website deployment is included.
-
-
-## Repository index — published preview.4, 10 October 2026
-
-Published and verified `0.1.6-preview.4`, superseding the unreleased/preparation status above. The npm package integrity matches the tested archive and `preview` points to this version. Direct registry installation and the restarted VM dashboard preserve all 246 real request records and 128 application files across passive refresh, with counts-only diagnostics and package-export checks passing. The release acceptance makes no inference calls; the separate earlier HF test supplied its provider/route identifiers explicitly. Static declarations remain distinct from actual usage. Stable `latest` is still `0.1.5`; homepage FAQ wording and site deployments are unchanged.
-
-
-## Phased repository indexing — unreleased source, 10 October 2026
-
-Reviewed startup, background collection, data handling, coverage and readiness claims. The source build opens the local dashboard before initial collection and indexes declarations in a dedicated worker. Repository-wide coverage limits become continuing batch budgets; per-file and parser protections remain, along with a worker memory ceiling. Fingerprints and sanitized parser metadata live only in process memory; no project files or persistent source cache are created. Rechecks start 60 seconds after a completed pass, while request/runtime collection keeps its existing interval and limits. Progress and failures remain explicit. The guide separates this unreleased behavior from published preview.4. No homepage FAQ wording, npm publication, or site deployment is implied.
-
-
-## Phased indexing release preparation — 10 October 2026
-
-Prepared `0.1.6-preview.5` for the existing npm preview channel. The source build passed all 281 verification tests. A separate 5,001-file synthetic repository on the four-core, 4 GiB VM exposed 25,001 references: URL ready in 43 ms, first declarations at about 1 second, full index at 4.1 seconds. An edit/deletion pass reused 4,998 files, read about 9 KiB, and completed in 1.27 seconds. These are fixture measurements, not a universal performance guarantee. The private VM source build preserved all 246 real request records and all 128 application files through passive refresh. Registry publication and installation verification are pending. The guide identifies behavior by minimum version; stable `latest`, homepage FAQ claims, and site deployments are unchanged.
-
-
-## Phased repository indexing — published preview.5, 10 October 2026
-
-Published and verified `0.1.6-preview.5`, superseding the unreleased/preparation status above. The npm integrity matches the tested archive and `preview` points to this version; stable `latest` remains `0.1.5`. A direct `npm install -g openmerit@preview` on the VM succeeded, and the persistent dashboard now runs that global registry package instead of the temporary source-build override. All 246 real records and 128 application files remain unchanged across passive refresh. Counts-only diagnostics, full JSON output, package exports, and all 61 packaged code/asset/metadata file hashes passed; served browser assets match the release. No inference calls were made. The existing activity/runtime limits and static-declaration evidence boundaries remain documented. Homepage FAQ wording and site deployments are unchanged.
-
-
-## Hosted sample synchronization — 10 October 2026
-
-Deployed the fictional sample at `dash.openmerit.site` with the preview.5 browser assets and current sample generator. The public data disclosure and sample-only API boundary remain intact; repository scanning, local runtime collection, and phased indexing do not run on visitors' environments. Historical range controls describe the available sample records, not a complete project-lifetime archive. The main-site FAQ and deployment remain unchanged. Live assets, sample counts, read-only API behavior, and desktop/mobile browser checks passed; see [the sample deployment record](site-terminal-preview.md).
-
-## Hosted enterprise comparison — 10 October 2026
-
-Reviewed evidence, pricing and readiness claims. The hosted comparison uses fictional workload volumes and published token rates, clearly labels model assignments as illustrative, and makes no measured quality or latency claim. Unknown costs remain unknown. No changes to local collection, consent, routing, evaluations, billing or the published npm preview are implied. The main homepage FAQ requires no change.
-
-
-## Insurance comparison evidence and preferences — 10 October 2026
-
-Reviewed the hosted demo's quality, price, privacy and model-selection claims. Replacements now require the selected public benchmark screen and a cost or paired-latency improvement. Publisher point estimates are distinct from application evaluations; missing evidence retains the baseline. Preference conflicts remain visible, including unresolved open-weight baselines under the closed-only option. ZDR is endpoint/account-specific and developer origin is separate from residency. Fictional insurance names and fixed token volumes remain explicit. No local discovery, runtime routing, evaluation-engine, npm or homepage FAQ behavior changes. Deployment verification is recorded separately.
-
-
-## Expanded comparison selection — 10 October 2026
-
-Reviewed the hosted preference behavior against the public guide. The dated catalog searches 25 offers across six configured services and distinguishes model identity from endpoint pricing and ZDR. A hard no-open-weights conflict blocks the complete After plan and its projected cost. Soft biases can produce identical selections; the UI exposes matches and equality with Default instead of implying arbitrary changes. Benchmarks remain public screening signals, not measured application-quality or endpoint-latency evidence. The main homepage FAQ and published npm behavior require no changes.
-
-
-### Incomplete comparison plans — 10 October 2026
-
-Reviewed hosted comparison claims after replacing the whole-plan block with a visible partial plan. The closed-weight requirement remains enforced per assignment: unresolved workflows have no After assignment or usage. Qualifying workloads remain inspectable, their subset coverage is disclosed, and complete-plan savings remain unavailable. No local collection, real routing, npm or homepage FAQ claims change.
-
-
-## Hosted preference comparison expansion — source, 10 October 2026
-
-Reviewed homepage FAQ claims against the expanded fictional comparison. The new application workloads, benchmark cohorts, fixed token profiles and preference-dependent costs affect only the hosted demonstration. They do not establish live model-routing performance, production discovery coverage or a new npm release. Existing public FAQ claims remain unchanged; detailed assumptions and limits are maintained in `inference-terminal.md`.
-
-
-## Preference overrides — source, 10 October 2026
-
-Reviewed comparison, evidence, approval and regression claims. This change is confined to the fictional hosted comparison: a selected preference may override benchmark and efficiency criteria, with explicit exceptions and truthful prices. It never weakens the live evaluation engine, routing approvals, endpoint compatibility or source collection. No real inference or insurance decision is made. The main homepage FAQ and published npm release remain unchanged. Hosted publication and verification are recorded separately.
-
-
-## Comparison visual hierarchy — source, 10 October 2026
-
-Reviewed the hosted comparison's presentation. The leading dark panel makes stage controls, fixed token costs and their modeled difference more prominent while keeping override disclosures and evidence visible. Selection and pricing rules are unchanged. No homepage FAQ, npm or live routing claim changes.
-
-
-## Primary domain migration — preparation, 12 October 2026
-
-The `.ai` migration changes hostnames and mail configuration, not product behavior or readiness. Existing homepage FAQ claims remain unchanged. The protected memo, OTP limits, reader data, and interactive demo must be preserved from the deployed Worker because this checkout lacks parts of the current production source. See [migration operations and verification](site-domain-migration.md) for cutover status; DNS preparation alone does not establish successful publication or email delivery.
-
-## Automatic light and dark appearance — unreleased source, 14 October 2026
-
-Reviewed homepage FAQ claims against the appearance-only change. Device-driven colors affect website reading surfaces, demos, and the Inference Terminal, including charts and overlays. They add no saved theme preference, inference calls, collection, routing, permissions, or billing behavior. No FAQ wording change is required. The terminal guide separates the unreleased source appearance from published preview.5. Website/npm publication is not implied by local builds; the main-app source divergence and integration boundary are recorded in [theme maintenance](site-themes.md).
-
-## Scout — unreleased branch preview, 14 October 2026
-
-Reviewed evidence, comparisons, data, background checks, cost, and readiness claims. Scout adds a separate prompt-only shortlist API and `/scout/` page; it does not change Pi approvals, evaluations, automatic swaps, terminal collection, or the published npm package. Its preview guide explains fixed ranking defaults, source/configuration differences, old visual evidence, missing speed, HTTP-only vision source transport, token-price assumptions, in-memory prompt handling, and hourly refresh lifetime. The homepage gains a navigation link; existing FAQ answers continue describing the terminal and Pi workflow and need no behavioral rewrite. Local checks do not establish a hosted deployment or state-of-the-art recommendation quality.
-
-## Scout launch preparation — 14 October 2026
-
-Reviewed freshness, real-data, privacy, price, speed and recommendation claims against the five-source importer and prompt-only API/MCP tool. The guide now documents independent source recovery, archived measurements, OmniDocBench's actual table version, uncertainty adjustment, and the limits of phrase matching. The page starts with a real empty input. Scout is a separate beta and does not establish SOTA task accuracy. No Pi/npm approval, budget or routing behavior changes. Hosted publication is verified separately.
-
-## Scout publication — 14 October 2026
-
-Scout's page, JSON API and MCP tool are now hosted, with an hourly Worker trigger and independently refreshed real public sources. The homepage navigation and generated documentation were published while preserving the deployed main application. Existing FAQ answers still describe the terminal/Pi workflow; no edits to those behavior claims were required. Publication and verification boundaries are recorded in [the Scout launch record](site-scout.md).
-
-## Scout comparison table — 14 October 2026
-
-Reviewed evidence, comparison, data handling and readiness claims for the semantic results table and bundled provider favicons. This changes presentation and evidence disclosure controls only; ranking, API/MCP responses and prompt handling remain unchanged. Icons use a curated local registry, with no remote favicon requests from the browser. No homepage FAQ wording change is required. Publication and browser verification are recorded separately in [the Scout launch record](site-scout.md).
-
-
-## Scout Decisions integration — release preparation, 14 October 2026
-
-Reviewed data handling, inference cost, evidence, scheduling and readiness claims. Scout now makes one server-side OpenAI Decisions call per prompt; its page and guide disclose this before submission. BFCL adds explicit tool-calling and external-memory evidence, with strict eligibility and source limitations. Fixed cost/quality/speed weights remain unchanged. The homepage FAQ continues to describe terminal/Pi behavior, so no FAQ copy change is required. This does not change terminal approvals, provider budgets, the npm package or local routing. Live publication is recorded separately in the Scout launch record.
-
-
-## Scout ranking revision — 14 October 2026
-
-Checked homepage FAQ claims against the proposed ranking revision. FAQ answers still describe the terminal/Pi workflow; Scout does not change its budgets, approvals or routing contracts. The Scout guide and table now disclose same-benchmark pairwise ordering, prompt-shaped reference cost, first-answer completion timing, tradeoff defaults, and incomplete comparison coverage. Reference estimates must not be described as measured task accuracy, actual endpoint latency or exact per-task charges. No general SOTA claim is established by the small task evaluations. Deployment and measured evaluation outcomes are recorded separately in the Scout publication notes.
-
-
-## Scout measured-task ranking — 14 October 2026
-
-Reviewed evidence, data, costs, scheduling and readiness claims for the Scout change. The separate Scout service uses calibration-only aggregates for narrow matching tasks, and public benchmark comparisons elsewhere. Held-out results are not loaded into ranking. Evaluation requires an explicit offline run; the existing hourly job still only refreshes six public feeds. No user task execution, saved prompt history, extra runtime inference, or database is introduced. Small samples and the selected candidate pool do not establish SOTA or a perfect ordered top five. Homepage FAQ claims concern the terminal/package and need no changes. Publication and test outcomes are recorded in `site-scout.md`.
-
-
-## Scout interface refinement — 14 October 2026
-
-Checked comparison, evidence and data-handling claims for the terminal-style Scout interface. Ranking and API/MCP contracts are unchanged. The page retains its OpenAI prompt-processing notice, measurement scope and limitations. Bundled provider marks replace boxed favicons; missing assets use text-only names. No homepage FAQ wording change is needed.
-
-## Scout compact controls — 15 October 2026
-
-Reviewed index coverage, evidence and data-handling claims. The header counts indexed models, distinct model creators, benchmark series and source feeds; it does not equate series with independent publishers or creators with hosting routes. Row disclosures retain benchmark and measured evidence, while sample/workload context moves into the existing limitations disclosure. The prompt-processing sentence is removed from the form at the user's request; the public Scout guide retains the OpenAI data-flow and retention description. Ranking, persistence and terminal/Pi behavior are unchanged. No homepage FAQ copy change is needed; publication is recorded separately in the Scout notes.
-
-## Scout execution evidence — 15 October 2026
-
-Reviewed evidence, comparisons, cost, latency, memory and data claims. The ranking extends the existing offline calibration path to specified code, dependent tool actions and external memory, with explicit execution/retention matching and full-episode cost/time. It adds no runtime provider evaluation, extra inference call, model-specific bonus or persistence of user prompts. The previous broad audit becomes development data; new held-out cases remain excluded. Failed candidate profiles are withheld, and missing action-pool coverage is filled through separate calibration before another fresh check. Selected pools and small samples cannot prove a universally correct ordered five. Homepage FAQ answers still describe terminal/Pi behavior and need no copy changes. Publication and fresh validation are recorded in the Scout notes.
-
-
-## Agent evaluation loop — unreleased source, 15 October 2026
-
-Reviewed harness support, evaluations, costs, budgets, data and scheduling. The new standalone eval commands are separate from terminal collection and Pi application evaluation. Source docs mark them unreleased; published npm 0.1.6 and homepage FAQ claims are unchanged. Project instructions are opt-in through init, not install hooks. Watch is foreground-only, cumulative reservations are admission controls rather than billing caps, unknown usage/cost stays unknown, and Scout eligibility filtering happens before ranking. No performance guarantee or automatic production model swap is introduced.
-
-
-## Scout model detail cleanup — 15 October 2026
-
-Reviewed evidence and comparison claims after removing the prose summary from every expanded model row. Measurement scope remains in Assumptions & limitations and source-linked evidence remains in the details. Ranking and API/MCP metadata are unchanged; homepage FAQ wording requires no change.
-
-
-## Agent evaluation npm preview — 15 October 2026
-
-Prepared the `0.1.7-preview.1` npm preview with explicit installation and setup instructions. The stable `latest` tag remains `0.1.6`. Reviewed homepage readiness, evaluation, budget and data claims: they describe stable terminal/Pi behavior and require no copy changes. The preview retains explicit initialization, connection scope, local execution and budget limitations; no install-time automation is claimed.
-
-## Agent evaluation accounting — unreleased source, 15 October 2026
-
-Reviewed evidence, comparisons, budgets, data and readiness against the source corrections. Native cost estimates and partial charges remain distinct from provider billing; reservations are not released by estimates. Recognized budget/environment blocks are unscored and stop comparisons. The Linux Codex sandbox probe is a local preflight action with no inference call or permission bypass. There is no provider-account ingestion in the product, production model swap or new background process. The guide distinguishes these changes from npm `0.1.7-preview.1`; stable homepage FAQ wording remains unchanged.
-
-## Agent evaluation budget selection — unreleased source, 15 October 2026
-
-Reviewed budget, approval, scheduling and readiness claims. Source planning now asks for an explicit $10, custom or no-fixed-cap allowance after model scope; no option is selected automatically. New project instructions reuse the saved choice, and reservations stay internal. Cumulative accounting survives replanning and limit changes. No fixed cap retains task/repetition/time limits and native permissions, but a foreground watcher can incur further charges until stopped. Provider billing limits remain independent. These changes are documented separately from published `0.1.7-preview.1`; the stable homepage FAQ still describes terminal/Pi behavior and needs no wording change.
-
-## Agent evaluation preview.2 release preparation — 15 October 2026
-
-Prepared `0.1.7-preview.2` for the existing npm preview channel, combining corrected accounting and execution-block handling with explicit budget selection. The public guide now describes these versioned behaviors together and keeps earlier VM findings historical. Stable `latest` remains `0.1.6`; homepage FAQ claims still describe terminal/Pi behavior and require no copy changes. Registry publication and fresh-install VM acceptance are recorded separately; a successful local build alone does not establish either.

package/docs/site-hero-resolution.md

@@ -1,62 +0,0 @@
-# Hero resolution correction
-
-The first generated 2 × 2 hero sheet was 2172 × 724 overall, leaving each pose only 1086 × 362. Displaying those cells at up to 1600 CSS pixels made the hero visibly soft. The hero now uses four standalone 2172 × 724 frames and a canvas with the same intrinsic dimensions. This restores four times as many pixels per pose; it does not enlarge the old low-resolution cells.
-
-## Final assets
-
-The table records the original full-resolution opaque frames. As of the 14 October 2026 source update, the homepage uses matching `hero-frame-{0..3}-transparent-v3.webp` cutouts at the same 2172 × 724 resolution. See [the transparency update](site-illustration-transparency.md); it was published on 14 October 2026.
-
-| Pose | Workspace asset | Source |
-| --- | --- | --- |
-| Rest | `site/assets/motion/hero-frame-0-v2.webp` | Original full-resolution PNG, `exec-c120bc1a-6cea-4824-a27a-81b382be4063.png`. |
-| Raise one third | `site/assets/motion/hero-frame-1-v2.webp` | `exec-589f6268-fb65-49db-a701-4b1964405226.png`. |
-| Raise two thirds | `site/assets/motion/hero-frame-2-v2.webp` | `exec-647442f6-76f6-408f-9322-01ce14d3b8ba.png`. |
-| Inspect | `site/assets/motion/hero-frame-3-v2.webp` | `exec-4906692d-eb37-46a1-9dc0-69545604a8ea.png`. |
-
-The three new poses were generated separately with the built-in image generation tool, using `site/assets/workshop-miniature-diverse.webp` as the reference. New masters are retained under `/Users/lazim/.codex/generated_images/01a0ccec-f664-7e43-bfcf-afbe4fa7f43c/`. The original master is under `/Users/lazim/.codex/generated_images/01a0c9d4-a3f3-7e12-aa03-2b46f42b5e83/`.
-
-Frames 1 and 3 returned at 2171 × 724; one white pixel column was added at the right edge to match the original canvas. No image was resized or upscaled. All four were exported as WebP at quality 94 with smart chroma subsampling. They total 928,000 bytes, including the initial poster.
-
-The original artwork is both the resting animation pose and the static poster. Playback loads the full-size files directly, validates matching dimensions and a minimum width of 2172, then copies each image at its native size. A missing or undersized frame leaves the sharp poster visible. The supporting illustration atlases and all existing timing/controls are unchanged.
-
-## Verification
-
-Chromium and WebKit checked locally and on the deployed site at 1440 CSS pixels with device pixel ratio 2, and at 390 CSS pixels with device pixel ratio 3. Every hero source and the canvas measured 2172 × 724; all four poses rendered distinct pixels. No v1 hero sheet or poster requests occurred. The supporting scenes, pause/resume persistence, reduced motion, failed/undersized-frame fallback, no-JavaScript poster, and page overflow checks passed. Screenshots of resting and raised poses were visually reviewed. The live HTML, player, and all four hero frames match the local files on both domains. Deployment: `10db0b26-2162-4aee-b8dc-6d28bb228d54`. Physical phone hardware was not tested.
-
-## Exact generation prompts
-
-### Frame 1
-
-```text
-Use case: precise-object-edit.
-Asset type: ONE FULL-RESOLUTION animation frame for a wide website hero.
-Input image 1 is the exact edit target, a 2172 x 724 photographic miniature workshop. Preserve its full resolution, crisp faces, fabric threads, tool edges and wood grain.
-Return ONE single full-width image at 2172 x 724 pixels (3:1), at least the source resolution. NOT a sprite sheet, NOT a collage, NOT a grid, NOT several panels. The entire output is ONE animation frame. This is a surgical edit of ONLY the seated gray-bearded South Asian craftsman in the ochre vest, third person from left. Preserve all other pixels as closely as possible: exact camera, crop, composition, bench dimensions, all five other makers, clothing, all their hands/tools, scale, notebook, vise, calipers, plant, boxes, sleeping dog, ground shadows and off-white background. No changing lighting, global softness, relighting, new visual style or shifting the scenery. Faces and tools must be as sharply detailed as the original. Do not crop, resize or reinterpret the scene.
-The older man's feet, stool, torso and shoulders stay fixed. Only his right forearm, wrist and the tool it holds articulate, with his head following slightly. The right hand is on the LEFT side of his body as seen by the viewer and holds the horizontal metal hand plane. His LEFT hand (viewer right) keeps holding the upright brown-handled tool exactly as in the reference. These must remain TWO SEPARATE solid tools, with natural hands and rigid object shapes. No stretching, warping, melting, crossfades or motion blur.
-POSE FOR THIS FRAME:
-Raise his RIGHT hand and its horizontal metal plane about one third of the way from the original chest-height position toward his face. The right elbow bends a little; the plane is just below his beard. Keep the left hand and its brown-handled tool stationary. His eyes begin looking at the raised plane.
-```
-
-### Frame 2
-
-```text
-Use case: precise-object-edit.
-Asset type: ONE FULL-RESOLUTION animation frame for a wide website hero.
-Input image 1 is the exact edit target, a 2172 x 724 photographic miniature workshop. Preserve its full resolution, crisp faces, fabric threads, tool edges and wood grain.
-Return ONE single full-width image at 2172 x 724 pixels (3:1), at least the source resolution. NOT a sprite sheet, NOT a collage, NOT a grid, NOT several panels. The entire output is ONE animation frame. This is a surgical edit of ONLY the seated gray-bearded South Asian craftsman in the ochre vest, third person from left. Preserve all other pixels as closely as possible: exact camera, crop, composition, bench dimensions, all five other makers, clothing, all their hands/tools, scale, notebook, vise, calipers, plant, boxes, sleeping dog, ground shadows and off-white background. No changing lighting, global softness, relighting, new visual style or shifting the scenery. Faces and tools must be as sharply detailed as the original. Do not crop, resize or reinterpret the scene.
-The older man's feet, stool, torso and shoulders stay fixed. Only his right forearm, wrist and the tool it holds articulate, with his head following slightly. The right hand is on the LEFT side of his body as seen by the viewer and holds the horizontal metal hand plane. His LEFT hand (viewer right) keeps holding the upright brown-handled tool exactly as in the reference. These must remain TWO SEPARATE solid tools, with natural hands and rigid object shapes. No stretching, warping, melting, crossfades or motion blur.
-POSE FOR THIS FRAME:
-Raise his RIGHT hand and its horizontal metal plane about two thirds of the way from the original chest-height position toward his eyes. The right elbow bends naturally; the plane is in front of the lower part of his face, wrist tilted very slightly to inspect the edge. Keep the left hand and its brown-handled tool stationary. His eyes look at the raised plane.
-```
-
-### Frame 3
-
-```text
-Use case: precise-object-edit.
-Asset type: ONE FULL-RESOLUTION animation frame for a wide website hero.
-Input image 1 is the exact edit target, a 2172 x 724 photographic miniature workshop. Preserve its full resolution, crisp faces, fabric threads, tool edges and wood grain.
-Return ONE single full-width image at 2172 x 724 pixels (3:1), at least the source resolution. NOT a sprite sheet, NOT a collage, NOT a grid, NOT several panels. The entire output is ONE animation frame. This is a surgical edit of ONLY the seated gray-bearded South Asian craftsman in the ochre vest, third person from left. Preserve all other pixels as closely as possible: exact camera, crop, composition, bench dimensions, all five other makers, clothing, all their hands/tools, scale, notebook, vise, calipers, plant, boxes, sleeping dog, ground shadows and off-white background. No changing lighting, global softness, relighting, new visual style or shifting the scenery. Faces and tools must be as sharply detailed as the original. Do not crop, resize or reinterpret the scene.
-The older man's feet, stool, torso and shoulders stay fixed. Only his right forearm, wrist and the tool it holds articulate, with his head following slightly. The right hand is on the LEFT side of his body as seen by the viewer and holds the horizontal metal hand plane. His LEFT hand (viewer right) keeps holding the upright brown-handled tool exactly as in the reference. These must remain TWO SEPARATE solid tools, with natural hands and rigid object shapes. No stretching, warping, melting, crossfades or motion blur.
-POSE FOR THIS FRAME:
-Raise his RIGHT hand and its horizontal metal plane to just below eye level so he can inspect its sole. The right elbow bends naturally, and his wrist turns the rigid plane a little toward his gaze. Keep his LEFT hand and its upright brown-handled tool stationary at their original position. His gaze lifts with the plane, shoulders and torso remain planted.
-```