GitHub Pages gzips for us, so the deployed site never had this problem. The
Docker image serves through serve.ts, which did not — so a self-hoster shipped
the bundle at 344 KB where the site sends 100 KB, and the feed at 90 KB where
the site sends 10 KB. Roughly three times the bytes, and on anything slower than
a laptop on wifi three times the download.
Negotiated on `accept-encoding` and applied only to the text types this app
serves; a PNG is left alone rather than spending CPU to grow it. `Vary` goes out
on both answers, because a shared cache that does not know the response depends
on the request header will hand gzipped bytes to a client that never asked.
The compressed bytes are cached in memory and keyed by mtime — these files
change only on deploy, so re-gzipping 344 KB per request is waste, and keying on
mtime rather than holding forever keeps `bun run dev` serving what was just
rebuilt. A failure to compress falls through to the raw file: this is an
optimisation and never a reason to fail a request.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
`build:js` was shipping React's development build. That cost 222 KB of the
566 KB bundle (61 KB of 164 KB gzipped), ran every element creation through
dev-only validation, and left `StrictMode` double-invoking effects — so
`fetchFeed` fired twice and every reader downloaded the feed twice on every
single load.
On a 4G/4×-CPU profile with the cache cold: first contentful paint 1480ms →
972ms, the feed on screen 1766ms → 1261ms, and two feed requests → one.
The flag is `--production` and not `--define process.env.NODE_ENV='"production"'`,
which is the obvious-looking version and produces a bundle that does not run at
all: the define flips React to its production build while the JSX transform
keeps emitting `jsxDEV`, so the page dies on `z is not a function` with a blank
body. Both variants build clean, typecheck clean and pass all 843 tests, because
nothing in the suite executes the bundle — so AGENTS.md now says to open a
browser before believing this one.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
`iso()` read back the month and the day to catch February 30 rolling over to
March 2, and took the year on trust. `Date.UTC` maps years 0–99 into the 1900s,
so a four-digit "0050" came back as 1950 with the month and day intact — past
both existing checks, because nothing about the resulting date is impossible.
Same class of failure as the rollover the guard was written for: a boundary the
source never stated, published as though it had. Reading the year back too is
the skip-rather-than-guess rule this module runs on, applied to the one field
that was not checked. It narrows only — `parseShortSlashRange`'s two-digit pivot
produces full years and is untouched.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The "Running now" header had a hint reading "next after this ends in …", and the
commit before this one fixed a real defect in the string it produced — an
unannounced end became the word "ended". Both were beside the point: the branch
cannot render at all.
`Section` shows `action ?? hint`. The hint needed a second live row to have
anything to say, and two live rows are two visible rows, which is exactly the
condition that puts the sort control in the same slot. So the action was present
whenever the hint was, and won every time.
What it would have said is already on the page. The headline panel's "Then" list
names the deadlines behind the closest one and counts each of them down, which is
the same answer with more room. So the hint slot goes, `followingDeadlineMs` goes
with it as its only caller, and `Section` is left with the one control slot it
actually uses.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Left over from before `orderGames` existed. The prop says feed order and App has
been handing it `enabled`, which is the reader's order filtered — so the comment
described the one thing that stopped being true when every game-listing surface
started going through the same rule.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The progress store merged like the mark stores do, keeping whichever copy had
the earlier timestamp. That is right for a mark — `at` is when the reader made
it, membership is the whole fact, and the oldest stamp is the truest one — and
wrong here, because this record *is* the data. A status, an effort, a note and
whether an event repeats all live in it, and `at` says when one of those last
changed.
So the earlier copy winning discarded every edit made after it, in both of the
directions an import actually happens in: restoring a backup taken before an
evening's work undid the evening, and importing an old file onto a device with
newer progress rolled the device back. Neither is recoverable — there is no
account and no server holding a second copy.
The later record wins now. Nothing is removed in either direction, and taking
the maximum of two timestamps is as order-independent and idempotent as the rule
it replaces. `mergeProgress` came out of the hook to be tested, which is also
how the ignored store's opposite rule is now written down rather than assumed.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Every other surface here is handed `now` — the headline, the board, the dailies
strip, the detail sheet — for the reason the parsers are: a function that reads
the clock cannot be rendered against a fixed instant, so nothing about it can be
asserted. The list row was the one exception, calling the wall clock twice for
its window caption and its "starts in".
Two things follow from fixing it. Those numbers were counted from a different
instant than the `clock` sitting beside them in the same row, which is a
disagreement nobody would ever notice and nobody could ever prove. And the
countdown is now testable: rendering one row at two instants gives the two
answers the injected clock implies, which is what the new test pins.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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 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]>
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]>
Switching refresh.yml back to ubuntu-latest left this file asserting that it
runs on a self-hosted runner "because the address is the legitimate lever". The
lever is still the address; that particular address just was not a better one.
Says so explicitly, because the revert is easy to misread as the idea being
wrong rather than one address not being the one — and the next person here will
otherwise try the same runner again.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The runner move was recorded here as untested for game8 because that cycle
interval-skipped all nine. The next one asked them: 202 CloudFront, every one.
So safe-ip is challenged by Cloudflare and refused by CloudFront alike and
bought nothing by itself — worth stating plainly, since "try a different runner"
is the first idea anybody has here and it has now been tried.
The Fandom half is fixed, by the cron passing --assume-robots-on-403 rather
than by the address: the next cycle put all four through at 200, two with fresh
bytes.
Also records why game8 cannot have the same treatment. Its 202 is the page
itself being withheld, not a permission we hold and cannot re-read, so there is
nothing for a recorded decision to stand on.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Four Fandom sources have skipped on a challenged robots.txt every cycle, so
their calendars are only ever as fresh as the last manual run. For a product
whose promise is a trustworthy end date, four stale lanes are the worse failure
— so the scheduled run now passes --assume-robots-on-403 and the owner re-reads
those files by hand over time.
Kept asymmetric on purpose: --force is still refused on an unattended run.
Forcing every cycle really is just a shorter interval with extra steps, and
nothing about this decision touches that.
The accepted risk is narrower than "crawling against robots.txt", and worth
stating precisely. A plain 403 still fails closed, so a host that turns us away
still stops the run — that is what the challenge-or-refusal split buys. What is
invisible is a robots.txt edited to disallow us, because from a challenged
address a withdrawal looks exactly like the challenge we already expect. No
code can catch that; only the re-read can.
Which makes the per-cycle warning the compensating control rather than a
courtesy, so it is now pinned as one: every host named, and surviving as a
run-page annotation on a completely green cycle where nothing else draws the
eye. A dispatch can set the input to false to see the real state.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Four Fandom sources have been skipping on a challenged robots.txt every cycle,
and the only thing that clears it is a person passing the recorded permission.
Until now there was no way to do that from the workflow, so it meant checking
out the repo and running the refresh by hand. Both overrides are dispatch
inputs now, guarded on the literal string "true" and empty on the cron, so the
schedule still cannot reach either one.
The force-push guard needed narrowing to allow this. It asserted the workflow
contains no "--force" anywhere, as a proxy for never rewriting the branch, and
the refresh runner's own --force flag trips that substring while having nothing
to do with pushing. It now matches force on a git push specifically, including
--force-with-lease, which is still one — a tighter assertion than the string it
replaces, checked against both a real force push and the flag it must ignore.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Both overrides stand in for a person deciding something, and the gate that
enforced it asked the coarser question. `isCi()` got the case that matters
wrong: a `workflow_dispatch` sets CI=true, so somebody clicking "Run workflow"
was refused exactly as the cron was, which made both flags unreachable from the
workflow at all. A dispatch is a person, and a better-evidenced one than a local
shell — GitHub records which one, and the run log keeps it.
`runAttendance` draws the line where it belongs: a local shell is a person, a
dispatch is a person and names the actor, and a schedule — or any other runner
event, erring that way on purpose — is not. The run now prints which override
was used and who authorised it, because a local shell leaves no trace anybody
else can read.
The schedule stays refused, and for the robots override that is not ceremony.
From an address that gets a challenge we never receive robots.txt at all, so a
cron standing on the recorded permission has no way to notice the host
withdrawing it, and that permission has no expiry. The challenge-or-refusal
narrowing does not close this: a plain 403 still stops us, but a robots.txt
edited to disallow us would be invisible, because a challenge arrives instead of
a file. A person re-reading it is the only thing that ever re-validates it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The runner move to [self-hosted, safe-ip] was recorded here as untested, with
the next cycle to settle it. It ran, and all four Fandom sources came back
403 (an interstitial challenge) — so that address is challenged too, and these
four still only move when a person refreshes them on the recorded permission.
Worth being exact about what the cycle did not settle, because the summary
looks fuller than it is: the nine game8 sources were all skipped_interval, not
due until 23:46 UTC, so nothing asked game8 anything and its 202 is unmeasured
on the new runner.
The reason string is doing the job it was added for one commit ago — the
challenge-or-refusal distinction is what says this is covered by the flag
rather than a host that turned us away, and it answered that from the summary
alone.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This file recorded a 403 as Fandom's posture, holding across every wiki and
every address, which made those four sources permanently unschedulable. It was
measured with curl, and curl is not what fetches: on one address, in the same
minute, curl takes a 403 with a bare, a Chrome and our own User-Agent alike,
while Bun's fetch is served the real robots.txt on all five hosts and the gate
passes with no override.
Two variables were folded into one there, and they are worth holding apart. The
client mattered — but so does the address, and the client does not rescue it:
the 17:46 UTC run on ubuntu-latest still skipped all four Fandom sources using
that same Bun client. So a claim that these refresh on a schedule is a claim
about the address the runner has, and on the new one it is untested rather than
established. The next cycle settles it.
Three traps recorded so the episode is not repeated: verify a fetch gate with
the real RobotsCache from the address that will run it, never a shell client;
the User-Agent is not a lever in either direction, so a 200 that appears when
you drop it is the challenge's probabilistic half and not a header you tuned;
and neither block is a rate limit, since every failure is first contact with
that host, the spacing is already applied, and a challenge carries no
Retry-After. More delay buys nothing.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
`--assume-robots-on-403` stands in for rules a person read in a browser, for a
host that will not serve us the file. It always claimed it would not override a
host that had turned us away — but it could not tell the two 403s apart, so it
excused both. A managed challenge ("we cannot tell what you are") is a question
our fetcher cannot answer and the operators never asked, which is what makes a
human reading the rules a fair substitute. A bare 403 is the site itself saying
no, and nothing recorded on our side may talk over that.
`isInterstitialChallenge` now decides, on Cloudflare's own `cf-mitigated` header
with the challenge page's markers as a fallback; an unreadable body counts as
unclassifiable rather than challenged. This only ever narrows what the flag
opens, so nothing that passed the gate before stops passing it.
Every 403 is classified whether or not the flag is set, and the kind goes into
the reason string the run reports. `robots.txt returned 403` read identically
whether the answer was to refresh by hand on the recorded permission or to stop
fetching the source, and the summary is where somebody has to decide that.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
F1 described a board-only setting and said in as many words that the
checklist "has listed them all along", which is now the opposite of what
happens. F2 did not mention the section at all. Both say it once, in the
place a reader of either would look.
The prefs key space records the rename and why the old value is carried
rather than dropped — the next person to move a field will want the
precedent, and the reasoning is the half a diff cannot show.
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]>
F1 described bars that carry their own not-started marking and stopped
there. It now has the label naming where the running ones end, and the
choice between keeping that block and dropping it for one deadline order
— including why the second is a re-sort rather than a hidden heading,
which is the part a future change would otherwise get wrong.
The heading itself shipped a commit earlier without this; same feature,
so it is written up once here rather than split across two entries.
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]>
F1 described a control in the board's header that is now a row in
settings, and the reasoning is worth keeping rather than the location
alone: the header holds the controls that reshape what is on the board,
settings holds the ones that decide what is on it. That is the line, and
it is what would otherwise be re-argued the next time a filter needs a
home.
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]>
F1 said the timeline plots what the reader can see, which is now half
true, and the prefs key space did not list the field the board writes.
Both record the argument the code only implies: the window is drawn from
what is plotted, so on-by-default is not a fuller board, it is a smaller
one for everything that is actually running.
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 run just made reported each of the four Fandom hosts twice — once from the
warning pushed in runRefresh and once from a second loop in main() that printed
summary.assumedRobots again. Eight lines for four facts, and the header above
them said "5 warnings" while nine printed under it, so the count a reader uses
to judge whether to read the list was wrong in the direction that matters.
Mine, from the commit that added the flag: I put the reminder in main() to make
it loud, having already made it loud in the summary.
The instruction folds into the single warning instead, so it still says to go
re-read the file in a browser, and it now also reaches the job summary and
annotations, which only ever read summary.warnings.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
First run of --force and --assume-robots-on-403 together, and the first time
every source has been confirmed in one cycle: 19/19, 0 broken. Nine game8 pages
answered 200 from a normal address, which is the CI block behaving exactly as
§ Scraping conduct describes it, and all four Fandom sources fetched on the
recorded permission.
Nothing a reader sees changed. No source's event count moved, and diffing the
parsed events of all eight changed pages against their previous snapshots finds
no event added, removed, or re-dated. The byte deltas are between -286 and +32
on pages of a quarter-megabyte — page furniture, not schedule.
That is worth stating rather than glossing: the value of this commit is the
negative result. Nine of these games are fixture-backed in CI and only ever
confirmed by hand, so "we looked, and the calendar is still right" is the thing
the refresh exists to establish, and lastConfirmedAt is what the footer reads to
tell a reader how old the answer is.
fgo is the odd one: identical length, different hash. Every one of its 101
changed characters sits in MediaWiki's `NewPP limit report` comment at the foot
of the body — cache timestamp and parser timings, fixed-width, outside the text
we parse. So a Fandom source will report `fetched` and produce a diff on any
forced refresh an hour apart, whether or not the wiki moved. Worth knowing
before reading a future Fandom diff as news.
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]>
The interval gate has no override, so a page you know has just changed cannot
be fetched until six hours after the last attempt. The only workaround was
deleting snapshots/<id>.state.json, which also wipes consecutiveFailures and
lastConfirmedAt — resetting the broken-source streak and making the footer age
every source from when its bytes last changed rather than when we last
confirmed them. A flag that says what it means is better than a side effect
nobody documented.
It sets aside the interval and nothing else. Conditional headers still go out,
which is what makes forcing defensible at all: the host is asked, not
re-served, and an unchanged page costs it a 304. Per-host spacing, robots, one
request per source and the no-retry rule all still apply — a source that was
not due and is also disallowed stays skipped, for the reason that matters.
Refused under CI, like --assume-robots-on-403 and for the same reason: a
schedule that forces every cycle is a shorter interval with extra steps, and
the interval is the obligation, not the default. So AGENTS.md § Scraping
conduct is amended rather than left to be quietly contradicted by a flag.
Every source asked early is named in summary.forced and warned about. A run
that was due anyway is never reported as forced — a summary that cried "forced"
on an ordinary run would train the reader to ignore the word.
Also repoints the "unknown flag" test, which used --force as its example and
stopped testing anything the moment --force existed.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The previous commit landed the first live pages for nikke and nikki, which
retires the last version of a sentence that has been wrong twice in one session
— it counted which of the four had ever been fetched, and that number kept
moving underneath it.
So it no longer counts. What matters about these four is not how many have a
snapshot but that every one was taken by hand and always will be: their
freshness is exactly as old as the last person who ran the refresh themselves,
because the schedule cannot read Fandom's robots.txt. Points at
--assume-robots-on-403, which is what makes that run possible.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Both were built on 2026-08-19 and have been served from their fixtures ever
since, because CI cannot read Fandom's robots.txt and the gate fails closed.
Refreshed by hand from an address Fandom serves, which is the only way these
two ever move.
Each body is a real action=parse envelope and each parses to exactly what its
fixture does — three events for Nikke, seven for Infinity Nikki, same titles and
same dates. That is the expected result rather than a weak one: both fixtures
were captured from these pages today, so agreement is the check that the stored
bytes are the wiki and not a challenge page.
All four Fandom sources now have a snapshot. None of them will get another one
from the schedule.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The "only ever commit your own work" rule already said not to `git add -A`, and
it was written as though the tree only ever holds work someone left there
earlier. It also holds work someone is doing *right now*: sessions run
concurrently here and the index is shared, so a status that was clean when a task
started can carry four staged files by the time it commits.
Today that cost a real commit — a source assessment finished in one session was
swept into another's, and published under a one-line message about snapshot
freshness. So the bullet now names the concurrent case, asks for a
`git status --porcelain` immediately before committing rather than at the start,
and gives the form that is safe when someone else's work is already staged:
`git commit -- <paths>`, which never reads the rest of the index.
The second half is the recovery, and it is deliberately not automatic. Splitting
a mixed commit is easy; doing it to a commit another session authored while that
session may still be running is not, so it is a thing to ask about rather than
fix quietly.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Its conduct is the cleanest of anything looked at here — a robots.txt of pure
comments, no directive, no Content-Signal, and a plain 200 to our own
User-Agent — so the reason not to build it is entirely in the data, and is worth
writing down rather than re-deriving next time the URL is offered.
The calendar prints no year anywhere, and heads its only date row "Estimated
date for Regional Servers" over a page that says the schedule is the CN
server's. Every date it could publish would therefore be a guess twice over: a
year we inferred, on a boundary the page itself declines to stand behind. The
week-column grid also rounds an end to a bucket rather than to a printed day,
and the URL carries the version number, so a SOURCES entry pinned to calendar89
would be publishing history from tomorrow.
The markup is recorded anyway, because it is readable and that is not the
problem — if the site ever states a year and a real regional schedule, the work
is a positional parser and nothing else.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
A hand-run refresh landed one at 02:36 on 2026-08-19, four events. The sentence
two commits ago said it had never had one, which was true when written and is
the kind of claim that decides whether someone bothers trying — so it is worth
being exact about: r1999 and fgo have snapshots, both taken by hand today;
nikke and nikki are still served from their fixtures.
The conclusion is unchanged. None of the four will ever be refreshed on a
schedule, because CI cannot read Fandom's robots.txt.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Fandom answers our fetcher 403 on /robots.txt itself, from every address we
have, while api.php?action=parse answers the same User-Agent with a 200. The
gate fails closed on the unreadable file, so r1999, fgo, nikke and nikki can
never refresh — even though their rules are not unknown: a person read them in
a browser and wrote them into AGENTS.md, verbatim, which is how three of those
four were cleared in the first place.
This flag is that recorded permission, and nothing wider. What it deliberately
does not do is most of the design:
- 403 only. A 401, a 5xx, a timeout or a soft 404 still mean we do not know
what the site permits, and unknown is still not permission.
- It never overrides a robots.txt we could read. A file that answers and
disallows us is an answer, and it still wins. So this is no use for game8.co
— whose robots.txt reads fine and welcomes us while its edge refuses the
pages — and it must not become one.
- Refused under CI. It stands in for a human having read a file this morning,
and there is no human on a runner. A scheduled job asserting a permission
nobody re-checked is exactly how "temporary" stops being temporary.
- Loud. Every host it applied to is warned about by name, in the run log and
in the summary, with a line saying to go re-read the file. An override that
reports nothing is one nobody withdraws.
Nothing else about being a guest relaxes: one request per source, six hours
apart, spaced per host, conditional headers, no retries.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Nothing in the client prunes reader data today — no store filters against the
feed, knownGames only appends, metaFor renders a lane whose game is gone — so a
retired source, page or game leaves completion marks, streaks and hand-entered
events untouched. That was true by construction and pinned nowhere.
The load path is what makes it worth pinning. useCustom reads through
validRecords, which drops a record that fails its schema, and the survivors are
what the next write persists. A record that stops parsing is therefore not
hidden until someone notices — it is deleted from the device, permanently, by
the act of opening the app, with no server-side copy to recover it from.
Which makes CustomEvent.game being z.string() rather than GameId the whole
safety property, and it currently reads like validation someone forgot. Anyone
narrowing it to the enum would be tightening a schema and arming every future
game removal to erase reader data on next launch. The tests state the premise,
the survival, and that one unreadable neighbour still does not take the rest
down; the field says why it is loose.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Nikke and Infinity Nikki were added on 2026-08-19 and the paragraph describing
what the Fandom robots gate costs was not extended to cover them. It still said
"the two built Fandom sources", named only r1999 and fgo as permanently
fixture-backed, and counted three wikis where the API answers our own
User-Agent.
The correction matters more than the arithmetic: it is this paragraph that
tells the next agent which lanes the scheduled refresh will never update, and
two of the four it now silently omitted are the two most recently built. Only
r1999 has ever had a snapshot; fgo, nikke and nikki have never had one and will
not get one from CI.
Also drops "Two Fandom sources now" from the Fate/Grand Order heading, which
counted the sources rather than describing the thing the paragraph is about.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Retiring nikki-game8-events left its snapshot behind. snapshots/ is defined as
the current page per source, and there is no such source — so these two files
are 200 KB of a wiki that stopped being updated in August 2025, tracked in git,
described by metadata naming a sourceId nothing resolves.
Harmless today: build-feed.ts iterates ADAPTERS, so an orphan is never read.
That is also what makes it worth removing rather than leaving. The one path
that would read it again is someone re-registering the id, and what they would
silently get back is the stale page the lane was moved off — the failure the
move was made to fix, arriving through a file nobody looked at.
The fixture stays. fixtures/nikki/game8-events-2026-08-17 is pinned and
permanent, it is the only page here carrying Game8's labelled "Start: ... End:
Permanent" shape, and test/adapters still drives it through the parser.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Three parsers decide currency against ctx.now, because their page has no
"ongoing" heading worth trusting: bawiki.ts, and the Fate/Grand Order and
Infinity Nikki branches of fandom.ts. All three compared Date.parse(endsAt) to
now, and all three publish day-precision ends — so the comparison was against
the 00:00Z placeholder, which § Domain rules says is not an instant and nothing
may read literally.
clockFor already knows that and resolves such a boundary to the reset opening
that game-day on the reader's server. The parsers did not, so the feed retired
a row up to nine hours before the app, the countdown and the game all agreed it
was over. On the pinned Infinity Nikki fixture, "Inspiration Burst" left the
feed at 2026-08-22T01:00Z while clockFor still called it live for an American
reader until 09:00Z, and the page said it ran to 03:59 server time. The reader
does not see a stale row; they see the deadline they were counting down to
disappear on its last day, which is the silent drop this codebase treats as the
dangerous failure.
latestBoundaryMs answers clockFor's question for the last region rather than
one reader's, so a row is history only once it is history everywhere. It follows
a game's own server map and reset hour for the same reason clockFor does —
Endfield and Reverse: 1999 both move. Nothing stored changes: this is one
comparison, not a resolved boundary written into the feed, and no expected.json
moves.
Being generous by nine hours costs an expired row at the bottom of a list.
Being strict costs a live one.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Eleven sources were inside the 6h floor and were left alone. Of the eight the
runner planned, five answered: Reverse: 1999, GFL2, Stella Sora, Chaos Zero
Nightmare and Umamusume — the last four getting their first snapshot, so those
games stop being built from checked-in fixtures.
Fate/Grand Order, Infinity Nikki and Nikke were skipped on a 403 from
robots.txt, which is the documented Fandom posture and fails closed as intended.
Reverse: 1999 is the one Fandom wiki that answered this time; its page bytes
moved but it parses to the same six events, so nothing on the calendar changed
for it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Two are worth building. MementoMori's current-events page parses today with no
parser change at all — seven events out of a seven-row table, six of them live.
Fire Emblem Heroes has the freshest page found anywhere here and states both
boundaries in their own columns, which is a shape the parser cannot read: not
two header words, but a title with a separate start and end, where the existing
Start/End reader wants the rowspan pair. It also publishes one real seven-month
banner, which the 180-day rule rejects as a misread year — a decision to make
before the fixture is written, because the fixture is the test.
The other eleven fail in three ways worth telling apart. Seven wikis are
abandoned, newest page between 2021 and 2025: they parse perfectly and publish
history, which is the failure a stale source hides behind. Gundam prints ends
with no starts, so no event ID exists to mint. Pokemon UNITE is current and
still refused, because its template fails canParse — the structural check doing
exactly its job rather than emptying a lane quietly.
Two method notes, both of which cost time. A hub's navigation is not an index of
its pages: four of these games have a schedule page linked from nowhere in the
nav, found only by searching. And "Last updated on:" separates a live wiki from
a dead one in a single grep, which is the check that was missing when Infinity
Nikki went a year stale.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
As written, the Blue Archive rule said a wall clock with no stated zone is
unparseable and that rounding it to a day "does not save it". Taken literally
that condemns every Game8 date in this repository — those state no zone either,
and are published at day precision without anyone minding.
What those Blue Archive tables actually were is narrower and worse: three of the
five did not say which server they described. A clock whose server is unknown
cannot even be labelled with a day, because you do not know whose day it is.
That is the case the rule governs, and it now says so.
Converting an unzoned clock by picking an offset stays forbidden, which is the
part that protects event IDs: the offset moves the day, and the start's day is
half of every ID.
Recorded because the rule and the Infinity Nikki source contradicted each other,
and AGENTS.md says that disagreement is a bug to fix rather than reconcile in
your head.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The Game8 page stopped being updated on 31 August 2025 and mentions 2026 zero
times, and it had been publishing five year-old events with endsAt: null — which
the app renders as live-with-unknown-end indefinitely. That is worse than an
empty lane, and nothing in the pipeline catches it, because a stale page is not
a broken one: it fetches, it parses, it passes every test.
The replacement is the game's Fandom wiki, permitted by the same standard
robots.txt that cleared Nikke, maintained to within two days, and shaped as
Current / Upcoming / Permanent / Past tables of Event | Duration | Description
| Type.
Its durations state a wall clock on both sides and no zone anywhere for that
column, so parseZonelessClockRange reads the clock and discards it, publishing
the printed date at day precision. That invents nothing and treats these cells
exactly as every Game8 date already is. Converting instead would mean picking an
offset, and the offset moves the day: July 16 20:00 read as UTC-7 is July 17,
and the start's day is half of every event ID this game will ever have.
The Game8 entry is removed rather than kept as a second opinion, since a source
whose every row is wrong is not corroboration. Its fixture stays: it is the only
page here carrying the labelled "Start: ... End: Permanent" shape, and the test
now drives it through the parser directly.
Titles come from a link's title attribute, which never passes through text(), so
they are entity-decoded by hand — otherwise "Alison's Travel Shop" becomes a
slug, and a slug is a localStorage key. The ingest sanitiser caught exactly that
during the build.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The lane's Game8 page is a year stale, and the last pass concluded there was
nowhere to move it. That was wrong: infinity-nikki.fandom.com is maintained,
permitted by the same standard Fandom robots.txt as Nikke, and its Event page
carries Current and Upcoming tables with full dates and clocks on both sides.
What it does not carry is a timezone on the Duration column. The page says
UTC-7 in prose about version launches and notes a 04:00 Server Time reset, and
the durations run 04:00 to 03:59, which only lands on a reset boundary if the
column is server-local. Strong, and circumstantial. It matters because the
offset moves the day, and the start's day is half an event ID.
Four options are written out with what each costs. The recommendation is to
take the printed date at day precision, which invents nothing and treats these
cells exactly as every Game8 date is already treated — and which contradicts
the Blue Archive rule as written, so that rule needs narrowing to say which
case it governs. Flagged rather than resolved: it changes an existing lane, and
retiring the game instead would drop a GameId that prefixes every completion
key its readers hold.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Its robots.txt was read in a browser and is the standard Fandom file: no
Disallow: / for *, /api.php?action= explicitly allowed, and only the namespaces
we never want refused. The AI crawlers it blocks by name are not us. That was
the one thing missing — the API itself has always answered our own User-Agent
with a 200, and it is only robots.txt that a datacentre address cannot read.
The zone lives in the column header, Start(UTC+9) / End(UTC+9), and no date in
any cell carries an offset. So the header is the safety property: a table that
stops naming its zone is refused rather than read as UTC, which is the Blue
Archive hazard arriving one column to the left.
Two shapes worth knowing. Every title is an image read from <a title>, and the
newest row is the one whose logo has not been uploaded yet — it renders as a
red link reading "File:Persona on Frontline logo.png", so a reader that only
understood the link title would silently drop today's live event. And story
events state a clock only on the end, so the start keeps the day the page
printed rather than being shifted nine hours into the previous one; the start's
day is half an event ID. That is the FGO rule applied to the opposite gap.
resetOffsets and resetHourLocal ship with the game because the page evidences
both: events end 04:59:59 and the banner replacing them starts 05:00:00, one
second later, on a stated UTC+9. Adding that later would re-label day keys
readers had already logged ticks under.
Seconds now survive the date helpers, since rounding 04:59:59 to the minute
would make an event overlap the banner that succeeds it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Every one of the fourteen sources was fetched and parsed. Twelve are healthy.
The two findings that are not about a game we just added:
Fandom's posture tightened on 2026-08-19 and now covers every wiki. Yesterday
blhx.fandom.com served robots.txt a 200, which is what the r1999 permission
argument leaned on; today every Fandom wiki tried answers 403 to our fetcher
and gives a real browser a challenge that never resolves. So r1999 and fgo are
permanently fixture-backed, and no new Fandom source can be added at all —
which is what blocks Nikke, whose data is the best of anything unbuilt. It is
blocked rather than declined: one person on an address Fandom serves can read
that file and unblock it.
Infinity Nikki's source is stale and there is nowhere to move it. The Game8
page was last updated 31 August 2025, mentions 2026 zero times, and publishes
five events with endsAt: null that read as live indefinitely — worse than an
empty lane, through a source that looks healthy to the runner because a stale
page is not a broken one. Every replacement was checked and none works. That
one is a decision for the owner, not a fix: retiring the lane drops a GameId
that prefixes every completion key its readers hold.
SOURCES.md carries each game's outcome and the reasoning behind the declines,
so the next pass does not re-derive any of it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
A normal `bun run refresh` from an address game8 serves, which is the only way
these nine pages move — the scheduled run in CI gets a 202 from game8's edge
and never lands them.
The two Fandom sources reported skipped_robots, as they now do from every
address available here.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Near matching exists to reconcile two sources describing one event under
different titles. Within one source it has no such job: the page has already
told us these are two rows, the parser has already dropped repeats of the same
id, and fusing them overrules a distinction the publisher made on purpose.
The loose 0.80 threshold that makes the rule useful across sources makes it
actively wrong within one. Umamusume's banner list runs "3 Star Guaranteed 1.5
Anniversary Scout (Character)" and "(Support)" concurrently — titles differing
by a single parenthetical, starting the same day — and fusing them dropped a
live banner off the calendar with nothing anywhere reporting it. A silent drop
is the failure this codebase ranks as the dangerous one.
Same-id fusion is untouched, so nothing duplicates.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
uma.moe stays declined — its API sits behind a Cloudflare Turnstile proof
header, and an adapter would mean defeating a deliberate access control. This
is the surface that is simply open, and it needed the parser change in the
commit before this one to be readable at all.
The stable URL matters: Game8 also publishes monthly "August 2026 Release
Schedule" pages whose id changes every month, which a static registry cannot
follow. "List of All Banners" does not move.
Four current banners, both columns of the side-by-side table, and none of the
Previous Banners below them. The tenth game8 source, so it carries the same CI
blindness as the other nine and only a manual refresh moves it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Game8's banner pages lay two schedules side by side inside one <table> under a
spanning label row: "Standard Banners | Banner | Rating | Availability | Paid
Banners | ...". That row is not merely unhelpful, it is plausible — it contains
both column words, so it resolves and puts the range at index 3, which no
three-cell data row has. Every row then fails to date and the table yields
nothing at all, with no error anywhere. So readColumnTable now falls back to
row 1, and only when row 0 produced nothing, which is what keeps every page
that parses today parsing identically.
Those pages also schedule banners rather than events and head their sections
accordingly, so the vocabulary learns "List of All Banners", "All Current
Banners" and — the one that matters — "Previous Banners", whose rows are dated
identically to the live ones directly above them.
This parser serves nine sources, so the widening was measured rather than
trusted: every pinned fixture and every live snapshot was parsed before and
after, and no existing source's output changed by a single event.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
No parser work at all — a GameId, a games entry, a SOURCES line, a fixture and
a test. The page lists six current events and the parser publishes four; the
two it skips print "Start Date: -", and no start means no event ID, so that is
the skip-never-guess rule working rather than a silent drop.
The cost is worth stating plainly: this is the ninth game8 source, and game8's
edge answers the Actions runner with a 202 and a bot-management body, so the
lane is built from a checked-in fixture in CI from day one and only a manual
`bun run refresh` moves it. freshness() discloses that in the footer, which is
what it is for.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This wiki publishes the same schedule twice and the fuller surface is the worse
one. /wiki/Banner_List has 55 clean rows with full wall clocks and states no
timezone anywhere on the page; the front page's Current Banners module emits
the same instants as real <time datetime="...-07:00"> elements. The two agree
exactly, which is strong evidence the list is UTC and is still only evidence —
so we read the surface that says what it means and pay four live banners
instead of a full history for it. If an editor ever states the zone on
Banner_List, that page becomes the better source immediately.
Two ways this could have failed silently. The template writes its BEM
underscores as __, so a selector written against the class name a
browser shows matches nothing at all; and banner names are red links to
?action=edit&redlink=1, which Miraheze's robots.txt disallows, so a href
carrying a query is refused and the page URL stands in.
No resetOffsets, and here the source did state an offset: -07:00, which is US
Pacific and therefore shifts twice a year. That is the Fate/Grand Order gap
arriving through a page that looks like it answered the question.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The best date material this project has after wiki.gg: every row states an
exact instant on both boundaries and names the zone, so nothing is converted
and nothing is assumed. `parseIsoClockRangeUtc` requires that `(UTC)` rather
than defaulting to it — a row that ever loses it should drop out instead of
landing hours off a boundary the reader is watching in-game.
The hazard here is the Server column. CN, EN and JP rows share one table and
the Chinese schedule runs about a year ahead, which is the akwiki CN-column
problem verbatim: publish EN, skip the rest. Betas are fenced off separately,
being dated exactly like everything else and playable by nobody, and the page
is an archive back to 2023, so currency is decided against ctx.now as in
bawiki. That leaves one live event today — thin, and true.
No resetOffsets: the EN boundaries land on three different clocks, which is a
patch window rather than a reset hour.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
PRD gets F15 and the fork that asked for it, DATA-MODEL the prefs field
and the fact that a script outside the bundle now reads that key, and
ARCHITECTURE the pre-paint script — the one piece of this that is neither
CSS nor React.
The AGENTS rule is the part worth reading twice: a component that names a
colour instead of a token now looks right in one theme and wrong in the
other, and nothing will tell you which.
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]>
The loudest feedback on the first release was "not enough games", so the
same wikis get researched again every pass — and the expensive half of
that work is not finding a page, it is establishing that a page which
fetches and parses cleanly is a 2021 archive, or states a wall clock with
no timezone, or belongs to a game that is shutting down in October.
This writes down what was actually checked on 2026-08-18: what each page
publishes, which existing parser can already read it, whether CI could
ever fetch it, and the hazard that would produce a confidently wrong date.
The verdicts stay proposals — once one is acted on the ruling belongs in
AGENTS.md § Scraping conduct, next to the sources already declined.
Indexed in the doc table so it is found before the search starts, not
after.
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]>
F1 described the scale only by how far out it goes — three months on a
screen — which left the close end reading as decoration rather than the
answer to two events ending a day apart. The suite count moves with the
test the previous commit added.
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]>
F1 described "one lane per game" as a fact about the timeline, which is
now false half the time, and the prefs key space did not list the pref
that decides it. Both say why the merged board sorts with
endingSoonestFirst rather than a bare end date, since that is the part a
later change is most likely to "simplify".
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]>
F4a called it "a bar at the top of the page", which the previous two
commits made false above `lg` — the working agreement's two-column bullet
and the PRD's desktop split both described a rail the bar was not in.
"Above everything it affects" is the rule that survived the move; where
that lands now depends on whether the layout has a rail.
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]>
A source that prints "August 19, 2026" and no time is stored at 00:00Z,
which is a placeholder for "somewhere in this day" rather than a claim
about when the day opens. The countdown read it literally, which turns it
into exactly that claim — and the UTC day is nobody's. Wuthering Waves
events dated the 19th were still running three hours after we had retired
them, because a European player's day opens at 04:00 on a UTC+1 server;
Asia was four hours out the other way and America nine. Sixty-two of the
eighty-six published events were affected, across ten of thirteen games,
so the reader was reading a wrong number far more often than a right one.
A day-precision boundary now resolves to the reset that opens that
game-day on the reader's server — the same grid daily.ts keys every tick
by, and the only clock we hold for a game. That is a reading of the date
the source printed, not a time invented for it: nothing stored moves, no
event ID moves, and the parsers still refuse to guess.
Two boundaries are never re-anchored. A regionEnds value is already the
instant a source stated per server, so anchoring it would throw a fact
away. And an event the reader typed in was resolved by readerInstant in
their own timezone, which is a stated time too — theirs.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Ticks are about to stop being its only caller: the countdown needs the same
grid, and daily.ts already imports time.ts, so asking for it the other way
would close a cycle. time.ts is where it belongs anyway — it has held
REGION_RESET_UTC_OFFSET all along, and serverOffsetUtc is that table's
accessor. Nothing changes shape; `shift` is exported as `resetShiftMs`
because dayKey now reads it across a module boundary.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
fgo-html.html was the rendered HTML already stored inside
fandom-events-2026-08-18.html, byte for byte — 793KB of it, in a
directory whose contents are pinned and kept forever.
agents/skills/add-game-source/ was a byte-identical copy of
.claude/skills/add-game-source/SKILL.md in a path nothing loads, so it
could only ever drift away from the one that does.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The adapter shipped with no docs at all, which left the one thing worth
writing down unwritten: this wiki publishes two servers' schedules on
two cross-linked pages, and the Japanese one parses just as cleanly as
ours. That now has a row in the assessed-sources table, a section under
Fandom, and a line in the ingestion pitfalls table alongside the akwiki
CN column and the bawiki JP tab — three sources bitten the same way is
a pattern, not a coincidence.
Also records what resetOffsets cannot express, since fgo is the first
game to need it: a server clock that shifts with daylight saving.
DATA-MODEL's GameId listing was two games behind the schema, missing
holodori as well as fgo.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Daily Quests is what the game calls the thing, not "daily missions".
The offset is the part worth recording. The English server is a single
worldwide machine on US Pacific — every duration on Event_List_(US)
says PDT — which normally earns a resetOffsets entry the way holodori's
JST did. It cannot have one: Pacific observes daylight saving and the
page itself alternates PDT and PST, while resetOffsets holds one fixed
number per region. Both -7 and -8 are wrong for half the year, and
either would re-label day keys twice a year for readers who logged
ticks under the other. So fgo takes the default and the gap is a
comment rather than a guess.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Every game names its gacha something else, and inferType only knew the
five words the game8 sources use. Fate/Grand Order calls its banners
"Summoning Campaign" — the whole of that page's banner vocabulary — so
without this every FGO pull lands as "other" and the type filter stops
meaning anything for that lane.
Nothing on the current English page carries the word, so no checked-in
expected output moves; the unit case is what pins the behaviour until
the next refresh brings a banner in.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The source landed pointed at Event_List, whose first sentence is "This
page lists all Events in Fate/Grand Order Japan". Every date it
published was a JP date on a calendar whose other twelve games are
global — the akwiki CN column again, and the failure this product
exists to prevent. Event_List_(US) is the English schedule and is what
the adapter reads now; a test asserts the URL so it cannot drift back.
The page is a different template from the Reverse: 1999 one, so the
parser branches, the way game8 branches over seven shapes. Its sections
are fenced by banner images with the label drawn in a positioned div —
no heading, no id — and only ONGOING EVENTS is read. FUTURE EVENTS
states a month with no day, and PAST EVENTS states no year at all, so
neither can be dated and neither is guessed at. canParse asserts both
dividers and the Duration label, which turns a redesign into a stalled
source rather than a lane that quietly empties.
The rewrite drops what the JP branch needed and this page does not: the
hand-rolled month/year rollover (parseFullRange already reads both
stated years), the any-typed locals, and a heading-to-duration regex
whose nested lazy quantifiers hung for minutes on a 620KB body the
moment one anchor stopped matching. Durations name a zone but no clock,
so the stated calendar day is kept rather than shifted into UTC —
there is nothing to anchor a conversion to, and the start's day is half
the event ID.
Also reverts two things done to quiet tests rather than answer them.
The parser no longer normalises NFKC: that was pre-empting the
sanitizer so "real fixtures need no repair at all" would pass, and the
seam is where repairs belong. And renderedHtml no longer reaches into
a legacy {"*": …} envelope, which every source here rules out by
pinning formatversion=2.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
