Battle scripts: how hero mechanics work in the game's code

1  About this page

Some hero mechanics are not in the config tables. Which damage counts as DoT, which units count as summons, and which buffs a hero's payoff counts are all decided in the battle scripts. Earlier tools guessed these from skill text and were often wrong. The scripts ship with the game as compiled Lua 5.4, and reading them answers these questions from the game's own logic.

This page is the durable record: layout, reading method, rules and procedure. The hero-by-hero result of applying it to stargazer's filters is a separate output: python3 tools/stargazer_filter_audit.py writes the audit page out/tools/stargazer-filter-audit.html. It holds the audit's findings with evidence, verdict, slot and level, and confidence, and reads stargazer's current tags live. The reading tool is tools/battle_scripts.py. Their output under out/tools/ is not committed.

2  What the game ships

igame.pkg holds 11,139 entries, all Lua. The battle code is the 3,632 chunks under Src/Battle/ (17.4 MB):

Src/EffectScore/ (418 files) only lists each unit's VFX prefabs. The engine the scripts call (BattleEngine, AddBuff, TakeDamage, …) is native code: an IL2CPP build whose metadata strings are obfuscated. What a script asks the engine to do is readable. What the engine does on its own is inferred from how scripts use it, and every such inference is marked below. The AFKJourneyData dump never had these files.

3  Reading the scripts

The chunks are stripped bytecode. Local variable names are gone, but every global, field and method name is a string constant, and each function keeps its source line span. afkj_extract.formats.luadis reads them (load, walk, dis) and lifts them. lift(chunk) tracks each register's content as an expression, so a function prints as statements with readable operands instead of register moves. Control flow stays as if … goto N; this is not a decompiler, and doesn't need to be.

$ python3 tools/battle_scripts.py show vulture OtherChangeHp
-- main/18@667  r1.OtherChangeHp  lines 667-690 params=8
    8  a0(a1, a2, a3, a4, a5, a6, a7)
    9  if a3 >= 0 goto 86
   11  if a7 ~= 'dot' goto 86
   ...
   60  r1.atk3buff_CurseAccumulate(a1.vluture_atk3_buffs[r11], -a3, a1, …)

• Parameters are a0…, and call results are named after their register (r6 = a2:AddBuff(…)). A value that differs by path shows its alternatives, sorted: (3 || a1.info.SArg1) is 3 on one path and info.SArg1 on another (often compiled from info.SArg1 or 3); || here is not Lua's or. The module table is r1.
• A copy or constant written over a variable (a parameter, a call result, a table, a loop value or a joined value) is printed as a statement: r9 = r6, r6 = 0. Before 2026-10-03 these were hidden, so a value replaced on one path looked unchanged: Lyca's target list (both branches return every target) was misread as trimmed, and lethal-hit saves that zero the damage before return, and heal hooks whose result replaces the heal, were easy to miss. Copies that only load a call's function and arguments, or a loop's bounds, stay hidden. When a result depends on a list built in a loop, a count, or which value a register holds at a return, still confirm it in the bytecode (luadis.dis).
• Every call site, store and comparison is recorded, so questions become queries: battle_scripts.py calls AddSummonUnit lists all 227 call sites with their arguments. show <codename> <word> prints every function whose name contains the word or whose constants include it.
• Table literals print as <list>. To read one, such as the stat lists below, walk the bytecode back from the SETFIELD to its NEWTABLE and collect the constants.
• All 29,779 functions lift without an unknown instruction: about 35 s for the whole package, 8 s for the 129 heroes. No unknown instruction doesn't mean nothing was skipped, so the reader has two more guarantees, below.
• Loops. Lua 5.4's FORLOOP and TFORLOOP jump back to pc + 1 − Bx: the VM has already moved past the instruction (lvm.c). Until 2026-09-29 the reader used pc − Bx, which sent every for … in loop back to its set-up and skipped the body. That hid 406 calls in 54 heroes, mostly the "for each enemy hero, add a buff" shape, and changed eight audit verdicts. tests/test_formats.py compiles loops with lupa to keep this fixed.
• Settling. A value that changes on every pass, such as an accumulator, never settles on its own. After 8 merges at one instruction the reader widens such registers to their plain name (r2), so every function settles. Each lifted function carries complete. If the safety budget ever ran out, the function would still be listed in full, with plain operands, and render would mark it -- incomplete. Today all 29,779 are complete.
• Reachability. Only 8 call instructions in the package are unreachable: dead code behind conditions that are always true, in four monster and boss scripts. With the old loop target it was 724. If a reader change moves that number, suspect the control flow.
• Game files are only read, and never while the game runs: every access checks first, with no override (Architecture §2). No game code is run.

4  Anatomy of a hero script

Each hero script (Logic/Heroes/<Unit.Script>.luae) builds one module table, ed.battlehero.<codename>:

• Settings. Buff ids (r1.ult_sleepBuff = 5602) and SArg names (r1.ult_sleeptime = 'SArg0'). Skill numbers are read at run time as skill.info[r1.ult_sleeptime], the skill row's SArg0 at the hero's level, so a number in the code traces to a table value. The parse model already reads the integer settings (HeroScripts, Raw data §10.5).
• Skill hooks, named <Slot>_<Event> (Ult_TakeEffectOn, Atk3_AddBuff, Atk2_OnAttackFrame, Atk3_CustomUpdate). Init_hero installs each on a named skill: ed.override(a0.skills[name .. '_ult'].OnAttackFrame, r1.ult_OnAttackFrame). ed.override(original, new) passes the original as the hook's first parameter, which the hook usually calls first. The same pattern installs hooks on buffs (buff.IntervalUpdate, OnRemoved, OnFinalDamaged) and on units (unit.TryDieWhenDefeated, unit.Die).
• Config buffs. A skill row's BuffID is applied by the engine when the skill hits. The hero's <Slot>_AddBuff hook wraps that and usually sets the buff's runtime numbers (SetAttribute).
• Unit event handlers: OtherChangeHp (any unit's HP changed; 29 heroes), OtherUnitDie (36), BattleEngineAddUnit (a unit entered the battle; 12), OtherAddBuff, OtherUnitRevive, SuccessMakeDamage, FixOneAttrib, RunBattleStartLogic, Reset, Update.
• Engine calls are methods on units, skills and buffs: target:AddBuff(id, caster, time), buff:SetAttribute(stat, v), buff:SetTimer(t), target:TakeDamage(…), unit:TakeHeal(v, 'hp'|'mp', src), ed.BattleEngine:AddSummonUnit(…), ed.BattleEngine:ForEachAliveUnit(camp). Files using them: AddBuff 1,632, SetAttribute 1,129, ForEachAliveHeroUnit 672, TakeDamage 257, AddSummonUnit 154.
• Units a hero creates run their own script, named by their Unit.Script. For example, Pandora's box is unit 5023 with script pandorabox, and Phraesto's Illusion runs scorpion, the same script as Phraesto. Anything those units do is in their script, not the hero's.

5  Engine rules learned from the code

5.1 Damage and damage kinds

TakeDamage(amount, type, caster, skill, flag, kind) and LostHp(amount, source, …, kind) carry a kind as their last argument, and HP-change handlers receive it (OtherChangeHp(base, self, target, hpChange, source, …, kind)). The type is 'AP', 'AD', 'Holy' or a buff's DotDmgType. Kinds seen:

• 'dot': 33 call sites.
• 'share_damage', 'drain' and 'skill': a handful each.
• None: ordinary hits.

Shadewing's curse (vulture.OtherChangeHp) accumulates only when kind == 'dot'. So damage every second is DoT only if it carries that kind. Tasi's ultimate re-hits every second, and Voracia's roast re-casts every 0.5 s (TakeEffectAt from a custom update). Both are ordinary skill hits.

The handler tests the damage, not who dealt it. An enemy that carries her curse (10602, which her skill3 puts on every enemy unit that can be targeted) and loses HP with kind 'dot' adds that loss to the curse, whatever the source: another hero, a summon, or Shadewing herself. One source counts at 20%: unit 5109 (camppettwinboth, not a hero and disabled in the unit table). So every hero DoT that lands on an enemy feeds the curse (checked for all 27 attachments, 2026-10-11).

5.2 Buffs, stats and FixOneAttrib

• Buff instances. AddBuff(id, caster, duration) returns a buff whose info is its SkillBuff row, with per-instance overrides via info:WrapTable. buff.timer is the time left, and buff.attrib lists the stats it sets. SetAttribute(stat, v) sets a stat at run time: stat is additive, stat_x multiplicative.
• FixOneAttrib. Whenever a buff sets one of a unit's stats, the engine calls the unit's FixOneAttrib(self, stat, old, new, mode, buff) (mode is 'adds' or 'coefs'; roles inferred from use). Hooks on it are how payoffs count buffs:
  • Temp buffs. Dionel (godspear), Orion (prince) and Perseus's ex (perseus) run the same check. They count a buff from another unit on the same team, with buff.timer ≤ 100 when applied, a positive new value, and a stat from the list below. Each ally caster counts once. The hook is on the hero's own unit, so the buff has to land on that hero. What differs is how long a caster stays counted: Dionel and Orion keep it for the whole battle, while Perseus counts the casters whose buff is still on him (his Update drops a caster when that buff is removed). In normal modes nothing else adds to the three counts (Orion's AddFriend is called from special-mode code only).
  • A season charm counts them too. gem_ep8buffboost (in SkillScripts) hooks FixOneAttrib on every ally of its holder, with the same 31 stats and a positive value. Its caster test is the holder, and its timer test is 0 < timer < 9000, wider than the heroes' 100. The Haste it then adds (4022200) is added with a 99999 timer and ended with the source buff, so Dionel, Orion and Perseus never count it.
  • Debuffs. Eryndor (hermit.OtherAddBuff, BadLuckTarget_FixOneAttrib, CanAddBadLuckStack) counts a buff cast by his team that pushes a listed stat below zero on an enemy that is a common unit (IsCommonUnit) and not a summon. It can do that in the table (info[stat] or info[stat..'_x'] < 0 when added) or later through FixOneAttrib. Each caster gives an enemy one stack (hermit_badLuckCountBySourceTarget[caster:target] against the ult's SArg9 = 1), up to SArg0 = 3 per enemy, so a full count needs three different casters on that enemy. The stack is a 9999 s buff, so the debuff's own length doesn't matter. The only test on the caster is its camp: nothing excludes Eryndor, so his own stat cuts (the awakening's entry fee, the ATK a lost game pays) read as one caster too, and a summon is a caster of its own. Not tested in game.
• The stat list is the same in all four scripts: HP MP ATK ARM MR CRIT RES HIT DODG HAST CURE HEAL PT LFS CRITRatio MpD MpP BLOCK HalfHp SUP DebuffP DebuffD VictimMpRatio GainMpRatio AllMpRatio MSFix ATKHAST CritP CritD DmgP DmgD.
  • Not in it: MakeDmgMulti, TakeDmgDivision, TakeDmgMulti, ExRange and shields.
  • Control flags carry no stat, but a fear or attraction buff with MSFix < 0 does.
• Order matters when a buff is added at 9999 and shortened later. The timer at the moment the stat is applied is what the check sees.
• What reaches FixOneAttrib. A stat_x change arrives under the base stat name with mode 'coefs': Eryndor's hook accepts 'adds' or 'coefs' for base names, and Lamentis's mirror replays info[stat..'_x'] as (stat, 0, value, 'coefs'). So an ARM_x buff counts as ARM. MaxHpChange and MaxHpChangeValue arrive under their own names (bwmitem.FixOneAttrib tests them) and are not in the list (Rolan's ultimate doesn't count).
• AddSource (owner or caster on a SkillBuff row) says whose stat an _x or _a value scales from. It doesn't change the buff's caster (hermit.Atk4_CollectPositiveBuffAttribs, perseus, phantom).
• Eryndor's ex names what it ignores next to the stat list: MakeDmgMulti, MakeDmgDivision, TakeDmgMulti, TakeDmgDivision, GravityCoef and MP (atk4_iconIgnoredAttribs; ult_badLuckAttribs is the list).
• An area's buff gets a short duration. A skill row's own buff applied by a region lasts what the engine passes, even when the table Time is 9999: Tilaya's ex 3 zone (10504, Time 9999, its hook passes the engine's duration through) stacks Dionel, Orion and Perseus in game (user, 2026-10-03). Region hooks that want a set length pass one (Kordan's ultd_AddBuff 0.5 s, Galahad's Ultb_AddBuff 1.25 s). A script's own AddBuff(id, caster, 9999) does last 9999.
• An upgrade can switch a duration. Velara's ult transfer passes CheckAwakenLevel(1) and 9999 or SArg3 (shown as (9999 || …)): 10 s, or all battle once awakened.

5.3 Ticking buffs (IsDot)

A SkillBuff with IsDot ticks every DotInterval (first tick after DotInitialInterval). The tick amount is the DotAttrib stat of the caster or target (DotAttribOwner) × DotDmgAttribCoef:

• Positive: damage of kind 'dot', of type DotDmgType; HP loss of kind 'dot' if the type is LostHp. Scaled by the target's DOTRATIO.
• Negative: a heal.
• No DotAttrib: only a timer. Tasi's sleep buff is one: each tick re-hits with the ultimate.

So IsDot alone says nothing about damage: most hero IsDot buffs are heals, shields or timers. Most DoT buffs have coefficient 0 in the table, and the applying hook sets it from an SArg (SetAttribute('DotDmgAttribCoef', skill.info[r1.ultdot_coef])). A script can also turn a buff into one at run time (SetAttribute('IsDot', true), Bonnie).

Inferred engine rule. No script defines the tick, but facelessmagewater.ult_BuffUpdate reimplements it exactly as above. Two things support it:

• Shadewing's own DoTs are IsDot buffs, and her handler heals her from her own 'dot' damage, which would be dead code otherwise.
• Players' tests tag five heroes whose DoT is a LostHp IsDot buff.
• A script can run a buff's tick by hand with buff:IntervalUpdate(amount): a positive amount is a 'dot' hit, a negative one heals. Nara's skill2 does this once per tile it pulls an enemy, so it counts as DoT (a player's test agrees); wheel_common_lowhprecover heals this way. These are the only two callers.

The replica reads a column the table no longer has (DotHidePop), so it may be older than the engine.

5.4 Healing

HEAL is healing received and CURE healing done. Alna's WinterladyTakeHeal reimplements the heal:

• a receiver with unheal gets nothing;
• a healer with onlycureself heals only itself;
• the amount is scaled by (receiver HEAL + 100)/100 × (healer CURE + 100)/100 (Thoran's sk_GetSupportCoef).

A heal-over-time is an IsDot buff with a negative coefficient (§5.3).

OnHealDivision returns the healing that passes: the engine replaces the running amount with the hook's result (brulespirit.CalcHpHealPreview, a Lua copy of the calculation, moves it back into the amount at pc 125). Kordan's wall returns heal × 0.6, a 40% cut, though his text says 60%. The same buff's OnDamagedDivision returns damage × the same value (ult_wallcoef), so if that hook's result replaces the damage as the healing one does, outside damage is cut by 40% too. Not tested in game.

5.5 Control flags

A buff's ControlEffects names flags, and the game's own tables (SkillBuffUI, SkillKeywords) define them:

• silence: normal attacks only.
• unmanual: ultimate forbidden.
• unheal: recovery forbidden.
• noAddMp: energy gain forbidden.

stun and frozen contain silence, disarm, unmanual and immobilize (CoverEffectNames). supersilence and uncastmanual also exist. A hero can also block enemy casts directly: Lily-May's CanOtherUnitCastSkill returns false for an enemy's ultimate.

5.6 Energy and casting the ultimate

• Energy moves through unit:TakeHeal(amount, 'mp', src) (negative drains) and unit:SetMp(v). AllMpRatio is energy recovery speed.
• Starting energy is Unit.StartMP, unless a script replaces it: Init_hero sets StartMP in the skill info, often after CheckLevel or CheckAwakenLevel. A script can also add energy at battle start (TakeHeal(x, 'mp') in RunBattleStartLogic, SetMp in Reset).
• Heroes whose script changes it, as last reviewed (build 14368) for heroes that end above 300: Cecia 500 at awakening 2 (thorn.Init_hero sets StartMP = SArg6), Valen 500 at awakening 2, Hodgkin +400 at battle start at awakening 2, Lyca 200 + 300 at awakening 2, Odie 600 at ex 3, and Cyran 400, then 600 from awakening 1. Hewynn's loli.Init_hero sets StartMP to loli_atk4 SArg2 = 300 at ex 2+: from 200 it becomes 300, it does not gain 300. Nara's Reset calls SetMp with her own StartMP, 750. No mastery skill sets or adds starting energy (all 127 read, 2026-10-03). Stargazer holds these in each hero file's energy: the StartMP first, then what the script adds. Its Init Energy filter is worked out from the two, so it is not a tag and the audit has no row for it.
• The ultimate's cost is the _ult row's CostMP, which a script can override (Reset sets CostMP).
• Every hero's max energy (Unit.BaseMP) is 1000, so StartMP 1000 starts full.
• Inferred: an ultimate is castable once energy reaches CostMP. Aster's 600-cost ultimate has no script check, and its text says it consumes 600. Most cheap ultimates add their own threshold in Ult_CanCastWithCaster (1000 for Galahad, Marcille, Pang, Senea, Velara and Zorya; Shakir 700 with his ex).
• Inferred: the first cast is the ready skill with the highest Priority (InitCD 0, cost met). Hidden auto-cast sub-skills (IsShow false, ActiveType active) are cast by the engine too: every hero's basic attack is one, and Smokey & Meerky's aroma (meerkat_ultb) starts that way, since no script casts it at battle start. When its hit lands is animation timing, which the tables don't hold (about 3 s in game for Smokey's).
• Prepare skills' GainMP isn't starting energy. Kulu's bombgirl_atk2b can never be cast (atk2b_CanCastWithCaster returns false); Faramor's and Pippa's are cast at 0 s like any first cast.
• Cast guards decide, not just energy. Read Ult_CanCastWithCaster and Ult_CanCastWithUnit before calling an ultimate instant. Faramor's returns false below 1000 energy, so his first cast's CostMP 250 doesn't help. Valka's needs a target with 4 panic stacks, or the target her EX just blocked.

5.7 Death, revival and kills

• Preventing death:
  • an override of unit.TryDieWhenDefeated that returns false;
  • a buff's OnFinalDamaged hook that compares HP with the incoming damage and answers with SetHp(1), an invulnerable buff or a morph;
  • an override of unit.SetHp that tests the new HP and passes a higher value on. Mehira's ex passes 20% of max HP on whenever the new HP is lower and a voidling is left. Inferred: every HP change reaches SetHp (her hook counts her healing and catches hits in the same place), a killing hit arrives as a value at or below zero, and the engine decides death from the HP SetHp leaves. Thoran's script expects the same: its SetHp turns a negative HP into 1 behind ult_cantdie, a flag no script sets, so that code never runs;
  • deadUnit:Revive(...).
  Many Die overrides only clean up, so they are not evidence.
• Killing outright: target:Defeated(killer), target:Exterminated(killer) or LostHp(target.hp), usually behind an HP threshold. Calls on a hero's own objects (summons, rocks, seeds) are cleanup.

5.8 Summons and created units

• A unit is a summon while unit.config.is_summoned is true; 261 scripts test it. Unit.UnitType is not what the code checks.
• ed.BattleEngine:AddSummonUnit(unitId, level, summoner, pos, attrs, …) (227 call sites) and a skill row's SummonUnitList create units with the flag set. Its two boolean arguments (positions 7 and 8) don't decide it: every combination scripts pass includes a confirmed summoner.
• A hero's starting companion is Unit.SubordinateID. It is placed with the hero, fetched by GetSubordinateUnits in InitRelationship, and has the flag cleared there.
• Scripts can clear the flag right after AddSummonUnit returns.
• Summon payoffs (Aurora, Florabelle) run in BattleEngineAddUnit(self, unit) and check the camp and the flag at that moment.
• Carriers and tools are not summons. Some units are created with isUnitCarrier = true in AddSummonUnit's last argument (read back as config.isUnitCarrier or unit:IsUnitCarrier()): helpers, partners and props. Examples are Taichi's and Yamato's partners, Sylphira's music note, Contess's energy bar, Kulu's Boomboom and Damian's plane (special modes only). The engine also marks some units config.is_tool; no script sets it. The game's own summon counting (fever_ep7skill_summonnumadd.BattleEngineAddUnit, bossrace_summon_atk.IsSummon) skips both, and names its exceptions: Zanie's low turret (5020), Laios's unit (5045), and Berial's summons (hero 31). Aurora's and Florabelle's handlers don't test the carrier flag. So for stargazer's Summon filter a carrier is not a summon, though in principle it could still pass their checks.
• Skill effects are not summons. Some units exist only as part of a skill: Ludovic's flower field, Thador's moon, Rolan's sword, Velara's altar, Sylphira's music note, Contess's energy bar. They have no battle script of their own (Unit.Script is empty), no or one placeholder skill row, no monster type, and sit in faction HeroTagID 7 ("Other"); the hero's code drives them. Players report that summon buffs (Aurora, Florabelle) don't apply to them. Every real summon has its own script, except Daimon's Stitchy, which is monster-typed (UnitType 3) and has its own skill rows.
• The rule, as code (battle_scripts.unit_kind, used by battle_scripts.py summons). A created unit is a summon if all of these hold:
  • its flag isn't cleared;
  • it isn't a carrier;
  • it isn't hero- or NPC-typed (UnitType 1 or 2);
  • it has its own script or is monster-typed.
  Every summon stargazer tags passes, and every unit players describe as a skill effect or helper fails. The engine's own reason a buff doesn't land on a skill effect isn't readable; the rule reproduces what players observe.

Two cases this explains:

• Phraesto. His starting Illusion never counts. His ex 4 re-creation clears the flag only after creation, so it counts for creation-time effects, which matches what players see. It also confirms the event fires inside AddSummonUnit.
• Zanie. Her starting turrets are not summons; the skill2 low turret is.

5.9 Teams, targets and "all enemies"

• ForEachAliveUnit(camp), ForEachAliveHeroUnit(camp) and AliveHeroUnitIterator(camp) iterate a team. -camp is the enemy team.
• A loop over -camp with no distance filter, or a skill row with AOE around [20] and no target-filter hook (IsSpecialIgnoreTarget, CollectAoeTarget), reaches every enemy.
• Inferred: a row with AOE from self, [20] and an empty AOEShape also collects the whole team. imprison, set up the same way, has to table.remove the extras to keep N, while Lyca's skill3 collector only reorders the list. Radius 10 from self is how the game writes the whole field: Alna's ultimate text says "all units except Alna" (除阿尔娜外的所有单位), and her blizzard and Igor's and Bonnie's ultimates use it.
• Skill rows' TargetCamp / AffectedCamp: 1 is allies, −1 is enemies. TargetPriority self only anchors a skill on the hero: its area can still reach allies (Laios's dish), and a script can retarget it (Antandra's ex sets a1.target to her guarded ally).
• TargetPriority (front_start, back_start, farthest, …) and FirstPriority (notself) pick targets. The common values are target, self, current_target, h_mostunits and enemy nearest.
• Scripts pick by board position with depth × camp arithmetic or battleStart_hexgonPosition.
• Areas a script runs itself. unit:GetAroundUnit(radius, …) returns the units around a unit (Shakir's ex aura, the charm gem_ep8frontbuff). skill:CollectAoeTarget(pos, …) runs the skill row's own area from a position, which is how a lasting zone finds who is inside it (ult_CheckRegion in Fay's and Mikola's ultimates). A CollectAoeTarget hook can move the origin (Zandrok's charge line).
• A script can replace a row's area or target. Laios's Init_hero wraps AOEShapeArgs on his skill3 row (the table says radius 1, the text 2 tiles). A SelectTarget hook can return a unit the script stored (Isabella's companion, Faramor's blessed hero), and IsSpecialIgnoreTarget drops units from an area (Kazim's wind field skips Kazim).
• Picks from deployment compare battleStart_hexgonPosition: the unit that started on a given tile (Gunnar's Doomfield, Faramor's blessing) or behind the hero (Taichi & Agumon's awakening). Hugin's sigil is the other kind: it looks up whoever stands on the tile now (BehindUnit reads cubePosition).

5.10 Areas, regions and "tiles"

• In this engine a "tile" is a projectile: CreateProjectile with *_tile_Hit handlers, and skill rows' TileArt.
• Lasting zones are skill regions (SetRegionState(true), SetRegionPos). Inferred: a region is on from battle start unless a script switches it off: 16 heroes switch theirs off in Reset/Init_hero, and Kazim's wind field, never switched on, works from the start ("covering the battlefield" when a battle starts). Its buff's duration is the engine's (§5.2).
• Terrain changes are AddBlock, Wreck, _AddUnitBlock and StartFreezeArea.

6  Skill slots and unlock levels

• Slots. Function names (Atk3_…) suggest a slot, but Init_hero says for sure. For example, Arden's Atk2_AddBuff is also bound to her ex skill. To find the slots behind an effect, read the ed.override(a0.skills[name .. '_X'].Event, r1.fn) bindings and follow calls, and hooks installed on buffs, from those functions. Hero-wide handlers (Update, BattleEngineAddUnit, …) belong to whichever skill's data they read.
• Sub-skills. Rows like atk2b or ultc belong to their parent skill. FatherSkillSlot links others: Ludovic's pharmacist_atk5 is part of his ultimate.
• EX and skill levels. Skill rows exist per SkillLevel with their own SArgs, and a script checks skill:CheckLevel(n). An effect unlocks at the first level whose value is non-zero or that passes the check. For example, Aliceth's ex DoT coefficient is 0 until ex 4, and Phraesto's contract energy is 0 at skill level 1.
• Awakening. CheckAwakenLevel(n), with values on the <code>_awake_n rows. A script may read them through another skill's info (skill_ult.info[r1.awaken_…]).
• Special modes. *_imba_1 rows and imba code apply only in Honor Duel and Dura's Trials.
• How stargazer records it. A tag lists its attachments, one per effect: where the effect is pinned, as {slot: level} (for example {"ex": 4}), with one entry per level where the effect changes, and optionally the modifiers that describe it ("mods"). A filter is a tag, or a tag narrowed by a modifier. Temp Buff (Opening) is the tag temp-buff on an attachment that carries "mods": ["opening"], so an opening buff is one attachment in both filters: {"skill3": 1, "mods": ["opening"]}. Debuff (Global), (AOE) and (Single Target) are debuff with global, aoe or single, one per attachment, Debuff (Eryndor Synergy) is debuff with eryndor (a hero's slug as a modifier marks a synergy with that hero), and Ult (Opening) is ult with opening. A global debuff his ultimate counts is one attachment in both: {"ex": 1, "mods": ["eryndor", "global"]}. Cheat Death takes self and ally (who is saved), and one effect that saves both carries both: {"ex": 1, "mods": ["ally", "self"]}. Two separate effects on one skill level are two attachments. Until stargazer's tag refactor (2026-10-03) these three were tags of their own (temp-buff-opening, debuff-global, opening-ult). tools/stargazer_tags.py reads the format for both filter tools. Since 2026-10-11 temp-buff attachments carry dionel, orion and perseus, and dot attachments carry shadewing (§7). A synergy never folds into its tag's name, so DoT still reads "DoT" with "Shadewing Synergy" as a choice under it. Each temp-buff attachment also carries one targeting modifier, global, aoe or single (§7), and so does each haste attachment, with opening beside it when the Haste lands at battle start: {"skill2": 1, "mods": ["aoe", "opening"]}.
• Charm tags. A season charm's tags are kept once per charm in stargazer's charm tag file, as the tiers that carry the effect plus optional modifiers, and stargazer joins them to every hero sharing the charm. The filter tools here read hero files only, so charm tags are checked by hand (research/synergy_check.py tags covers their synergy modifiers, and research/tempbuff_targets.py check their targeting modifier).

7  Stargazer filters as game rules

Each of stargazer's hero filters maps to a rule in the code. Where a hero's code consumes the mechanic, that code is the definition, and it is exact. Elsewhere, the definition is what the tagged heroes' code does. A hero qualifies at the slot and level where its code meets the rule. Stargazer treats every hero as fully unlocked and leveled, so the level in a tag ({ex: 4}) records where the effect starts; it is not a condition for the filter (user, 2026-10-02).

Derived, not hand-kept: DoT, Summon, Heal Denial, Cheat Death, Invincibility, Execute, Energy Denial, Ult Denial and Energy Battery. tools/filter_derive.py applies these rules to every hero (tests: tests/test_filter_derive.py). Where an effect sits:

• Slot. In order: the function's name (Atk4_, Ult_; derived skills such as atk5c through the row's FatherSkillSlot); the skill it is installed as a hook of; a level check on a skill, which moves the effect to that skill; the skill whose data the value is read from (Nerion's drown damage is the EX's numbers, applied by the ultimate); a skill named mid-name (OpenAtk4Circle); then its callers. Awakening and special-mode code keep those slots (*awake* buffs and functions, imba code and branches, Duel leader skills DuelSkill_*). A skill named through a module variable (r1.atk4Name = r1.name .. '_atk4', Shakir, Pang) is read as that skill.
• Level. The highest CheckLevel on the way to the effect, and the first level at which its value is non-zero in the skill rows (Saida's trap is 0 until EX 4). A flag or a count switched on behind a level check gates the code that tests it (Rowan's energy potion: mpbottlenum = 1 after CheckLevel(3)). A check covers only the code it guards: code reached by a jump from before the check isn't gated by it (Nara's normal path runs inside the span of a special-mode check).
• Every skill counts. Each skill whose code has the effect is tagged on its own, mastery and basic attack included (Contess's mastery regen cut beside her skill3 one), whether or not another skill of the hero already carries the tag (user, 2026-10-03). Special-mode (imba) code is never tagged, in every filter (user, 2026-10-03).
• Ignored. Functions nothing calls or installs (Arden's TwineBuff_Update).
• DoT. A 'dot' hit, an IsDot buff with a positive coefficient (table or set at run time; a skill row's own buff with its AddBuff hook, on a ground area where the area is switched on: Gunnar's scorched area at awakening 1), a buff made IsDot at run time, or a tick run by hand. Awakening buffs need a positive coefficient too.
• Heal Denial. An unheal/onlycureself buff on a unit that isn't the hero's own (the same test as the other filters, and not a protection buff that is also invulnerable or untargetable), a skill row's own such buff (a ground area at the place it is switched on; preparation-display rows don't hit), or an OnHealDivision/TakeHeal hook that passes on less healing. Where several skills apply the same buff, its name decides (oldgod_ult_… is the ultimate's).
• Cheat Death. Each saving action in a death hook counts on its own skill: the skill it casts or the skill its buff is named for (Thoran's hook casts his skill3 revival or the ex's ally save). A lethal-hit hook's slot is its own name, its level the install site's check or the first level of the counter it checks (Ravion's save count is 0 below ex 3). Setting the hit to 0 before returning it is a save (Brutus, Talene, Zorya). A SetHp hook counts when it tests the new HP and hands the engine another value, on the skill whose data it reads (Mehira's ex), unless the test sits behind a flag the script never sets (Thoran's). A lethal check that lets the hit through doesn't count, nor does a low-HP trigger whose test a killing hit can pass (user, 2026-10-03). Scarlita's awakening 2 is one: it fires once the ally is already at or below 20% HP, or on a single hit of at least 80% of its max HP (the code subtracts the hit from max HP, not from current HP), so an ally at 50% that takes a 55% hit dies.
• Invincibility. An invulnerable buff outside death hooks, on a unit that isn't the hero's own: not caster, not the hero inside its own hooks, not a unit it created or keeps in a field filled with one, not a hook's unit installed on such a unit. The skill must not target enemies. A transition that happens to be invulnerable isn't protection (Reinier's skill2 swap; user, 2026-10-03).
• Execute. A Defeated/Exterminated call, or a LostHp of the whole HP, on a unit that isn't the hero's own (own also covers lists of created units, and the holder of a buff the hero put on its own unit). Clean-up at battle end, and functions named for destroying the hero's own props (destroy/destory: rocks, stones, seeds, ice), don't count.
• Energy Denial. A drain (negative TakeHeal 'mp', a lowering SetMp), a regen cut (AllMpRatio, GainMpRatio, VictimMpRatio or MpP below zero; UnitAttr: MpP is energy gained when hit; regen cuts count, user, 2026-10-03) or noAddMp, on a unit that isn't the hero's own. A buff stored on the hero is the hero's (Shakir's wolf-form cost), so is a buff a unit puts on itself (Zorya). A table buff named for a skill counts on that skill (Viperian's ult mark).
• Ult Denial. silence/supersilence/unmanual/uncastmanual on others, not with stun, freeze (frozen, forcefreeze), sleep, fear, petrify, entangle (twine), imprisonment, disableAI or a polymorph; or a CanOtherUnitCastSkill hook that returns false or drains the caster. A flag gates code only when it is switched on behind a level check (Orion's silence at ex 3); a flag set at level 1 is plain state.
• Energy Battery. A positive TakeHeal 'mp' or a raising SetMp on a unit that isn't the hero's own. Also own: the hit unit of a projectile homing on the hero (Isabella's ult tiles, Bryon's absorb), the target of a self-aimed shot (TargetPriority self, no area, TileCollideType target, not aimed at enemies and not retargeted by the script: Arden), a summon's config.summoner (Damian's car), the holder of a buff the hero puts on itself (Lenya) or gets through its own AddBuff hook (Galahad). TargetPriority self alone isn't enough: a script can retarget the skill (Antandra's ex sets a1.target to her guarded ally) or its area can reach allies (Laios's dish). A fixed partner counts (Laios → Marcille, Taichi & Agumon → Gabumon). The level is the first at which every table value the amount reads is non-zero (Reinier's ally energy at skill3 4).
• Units the hero creates. For Energy Denial, Ult Denial, Heal Denial and Execute, the scripts of created units are read too, carriers included, and their effects count on the skill that creates the unit (Pandora's box). Energy Battery isn't: a unit sends energy back to its owner (Lamentis's minions, Taichi's carrier), and from inside the unit that isn't visibly the hero. Death saves' side effects and Init_hero are handled as above: the saved unit's state isn't denial, and hooks installed in Init_hero count.
• "Has skill X" checks. if caster.skills[.. '_atk4'] then … places the code on that skill at level 1 (Odie's kill rides on his ultimate's poison but needs the ex); a level check outranks it.
• Summon. A created unit with the flag, including copies of heroes and units whose flag is cleared only after they enter (Phraesto's EX 4 clone), and copies of any unit by its own id (Berial's Silhouettes: AddSummonUnit(enemy.info.ID, …)). Not: carriers, units with no script of their own unless monster-typed (UnitType 3, Daimon's ghost), hero/NPC units, and companions whose flag is cleared at battle preparation (Elijah & Lailah's twin, the first Illusion). A copy kept hidden until it casts still counts: Galahad's ultimate makes one of herself, invisible with its AI off, and it takes summon buffs in game (user, 2026-10-04). Until then the check left such copies out as helpers, which the code never said. Unit ids are followed through parameters to the callers' values.

Special Target and Tile Effect are chosen by hand for guides and skill simulation, not by game rules, so they are out of scope. §5.9 and §5.10 record the code facts behind them. Honor Duel / Dura's Trials-only effects are not tagged.

8  Checking a hero

For a new release, or to re-check an existing hero:

1. Refresh the data. With the game closed, run the routine (./afkj-extract --locales-from cdn, ./afkj-parse build) so out/raw/tables and out/api match the install. The hero's codename is out/internal/keys.json → heroes[slug].codename, the same as Unit.Script.
2. Map the skills. Run python3 tools/battle_scripts.py show <codename> Init_hero for the skill bindings, then show <codename> for the settings (buff ids, SArg names).
3. Run the audit. make audit runs tools/filter_derive.py (the nine derived filters for every hero, compared with stargazer; exits 1 on a difference or a fact whose slot it can't place) and then rebuilds the audit page. Each derived tag lists the code fact behind it. A decision the code can't make goes in its REVIEWED table with the reason (today Yamato & Gabumon's cheer-partner hook and Nerion's awakening energy).
4. Work the "Needs review" panel at the top of the audit page. It lists:
   • heroes new on stargazer since the last full review: the derived filters cover them, the hand-reviewed filters (Debuff (Global), Debuff (Eryndor Synergy), Haste with its four modifiers, Temp Buff with its targeting modifiers, Temp Buff (Opening), Ult (Opening), and Cheat Death's Self and Ally modifiers) need the checks below;
   • heroes in the game data that aren't on stargazer yet (unreleased: handled when they release). A released hero's level can be unreleased too: the game hides an Awakening Lv2 with IsShow false until a later update (Harak, Ulmus, Sinbad and Mikola on build 14368; raw-data §9.2), and the feed and stargazer's skill data leave it out. A pin on a level stargazer's skill data doesn't have is never tagged (stargazer_tags.released): the audit shows its rows as Waits for release, and the code check lists it as waiting instead of a difference. Both lift on their own when the update brings the level in (user, 2026-10-14);
   • a warning when the game data build changed since the review;
   • rows made from the code check's differences, not reviewed yet. They also appear in each derived filter's table. Keep each one as a reviewed row (with its evidence) or fix the rule in filter_derive.py.
   After a full review, run python3 tools/stargazer_filter_audit.py --mark-reviewed: it records the date, data build and stargazer's heroes in tools/filter_audit_baseline.json.
5. Run the per-filter checks. battle_scripts.py dot --evidence and summons write every hero's DoT and summon evidence. For the other filters, show <codename> <word> with the rule's calls or fields:
   • Temp Buff: AddBuff, SetAttribute, SetTimer.
   • Debuff (Global): ForEachAliveUnit, ForEachAliveHeroUnit, and TakeDmgMulti, MakeDmgDivision, MakeDmgMulti, MaxHpChange, TakeHpLossMulti and damage rules on a buff, which are debuffs whatever Eryndor's list says.
   • Debuff (Global), (Single Target) and (AOE): python3 tools/debuff_targets.py sweep <slug> lists every buff the hero's code (and its created units') puts on another unit that turns a number against it, with its slot and level, the team loops and area lookups in the function, and the skill rows' targeting fields. Read the function and whatever picks the units, then sort it by the Temp Buff targeting rule (§7) applied to enemies. Compare the skill text too: the sweep reads one function at a time. Then nets and the audit page's sweep coverage line (§8.1).
   • Debuff (Eryndor Synergy): for each debuff attachment, whatever its reach, the buff's table row and its SetAttribute calls, against the stat list in §5.2.
   • Temp Buff and DoT synergy modifiers: who can receive the buff (a fixed partner, as in Niru's awakening 2, takes them off) and who casts it (§7). python3 research/synergy_check.py tags compares stargazer's hero files and charm tags with those rules and exits 1 on a difference. Its sweep lists every timed buff with a listed stat on another unit, for a hand review of what is untagged, and lists compares the hooks' stat lists.
   • Temp Buff targeting (Global, AOE, Single Target): python3 research/tempbuff_targets.py rows <slug> prints each attachment's skill text and its skill rows' targeting fields. Then read the function that applies the buff and whatever picks its recipients, and for an area the skill's IsSpecialIgnoreTarget, CollectAoeTarget and SelectTarget hooks (§5.9). Sort it by §7's rule and add its row to the script. check exits 1 while an attachment has no row or stargazer's modifier differs, and page writes every row with its evidence to out/tools/temp-buff-targeting-review.html.
   • Haste (Global, AOE, Single Target, Opening): python3 tools/haste_targets.py sweep <slug> lists every buff the hero's code (and its created units') puts on another unit that raises Haste, with its slot and level, the team loops and area lookups in the function, and the skill rows' targeting fields. Read the function and whatever picks the recipients, then sort it by Temp Buff's targeting and timing rules (§7) and add its rows to the audit page. Then nets and the page's Haste sweep coverage line (§8.1).
   • Heal Denial: unheal, onlycureself, OnHealDivision, TakeHeal.
   • Cheat Death: TryDieWhenDefeated, OnFinalDamaged, SetHp, Revive. For Self or Ally, read which unit the hook or its buff is put on (a1:AddBuff(buff, a1) is the hero). Most final-damage hooks only share, cut or count damage, so read for the lethal check. A save may have no fatal-blow wording in its text: Mehira's reads "a hit that would reduce her HP below 20%", so for an HP threshold read what the test compares. The table flag immoratal (cannot die) is used by modes only; a hero buff carrying it would be a save the code check doesn't read.
   • Execute: Defeated, Exterminated.
   • Energy: mp, SetMp, AllMpRatio, noAddMp.
   • Starting energy and Ult (Opening): StartMP, CostMP.
   • Ult Denial: silence, unmanual, CanOtherUnitCastSkill.
6. Resolve the values. Look each buff up in out/raw/tables/SkillBuff.json (stats, Time, ControlEffects, IsDot fields). Read each coefficient's sign from the SArg on the hero's skill rows (out/raw/tables/Skill/).
7. Follow created units. Take the unit id from AddSummonUnit or SummonUnitList, its Unit.Script, and repeat steps 2–4 on that script.
8. Find slot and level. Use the bindings (§6), CheckLevel / CheckAwakenLevel, or the first non-zero SArg level. A level check isn't enough on its own: Dionel's EX checks level 2, but its HEAL value is 0 until level 3.
9. Check the whole condition. A matching call is not a verdict. Before recording, confirm:
   • who receives the effect: targeting hooks, and which unit the buff lands on (Pandora's EX energy fills her box, not an ally);
   • the cast guards and alternate states that gate it;
   • that the coefficient is non-zero at the claimed level;
   • the scripts of any units the skill creates.
10. Record and apply. Fact-check every result in the code before recording it, including rows the code check made and any review notes: a call that looks like a match is a claim, not a fact. Add rows to tools/stargazer_filter_audit.py with the evidence, regenerate the audit page, then edit stargazer's character file. The page's By hero view gives each tag's value to set, in stargazer's format; a row in a filter with a modifier edits mods on the slot's attachment. A Check row states engine behavior the code doesn't show and ends with Test: …. A Decide row states a question about the filter's definition and ends with Decide: …. The generator refuses rows missing these. Rows stargazer already carries, compared slot by slot, show as done. Stargazer is public: never name the private repos or the extraction there.

8.1 Adding a filter or changing its rule

A new tag, a new modifier or a changed rule means reading every hero again under it. The Debuff reach review (2026-10-13) missed five effects, each for one of the reasons below (2026-10-14), so follow these steps:

1. Write the rule from the code and the owner's rulings alone, in §7 and in the section's definition. Keep it apart from other filters' modifiers: what makes a debuff doesn't depend on Eryndor's stat list, which only decides eryndor.
2. Build the candidate list by script, never by hand. Run the sweep (tools/debuff_targets.py sweep for Debuff, tools/haste_targets.py sweep for Haste). Every hero and slot it lists must end with a row, a stargazer tag or a reviewed reason. The audit page's Needs review panel lists any that don't (sweep_gaps, reasons in SWEEP_REVIEWED and HASTE_SWEEP_REVIEWED). Valen was missed because a hand-made reviewer list skipped him. When the reading is split between agents, generate the groups from every stargazer hero and check that each output covers every hero in its group.
3. Re-read every slot, tagged ones included. A slot can carry several effects that reach differently, and each is its own attachment: Pandora's ex 1, Evie's skill2, Daimon's ex 1, Velara's ultimate, Mehira's awakening 1, Viperian's ultimate. Velara and Mehira were missed because their slots were already tagged Global. A modifier row (eryndor) on such a slot names its reach in the label, Hero {ex: 1} (aoe); the page generator stops on an unnamed one.
4. Check the sweep's blind spots by hand.
   • The slot is decided by the gate, not by the buff's name. The sweep flags an AWAKENING GATE up the call chain; Viperian's awakening 2 viper carries a buff named for his ultimate.
   • A buff written into skill data at run time (x.BuffID = …, then WrapTable) is applied by the engine on hit, with no AddBuff. The sweep lists it as skill data (BuffID set) since 2026-10-14; Berial's ultimate fear was missed before.
   • A value written as current - v is a cut (Senea's and Voracia's max HP cuts).
   • A register can hold several buffs in one function. Since 2026-10-23 the sweep gives each setting to the buff the register holds at that point, and lists buffs that are never stored one by one. Before, the last buff took everything: Mehira's skill2 Haste was hidden behind a special-mode buff, and on the Debuff side three sites whose debuffs are tagged on another slot (Eironn's ultimate, Kafra's skill2 and ultimate).
   • One skill adding another skill's buff (Gwyneth's ex splash gives her skill3 burn through skill_atk3:AddBuff), and a skill's area rewritten at run time (Shakir's Wolf Form arc, Velara's circles). The sweep prints both as note: lines under the hero; read each.
   • Created units, and damage rules on a buff.
5. Run the checks that don't depend on the sweep. tools/debuff_targets.py nets searches the skill text and the buff table for debuffs no row covers. It exits 1 on a hit not yet read (reasons in TEXT_REVIEWED, BUFF_REVIEWED). tools/haste_targets.py nets searches the skill text for Haste raised for someone else on a slot no Haste row covers (reasons in its TEXT_REVIEWED). Community lists are leads to compare, not sources.
6. Hold unreleased levels. A level stargazer's skill data doesn't show waits for release (stargazer_tags.released, §8 step 4).
7. Put the open questions to the owner plainly. A Decide row says what the skill does, the question after Decide:, what each answer changes, and a recommendation. Record each ruling with its date in the row and in §7.

9  What only the game can settle

These rules are inferred, not read from the engine. Each has one short in-game test:

• Units created before battle start (partner units) and helper units made with AddSummonUnit: do they trigger summon payoffs? Test: Aurora with Sylphira (music note) or Contess (energy bar); does her mastery ATK rise?
• The ultimate cast rule (§5.6), supported by Aster's 600-cost ultimate. Test: Kordan; does he cast at battle start?
• The first-cast order (§5.6) and when a cast's hit lands (animation timing isn't in the tables). Seen in game: Smokey & Meerky's aroma reaches allies about 3 s in (user, 2026-10-03).
• Buff order for 9999-then-shortened buffs (§5.2). Test: Gunnar's ultimate with Dionel; do Dionel's stacks rise?
• Coverage of a radius-10 AOE, now backed by the game's own text (§5.9). Test: Alna's ultimate; is the rearmost enemy slowed?
• Settled. Max HP buffs don't count for temp buffs: MaxHpChange reaches FixOneAttrib under its own name (§5.2). An area's buff gets a short duration even with table Time 9999 (Tilaya ex 3, seen in game; §5.2). Galahad's own shadow, the hidden copy her ultimate makes, takes summon buffs in game, as does the ex's shadow of an ally (user, 2026-10-04). The Summon rule in §7 counts hidden copies since then.
• Death is decided from the HP SetHp leaves (§5.7). Test: Mehira with a voidling left takes one hit larger than her current HP; does she survive at 20% and heal?
• The IsDot tick rule (§5.3), already supported by five tagged heroes. Test: Aliceth ex 4 with Shadewing; do blinded enemies build curse?

10  Why code, not skill text

The retired viewer (afkj-data-viewer, scripts/build-data.ts) tagged mechanics with keyword and regex searches over skill text, plus IsDot copied from buffs and SummonUnitList. Text is a poor guide:

• "damage every second" is often not DoT (Tasi, Voracia, Karma's pool);
• HP loss is not DoT without the kind (Frieren's burn, Viperian's drain);
• a searched phrase misses most real cases;
• IsDot marks heals and timers;
• UnitType doesn't decide summons.

Effects gated behind EX 4 or awakening (Aliceth, Contess, Rolan) are easy to miss in tests. The code shows them with their level.

11  Size and cost

Most filters reduce to a few call shapes, so a mechanical reader covers them. Per-hero care is still needed for:

• values set in another function;
• buff ids passed in registers;
• created units' own scripts;
• engine-driven timing.

12  Open questions and next steps

• Derive the last filters. tools/filter_derive.py covers nine filters. Debuff with its reach and Eryndor modifiers and Haste with its four modifiers (their sweeps and coverage lines help, §8.1), Temp Buff with its targeting modifiers, Temp Buff (Opening) and Ult (Opening) are still reviewed by hand, so a new hero needs the §8 checks for them. Moving them into the derivation would make every release a routine check. Cheat Death itself is derived, but its Self and Ally modifiers are read by hand: the derivation finds the hook, not the unit it saves.
• Debuff reach: done 2026-10-14. One Debuff filter (user, 2026-10-03): every debuff attachment carries one of global, aoe and single, plus eryndor when Eryndor's ultimate counts it. Global and Eryndor Synergy came first (2026-10-06); AOE and Single Target were reviewed on 2026-10-13 and 2026-10-14 and are in stargazer since 2026-10-14. The rule and the user's rulings are in §7, every attachment's row and evidence on the audit page. How it went: a code sweep listed the candidates (tools/debuff_targets.py sweep), readers wrote a row for each, and the user ruled on the definition questions (max HP cuts, HP loss taken up, damage rules on a buff, reaches between two kinds; Eryndor's list decides only eryndor). The evidence was rewritten in plain English with code terms marked. A comparison with two community lists and seven checks against the code then found missed effects (Valen, Velara, Mehira, Viperian, Berial, Daimon), and a full reading of all 129 heroes, in groups made by script with coverage checked, found two more (Gwyneth, Shakir). Their causes and the fixes now in the tools and the checklist are in §8.1. Still open: Mikola's awakening 2 (AOE, eryndor) waits for its release, and Lamentis's ultimate stays Single Target, since its cut reaches every enemy only with five or more apostles. Ruled last, the same day: heal blocks are not debuffs, Vitality and Healing cuts are (with eryndor), and a healing rule on an enemy's buff counts unless it also protects the holder (§7). No hero has such a rule today, so it changed no tag.
• Haste: done 2026-10-23. A new filter (user, 2026-10-23): Haste a skill gives another hero, with Opening, Global, AOE and Single Target as for Temp Buff. tools/haste_targets.py sweep (the Debuff sweep's reader with the test turned around) listed the candidates, every site was read, and the user ruled on lasting Haste, summons and Laios's random pick (§7). The audit page has a section per modifier. Haste itself isn't derived yet: its rule is mechanical enough for tools/filter_derive.py, but each new site needs its reach read anyway, and the sweep's coverage line flags it at every audit.
• Temp Buff targeting on the audit page. Global, AOE and Single Target have no section on the audit page and aren't in the code check: research/tempbuff_targets.py check is the check, and its rows are hand-reviewed. A skill row's area and target priority could sort many of them mechanically; the script-chosen ones (stored partners, sorts, triggers) need reading.
• Synergy modifiers for Temp Buff and DoT (2026-10-11). The four modifiers follow their base tag with the exceptions in §7, so they have no section on the audit page and aren't in the code check yet: research/synergy_check.py tags is the check until they are. Open: whether the charm gem_ep8buffboost keeps its Temp Buff tag on stargazer. By the heroes' test its Haste isn't a temp buff (99999 timer); the charm reads temp buffs the way the three heroes do (§5.2).
• Unreleased heroes. Baden (unit 140; his ult blocks healing and energy gain) is in the game data without a stargazer page; his skill text is still a placeholder ("在神秘力量的影响下…"). Released heroes can have unreleased levels too: the Awakening Lv2 of Harak, Ulmus, Sinbad and Mikola is hidden (IsShow false), and the tools hold any tag on it until stargazer shows the level (§8).
• Feed facts. If stargazer should read mechanics from the feed rather than hand-kept tags, add per-hero facts with a gate that notices when the code's shape changes. This needs the user's decision.
• Unconfirmed passives. 265 of the 1,102 buffs buffs.json files under a hero by name are not named by that hero's script settings. The call index can show what applies them.
• Other platforms. The process guard is macOS-only (Architecture §2).