4.7 KiB

Raw Blame History

Documentation and implementation alignment

The module dependency register Status column and each module’s summary table should not silently disagree with the repo. This doc defines how to keep decomposition docs truthful and where to record partial work.

Roles

Source	Role
Register + module markdown	Intent, dependencies, contracts, policies (authority, PvP, quests, ops).
Code + tests	What actually runs; paths under `server/`, `client/`, etc.
Plans	`docs/plans/` (e.g. NEON-* implementation plans) tie stories to acceptance criteria.
Jira	Stories under epics; module grouping = labels on the story (no Jira Feature issues). Decomposition README — Jira alignment.
This doc’s tracking table	Quick inventory of modules that have started implementation; expand as work lands.

Status column (register)

Status	Meaning
Planned	No meaningful implementation toward this module yet, or only unrelated spikes.
In Progress	At least one tracked story or code path exists toward the module; contracts may be partial.
Ready	Exported contracts meet contracts.md “Ready” guidance and dependents may integrate.
Blocked	Upstream module or external dependency prevents progress.

Rule: When a story merges that implements part of a module (API, store, schema), move that row from Planned to In Progress (or Ready when appropriate) in the same PR or a follow-up doc PR.

Partial modules stay In Progress until the prototype slice for that module is satisfied or contracts are explicitly frozen for dependents.

Per-module docs

Optional ## Implementation snapshot (or a short bullet under Summary) on a module page: one paragraph + links to docs/plans/…, server paths, and server README sections—avoid duplicating the full tracking table on every page.

The Summary table Status field should match the register row for that module.

Implementation tracking table

Rows appear when work starts; default for unlisted modules is Planned / not started.

Module	Register status	Snapshot	Plans / pointers
E1.M1	Ready	Prototype milestone Done (NEON-9). Authoritative `PositionState` + MoveCommand over HTTP (JSON v1 snap); in-memory store by default, Postgres when configured (NEON-5); shared NpgsqlDataSource disposed on host shutdown (NEON-15); Godot sync + path-follow (NEON-4, NEON-8); InteractionRequest + horizontal range (NEON-6). Follow-on: prediction/reconciliation, Slice 1 telemetry, Protobuf wire per contracts.md.	NEON-3, NEON-4, NEON-5, NEON-6, NEON-7, NEON-8, NEON-15; `server/NeonSprawl.Server/Game/PositionState/`, `Game/Interaction/`; server README
E1.M2	Ready	Slice 2 prototype slice closed: follow + `CameraState` (NEON-25); zoom bands (NEON-26); occlusion (NEON-27); occluder pick-through (NEON-30); contracts + hardening (NEON-28). Client-local; no server use of camera pose.	NEON-25, NEON-26, NEON-27, NEON-28, NEON-30; `client/scripts/isometric_follow_camera.gd`, `camera_state.gd`, `zoom_band_config.gd`, `occlusion_policy.gd`, `ground_pick.gd`; E1_M2_IsometricCameraController.md

Module dependency register
contracts.md — versioning and Ready criteria

4.7 KiB Raw Blame History Unescape Escape