Find every item in the Mortal Shell II equipment database.

The database groups Shells, weapons, sidearms, abilities, bosses, locations, NPCs, items, maps, quests, reference pages, and walkthrough records. Begin with the type of decision blocking the run, then open the smallest matching hub. A record count describes the current imported dataset, not an official total for the game. Cards preserve names, source labels, version status, and review dates; they do not silently supply missing statistics, rewards, coordinates, or completion conditions.

Choose one record as the primary question. Read its summary with the evidence strip and follow the attributed source when more context is required. If the page is source-summary only, treat it as a review lead and do not infer a guide from its title. Records marked current and needs recheck can coexist because the labels describe different evidence states. Repeated claims from the same publisher remain one source family rather than independent corroboration.

Search can locate related records, the map can narrow a named spatial question, the roadmap can place a confirmed step, and the tracker can preserve a supported target. These tools share a local completion graph but do not read the game save, inventory, platform trophies, quest flags, or storefront. Confirm the object or outcome in the game before changing local state. A favorite marker, checked card, or imported route step is organizational data rather than gameplay proof.

For acquisition work, separate identity, prerequisite, route, inventory confirmation, and any effect claim. For encounters, separate location, entry condition, strategy, result, and reward. For reference answers, match platform, edition, region when relevant, application branch, and date. For rankings, require explicit criteria and alternatives. These boundaries let one directory support different search intents without turning every record into a universal recommendation.

If the release build differs from a captured record, preserve both observations. Record the source URL and date, platform and game build tested, expected result, observed result, and the narrow question affected. Look for a current official or independently attributed source that addresses the same condition. Similar wording in patch notes is only a lead; it must refer to the same object, state, and outcome before it can resolve the discrepancy.

Finish with a compact receipt: record opened, evidence checked, test performed, result observed, and target changed. Keep unknown, skipped, failed, and complete states distinct. Exporting the companion profile protects that local receipt but does not back up the game. Use platform save tools separately before irreversible route decisions. This workflow keeps the database searchable and useful while making every factual boundary visible.

Review the directory again after a release update or source refresh. Reopen only records whose platform, version, route condition, location, or stated outcome changed, and preserve confirmed unrelated targets. If a record is removed from the current import, keep its earlier receipt until the disappearance is explained; missing data is not proof that the entity or feature was removed from the game.

Use the checked date as the review trigger, not as a freshness guarantee. A recent import can still preserve an older source claim, while an older record may remain correct after direct current-build verification.