Commit Graph
242 Commits
Author SHA1 Message Date
Marc-André BombeckandClaude Opus 4.7 a106547e20 test(e2e): doctor-report PDF + mobile-viewport smoke
doctor-report.spec.ts mocks /api/doctor-report with a
shape-correct payload, clicks the "Doctor report" button on
/settings/advanced, captures the resulting download via Playwright's
`waitForEvent('download')`, and asserts the file is >1KB and starts
with the `%PDF` magic.

mobile-viewport.spec.ts is a Pixel 5 only smoke that verifies the
dashboard has no horizontal scroll, the fixed bottom-nav doesn't
clobber main content, and every interactive CTA visible above the
fold meets WCAG 2.5.5 (≥44×44 CSS px). Skips on the desktop project
via testInfo.project.name.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:49:09 +02:00
Marc-André BombeckandClaude Opus 4.7 2b6f959434 test(e2e): mocked Codex device-flow + insights regenerate specs
codex-flow.spec.ts intercepts /api/auth/codex/device-start +
device-poll + /api/insights/settings to drive the UI through the
three-state machine (CTA → device-code panel → "ChatGPT connected"
badge) without touching auth.openai.com / chatgpt.com.

insights-generate.spec.ts mocks /api/insights/generate with the
canonical InsightResult shape (changed/stable/drivers/nextSteps/
confidence/limitations) and confirms the regenerate button surfaces
the inline success message — the AI provider stays uninvolved.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:49:00 +02:00
Marc-André BombeckandClaude Opus 4.7 3999ea7b3c test(e2e): authenticated dashboard render + add-measurement flow
Two new specs exercise the core happy path: the dashboard tile strip
+ Recharts surface render against a mocked /api/analytics, and the
quick-entry dropdown → MeasurementForm dialog → POST /api/measurements
round-trip surfaces a weight reading on /measurements.

Both rely on the global setup's pre-captured session cookie, so
neither hits the auth rate limit. The mocks fully isolate from the
DB so we don't need a 90-day measurement seed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:48:52 +02:00
Marc-André BombeckandClaude Opus 4.7 535465c0ef test(e2e): add seeded test user + auth storageState fixture
Authenticated specs need a deterministic user and a persistent session
cookie. global-setup.ts upserts an `e2e-tester` admin via raw `pg` (the
generated Prisma client uses ESM `import.meta.url`, which Playwright's
TS loader cannot resolve), then logs the user in once and writes
`storageState.json` so every authenticated spec reuses the same
session — the per-IP login rate-limit (5 attempts / 15 min) would
otherwise lock out the suite the moment six specs run in parallel.

Adds `pg` + `@types/pg` as devDependencies — required for the seed
step. `pg` is already used by `scripts/seed-demo.ts` for the same
loader-incompatibility reason, so we're not introducing a new
dependency footprint, only making it explicit in the lockfile.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:48:45 +02:00
Marc-André BombeckandClaude Opus 4.7 1a85da0b05 fix(insights): preserve chart visual parity in deferred bundle
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>
2026-05-09 16:41:49 +02:00
Marc-André BombeckandClaude Opus 4.7 ad8fe5a60d chore(planning): phase 4 done — performance audit landed
Captured Playwright+PerformanceObserver perf metrics against prod
(/api/version=1.4.13) at 2026-05-09T14:14Z. Top 2 wins shipped
inline (Recharts deferred-import on /insights, checklist queries
gated on post-onboarding state); Recharts replacement deferred to
v1.5.1 because v1.5 forbids new deps.

Wins: bb2b1de + 519e36e. Audit doc: 41fa203.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:24:39 +02:00
Marc-André BombeckandClaude Opus 4.7 41fa2032ae docs(audit): v1.5 performance audit report
Captures Playwright+PerformanceObserver measurements against
production (https://healthlog.bombeck.io, /api/version=1.4.13) at
2026-05-09T14:14Z. Four pages × two viewports (1920x1080 desktop,
Pixel 5 mobile): /, /settings/integrations, /admin, /insights.

Key findings:
- /insights eagerly imported Recharts (108.5 KiB) — fixed in
  bb2b1de via per-symbol next/dynamic.
- Dashboard checklist fired 2 redundant API calls per load for
  established users (~950 ms wasted) — fixed in 519e36e by gating
  on user.onboardingCompletedAt.
- Recharts replacement deferred to v1.5.1 (no new deps in v1.5).

Local re-measurement is blocked by the Node-25 turbopack regression
already noted in CLAUDE.md; verification will land via the v1.5.0
prod measurement once Coolify force-pulls the new bundle.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:23:54 +02:00
Marc-André BombeckandClaude Opus 4.7 519e36e84f perf(dashboard): skip checklist API fetches once onboarding is complete
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>
2026-05-09 16:23:44 +02:00
Marc-André BombeckandClaude Opus 4.7 bb2b1de742 perf(insights): defer Recharts ScatterChart imports via next/dynamic
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>
2026-05-09 16:23:32 +02:00
Marc-André BombeckandClaude Opus 4.7 210f6105a7 chore(planning): phase 2 done — v1.4.6 deferred backlog cleared
T2.1 / T2.2 / T2.3 / T2.5 landed as atomic commits 512a6a6, cb6a59a,
5403821, d6696cf. T2.4 / T2.6 / T2.7 deferred to phase 4b (admin
refactor to per-section dynamic routes makes anchor-id work
disposable).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 16:08:20 +02:00
Marc-André BombeckandClaude Opus 4.7 6b88e56aeb chore(format): prettier sweep over phase-2 touched files + stale planning docs
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>
2026-05-09 16:06:52 +02:00
Marc-André BombeckandClaude Opus 4.7 d6696cf02b fix(logging): redactSecrets regex requires non-alphanumeric prefix to avoid false positives
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>
2026-05-09 16:05:53 +02:00
Marc-André BombeckandClaude Opus 4.7 54038216e4 fix(insights): map AI provider errors to 422/503 instead of 500
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>
2026-05-09 16:04:15 +02:00
Marc-André BombeckandClaude Opus 4.7 cb6a59a431 fix(insights): correct DST handling in cross-metric daily bucket pairing
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>
2026-05-09 16:02:26 +02:00
Marc-André BombeckandClaude Opus 4.7 512a6a619c fix(admin): wipe-all-data clears notification channels, push subs, telegram deletions
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>
2026-05-09 15:56:24 +02:00
Marc-André BombeckandClaude Opus 4.7 0668d35704 chore(planning): phase 1 done — Codex flow verified live
Default model slug fix (gpt-5 → gpt-5.3-codex) on commit 5df74f7
makes the chatgpt.com backend accept HealthLog's Codex requests on
Marc's ChatGPT-Plus account; spec §7a updated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 15:51:18 +02:00
Marc-André BombeckandClaude Opus 4.7 5df74f7981 fix(ai): default Codex model to gpt-5.3-codex for ChatGPT-account auth
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>
2026-05-09 15:46:21 +02:00
Marc-André BombeckandClaude Opus 4.7 2c488b830c chore(planning): bootstrap v1.5 marathon
Reset .planning/STATE.md and .planning/ROADMAP.md for the v1.5
overnight marathon. STATE.md tracks 12 phases (0–11) with empty
checkboxes; phase 0 marked done. Capture phase-0 sanity report at
.planning/phase-0-report.md (git status clean, recent commits, CI
status, /api/version=1.4.12 — one tag behind HEAD because the
v1.4.13 GHCR build is still in_progress; phase 1 owns the force-pull
verification). ROADMAP.md condenses the 12-phase plan with the
time-runs-short minimum (1+2+7+8) for shipping v1.5.0.

Previous milestone (v1.4.6) summary preserved as a one-line link to
docs/audit/v146-summary.md at the top of STATE.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 15:23:34 +02:00
Marc-André BombeckandClaude Opus 4.7 cfa8ea60a0 fix(ai): use plain gpt-5 model slug for ChatGPT-account auth
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>
v1.4.13
2026-05-09 15:10:54 +02:00
Marc-André BombeckandClaude Opus 4.7 e4a07bc2e4 fix(ai): complete Codex backend protocol implementation per spec
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>
v1.4.12
2026-05-09 14:36:12 +02:00
Marc-André BombeckandClaude Opus 4.7 e0de659fdd fix(ai): CodexClient consumes SSE stream from chatgpt.com backend
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>
v1.4.11
2026-05-09 14:16:45 +02:00
Marc-André BombeckandClaude Opus 4.7 68e5797e48 fix(ai): Codex backend request body matches OpenAI Responses schema
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.10
2026-05-09 13:34:12 +02:00
Marc-André BombeckandClaude Opus 4.7 3dbc8af627 fix(ai): device-code flow uses OAuth access token directly (v1.4.8 follow-up)
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.9
2026-05-09 11:25:50 +02:00
Marc-André BombeckandClaude Opus 4.7 19eb1d95d6 fix(ai): switch ChatGPT-OAuth to device-code flow (v1.4.7-followup)
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>
v1.4.8
2026-05-09 10:31:30 +02:00
Marc-André BombeckandClaude Opus 4.7 2f7f487228 fix(ai): Codex OAuth flow — correct issuer + api-key exchange
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>
v1.4.7
2026-05-09 09:31:13 +02:00
Marc-André BombeckandClaude Opus 4.7 3bca8267cc docs(release): v1.4.6 marathon summary
Marc-facing morning brief at the top, full per-finding list,
deferred-to-v1.5 backlog, production state, docs/landing sync log,
and the multi-agent QA reconciliation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 03:04:20 +02:00
Marc-André BombeckandClaude Opus 4.7 a852612bfe chore(release): v1.4.6
Release notes in CHANGELOG.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.4.6
2026-05-09 02:29:08 +02:00
Marc-André BombeckandClaude Opus 4.7 02b99553b9 chore(style): repo-wide prettier sweep before v1.4.6 tag
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>
2026-05-09 02:27:17 +02:00
Marc-André BombeckandClaude Opus 4.7 67575180b8 fix(qa): apply pre-release multi-agent QA findings
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>
2026-05-09 02:22:12 +02:00
Marc-André BombeckandClaude Opus 4.7 dc4507a55f fix(admin/status-overview): one failed probe no longer blanks the grid
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>
2026-05-09 02:10:15 +02:00
Marc-André BombeckandClaude Opus 4.7 26543378b5 fix(admin): surface query errors instead of an infinite spinner
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>
2026-05-09 02:10:05 +02:00
Marc-André BombeckandClaude Opus 4.7 86a4b52053 fix(admin): danger-zone result colour driven by mutation state
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>
2026-05-09 02:09:57 +02:00
Marc-André BombeckandClaude Opus 4.7 505f31844e style(admin): switch feedback-category badges to dracula tokens
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>
2026-05-09 02:09:49 +02:00
Marc-André BombeckandClaude Opus 4.7 89b5b80493 fix(settings/ai): drop unreleased OpenAI presets + i18n the AI section
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>
2026-05-09 02:05:28 +02:00
Marc-André BombeckandClaude Opus 4.7 dcc697c33d fix(ai): codex-client mirrors openai-client structured-error pattern
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>
2026-05-09 02:01:56 +02:00
Marc-André BombeckandClaude Opus 4.7 4a159d2b6c fix(insights): cache hits no longer burn rate-limit tokens
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>
2026-05-09 02:01:17 +02:00
Marc-André BombeckandClaude Opus 4.7 c7b600575e fix(idempotency): refuse to cache bodies containing third-party AI keys
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>
2026-05-09 02:00:49 +02:00
Marc-André BombeckandClaude Opus 4.7 e903d9a2c2 fix(logging): scrub OpenAI / Anthropic API keys in redactSecrets
P11. Adds a `sk-(ant-)?[A-Za-z0-9_-]+` rule so any sk- / sk-ant- token that
finds its way into an error message or stack trace gets redacted before
it reaches Loki or Glitchtip. We never log these on purpose, but a
mis-typed config or a dumped request body could carry one — defense in
depth on the egress path.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 02:00:01 +02:00
Marc-André BombeckandClaude Opus 4.7 5c884b3d0e style(layout): tighter mobile bottom-nav buffer + muted trend-hint title + drop font-mono on progress
- P7: shrink the bottom-nav clearance from 5rem to 4rem on mobile (md:pb-0 unchanged) so content sits closer to the nav without overlap.
- P8: TrendHint title gets text-muted-foreground so it stops competing with chart titles after the T2 muted-foreground hierarchy fix.
- P9: drop font-mono from the onboarding "X%" progress label; tabular-nums alone is enough.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:59:25 +02:00
Marc-André BombeckandClaude Opus 4.7 dc6db82a79 style(dashboard): visible muted welcome subtitle + medications card padding parity
- P6: drop hidden sm:block from the welcome subtitle and add text-muted-foreground so it stays visible on mobile but recedes from the H1.
- P10: medications card rounded-lg border p-4 -> rounded-xl border p-4 md:p-6 to match the other dashboard chart cards.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:58:30 +02:00
Marc-André BombeckandClaude Opus 4.7 fda8dd8c47 style(dashboard): trend-card typography + tabular nums + match chart padding + always-show avg chips
- P1: tabular-nums on latest, unit, avg7, avg30 spans so digits stop jiggling on refresh.
- P2: bump value text-2xl -> text-3xl tracking-tight; label text-sm font-medium -> text-xs uppercase tracking-wide.
- P3: tile padding p-3 -> p-4 md:p-6 to align with chart card padding.
- P4: drop direction-tinted arrow color (orange/cyan) — direction-as-good-or-bad is metric-specific, deferred to v1.5+. Both directions now muted-foreground.
- P5: always render avg7/avg30 chips, with em-dash placeholder when null, so vertical rhythm stays consistent across tiles.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:58:06 +02:00
Marc-André BombeckandClaude Opus 4.7 6a64df0fad feat(charts): bucket > 1y ranges into weekly / monthly averages
Hitting "All" on a long-running account used to render thousands of
daily points — unreadable, and slow on mobile. The chart adapter now
picks an aggregation level based on the visible range:

  - ≤ 90 days  → daily (unchanged)
  - 91-730 days → ISO weekly mean
  - > 730 days  → Berlin-calendar monthly mean

Empty buckets are dropped instead of zero-padding so a sparse user
keeps a real trend instead of a baseline floor. Each metric is
aggregated independently so blood-pressure SYS/DIA pairs stay in sync
without one channel pulling the other to 0 on missing days.

A small chip beside the chart title surfaces the active bucket
("Wochendurchschnitt" / "Monatsdurchschnitt" in DE, "Weekly avg" /
"Monthly avg" in EN) so the user always knows what they're looking at.

The bucketer (`src/lib/charts/bucket-time-series.ts`) is pure and
covered by 14 unit tests including ISO-week boundary handling, the
multi-metric independence guarantee, and the empty-bucket skip.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:56:07 +02:00
Marc-André BombeckandClaude Opus 4.7 46e686f396 fix(e2e): switch mobile project to chromium and repair spec flakiness
Three orthogonal fixes that account for most of the e2e suite's
ongoing red:

- The `chromium-mobile` project was actually iPhone 13 (webkit) — CI's
  `playwright install chromium` therefore could not launch it
  (`webkit-2272/pw_run.sh` does not exist). Renaming-to-Pixel-5 makes
  the project name match what the runner provides without expanding
  the install footprint.
- `locale-switch.spec.ts` tried to anchor the cookie at `page.url()`,
  which on a fresh context is `about:blank`; Playwright rejected the
  cookie outright. Using the project's configured baseURL is the
  documented way and works regardless of navigation timing.
- `login.spec.ts` looked for the username/password inputs immediately
  after navigation, but the password form is mounted lazily once the
  user clicks "Login with password" (passkey is the default mode).
  A small helper now opens the form before the assertions run.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:52:57 +02:00
Marc-André BombeckandClaude Opus 4.7 1adda80944 feat(insights): widen per-card window from 30 days to 360+24 buckets
Every per-card KI insight generator was clipping each metric to the
last 30 daily means before sending the prompt. The model therefore
saw a one-month window per metric — far too narrow to detect drift
that plays out over a year, and the cause of repeated complaints that
a "Stable" trend assessment ignored an obvious 9-month decline.

New shared helper `applyPayloadBudget()` builds a `{ daily, monthly }`
view: the most recent 360 days as daily means (`dayOffset 0..359`)
plus 24 thirty-day windows for the older history (`monthOffset
12..35`). Empty buckets are dropped. If the canonical payload would
serialise above 50 KB the helper transparently re-buckets at 180
daily days so the prompt token budget stays bounded; a per-generator
`annotate({ payload_size_bytes })` makes the chosen window
observable in Wide Events.

All seven generators now consume the bucketed view as the metric
`series` field (general-status, blood-pressure-status, pulse-status,
weight-status, bmi-status, mood-status, medication-compliance-
status) — including their cross-metric joins (BP-pair, weight ↔ mean
BP correlation, medication-compliance per day) which are rebuilt on
top of the shared `dayOffset` instead of date strings. Mood and
medication queries widened to ~3 years so the older monthly window
can actually be filled.

One focused vitest per generator captures the prompt that goes to the
provider, JSON-parses the embedded snapshot, and asserts every
metric series carries both `daily` and `monthly` arrays with the
expected shape. The bucketing helper also has its own unit tests
covering offsets, leap-year-safe Berlin-day boundaries, and the
50 KB → 180-day fallback.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:50:10 +02:00
Marc-André BombeckandClaude Opus 4.7 c3ca8614a6 fix(admin): preserve audit trail across the data wipe
Two related corrections to the "Wipe all data" admin action:

- Stop deleting the audit log inside the transaction. The whole point
  of the audit trail is to outlive the data it documents, and this is
  the single feature where that property matters most. AuditLog rows
  now survive the wipe.
- Audit-log the *intent* (`admin.data.clear.start`) before the
  transaction begins, so even if the wipe crashes mid-flight there is
  a record of who initiated it.
- The i18n copy and the success toast both undersold the scope: they
  only mentioned measurements/medications/intakes, but the wipe also
  clears API tokens, Withings connections, and any open auth
  challenges. EN + DE strings now enumerate every cleared category and
  call out that user accounts AND the audit log are preserved.
- Mutation result type widened so the toast can render the full
  count tuple.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:32:29 +02:00
Marc-André BombeckandClaude Opus 4.7 31959e436e fix(bugreport): admin toggle now actually blocks feedback submissions
The "Bug reports" admin toggle had no effect. The form on `/bugreport`
posts to `/api/feedback`, which was the wrong endpoint for the gate —
it lived only on the legacy `/api/bugreport` route the form does not
call. Users still submitted into the local feedback inbox after the
admin disabled the feature, and the prior commit message claimed
"the report button gracefully disappears" was untrue.

- `/api/bugreport/status` now also returns `enabled` (defaults true
  when the column has never been written) so the page can decide
  whether to render the form at all.
- `/api/feedback` POST checks `bugReportEnabled` and returns 503 with
  a readable error when the admin has switched the feature off, so a
  scripted client cannot bypass the UI by hitting the endpoint directly.
- `/bugreport` page now hides the form and shows the disabled-banner
  copy when `enabled === false`.
- New i18n keys for the disabled state in DE + EN.
- Vitest covers the gate: blocked when off, allowed when on, allowed
  when row absent.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:31:11 +02:00
Marc-André BombeckandClaude Opus 4.7 4aeb8c904e fix(admin): point status-card CTAs at real anchor IDs
Every "Manage users" / "View backups" CTA reloaded `/admin` to the top
because the hrefs were pointing at sub-routes that never shipped
(`/admin/users`, `/admin/audit-log`) and at anchors whose IDs do not
exist (`/admin#integrations`, `#monitoring`, `#backups`,
`#maintenance`). The actual section IDs in `src/app/admin/page.tsx`
follow a `section-admin-*` / `section-user-management` pattern.

Six href fixes plus a tightened test: instead of `startsWith("/admin")`
the test now asserts each href is `/admin#section-<known-id>` and that
the anchor is a member of the source-of-truth ID set rendered by the
admin page. Adding a new section requires adding the ID here too —
which is exactly the visibility we want to keep CTAs honest.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:28:55 +02:00
Marc-André BombeckandClaude Opus 4.7 c8ee28d2b0 fix(insights): map LLM-parse failure to 422 instead of 502
Same Cloudflare-rewrites-5xx footgun the v1.4.5 ai/test fix solved. A
malformed JSON response from the upstream model returned HTTP 502, which
Cloudflare swapped for its own HTML error page; the client's
`await res.json()` then crashed with `Unexpected token '<', "<!DOCTYPE "`
and the user — already throttled by the 2/h rate limit — saw nothing
useful. 4xx passes through Cloudflare untouched, so the React Query
mutation can read the JSON envelope and show a real error.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:27:07 +02:00
Marc-André BombeckandClaude Opus 4.7 eba898f4c1 fix(ai): block aiBaseUrl from leaking across providers
The user row stores a single `aiBaseUrl` column that is meaningful only
for the LOCAL provider, but `buildUserProvider` and
`resolveProviderForTest` were forwarding that value to OpenAI and
Anthropic clients too. A user who had configured LOCAL pointing at e.g.
`http://192.168.x.x/v1` and later switched to OPENAI would have their
OpenAI API key sent to that LAN host on the next request.

Defence in three layers:

- PATCH /api/user/ai-provider — when the provider switches to anything
  other than LOCAL and the body does not include an explicit
  `aiBaseUrl` write, set the column back to NULL.
- `buildUserProvider` — for OPENAI hardcode `https://api.openai.com/v1`,
  for ANTHROPIC do not forward a base URL at all (the SDK default is
  correct and the UI never exposed an Anthropic base-URL input).
- `resolveProviderForTest` — same belt-and-braces: ignore the merged
  base URL for OPENAI/ANTHROPIC so a stored LOCAL value cannot bleed
  into a connection-test request.

Adds two regression tests covering the LOCAL → OPENAI and LOCAL →
ANTHROPIC paths with a stale `aiBaseUrl`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:26:48 +02:00
Marc-André BombeckandClaude Opus 4.7 a75fbc6aaf fix(insights): primary recommendation parses metric: chart tokens
The base-system prompt invites the model to embed `metric:WEIGHT` /
`metric:BP` etc. tokens in `primaryRecommendation` so the UI can drop
inline charts under the prose. The hero "Key Takeaway" card was the
only renderer printing the field raw — when the model followed the
instructions, the user saw the literal string `metric:WEIGHT` inside
the recommendation. Apply the same `stripChartTokens` + `<InlineCharts>`
pattern that the summary already uses.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 01:24:47 +02:00