Evidence levels
Verified claims come from the official Steam store or official developer announcements. Developer-acknowledged guidance comes from identifiable developer replies. Community-reported issues remain individual observations unless an official source confirms the behavior.
SteamDB may be used as an independent point-in-time release or demand proxy, never as search-volume evidence. Competitors are used only for gap analysis and are not sources for game facts or prose.
- Verified: official store or announcement.
- Developer acknowledged: identifiable developer reply.
- Community reported: player observation, not universal fact.
- Not verified yet: evidence is insufficient for publication as fact.
Patch and freshness rules
Every guide has a last-checked date. A full-release patch note can supersede older demo information only for the exact behavior it names. A later community report resembling a fixed issue is described as a possible regression, not proof that the official fix failed everywhere.
Dates are changed only after the relevant content is checked. Patch-sensitive routes list their evidence IDs, and old demo notes are retained as historical context rather than silently promoted to current behavior.
Tools and calculations
The profit calculator performs ordinary arithmetic on player inputs. The inventory, dungeon-risk, and layout tools apply visible editorial weights to priorities the player selects. None claims access to item databases, customer coefficients, drop rates, or hidden combat formulas.
A recommendation is a planning prompt. Players should override it when direct current-patch evidence, accessibility needs, or immediate in-game danger is stronger than the model.
Issues, workarounds, and corrections
Issue pages distinguish confirmed fixes, developer workarounds, and community monitoring. Save procedures begin with a complete folder copy and avoid destructive steps. A workaround is never presented as guaranteed when the evidence is demo-era, isolated, or mixed.
When a claim is found to be wrong, the intended response is to correct the page, update its evidence and checked date, and preserve the stronger source language. No automated freshness date is used to disguise stale research.
Monetization and conflicts
The current production code has no verified Adsterra snippet and renders no ad containers. Analytics also remains disabled without an explicit provider configuration. If monetization is added later, it must not interrupt tool controls, hide evidence, or blur the distinction between an advertisement and editorial content.
Affiliate or sponsored relationships, if introduced, must be disclosed beside the relevant link or placement. No such relationship is claimed in the current research gate.