XP & LEVELING

Two-phase leveling built for an autoplay climb: a gentle journey to level 66 that opens the whole tower fast, then a steep geometric endgame that carries hundreds of hours.

Formulas

Computed from codex/XPCurve.csv and the on-level battle of tools/codex_tables.py (xp-formulas).

The two phases are continuous at level 67. Per-kill XP is not flat in the enemy's level — it is the authored table — but a whole battle tracks 10 × L closely enough that the battle counts follow the requirement curve almost exactly.

XP curve

Log scale, plotted from codex/XPCurve.csv. Requirement for the next level and cumulative XP to reach the level. The knee at 67 is where 10 × L^1.75 hands off to a geometric phase whose per-level growth ramps smoothly from +2.7% (the polynomial's own rate at 66) to +16% at level 99 — no step anywhere; levels 90–100 are 60% of the total (C1, 2026-10-23, ramp end +12% → +16% by T53, 2026-11-02; before C1 it was a flat +17.5% from 67 and 78.5%).

Battles curve

The same curve divided by what a battle actually pays — battles spent at each level and cumulative battles to reach it, at the level-appropriate floor's own rarity mix over the −3…+3 spawn spread. Log scale. Level 100 has no bar of its own: it is the finish line, about 3,730 battles out (see Milestones).

Milestones

*At ~109 battles/hour on autoplay — the economy simulator’s figure (dfmc-client tools/sim_econ.mjs BATTLES_PER_HOUR), about 33 s per battle. Generated by tools/codex_tables.py.

Level-by-level curve

Read live from codex/XPCurve.csv — the same 100 rows the client's xpLevel()/xpKill() and the server's TABLES.xp_cum/TABLES.xp_kill read. Nothing here is restated by hand. XP to next and cumulative are the requirement curve and apply identically to creatures, classes and the player level; the five per-kill columns are indexed by the enemy’s level, not the recipient's. XP/battle and battles are derived against that floor's own rarity mix in codex/encounter_weights.csv over 3 kills — a boss floor has no wild spawns, so it inherits the last wild floor's mix.

What actually sets the number. Per-kill XP is indexed by the enemy’s level, so XP per battle is set by the floor you farm and never by your own level — out-levelling a floor earns you nothing extra, it only costs. Three things are measured rather than assumed:

• 3.00 kills per battle, exactly — on 9 of 9 alpha accounts that have fought one (_ledK / _ledB from the server's own ledger). The assumption behind every battle count on this page.
• A wild slot is not stamped at the floor's level. buildSpawn() rolls an offset of −3…+3 at 3/7/12/56/12/7/3%, clamped 1–100, and the whole spread sits inside the grace band, so on-level really is penalty-free on every roll. Averaging over it rather than reading the floor's own row moves the number by under 0.35% above level 4 — one battle in 20,346 across the climb.
• The penalty is visible in the ledger. Account XP is raw, class XP is penalised, so _ledC / _ledX is the retention the account actually got. On the reference account — class 31 on floor 23, a gap of +8 — the formula predicts 0.796 and the ledger reads 0.807.

The multiplier applies to class and creature levels only. Account (player) XP takes no penalty at all — it is the raw sum — so the account level tracks the on-level column exactly, provided the character is farming the floor that matches it. Full curve in Level Penalty.

Source: codex/XPCurve.csv · mix from codex/encounter_weights.csv · spawn spread from app.js buildSpawn(). Level 100 carries XP_To_Next = 0: creatures and classes are maxed there, and the player level continues at a flat XP_Account_Flat (354,245). Battle counts assume the enemy is level-appropriate, so the level-gap penalty is zero — see Level Penalty.

Player level (uncapped)

Separate from creature levels and class levels. The player (account) level is an account-wide marker of total time in the tower. It grants no stats and no unlocks, but since 2026-08-25 it has one job: it gates character gear — tier N needs account level ≥ (N−1)×10, T10 = 90 (D ruling: “Account level gates gear”; On release.; mechanics on Equipment). Tags are gated by the creature's own level, never by this one. It exists so that the endgame keeps counting, and so that a future system has a natural place to hook into. (This paragraph said “no gear requirements” until 2026-08-25; that was true only because nothing enforced them.)

Pacing, past 100: at level-100 enemies (kill XP 118–827 by rarity, XPCurve.csv row 100 — roughly 1,000 XP per battle) each player level is ~355 battles ≈ 3¼ h of autoplay at the measured 109 battles/h — a level most evenings for a steady player, so the counter visibly ticks over instead of freezing. Reaching player level 100 itself takes 2,936,130 XP (the curve’s cumulative at 100, the same number playerLv() reads); every level after is the flat 354,245, climbing linearly forever instead of exploding. Continuing the ramp past 100 was rejected as too slow to feel alive.

Who receives XP

• End-of-battle XP goes to every creature in the party and the avatar, not only the participants.
• Dying in battle does not forfeit XP — a fainted creature or downed avatar still receives its full share.
• Each recipient's XP is then scaled by the level gap to the defeated enemy. See Level Penalty for the full curve.

XP is addressed to a CREATURE, never to a party slot — LIVE on release since 2026-08-05 (0.32)

The party occupies gear slots 8 and 9, and the battle units a1/a2 are derived from whatever record sits in them. The credit used to be written back the same way — straight into equipOv[8|9] at commit time. The Equipment window can be opened during a battle, so that record is not guaranteed to still be the creature that fought.

Reported by a player on 0.31 and reproduced on his own save: a level 28 Scorchscale fought a full battle, was swapped out mid-fight, and received nothing; a level 1 Vaettir swapped into the slot received 282 — the gain computed from the fighter's level and applied to the newcomer's base. That is also a power-levelling exploit: swap a fresh creature in before the killing blow and it earns at a veteran's rate.

• Every battle unit carries the uid of the record it was derived from (monFromSlot / mkMon).
• partyRecFor(un, gi, st) resolves the fighter's record wherever it now sits: still in its slot, moved to the other slot, or back in the bag. A fighter found in the bag is paid there.
• If the fighter cannot be found, nobody is credited — never the occupant of the slot. A slot that is simply empty still falls back to the pre-uid crXp species map, so legacy saves keep working.
• Records written before uids existed compare on name instead. This is the same guard shape commitSoulEvolution has carried since 2026-07-27.

The advance check had the same defect, with a worse outcome. advancingAlly also read the slot, so after a mid-battle swap it took the newcomer's level and stamped the newcomer's uid — which meant commitPartyEvolution's own guard passed and wrote the fighter's next form into the newcomer's record. That is the exact cross-line corruption the guard exists to prevent, arriving through a different door. It now resolves through partyRecFor as well.

Class XP — who computes it

The server, since 2026-08-01. Class XP is the avatar's share of the same battle, and it is derived from the same authored tables the account total comes from — the client is not asked and is not believed.

Two consequences fall straight out of the definitions. Class XP can never exceed account XP, because the penalty is never negative — an account where it does has a starved account total, not a rich class total. And at a level gap inside the grace window the penalty is zero, so the two totals are identical; that is the sharpest available check that both are being computed from the same table.

What this replaces. Until this landed the ledger held account XP, Ichor, kills and battles — and nothing at all for class XP. The save door capped it only on a newborn account, then merged it grow-only forever after, so on any established account a crafted save could set class XP to any number and keep it permanently. Class advancement was the last progression system still authored entirely by the client.

Grandfathering. The class ledger starts counting from the day it shipped while every live account's class XP is historical, so the ceiling is a delta: each accepted save is stamped with the server's class total at that moment, and the next save may claim what was credited since, plus the standard grace. An account with no stamp yet keeps what it holds. This is the same shape as the kill and battle counters, and for the same reason — a flat total would have confiscated real progress on the first save.

Who credits a battle's XP — nobody but the server

LIVE on release since 2026-08-04 (0.31). Owner ruling, standing: no client-credited battle rewards. Account XP, class XP and Ichor are not moved when a battle ends. /api/battle answers with the figures the server derived from its own kill list, and those are the only numbers that ever reach the account or the screen.

What this replaced, stated precisely, because the end state was already correct. Since 2026-08-03 the client credited its own arithmetic and then reconciled to the server's number as a delta when the response landed — so the stored total was already the server's. What was wrong was the transient: for the 67–256 ms until the response arrived, the player's totals held a figure the server had never agreed to, and an uncredited battle (rate cap, spawn budget) had to be adjusted back down to zero afterwards. The local credit is now zero, which makes that same delta reconciliation an absolute apply with no second code path.

• Timing is not the obstacle and was measured, not assumed. The victory bar stages at 80 / 1000 / 1070 ms while a live round trip is 67–256 ms, so the server's figure lands an order of magnitude inside the fill animation. The bar simply grows to it.
• The victory class row is rebuilt from the server's number too. Account XP is rendered nowhere on the victory screen, so the class row is the one battle figure a player actually reads; leaving it on the client's estimate would have kept showing a number the server never agreed to. The row's XP text, both percentages and the level-up marker are recomputed from the same level function the row was built with, so bar and label can never disagree.
• Creature XP is untouched by this. The server does not compute per-creature XP, so crXp is still client-side. It is a separate question from the account ledger.
• An uncredited or unanswered battle now credits nothing at all, which is the ruling working: the server credited nothing, so the player earns nothing. A battle cannot start without connectivity in the first place — the battle-entry gate awaits a save flush and refuses the fight if it does not land.

Why it matters beyond correctness. The two authorities disagreeing by design is what made xp_over_ledger fire on every live account — hundreds of times each, on four of four accounts measured. A guard that fires on every honest player describes the system, not the players, and a real offender would have been invisible inside it. With one authority the flag becomes a signal again.

Advancement is asked for, not given

LIVE on release since 2026-08-04 (0.31). A creature, a socketed soul or the class still becomes eligible to advance the same way — by passing its line's advance level with a further stage to reach. What changed is who starts it. A victory no longer interrupts itself to play the scene. The win resolves, the rewards land, and the floor returns.

The advancement waits on the record that earned it. An upward arrow sits on that record's icon — the teammate's portrait, the equipment slot holding the soul, or the creature's tile in the soul bag (ON DEV since 2026-09-02, LIVE on release since 2026-09-02 (0.66).) — and clicking it plays the advancement scene. A creature in the bag can cross its advancement level through devour, and until 2026-09-02 nothing looked at it there: the arrow only ever reached equipped creatures, so a bag creature had to be equipped to advance.

• The arrow and the scene are one call. The marker is computed from the same function the scene uses, so an arrow can never appear on a slot the scene will not go to.
• One at a time, in order — party creature, then socketed soul, then class. That was always the rule; it is simply now visible. A second eligible creature is marked once the first has been played.
• Nothing expires. Eligibility is read from the creature's level, not from an edge, so an advancement left unclaimed stays claimable across battles, floors and reloads.

The arrow — where it sits, and when it goes

The arrow is dead centre on the image in all three places it can appear: the equipped soul's tile, the party creature's card, and the class portrait. One shape, one size, one placement, so it means the same thing everywhere.

• It goes on the click. Every arrow is derived from the records, and the records are not written until commitEvolution() runs at the end of the ~3s scene — so the arrow used to sit there, live and clickable, for the whole animation. advFired holds the advancements already set in motion so the derivation can answer honestly while the screen stops offering it.
• The suppression key carries the creature and the target form (uid + toId), never the slot. A slot can be swapped while the scene plays — that is the cross-line corruption the commit guard exists for — and a slot-keyed suppression would hide the newcomer's arrow instead.
• Every commit path clears it, deliberately. A commit refused by the same-creature guard writes nothing, so the derivation offers the advancement again and the arrow returns — correct, because that creature did not advance. Suppression outliving a failure would be a silent loss.
• The class arrow lives on the portrait, not beside the class name in the header row, which is where it used to be and where players kept finding it. Its click stops propagation, so the portrait still opens the soul crystals when the arrow is not hit.

The stale battle unit (report #41, measured 2026-08-07). advancingAlly() reads the creature's current stage off units[id].src — the battle unit — and commitEvolution() only ever rewrote equipOv. Measured against a real save: the slot became a Lich and units.a1.src stayed on DFMC-265, so the arrow was re-derived forever and every click replayed Reliquary → Lich on a creature that was already a Lich — word for word what the player reported. refreshPartyFromCsv() could not rescue it either: it rebuilds the party only while the phase is 'floor', and an advancement runs in phase 'evolution', so it fell through to a bare forceUpdate() and the stale unit survived even a return to the floor. The commit now moves the battle unit with the record.

The equipment arrow was clipped, not missing. It sat at top:-9px inside an overflow:hidden 72 px soul tile — measured 17×17 with its top cut off. It is now centred on the image and no longer clipped.

Two sizes, because one constant cannot serve both. The party card and the class portrait have room and take 44 px. The soul tile is a 72 px chip already carrying a creature image, a gender glyph, a grade glyph and a full-width multiplier band, so it takes 30 px and sits at top:32% — centred on the image area rather than on the whole tile, clear of the band below and the glyph in the corner. That is a real constraint, not a preference: at 44 px the arrow covered the tile’s own multiplier, which read ×1.?9 on screen. It can grow once that multiplier moves into the details panel.

How that was missed, and what now catches it. The probe measured size and centring, reported a clean pass, and never asked what else was in the box — the collision was found by taking a screenshot and looking at it. Every sibling carrying text is now checked with document.elementFromPoint at its own centre: is the arrow what is actually painted there? Rect-versus-rect was tried first and is the wrong test, because the multiplier is a full-width band whose box spans the tile even though its digits sit centred — it reported a collision that was not on screen.

Client: advKey(), advFiredHas(), advClearFired(), advReady(), advancingClassLive(), commitEvolution() in play/app.js. Probe: tools/probe_advarrow2.py (12/12).

An advancement waits for the battle — and the server is told

The advancement arrows live in the equipment window, and the equipment window opens during a fight. Clicking one mid-battle used to drop the phase straight to the advancement scene and take the player out of a live battle — gear is frozen for the duration of a fight, and this was the one thing that could still change a fighter mid-round.

• It defers, it does not refuse. The click is acknowledged: the arrow goes at once exactly as it does out of battle, and the player is told ADVANCEMENT WILL PLAY AFTER THE BATTLE rather than being ignored.
• It plays when the run is back in a room — floor or boss den, the only unambiguous “after the battle”. One at a time: the advancement scene itself ends by returning to the room, which drains the next, so three queued advancements play as three scenes in order rather than racing.
• Nothing is trusted to survive the wait. The deferred advancement replays through the ordinary path, and the same-creature guard still refuses it if that slot no longer holds that creature.

The advancement claim

Every committed advancement appends a row to _advQ, which rides the next ordinary save and is then consumed and deleted. Same contract as the dismantle claim: the client claims, the server decides. The row names the creature (uid), the form it left, the form it reached and the level it held — and every one of those is re-derived server-side. They are sent so the server knows which record to look at, never so it can take their word for it. The claim is cleared once the save is accepted, keyed on uid+to rather than uid alone, because one creature can advance twice in a session.

The check is split, and the split is deliberate. creatures.csv lives behind a fetch and only the worker can read it; the previous save — the only thing that can say what that creature actually was and what level it held — lives in the player's object. So the worker answers “does this line take that step, and at what level?” and stamps the requirement; the object answers “is this that creature, and had it reached it?” The worker decides nothing about legality.

Four conditions must all hold, all of them against the server's own previous save:

• the line actually takes that step, per creatures.csv;
• we held that creature before, by uid, wherever a creature can be held — bag, party slot or soul socket;
• it was in the form it claims to have left;
• it had reached the required level, computed from the XP banked in the previous save. The claim's own lv is never read. That is the level check.

A fifth is a consequence rather than a rule: the creature must actually be the new form in the save now arriving, or nothing advanced and there is nothing to record. Legal advancements are written to adv_ledger, one row per creature per form reached — the UNIQUE key is the idempotence, so a replayed claim writes nothing. Nothing is clamped or refused. An illegal claim is flagged advance_claim_bad and not written; the save still lands. This is a record of what legitimately happened, and a save must never be lost to it.

The class needs no claim. clsAdv is already in the save and the server already derives the class level from the same cumulative curve, so class legality is checkable from the save itself without a queue.

Client: deferAdvance(), drainAdvDefer(), advQPush() in play/app.js. Server: _advReq in the worker, adv_ledger and levelOfXp() in the object. Probes: tools/probe_advdefer.py (10/10), tools/probe_advledger.mjs (15/15, real SQLite).

A creature does not state its tier

LIVE on release since 2026-08-04 (0.31). Rarity still exists and still governs everything it always did — spawn tables, encounter weights, art, the codex. What it no longer does is announce itself. Owner ruling: players work it out by meeting a creature more or less often.

Removed from every in-game surface: the badge on the creature card, the badge on the creature sheet, the badges in the hatch and codex lists, and the tier baked into a creature's subtitle. The abbreviation function still exists and is still correct — nothing renders it.

The tier colour stays (owner ruling). A card still reads at a glance without naming what it is. Item grades are a separate system and are untouched.

Aptitude is a shape, not a score — LIVE 0.31

Base attributes are drawn as the same three-axis radar the class pages use: ATK at the top, DEF lower right, SPD lower left, rings at 25/50/75/100%, values scaled out of ten. It replaced the numeric rows on the creature sheet and the bar charts on the class card and the class selector. HP is not charted — the class pages chart three axes and list HP nowhere, and the in-game chart follows that exactly. Utility went with the bars for the same reason.

The point is what a player reads off it. A grade of 9 reads as a quantity to be compared; a shape reads as an aptitude — what this creature is for. The geometry is shared with the codex so the two can never drift into two different triangles.

Move upgrades follow the stages — LIVE 0.31

A move exists in three versions, and a creature moves up through them by level. Until 0.31 every one of the hundred lines upgraded its entire four-move kit on a single level: all four to V2 at once, then all four to V3 at once. Learn levels were already staggered, so only the upgrade columns were flat — a column filled per line rather than per move. The result was a cliff: a creature crossed one level and gained its whole next kit.

The rule now:

• V1 is learned on the way to the second stage.
• V2 lands inside the second-stage window — between the S2 advance and the S3 advance.
• V3 lands only after the S3 advance, so a creature can never wield its final form's moves before it has reached that form.
• Everything is fully upgraded by level 90.
• Each line has its own shape, so no level between 2 and 90 passes without some creature gaining something — either a new move or an upgrade to one it has.

What found it. A player reported Hafgufa as overtuned. It was: Hafgufa is the second stage of the kraken line and advances at 69, but every move in that line upgraded to V3 at 54 — so for fifteen levels a mid-stage creature with the top attack grade held the full final kit, on the floors where it spawns. It was throwing Collapse of the Trench, a Kraken's move, at power 120. That move now cannot exist below level 80, and the line advances at 69, so a Hafgufa can never fire it.

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”). WIKI ONLY. The hand-written chart captions still carried the pre-T53 ramp (+12% at 99, 90–100 “half of the total”) and the pre-C1 finish line (20,346 battles); they now say +16%, 60% and ~3,730 battles, matching the generated tables. The past-100 pacing paragraph still quoted the pre-C1 numbers (18,464,128 XP to 100, ~640 battles a level); it is recomputed from XPCurve.csv (2,936,130 to 100; 354,245 a level ≈ 355 battles) and those two figures bind to the csv. “In every realm” (in the generated xp-player block, so the wording is fixed in tools/codex_tables.py gen_xp_player and the block regenerated) and the hardcore-death note left with the realms (2026-08-28). No game code or csv changed.
• 2026-11-02 — the ramp ends at +16%: D’s T53 ruling “Slower: end the ramp at +16% (90–100 is 60%, about 34 hours)” (dfmc-client lane xpcurve, rulings card T53, docs/balance-2026-10.md § 3). Codex data; reaches the game with the next DATA_PIN advance, and the server’s src/tables.json (xp_cum, class_max_xp) must be regenerated with tools/gen_tables.py in the same release. What changed: the C1 generator, now written down as dfmc-client tools/gen_xpcurve.py (it reproduces the 2026-10-23 rows at --end 12), run at --end 16: the per-level growth of XP_To_Next ramps linearly from the polynomial’s own 2.7% at 66 to 16% at 99 (was 12%), cumulative recomputed; rows 1–66 and every kill-XP column untouched. Level 100 = 2,936,130 XP (was 2,126,757); 90–100 = 59.7% of it (was 50.0%); XP_Account_Flat = 354,245 (was 184,439; the ramp’s next step, +16.4%). A fresh on-level climb to 100: 34.2 h (was 27.0), 15.9 h of it in 90–100 (was 9.8); clearing only the Wins_To_Clear battles ends floor 120 at class 88 (was 89). The formula rows, the level table and the milestone note are regenerated (tools/codex_tables.py --write) and the bound spans refreshed; this page now loads csv-bind.js (it carried bound spans with no binder). An existing XP total between the old and the new cumulative of its level reads one level lower; a class clamped at the old cap (2,126,757) reads 95 and earns again to the new one. Gate: dfmc-client tools/probe_t53_xpcurve.py 4/12 → 12/12.
• 2026-10-23 — the formulas and player-level tables and the milestone pace are generated (dfmc-client lane a8-s5-c17-tail, C17 part 4; WIKI ONLY): blocks xp-formulas, xp-player, xp-milestone-note in tools/codex_tables.py, from XPCurve.csv and the on-level battle. Changed: growth at 67 2.7% → 3.0% (XP_To_Next 67 / 66); the ±0.7% band → ±0.8%; floor 100 999.4 → 996.6 XP per battle; the retired L^0.75 / 23.4 × 1.16^(L−67) battles formula → the computed counts (1 / 24 / 24 / 166 at 1 / 66 / 67 / 99); the milestone time column and its footnote ~30 → ~109 battles/h (the economy simulator, tools/sim_econ.mjs), and the “~98 h at the 30/h below” aside is gone. Player-level numbers unchanged.
• 2026-10-23 — the penalty table is generated (dfmc-client C17 part 2, lane c17-gen; WIKI ONLY): every penalty, retention and battles-per-level figure is src/worker.js xpPenalty over src/tables.json xp_penalty, so a penalty edit can no longer leave this table behind (all 16 matched). tables marked <!-- gen:NAME --> are generated by tools/codex_tables.py from the CSVs with the engine’s own formulas (each generator cites the engine line it ports); its --check is a dfmc-client gate, so a CSV edit without --write fails the gates.
• 2026-10-23 — the account’s flat step past 100 is codex data, continuous with the C1 curve (dfmc-client lane pvp-spread, docs/balance-2026-10.md § 8.2). Codex data; reaches the game with the next DATA_PIN advance. What was wrong: every account level past 100 cost PLAYER_FLAT_XP = 639,723, hard-coded in play/app.js — the OLD level-90 step. On C1’s curve 99→100 costs 164,264, so 100→101 cost 3.9× the level before it; and playerCost(), the curve-missing fallback, still carried the retired 234 × L × 1.16^(L−67). The fix: XPCurve.csv gains the column XP_Account_Flat, filled on row 100 only: 184,439 (the 67–99 ramp continued one step, +12.28%). The client’s playerLv reads it; the constant, playerCost() and its formula are deleted. The server does not price account levels, so src/tables.json is unchanged. Gate tools/probe_acct_flat.py 2/7 → 7/7.
• 2026-10-23 — the 90–100 stall is gone: levels 67–99 re-authored in XPCurve.csv (dfmc-client lane c1-balance, BACKLOG C1 §5.2/5.4, D’s balance card). Codex data; reaches the game with the next DATA_PIN advance, and the server’s src/tables.json (xp_cum, class_max_xp) must be regenerated with tools/gen_tables.py in the same release. What was wrong: XP_To_Next followed 10 × L^1.75 (+2.7%/level at 66) and then jumped to a flat +17.5% per level from 67, while a battle’s XP grows ~1% per level — so a level cost 0.2 h at 66, 3.5 h at 90 and 25 h at 99, and 78.5% of the XP to 100 sat in levels 90–100 (the live accounts 17–19 levels under their floor at 97–99). The fix: rows 1–66 untouched; from 67 the per-level growth ramps linearly from the polynomial’s own 2.7% to 12% at 99, cumulative recomputed. Level 100 = 2,126,757 XP (was 18,464,128); 90–100 = 50.0% of it. A fresh on-level climb to 100: 27.0 h (was 172.9 h), 90–100 9.8 h (was 129.9 h); clearing only the Wins_To_Clear battles now ends floor 120 at class 89 (was 79). Kill XP columns unchanged. Existing XP totals map to the same or higher level; a class above the new cap reads 100 and the server clamps it there. Two client constants are left as they were and are listed for a follow-up: PLAYER_FLAT_XP = 639,723 (the OLD level-90 requirement; the new 99→100 step is 164,264) and the playerCost() fallback. Research and targets: docs/balance-2026-10.md in dfmc-client.
• 2026-10-23 — a class level-up is announced (dfmc-client lane ui-polish-2, D FTUE playthrough 2026-10-23: “class level went 1→5 silently”). Dev build now; release with the next ritual. When the server’s class XP lands — the victory credit or the save door’s correction — and the active class’s level on that XP is above the level before it, a short gold toast reads “▲ LEVEL UP · CLASS LV n” (one toast for a multi-level jump). The client adds no XP and guesses no level: a repeated answer, a clamp down, or an answer that also switches the active class shows nothing. Creature levels are not announced here — creature XP is not a server figure yet. Gate tools/probe_clslvup.py 4/5 → 5/5.
• 2026-10-22 — class XP is a server ledger per class; the save’s class fields are a view (server-authority run § 3 item 7, F169). LIVE on release since 2026-10-23 (0.89). The per-class ledger is append-only rows now, one per credited battle keyed by the event id, so a replayed event adds nothing and a class’s XP is the SUM of its rows, ceilinged at the level-100 figure. The battle credit lands on the class the server knows is worn (the stored row’s class, or the class named for the fight when the class door sold it), never the save’s word. The save door no longer merges classXp / clsXpBy with a grace or a clamp window: each class is set to the ledger’s view, a client figure above it is corrected and flagged (classxp_over_ledger), below it lifted, and the save is never refused. clsOwned is derived - the stored row’s class plus the class door’s wallet rows - not the stored list. A pre-ledger account keeps its stored figure until that class’s first credit folds it into the ledger; the wipe starts every class at 0. Gate tools/probe_sa_class.py 10/20 → 20/20.
• 2026-10-01 — every class has its own level (D, Rulings board card classlevel: “Every class is a different level. Only the account level stays shared.”). LIVE on release since 2026-10-23 (0.89). Since 2026-07-27 the build kept one classXp for every class, so switching class kept the number and every class shared one level, against what this design always said. Now classXp and clsAdv are the active class’s, and clsXpBy / clsAdvBy bank every other class. A newly bought class starts at level 1 and earns its own XP on the same curve (cap at level 100). Switching banks the class you leave and loads the class you take; its soul in the bag shows its own level. The server owns it: /api/battle credits class XP to the class the battle was fought as (if the account owns it), in a per-class ledger (ledger_cls), and the gap penalty uses that class’s level; the save door clamps each class’s XP to what that class was credited plus the usual grace, grow-only per class. Account XP and the account level are unchanged and shared. No migration: a save from before this has its classXp on its active class and every other class at level 1 until the wipe. Gates tools/probe_classlevel.py 1/9 → 9/9 and tools/probe_classlevel.mjs 6/19 → 19/19.
• 2026-09-30 — review fix F173 (client, lane P). On dev. The client had two player-level functions that disagreed past 100: the fallback (used when the XP curve has not loaded, and by the forge’s requirement colour) charged the level-100 curve cost for 100→101, while the HUD and the gear gate charge the flat step. The fallback now charges the flat step from 100 on, as this page says. No visible change today (no recipe asks for more than 90). Gate tools/probe_review_lanep.mjs.
• 2026-09-30 — review fix F085 (server). The class-XP level-gap penalty on /api/battle read the avatar’s class level from the ledger’s class_total alone, which only counts credits since 2026-08-01, so a grandfathered account was priced as class level 1 and the server’s class figure (which overwrites the client estimate) disagreed with the rule. The class level is now the higher of the ledger and the stored save’s classXp, capped at class_max_xp as the save door caps it — the same level the client estimate reads.
• 2026-09-30 — review drift fixes: F172. Codex only. The player-level pacing paragraph said level 100 takes ~21.6 M XP and that a level-100 kill pays 1,000 XP. Level 100 is reached at 18,464,128 (XPCurve.csv cumulative, what playerLv() uses); 21.6 M also counted the level-100 row’s own cost. Kill XP at level 100 is 118–827; ~1,000 is per battle. No rule changed.
• 2026-09-02 — a creature in the SOUL BAG advances. LIVE on release since 2026-09-02 (0.66). D fed a level-90 creature to a Void dragon and it did not advance until he equipped it. The detector scanned socketed souls and the two party slots only — there was no scanner for the bag, so a creature that crossed its advancement level while unequipped got no arrow and did not count on the floor marker. A third scanner now reads the bag, keyed by the creature's uid because a bag record has no slot; the bag tile draws the same arrow the party tile draws; the floor marker counts it; and the commit rewrites only name and form on the same uid, leaving XP, grade, mutant status and the lock alone. A stale arrow for a creature that was since dismantled, devoured or equipped rewrites nothing. Party creatures and socketed souls are unchanged. Gate: tools/probe_bagadv.py, 2/9 before the change, 14/14 after, driven through the real click and ritual on D's own save.
• 2026-09-02 — the READY TO ADVANCE floor marker now renders for everyone. LIVE on release since 2026-09-02 (0.66). Since 0.31 the marker's block sat inside the PvP queue icon's block in the markup, so it was computed for every player and drawn only while a match was being searched for. Found by the probe above when its floor-marker check failed on the unpatched client; live on 0.65. Moved out to be a sibling of the queue block. The queue icon is pinned present-when-queued and absent-when-not by the same probe.
• 2026-08-25 — the account level now gates character gear (D ruling “Account level gates gear”). On release. The “Player level (uncapped)” paragraph corrected: it used to promise no gear requirements. Rule and thresholds on Equipment. Same day, ops: every account and party creature wearing above its level was promoted to level 90 on D's order (record on Admin & backend).
• 2026-08-07 — a mid-battle advancement waits for the battle, and the server is told (LIVE on release since 2026-08-07 (0.39)). Clicking an arrow in the equipment window during a fight took the player out of a live battle; it now defers, acknowledges the click, and plays when the run is back in a room. Every committed advancement also queues a claim onto the next save: the worker resolves the line step out of creatures.csv and stamps the level it requires, and the player's object checks the creature, the form it left and the level it had banked in the previous save before writing adv_ledger. The claim's own level is never read. Nothing is clamped — an illegal claim is flagged and dropped, and the save still lands. New section above. D spec. Verified 10/10 in a browser and 15/15 against real SQLite.
• 2026-08-07 — the advancement arrow: dismissal, the stale battle unit, and placement (LIVE on release since 2026-08-07 (0.39)). Report #41: an equipped creature advanced, the record became a Lich, and the arrow stayed live and replayed the same scene on a creature that had already advanced. Cause: advancingAlly() reads the stage off the battle unit and the commit only wrote the record, while refreshPartyFromCsv() rebuilds only in phase 'floor' — so the stale unit survived even a return to the floor. The commit now moves both. The arrow also disappears on the click rather than at the end of the scene (advFired), is centred on the image and materially larger everywhere, and the class arrow moved from the name row onto the class portrait. The equipment arrow was not missing but clipped: top:-9px inside an overflow:hidden tile. Corrected the same day after a screenshot showed the enlarged arrow covering the soul tile’s own multiplier: two sizes now, and the probe gained an elementFromPoint occlusion check it had lacked. New section above. D report + #41. Verified 12/12.
• 2026-08-05 — battle XP is addressed by creature, not by party slot (LIVE on release since 2026-08-05 (0.32)). Swapping a party creature mid-battle in the Equipment window paid the newcomer at the fighter's rate and paid the fighter nothing; the advance check had the same slot-addressing and could write one creature's next form into another's record. Both now resolve the fighting unit's own uid, and credit nobody rather than the wrong creature.
• 2026-08-04 — aptitude radar and staggered move upgrades (LIVE in 0.31). Base attributes became the codex's three-axis radar everywhere in game; HP is not charted. Move upgrades were flat across every line's whole kit and now follow the stage windows, complete by 90, with each line on its own schedule. Found by a player reporting Hafgufa as overtuned — it was firing a Kraken's move fifteen levels before it could become one.
• 2026-08-04 — creatures no longer state their rarity (LIVE on release since 2026-08-04 (0.31)). The C / UC / R / SR / SSR badges are gone from the creature card, the creature sheet, the hatch and codex lists, and from creature subtitles. Rarity still drives spawn rates, art and the codex, and the tier colour stays — only the words are gone.
• 2026-08-04 — advancement is fired by the player (LIVE on release since 2026-08-04 (0.31)). A victory no longer plays the advancement scene on its own. An upward arrow marks the slot that earned it — the teammate or the socketed soul — and clicking it plays the scene. Eligibility is level-based, so an unclaimed advancement keeps until it is asked for.
• 2026-08-04 — “battles per level” was framed as normal play; it is a best case (live, on release). D called it and the live saves agree. The two battle columns assume the character stands on the floor matching its level, which is the one place the level-gap penalty is zero. Measured against all 11 closed-alpha accounts: class level runs +1 to +19 above the floor through the early and middle tower (median ~+7) and 17–19 below at floors 97–99; two of eleven are inside the zero-penalty band. Columns are relabelled on-level, and a gap → retention → battles-multiplier table now sits under them. Also measured from the server ledger rather than assumed: _ledK / _ledB is 3.00 kills per battle on 9 of 9 accounts that have fought, and _ledC / _ledX on the reference account (class 31, floor 23, gap +8) reads 0.807 against a predicted 0.796 — the penalty model is confirmed against live data, the framing around it was what was wrong. Account XP is unaffected: it is raw, so the account level still tracks the on-level column.
• 2026-08-04 — both curves are now charted (live, on release). The single battles-per-level canvas became two, drawn by one generic log-scale routine off the same loaded data: an XP curve (requirement for the next level against cumulative XP to reach it) and a battles curve (battles spent at each level against cumulative battles to reach it). Both carry a legend and the level-67 knee marker. The caption above them claimed per-kill XP is flat in the enemy's level, which is the same error the Formulas table carried — corrected: the flat thing is a whole battle, at ≈10 × L.
• 2026-08-04 — battles-to-level, averaged over the real spawn spread (live, on release). The level-by-level table gains battles to reach that level and time to reach it (at 30 battles/h), and the XP-per-battle column is no longer read off the floor's own row: it now averages the −3…+3 at 3/7/12/56/12/7/3% spawn-level spread that buildSpawn() actually rolls. The whole spread lies inside the level-gap grace, so on a level-appropriate floor the penalty is zero on every roll and account, class and creature XP are identical — which is what makes a single “battles at Lv” number well defined at all. Measured effect of the averaging: under 0.35% above level 4, one battle in 20,346 across the whole climb, and ~19% at level 1 where the 4-XP floor bites. The flat floor-row figure was therefore already the average, and is documented as such rather than quietly kept.
• 2026-08-04 — the level-by-level curve is on the page (live, on release). All 100 rows of codex/XPCurve.csv now render here — XP to next, cumulative, and the five per-kill columns — alongside derived XP-per-battle and battles-per-level against each floor's own encounter_weights.csv mix. The milestone table and the chart were switched off their analytic approximation onto the same data (the approximation survives only as a fetch-failure fallback). Two Formulas rows were WRONG and are corrected: per-kill XP is not 10 × C — it is an authored table on the C 1.0 / UC 1.5 / R 2.5 / SR 4.0 / SSR 7.0 ladder, and at level 100 a Common kill is 118 XP, not 1,000. What is ≈ 10 × L is a whole battle (3 kills at the floor's rarity mix): 999.4 at floor 100, within ±0.7% of the line from level 10 up. That identity is why every downstream figure on this page — ~20,300 battles to max, ~885 to level 67, 74.5% of the climb in levels 90–100 — verified against the real tables rather than needing a rewrite. Client and server were checked against the CSV on both branches: xp_cum and xp_kill in src/tables.json match all 100 rows exactly on main and dev, and class_max_xp equals the level-100 cumulative, 18,464,128.
• 2026-08-04 — no client-credited battle rewards (LIVE on release since 2026-08-04 (0.31)). Account XP, class XP and Ichor are no longer moved at battle end; the server's figures are the only ones that reach the account, and the victory class row is rebuilt from them when they land. The delta reconciliation shipped 2026-08-03 already left the stored total correct — what this removes is the window in which the player held a number the server never agreed to.
• 2026-08-01 — class XP moves server-side. It had no ledger and no ceiling; a save could claim any class level and keep it. The server now credits class XP itself per battle from the authored curve and the level-gap penalty, caps it at the level-100 cumulative, and clamps a claim to what it actually credited. Verified against a real worker: at zero level gap the class and account totals come out identical, a 1,000,000,000 claim clamps, a claim past the level-100 cumulative clamps to the cap, an established account's historical total is kept, and legitimate growth still lands untouched.