When a guide needs a current fact, begin with the official product page and developer channels. The Steam page identifies Sephiria, AppID 2436940, TEAM HORAY, the 1.0 release date, supported platforms, and the broad feature set. TEAM HORAY’s site provides a second first-party description of the game’s top-down roguelite and inventory focus. These sources establish scope; the live game confirms the exact behavior of a current mechanic.
Read an announcement carefully
Separate a new feature from a correction. A new weapon changes the catalog; a balance adjustment changes a comparison; a bug fix may invalidate a workaround without changing the intended design. Copy the date and the affected system into an editor note before changing a guide. If the announcement uses a branch or test-build label, do not apply it to the public base game until release context is clear.
Turn sources into a verification task
For a weapon, write the target, range, and upgrade context. For an Artifact or Tablet, write the arrangement and the visible result. For a chapter or boss, write the encounter label and mode. For an achievement, copy the official description and check the Steam client. A source link without a test context cannot tell a future editor whether a recommendation still holds.
Keep secondary evidence visible
Steam Community posts are valuable for finding friction points: players ask about builds, inventory placement, co-op, bosses, and achievements. They can also be dated, incomplete, or tied to Early Access. Link them as secondary observations and rewrite the practical question in original language. Do not copy a community table, image, heading sequence, or unsupported exact claim.
Always preserve the source date and the page’s verification date. Those two dates answer different questions: when the developer published the change and when this guide last reproduced it.
Add the platform and branch when the source supplies them, and leave the field visibly pending when it does not.
When a source links to a discussion rather than an official note, keep it in the secondary-evidence section and state that the live game still needs to confirm the claim. A transparent boundary is part of the update itself.
This also tells readers when a page is safe to use immediately and when it should be treated as a research lead until the next verification pass.
A source-check checklist
Confirm the product name, AppID, publication date, branch, and affected system before using an announcement. Then open the live game and test the smallest visible behavior. If the update is a platform or co-op note, record platform and party mode. If it is an achievement note, check both the description and the Steam client result.
If the official source does not answer a player’s question, link the Community discussion as a lead and label it secondary. Rewrite the question in original language, omit unsupported numbers, and invite a current observation. The Patch Notes Guide provides the longer change-log format.
Release versus branch
Before applying a note, check whether it belongs to the public branch, an Early Access history, a test build, or the separately listed demo. The base-game guide uses AppID 2436940; Demo AppID 2686970 is excluded. A correct product boundary prevents a real announcement from being attached to the wrong guide and gives future editors a clear reason for omitting it.
Make the handoff actionable
End an update note with the page and test that should change. For example, an inventory adjustment should point to a before-and-after layout; a weapon adjustment should point to a fixed-room comparison; a co-op change should name party size; an achievement change should name the client confirmation. This turns an announcement into a useful maintenance task without inventing details that the source does not provide.