# Fable adversarial pass

## (a) The capture-first fix is aimed one step too late

The doc says persist "the moment transcription returns." Read your own root cause again: the screen went off **during the transcribe-then-route step**. Transcription is a network round trip from a foreground page. On Android, screen-off can freeze or kill the page mid-fetch — meaning "the moment transcription returns" is exactly the moment that never arrives. You've moved the persist point from after-routing to after-transcription, but the failure window you actually hit is *before* transcription completes. The bug will recur; it'll just recur less often, which is worse, because you'll declare it fixed.

The correct capture point is **end of recording — or better, during it**:

1. Persist the raw audio blob to IndexedDB the instant recording stops. Better: chunk-persist via `MediaRecorder.ondataavailable` every few seconds, so even a kill mid-recording loses seconds, not the memo.
2. Hold a Screen Wake Lock while recording. Screen-off during recording suspends MediaRecorder on plenty of Android builds — that's a fourth lost-message path the doc doesn't mention.
3. Transcription and routing become **retryable jobs against a saved record**, with idempotency keys so a retried upload can't double-fire an agent. Look at Background Fetch (Chrome Android) for the upload leg — it survives page death, which is the entire problem. (`fetch keepalive` won't work; 64KB body cap.)

"A dictation should be as unlosable as a photo" is the right slogan. A camera app persists the sensor data first and does everything else later. Yours currently persists after a cloud round trip. That's not photo-grade.

Also: "capture-first refactor" as one of three P0 items in a single weekend is fantasy if done right (chunked persistence + wake lock + retryable jobs + idempotency). Done in a weekend, you'll ship the shallow version described in the doc. Cut scope elsewhere — bug 2 is an afternoon, bug 3 is a sideload — and give bug 1 the whole weekend.

## (b) It's a to-do list in a trenchcoat — but the trenchcoat has a self-destruct timer, and that's the part that matters

Be honest about the anatomy: items with states (`waiting`, `stalled`, `executed`), a daily review surface, a snooze button (⏸ **Later** is a snooze — the foundational to-do primitive, renamed). Structurally, this is a to-do system.

What actually distinguishes a to-do system is not the list — it's **who bears the maintenance obligation**. Here the differentiators are real: 7-day mortality means the only durable state is <7 days old and self-garbage-collects; the max-three resurfacing cap prevents backlog grooming; the model, not Byron, assigns importance. The list tends itself. That's a genuine inversion, not marketing.

But the design has two failure modes it doesn't confront:

- **The trust collapse.** Mortality is only tolerable if execution rate is high. If `daily` items keep dying unexecuted, the burial notes become a weekly log of dropped commitments, Byron stops trusting the system, and he starts a manual list on the side — to-do system reborn, now with worse ergonomics. The doc has no metric for this. It needs one (see changes below).
- **The double decision layer.** The model triages on arrival *and* every card demands Execute/Later/Log buttons. That's two triage systems for the same item. Five drive dictations = five cards awaiting taps = an inbox. The card contract as written **is** the to-do system, arriving one item at a time. Collapse it: model decides, card *reports* the decision, buttons only appear when the model genuinely can't act.

Also unstated: what does "Later" mean mechanically? If it means "appears in tomorrow's digest," fine. If it means "appears until I deal with it," you've built snooze-until-guilt, and mortality-vs-Later interaction is undefined.

## (c) Over-engineering audit — mostly clean, three cuts

For a single user, most of this is appropriately small. Specific verdicts:

- **Cut the 5-minute cron option entirely.** Direct POST on upload with the queue as safety net is strictly better and simpler. The doc presents them as alternatives; there's no decision here. Do the POST.
- **The per-dictation card choreography is over-built** given auto-triage (see above). Most dictations should produce zero Telegram messages or one silent-edit confirmation. "Exactly one message per dictation" should be "at most one."
- **Auto v1.1 (MediaSession, big-button destinations) is correctly deferred**, but the sideloaded-APK situation is the real fragility — the audit check is the highest-value line item in P0 relative to its cost. Good.
- **The SW VERSION-bump "reminder" is a process smell.** A rule that "has burned this app before" and lives as a parenthetical in a planning doc will burn it again. Hash the shell at build time or fail the deploy. Reminders are not engineering.
- The rollup-feeds-podcast bit rides on existing infrastructure — fine, not gold-plating.

## Ruling: auto-EXECUTE — yes, and it's not optional

Byron dictates while driving. A card requiring a tap arrives when he cannot legally or safely tap it. If nothing executes without Execute, every `execute-now` item stalls until he parks, and the "queue of decisions" is just an inbox with better typography. The tap-gate defeats the product.

**Auto-execute this class:** anything reversible, idempotent, and contained within Byron's own systems — log to OB1, draft documents/notes, research and retrieval, write code to a branch, create/modify entries in his own calendar, queue podcast items. The test: *worst case is Byron deletes an artifact.*

**Never auto-execute:** anything that crosses the blast-radius boundary — outbound messages to other humans, sends via Signal, purchases, deploys, deletes of existing data, anything irreversible or externally visible. The test: *worst case is Byron apologizes to a person or reverts production.*

Mechanics: per-destination allowlist plus a model-confidence floor; below the floor, degrade to the tap-gated card. Every auto-executed card edits in place to ✓ with result **and an [Undo] where the action supports it** — Undo is what makes auto-execution trustworthy, not confidence scores.

---

## The 3 highest-leverage changes

1. **Move the capture point to during-recording:** chunked IndexedDB persistence via `ondataavailable`, wake lock while recording, transcription/routing as idempotent retryable jobs on saved records. This is the actual fix for the lost-message bug; the doc's version is not.
2. **Collapse triage and the card into one layer:** model auto-triages, safe class auto-executes with edit-in-place + Undo, buttons appear only for boundary-crossing actions. Target: median taps per dictation = 0.
3. **Instrument the anti-to-do bet:** track executed-vs-buried ratio for `daily` items and lost-memo rate, surfaced in the Morning Brief. If important items are dying at 7 days, you need to know in two weeks, not discover it when Byron quietly opens a notes app.

## One bold idea missing

**Close the loop in the same modality it opens in: voice.** The entire capture surface is audio-while-driving, but every confirmation is a visual Telegram card the driver can't read. Pipe execution results back as TTS through Android Auto / the existing podcast channel: *"Captured. Two actions running. The Gia note is sent. One thing needs a decision when you stop."* Bolder still: accept a spoken "yes" / "later" as the tap for boundary-crossing actions. The system as designed dictates hands-free and confirms hands-required — that asymmetry is the biggest unexamined gap in the whole document.