The tour now floats over the page it describes and must be finished
before the app can be used: new readers straight after setup, returning
readers on their next visit, and anyone who saw the earlier tour. The
page behind stays visible and scrollable but inert.
"Pick a layout" (on the Checklist) and the Timeline step switch Relaxed /
Structured and New / Classic in place; the selected look is kept.
Returning readers start on Relaxed. A replay from Settings stays
optional and closable.
redesignTourSeen now records new / returning / replay / 2026-10-tour-2;
any other value means not yet taken.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Game8 codes pages for Star Rail, ZZZ, Wuthering Waves, Endfield, NTE,
P5X, Chaos Zero Nightmare and Umamusume, read by one table parser told
each page's active-codes heading. Each page was fetched once and pinned
as a fixture. Infinity Nikki's page is stale (still titled July 2025)
and is left out.
The Codes tab links the publisher's own redeem page where one exists
(Genshin, Star Rail, ZZZ) and gives the in-game route for every game,
and names the server on a redeemed checkbox only when there are two.
Settings uses the width of a large screen: content up to 1320px and the
menu column running the full height.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new reader app replaces the old UI: Checklist with a rail (focus
pills, Next to expire, today's dailies, pinned routines), Timeline in a
new and a classic look, Routines, Archive and a Settings area, in a
Structured (default) and a Relaxed interface. It follows the approved
Round 6 B and Round 7 mockups, corrected screen by screen with the owner.
Reader data moves to a v2 store (gacha-tracker:v2:*). Existing v1 data
is migrated on first load, a recovery copy is written first, and the v1
keys are never removed, so a rollback finds them unchanged. Redeem codes
for Genshin arrive as their own feed.
Also: live's urgency ramp, editable per theme; completion and
section-complete fireworks; a returning-user tour; the design mockups,
specs, plans, reviews and handoff record.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Beyond the Rails rolls on Asia's reset, and the header took the soonest
reset of every chip, so a Europe NTE reader read "next reset in 1h" at
20:00 UTC when their day rolls in seven. The countdown now counts the
reader's own clocks. Found in the whole-branch review.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Routine gains clock?: Region, code only. Its day key, its countdown and
its catch-up days are cut on that server's reset rather than the
reader's: for a cycle that ends at one instant on every server. Make it
mine leaves it behind.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add a task gains "Every N days": a length of 2 to 366 days and the date a
cycle began. Editing one keeps its length and start, and "days needed" is
capped at the cycle's length.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A third period, { unit: "cycle", days, from }, cut in day-key space like
weeks and months, so each game's per-server reset carries over. Tasks on
it are tallied and switched apart (showCycleTasks, on by default), show
the days left in their chip, and the lower row's heading now names the
periods it holds.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Most shops sell both banners' pulls. A shop's premium line is offered like any
built-in; its standard line (Acquaint Fates, Star Rail Pass, Master Tapes,
Resonite Crystals) only when the reader switches on Include standard-banner
pulls under the built-ins switch. A new pref, standardPulls, absent meaning
off, so no install gains anything until it asks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Built-ins now include monthly items, so the strip's question, Settings and Your
own say "weekly and monthly". The per-game tooltip quotes the oldest source
date when a game has several.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The strip's Edit panel lists each game's chore, then its built-ins, then its
events, each with Stop tracking, and Track · N offers everything a game could
track and does not. Your own lists every built-in of the games that are on,
untracked ones included and marked, so none is off with no way back.
Renames Remove from dailies / Add an event to Stop tracking / Track.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With "Comes back after a wait" and "I don't know when it ends" both
chosen, the end field is hidden, yet the still-needed line asked for "an
end date". It now names the way out: an end date, or another repeat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Readers who knew what they wanted could not see which answers in Add an
event or Add a task produced it. Both add forms now open with a row of
examples (templates.ts) that set the form's shape only: kind, how often,
how it repeats, how it is measured. Never a name, date, target or game,
and no date is guessed, so nothing an example set can be saved unread.
Both forms also had a pass: plain words and pills for how often and
repeat, the name asked first and the kind after the dates, each message
beside its field, and a "Still needed" line read from the same check that
disables Save. The event form's derived state is now one pure function,
eventFormState, so the examples are proved to complete into a saveable
event without a click.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What you see drew a checkbox per game for built-ins, a list that grows
with every game and every built-in, and offered no per-game answer for
chores at all. Each now has one switch, a line naming the games that
differ, and Choose games to change them, in the focus chip's colours.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Chores had one global switch and built-ins only a per-game opt-in, so the
two answered the same question two different ways. perGame.ts is now the
one rule for both: a global answer, then the games that differ.
Nothing is migrated. routineGames keeps its meaning as the built-ins'
on-list and an absent showRoutines still reads as off, so every reader's
answers, and an older cached tab, see what they saw before. The strip
stops asking about one game once the reader has answered for all.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Giving Genshin's "To Temper Thyself and Journey Far" its five-of-seven goal
meant finding it in the list, opening its sheet, saying it repeats and only
then setting the goal. The strip now has an Edit mode beside Catch up that
lists its events by game with their goals, opens the sheet's goal control in
place, and adds any running event a game at a time. It calls the same
setDaily/setGoal the sheet does, so it can store nothing the sheet would not.
Weekly and monthly tasks are not due tonight, so they move to a row under the
dailies, and each period can be switched off (showWeeklyTasks,
showMonthlyTasks; default on, so nothing disappears on upgrade).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A card above the lists shows the entries the reader hasn't seen, five at
most; Got it records the newest. The footer opens the changelog: release
notes with their commit range and specs, the short entries each covers,
and the rest by month.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Make it mine's copying was inline in App and untested; it is now a pure
function with a test, so a change to either store can't make the copy
silently arrive empty. The question's buttons now say what they answer
when heard out of context. The prefs block and the spec now match what
shipped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A reload can be served the browser's cached feed for minutes. The button
beside the data's age asks the server past that copy, swaps in a newer
feed without reloading, and says honestly what came back. Newer is
judged on events and sources, never the build stamp. The age now says
"just now" rather than "ended ago" when a fresh feed is a moment ahead
of the page's clock.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The switch sits beside the daily chores and answers the strip's question
too. Built-ins are listed with a link to their dated source. Make it mine
copies one into the reader's tasks, numbers and ticks included, and hides
the original while the copy exists. It's additive, so deleting the copy
brings the original back as it was.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The strip asks once, in one line, about a game on screen that has
built-ins. Yes puts them beside its dailies, drawn and counted like the
reader's own tasks, with a tooltip giving the source's date.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review found that import and edit rebuilt a task from this build's parse.
That stripped any field it didn't know, and import dropped a newer
version's task entirely. Both now keep the record as stored and validate
only to display it.
An event whose goal is points can't be ticked, so it no longer counts as
waiting today: it counts with its week. The month-day field reset
itself to 1 when emptied; it now keeps a draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In the rail, three counts on one heading line wrapped it and broke the
reset countdown across two lines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
They live in Your own, beside the reader's games and events. Every field
has a default the reader can accept unread (weekly, from Monday, ticked
off once) except the target, which nobody can guess for them. Save is
offered only when the store would accept what was typed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Some events want a number of points rather than a number of days. The
goal control gains Days and Points. Switching period keeps the measure
and the number, and the sheet keeps this period's number editable in
place. A target is capped where the schema reads it back, so a huge
number can't silently become no goal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tasks sit at the end of their game's group and are counted by their own
period, so a chore due Sunday is not "waiting on you today" every
morning. A number chip opens an editor under the strip instead of
ticking, since a chip is one target. Catch up offers last period's
number the way it offers yesterday's tick.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Weekly chores like 2,100 activity points are a number, not a count of
days, and monthly ones need a month. The status shape now carries its
measure and period start, so tasks can reuse it whole.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review found three ordinary actions that deleted a goal this build could
not read: "It repeats daily", pressing an already-pressed Off, and "not
daily" without saying so. Only "not daily" clears a goal now, and its
warning keys off what is stored, not what parses.
The count field was bound straight to the goal, so emptying it snapped
the old number back and typing appended to it. It now keeps a draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The goal sits under the checklist, where its count shows. With a goal
set, the caption counts against it instead of calling unticked days
missed. Reaching an event-wide goal offers Mark event done but never
takes it. Saying "not daily" says up front that it removes the goal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An event wanting five days of seven stays in the strip all week with its
count on the chip. Once the week is met it reads as done this week, and
it counts toward the header without a tick being invented. The burst
now watches today's ticks, so meeting a week by backfilling stays quiet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every server's reset hour and offset was checked against it, so it is
credited beside the schedules' sources.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Its summary set focus-visible:outline-none, which left a keyboard
reader with no visible focus there. It now shares the settings groups'
focus rule and chevron.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A sticky name wider than what was left of its bar got pushed out at its
start, so bars ending today read "e - Part 2". Those are the most urgent
events on the board. Capping the name to the visible run makes it
truncate at its end instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Forty minutes left of a two-week event is under half a tick, so the
meter rounded it down to an empty strip. The most urgent rows and the
headline looked like events that were already over.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a phone a single truncated line cut most titles mid-word, and the
title is what a reader scans the list for.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fullwidth plus is in neither Chakra Petch nor Public Sans, so it fell
back to whatever font the device had and showed as an empty box on some.
It is now an SVG stroked like the other icons.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Derive source pull date from confirmation and recent content updates, preventing recently updated sources from displaying as pulled never or pull overdue.
The footer's staleness notice is an instruction, and the only remedy it
offers is "go and check that game's source page". That is not something a
reader can act on for a game they turned off and cannot see a single row
of — and with nineteen lanes, naming eleven they do not play buries the one
they do. A new lane arrives switched off (F8), so an untouched install was
being warned about most of the catalogue.
Scoped in two places, not one: the named list, and the count the
summarising branch measures against. Without the second, that branch would
never fire for a reader with most of the calendar off and they would get a
list where a sentence was the readable answer.
The notice now also states whose games it counted, in the words NextUp
already uses for the same set. Narrowing what the footer measured while
still printing "nothing has refreshed" would turn a claim about four games
into one about eighteen, in the one paragraph on the page whose job is
being trusted about age.
The headline age and the credits stay whole: the first is a fact about the
feed and feeds the bug form, the second is attribution owed to every source
we read regardless of what is on screen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Today's dailies carries two different things: each game's standing chore —
"Commissions, resin", a fixed list nobody publishes — and any event with a
checklist. The first is the app guessing at a routine the reader never asked
for, and it was the only part of that strip with no way out.
So the switch removes exactly that. Events keep their checklists whatever
their source, including ones the reader added themselves and marked daily,
which was the requirement most at risk of being filtered away by a switch
aimed at something else.
Nothing is discarded. The ticks live under `dailies:<game>` and nothing here
reads or writes them, so switching back on restores every logged day and
every streak — the same promise `detectDaily` already makes. Defaulted on,
because everyone has these today and a setting that silently removes
something on upgrade is worse than one nobody notices.
Gating where the chore is built rather than where it is drawn means the
counts follow for free: "N still waiting on you today" is derived from the
items, and a game left with nothing contributes no group at all, so the
strip's own empty guard drops it rather than leaving a heading with no rows.
Named for what it removes. A switch called "dailies" would read as broken
while the strip stayed on screen showing the reader's own events.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review found the new settings row opening nothing for a rule whose `until`
precedes its `startsAt`. That parses — nothing ties the two together — and
yields no occurrence at all, so nextOccurrences and the anchor fallback both
come back empty, nearestOccurrence returns null, and openRow cannot resolve
a bare rule id. It was the undeletable record this index exists to rescue,
now with a button that lies about it.
So resolution moves out of App into displayEventFor, with the rule itself as
the floor: a stored id always names something the reader can edit and
delete, whatever the rule does or does not generate. Exported because
nothing here can click and no test renders App, which is exactly how a dead
button shipped — the chain is now covered without a DOM.
Two of the caption tests could not fail, proven by mutation rather than
read: deleting the whole "starts" branch and removing the null-end guard
both left the suite green, because `not.toContain("ended")` was never
watching the branch at risk. They assert what the caption says now.
And a repeating series that has stopped said only how often it repeats — in
the one place whose job is explaining why an event is on no other surface. A
healthy cadence explains nothing; it says when it stopped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An event of theirs that had ended was on no surface at all. Every list and
the board drop a row once its end has passed, and settings only counted the
events a game held rather than naming them — so a one-off became unreachable
the day it finished: impossible to edit, and impossible to delete out of a
store nothing else can see. Repeating events escaped only because their
occurrences roll forward.
So settings names them now, under the game they were filed against, each row
opening the same detail sheet a row on the front page does. Nothing about
how they are managed changes; what was missing was the way back to them.
Two things the index has to get right or it leaves the same hole it closes.
The lists hold occurrences, never rules, so a repeating rule's own id opens
nothing — nearestOccurrence bridges that, and answers for a finished series
too by falling back to the first occurrence, since a rule whose `until` has
passed would otherwise be exactly as stuck. And an event filed under a game
we track has no row of theirs to nest under; the form allows that, so those
get their own heading rather than trailing the list and reading as though
they belonged to whichever game came last.
Each row says why it is not on the front page — ended and when, or its
cadence — because a list of bare titles leaves you guessing which of two
entries is the dead one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review found the headline feature unreachable. `valid` still demanded an end
date unconditionally, while every sibling rule had been gated on
`datedWindow`. A fresh form starts with endKnown true and endDate empty, so
picking weekly hid both the field and the checkbox and left Save disabled
with nothing on screen a reader could do about it. Editing an existing event
was fine, which is why no test caught it: every static render drives the form
through `initial`, and cadenceOf never returns a preset for an event that has
an end.
So the three states that needed a click to reach are now pure functions that
do not. endStated pins exactly that case. repeatOf takes the cadence and
answers for all five, which also makes `until` surviving the preset path
provable — mutating it away previously left the suite green.
Two more from the same review. The unknown-end note keyed off the cadence, so
custom with the repeat set to never promised a countdown that would never
arrive; it keys off the rule now, which is what actually decides. And a delay
whose start and end disagree about having a time of day can never land a
whole unit from the anchor — unstatable, not merely unstated — so it says so
rather than disabling Save in silence.
"State it myself" was also a one-way door: nothing ever cleared it, so the
measured reading could not be recovered without abandoning the form.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The repeat controls sat after the dates and applied to whatever was there,
which meant a weekly chore still had to answer an end date it has no honest
answer to. Asking first inverts that: the cadence decides which dates are
even questions.
A preset carries no window. Weekly means the week is the window, so there is
no end to type and no ignorance to admit — five fields instead of eight, and
it stores exactly what the model already renders as back-to-back
occurrences. A dated recurring event is therefore a custom, which is where
the forever/delay control now lives; a one-off shows no repeat machinery at
all.
cadenceOf derives which of the five a saved event opens in, so a rule made
before this control existed opens in whichever answer describes it. Nothing
about the schema moved.
Switching cadence hides the end date rather than clearing it: hiding a field
and quietly discarding what is in it is how a form loses somebody's work
when they change their mind back.
The duplicate note was found by rendering the form and looking at it. Both
of the older notes explain the end-date field, so a preset — which has no
such field — was showing two sentences that said nearly the same thing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Every 26 days" is ordinary English for an interval, but it sits directly
beneath a start and an end — a duration — and a reader who has just been
thinking in durations reads it as another one. Naming the shape of the
repetition is what separates them, and "cycle" is the word this genre
already uses.
A cycle of one unit is named rather than numbered, because nobody says "a
1-week cycle"; a longer one takes the singular unit, since a hyphenated
"26-day" is an adjective and not a count. The article follows how the
number sounds — an 8-day cycle, an 11-day, an 84-day — which is the kind of
wrong that reads as sloppiness rather than as a bug.
The manual control becomes "Cycle length" for the same reason: it is asking
for the length of the cycle, not for a duration the reader already gave.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three answers — never, forever, or after a delay — because "how often" is
rarely the question a reader has. They know it comes back the moment it
ends, or that it comes back after a wait. The cadence follows from that and
from dates they have already typed, so the form reports what it measured
instead of asking for a number, and says it out loud rather than filling a
field silently.
A delay is expressed by where it lands: the next opening is the wait added
to the close, so a delay cannot produce a rule that comes round before it
ends. Only a hand-stated cadence can, and stating one by hand stays
available — measuring is the convenience, not a cage.
Both readings are shown for a delay, since a week's wait after a week's
window is a fortnightly rule and seeing that spelled out is how a wrong
number gets caught.
contiguousOpening is the load-bearing detail. An end given as a date is
stored as 23:59:59, so a successor opening "the moment it closes" opens at
the following midnight, a second later. Comparing against the stored end
instead read every day-precision rule as having a gap it does not have —
and the form has to measure the instants it will save, not the ones the
record happens to hold, or it opens describing a rule it would not write.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy-paste artefact from the review fix wave: the nine lines explaining why
the bar's right edge is clamped appeared twice, back to back. Cosmetic, but
this file's whole style is careful commentary and a doubled paragraph reads
as an editing mistake in the middle of it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The PRD said a reader's rule could optionally stop on a date; the until
control was deliberately descoped from the form during planning, and the
PRD was written as though it shipped. Corrected the PRD to describe what
actually ships, and noted that the field still exists in the schema —
reachable today only by importing a file that carries one.
That gap had a second-order bug behind it: because the edit form rebuilt
`repeat` from scratch on every save, hard-coding `until: null`, a rule that
already carried a non-null `until` had it silently reset to eternal on any
edit at all, including a pure title fix. Extracted the `repeat`-building
logic into `repeatFrom`, which now carries `initial?.repeat?.until` forward,
and is exported so the behaviour is provable without a submit nothing in
this suite's renderToStaticMarkup tests can click.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The day-precision note ("The source gave a date but no time of day, so this
counts down to that day's server reset...") rendered for any event with
endPrecision "day" and a stated end, with no check on where the date came
from. For a reader's own event that is false three times over: there is no
source (sourceUrl is null, sourceId is "you"), nobody gave a date — for a
repeating occurrence with no stated end the app derived it from the interval
— and it does not count down to a server reset, since boundaryMs only applies
that shift when extractionMethod === "parser". Gated the note on the same
condition so the copy and the countdown agree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
