[lavaman131]

Upgrade Atomic to the stable 0.9.81 release

This moves the Atomic harness from 0.9.80 to the stable 0.9.81 release. It follows the same steps as the 0.9.80 upgrade.

Versions

• catalog:harness pins @bastani/atomic 0.9.81.
• bun.lock resolves @bastani/atomic, @bastani/atomic-natives and all eight of its platform packages, and @bastani/pi-ai at 0.9.81. No older @bastani package is left.
• The @earendil-works/pi-* packages stay at 1.5.2, which Atomic still pins.
• @bastani/pi-ai 0.9.81 takes @google/genai 2.32.0. @earendil-works/pi-ai 1.5.2 still pins 2.21.0 exactly, so the lockfile keeps that copy nested under it.
• I deleted the lockfile and ran bun install to re-resolve it. This moved the rest of Atomic's tree to the newest version its ranges allow: ws 8.23.0, encodeurl 2.0.3, graceful-fs 4.2.12 and @hono/node-server 2.1.8.
• Outside Atomic's tree the same run moved baseline-browser-mapping to 2.11.37, electron-to-chromium to 1.5.485 and enhanced-resolve to 5.27.0.
• @modelcontextprotocol/ext-apps and get-intrinsic stay on the version their latest tag names.
• The self-hosting guide now says 0.9.81.

What changed in 0.9.81, and whether Chopin depends on it

I compared the published 0.9.80 and 0.9.81 packages of @bastani/atomic and @bastani/pi-ai file by file and checked each behaviour change against Chopin's code and tests. None needed a code change.

• Strict tool schemas. The new fallback to non-strict mode applies only to tools that set constrainedSampling: { strict: "prefer" }. Chopin's host tools and its structured result tool (apps/server/src/harness/atomic/adapter.ts) don't set constrainedSampling, so the fallback never applies to them. One change does affect Chopin's tools: a non-strict Anthropic request now keeps a schema's root additionalProperties instead of dropping it. The result tool's additionalProperties: true and the host tools' additionalProperties: false are both valid there.
• bash long-line output. No Chopin code reads the bash tool's truncation footer.
• pi.exec exit codes. Chopin never calls pi.exec.
• Google adapters and @google/genai 2.32.0. Chopin doesn't configure a Google provider or a custom fetch.
• "Connection closed." retries. The new pattern (/connection.?closed/i) is in Atomic's model-fallback failure list. No Chopin code or test matches a provider's "Connection closed." error. The remote link's "The agent connection closed." is Chopin's own error, and it never passes through Atomic as a provider error. The harness tests drive Atomic through a stub OpenAI-compatible server that never closes a connection mid-turn.
• model: "auto" routing, parallelSlot, the footer, queued-message rows, /resume and find globs. These live in Atomic's router, its workflows and its terminal interface. Chopin's Planner doesn't use any of them, and the export list gains only the ParallelSlot type. Chopin's own steering calls AgentSession.steer, which didn't change between the two releases.

Checks

• bun install --frozen-lockfile: passed.
• bun run types and bun run ci: passed.
• GIT_CONFIG_GLOBAL=/dev/null bun test apps/server/src/harness: 596 passed, 0 failed.
• GIT_CONFIG_GLOBAL=/dev/null bun test apps/server/src/conversation-plan (this code imports ModelRegistry from Atomic): 1059 passed, 0 failed, 1 skipped.
• bun run e2e --project=harness --workers=2: 78 passed.
• bun run e2e --project=chromium --workers=2 e2e/planner-picker.e2e.ts e2e/planner-attachment.e2e.ts: 62 passed, 1 failed. See the note below.
• bun run build:
  • Initial JavaScript is 259,958 B raw and 82,471 B gzip, against a budget of 260,500 B and 83,450 B.
  • The initial stylesheet is 184,420 B raw and 32,675 B gzip, against a budget of 185,000 B and 33,000 B.

The one failure was already failing on main

e2e/planner-picker.e2e.ts:2388 ("with no machine of their own, a person still opens the Machines menu to a teammate's shared machine…") fails on this branch. It also fails on origin/main eec9491c3, which still has Atomic 0.9.80.

• I checked origin/main in a separate worktree with a fresh build, and the spec failed 2 of 2 runs (--repeat-each=2).
• On this branch it failed 3 of 3 runs, in the same assertions on the "Runs on" menu's machine rows.
• The spec runs against the AGENT=off server and doesn't touch Atomic.

I left it alone because fixing it is outside this upgrade.

Judgement calls

• I re-resolved the whole lockfile rather than only Atomic's entries, as the 0.9.79 and 0.9.80 upgrades did. That brings in three in-range patches outside Atomic's tree, all build-tooling data or resolvers.
• I kept the nested @google/genai 2.21.0 that @earendil-works/pi-ai pins exactly. Overriding it would break that package's exact pin.