sip

Encoded the handoff's token table once in tailwind.config.js — colors, radii, font families — so screens never hardcode a hex value, and defined the three named shadow recipes (button, card, hero) as RN style objects since Tailwind's shadow-* doesn't translate reliably across platforms. units.ts and date.ts became the single source of truth for anything printed on screen — every amount goes through formatAmount, never inline ml→L/oz arithmetic in a component. The store holds only goalMl, unit, onboarded, and today's entries; intake is derived from entries via a selector rather than stored, so the two can't drift. WaterCircle and Waves carry the one genuinely fiddly bit — a Reanimated fill plus two looping SVG sine paths — and it worked on the first try.

Added docs/plans/2026-08-21-mobile-v1.md: the plan as agreed before writing any code, followed by an Outcome section covering the SDK downgrade and the PressableScale bug above, and the gaps still open — onboarding is unreachable once onboarded is true and there's no Settings screen to change the daily goal afterward despite the onboarding copy promising you can, Home's settings button is wired to the paywall as a placeholder, and Stats/Profile are inert tab stubs. Settings screens are next.

The flow's shape drove the routing. app/onboarding.tsx became app/onboarding/index.tsx so the existing segments[0] === 'onboarding' guard kept working untouched; only sign-in needed the guard edited, because it sits outside onboarding/ and has to be reachable both before onboarding and long after it. Anything already on screen twice got extracted instead of duplicated — BrandMark, UnitToggle, GoalStepper, and the entire Sip+ body as PlusOffer, which the paywall modal and onboarding step 3 now share behind one variant prop. The alternative was two near-identical copy sets drifting apart forever.

Two things the plan hadn't named surfaced during the build. router.back() from sign-in lands back on the paywall, so someone who just subscribed gets shown the upsell again — router.dismissTo('/settings') closes both. And extracting GoalStepper fixed a live bug: the prototype gives the value block a min-width of 156, the shipped v1 screen didn't, so switching units shifted the ± buttons sideways. Both sizes carry it now.

The big goal number was clipped. GoalStepper set lineHeight equal to fontSize to reproduce the prototype's line-height: 1. CSS paints glyphs outside the line box, so a browser renders the number whole; React Native clips to the line box and shaved the top off the tall digits. The line box now carries 25% headroom, and the sub-line's marginTop subtracts the resulting half-leading so the drawn gap stays on spec. A sweep confirmed GoalStepper was the only place where lineHeight === fontSize.

Sixteen reanimated warnings per session came from a SIZES key named value — reanimated's babel plugin statically flags any .value read inside a JSX style prop as a misused shared value. A false positive, but it was our naming, so the key is amount now.

Also added, unplanned: a __DEV__-only long-press on Settings' "Sip · v1.0" that replays onboarding. onboarded is persisted and survives reloads, Fast Refresh and force-quits, so the only way back into the flow was wiping Expo Go's entire storage.

docs/plans/2026-08-22-onboarding-settings.md keeps the plan verbatim plus what actually happened. The assumptions to verify first section earned its place immediately: one assumption took two minutes, and another was settled by a single grep of a dependency's source — better than the device screenshot the plan had asked for.

But the plan also sequenced two device checkpoints it had no way to enforce, writing them as gates to clear before any screen was built when the implementer — no phone, no Mac — could run neither. A checkpoint the implementer cannot execute is a handoff; the honest fix is to name it as one at planning time and decide explicitly whether the work blocks on it, rather than writing a firmer instruction.

The other lesson: "verify on device" is too coarse. The useful split is read the runtime log (free, instant, and it caught two of the three defects), look at the screens (caught the clipped number), and wait out real time (the notification behaviour). The plan bundled all three into a single checkbox, so the nearly-free ones never got scheduled early. Agreed as next, in order: a History page — the Stats tab is still an inert stub, and entries only keeps today, so it needs a persisted per-day log before any chart can exist — then more Settings, then real subscriptions and login.

Expo Go on SDK 54 does deliver scheduled local notifications on iOS, confirmed on my own phone, so screen 2c's promise holds without a development build. The docs said so all along — but yesterday's SDK ceiling is exactly why a doc claim about Expo Go isn't enough on its own, and only observation settled it.

iOS passing does not carry Android. Android has two failure modes iOS doesn't: a notification posted without a channel is dropped from API 26, and API 33+ gates delivery behind the POST_NOTIFICATIONS runtime permission. ensureAndroidChannel() runs at app start and requestPermissionsAsync() covers the permission, but neither has been observed working on a real Android device — the one Android phone in the session never got past a network error.

Still not isolated on either platform: that the body renders the personalised copy rather than the empty-name fallback, that nothing arrives outside the waking window, and that toggling the switch repeatedly leaves exactly one set of triggers. syncReminders cancels before scheduling precisely to make the last one true, but nobody has counted pending triggers to prove it.

The plan's web verification step read "all five routes reachable, no console errors". Doing exactly that returned HTTP 200 for twelve routes and proved nothing — expo-router serves one SPA shell for every path, and every route had silently redirected to onboarding because onboarded was false. "Reachable" is not a check; "rendered the right thing" is. The pass that found things drove a real browser at the mockup's 402×874, walked the onboarding flow, seeded localStorage['sip-store'] with a realistic week, then asserted on rendered text and on what came back out of the store.

syncReminders threw on web: cancelAllScheduledNotificationsAsync is "not available on web" and raises rather than no-opping, so every interval tap produced an unhandled rejection. It returns early off native now — while the permission calls deliberately do not, since the browser's own Notification API backs them and guarding those too left the whole Reminders screen permanently dimmed for no gain.

The Reminders master switch also disagreed with its own screen. With permission denied it rendered off (enabled && permitted) while the sections below stayed undimmed, because the dimming keyed off enabled alone. One active constant now feeds the switch, the dimming, the pointerEvents and the "next nudge" line.

One thing the plan never anticipated: formatAmount was the wrong formatter for a drink. formatAmount(400, 'metric') is "0.4 L", but the handoff writes every drink in millilitres — so formatDrink joined units.ts, and quick-add's custom amount now honours the unit preference where it previously did not.

docs/plans/README.md gained a Lessons that outlived their plan section — a plan's own retrospective says what that plan got wrong, but the recurring ones are the set worth reading before writing the next one.

Close assumptions by reading, not by scheduling a device check. Three chunks running, the verify first section has been the cheapest part of the plan and has never once been where things broke: a version pin in bundledNativeModules.json, a line in zustand/middleware.js, a prop in a .d.ts. Reading tells you why, and the why transfers; hardware only tells you whether. Reserve device checkpoints for genuinely native claims — is the module in the Expo Go binary, what does the keyboard do — and name them as handoffs.

The risks you name get designed around; what bites is the seam you didn't know existed. Every risk list so far has been accurate and largely inert, because writing a risk down is most of the work of avoiding it. The real defects came from elsewhere — a persist.version bump reasoned safe in prose, cancelAllScheduledNotificationsAsync throwing instead of no-opping, a switch whose dimming disagreed with itself. The lesson is not "write a better risk list"; it is to schedule the cheap rendering pass that finds what was never on it.

Write the one assertion that can only pass for the right reason. "The tab bar is fixed" became the same DOM node, top=818 on five screens. "The onboarding header is static" became the same node at {30,26} across four steps. Everything else in a suite is supporting evidence.

The index was corrected too. The tab bar work was confirmed on device; the two things still genuinely unverified are the platform time picker inside Expo Go — which gates three screens — and the name step's keyboard behaviour, which today's restructure moved from a padded root KeyboardAvoidingView to a nested child. Next, in order: that device pass, a per-day goal snapshot so the week chart stops recolouring history, Month view, then subscription and login for real.

AGENTS.md gained an Agent skills block pointing at three files. Issues are GitHub Issues on pdrmdrs/sip, driven through the gh CLI, with external PRs kept out of the triage queue. Triage keeps the five canonical labels unchanged. Domain docs are single-context — a root CONTEXT.md and docs/adr/, neither of which exists yet, which the rules say to pass over silently rather than scaffold upfront.

One departure from the seed template: docs/plans/ joins the read-before-exploring list. A skill that skips it re-argues decisions this repo already settled and wrote down — which is the entire reason the plans live in the repo instead of in a chat log.

The block lands in AGENTS.md rather than CLAUDE.md, since the latter is one @AGENTS.md line and everything reaches Claude through it anyway.

src/components/PlusOffer.tsx:10-52 is rendered by both /paywall and onboarding step 3, and it sells three rows. Sync everywhere is cut from this chunk and undecided as a feature at all. Reminders that find you describes a local notification that the free tier already has. Focus lock needs FamilyControls, a dev build and a per-bundle-ID Apple entitlement — it cannot ship on the current runtime, ever.

So the copy pass ships in the same commits as the code, not after it. The FEATURES array is rewritten, Settings' "Sync across devices" row has to become something true, Account's privacy alert — "Sip keeps everything on this device. Nothing is uploaded, and there is no account unless you start Sip+" — stops being accurate the moment a payment record exists, and delete-account.tsx's "Cancel in the App Store / Play Store" line is simply wrong for a web subscription. Nothing may advertise unlimited history without the words on this device.

This chunk makes the paywall real. It does not make it worth buying. After it lands, the paid tier is skipWhenAhead plus unlimited on-device history, and the features that justify a price — Month view, streaks, averages, export, themes, custom containers, per-day goals — are a chunk of comparable size that is not this one. The consequence is a sequencing rule rather than a scope change: do not submit to the App Store between this chunk and the paid-features chunk. Shipping the gate before there is anything behind it is the right order; a live paywall charging $2.99 for a reminder toggle is the failure mode that order creates, and simply not submitting yet avoids it.

Two smaller things went with the redraft. expo-secure-store is retired in favour of the AsyncStorage already backing persist — deleting an assumption and a ~2048-byte silent-truncation risk that would have shown up as "signed out at random". And the SDK 54 pin is reworded as a development constraint rather than architecture: Expo Go is a dev client, not a distribution channel, so the pin dies the day the $99 is paid, and every paid feature past launch needs it gone.

One verification note carried forward, because it is now the third plan running where a structural change quietly invalidates how things get checked. The browser suite has only ever needed localStorage['sip-store']; it now needs a live second Supabase project, and the existing "sign in → Settings reads Sip+ active" assertion would still pass while proving the opposite of what it claims. It gets rewritten, not reused.