current_streak and longest_streak are reported swapped

This is the headline number on the whole product -- a habit tracker whose entire pitch (per this project's own README.md) is "correctness-focused ... timezone-aware streak tracking." Right now GET /habits/{id} and GET /habits both report current_streak and longest_streak swapped. A user who just broke a long streak and started a fresh 1-day run would see current_streak still showing their old best (misleadingly telling them they're fine) and longest_streak showing 1 (misleadingly erasing their actual best). This is not a cosmetic bug -- it actively lies to users about the one thing they open the app to check, in both directions at once.

habit_to_out (the function every habit-returning route funnels through) assigns current_streak=compute_longest_streak(dates) and longest_streak=compute_current_streak(dates, today) -- compute_longest_streak is wired to the current_streak field, and compute_current_streak is wired to the longest_streak field.

cd fastapi/habit_tracker source .venv/bin/activate python - <<'PY' import datetime as dt from fastapi.testclient import TestClient from app.main import app from app import models from app.database import SessionLocal, Base, engine

c = TestClient(app) c.post("/auth/register", json={"email": "demo2@example.com", "password": "supersecret1"}) token = c.post("/auth/login", data={"username": "demo2@example.com", "password": "supersecret1"}).json()["access_token"] h = c.post("/habits", json={"name": "Read", "timezone": "UTC"}, headers={"Authorization": f"Bearer {token}"}).json()

db = SessionLocal() today = dt.date.today() for offset in (10, 9, 8, 7): # an old 4-day run db.add(models.CheckIn(habit_id=h["id"], date=today - dt.timedelta(days=offset))) db.add(models.CheckIn(habit_id=h["id"], date=today)) # a fresh 1-day run db.commit()

compute_current_streak and compute_longest_streak are both pure, well-tested functions (see tests/test_streaks.py::test_pure_*) -- the bug isn't in the streak math, it's a one-line wiring mistake at the point where the two already-correct results get assigned to the two response fields. This is worth internalizing as a class of bug: the unit tests for the underlying logic can be 100% green while the integration point that hands results to callers is still wrong.

Read habit_to_out line by line against schemas.HabitOut's field names. Nothing needs to change in compute_current_streak or compute_longest_streak themselves.