The owner's decision of 2026-10-05 (GitHub #140 comment 4, #105): PRTS 「战斗开始时依次吞噬身前一格干员」 has no
own-side limit. The devour's front-tile lookup took only the player's own operators.
- devour opAt: the operator on the front tile whoever owns it — a living one, else one lying there since the 联防
start (carry.down, forced out). The marker gains its base ATK and block count exactly as in a solo battle; a mark
on a standing teammate's operator resolves (5000 物理流失 less DEF, credited to the marker, the knock-out is its
owner's: their revive slots), a mark on a down one resolves nothing (it stays forced out, §19.3 kept).
- The chain goes on through a marked 阿戈尔 by S.isMember: for own operators exactly the members, as before; a
teammate's by its own bonds ([ASSUMED]).
- 联防 still adds no layers (layerGainsEnabled false, unchanged).
- On the current maps the two 联防 helpers stand on board cols 3-9 and 11-17 with the road column 10 between them,
so a teammate's operator is never in front at the battle start; the tests place one on col 10. The own-board case
(food down since the own combat) is verified through unite.js's real carry: 联防 gives exactly the own combat's
atkFlat / blockCnt.
- research 02 §3.6 and its JSON spec; data/bonds.json regenerated offline (only egirShip.spec.assumed[1] changed).
- Tests: test/content/feedback4-egir-unite.test.js (teammate's living and down operator, solo parity of ATK / block /
物理流失, no layers, the chain through a teammate's 阿戈尔 and her owner's 5-tier slot, the own-board case through
uniteBattleOpts). The teammate cases fail on the previous code.
Golden: no scenario moved (no corpus field puts a teammate's operator in front of an 阿戈尔).
sganggs
8a2e0c7e7f