mirror of
https://github.com/kuhyx/diet-guard.git
synced 2026-11-10 20:47:12 +01:00
Krzysztof kuhy Rudnicki
38d66a8492
The periodic diet-guard-sync.timer paid a network round-trip every ~15 min to approximate the two moments the shared log actually changes on this device. Sync now fires on those events instead: * before a lock -- already present in _cli_gate._should_lock, which pulls only when a lock is otherwise due, so a phone-logged meal clears the lock and a not-due tick never touches the network; * after a meal is logged here -- new _sync_events.publish_after_log, wired into all three write paths (_cli_log, _cli_gate, _mcp). This is what stops the PHONE nagging for a slot already logged on the PC, the mirror image of the rule that keeps the phone's own tick unconditional. The gate's publish sits in cmd_gate AFTER MealGate.run() returns, never in the unlock handler: that runs on the Tk thread with the window still up, so a hanging network call would keep the user locked in behind a successful log. It also covers the "Synced from another device" unlock, which hooking log_meal would miss. Accepted trade: a PC that is on but neither logging nor locking no longer pulls, so an inbound phone edit lands at the next log or lock rather than within 15 min. Bounded by slot spacing -- an unlogged day raises a lock. install.sh now disables and removes the installed timer (guarded, since a fresh machine has no such unit and `disable` would abort under `set -euo pipefail`); the .service stays for manual one-off ticks. Every test that logs a meal would otherwise reach the network through the new call sites, so conftest patches publish_after_log at each of the three call sites -- not on _sync_events, so test_sync_events still exercises the real helper. Suite stays at ~8s, which is the actual leak detector. Two files had to be split to commit at all, since file-length passes filenames and both were already over the 250-line cap: _cli.py 466 -> 207, + _cli_args.py, _cli_init.py, _cli_log.py _mcp.py 370 -> 194, + _mcp_server.py (singleton + annotations), _mcp_read.py Their conftest/test patch targets moved in the same commit; a stale target redirects nothing and fails open. Verified: 701 python tests at 100% branch coverage, 555 flutter tests, `python -m diet_guard sync` -> 402 entries/exit 0, `gate --check` -> exit 0, all five MCP tools still register, live ~/.local/share/diet_guard byte-identical. Over-cap files: 44 -> 42. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RA9ynjqXPnexRQnR5oAuCC
50 lines
1.8 KiB
Python
50 lines
1.8 KiB
Python
"""The MCP server singleton and its shared tool annotations.
|
|
|
|
Extracted from :mod:`diet_guard._mcp` to hold the repo's 250-line cap. It has
|
|
to be a *separate* module rather than a section of ``_mcp``: the tool modules
|
|
need ``mcp`` at import time to register themselves with ``@mcp.tool``, so
|
|
keeping the singleton alongside them would make every split a circular import.
|
|
|
|
Also the single place stdio logging is configured, which is load-bearing:
|
|
STDOUT carries the MCP JSON-RPC protocol frames, so a stray write there
|
|
corrupts the stream and kills the session. Everything logs to STDERR.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
import logging
|
|
import sys
|
|
|
|
from mcp.server import MCPServer
|
|
from mcp.types import ToolAnnotations
|
|
|
|
# Log to STDERR only -- STDOUT carries the MCP JSON-RPC protocol frames, so a
|
|
# single stray stdout write would corrupt the stream and kill the session.
|
|
logging.basicConfig(
|
|
level=logging.INFO,
|
|
stream=sys.stderr,
|
|
format="%(asctime)s [%(levelname)s] diet-guard-mcp: %(message)s",
|
|
)
|
|
logger = logging.getLogger("diet_guard._mcp")
|
|
|
|
mcp = MCPServer("diet-guard")
|
|
|
|
# Machine-readable versions of what the docstrings already say, so a client
|
|
# can decide what to run unattended. The day a "read" tool starts writing,
|
|
# these annotations are what has to change with it.
|
|
READS_ONLY = ToolAnnotations(
|
|
read_only_hint=True,
|
|
idempotent_hint=True,
|
|
open_world_hint=False,
|
|
)
|
|
# log_meal is the one tool that writes. It appends and never rewrites or
|
|
# deletes, so it is not destructive; it is not idempotent either, because a
|
|
# second confirmed call logs a second meal. It reaches Open Food Facts when
|
|
# macros are not supplied, which is exactly what open_world means.
|
|
APPENDS = ToolAnnotations(
|
|
read_only_hint=False,
|
|
destructive_hint=False,
|
|
idempotent_hint=False,
|
|
open_world_hint=True,
|
|
)
|