fix(pi): rescue undecorated composer + restore removed call button (#460)

[rosscado]

Problem

On the initial load of https://pi.ai/talk the SayPi call button could be missing from the composer until a page reload or an SPA navigation away and back (#460). Everything else (sidebar buttons, audio controls) decorated normally.

Root cause

The prompt was the only decoration target with no document-wide rescue path, so any missed mount was permanent:

1. content-loaded never decorated the prompt. The handler re-scans document.body for audio controls, the sidebar, and chat history — but not the composer. If the composer mounted while route observation was stopped (the 300ms route poll calls stopObservingDom() on transiently non-chatable paths during Pi's boot), nothing ever decorated it — matching the report exactly: no call button, everything else normal, reload fixes it.
2. The initial-decoration retry window was ~7.5s, while a live cold-cache probe measured Pi's composer mounting at t≈25s. The loop also self-terminated permanently if a single retry tick landed on a non-chatable path.
3. A removed call button was undetectable. A host re-render that destroys the injected button while reusing the same <textarea> (which keeps id=saypi-prompt) leaves every finder reporting "already decorated" — the button could never come back.

Investigation details (instrumented headed-CDP probes against live pi.ai, mutation/URL timelines) are on the issue.

Fix

• content-loaded now rescues the prompt (findAndDecoratePrompt(document.body)) and restores a missing call button (ensureCallButtonPresent).
• bootstrapInitialDecoration retries for ~30s and survives transiently non-chatable ticks.
• The mutation removal branch detects a removed #saypi-callButton and re-creates it in place. decoratePromptControls extracted from decoratePrompt for reuse, guarded against duplicate buttons and stacked submit-button observers.
• updateButtonSegments no longer console.errors in the (re)creation gap before the async SVG mounts — with the restore path this is a normal transient (it surfaced as flaky page errors in the Layer 3 suite until downgraded).

Testing

• Fail-first specs (all 4 watched failing before the fix): test/chatbots/PiBootstrapInitialLoad.spec.ts (route-blip miss, content-loaded rescue, ~20s late mount, button-removal restore) and test/buttons/CallButton-svg-mount-gap.spec.ts.
• Full gate green in the worktree: typecheck + Jest + Vitest (182 files / 1590 tests).
• Layer 3 e2e: 12/12, zero console errors.
• Layer 4 (CDP) on live pi.ai/talk with this branch's build: decoration + a full synthetic voice turn verified.

Closes #460

🤖 Generated with Claude Code

https://claude.ai/code/session_01VVm2qYNQoMSQMUpnWcriJE

[rosscado]

Reviewer verdict (independent, post-hoc gate completion): APPROVE

Independent adversarial review completing the merge gate for a sibling session's finished work. I traced the bootstrap machinery end-to-end on main vs. the branch, ran the PR's specs in its worktree, and empirically re-verified the fail-first claim against main.

1. The three miss vectors each have a real recovery path

• (a) Route-blip miss — handleRouteChange (src/chatbots/bootstrap.ts:155) emits content-loaded on return to a chatable path, and the content-loaded handler now runs findAndDecoratePrompt(document.body) + ensureCallButtonPresent() (bootstrap.ts:188-189). On main that handler re-scanned audio controls/sidebar/chat history but never the prompt — the claimed root cause is accurate; a composer mounted while stopObservingDom() was in effect stayed bare forever. Recovered. The route-blip spec exercises the real route monitor (/talk → /onboarding → /talk, Pi's isChatablePath correctly rejects /onboarding), not a mocked path.
• (b) Late mount — bootstrapInitialDecoration maxAttempts 10→18 (bootstrap.ts:241). I summed the capped backoff series: old window ≈ 7.5s, new ≈ 31.5s — the "~30s" claim is arithmetically correct and covers the t≈25s cold-load probe. The restructured guard skips the scan on a transiently non-chatable tick but keeps the loop alive, where main's early return killed it permanently — that was a second, independent contributor to vector (a).
• (c) Button destroyed, textarea reused — the removal branch (bootstrap.ts:93-101) detects #saypi-callButton in any removed subtree and ensureCallButtonPresent() re-runs the extracted decoratePromptControls. Main had no path back from this state: findPrompt short-circuits on document.getElementById("saypi-prompt"), so every finder reported "already decorated" forever. Every content-loaded emission now also acts as a backstop.

2. Regression hunt — clean

• Other hosts: all rescue paths are getElementById-guarded no-ops once decorated; findAndDecoratePrompt returns foundAlreadyDecorated without re-decorating. The ChatGPT Phase-1 control-panel cleanup moved intact into decoratePromptControls, and ChatGPT always got a call button on main too, so ensureCallButtonPresent creates nothing ChatGPT shouldn't have. Adjacent host specs (ClaudeBootstrapReload, Pi-onboarding, CallButton-arc-rebuild, Pi-PromptSelector: 14/14) pass on the branch.
• No runaway work: no new intervals; the retry loop self-terminates at attempt 18 even while skipping non-chatable ticks (it now idles for up to ~30s after a permanent nav-away instead of exiting on the first tick — bounded, negligible, and deliberate). The one new observer risk — stacked submit-button MutationObservers from re-running decoratePromptControls — is explicitly guarded by the new submitButtonMonitoredAncestors WeakSet, which incidentally fixes a pre-existing stacking leak on the prompt-replacement path.
• Single-decoration invariants: createCallButton is guarded by !document.getElementById("saypi-callButton") (bootstrap.ts:344); buttonModule.createCallButton reuses the singleton CallButton instance (src/ButtonModule.js:251-259), so restores add no duplicate EventBus subscriptions. I specifically checked the ImmersionService interplay: attach/detachCallButton moves are synchronous, so by MutationObserver-callback time the moved button is back in-document and ensureCallButtonPresent no-ops — no duplicate button, and the rescue doesn't fight immersive placement (initMode is promise-deferred and runs after the rescue creates the button).
• console.error→debug downgrade (src/buttons/CallButton.ts:250-256): justified. createButton assigns this.element (CallButton.ts:326) before the awaited callInactive mounts the SVG, and redraws segments itself at CallButton.ts:341 after mount — so a missing SVG in that window is a self-healing transient, and the actor subscription (if (!this.element) return) can legitimately fire inside it. Still logged at debug; a genuinely never-mounting SVG would be visually obvious, not silently masked.

3. Tests — fail-first empirically confirmed

• On the PR worktree (Node 22.21.1): PiBootstrapInitialLoad.spec.ts 4/4 + CallButton-svg-mount-gap.spec.ts 1/1 pass.
• I ran both specs unmodified against main (66e43ea) in a throwaway detached worktree: all 5 fail, each for the bug's exact reason — createCallButtonMock never called (route-blip, content-loaded rescue, late-mount specs), button not restored after removal (expected null not to be null), and console.error called once in the SVG-mount gap. The fail-first claim is not just coherent; it reproduces.
• CI on the PR: test (22.x) and e2e both SUCCESS.

4. AGENTS.md discipline

Minimal diff (2 source + 2 test files, no .wxt/ or stray artifacts), no gate weakening (the one log downgrade is pinned by a spec), commit carries Co-Authored-By + Claude-Session trailers, PR body has the session link and Closes #460.

Non-blocking observations

• The removal branch now runs a querySelector("#saypi-callButton") per removed element per batch — in line with the existing per-removal finders, negligible.
• If a host re-render ever pathologically deletes the injected button on every commit, the restore path would re-insert once per removal — bounded per mutation batch (no tight loop), and strictly better than the button staying gone.

Solid, well-evidenced fix. Approving.

[rosscado]

Merge gate complete — requesting founder merge. CI green + independent reviewer APPROVE (verdict above, fail-first re-proved in both directions). Two agent sessions were classifier-blocked from merging (auto-merge grant covers only self-opened PRs), so this one's yours, @rosscado. Merging completes #460 (closed as deferred-on-merge).

[rosscado]

Not approved - changes requested.

1. The proposed solution does not work on first load of pi.ai.
   Steps to reproduce:

• In a new browser tab/window, open https://pi.ai
  Expected Result:
  The "new chat" page appears and a call button is present in the prompt editor.
  Actual Result:
  The call button is not present in the prompt editor.

2. Navigating from page to page on pi.ai loads more than one call button.
   Every time I move from one page to another, e.g. between threads/conversations, another call button gets added to the prompt editor.

Reproduced on builds produced with npm build and npm dev.