VERIFICATION COVERAGE
This page does not treat published content as verified by default. It maps the Phase 4B symptom paths to Errors, APIs, Object Hubs, Guides, and Tools, then calculates current coverage through the existing accepted Verification boundary.
Evidence strength and coverage completeness stay separate. Without accepted Console or live multi-tick evidence, a path remains unverified; documentation review, offline simulation, or a database row cannot promote it on their own.
VERIFICATION COVERAGE
The registry prioritizes what should be proved next. Coverage status is calculated from the same accepted public verification layer used by Diagnostic Center; database records cannot promote an unaccepted guide on their own.
Cover moveTo(), fatigue, no-path, and range branches, then verify later-tick position or state changes.
Capture the real moveTo() result, creep.fatigue, start/end positions, and at least one later tick.
Cover harvest() target, range, WORK-part, and resource branches, then verify Store or Source state changes.
Record the harvest() result, target type, WORK parts, resource amount, and later-tick Store/Source changes.
First make the high-frequency spawnCreep() return-code, dryRun, and real-call boundaries reproducible in Console evidence.
Prioritize ERR_NOT_ENOUGH_RESOURCES, ERR_NAME_EXISTS, ERR_BUSY, and one OK path without generalizing to long-term queue behavior.
Put the Controller, Upgrader, Link/hauling supply, and ticksToDowngrade into one multi-tick evidence chain.
Record upgradeController() results, Upgrader Energy, Controller progress, ticksToDowngrade, and supply-side state across ticks.
Cover cooldown, sender stock, receiver capacity, and the real transferEnergy() result, then verify both Stores on the next tick.
Capture sender/receiver Stores, cooldown, return code, and next-tick state instead of relying on a single screenshot.
Use controlled Console cases to confirm argument, Credits, Terminal, and transaction-Energy boundaries without generalizing one trade into a market strategy claim.
Prefer low-risk, reversible, or read-only checks; when a real transaction is required, verify only the smallest explicit case and record limitations.
Use multi-tick CPU/bucket and hotspot measurements to prove the performance problem and the effect of changes instead of concluding from one tick.
Record Game.cpu.getUsed() section measurements, bucket, workload size, and before/after comparisons across multiple ticks.
No single return-code branch defines this path.
Connect withdraw/pickup, movement, transfer, and source/carrier/destination Stores into one complete multi-tick logistics evidence chain.
Store withdraw, pickup, moveTo, and transfer results separately and track source, Creep, and destination Stores across ticks to locate the broken logistics stage.
Cover build()/repair() results, WORK parts, Energy, target type, and later Construction Site progress or structure hits changes.
Record build/repair results, Creep Energy, WORK parts, target starting state, and at least one later tick of progress or hits.
Cover Tower attack/heal/repair results, Energy, targets, and later state; treat range as an output factor rather than a substitute for runtime evidence.
Prefer controlled repair or heal cases with action result, Tower Energy, target hits, and a later tick; add attack evidence only when it occurs naturally and can be recorded clearly.
