diet-guard/diet_guard/sync_merge/__init__.py
Krzysztof kuhy Rudnicki 24dbffc432 Sync the meal schedule as sched: fields on the budget record
Without this the schedule would be device-local, which is the failure this
whole feature has to avoid: the phone sets five meals, the PC still derives
four, and the PC's gate nags for a 12:00 checkpoint the phone never offered
and can never satisfy. So sync lands before either edit surface, not after.

The history rides the existing `budget` CRDT record as one
`sched:<YYYY-MM-DD>` field per entry, exactly like the budget's own `hist:`
fields. merge_record is per-field LWW over the *union* of field names and both
devices push the merged record, so a device that predates the feature relays
the fields untouched -- no coordinated release. There is a test for precisely
that: merging our push with a budget-only peer keeps both schedule entries.

Verified the two languages agree on the wire, not just in their own suites --
Python and Dart both emit
  {"sched:1970-01-01":{"f":8,"l":20,"n":4},"sched:2026-08-16":{"f":8,"l":20,"n":5}}
The Hlc is derived from the *parsed* timestamp on both sides, which matters
because the epoch fallback formats differently in each language
(1970-01-01T00:00:00+00:00 vs ...000Z) and a string comparison would diverge.

Two guards worth naming:

- A device with no history contributes no `sched:` fields at all, so an unset
  default can never outrank a peer's real schedule; and an empty merge result
  is never written back, so a pre-feature peer cannot erase a real history.
- Dart's `_syncBudget` synthesises a local record when the schedule has been
  edited but the budget never has -- `budgetToLog(null, ...)` returns an empty
  Log and would otherwise drop the schedule fields too. Its budget value
  carries an epoch stamp, so it loses every LWW race against a real edit.

sync_merge/_schedule.py and sync_merge_schedule.dart are separate modules
rather than additions to the budget adapters, which were at 186 and 170 lines
against the 250 cap. Each declares its own record-id constant so the Dart
pair does not import each other.

772 Python tests at 100% branch coverage, 619 Dart.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159b4E5hh512jYUeaJVNxfM
2026-08-16 14:49:08 +02:00

80 lines
2.4 KiB
Python

"""Entry <-> ``crdt_sync.Record`` adapters for diet_guard's cross-device sync.
diet_guard's own on-disk ``food_log.json`` format is unchanged (a
:class:`~diet_guard._state.DayLog`: date string -> list of entry dicts) --
only the GitHub-synced wire format and the cross-device merge algorithm go
through ``crdt_sync``'s ``Record``/``Log``/``Hlc`` primitives, the same ones
every other kuhy app that syncs this way uses (see ``~/crdt-sync``).
Split into three submodules for file size, along the same seams the tests
already use:
* :mod:`._daylog` -- the food log itself, including the legacy-format fallback
* :mod:`._budget` -- the budget record and its ``hist:`` history fields
* :mod:`._banks` -- the derived and curated halves of the food bank
Everything public is re-exported here, so ``from diet_guard.sync_merge import
parse_remote_log`` reaches the same object the flat module exposed. (The
``merge_logs`` these adapters feed is ``crdt_sync``'s, imported directly by
:mod:`diet_guard._sync` -- it was never defined here.)
"""
from __future__ import annotations
from diet_guard.sync_merge._banks import (
food_bank_to_log,
log_to_food_bank,
log_to_manual_bank,
manual_bank_to_log,
parse_remote_food_bank,
parse_remote_manual_bank,
)
from diet_guard.sync_merge._budget import (
_budget_hlc,
budget_to_log,
log_to_budget,
log_to_history,
parse_remote_budget,
)
from diet_guard.sync_merge._daylog import (
_entry_hlc,
_legacy_entry_id,
daylog_to_log,
entry_to_record,
log_to_daylog,
parse_remote_log,
record_to_entry,
)
from diet_guard.sync_merge._schedule import (
SCHEDULE_FIELD_PREFIX,
log_to_schedule_history,
schedule_fields,
)
__all__ = [
# Private helpers the tests reach for directly. Re-exported deliberately:
# they were importable from the flat module, and dropping them here would
# break those tests for a naming reason rather than a behavioural one.
"SCHEDULE_FIELD_PREFIX",
"_budget_hlc",
"_entry_hlc",
"_legacy_entry_id",
"budget_to_log",
"daylog_to_log",
"entry_to_record",
"food_bank_to_log",
"log_to_budget",
"log_to_daylog",
"log_to_food_bank",
"log_to_history",
"log_to_manual_bank",
"log_to_schedule_history",
"manual_bank_to_log",
"parse_remote_budget",
"parse_remote_food_bank",
"parse_remote_log",
"parse_remote_manual_bank",
"record_to_entry",
"schedule_fields",
]