ark-stronghold-protocol/docs/history/0.2.1.md

DESIGN §26 — 0.2.1

Part of DESIGN.md (the index; section numbers are global).

26. 0.2.1 — after the 0.2.0 release

0.2.1 is built on feedback6, branched from the 0.2.0 release (tag v0.2.0) and marked 0.2.1-dev until it shipped (2026-10-07). Its workstreams branch off it as fb6-*, each merged after review with its golden scenarios named. Each rule was checked against the official data and PRTS; anything no source backs is marked ASSUMED. Where each is handled: the 突袭 landing on a teammate's half of a shared field → §26.1; 联防 back on the round's battlefield → §26.2; the 自选 picks in the bond lists → §26.3; a consumable on a full carrier → §26.4; the 外勤医疗 Touch → §26.5; 凋亡 and stored charges → §26.6; 贾维's 拉普兰德 → §26.7; .gitignore → §26.8; enemy flyers over raised tiles → §26.9; enemy animation states → §26.10; battle messages while the browser prepares a battle → §26.11; the 频次 器物 and leader summons → §26.12; the bond strip's collapse arrow → §26.13; every operator at full potential → §26.14; Esc in the 自选 picker → §26.15.

Decisions of the owner: 2026-10-07 — a 突袭 member may land on a teammate's half when both halves of the field are taken (the two-helper 联防 field, the Final Assault / Hidden Core pair field), replacing part of §25.18.1; 乌尔比安's S3 【移动】 keeps his own board (§26.1); 联防 plays on the round's battlefield again, from the owner's knowledge of the official mode and a tournament video (§26.2, withdrawing §25.6.4); 0.2.1 within hours of the report; every operator at full potential, no host setting (§26.14); the 自持有 bonus, multi-language voices and the title particles are not in 0.2.1.

26.1 突袭 may land on a teammate's half when both halves are taken (the owner's decision of 2026-10-07) — sim/battle/players.js onFieldBoard, content/bonds/addon/battle.js raidTile

• Seen: 0.2.0 (§25.18.1) let a member land only on its own board, on every field. Where both halves belong to players — the two-helper 联防 field and a Final Assault / Hidden Core pair field — a member whose target stood on the teammate's half stayed home or took a farther tile of its own half (reproduced: the right player's member with an enemy on the left telin (1,3) of 战场#01 stayed home; on the two-helper 联防 map the left helper's member with an enemy at (10,15) stayed home). After the release the owner decided that such a member may land on the teammate's half.
• Official: the bond text 「保留技力立即再部署至一名地面敌人周围」 names no board, and where the official landing falls among the legal tiles is not in the data (§22.2). PRTS 卫戍协议/帮助 §联防阶段: with two helpers 「两处阵地将前后拼接为一处 阵地，玩家在同一阵地作战」; a pair field is one boss map holding both players' boards (research 09 §1.2, ConvertChessPositionInfoToBossMap). A lone helper's other half and a solo boss field's other half hold no player.
• Now: Battle.onFieldBoard(r, c) — the tile lies on the board of a player of this field (onOwnBoard of any of players, the players whose units the battle holds; the 联防 right-hand helper's +8 columns and the mirrored right half of a pair are mapped as before) — and raidTile takes only those tiles: both halves on the two-helper 联防 field and on a pair field; the own half for a lone 联防 helper (escaped_single) and on a solo boss field (nobody stands on the other half; a teammate eliminated before the battle or playing another field opens nothing); never a boss field's hand row 0 or 临时整备区 row 1 (no board covers them). Every other landing rule is kept: ground / ranged tiles (grid.canStand), free tiles (isReservedTile), a blockable tile first for a melee member (§25.11.3), a target only reachable from a forbidden tile skipped (the next candidate is tried, else the member stays); the candidates are still the player's own enemies first (raidTargets). 乌尔比安's S3 【移动】 keeps onOwnBoard (§25.17.2, a separate community report): his landing never takes the teammate's half. This replaces the own-half rule of §25.18.1 on those two fields.
• ASSUMED: none beyond §22.2's landing rule (which legal tile the official landing takes); with both halves open the nearest covering tile wins, on whichever half it lies.
• Golden: 8 scenarios, each parting from the parent at the first landing on a teammate's half (checked tick by tick with the parent instrumented: identical up to that landing): boss-boss_2 / 3 / 4 / 5 / 6-pair, hidden-boss_8 / 10-pair (the right player's 缄默德克萨斯, 伊内丝, 仇白 or 耀骑士临光 landing on the left player's half, 1–7 times per battle, the first 0.3–39.8 s in) and the bot match coop4-ABYSS-7 (its round-6 two-helper 联防: at 52 s ai_2's 斯卡蒂 lands on ai_1's half; of the match digest only the two players' damage totals move, 8263 from ai_1 to ai_2). unite-2 is unchanged (its two landings stay on their own half). Tests: test/sim/feedback5-raid-own-board.test.js (4 cases; the pair and the two-helper cases fail on the parent; the solo boss field's hand rows, the lone helper and 乌尔比安 beside a teammate are unchanged). Docs: docs/SIM.md (onFieldBoard; onOwnBoard is now 乌尔比安's only).

26.2 「联防阶段地形全消失了」 (GitHub #244, reported by alien-zzy, official footage pointed out by RushFTK): 联防 plays on the round's battlefield again — §25.6.4 withdrawn — match/unitePhase.js _uniteOpts, unite.js, screens/game.js, public/dev/game-mock.js, tools/golden.mjs

• Seen: from 0.2.0 on, every 联防 was an empty two-part road — no walls, fences, water, crates, 活性源石, blowers or band medic. Walkers went straight down row 9 where the round's battlefield walls them off (战场#01 cols 5–7), and the helpers' 机变 terrain cards and the stage's devices did nothing there. In 0.1.x the 联防 was fought on the round's map.
• Official: the owner's first-hand knowledge of the official mode — 「官服保留地形，改回去」 (2026-10-07) — matching the tournament footage RushFTK linked in #244 (舟戍杯#2: a 联防 on the round's map). Why the level files misled us: act2autochess constData escapedBattleTemplateMapSinglePlayer / MultiPlayer name level_act1autochess_escaped_single / _multi, and §25.6.4 read that level's map as the 联防 map. But that map is the placeholder grid every wave template level carries: the 39 template levels of the season (the round templates 01…07 and h01…h08 with their _s solo variants, the training tr01/02/04, both escaped levels) hold the identical 19 × 21 road grid, tile for tile, while only the 11 stage levels (m01…m07, act2 m01…m04) have terrain and devices. Nobody plays a normal round on its template's road: a template gives a battle its waves, routes and BGM (the 联防 BGM, PR #110, stays), the stage gives the map.
• Now: _uniteOpts fields the 联防 battle on this.stageId in both combat modes, as 0.1.4 did: the match stage opened to both halves (GEO.UNITE_RECT, cols 0–20) with its terrain, crates, water, devices, runes and band map characters; the escaped templates' routes (one helper: escaped_single from the middle gate (9,10); two: escaped_multi from col 18 through (9,10)); each helper's pieces on their prep tiles, the first of two shifted 8 columns onto the right half. unite.js uniteStageId is removed. The client draws the 联防 on the board's stage again (screens/game.js: 0.1.4's ownView ? ownStage : baseStage — no map switch, nothing to restore on leaving; the helpers see their own 机变 terrain changes, as in 0.1.4); the dev mock's 联防 likewise. Kept from 0.2.0: 突袭 and 乌尔比安's S3 land only on their own board (Battle.onOwnBoard; the raidTile change of another stream is independent of this one), the payee of a bounty death no operator caused (the helper of that half — 战场#04's 活性源石 burns leaked bounty enemies in 联防 again, §25.14.3), the 联防 BGM, the official result box at SETTLE, and everything else since 0.1.4. data/stages.json keeps the two kind: 'unite' records, which no field uses: they are the official level data, the build checks them against config.unite.templates, and the engine tests of the own-board rules use them as a plain two-halves road (乌尔比安 S3, 突袭 landing, the CB4 pins); dropping them changes no game behaviour and would rewrite those tests (one of them belongs to the raidTile stream). tools/build-data.mjs: comments only — node tools/build-data.mjs --offline reproduces all 15 data/*.json files byte for byte.
• Checked against 0.1.4: the 联防 battle input a match builds — stage id, rect, wave id, routes, spawns, helpers' offsets, units and carried state, and the battle made from it (rows, ground / crate grid, device units, special terrain, runes, map characters, ally tiles) — is byte-identical to v0.1.4's in 20 cases (战场#01, #04, #05(下半), #07(下半), #08(下半) × 1 / 2 helpers × both combat modes).
• GitHub #41 item 3 (an enemy pushed back across the spawn onto the other half): back exactly as in 0.1.4 — 野鬃 S2 beside the middle gate pushes 3–4 of escaped_single's 20 walkers onto the right half (x ≤ 13.2), none off the map, the same numbers on v0.1.4; they walk back through the left half and leak or die. The reporter accepted it 「不影响正常 运行就可以了」. The 0.2.0 road showed the same push (its right half is road too): §25.6.4 never removed it.
• ASSUMED: none new (the official 联防 field is the owner's knowledge, not a data reading).
• Golden: fields unite-1 (escaped_single → 战场#02, act1autochess_m02) and unite-2 (escaped_multi → 战场#07(上半), act1autochess_m07) — the stages they had in 0.1.4; the matches whose 联防 rounds came out differently on the round's map: coop2-NORMAL-3, coop2-HARD-4, coop3-ABYSS-5, coop4-ABYSS-7, coop2-NORMAL-8-serverrun, coop2-NORMAL-14-standins (now a victory: walls and crates send the leaked walkers round through the helpers' range). coop4-FUNNY-6, coop2-ABYSS-10-boosted and coop2-NORMAL-70-diy play 联防 rounds too, with the same digests on both fields. roster, bonds, standins, diy unchanged.
• Tests: test/match/feedback5-unite-map.test.js rewritten — 6 tests: one / two helpers × both combat modes (the match stage, its rows and walls, 战场#01's six crates on both halves, the helpers on their 围墙 prep tiles with the +8 columns, walkers going round the walls, the stage the leaker's spec / a watcher's m.field names), 战场#04's 活性源石 on the field, and the same field with or without the escaped records — all 6 fail on the parent, and with soft asserts every new assertion does. test/e2e/coop.e2e.mjs: the 联防 round's field meta and drawn stage are the match stage. test/data.test.js (the records' test retitled: never the 联防 field). Docs: DATA §12, META §4, PLAYING §5, design/geometry-time.md, I18N, the §25.6.4 pointer.

26.3 The 自选 picks in the bond popup's member list (the owner's report of 2026-10-07) — ui/gameLogic/bonds.js bondMembers, ui/bondStrip.js BondPopup, ui/detailPanel.js resolveDetail

• Seen: the owner's report of 2026-10-07 「自选编队的干员在局内对应盟约展开的名单里没有显示出来」. Reproduced with a unit test of bondMembers (m.private.diy holding 推进之王 and 煌) and the popup in headless Chrome: the popup listed every regular member — dimmed while not owned — but a 自选 pick only once a copy was owned (on the board, in the hand or the 临时整备区), so a pick not bought yet, or not offered yet (the tier-5 slots from 调度中心 level 5, the tier-6 from 6), never appeared. Owned pieces did show in every case checked (board, hand, 临时整备区; normal and elite; 煌 in both 炎 and 维多利亚; beside a 补位 stand-in of the same bond), with two smaller faults: an elite on the board drew its row with the elite record (gold frame and golden avatar, unlike a member row, which always draws the base chess), and in a watched teammate's popup a tap on their 自选 row opened the empty 甄选干员 slot's card (resolveDetail read no pick for another player's member card).
• Official: neither the excel nor PRTS describes the popup's 自选 rows (PRTS 卫戍协议：盟约 only notes 「禁用盟约有可能 影响自选的支援干员」). The rule follows the owner's report: a 自选 pick belongs to the bonds of its operator like any member.
• Now: bondMembers adds each pick of m.private.diy (the V and VI slots) to every bond its operator carries (the composed record through the own getter, gameLogic/diy.js diyGetter): owned: false until a copy is on the board, in the hand or in the 临时整备区 (then on board / in hand as before), banned when its slot is in m.private.diyBanned (every bond of the operator off this match: it never shows in the shop). One row per slot, drawn as its normal form, with the operator's name and portrait and the 「自选」 tag; a banned pick's tag sits on the portrait's bottom corner, clear of the ✕ and the tier chip. The order rule is kept (on board, owned, tier, id: an unbought tier-5 pick comes after the unowned tier-5 members). The 成员 header (memberHeadCount: the board, plus the hand for a bond that counts it) and 在场 (the server's count) mean what they did — an unowned pick counts for nothing; the header's total includes the picks, as it includes the unowned members. A tap opens the operator's card (the own pick, from m.private.diy). A watched teammate: m.public sends no picks, so their popup still lists only their 自选 pieces on the field on screen (UnitInfo diy, ui/watchBonds.js ownerBoard, as in 0.2.0); such a row now passes the unit's pick on (BondPopup onMember's fourth argument → the detail target's diy → resolveDetail composes their operator). The briefing and the 本局信息 bond lists show no members (bond discs, banned-member counts, the 本局禁用干员 grid and the diyBanned line), so nothing changes there.
• ASSUMED: how an unbought pick looks (dimmed, like an unowned member), how a pick whose bonds are all off looks (the banned member's ✕), and the normal-form portrait for an elite copy (one row per member).
• Golden: unchanged (client only). Tests: test/ui/feedback6-diy-bond-members.test.js (5 cases, each failing on the parent: the unowned pick listed and dimmed, header 0 / n + 2, its card; owned → on through the hand, the 临时整备区, the board and the elite, one normal-form row; 煌 in 炎 and 维多利亚 beside 风笛's stand-in; the diyBanned pick; the teammate's row opening their 煌, not the slot); test/ui/watch-bonds.test.js (the game screen's onMember wiring, now with the pick).

Optional PLAYING.md sentence for the integrator (the 自选编队 paragraph, after 「和普通棋子一样计入盟约人数」 — not edited here to avoid a conflict on that one-line paragraph): 盟约详情的「成员」一栏也列出你的自选干员（带「自选」标记；还没买到、商店 里还刷不出来时和没有的成员一样显示为灰色）。

26.4 A consume-on-equip item on a full carrier replaces first (GitHub #263, PR #264) — match/player/items.js equip / _takeReplaced, ui/gameLogic/placement.js equipReplaces, match/bot.js itemTarget

• Seen: with both equipment slots of an operator used, a normal 博士投影 dropped on it opened no replace dialog and silently destroyed the OLDEST equipped item: the client's itemAttaches treated every consume_on_equip* item as slot-free (dropIntent → confirmReplace: false), and the server ran the effect, whose ev.keep re-attached the item through _attach(holder, item) with no replaceUid — the full row pushed out index 0 (a replaceUid sent anyway was ignored). 盟约之币 and the other immediate consumables (随身身份牌, 紧急调度券, 精打细算玩偶, 简易通讯机, 见钱眼开玩偶, 骑士储蓄罐, 寻呼模块, 信标, 拟态物质, 人事部文档, the golden 博士投影) opened no dialog either and kept both equipped items (reproduced on feedback6 783bd30: scratchpad/w6-r21d-notes/repro.mjs; reported by @SpiritedAwayCN with PR #264).
• Official: PRTS 卫戍协议/帮助 §装备 (fetched 2026-10-07): 「每名干员最多可佩戴2件装备」, 「达到上限强行佩戴会改为替换装备： 指定一件已佩戴装备替换为将要佩戴的装备，并销毁被指定的装备（可取消以中断替换操作）」 — no exception for the items the data marks 装备时销毁; research 04's "never take a slot" is a [DATA] reading of kind, not a waiver of the dialog. The reporter's first-hand account of the official mode: the picked item is destroyed first, then the item resolves, and the operator is left with a free slot.
• Now: server — PlayerState.equip's consume path takes the item replaceUid names (else the oldest, as for every third item) off a full carrier before onEquip runs (_takeReplaced), so the effect sees the carrier without it (its bonds: 随身身份牌 / 简易通讯机 / 寻呼模块 / 拟态物质); once the effect went through the item is destroyed (onDestroy reason replace) and the slot stays free — the normal 博士投影 takes it (ev.keep) and no longer pushes another item out. A refusal (博士投影 of either quality on an elite: BAD_TARGET 'already elite') puts the item back at its index: nothing is destroyed, the 博士投影 stays in the hand. 信标 destroys its carrier as before: the remaining item returns to the hand, the picked one is gone. Client — equipReplaces(ctx, uid, target) (gameLogic) opens the replace dialog for every item on a full carrier, a consumable too, except where nothing would be replaced: an attaching item that completes an item merge (equipMerges; the server's consume path never merges) and a 博士投影 (its promoting effect keys) on an elite. itemAttaches is gone. Bots — a consumable whose effect is the same on anyone (funds, 紧急调度券, 人事部文档 …) goes to a carrier with a free slot first (itemTarget, PR #264); the targeted ones (博士投影, 随身身份牌, 简易通讯机, 寻呼模块, 拟态物质, 信标) keep their carrier and, when it is full, replace its oldest item (bots send no replaceUid).
• ASSUMED: the order inside the server is "take off → effect → destroy" rather than "destroy → effect": the effect sees the carrier without the item (as officially), but the replaced item's onDestroy runs after the effect so a refusal can restore it — no equipment item has an onDestroy effect for replace, so nothing observable differs.
• Golden: matches only, 10 of 18 move — in each the first point it parts from the parent is a bot's (or the AI 托管 human seat's) targeted consumable resolving on a full carrier, which now destroys the carrier's oldest item (traced equip by equip against the parent: scratchpad/w6-r21d-notes/trace-equips.mjs): solo-FUNNY-1 (r9 ai_0 随身身份牌 → 突袭手雷 destroyed; bossPoolLeft 88535 → 91555), solo-FUNNY-2 (r9 ai_0 寻呼模块; bossPoolLeft 87617 → 107027), solo-HARD-2 (r9 ai_0 随身身份牌, r12 简易通讯机; teamLp 17 → 13), coop2-NORMAL-3 (r9 ai_1 随身身份牌; teamLp 46 → 39), coop3-ABYSS-5 (r11 ai_1 随身身份牌; ai_1's numbers only), coop4-FUNNY-6 (r4 ai_1 随身身份牌), solo-HARD-9-boosted (r14 ai_0 随身身份牌), coop2-ABYSS-10-boosted (r13 ai_0 随身身份牌, r14 ai_1 简易通讯机; teamLp 398 → 529), coop2-NORMAL-14-standins (r9 ai_0 随身身份牌; the match now won: 13 → 14 rounds, teamLp 0 → 12), coop2-NORMAL-70-diy (r14 h_0 随身身份牌; numbers only). The bots' free-slot choice for target-agnostic consumables moves no scenario by itself (six unmoved matches carry such a changed carrier: the effect is the same on anyone).
• Tests: test/match/merge.test.js (a full carrier with the picked item: normal 博士投影 takes the pick's slot, 盟约之币 pays and leaves a free slot, 随身身份牌 gives the carrier's bonds +3, the golden 博士投影 promotes and the other item stays; 博士投影 of both qualities on an elite is refused with every pick and both items kept), test/ui/leftovers.test.js (all 24 consumables open the dialog on a full operator and not on a free one, 博士投影 on an elite does not, an operator in the hand the same; the real engine end to end: the dialog asks for 博士投影 and 盟约之币 and the picked item is the one destroyed), test/ui/gameLogic.test.js (the consumable intent flipped), test/match/bot-smarter.test.js (盟约之币 to a carrier with a free slot) — each new assertion fails on the parent; the dialog e2e test/ui/leftovers.e2e.test.js.

26.5 The 外勤医疗 Touch casts on its 5-2, and the map characters' card is an operator card (GitHub #260, PR #278) — content/tokens.js touchKit, ui/detailPanel.js MapCharDetail / SKILL_TEXT_NOTES / skillTags

• Seen (reported by @CurlyZhu on 0.1.4; PR #278 by @IceCodeNew): the 外勤医疗 strategy's Touch and 预备干员-医疗 showed as 「召唤物」 with base stats only — no skill, no talents. Touch waited for an injured ally inside her own 3-3 before casting 恳切福音 although the skill heals on its 5-2, so a 雷蛇 losing HP to 源石溶剂 five tiles ahead was never healed. Cause: tools/build-data.mjs builds the map characters as tokens (kind mapChar, variants: {}; stats, skill, talents and 特性 on the record) and resolveTrigger widens operators' skills only, so their records keep DEFAULT; TokenDetail read skill and talents from an owner variant only (none) and always printed 召唤物.
• Official: PRTS Touch(卫戍协议) — an operator of the mode (医疗 · 医师, 远程位), talents 攫升 / 超脱, S3 恳切福音 手动 触发, 技能范围 5-2, 「攻击距离+2」 corrected by PRTS to 攻击范围扩大, 「不高于一半」 corrected to 低于 (原因 6); aceffect_band_61: a 预备干员-医疗 appears, replaced by Touch with two elites on the field. The larger-range cast is the owner's rule of 2026-10-05 (§25.5), which the Touch 补位 already runs by its data (backups.json S3 ACTIVE_RANGE on the 5-2).
• Now: touchKit sets the skill's trigger to ACTIVE_RANGE on the skill's own range (the running range, which strictly contains her 3-3): an injured, healable ally inside it casts; a full-HP or 禁疗 one does not (the reserve medic's 治疗强化·β型 has no range of its own and stays DEFAULT). The card (MapCharDetail, taken for kind: 'mapChar'): chip 干员, the class line (医疗 icon, 远程位), the 特性, the four stats (live in battle), the skill row of the operator card (icon, SP type, trigger, initial · cost, duration — skillTags, shared with ChessDetail) with its text, and the talents — all from the record, translated by the data overlays. Checked against the kit: 恳切福音's stored sentence matches what the sim does (ATK +40 %, ×150 %, 2 targets, the 30 % extra heal; the 5-2 = her 3-3 two tiles longer) except 「不高于一半」 — touchGospel boosts strictly below half (PRTS 修正) — so the card keeps the official sentence and adds a line under it (SKILL_TEXT_NOTES, by skill id; on the Touch 补位's S3 card too, whose text reads the same). The triage's "+40 %" doubt does not hold: bb.atk of the map character's Lv10 skill is 0.4, which the kit applies. Enemy targeting is unchanged (the units stay kind: 'token' in the sim; no enemy that skips them was named).
• ASSUMED: none new (the trigger is the standing owner rule).
• Golden: roster-041 (its strategy Touch: heal 8438 → 17072, heal actions 19 → 27, casts 2 — the same numbers as PR #278; p1 deaths 7 → 4) and matches coop2-NORMAL-14-standins (h_0 plays 外勤医疗: defeat in round 13 → victory, team LP 16) — the two battles with that strategy's Touch; nothing else moved.
• Tests: test/content/tokens_devices.test.js (Touch on her stage slot, an ally only in the 5-2: no cast at full HP, none while 禁疗, then a cast and a heal — fails on the parent), test/ui/playtest6_summons.test.js (both cards: 干员, 医疗, skill / talents / 特性 text, the 低于 line only under 恳切福音, a summon keeps 召唤物 — fails on the parent). i18n: one new string in en / ja / ko / zh-TW. Docs: docs/SIM.md (ACTIVE_RANGE also set by touchKit).

26.6 An operator's 凋亡 drains the stored charges too (PR #262; #261 its closed duplicate, both by @siruimei07) — sim/damage.js resolveBurst (apoptosis, ally side)

• Seen: the burst's −1 SP/s took only sk.sp, the SP towards the next charge. A full skill keeps sp = cost with every charge stored, so it kept all of them; a one-charge skill stayed ready through the whole 15 s (and cast the moment 静默 ended). Reproduced with 精锐 雪猎 (S2 可充能2次, 14 SP): two charges stored before the burst, two after it.
• Official: PRTS 元素 — 凋亡损伤 on a 我方单位: 「立即获得等时长的阻回、静默，该阻回、静默持续期间每秒损失1点技力并受到100点无来源 法术持续伤害」 (15 s); PRTS 技能 §特殊属性 可充能: 「当前技力上限等于该技能技力需求的X倍」 and 「当持有者的技力流失时，充能次数也 会实时降低（但因达到上限产生的额外效果会依然生效）」.
• Now: each second sk.setSpTotal(max(0, spTotal − 1)) — the official 技力 (charges × cost + the partial bar), charges rebuilt silently (no spGain hook, 阻回 untouched); a passive, a skill-less unit, a free skill (spTotal 0) and a running duration / ammo / toggle skill are left alone as before (setSpTotal refuses those too). An effect a full charge produced is not undone (none is modelled on this path).
• Golden: 5 moved, each by a burst on an operator with SP stored — 假想敌：管's 凋亡 strikes and the 萨卡兹王庭军's 凋亡 on hit: fields hidden-boss_10-solo (泥岩 loses its stored charge, casts 1 → 0 — the move PR #262 reported; team heals 73194 → 72505), boss-boss_3-solo, hidden-boss_10-pair and diy-058 (later snapshots and event counts only, same results), diy-059 (黍 forms: casts 11 → 5, 6 → 2, 9 → 5, 6 → 1; kills 39 → 47, leaks 57 → 49).
• Tests: test/content/feedback6-apoptosis-sp.test.js (2: 雪猎's two charges → one after 1 s, none after 15 s; a full one-charge skill not ready after 1 s, −15 技力 in all, no spGain, a running timed skill unchanged — both fail on the parent); test/sim/combat.test.js operator bursts unchanged. Docs: docs/SIM.md element table.

26.7 A 拉普兰德 贾维 grants during a refresh waits for the next one (PR #196 by @SpiritedAwayCN, the part 0.2.0 lacks) — match/effectsMeta.js dispatch / _garrisons / refreshPieces

• Seen: 贾维 【团伙行动】 grants a 叙拉古 operator from the dispatch of every 6th manual refresh (band step 2), before the garrisons (step 4), which walked the board and hand live — so a 拉普兰德 granted (or the elite her copy completes) ran her 刷新时 特质 in the refresh that granted her and spent her 「本回合首次主动刷新」 on it (+4 / +8 at once, nothing on the next refresh).
• Official: garrison_123 「<刷新时>若为本回合首次主动刷新…此干员在整备区时也有效」; the players' reading (§21.1, after 0.1.0) 「获得该干员后该回合的首次刷新」 — a refresh she was gained in is not one she was there for. 贾维: 「主动刷新6次调度中 心后获得一名…<叙拉古>干员」.
• Now: dispatch takes the board (reading order) and hand chess before the first handler of an onRefresh; the garrison step runs each of them that is still on the board or in the hand, where it stands now; a chess gained during the dispatch does not run, nor one that left (sold, consumed by a merge, sent to the 临时整备区). Other hooks keep the live walk. Not taken from PR #196: copying round counters on a merge and keying the counter by garrison id — 0.2.0 counts a merged elite as a new 拉普兰德 and keeps an in-place promotion's count (the owner's decision, §25.13.3).
• ASSUMED: none new.
• Golden: unchanged.
• Tests: test/match/feedback1-meta.test.js (2: a gifted copy and a gift that completes the elite — nothing in the 6th refresh, +4 / +8 in the 7th, nothing in the 8th; both fail on the parent). Docs: docs/META.md (SERVER_REFRESH_SHOP row), the effectsMeta.js header, garrisons/meta.js.

26.8 .gitignore lists .npm-cache/ (GitHub #258, reported by @qfmc7040) — .gitignore

• Now: a local npm cache (npm_config_cache=./.npm-cache, npm ci --cache .npm-cache) is ignored like node_modules/ and .cache/; the packages ship tracked files only, so it stays out of them too. Golden: unchanged. Test: test/gitignore.test.js (the entry, and git's own check-ignore; fails on the parent).

26.9 An enemy flyer hovers from the road whatever tile it crosses (GitHub #277 by @FrogThai) — render/units.js UnitView.sync / shadowZ

• Seen (GitHub #277, 飞机经过一格方块时会跟走楼梯一样，有高低差): a flying enemy whose route crosses one high-ground or forbidden block rose onto it and dropped back, like a step. Cause: UnitView.sync put every unit except a ground enemy on the tile top under it (groundZ: TILE_H.wall 0.42, forbid 0.3) and added FLY_HOVER on top, so an enemy flyer followed the tiles (reproduced headless, w6-r21f-notes/flyer-277.mjs: 妖怪 along row 9 of act2autochess_m01 over the '#' at col 6 — body height 1.293 … 1.600 tiles on both boards before, 1.293 … 1.300 after).
• Official (docs/research/12, §25.13.5): the fly offset is one constant, Vector3(0, 0.35, 0) added while flying, ≈ 1.3 tiles over the route; nothing per tile. High ground is where units stand, not a step under a flyer.
• Now: every enemy keeps z 0 (ground enemies already did; a flyer hovers FLY_HOVER above the road); operators and summons keep their tile top (an operator on high ground stands on it). The flyer's shadow lies on the tile under it (shadowZ, eased like the body), so over a block it is drawn on the block top. The 2D and the 3D board share the camera and the Pixi unit layer, so both are fixed.
• ASSUMED: the shadow on the block top under a flyer (no official reference for a shadow over a block).
• Golden: unchanged (client only). Tests: test/render/unitview.test.js an enemy flyer crossing a raised tile keeps its height (GitHub #277) (2 cases; the body-height case fails on the parent: it rose 0.415 tiles). Headless screenshots before / after, 2D and 3D: w6-r21f-notes/{before,after}-{2d,3d}-{before,over,past}.png. Docs: ASSETS (flying units), design/client.md, research 12 §6.

26.10 Enemy animation states: per-slot skill clips, two stun spellings, the Run cycle, two 重生 (PR #275 by @xcdoge, client part) — tools/assets/anim-roles.mjs, tools/assets/spine.mjs, render/spine.js _applyRoles, render/units.js setSkillSlot / moveFast / FORMS, render/app.js 'cast'

• Seen (PR #275, a scan of every enemy skeleton against its manifest roles): (1) an enemy's manifest only had skill index 0 (tools/assets/plan.mjs passes [0]), so a multi-skill boss could show one cast clip — 盐风主教昆图斯 has Skill_01..04; (2) the stun resolver knew Stun / Stun_Begin / Stun_End only, so 巨大的丑东西 (Stun_1 / Stun_2) and 斩胄之剑 / 破胄之锤 (Dizzy_*) had stun: null and froze their clip; (3) 猎狗pro walked on Move_Loop (0.80 s) though its skeleton has Run_Loop (0.53 s) and it is fast (moveSpeed 1.9, 行动速度很快); (4) 巨大的丑东西 and 自在 have a Revive clip and a 重生 in the sim but no FORMS entry, so their 重生 played nothing.
• Official: clip names and lengths are the skeletons' own (data/assets.json animations): 巨大的丑东西 Revive 8.67 s for its 10 s reborn.duration (its self-destruct 2.17 s in), 自在 Revive_01 5.33 s for 5 s. The sim reports a 重生 as a stun (archetypes.js reborn: flags.stun), so the 重生 form must say what the rest of it holds.
• Now: the resolver resolves every numbered skill clip of an enemy after the caller's indices (numberedSkills, passed by spine.mjs for enemy models; the first index stays the primary skill; operators keep the pool's indices, 宴's PREFAB_SPINE_ROLES fix of §25.22.9 unchanged); the stun loop is Stun → Stun_1 → Dizzy_Loop (with *_Begin / *_End); a model's own Run cycle is a separate run role. The renderer: SpineActor._applyRoles composes the skill slot's clip, the Run cycle and the form in force (a slot change keeps a form; a form ending keeps the slot); a UnitView of an enemy faster than moveSpeed 1 moves on run (猎狗pro 1.9, 深池侦察犬 / pro 1.7; 宿主士兵 0.9 and 鸭爵 0.4 keep Move); UnitView.setSkillSlot (render/app.js case 'cast') swaps an enemy's skill clip. FORMS: 巨大的丑东西 reborn = Revive as the change clip, then the 大祭司's Idle_2 held (also as the 重生's stun) → form2 Idle_2 / Move_2 / Die / Stun_2, no attack (不进行攻击); 自在 reborn = Revive_01 → form2 its own clips. data/assets.json regenerated with node tools/fetch-assets.mjs --offline: 18 enemies gain anims.skills, 6 anims.run, 3 a stun clip instead of null (巨大的丑东西, 斩胄之剑, 破胄之锤 — the two 胄 parts are stun-immune, so only 巨大的丑东西's is ever seen); no operator or token entry changed (w6-r21f-notes/manifest-diff.txt).
• Not ported: the sim side of (1) — content/enemies.js castSkillSlot emitting ['cast', id, slot] when an ability casts, 昆图斯's ability ids, UnitInfo.skillIndex for enemies — adds an event, so golden's event counts move (+cast in the two 昆图斯 fields); it is left for the owner (patch: w6-r21f-notes/sim-cast-slot.patch, not applied). Until then the per-slot clips are unused and every boss keeps its primary clip. Note: 昆图斯 has 10 data skills (Tidewater … Doom) and 4 clips, so mapping the G1 / G2 / Doom slots to Skill_04 or the primary needs a check first. The PR's research note (docs/research/13-animation-states.md) is not ported.
• ASSUMED: the Run threshold (moveSpeed > 1; the client's own trigger is unknown) — only a model with a Run cycle changes; 巨大的丑东西's _1 / _2 clips as its first form / the 大祭司 (the 大祭司 set has no attack clip, matching 不进行攻击); 自在's second form on its first-form clips.
• Golden: unchanged (client and asset tools only). Tests: test/assets.test.js (resolver: numbered enemy skills, Stun_N / Dizzy_*, run role; the manifest: every stun / Run clip has its role, every enemy with numbered skill clips has a clip per slot, 宴 unchanged — 6 cases, all fail on the parent), test/render/forms.test.js (the two 重生; every clip FORMS names exists in its manifest entry), test/render/loadout-skill.test.js (an enemy cast slot swaps the clip, a form kept), test/render/unitview.test.js (moveSpeed 1.9 on Run, 1 on Move, composing with the slot); RENDER_E2E=1 node --test --test-concurrency=1 test/render/models.browser.test.js 7/7. Docs: ASSETS (Roles: skills of an enemy, run, stun spellings).

26.11 A b.end, a second b.start, b.pool and the pause reach a battle the browser is still preparing (PR #266 by @siruimei07) — public/js/battle/runner.js (pending, prepare, onEnd / endBattle, onPool, setPaused, clear)

• Seen (PR #266; reproduced on feedback6 783bd30 by test/match/runner-pending.test.js — 11 of its 15 cases fail on the parent): the client runner added a b.start's battle to its map only after the sim module had loaded (ensureSim) and the new Battle had been caught up silently to the field clock (one animation frame per 600-tick slice), and everything else looked only at that map. Cause (runner.js at 783bd30): onEnd (line 688, entries.get) dropped a b.end that came during the load or the catch-up — after a takeover the browser went on reporting as the authority (the server ignores a non-authority's reports, server/match/match/reports.js), and a forced end (the Final Assault's cleared / forced) never ended the battle, so the server waited out its 6 s grace and filled the field with the stats-only stand-in; onStart (line 595) built a second Battle for a second b.start of the same battle during the catch-up; line 624 (seq !== startSeq) never built an authority that another field's b.start superseded during the load (the deadline then took the field over); lines 663–666 re-registered an authoritative battle whose catch-up the next prep's clear() had interrupted, and it went on running and reporting into the next round; setPaused (line 506) and onPool (line 680) skipped a battle in catch-up (the paused time was caught up; the boss pool waited for the next b.pool). No wrong settlement came of it: the server re-simulates or stands in.
• Official: not a game rule — the remake's own client / server protocol (§14); nothing to check in the game data.
• Now (§14 Client runner, b.end): a b.start is registered as pending the moment it arrives (pending, battle null until built; prepare() loads, builds, catches up and registers it), so what comes for that battle meanwhile is applied to it in arrival order: b.end takeover clears its authority; a forced / timeout b.end keeps the first end reason and ends the Battle as soon as it exists — before any catch-up, or at once mid-catch-up — and an authority reports it then; a second b.start of the same battle updates the same entry (authority, watch, the field clock while it is not built yet) and never builds a second Battle; b.pool syncs a built pending boss Battle (one not built yet takes the last pool when built, as before); the solo pause shifts a built pending battle's clock. A b.start of another field supersedes it: an authority, or a battle the server already ended, is still built and registered (a superseded authority catches up in the background with the bounded fast-forward, as before), a display replica is dropped. clear() (the next prep, the match over, leaving) drops the pending entries; their preparation finds itself gone at its next step and builds, steps, registers and reports nothing — a fresh b.start of the same battleId afterwards is a new preparation the old one cannot touch.
• ASSUMED A forced / timeout end that arrives before the Battle exists ends it where it stands (tick 0, or wherever the catch-up was) instead of catching up to the field clock first (as the PR does): the server sends those ends only when the Final Assault / Hidden Core ends, and after a forced end it credits no further report (§20.5), so catching up first would only cost time. A superseded display replica the server already ended is kept (registered, finished) so switching back shows it ended (as the PR does).
• Not taken from the PR: its cancelled guards on a result request already in flight when the round moves on (a timeout may still retry it once; the server ignores a stale battleId — not a lost control message) and its cancellable frame wait (the preparation notices a clear or an end at its next frame). Its docs/DESIGN.md paragraph became the §14 Client runner sentences (DESIGN.md is the index now).
• Golden: unchanged (client only). Tests: test/match/runner-pending.test.js (new, 15: a b.end takeover / forced / takeover-then-forced, a second b.start, the next prep and another field's b.start, each during the load and during the catch-up; a superseded replica, the pause and b.pool during the catch-up); the runner suites test/match/runner.test.js, clientCombat-review, feedback1-runner-forms, diy-shop, standin-ownership, watch-bonds, test/ui/playtest6-unite.test.js, test/ui/spectate-effects.test.js unchanged and green.

26.12 The round's enemy effects reach the 频次 器物 and the leaders' summons (PR #272, 感谢 @CXUtk) — content/enemies/archetypes.js times, content/bosses.js summonMods, config enemyScale[r].supplyHp

• Seen: a 器物 (the 14 hit-count keys: 瑞印, 卷轴, 铜镜, 镇纸, 茶器, 矛头, 灯盘 and their _2) needed the data's number of hits at every difficulty: spawnEnemy multiplied its max HP by the round's hpMul, then the 频次 archetype's setHits(e, e.def.maxHp) overwrote it with the raw count (reproduced: 青铜镜 30 hits in solo 标准 R1 — data × 0.75 — and in co-op 终极 R15 — data × 4.30 — alike, as a 悬赏 card and as 身观's death spawn). A leader's mid-fight summons — 死亡集群's 妖怪, 刺胄之弹, “裂管之音”/“断弦之音”, 不祥幻影 — spawned with no round mods at all (800 HP / 8 hits / 10 hits / 10000 HP at every difficulty). Reported by @CXUtk in PR #272.
• Official: activity_table act2autochess (data/effects.json): the round effects are ENEMY effects on 所有敌人 — 攻坚装备 / II / III enemy_attribute_mul (ATK ×1.1 / 0.8 / 0.7, HP ×1.2 / 0.8 / 0.75) and 急行军 (speed +15 %) with enemy_exclude = 炎佑 only; 补给线 / 补给线II (HP ×1.08 / ×1.2, no ATK) with enemy_exclude = 炎佑 + exactly the 14 器物 keys. The exclusion only makes sense if a max-HP multiplier changes a hit-count unit's count, so the 器物 take 攻坚装备's HP and not 补给线's. The per-round table (PRTS 卫戍协议：盟约/下半 §开始模拟, user-provided; research 01 A3): hp = hpBase · 1.2^kHp · extra, atk = atkBase · 1.1^kAtk; 攻坚装备 always brings ATK, so kAtk counts its stacks and the HP-only steps 1.2^(kHp − kAtk) are 补给线II, extra 1.08 is 补给线 — only co-op 终极 has them (R5–R15). PRTS: "领袖单位于 服务器的生命值加成不受上述加成影响" — only the leader's HP (the server pool) is exempt. 炎佑 is a bond ally in this remake (spawnYanyou), never an enemy (waves.js skips it in templates): its exclusion needed no change.
• Now: build-data writes enemyScale[r].supplyHp = 1.2^(kHp − kAtk) · extra when ≠ 1 (co-op 终极 R5 1.2, R6 1.08, R7 1.44, R8–R11 1.728, R12 2.0736, R13 1.86624, R14–R15 1.5552; only config.json changed in the rebuild, checked by a JSON compare); gamedata.baseEnemyScale returns it as supplyHpMul and the wave / 悬赏 mods carry it (waves.js roundMods). The 频次 archetype sets hits = the spawn's max HP (data × hpMul) ÷ supplyHpMul, rounded (setHits); a 频次 enemy's death spawn inherits the parent's mods, so 身观's 青铜镜 counts the same. A boss / hidden field gets the round's scale as the BattleSpec flag flags.enemyScale (bossRounds.js; golden fields and tools/balance.mjs likewise), and the leaders' summons spawn with it (summonMods): HP / ATK / speed, 死亡集群's summon.hp_ratio multiplied on top; 刺胄之弹 and 余音 set their hit count from that HP like the 器物 (they are in no exclusion list). 王权号令's equipment (invulnerable, untargetable, never fights) is left as it was. Examples: 青铜镜 solo 标准 23 hits, co-op 险境 R13 86, co-op 终极 R6 62 (1.2⁴, not 1.2⁴ × 1.08), R14 129; co-op 终极 R14 刺胄之弹 53 hits, 余音 67, 妖怪 5350 HP.
• What the PR did and we did not take: it back-calculated 补给线 from the composed hpMul (recognising only a 1.08 / 1.2 ratio against 1.2^kHp), which counts the 补给线II steps as 攻坚装备 (co-op 终极 R5 / R7–R12 器物 too many hits), and kept fractional HP (a ceiling); it also scaled the husk counts.
• ASSUMED: a fractional count rounds to the nearest whole hit (setHits' Math.round, kept; a ceiling — float HP — would differ for 3 × 0.75 and 35 × 0.75); the summons' hit counts follow their HP (inferred from the 器物 exclusion, not measured). Open: the 逐火 ember / 再生 傀儡 counts (talent Revive[Trigger].prop_max_hp) stay unscaled — whether the effect multiplies a talent-set max HP is not in the data.
• Golden: 74 scenarios. 器物 counts (every one holds a 器物 — extra spawn, 频次 wave or a 频次 enemy's death spawn): roster 37 (002 003 004 005 007–020 022 023 025 026 029–034 036–041 043 045 049), bond-soloShip-high, diy 9 (036 040 056 062 068 073 091 114 115), boss-boss_6-solo (俗心's 小说卷轴), matches 16 (all but solo-ABYSS-2 and coop2-NORMAL-70-diy: solo-FUNNY-1/2, solo-NORMAL-1/2, solo-HARD-1/2, solo-ABYSS-1, coop2-NORMAL-3, coop2-HARD-4, coop3-ABYSS-5, coop4-FUNNY-6, coop4-ABYSS-7, coop2-NORMAL-8-serverrun, solo-HARD-9-boosted, coop2-ABYSS-10-boosted, coop2-NORMAL-14-standins — 频次 rounds / 悬赏 and the Final Assault summons). Summons: boss-boss_1-pair/solo and hidden-boss_8-pair/solo (妖怪 + 刺胄之弹), boss-boss_3-pair/solo and hidden-boss_10-pair/solo (余音), boss-boss_5-pair/solo (不祥幻影). standins unchanged.
• Tests: enemies_bosses — the 14 per-key 频次 tests (hits × the round's HP, was "must not change"), the data pin (the 14 kitTimes keys = 补给线 / 补给线II enemy_exclude minus 炎佑; 攻坚装备 / II / III / 急行军 only 炎佑), hpMul ÷ supplyHpMul with a death spawn and the solo 标准 rounding, leader summons with / without flags.enemyScale; waves — supplyHpMul per co-op 终极 round (hp ÷ it = 1.2^kAtk), wave and 悬赏 mods; finalAssault — the boss fields carry flags.enemyScale.

26.13 The bond strip's collapse button is a bare arrow (the owner's request of 2026-10-07) — screens/game.js, public/css/screens/game.css .bonds-toggle

• Seen: the boxed 「收起」 / 「盟约」 tab in front of the bond discs looked heavy (0.1.4's fold button, PR #149, GitHub #142).
• Now: a bare chevron (‹ open, › folded), transparent, at 55 % opacity (80 % when folded), full opacity and mint on hover / keyboard focus; the 44 × 44 touch target stays as an invisible hit area and the name is the aria-label (展开盟约 / 收起盟约). Tests: test/ui/bond-collapse.e2e.test.js (SP_E2E, 2).

26.14 「当前全体干员为无潜能，与官方实现不符」 (GitHub #252 by SpiritedAwayCN, PR #255 by SpiritedAwayCN — a host slider, not taken): every operator fights at FULL potential (潜能 6) — the owner's decision of 2026-10-07 — tools/build-data.mjs OPERATOR_POTENTIAL / withPotential, data/chess.json / backups.json / tokens.json, data/i18n/*.json

• Seen: every operator fought at potential 1 (no potential): 刺玫 (tier 1, E1 Lv55) ATK 413 / cost 17 where the official panel reads 435 / 15; 砾's redeploy 18 s instead of 16, the gift 5★ (至简 …) 80 s instead of 70; every 「天赋效果增强」 step missing (刺玫's 土壤基肥改良 108 % instead of 111 %, …). The data build picked every candidate at potential rank 0 and added no potentialRanks attribute step.
• Official: the season's chess records (activity_table act2autochess charChessDataDict status: evolvePhase, charLevel, skillLevel, favorPoint 0, equipLevel) carry no potential field; a tournament video (bilibili BV1FTowB2EzP, 02:36, linked in #252) shows 刺玫 at ATK 435 / cost 15 — exactly her E1 Lv55 413 / 17 plus her potentials 攻击力+22 and two 部署费用-1. In the official game a player's own potential applies (RushFTK in #252: 0 信赖, potential from the account; an operator not owned — potential 1; the shop rows' backupCharPotRank is 0 except 宴 / 野鬃 1). The owner's decision of 2026-10-07: everyone at full potential, no host setting (PR #255's 1–6 slider is not taken). Summons: a token's own character has no potentialRanks, but its talent candidates carry requiredPotentialRank mirroring its owner's 「天赋效果增强」 (夕 潜能 5 → “小自在” 化境 15 → 18 层; 凯尔希 潜能 5 → Mon3tr 不毁重构 3.5 s / 1400 — PRTS 凯尔希 天赋 "潜能增强=5 … 晕眩3.5（+0.5）秒…1400（+200）点真实伤害", X 模组 3 级 4 s / 1700; 望 潜能 3 → 棋子 +1 持有 / 部署; 麦哲伦 → 龙腾 22 s; 鸿雪 → 打字机 −20 % / −25 % 5 s; 伺夜 → 狼群 200 DEF ignore; 风丸 → 纸偶 ×2.75; …). So a summon picks its candidates at its owner's potential and takes none of the owner's attribute steps (ATK / cost / redeploy belong to the owner entity).
• Now: OPERATOR_POTENTIAL = 5. Every chess (normal and elite), every 补位 / 自选 unit form (buildUnitForm) adds every potentialRanks attribute modifier to the interpolated attributes before rounding (withPotential: all ADDITION — COST, RESPAWN_TIME, ATK, MAX_HP, DEF, MAGIC_RESISTANCE, ATTACK_SPEED; another kind is reported, none exists) and picks talent / trait / module-talent candidates at rank 5 (bestCandidate(…, potRank)). Summons (tokenVariant, tokens.json and backups.json tokens, tokenTalentDeckBonus) pick theirs at the owner's rank; the band's map characters and stage devices stay at 0. The 17 原型干员 stand-ins (预备干员 char_600–607, char_608–615, 领主·Sharp) have no potential ranks: unchanged. Nothing else reads potential: no skill or trait candidate of the season's operators carries a requiredPotentialRank > 0, skill levels never depend on it. JSON compare (old vs new build): only potential-driven fields moved — chess.json 256 of 266 records (all but the four DIY slots and 盟约·辅助干员, which has no potential ranks; stats cost 256, respawnTime 200, atk 176, def 16, maxHp 14, res 12, aspd 6 — statsBase the same; 275 talents and 140 talentsBase entries, 27 module talent changes: bb + desc), backups.json (the 71 owned picks' three forms — none of the 17 stand-ins: cost, atk, respawnTime, hp / def / res / aspd, talents, module talent changes; 8 of 38 summons: Mon3tr, 龙腾.F / L / A, 打字机, 结构性原理 talents, 望's 棋子 deploy limit 6 → 7 / holding 7 → 8 / count 7, 多萝西's 共振装置 count 8 → 10), tokens.json (5 summons' talents: “小自在”, 海嗣, 纸偶, 狼群, 防护单元); every other data file byte-identical. The data translations (data/i18n/en / ja / ko / zh-TW) are rebuilt (tools/build-i18n.mjs --offline): only the talent texts that carry the new numbers. Spot checks: 刺玫 435 / 15 / 66 s and 111 %; 格雷伊 ASPD 100 → 106 (攻击速度+6), 崖心 / 伊内丝 +8; 砾 16 s, 至简 70 s, 野鬃 60 s (two 再部署时间-10秒: #252 said 70 for the gift 5★ — true for 至简; 野鬃 has two such steps). The 干员调配 局内数值 and the detail card read the records (statsBase + module attr, shared/loadoutRecord.js), so they show the new numbers unchanged in code. One kit read a number from a talent text that now carries the potential step: 望's stock cap, 「最多拥有7枚」 at potential 0, reads 「最多拥有8（+1）枚」 — op-wang.js matched /最多拥有(\d+)枚/ and fell back to 7, so with 7 棋子 to start she sat at the cap (阻回, no S1 / S2); the pattern now skips the step (8 = the 棋子's holding, deckStack 8). The other kits that parse talent texts (多萝西 「最多拥有10个」, 娜仁图亚 「偷取触发2次」, 傀影 「攻击力各+10%」, 伺夜 「至多3只」) read numbers that carry no step; skill texts have no potential steps.
• Consequences worth knowing (the data's, nothing assumed): 多萝西's 共振装置 stock at a deployment is 10 at full potential (潜能 5 「第一天赋效果增强」) — her trap limit without TRP-X is 10, so the kit's 阻回 (no SP while the stock is full) holds from her deployment until a trap is spent (TRP-X: limit 13, no change); 望 sends 7 棋子 (TRP-X 8); 史尔特尔's 余烬 lasts 9 s; 琳琅诗怀雅's 破财消灾 revives to 80 %. One official-data quirk surfaces: 重岳's FGT-Y stage 3 potential candidate (battle_equip_table uniequip_003_chyue) keeps prob 0.23 while its text reads 「25%（+2%）」 (damage_scale 1.75 → 1.8 does move) — the sim follows the blackboard, as for 嵯峨's SOL-Y before (op-saga.js), so that one form rolls 23 % and every other form 25 %.
• ASSUMED none beyond the owner's decision (full potential for every player and every operator, including the 自选 picks, whose official potential would be the account's).
• Golden: moves almost everywhere, as a data change of every operator must — roster 49 / 49, bonds 46 / 46, fields 22 / 22, matches 18 / 18, diy 133 / 138, standins 0 / 10. Unchanged: the 10 stand-in battles and the four prototype 自选 battles diy-135…138 (the 原型干员 have no potential ranks), and diy-012 (twelve 夜莺 pieces that are never hit, never redeploy and deal no damage, so her cost / RES / redeploy steps never show; her talents do not move). Spot checks, the parent data against the new one tick by tick through the golden scenario path (diy-110 / diy-111, 望's battles, also move with her cap fix): roster-001 and roster-020 part at tick 1 on 角峰's HP (生命上限+250: 2770 → 3083 and 5961 → 6634 with the board's HP bonuses), bond-arcaneShip-high at 4.73 s and diy-001 at 3.70 s on an enemy's HP (a hit of a higher ATK). Every moved battle's first differing snapshot hash is in its first 10 game seconds except one bond battle (20–30 s) and ten 自选 battles (10–100 s): a later hit or redeploy; the matches part at rounds 1–8 through those battles (battle results, then the bots' boards).
• Tests: test/full-potential.test.js (new, 6 tests — every one fails on the parent data): 刺玫 435 / 15 / 66 s and her talent; the other potential kinds and #252's redeploy times; every chess, 自选 form and stand-in form re-derived from the raw keyframes plus the potential steps; every chess talent = the last candidate unlocked with requiredPotentialRank ≤ 5; summons at the owner's potential (PRTS Mon3tr numbers) without the owner's attribute steps; the loadout record (局内数值 / detail card), 自选 / 补位 compositions and a battle unit (刺玫 base ATK 435, cost 15, 66 s). data.test.js's independent re-derivation now adds the potential steps (and re-derives respawnTime too); the spot checks and the kit tests that hard-coded potential-0 numbers carry the full-potential numbers (each from the data and the test's own formula; no check loosened): 205 tests in the 71 自选 kit test files (op_*), 21 elsewhere (data / backups / i18n-data, chess kits, summons, 史尔特尔 余烬 9 s, 望's hand of 7, …); op_wang's S1 / stock / S3 tests fail on the parent kit (the stock cap). Full node --test: 5114 / 5114 pass (the first run on the new data: 233 failures in 87 files, two of them timing tests that failed under load only and pass alone).

26.15 Esc in the 自选 picker closes only the picker (GitHub #284 by Xinglan233, idea from PR #286) — screens/diy.js DiyPicker, screens/loadout.js

• Seen: in 干员调配 → 自选编队, one Esc with the operator picker open closed the whole overlay and went back to the lobby (5阶 and 6阶 slots, also from the picker's search field), while the picker's 取消 and × close only the picker and the 导入 dialog's Esc closes only itself. The overlay's capture-phase key handler gave way only to a .modal; the picker is a .diy-pick section without key handling of its own.
• Now: the picker registers its own capture-phase Esc handler that acts as 取消 (the draft is dropped, the saved picks are untouched) and gives way to a .modal over it (the 导入 dialog); the overlay's handler skips Esc while a .diy-pick is open. The next Esc closes the overlay as before.
• Golden: unchanged (interface only). Tests: test/ui/diy.e2e.test.js — a real-server browser test that needs no art: Esc closes the picker of a 5阶 slot, then of a 6阶 slot from its search field, the overlay and its four slots stay, sp.pref.diy is unchanged, and a second Esc closes the overlay; it fails on the parent.