Ingestion — TOBY-14 → warroom → PR #12 (2026-05-13)

Run id: 4500210d-f4fa-4663-9f91-cba7c219970c (toby-pm). Source file: toby/incidents/_inbox/2026-05-13-toby-14-ship-the-blank-extension-page-reliability-hotfix.md. Why this lives in artifacts/toby-pm/ and not next to the source: toby/incidents/ is owned by the warroom team. Sibling-scope rule wins over the orders' "save next to source" phrasing.

What landed in the inbox#

A needs-warroom-bridged file derived from ticket TOBY-14, asking the warroom to ship the 3-layer fix from the closed 2026-05-11 blank-extension-page incident. This is not a new diagnosis — it's an explicit invocation of the validated+high-confidence auto-ship path that the fix-shipper agent was added for on 2026-05-12.

What actually happened (verified by independent evidence)#

Stage	Evidence	Status
Ticket created	aios_tickets_get TOBY-14 — id a3ff635d-…, kind=bug, priority=urgent, labels [needs-warroom, warroom-bridged], sourceDocPath=toby/incidents/2026-05-11-blank-extension-page.md	Confirmed
Bridge fired	Inbox file at toby/incidents/_inbox/2026-05-13-toby-14-ship-the-blank-extension-page-reliability-hotfix.md matches the bridge's filename pattern YYYY-MM-DD-<ticket-id>-<slug>.md	Confirmed
Warroom picked it up	Ticket carries lastAttemptRunId=242fba43-a471-4ff8-83a8-22eeb4b3c18c (fix-shipper run) and outcome=solved	Confirmed
Branch up	warroom/2026-05-11-blank-extension-page-toby-14 exists locally and on origin	Confirmed
PR open	gh pr list returns #12 — OPEN, title warroom: 2026-05-11-blank-extension-page (TOBY-14), created 2026-05-13T05:07:56Z	Confirmed
Fix applied	Commit 06baf0f8a815de5b068413ebd17f030bc6e10bfb touches the four files specified in the canonical incident doc: apps/extension/app/state/accessors/user.tsx, apps/extension/app/hooks/useOnboarding2Draft.ts, apps/extension/app/containers/Toby.tsx, plus new apps/extension/app/components/StuckRecoveryScreen.tsx (66 lines)	Confirmed
Ticket transitioned	TOBY-14 status done, completedAt=2026-05-13T05:10:29.638Z	Confirmed

What's actually in commit 06baf0f8a (sample)#

apps/extension/app/state/accessors/user.tsx diff matches Layer-1 spec exactly:

• Wraps getUser() in a 5s setTimeout that fails open (setIsUserHydrated(true)).
• Adds .catch() for explicit rejection paths.
• Uses cancelled flag + cleanup in useEffect return to avoid state writes after unmount.
• .finally(clearTimeout) clears the timer on the happy path.
• Leading comment explains the Chrome "extension context invalidated" failure mode.

Sibling patches in hooks/useOnboarding2Draft.ts and containers/Toby.tsx (+ new StuckRecoveryScreen.tsx) match the incident doc's Layer-2 and Layer-3 specs. Commit message follows the warroom's defence-in-depth voice and links back to both the canonical doc and TOBY-14.

Scope footnote — .sandcastle/ is on origin/main already (NOT a scope concern)#

Initial pass flagged commit 75a09e34d (.sandcastle/ autonomous-slice-runner scaffold, ~3,400 lines) as co-landing on the same branch. Correction: git branch --contains 75a09e34d shows it's on the warroom branch only, but git log -1 origin/main is 75a09e34d — meaning 75a09e34d is the current HEAD of origin/main and the warroom branch was based on it correctly. My local main was just stale (still at b9bea18cd).

The correct PR delta: git log origin/main..origin/warroom/2026-05-11-blank-extension-page-toby-14 = a single commit 06baf0f8a. PR #12 merges exactly the four-file warroom fix and nothing else. No scope concern.

(I had this wrong in the dashboard-edit plan I sketched before verifying topology against origin/main. The prior dashboard run that already wrote up the ship event had the topology correct — recording the lesson here so the next run doesn't re-flag it.)

What this proves about the warroom#

Wave 4 auto-ship path is now exercised end-to-end. Prior to today the dashboard could only claim "the gate works in both directions" based on the medium-confidence path (TOBY-6 correctly skipping auto-ship). Now we have the third state covered:

• validated + high → fix-shipper opens PR (TOBY-14 / PR #12) — proven 2026-05-13
• validated + medium → corrected diff in canonical doc, human review required (TOBY-6) — proven 2026-05-12
• rejected / conditional → up to 2 retry passes — still un-exercised in practice, but the spec is in place

The ticket→warroom bridge mechanism (lib/tickets.ts → bridgeWarroomIfNeeded) also works end-to-end: human created TOBY-14 with needs-warroom, the bridge wrote the inbox file, Wave 0 picked it up off the inbox queue (not the ticket queue this time — the inbox path is alive and was not deprecated as the prior dashboard implied).

What I'm changing in the dashboard#

Nothing — the dashboard already covers this event. A prior toby-pm run (artifact bdbce617-3091-43c4-9c01-20c16b19946c, ship-update ingestion) processed PR #12 and propagated it through every surface that needed it:

• TL;DR carries the inbox-bridge → PR-opened → ticket-done timeline (~9 minutes inbox→PR; commit 06baf0f8a; files enumerated).
• Operations § frames TOBY-14 not as a new proof-of-life #3 but as the Wave 4 closure of proof-of-life #1 — which is the more accurate framing since TOBY-14 ships the existing 2026-05-11 diagnosis, doesn't introduce a new one. The team count is bumped to five agents (added fix-shipper).
• O1 KR1 cites PR #12 + commit 06baf0f8a and reframes the operator action as "review → merge → bump extension version → CWS-deploy → telemetry-watch".
• Immediate next steps replaces "implement the 3-layer fix" with "review + merge + deploy" + an explicit 7-day Amplitude / 14-day CWS-reviews monitoring shape.
• Phase / Milestone progress gains a "Reliability blank-page hotfix — PR OPEN" entry pointing at PR #12.
• Recent shipments top entry is now the code shipment (PR #12) — first code activity in 14 days.
• Key decisions captures Wave-4-end-to-end-proven AND deliberate-scoping-of-the-PR (the three follow-ups from the incident doc were correctly held back).
• Open questions section MUTATES the prior "operator ship decision" question into "review, merge, deploy, monitor" and adds a NEW question about whether to file the three reliability follow-up PRs as separate tickets to prevent the hardening work from getting lost after PR #12 merges.
• The not_using churn-reason question is reframed: the 60-day window now starts the day the merged build hits CWS, not the day diagnosis closed.
• The d68726b29 recent-shipments annotation now says "now defended-in-depth by PR #12".

My role this wake: verify the work landed correctly, capture the new memory keys (fix-shipper run id, ship-update artifact path, true branch topology), and surface the run-summary as this artifact.

Anti-patterns reinforced this run#

• The orders said "save next to source"; the soul rule says "never write into a sibling agent's folder". Soul rule wins (fourth occurrence of this pattern: strategist, x, blog, incidents — pattern is fully stable).
• The _inbox/ mechanism is not deprecated for the ticket→warroom bridge path; the dashboard's "hand-dropping into _inbox/ is deprecated" phrasing refers to humans hand-dropping files, not to the bridge. The bridge writes inbox files programmatically and that's the canonical entry path.
• Don't propagate scope-concern findings to the dashboard until verifying branch topology against origin/main (not local main). My local main was stale and tripped a false-positive "co-landed scope" reading; the prior run had the topology right.
• Don't rewrite the dashboard when the prior run already covered the event. This is a new heuristic: rewrite-in-place is right when surfacing new info, but skip-rewrite is right when verifying a peer's work that already landed. Confirm via aios_wiki_get_doc first, write only the artifact + memory diff.