A guild master keeps a tracker the way they always have. A player checks off quests on a web page. The game itself notices the moment a quest is completed, photographs it, and packages the evidence for review. Nobody changed how they work — the machine formed around them.
Historical snapshot. This page records the 2026-08-06 Baseline vertical slice. Active Quest implementation and contracts now belong to comfy-quest; this page is retained as a public evidence narrative, not an implementation authority.
The guild masters this is for already run quests — in Google Sheets, Word docs, pinned Discord messages, and years of accumulated house style. The absorption engine's one rule: their content passes through verbatim; only the plumbing gets standardized. Anything that looks off is never silently fixed — it becomes a question routed back to the guild. Three communities with three structurally different artifacts have gone through it; none of the sources were edited, and all three project into the same picker.
Solid lines are built and running. Dashed lines are where the loop closes on humans: anomalies go back to the leader as questions, and the exported command lands in the ritual the guild already runs.
Absorption is only trustworthy if it is inspectable. Every artifact a leader hands over produces three named files they can open — and the missing piece is a surface that shows the whole journey at a glance.
The original spreadsheet is copied into data/raw/ and never edited.
A one-entry config in sources.json records which tab, which era,
which adapter, and when it was retrieved.
Each source keeps its native structure; a small adapter translates it to one canonical quest contract. New guild, new shape? New adapter — the rest of the system doesn't change.
Duplicate bot commands, mismatched screenshot counts, rows with a name and nothing else. A punch list the leader didn't have before, generated free with every harvest.
A page per source: this cell became this quest, this column became that evidence rule, these rows were flagged — with the anomalies pinned to the rows they concern. Open the receipts.
The catalogs render into a single self-contained page — no server, no
accounts, works from file://. A player filters 314 quests
across three communities, checks what they're chasing, and saves a
personal quest-view.json. The picker owns no data: it is a projection
of the absorbed truth, and a composer for one player's working set.
Most quest systems ask the player to prove what they did after the fact. This one watches for the deed — and a trigger only changes how a submission starts. Everything downstream is one pipeline.
QuestViewLoader is the web/game boundary: quest-view.json
must parse cleanly and match the schema exactly; failures go to status files,
never swallowed.
A hit on a world target, a kill with optional
weapon-skill and projectile filters, or a two-shot sequence — first hit is
shot one, that same creature's death is shot two.
Triggers count only the local player's actions, are cooldown-gated per quest, and a sequence binds to one creature instance — no farming a crowd for credit.
The file is the seam and stays the seam — only the transport changes. Both candidates keep every artifact inspectable on disk. This decision is deliberately still open.
The in-game F7 quest panel is functional, not impressive — it proves the loop but reads as a debug surface, and it needs a real visual pass before it can carry a demo. The picker-to-mod handoff is a hand-moved file. And the picker's own visual style predates this design language — the two surfaces don't yet read as one product. All three are known, tracked, and in scope; none are dressed up here as done.