Skip to main content

Remaining work — checkpoint at loop stop (2026-07-03 ~14:10)

Status: Session loop stopped by owner after documenting. This file is the single resume point; the blow-by-blow ledger is .superpowers/sdd/progress.md (gitignored, same repo). Repo tip at write time: 5f34443 (= origin/main = feat tip).

0. IN FLIGHT right now (may complete after this session)

P1 onboarding-loop fix S1 — an implementer agent was building when the loop stopped. It commits but does NOT push. On resume: check git log --oneline -3 and .superpowers/sdd/onboarding-loop-s1-report.md first. If the commit exists, run the review (economy-grade, plan at .superpowers/sdd/onboarding-loop-plan.md), then push + deploy. If absent, re-dispatch from that plan file.

  • Root cause (proven, three compounding defects — full detail in the plan file):
    1. No cloud "member for this auth user" bootstrap on session restore; the AuthenticatedGuard just tests getHousehold() == null (authenticated_guard.dart:52-72).
    2. getHousehold = unscoped .limit(1).maybeSingle() (supabase_households.dart:14-17).
    3. CachedStorageAdapter._hydration ??= memoizes a PRE-AUTH empty read — the unconditional initState tempBonus sweep (builder.dart:203) fires before the JWT attaches → RLS returns 0 rows → cache frozen empty; deterministic on every load.
  • Fix shape: memberForAccount(authUserId) + bootstrapSession (cloud-as-truth), hydration never latches empty/unauthenticated results, guard routes to Setup ONLY on confirmed no-member (network error ≠ no-member — the duplicate-creation guard), sweep gated on auth. Regression tests incl. network-error → NO createHousehold.

1. UAT bugs open

  • Parent goal-add "doesn't work" — believed to be the SAME P1 root cause (all four layers verified permissive: UI button unconditional, bloc consent gate child-only, SDK createGoal has no adult block, assert_child_goal_consent trigger is child-scoped; Postgres logs show the insert NEVER arrived → client died pre-network on the poisoned/stale session, which was additionally bound to a now-deleted shell household). Retest with a fresh login after the fix deploys. If it still fails on a healthy session, treat as a distinct bug and diagnose separately.

2. G-2 account switcher — nearly closed

  • ✅ S1 substrate (adfa53c), S2 switcher UI (263919b+28fd4d1), S3 catalog rewire (f2518be) — all reviewed clean, pushed, DEPLOYED.
  • S4 (5f34443) committed + reviewed, pushed to main, NOT yet deployed — must-fix wave queued before deploy:
    • HIGH: tappable "Viewing as {name}" label (account_switcher_chip.dart:104-122) lacks Semantics(button:) + 48px target (siblings do it right — copy them).
    • MEDIUM: label color teal likely fails WCAG AA as small light-theme text — pick an AA-passing DS token.
    • MEDIUM: tap→MemberProfileRoute navigation has zero test coverage.
    • LOW: static invariant guard misses selected_member_store/barrel import vectors — extend cheaply.
    • The invariant-lock itself (G-2's exit gate) was verified genuinely falsifiable and green (405/126/0 independent). Fix → re-review → deploy.
  • S5 (docs) not started — last G-2 slice per .superpowers/sdd/g2-plan.md: ADR + architecture-page updates + graphify. Closes G-2 AND the G-board.
  • Decided en route (FYI, revisit in UAT if it feels wrong): a watchOnly viewer defaults to viewing SELF (old catalog rule would have picked an unselectable subject post-switcher); watchOnly subject is inert (eligibility + service authz deny).

3. H-phase (after G-board closes) — spec'd in docs/decisions/2026-07-02-h-phase-enhancements.md

H-1 subtask icons+visibility (POC-style) · H-2 member-role chore recommend/request (request→approve lifecycle) · H-3 self-only step customization · H-4 print review (rooms + steps missing) · H-5 Today rework on the G-2 switcher (parent=master, member=tailored, approvals hidden unless helper; consumes the deferred lens-vs-subject question) · H-6 IA restructure (Earn tab = chores+bounties, Rewards tab = activities+rewards, catalog page removed, admin-only editing + deep links; extract SpendGatesRepository).

4. Launch checklist (tracked, pre-launch) — docs/decisions/2026-07-02-mvp1-launch-checklist.md

Supabase dashboard: Site URL + redirect allowlist, "Secure email change" ON, leaked-password protection · COPPA HARD-1 (child financial-PII gate) + HARD-2 (consent re-capture on version bump) before real minor data · DF-1 helper RLS widening (+ ledger self-move widening) · co-parent accept-invite email/deep-link leg · 2 pre-existing full_stack_test failures (demo 3-vs-2 kids; updateReward captureConsent) · reference-env golden regeneration · ⚖️ counsel items.

5. Small carried debts

  • Repo-wide dart format normalization (pinned Dart 3.12 "tall style" vs committed style) — dedicated commit, never inside a feature slice.
  • design_system golden failure artifacts on Windows (Linux-generated goldens) — regenerate on the reference env; do not chase locally.
  • graphify graph refresh commit (graph.json/GRAPH_REPORT.md staleness vs the never-stage-mid-slice session rule).
  • Flow-harness Stream.empty() selected-member default diverges from prod (documented at test_app_builder.dart:236; mitigated by real-repo integration tests).
  • Goldens for the switcher at 320/768/1024/1440 breakpoints (S2 carried minor).
  • .superpowers/sdd/g1-s3-report.md stale numbers above the corrected appendix (cosmetic; gitignored file).

6. Live-environment state (verified at write time)

  • App https://home.eldr-labs.duckdns.org/rewhaven/ → 200, build = f2518be (G-2 S3). S4 + onboarding fix NOT yet deployed.
  • Supabase (bgedvvmihygwxhjxlvfu): 10 live migrations (latest goal_envelope); exactly ONE household — "Ellenberger" 985566a0-… (2026-06-27: 4 members / 4 chores / 20 ledger / 3 goals / 14 rooms, owner account linked). The 5 loop-created shells were deleted 2026-07-03 with owner approval (consent_ref nulled → consents → households, single transaction).
  • Suites (independently verified): app 405 pass / 126 skip / 0 fail at 5f34443; SDK 851 pass. Drift schemaVersion 21.
  • Git: on resume trust git log over this line — the in-flight agent may have committed after this file was written.
  1. Check in-flight fix agent result (§0) → review → S4 a11y fix wave (§2) → re-reviews.
  2. Push everything green + ONE deploy (bootstrap fix + S4).
  3. Owner retests: fresh login lands in "Ellenberger"; refresh persists; parent goal-add works.
  4. G-2 S5 docs → G-board CLOSED.
  5. H-phase kickoff (H-1, H-6 largest; H-5 depends on G-2 — now satisfied).