Editorial policy

A guide should answer its stated task, show the reasoning needed to follow it and make clear when an example is conceptual. Announced game content, base-game documentation and a tested DLC solution are different kinds of information.

Game facts and examples

Official descriptions establish announced features and planned dates. They do not establish every rule hidden behind a screenshot. Base-game knowledge is useful preparation, but it is not automatically proof of underground behavior.

Original diagrams and teaching boards are labeled as examples. Their coordinate conventions, values and constraints are explained on the page. A numeric sorting exercise does not claim the DLC uses that exact sequence or color order.

What a working-script claim requires

A script described as working should name its task, relevant game version and prerequisites, and have an observed successful run. It should also explain important failure or boundary cases. A copied code fragment, a screenshot of code or ordinary Python execution is insufficient.

This pre-release build does not present a set of tested DLC scripts or a complete underground walkthrough. The exercises explain reasoning without executing arbitrary reader code.

Updates and corrections

Planned dates, game commands and unlock conditions can change. A changed rule requires checking the affected answer and example before continuing to describe it as current. A page’s update date identifies the version of the guide, not proof that every game state has been tested.

When information conflicts, the narrow supported answer takes priority over a confident guess. A correction should change the actual answer and affected example, rather than leaving an inaccurate claim in place under a generic disclaimer.

Use Start here for current access context and About for the site’s scope.