Krzysztof kuhy Rudnicki
802ee0fe6d
Flutter's Linux embedder manages ~20fps at 3840x2160 -- measured on a stock `flutter create` counter app, so it is the toolkit rather than this code -- where the same Dart rendered by Chrome sustains ~144fps (evidence in ~/todo/docs/desktop-performance-findings.md). The desktop target therefore becomes a Flutter *web* build; Android is untouched. `dart:io` does not fail a web *compile* -- it resolves to a stub that throws at runtime -- so every platform edge moves behind a conditional export rather than being discovered later as a blank white window: - storage: `document_store*.dart`, files on Android and IndexedDB in the browser (mirrored to the desktop wrapper, which is what makes a wiped Chrome profile recoverable). Document names stay the exact pre-web filenames so an installed phone keeps reading its existing log. - photos: `blob_store*.dart` plus `attached_image*.dart`, since `Image.file` cannot resolve an IndexedDB key. The picker itself has web support; what changed is the storage and display model. Camera *capture* is genuinely lost on desktop -- and photos never crossed devices anyway, `imagePath` being stripped before push. - scheduling: `background_tasks*.dart`. A browser has no WorkManager equivalent -- a closed tab runs nothing -- so the desktop runs an in-page 5-minute check while its window is open. That loses nothing on the PC, where `diet-guard-gate.timer` already locks the screen on an unlogged slot, which is strictly stronger than a notification. - notifications: `notification_backend*.dart`, the browser Notifications API in place of flutter_local_notifications. - the GitHub token: `token_vault*.dart`. On web it is *not* held by the browser at all -- flutter_secure_storage's web backend is WebCrypto-wrapped localStorage with the wrap key beside the ciphertext, which is obfuscation, not encryption at rest -- so the desktop wrapper owns it and proxies the API (`github_client_factory*.dart`). `Platform.isAndroid` itself throws on web, so every platform branch now tests `kIsWeb` first; the battery-optimization row (permission_handler, no web implementation) is hidden off Android. The desktop pushes under device id `desktop`, not `phone`: sharing an id would have made the two devices overwrite each other's pushed log on every tick. The Python side enumerates device directories generically, so it needs no change. Tests move onto the same seams -- the file-backed stores keep the atomicity and unreadable-file guarantees where they belong. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .github/workflows | ||
| app | ||
| diet_guard | ||
| docs | ||
| scripts | ||
| .gitignore | ||
| .mcp.json | ||
| .pre-commit-config.yaml | ||
| CLAUDE.md | ||
| diet-guard-gate.service | ||
| diet-guard-gate.timer | ||
| diet-guard-sync.service | ||
| diet-guard-sync.timer | ||
| install.sh | ||
| pyproject.toml | ||
| README.md | ||
| requirements.txt | ||
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)
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.log_meal(description, grams=, kcal=, protein=, carbs=, fat=, slot=, confirm=False)— gated write: withconfirm=Falseit previews the resolved nutrition and target slot and mutates nothing; onlyconfirm=Trueappends 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.