@open-everywhere/create 0.1.5 → 0.3.0

package/template/agent/sandbox/sandbox.ts

@@ -1,15 +1,18 @@
-import { defineSandbox } from "eve/sandbox";
-import { vercel } from "eve/sandbox/vercel";
-import { justbash } from "eve/sandbox/just-bash";
-import { docker } from "eve/sandbox/docker";
+import { defineSandbox, type RuntimeSandboxSession, type SandboxEnvironment, type SandboxSession } from "eve/sandbox";
+import { VercelSandbox } from "eve/sandbox/vercel";
+import { JustBashSandbox } from "eve/sandbox/just-bash";
+import { DockerSandbox } from "eve/sandbox/docker";
 import { bindFrom, type BindableContext } from "@open-everywhere/core/agent/identity/binding.js";
 import { resolvePartition } from "@open-everywhere/core/agent/memory/partition.js";
 import { sandboxPresetFor } from "@open-everywhere/core/agent/roles/role.js";
 import { getConfig } from "@open-everywhere/core/agent/access/config.js";
 import { onVercel } from "@open-everywhere/core/agent/access/platform.js";
-import { agentBrowserSandboxHooks } from "@open-everywhere/adapters/agent/browser/sandbox.js";
-import { recordCreatedSandbox } from "@open-everywhere/adapters/agent/sandbox/created-sandbox-registry.js";
+import { agentBrowserSandboxHooks, type BakeableSandbox } from "@open-everywhere/adapters/agent/browser/sandbox.js";
+import { registerSandboxFirewall } from "@open-everywhere/core/agent/sandbox/network-policy.js";
 import { resolveSelfHostBackendKind, selfHostBackendBootLog } from "./backend-select.js";
+// The KIND type has one home — core's adapter-api barrel — so the backend that runs and the backend
+// that stops cannot disagree about its spelling (see ./backend-select.ts's header).
+import type { SelfHostBackendKind } from "@open-everywhere/core/agent/adapter-api.js";
 import {
   resolveSandboxRegionPlan,
   vercelSandboxCreateOptions,
@@ -148,22 +151,67 @@ const VERCEL_CREATE_OPTIONS = vercelSandboxCreateOptions({
 // ── Agent-browser PRE-BAKE (the in-sandbox browser plane, OPE-43 — flag-gated) ──
 // When browser.enabled: true with at least one row in the host declaration
 // (agent/access/browser-hosts.ts, registered through lib/register-config.ts) (and only on the
-// Vercel backend), this contributes { revalidationKey, bootstrap } that bake the agent-browser
-// CLI + Chromium into the sandbox TEMPLATE — sessions boot warm, and nothing is ever fetched
-// mid-session (the runtime firewall wouldn't allow it; the vendor tools additionally run with
-// autoInstall bound off). Unarmed it is {} — the definition below carries NO bootstrap /
-// revalidationKey property at all, byte-identical to the pre-capability shape. Rationale +
-// fail-closed matrix live in the adapter (@open-everywhere/adapters/agent/browser/sandbox.js).
+// Vercel backend), this bakes the agent-browser CLI + Chromium into the sandbox TEMPLATE —
+// sessions boot warm, and nothing is ever fetched mid-session (the runtime firewall wouldn't allow
+// it; the vendor tools additionally run with autoInstall bound off). Unarmed it is {}, and the
+// environment below carries NO `prepare` at all. Rationale + fail-closed matrix live in the adapter
+// (@open-everywhere/adapters/agent/browser/sandbox.js).
 const AGENT_BROWSER_BAKE = agentBrowserSandboxHooks();
 
-function selfHostBackend() {
+// 🔴 eve 0.69.0 TOOK `revalidationKey` AWAY, AND THE TEMPLATE KEY IS NOW THE ENVIRONMENT'S OWN HASH
+// (OPE-2247). Through 0.68.x the bake contributed `{ revalidationKey, bootstrap }` to the sandbox
+// definition, and bumping the agent-browser pin changed that key, which rebuilt the template. 0.69.0
+// replaced both: setup is the environment's `prepare`, and a template is keyed by
+// `sha256(stableSerialize(environment options))` — which serialises a function by its SOURCE TEXT
+// (`shared/sandbox-environment.js`), not by the values it closes over. So ARMING or DISARMING the
+// bake rebuilds the template (the `prepare` key appears or disappears), and EDITING this file's
+// prepare body rebuilds it, but bumping the agent-browser version alone does NOT: the pin lives
+// inside the vendor installer, behind a closure, where the hash cannot see it. The consequence is a
+// stale warm template after a pin bump, not an unfenced session. Re-deriving a revalidation input the
+// hash can see belongs with the browser plane, not with this port — it is handed to the orchestrator
+// as a follow-up rather than guessed at here, because every field of these options is forwarded to
+// Vercel's own `Sandbox.create`, so inventing a carrier key is a change to the create call.
+const AGENT_BROWSER_PREPARE =
+  AGENT_BROWSER_BAKE.bootstrap === undefined
+    ? {}
+    : {
+        // `installAgentBrowser` reads only `run` off the session it is given, verified in the vendor
+        // bytes: `sandbox.id` appears once in `@agent-browser/eve/dist/sandbox/sandbox.js`, inside
+        // `runAgentBrowser` (the TOOL path), never on the install path. eve 0.69.0's `prepare` hands
+        // over a `SandboxSession`, which carries `run` and no `id` — and `BakeableSandbox.id` is
+        // optional for exactly that reason, so this is a widening to the adapter's own shape rather
+        // than a cast that hides a missing field.
+        prepare: async (sandbox: SandboxSession): Promise<void> => {
+          const bootstrap = AGENT_BROWSER_BAKE.bootstrap;
+          if (bootstrap === undefined) return;
+          await bootstrap({ use: async () => sandbox satisfies BakeableSandbox });
+        },
+      };
+
+// ── The three provider ENVIRONMENTS (eve 0.64.0 + 0.66.0 shape) ──
+// eve replaced the object-form `defineSandbox({ backend, … })` with environments a selector opens.
+// The environment is also the capability carrier: only a Vercel session takes a full
+// `SandboxNetworkPolicy`, Docker takes the coarse `"allow-all"` / `"deny-all"` alone, and just-bash
+// takes none because its policy is fixed at creation. Core's firewall sites reach whichever one is
+// live through `registerSandboxFirewall` below, because they cannot import this file.
+const VERCEL_ENVIRONMENT = VercelSandbox.environment({ ...VERCEL_CREATE_OPTIONS, ...AGENT_BROWSER_PREPARE });
+
+interface SelfHostSandbox {
+  readonly kind: SelfHostBackendKind;
+  /** The environment itself, for the named `environment` export eve's compiler requires. */
+  readonly environment: SandboxEnvironment<object | undefined, SandboxSession>;
+  /** Opening is a closure because each provider's open options differ, and the union of two
+   *  environments has no callable `open` signature. */
+  readonly open: () => Promise<RuntimeSandboxSession>;
+}
+
+function selfHostEnvironment(): SelfHostSandbox {
   // Fail-loud selection: unknown OE_SANDBOX_BACKEND throws here at boot (never a silent fallback).
   const kind = resolveSelfHostBackendKind();
   const bootLog = selfHostBackendBootLog(kind);
   if (bootLog.warn !== undefined) console.warn(bootLog.warn);
-  console.info(bootLog.info); // chosen backend, one info line either way (ids only)
-  // Surface the egress POSTURE at boot too (off-Vercel only): otherwise a "no proxy, no escape
-  // hatch" deployment looks healthy until the first wake, when every session silently aborts.
+  console.info(bootLog.info);
+  // ── EGRESS POSTURE (self-host only) ──
   const egressLog = selfHostEgressBootLog();
   if (egressLog.warn !== undefined) console.warn(egressLog.warn);
   console.info(egressLog.info);
@@ -176,67 +224,73 @@ function selfHostBackend() {
   // readable file (the compose stack mounts one; a bare self-host run does not), and the timer is
   // unref'd, so nothing about this can keep a process alive or take one down.
   startEgressDenialPoller();
-  if (kind === "justbash") return justbash();
+  if (kind === "justbash") {
+    const environment = JustBashSandbox.environment({});
+    registerSandboxFirewall({ carries: "none", backend: "justbash" });
+    return { kind, environment, open: async () => await environment.open() };
+  }
   const image = getSettings().sandbox.image;
-  return docker(image ? { image } : {});
+  const environment = image ? DockerSandbox.environment({ image }) : DockerSandbox.environment({});
+  registerSandboxFirewall({ carries: "coarse", environment });
+  return { kind, environment, open: async () => await environment.open() };
 }
 
-export default defineSandbox({
-  backend: ON_VERCEL ? vercel(VERCEL_CREATE_OPTIONS) : selfHostBackend(),
-  ...AGENT_BROWSER_BAKE,
+// Resolved at module load, exactly as the backend ternary was: one boot decision, one set of logs,
+// and the registration core's firewall sites read must be in place before the first turn.
+const SELF_HOST = ON_VERCEL ? undefined : selfHostEnvironment();
+if (ON_VERCEL) registerSandboxFirewall({ carries: "full", environment: VERCEL_ENVIRONMENT });
+
+/**
+ * The environment eve's COMPILER reads, and it must be exactly one (`compiler/normalize-sandbox.js`:
+ * "Sandbox must export an environment"). eve records its `provider` name and this export's name in
+ * the compiled binding, so the built app is specialised to the backend resolved HERE, at module load —
+ * which is what the old `backend:` ternary already did, so nothing about that is new. The selector
+ * below opens the same environment; this export is how the build learns which provider that is.
+ */
+export const environment: SandboxEnvironment<object | undefined, SandboxSession> =
+  SELF_HOST === undefined ? (VERCEL_ENVIRONMENT as SandboxEnvironment<object | undefined, SandboxSession>) : SELF_HOST.environment;
+
+export default defineSandbox(async (context) => {
   // ── Per-domain/role sandbox SIZING (item 26 stretch) ──
   // A domain (or the role preset it adopts) may declare `sandbox: { vcpus: N }`
-  // (core memory/domain.ts SandboxPreset); this hook applies it to the live session —
-  // eve forwards `use({ resources })` to the Vercel SDK's Sandbox.update, so the size
-  // change lands on the session VM. FAIL-OPEN end to end (sizing is a tuning knob, the
-  // turn must never die for it): identity/config resolution errors → default size; an
-  // update rejection retries a bare use(). NB Sandbox.update applies `resources` on the
-  // session, so a preset takes effect per-session (stop-after-turn recycles sessions
-  // every turn, so in practice the next turn after a config change).
-  onSession: async ({ ctx, use }) => {
-    // Per-session vcpu sizing is a Vercel-only knob (it forwards to Sandbox.update).
-    // justbash()/docker() don't honor `resources` — open straight through.
-    if (!ON_VERCEL) {
-      await use();
-      return;
-    }
-    // With the backend now a union (vercel | justbash | docker), `use`'s param type
-    // narrows to the intersection (no `resources`); but this branch only runs on Vercel,
-    // whose backend DOES accept `{ resources }`. Type the sized open explicitly. The resolved
-    // session's `.id` is eve's own session key — see created-sandbox-registry.ts for why that is
-    // the same value the Vercel binding names the sandbox with.
-    const useSized = use as unknown as (options?: { resources: { vcpus: number } }) => Promise<{ id: string }>;
-    let options: { resources: { vcpus: number } } | undefined;
-    try {
-      // SessionContext structurally satisfies BindableContext (session.auth carries the
-      // platform attributes); a ctx with no resolvable identity falls through the
-      // binding bridge or resolves no domain — either way: no preset, default size.
-      const bindable = ctx as BindableContext;
-      const preset = sandboxPresetFor(bindFrom(bindable), resolvePartition(bindable), getConfig().loadDomains());
-      const vcpus = preset?.vcpus;
-      if (typeof vcpus === "number" && Number.isFinite(vcpus) && vcpus > 0) {
-        options = { resources: { vcpus: Math.floor(vcpus) } };
-      }
-    } catch (err) {
-      console.warn(`[open-everywhere:sandbox] vcpus preset resolution failed — using default size (${String(err)})`);
-    }
-    // OPE-722: record the ACTUAL vendor sandbox name eve just opened for this session, so the
-    // turn-end stop hook (backend-stop.ts) can find it directly instead of depending on
-    // Sandbox.list's tag index for a sandbox THIS turn just created — a hardening against the
-    // same-turn creation race OPE-722 reported, regardless of whether the vendor's tag index is
-    // ever actually stale (see backend-stop.ts's createVercelList doc comment for the full
-    // account). `recordCreatedSandbox` is documented to never throw, so no extra try/catch layer
-    // is needed here — it fails as loud as `recordCreatedSandbox`'s own contract allows.
-    const record = (session: { id: string }): void => recordCreatedSandbox(ctx.session.id, session.id);
-    try {
-      record(await useSized(options));
-    } catch (err) {
-      // The sized open failed (e.g. the update was rejected for this plan/region):
-      // fall back to the default size rather than blocking the turn. A bare use()
-      // failure is a real sandbox outage — let that one propagate.
-      if (options === undefined) throw err;
-      console.warn(`[open-everywhere:sandbox] applying vcpus=${options.resources.vcpus} failed — retrying default size (${String(err)})`);
-      record(await useSized());
+  // (core memory/domain.ts SandboxPreset); this selector applies it when it opens the session —
+  // eve forwards `resources` to the Vercel SDK's create/update, so the size change lands on the
+  // session VM. FAIL-OPEN end to end (sizing is a tuning knob, the turn must never die for it):
+  // identity/config resolution errors → default size; a rejected sized open retries unsized.
+  // Per-session vcpu sizing is a Vercel-only knob, so every other backend opens straight through.
+  if (SELF_HOST !== undefined) return await SELF_HOST.open();
+  let options: { resources: { vcpus: number } } | undefined;
+  try {
+    // SandboxSelectorContext structurally satisfies BindableContext (session.auth carries the
+    // platform attributes); a context with no resolvable identity falls through the binding bridge
+    // or resolves no domain — either way: no preset, default size.
+    const bindable = context as unknown as BindableContext;
+    const preset = sandboxPresetFor(bindFrom(bindable), resolvePartition(bindable), getConfig().loadDomains());
+    const vcpus = preset?.vcpus;
+    if (typeof vcpus === "number" && Number.isFinite(vcpus) && vcpus > 0) {
+      options = { resources: { vcpus: Math.floor(vcpus) } };
     }
-  },
+  } catch (err) {
+    console.warn(`[open-everywhere:sandbox] vcpus preset resolution failed — using default size (${String(err)})`);
+  }
+  // 🔴 OPE-722's CREATED-SANDBOX RECORD IS GONE, BECAUSE eve 0.69.0 NO LONGER EXPOSES THE NAME
+  // (OPE-2247). The old `onSession` hook's `use()` resolved to an object carrying `.id` — the vendor
+  // sandbox name — and this file recorded it so the turn-end stop hook could reach the sandbox with a
+  // primary-key `Sandbox.get` rather than `Sandbox.list`'s tag index. On 0.69.0 neither
+  // `SandboxSession` nor `RuntimeSandboxSession` carries an `id`, so there is nothing to record and no
+  // authored surface that can learn it. The stop hook degrades to exactly the pre-OPE-722 path:
+  // `created-sandbox-registry.ts` documents an absent record as "falls back to the vendor's tag
+  // index, exactly as before this fix", so stop-after-turn still works and the narrow create-then-stop
+  // race OPE-722 hardened against is open again. Re-deriving a name the hook can use is handed to the
+  // orchestrator as a follow-up; it is not guessable from these bytes.
+  if (options === undefined) return await VERCEL_ENVIRONMENT.open();
+  try {
+    return await VERCEL_ENVIRONMENT.open(options);
+  } catch (err) {
+    // The sized open failed (e.g. the size was rejected for this plan/region): fall back to the
+    // default size rather than blocking the turn. A bare open() failure is a real sandbox outage —
+    // that one propagates, from the call below.
+    console.warn(`[open-everywhere:sandbox] applying vcpus=${options.resources.vcpus} failed — retrying default size (${String(err)})`);
+    return await VERCEL_ENVIRONMENT.open();
+  }
 });

package/template/agent/spend/checkpoints.ts

@@ -8,8 +8,10 @@
 // scope is over its monthly total. A checkpoint is softer and per-session — when a single
 // conversation gets expensive it PAUSES only CONSEQUENTIAL actions (PRs, memory writes, skill/
 // routine creation, …) and posts a "keep going?" card. Reads and replies are never blocked, and a
-// member's approval lets the agent resume for the rest of that session. It's a runaway-session
-// circuit-breaker, not a spend ceiling.
+// member's approval lets the agent resume. On a live session the approval lasts until the window
+// rotates or `approvals.checkpointTtlHours` (default 24 h) lapses, whichever comes first. On a
+// durable job's session it does not lapse: the agent asks again once it has spent that much again.
+// It's a runaway-session circuit-breaker, not a spend ceiling.
 //
 // EMPTY BY DEFAULT — with nothing declared here, nothing is checkpointed (Open Everywhere never
 // invents a threshold). This file is the seam a DB/dashboard would swap behind, same as

package/template/claude/skills/quickstart-open-everywhere/SKILL.md

@@ -22,9 +22,13 @@ that repository ships no `env:pipe` script. Everything else is the same.
 - The ops MCP tools check and scaffold. **You** run install, build and deploy commands in the
   user's shell: show the command, get a yes, then run it. Never run a deploy, create a cloud
   resource, or write a secret without explicit confirmation.
-- **Never ask the user to paste a secret into the chat, and never echo or commit one.** They paste
-  it where a tool reads it; you write it to the gitignored `.env.local` with `scaffold_env`, then
-  forget it. Mint the credential-store key with `scaffold_credential_key`, which never prints it.
+- **Never ask the user to paste a secret into the chat, never pass one to a tool, and never echo or
+  commit one.** A tool call is part of your transcript. The user types each secret into their OWN
+  terminal with `npx oe env set <NAME>`: it reads the value from a hidden prompt and writes it to the
+  gitignored `.env.local`. You only ever handle the NAME: `scaffold_env { secretNames: [...] }`
+  returns the command per name and whether the file holds a value yet. `scaffold_env { values }`
+  takes non-secret config only, and its schema refuses a secret name. Mint the credential-store key
+  with `scaffold_credential_key`, which never prints it.
 - **Never propose a local run as a setup step.** `npm run dev` is the development loop AFTER the
   deploy. A local run has no public HTTPS URL for Slack to reach and keeps its state in a different
   store, so it proves little about the deployment. See "Develop locally" below.
@@ -32,9 +36,17 @@ that repository ships no `env:pipe` script. Everything else is the same.
   `OE_CREDENTIAL_ENCRYPTION_KEY`, `SLACK_BOT_TOKEN`, `SLACK_SIGNING_SECRET` and
   `GITHUB_WEBHOOK_SECRET` from its **environment**: the Slack bundle and the GitHub webhook check
   never read the credential store. So these go in `.env.local`, and then into the deployment's own
-  environment. `secret_set` is for a credential whose `broker` is `"db"` (and
-  `NOTION_WEBHOOK_SECRET`). It needs `DATABASE_URL` and the key in `.env.local` first. Nothing
-  reads a stored secret back out (`secret_list` returns names only).
+  environment. `secret_set { names: [...] }` is for a credential whose `broker` is `"db"` (and
+  `NOTION_WEBHOOK_SECRET`): it moves each named value from `.env.local` into the store, so the user
+  runs `npx oe env set <NAME>` first. It needs `DATABASE_URL` and the key in `.env.local` too.
+  Nothing reads a stored secret back out (`secret_list` returns names only).
+- **If an ops tool answers "the app now runs @open-everywhere/core X; this ops server runs Y"**, the
+  server predates an upgrade. Ask the user to restart it (`/mcp`, then reconnect
+  `open-everywhere-ops`) and call again. Never work around it: a stale server serves old code. A
+  server whose core predates this check cannot refuse: after an upgrade, an input-validation error
+  that names `values` or `secrets`, a `scaffold_env` reply with no `secrets` list for the
+  `secretNames` you sent, or "Tool … not found", means the same thing. Restart it. Never fall back
+  to passing a value.
 - Every command runs from the app root.
 
 ## Step 1 — ask which route
@@ -53,11 +65,26 @@ that repository ships no `env:pipe` script. Everything else is the same.
 Nothing beyond these two is supported. For any other host, read the contract and follow the Docker
 route; do not invent a recipe.
 
+## Tell the user about telemetry, before the first deploy
+
+**The deployed app sends anonymous usage telemetry, and it is ON by default.** Tell the user that
+before the first deploy, and ask whether they want it. Do not decide for them. It sends event names,
+enums, coarse buckets, public model ids and the app version, with a random per-install id
+(`service.instance.id`). It never sends message or memory content, org names, workspace, channel,
+user or session ids, or env values. The full list
+of events is `https://github.com/open-everywhere/open-everywhere/blob/main/docs/deploy/telemetry.md`.
+
+To turn it off, `OE_TELEMETRY=off` (or `DO_NOT_TRACK=1`) must be set on the DEPLOYMENT: a value in
+`.env.local` reaches only a local run. On the Vercel route, at step 9:
+`printf off | npx vercel env add OE_TELEMETRY production`. On the Docker route, put it in the
+container's environment. Every boot prints a line that says whether telemetry is on.
+
 ## Status, at every step
 
 - `npx @open-everywhere/create --check --json` — the step list as data: `satisfied`, `detail`, and a
   `next` command per unsatisfied step. It changes nothing. Pass `--route docker` on the Docker
-  route, and `--host https://<host>` once a deployment exists. In a clone of the repository, run
+  route, and `--host https://<host>` once a deployment exists: the env step then also reads the
+  deployment's own verdicts from its public status route. In a clone of the repository, run
   `node packages/create/bin/create-open-everywhere.js --check --json` instead.
 - The `preflight` tool — the env verdict per name. Pass `target: "vercel"` or `target: "docker"`.
 
@@ -74,18 +101,21 @@ tool. The same step list, written for a human, is
 3. **Database.** `npx vercel install neon` provisions a Neon database and connects it to the linked
    project, which sets `DATABASE_URL` there. (`vercel install` is an alias of
    `vercel integration add`; the Marketplace slug is `neon`.) The dashboard path — project →
-   **Storage → Neon → Connect** — does the same thing. Then get the same value into `.env.local`
+   **Storage → Neon → Connect** — does the same thing. The integration can also enable **Neon
+   Auth** (`NEON_AUTH_BASE_URL`, `VITE_NEON_AUTH_URL`). Open Everywhere does not use it: leave it
+   off, or ignore those two variables. Then get the same value into `.env.local`
    for the operator tools, either with `npx vercel env pull` (it writes the project's environment
    into `.env.local`, overwriting it, so pull before you add anything local) or by asking the user
-   for the connection string and writing it with `scaffold_env`. **That one value is the whole
+   to run `npx oe env set DATABASE_URL` and paste the connection string at its prompt. **That one value is the whole
    step:** it resolves both the operational store and the memory backing to postgres on its own, so
    set no provider selector. A selector pointing AWAY from postgres is the only thing that breaks
    it.
 4. **Key.** `scaffold_credential_key`.
 5. **Slack app.** Call `surface_manifest { surface: "slack" }` and hand the user the manifest and
    the steps it returns. Before the first deploy the manifest keeps `YOUR-DEPLOY-URL`. The user
-   creates and installs the app, then pastes `SLACK_BOT_TOKEN` and `SLACK_SIGNING_SECRET`: write
-   both with `scaffold_env`.
+   creates and installs the app, then runs `npx oe env set SLACK_BOT_TOKEN` and
+   `npx oe env set SLACK_SIGNING_SECRET` in their own terminal. Confirm with
+   `scaffold_env { secretNames: ["SLACK_BOT_TOKEN", "SLACK_SIGNING_SECRET"] }`: both read `present: true`.
 6. **Vouch the workspace.** Ask for the team id (`T…`: the segment after `/client/` in the
    workspace URL at app.slack.com). In `agent/identity/surfaces.ts` add
    `defineSurface({ key: "slack/<team-id>", trust: "internal" })`.
@@ -96,7 +126,8 @@ tool. The same step list, written for a human, is
 9. **Deployment env.** `.env.local` never ships, so the deployment reads only what you set ON it.
    The names are `OE_CREDENTIAL_ENCRYPTION_KEY`, `SLACK_BOT_TOKEN` and `SLACK_SIGNING_SECRET`. The
    Neon integration already set `DATABASE_URL` there, and that one value resolves both stores — so
-   there is no `OE_OPERATIONAL_PROVIDER` or `OE_MEMORY_PROVIDER` to push.
+   there is no `OE_OPERATIONAL_PROVIDER` or `OE_MEMORY_PROVIDER` to push. Add `OE_TELEMETRY` (value
+   `off`) only when the user chose to turn telemetry off (see the telemetry section above).
    Confirm each command first, and **never let a value reach your own output.**
    - **In a scaffolded app:** `npm run -s env:pipe -- <NAME> | npx vercel env add <NAME> production`.
      Always pipe `env:pipe` straight into `vercel env add`, as written. Never run it bare: your
@@ -127,11 +158,12 @@ public HTTPS URL, Postgres, a sandbox backend, egress control, a model route, an
 Then:
 
 1. **Install and build.** `npm install`, then `npm run build`.
-2. **Postgres.** Provision one the container can reach, and `scaffold_env` its `DATABASE_URL`. That
-   one value resolves both stores to postgres; set no provider selector.
+2. **Postgres.** Provision one the container can reach. The user runs `npx oe env set DATABASE_URL`
+   and pastes its connection string at the prompt. That one value resolves both stores to postgres;
+   set no provider selector.
 3. **Key.** `scaffold_credential_key`.
 4. **Model route.** There is no OIDC off Vercel, so the user supplies `AI_GATEWAY_API_KEY` (Vercel
-   → AI Gateway → API Keys issues one for any host). Running a different model backend instead is
+   → AI Gateway → API Keys issues one for any host) with `npx oe env set AI_GATEWAY_API_KEY`. Running a different model backend instead is
    an **adapter swap in app code**
    (`https://github.com/open-everywhere/open-everywhere/blob/main/docs/extending/adapter-model.md`),
    which `--check` cannot see: that step stays `missing` on the Docker route either way, so read it
@@ -147,9 +179,9 @@ Then:
 
 ## Develop locally
 
-Only when the user asks to change or debug the agent — never as a setup step. Write
-`AI_GATEWAY_API_KEY` with `scaffold_env` (the user creates it: Vercel → AI Gateway → API Keys),
-then `npm run dev`. A local run keeps its state in an embedded database under
+Only when the user asks to change or debug the agent — never as a setup step. The user creates
+`AI_GATEWAY_API_KEY` (Vercel → AI Gateway → API Keys) and writes it with
+`npx oe env set AI_GATEWAY_API_KEY`, then `npm run dev`. A local run keeps its state in an embedded database under
 `.open-everywhere-data/`, and Slack cannot reach it without a public tunnel.
 
 ## Notes
@@ -161,7 +193,12 @@ then `npm run dev`. A local run keeps its state in an embedded database under
 - The deployment's own identity (`deploymentIdentity`) is code in `agent/identity/surfaces.ts`, not
   env.
 - `@open-everywhere/create` has no interactive wizard and sends no telemetry. It scaffolds
-  (`npx @open-everywhere/create <dir>`) and reports status (`--check`). Nothing else.
-- 🔴 **`--check` reads `.env.local` and your shell, never the deployment's own environment.** A
-  "9/9 satisfied" is not proof that the deployment holds the credential key or the Slack secrets:
-  step 9 is the only thing that puts them there, and nothing can observe it from here.
+  (`npx @open-everywhere/create <dir>`) and reports status (`--check`). Nothing else. The deployed
+  app is a different matter: its telemetry is on by default (see the telemetry section above).
+- 🔴 **Without `--host`, `--check` reads `.env.local` and your shell, never the deployment's own
+  environment.** With `--host`, the env step also reads the deployment's status route, which reports
+  `DATABASE_URL` and the credential key (its `secrets` row), the store selection and the model route.
+  The env step does not judge the Slack secrets, so even a "9/9 satisfied" is not proof that the
+  deployment holds `SLACK_BOT_TOKEN` and `SLACK_SIGNING_SECRET`. The same status document's
+  `surfaces.slack.credentials` reports whether both are present: read it with
+  `curl -s https://<host>/eve/v1/oe/status`. Slack's **Verified** is what proves the signing secret.

package/template/claude/skills/upgrade-open-everywhere/SKILL.md

@@ -66,15 +66,31 @@ Those are decisions, not steps.
 
 `--plan` also prints a **template drift** report. It compares every file the scaffold copied into
 this app with the TARGET release's `@open-everywhere/create` template, and lists each one that
-differs, with a one-line size of its diff. An upgrade changes only `package.json`, so a scaffolded
+differs, with a one-line size of its diff. An upgrade changes only `package.json` and
+`package-lock.json`, so a scaffolded
 file stays as the old template wrote it. A stale copy can typecheck and build and still break the
 deployment: the 0.1.2 `agent/lib/register-adapters.ts` registers no Postgres client on a bare
 `DATABASE_URL`, so a Vercel+Neon deployment of 0.1.4 fails at its first write.
 
+`agent/lib/register-adapters.ts` is the exception once it is current. The current template's copy
+is ONE call, `registerDefaultAdapters()` from `@open-everywhere/adapters`, plus a `customAdapters`
+hook. The adapter wiring, the store selection rules and the floors live in that package, so the
+package upgrade carries them, and the file needs no hand-merge. Sync it ONCE, from a copy that wires
+the adapters by hand to the one-call copy: move any adapter the user registered by hand into the
+`customAdapters` hook. After that, a SYNC line for this file is a comment or hook difference only.
+
 | Line | What to do |
 | --- | --- |
 | SYNC | a template-owned file — wiring, a script, `AGENTS.md`, `README.md`, `.env.example`, a skill. Plan to copy the target's file over this one, after you read the diff. |
 | config | the app's own config-as-code. A difference is normal once the app is configured. Merge the template's change by hand only if the user wants it. |
+| DELETE | a release up to the target removed this file from the template, and the app still has it. Plan to delete it. eve 0.69 and later refuse `agent/instrumentation.ts` at build. |
+| app-owned | `.oe-template-ignore` names the file, so the app owns it. Nothing to do. |
+
+`.oe-template-ignore` at the app root lists the template files the app removed or owns on purpose:
+one app-relative path per line, a trailing `/` for a directory, `#` for a comment. The report prints
+nothing for an ignored file the app does not have, and one `app-owned` line for one it has. Add a
+path only when the user says the app owns that file. Never add one to silence a SYNC line you have
+not read.
 
 The report never writes a file. If it says the drift check did not run, compare the files with the
 target's template by hand. An installed core without the report prints none: `oe upgrade` runs the
@@ -92,7 +108,11 @@ In order, and it stops at the first step that fails:
 1. bump every `@open-everywhere/*` package to the target, renaming a dependency on the retired
    unscoped `create-open-everywhere` to `@open-everywhere/create` as it goes;
 2. pin `eve` to the version the target core declares as its peer;
-3. `npm install` — its `postinstall` runs `oe-eve-patch`, which the app refuses to boot without;
+3. `npm install` — its `postinstall` runs `oe-eve-patch`, which the app refuses to boot without.
+   Before it, the run drops the `package-lock.json` entries of `eve`, of every
+   `@open-everywhere/*` package and of every package that peers on one of them, so npm resolves
+   that set again. If the install still stops with ERESOLVE (a core at 0.2.1 or earlier does not
+   drop them), run `rm package-lock.json && npm install`, then run `oe upgrade` again;
 4. run the config codemods the target's notes name, and print the migrations that are yours;
 5. `oe build --accept` — this rewrites `roster.lock.json`;
 6. `npm run typecheck`;
@@ -129,7 +149,7 @@ codemod. Do not delete the marker to get past this refusal.
 
 ```
 git diff roster.lock.json
-git diff package.json
+git diff package.json package-lock.json
 git status
 ```
 
@@ -142,9 +162,13 @@ Then run the app's own checks once more if anything above was fixed by hand:
 
 Then act on the template drift report. A core that carries it prints it again after the install;
 if this run printed no "Template drift" heading, run `npx oe upgrade --to <target> --plan` now to get it. For
-each SYNC line, read the diff against the installed template, for example
+each DELETE line, delete the file. If the user says the app owns it, keep it and name it in
+`.oe-template-ignore`. For each SYNC line, read the diff against the installed template, for example
 `diff node_modules/@open-everywhere/create/template/agent/lib/register-adapters.ts agent/lib/register-adapters.ts`.
-Keep any edit the user made on purpose, and copy the template's file otherwise. A file under the
+Keep any edit the user made on purpose, and copy the template's file otherwise. For
+`agent/lib/register-adapters.ts`, the user's edits belong in the `customAdapters` hook of the
+template's one-call copy, never in a hand-wired copy: a hand-wired copy does not get the product's
+wiring changes on the next upgrade. A file under the
 template's `claude/` directory lands in the app's `.claude/`, and the template's `gitignore` is the
 app's `.gitignore`. Name every synced file in the pull request.
 
@@ -161,7 +185,7 @@ Commit on a branch, never on the default branch. The body carries:
 - what changed in `roster.lock.json`, in your own words;
 - **the env names the deployment needs before this merges**, names only;
 - the manual steps, and who does each one.
-- the template files you synced, and each SYNC line you left as it is, with the reason.
+- the template files you synced or deleted, and each SYNC or DELETE line you left as it is, with the reason.
 
 Then stop. The admin reviews the lock diff and merges. The merge deploys.
 
@@ -169,21 +193,23 @@ Then stop. The admin reviews the lock diff and merges. The merge deploys.
 
 A green build is not a working deployment.
 
-**The status endpoint is not built yet.** OPE-2230 adds one: an unauthenticated, non-sensitive
-JSON route that reports the deployment's version, whether the database is reachable and which
-provider it uses, the sandbox backend, whether egress is enforced, whether the model route
-answers, and the Slack posture. That ticket proposes `GET /eve/v1/oe/status`. Do not assume the
-route exists, and never read some other route as if it were this one. Check the deployment's own
-routes first; when the endpoint is there, read it and report each field, in this order:
+**Read the status route, `GET /eve/v1/oe/status`.** It ships from core 0.1.4. It is an
+unauthenticated, non-sensitive JSON route that reports the deployment's version, whether the
+database is reachable, the sandbox backend, whether egress is enforced, whether the model route
+answers, and the Slack posture. A deployment can hide it on purpose, with a roster exclusion or an
+edge rule (`docs/deploy/contract.md` § Hiding the status route). A 404 or a 403 there can be that
+choice, not a fault: ask the operator before you call it broken. Never read some other route as if
+it were this one. When the route answers, report each field, in this order:
 
 1. **version** — it reads the target. If it still reads the old version, the deploy has not
    finished, or it failed. Nothing below is meaningful until this matches.
-2. **database reachable**, and the provider it names.
+2. **database reachable** (the `postgres` verdict).
 3. **sandbox backend**, and **egress enforced**.
 4. **model route answers.**
 5. **Slack** — credentials present, workspace installed, events verified.
 
-**Until that endpoint ships**, confirm what you can and say plainly what you could not:
+**When the route does not answer**, on a core older than 0.1.4 or on a deployment that hides it,
+confirm what you can and say plainly what you could not:
 
 - the deploy finished, from the host's own deployment log;
 - `npx @open-everywhere/create --check --json --host https://<host>` — its `build-deploy` step

package/template/package.json

@@ -31,7 +31,7 @@
     "@open-everywhere/provider-notion": "{{OE_VERSION}}",
     "@open-everywhere/provider-slack": "{{OE_VERSION}}",
     "@open-everywhere/provider-teams": "{{OE_VERSION}}",
-    "eve": "0.54.3",
+    "eve": "0.71.0",
     "just-bash": "^3.1.0"
   },
   "devDependencies": {

package/template/roster.lock.json

@@ -39,6 +39,7 @@
         "hook/eve-patch-gate": "mounted",
         "hook/fire-carriage": "mounted",
         "hook/fire-toolset": "mounted",
+        "hook/held-question": "mounted",
         "hook/job-posture": "mounted",
         "hook/lean-seat": "mounted",
         "hook/learn": "mounted",
@@ -69,10 +70,13 @@
         "tool/add_label": "mounted",
         "tool/add_routine_rule": "mounted",
         "tool/agent_version": "mounted",
+        "tool/ask_question": "mounted",
+        "tool/ask_room": "mounted",
         "tool/assign": "mounted",
         "tool/aws": "mounted",
         "tool/browser_tools": "mounted",
         "tool/cancel_routine": "mounted",
+        "tool/cancel_work": "mounted",
         "tool/capture_events": "mounted",
         "tool/check_pr_status": "mounted",
         "tool/checkout_repo": "mounted",
@@ -118,6 +122,7 @@
         "tool/read_channel": "mounted",
         "tool/read_docs": "mounted",
         "tool/read_file_upload": "mounted",
+        "tool/read_github_issue": "mounted",
         "tool/read_routine_transcript": "mounted",
         "tool/read_thread": "mounted",
         "tool/read_thread_seat": "mounted",
@@ -151,7 +156,8 @@
         "tool/unlink_identity": "mounted",
         "tool/update_status": "mounted",
         "tool/usage_report": "mounted",
-        "tool/walk_pr": "mounted"
+        "tool/walk_pr": "mounted",
+        "tool/work": "mounted"
       }
     },
     "@open-everywhere/provider-github": {