DEV Community: Ibukun Demehin

Polish pass #3: store-release edges and platform traps

Ibukun Demehin — Sun, 06 Sep 2026 18:58:02 +0000

Third polish pass, and this one has a theme without trying: every item is a trap that only appears at the edges — on Android rather than iOS, on a real device rather than the simulator, at cold start rather than warm, in a store listing rather than the app. The weeks around a launch are where those edges get found, because that's when strangers start holding the thing.

TL;DR — Android's native alert renders three buttons and silently drops the fourth (Cancel vanished; use a sheet, act on dismiss). A single bottom-sheet prop, adjustResize, makes the sheet trust a window resize that never happens under edge-to-edge — omit it. The web dev server started answering HTTP 431 to everything because Cognito tokens in cookies grew past Node's header limit. A transient session-refresh failure was treated as "signed out" while the tokens stayed — users landed on sign-in and were told they were already signed in. Scanned items now carry brand and pack size (with the pack unit deliberately not stored as the item unit). Plus: the iOS back button that said "index", per-document legal dates, and "CannyCart" becoming "Canny Cart" everywhere — because the store cross-checks your listing against your deletion page.

(Part 39 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Android's fourth button doesn't exist

The profile-photo sheet offered four options once a photo was set: camera, library, remove, cancel. On Android, Alert.alert has three button slots and silently discards the rest — and the one it discarded was Cancel, leaving a dialog with no way out.

Replaced with a proper bottom sheet, which has three escape routes by nature (Cancel, the backdrop, hardware back). One subtle rule inside it: actions run on dismiss, not on press. The image picker is itself a modal, and opening a modal over a closing sheet races on both platforms — sometimes the picker appears, sometimes it's swallowed. Let the sheet finish closing, then act on what was chosen.

The one prop that hides the keyboard trap

Part 20 explained why React Native's core keyboard-avoiding view measures zero under Android's mandatory edge-to-edge: the window doesn't resize, it receives insets. The bottom-sheet library has the same trap wearing a different hat. Pass android_keyboardInputMode="adjustResize" and the sheet skips its own keyboard lift and zeroes its scroll inset, trusting a window resize that never comes — so the keyboard simply covers the sheet's input. Omit the prop and the library's own keyboardBehavior does the lifting correctly.

The tell that finally pointed at it: two sheets had always worked (the amount and list sheets) and two never had (the review sheets). The difference was that one prop, copied from a snippet that predated edge-to-edge.

HTTP 431 from cookies

The web dev server began answering 431 Request Header Fields Too Large to everything. Cause: the auth library was configured for server-side rendering, which stores Cognito tokens in cookies. Localhost cookies are shared across every port; refresh tokens run 4–6 KB each; a few accumulated sessions from different local apps pushed request headers past Node's 16 KB limit.

The fix was to notice the flag bought nothing — every guard in the console is client-side (Part 37), nothing does server-side auth — so tokens went back to localStorage and an unused adapter dependency left with the flag. One-time cost: cookie-stored sessions aren't readable from local storage, so signed-in admins re-authenticated once. A configuration that "enables" something you don't use is a liability with a delay on it.

"There is already a signed in user"

A cold-start bug from the v1.0.3 release: the auth gate treated any error from fetching the session as "signed out". But the auth library keeps the stored tokens on a transient refresh failure — no signal at cold start, a brief identity-provider hiccup — and only clears them on real auth errors. So users with perfectly valid sessions landed on the sign-in screen, entered their password, and were refused with "There is already a signed in user."

Two fixes. The gate now falls back to the stored id token when verification throws — a transient failure is not a sign-out. And the login flow honours an existing session for the same email (or signs the old account out first for a different one) instead of surfacing the library's message. The lesson is about error taxonomy: couldn't verify and not signed in are different states, and collapsing them punishes exactly the users with the worst signal.

A sibling bug shipped in the same release: announcement dismissals lived in a per-user key that sign-out wiped, so signing back in replayed every takeover, dialog and strip you'd already seen. They're now device-scoped and keyed by user id — the same account on the same phone stays dismissed; a different account gets its own entry.

Brand and pack size, and the unit that isn't

Scanned products now carry brand and pack size as first-class fields — and the display name folds the brand in at staging time: "Still Water" doesn't tell you which one to pick up, and the price-history key is the name, so a stripped brand would merge two different waters into one swinging price. (Guarded against providers that already include it — no "Buxton Buxton Still Water".)

One deliberately not-done thing: the pack unit is not stored as the item's unit. Quantity means "how many to buy", so "415 g" plus quantity 2 would render as "2 g". The pack size lives in its own field and the row reads "× 2". A unit that means two different things is worse than no unit.

Four small ones

The iOS back button said "index". The native stack labels the back button with the source route's name when that screen sets no title, and every push from a tab's index screen rendered "‹ index". A minimal back-button display mode on all three header-bearing stacks leaves just the chevron.
Per-document legal dates. Terms and privacy previously shared one updated-date, so amending either restamped both — a false claim about the other. Now two constants.
"Canny Cart", with a space. The home-screen label said "Canny Cart"; every other surface said "CannyCart". The store title would be the two-word form, and Google Play cross-checks the listing against the deletion page — so legal docs (both renderers), permission strings, web metadata and wordmark all now agree. Identifiers — bundle ids, scheme, table prefixes — untouched.
The sandbox prints its env vars. A one-line startup log listing which environment variables the sandbox script loaded, because "is the key set?" was the first question in every AI-feature bug report.

What I took away

Count the buttons on Android. Three is the limit; a sheet has infinite escape routes.
Old snippets carry old assumptions. One prop from the pre-edge-to-edge era hid the keyboard on half the sheets.
Unused capabilities aren't free — cookie storage nobody read produced a 431 nobody expected.
"Couldn't verify" is not "signed out." Transient failures deserve the stored token, not the login screen.
A field means one thing. Pack size and purchase quantity don't share a unit.
Stores read your app more carefully than your users do — even the space in the name.

The series, at 39

This closes the fourth batch: the money arc, the vision features, the release, the account move, deletion, languages, the admin console. The next posts will come from whatever ships next — the plan is a living document, and the app keeps outrunning it.

What's the edge your app only breaks on — the platform, the device, the cold start — and when did a real user find it before you did?

MUI vs Tailwind: the cascade-layers war story

Ibukun Demehin — Sun, 06 Sep 2026 18:56:10 +0000

The admin console's every input lost its outline. Every button flattened to plain text. A <Select> printed its raw value on top of its own label. Nothing threw. The server-rendered pages looked perfect — the breakage lived only on the pages behind the login, which is exactly where nobody looks until they're using them.

Two CSS systems share the web app: MUI (component styles injected at runtime by Emotion) and Tailwind v4 (utility classes, plus its "preflight" reset). Their coexistence is a solved problem — MUI documents it — and the solution is CSS cascade layers. This is the story of how a working layer setup got broken twice, each time by a single plausible-looking line, and what the cascade actually does when you get the order wrong.

TL;DR — MUI's official Tailwind v4 integration puts every Emotion style into a mui cascade layer; the global stylesheet declares the order theme, base, mui, components, utilities, so Tailwind utilities (later layers) reliably beat MUI. Two ways to break it, both shipped once: StyledEngineProvider injectFirst shadows the App Router's cache with an unlayered one, and Tailwind silently stops winning (a md:hidden that never hides). prepend: true on the cache provider inserts Emotion's @layer mui {} at the front of <head> — and since a layer's priority is fixed by where it's first declared, mui becomes the lowest layer and Tailwind's preflight outranks every component style: border: 0 solid erases input outlines, background-color: transparent flattens buttons, opacity: 1 un-hides the inputs MUI keeps invisible. It hides because only client-inserted styles are affected — SSR markup looks fine.

(Part 38 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

How the coexistence is supposed to work

CSS cascade layers (@layer) let you declare that entire groups of rules rank below other groups, regardless of specificity or source order within them. Tailwind v4 is built on them: its reset lives in a base layer, utilities in utilities. MUI's integration guide adds one option to the App Router cache provider — enableCssLayer: true — which wraps every Emotion-injected style in a mui layer. The global stylesheet then declares the order once:

@layer theme, base, mui, components, utilities;

Read left to right, lowest to highest. Tailwind's base reset ranks below MUI's components (so the reset can't strip a button), and utilities ranks above them (so a hidden class on an MUI component actually hides it). One line of config, one line of CSS, and two styling systems stop fighting. That was the working state.

Breakage #1: `StyledEngineProvider injectFirst`

The first plausible line came from older MUI advice about making other CSS beat MUI: wrap the tree in <StyledEngineProvider injectFirst>. In the App Router it did something subtle — it created a second Emotion cache, without the layer option, that shadowed the layered one from the cache provider. MUI styles went back to being unlayered, which means they participated in the normal cascade as ordinary high-specificity rules… and Tailwind's layered utilities, being in a layer, ranked below every unlayered rule.

The symptom was a single md:hidden on an MUI icon button that never hid. No error, no warning, just a class that did nothing. The fix was deletion: the cache provider with enableCssLayer is the integration; anything that constructs another cache undoes it.

Breakage #2: `prepend: true`

The second line was more plausible still. prepend: true on the cache provider makes Emotion insert its styles at the front of <head> instead of the end — commonly recommended so "other CSS can override MUI." Reasonable in an unlayered world. Catastrophic in a layered one, for a reason that took a while to see:

A cascade layer's priority is fixed by where it's first declared in document order. The global stylesheet declares theme, base, mui, components, utilities. But with prepend: true, Emotion's @layer mui { … } block landed in <head> before that stylesheet. So the browser met mui first — making it the lowest layer of all — and only then read the ordering declaration, which can't demote layers it's already ranked. Tailwind's base preflight now outranked every MUI component style.

Three preflight rules did the visible damage:

border: 0 solid — every input outline erased.
background-color: transparent — every button flattened to plain text.
opacity: 1 — the inputs MUI keeps invisible got un-hidden, so a <Select> printed its raw value on top of its label.

Why it hid for so long

The cruel part: only client-inserted styles are affected. Server-rendered pages carry just the baseline global styles in their markup, and those looked correct throughout. The component styles that break are inserted by Emotion after hydration — which means everything behind the auth guard (the entire admin console, client-rendered by construction) was broken, while the public landing page and legal pages that everyone checks were fine. The bug was invisible on every page you'd screenshot and total on every page you'd use.

The fix, again, was deletion — enableCssLayer: true alone is what the integration guide specifies, and nothing else. The repo's own instructions now carry both breakages as named rules, because each looked like a fix at the time.

The mental model that would have prevented both

Layers are ranked by first declaration, not by the ordering statement alone. The @layer a, b, c; line only ranks layers the browser hasn't already met. Anything that injects a layer block earlier in the document than that statement wins the race and loses the priority.
Unlayered styles beat all layered styles. A second cache without the layer option doesn't "join" the cascade — it sits above every layer, silently.
Injection position is a cascade decision. In a layered world, "put my styles first" means "make my layer lowest." prepend and injectFirst are answers to a question layers already solved.
Test client-rendered pages. If your styles are inserted post-hydration, your SSR screenshots are not evidence.

What I took away

Two styling systems, one integration, zero extras. enableCssLayer: true and the ordering line — anything added "for safety" is a regression.
First declaration ranks the layer. Read your <head> order, not just your stylesheet.
Preflight is a weapon once it outranks your components: borders, backgrounds and opacity vanish together.
Client-only breakage hides behind auth. Audit the pages that render after hydration.
Write the failure modes down as rules. Both of these looked correct; the note in the repo is what stops the third attempt.

Next up

Part 39 closes the fourth batch with the third polish montage: brand and pack size on scanned items, the Android alert that silently drops its fourth button, the edge-to-edge keyboard trap in bottom sheets, and the day the app got a space in its name.

What's the "recommended" line in your CSS setup that predates cascade layers — and have you checked what it does now?

The admin console: a web app on a mobile app's Cognito pool

Ibukun Demehin — Sun, 06 Sep 2026 18:53:37 +0000

Every support question in Part 36 implied a place to answer it from. The web app had been a landing page and legal documents; it needed to become a console — a dashboard, a deletion queue, user lookup, announcements, the activity feed. The Next.js + MUI half of the monorepo finally earned its keep.

The architectural wrinkle that shaped everything: the console and the phone app share one Cognito user pool. Every shopper is a valid Cognito user. Which means a successful sign-in to the console proves precisely nothing about whether you belong there.

TL;DR — The front door signs non-admins straight back out: sign-up is removed from the web auth page, and a valid session that isn't in an admin group is ended with a plain message — because on a shared pool, a session proves identity, not membership. That's front-door only; the schema's group rules stay the real boundary, and the route guard's group check is defence in depth for a session that changes under you. The deletion queue renders its runbook inline; the user lookup surfaces the S3 identity id that's unrecoverable after deletion. Every admin table spreads one defaults object — which is also the dark-mode fix, because the table library reads the light palette's literals under CSS-variables mode and its colour maths throws on var(...). Forms get their own routes, never dialogs; labels above fields, never floating.

(Part 37 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The front door: a valid session proves nothing

Two decisions make the console admin-only at the door:

No sign-up on the web auth page. Accounts are created in the phone app — or by hand, for admins. The console has no reason to mint users.
A successful sign-in that isn't in SUPER_ADMIN or ADMIN is signed straight back out, with "this console is for administrators." The check reads the groups claim off the access token, in one module that is the single definition of the gate. The route guard carries the same check as defence in depth — for a session that changes under you (a demotion mid-session, a stale tab).

And the honest caveat, written in the code and the docs: all of that is front-door only. The API's allow.groups rules are the real boundary. Models on plain authenticated access — profiles, lists, receipts — remain readable by any signed-in user through the API, because that's what the phone app needs. The console's gate keeps the wrong people from seeing controls whose writes would fail; it isn't what stops the writes. Knowing which of your walls is load-bearing is most of security architecture.

The screens, and the decision in each

/deletion-requests — the queue of requests filed from the public website (in-app deletion runs the Lambda immediately and never files one, per Part 32). The fulfilment runbook renders inline, next to the row's status, so working a request no longer means opening a markdown file beside the console. A runbook nobody has open is a runbook nobody follows.

/users — lookup for support questions, and one deliberately prominent detail: each user's row shows the Cognito sub and the S3 identity id. The identity id is unrecoverable once the Cognito user is deleted, and the deletion runbook needs it first — so the screen puts it where you'll capture it before you do anything irreversible.

/announcements — a composer with a live phone preview (the announcement rendered as the app will show it) and a typed confirmation for anything blocking (Part 35). /activity — the feed, with its filters in the URL.

Inviting an admin — a dialog on the users page calling a group-gated mutation, with distinct toasts for "invited fresh" vs "promoted an existing user," and retry: 0 on the mutation, because a slow identity-provider call that retries is how you double-invite someone.

One defaults object for every table (and the dark-mode fix inside it)

Admin lists are material-react-table, and the first two screens each had their own configuration. The third would have had a third. So: one adminTableDefaults() that every table spreads first, one stat-card component, and a rule for the cards themselves — a stat earns its place only if it changes what the admin does next, and the "alert" style means something is wrong, never something is big. (Yes, that's Part 26's Home rule, applied to a different audience.)

The defaults object is also where the dark-mode bug got fixed, and the bug is worth understanding. The table library paints its own surfaces by reading theme.palette.*. Under MUI's CSS-variables colour-scheme mode, those values are the light scheme's literal colours — the flipping references live in theme.vars.* — so every surface the library painted for itself stayed white under .dark. The obvious fix, handing it CSS variables, fails differently: the library runs darken()/lighten() over its base background colour, and MUI's colour maths throws on var(...). So the surfaces are painted through sx (which does no maths) — and only the two properties the library assigns directly without maths take variables, which happens to be the only way to reach the row-action popover, the one surface sx can't touch. A fix that's three lines and a paragraph of reasoning, which is why the paragraph lives in the code.

Tables also got a fixed frame: sticky header, body scrolling inside a bounded container, toolbar and pagination pinned — with head cells kept opaque because rows scroll under them (the web cousin of Part 12's sticky-header lesson).

Forms get routes; labels sit above fields

Two house rules the console enforces everywhere:

Forms get their own route (/announcements/new, /announcements/[id]), never a dialog on the list page. A form in a dialog can't be linked, refreshed, or half-finished safely.
Labels above fields — never MUI's floating labels. One shared form-field component (FormControl → FormLabel → input), and pickers get no label prop for the same reason. Floating labels collide with placeholder text, autofill, and every screen reader test I've run.

Every destructive action goes through one shared delete dialog; confirm() is banned. Web reads page through the same load-everything helper ported from mobile; admin writes use the user-pool auth mode, never the identity-pool mode the public deletion form uses.

The console also got light/dark/system theming — but default light, not system: the public landing was designed light, and dark is an explicit per-browser choice. And the reason the theme toggle sits in this post rather than being trivial is the next part: making MUI and Tailwind coexist broke in two spectacular ways before it worked.

What I took away

A shared identity pool means sessions prove identity, not membership. Gate at the door, enforce at the API, and know which is which.
Put the runbook next to the row. Documentation you have to go find is documentation that gets skipped.
Surface the value you'll need before the irreversible step — the identity id on the user row exists for the deletion runbook.
One defaults object per library, spread first, and put the workaround's reasoning in it.
Library colour maths and CSS variables don't mix — paint surfaces with plain styles, pass variables only where nothing computes on them.
retry: 0 on anything that creates. Retries turn slow into duplicate.

Next up

Part 38 is the war story this console produced: MUI vs Tailwind — two CSS systems, one cascade, and the two one-line changes that each silently erased every input outline in the app.

If your admin app shares a user pool with your consumer app, what happens today when a regular user signs in to it?

The activity log: what users did, without their words

Ibukun Demehin — Sun, 06 Sep 2026 18:51:27 +0000

The first real support question was small and unanswerable: "I scanned a receipt on Tuesday and I can't see it — did it save?" The database could say whether a receipt row existed. It couldn't say what the person had done — whether they'd scanned and cancelled, scanned and hit an error, or scanned twice and deleted one. The app had state but no history of actions.

An activity log is the standard answer, and the standard answer has a standard failure mode: a table that quietly accumulates copies of every private thing users type, under different access rules than the data it copied, with a different retention lifetime. The whole design of this one is about not building that.

TL;DR — Users write their own rows; only admins read them. No user text, ever — a row carries an action key, a count and ids, and the admin UI composes the sentence from a constants file (28 keys, mirrored across both apps). One row per user action, never per write — a voice capture of 30 items is one row with count: 30. Never log inside a mutation function — those re-run on retry and offline replay; log at the tap, with a queue that keeps the original timestamp when signal returns. Deliberately unlogged: item ticks (the ledger already is that record, at 30× the volume). And the repo's first GSIs: date-partitioned and per-user, paged with limits — the one screen that must not use the load-everything helper.

(Part 36 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Rule 1: no user text, ever

A row looks like this in spirit: { userId, action: "receipt.scanned", count: 12, targetId, at }. No list name, no item name, no store, no note — nothing the user typed or the parser read. The admin feed composes the human sentence ("scanned a receipt with 12 lines") from a constants file of 28 action keys, mirrored verbatim between the mobile app that writes and the web console that reads.

Three things fall out of that one rule:

Different auth, different lifetime, no leak. Activity rows are admin-readable and live a year; shopping items are user-private and live forever. Copying item names into the log would put private text under looser access with a different retention policy. Ids and keys leak nothing.
Rewording needs no migration; a new action needs no deploy. The sentence lives in the UI. Change the words, change nothing in the table.
The replication masker passes it straight through. A table with no free text has nothing to fake; the mirror copies it structurally, safely, by construction.

Rule 2: one row per action, never per write

The unit of logging is what the user did, not what the code did. A voice capture that creates 30 items is one row, count: 30. A receipt save that fans out into N item updates, a bulk add, and a receipt create is one receipt.scanned. If the log mirrored the write pattern, a single afternoon's shopping would produce a hundred rows nobody could read, and the count of "receipts scanned" would be wrong by a factor of the fan-out.

Which leads directly to the rule that took the most discipline: never log from inside a mutation function. Mutation functions re-run — on retry, and on offline replay after an app kill. A log call inside one would double-count every retried action and re-log yesterday's supermarket at the moment signal returned. The log call lives at the call site, at the tap — the moment the human did the thing. And because a mutation paused offline never reaches its success callback, the logger has its own queue for that case.

Rule 3: what is deliberately not logged

The absences were designed as carefully as the presences:

Item ticks. checkedAt on the item — the purchase ledger — already is that record, at roughly thirty times the volume of every other action combined. Logging it twice would drown the feed.
The auto-created default list, push-token refreshes, and writes to the shared product cache — machine actions, not human ones.
Account deletion — the deletion Lambda erases its own rows, and the public web form is a guest who can't write activity at all. (Deletions are counted, not logged: the anonymous rollups from Part 32.)

The logger never throws and is never awaited

logActivity() is fire-and-forget by contract: it can't fail the action it's describing. On failure — offline, transient — it buffers to per-user local storage (capped, with a seven-day cutoff so an abandoned device doesn't flush a month of stale rows later), and flushes on foreground or reconnect. The flush keeps the original timestamp: an action taken in a supermarket yesterday must appear at yesterday's time, not at the moment the phone found signal in the car park. A log whose timestamps mean "when we managed to write it" is a log of connectivity, not behaviour.

The repo's first GSIs — and the screen that must not `listAll`

Every other read in this app pages through the load-everything helper — fetch all pages, filter client-side — because the data is per-user and small. An activity table is neither. Loading a year of rows to render ten is the bug the paging rule exists to prevent, inverted.

So this model got the repo's first secondary indexes: activityByDate — a bounded partition per local day — and activityByUser, both paged with a limit and a continuation token. A date-range query in the admin feed walks day partitions backwards, resuming from a {date, token} cursor and capped at 31 days per page; picking a person switches to the user index instead. The feed's filters live in the URL (?from=&to=&user=) so a refresh or a shared link keeps the view — which, in the App Router, means the page needs a Suspense boundary or it stops prerendering and the build fails. A small tax on a good habit.

Retention is a TTL attribute (one year out), set through the table wrapper — which needed two extra permissions on the provider role that nothing else had ever required. And TTL deletion emits stream REMOVE events, so when production rows expire, the mirrored dev copies expire with them. Retention policy replicates itself.

What I took away

Log keys and counts, compose sentences in the UI. No user text means no leak, no migration for rewording, and a masker with nothing to do.
The unit is the human action. One row per tap, however many writes it fans out into.
Never log where code re-runs. Mutation functions retry and replay; the call site doesn't.
Decide what you won't log, especially anything another field already records.
Fire-and-forget, buffer on failure, keep the original time.
Know which table breaks your paging convention — and give it real indexes before it does.

Next up

Part 37 walks through the door of the admin console — a web app bolted onto a mobile app's identity pool, where a valid sign-in proves nothing, and the front door has to send the wrong people straight back out.

What does your audit log accidentally copy — and would you be comfortable if its access rules were the loosest in your system?

In-app announcements: talking to users after the build shipped

Ibukun Demehin — Sun, 06 Sep 2026 18:50:12 +0000

The day after the store launch, a fact about the architecture became a product problem: there was no way to tell users anything. Over-the-air updates aren't installed, so nothing reaches a running app; the store's "What's New" only reaches people who read store pages; and push notifications hadn't shipped yet. A bug found on launch day would have been invisible to every installed copy until the next review cycle.

In-app announcements are the channel that fixes that — a global model the admin console writes and the app reads. The feature is mostly small decisions, and two of them are the kind you only find with a real device in your hand.

TL;DR — A global Announcement model (no userId, admin-write, everyone-read). Severity picks the shape (INFO = dismissible strip, IMPORTANT = dialog shown once, CRITICAL = full-screen takeover); kind only picks the wording. Targeting is by the version users are running, compared segment by segment — a string compare sorts "1.10.0" below "1.9.0" and would mis-target every release after the ninth. actionUrl: "store" is a sentinel the app resolves per platform. The force-update wall fails open by construction: any error, timeout or empty cache renders nothing, so offline is never a wall. Seen state loads inside the component, never at root; a new account is never walked through the backlog. And from device testing: messages must arrive live (a subscription feeding the query cache), and a modal that must appear unprompted cannot be a bottom sheet.

(Part 35 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Severity picks the shape; kind picks the words

Two enums, deliberately orthogonal. Severity decides how a message interrupts:

INFO → a dismissible strip on Home. "What's new in 1.0.3."
IMPORTANT → a centred dialog, shown once. "Your receipts from Tuesday were re-processed."
CRITICAL → a full-screen takeover. "This version can't sync — please update."

Kind (WHATS_NEW / UPDATE_AVAILABLE / NOTICE) only drives the icon and label. Keeping them separate means an update nudge can be an INFO strip or a CRITICAL wall depending on how bad the old build is — the admin chooses the interruption level independently of the message type. Every message also lands in a What's-new archive screen, badged while unread, so a dismissed strip isn't gone forever.

Target the version people are running

The reader has to already be installed for a message to arrive, so targeting is by app version: inclusive minVersion/maxVersion on the row. The bug-in-waiting was the comparison. A string compare sorts "1.10.0" below "1.9.0" — perfectly, silently wrong, and it would have mis-targeted every release after the ninth. Versions are compared segment by segment as numbers, in one small module the whole app shares.

The action link got a sentinel: actionUrl: "store". The admin never pastes a store URL — the app resolves the sentinel to the right listing per platform, so a message can't carry an App Store link to Android users or vice versa. Any other actionUrl deep-links into the app.

The force-update wall fails open — by construction

A CRITICAL announcement can be marked blocking: a wall the user can't dismiss, for "this version corrupts data" emergencies. The design principle is that the wall must be impossible to raise by accident:

Any fetch error, timeout or empty cache renders nothing. An offline user is never walled; a backend hiccup is never a lockout. The wall only appears when the app has positively received a blocking row.
Only CRITICAL may block; a blocking row must carry an actionUrl (a wall with no exit is a hostage situation); the composer demands a typed confirmation before publishing one.
active: false is a one-click kill switch that releases everyone.
A blocking row ignores the seen-list — acknowledging a wall must not walk through it.

"Fails open" is the whole security posture, inverted: for a feature whose failure mode is locking out your own users, the safe default is to do nothing.

Seen state: per user, loaded in the right place

Dismissals are local state (announcements don't roam — you dismiss on each device), keyed per user and held in the preferences store so the strip, the dialog and the archive can't disagree about what's been seen. Where it's loaded matters: inside the <Announcements /> component, never at the root layout — the root runs before the per-user storage setup from Part 27 has keyed storage to the signed-in account, and would read the previous user's seen-list.

Two more gates: <Announcements /> mounts inside the onboarding gate's children, so a message can never interrupt currency onboarding. And an account-age gate: non-blocking rows published before the user's profile was created never interrupt or badge — a brand-new user (or an old account on a new device, since seen state doesn't roam) must not be walked through six weeks of release notes on first open. Blocking rows are exempt, because a force-update wall must stop a fresh install too.

What device testing found

They didn't arrive on their own. The query refetched on mount, foreground and reconnect — sensible for most data, and exactly the wrong shape for a message published "now": an open app learned nothing until the user backgrounded it. The fix was a live subscription (observeQuery) holding one AppSync connection and pushing the filtered list straight into the React Query cache — so every consumer updates together, the persisted cache still serves offline, and a failed socket degrades to what it did before. No schema change: read permission already covers listen.

The IMPORTANT sheet could not be made to work. It began as a bottom sheet, which opened at handle height on Android and not at all on iOS. The cause was structural: a bottom sheet needs an imperative present() call and a measured container — and fired from an effect at app start, it had neither. Fixing the content measurement just moved the problem to the container. Meanwhile INFO and CRITICAL never missed, because both render declaratively from state. So the sheet was rebuilt as a centred <Modal> dialog: visible is a boolean, height is its content, nothing to measure and nothing to time. The rule worth keeping: a surface that must appear unprompted should not depend on a measurement.

Small conventions that rode along

The body is a JSON field in the same shape as the legal pages ({paragraphs, bullets}) — a JSON string on write, string-or-parsed on read (the Part 14 lesson, still paying).
Time filtering happens in the query function, not a memo — the React Compiler rejects clock reads there — so a scheduled row appears on the next refetch rather than to the second. Acceptable; a scheduled announcement is not a countdown.
Archive cards key on the row id, never on their text: release-note bullets repeat across versions.

What I took away

Ship the reader before you need it. An announcement system reaches only builds that already contain it; the first version to include it protects every version after.
Compare versions as segments. "1.10.0" < "1.9.0" as strings is a bug you ship on your tenth release.
Force-update must fail open. The only safe default for a feature that can lock out users is silence.
Orthogonal enums: interruption level and message type are different decisions.
Load per-user state where per-user storage is ready — not at the root.
Unprompted surfaces render from state, never from an imperative call that needs a measurement.

Next up

Part 36: the activity log — what users did, for support and usage questions, with a rule that keeps user text out of it entirely, one row per action rather than per write, and the repo's first secondary indexes.

If your app has no OTA updates and no push, how would you tell every installed copy about a bug tomorrow?

Emails in the user's language, and the frozen Cognito pool

Ibukun Demehin — Sun, 06 Sep 2026 18:47:36 +0000

After Part 33, a user could pick Arabic in onboarding and get an app that flipped right-to-left within a restart — and then receive a verification email in English. The emails hadn't kept up, and the reason was structural: the two email senders fire in places where no profile row exists. The sign-up verification trigger runs before the user's profile is created. The forgot-password trigger runs for someone signed out. Neither can read UserProfile.locale.

The fix was two lines on the client and one attribute in Cognito — and then a deploy that failed on every branch for reasons the sandbox was structurally unable to show me.

TL;DR — Cognito's standard locale attribute is a mirror of the app's language for the one consumer that can't reach a profile: the app writes it at sign-up (the language the sign-up screen is rendered in — so the verification email matches by construction) and on every language change. The trigger reads it, treats it strictly as a whitelist key (user-controlled text is never echoed into HTML), falls back to English, and flips Arabic to dir="rtl". Deletion emails stay English by design — a per-address language lookup would turn the no-oracle guest form into an oracle. The war story: declaring locale in defineAuth.userAttributes failed every branch deploy with "Invalid AttributeDataType input", because a user pool's attribute schema is frozen at creation — and the sandbox looked fine only because its pool was born after the change.

(Part 34 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The attribute is a mirror, not a source of truth

UserProfile.locale stays the app's real language setting. The Cognito locale attribute exists for exactly one reason: the customMessage trigger from Part 28 receives event.request.userAttributes inline — no lookup, no latency, and available pre-confirmation when nothing else about the user exists yet.

The write side is three touch points, all client-side:

Sign-up passes locale as a user attribute — the app's resolved UI language at that moment ("es", never the "auto" sentinel). Which is the language the person is currently reading the sign-up screen in — so the verification email matches by construction, without a round trip.
Every explicit language change (onboarding, the More → Language picker) fires a best-effort attribute update alongside the profile write.
Nothing on sign-in — the attribute rides along from whenever it was last set.

The two lines at sign-up had been added in Part 33 "for later." This was later.

The read side: whitelist, never echo

The trigger localises verification and reset emails from a typed translations module — and the one rule that matters for security: the attribute is treated strictly as a whitelist key. It's user-controlled text; the client can write anything into it. So it's looked up against the supported-language map and never echoed into the HTML. An unknown or hostile value falls back to English silently. The verification included rendering the real handler with Spanish, Arabic, an unsupported locale, and a deliberately hostile string, and screenshotting every output.

Arabic flips the email shell to dir="rtl" — accent borders and card icons hug the reading edge — while the code digits stay LTR, because a six-digit code is not prose. The admin-invite email stays English: the console is English-only, and the invite goes to an admin.

The email that stays English on purpose

Deletion-request emails from the public web form are English by design, and the reason is a small security argument. A guest form has no trustworthy language signal — the browser locale is trivially spoofable and says nothing about the account. The tempting alternative — look up the address's stored language and reply in it — would make the request mutation behave differently for known addresses than unknown ones. That's the email oracle Part 32 spent a section preventing, reintroduced through translation. A language leak is still a leak; English for everyone is the fix.

The extended tier came free

When the thirteen extended-tier languages landed, the email templates followed — as a Lambda-only change: existing users with a stored locale started receiving translated emails on deploy, with no app update at all. The email's button labels and screen names are taken from the app's own locale files, so "Speak" is the same word in the welcome email as on the Home screen. One vocabulary, two renderers — a rule this project keeps rediscovering.

The war story: a schema that can't change

Somewhere along the way — because it looked like the correct, declarative thing to do — locale got declared in defineAuth's userAttributes. The sandbox deployed fine. The app worked. Then every dev-branch deploy failed, build after build, with:

Invalid AttributeDataType input

The cause is a Cognito fact worth memorising: a user pool's attribute schema is frozen at creation. The update API has no schema parameter at all. When CloudFormation is asked to change the schema of an existing pool, its handler falls back to the one thing it can call — add-custom-attributes — which rejects a standard attribute name (locale is OIDC-standard, not custom) with that error. Every branch deploy tried, every branch deploy failed.

And the sandbox? Its pool had been created after the declaration was added, so locale was in the creation-time schema and there was nothing to update. The sandbox wasn't lying; it was structurally incapable of reproducing the failure. "It works in the sandbox" and "it deploys to a branch" are different claims when the resource in question can only be shaped once.

The twist that made it worse: the declaration was also a no-op. Every Cognito pool is born with the full set of standard OIDC attributes — locale included, mutable and optional — and an app client with no explicit read/write attribute lists can already use all of them. The line had done nothing except break deploys.

The fix was deletion: remove the declaration. Schema removals are ignored on update — the documented-safe direction — so the sandbox pool keeps its harmless drift and the branches deploy again. The rule now lives in the repo's own instructions: never declare a standard attribute; they already exist.

What I took away

Mirror, don't move. The profile stays the source of truth; the auth attribute exists for the one reader that can't reach it.
Write the language the user is reading. The sign-up screen's own locale is the correct email language, by construction.
User-controlled attributes are keys, never content. Whitelist, fall back, never echo.
Translation can be an oracle. If a response changes based on whether an address is known, the language of the response counts.
Some resources are shaped once. A user pool's schema is frozen at creation — and a young sandbox will never show you that.
Sandbox age is a variable. Recreate it occasionally, or at least know which resources it created after the code changed.

Next up

Part 35: the only channel to users after a build has shipped — in-app announcements with version targeting against what people are actually running, severity that picks the shape, and a force-update wall that fails open by construction.

What's your platform's "frozen at creation" resource — the one where the sandbox says yes and production says never?

The app speaks 19 languages: tiered i18n and the AI translation pipeline

Ibukun Demehin — Sun, 06 Sep 2026 18:45:40 +0000

The codebase survey was blunt: zero i18n infrastructure, roughly 660 user-facing text nodes across 53 files, a dozen alert dialogs, forty toasts, screen titles scattered across layout files. English was load-bearing everywhere.

The reason to fix it then, rather than "after launch", was the closed-test window: Google Play makes you sit in testing for fourteen days regardless, and fourteen days of real people using translated builds is worth more than fourteen days of them using English. So the app learned six languages in one pass, then thirteen more.

TL;DR — i18next + react-i18next + a plural-rules polyfill (the JS engine ships a stub Intl on some platforms, and Arabic needs six plural categories), eight namespaces, static resources so the first frame already has copy. Language is per-user, not per-device — the currency pattern — cached for the first frame, mirrored on the profile so it roams, cleared and restored on account switch; the Cognito locale attribute is written at sign-up so emails can follow later. Arabic flips the shell RTL with a native flag and a one-shot restart prompt, logical direction classes, and a font trick: the Arabic face is registered under the Latin font's names, so every existing style re-faces with zero call-site changes. Two tiers — six human-reviewable launch languages, thirteen machine-translated — generated by a diff-only pipeline that forces structured output because free-form JSON kept breaking on quotes.

(Part 33 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Four pillars, all cloned from patterns the app already had

The plan's insight was that the app already contained every pattern i18n needed — a per-user preference (currency), a device-detected onboarding step (country), a searchable picker (voice language). i18n was the fourth instance of each, not a new discipline.

The library layer is i18next + react-i18next — pure JS, no dev-client rebuild — with the intl-pluralrules polyfill. That polyfill matters more than it sounds: the Hermes engine ships a real Intl on some platforms and a stub on others (the trap Part 16 hit with thousands separators), and correct CLDR plural rules are essential once Arabic — with six plural categories — is in the mix. Eight feature namespaces, static resources bundled with the app so the very first frame already has copy (no flash of keys), and dayjs switches locale alongside so dates translate with the words. 568 English keys at launch.

Per-user, not per-device — the shared-phone argument

The theme preference is device-scoped, and the first instinct was to copy it. One question killed that: on a shared phone, user A picks Arabic and signs out — user B is now in Arabic with no idea how to fix it. Language must follow the person. So it copied the currency pattern instead:

UserProfile.locale is the durable source of truth, so the choice roams to a user's other devices.
A per-user AsyncStorage cache means the right language on the first frame, before the profile query resolves.
On account switch the language resets to auto (device language) and is restored from the incoming profile — a returning user is in their language on first paint, a brand-new user is in their phone's, and nobody inherits a stranger's.
Signed-out screens therefore run on the device language, which is the right default for an unknown human.

Two extra lines at sign-up write Cognito's standard locale attribute alongside. They looked like over-engineering at the time; they're what later let the verification and reset emails arrive in the user's language, because the email trigger fires before any profile row exists and can only read the pool's own attributes. (That story, and its war story, is the next part.)

First-run onboarding gained a language step ahead of currency, pre-selecting the device language — guess, then confirm, as always.

Arabic: the RTL flip, and a font trick I'm proud of

Right-to-left was the reason Arabic was in the launch tier rather than the extended one: it's the language that finds every layout assumption. Three pieces of work:

The flip itself. RTL is a native flag: allow it at init, keep the force-flag in step on every language apply, and accept that it takes effect on the next launch. A one-shot restart prompt handles that — mounted inside the onboarding gate on purpose, so a first-run Arabic choice finishes onboarding before it asks you to restart. Roughly 33 places where gap/flex-based layouts didn't already mirror had their physical direction classes replaced with logical ones (ps/pe, ms/me, start/end, border-s/border-e).

The font. Nunito has no Arabic glyphs; Arabic text needs its own face, in the same four weights (400/600/700/800), or bold headings render regular. Cairo was the one candidate with exactly that set (the obvious alternatives each lacked a weight). Then the trick: in RTL sessions, Cairo's four weights are registered under Nunito's names in the font loader. Every font-nunito* class and every raw fontFamily: "Nunito_…" string — nineteen of them — re-faces automatically. Zero call-site changes. Sometimes the best migration is lying to the font registry.

Six plurals. Spanish, French and Italian carry their CLDR _many forms; Arabic gets all six categories — and its _zero/_one/_two forms deliberately drop the {{count}} placeholder, because in Arabic the number lives in the word itself (عنصر واحد — "one item" — contains no digit). A translation pipeline that blindly demands {{count}} in every plural form produces Arabic that reads like a machine.

Two tiers, and a pipeline whose limiter is review

Launch tier — Spanish, French, German, Italian, Arabic: languages where a human review is realistic, and where the plural/RTL work happens.
Extended tier — thirteen more (Portuguese, Dutch, Polish, Turkish, Russian, Ukrainian, Hindi, Indonesian, Vietnamese, Thai, Japanese, Korean, Simplified Chinese): machine-translated, labelled as such, generated by the same pipeline. Portuguese is deliberately pt-BR.

The pipeline is a script that sends the diff of English keys to a language model and writes the results per locale. Its one hard-won rule: force a structured tool call for the output. Free-form JSON in the response kept breaking on quotes and embedded newlines — a translation of a toast with an apostrophe would take the whole locale file down. Structured output made generation zero-retry. A companion checker validates every locale against English for key parity and for the correct plural category set per language — so Arabic can't ship with two forms and French with six.

The observation from running it: review, not tokens, is the limiter. Generating thirteen languages costs minutes; deciding whether the Vietnamese is any good is the actual work, which is why the tiers are honest about which languages a human has looked at.

The one native-rebuild piece: iOS permission strings (camera, microphone, photos) are localised per language through the app config's locales, which bakes into the binary.

What's deliberately not translated (yet)

Category and aisle vocabulary — "Produce", "Dairy" — stays English-keyed internally. Those labels are display text used as keys across the app and the parsing Lambdas; translating them touches the vocabulary the whole data model keys on, which is its own plan, not a string sweep. The voice and receipt parsers already tolerate non-English input; their internal vocabulary just stays anchored.

What I took away

Clone the patterns you already have. Currency taught per-user prefs; onboarding taught guess-then-confirm; i18n was the fourth instance, not a new discipline.
Language follows the person, not the phone. The shared-device question settles it in one sentence.
Write the auth provider's locale attribute early — it's the only thing an email trigger can read.
Arabic is the layout's audit — RTL, six plurals, and placeholders that shouldn't exist.
Register the fallback font under the primary's names and skip the sweep.
Force structured output for generated files — free-form JSON breaks on the first apostrophe.
Label your tiers honestly. Machine-translated is fine; pretending it's reviewed isn't.

Next up

Part 34: the emails caught up with the app — verification, reset and welcome messages in the user's language — and the deploy that failed every branch with "Invalid AttributeDataType", because a Cognito user pool's attribute schema is frozen at creation and the sandbox never said so.

Which language would audit your layout hardest — and does your plural handling survive a language where "one" and "two" are their own forms?

Account deletion for real: immediate, guest round-trip, admin-initiated

Ibukun Demehin — Sun, 06 Sep 2026 18:43:19 +0000

Part 24 shipped account deletion as a request — a form, a queue, a runbook I'd follow by hand. It was honest and it was insufficient: the release runbook ranked it the single most likely rejection, because Apple's 5.1.1(v) and Google Play both require deletion to be completed, not filed.

So deletion became real — in three lanes, each with a different threat model, sharing one Lambda's order of operations. This is the post where security decisions stop being abstract.

TL;DR — In-app: an argument-free authenticated mutation — the caller is whoever the API verified, so it can only ever delete itself; the order S3 → DynamoDB → Cognito last is the design, so any earlier failure leaves an account that can still sign in and retry; the S3 identity is derived from the caller's own object keys, never a client-supplied value. Guest web: a single-use confirm token, email dedupe, a confirm page that acts only on button click (inbox scanners prefetch links), and a mutation that always answers {ok: true} so the form can't probe which emails have accounts. Admin: the same Lambda's twin with group rules (super-admins are un-deletable, never yourself), plus a repair path for half-deleted accounts — and anonymous activity rollups, so erasing a user doesn't rewrite usage history.

(Part 32 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Lane 1: in-app, immediate — and the order is the design

The deleteAccount mutation takes no arguments. That's the first security decision: the caller is whoever AppSync verified the token for, so the Lambda can only ever delete the account making the call. There is no "which user?" parameter to tamper with, because there is no parameter.

The second decision is the sequence. Deleting an account touches three stores, and the Lambda walks them in a specific order:

S3 objects — avatar, receipt photos.
DynamoDB rows — every table the user owns (names arriving as SSM paths, per the house convention; the list of tables to sweep is one explicit constant).
The Cognito user — last.

The reasoning: every earlier failure leaves an account that can still sign in and retry. If S3 fails, nothing's gone. If DynamoDB fails halfway, the user still has credentials and can press the button again. Delete the Cognito user first and any subsequent failure orphans data that can no longer be attributed to anyone — un-deletable exactly when you're obliged to delete it. Part 24 made this point about the manual runbook; the Lambda inherited it as a hard invariant.

A third decision hides in step 1. Storage paths are keyed by the identity-pool ID, which is not the Cognito sub. Rather than accepting that ID from the client (a value a hostile caller could point at someone else's prefix), the Lambda derives it from the caller's own object keys — the avatar key and receipt image keys already stored on their rows. If you own the row, the row tells us your prefix.

When it's done, one thing is deliberately left behind: a COMPLETED deletion-request row — proof of fulfilment, with no user data on it, for the ninety days the privacy policy says records are kept.

On the client: a type-DELETE confirmation, immediate execution, sign-out after. And one honesty detail — the Lambda deliberately outlives the API gateway's timeout (a full sweep can take longer than the request window), so a "failed" call is reported as "outcome unknown — check by signing in", never "nothing happened." The one thing worse than a slow deletion is telling someone it didn't happen when it did.

Lane 2: the guest round-trip that can't leak

Google Play requires a public web page where anyone — including someone who can't sign in — can request deletion. A guest form is an attack surface by definition, and the original version (a guest-writable model, verify-by-reply) was tightened into a proper flow:

The form calls a mutation; direct guest writes to the model are revoked. One writer, so every request passes through the same guards.
One email per address per 24 hours. The form can't be used to flood an inbox.
A single-use confirm token lands in a branded email with a confirm link (with a reply-to-confirm fallback when no site origin is configured).
The confirm page acts only on button click. This one matters more than it looks: corporate inboxes and security scanners prefetch every link in an email. A link that confirms on GET would confirm deletions that nobody clicked. The page loads inert and deletes only on an explicit press.
The mutation always answers {ok: true}. Whether the address has an account or not, the response is identical — otherwise the public form becomes an email oracle: a way for anyone to test whether an address is registered. The truth goes to the support inbox, which is notified separately.

Confirmed web requests take the documented 30-day path in the privacy policy; in-app deletion is immediate. Two doors, two timelines, both written down where users can read them.

Lane 3: admin-initiated, without rewriting history

Support sometimes needs to delete an account on someone's behalf. adminDeleteUser is the deletion Lambda's twin — same S3 → DynamoDB → Cognito-last order — with the target named by sub and a set of rules the handler enforces against the caller's verified groups (not anything the client claims):

A super-admin can never be a target — refused outright.
Deleting an admin requires a super-admin caller.
Never yourself — use the app's own door.
A sub with rows but no Cognito user still erases — the repair path for half-deleted accounts from the manual era.

And the subtle design that makes admin deletion safe for analytics: an ActivityRollup model of anonymous per-day, per-action counters. As the Lambda erases a user's activity rows, it increments the rollups — so deleting an account doesn't rewrite usage history. The rollups carry no userId by design, which is precisely what lets them survive the erasure they record. They replicate to dev as structured passthrough and are admin-read-only. A deleted user disappears; the fact that someone scanned a receipt on that Tuesday does not.

The legal copy had to get honest too

Making deletion real forced a re-read of the privacy policy, and one paragraph turned out to be false. The barcode feature's product lookups run server-side — but the review sheet loads product photos straight from the third-party database's servers, which means they do see the device's IP at that moment. The drafted "they never see your IP" wording was wrong and was rewritten to disclose all four databases, the server-side lookup, and the photo exception. Deletion got its own rewritten section (immediate in-app; email-verified 30-day web path; records kept 90 days), and each legal document got its own updated-date so amending one no longer restamps the other.

Compliance work has a way of auditing your own claims. It's worth doing before someone else does.

What I took away

Identity comes from the token, never a parameter. An argument-free mutation can only delete its caller.
Order destructive operations so every failure is retryable — the step that destroys the ability to retry goes last.
Derive cross-store identifiers from data the caller already owns, never from the request.
Confirm on click, never on load. Link scanners prefetch; a GET must be inert.
Public forms must not be oracles. Identical responses whether or not the account exists.
Erase the person, keep the count. Anonymous rollups let deletion and analytics coexist.
Audit the policy while you build the feature — mine contained a sentence that wasn't true.

Next up

Part 33: the app learned to speak nineteen languages — a two-tier translation model (human-reviewed launch tier, machine-translated extended tier), a diff-only translation pipeline, and the day the shell flipped to right-to-left.

What does your delete-account flow do if the Cognito (or auth-provider) call succeeds but the data delete fails? If the answer is "orphans," swap the order.

Moving a live backend to a fresh AWS account

Ibukun Demehin — Sun, 06 Sep 2026 18:41:14 +0000

Two weeks before the store launch, the entire backend moved to a brand-new AWS account. Not a disaster-recovery drill — a deliberate reorganisation: the old account had grown up as a personal sandbox, and a fresh one with proper identity management was where a product with real users belonged. The closed-test deployment kept running in the old account until cutover.

It sounds terrifying. It was mostly boring, which is the point of this post: the conventions built in the earliest parts of this series are what made it boring, and the two things that did bite had nothing to do with the data.

TL;DR — A fresh account is empty, which makes the scariest migration step (renaming every table) free: the env-scoped naming code simply deploys clean on day one, so the copy-old-to-new script written for an in-place rename went unused. What can't move: Cognito users — passwords aren't exportable, and re-signup means new ids anyway, so user-keyed data resets by design. What must change: every client build, because new pools and endpoints mean new outputs. What you forget: the old account's Hosting webhook keeps building every push, and the new Hosting app has none of your env vars. Plus the small mechanics that made multi-project accounts and warm Lambdas behave.

(Part 31 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The migration that didn't need to happen

The plan I'd been carrying was an in-place table rename: adding a project prefix to every DynamoDB table (cannycart-{Model}-{env}) so multiple Amplify apps could share one account. Renames replace resources in this stack, so in a live account that meant a copy script — walk every old table, write into the new one, cut over in a quiet hour, and pray the orphans get cleaned up. I'd written the script.

Then the decision to move accounts arrived, and the whole problem dissolved: a fresh account has no old tables. The renaming code — the same backend.ts override from the resource-naming days — just deploys clean from the first sandbox run, tables arriving with their new names natively. No copy, no cutover window, no orphans. The migration script stays in the repo, harmless and unused, in case the old account ever needs the in-place path.

The transferable lesson: sometimes the cleanest migration is a new environment. When the destination is empty, "rename" becomes "name," and a week of risk becomes a config change.

What can't move: the users

Cognito users don't migrate. Passwords aren't exportable — by design — and even a bulk re-create would issue every user a new sub, the id that keys every profile, list, item and receipt in the app. So user-keyed data resets by design with the move: closed testers re-register, and their data starts fresh.

That was acceptable because of when it happened — closed test, a dozen testers, no store customers yet. Two weeks later it wouldn't have been. If your app is already live, an account move is a different, much harder project (identity-first migration with an activation flow), and the time to move is before the first real user. The only user-independent data worth carrying was the shared Product barcode cache — global facts, no userId, optional copy.

What must change: every client build

The opposite of the rename-only scenario, where clients wouldn't have noticed: a new account means new Cognito pools and new AppSync endpoints, so every per-environment outputs file changes (Part 2's mechanism), which means new EAS builds and new store submissions once the new production backend is live. Anyone with an old build installed is pointed at a backend that's about to be turned off. The move therefore had to land before the first store release, not after — the timing wasn't a coincidence.

The mechanics that made it boring

The project slug in every table name — cannycart-{Model}-{env} — is what lets multiple Amplify apps share the account: table names are account-and-region unique, and the IAM wildcards became table/cannycart-* (deletion Lambda, replicator, post-confirmation writes). The replicator strips the prefix when deriving model names — its masking map keys on bare names — and ignores other projects' streams entirely.
SSM table-name caches got a 5-minute TTL. Lambdas read table names from Parameter Store and cache them; a warm Lambda would otherwise keep writing to an old name after a rename indefinitely. A short TTL means renames reach warm functions within minutes, no redeploy.
The AWS profile became overridable (${AWS_PROFILE:-…}) instead of hardcoded across a dozen scripts — the kind of thing you fix once, during the move, so the next move is a one-line change.
One IAM grant got tighter while we were in there: the post-confirmation trigger's write permission narrowed from table/* to the one profile table it actually writes. Migrations are a good moment to audit the wildcards you accepted while prototyping.

The two things that bit

1. The old account kept building. The old Amplify Hosting app was still connected to the GitHub repo via its webhook — so every push to dev triggered a stale build in the old account for weeks after the move. Harmless, confusing, and quietly costing money: "the deploy failed" alerts from a backend nobody used anymore. Disconnect the old Hosting app as part of the move, not as cleanup later.

2. Env vars don't come along. The new Hosting app had none of the old one's environment variables — the AI parsing key, the email sender address. Nothing fails loudly: the backends deploy fine, and every AI-powered feature is simply dead on dev and prod until the vars are set in the console and both branches rebuild. Secrets and config live outside the repo by design, which means a new account starts with an empty set — put "re-enter every env var" in the runbook as a step, not a discovery.

And one external clock: transactional-email production access doesn't transfer either — the sending identity and its reputation belong to the old account. That restart is part of why app emails moved to a dedicated provider with a verified domain (a story the email parts tell).

What I took away

An empty destination makes renames free. If a migration's hardest step is renaming, ask whether the answer is a new environment.
Move before the first real user, or don't. Cognito users don't migrate; the ids that key your data change with them.
New account, new builds. Anything that bakes endpoints into a client must ship again.
Short-TTL your config caches. Warm Lambdas hold on to old names longer than you'd think.
Disconnect the old webhook, re-enter every env var, and audit your wildcards — the three steps every account-move runbook should list explicitly.

Next up

Part 32: account deletion done properly — an in-app Lambda that erases server-side in the right order, a guest email round-trip that can't become an email oracle, and admin-initiated deletion with anonymous rollups.

Have you ever moved a backend between accounts? What was the thing that kept running in the old one after you thought you were done?

Shipping to both stores: the release runbook

Ibukun Demehin — Sun, 06 Sep 2026 18:38:53 +0000

On 27 August, Canny Cart went live in both stores — the App Store and Google Play — as v1.0.1. Twenty-nine parts of building in public and the actual shipping turned out to be its own project, with its own runbook: ten numbered documents covering accounts, blockers, credentials, listings, privacy declarations, ratings, testing tracks, submission, and launch day.

This post is that runbook, compressed to what I'd tell someone releasing a solo app for the first time. The headline: the two things that decided the launch date weren't code, the highest-consequence failure mode was silent, and the one rejection that actually arrived was about a button.

TL;DR — Start Google Play's closed test first: new personal accounts need 12 testers continuously opted in for 14 days before you can even apply for production, and the clock starts when the twelfth joins. Get a domain early — Play won't roll out to any track without a Data Safety form, which needs a privacy-policy URL. Fix the blockers ranked by rejection probability: real in-app account deletion (Apple 5.1.1(v)), email deliverability (a reviewer's test account must receive its verification code), and third-party data disclosure. Guard the silent killer: a missing production outputs file makes the build ship pointed at your sandbox without a single error. Expect one rejection anyway — mine was 5.1.1(iv): a camera permission gate with an "Allow" button. And approved ≠ released: phased/staged rollout, manual release, so approval doesn't put you live at 3 a.m.

(Part 30 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The two things that decided the date (neither was code)

1. Google Play's closed test. New personal developer accounts must run a closed test with at least 12 testers, continuously opted in, for 14 days — before you can even apply for production access. The 14 days start when you have 12 testers, not when you create the track; drop below twelve and the clock can reset. Nothing else in the release takes as long, so the runbook's first instruction is: start this first, today, and let it run in the background while you do everything else. (You'll also need twelve friends who'll actually install a test build. Budget the social capital.)

2. A domain. I didn't have one. It gates far more than a pretty listing: Play won't roll out to any track — closed testing included — without a completed Data Safety form, and that form needs a privacy-policy URL that resolves. The compliance sprint had built the legal pages; without a domain they weren't anywhere. Buy the domain before you think you need it.

Everything else, in the runbook's words, "is paperwork, assets and a build."

The code blockers, ranked by rejection probability

The blockers document ordered the repo's problems by how likely each was to get the app rejected. Three mattered:

🔴 Account deletion was a request, not a deletion. The app filed a DeletionRequest for me to fulfil by hand — and Apple's 5.1.1(v) expects deletion initiated and completed from the app. "Email us and we'll get to it" is the classic rejection. The cheapest fix was to actually automate it: a server-side deletion Lambda (verify the caller → S3 objects → DynamoDB rows → the Cognito user, last). A day of work that removed the risk permanently; it gets its own part.

🔴 Email deliverability. The transactional-email service was still in its sandbox mode, where mail only reaches pre-verified addresses. The consequence isn't cosmetic: a reviewer creating a test account would never receive their verification code, and the sign-up flow needs that code. This alone can fail review. Auth emails were confirmed on Cognito's own default sender (unaffected), and app emails moved to a provider with a verified domain — no code path in the review flow depended on a sandboxed sender.

🟠 An undisclosed third party. Barcode lookups call the Open Food Facts databases — a data flow to a third party that the privacy declarations had to name. Store data-safety forms are an inventory of every external call your app makes; the provider chain had quietly added one.

The highest-consequence silent failure

The mobile app selects its backend config per build profile from committed per-environment files, with a fallback to the root file when the profile's file is missing (Part 2's mechanism). Robust for development. Catastrophic for a first release: amplify_outputs.production.json didn't exist yet — because the production backend hadn't been deployed — and the selector would have silently fallen back to the root file, which is generated from my personal sandbox.

A production build made that day would have shipped to both stores pointed at my dev backend, with zero errors anywhere in the pipeline. The runbook flags it as the highest-consequence silent failure in the whole release, and the pre-build checklist now includes:

ls -la amplify_outputs.production.json
grep -o '"user_pool_id": "[^"]*"' amplify_outputs.production.json   # NOT your sandbox pool
npm ci --dry-run                                                     # EAS installs with npm ci

Deploy main, generate the production outputs, commit, then build. Fallbacks that are convenient in dev are exactly the ones that hurt in release.

The rejection that came anyway

Build 6 of 1.0.1 was rejected under 5.1.1(iv) — on the barcode scanner's camera permission gate. The scanner opened with an explanation screen: an "Allow camera" button and a "Not now" button that let you delay the request. Both are violations, and the rejection letter itself explained why: the permission button's wording must be neutral (not "Allow"), and the flow must not let the user defer the system prompt.

The fix followed the letter's own recommendation. Tapping "Barcode" is the intent, so the system prompt fires the moment the screen opens, with the explanation text as a backdrop rather than a gate in front. A denied state shows "Continue" (re-askable, Android) or "Open Settings" (iOS), and leaving is a standard ✕ — navigation chrome, not a permission choice. Then a sweep of every other permission surface — voice, receipt camera, photo-to-list, avatar, notifications — confirmed they already called the system prompt directly. The resubmission passed.

The lesson: permissions are UX that reviewers grade. Your carefully explained pre-prompt is, to Apple, a gate between the user and the system dialog. Ask in context, ask immediately, let the OS do the asking.

Approved is not released

Two runbook rules for launch day:

Phased / staged rollout, always. Apple's Phased Release spreads updates over seven days (1% → 100%) and can be paused; Play's staged rollout goes 20% → 50% → 100% and can be halted — but a 100% release can't be cleanly unpublished. For a backend that's never been load-tested by strangers, this is the only sane default.
Manual release, not automatic — so approval doesn't put you live at 3 a.m. while you're asleep. Approval is a notification; release is a decision.

And one thing that turns on at production that nobody expects: the prod → dev replicator is wired only in the production deployment, so it had been dormant for a month. On the first real user it woke up and began mirroring masked writes into dev — exactly as designed, and still slightly startling to watch.

Only after both listings existed did the website's store badges become real links; they'd shipped as disabled placeholders until then, per a note in the repo's own instructions — "until the listings exist."

After: the cadence

v1.0.1 was live on 27 August. Since then: 1.0.2 (the receipt-linking schema), 1.0.3 (stored sessions survive a failed token refresh; dismissed announcements survive sign-out), and 1.0.4 (save a receipt from Expenses and link it on the full page) is built and heading to the stores. Each one runs the same pre-build checklist, the same npm ci --dry-run, the same staged rollout. The runbook didn't retire at launch; it became the release process.

What I took away

Start the slowest external clock first. Twelve testers for fourteen days is the launch date; everything else fits inside it.
Buy the domain early. It gates privacy forms, which gate every store track, which gate the testers.
Rank blockers by rejection probability, not by how annoying they are to fix. Deletion, deliverability, disclosure.
Hunt the silent fallback. The scariest bug in a release is the one that produces a working build pointed at the wrong world.
Permissions are graded UX. No "Allow" buttons, no "Not now" — the OS dialog, in context, immediately.
Approved ≠ released. Manual release, phased rollout, and sleep.

Next up

Part 31: the backend moved to a fresh AWS account mid-flight — and the env-scoped naming convention from the earliest days of the series is what let a staged table rename deploy clean.

What was the non-code thing that actually decided your launch date? I'd bet it wasn't in your roadmap either.

Scan now, link later: receipts that wait for the list

Ibukun Demehin — Sun, 06 Sep 2026 18:35:55 +0000

Receipt scanning worked, and it felt like homework. You'd come home with the receipt, open the Expenses tab, scan — and the app would immediately want a decision: review every line, confirm every match against the list, log it. If you were unpacking shopping with one hand, the honest answer was "not now" — and "not now" meant the receipt never got scanned at all.

The fix inverted the order of operations: save the receipt first, ask questions later. It sounds like a UI tweak. It turned into a small data-model design with one immutability rule to protect.

TL;DR — A receipt button on the Shopping tab saves the receipt before asking "Link now / Later." Receipt.reconciledAt === null means pending, which drives a strip and badge on the list. Lines are stored with provisional match ids and addedToList: false, so an unlinked receipt's money shows as the Expenses off-list caption, never the headline. Linking re-verifies every match against the list as it is *then* (a hand-ticked item degrades to "still to buy," never a double tick), applies ticks with the receipt's printed date, enriches the snapshot once, and stamps reconciledAt. Matching became model-first with a conservative fallback ladder — and deliberately no edit distance.

(Part 29 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The order of operations was the bug

The original flow coupled two jobs that don't want to be coupled: recording the receipt (a fact about the world — you bought these things for this much) and reconciling it with the shopping list (ticking items, applying prices, adding the strays). Recording takes a photo. Reconciling takes attention. Forcing them into one sitting made the cheap one hostage to the expensive one.

So the Shopping tab grew a receipt button (next to History): photograph → parsed → saved immediately → then a two-button question: Link now or Later. Later is a real answer. The receipt exists either way.

`reconciledAt: null` is a state, not an absence

The whole feature hangs on one nullable timestamp. A receipt with reconciledAt === null is pending: the list shows a strip ("1 receipt waiting to be linked") and a badge on the receipt button. Linking stamps the timestamp. Dismissing the strip stamps it too — with no links — so "I'll never link this one" is also a first-class outcome rather than a permanent nag.

Receipts scanned from the Expenses tab are born linked: the review sheet's primary button records and reconciles in one go, exactly as before. Nothing changed for the people who liked the old flow; a second, cheaper door opened for everyone else.

Provisional matches, and money that stays out of the headline

A pending receipt's lines are stored with provisional match ids (the parser's best guess at which list item each line corresponds to) and addedToList: false on every line. That second flag is what keeps the money honest. Part 19 established the rule: the Expenses headline sums the purchase ledger — items actually bought through a list — and receipt lines that never touched a list are a separate caption. An unlinked receipt is precisely that: real spending, not yet attributed to any list or budget. So its money shows in the caption and never in the headline, until linking moves the lines into the ledger. No double counting is possible, because a line is either in the ledger (linked) or in the caption (pending) — never both.

Linking re-verifies against the list as it is then

Here's the part that makes "later" safe. Time passes between scan and link. The list changes: you tick things by hand, delete something, add more. A provisional match made at scan time might point at an item that's since been ticked, removed, or claimed by another line.

So the link page trusts nothing provisional. It re-verifies every match against the list as it exists at link time: the item must exist, be unchecked, and be unclaimed by any other line. The important degradation rule: an item you've already ticked by hand degrades to "still to buy" for that line — it is never double-ticked. A receipt arriving late must not rewrite what your hands already did.

Then the ticks are applied with the receipt's printed purchase date (the same midday-local stamping as Part 18's ledger), so a receipt linked on Friday for a shop on Tuesday lands in Tuesday's week.

The one-time enrichment, and the immutability rule

Part 14 made a promise: the receipt's line snapshot is immutable — a record of what was read, independent of the live items that keep changing. Linking looks like it violates that: it writes match ids and addedToList back into the lines.

The resolution is a rule with a boundary: enrichment happens exactly once, at the moment reconciledAt is stamped, and never again. Before linking, the snapshot is "what the parser read plus provisional guesses"; after linking, it's "what the parser read plus what actually happened." The record graduates from provisional to final one time and then freezes. A snapshot that can be enriched once, at a known transition, is still a snapshot; one that can be edited whenever is a mutable table wearing a costume.

Matching: model-first, fallback ladder, no edit distance

The reconciliation also changed how lines find their items. The parse mutation now takes the list's unchecked {id, name} candidates as an optional argument and returns a matchId per line — told, as always, to prefer null over a guess. The client re-verifies every id (exists, unchecked, unclaimed), then falls back to a conservative ladder for the rest: barcode → exact normalised name → token containment. Deliberately no edit-distance matching: fuzzy string similarity is how "Cream" matches "Ice cream" and a wrong tick lands on a real purchase. A conservative matcher that leaves a line unmatched costs one tap; a clever one that mismatches costs trust.

And a UX lesson paid for in full: the first version let you correct a match from a picker sheet stacked on top of the review sheet. A picker over a sheet broke the flow — two modal layers, two dismiss gestures, and confusion about which one you were in. Matches now render as read-only text in the review sheet, and all corrections live on the link page, which became the one correction surface: three entry points, one-to-one claims, and picking a new item visibly un-claims the previous one. One place to fix things beats a fix-it affordance on every surface.

The link page itself moved into a shared component mounted as thin routes in both the Shopping and Expenses stacks — the Part 14 pattern again — so opening it from Expenses no longer jumps you to a different tab.

What I took away

Decouple recording from reconciling. The photo is cheap; the decisions are expensive. Never make the cheap step wait for the expensive one.
A nullable timestamp is a state machine. reconciledAt: null drove a strip, a badge, a caption rule and a dismissal path — one field.
Provisional data must stay out of totals until it's verified — the addedToList flag is the honesty gate.
Re-verify against the present. Anything decided at scan time is a guess by link time; your hands' work wins.
Enrich once, then freeze. Immutability with a single known transition is still immutability.
No edit distance in money matching. Conservative matchers cost taps; fuzzy ones cost trust.
One correction surface. A picker over a sheet was two too many layers.

Next up

Part 30 is the one this whole series has been building toward: shipping to both stores — the runbook, the credentials, the privacy declarations, the review rejection, and what v1.0.1 through v1.0.4 taught about releasing as one person.

Where in your app does a cheap action get held hostage by an expensive decision — and what would "save first, ask later" look like there?

Branded Cognito emails: the customMessage trigger in 20 minutes

Ibukun Demehin — Sun, 06 Sep 2026 18:33:40 +0000

Cognito's default emails are a small embarrassment: plain text, no name, a bare code — the kind of message a security-aware user treats as a phishing test. For a shopping app trying to look like something you'd trust with your receipts, that's the first impression at sign-up.

The fix is a single Lambda on the user pool's customMessage trigger. The wiring is twenty minutes. The interesting parts are the three ways it silently fails, and the one line that keeps the deploy from tying itself in a knot.

TL;DR — Define a customMessage trigger function with resourceGroupName: "auth" so it deploys inside the auth stack — a trigger living in the shared function stack is an auth ↔ function circular dependency. In the handler, the code parameter must appear in the body or Cognito rejects the message and sends nothing. Write email HTML like it's 2009 — tables, inline styles, no webfonts (your brand font can't ride along; the colours carry the brand). And on the invite trigger, codeParameter isn't a code, it's the temporary password, and the username parameter must appear too.

(Part 28 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The one line that matters in the definition

// resourceGroupName keeps it in the auth stack — a trigger living in the
// shared function stack would be an auth↔function circular dependency.
export const customMessage = defineFunction({
  name: "custom-message",
  entry: "./handler.ts",
  resourceGroupName: "auth",
});

By default, functions deploy into a shared function stack. But a Cognito trigger is referenced by the user pool (auth → function) while also needing the pool's context — and in a backend where the function stack already depends on auth for other reasons, that reference points the dependency arrow both ways. resourceGroupName: "auth" places the Lambda inside the auth stack, so the pool and its trigger are siblings and no cross-stack arrow exists. Same lesson as Part 25's stream wiring and Part 14's IAM policy: in a multi-stack backend, where a resource is declared is a dependency-direction decision.

Three ways it silently sends nothing

The handler's own docstring is the checklist:

/**
 * Branded Cognito emails — verification + password reset. Cognito injects the
 * code as `event.request.codeParameter`; the body MUST contain it or Cognito
 * rejects the message and nothing is sent.
 *
 * HTML email rules apply: tables + inline styles only (Outlook), no webfonts —
 * Nunito can't ride along, so the system stack stands in and the brand is
 * carried by the colours.
 *
 * AdminCreateUser IS handled … Careful: on that trigger `codeParameter` is
 * the TEMPORARY PASSWORD, not a code, and `usernameParameter` is the email to
 * sign in with. Both must appear in the body or Cognito refuses to send.
 */

1. The code placeholder must be in the body. Cognito hands you event.request.codeParameter — a placeholder token it substitutes after your handler returns. Build a beautiful template that forgets to include it, and Cognito doesn't send an ugly email; it sends no email, with no error surfaced to the user. Test every trigger type by actually receiving the message.

2. Email HTML is not web HTML. Tables for layout, every style inline, no external stylesheets — Outlook still lives in the past. And no webfonts: the app's brand font can't come along, so the template uses the system font stack and lets the colours — the teal header, the mint code panel — carry the brand identity. A responsive @media block in a <style> tag is the one modern concession most clients honour.

3. The invite trigger lies about its parameter names. The same handler serves AdminCreateUser (the admin console's "Invite an admin"). On that trigger, codeParameter is not a code — it's the temporary password — and usernameParameter is the email to sign in with. Both must appear in the body, or Cognito refuses to send. The template branches on triggerSource and uses different copy and different placeholders for the invite.

What "branded" means here

One template shell: a teal header with the wordmark, a mint panel with the six-digit code in large spaced digits (30px, 6px letter-spacing on mobile — a code you can read from across the room), a short line of what to do, and a muted footer. The verification and reset emails share the shell and differ in copy; the invite reuses it with the temporary-password panel. Every colour is the design system's email-safe subset — six hex values copied from the shared tokens file, never a gradient (Outlook again).

The template later grew a second dimension — every one of these emails now arrives in the user's own language, flipped to right-to-left for Arabic — but that's a later part's story, because it came with a war story about Cognito's frozen attribute schema.

What I took away

resourceGroupName: "auth" — the trigger belongs beside the pool, not in the function stack.
Include the placeholder or nothing sends. Cognito fails closed and quiet; verify by receiving.
Write email HTML for Outlook — tables, inline styles, system fonts, colours as the brand.
Invite trigger: codeParameter is the temporary password, and the username must appear too.
Test all three trigger types (sign-up, forgot-password, admin invite) with a real inbox before calling it done.

Next up

Part 29 goes back to receipts and fixes the thing that made scanning feel like homework: scan now, link later — the receipt is saved before the app asks which list it belongs to.

What's the worst default email your platform sends on your behalf — and have you checked it recently?

DEV Community: Ibukun Demehin

Polish pass #3: store-release edges and platform traps

Android's fourth button doesn't exist

The one prop that hides the keyboard trap

HTTP 431 from cookies

"There is already a signed in user"

Brand and pack size, and the unit that isn't

Four small ones

What I took away

The series, at 39

MUI vs Tailwind: the cascade-layers war story

How the coexistence is supposed to work

Breakage #1: StyledEngineProvider injectFirst

Breakage #2: prepend: true

Why it hid for so long

The mental model that would have prevented both

What I took away

Next up

The admin console: a web app on a mobile app's Cognito pool

The front door: a valid session proves nothing

The screens, and the decision in each

One defaults object for every table (and the dark-mode fix inside it)

Forms get routes; labels sit above fields

What I took away

Next up

The activity log: what users did, without their words

Rule 1: no user text, ever

Rule 2: one row per action, never per write

Rule 3: what is deliberately not logged

The logger never throws and is never awaited

The repo's first GSIs — and the screen that must not listAll

What I took away

Next up

In-app announcements: talking to users after the build shipped

Severity picks the shape; kind picks the words

Target the version people are running

The force-update wall fails open — by construction

Seen state: per user, loaded in the right place

What device testing found

Small conventions that rode along

What I took away

Next up

Emails in the user's language, and the frozen Cognito pool

The attribute is a mirror, not a source of truth

The read side: whitelist, never echo

The email that stays English on purpose

The extended tier came free

The war story: a schema that can't change

What I took away

Next up

The app speaks 19 languages: tiered i18n and the AI translation pipeline

Four pillars, all cloned from patterns the app already had

Per-user, not per-device — the shared-phone argument

Arabic: the RTL flip, and a font trick I'm proud of

Two tiers, and a pipeline whose limiter is review

What's deliberately not translated (yet)

What I took away

Next up

Account deletion for real: immediate, guest round-trip, admin-initiated

Lane 1: in-app, immediate — and the order is the design

Lane 2: the guest round-trip that can't leak

Lane 3: admin-initiated, without rewriting history

The legal copy had to get honest too

What I took away

Next up

Moving a live backend to a fresh AWS account

The migration that didn't need to happen

What can't move: the users

What must change: every client build

The mechanics that made it boring

The two things that bit

What I took away

Next up

Shipping to both stores: the release runbook

The two things that decided the date (neither was code)

The code blockers, ranked by rejection probability

The highest-consequence silent failure

The rejection that came anyway

Approved is not released

After: the cadence

Breakage #1: `StyledEngineProvider injectFirst`

Breakage #2: `prepend: true`

The repo's first GSIs — and the screen that must not `listAll`

`reconciledAt: null` is a state, not an absence