The changelog has two tiers, each tied to git: short entries shown after
a reload, and release notes summarised from the history and specs.
Ridu Weekly (1,300) and the Weekly Routine (10) are now sourced. The
first guesses of 2,100 and 10 were checked against the owner's links.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The product, storage and design records now cover F17. They say why the
task and amount stores, unlike the custom-event store, never filter on
load, which is the rule a future store would most likely copy wrongly.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The product, storage and design records now say what a goal is, why it
never marks an event done, and why an unreadable goal is kept rather than
stripped. That last rule is the one a future cleanup would most likely
undo by mistake.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
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]>
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]>
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]>
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]>
