ADVENTURE LOG

Archive — the system as it was (2026-07 → 2026-10-22)

Everything from here to the changelog is the record of the retired system, kept in the present tense it was written in. None of it is in the game today; the server keeps an account action log that only the GM console reads.

A permanent, chapter-bound chronicle of everything that has ever happened on the account — hatches, advancements, breedings, floor clears, boss kills, deaths, realm events, and every battle fought. The log itself never forgets; only the depth of battle detail is pruned over time.

Architecture — events, not text

• The log is an append-only event stream, not stored prose. Each entry is a compact record: {timestamp, event_type, param_ids[]} — e.g. {t, HATCH, DFMC-042}, {t, ADVANCE, DFMC-044 → DFMC-045}, {t, FLOOR_CLEAR, 17}.
• Display text is rendered at view time from string templates plus codex CSV data. Renaming a creature or rewording a template retroactively fixes the entire history.
• Cost per event: ~68 bytes live, ~7 bytes once archived (Storage budget, below).
• Storage: device-local, inside the local save JSON in localStorage. The newest events live expanded in advChapters (newest-first, one chapter per day, advPush / advTrim); older ones are packed into gzip advArc blocks with a day index. There is no database. No server round-trips to read the log.

Chapters

• Chapters are days of the one event stream, not separate documents. A live day is an advChapters entry; an older day is found through the archive’s day index and unpacked from its advArc block.
• The chapter list UI shows one entry per active day (or per zone milestone on the same screen). Opening a chapter loads only that chapter's events, paginated — the full history is never held in memory.
• Because chapters are slices of the stream, they cost nothing extra to store and can be re-cut later without touching the data.

Event types

HATCH ALL is one event

• A single-egg hatch writes HATCH (or MUTANT_HATCH) with the full per-creature fields. The soul bag's HATCH ALL button does not: however many eggs it opens, it writes exactly one HATCH_BATCH.
• The batch carries the hatchling count, the grade tally of what came out, and the species breakdown sorted by count, capped at six entries with +n more beyond that. The cap is a storage rule, not a display one — the string is written at hatch time and lives in the save forever.
• A mutant is exempt. Any mutant in the batch still writes its own MUTANT_HATCH line alongside the batch line, and is also counted in the batch's mutant tally. Mutants are story events and are rare enough to deserve the room.
• Rationale: one press of HATCH ALL on a full soul bag wrote 85 separate events, which buried the chapter it landed in and was then carried in every save from that moment on.

Param IDs reference codex CSVs; the log stores no names or descriptions. Ordinary per-battle XP ticks are not logged as separate events — they live inside the battle summary.

Battle Logs (sub-item of the Adventure Log)

• Battles are not deterministic, so full turn-by-turn data must be recorded — there is no seed-replay shortcut.
• The adventure log itself holds only a battle summary row: participants, result, turn count, rewards, and a battle_id.
• Full detail is the fight’s own log lines, packed by blAppend against a word dictionary (blW words, blS labels) into pending streams keyed by battle_id — about 44 bytes a fight. See How a fight is stored, below.
• Each battle's turn array is serialized and gzip-compressed as one blob (3–5× reduction) before storage. Nothing is decompressed until requested.

Viewing a battle log

Retention policy

• Compaction deletes only the detail blob; the summary row (and therefore the chapter narrative) is never lost — the log loses replay depth, not history.
• After compaction, the Battle Log button on an old wild battle shows the summary card with a "detail expired" state instead of turn-by-turn text.

Storage budget — compress first, shed only at the cap

Nothing is deleted until the archive is full. Every event and every battle's numbers are kept, because they are balancing data to be pulled off real players; what changes with age is how they are stored. The archive is capped at 1,029 KiB and sheds its oldest whole blocks past that (The budget, below).

Measured on the two worst real accounts, with the full history intact in both cases: 905 KB → 373 KB (500 live events + 3,380 archived in 38 KB) and 638 KB → 317 KB. Applied on write and on load, so an oversized save shrinks the moment it is opened.

High-frequency events use one-letter keys — {c:37,g:{Worn:22},y:'+148 Scrap'} — and a bulk action is always one event: dismantling 113 eggs costs one line with a grade tally, never 113 lines.

Reading the archive

The archive is DEVICE-LOCAL and does not reach the server. The Stage 4a save diet strips advArc, advChapters, advBattles and floors from every upload — they were 89% of a real save's bytes, and advArc riding the upload was itself the 2026-08-01 save-ceiling incident (68,560 B of a 127,115 B save; /api/save refuses over 131,072 B). So /api/backup/export does not carry log history, and a new device starts with an empty log. Pulling history off a player is the on-demand advlog extraction round (admin-backend.html §8). Each block is {n, z} (gzip, base64) or {n, t} (plain), plus the day index below. Unpack a block's text into events by splitting lines on \n and fields on \x01 — ts, TYPE, JSON params:

import gzip, base64, json
for b in save.get('advArc', []):
    txt = gzip.decompress(base64.b64decode(b['z'])).decode() if 'z' in b else b['t']
    for line in txt.split('\n'):
        ts, typ, params = line.split('\x01'); ev = (ts, typ, json.loads(params))

The day index — how a per-day view is possible at all

On release since 0.64. A packed event carries only ts = HH:MM. The DATE lived on the chapter object, and advTrim drops a chapter the moment its last event is archived — so the archive was a single undated stream. Nothing was ever lost; the history simply could not be cut into days. That is the whole of “the log only shows a day”.

• DAY marker. advTrim writes {ts:'00:00', type:'DAY', params:{k:<dayKey>, t:<date>, c:<chapter title>}} into the packed stream when the day changes and whenever a fresh block opens. Every event after a marker belongs to that day until the next marker.
• Every block is self-describing. The marker at each block head is the load-bearing half: without it a block that opens mid-day loses its leading non-battle events. Measured at 14 of 156 on a real-shaped day before the rule was added.
• Block header, never compressed. d is the list of dayKeys the block holds; dl is the last day it declared, so the next append knows whether it owes a marker. A day grid is drawn from d across all blocks with zero decompression; opening one day decompresses only the blocks whose d lists it (measured: 2 of 5 worst case, 0.7 average over 30 days).
• Marker is the truth, d is a cache. A reader that finds them disagreeing trusts the marker and repairs the header.
• advArcCompact re-declares the running day at the head of every regrouped block. The heal splits blindly by index, so without this it destroys the index it exists to carry.
• A BATTLEROW is a RECORD, not a log entry. It is the compacted detail its BATTLE line points at, is looked up by id, and must never be rendered or counted as an event — doing so double-counts every archived day.
• NEVER date an event from its battle id. A battle_id is 'B-' + Date.now().toString(36) — epoch ms, i.e. UTC — while a chapter's dayKey is toDateString(), the device's LOCAL date. At UTC+9 a 07:00 battle decodes to the previous day, so id-dating puts every morning on the wrong tile. Id-dating survives only as an approximate rescue for archives written before markers existed, where it is accurate to within one day at the boundary.
• Cost. One marker per day plus one per block: 1.9% of the archive. A marker per moved slice would be a marker per event — once the live window is full advTrim runs on every event and moves exactly one — which measured 7.4%, the same shape as the 2026-08-01 gzip-per-single-event mistake.
• Ceiling. Web Storage is ~5 MiB per origin and the local slot is written twice (a once-per-session _bak copy), so the practical budget is ~2.5 MB against a ~102 KB non-log save. At ~37 B per archived event that is roughly 57,000 events. A full store raises QuotaExceededError; the save path catches it, sheds the oldest archive blocks and writes again (The budget, below).

Retrofitting an archive written before the index

The dates were never gone — an earlier note on this page said they were, and that was wrong. Every BATTLE and BATTLEROW carries params.id / params.i = 'B-' + Date.now().toString(36), the exact epoch millisecond at which advPush minted the dayKey, and new Date(ms).toDateString() is that same call — so it reproduces the original key exactly on the device that wrote it.

• Anchors. Battles date themselves exactly. Everything else sits in a chronologically ordered stream between two battles and takes the day of whichever it is nearer to in elapsed clock time, wrapped at 24 h.
• Elapsed distance, not clock order. “Is this later than the previous battle?” is right 99.3% and wrong on exactly one shape: a session that opens later on the clock than the previous one ended, on the next day (yesterday finished 16:00, today starts 21:00). Clock order cannot tell “later today” from “later tomorrow”; elapsed distance can.
• Measured. 5,556 entries over 41 days: 100% exact in Asia/Tokyo, America/Los_Angeles and Pacific/Kiritimati, nothing unresolvable. Control: naive UTC-day arithmetic misplaces 991 battles in Tokyo and 3,973 in Los Angeles.
• Strictly additive, with a census. Markers are inserted; nothing is removed, reordered or rewritten, and a count of every non-marker line must match before the heal commits. It runs once, ahead of advArcCompact, and is a no-op once every block carries d.
• One caveat with no fix. It reads dates on the device that wrote them, so a player who has moved timezone since will see those older days shift by up to one. Nothing detects this and no method can.

Only entries with no battle anywhere before or after them stay undated, and fall to the reader’s “Earlier” tile.

The day grid — what the player sees

On release since 0.64. The log opens on a grid of tiles, one per day, newest first. Archived days are included — which is the whole point, because a day whose events had all been packed away used to disappear from the list entirely, and that is what “the log only keeps a day” actually was.

• A tile carries the chapter number, the date and the entry count and nothing else.
• The grid costs no decompression. Tiles are built from block headers alone; the count lives in the header (d is {dayKey: entryCount}) precisely so that a tile does not have to open anything to know its number. A pre-count archive shows a dash rather than a wrong number.
• Opening a day unpacks only that day — the blocks whose header lists it, measured at a worst case of two of five.
• The chapter number is DERIVED from position, and it has to be. The stored title is a roman numeral of how many chapters existed when the day began, and emptied chapters are dropped as they archive — so the counter shrinks and the stored numerals repeat. A full-history grid built on stored titles shows two Chapter IIIs. Position in the day list is stable forever.
• Order comes from the archive, not from parsing dates. Chapter slices are appended oldest-first, so first-appearance order is already chronological.

The budget — what happens when the device fills

On release since 0.64. The archive is capped at 1,029 KiB and sheds its oldest whole blocks when it exceeds that.

• The number is measured, not assumed. On a real save in a real browser the per-origin store ceiling binary-searches to 5.00 MiB; the slot is written twice (a once-per-session backup copy), so the real per-copy room is ~2.62 MB; and everything that is not archive, each part at its own cap, comes to 511 KB — the save itself ~104 KB, the floor cache ~66 KB, the live 500-event window ~47 KB, 200 battle rows ~37 KB, 25 full battle logs ~257 KB. That leaves ~2.11 MB, and the budget is half of it — roughly 28,000 entries, about nine months at a measured 110 entries a day.
• The floor cache used to dominate everything, and now does not. It is not images — it is the text of each encounter, and each of a floor's ten slots carries its own creature plus the two battle extras the server sends with it, so a slot is ~1.3 KB and a floor ~13 KB. Across 120 floors that was 1.58 MB, sixty per cent of the whole per-copy budget, larger than everything else put together, and nothing had ever pruned it. It now keeps the last five floors — 66 KB instead of 1.58 MB — which is where the log's room came from.
• Two halves. Ahead of time, the oldest blocks are dropped after each seal. And if the store fills anyway, the save now catches the refusal, sheds oldest blocks and writes again — it used to swallow that into a console line, so the player kept playing with nothing being stored and no sign of it.
• Whole blocks only, and never the newest. A half block is an archive with no day marker at its head, which is the one thing the day index cannot survive.
• Roughly 28,000 entries, about nine months at a measured 110 entries a day (the figure above; ADV_ARC_BUDGET).

How a fight is stored

On release since 0.64 (abfb7fa). A fight used to be kept as rendered English in plain JSON — about 5 KB each, and only 25 kept, which on autoplay is under an hour of history. Packed, a fight is 44 bytes, and every number stored is the number that happened.

• Not a replay. Rebuilding a fight by re-running combat would show damage that never happened once the game is rebalanced. It is also lossy: three writers add lines to a fight — the action, an event's effects, and end-of-round damage-over-time — and only the first is recorded as structured data.
• It knows nothing about any sentence. The lines are built inside the battle module, so hand-written templates would be guessing at shapes that move whenever combat text changes. Instead: pull every run of digits into its own column, split what is left on whitespace, index the words. Re-insert the digits and the line comes back byte for byte.
• Columns must stay columns. Packing each fight into a self-contained row re-interleaves the words with the digits and costs 430 B a fight instead of 45. The buffer holds two growing streams, not a list of rows.
• Seal small, compact later. Cost tracks how much the compressor can see at once — 269 B merging at 64 KB, 150 at 128 KB, 93 at 256 KB, 44 at 1 MB — but waiting to fill a big block would need a big buffer. So seal at 32 KB and merge lazily, the same shape the archive already uses.
• It checks its own work. Every fight is packed, read straight back, and compared line by line; anything that does not match is kept as prose instead. A log must never say something the fight did not.

At 44 bytes a fight, 200 fights a day costs 9 KB and a thousand costs 43 KB. A 512 KiB budget holds around 12,000 fights.

The budget bounds the whole store (lane I, 32391b5, on dev): the sealed blocks, the pending streams, the fights kept as prose because they failed the round trip (blRaw) and the word dictionaries (blW, blS) all count toward BL_BUDGET. Past it the oldest sealed blocks and raw fights are shed together, oldest first, and the newest block always stays. The dictionaries cannot lose single entries, because sealed blocks index into them, so once they pass a quarter of the budget they are rebuilt from the fights still stored.

Changelog

• 2026-11-03 — codex review (dfmc-client lane codexreview-a; D 2026-11-03 “review the codex, clean it up, update whatever needs updating”). The page is a record, not a manual: the body below the retired banner is now headed as the archive and says so; the REALM_EVENT row no longer reads “planned” (realms and seasons left the game on 2026-08-28, nothing was ever going to write it); the Notices pointer and the server-side account log are named in the banner. No mechanic changed.
• 2026-10-22 — RETIRED: the player-side log leaves the game (ADVLOG-OUT, client half (D, Tower rulings form card T31-2; dfmc-client lane advlog-client). LIVE on release since 2026-10-23 (0.89).) The ADVENTURE LOG plate is off the main menu and the window, its day grid, battle view and both exports are gone, with every event the client wrote into it (battles, hatches, breeds, upgrades, dismantles, purchases, sockets, devours, advancements, floor clears, boss kills, deaths). The device stores none of it any more: advChapters, advBattles, advArc and the packed battle-log store (blW … blRaw) left the save, and the hourly /api/advlog/upload check-in is gone (the server half answers 410). The PvP replay never read this log and is unchanged. The floor-101 letter and the UNLOCK lines are now notices: a short list derived from the account’s tutorial flags, shown at Settings > Notices, where the letter can be read again.
• 2026-10-01 — the XP on a fight’s row is the server’s figure too (review lane AB follow-up, dev 0afcb21). LIVE on release since 2026-10-23 (0.89). The same fault as the Ichor entry below: the row kept the client’s XP estimate after the server answered with its own. When the server credits the fight, the stored record and its row now take the server’s XP, as they already take its Ichor.
• 2026-10-01 — the round count, the Ichor figure and the chapter count (review lane AB, dev 2a4e144). LIVE on release since 2026-10-23 (0.89). A fight’s detail header read 0 ROUNDS while its row read 2: the header counted turnsLog, which a fight in the packed store no longer carries. Both now read one count (the stored rounds, else the unpacked block). A victory whose Ichor the server corrected showed the server’s figure on the spoils (16) and the client’s estimate on the log row (+18); the fight’s record and its BATTLE entry now take the server’s figure too. A chapter with one entry says 1 ENTRY.
• 2026-09-30 — review leftovers F6-012, F287, F288 (client, lane P). On dev. How a fight is stored now says in the body, not only here, that blRaw and the word dictionaries count toward BL_BUDGET. Two dead helpers of the packed store, BL_BLOCK (the fight-count block size the byte seal replaced) and blGunz, are removed. Back from a battle view with no day behind it opens the chapter list; it used to build a chapter-index view that no longer exists.
• 2026-09-30 — review fixes F278-F282, F286, F289, the battle-log bound (lane I). On dev. BL_BUDGET now bounds the WHOLE battle-log store, not only the sealed blocks: fights kept as prose because they failed the pack round trip (blRaw) count toward it and are shed oldest first together with the blocks (the newest block always stays), and once the word/sentence dictionaries (blW/blS) pass a quarter of the budget they are rebuilt from the fights still stored, so words that only the shed fights used leave with them. A fight finished while a block was being sealed is no longer lost (the seal removes only what it packed), and the idle merge of small blocks no longer re-packs the whole store on every seal, drops a block sealed while it ran, or brings back a block the budget had shed. The adventure archive keeps every event moved out while it is being re-grouped (the heal commits only if nothing touched the archive meanwhile, otherwise it runs again), and the events trimmed out of the live window when a save loads land in the loaded archive instead of being lost. The multi-device read of a round's upload now shows a day two devices both played as the union of both devices' events, not the last device's. The event table now lists LETTER and marks EQUIP_UPGRADE, LEAGUE_EVENT and REALM_EVENT as not written yet. Gates tools/probe_advlogstore.py, tools/probe_nameclaim_merge.py.
• 2026-09-30 — review fixes Q10/F273, F6-016 (lane D). On dev. The packed battle-log store (blW, blS, blBlocks, blPS, blPN, blIds, blRaw) lived only in memory, so every reload lost the round-by-round detail the log opens; it now rides the LOCAL save slot beside advArc (runSnapshot saves it, the load reads it), is stripped from the server copy by serverSnap and by the save door (the server save does not grow by a byte), and stays bounded by BL_BUDGET. The login splice that reunites the device half with the server save read it from the legacy key the app deletes on every boot, so from the second login on nothing was spliced back and the adopted save overwrote the device log; it now reads the slot the app writes. A full device sheds the oldest whole block of whichever log is larger (archive or battle logs), never the newest, and when the save still will not fit the player is told once that the logs are no longer kept on this device (progress still saves to the server). Gate tools/probe_blpersist.py.
• 2026-09-30 — review fix F226 (server). Once-per-round extraction is now enforced by the server, not only the client: /api/advlog/upload refuses any round but the active one (inside its window), answers a second upload from the same account and device with no write, and takes at most 3 devices per account per round — all before the shared r2_write budget is spent, so a looping client can no longer drain the budget the save mirror pauses on.
• 2026-09-30 — review drift fixes: F284, F285. WIKI ONLY. The Architecture, Chapters and Battle Logs sections still described a SQLite database, WHERE ts chapter queries and turn-action structs; the log is local save JSON (advChapters plus gzip advArc blocks with a day index) and fights are packed against a word dictionary. Storage budget said nothing is ever deleted while the archive is capped and sheds oldest blocks; the Ceiling bullet said the quota error is swallowed while the save now catches it and sheds; the 25-battle row is legacy-only; the second budget figure (22,000 / seven months) now matches the first (28,000 / nine months); How a fight is stored is on release, not ON DEV. DESCRIPTIVE ONLY.
• 2026-09-30 — the log's readers catch up with the day grid, the archive and the packed store. ON DEV. Four readers were still written for the log as it was before the archive. Back from a fight opened on a day tile now returns to that day; it used to land on an empty, untitled chapter. A fight whose record has moved to the archive (past the newest 200 wild fights) now shows its result, floor, experience and ichor from the entry itself, instead of a blank line reading “FLOOR — · 0 ROUNDS”. The oldest live day, which is always half in the archive once the log is full, now opens with both halves, so the entries match the count on its tile. The exports read the whole log: the event log and the complete log include the archive, in order, oldest first, and a fight's export and the complete log carry round detail from the packed store, which they had never read. The complete log's header no longer claims detail is kept for the last 60 battles. Nothing stored changed shape (review C25: F274–F277).
• 2026-08-30 — fights are recorded again; nothing was being written since 0.64. ON RELEASE (0.64). The store keeps its word dictionary as a lookup rebuilt whenever the saved copy changes. On a save that had never written one there was nothing to notice a change in, so the lookup was never built at all — and the dictionary is only written once a fight has been recorded, so no save could get itself out of it. Every fight failed to record from the moment the store shipped. Because recording happens before the battle is reported to the server, the whole end-of-fight step went with it: no experience, no ichor, no drops, no victory screen, and another round handed back against an enemy team already down. Nothing in the format changed and no stored history was lost — the fights from those hours were simply never written.
• 2026-08-28 — the packed store is wired; fights are recorded into it. ON DEV. A finished fight no longer puts its prose on the row — it goes to the store, and only the round count stays behind so the fight list never has to open anything to show it. Opening a fight unpacks it once and caches it. Rows still holding prose from before the store existed keep working and migrate as they are rewritten. The 25-fight limit now applies only to those; packed logs are bounded by bytes instead, which is what the cost actually is.
• 2026-08-28 — a fight is stored in 44 bytes instead of 5 KB. ON DEV, packer built and gated, not yet wired. Combat logs were kept as rendered English in plain JSON and only 25 fights survived. The new store keeps every line exactly, knows nothing about any sentence so it cannot go stale when combat text changes, and checks its own work on every fight. 116× smaller, so a full day of fights fits where an hour used to.
• 2026-08-28 — the archive is capped and sheds its oldest history when full. ON RELEASE. 1,029 KiB, sized as half the room actually left after measuring the store ceiling and everything else that competes for it. Whole blocks from the oldest end, never the newest, and a full device now sheds and saves instead of failing into a console line nobody reads.
• 2026-08-28 — the log opens on a grid of days, and a day unpacks when you open it. ON RELEASE. One tile per day — chapter number, date, entry count — drawn from block headers with no decompression at all; opening a tile unpacks only the blocks holding that day. Archived days appear alongside live ones, so a day no longer vanishes the moment its last event is packed away. The header gained per-day counts so a tile can show one without opening anything, and the chapter number is now derived from position because the stored numerals repeat once emptied chapters start being dropped. One entry formatter serves both a live day and an unpacked one. Verified on the rendered screen, not the payload: six tiles drawn with their counts and dates, newest first, and the oldest — which exists only in the archive — opening to 120 entries.
• 2026-08-28 — history written before the index is retrofitted, not abandoned. ON RELEASE. This page previously said the dates of pre-index events no longer existed. They do: a battle id is the exact epoch ms of the moment the dayKey was minted, and toDateString() reproduces that key on the device that wrote it; everything else brackets between two battles by elapsed distance. A one-off heal dates the whole archive and writes the markers in permanently, strictly additively and behind a census that refuses to commit if a single line would be lost. 100% exact over 5,556 entries and 41 days in three timezones. Gate 15/15, red-first.
• 2026-08-28 — the archive gains a day index; a per-day view becomes possible. ON RELEASE. Archived events carried only HH:MM and the date lived on a chapter that is dropped as soon as it empties, so the history was one undated stream — the reason the log appeared to keep only a day. advTrim now writes a DAY marker on a day change and at every fresh block, and each block header carries d (its dayKeys) and dl (its last declared day), uncompressed, so a day grid draws from headers alone and only the opened day is decompressed. advArcCompact re-declares the running day per regrouped block. Also corrected here: advArc has not ridden the save since the Stage 4a diet, so the backup export does not carry log history — this page claimed it did. Three defects were caught by tools/probe_advday.py before shipping and are written up above: per-slice markers becoming per-event, BATTLEROW counted as an entry, and UTC id-dating against a local dayKey. Gate 10/10, red-first 4/10. Write side only — no reader surfaces the day index yet.
• 2026-08-01 — the archive packs before it compresses, and rows keep their time. Overflow was gzipped and base64'd the instant it happened, and once the live window is full the overflow is exactly one event — so a 405-event archive was 405 single-line blocks. gzip has nothing to find in a 100-byte line and costs an ~18-byte header, then base64 adds a third on top: measured 40,912 B of text stored as 68,560 B, larger than not compressing at all, where one packed block is 7,856 B. Events now land in a trailing plain block and are sealed into gzip only at 16 KB, and a fragmented archive is re-packed once on load (405 blocks → 2, every event preserved). Archived battle rows were also being built with an empty ts field and losing their time — 275 of 405 in a live save; the row now carries the timestamp stamped when the battle was recorded.
• 2026-07-28 — HATCH_BATCH added: HATCH ALL now writes one event for the whole press instead of one per hatchling, carrying the grade tally, the capped species breakdown and the mutant count. Mutants keep their own line. Documented under Event types.
• 2026-07-28 — events carry what actually happened. Every event above recorded little more than a name. HATCH and MUTANT_HATCH now carry grade, sex, the egg's grade and where the egg came from (bred in pen N, or found on floor N); ADVANCE carries the level and stage it happened at; LEVEL_UP carries the level it came from; BOSS_DEFEATED carries floor, rounds and how many of the party were still standing; DEATH carries floor, killer and rounds. BREED was never written at all — the renderer existed and nothing called it, so a pen laying an egg produced no entry; it now fires on lay with both parents, their grades, the pen, and the egg's grade and species.
• 2026-07-28 (second pass) — everything else logged, under a budget. Added UPGRADE (grading an item or a class soul, including the failed roll that spends the bundle and previously left no trace), DISMANTLE (one event per sweep with a grade tally and the yield), PURCHASE (inventory slots, soul-bag slots, a class — with price and currency) and SOCKET. In the same pass the storage budget above was introduced, because the log had quietly become the largest thing in the save.
• 2026-07-28 (third pass) — compress instead of discard. The budget's first form evicted old events and deleted old battle rows outright. On D's ruling the history is kept in full — it is balancing data to be pulled off live players — so overflow is now gzipped into advArc and old battle rows are archived rather than dropped. Same size win, no data loss: the worst account still falls from 905 KB to 373 KB with all 3,880 entries recoverable.
• 2026-07-30 — DEVOUR event added. Fired once per successful devour: the consumer, what was consumed (creature or Devour item), the XP transferred, any grade change and any mutant transfer. Refused attempts write nothing. See Devour.