openmerit 0.1.10 → 0.1.12

package/docs/getting-started.md

@@ -1,6 +1,6 @@
 # Getting started
 
-Stable npm 0.1.7 includes a separate [agent-evaluation CLI-change loop](agent-evaluations.md) for Claude Code, Codex and OpenCode, plus [Scout device setup for Claude Code](scout.md#connect-a-coding-agent). Neither is part of the Pi setup below.
+OpenMerit provides a passive Inference Terminal, Scout model-selection guidance, and a separate [agent-evaluation CLI](agent-evaluations.md). Pi Scout setup requires OpenMerit **0.1.12** or newer and Pi **1.5.0**. Package publication and website deployment are independent releases.
 
 ## Open your inference environment
 
@@ -12,65 +12,40 @@ cd /path/to/your/application
 openmerit dash
 ```
 
-The Inference Terminal is included in stable `openmerit@0.1.7`. It opens a local, read-only view of the selected application's services, models, recorded requests, and linked compute. It does not require Pi or a provider API key, make inference calls, or change model assignments. Supported code/configuration declarations identify inventory; request history requires existing supported logs or exports. See [the terminal guide](inference-terminal.md) for collection, privacy, configuration, and diagnostics.
+The Inference Terminal opens a local, read-only view of the selected application's services, models, recorded requests, and linked compute. It does not require Pi or a provider API key, make inference calls, or change model assignments. Supported code/configuration declarations identify inventory; request history requires existing supported logs or exports. See [the terminal guide](inference-terminal.md) for collection, privacy, configuration, and diagnostics.
 
 To inspect fictional data without installation, open the [hosted dashboard](https://dash.openmerit.ai/) or its [before/after comparison](https://dash.openmerit.ai/demo). Neither connects to your machine.
 
-## Set up model comparisons with Pi
+## Connect Scout to a coding agent
 
-The Pi integration is a separate workflow for evaluations and authorized model changes. It requires Pi 0.87 with a model provider configured, and a product repository where Pi can create and verify evaluation and observability artifacts. Provider credentials belong to Pi or its environment; OpenMerit does not accept them.
-
-Install the extension in Pi:
-
-```sh
-pi install npm:openmerit
-pi list
-```
-
-Run `/openmerit doctor` inside Pi to confirm that the extension is available.
-
-## Install from source
+Claude Code setup is described in [the Scout guide](scout.md#connect-a-coding-agent). For the new Pi integration, use Pi **1.5.0**, Node.js 22.19 or newer, and npm. Run the intended command in your shell:
 
 ```sh
-git clone https://github.com/laz-aslam/openmerit.git
-cd openmerit
-npm ci
+npx -y openmerit@latest install --client pi --scope user
 ```
 
-Start Pi with the extension:
+Approve the matching device code in the browser, then start a **new Pi session**. Only approve a request you initiated. User scope is the default and applies across projects. For one project, run this from that project's root instead:
 
 ```sh
-./node_modules/.bin/pi --no-extensions -e ./packages/pi/src/index.ts
+npx -y openmerit@latest install --client pi --scope project
 ```
 
-`--no-extensions` prevents a globally installed npm copy from conflicting with the source extension. Run `/openmerit doctor` inside Pi to confirm that the adapter and intent executor are available.
-
-## Establish a product profile
-
-Open the product repository in interactive Pi with the extension loaded. If the project has no OpenMerit state, the Pi adapter performs a bounded source preflight. It also scans after a settled Pi build turn, so an application created from an initially empty directory can enter setup without a slash command. A repository without such a target remains idle; use `/openmerit setup` only to recover or configure a custom integration explicitly.
+Each client/scope installation has its own private Scout key; project keys are stored outside the repository. Do not install overlapping Pi user/project adapters or a duplicate `openmerit` MCP entry. The installer reports conflicts rather than overwriting edited or unowned files.
 
-OpenMerit sends Pi a private, typed `establish_evals` intent. Pi must identify the application LLM call or shared route under evaluation and its exact incumbent application model. It inspects the application's outputs, tools, and failure modes to infer task-relevant metrics instead of asking you to invent them. Before running setup, Pi shows the proposed metrics, why each matters, the representative case and repetition counts, aggregation, any actual performance threshold, and estimated evaluation cost. You confirm or edit that plan together with the stable target ID, call sites, route key, budget, check cadence, scheduling mode, and automation permissions. Pi's own model is never an application target.
+The adapter connects Scout through Pi's native MCP and supplies the shared Scout rule and skill. Pi owns tool discovery, tool execution, model choice, permissions, and sessions. Scout recommends application-model candidates; it does not execute those candidates or change Pi's own model. There are no `/openmerit` lifecycle commands, automatic evaluation setup, scheduler, or LaunchAgent in this adapter.
 
-For an active-session demo, Pi defaults the baseline and post-swap verification cadence to one completed evaluation task unless you change it. OpenMerit rejects empty baseline or post-swap cadences.
+## Check, update, or remove Pi setup
 
-Pi is also asked to research preliminary model leads during setup. Each reported lead has a current price estimate and reputation summary with sources and check times. OpenMerit stores these leads with the project profile. The field is optional for compatibility with existing protocol-0.1 harnesses, and an empty list means no credible leads were found. It does not change the application model or count as a measurement.
-
-OpenMerit rejects successful setup without a confirmed task profile, at least one valid objective with an explicit sampling plan, a supervised-graduation policy, non-empty baseline and post-swap cadences, a budget, and evidence.
-
-The setup instruction asks Pi to run the application path with working provider authentication, execute each required collector and grader, inspect the resulting metric values, and retain verification artifacts. A metric that cannot be produced must be marked missing. This smoke run verifies the pipeline; it is not counted as a production baseline sample. OpenMerit still checks the reported coverage and evidence references, not the authenticity of a grader run itself.
-
-## Collect the baseline
-
-After setup, instrument the confirmed application target and use the product normally. Report application-task completions and cumulative metric windows through Pi's typed signal tool, including the application model where applicable, sample counts, and durable evidence. Pi's own model, tokens, cost, and latency are orchestration telemetry and do not satisfy product metrics. OpenMerit core checks the stored baseline windows at the approved cadence without calling Pi; missing evidence stays insufficient.
-
-## Find the frontier
-
-When the baseline meets every required metric threshold, OpenMerit issues the next approved nudges: discover candidates, run controlled challenger trials, and calculate the Pareto frontier. Pi performs that work. OpenMerit checks the returned result against the [Pareto specification](pareto-spec.md).
+```sh
+npx -y openmerit@latest status --client pi --scope user --check
+npx -y openmerit@latest doctor --client pi --scope user
+npx -y openmerit@latest remove --client pi --scope user
+```
 
-Candidate discovery uses current price, capability, availability, reputation, and benchmark signals to shortlist models worth testing. These are starting clues, not evidence that a model performs well on your application. OpenMerit collects preliminary leads at setup, then refreshes them, probes availability, and freezes the incumbent plus challengers. Pi must use the same cases, application revision, prompt, tools, grader, and run count, with a recorded shuffle seed. It preserves one experiment manifest and reports measured quality, cost, latency, tokens, and other required metrics. OpenMerit durably carries the accepted candidate set and assessments into later intents rather than relying on Pi conversation history. A model proposal must come from the verified frontier of those measured candidate results, not from price or reputation alone.
+Use `--scope project` from the original project root for a project installation. `login` and `logout` accept the same `--client` and `--scope` flags. These commands target that installation, not another client's connection. Updating Pi setup requires explicitly rerunning `install` and starting a new session; no Pi auto-update hooks are installed. Installing or updating the npm package alone does not reconfigure Pi.
 
-## Approve an early swap
+See [the Pi extension guide](pi-extension.md) for installed paths, migration from Pi 0.87, and SDK embedding. Use [troubleshooting](troubleshooting.md) for setup failures.
 
-With automatic swaps disabled, a model proposal that passes frontier validation waits for `/openmerit approve`. That authorizes Pi to apply only the proposed change. OpenMerit then requires post-swap evaluation; the approved policy determines rollback behavior. Automatic swaps may bypass per-proposal approval when enabled and the configured verified-swap threshold is reached, including when that threshold is zero.
+## Evaluate application changes
 
-Continue with [your first supervised trial](first-trial.md) for a practical walkthrough.
+The standalone `openmerit eval` CLI is unchanged by the new Pi adapter. It evaluates Claude Code, Codex and OpenCode through explicit task, scope, budget and grader configuration; see [agent evaluations](agent-evaluations.md). The core evaluation coordinator remains available to custom harness integrations, but the removed Pi 0.87 lifecycle adapter is not the way to invoke it.

package/docs/index.md

@@ -1,6 +1,6 @@
 # OpenMerit documentation
 
-These guides describe the implementation on **main**. Stable npm `openmerit@0.1.7` includes the Inference Terminal, agent-evaluation CLI and Scout device setup for Claude Code. The website, hosted samples, Scout service and npm package are deployed independently; dated receipts describe the versions actually tested.
+These guides distinguish current source work from published behavior. OpenMerit **0.1.12** adds native Scout support for Pi **1.5.0**, replacing the old Pi 0.87 evaluation extension. The Inference Terminal and standalone agent-evaluation CLI are separate products and are unchanged by that replacement. The website, hosted samples, Scout service and npm package are deployed independently; dated receipts describe the versions actually tested.
 
 ## See your inference environment
 
@@ -20,11 +20,15 @@ Start with [installation and setup](getting-started.md) or the [Inference Termin
 
 For a shortlist before building an integration, the separate [Scout beta](scout.md) accepts a task description and returns up to five evidence-backed model candidates. It is available at [openmerit.ai/scout/](https://openmerit.ai/scout/), with a prompt-only JSON API and MCP tool for coding agents.
 
-## Evaluate model changes with Pi
+## Connect Scout to Pi
 
-The separate Pi 0.87 integration asks a coding harness to establish evaluations, gather application measurements, and test candidates. OpenMerit coordinates the approved lifecycle, records evidence references, validates structured results and frontier conformance, and requests authorized changes. The harness executes the work; the terminal does not perform this workflow.
+The thin Pi 1.5.0 adapter uses native MCP and shared Scout guidance. Pi owns tools, models, permissions and sessions; the adapter has no `/openmerit` lifecycle commands, evaluation scheduling, LaunchAgent or automatic updates.
 
-Follow [Pi setup](getting-started.md#set-up-model-comparisons-with-pi), then [your first supervised trial](first-trial.md).
+Follow [setup](getting-started.md#connect-scout-to-a-coding-agent) and [the Pi guide](pi-extension.md), including browser approval, per-client/scope credentials, explicit reinstall updates and SDK requirements. Registry setup requires OpenMerit 0.1.12 or newer.
+
+## Evaluate application changes
+
+Use [the standalone evaluation CLI](agent-evaluations.md) for Claude Code, Codex and OpenCode. Custom harnesses may use the core coordinator. The following guides retain core concepts and historical Pi 0.87 workflows; they do not describe the new Scout adapter:
 
 - [Metrics and evidence](metrics-and-evidence.md): measurements, sample requirements, and readiness.
 - [Comparisons and swaps](lifecycle.md): baseline, challenger trials, approval, verification, and rollback.
@@ -33,8 +37,8 @@ Follow [Pi setup](getting-started.md#set-up-model-comparisons-with-pi), then [yo
 
 ## Operate and troubleshoot
 
-[Commands](commands.md) and [project files and logs](operations.md) explain status, pause, diagnostics, and recovery. [Troubleshooting](troubleshooting.md), [security and data](security.md), and [current limitations](roadmap.md) describe the boundaries to check before relying on automation.
+[Troubleshooting](troubleshooting.md), [security and data](security.md), and [current limitations](roadmap.md) explain current Pi setup and its boundaries. [Commands](commands.md) and [project files and logs](operations.md) also retain explicitly historical Pi lifecycle references alongside standalone/core information; their old pause and recovery commands are not part of the new adapter.
 
 ## Build an integration
 
-Pi is the implemented coding-harness adapter. Other harnesses can implement the protocol and coordinator boundary described in [architecture](architecture.md) and [the adapter guide](adapter-guide.md). The [Pareto specification](pareto-spec.md) defines comparison rules; [testing and validation](testing.md) distinguishes automated coverage from product evidence.
+Pi now supplies a native Scout connection, not an evaluation `HarnessAdapter`. Custom evaluation harnesses can implement the protocol and coordinator boundary described in [architecture](architecture.md) and [the adapter guide](adapter-guide.md). The [Pareto specification](pareto-spec.md) defines comparison rules; [testing and validation](testing.md) distinguishes automated coverage from product evidence.

package/docs/inference-terminal.md

@@ -79,7 +79,7 @@ openmerit dash --no-open
 | `--demo` | Use only a fictional local sample; no local collectors run |
 | `--help` | Show usage |
 
-Ctrl+C stops collection. The terminal has no persistent daemon and is independent of Pi's pause and scheduling commands.
+Ctrl+C stops collection. The terminal has no persistent daemon and is independent of core evaluation pause/scheduling policy. The unreleased Pi 1.5.0 Scout adapter exposes no pause or scheduling commands.
 
 ## Repository indexing
 

package/docs/lifecycle.md

@@ -1,5 +1,7 @@
 # Improvement lifecycle
 
+**Core reference / historical Pi workflow:** this lifecycle remains available through the coordinator for custom harnesses. Pi-specific actions below describe the removed Pi 0.87 adapter, not the unreleased Pi 1.5.0 native Scout adapter. The replacement has no lifecycle commands, evaluation setup, swaps, or scheduling. See [Pi setup](pi-extension.md) or the separate, unchanged [evaluation CLI](agent-evaluations.md).
+
 ## Stages
 
 1. **Unconfigured** — no confirmed profile exists.

package/docs/operations.md

@@ -1,5 +1,7 @@
 # Project state and operations
 
+**Scope — unreleased Pi replacement:** the evaluation lifecycle files and `/openmerit` commands below describe the core coordinator and historical Pi 0.87 adapter. The Pi 1.5.0 Scout adapter does not create or advance that lifecycle, manage scheduling, or expose those commands. See [current Pi paths and targeted shell commands](pi-extension.md). Terminal files remain current; standalone evaluation files are documented in [agent evaluations](agent-evaluations.md). Preserve older state and separately remove any legacy background job when migrating.
+
 ## State location
 
 Operational data lives under `.openmerit/` in the target product repository. It should be ignored by version control because it can contain local lifecycle state and evidence locations.

package/docs/pi-extension.md

@@ -2,53 +2,57 @@
 
 ## Supported version
 
-The adapter targets Pi 0.87 and declares `>=0.87.0 <0.88.0`. Development uses 0.87.0 without modifying a globally installed Pi.
+OpenMerit **0.1.12** adds a Scout adapter for Pi **1.5.0**. It replaces, rather than upgrades in place, the Pi 0.87 evaluation adapter. The `@latest` commands below require OpenMerit 0.1.12 or newer. Package publication and website deployment remain independent releases.
 
-## Loading
+## Installation
 
-Install the published package with `pi install npm:openmerit`. For development
-from a checkout, load the source extension with:
+With Node.js 22.19 or newer, npm, and Pi 1.5.0 installed:
 
 ```sh
-./node_modules/.bin/pi --no-extensions -e ./packages/pi/src/index.ts
+npx -y openmerit@latest install --client pi --scope user
 ```
 
-The isolation flag avoids duplicate `openmerit_complete_intent` and `openmerit_report_signal` registrations when npm `openmerit` is also installed in Pi's user settings.
+Approve the matching browser device code and start a new Pi session. Scope defaults to `user`; use `--scope project` from the project's root for project-local setup. Each client and scope gets an independent key and approval; project keys are also separated by project. The npm package alone does not configure Pi.
 
-Use `/openmerit doctor` to confirm that the adapter and intent executor are available.
+The website's **Add to Pi** action is copy-only and sits below the Claude action, with the Pi logo before the label. It copies the installer command; it does not open a Pi deep link or prove installation. The button requires the corresponding Scout website deployment.
 
-Use `/openmerit logs` to locate the project-local audit stream, exporter failures, evidence manifests, and state while testing an end-to-end run.
+## Installed files and credentials
 
-On `session_start`, an interactive unconfigured project receives a bounded source preflight. The adapter also repeats that bounded detection after a settled Pi turn. This lets Pi build an application from an empty directory and then receive an automatic `establish_evals` intent without requiring `/openmerit setup`. Durable active-intent state prevents duplicate setup nudges. Non-interactive runs do not attempt a confirmation flow.
+| File | User scope | Project scope |
+| --- | --- | --- |
+| Native extension bundle | `~/.pi/agent/extensions/openmerit-scout.ts` | `.pi/extensions/openmerit-scout.ts` |
+| Credential-path reference | `~/.pi/agent/extensions/openmerit-scout.json` | `.pi/extensions/openmerit-scout.json` |
+| Shared Scout skill | `~/.pi/agent/skills/openmerit-scout/SKILL.md` | `.pi/skills/openmerit-scout/SKILL.md` |
+| Installer ownership record | `~/.pi/agent/openmerit-install.json` | `.pi/openmerit-install.json` |
 
-If Pi exits while an intent is active, the adapter restores its completion tool and resends that same persisted intent on the next interactive session so the harness can continue it.
+`PI_CODING_AGENT_DIR` overrides the user agent directory. The connection JSON contains a `credentialsPath`, not the key. The default private key paths are `~/.config/openmerit/pi/user/credentials.json` for user scope and `~/.config/openmerit/pi/<project-id>/credentials.json` for project scope. The project ID derives from the resolved project root; run targeted commands from that root. `OPENMERIT_CONFIG_DIR` or `XDG_CONFIG_HOME` can override the private configuration base. Do not copy credentials into the project or model instructions.
 
-For configured projects with a confirmed application target, session start reports the available model catalogue and a scheduled tick. Application instrumentation reports idempotent completed-task and metric-window signals. OpenMerit evaluates the confirmed policy before issuing work. On macOS, Pi can install a per-project user LaunchAgent after you confirm persistent execution and authorize infrastructure changes in the policy. It uses the selected authenticated Pi model, checks for due work locally every five minutes, and starts a headless Pi only when the due core check finds downstream harness work. If installation or background authentication fails, the adapter reports a scheduling gap. Other platforms still need an external scheduler.
+The extension reads credentials at session startup and registers the `openmerit` HTTP MCP server with direct tool exposure. Authorization is an HTTP header, not prompt content. Missing or invalid configuration produces a sanitized setup diagnostic, not an automatic login. The adapter performs no per-turn HTTP connection checks or credential reads.
 
-The macOS background runner is not yet product-validated for candidate work. A local runner test verifies that an insufficient baseline is checked and recorded without starting Pi. A model-driven runner is capped at 15 minutes and records a nonzero exit and active intent ID on failure. Do not infer that unattended candidate discovery or swapping has passed end-to-end validation.
+## Native ownership and shared guidance
 
-The adapter does not convert Pi's own provider usage into application metrics. Application-task signals must carry the application model, target ID, and durable evidence; application telemetry may include provider-reported USD cost, token counts, and wall-clock latency. If automatic setup is active when interactive input arrives, the input is queued and released after setup completes instead of racing the setup turn.
+Pi supplies the MCP connection, tool discovery and execution, permissions, and session management. The thin adapter adds the same Scout rule and skill used by the shared installer as structured system-prompt sections. It leaves the host's model, tool allow/exclude lists, and other prompt sections intact. This is guidance to consult Scout before application-model choices, not enforcement of tool invocation or permission to download, spend, deploy, or change models. Scout's [data-handling policy](scout.md#refresh-and-data-handling) applies to submitted tasks.
 
-Pi also exposes `openmerit_report_signal` for verified `product_task_completed`, `metric_window_available`, and `verification_window_completed` events. Evals or observability work performed by Pi can submit measured application-target metric records through this typed ingress using stable signal IDs. For baseline checks, send cumulative metric windows with sample counts and evidence references. The background wakeup only checks whether a time-based action is due; it does not collect application results by itself. `/openmerit assess` checks those stored windows locally and starts candidate discovery only when all required metrics are ready.
+## Updates and targeted lifecycle commands
 
-## Intent delivery
-
-The extension persists each intent as a custom Pi session entry, sends private extension-authored context with `display: false`, and triggers a follow-up Pi turn. The intent describes the outcome, constraints, evidence, task profile, and authorization boundary without prescribing Pi's method.
-
-Pi must finish by calling `openmerit_complete_intent` exactly once. Success without evidence is rejected. Setup, assessment, and frontier intents receive additional structured-output checks. During setup, Pi first presents its inferred metrics and sampling plan to the user. The accepted task profile records how many representative cases and repetitions each metric needs and how results are aggregated; sample counts are kept separate from optional performance thresholds.
-
-If Pi exits while an intent is active, the next session reports the recovered intent. Use `/openmerit cancel` to record an explicit cancellation before retrying; OpenMerit does not silently reinterpret interrupted work as success.
+```sh
+npx -y openmerit@latest status --client pi --scope user --check
+npx -y openmerit@latest doctor --client pi --scope user
+npx -y openmerit@latest login --client pi --scope user
+npx -y openmerit@latest logout --client pi --scope user
+npx -y openmerit@latest remove --client pi --scope user
+```
 
-The extension replaces the completion tool definition whenever an intent becomes active. Its `outputs` property therefore exposes the canonical schema for that exact intent instead of untyped JSON. Pi validates the arguments before execution and requests provider-side JSON Schema constrained sampling when supported. OpenMerit validates the canonical schema and semantic rules again when accepting the result. OpenMerit records the exact incumbent during setup, freezes accepted candidates after discovery, and carries accepted assessments and the experiment manifest into frontier calculation so these transitions do not rely on conversational memory.
+Replace `user` with `project` for a project installation. Removal and logout target that client's scope/key, not a Claude Code installation or another project. Edited or unowned files are not silently overwritten or deleted. Resolve duplicate user/project adapters or existing `openmerit` MCP entries before installing.
 
-## Model changes
+Updates are **explicit reinstall only**: rerun `install --client pi` with the same scope and start a new session. There are no Pi auto-update hooks; Claude Code update-hook settings do not apply to Pi.
 
-The extension never treats Pi's model as the application target. After policy authorization, it sends a bounded, target-bound `apply_model_swap` intent. Pi performs the application-route change and returns configuration proof; the target ID must match the confirmed application LLM target, and Pi's own model must remain unchanged.
+## SDK embedding
 
-## Jev System One
+`openmerit/pi` exports `createScoutPiExtension({ credentialsPath })` and a default extension created by that factory. SDK hosts must explicitly load Pi's own **`createMcpExtension()`** alongside the Scout extension; the Scout factory does not create an MCP runtime. The Pi CLI already supplies native MCP. The explicit credential path takes precedence over the installed adjacent connection JSON, with the shared Pi user credential path as the fallback when that JSON is absent. The host supplies its own model, tools, session and permission configuration.
 
-Jev is not integrated into OpenMerit. If configured in Pi, the intent asks Pi to use harness-configured fast decision resources aggressively for bounded ranking, triage, and judgment. Credentials remain outside OpenMerit.
+## Migration from Pi 0.87
 
-## Non-interactive modes
+Remove or disable the old `npm:openmerit` Pi package registration before loading this adapter, and explicitly remove any previously authorized background job through its existing management path. New setup does not promise to uninstall a legacy LaunchAgent. Preserve `.openmerit/` evaluation state and evidence if needed; do not delete them as a setup repair.
 
-A harness must not attempt interactive confirmation in a mode without dialog-capable UI. It should return a waiting-for-user or failed result with an actionable reason.
+The replacement has no `/openmerit` commands, `openmerit_complete_intent` or `openmerit_report_signal` tools, source preflight, evaluation lifecycle, intent recovery, scheduling, automatic swaps, or LaunchAgent. The [core coordinator](architecture.md) remains available for custom harnesses. The [standalone evaluation CLI](agent-evaluations.md) is unchanged. Older lifecycle guides are retained as historical adapter/core references, not instructions for this Scout adapter.

package/docs/roadmap.md

@@ -2,7 +2,7 @@
 
 ## Current status
 
-The Inference Terminal provides a read-only view of existing application evidence. The Pi integration coordinates supervised model-comparison trials. Neither a populated dashboard nor passing implementation tests establishes that an application has better models, trustworthy evaluations, or reliable unattended automation.
+The Inference Terminal provides a read-only view of existing application evidence. The Pi **1.5.0** adapter in OpenMerit **0.1.12** provides only native Scout MCP and shared guidance, not evaluation coordination. The standalone evaluation CLI and reusable core coordinator remain separate. Neither a populated dashboard nor passing implementation tests establishes that an application has better models, trustworthy evaluations, or reliable unattended automation.
 
 ## Known limitations
 
@@ -10,10 +10,11 @@ The Inference Terminal provides a read-only view of existing application evidenc
 - History and inventory can be incomplete because of source availability and read/parser limits. “All time” means retained supported evidence, not a complete lifetime archive. Cloud account usage is not fetched.
 - Machine and runtime readings describe shared resources; they are not per-request resource measurements. Static endpoints do not prove deployment, availability, or physical location.
 - Hosted samples and the before/after dashboard demo are fictional. Their cost projections and public benchmark screens do not establish application quality or latency.
-- Pi 0.87 is the only implemented coding-harness adapter. Jev must be configured and invoked by the harness; OpenMerit provides no Jev client.
-- Setup asks the harness to establish task-specific evaluations and observability. Generic coding checkpoints cannot replace product telemetry, and structured-result validation cannot prove external evidence is truthful.
-- Background wakeups require a logged-in macOS user, working headless Pi authentication, and explicit persistent-execution/infrastructure permission. Other platforms require an external scheduler. Deterministic baseline checks have automated coverage; unattended candidate discovery and model changes still need representative product validation.
-- Pause persists and gates automatic work, but does not cancel active intents, stop explicit commands, or stop the standalone terminal.
+- The Pi 0.87 evaluation adapter is removed in source. Pi 1.5.0 setup needs explicit browser approval, a new session and an explicit installer rerun for updates. It has no lifecycle commands, scheduler, LaunchAgent or auto-update hooks. The host owns tools, model, permissions and sessions; SDK hosts must load Pi's native MCP extension explicitly.
+- Scout rule/skill availability does not guarantee invocation or measured application quality. Missing project policy requires asking; unavailable or insufficient Scout evidence requires pausing the model choice.
+- Custom core evaluation harnesses must establish task-specific evaluations and observability. Generic coding checkpoints cannot replace product telemetry, and structured-result validation cannot prove external evidence is truthful.
+- Background provisioning and unattended validation belong to custom evaluation integrations, not the new Pi adapter. Existing legacy Pi jobs require separate cleanup during migration.
+- Core pause policy does not cancel active intents or stop explicit commands or the standalone terminal. It is not a command exposed by the new Pi adapter.
 - Challenger accounting depends on reported costs. It cannot independently meter provider billing or stop an in-flight request. Use provider spending controls as well as the confirmed evaluation policy.
 - The source interface and hosted dashboard follow the device's light/dark preference. That UI change is not included in npm 0.1.6.
 

package/docs/scout-data-policy.md

@@ -1,81 +1,39 @@
-# Scout beta data policy
+# Scout data policy
 
-Updated 25 October 2026.
+Updated 29 October 2026.
 
-**Source only, not released:** Scout setup usage/installation analytics now defaults on without an analytics-enabling prefix in the normal copied command. `OPENMERIT_TELEMETRY=0` or `DO_NOT_TRACK=1` disables it and propagates to device approval and installed MCP headers. Scout's browser usage/unlink choices and account opt-outs remain effective; MCP prompt-content capture stays off. Terminal/evaluation analytics remain opt-in. These defaults require an updated npm release before prompt deployment; npm 0.1.9 still has the opt-in setup behavior described below.
+OpenMerit operates Scout. This policy covers its hosted website and connected clients.
 
-**Coding-agent setup, 24 October 2026:** hosted Scout supports device sign-in and MCP; stable npm 0.1.8 installs Claude Code's MCP configuration, startup rule and Scout skill after approval. This supersedes the 23 October web-placeholder reset. Scout stores the approving account, device name you chose (the host name by default), client, scope, timestamps and hashes of device codes and keys, but never a plaintext key. Local setup stores the key in private configuration; external coding agents have their own data handling. Installation and startup guidance do not guarantee an agent will invoke Scout.
+**Don't submit confidential or sensitive information.** Automated redaction is not guaranteed to remove it.
 
-**Lifecycle telemetry — npm 0.1.9 and matching Scout deployment:** this revision adds consent-gated setup-click, clipboard/launch-request, device-authorization, installation/component-verification and MCP-invocation diagnostics. Linked setup uses random setup and installation UUIDs to correlate those milestones; the local ownership record and installed MCP headers retain them across sessions/upgrades. Unlinked mode omits these IDs. Copied setup prompts carry usage/unlink preferences into installation, while standalone CLI telemetry remains opt-in and DNT overrides it. Installed MCP prompt-content capture remains off. The revision also adds bounded delivery retries and sanitized Cloudflare delivery counters, without identity, content, URLs, device codes or credentials in those counters. Existing installations need an installer rerun; these changes do not backfill earlier activity. Release acceptance is recorded separately.
+## Data we use
 
-**Version-5 diagnostics:** Scout serving builds collect page views/leaves, bounded engagement, allowlisted acquisition/UTM and browser/device categories, and sampled browser performance observations where supported and usage analytics is enabled. Native URL properties use only reconstructed public paths, never raw visitor URLs, queries or fragments. Linked activity can join same-tab visits, signup and searches; unlinking retains request-only server identity, not a cross-request funnel. Feedback records a useful/not-useful rating and optional fixed reason, with linked trace/retry correlation, not free text. Server diagnostics include bounded stage/provider failure codes and actual pipeline attempt tokens when reported, not invented charges or executions of recommended models. Main-site/docs collection and CLI publication have separate release boundaries. No replay or ranking experiment is enabled, and none of the prompt-content or retention controls below change.
+- **Service data:** Your submitted task and related information are processed by an AI service provider, even with analytics off. We also retain account, authorization and device details needed to provide access.
+- **Optional analytics:** When enabled, we collect usage, recommendations, feedback, setup activity, device/browser categories, performance and error information to improve Scout and fix problems. Account analytics may include your name, verified email and sign-in provider, and may link activity before and after sign-in.
+- **Shared content:** When prompt sharing is enabled, analytics also includes task text and analysis. We use this for product improvement, not foundation model training. There is no session recording.
 
-Scout is operated by OpenMerit. This policy covers the hosted Scout website, recommendation API and MCP endpoint. It describes current data handling, not a promise that beta data is anonymous or exempt from privacy requirements. External coding agents, the local Inference Terminal and other OpenMerit services have separate data flows.
+Service providers handle hosting, AI processing, sign-in and analytics on our behalf. They have their own retention and security policies; processing is not guaranteed to stay in one region or have zero retention. External coding agents and linked services have separate policies.
 
-## Help improve Scout during beta
+## Your choices
 
-Scout processes your submitted task to generate recommendations. With usage analytics enabled, we record recommendations and usage diagnostics for product evaluation, improvement and debugging, not foundation model training. Our service providers process data on our behalf.
+Manage sharing in [Privacy & analytics](/scout/privacy/). Browser usage analytics and prompt sharing default on unless you previously opted out. Saved opt-outs, Do Not Track and Global Privacy Control are respected.
 
-**Beta revision, effective 22 October 2026.** Browser prompt sharing defaults on only where no content choice is stored; a saved off choice remains off. You can turn sharing off before submitting a task, or choose not to link this browser's activity to your account. Browser privacy signals still take precedence. A beta label or this notice does not establish consent or another legal basis.
+You can disable usage analytics, disable prompt sharing, or stop linking this browser's activity to your account. Unlinking does not remove earlier links or stop separate account-profile analytics; task text can still identify you.
 
-**Don't submit confidential or sensitive information.** Describe the work rather than pasting credentials, private customer records or real documents. Automated redaction cannot recognize every secret or personal detail.
+Setup analytics defaults on. Set `OPENMERIT_TELEMETRY=0` or `DO_NOT_TRACK=1` to disable it. Installed coding-agent connections do not share prompt content for analytics. Terminal and evaluation analytics remain opt-in. Rerun setup to apply changed preferences to existing installations.
 
-## What we process and why
-
-| Data | Purpose and collection |
-| --- | --- |
-| Submitted task and model restrictions | Required to interpret the task, find suitable models and return recommendations. Scout sends task information to OpenAI even when analytics is off. |
-| Recommendations and search diagnostics | When usage analytics is enabled, PostHog receives task categories, model IDs, ranks, available quality/cost/latency evidence, timings, cache status and outcomes. These describe recommendations, not execution of those models on your data. |
-| Product interactions and errors | Enabled analytics includes visits, preset selections, sign-in activity, results viewed, evidence opened, copies, provider-link clicks and coding-agent setup activity. API/MCP events record request outcomes. Lifecycle-enabled builds add allowlisted method/tool, reported agent/harness and version, setup/installation correlation and verified-connection diagnostics. A launch request is not proof an app opened, and key authorization is not proof of installation. Error reports use bounded categories and application stack locations, not raw error messages. |
-| Account details | Clerk handles Google/GitHub login. Enabled account analytics can synchronize your name, verified primary email, signup time and connected providers to PostHog. Account and session lifecycle events help us understand onboarding and returning use. |
-| Optional prompt content | Only when prompt sharing is enabled, PostHog also receives the submitted prompt and written task breakdown, for at most three tasks. Prompt text is limited to 4,000 characters, with up to 1,000 characters per excerpt or five-layer field. Common sensitive patterns are removed where detected; this is not guaranteed anonymization. All such text is confined to `$ai_trace.$ai_input_state={prompt,tasks}`; new ordinary `scout_search_details` events contain no prompt, excerpt or layer prose. |
-
-Scout does not use session replay, record keystrokes, or automatically capture every page element. Our analytics code does not forward bearer tokens, cookies, raw Clerk identifiers or visitor IP addresses to PostHog. Hosting and authentication providers still process the connection and security information needed to run their services.
-
-## Your choices and account linkage
-
-Open **Privacy & analytics** in the [Scout footer](/scout/#analytics-settings):
-
-- **Share usage and account analytics** controls optional product events and account synchronization. It is on by default unless you opt out or a supported browser privacy signal disables it.
-- **Share my task prompts and breakdowns for product improvement** defaults on only without a stored content choice. Saved off, general opt-out, DNT/GPC and unreadable preference storage keep content off; usage analytics must also be enabled.
-- **Don’t link this browser’s activity to my account** applies to this browser/request only, not your account everywhere. It sends `X-Scout-Analytics-Account: off`.
-- Turning sharing off stops future analytics collection. It does not stop necessary task processing, undo in-flight work or delete information already stored.
-
-Scout respects Do Not Track and Global Privacy Control for these analytics. An authenticated browser also communicates its usage preference to the server; the latest received account preference controls background synchronization. A browser that is offline or not signed in cannot update that account preference until it reconnects and authenticates.
-
-API/MCP clients can send `X-Scout-Analytics: off` to disable analytics. Prompt text still requires explicit `X-Scout-Analytics-Content: on`; general opt-out and supported privacy signals take precedence. CLI content capture is always off. Older 0.1.8 setup does not inherit this browser's account-linkage setting; the 0.1.9 lifecycle revision explicitly carries usage and unlink preferences into the command and installed headers. Later browser changes do not rewrite existing agent configuration; rerun setup to update it. Request-only refusals in that revision do not overwrite saved account-wide preferences.
-
-Enabled signed-in analytics normally uses a stable account identifier linked to the profile above; hashing does not make it anonymous, and a pre-sign-in visit can be joined after login. In unlinking mode the server uses fresh unrelated random identifiers, sends no profile/identify operation, ignores previously linked browser identifiers and supplied trace IDs, and does not return an analytics trace ID for later interactions to reuse. Account opt-out and deletion gates still apply before sending. Clerk profile/lifecycle analytics can continue separately under general usage consent. Past records remain linked; signing out or selecting this option does not unlink them. Unlinked request events cannot support cross-request funnels or automatic account-based historical deletion. Prompt text itself may identify a person: unlinking is not anonymization.
-
-## Service providers
-
-| Provider | Role |
-| --- | --- |
-| Cloudflare | Hosts Scout, handles requests and rate limits, holds the public model catalogue, and coordinates analytics preferences, webhook receipts and deletion state. |
-| OpenAI | Processes task descriptions and related public evidence for interpretation, matching and query embeddings. Its API retention policies apply; Scout does not promise zero retention by OpenAI. |
-| Clerk, Google and GitHub | Provide authentication and account/session handling. Google or GitHub is contacted according to the sign-in method you choose. |
-| PostHog | Stores optional product/account analytics, recommendation diagnostics and separately enabled prompt content. Scout uses PostHog's EU ingestion endpoint; this is not a claim that every provider processes data only in the EU. |
-
-Scout's twice-daily research uses Parallel and public model/benchmark sources. Visitor prompts are not sent to Parallel, benchmark publishers or the recommended-model providers as part of that research. Opening a provider link takes you to a separate service under its own policies.
+Turning sharing off stops future optional collection. It does not stop required processing or delete stored data.
 
 ## Storage and retention
 
-Submitting a task is not a zero-storage operation, even with analytics disabled:
-
-- **In your browser:** Scout temporarily keeps a prompt draft in tab storage during sign-in. Analytics preferences use local storage; anonymous visit/session-transition markers use tab storage when analytics is enabled. Clerk manages authentication storage separately.
-- **Search cache:** Scout temporarily keeps exact tasks and results in server memory for reuse. Cached results are eligible for reuse for 30 seconds. Expired entries are removed on subsequent cache access or when the instance ends; this is not a guarantee of physical erasure at exactly 30 seconds.
-- **PostHog:** Content uses the provider's [AI event retention policy](https://posthog.com/docs/ai-observability/data-retention): large AI properties including `$ai_input_state` are stored in `posthog.ai_events` for 30 days and stripped from normal events at ingestion. Metadata remains under normal event retention. Storage separation and the 30-day setting have been checked with synthetic data; actual expiry and backup erasure have not been independently verified. Historical v3 `scout_search_details` may still contain content outside those AI properties. There is no custom retention cron or content export, and no claim of retroactive deletion. Other events and profiles remain subject to applicable retention/deletion settings. Disabling sharing is not a deletion request.
-- **Account synchronization:** Cloudflare retains preference state and pseudonymous delivery/deletion records, not a second copy of your name, email or prompts. Pending lifecycle events without a known preference are bounded and expire after seven days. Deletion tombstones are retained to prevent delayed events from recreating an account's analytics.
-- **Historical records:** Before the 22 October 2026 consolidation, Scout stored prompts and recommendation evidence in a private Cloudflare Analytics Engine archive. New writes have stopped. That archive follows Cloudflare's three-month retention, may contain unredacted personal information, and is not automatically erased by the PostHog account-deletion flow.
-
-OpenAI, Clerk and other providers have their own retention and security policies. A change to Scout's analytics settings does not change those policies. Restrict analytics access to authorized personnel with a product evaluation/debugging need; Scout does not expose a public search-history endpoint. The processors above receive data: this is not a “no third party” service.
-
-## Data questions and deletion requests
-
-Contact [lazim@openmerit.ai](mailto:lazim@openmerit.ai) for data questions or to request access, correction or deletion. Include the account email and approximate dates, but do not send passwords, session tokens or sensitive prompt content. We may need to verify account ownership before acting. The rights and obligations that apply depend on your location and circumstances.
+- Your browser stores sign-in information, sharing preferences and temporary task drafts.
+- Task data and results may be stored temporarily even with analytics off: short-lived results for 30 seconds and completed-search processing data for seven days. Expiry is not a guarantee of immediate erasure.
+- Newly shared task content has a 30-day analytics retention window. Other analytics and account records may remain longer under provider settings. Backup erasure has not been independently verified.
+- Older task records may fall outside that 30-day policy. A discontinued archive follows a three-month retention period and is not automatically covered by account deletion.
+- We retain access and privacy-preference records as needed to operate the service and honor opt-outs and deletion requests.
 
-Deleting a Clerk account triggers a request to delete its linked PostHog profile and events. Deletion is asynchronous, and Scout repeats reconciliation to catch delayed deliveries; an accepted request is not proof that erasure has finished. Unlinked anonymous events and the historical Cloudflare archive are not automatically covered. Clearing a current profile field also does not remove it from older events. Contact us when a request needs review beyond the account-deletion flow.
+## Contact and deletion
 
-## Changes during beta
+For data access, correction or deletion, contact [lazim@openmerit.ai](mailto:lazim@openmerit.ai). We may verify account ownership. Do not send passwords or sensitive task content.
 
-We will update this page when data handling changes and identify the revision date. This notice does not itself override an existing opt-out or guarantee a fixed erasure deadline. Privacy settings remain available before and after submitting a task.
+Account deletion requests deletion of linked analytics. Erasure is asynchronous; unlinked activity and historical records may require separate review. Turning off sharing does not delete past data. Your rights depend on applicable law.