Updates · Source timeline
Official or attributed change summaries stay separate from companion impact notes. A public test fix may not exist in the build you launched.
A source-linked summary of Mortal Shell 2 open beta public test builds 86328, 86724, and 87133 covering crashes, camera, targeting, bosses, UI, and controls.
Current Mortal Shell 2 Revered Edition availability guidance, what the official community update says, and what to check before ordering.
Each update record belongs to a named application, branch, platform scope, source, and date. Read the archive in chronological order and match the exact build before applying a bullet to a current session. An Open Beta fix is historical evidence for the beta application; it is not a promise that the same change shipped unchanged in retail. A release availability or edition notice can also change after capture, so the latest official status must supersede stale operational guidance while the older snapshot remains visible as history.
Separate source text from companion impact. The attributed record states what its publisher reported. The companion can identify which route, trophy, map, or issue may need review, but similarity of wording does not prove causation. A bullet mentioning a crash, camera, boss, item, or balance change must match the same symptom, state, and application before it is linked as resolution evidence.
Before testing, record the platform, application branch, visible version, save state, and exact behavior expected from the update. Reproduce the shortest sequence that isolates the named change. Do not combine several route steps or equipment changes into one test, because a successful outcome would not show which change mattered. Preserve screenshots or logs outside the companion profile and avoid publishing account credentials or private save data.
If the result now matches the patch claim, close only the affected issue or route question for that build. Do not delete earlier observations or declare every similar report fixed. If the result still differs, keep the target open, record the mismatch, and check whether the update reached the same platform or branch. Absence of a repeated symptom in one run is useful local evidence, not proof of a universal correction.
Link an update to a known issue only when the source names a matching condition and the current-build test addresses the same outcome. Link it to a route step only when the change affects that step's prerequisite, action, or completion signal. Map and database records should be reopened narrowly when a coordinate, item, encounter, or requirement changes; confirmed unrelated progress must remain intact.
Close the review with the update source and date, application build, platform, test sequence, observation, and every local target changed. Keep unresolved, mitigated, and fixed statuses separate. A workaround can remain active after one successful completion, and a completed target can coexist with an unresolved general issue. This dated receipt prevents beta history, release notes, personal testing, and companion state from being collapsed into one unsupported claim.
Revisit the archive when a newer build appears, but compare from the last verified state instead of retesting the entire site. Identify which notes supersede earlier bullets, which remain branch-specific, and which do not affect completion. Preserve a direct link to the exact update page used so later reviewers can distinguish an official change, an attributed summary, and the companion's own impact assessment.
Keep publication time separate from the time a build reached a platform. When rollout timing is unknown, label it unknown and avoid promising that every player can reproduce the note immediately.
