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

Engagement wiki update — 23 October 2026

This documentation update explains the implemented enemy checkpoint 674abeea and its Task 4 automated qualification. The previous 15–16 October wiki record remains historical. Repository source/assets determine behavior; this article and the generated catalogue do not supply new gameplay proof.

Scope and approach

The user requests the current enemy system throughout the wiki, with useful diagrams and animations, and few tests. This is the documentation-only route under AGENT_WORKFLOW. Lead is the sole writer. Game source, tuning, scenes/prefabs, Editor operations and game tests/builds are read-only/out of scope. Preserve all unrelated art/terrain edits and staging.

Reuse the established MkDocs, local SVG and finite user-started JavaScript explanations. Add an engagement/diagnostics guide and a combat roles/recovery guide, reconcile perception, spawning, ownership, glossary/catalogue notes and navigation. Update existing diagrams rather than leaving planned C1/C2 captions on implemented systems. No new dependency or media service is needed. The drawings and animated sequence are schematic documentation, never gameplay captures or simulation evidence.

Hypothesis: separating phase from activity, task time from enclosing deadlines, and finite search allowance from new evidence makes the current system understandable without implying human acceptance or production activation. Factual contradiction, invisible labels, broken links/controls or an implication of budget renewal fails this goal.

Risk is bounded medium documentation presentation/source interpretation, with no authority, evidence or acceptance policy changes. One independent Sol 6.1 Medium read-only technical/document reviewer covers source accuracy, timing/allowance semantics, status, accessible presentation and Ponytail simplicity before and after the change. Other runtime implementation review rounds add no scope here.

Identity and verification budget

The current inspection snapshot records revision, source hashes and unrelated staged state. The collector's provenance and input hashes identify the refreshed catalogue. Existing manual terrain, NavMeshes and unrelated art remain untouched.

Planned checks: one static Refresh-Wiki, one Test-Wiki documentation batch, one strict Build-Wiki/link/anchor check, the existing small animation control fixture extended for engagement boundaries, and representative rendered desktop/narrow inspection. No Unity, C#, native suite, player build, network cohort or gameplay test. Duration initially unknown, dominated by collection/build/browser response. Repeat only checks invalidated by a concrete correction/source drift. Stop after review, documentation proof, scoped local commit and updating the existing hosted wiki under the standing publication authorization. No Git push or gameplay promotion.

Gameplay status retained

Tasks 1–2 have user-reported playtesting acceptance; Task 3 overhead visuals are accepted. Actual moving diagnostic readability, M6–M8 remaining observations, integrated keep/tune/revert, hardware/separate-network acceptance and production promotion remain open. The checklist owns those observations. The Task 4 record owns fresh versus compatible automated proof and retained failures, including the unexplained historical late arrival receipt. No gameplay acceptance is advanced here.

Documentation results

  • Refresh regenerated 91 entity pages and 213 explicitly linked source copies. The collector also reconciled existing committed weapon/presentation changes since the old snapshot; generated outputs were not hand-edited. No weapon/game source was changed. A concurrent documentation-only VFX-plan commit appeared during work; the snapshot records the inspected revision rather than attributing it to this task.
  • 31/31 documentation tests pass. Catalogue freshness/identity and local links and anchors pass; the strict static build validates 128 HTML pages, including image, script and style targets. Existing unlisted-index/upstream notices do not change the pinned MkDocs/Material installation.
  • The small existing Node control fixture passes for all three schematic modes, including exact engagement boundaries, unchanged deadline after the example peek, no autoplay, pause/resume/replay/end, hidden-tab pause and reduced-motion fallback.
  • Actual browser inspection checked the engagement article/diagrams at desktop and 390×844, with local diagram scroll and no horizontal page overflow. Playback reaches Available, replay works and keyboard Space pauses. Typed Breakoff search returns four matching documents. One early diagram route crossed its label; the path/text placement was corrected before final delivery.
  • Independent read-only technical/document/Ponytail review found no source/status blockers. It checked cycle/search/attack/retirement semantics against their owners and kept current qualification distinct from historical failures and human gates.

The browser exposes no reduced-motion/no-JavaScript rendering override; those paths are established through the controlled fixture and readable static HTML, not an actual browser preference capture. Browser SVG measurement does not expose getBBox; the diagrams received visual inspection instead of a claimed automated text-bound pass. Initial sandbox loopback preview did not listen; its owned process was stopped and the approved loopback preview returned HTTP 200. No browser security setting was changed. No gameplay, Unity, player-build, network or hardware checks ran.

The hosted update uses the existing public static Pages project projecti-wiki and the standing source-copy publication authorization recorded in upkeep. Only the checked Builds/Wiki output is uploaded. Delivery receipts, logs and the staged-state preservation check are retained in the ignored local packet TestResults/wiki-engagement-20261023-12d0a124/; a public deployment is verified separately from the local build. No Git push or gameplay promotion is part of this task.