062026 13

The problem framed (Tree of Savior, but tighter):

• Owner likes ToS's open class progression (base archetype then class 1, class 2, class 3 — picking 3 of ~18 per tree) and its build diversity, but rejects ToS's ability model: each class APPENDING new skills produces the MMO "100 buttons on long cooldowns" soup. Wanted a tighter action-game version.
• Key reframe (Claude): the button-soup disease is ToS COUPLING class-count to skill-count. Founding law adopted: the button count is fixed by the archetype; picking a class (mostly) never grows it. Classes reshape a fixed kit instead of growing it.

Ability-model spectrum surveyed, then resolved by the owner:

• Options run through: slot-claim (each class fills a slot), modifier-lens (classes transform the whole kit), ability-evolution (classes upgrade one ability), pool-bias, and the "Anchor+Rider" hybrid.
• Owner's chosen model: classes contribute ROLE-bound modifiers, never ability-specific ones. A modifier targets a slot ROLE ("does X to the primary"), never a named ability ("does X to Cleave"). Because the base unit determines what fills the primary slot, the same class reads differently on different bases (Outlaw on Swordsman vs Outlaw on Scout) — this is the core variety engine.

Contention resolved (owner's cleaner solution, eliminates the hard case): two contribution types, NO replacement category.

• (1) MODIFY an existing role — a composable tweak. Tweaks STACK, and because the co-tree set is finite and KNOWN, they're hand-curated to compose (a curation problem, not a general algorithm). Bespoke override is the escape hatch for pairs that don't compose.
• (2) ADD a genuinely new ability — it gets its OWN new slot/key (DotA-style extra button). Capped tight (~+2 actives; most builds 5–7; solo active-aim has LESS room than DotA, so tighter than DotA's budget). PASSIVES are free (no key) and can pile up. Button-count becomes a build dial (high-APM vs streamlined build).

Emergent (floor) + bespoke (ceiling) — owner wants both:

• Emergent: modifiers bind to carrier-type + role-universals and reinterpret automatically per base; guarantees coverage; the game ships complete with ZERO bespoke entries.
• Bespoke: hand-authored [class x base] overrides are opt-in polish only, never the baseline (else the M*N authoring matrix buries the project).

Tag-locked pick pool (owner correction — simpler than graph traversal):

• Every one of the 3 picks must carry the BASE's tag. Base = e.g. Warrior (root Swordsman); pool = {all units tagged Warrior}. Multi-class units (Outlaw = Warrior+Rogue) are pickable because they ARE Warriors; the 2nd tag is flavor, not a passport. You can NEVER pick a unit lacking your base tag ("no rogue-mage after a warrior-rogue"). This is pure ToS (root defines the tree) and removes any reachability/ordering problem — just "pick 3 from ~18."

Roles = the system-wide ABI (owner set the vocabulary): primary, secondary, utility (= mobility), ultimate, passive (5 roles). Shield stays a UNIVERSAL system (from session 10), NOT a modifier-target role yet — promote only if a modifier needs it.

Scope payoff (the quantitative win):

• ~55 SNKRX units, each with ~2.5 class tags, populate ~144 tree-slots (~8–10 trees x ~18). "144 classes" is NOT 144 designs — it's 144 (tree x unit) memberships drawn from ~55 units.
• Author ~10 full root kits + ~55 lightweight modifier-sets. Each unit is authored once as {kit-when-base, modifier-set-when-picked}. NOT 55 full kits. The multi-class web IS the content multiplier.

Substrate connection (to session 11): "modify the primary" with anything interesting = carrier-behavior mutation (re-fire / chain / fork / +projectiles), which the session-11 review flagged as the hardest open architectural decision. Adopting this class model MAKES that substrate mandatory. Required spine = the session-11 convergence: player:cast(name, opts) chokepoint + abilities as enumerable role-keyed handles + per-ability replay-shape + opts.free.

SNKRX grounding (read from source, not memory): pulled character_classes, character_class_strings, class_descriptions, tier_to_characters from SNKRX/main.lua, and root-unit attack code from SNKRX/player.lua. Recorded each of the 16 SNKRX class synergy effects (warrior=+def, ranger=barrage-on-attack, mage=-enemy def, rogue=crit-4x, nuker=+area dmg/size, conjurer=+construct, psyker=+orbiting orbs, curser=+curse targets, voider=+DoT, sorcerer=repeat-every-N, forcer=+knockback, swarmer=+critter hits, healer=healing orbs, enchanter=+ally dmg, mercenary=+gold, explorer=+per-class scaling). Key data-driven insight: SNKRX never ships a PURE nuker/psyker/curser/voider/forcer — they only exist as second tags — which is the game telling you those are FLAVORS, not standalone base identities.

[REDACTED: private project content]

Curser folded away (where the curser-only units land): barbarian to Warrior, silencer to Sorcerer, jester to Rogue, infestor to Swarmer (launcher already cut in source). Secondary-only tags, never a base: Curser, Healer, Enchanter, Forcer, Mercenary, Explorer.

Open items / NEXT:

• Roots still to INVENT: Voider, Nuker (Psyker = Vagrant decided).
• Mage-vs-Nuker overlap is GATED on the Magician's direction (other session): if Magician trends to AoE, Nuker is redundant; if precision/status, Nuker is wide open (split = precision-element vs raw-AoE-boom).
• Archer needs a NEW passive when Echo migrates to Arcanist.
• NEXT DESIGN PHASE = oversample/overgenerate abilities per base (abilities-first, iterate to a fun-lock as the Swordsman and Archer both required; designs WON'T survive unchanged since fun is unmeasured beforehand), THEN the modifier-sets. Widest oversampling at the 4 hardest: Voider (active DoT payoff), Psyker (active orbit control), Rogue (gunslinger vs assassin), the Mage/Nuker split.

Memory: updated project_062026.md with a full Session 13 entry marked the class-system design reference, and updated the MEMORY.md index pointer. No design document created (owner's explicit call).

Only the summary of this log is public. Private because this is 062026.