5.5 KiB
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. NEO-* implementation plans) tie stories to acceptance criteria. |
| Linear | Issues under projects; module grouping = labels on the issue (no duplicate Feature tier). Decomposition README — Linear 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 (E1.M1). Authoritative PositionState + MoveCommand over HTTP (JSON v1 snap); in-memory store by default, Postgres when configured (NEO-8); shared NpgsqlDataSource disposed on host shutdown (NEO-13); Godot sync + path-follow (NEO-7, NEO-11); InteractionRequest + horizontal range (NEO-9). Follow-on: prediction/reconciliation, Slice 1 telemetry, Protobuf wire per contracts.md. |
NEO-6, NEO-7, NEO-8, NEO-9, NEO-10, NEO-11, NEO-13; server/NeonSprawl.Server/Game/PositionState/, Game/Interaction/; server README |
| E1.M2 | Ready | Slice 2 prototype slice closed: follow + CameraState (NEO-15); zoom bands (NEO-16); occlusion (NEO-17); occluder pick-through (NEO-20); contracts + hardening (NEO-18). Client-local; no server use of camera pose. |
NEO-15, NEO-16, NEO-17, NEO-18, NEO-20; client/scripts/isometric_follow_camera.gd, camera_state.gd, zoom_band_config.gd, occlusion_policy.gd, ground_pick.gd; E1_M2_IsometricCameraController.md |
| E1.M3 | Planned | No E1.M3-named contracts in code yet (TargetState, InteractableDescriptor, SelectionEvent). Precursor for interact range + POST …/interact is E1.M1 (NEO-9); see E1_M3_InteractionAndTargetingLayer.md. Register stays Planned until first E1.M3-tagged implementation merges. |
Linear NEO-23 through NEO-27 (Todo); register unchanged until code merges. E1_M3_InteractionAndTargetingLayer.md; E1M3 prototype backlog; NEO-9; server README — Interaction |
Related docs
- Module dependency register
- contracts.md — versioning and Ready criteria