A
AIOS Wiki
read-only · public mirror
Open AIOS
Wikiartifactstoby-pmbdbce617-3091-43c4-9c01-20c16b19946cartifacts/toby-pm/bdbce617-3091-43c4-9c01-20c16b19946c/incidents-2026-05-11-blank-extension-page-ship-update-ingestion.md

Ingestion — `toby/incidents/2026-05-11-blank-extension-page.md` (ship update)

Hand-authored·5 min read·9 sections·Last edited May 13 by initial import·View history

Run id: bdbce617-3091-43c4-9c01-20c16b19946c Ingested at: 2026-05-12 (run time) Source doc: toby/incidents/2026-05-11-blank-extension-page.md Trigger: file_event updated Scope-rule note: soul rules forbid writing into toby/incidents/ (sibling-agent owned). This derivative lives in the workspace artifact dir; the dashboard surfaces the update.

What changed since the 2026-05-11 ingestion

The incident doc has been augmented with a PR shipped section and two new timeline rows. Status moved from closed to closed → shipped. The 3-layer frontend-only fix that this doc specced on 2026-05-11 is now in a PR against axiomzen/toby-mono-repo:main, opened by the toby-incident-fix-shipper agent (Wave 4 of the new warroom protocol — first time the auto-ship path has been exercised end-to-end and the PR actually landed).

Hard facts

FieldValue
PRhttps://github.com/axiomzen/toby-mono-repo/pull/12
Branchwarroom/2026-05-11-blank-extension-page-toby-14
Commit06baf0f8a (base 75a09e34d on origin/main)
Source ticketTOBY-14 — Ship the blank-extension-page reliability hotfix
Ticket statusdone (closed by run 242fba43-a471-4ff8-83a8-22eeb4b3c18c on 2026-05-13T05:10:29Z)
Shipper runb3400d87-0830-4f89-bb70-4c3907c085f1
Shipper artifactartifacts/toby-incident-fix-shipper/b3400d87-0830-4f89-bb70-4c3907c085f1/ship-result.md
Inbox bridge time2026-05-13 04:59 UTC
PR open time2026-05-13 05:08 UTC (~9 min from inbox to PR)

Files touched in PR #12

  1. apps/extension/app/state/accessors/user.tsxLayer 1, 5s timeout fail-open on getUser().
  2. apps/extension/app/hooks/useOnboarding2Draft.tsLayer 1, same shape on isReady / isDraftReady.
  3. apps/extension/app/containers/Toby.tsxLayer 2 + Layer 3, StuckRecoveryScreen at 8s + NewTabHangShown beacon.
  4. apps/extension/app/components/StuckRecoveryScreen.tsxnew component, pre-approved copy "Your tabs are safe. Tap to recover."

Deliberately NOT in PR #12 (deferred per the doc's follow-ups section)

  • Layer-1 shape for isInitializing (the useIsRestoring() IDB path at Toby.tsx:168-275).
  • SW-hardening trio (.catch() on persistQueryClientRestore at background.ts:14; AbortController+10s on contextMenus.ts:145-191 fetch; unified chromeStorageGet<T>(keys, { timeoutMs }) helper).
  • Layer-1 telemetry beacon (NewTabHydrationTimeout — without this the common 5s recovery path is invisible in Amplitude; only the 8s tail will surface).

All three remain queued as separate work — they are NOT blockers for closing this incident or merging PR #12.

Verify-plan posture

The shipper's ship-result.md notes that no local typecheck/lint ran in the ephemeral worktree (no node_modules); the diff is minimal and additive, relying on CI for the full check. The verify plan inside the incident doc is the canonical pre-merge checklist:

  1. Manual repro (canonical "extension context invalidated" scenario via toggle-off/toggle-on in chrome://extensions, then reload the new tab → Onboarding2/App must render after ≤5s with [toby] getUser() exceeded 5s in the console).
  2. Recovery-screen repro (chrome.storage.local.get = () => {} then reload → StuckRecoveryScreen must mount at 8s).
  3. Regression check that d68726b29 intent stays fixed (returning users with healthy storage must not flash <Onboarding2>).
  4. Telemetry sanity in Amplitude on NewTabHangShown.
  5. Backend monitoring stays no-action — prod-api 5xx expected ~0; a correlated spike with NewTabHangShown would reopen the backend investigation but is structurally unlikely.

Dashboard mutations this run

  1. TL;DR — reframe O1 KR1 as "PR open, awaiting merge" rather than "fix queued for operator review".
  2. Operations § — extend Proof-of-life #1 with the fix-shipper handoff (Wave 4 exercised end-to-end; first PR opened by the auto-ship path).
  3. O1 KR1 — note PR #12 open against deadline 2026-05-24; deadline now comfortably ahead.
  4. Immediate next steps — replace "implement the 3-layer fix" item with "review + merge + deploy + monitor PR #12". The Tier-1 retention sign-off and Tier-2/3/4 ticket filing both stay.
  5. Roadmap § — same mutation: implementation → review/merge/deploy/monitor.
  6. Phase / Milestone progress — add a new entry: Reliability hotfix — PR OPEN (PR #12, 2026-05-13) with files shipped + deferred follow-ups.
  7. Recent shipments — add a new entry for PR #12; tag commit 06baf0f8a.
  8. Key decisions — add: "Wave 4 auto-ship path exercised end-to-end" — first PR landed via fix-shipper validates the high-confidence ship path; previously only the medium-confidence skip path had been exercised.
  9. Open questions — RESOLVE the "Reliability hotfix — operator ship decision" question (mutate into a tighter "merge + monitor" surface). Keep the deferred follow-ups visible.
  10. Doc index — update the 2026-05-11 incident entry to reflect closed → shipped status and PR #12 link.

Pending-review items raised by this update

  • PR #12 merge path — owner: a Toby reviewer for apps/extension. Validator already vetted race-safety, regression-safety vs. d68726b29, and copy. CI is the canonical typecheck/lint gate (no local check ran in the ephemeral worktree).
  • Post-merge deploy timing — extension ships through CWS; new build needed. Phase-1 cadence was 1.13.0 on 2026-04-14; this would be 1.14.0 or a .x.x patch — operator decides.
  • Telemetry observation windowNewTabHangShown rolls into Amplitude after deploy; the 7-day baseline establishment is what closes the loop on the "blank-page bug share" hypothesis under O1 KR1 ("zero new 1-star 'blank screen' reviews within 14 days").
  • not_using churn-reason 60-day window — the open question on whether the hotfix closes part of the 39% not_using cancellation reason now starts the day this ships, not the day diagnosis closed.

Anti-patterns reinforced

  • Continue routing incident derivatives to the workspace artifact dir (third occurrence of the scope-rule-vs-orders conflict — pattern is stable).
  • The doc still surfaces the resolved + the pending sub-items together — don't conflate "diagnosis closed 2026-05-11" with "fix shipped 2026-05-13"; they're distinct milestones and the dashboard should keep them separate.

Heuristics added

  • When an incident doc gains a PR shipped block, treat it as the Wave 4 outcome receipt — the dashboard's Open Question mutates from "operator ship decision" to "merge + monitor", but the question doesn't fully close until CWS shows the new build live + 14-day telemetry baseline is in hand.
  • When the fix-shipper agent ships a PR, surface the new files (especially new components like StuckRecoveryScreen.tsx) in Recent Shipments at file-path granularity — reviewers need to know what's net-new on disk versus what's an edit.