Pre-phase-4b these sections were cards on the long monolithic /admin
scroll, where the expand-to-reveal kept 100+ table rows from
dominating the overview. Post-phase-4b they each own a dedicated
route reachable via the sidebar / mobile strip — the user has already
opted into the topic by navigating there. Landing on a card with only
a header and an "Expand" button reads as "is this page broken?".
Default `expanded = true`; the toggle stays as an escape hatch.
Closes H3 from .planning/phase-6-design-findings.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The four per-row action buttons on `/admin/users` (role toggle, edit,
reset password, force-logout) and the filter pills on both routes
were sized `h-7` (28px) — well below WCAG 2.5.5 AA's 44×44px target
that the rest of the app already honours (bottom-nav, dashboard
quick-add). Mobile users on a 360px viewport had four 28×28px buttons
crammed into the right edge of every user row.
Adds `min-h-11 min-w-11` to all six button sites. The visual icon-only
look is preserved — only the hit-area expands.
Closes H2 from .planning/phase-6-design-findings.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 4b's `<SectionFrame>` already paints the canonical h1 + subtitle
for each `/admin/<slug>` route, but every section card kept its v1.4
in-card h2 with the same (or near-same) text. The result was the
section title announcing twice — once as h1, then immediately again as
h2 — both visually redundant and a screen-reader landmark anti-pattern.
Demoting the in-card label to a `<div>` preserves the visual look
(same Tailwind classes) while removing the duplicate heading. The
four sub-cards inside `IntegrationsGroupSection` (umami, glitchtip,
web-push, bug-report) keep their h2 because they live under the
"Integrations" h1 and genuinely deserve a heading level — that is the
non-duplicating case.
Closes H1 from .planning/phase-6-design-findings.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Bearer rule already covers `Authorization: Bearer hlk_…` headers,
but standalone tokens in error bodies, JSON dumps, or raw debug
strings were untouched. The idempotency replay-cache rejects bodies
containing `hlk_` / `hlr_` (CLAUDE.md headless-client-API patterns)
exactly so cached responses can never echo a token back; this commit
adds the matching egress guard for log/error surfaces.
Boundary-aware shape mirrors the v1.5 phase-2 sk- regex tightening so
benign identifiers like `html_render` or short `hlk_short` strings are
not over-matched.
Closes H4 from .planning/phase-6-code-review-findings.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
pg-boss does not deduplicate by payload, so each click on the manual
"Backup now" button enqueues a fresh data-backup job. Without a
rate-limit, an impatient admin (or compromised admin session via XSS
or token theft) can stack dozens of identical fan-out-per-user jobs
on the queue.
Three runs per minute per admin is plenty for ad-hoc snapshots — the
weekly cron in `reminder-worker` already carries the regular cadence.
Closes H3 from .planning/phase-6-code-review-findings.md (also addresses
M-1 from .planning/phase-6-security-findings.md).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The UI already disabled the per-row force-logout button for the active
admin (user-management-section.tsx:295), but the route handler had no
matching server-side check. A direct curl/DevTools call (or a
compromised admin session) could revoke the caller's own sessions and
bounce them to /auth/login mid-action.
Mirrors the UI gate with a 422 + an `admin.user.force-logout.denied`
audit entry tagged `reason: self_target`. Admin-on-admin force-logout
remains permitted (today's intentional behaviour).
Closes H1 from .planning/phase-6-code-review-findings.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drops dead `id` props and `scroll-mt-28` classes from admin section
components (load-bearing in v1.4 monolithic admin, dead since the v1.5
phase-4b dynamic-route split). Also removes the unused
`LEGACY_ANCHOR_TO_SLUG` map, the `admin-shell` re-export shim, the
`BERLIN_TZ` and duplicate `MS_PER_DAY` constants, the verbose
`AdminSectionPage` docstring, the `useEffect` paraphrase comment in
`ai-section`, and rewrites the `_exhaustive: never` exhaustiveness
guard to the modern `slug satisfies never` form. `UserManagementSection`
now reads `currentUserId` via `useAuth()` instead of accepting it as a
prop.
Findings 1, 2, 3, 4, 6, 7, 8, 11, 15, 16, 17 from
.planning/phase-6-simplify-findings.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wrap the section quick-jump list under `/admin` in a `<nav>` with
`aria-labelledby` pointing at its heading. Without the landmark,
screen-reader users navigating by region heard "list of links" with no
contextual label distinguishing it from the sidebar nav (which already
carries its own `aria-label`).
The `<h2>` keeps its existing copy ("Sections") and now serves as the
nav's accessible name via `aria-labelledby`. Visual is identical.
Picked up from the v1.5 phase-5 friction audit (item #10) — small fix,
clear win, no scope creep.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase-3 e2e suite documented an i18n collision: the dashboard's
quick-entry dropdown trigger says "Add" and both menu items underneath
also rendered the bare verb "Add" because `measurements.addMeasurement`
and `mood.addEntry` both translate to "Add". Screen-reader users heard
two indistinguishable rows; the e2e spec was forced to use
`getByRole("menuitem").first()` as a workaround.
The dropdown trigger already says "Add" — the menu items label what's
being added.
- Add `dashboard.quickAddMeasurement` ("Measurement" / "Messung")
- Add `dashboard.quickAddMood` ("Mood entry" / "Stimmungseintrag")
- Wire the two `<DropdownMenuItem>`s on `/`
- Mark the leading icons `aria-hidden` so the accessible name is
just the noun
- Update `e2e/measurement-flow.spec.ts` to target the menu item by
name (`/measurement|messung/i`) instead of `.first()`
Dialog titles still use the existing `addMeasurement` / `addEntry`
keys — those work in the larger dialog context where "Add" reads fine.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the v1.4.6 deferred polish item — feedback / mood / medication
status indicators now ask for *meaning* (success / warning / info)
instead of hard-coding `text-dracula-green` / `bg-dracula-orange/15`.
Adds three CSS aliases to `globals.css`:
--success → dracula-green (positive outcome)
--warning → dracula-orange (caution / attention)
--info → dracula-cyan (neutral informational)
Dark mode (Dracula): each alias resolves to the same hex as before, so
the visual is pixel-identical to v1.4.6 — what changes is the *intent*
of the class.
Light mode (Alucard): the raw Dracula greens and oranges fail AA
contrast on a white card. The new tokens get higher-contrast
counterparts (#14720a, #a34d14, #036a96) that match the existing
`--destructive` / `--chart-*` light-mode swap.
Migrated callers:
- `src/components/admin/feedback-inbox-section.tsx`:
- BUG category badge → `destructive` (semantic — bug *is* broken)
- "published to GitHub" badge → `success`
- `src/components/medications/medication-card.tsx`:
- in-window status → `success`
- very-overdue status → `warning`
- "late" intermediate stays on `dracula-yellow` (yellow doesn't
map to either semantic bucket — it's mid-warning)
- `src/components/settings/ai-section.tsx`:
- "ChatGPT connected" badge + success toast → `success`
- "Connection expired" badge + raw-data warning → `warning`
Charts (`src/components/charts/**`) untouched per
`feedback_charts_visual_identity.md`. Other dracula-token callsites in
settings/* (telegram, ntfy, web-push, account, about, test-connection)
are deferred to v1.5.1 — broader sweep, not in tonight's scope.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the v1.4.6 deferred polish item. When the user has saved a key
for the active provider (OpenAI, Anthropic, or Local), a "Remove saved
key" button now sits next to Save / Test connection. Clicking opens an
AlertDialog confirmation, then PATCHes `{ <provider>Key: null }` — the
existing `/api/user/ai-provider` route already treats null/empty as
"clear" (encrypted column set to NULL).
Provider, model, and base URL stay untouched so users keep their
selection while just rotating the secret. The button hides itself when
no key is stored, so the only state where it shows is exactly the one
where it's actionable.
Insights for the wiped provider fall back to the admin/Codex provider
on the next request — surfaced in the confirm-dialog body so the
behaviour is explicit.
i18n: 4 new keys under `settings.ai.*` (`removeKeyCta`, `keyRemoved`,
`removeKeyConfirmTitle`, `removeKeyConfirmBody`), EN canonical, DE
mirror. Existing `i18n-locale-integrity.test.ts` enforces parity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Restore the colour on the small ↑/↓ trend-arrow next to each tile's
latest reading — but make it metric-aware. v1.4.6 P4 stripped the colour
because the original rule (up=red, down=green) was wrong for half the
metrics: mood up is good, weight up is bad, pulse up is neither. v1.5
phase-5 brings back the colour through a `directionSentiment` prop:
- `up-good` → ↑ green, ↓ orange (mood, sleep, steps, BP-in-target%)
- `up-bad` → ↑ orange, ↓ green (weight, BP, body fat)
- `neutral` → muted in both (pulse, glucose — range matters
more than direction)
Stable-slope arrows ("→") and "no slope yet" placeholders ("—") always
stay muted. The default is `neutral` so any TrendCard call site that
hasn't been updated keeps the v1.4.6 muted look — back-compat is the
visible intent of the prop.
Affects only the icon next to the latest reading. The chart axes,
lines, colours, and the avg7/avg30 range-colour classes are untouched
(per Marc's hard-rule on chart visual identity, see
`feedback_charts_visual_identity.md` in user memory).
Tests: `src/components/charts/__tests__/trend-card.test.tsx` covers all
three sentiments × all three slope directions plus the
prop-omitted-back-compat case.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Re-enable the /admin axe-core spec that phase-3 parked while phase-4b
restructured the admin into per-section dynamic routes. The fixme is
gone, /admin/system-status and /admin/users are added as representative
sub-route audits, and the violations the original audit surfaced are
fixed:
- `src/components/admin/_shared.tsx`: drop the duplicate
`<PasswordInput>` whose toggle button had no accessible name.
Re-export the canonical `<PasswordInput>` from
`src/components/settings/password-input.tsx` (added in phase-3) which
already carries the `aria-label="Show password" / "Hide password"`
pair. Affects `/admin/integrations` (bug-report token, web-push VAPID
private key) and `/admin/users` (password-reset dialog).
- `src/components/admin/user-management-section.tsx`: icon-only edit /
reset-password / force-logout buttons now carry `aria-label` (axe
`button-name` is `serious`); the leading icon is `aria-hidden` so the
accessible name is just the action verb.
- `src/components/admin/status-card-grid.tsx`: drop the placeholder
`{ label: "—", value: "" }` tuple from the audit-log card. An empty
`<dd>` next to a "—" `<dt>` is not navigable and the `<dl>` was the
most likely source of an axe violation on `/admin`. The 3-column grid
still works with two metrics; the empty cell at the end is unrendered
because there is no `<div>` for it.
- `src/components/admin/__tests__/status-card-grid.test.tsx`: rework
the 3-metric assertion to allow 1..3 metrics with non-empty,
non-em-dash labels so the audit-log change doesn't regress.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* `status-card-grid.test.tsx` — replaces the v1.4.6 anchor-id allowlist
with a route-existence check: every card's href must match `/admin/
<slug>` AND `slug` must be in the `ADMIN_SECTION_SLUGS` source-of-
truth, AND `src/app/admin/[section]/page.tsx` must exist on disk.
This guarantees the dynamic-route file can never be silently moved
out from under the cards.
* `sections.test.tsx` — SSR smoke test for every section component
reachable from the dynamic-route renderer. Every section paints a
recognizable heading, and the `<UserManagementSection>` filter pills
+ `<BackupsSection>` "Backup now" button are asserted so the v1.5
fold-ins for T2.6 and T2.7 don't regress silently.
Locale parity for the new admin.section.* keys is enforced by the
existing `i18n-locale-integrity` test suite.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a `LEGACY_ADMIN_ANCHORS` map in proxy.ts that 301-redirects any
`/admin/section-<id>` path to its v1.5 dynamic-route equivalent. Pure
URL fragments (`#foo`) never reach the server, so this only catches
path-style legacy URLs (a referrer rewriter could promote a fragment
to a path segment, or someone might bookmark a hand-crafted form). The
in-app callsites that previously emitted `/admin#section-*` anchors
have all been rewritten to use the new routes directly — see the
status-card-grid commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The v1.4.6 status cards linked to `/admin#section-*` anchors that
required server-side scroll into the monolithic admin page. With the
v1.5 dynamic-route refactor, every section is its own route, so each
href now points at `/admin/<slug>` — fixes the v1.4.6 T6 honesty
problem permanently.
Mapping:
Users -> /admin/users
Integrations -> /admin/integrations
Monitoring -> /admin/integrations
Backups -> /admin/backups
Maintenance -> /admin/reminders
Audit log -> /admin/login-overview
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds an "Admin Console" link to the global sidebar (visible only to
ADMIN users). When the active route is under /admin/*, the link
expands into a sub-list of every section, mirroring the in-shell
section sidebar — same as Settings, where the global nav points to
the section landing and the shell drives in-context navigation.
Collapsed-sidebar mode keeps the icon-only Admin button without the
sub-list (consistent with the Bug Report and Settings buttons).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Folds in the v1.4.6 deferred backlog item:
* `<UserManagementSection>` now exposes role filters (All / Admins /
Users — "suspended" is documented as a no-op since the User model
lacks a `suspended` field; mapped to passthrough for forward
compatibility).
* New per-row "Force logout" action surfaces a confirmation dialog,
then POSTs to the new endpoint below. Shows a toast with the
number of sessions revoked.
* `POST /api/admin/users/[id]/force-logout` — admin-only kill switch
that deletes every Session row for the target user. Audit-logged
as `admin.user.force-logout`.
Existing role-toggle, edit, and reset-password actions are untouched.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Folds in the v1.4.6 deferred backlog item:
* `GET /api/admin/backups` — returns metadata-only listing of every
DataBackup row (size in bytes, no payload). Encrypted blobs stay
server-side.
* `POST /api/admin/backups/run` — enqueues an ad-hoc data-backup
pg-boss job. Returns 503 if the worker isn't running; the existing
weekly cron schedule is unchanged.
* `<BackupsSection>` — admin route at /admin/backups with the rows
table + "Backup now" CTA.
No new dependencies; uses the global pg-boss instance already wired in
`src/lib/jobs/boss-instance.ts`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Each admin section component now accepts an optional `id` prop (was
required) so it works under the new /admin/[section] dynamic route
without scroll-anchor wrapping. Adds <IntegrationsGroupSection> as the
composite for /admin/integrations (Umami + GlitchTip + WebPush + Bug
Report). Reduces /admin to a true overview: status-card grid + welcome
card + quick-jump menu of sub-sections; the long monolithic scroll is
gone.
Bundle-size win: each section now ships under its own route bundle, so
the overview no longer drags Umami/GlitchTip/Feedback/Users/etc. trees.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirrors the v1.4 settings split for the v1.5 admin refactor. Adds the
shell, the slug constants, the dynamic-route page, and the client-only
renderer that picks the right section component for each slug. The
existing admin sections continue to live in src/components/admin/*.tsx;
this scaffolding wires them into per-route bundles.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five real WCAG 2.1 AA violations the extended axe-core spec caught:
- top-bar.tsx: mobile user-menu DropdownMenuTrigger had no
accessible name on viewports < sm (the username text is
`hidden sm:inline`, leaving an icon-only button). Added
aria-label using the existing nav.userMenu key.
- password-input.tsx: show/hide eye toggle was icon-only, no
aria-label. Added common.showPassword / common.hidePassword
in en + de and bound to the visible state.
- auth/login/page.tsx: "Sign up" link relied on colour alone
(link-in-text-block). Switched hover:underline → underline so
the link is distinguishable without colour.
- page.tsx (dashboard): "Add" dropdown trigger was 32px tall
(size="sm"); on Pixel 5 below WCAG 2.5.5 44px threshold.
Added min-h-11 — desktop visual unchanged because the explicit
height only kicks in if it exceeds the size variant's h-8.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
bb2b1de wrapped seven Recharts primitives (ScatterChart, Scatter, XAxis,
YAxis, CartesianGrid, Tooltip, ResponsiveContainer) in next/dynamic to
push the ~108 KiB Recharts chunk off the /insights initial bundle. That
seam is one level too low: ScatterChart discovers its children by
comparing child.type against the imported component identity
(findAllByType). Once each child is wrapped in a next/dynamic HOC the
identity check fails and the chart renders an empty plot area —
no axes, no scatter points, no tooltip, even after Recharts lands.
Fix: extract the inline <ResponsiveContainer><ScatterChart>…</ScatterChart>
block into src/components/charts/scatter-correlation-chart.tsx, a
self-contained wrapper that statically imports every Recharts symbol it
needs. The insights page now next/dynamics that wrapper instead, matching
the existing HealthChart / MoodChart pattern in the same file. Recharts
still ships only in the deferred chunk; child-type detection keeps
working because primitives stay statically related to each other.
All four scatter cards (BP-medication continuity, mood-vs-BP,
weight-vs-BP, mood-vs-weight) rewritten as declarative
<ScatterCorrelationChart> calls. Identical height={250}, margins, grid
colour (hsl(var(--border))), axis colours (var(--dracula-fg) /
var(--dracula-comment)), per-chart fills (--dracula-orange / --cyan /
--lavender), tooltip styling, units, domains, ticks, labels, and
formatters. No color tokens, animations, or chart options changed.
Also adds a loading skeleton (h-[250px] w-full bg-muted/40 animate-pulse
motion-reduce:animate-none) that matches the chart footprint exactly so
the first paint of each card no longer shifts layout while Recharts
hydrates.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GettingStartedChecklist fired four useQuery calls on every dashboard
load even for users long past onboarding (Marc has
onboardingCompletedAt = 2026-02-20 and 1k+ measurements). The component
then short-circuits with `null` once shouldShowChecklist() reports
false, so the network round-trips are wasted.
The analytics + medications queries already share their cache with the
dashboard's own queryKeys, so they remain enabled. The other two —
withings/status (~303 ms) and notifications/preferences (~654 ms) —
are unique to the checklist and now gate on
`user.onboardingCompletedAt == null`. That removes ~950 ms of network
from /` for every established user.
Edge case (returning user with onboardingCompletedAt set but
measurementCount < 5 because they deleted readings post-onboarding) is
preserved by the inline comment + by the fact that the checklist
already renders unknown defaults gracefully.
v1.5 phase-4 perf audit, win #2 (docs/audit/v15-performance.md).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The insights page imported seven Recharts symbols (ScatterChart, Scatter,
XAxis, YAxis, CartesianGrid, Tooltip, ResponsiveContainer) eagerly at
module top, which pulled the entire ~108 KiB Brotli Recharts chunk onto
the initial bundle even though every scatter card sits inside a
`length >= 5` gate below the fold.
Switching each symbol to next/dynamic with `ssr: false` matches the
existing HealthChart / MoodChart pattern in the same file. Recharts is
still loaded once via the shared chunk graph the first time any scatter
section mounts; until then, /insights ships the same JS payload as
chart-free pages.
Verified static-only — local pnpm build is blocked by the documented
Node-25 turbopack regression. Full deltas captured in
docs/audit/v15-performance.md (v1.5 phase-4 perf audit).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Picks up the prettier line-wraps the v1.5 phase-1 planning docs and
codex-protocol-spec.md missed, and brings the redact.ts + insights
generate route test into the project's standard form. No behaviour
change — pnpm format:check now passes clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The original `/sk-(?:ant-)?[A-Za-z0-9_-]+/g` redacted any word ending
in `sk-…`, including common English compounds in error messages and
PR descriptions like `task-force`, `risk-management`, `disk-io`.
Server logs ended up reading "ta[REDACTED] ABC" / "ri[REDACTED]
note" / "di[REDACTED] 1234", which is unhelpful even though
over-redaction is the safer-than-leaking failure mode.
Tightens the regex to require either the start of the string OR a
non-alphanumeric prefix character (whitespace, `=`, `{`, `,`, `:`,
etc.) so the `sk-` token must actually start a secret, mirroring the
v1.4.6 P12 idempotency-cache guard. Adds a minimum tail length of 8
characters to defend against `sk-1`-style false-positives in code
identifiers.
Capture group 1 is the leading separator (preserved in the
substitution) so the redaction reads "apiKey=[REDACTED]" rather than
"apiKey[REDACTED]".
Adds tests covering the three v1.4.6-QA false-positive examples
(task-force, risk-management, disk-io) plus mid-word negatives, and
extends the positive coverage to confirm `sk-1234567890abcdef` and
`sk-ant-1234567890abcdef` still redact correctly with various
preceding separators.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.4.6 T5 fixed only the parse-error branch (502 → 422 to keep
Cloudflare's HTML-error rewrite from breaking `await res.json()` on
the dashboard). Provider errors — `OpenAI request failed (401)` for
an invalid admin key, or transient `OpenAI request failed (5xx)` —
still propagated to the apiHandler's generic 500. Cloudflare rewrites
the 5xx to its own HTML page, so the React Query mutation crashed
with "Unexpected token '<'" instead of surfacing a readable message.
Wraps `provider.generateCompletion(...)` in try/catch and mirrors the
v1.4.5 ai/test categorisation:
- 401 / 403 from the provider → 422 with "AI provider rejected the
request — check your API key in Settings > AI"
- 5xx from the provider → 503 with "AI provider temporarily
unavailable, try again in a moment"
- 429 from the provider → 429 (rate-limit passthrough)
- any other status → 422 generic provider-connection failure
Full error details (message, httpStatus, bodyExcerpt, providerType)
land in the Wide Event via `annotate()` so the operator can debug
without leaking provider URLs / partial keys to the client.
Adds unit tests covering 401/403/429/500/503/unknown mapping.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The `pairDailyBuckets` helper in blood-pressure-status, weight-status,
and mood-status synthesised a `date` field via
`new Date(now − dayOffset·86_400_000)`. That subtraction treats every
day as exactly 24h — wrong on the Europe/Berlin DST boundaries (the
spring-forward day is 23h, the fall-back day is 25h). The result was
that `toBerlinDayKey(date)` slipped one calendar day for ~2 days/year,
causing miscredited correlations and mismatched same-day BP joins on
those boundaries.
Adds and exports `dayOffsetToBerlinDayKey(now, dayOffset)` from
`bucket-series.ts`. The helper anchors at Berlin Y-M-D (DST-immune via
Intl) then subtracts in UTC-anchored Berlin-day space, where every day
is exactly 86_400_000 ms wide because both endpoints are UTC midnights
of consecutive Berlin calendar days.
All three `pairDailyBuckets` helpers and the four other call sites
that synthesised a date from a dayOffset now use the helper. The
returned pair carries `dayKey` directly so callers don't have to
re-format. The synthesised `date` field is anchored at the UTC
midnight of the Berlin day so any code that still formats it via
`toBerlinDayKey()` gets the same DST-safe answer.
Adds unit tests across the 2024 spring (2024-03-31 02:00 → 03:00)
and autumn (2024-10-27 03:00 → 02:00) DST boundaries from late-evening
and early-morning Berlin times — the cases where the naive 24h
subtraction visibly slips a day.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "Wipe all data" admin transaction was scoped only to measurements,
medications, intakes, API tokens, Withings connections, and auth
challenges. Notification channels (encrypted Telegram bot tokens in
NotificationChannel.config), Web Push subscriptions, and queued
Telegram message deletions survived the wipe — a scope leak first
flagged in the v1.4.6 multi-agent QA pass.
Extends the transaction with `notificationChannel.deleteMany`,
`pushSubscription.deleteMany`, and `telegramScheduledDeletion.deleteMany`.
NotificationPreference rows cascade via the schema FK.
Feedback rows are intentionally preserved (T8 v1.4.6) and the i18n
copy now states this explicitly so admins know bug reports survive a
wipe. Counts for the three new tables are returned to the UI.
Adds an integration regression test that seeds all three tables,
invokes the route handler with a real admin session, and asserts the
wipe clears them while Feedback + AuditLog survive.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.4.13 swung from gpt-5-codex to plain gpt-5, but the chatgpt.com
backend rejects both with the same error:
{"detail":"The 'gpt-5' model is not supported when using Codex with
a ChatGPT account."}
The accepted slugs come from the bundled `models.json` in
`codex-rs/models-manager/` — neither `gpt-5` nor `gpt-5-codex` is in
the current bundle. `gpt-5.3-codex` IS in the bundle and is available
on Plus/Pro plans (per `available_in_plans`); verified live against
Marc's account today.
Operators can still override via `CODEX_MODEL` env var if they're on
a different plan tier.
Spec updated with §7a documenting the chatgpt-account-auth allow-list
constraint — the lesson is that the model_migration.rs slug references
are migration *prompts*, not wire slugs. Always cross-check
`models.json`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Codex backend rejects `gpt-5-codex` when authenticated via the
ChatGPT-account OAuth flow with:
"The 'gpt-5-codex' model is not supported when using Codex with a
ChatGPT account."
The `-codex` suffix is API-key-auth-only. ChatGPT subscriptions route
through the plain `gpt-5` slug instead. Switch the client default and
expose a `CODEX_MODEL` env override for operators on plan tiers that
prefer a different slug (e.g. `gpt-5-codex-mini` or a future
preview model).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stop iterating on individual 400 errors and implement the full Codex
Responses-API protocol once, from the source. Wrote a 713-line
reference at docs/codex-protocol-spec.md from the official
openai/codex Rust client; this commit is the TS implementation
against that spec.
Required pieces that were missing in v1.4.11:
- `ChatGPT-Account-ID` header — extracted from the `chatgpt_account_id`
claim of the OAuth id_token (also accepts the URI-namespaced
variant under `https://api.openai.com/auth`). Without it: 401.
- `originator`, `User-Agent`, `Accept: text/event-stream`,
`session_id`/`session-id` (both spellings), `thread_id`/`thread-id`.
- Body fields `reasoning: null` and `include: []` are required even
when no reasoning is requested.
- Model slug is `gpt-5-codex`, not `gpt-5.3-codex` (the latter is a
test placeholder upstream).
- Refresh endpoint takes a JSON body, not form-urlencoded.
Storage codec rewrite: `codexAccessTokenEncrypted` now holds an
encrypted JSON blob `{ accessToken, accountId, expiresAt }` instead
of just the raw access token, so the account id stays available
across requests. v1.4.7-v1.4.11 records that lack the field cannot
be revived — `decryptCodexCreds` returns null for those rows and
`resolveCodexProvider` flips the connection to `expired`, prompting
the user to re-link once.
Removed the dead browser-flow routes (`/api/auth/codex/authorize`
and `/callback`). They never worked on hosted domains because
Hydra's redirect-URI allow-list for the public Codex client ID
covers only localhost; device-code is the only viable path.
CodexClient SSE parsing extended to handle `response.failed` and
`response.incomplete` terminal events, and to read the actual
routed model from the `OpenAI-Model` response header.
Tests rebuilt: codex-oauth covers the full device-code flow with a
synthesised id_token JWT, the JSON-body refresh, and the
storage-codec round-trip. CodexClient tests carry an `accountId`
through the constructor. All 720 tests pass; typecheck clean.
Refs: docs/codex-protocol-spec.md §1-§6 for every claim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After v1.4.10 fixed the request body, the Codex backend started
returning 400:
{ "detail": "Stream must be set to true" }
The endpoint is streaming-only — `stream: false` is rejected
outright. The official Codex CLI consumes a Server-Sent-Events
stream (`codex-rs/codex-api/src/sse/responses.rs`); we have to do
the same.
CodexClient now requests `stream: true` and reads the response body
incrementally via the standard `ReadableStream` reader. Each SSE
message ends in a blank line; the `data:` payload is JSON. We listen
for three event types from the OpenAI Responses API protocol:
- `response.output_item.done` with an assistant `message` item — the
final text is read directly from the message's `output_text`
content. Preferred path because the backend has already stitched
any deltas together.
- `response.output_text.delta` — incremental text chunks. Fallback
when no `output_item.done` arrived (e.g. older models or
reasoning-only responses), all deltas are concatenated.
- `response.completed` — picks up `usage.total_tokens`.
- `response.error` / `error` — bubbled as a thrown Error with the
upstream message.
Tests rebuilt to drive the client with synthetic SSE bodies, plus
new coverage for the delta-fallback path. All 720 unit tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After v1.4.9 the OAuth connect went green, but every real insight
call still failed with:
Codex request failed (400): { "detail": "Input must be a list" }
The `chatgpt.com/backend-api/codex/responses` endpoint speaks the
OpenAI Responses API shape (`ResponsesApiRequest` in
`codex-rs/codex-api/src/common.rs`), where `input` is a list of typed
message items rather than a single string. CodexClient was sending
the older Chat-Completions-style body (`input: <string>`) which the
upstream rejects with the 400 above.
The body now mirrors the canonical shape:
{
"model": "gpt-5.3-codex",
"instructions": "<system prompt>",
"input": [
{ "type": "message", "role": "user",
"content": [{ "type": "input_text", "text": "<user prompt>" }] }
],
"tools": [], "tool_choice": "auto",
"parallel_tool_calls": false, "store": false, "stream": false
}
The response shape (Output `ResponseItem[]` with `output_text`
content) is unchanged, so `parseResponse` still works without
modification. Both Settings → KI "Verbindung testen" and the insight
generator now complete end-to-end through the ChatGPT subscription.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.4.8's device-code flow got the user as far as the chatgpt.com
approval, but the connect step at the end still failed with:
Codex api-key exchange failed (401): "Invalid ID token: missing
organization_id"
Root cause: the api-key exchange (RFC 8693, swap id_token for an
OpenAI API key) requires the id_token to carry an `organization_id`
claim. That claim only gets added when the authorize URL is hit with
`id_token_add_organizations=true` — which the browser/auth-code
flow does, but the device-code flow does NOT (the user types the
code on chatgpt.com's own page; we never control the authorize URL).
The official Codex CLI handles this by NOT calling the api-key
exchange in the device path: it persists the OAuth access_token /
refresh_token directly and uses them against
`https://chatgpt.com/backend-api/codex/responses` (the Codex backend
that bills against the ChatGPT subscription). v1.4.9 does the same.
`pollDeviceCode` no longer calls `obtainApiKey`; it returns the raw
OAuth access_token instead. New `refreshDeviceTokens()` mirrors that
on the refresh path. The provider rewires Codex back through the
existing `CodexClient` (bg backend-api), with proactive refresh
+ on-401 refresh both going through `refreshDeviceTokens`.
The browser/auth-code flow path is left in place — operators who
register a private OAuth app with OpenAI (e.g. for an enterprise
deployment) can still use the api-key exchange via the
`exchangeCodeForTokens` helper. For the public Codex client ID on
hosted instances, device-code is the only working path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.4.7 corrected the issuer (`auth.openai.com`) and added the
RFC-8693 api-key exchange, but the Connect button still failed in
production with `unknown_error`. Root cause: OpenAI's Hydra
allow-lists only `http://localhost:1455/auth/callback` and
`:1457/auth/callback` for the public Codex CLI client ID. Any hosted
redirect URI gets silently rejected — the v1.4.7 user landed on the
"An error occurred during authentication (unknown_error)" page.
The official Codex CLI ships a parallel **device-code flow** for
exactly this case (`codex-rs/login/src/device_code_auth.rs`):
1. POST `https://auth.openai.com/api/accounts/deviceauth/usercode`
with the client id → `{ device_auth_id, user_code, interval }`.
2. Show the user the code and a link to
`https://auth.openai.com/codex/device`. They open it on any
device, log in, and type the code.
3. POST `https://auth.openai.com/api/accounts/deviceauth/token`
repeatedly until Hydra returns `{ authorization_code,
code_challenge, code_verifier }` (otherwise 403 / 404).
4. Standard PKCE token exchange against `/oauth/token` — but with
`redirect_uri = https://auth.openai.com/deviceauth/callback`,
which IS allow-listed for the public client. Then the same
id_token → API-key exchange that v1.4.7 already added.
This sidesteps the redirect-URI allow-list entirely; HealthLog's
domain never appears in any OAuth round-trip.
Implementation:
- `src/lib/ai/codex-oauth.ts` adds `requestDeviceCode()` and
`pollDeviceCode()`.
- `POST /api/auth/codex/device-start` initialises the flow, persists
the `device_auth_id` + `user_code` in an encrypted httpOnly cookie
(15 min, scoped to the requesting user), and returns the user-
facing pieces.
- `POST /api/auth/codex/device-poll` does one poll attempt; on
`pending` it returns `{ status: "pending" }`, on success it
exchanges + persists the api key + refresh token and returns
`{ status: "connected" }`.
- The Settings → KI section replaces the "redirect to OAuth"
button with an inline card showing the user code, the
verification URL, and a copy button. The page polls every
`intervalSeconds` (5s default) until status flips to "connected"
or the user cancels. EN + DE strings under
`settings.ai.deviceCode*` cover the new copy.
- The legacy authorize / callback routes stay on disk for now —
they're harmless when the redirect-URI allow-list is updated for
a private client ID, so operators with an OpenAI partner client
can still use the original flow via `CODEX_OAUTH_CLIENT_ID`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "Connect with ChatGPT" button never actually completed an OAuth
flow. The implementation hit `chatgpt.com/authorize` and
`chatgpt.com/oauth/token`, which are not OAuth endpoints — ChatGPT
silently rendered its normal web app, dropped our params on the
floor, and the user landed on a regular logged-in chat session with
nothing else happening. There was no error and no callback, which is
why the regression survived multiple releases.
The canonical issuer for ChatGPT-OAuth is `auth.openai.com`. The
official `openai/codex` CLI confirms this in
`codex-rs/login/src/auth/manager.rs` and `codex-rs/login/src/server.rs`.
The flow is also slightly more involved than a vanilla PKCE
authorisation:
1. PKCE authorize against `auth.openai.com/oauth/authorize` with the
`openid profile email offline_access api.connectors.read
api.connectors.invoke` scope set, plus `id_token_add_organizations`
and `codex_cli_simplified_flow` flags so the resulting `id_token`
carries the ChatGPT-subscription claims.
2. Token exchange against `auth.openai.com/oauth/token` (form-
urlencoded body, NOT JSON) yields `{ id_token, access_token,
refresh_token }`.
3. **Second token exchange** with grant
`urn:ietf:params:oauth:grant-type:token-exchange`, swapping the
`id_token` for an OpenAI API key (`requested_token=openai-api-key`).
This key bills against the ChatGPT subscription rather than a
separate API plan — exactly what the v1.2/v1.3 design intended.
4. HealthLog stores the API key in `codexAccessTokenEncrypted`
(re-purposing the existing column to avoid a migration) and the
OAuth refresh token in `codexRefreshTokenEncrypted`. When the
key is about to age out we refresh + re-exchange transparently
before the next request.
The downstream provider is now a regular `OpenAIClient` tagged with
`providerType: "codex"` so logs and analytics still distinguish
ChatGPT-subscription billing from plain BYOK. The bespoke
`codex-client.ts` (which hit the chatgpt.com/backend-api/codex/responses
endpoint with the OAuth access token) is still on disk for now so the
prisma columns and the provider tag stay stable, but is unreferenced
by the active path.
The public Codex CLI client ID `app_EMoamEEZ73f0CkXaXp7hrann` is
shipped as a default; operators who registered a private OAuth app
with OpenAI can override via `CODEX_OAUTH_CLIENT_ID`. The
`isCodexOAuthConfigured()` gate is a no-op now because the default
always has a value, so the UI surface no longer silently hides the
"Connect with ChatGPT" button.
Tests cover the new shape end-to-end: PKCE generation, the
authorize-URL parameters, the form-encoded token exchange, the
api-key exchange, the refresh path, and the encrypt/decrypt
round-trip. The provider integration test is updated to expect a
`providerType: "codex"` OpenAIClient instead of the legacy
`CodexClient`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Long-overdue prettier sweep; prettier had drifted vs. checked-in code
across ~130 files (mostly long-argument line-break wrapping in TS and
table-padding in markdown). Pure formatting — no semantic changes —
and required to clear the v1.4.6 release gate's `pnpm format:check`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three small follow-ups surfaced by the v1.4.6 QA pass:
- Settings → KI: the "raw data" warning still used raw Tailwind orange
tokens instead of the Dracula `dracula-orange` ones, breaking theme
consistency and tipping below the WCAG-AA contrast floor on the
card surface.
- Admin status grid: the Backups card cta read "View backups" but
jumped to the system-status section (the dedicated backups view
does not exist yet — that's a v1.5 feature). Re-labelling the cta
to "Open system status" and the Integrations cta to "Open
integrations" makes the destination honest. The href targets
themselves are unchanged.
- `withIdempotency` body-content guard previously did `text.includes("sk-")`
which silently broke caching for benign payloads containing common
English compounds like "task-id", "risk-management", "disk-io".
Tightened to a regex requiring the canonical secret prefix plus a
realistic suffix length, so only actual API keys trip the guard.
Three regression tests cover the false-positive cases.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P20. Switch the 16-probe batch from `Promise.all` to
`Promise.allSettled`. Before: any single probe rejecting (a transient
DB timeout, a missing index after a schema migration, etc.) would
reject the whole route and the admin overview grid would render as
blank — costing the admin the other five healthy cards' info too.
Now each probe is labelled, the rejected ones map their card's severity
to "alert" + zero/null defaults so the StatusCardGrid still draws
something, and the failed probe names are surfaced in a Wide Event
annotation (`statusOverviewProbeFailures: [...]`) for ops triage.
Adds a vitest case that mocks a single rejection on the withings probe
and asserts the response still 200s, the integrations card flips to
alert with `withings: 0`, and untouched cards keep their normal
severity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P19. `useSystemStatus()` and `useAdminSettings()` already throw on
non-OK responses so React Query sets `isError`, but neither caller
read it — the system-status panel just kept spinning forever and the
settings sections silently rendered defaults as if they were live.
Now system-status renders a destructive inline alert when isError, and
the admin page top renders a one-line "Failed to load admin settings"
banner when the shared settings query fails so the admin notices the
toggles below aren't reflecting reality. Both messages have new i18n
keys (`admin.systemStatusLoadError`, `admin.adminSettingsLoadError`)
in en.json (canonical) + de.json.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P18. Replace the brittle "wipeMsg.startsWith(localized prefix)" success
heuristic with React Query's `wipeAllData.isError` flag. The previous
heuristic (a) re-formatted the success copy with empty placeholders to
extract a prefix, (b) string-prefix-matched against the rendered
message, and (c) silently broke whenever the i18n copy changed colon
position or got translated. Now the colour follows the mutation state
directly: error → destructive, success → dracula-green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P17. The category badges (BUG / FEATURE_REQUEST / QUESTION / OTHER)
were using raw Tailwind palette values (bg-red-500/15 text-red-400 etc.)
which clash with the rest of the app's Dracula tokens. Switch to the
dracula-red / dracula-purple / dracula-cyan equivalents so the inbox
matches the site theme — and dark/light mode parity is consistent
with every other status badge in the admin grid.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P15: drop `gpt-5` (unreleased) and `o3-mini` from `MODEL_PRESETS["OPENAI"]`.
gpt-5 would surface as model_not_found from OpenAI; o3-mini uses the
o-series param contract (max_completion_tokens, no temperature override)
which the current OpenAIClient body shape doesn't speak — so picking
either preset just produced a confusing 400. Keep gpt-4o, gpt-4o-mini,
gpt-4-turbo. Power users can still type any model via the Custom… option.
P16: pipe ~30 hardcoded German strings in ai-section.tsx through
`t("settings.ai.…")` and add the matching keys to both messages/en.json
(canonical English) and messages/de.json. Behaviour unchanged — the
Connect/Disconnect/Save/Test/Provider/Model labels and the connect-help
copy now respect the user's locale toggle. The provider-test flow keeps
its own DE strings localized too.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P14. CodexClient previously threw a bare `Error("Codex request failed
(500)")` on upstream failure, which made it impossible to triage from
logs. Mirror the openai-client.ts:42-58 pattern: pull the body
(truncated 500 chars), mask any leaked `sk-` / Bearer token, and tag
the Error with `httpStatus`, `upstream`, `model`, and `bodyExcerpt`
fields. Glitchtip and Wide Events now have the same shape for both
providers.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P13. Move `checkRateLimit` below the 24h cache-return path so a request
that gets served from the cached `insightsCachedText` never consumes one
of the 2/hour LLM-generation tokens. A user reloading the dashboard a
few times no longer locks themselves out of a fresh refresh for an hour.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P12. The body-content guard already rejected `hlk_` / `hlr_` (our access
and refresh tokens). Extend it to also reject `sk-` so any OpenAI or
Anthropic key that might be echoed by a misrouted handler never lands
in the IdempotencyKey table. The substring match also covers `sk-ant-`
so we don't need a second branch.
Adds a parametrised vitest case asserting all four prefixes
(hlk_, hlr_, sk-, sk-ant-) suppress caching, plus a
positive case to prove a normal payload still caches.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
