They live in Your own, beside the reader's games and events. Every field
has a default the reader can accept unread (weekly, from Monday, ticked
off once) except the target, which nobody can guess for them. Save is
offered only when the store would accept what was typed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Some events want a number of points rather than a number of days. The
goal control gains Days and Points. Switching period keeps the measure
and the number, and the sheet keeps this period's number editable in
place. A target is capped where the schema reads it back, so a huge
number can't silently become no goal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tasks sit at the end of their game's group and are counted by their own
period, so a chore due Sunday is not "waiting on you today" every
morning. A number chip opens an editor under the strip instead of
ticking, since a chip is one target. Catch up offers last period's
number the way it offers yesterday's tick.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
They exist on this device and nowhere else, so an export without them is
a lossy backup. Both are additive keys, as custom games were: older files
lack them and still import. Tasks travel as stored, including any this
build cannot read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both stores keep what is on disk and validate where they read, unlike the
custom-event store. Filtering on load would let the next write delete a
newer version's records. Import merges by id, or by item and period for
amounts, and the later edit wins, so a restored backup cannot roll a
week back.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A task is a period that rolls on the game's reset and a measure that
fills it: days ticked, or a number against a target. Its status is the
goal status shape, so the dailies strip treats it like any other item.
Its ids get their own reserved space, as do the built-ins to come.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Weekly chores like 2,100 activity points are a number, not a count of
days, and monthly ones need a month. The status shape now carries its
measure and period start, so tasks can reuse it whole.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review found three ordinary actions that deleted a goal this build could
not read: "It repeats daily", pressing an already-pressed Off, and "not
daily" without saying so. Only "not daily" clears a goal now, and its
warning keys off what is stored, not what parses.
The count field was bound straight to the goal, so emptying it snapped
the old number back and typing appended to it. It now keeps a draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The goal sits under the checklist, where its count shows. With a goal
set, the caption counts against it instead of calling unticked days
missed. Reaching an event-wide goal offers Mark event done but never
takes it. Saying "not daily" says up front that it removes the goal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An event wanting five days of seven stays in the strip all week with its
count on the chip. Once the week is met it reads as done this week, and
it counts toward the header without a tick being invented. The burst
now watches today's ticks, so meeting a week by backfilling stays quiet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Goals ride the existing record, so export and the later-edit-wins import
merge carry them with no new key. Setting one clears a contradicting
"not daily"; saying "not daily" clears the goal, so no conflict hides
in storage.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Some events want five days out of seven, not every day. The goal is the
reader's input, recomputed from the day log on every read, so backfills
and week rollovers need no bookkeeping. An unreadable stored goal reads
as none instead of being stripped, so a newer shape survives an older
bundle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Check-in goals and weekly tasks both need a period longer than a day.
Working in game-day keys rather than instants means a week rolls exactly
where the game's own day does, per region, with no second clock.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every server's reset hour and offset was checked against it, so it is
credited beside the schedules' sources.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Game-Time-Master gives the reset as 05:00 JST (20:00 UTC). The previous
04:00 was read off a single mission ending at 3:59AM JST.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reverse: 1999 has an Asia server on UTC+8 alongside Global on UTC-5, both
resetting at 05:00. Asia readers were on Global's 10:00 UTC; theirs rolls
at 21:00 UTC. Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks for Asia readers.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Haoplay Asia resets at 05:00 UTC+8 and Haoplay Global at 21:00 UTC-8; the
app used the regional default at 04:00. Asia readers take the Asia server,
America and Europe take Global. Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
NTE resets at 05:00 server time, not 04:00, and its America server runs
UTC-4. Asia and Europe rolled an hour early; America lands on the same
09:00 UTC instant and day key as before. Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks in Asia and Europe.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One worldwide server on a fixed UTC-7 resetting at 13:00 (20:00 UTC); the
app used the regional default. Source: Game-Time-Master, which lists the
zone as fixed rather than Pacific.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Global server resets at 05:00 UTC; the app used the regional default.
Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The English/Japanese server resets once worldwide at 20:00 UTC; the app
used the regional default. Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One worldwide server resetting at 18:00 UTC; the app used the regional
default. Source: Game-Time-Master, corroborated by GameWith.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Umamusume Global resets once worldwide at 15:00 UTC (midnight JST); the app
used the regional default. Kept on the UTC calendar because the source's
dates are headed Availability (UTC). Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Blue Archive Global is one worldwide server resetting at 19:00 UTC, but the
app used the regional default (20:00 / 09:00 / 03:00 UTC). Source:
Game-Time-Master, corroborated by two guides.
Re-labels the game-day of some already-logged ticks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Infinity Nikki resets at 04:00 on America UTC-7 and Europe UTC+2, not the
regional default, so the app rolled the day 2h early for American readers
and 1h late for European ones. Source: Game-Time-Master.
Re-labels the game-day of some already-logged ticks for those readers.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A game's servers need not agree on the reset hour any more than on the
offset. Reverse: 1999 and Nikke spell their 05:00 out for all three
regions, so no reader's day key moves.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
readableHue returned every dark hue untouched on the claim that all of
them already cleared 4.5:1 there. Five did not, and Fate's navy was
1.8:1, so its name under the headline deadline was nearly invisible.
Those five are now lifted in lightness only, keeping hue and saturation;
the fifteen that pass are unchanged. The owner approved relaxing the
"dark theme does not move" rule to this, and AGENTS.md and PRD F15 say so.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Record lastConfirmedAt in snapshot metadata when a source is confirmed (200 or 304). This ensures git-committed snapshot metadata reflects when sources like wiki.gg were successfully pulled even when page HTML did not change, avoiding false pull overdue notices on downstream builds like GitHub Pages.
Document the forge responsibilities across AGENTS.md, README.md, ARCHITECTURE.md, INGESTION.md, and the CI workflow headers: GitHub Actions only builds and serves (Pages deployment) without fetching data sources, while Gitea Actions exclusively runs the scheduled refresh and publishes the container image.
When sources return 304, no git commit is created, but the cache holds updated confirmation timestamps. Publish the refreshed feed unconditionally on non-dry runs so CI rebuilds events.v1.json with fresh confirmation dates.
Derive source pull date from confirmation and recent content updates, preventing recently updated sources from displaying as pulled never or pull overdue.
The Blue Archive Wiki (bluearchive.wiki/wiki/Events) redesigned its
schedule, replacing the per-version MediaWiki tabber with a unified
#eventtable displaying JP and Global periods side-by-side.
- Parse #eventtable resolving GL Period, event titles, and article links
from .event-region-gl, with fallback to .event-region-jp.
- Maintain backwards compatibility with legacy tabber schedule format.
- Add pinned fixture fixtures/ba/bawiki-events-2026-09-17 and tests.
- Update snapshot, AGENTS.md, ARCHITECTURE.md, and INGESTION.md.
Move the scheduled refresh and container-registry CI workflows into
.gitea/workflows/ so Gitea Actions runs them natively. Update
.github/workflows/ci.yml to build with BASE_PATH and deploy to GitHub
Pages upon push from the mirror sync, removing the Gitea-specific
container registry step. Update Dockerfile, .dockerignore, and test
harness to test and copy workflows from .gitea/.
The pipeline change made a set of sentences false, and they are the only
record of why things are the way they are, so they move with it: the CI
section and deploy target in README, the cron and BASE_PATH notes in
ARCHITECTURE, the documented User-Agent in INGESTION, and the contact
URL in SOURCES.
Two comments in source were false in the same way and are fixed here
rather than left for the next reader. `serve.ts` said compression was
"the whole difference between the Docker image and the deployed site" —
the image *is* the deployed site now, so that negotiation is the only
compression any reader gets. `robots.ts` justified product-token
matching with "our contact URL contains the string StereotypicalCat",
which it no longer does; the hazard is the arbitrary substring, not that
one, so the comment now says so and the regression test keeps the URL
that actually caused it.
What is deliberately NOT rewritten: game8.co's refusal stays in the past
tense with the Gitea result marked unverified, in AGENTS.md, README,
SOURCES and FEEDBACK alike. A new runner address is the variable that
failure turns on, so it may well be served — but "may well be" is not
evidence, and the four places that would have to change are named
together so they change together once a cycle has actually run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add karendar.com as the event source for Punishing: Gray Raven (PGR).
Karendar publishes a dedicated Global event calendar with exact UTC
timestamps in clean server-rendered HTML.
- Register 'pgr' in GameId and GAMES registry (#CC292B, Kuro Games).
- Add parseWeekdayDayMonthYearUtc in src/ingest/dates.ts with unit tests.
- Implement karendarParser in src/ingest/parsers/karendar.ts reading
'week', 'ongoing', and 'upcoming' sections, mapping indefinite/permanent
ends to endsAt: null, and categorizing tags to EventType.
- Register pgr-karendar-events in src/ingest/adapters/index.ts.
- Add pinned fixture, expected output, and comprehensive test suites.
- Update documentation in AGENTS.md, README.md, docs/INGESTION.md,
and docs/SOURCES.md.
Add genshin-impact.fandom.com as a second source for Genshin Impact,
which has been fixture-backed in CI because Game8 CloudFront-blocks the
Actions runner with 202s.
- Add fifth Fandom template parser in src/ingest/parsers/fandom.ts
extracting titles from caption display text, stripping dated subpage
suffixes, and checking currency via latestBoundaryMs.
- Register genshin-fandom-events in src/ingest/adapters/index.ts and
set genshin-game8-events priority: 10 so existing event IDs survive
near-match ties, preventing localStorage completion marks from
orphaning.
- Explicitly sort adapter groups by priority descending in
scripts/build-feed.ts to align with parseGame.
- Pin fixtures and add test coverage in test/adapters/game8.test.ts.
- Update AGENTS.md, README.md, docs/INGESTION.md, and docs/SOURCES.md.
Patch cycles are ~6 weeks, so a span over 180 days previously indicated
a misread year. However, real year-long events exist in this domain:
Genshin's anniversary 5-star selection runs 336 days (2025-10-22 to
2026-09-23), correctly dated on its wiki, and Fire Emblem Heroes runs a
seven-month new-player banner (docs/SOURCES.md § 12b).
Widening the ceiling to 365 days admits genuinely year-long events while
still catching misread years, which place the end 12 months out (span +
~365, or 405+ days for a 6-week event).
Update test/adapters/game8.test.ts duration test, AGENTS.md domain rules,
and docs/INGESTION.md sanity checks.
The build log prints a count per source, and CI now declines to fail on
a page that states its own emptiness — which leaves that source showing
an unexplained 0, reading as exactly the fault the gate just decided it
was not. The zero we are content with is the one that has to say why.
It is also the only line that would ever prompt anyone to ask whether a
lane quiet for a month is a game between patches or a wiki that reworded
the sentence a statesNoEvents check is still matching. Nothing else in
the pipeline can tell those apart.
The test count in the layout block was stale at 898 and moves with these
two commits, so it is corrected here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Infinity Nikki's wiki prints "There are no Events in this category"
between versions, and the refresh runner has honoured that since
2026-09-03 — it stores the empty parse as the source's real answer
rather than letting a quiet lane reach the broken tier. The feed build
never asked, so the same page arrived at CI as parsedCount 0,
indistinguishable from a parser that has stopped reading a redesigned
page, and brokenSources failed every build while every refresh stayed
green.
The runner's verdict cannot travel on its own: only a parser has seen
the page, and by the time brokenSources runs there is nothing left but
the feed. So the fact rides on SourceHealth, defaulted so an older feed
the service worker cached keeps validating and reads as the strict
answer.
Both ends now ask it the same way — of an empty parse only, from the
page's own words only — because a redesign yields zero rows too, and
excusing that is the silently emptied calendar the gate exists for.
The rule sits in a module rather than in build-feed.ts, which writes
public/ and so runs a build if a test imports it. That is how the two
ends drifted apart with nothing to catch it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Refusing every zero-event body is right when the alternative is silently
emptying a calendar, and wrong when the page has told us it is empty. A
gacha game goes quiet between versions, and read strictly that is a source
failing every cycle until the next patch ships: three of them reach the
broken tier and fail the workflow over a lane that is correctly empty,
while the snapshot being held ages out of date. Infinity Nikki sat in
exactly that state for four cycles.
So an empty parse is stored when the source's `statesNoEvents` vouches for
it, and the cycle counts as confirmed rather than failed. Everything else
is unchanged: a body that parses to nothing on its own still keeps the
previous snapshot, and a first fetch that yields nothing still stores
nothing.
The gate turns on the page's statement, never on the adapter merely being
able to make one — otherwise implementing `statesNoEvents` would quietly
switch the zero-events gate off for that source. A test pins that.
The run says which of the two empties it saw. "0 events — down from 6"
reads as the shape change it is not, and that note is what somebody
checking on a quiet lane actually sees.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The wiki emptied both its Current and Upcoming tables on 2026-09-03 — 2.7's
events had ended and 2.8 was not listed yet — and said so in words: "There
are no Events in this category". Nothing else moved; Past Events still
carries twenty tables of the same shape.
`isInfinityNikkiEventPage` looked for a *populated* table, so it read that
as a redesign. The source spent four cycles reporting "the source has
likely been redesigned" at a page nobody had touched, reached the broken
tier, and went on serving a snapshot whose every row expired on 27 August.
A check that reads data cannot tell a rewrite from a quiet week. It now
reads the section headings, which an empty table does not take with it —
either heading rather than both, since requiring the pair would fail the
source over a renamed heading it does not even read, and one already
separates this page from the other three Fandom templates. docs/INGESTION.md
asked for structural checks all along; this one had drifted into content.
`statesNoEvents` then reports the page's own declaration, so the runner can
tell an answer from a failure. It insists on the statement rather than an
empty table, because a redesign yields an empty table too.
The emptied page is pinned as a fixture: an empty answer is a shape, and it
is the one that used to read as a redesign.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The footer's staleness notice is an instruction, and the only remedy it
offers is "go and check that game's source page". That is not something a
reader can act on for a game they turned off and cannot see a single row
of — and with nineteen lanes, naming eleven they do not play buries the one
they do. A new lane arrives switched off (F8), so an untouched install was
being warned about most of the catalogue.
Scoped in two places, not one: the named list, and the count the
summarising branch measures against. Without the second, that branch would
never fire for a reader with most of the calendar off and they would get a
list where a sentence was the readable answer.
The notice now also states whose games it counted, in the words NextUp
already uses for the same set. Narrowing what the footer measured while
still printing "nothing has refreshed" would turn a claim about four games
into one about eighteen, in the one paragraph on the page whose job is
being trusted about age.
The headline age and the credits stay whole: the first is a fact about the
feed and feeds the bug form, the second is attribution owed to every source
we read regardless of what is on screen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CI failed on Infinity Nikki yielding no events, and was wrong to. Its
snapshot parses to six events; every one of them had ended by the morning
the build ran. The parser is fine — `--now 2026-08-14` gives six, today
gives none — and the page simply has nothing current left on it.
eventCount is counted after expired events are dropped, so "this parser has
stopped reading a redesigned page" and "this page's events have all
finished" arrived as the same zero. Only the first means our code is wrong,
and only the first should redden a build. So the feed now records what each
document yields parsed as of its own capture date, before expiry, and the
check fails on that instead.
Nikki cannot refresh itself out of this, either: docs/SOURCES.md records
that Fandom refuses the Actions runner. A lane with an empty calendar is a
real problem, but it is a refresh problem, so it is reported on the build
log and left visible rather than thrown.
parsedCount is nullable and defaulted, never required: the client validates
the whole feed with safeParse and the service worker serves the last feed it
downloaded, so a required field would have made every cached feed fail
validation and taken the offline promise with it. Null also covers a source
whose bytes were never confirmed live — there is no date to parse "as of",
and a build is not failed on missing information.
The rule moved to shared/feed.ts. A test did pin the old one, by grepping
the workflow for the string — which proved the check existed, never that it
was right.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review pointed out that `dailyGroups` was well covered and the wiring to it
was not: passing the wrong pref from App, binding the checkbox to a
neighbour, or hardcoding `true` in Dailies each shipped with the suite
green. Three of those are now caught by rendering the strip and the settings
panel rather than the function behind them — verified by performing the
mutations, not by reading the code.
The fourth, App handing Dailies the wrong pref, is still uncovered: no test
renders App, and closing it needs a feed and a click library this project
does not have.
Also pins the default. Flipping that one line silently empties Today's
dailies for every existing reader, which is the whole argument of the
comment above it, and nothing was watching — `defaults` is exported so the
value and the upgrade path can both be asserted.
And DATA-MODEL's enumeration of the prefs blob had gone stale; AGENTS.md
names it as the doc to update when a stored key moves.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Today's dailies carries two different things: each game's standing chore —
"Commissions, resin", a fixed list nobody publishes — and any event with a
checklist. The first is the app guessing at a routine the reader never asked
for, and it was the only part of that strip with no way out.
So the switch removes exactly that. Events keep their checklists whatever
their source, including ones the reader added themselves and marked daily,
which was the requirement most at risk of being filtered away by a switch
aimed at something else.
Nothing is discarded. The ticks live under `dailies:<game>` and nothing here
reads or writes them, so switching back on restores every logged day and
every streak — the same promise `detectDaily` already makes. Defaulted on,
because everyone has these today and a setting that silently removes
something on upgrade is worse than one nobody notices.
Gating where the chore is built rather than where it is drawn means the
counts follow for free: "N still waiting on you today" is derived from the
items, and a game left with nothing contributes no group at all, so the
strip's own empty guard drops it rather than leaving a heading with no rows.
Named for what it removes. A switch called "dailies" would read as broken
while the strip stayed on screen showing the reader's own events.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
