Go to file
Krzysztof kuhy Rudnicki fe28c8a395
Some checks are pending
pre-commit / pre-commit (push) Waiting to run
Tests / test (3.10) (push) Waiting to run
Tests / test (3.11) (push) Waiting to run
Tests / test (3.12) (push) Waiting to run
release-apk / release (APK) (push) Waiting to run
Step Dart dates by the calendar, not by 24 hours
A Duration is an absolute span, so stepping a local DateTime by
Duration(days: 1) moves 23 or 25 hours across a DST boundary and lands on
the wrong wall-clock day. Under Europe/Warsaw, spring-forward 2026-03-29:

  lastCompleteDay(2026-03-30)  ->  2026-03-28 23:00, the day before
                                   yesterday, not yesterday
  weeksAgo: 1 from 2026-04-01  ->  2026-03-24 23:00, a Tuesday, so the
                                   wrong ISO week entirely
  a 03-27..03-31 period        ->  emits four day keys, silently dropping
                                   2026-03-31

The Python half computes all three correctly, because timedelta on a date
has no clock to drift against. So for about two weeks a year the phone and
the PC would report different averages for the same log -- exactly the kind
of device-local divergence the shared-source-of-truth rule exists to stop.

Passing out-of-range components to DateTime's constructor normalizes on the
calendar (day 0 is the previous month's last day), which is what timedelta
already does. The same fix goes to day_status_service's streak walker: it
had the identical pattern and predates this feature, so a streak that
spanned the clock change could break when it should have held.

None of the existing tests could see any of this -- every fixture date sits
in a DST-free span -- so the regression tests use dates that straddle
2026-03-29 and assert on the calendar day rather than the DateTime, which
keeps them meaningful whatever zone the runner is in. Verified they fail
against the old arithmetic before fixing it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DjJqpcEsaV5WRhPXyxCThd
2026-08-09 15:06:41 +02:00
.github/workflows Build and publish a signed APK on every push to main 2026-08-04 20:55:14 +02:00
app Step Dart dates by the calendar, not by 24 hours 2026-08-09 15:06:41 +02:00
diet_guard Show weekly and monthly average intake on both devices 2026-08-09 14:59:40 +02:00
docs Add change explanation: desktop-web-build 2026-07-20 17:27:42 +02:00
scripts Stop two keyboard tests hanging, and make the CI mirror mirror CI 2026-08-04 21:50:15 +02:00
.gitignore Add CI-mirror pre-push gate + requirements-sync check 2026-07-11 17:58:49 +02:00
.mcp.json Add MCP server exposing diet status + a gated log_meal 2026-07-10 21:36:46 +02:00
.pre-commit-config.yaml Sync meals and the food bank through Firebase, mirroring to GitHub 2026-08-05 08:35:21 +02:00
CLAUDE.md Show weekly and monthly average intake on both devices 2026-08-09 14:59:40 +02:00
DESIGN_AUDIT_TODO.md Add a design-rules audit against the new safe-design-rules checklist 2026-07-21 15:25:20 +02:00
diet-guard-gate.service Extract diet_guard from testsAndMisc as a standalone repo 2026-06-22 12:18:39 +02:00
diet-guard-gate.timer Extract diet_guard from testsAndMisc as a standalone repo 2026-06-22 12:18:39 +02:00
diet-guard-sync.service Add cross-device log sync (Python half of Milestone 3) 2026-06-22 19:36:27 +02:00
diet-guard-sync.timer Add cross-device log sync (Python half of Milestone 3) 2026-06-22 19:36:27 +02:00
install.sh Add budget-adherence calendar, streaks, and freely-editable synced budget 2026-07-13 21:31:45 +02:00
pyproject.toml Make Firebase the visible sync path, and GitHub the mirror it now is 2026-08-05 08:55:12 +02:00
README.md Show weekly and monthly average intake on both devices 2026-08-09 14:59:40 +02:00
requirements.txt Make Firebase the visible sync path, and GitHub the mirror it now is 2026-08-05 08:55:12 +02:00

diet_guard

A log-to-unlock gate: locks the desktop until a meal is logged once a meal slot (08:00 / 12:00 / 16:00 / 20:00) has elapsed without one, and tracks a sealed daily calorie/macro budget.

Install

bash install.sh

This installs the package + dependencies into system Python's user site-packages (the systemd service runs /usr/bin/python directly, not a venv — see CLAUDE.md), installs the systemd user timer, seals your daily budget, and locks the budget file immutable.

Usage

python -m diet_guard init          # one-time: compute and seal today's budget
python -m diet_guard gate --demo   # test the lock window (safe, closeable)
python -m diet_guard averages      # weekly/monthly average kcal vs budget

Averages

averages prints the mean kcal/day for this week, last week, this month and last month, each labelled under / slightly over / very over.

Three rules make the number honest, and all three are mirrored in the phone app and the gate's History tab:

  • the mean is over logged days only -- a day you forgot to log is not a zero-calorie day, and averaging it in as one would make every gap in the log read as "well under budget";
  • the yardstick is the mean of the budgets that applied on those same days, not today's budget, so editing the budget never retroactively reclassifies a past week (same reason the calendar uses .budget_history);
  • today is excluded -- every period ends at yesterday, because a half-logged today drags the mean far enough to flip the band. On a Monday "this week" therefore reports no logged days yet rather than a flattering number.

The band boundaries are the calendar's own (at or under budget / up to 20% over / more than 20% over), so a period and its day cells can never disagree about what "over" means.

The timer runs the gate automatically every ~30 minutes; no manual invocation is needed once installed.

MCP server

An optional Model Context Protocol server lets an MCP client (Claude Code and its subagents) query today's intake and log meals as typed tools instead of shelling out to the CLI. It runs in its own venv (~/.venvs/diet-guard-mcp) so the mcp SDK never touches the dependency-light system/CLI python path.

Tools:

  • get_status — today's consumed kcal + macros, the consumption band (on track / approaching limit / OVER BUDGET, or none when no budget is sealed), plus due / logged / current meal slots.
  • list_today — today's logged meals (description, kcal, macros, source, slot).
  • get_slots — the day's fixed meal slots and the current one.
  • get_averages — average kcal/day for this/last week and this/last month, each with its band (under / slightly_over / very_over). Returns the intake and the band only — never the period's average budget.
  • log_meal(description, grams=, kcal=, protein=, carbs=, fat=, slot=, confirm=False) — gated write: with confirm=False it previews the resolved nutrition and target slot and mutates nothing; only confirm=True appends the entry. The gate is intrinsic — never add this tool to a permission allowlist, since a client's auto-approve mode would otherwise bypass the human confirmation.

The read tools deliberately never expose the raw daily budget number (only the qualitative band), nor the sealed .budget file, the shared HMAC key, or the sync token — the budget stays hidden by design.

Setup:

bash scripts/setup_mcp.sh   # create the venv and install diet_guard[mcp]

Then restart Claude Code in this repo and approve the project MCP server (registered in .mcp.json).

Development

python -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/pre-commit install && .venv/bin/pre-commit install --hook-type pre-push
.venv/bin/python -m pytest diet_guard/tests/ --cov=diet_guard --cov-branch --cov-fail-under=100

See CLAUDE.md for scheduling details and production deployment gotchas, and docs/design.md for the original feature spec.