v1.0 exit: real-environment acceptance run of record at 093c7be (a-account environment) #143

Activity

1. Simon-AI-coding

   added

   wayfinder:taskWayfinder task ticketWayfinder task ticket

   on Aug 29, 2026
2. Simon-AI-coding

   added a parent issue on Aug 29, 2026

   • Map: v1.0 is a bridge over every Session the user starts #67
3. Simon-AI-coding

   self-assigned this

   on Aug 29, 2026
4. Simon-AI-coding commented on Aug 29, 2026

   

   Simon-AI-coding

   on Aug 29, 2026

   OwnerAuthor

   More actions

   Acceptance run — 20260829T233015Z — result PASS (19/19: both lanes 9/9 green, plus the realtime probe)

   The map's exit condition, run of record attempt 3, executed on Simon's machine per this ticket's procedure. Nothing was fixed, arranged or changed to make a step pass; main is byte-for-byte the tree that was built, before and after.

   Run id: 20260829T233015Z (16m 34s wall)
   Tree: main @ 093c7be, git status clean before and after the run.
   Bundle: rebuilt with PATH=.venv/bin:$PATH scripts/build-app.sh, codesign --verify --deep --strict OK on the built bundle and again after install; installed by ditto into /Applications/GPT-VoiceCoding.app.
   Preflight provenance (verdict.json): "the bundle's engine is byte-identical to 093c7be" — "bundle": "/Applications/GPT-VoiceCoding.app", "commit": "093c7be". My own diff -rq -x __pycache__ src/gpt_voicecoding <bundle>/…/site-packages/gpt_voicecoding agrees: the sole difference is the untracked src/gpt_voicecoding/adapters/session_launcher/, which holds nothing but a stale __pycache__ and no .py at all, so preflight's .py-only compare rightly ignores it — the same artefact attempt 1 recorded.
   Undo kept, never deleted: the previous bundle is renamed aside at /Applications/GPT-VoiceCoding.app.pre-143-1788046198 (attempt 2's …pre-135-1787917957 is also still on disk).
   Versions seen (verdict.json): claude /Users/simon/.local/bin/claude: 2.1.251, codex /Users/simon/.nvm/versions/node/v24.13.0/bin/codex: codex-cli 0.150.1, bundle python 3.12.14.

   The three preconditions this ticket added after attempt 2

   1. CLAUDE_CONFIG_DIR was unset for the whole run — the default ~/.claude, the main-account universe, the one Map: v1.0 is a bridge over every Session the user starts #67 scopes v1.0 to. Recorded before starting, never set by me. The ~/.claude-b universe was not touched.
   2. Run from the primary checkout /Users/simon/Documents/coding/GPT-VoiceCoding, not a worktree, so the realtime probe resolved on its own and GPTVOICECODING_ACCEPTANCE_REALTIME_PROBE was never set. Since Acceptance: realtime probe SKIPPED when run from a worktree — default legacy path not found #142 a missing probe is a refusal — it did not refuse, and it did not skip: it ran and passed.
   3. GPTVOICECODING_ACCEPTANCE_ROOT was explicitly unset (as was _BUNDLE), so the documented default root was used: ~/Library/Application Support/GPT-VoiceCoding/acceptance/. Nothing under /tmp was the run root, so Acceptance harness: reject run roots that bypass Codex permission triggers #140's refusal never fired and the Codex permission targets were not world-writable — which is exactly what attempt 2 got wrong.

   Before the run

   • pgrep -fl 'GPTVoiceCodingShell|gpt_voicecoding' → nothing. Neither the menu-bar shell nor an engine was running, so there was nothing to quit — the still-unexplained Shell: engine blocked by preflight does not start on its own after the credentials file is fixed by hand #139 aftermath this ticket says is not mine to fix. There was no second consumer of the bot at any point.
   • Token: exported from the repo's .env (GPTVOICECODING_TELEGRAM_TOKEN, standing authorisation on Map: v1.0 is a bridge over every Session the user starts #67) into the pytest shell alone. Never printed, never written anywhere.
   • .venv/bin/python tests/acceptance/telegram_person.py status → AUTHORISED as Simon (@None, id 8760621971); session /Users/simon/Library/Application Support/GPT-VoiceCoding/acceptance/person/person.session.
   • .venv present: Python 3.14.4, pytest 9.1.1.

   Every step's verdict, both lanes

   Step	claude	codex
   roster	PASS	PASS
   stable name	PASS	PASS
   progress	PASS	PASS
   stop notice	PASS	PASS
   relay	PASS	PASS
   approval	PASS	PASS
   companion inbound	PASS	PASS
   switches	PASS	PASS
   child	PASS	PASS

   Probe
   0b realtime contract probe	PASS

   "result": "PASS", "missing": []. pytest: 3 passed in 994.57s.

   The four evidence lines worth reading, because each closes something the map left open

   • 0b is green. 1837 remote audio frames in 30s, first frame seen (realtime-probe.log). Map: v1.0 is a bridge over every Session the user starts #67's fog carried "the realtime contract change found by acceptance step 0b (session.model refused) — must be resolved or the voice lane's acceptance re-scoped", re-confirmed unchanged as recently as 2026-08-26 with 0 remote frames in 30s. It is no longer refusing. This is an upstream-side change measured here, not a change this repo made — nothing in 093c7be touches it — so what it means for the fog entry is the advisor's call, not mine.
   • A Codex approval can be raised in a trusted workspace, and the run measured the conditions rather than inferring them: approval item/fileChange/requestApproval:…:exec-02114493-… announced as chat message 4064, approve answered 'approved by voice', measured at sandbox 'workspace-write', approval_policy 'on-request', approvals_reviewer 'user' — read out of codex's own turn_context in rollout-2026-08-30T11-36-04-01a04fe1-….jsonl. That answers the fog item asking whether the step is red on that lane or unobservable on it: neither — it is green and observable.
   • A Claude subagent does show up from outside. claude:a240942779a9c8a75:12508 listed under {'agent': 'claude', 'session_id': '30287fe2-…', 'pid': 12508}, no notice naming it in 120 s, and the Relay refused with is a Child Process spawned by …: it appears in the roster and is never Relayed into. The fog item said this was known only in the negative; it is now known in the positive, on both lanes (codex: codex:01a04fe8-…, same shape, same refusal).
   • stop notice is green on both lanes, the step Build 1/7 — Discovery, roster and reachability: lock the one Session-inspection type #74 handed on with evidence rather than a conclusion — claude bot message 4047 and codex 4063, each naming its own Session, each matched to an engine.log Session stopped: … waiting on none line.

   Turns measured — claude: acknowledge 13.5s, relay 6.0s, wait-for-permission 7.5s, question 4.6s, child 19.5s. codex: boot 4.1s, acknowledge 13.6s, relay 7.5s, wait-for-permission 16.7s, child 25.8s. #44's approval directory holds nothing on both lanes.

   environment block, verbatim

   {
     "gen1_runtime_present": false,
     "gen1_hooks_in_user_settings": [],
     "gen1_daemon_listening": false,
     "shell_wrappers": [],
     "scrubbed_agent_markers": [
       "CLAUDECODE", "CLAUDE_CODE_CHILD_SESSION", "CLAUDE_CODE_ENTRYPOINT",
       "CLAUDE_CODE_EXECPATH", "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS",
       "CLAUDE_CODE_MESSAGING_SOCKET", "CLAUDE_CODE_MESSAGING_TOKEN",
       "CLAUDE_CODE_SESSION_ID", "CLAUDE_EFFORT", "CLAUDE_PID"
     ]
   }

   Worth naming: gen1_hooks_in_user_settings is now empty. #73 recorded gen-1's wrapper and its four user-scope hooks in ~/.claude/settings.json — two of them ADR 0011's own slots — on the verdict rather than refusing them. They are gone, and the run says so itself.

   Recorded, not graded (the harness's own words)

   • Workspace trust is arranged by the harness, not observed, on both lanes: "the run cannot both arrange this and judge it". The grant and the revoke are in journal.jsonl; .claude.json.before-trust and config.toml.before-trust are in the run directory.
   • Codex boot turn: launched with a non-empty prompt because that is what skips Codex's update gate (Acceptance: skip the Codex update prompt by starting the TUI with an initial prompt, never by editing config #110); its Stop Notice drained behind chat mark 4062 (Acceptance: stop notice takes any bot message as its own Stop, including another Session's #109), nothing arrived in 90 s.
   • Codex question: "Codex projects no question dialog; recorded, not graded (Rework #103: a question's answer is an Answer Relay through the held hook, not a fourth ApprovalVerdict kind #128)."

   Artifacts

   • verdict.json — /Users/simon/Library/Application Support/GPT-VoiceCoding/acceptance/20260829T233015Z/verdict.json
   • journal.jsonl — /Users/simon/Library/Application Support/GPT-VoiceCoding/acceptance/20260829T233015Z/journal.jsonl (12.8 MB)
   • pytest output — /Users/simon/Library/Application Support/GPT-VoiceCoding/acceptance/pytest-143-20260829T233014Z.log
   • also in the run directory: pty-claude.log, pty-codex.log, realtime-probe.log, engine-claude/, engine-codex/, both workspaces, outside-the-sandbox/

   Step 8 — the machine put back

   open -a /Applications/GPT-VoiceCoding.app, and both processes came up — pid 1492 GPTVoiceCodingShell and pid 1802 …/engine/bin/python3 -m gpt_voicecoding.engine --config …/engine/config.toml. Attempt 2's unexplained note — shell up, no engine — did not recur here, on a bundle built from the main that carries #139's fixes.

   bridge-install status, verbatim:

   installation-record: wanted=true
   codex-launch-agent: the shared daemon is answering, CLI and app-server both '0.149.1'
   claude-hooks: current — /Users/simon/.claude/settings.json
   codex-launch-agent: stale — /Users/simon/Library/LaunchAgents/com.gpt-voicecoding.codex-daemon.plist — loaded job is of unknown render; applies at the next login
   

   The stale line is #83's written rule doing what it was built to do, not a defect: this product never bootouts a daemon the user's Sessions are attached to, so a re-rendered plist is written and not reloaded, and status asks launchd which program it actually holds rather than answering a boolean. It applies at the next login. Nothing was kickstarted, booted out or otherwise done to the Codex daemon at any point in this run — Simon's Sessions stayed on it throughout.

   The CLI 0.150.1 / daemon 0.149.1 split that attempt 1 flagged is present again and again is not a blocker: the codex lane went 9/9 green across it.

   Left for the advisor

   Per this ticket's Done when, the ticket stays open: the verdict is recorded, the login engine is back up, and declaring the map's exit is the advisor's call, not the worker's. Nothing here is red, so there is nothing to file.
5. Simon-AI-coding commented on Aug 30, 2026

   

   Simon-AI-coding

   on Aug 30, 2026

   OwnerAuthor

   More actions

   Ruling (advisor, Simon, 2026-08-30) on run 20260829T233015Z: the exit is declared. v1.0's destination is reached.

   The map's exit condition is one sentence — "the real-environment automated acceptance (docs/acceptance-design.md, reshaped for this journey) runs green on Simon's machine against the installed bundle" — and this run satisfies every clause of it literally: the real environment (main-account ~/.claude, the documented run root, the real Telegram bot, the real Codex daemon), automated (pytest -m acceptance, no step arranged by hand), green (19/19, "result": "PASS", "missing": []), on Simon's machine, against the installed /Applications/GPT-VoiceCoding.app that preflight certified byte-identical to 093c7be.

   What makes this the run of record and not merely a green run: the three failures of attempt 2 were all harness defects (#140, #141, #142), all landed, and this run was taken under the preconditions those fixes require rather than around them — so the green is the product's, not the harness's. git status was clean before and after; nothing was changed to make a step pass.

   Closing this ticket. The map is closed alongside it; what the run answered and what it did not are recorded there.
6. Simon-AI-coding

   closed this as completedon Aug 30, 2026