mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 04:32:42 +00:00
Marc-André Bombeck
43361bd74e
With signals of the day resting on today's readings only, the briefing had to be written after those readings, and it was only written at the 04:30 Berlin warm, the post-sleep morning refresh, or a page open on a day-old cache. A morning blood pressure or weigh-in never became a signal, and since an earlier day's briefing is no longer served, a reader in Los Angeles or Seoul had none for most of the day: the Berlin warm lands the previous evening there, or at noon. The snapshot read every surface goes through (dashboard, iOS, digest, morning push) now asks for a briefing for today at two moments: the first read of the reader's local day with no briefing written today, and the first read after a signal metric's first reading of the day that the briefing has not read. Each reason is claimed once per user per local day in a Postgres bucket and remembered in-process, so later reads cost no query; no write path needs a hook. A claim enqueues one today warm: immediately for a new day, after a five-minute window for readings, so a burst (weigh-in, then blood pressure) folds into one job. The warm writes the comprehensive briefing only, past the one-hour freshness gate but under the failure backoff, the daily forced-warm cap (two per 24 h) and the content-hash gate. Worst case per user per local day: one enqueue per reason, at most eight (the day plus seven signal reading types, measured over a day of reads every two minutes); at most two forced comprehensive attempts under the existing cap, each at most three completions (the answer, a JSON retry, a grounding retry), so six provider calls at the ceiling. A warm whose data has not changed costs at most the existing once-a-day paragraph re-roll, inside the same cap.
src/
Application source. HealthLog is a Next.js 16 App Router project (output: "standalone", React 19, TypeScript strict). The path alias @/* resolves to this directory. Everything a request touches lives under here; the layout below follows the request flow rather than alphabetical order.
Request flow
client → src/proxy.ts → src/app/<route>/route.ts → src/lib/api-handler.ts → handler body → src/lib/api-response.ts → client
proxy.ts— the HTTP edge (Next.js 16's renamedmiddleware). Public-path allowlist, demo-mode mutation block, server-side onboarding redirect, worker-only refusal,x-request-id+ CSP nonce generation, every security header.app/— App Router pages (RSC by default) and API routes. Every API route wraps its handler inapiHandler. Seeapp/README.md.lib/— the server/runtime toolkit:apiHandler, auth, crypto, rollups, AI, notifications, pg-boss jobs, integrations, rate limiting. Seelib/README.md.components/— React components (shadcn/ui new-york, kebab-case files). Seecomponents/README.md.
Other directories
hooks/— shared React hooks (use-prefix, kebab-case).types/— shared TypeScript declarations.generated/prisma/— the generated Prisma client (do not edit; regenerated byprisma generate). Imported as@/generated/prisma.instrumentation.ts— Next.js startup hook; boots the pg-boss worker registry and boot-time backfill queues.__tests__/— cross-cutting unit tests; most tests live in__tests__/folders next to the code they cover.
Conventions
See ../CLAUDE.md for the full set. The load-bearing ones: RSC by default ("use client" only when a hook/state/browser API needs it); every API route wraps apiHandler and parses its body with Zod safeParse; userId is always narrowed from session or Bearer, never accepted as a body field; TanStack Query keys come only from src/lib/query-keys/; outbound HTTP goes through src/lib/safe-fetch.ts.