From d42411ef884484c9c49482dd944a8394e78d8e15 Mon Sep 17 00:00:00 2001 From: "Emil A. Overbeck" Date: Sun, 19 Jul 2026 02:57:01 +0200 Subject: Update docs --- CLAUDE.md | 36 +++++++++++++++++++++++++++++++----- 1 file changed, 31 insertions(+), 5 deletions(-) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index e94eeb5..a2453f7 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -153,12 +153,17 @@ See `requirements/milestones.org` for the live checklist. Roughly: - **M0–M3 done:** scaffolding, rendering/physics, building system, structural destruction (stress/collapse/fire). -- **M4 in progress:** cannon (ballistic) + laser (beam/fire) with the Forts - select-a-weapon-and-aim-in-its-arc UX. Missing: mortar, flak/point-defence, - machinegun/sniper (hitscan), guided missiles, EMP, per-shot recoil. -- **M5 in progress:** reactors + win/loss + restart (R), real resource economy +- **M4 mostly done:** per-strut HP, cannon (ballistic) + laser (beam/fire) with + the Forts select-a-weapon-and-aim-in-its-arc UX, direct-vs-splash delivery, + fire + spread. Missing: mortar, flak/point-defence, machinegun/sniper + (hitscan), guided missiles, EMP, per-shot recoil, metal-per-shot. +- **M5 mostly done:** reactors + win/loss + restart (R), real resource economy (mines on deposits, turbines by height, storage caps, firing costs energy), - device framework + placement. + device framework + placement. Two gaps: fire does **not** damage devices, and + devices are not mounted on the strut graph, so the "cut its supports and the + reactor falls" victory path does not exist. +- **M6 partial:** enemy fort (`data/mods/enemy-fort/`) + deposits both sides; + terrain is still a flat half-plane and there is no sky backdrop. - **Not started / later:** repair & recycle (M7), armour/door/shield materials, tech tree + upgrades, commanders, real map/terrain, AI, netcode. @@ -177,6 +182,27 @@ consult it before deciding what to build; don't guess from vibes. - **Build before you claim done** (compile in the container) and validate any Lua you touched with a standalone `lua` run. Be honest about what you couldn't verify (the GUI can't run headless here). +- **Keep the status docs in sync — same commit as the change.** When you land, + extend or remove a feature, update all three in the commit that changes the + behaviour, not later: + 1. `requirements/milestones.org` — tick the boxes you actually delivered, and + fix any item whose *description* no longer matches what was built. + 2. `research/gameplay-gaps.org` — the "What we HAVE" baseline, the affected + `**` section, the roadmap table, and the "smallest next steps" queue. + 3. `CLAUDE.md` §6 — the milestone summary, plus §2/§3/§4 if the architecture, + the physics model or the data schema moved. + + Rules that make this worth doing: + - **Verify against the code, not memory.** Grep for the thing before ticking + it. These docs drove a real prioritisation error once: every M4/M5 box sat + unchecked and the gaps doc still claimed "we have ZERO devices" long after + reactors, mines, turbines, the economy and win/loss had shipped. + - **Record the gap, not just the win.** Half-done is `[~]` plus a one-line + note on exactly what is missing (e.g. M5's reactor exists, but nothing + mounts it on the strut graph, so there is no collapse-victory path). A + `[X]` that hides a caveat is worse than an unticked box. + - §6 tells everyone to consult `gameplay-gaps.org` before choosing work, + not to guess from vibes. That holds only while the doc is true. - **Don't commit game assets** (§5), `builddir/`, or `imgui.ini`. - Match surrounding code style; keep the engine/game split; prefer data (Lua) over hard-coded constants. -- cgit v1.3