Skip to content
THE DEVELOPMENT WIKIPROJECT I SPACE FANTASY · CO-OP FPS · ROGUELIKE

Wiki implementation and verification

Implementation date: 10 October 2026. Scope: documentation and standalone wiki tooling. All game source/assets/configuration are read-only; no Unity/Game/Editor operation is part of this workflow.

Decisions

  • Replace the planned Editor exporter with static Python inspection because the user explicitly prohibited game-source edits and running anything within the game. Cost: no claim that virtual properties/resolvers were executed; source interpretation and raw fields remain labelled.
  • Keep work in the current checkout so the wiki can inspect the user's actual uncommitted authoring state. Only Docs/, Tools/Wiki/ and documentation ignore entries are written; existing gameplay changes are preserved.
  • Use 91 type-qualified entries: 45 cores, 27 abilities, seven weapon assets (five roster/two legacy), five enemy definitions, three unique sequence maps and four planned enemies. Ordered scene reuse is preserved separately.
  • Keep narrative in authored overview pages and catalog-notes.json; generated pages can be refreshed without losing editorial explanations.
  • Run documentation-only fixture/integrity/static-build/browser checks. Full game/network campaigns are outside this request.

Independent design review reconciliation

Technical review required safe, fail-closed parsing, typed component identity, GUID/fileID resolution, input hashes and preservation on failed collection. Gameplay review required explicit schema/duration/units/charge/proc/defense distinctions. Design review required the current all-participant portal-before-selection flow, separate planned roster, aliases and readable status/navigation.

The integrated approach follows these constraints. Source inventory and page coverage are checked independently of MkDocs rendering. Final evidence and any remaining limits are recorded after the final build/review.

Final documentation evidence

  • 30/30 Python documentation tests pass. Fixtures cover catalogue grammar/strings/enums, safe multi-document YAML, script/component identity, inherited slots, duplicate IDs/GUIDs, required local fileIDs, roster count/type/membership, out-of-directory enemy coverage, deterministic collection, freshness, source-change/IO-failure preservation, missing pages/anchors, escaping, restricted icon expressions and raw-HTML directory URLs. Failures were observed before the responsible fixes.
  • 91 entity pages reconcile against the source snapshot. Generated text/SVGs, manifest identity/page coverage, input hashes, source links and anchors pass integrity checks.
  • Strict static build passes. Built links, anchors and image/script/style targets pass across 122 HTML pages. The package's upstream informational notice does not change the pinned MkDocs 1.6.1 installation.
  • Browser checks: core alias search, Rare + Mobility (three expected entries), alphabetical sorting with aria-sort, empty result/reset to 45, Passive filter to eight, Ultimate filter to four, reset to 27 and numeric resource sorting all behaved as expected. Global Bulwark search distinguishes Passive from Planned enemy. Core entry navigation loads its infobox/art.
  • Rendered checks: desktop dark shell/core/ability tables and entry infobox inspected; 390×844 tables retain icon/name/effect/scaling with no horizontal page overflow. Mobile drawer navigation to Controls succeeds. One browser automation session stalled during capture; recovery used a fresh tab and fresh accessibility state, with subsequent actual screenshots retained.
  • Independent gameplay and rendered-design final perspectives found no remaining material issue in their inspected scope. Technical review findings on object identity/completeness and failed publication were repaired with RED→GREEN fixtures; the last enemy completeness case is included in the 30-test suite.

Screenshots are retained locally under ignored Builds/WikiProof/: core-table.png, core-mobile.png and mobile-controls.png. They show this documentation website, not gameplay.

Maintenance limits

The wiki intentionally does not execute virtual properties or gameplay resolvers. Rank formulas/interpretations and authored values are provided; runtime-produced rank snapshots and new gameplay captures require a separately authorized workflow. Existing gameplay validation is linked with its original scope.

Obsolete generated pages are detected as orphans and require deliberate reviewed removal after catalogue deletion/rename. Previously staged source copies can also require cleanup after removing a source link. No public deployment is configured. These limits do not affect the current complete inventory/build.

Check commands

& .\Tools\Wiki\Test-Wiki.ps1
& .\Tools\Wiki\Build-Wiki.ps1
& .\Tools\Wiki\Preview-Wiki.ps1

These commands run Python documentation tooling and a local static server. They do not run Unity, game builds, C# or online services.