5 Commits

Include renames

Author	SHA1	Message	Date
Lucas WintherandClaude Opus 5.5	5223a74013	docs: plan check-in goals task by task ... The goal control lives on the checklist only: "It repeats daily" already reaches it from a non-daily event, so a second entry point added nothing. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-13 13:03:46 +02:00
Lucas WintherandClaude Opus 5.5	1deb0cb4cb	docs: settle check-in goals and specify weekly and monthly tasks ... The goals draft stopped at three open questions; the owner answered them, and widened the scope to weekly and monthly chores with numeric targets. Both share one period engine, so they are specified together and built goals-first. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-13 12:57:37 +02:00
Lucas Winther	b0ade109a0	docs: specify event check-in goals ... Record weekly and event-wide targets so partial-week requirements can stay visible in Dailies without treating a satisfied week as event completion.	2026-10-03 20:22:48 +02:00
Lucas WintherandClaude Opus 5	98cd950e8e	Design recurring events, and plan the sourced ones ... The app can express a window closing and a day repeating, and nothing in between — daily.ts counts in days and stops there. That gap is already costing parsed data: arustats scheduleBosses is read and discarded because "a recurring rotation with no end is not a deadline" (docs/SOURCES.md:740). A rule fixes exactly that. Content repeating every fourteen days ends, at the latest, when its next occurrence opens — a boundary entailed by the interval rather than invented for a form. So an occurrence may state no end and still be a deadline, which is the distinction the spec turns on. Proposes it first on the reader's own events (F13), where the rule is typed rather than fetched: no parser, no review gate, no GachaEvent change, and a tested recurrence model in shared/ for the ingest side to adopt later. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-08-27 01:53:43 +02:00
Lucas WintherandClaude Opus 5	5ae559de97	docs: record the game order and the catch-up window ... The rules a future change could undo without noticing, written where whoever touches that area next will read them. Three of them are traps rather than descriptions. An absent `gameOrder` means the reader has never placed a game, not an empty order — reading it the other way hands every existing install a blank list, which is the `knownGames` mistake again. `games` is left in feed order deliberately, because the code that hides a reader's games diffs it. And the catch-up window bounds display and never storage: a fortnight's streak exists on one device and nowhere else, so nothing prunes the log against a window. The spec that produced the work goes in alongside, including the helper it specified and the implementation dropped, so the next reader sees why rather than wondering. Also corrects the test count in AGENTS.md, which said 772 and was already stale before this. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-08-20 06:02:16 +02:00