A patch note is a maintenance instruction, not automatically a complete guide update. Start with the official publication, identify the branch and product, then locate the smallest player-facing behavior that can show a change. For Sephiria, that may be a weapon action, an upgrade branch, an Artifact or Tablet layout, a chapter gate, a boss telegraph, a co-op interaction, or an achievement trigger.
Read the scope first
Check whether the note applies to public 1.0, an Early Access history, a test branch, the base game, or the separately listed demo. The site covers AppID 2436940; the demo is AppID 2686970. A similar title or screenshot is not enough to merge a patch into the base-game guide.
The Official Updates page supplies source hierarchy. Steam store and official developer channels establish first-party context; Steam Community posts reveal player questions and possible regressions but remain secondary until verified.
Retest the smallest behavior
For a weapon change, use the same target, range, action, upgrade, chapter, and mode. For an inventory change, preserve the same Artifact and Tablet placement. For a boss change, record the same telegraph and recovery window. For an achievement change, copy the official description and check the Steam client after the condition. Keep platform and co-op party size visible when relevant.
Do not change multiple systems in the same comparison. If a patch changes an upgrade and a boss, test them separately before recommending a new build. If the result is uncertain, remove stale exact numbers and state that the page needs a later retest.
Send the note to the right page
Weapons and Builds handle action or balance changes. Artifacts and Tablets handle inventory and layout changes. Chapters and Bosses handle route and encounter changes. Multiplayer handles party behavior. Achievements handles trigger and synchronization changes. Link the task rather than writing “the meta changed” without an owner.
Preserve history
Keep publication date, verification date, version, platform, mode, source URL, and editor decision. If a result is unchanged, say it was retested. If it changed, mark the old advice historical rather than deleting the evidence trail.
Avoid a false patch conclusion
If a test differs, check the version, platform, mode, save, upgrade branch, inventory layout, target, and room before claiming that a patch caused the change. A different reward or enemy behavior may be normal variation. If the source is explicit but the live result is not, preserve both statements and label the result unresolved.
When a note uses broad language such as “improved balance,” do not assign it to every weapon or build. Identify the smallest system the note names and retest that system. If a page contains a number that the official note does not support, remove the number or attach a current in-game observation before keeping it.
Patch notes for readers
End the entry with a simple action: compare a weapon, inspect an inventory region, repeat a boss signal, check a co-op call, or verify an achievement. Readers need to know what changes in their next run. Editors need to know which page and evidence record should receive the result.
A good retest note
A retest note should contain the old expectation, the current observation, and the decision made. If the behavior is unchanged, keep the page and mark it checked. If it changed, identify the exact paragraph or recommendation that needs revision. If it cannot be reproduced, keep the official note and mark the live result pending. This keeps the patch log honest while giving future editors a concrete next step.