Weekly/monthly completion rate silently excludes today

GET /habits/{id}/stats is the number a user sees on any "how am I doing this week" screen. Right now, a check-in made today never counts toward this week's (or this month's) completion rate -- it only starts counting tomorrow. A user who checks in every single day will see their weekly completion rate permanently one day behind reality, which reads as "the app doesn't notice when I show up." This is exactly the kind of quiet correctness bug that erodes trust in a habit-tracking product without ever throwing an error -- nobody files a support ticket for "my percentage looks 1/7th too low," they just stop trusting the number.

habit_stats computes the trailing window as window_start = today - timedelta(days=days), then window = {window_start + timedelta(days=i) for i in range(days)}. For a 7-day week, this produces the date range [today-7, ..., today-1] -- today itself is never included in the set.

cd fastapi/habit_tracker source .venv/bin/activate # or: python3 -m venv .venv && pip install -r requirements-dev.txt python - <<'PY' from fastapi.testclient import TestClient from app.main import app c = TestClient(app) c.post("/auth/register", json={"email": "demo@example.com", "password": "supersecret1"}) token = c.post("/auth/login", data={"username": "demo@example.com", "password": "supersecret1"}).json()["access_token"] h = c.post("/habits", json={"name": "Meditate", "timezone": "UTC"}, headers={"Authorization": f"Bearer {token}"}).json() c.post(f"/habits/{h['id']}/checkins", json={}, headers={"Authorization": f"Bearer {token}"}) # check in today print(c.get(f"/habits/{h['id']}/stats?period=week", headers={"Authorization": f"Bearer {token}"}).json()) PY

-> observe "completed_days": 0 even though you just checked in

window_start is off by one calendar day, which shifts the entire window back by a day instead of shrinking or growing it symmetrically. It's the classic "did I mean N days back inclusive of today, or N days back exclusive" boundary mistake -- the same category of bug the rest of this project's compute_current_streak/compute_longest_streak functions were clearly written carefully to avoid (see README.md's "today not yet checked in" discussion), which makes this one stand out as an oversight rather than a design choice.

Look at how window_start relates to days and to today. Ask: for a 7-day window that must include today, what's the earliest date in that window? Compare against how compute_current_streak and compute_longest_streak already reason about "today" as an inclusive endpoint elsewhere in this same file.