The panel was one open block of everything in two columns. That reads fine at
four games and stops working at eighteen: the game list alone is eighteen rows
of four controls each, and it sat above the checkbox somebody had scrolled down
here to tick. Nothing was findable and everything was in the way.
Collapsing it into groups is only half an answer, though — a group showing
nothing but its name turns "what is my region set to?" into a click, which
trades one kind of friction for another. So each summary carries its group's
current state: "Europe · Dark", "17 of 18 on · A–Z", "plus finished, not
started". Closed, the panel is a five-line report of how the app is configured;
opening one is for changing an answer rather than reading it. The states are
derived from `prefs` at render, never stored, so they cannot drift from the
controls they describe.
Native `<details>`, for the reason the reorder arrows are ordinary buttons:
keyboard and screen reader reach it with no second implementation. `summary` is
not an `a`, `button` or `[tabindex]`, so it needed its own focus-visible rule —
the shared one does not reach it.
Two things fell out along the way. The region and appearance rows had no
accessible name at all, so a screen reader read six unlabelled buttons in a row;
they and the board's split pills are one `PillGroup` now, with the `role="group"`
the board's own controls already carry. And the empty states that point at
"Show events that haven't started" now name the group holding it, which is what
makes shipping the groups closed safe.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Export is the whole of this app's backup story. Progress, streaks, ignores and
every game and event the reader typed in live in one browser and nowhere else —
no account, no server, nothing to restore from — so the download either happens
or the data was never backed up.
Two things made it a coin toss. The anchor was never in the document, which is
not reliably clickable, and the object URL was revoked in the same task as the
click, which can pull the blob away before the download has read it. Both fail
silently and look exactly like a successful export.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Stacking by game rebuilt a lane's whole array for every row it added, which is
quadratic in the lane's length. That is cheap at three events and not at a
reader with fourteen games switched on and the future plotted — and it is not
paid once, because the board re-renders on every clock tick.
Appending into the array instead is the same output: `Map` preserves insertion
order, so lanes still arrive in the order their first row did and the rows
inside one keep the order they were given, which is what the existing tests
pin.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The section header said "next after this ends in {live[1]}", which got the
question wrong in both of the ways lens.ts exists to prevent.
An event whose end was never announced has no time remaining, and the `?? 0`
that stood in for it made `formatRemaining` return its expiry string — so a
second row with `endsAt: null` had the header reading "next after this ends in
ended". That is the one rule this product is built on, inverted: an unknown end
announced as an expiry.
And `live[1]` is the second *row*, not the second deadline. The list is sorted
by whatever mode the reader picked, so under "doing first" the header named
whatever they were second-most partway through — the same mistake firstToExpire
was written to keep out of the headline, one row further down.
`followingDeadlineMs` asks the deadlines instead and returns null when there is
no second dated end, and the header then says nothing at all.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This project has no linter and does not want one, but `strict` says nothing
about a binding that is simply never read — and that is the one kind of dead
code a reader cannot tell apart from a deliberate seam. `tsc` already walks
every file, so it may as well answer the question.
Three had accumulated: an unread `type View` import in App, and a
`useGameMeta()` resolver in Controls and YourOwn, both of which draw their
colours from somewhere else — the game-order list has its own resolver, and
YourOwn reads the reader's own records directly. None of them were wrong, they
were just leftovers that read as intent.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The games chip row becomes a row per game, because a reorder affordance needs
somewhere to put a handle and two arrows, and at fourteen games a list reads
better than a wrapped row of pills anyway.
Reordering lives here and nowhere else. The focus bar and the dailies strip are
the fastest tap targets in the app, and a drag target sitting on top of a tick
target costs somebody a streak the first time it misfires — so the live surfaces
stay drag-free and this is the screen you visit on purpose.
Both affordances ship. Touch fires no drag events at all, so the arrows are the
mechanism and the handle is the pointer fast path; being ordinary buttons is
also what makes the whole thing reachable by keyboard and screen reader without
a second implementation of the same interaction. An arrow at either end is
disabled rather than removed, because a control that disappears on the first row
slides the other one under the finger aiming at it.
A move writes back the whole displayed list: the indices are positions on
screen, so applying them to a stored order that names only some lanes would move
the wrong game. Reset writes the field away rather than storing an empty order.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The focus bar, the settings list, the timeline's lanes and the dailies strip all
go through `orderGames` now, resolved once in App. `games` itself stays in feed
order on purpose: `adoptNewLanes` diffs it and `knownGames` is seeded from it,
so ordering it at source would let a display preference reach the code that
decides which of a reader's games get hidden — a reordering bug would become a
game-silently-switched-off bug.
The dailies strip also groups. It was `[...chores, ...repeating]`, which put
Genshin's commissions and Genshin's own login event at opposite ends with a
dozen games between them; a game's chore and its repeating events are now
adjacent, chore first, events in the order they arrived. Collapsed that is
adjacency alone — no per-game headings, because this is the part of the page
answerable in ten seconds and a heading each would make it the tallest block on
it, pushing "next to expire" down the page.
Two things moved to where they belong. Skipping a standing chore for a lane the
reader invented is `dailyGroups`' rule, not the call site's: filtering those
lanes out in App also cost a reader's own game its place in the order its events
group under. And the expanded catch-up panel is its own exported component, so
which days it offers and whose clock they were cut on are testable rather than
trapped behind a `useState`.
`Welcome` drops its own comparator for the shared rule — the picker runs before
any stored order, so it asks for the A–Z case and cannot drift from the four
surfaces behind it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
People play at midnight and tick at breakfast, or forget for a week and come
back. A log that only accepts today goes wrong on its first bad evening and is
never trusted again.
An event whose end was published already allowed this — its checklist draws the
whole run and past pips are clickable. `catchUpDays` answers the two cases
`dailyDays` cannot: a standing chore, which has no start or end because it is a
routine rather than an event, and an event with `endsAt: null`, where the
checklist could draw no run at all and so offered only today. That second one
is the worse of the two, because it looks like a working checklist.
Never a day past today. A tick claims you did it, and nobody can have done
tomorrow, so a future day is absent rather than rendered and disabled — a
control for a claim that cannot be true. An event's strip starts when the event
did, capped at the same fortnight so a login campaign that opened in March does
not become a wall of pips.
The window bounds display and never data: a tick older than it stays logged and
keeps counting toward the streak. `DayPip` moves to its own module rather than
being copied, so there is one answer to what a missed day looks like.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Nothing did. Every surface that lists a game rendered App's `games`, which is
the order lanes first appear in the feed — whichever game happened to hold the
first event row. It is arbitrary, it moves as events come and go, and it was
the same complaint the first-run picker had.
So `orderGames` is one rule in one place, and `prefs.gameOrder` is where the
reader's own answer goes. Absent means they have never placed a game rather
than an empty order, which is the distinction `knownGames` already draws and
the same trap: every install predating the field is in that state, and reading
it the other way would hand them a blank list. They get A–Z by the name on
screen instead.
Two properties carry the weight, and both are tested rather than asserted. The
result is always a permutation of the lanes given, because a game dropped
here looks exactly like a game switched off and switching it on would not
bring it back. And a lane the order does not name trails the ones it does, so
a game we add later never lands in the middle of a hand-made order and a
retired source keeps its slot for when it returns.
Nothing reads it yet.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The picker took `available` in feed order — whichever game happened to hold
the first event row — which means something everywhere else in the app and
nothing on this screen, where the reader is scanning for the two or three
names they already know.
Sorted on the name printed on the button rather than the LaneId, since the id
is not what a reader sees, and through localeCompare rather than `<`, because
a code-point sort files hololive Dreams after every capitalised game instead
of between Genshin and Honkai.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
It was the board's alone, sitting between two app-wide filters and
carrying a line of small print to explain why it was different. It is the
same events answering the same question in either view, so it is now one
switch: the board plots them, and the checklist keeps its "Not started
yet" section.
That means the section is off by default, which is a visible change for
every existing reader — deliberate, and the same argument the board makes.
This app answers what expires next; on fourteen lanes the queued patches
are more rows than the thing they came for.
`timelineUpcoming` becomes `showUpcoming`, because the old name would now
be false, and `adoptRenamed` carries a stored answer across on load.
Nothing would be lost by dropping it — `prefs` is one blob under one key,
not a key space — but a reader who had switched the future on would find
it off with no explanation, and they should not have to say a thing
twice. A stored new name always wins, so it cannot overwrite a fresher
answer with a stale one.
Gating the section alone would have opened a hole: nothing running and
everything held back rendered an empty column, because the "nothing to
show" line keyed off there being no rows at all rather than none listed.
It now counts what is held back and names the switch, as the board does.
The split pills stay the board's: the checklist gives these a section
with a heading either way, so there is nothing there to mix them into.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
They are the same object twice — a pill carrying a game's colour, pressed
or not, that you tap — so they get the same hover rather than a second
one: a ring in the game's hue, a one-pixel lift, and the label coming up
to full ink while the chip is not the pressed one.
Sharing it meant `.tick-chip` becoming `.hue-chip`, and dropping the
`data-done` attribute it keyed off. Both chips were already saying the
same thing in `aria-pressed`, and a second attribute repeating it is one
more thing to keep in step — a rule that reads the announced state cannot
disagree with it.
The focus strip needed a pixel of headroom for that lift. `scroll-x` sets
`overflow-x: auto`, which computes the vertical axis to `auto` as well,
so a chip that rises loses that pixel and its ring to the scroller's
edge; `pt-1` is the room, and `mt` gives the same total gap back.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
"In their own group" is the shape of a patch — what is on now, and what
is queued behind it. "Mixed in" is the question a Gantt chart exists for:
what runs out first, whether or not it has opened. On real data that is
not a cosmetic difference — mixed, five events currently running sort
below an Arknights rerun that has not started, because it closes before
they do.
Which is why it is a pair of pills and not a checkbox: neither answer is
the absence of the other, and "mixed in" is a different order rather than
the heading switched off. It sits under the row that puts the future on
the board at all, and only while that row is ticked — a choice about
arranging unstarted events is unanswerable with none of them on screen.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Whether unstarted events keep to their own block or sit in one deadline
order with the running ones. Both are right for somebody, so it is the
reader's answer and it survives a reload like the rest of the board's
shape does.
Defaults to the block, which is the board as it was before the choice
existed. Only read while `timelineUpcoming` is on — with nothing
unstarted plotted there is no block to keep apart — but stored either
way, so switching that back on restores what they said rather than a
default.
The Controls test builds a whole `Prefs`, so a new required field lands
there in the same commit or nothing typechecks in between.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
`endingSoonestFirst` holds every unstarted event behind every running
one. That is right for a checklist — you cannot do a thing that has not
opened — and it is one answer of two for a board, which is asked what
runs out first. An event opening on Friday and closing on Sunday is a
nearer deadline than one running now until October, and that order can
never show it.
So `byDeadline` is the same comparator with that clause removed, and
`timelineLanes` takes a `split` flag choosing between them. It defaults
to the old behaviour, so nothing moves yet.
The flag is also the one case where lane mode reorders inside a lane,
which the module otherwise refuses to do. Deliberate: the given order is
live-first whatever the reader chose in the list, so honouring it would
draw exactly the block this was asked not to draw.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
A dashed edge and a thinner wash say "this bar has not started". They do
not say where the running ones ended, so a board with the future switched
on had to be decoded bar by bar to answer the question a reader opens it
with — what is on now.
So the boundary gets a label, and it is the same object as a lane's name:
a small eyebrow pinned to the left edge, surviving any scroll position. In
muted ink rather than a hue, because a hue on this board means "whose
event is this" and this is not about a game. One per lane, since "where
does this stop running?" is a different answer for each of them.
Where it goes is a single index rather than a per-row test, because there
is only one boundary: every order this board can be given puts live rows
before upcoming ones, and `splitAt` is exported so that is a test rather
than a comment.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
It shipped as a pill in the board's own header, beside the stacking and
scale controls. That is the wrong company: those two reshape what is
already on the board, which is why they are reached for while reading it,
and this one decides what is on it at all — the same question
"Show events I've finished" and "Show events I'm ignoring" answer, from
the panel where both of those live.
It is the only one of the three scoped to a single view, so the row says
so instead of reading as a promise about the whole app. The board loses
the count the pill carried; with nothing left running it still says how
many are waiting and names the setting, and the page header has said
"N live · N upcoming" all along.
Controls had no tests at all, so the three view filters get some: what
each checkbox is bound to is invisible in a diff and obvious only to the
reader it happens to.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The strip is the fastest thing on the page to act on and nothing happened
under the cursor, so a row of tappable jobs read as a row of status
badges.
The hover has to be drawn from what the component does not own: a chip's
border, ink and wash are mixed from the game's hue, which is data rather
than a token and so arrives as an inline style that no rule can override.
A ring in the same hue, a one-pixel lift and the label coming up to full
ink do the work instead, off `--hue` and `data-done`. Only an outstanding
chip brightens its label — on a finished one the ink *is* the hue, and
overriding it would trade the one thing saying which game for a hover
state.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
A `<button>` defaults to `cursor: default`, so most of this app read as
text until you clicked it and found out otherwise — the headline
deadline, the daily chips, the settings pills. Sixty-five controls on the
checklist view alone, two of which had picked up a `cursor-pointer` at
some point because somebody noticed them.
So it is a base-layer rule rather than a class per call site: an
affordance that has to be remembered is one that goes missing. Utilities
still win over it, which is what keeps `cursor-not-allowed` on a disabled
zoom step and `cursor-default` on a checklist day that cannot be ticked
yet saying what they mean.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
It is the thing on the page a reader is most likely to tap and the only
clickable text in the panel that did nothing under the pointer — the
queued deadlines beneath it brighten, and every list row brightens, so
the headline read as a heading rather than as a way in.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Two halves of one reading. The board answers "how does the time I am in
lay out?", and plotting every lane's next patch stretched the window
weeks past today and squeezed the running bars down to nothing — so it
holds them back, and holds them back itself rather than being handed a
shorter list, because the control has to say *how many*. A board that
quietly withheld a third of the schedule is indistinguishable from a
quiet fortnight, which is the wrong thing for this app to imply by
accident. A board with nothing left running says so and points at the
control instead of reading as an empty calendar.
Switched on, a bar drawn right of the now rule is only implicitly in the
future, and implicitly is not a standard we hold anywhere else a date is
involved. Gacha schedules are not a smooth stream of starts either — a
patch ships six things at once — so the unit is the clump: a dashed rule
per group of starts, labelled in words. Clumps merge by distance on
screen rather than by calendar, since a week apart is one mark at six
pixels a day and two at a hundred and eight, and a merged one states the
span it covers rather than claiming a date the board is not ruling at.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The timeline draws its window from what it plots, so a lane's next patch
sitting on the board pushes every running bar right to make room for
things nobody can do yet. That wants to be the reader's answer rather
than ours, and it wants to survive a reload like `view` and
`timelineGroup` do.
Defaults to false, which is what every existing board already looks
like — the rows were there but nothing was asked, so shipping this moves
nobody. A stored pref wins either way.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The link sits last in the existing row beside @StereotypicalCat and Source
code, in that row's own muted grey, with the same hover and the same small
mark. No accent colour, no button, no sentence asking for anything, and the
footer still contains no appeal anywhere — a test asserts that. This page earns
its keep by being trusted about dates, and a tip jar competing with the
disclaimer two paragraphs above spends that trust to make an ask. As one more
link it costs nothing and is there for a reader already looking.
The row also moves above "Additional ideas and design from". That row is who
built this and where to find them; the credit below it is other people. Reading
order now follows that split, instead of routing a reader past five strangers'
handles to reach the author's own links.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Both are "how do I read this?" rather than what the page knows, so they
sit together. Dark reads first because it is what the control is being
offered from, System last because it defers rather than decides.
Switching saves nothing and costs nothing: no reload, and nothing marked,
typed or ticked is touched.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
`prefs.theme` is dark, light or system, defaulting to dark: a reader
whose laptop is in light mode has said something about their laptop, not
about this page, and following the device would move every existing
reader the first time they loaded this. No control yet — the value can
only arrive from storage.
App resolves it and writes it to the document. It is also where a hue
meets the theme: doing that in the lane resolver means every label, chip,
rail and bar gets the readable answer without a component knowing a theme
exists, which is why the colophon moves onto that resolver too.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The dark tokens re-struck under `[data-theme="light"]`. Nothing sets that
attribute yet, so the app still renders exactly as it did.
Two things could not be tokens. Game hues are data — ours and the
reader's — and every one was picked against a near-black ground, so
`readableHue` darkens them along the same hue until they read on paper,
and returns dark untouched by construction. And the attribute has to be
on the root before React can mount, or a reader who chose light gets a
dark flash on every load, so the shell reads the preference itself.
That leaves the ground colour written in three files that cannot import
each other, which is what the test pins together.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
They sat between "Built by" and the two GitHub links, splitting one thought
about who made this and where it lives. Below the links they read as the
tail of that block instead of an interruption in it, and the paragraph that
invites a bug report still comes last, where a reader who has just found a
wrong date is looking.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
u/lotus_lunaris, u/Neoragex13 and u/ShiroWaffles, on the same terms as the
two already there — thanks for ideas, carrying no licence obligation.
Five entries is where the line starts wrapping on a narrow screen, which is
what the existing comma-and-"and" join was written for, so nothing else had
to change.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Events routinely end within a day of each other, and at the old close
end of the ladder their bar ends were a few pixels apart — the board
being asked the one question it exists to answer and telling the reader
to squint. Seventy-two and 108 px/day separate them, and give a one-day
event a bar wide enough to read and to tap rather than the 34px every
short bar collapses to.
The clamp test now reads the ladder's last rung instead of naming 48, so
extending it again does not need the test rewritten.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Second name on the list, and the first from somewhere other than a fork —
so the doc comment stops calling this a list of forks, and says what the
`handle` field now carries: it renders verbatim, a bare handle meaning
GitHub and `u/` meaning Reddit, rather than a `platform` field nobody would
keep consistent across two entries.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
A public fork of this project worked out several things worth having — a
theme toggle, an archive for finished events — and ideas are not code:
nothing here carries a licence obligation, so this is thanks rather than a
term, and it belongs in the credits rather than in NOTICE with the terms.
Credited by GitHub handle and fork URL, not by name. The commits behind that
fork carry a third name again, and a handle is the one identity that is
verifiable and stable.
Hardcoded, unlike the source and studio credits above it — nothing in the
feed knows a fork exists, so there is nothing to derive it from.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Thirteen px/day opened the board on about a quarter of calendar, which
is more time than these schedules are written in: a patch is six weeks,
so most bars were short enough that their length stopped reading as a
duration and their title no longer fit inside the bar it named. Thirty-
two opens on roughly one patch cycle on a laptop.
Only new readers move. `prefs` is written on every load, so anyone who
has opened the app has a timelineDayWidth of their own and keeps it. A
phone now shows about twelve days rather than thirty, which is the cost;
the longer view is one press of − away and that answer is remembered.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The board's header said "One lane per game" and left it at that; now it
offers the other stacking too, in the same place and the same pill shape
the list's sort control uses — you reach for it while looking at the
board, not in settings.
Merged, there is no lane heading to say whose event a bar is, and hue
alone cannot answer that once every game shares one stack. So each bar
carries its game's short name, and its tooltip carries the full one. A
bar under 96px has no room for a tag and a title both, and a chopped
game name reads as a broken word — those keep the title and say the game
in the tooltip.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Lanes keep a game's events adjacent, which is what makes the board
readable for someone playing four of them — but a reader with four games
has one queue of deadlines, and lanes scatter it: the thing ending
tonight sits three lanes below the thing ending next month, and no
amount of scrolling puts them side by side. So the stacking becomes a
choice, and the choice is remembered like the scale and the view are.
The merged mode sorts with endingSoonestFirst rather than a bare end
date, so the timeline and the list cannot mean different things by the
same words — and an unannounced end keeps its place behind every dated
one instead of pretending to a deadline.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
In a 20rem column the scrolling strip shows four chips of a thirteen-game
reader's set behind a hairline scrollbar, and a game you cannot see is a
game you will not focus. Past `lg` they wrap instead: the rail is short and
the list beside it is long, so the extra rows cost that column nothing it
was using. On a phone the strip is right and stays.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Past `lg` the page is a pinned rail of instructions beside the lists, and
the focus bar was still a full-width strip above both columns: it spent
the whole width of a wide screen on a row of chips and pushed "next to
expire" — the thing the reader opened the page for — down behind it, while
sitting nowhere near the panels it narrows.
The top of the rail is still above everything it affects, and now it pins
with the deadlines and dailies it filters. On a phone, and on the
timeline, which has no rail, nothing moves: the same rule puts it back at
the top of the page. One element, rendered once per view.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The detail sheet formatted the stored ISO, so a day-precision end rendered
as 00:00Z — the previous day for every reader west of UTC, and now a
different day from the timer sitting beside it. Both dates come off the
clock instead, which resolves them the same way.
The note under them said the end was "accurate to the day only" and left
it there. It can say where the count actually lands, and should: a reader
deciding whether to log in tonight wants the reset, not a shrug. It still
says this is a reading rather than a time the source printed.
REGION_LABEL moves next to the region table it names, which is also how
the note gets "Europe" rather than the raw id.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
One density cannot answer both questions the board is asked. A patch cycle is
six weeks, a login campaign runs for months, and 13px a day is a compromise
between "what am I in the middle of this week?" and "how do the next three
months line up?" that serves neither well.
A pair of controls steps through a ladder of day widths and the choice is
remembered, on the same argument as the view tabs: a reader who has said how
they want to read this should not say it again on the next load.
Two things it had to get right. Zooming holds the middle of the view still —
rescaling around the left edge of a three-month board throws away whatever
they had scrolled to, and re-opening at today would undo the scrolling that
got them there. And the dated ticks thin out as the scale shrinks, because a
week is 42px at the widest setting and the dates would sit on top of each
other; the gridlines stay weekly, since they carry the rhythm rather than the
reading.
The scale is stored as the measurement, not a step number, and read through
`snapDayWidth`. An export written against a different ladder then opens on
something close to what its reader chose, and a corrupt value opens on the
default rather than a board one pixel wide.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Adding a source is our decision, not the reader's. Eleven lanes became
fourteen this week, and for someone who plays two that is not a feature
arriving — it is their calendar filling with events they will never open,
which is the thing the first-run picker exists to prevent.
`knownGames` records every lane a reader has been offered; a lane missing from
it is new to them, so it is recorded and hidden on sight. The games chips in
settings list every lane, on or off, which is where they take one up.
The case that had to be right is the reader who installed before any of this
existed: they have no `knownGames` at all, and reading that as "has been
offered nothing" would switch off every game they already read. Absent means
unrecorded — the first pass records what is already on their screen and
changes nothing else. Lanes they invented are recorded but never hidden;
typing a game in is asking for it.
The decision is a pure function so this is provable rather than watched for.
One real cost, stated in the PRD rather than hidden: a reader whose game
finally arrives is not told, which makes the colophon roadmap matter more.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
"Ending soon" described the sort, not the job — and it sat one line above a
sort control whose own option reads "Ending soonest", so the tab and the
ordering looked like the same control said twice. Checklist is what a reader
with four games is doing with it.
The stored id stays "soon". That value is in `prefs.view` on real devices, and
a label is copy: renaming one must never move a reader to the other view.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Two changes to how the board reads.
The window was drawn from the earliest start, so one long-running event — a
standing login campaign can have been going half a year — bought months of
empty calendar that nobody scrolls back through and that pushed every other
bar off to the right. It now floors at two months, a patch cycle and a half:
far enough that a running event's start is usually still on the board, past
the point where the answer changes what anyone does today. A bar older than
the board keeps its faded left edge rather than being redrawn as though it
started there.
The bars themselves were 28px with 4px between them, which read as a stack of
hairlines rather than a schedule. They are 36px now, with more padding, more
air between events, and more between lanes.
`boardWindow` comes out of the component while it is being changed: it
decides what a reader can and cannot see, which is worth a test rather than a
rendering.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The reader who was asked what good looks like named paimon.moe's timeline,
and the thing ours was missing is what that view never loses: on a wide
window we drew more calendar and nothing that said which day, whose game, or
which event was on screen. The date axis, the lane names and the event names
all scrolled away together — and a six-week bar starts weeks off the left
edge, so its name went with its start date and left a coloured rectangle.
So it is a pane that scrolls in both directions, with the axis stuck to the
top and every name stuck to the left. A name is sticky inside its own bar, so
it can never wander onto an event it does not belong to. The axis gained the
week the schedules are actually written in: a dated tick every Monday and a
brighter rule at each month.
The frozen label column that started this went away again — it stood on the
calendar and ate the names it was meant to keep. Lane names sit on their own
line instead, and "jump to today" sits in the board's header rather than
floating over the dates it sends you back to.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Every screen got the same 672px column, so a desktop reader read a phone page
with two thirds of the window empty — and the one design criticism the release
thread produced was formed from a screenshot.
Past lg the page splits along the line this codebase already draws: what it
tells the reader to do — the next deadlines, tonight's dailies — pins to a
rail on the left and stays there while the lists it shows them scroll beside
it. The footer and the settings panel become columns rather than a long fall
of small grey text. Below that breakpoint nothing moves: the same split puts
the instructions first in one column.
The rail's rule sits on the panel rather than the column. The panel is short
and the list beside it is long, so a full-height divider would spend most of
its length walling off a gap.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The reader who reported this had two games switched on, twenty-one live
events, and said the list stopped being usable — and every game added doubles
down on that. Each section now shows six rows with an explicit "show all N".
It truncates the view and nothing else. The slice comes off the front of a
list already in the order the reader chose, so the hidden rows keep their
place, stay counted in the header, and stay on the timeline. Expanding is
per-visit state: it is something you do while reading one list, not a
statement about how the app should work.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
`view` was component state, so a reader who preferred the timeline was put
back on the list by every reload — and which view opened at all had been
decided for them twice over: the PRD said calendar, the app shipped the list.
Neither was the reader's answer.
So the first run asks, and the tabs write to `prefs` from then on. The
question ships pre-answered with the list, because a reader cannot choose
between two layouts they have not seen and that is the one that answers "what
expires next" in a look — and each option is drawn rather than described, for
the same reason. The screen says where to change it afterwards, since the tabs
are small text in a corner.
Adds `view` to the prefs key space. Additive and defaulted, so an existing
reader's stored prefs open exactly where they did before.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
A reader with two games switched on said the list lost its point at
twenty-one rows and asked for the three closest deadlines up front. One row
was also fragile on its own terms: ticking off the headline event left the
panel pointing at something the reader had no context for.
Three equal panels would be a stat grid, and a reader arrives with one
question — so the shape is one answer at full size and two follow-ups under
it, with no meter, summary or badges to turn the panel into a second copy of
the list below it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The headline panel asked for one row and got one row, so nothing else could
ask this question. `nextToExpire` answers it for any count and `firstToExpire`
is now that function asked for one — one definition, so a big countdown and the
lines under it can never disagree about which deadline is next.
Unannounced ends still sort behind every dated one however long they have been
running: a panel of deadlines that leads with "unknown" is not a panel of
deadlines. It sorts a copy, because the array it is handed is the one the list
on screen is rendering from.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
New bawiki parser plus the ba-bawiki-events source, giving the game its
two live and upcoming events at day precision.
It reads the rendered /wiki/Events page, which is the opposite call to the
Fandom source next door and for the same kind of reason: bluearchive.wiki
is Miraheze, whose robots.txt disallows /w/ and /*?action=, so there the
API is the closed route and the page is the surface * is allowed. It
serves our own User-Agent a 200, sets no Content-Signal and no Crawl-delay
for us. The Fandom wiki was declined earlier as a JP archive yielding
nothing live; this is the live source that assessment pointed at.
Three page facts shape the parser, each a way to publish a confidently
wrong date. The schedule is a JP/Global tabber and the Japanese version
runs four to nine months ahead, so only Global is published — the akwiki
hazard. The Global tab's nav button carries the id
tabber-Global_version-label and precedes both panels, so slicing from the
first matching id reads the Japanese schedule while believing it read
ours; the first version of this parser did exactly that and published a
JP-only event. And three tabs on the page are named Global, the schedule
plus Mini-Event and Joint Firing Drill, so the schedule is found by its
Name (EN) header rather than by position, with canParse asserting the same
lookup — a renamed tab or column fails the run instead of emptying the
lane.
The page states no time of day and no timezone anywhere, which is why the
dates are day precision and why ba gets no resetOffsets. It also settles
the five other schedule tables, which do carry a wall clock but name no
zone and mostly do not say which server: reading those as UTC would invent
the fact that matters most, and rounding to a day would not save it,
because a 04:00 local boundary falls either side of UTC midnight depending
on the offset assumed and the start's day is part of the event ID. They
are left unparsed deliberately.
The two-event count is asserted against an independent extraction off the
fixture, and both starts corroborate against the per-event infoboxes
elsewhere on the page — GL 2026-08-04 and GL 2026-09-01, where the JP
reruns those tabs would have given are 2026-04-01 and 2026-05-06.
Three comment counts were already stale before this and are corrected to
what the tree now holds rather than to what it held yesterday.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Nothing a reader marks, types or ticks ever leaves their browser, so there is no
account and no server-side record to look anything up in after a report arrives.
Whatever the form captured is all there will ever be — which is the argument for
structured forms over a blank box, and for the bug form carrying the footer's
"event data last refreshed" line as a prefill. A stale calendar and a genuinely
wrong parse are indistinguishable from outside, eight sources cannot be fetched
from CI at all, and that line is the only thing that separates the two cases.
The feature form states the three constraints up front, because "sync across my
devices" and "have a model read the page" both have settled answers and a reader
deserves them before typing rather than after. It also points source requests at
the assessed-and-declined table: the loudest feedback on the first release was
that the game list is too short, so that is the request that arrives most, and a
wiki that forbids automated access or only archives finished events cannot be
used no matter how often it is asked for.
Blank issues stay enabled. A form that turns someone away loses the report, not
the noise.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The footer only spoke up past the two-day threshold, and then only as a
count of stale sources. A page silent about its own age reads as current,
so it now says when the data last refreshed on every load — absolute date
plus relative age, next to where the warning appears. This is the half of
PRD F7 that was never built.
Where the number comes from is the whole point. `freshness()` in
src/shared/feed.ts takes the newest lastSuccessAt and never generatedAt:
the feed is rebuilt on every deploy whether or not anything was refetched,
so a build stamp would report a calendar as minutes old while its events
came from a fixture captured months ago. A game is also only as fresh as
its oldest source, or Endfield's live wiki would vouch for its stalled
Game8 page. That matters concretely here — eight sources cannot be fetched
from CI at all, so this notice is what stands between a reader and a
confidently stale calendar.
The stale warning now names the lagging games and how far behind each is,
because a count is not something a reader can act on while a name tells
them which source page to check. Two exceptions found by rendering it
against the real feed: past four games it summarises the remainder, and
when every game is behind — what a refresh that stopped running looks like
— it collapses to one sentence rather than ten names repeating one age.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
