lucasw89/gacha-event-tracker
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(daily): ship daily detection off, and say it's experimental

Browse Source 
Dailiness is guessed from the source's wording, which is a weak signal
and wrong in both directions. Guessing on a reader's behalf and hoping
they notice is the wrong default for a checklist they may build a streak
on, so `detectDaily` now starts false and the control carries an
Experimental tag saying what it does and doesn't know.

The default applies to new readers only — a stored `prefs` keeps its
value, because switching it off under someone who has been ticking
auto-detected checklists would pull those chips out of the strip with no
explanation. Nothing is deleted either way.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This commit is contained in:
Lucas Winther
2026-08-16 20:57:26 +02:00
co-authored by Claude Opus 5
parent 3a70672d22
commit 3434ac02cf
4 changed files with 28 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CLAUDE.md
+6 -3
View File
@@ -211,9 +211,12 @@ event's length. It adds **no schema field**, so the feed contract is untouched.
- **A repeating event the reader marked done leaves the strip.** They have said there is nothing
left to do; keeping a tickable chip for it is the app arguing with them. Their logged days are
untouched, so unmarking it brings the chip and the streak straight back.
- **Detection is a default, not a verdict.** The reader can mark any event as repeating, or unmark
one detection got wrong (`progress.daily`, resolved by `resolveDaily`), and `prefs.detectDaily`
switches the guessing off entirely. Store an override only when it *disagrees* with detection —
- **Detection is a guess, not a verdict — and it ships off.** `prefs.detectDaily` defaults to
`false` and the control is labelled experimental: wording is a weak signal and gets it wrong in
both directions, so a new reader opts in rather than out. The default moves nothing for an
existing reader, whose stored `prefs` wins. The reader can mark any event as repeating, or unmark
one detection got wrong (`progress.daily`, resolved by `resolveDaily`), whether the guessing is
on or off. Store an override only when it *disagrees* with detection —
recording agreement would freeze today's guess and stop a better parser from ever reaching that
event. Neither control ever deletes a mark or a logged day, so both are reversible.