# 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.