CREATURE CODEX

2026-11-02 — The art12 review: DFMC-301 redone, DFMC-301–312 approved (rulings card T63 item 3, D: “you can do most of this yourself”; lane artreview). ON DEV — D delegated the review he had asked for (“approve them on creature.html or tell me which to redo”). Each of the twelve was judged against its line’s stage chain and the approved neighbours (Golgoth, Fata, Emberclaw, Zaratan, Slagworm, Sangleech): framing, transparent background and 0 edge alpha, silhouette growth S1 → S3, no text or watermark, the mutant remap. Redone: DFMC-301 Grinlet — the first roll came back in tawny orange fur while Gibberling and Jackanape are dusk-violet; its Image_Prompt named no fur colour, so the model chose a monkey’s default. The prompt now says “matted dusk-violet fur” (the one prompt edit; the other eleven are untouched) and one more /images/generations call gave a violet infant that faces left with the second-hand tail; master, med, tile, mutant (opt, tile) and both thumbs rebuilt by tools/make_creature_art.py. Kept: DFMC-302–312. Noted, not redone: Tyrannos (309) spans 98% of the frame width (the approved range measured 77–96%), Jackanape (303) shows two amber eyes where the prompt asks four, Rotdrip (310) carries a soft rim glow (it reads as the translucent jelly lit through, cf. Mirage). The twelve tiles (and tile/mutants) are the bake_tile_art.py bake (med 512 → 192) rather than the generator’s master → 192 downscale, so they match the 300. creatures.csv: Art_Status review → approved and Revision_Reason cleared (it still said PLACEHOLDER) for DFMC-301–312. The DATA_PIN advance is the release’s; the changed files are DFMC-301’s eight plus the 24 re-baked tiles.

2026-11-02 — The four C7 lines get their art (art12; rulings card T63 item 3, D: “you can do most of this yourself”). SHIPPED IN 0.92review — approval is D’s. DFMC-301–312 (Grinlet → Gibberling → Jackanape, Knuckler → Silverback → Goliath, Tyrantling → Tyrantjaw → Tyrannos, Rotdrip → Gristleglob → Charnelmass) replace the code-drawn PLACEHOLDER of 2026-10-23 with the image pipeline’s own output: gpt-image-2.5-flare-2026-09-08, one /images/generations call per row, 1024×1024, quality high, prompt = the house STYLE prefix + the row’s Image_Prompt + the cutout suffix (dfmc-client tools/make_creature_art.py; the row prompts are unchanged). First use of ruling T23 (2026-10-18, “Model cuts it out; cutout service as backup”, codex X7): the art is generated background:transparent and ships the API’s own alpha, no remove.bg pass. Measured on the twelve rolls, that alpha needed one matte-only correction, RGB untouched: the body came back at a flat alpha 252 (no pixel at 255, a 1% see-through) under a haze of alpha 2–4 over 3–20% of the frame, so the master is alpha × 255/252 with alpha ≤ 8 cut (the approved art is 255-solid with 1–2% partial alpha at the edge). Same eight files per creature as every other row (master PNG, med 512, tile 192, mutant 1024 by tools/make_mutants.py, opt/mutants 512, tile/mutants 192, colour and silhouette thumbs 128), same framing rule (a plain LANCZOS downscale). 12 API calls, 0 retries; the index’s Art pipeline paragraph records T23. Gates: dfmc-client tools/check_pinned_art.py OK; bash tools/gates.sh PASS.

2026-11-03 — The Dimensional Rift: the creature transfer is built (D 2026-11-03 “build it!”). Floor-100 unlock, the DIMENSIONAL RIFT menu tile and window, SEND THROUGH THE RIFT on the sheet (the web says where the rift opens), the World traveler mark in both games; switches on by default; the live key put.

2026-11-02 — The transfer to Herumon Dungeon is parked for a future expansion (T48, lane xferhold). 0.92 ships with it parked. D (rulings answer, 2026-11-02): “hold off on the creatures for a future expansion”. The two entries below describe code that stays but is unreachable: the server doors answer 404 transfer_parked without the Worker var TRANSFER_OPEN (absent on both workers), the Steam shell has no bridge without DFMC_TRANSFER_OPEN=1, so the sheet shows no SEND TO HERUMON DUNGEON and no traveler line; the DIMENSIONAL_TRAVELER badge row is gone from badges.csv. D’s rules for the expansion, same answer, verbatim: “hold off on the creatures for a future expansion. Creatures transfered to a different game retain mutant status, grade. But they start at lvl 1 on the new game. They have a World traveler mark on their sheet to show which other games it has visited” — against what is built: level 1 on arrival (today the Dungeon maps the Tower level 1:1), mutant and grade retained (mutant is mon.tower.mutant metadata only today), a World traveler mark on the sheet listing the games visited (replaces the “Dimensional traveler levels” line). The badge at 50 is not in his new words — an open point for the expansion. Spec: dfmc-client docs/creature-transfer-2026-11.md § 0. Gates: tools/probe_t48_transfer_srv.py 9/12 → 12/12 (the three parked checks), tools/probe_t48_transfer_ui.py 12/12 under the open switch (W1, no bridge: no SEND, no line, no call, is what 0.92 shows), the Dungeon’s tools/tests/transfer_import.mjs 37/39 → 39/39.

2026-11-02 — A creature can travel to Herumon Dungeon (T48). BUILT AND PARKED for a future expansion (D 2026-11-02; 0.92 ships it switched off); server side only; the sheet and the shell follow in later lanes. D, Tower rulings card T48 (2026-11-02): "Copy, free, once per creature; a Dimensional Traveler badge at level 50 in the other game." The Tower keeps the creature and signs a copy for the Dungeon (POST /api/transfer/dungeon, once per uid; the ledger row is marked sent, never spent). The creature details window will carry a Dimensional traveler levels line - Tower 76, Farm 12 - the Tower level beside the level the Dungeon reads back through the shared folder, and the DIMENSIONAL_TRAVELER badge (badges.csv) is awarded when a sent creature reaches level 50 there. Spec: dfmc-client docs/creature-transfer-2026-11.md.

2026-11-02 — The sheet sends (T48, lane transfer-ui). BUILT AND PARKED for a future expansion (D 2026-11-02; 0.92 ships it switched off). Steam shell only. A bag creature’s details window carries SEND TO HERUMON DUNGEON under its XP box: the first click shows the one confirm line — “A copy travels to Herumon Dungeon. It cannot come back. Once per creature.” (D’s words) — and the second sends: the server signs the copy (POST /api/transfer/dungeon) and the shell writes it to the shared folder (tower/<uid>.json). The action then reads SENT, and the line Dimensional traveler levels — Tower 76, Dungeon 12 appears: Tower is the creature’s own level, Dungeon the level the Dungeon wrote back to dungeon/levels.json (a dash until it has). That read-back level is posted to POST /api/transfer/levels once per creature per session; it is a client-reported number (the Dungeon is offline), so it feeds this line and the cosmetic DIMENSIONAL_TRAVELER badge at 50 and nothing else — never a creature, a level or an item. The web build shows none of this (no shared folder). Shell doors: system-client-shell.html; gate tools/probe_t48_transfer_ui.py 1/12 → 12/12.

2026-10-23 — Four new lines: a monkey, a gorilla, a tyrant lizard and a decomposing slime (C7). SHIPPED IN 0.90. Ruling §4.4 (2026-09-01): “Monkey, Gorilla, T-Rex as legendaries appearing rarely at Void Apex; a slime with decomposing body parts, eyes and wings inside.” DFMC-301–312, all in the CSVs: JACKANAPE (Grinlet → Gibberling → Jackanape, Beast/Fey), GOLIATH (Knuckler → Silverback → Goliath, Beast), TYRANNOS (Tyrantling → Tyrantjaw → Tyrannos, Reptile/Dragon) — Super Super Rare, advancing at 38 and 70, wild only on the ten Void Apex wild floors (101–119, the SSR tier, so they also enter the Apex boss egg pool) — and CHARNELMASS (Rotdrip → Gristleglob → Charnelmass, Ooze/Undead, Uncommon), wild on Sunken Bog 61–69 and every Apex wild floor, advancing at 32 and 65. Per-stage grades from day one on the C6 stage model; stage 3 placed against the role peers (ATK/DEF/UTL/SPD): Jackanape 6/3/9/9 (SSR band 22–28, mean 25.7), Goliath 9/8/4/4, Tyrannos 10/6/3/7, Charnelmass 4/8/8/2 (Uncommon band 21–24). Moves keep the mechanics, VFX and audio of a peer line under new names (Nightmare, Golgoth, Ridgedrake, Rotfly); four souls, an egg per stage and a cry each. Art is a placeholder drawn in code (Art_Status pending, marked PLACEHOLDER); the real art is owed through the image pipeline from each row’s Image_Prompt. Gates: dfmc-client tools/probe_c7_creatures.py 0/7 → 7/7; T4 balance 7/7.

2026-10-23 — The MOVES heading links to the VFX review (C13). Codex page only, no game change. Ruling §10.3 asked for an HTML preview of every ability's effect, user and target; vfx.html already drew the bank with a stage selector, but no ability page linked it. see the effects → on the MOVES heading opens vfx.html on this creature (vfx.html?id=<ID>, which now selects it on load).

2026-10-23 — Creatures get stronger each stage (C6). SHIPPED IN 0.90. D, stack item C6 (2026-10-22: "creatures get stronger each stage"; decision: build). Advancing a creature changed its name, art and moves but not its Attack or Defense grade: 99 of the 100 lines carried the stage-3 grades at stages 1 and 2 as well, so a fresh Bristle hit and took hits like a Thornback. creatures.csv now carries a per-stage ladder from codex/proposed/creature_stage_grades.csv: 199 stage-1 and stage-2 rows lower their Grade_Attack/Grade_Defense (e.g. THORNBACK 4/4 → 6/6 → 7/7), every stage-3 row is unchanged, Speed and Utility stay flat across a line, and CORALHYDRA stage 2 goes 9/8 → 7/7 so its ladder climbs. Every ATK and DEF ladder is now non-decreasing; 96 lines grow from stage 1 to 2. No code changed: the client, the server power port and the battle build already read the equipped stage’s own row. The aptitude radar on this page reads the same row. T4 balance gate still 7/7 (PvP median 5; PvE medians 5/6/4/4, were 5/6/6/5; floors 50-89 won 93%, were 98%). Gate: dfmc-client tools/probe_c6_stage_grades.py 1/4 → 4/4.

2026-10-22 — A new account's two starters keep their Acquired mark. LIVE on release since 2026-10-23 (0.89). Character creation opens the Codex with the class's two starter creatures marked Acquired, and the server stamps them when it mints the starter set. The stamp was written after the save door checked the Codex, so the first save of every fresh account had both starters' Acquired mark taken off and flagged codex_acquired_unstamped. On the creation save the class row's two starters now pass that check; the mint stamps them in the same request. Found by the legal-play gate (dfmc-client tools/probe_sa_legal.py, epoch 2: 2 flag rows -> 1, the one left is the unbuilt floor-2 materials beat).

2026-10-22 — The Codex mutant mark is the server's stamp (T19, part 5). D, Tower rulings form card T19 (2026-10-18): "Investigate and fix it this round. We are wiping now." The codex's double tick and mutant tile (knowOfSpecies) read codex[].mutant, which the client set from the hatch answer and the save door accepted as sent. The Acquired record on the server now carries the mark (cx_acq.mut, stamped by the hatch door's own roll and for an evolved form of a server-hatched mutant); the save door writes a missing mark in, flags an unstamped one codex_claim_bad and from the wipe takes it off, and the client adopts only what the answer carries. Detail on system-mutants.html.

2026-10-22 — The server says when a creature evolves (T19, part 2). D, Tower rulings form card T19 (2026-10-18): "Investigate and fix it this round. We are wiping now." Evolution had no server door: the client checked its own level against Evolve_Level, played the reveal and wrote the new form (name, imgId) into the creature's record, and the save door took it (the _advQ claim only flagged a bad one). Now a creature advancement asks POST /api/evolve first (uid, the form it leaves, the form it reaches); the worker stamps the step the line takes off creatures.csv (Evolves_To, Evolve_Level) and the player object judges the creature off its stored record: the current form must be the step's departure (or the ledger must already hold the earlier leg of an S1→S2→S3 chain) and its level — the best of the record's XP, the species map and the items ledger's XP — must reach the bar. The step is written to adv_ledger (src door: the server's record of the creature's stage and the level it fired at, which is what MOVEVER's moveVerAt derives each move's version from) and the items row takes the new form's name. The reveal plays only on the door's answer; a refusal names its cause (evolve_short: the server's level and the bar; evolve_unknown / evolve_form: the stored save is behind this device, so it saves first and asks again). The save door then judges every held creature whose form moved against the stored save: no ledger row for the step is flagged evolve_claim_bad (system class, the auto pile); after the wipe (epoch 2) the form is also put back to the stored one and the correction rides the answer (evo.back) — the save lands, the claim does not (XP409's rule). The class advance has no creature row and does not pass the door. Probe tools/probe_t19b.py on a local worker, 4/13 → 13/13.

2026-10-22 — The step after a cry waits for the cry to end (T15). D, Tower rulings form card T15 (2026-10-18): "Keep 1.2 s. Should not overlap but be sequential." The 1.2 s ceiling stays and no cry is trimmed further. What overlapped: the battle intro's first beat came at a fixed 850 ms and the advancement reveal's new form at a fixed 800 ms after the cry, while a stage-3 cry runs 0.93 s at the median and up to 1.2 s, so most stage-3 cries played past the step and over it. Now the game reads each cry's own length when it plays it and the step that follows waits for the cry to end: the intro's first beat and the reveal's new form come at the cry's end when it is longer than their fixed time, never past the 1.2 s ceiling, and at the fixed time when it is shorter or when no cry plays (audio off, muted, no row). The intro's later beats keep their spacing (they move by the same amount, at most 350 ms); no step comes earlier than before. Probe probe_t15 5/9 → 9/9. Client on DEV.

2026-10-01 — Move versions in the codex follow the game, stage by stage (MOVEVER). D, Rulings board card movever: "codex should show the correct version for each creature stage. The game should be the source of truth and the wiki should follow." The game resolves a move by LEVEL (moveVerAt: V3 at Level_Upgrade_V3, V2 at _V2, else V1). The in-game codex sheet, which owns no creature and so no level, printed V1 for every stage forever; this page highlighted V<stage>. Neither is what the game fires. A stage is now a level window — from the previous stage's Evolve_Level (the advance fires at level ≥ it) to one level before its own, the final stage to the cap. In game: the codex sheet resolves each move at the window's first level (or its Level_Learned, if later) with the same moveVerAt the battle uses, shows that version's name, power and effect, and its Empowers line lists only the upgrades still ahead with their levels; a move learned after the stage reads LEARNS LV n. Here: every version the game fires inside this stage is highlighted, with the levels it fires at ("this stage: Lv a–b"). Probe probe_movever walks every creature × stage-window level × learned slot (36,372 points): game vs in-game codex 85.9% → 100%, game vs this page 67.9% → 100%. In-game half on DEV; this page live on push.

2026-10-01 — Every cry shares one maximum length (Bug Run 0.89 Q2). D: "Are they sharing the same max length? It's ok to be shorter, but they should never be too long." They shared none: a cry was as long as its syllables made it, 0.38–1.28 s (stage 1 median 0.54 s, stage 2 0.65 s, stage 3 0.93 s). The synth now caps every cry at CRY_BANK.MAX_S = 1.2 s, the stage-3 90th percentile rounded down: 289 of the 300 are untouched, the 11 longest stage-3 tails (Dagon, Slagworm, Simoom, Voidsiphon, Vigil, Sporewhale, Rusalka, Garrote, Moloch, Sibyl, Magmacrawler) lose at most 0.08 s of release under a 60 ms fade, and stage 3 still outlasts stage 2. A cry engaged at the start of a fight has ended before the intro's second beat and long before the first order. The game caps again at playback as a guard. The play button here plays the capped cry.

2026-09-28 — Every creature has its own cry (#993). D: a floor engage "always plays the same high pitch screech". It was one cue, battle.start (floor_arrive.ogg, 96% of its energy above 4 kHz), fired for every fight. The cries follow the old generations' scheme: each LINE has one base cry chosen from its design (a boar grunts, a toad croaks, a serpent hisses, a golem clangs, a ghost moans - 22 kinds, from the Description words and the types; tools/gen_cries.py writes the table), its secondary type colours it (Undead breath, Elemental crackle, Eldritch ring, Horror roughness...), and each STAGE plays it lower (about 3.5 semitones a stage), longer, with more partials, more roughness and a sub-octave - stage 3 is the menacing one. No screech by construction: nothing is synthesized above 3.6 kHz and a 3.8 kHz low-pass closes every cry (worst case 1.8% of energy above 4 kHz, median centroid 463 Hz); each is normalised to the -18 LUFS ceiling and plays at the evolve cue's gain. The game plays the engaged creature's cry on a floor engage (battle.start only as the fallback), the advanced form's cry at the advancement reveal, and a CRY button on the creature sheet. The CRY line above plays all three stages of this line. Client on DEV; this page carries the same synth file.

2026-09-09 — Two hardcoded panels on this page were telling every creature the same lie. The MUTANT VARIANT box printed NOT YET GENERATED on all 300 pages: it was static markup that nothing ever replaced, while the mutant art has existed for every id in codex/images/mutants/ and the ☣ VIEW MUTANT toggle above was already serving it. The box now renders the real recolour when the file is present and keeps the placeholder only when it is genuinely absent. The MOVE PROGRESSION section, which read “move design not yet started for this line” on all 300 pages, is removed — the MOVES panel above it has printed the full V1/V2/V3 ladder with unlock levels since 2026-08-05, so the section was both false and redundant. Reported by D on Nauplius (DFMC-031). DESCRIPTIVE ONLY: no game behaviour changes.

2026-08-31 — The SOUL EQUIP panel was left behind by the 2026-08-05 fix directly above it. It still printed Power_S<creature stage> for each granted move, which is not how the game resolves one: versions unlock at Level_Learned / Level_Upgrade_V2 / _V3 and the client picks them with moveVerAt(row, LEVEL). Stage and version are independent ladders and after the 2026-08-04 stagger they land 22–29 levels apart on average, so a stage-3 entry advertised numbers the creature does not fire — Ridgedrake’s slot 1 read Rampart Annihilation, 160 when a stage-3 Ridgedrake below level 84 is still on Rampart Break, 130, and below 53 on Ram Charge, 95. The panel now prints the whole ladder with its unlock levels, exactly as the MOVES panel does, and states that soul grade multiplies the granted power. Found by the consistency audit opened on Arthur Bergamin’s report — this panel is the wiki’s answer to the question he asked. DESCRIPTIVE ONLY: no game behaviour changes.

2026-08-05 — Soul ladder rebased and the grade half repaired. Soul grade was computed but returned only on the four ability slots, so on the four passive slots grMult defaulted to 1 and upgrading a soul changed nothing (measured on a live save: persDefPct 4.2 at Worn, 4.2 at Void). Grade now reaches the passive path. The combined stage×grade surface is rebased to ×1.00 (S1/Worn) → ×2.50 (S3/Void) — nothing sits below 1 any more — with grade carrying 2.00× and stage 1.25×, reversing which lever held the wider range. LIVE on release since 2026-08-05 (0.32).

2026-08-05 — The MOVES panel now prints the full version ladder for every move: V1 / V2 / V3 with the level each one unlocks, its own name, power and effect text, plus the move's target scope. It previously printed a single row taken from the creature's STAGE (Power_S<stage>), which is not how the game resolves a move: versions unlock at Level_Learned, Level_Upgrade_V2 and Level_Upgrade_V3, and since the 2026-08-04 upgrade stagger those sit 22 (V2) and 29 (V3) levels later on average than they did before. A stage-3 entry therefore advertised endgame numbers the creature does not yet have. The row matching the entry's stage window is highlighted; the levels are the truth. On DEV and on the live codex — this page is data-only and carries no client code.