ACC v0.10.2

ACC v0.10.2 release evidence

A native binding whose pid another program now has no longer holds a store-contract update, and
a pending release that cannot activate gives way to a newer one.

Exact artifact

• Source: clean commit fb1222a1411cabf9ea539ce56008a479182778f8, the version sweep on the
  merge of #278.
• Archive: agents-can-communicate-0.10.2.tgz, packed from that commit.
• Size: 580,985 bytes; 351 packed entries.
• SHA-256: 6e3d63508379246a971947ccd66c5e544e8a53932f4f95e9f179e85b40fa4ceb.
• The root and fifteen bundled workspaces are at 0.10.2. The Antigravity plugin manifest, the
  Gemini extension manifest and the lockfile carry the same version sweep as 0.10.1, over the
  same nineteen files. docs/UPGRADING.md already describes 0.10.2, from #278.

scripts/verify-package.mjs passed on that exact file: 351 entries, none forbidden; six
certification manifests with the exact evidence allowlist; every packed Markdown link resolves;
the root and fifteen bundled workspaces at 0.10.2; acc, acc-hook and acc-mcp present;
doctor reports six adapters; nothing written into a project without Git; client install and
uninstall restore topology, modes, links and bytes, and a repeated uninstall is a no-op.

All 27 packed checks passed against real installed archives: the 24 managed-update checks and
the 3 store-migration checks.

What changed since 0.10.1

One merged pull request changed the package; its development record is below this section of
the CHANGELOG:

• #278 (#276, #277). A binding whose live pid belongs to a process that started more than a
  second after the binding was last written is no hold (ps -o lstart= with LC_ALL=C, or WMI
  on Windows; an unreadable start time decides nothing), and the pending generation's refresh
  removes it. When the pending release reports processes_active, acc update, and the
  automatic update once a check is due, stage a newer release in its place; with nothing newer,
  the result still reports processes_active.

Upgrade from the published 0.9.1

The published agents-can-communicate@0.9.1 was installed from npm into an isolated prefix,
with its own HOME, ACC_DATA_HOME and project, a PATH of the prefix, client stubs, node and
system directories, and a local registry that served this exact archive:

• A live 0.9.1 process. 0.9.1's own acc-mcp held contract 6, and acc update waited for
  it. After it exited, the next acc status activated 0.10.2. The store was on contract 7 within
  0.8 seconds, with event, journal, message and receipt bytes unchanged, and 0.10.2 answered the
  open question on it. The installed generation matched the archive file for file, and the Codex
  config.toml was unchanged. 0.9.1 code refused the migrated store with exit 4.
• Stale bindings. Two bindings without a pid for sessions with no record: the 0.9.1 updater
  activated 0.10.2 after its refresh removed them, and the store moved to contract 7. With a
  third binding for a session that still heartbeats, that one stayed and kept 0.10.2 pending.
• A reused pid. A binding written two days earlier, whose pid now belonged to a sleep
  started at the time of the run: the 0.9.1 updater activated 0.10.2, the binding was removed,
  and the store moved to contract 7.
• A stuck pending 0.10.1, as on the maintainer's machine. With 0.9.1's acc-mcp holding
  contract 6, acc update staged the published 0.10.1. Offered 0.10.2, the 0.10.1 updater only
  retried 0.10.1. acc update --pin none cleared it, and acc update staged 0.10.2. Once the
  server exited, 0.10.2 activated, and only its generation remained.

Upgrade from the published 0.10.0 and 0.10.1

Each was installed the same way, with its own acc-mcp running and holding contract 7; their
published sha256 matched the recorded ed5c2d88… and b899b2ca…. Each acc update printed
Updated ACC to 0.10.2; integrations refreshed. without waiting. The installed generation
matched the archive file for file, and the Codex config.toml was unchanged.

Mixed versions

The published 0.10.0 code, and separately the published 0.10.1 code, each run from its own
package through its entrypoint, shared one store with the installed 0.10.2: a question each way,
each found in the other's inbox and answered, both reported 2 live, and both doctors reported
the store healthy.

The maintainer's data home

Native holds that block a contract-7 activation, counted read-only on the live data home with
this tree's code: 5 bindings on 2 pids, the Codex app server and the Claude Code session that
ran these checks. The 0.10.1 code had counted 6 pids on the same home earlier the same day.

Suite

npm test on the evidence commit 3f42483 ran under env -i with only HOME, USER, TMPDIR,
a PATH of system directories plus node, the release npm cache, and ACC_TEST_REAL_FSYNC=1, so
that every flush happened, as in CI. It gave 3,201 tests: 3,193 passing, 0 failing, 8 skipped,
in 5.0 minutes, and left no test directory behind. Five skipped tests exercise Windows only
(named pipes, .cmd clients, WMI); two are the real-clients tests, which ran separately
(below); one needs Gemini CLI absent from the machine. Nothing was re-run.

Real clients

On the maintainer's Mac (macOS arm64), the real-clients tests ran against the candidate commit's
packed tree, with an isolated home and a model stub on 127.0.0.1. Claude Code 2.1.292 and
Codex 0.160.1 attached through their own hooks, saw each other and carried a message into the
next turn, and an idle interactive Claude Code woke through its inbox. Both passed on the first
run. The real-clients CI job passed on ubuntu-latest and windows-latest on the final head of
#278.

Limits

• The maintainer's own machine is updated after publication; that result is not part of this
  record.
• A machine with a pending 0.10.0 or 0.10.1 needs acc update --pin none once: their updater
  runs the decision and does not replace a pending release.
• Linux and Windows were exercised only through CI; the Windows start-time reading is covered by
  the unit test that reads the test process's own start time.