[lilyshen0722]

Rollback for #2354. Press only on Cofounder's revert call.

#2354 merged as 8fbbfca6 and publishes CLI 0.1.112. On 10-20, after the publish, a non-admin page-path walk on @latest checks that the seat:

• answers one normal question and one @mention, once each, with no double-post and no NO_REPLY;
• confirms it has the "Being a good Commonly member" text.

If that walk fails, pressing this PR is the rollback.

Why a PR: no one here can move npm's latest tag (the package's only owner is not on this host, and publishing is OIDC only). So the rollback ships the same way the fix did. A merge publishes 0.1.113 with the old behaviour. 0.1.112 stays on npm but is no longer latest.

What it is:

• git revert 8fbbfca6, so cli/src/lib/adapters/claude.js and cli/__tests__/adapters.claude.environment.test.mjs are byte-identical to their state before fix(cli): a public Claude seat gets its declared skills as prompt text #2354.
• cli/package.json and cli/package-lock.json at 0.1.113. The open TASK-189 Isolate public OpenCode provider egress on Linux #2320, TASK-233 Measure Seatbelt system Keychains access #2321 and feat(cli): add private Goose adapter (TASK-235) #2326 claim 0.1.109–0.1.111.
• Against 8fbbfca6~1, the only diff is those two version lines.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wkz5axAzCvoLEFkZ5KtkKG

[lilyshen0722]

Gate — #2355 at 452561e1ed991cb5ce24ec200028bfb2d92848f6

A standby revert of 8fbbfca6 (#2354's squash), to be held unpressed until ~Tue 10-21 21:30 PT. One commit, parent 8fbbfca6, 4 files, +3 −225.

The property holds, and more tightly than stated

The ask asks that two named files be byte-identical to 8fbbfca6~1. I checked the whole tree instead: the only paths that differ between this head and 8cb239f7 (8fbbfca6~1) are cli/package.json and cli/package-lock.json, and the only hunk in each is the version line, 0.1.108 → 0.1.113. Nothing else in the repository moves.

• cli/src/lib/adapters/claude.js → c89fc6859b56e40fb5f70d53268be7f5437a5098, identical to pre-#2354.
• cli/__tests__/adapters.claude.environment.test.mjs → c32d33742190ff93f054593378e9e03e334b1ab3, identical. The 161 deleted lines are both of #2354's commits (119 + 42), so the revert covers the test commit I re-gated, not just the first one.
• cli/ file sets identical to pre-#2354 — nothing added or orphaned.

Version numbering checks out against the registry, not just the claim. npm has …0.1.107, 0.1.108, 0.1.112, latest = 0.1.112. So 0.1.109–0.1.111 are unpublished reservations, and 0.1.113 is free. The three reservations are real and I can name them: #2320 claims 0.1.109, #2321 0.1.110, #2326 0.1.111.

Nothing else on main is touched. Main has moved once since 8fbbfca6 — 2907b465 (#2339), which touches three frontend/ files and no cli/ path. Merged state computed with git merge-tree --write-tree origin/main <head>: clean, tree d0cbc80a. In that pressed tree the two restored files are still blob-identical to pre-#2354, the version reads 0.1.113 in both files, the only cli/ paths differing from pre-#2354 are the two version files, and the only non-cli differences are #2339's own three files.

Press-state suite (pressed tree applied in a throwaway worktree): 1209 passed, 16 skipped. That is exactly 7 fewer than the 1216 I measured at #2354's head — the 5 + 2 arms #2354 added and nothing else. The two failures are the pre-existing mention-event-types.contract.test.mjs pair (Cannot find module 'ts-node/register/transpile-only', no backend dependencies in this worktree), identical to what I measured on #2354.

Defect — the hold window makes this unmergeable on the first contending bump

The revert is clean today and conditionally clean tomorrow, and the condition is not in anyone's control once the queue moves. Measured, with a control:

scenario	#2355 merges
main as it stands (2907b465)	clean, tree d0cbc80a
main + any later cli version bump (synthesised 0.1.114 on main)	CONFLICT in cli/package.json + cli/package-lock.json

The version line is a single contended line, and this PR's whole delta from pre-#2354 is that line. The queue makes the hazard concrete rather than theoretical: #2320, #2321 and #2326 each already conflict with main on exactly those two files today, because main took 0.1.112 while they were reserving 0.1.109–0.1.111. Every one of them therefore has to touch that line again to merge at all, and the moment any of them does, this standby PR needs a rebase before it can be pressed — during the window where it is being pressed because something is wrong in production.

This is a press-readiness defect, not a correctness one: a version-line conflict blocks a merge, it cannot silently resolve to a wrong tree, so there is no path where pressing this produces something other than pre-#2354 code. The cost is latency at exactly the wrong moment, and it is invisible until someone looks at the PR.

Verdict

Pressing this restores the pre-#2354 CLI exactly — whole-tree, not just the two named files — under 0.1.113, which is free on the registry. The defect above is about when it can be pressed, not what pressing it produces. A rebase that changes only the version lines would not need a fresh gate from me on the restored-code property, since that property is established by blob identity against 8cb239f7; a rebase that touches anything under cli/src would.

Written by Vera, a Commonly agent — https://commonly.me/pods/6a8f6dc7a1dccf2e02f31015

GATE: PASS

[lilyshen0722]

Closing as planned: nothing surfaced against 0.1.112 (#2354) by the 21:30 PT 10-20 deadline. npm latest stays 0.1.112, and no revert was called. The branch stays, so this can be reopened if one is needed later. A revert that ships after #2361 (0.1.117) would have to claim a version above the highest merged one, because npm-publish refuses a version below the registry's.