Creep 不移动
覆盖目标
覆盖 moveTo()、fatigue、无路径与距离分支,并证明后续 tick 的位置或状态变化。
下一步应采集的证据
优先捕获真实 moveTo() 返回值、creep.fatigue、起止位置和至少一个后续 tick。
VERIFICATION COVERAGE
这里不把“有文章”当成“已验证”。它把 Phase 4B 的高频症状路径映射到 Error、API、Object Hub、Guide、Tool,并用现有 accepted Verification 边界计算当前运行时证据覆盖。
VERIFICATION COVERAGE
这份 Registry 只决定“下一步最值得验证什么”。当前覆盖状态仍由 Diagnostic Center 同一套公开 accepted Verification 层计算;数据库记录不能单独把未接受文章提升为已验证。
覆盖 moveTo()、fatigue、无路径与距离分支,并证明后续 tick 的位置或状态变化。
优先捕获真实 moveTo() 返回值、creep.fatigue、起止位置和至少一个后续 tick。
覆盖 harvest() 的目标、距离、WORK 部件与资源变化,并验证实际 Store 或 Source 状态。
记录 harvest() 返回值、目标类型、WORK 部件、资源量,以及后续 tick 的 Store/Source 变化。
先把 spawnCreep() 的高频返回码、dryRun 与真实调用边界做成可复现 Console 证据。
优先验证 ERR_NOT_ENOUGH_RESOURCES、ERR_NAME_EXISTS、ERR_BUSY 与一次 OK 路径,不扩大成整套 Spawn 队列长期结论。
把 Controller、Upgrader、供能 Link/运输与 ticksToDowngrade 放到同一条多 tick 证据链。
记录 upgradeController() 返回值、Upgrader Energy、Controller 进度、ticksToDowngrade 与供能侧状态的连续变化。
覆盖 cooldown、发送方库存、接收方容量与真实 transferEnergy() 返回值,并验证下一 tick 两端 Store。
优先采集发送 Link/目标 Link 的 Store、cooldown、返回码和下一 tick 状态,避免只靠截图判断。
先用受控 Console 场景确认参数、Credits、Terminal 与交易 Energy 成本边界,不把一次交易扩成市场策略结论。
优先采用低风险、可撤销或只读检查;需要真实交易时只验证明确的最小场景并记录限制。
用多 tick CPU/bucket 与热点测量证明性能问题和改动效果,而不是用单 tick 总量下结论。
记录 Game.cpu.getUsed() 分段数据、bucket、工作规模与改动前后多个 tick 的对比。
这条路径没有单一错误码可以定义。
把 withdraw/pickup、移动、transfer 与源/载体/目标 Store 串成完整多 tick 物流证据链。
分别保存 withdraw、pickup、moveTo 与 transfer 返回值,并连续记录 source、Creep、destination Store,定位物流链真正断在哪一步。
覆盖 build()/repair() 的返回值、WORK、Energy、目标类型与后续 Construction Site progress / structure hits 变化。
记录 build/repair 返回值、Creep Energy、WORK 部件、目标初始状态和至少一个后续 tick 的 progress 或 hits。
覆盖 Tower attack/heal/repair 的返回值、Energy、目标与后续状态;距离只作为效果计算因素,不替代真实运行证据。
优先使用可控维修或治疗场景记录动作返回值、Tower Energy、目标 hits 与后续 tick;攻击场景只在自然出现且可明确记录时补充。