Build "The Architect" — personal health & habits tracker with coaching

You are building a self-hosted personal tracking app from scratch. Build it, run it, verify it works, then stop and report. Do not over-engineer. Do not add features I did not ask for. Every feature below is required; anything not listed is out of scope.

What this is

A private web app that replaces an Excel/Google Sheets tracker. I log daily health data (weight, sleep, alcohol, food, training), submit it, and immediately query it — and the app gives me coaching advice in a specific voice, backed by my actual data.

The value is NOT the UI. It's the loop: log → submit → query → get a verdict.

Hard constraints (do not change these)

• Stack: Next.js (App Router) + React + TypeScript, DuckDB for storage.
• Use the @duckdb/node-api (or duckdb) Node bindings with a single local .db file — NOT a separate database server. DuckDB is embedded, keep it that way.
• No Postgres, no SQLite, no ORM. DuckDB is the requirement.
• Single user. This is one person's private health data. Auth = one password via a SITE_PASSWORD env var + an httpOnly session cookie. Nothing more. No OAuth, no multi-user, no signup flow.
• Self-hosted on one VPS. Dockerized. The .db file lives in a mounted volume (survives container restarts). No cloud DB, no S3.
• LLM integration for coaching: the app calls an OpenAI-compatible endpoint to generate the coaching text. The endpoint URL and API key come from env vars (LLM_BASE_URL, LLM_API_KEY, LLM_MODEL). Default LLM_MODEL = deepseek-v4-pro. Do NOT hardcode any API key. Do NOT call the LLM for anything except coaching text.
• All UI and coaching text is in ROMANIAN (technical terms may stay English).
• No charts/graphs in the MVP. Numbers in tables are enough. A chart library is out of scope until the logging+query+coaching loop works.

Data model — the daily log (this is the exact schema, use it verbatim)

One table, daily_log, one row per day. Columns:

• date (DATE, primary key)
• weight_kg (DOUBLE, nullable) — target 80
• bmi (DOUBLE, nullable)
• body_fat_pct (DOUBLE, nullable)
• water_pct (DOUBLE, nullable)
• protein_pct (DOUBLE, nullable)
• basal_metabolism_kcal (DOUBLE, nullable)
• visceral_fat (DOUBLE, nullable)
• muscle_kg (DOUBLE, nullable)
• bone_mass_kg (DOUBLE, nullable)
• fell_asleep (VARCHAR, nullable) — e.g. "23:49"
• wake_up (VARCHAR, nullable) — e.g. "07:20"
• sleep_total_min (DOUBLE, nullable) — minutes
• rem_min (DOUBLE, nullable)
• deep_min (DOUBLE, nullable)
• light_min (DOUBLE, nullable)
• bpm_rest (DOUBLE, nullable)
• alcohol_units (VARCHAR, nullable) — free text, e.g. "4x500ml bere"
• breathing_score (DOUBLE, nullable)
• last_meal (VARCHAR, nullable) — e.g. "< 20:00", "OMAD - 12:30"
• energy_1_10 (DOUBLE, nullable)
• sport (VARCHAR, nullable) — e.g. "Freeletics 25min", "Nu"
• body_score (DOUBLE, nullable)
• justrite_note (VARCHAR, nullable) — work note
• personal_note (VARCHAR, nullable) — personal/reality note
• elenor_note (VARCHAR, nullable) — Elenor task note
• created_at (TIMESTAMP, default now)

Every field is optional EXCEPT date. Empty is better than guessed — never invent values the user did not enter.

Features (MVP — build exactly these, in this order)

1. Log entry — a form for today's date with all the fields above. Submit = upsert (insert or update) the row for that date. Show confirmation after save.
2. Query — a plain SQL text box that runs read-only SELECT queries against the DuckDB file and renders results as a table. This is the "interoghez imediat" feature. Wrap it in try/catch and show the error message on bad SQL. Only SELECT — block INSERT/UPDATE/DELETE/DROP/ALTER/CREATE and any multi-statement.
3. Coaching — a "Dă-mi verdictul" button. It:
4. pulls the last 7 and last 30 days from daily_log,
5. computes simple aggregates (7-day and 30-day average weight, average sleep, average bedtime, total alcohol, number of sport sessions, latest body_score),
6. sends ONE LLM call with those aggregates + the coaching system prompt below,
7. renders the response as markdown.
8. If the LLM call fails, show the error and the raw aggregates (never fake a verdict).

The coaching voice (this is the most important part — encode it exactly)

The LLM system prompt for the coaching feature must be:

You are THE ARCHITECT — Remus's personal high-performance coach. You analyze his
tracked health data and give him ONE verdict and ONE action. Reply in Romanian,
short, direct, no fluff, no motivational poster language.

Data context you will receive: his last 7 and 30 days of weight, sleep, bedtime,
alcohol, sport, and body score, already aggregated.

Rules:
- Format: Verdict (1-3 lines) → ONE action for the next 24-48h → the reason why,
  grounded in HIS numbers, not general advice.
- Never give advice without citing his data.
- Known targets and patterns (apply these):
  - Weight target 80 kg. He has been stuck ~91 kg for months.
  - Sleep target > 7.5h, bedtime < 23:00. Bedtime is THE lever: when he falls asleep
    before ~23:00 his sleep score is 85+; at 02:00 it drops to ~68 and REM collapses
    to ~40 min. Weight and visceral fat follow the sleep window, not the diet.
  - Visceral fat stuck at 15. Alcohol (esp. evening beer) directly worsens next-day
    BPM, REM, and weight.
- If he slipped (weight up, bad sleep, drinking): one Dalio principle + move on.
  Do not moralize. Name the one thing that will fix the trend, not everything.
- Never invent REM/deep/sleep data he did not log.
- End with the single measurable action, not a list of 5.

Build order & verification (you must actually do these, not describe them)

1. Scaffold Next.js + TypeScript. Add DuckDB. Create the table on first run.
2. Build the log form + upsert. Verify: insert a test row via the form, confirm it's retrievable via SELECT * FROM daily_log.
3. Build the SQL query box. Verify: run SELECT * FROM daily_log LIMIT 10 and see the test row. Run a destructive statement and confirm it's blocked.
4. Build the coaching feature with the system prompt above. Verify: call it against a couple of seeded rows and confirm the output is Romanian, short, and cites the data.
5. Dockerize. Put the .db in a mounted volume. Verify: restart the container and confirm data persists.
6. Write a short README.md with: how to run locally, env vars needed (SITE_PASSWORD, LLM_BASE_URL, LLM_API_KEY, LLM_MODEL), and the deploy notes (Docker, volume, reverse proxy).

At the end, report: what you built, what you verified (with the actual command output), and the exact docker run/compose command for production.

Out of scope (do not build)

Charts, multi-user, OAuth, mobile app, reminders, notifications, export to Excel, historical migration from his old sheets, any ML/forecasting. One person, one loop: log → submit → query → verdict.