TRANSPARENCY
Pending tests remain visible
If a guide has not been tested in the Console or in a live room, that status remains pending rather than being inferred from documentation alone.
Review the 12 priority evidence gaps →VERIFICATION METHOD
Evidence is reported by level
A code example can be syntactically valid without being proven in a live colony. The site separates documentation review, offline checks, Console tests, and multi-tick room evidence instead of treating them as the same claim.
- 01Official documentation checked
The API name, arguments, return values, limits, and timing rules are compared with current official documentation.
- 02JavaScript syntax checked
Code is parsed or type-checked so that basic syntax and obvious type mistakes are caught before publication.
- 03Offline simulation passed
Relevant branches are exercised with controlled mock data when a full Screeps runtime is not required.
- 04Screeps Console tested
The example or probe is executed in the Screeps Console and the observed return value is recorded.
- 05Live multi-tick test completed
The behavior is observed in a real room across multiple ticks, including state changes and edge conditions.
CONTRIBUTE EVIDENCE
Submit a reproducible observation
A useful report includes the server or shard, room state, tick range, exact code or action, return values, later-tick state, and limitations. Credentials and unrelated player data must be removed.
Open the live-evidence form ↗SAFETY
Read-only probes come first
Diagnostics should begin with object reads, return-code logging, and state snapshots before spawning, moving, trading, destroying, or modifying Memory.
ACCEPTANCE RULE
One screenshot is not always enough
Stateful behavior normally needs a starting state, the action return code, and one or more later ticks. Accepted evidence is added with its environment and limitations, not generalized beyond what it proves.