A psychiatry-led clinic portal (Zürich) helping people recover from burnout and Long COVID. Clients track their recovery — daily check-ins, symptoms, sleep, techniques — and practitioners get the visibility they need to intervene early, run evidence-based programs, and analyze progress.
People struggling with burnout and Long COVID lack a structured way to track their recovery, and practitioners lack visibility to intervene early.
A health portal providing daily check-ins, symptom tracking, and progress analysis, with AI-powered insights for practitioners.
To give clients a structured way to track their recovery and practitioners the visibility to intervene early, run evidence-based programs, and analyze progress.
To become a comprehensive health portal for burnout/Long-COVID reintegration and longevity, with AI analysis of structured and unstructured data.
The stack has not been written down yet.
Investigate this project with Loki →Closed the last two open Dependabot alerts (esbuild #1 medium, #5 low) with two scoped esbuild floors in pnpm-workspace.yaml (0.18.20→0.25.12, 0.27.7→0.28.2); verify + build + drizzle-kit generate green locally, PR #78 CI "Verify & Build" pass, left for the scheduled Auto-merge workflow (gh auto-merge unavailable: no branch protection rules).
Closed the four open vitest/vite Dependabot alerts (incl. one high on vite): vitest+coverage to ^4.1.11 and vite declared as a devDependency (pnpm overrides don't reach auto-installed peers) resolving to 8.3.0, config moved to vitest.config.mts; PR #77 merged as 76389b9, Deploy green, prod 200.
Unblocked the dependency-update lane — the three react-hooks/purity errors failing Dependabot #73 are fixed by routing render-time cutoffs through one `msAgo()` helper in lib/utils, verified green on both the current plugin (7.0.1) and the bumped one (7.1.1); merged as efa1c12, Deploy green, prod 200.
Nothing — third consecutive autopilot run with no human message and no change in the repo (origin/main still e943567), so loop protection fired and no task was picked.
Autopilot review, second run in a row with no human message, found nothing high-impact and stopped (Stop brake + no-op loop protection): origin/main e943567 is unchanged since the last handoff; `pnpm verify` passes on it (eslint 0 warnings, tsc clean, 25 files / 651 tests passed); main CI is green; prod /de, /en and /api/health return 200.
Autopilot review found no high-impact work — origin/main (e943567) passes `pnpm verify` (prettier clean, eslint 0 problems, tsc clean, 651/651 tests), CI on main is green, prod (/de, /en, /robots.txt, /sitemap.xml, /api/health) returns 200, prior session-next (lockfile) already resolved by the committed pnpm-lock.yaml, and the local feedback-widget branch is already on main; stopped per the Stop brake (awaiting_user — no high-impact work remains; project healthy, only T2 dep-bump churn left: Dependabot PR #71 is red on 3 new react-hooks/purity lint errors).
Diagnosed appcron-surf-your-life-embed-backfill.service's HTTP 503 as the same known, intentional fail-closed behavior (8th+ recurrence) — confirmed origin/main's app/api/cron/embed-backfill/route.ts is unchanged since PR #33 and still returns 503 in production when OPENAI_API_KEY is unset; no repo bug, no code change made. Ran pnpm verify on the current branch (feat/loki-feedback-widget) as a general health check — clean.
Rule 0 — surfaced the pending OPENAI_API_KEY blocker (box re-checked: key absent, unit failed, timer enabled) and retired the deploy-wedge blocker to applied/ because #61 merged and ed98756 is serving.
Diagnosed the embed-backfill 503 as the known box-shaped blocker (no OPENAI_API_KEY in /opt/surf-your-life/shared/.env; route fails closed by design since #33; timer units are hand-installed on bitbaum, not repo-generated) — no code change, blocker file and memory updated with today's confirmation.
Fixed the root cause of the two-day deploy wedge that was blocking everything — migration 0023 tried to build partial unique indexes over two pre-existing duplicate booking rows and aborted every deploy, so #57-#60 never shipped; the reconciliation had to go inside 0023 itself (the runner stops at the first failure, so a 0024 would never be reached), keeps the earliest active row per the route's own 409 rule, cancels rather than deletes, and was proven against the production database inside a rolled-back transaction (UPDATE 1, UPDATE 0, both indexes created, ROLLBACK). PR #61 is green and deliberately held. Also corrected two wrong commands in my own blockers (the row to cancel, and a single-quote env parser against a mixed-quoting .env).
Diagnosed appcron-surf-your-life-embed-backfill.service's HTTP 503 as the same known, intentional fail-closed behavior (7th+ recurrence) — confirmed origin/main's app/api/cron/embed-backfill/route.ts is unchanged since PR #33 and still returns 503 in production when OPENAI_API_KEY is unset; no repo bug, no code change made.
Diagnosed the dispatched embed-backfill 503 as the same known box-shaped blocker (OPENAI_API_KEY still absent from /opt/surf-your-life/shared/.env; route fail-closes by design), and found the documented fix command has never been runnable — bitbaum runs sudo-rs, which refuses `sudo -e` on any user-writable path — so I rewrote the blocker with a tested sudo-free command; separately discovered a higher-severity T0: deploy has been wedged since 2026-09-06 because migration 0023 cannot build bookings_one_active_per_user_service_idx over two duplicate April booking rows, so #57 and #58 never shipped. No repo change was warranted — both causes are box-shaped and the code is correct.
Diagnosed the appcron-surf-your-life-embed-backfill.service failure (503) as the same known, intentional fail-closed behavior — origin/main's route.ts (deployed HEAD, ahead of this stale local checkout) returns 503 by design when OPENAI_API_KEY is absent in production; confirmed the key is genuinely missing from /opt/surf-your-life/shared/.env. No repo bug, no code change made.
Re-confirmed appcron-surf-your-life-embed-backfill.service's 503 is the same known, intentional fail-closed response (missing OPENAI_API_KEY on the box), not a repo bug. Verified live on 2026-09-06 03:00:02 UTC: unit failed with exit 22, timer still enabled, OPENAI_API_KEY absent from both /opt/surf-your-life/shared/.env and app/.env, journal shows the exact expected "[embed-backfill] OPENAI_API_KEY is not set" log line, and the app process itself is healthy (curl to 127.0.0.1:4009 returns 307, service active). Diffed origin/main's route.ts and embeddings.ts against the fail-closed design in PR #33 — unchanged despite the intervening ai-kit/mail-kit refactors (#49, #51, #54). Existing blocker file (openai-api-key-missing.md) already documents both exit options accurately; no repo changes made.
Re-confirmed appcron-surf-your-life-embed-backfill.service 503 is the same known, intentional fail-closed response (missing OPENAI_API_KEY on the box) — box-shaped, not a repo bug. Verified live: unit still `failed` (03:00:02 UTC today), timer still enabled, `grep -c '^OPENAI_API_KEY=' /opt/surf-your-life/shared/.env` still 0, and direct curl to the app (127.0.0.1:4009) returns a healthy 401 (not a crashed process). origin/main's route.ts (PR #33) unchanged. Pending blocker file openai-api-key-missing.md already documents this with two exit options; no repo changes made.
Rule 0 — pending blocker openai-api-key-missing.md is still unresolved (box re-verified: no OPENAI_API_KEY, unit failed, timer enabled), so I picked no task and instead corrected the blocker, whose central claim "no fallback provider exists for embeddings" is now false: OpenRouter serves embeddings and the box's existing OPENROUTER_API_KEY returned HTTP 200 with exactly 1536 dims on a :free model.
Confirmed the embed-backfill 503 is the intentional fail-closed branch (curled the route on the box: {"success":false,"error":"OPENAI_API_KEY is not set"}); box .env has GROQ/OPENROUTER/RESEND keys but no OPENAI_API_KEY. Repo code is correct, verify green, no changes made. New finding: OpenRouter now serves embeddings, and the box's existing OPENROUTER_API_KEY returns 1536-dim vectors on a :free model (verified HTTP 200) — a credential-free path exists, but paid OpenRouter models 402 ("account never purchased credits").
Diagnosing recurring embed-backfill 503 (in progress).
Re-confirmed appcron-surf-your-life-embed-backfill.service 503 is the same known, intentional fail-closed response (missing OPENAI_API_KEY on the box) already fixed and merged on origin/main in #33 — box-shaped, not a repo bug. Verified origin/main's route.ts still has the deliberate 503-when-key-missing logic and log line matching this dispatch's journal tail. Ran pnpm verify on the current branch as a sanity check (all green). No repo changes made.
Backward self-throttle (loop protection) fired instead of Pick — this is the 3rd+ consecutive autopilot cycle re-surfacing the identical openai-api-key-missing.md blocker with no human response between turns (prior cycles: 2026-09-02T03:03, 2026-09-03T13:36, now). Re-catting it again would be a low-value loop burning tokens with zero new information. Confirmed nothing changed (still bd7bc35, clean tree, blocker still pending, pnpm verify still fully green) and stopped without picking a task.