Makefile

1 files changed, 20 insertions, 15 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 23aec69..4234a9b 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -15,27 +15,32 @@ Read `research/` and `requirements/` for the deep dives; this is the map.
 in `/usr/local`, defined by `Containerfile`). The **binary runs on the host**
 (needs the host's SDL3 + a display).
 
-```bash
-# one-time (and after editing Containerfile): build the dev image
-podman build -t forts-clone-dev .
-
-# configure + compile (from repo root)
-podman run --rm -v "$PWD":/src:Z --userns=keep-id localhost/forts-clone-dev:latest \
-  bash -c "cd /src && meson setup builddir && meson compile -C builddir"
+**Use the `Makefile` — don't type raw `podman` commands.** It wraps the whole
+workflow and puts each half in the right place (compile in the container, run on
+the host). Run everything from the repo root.
 
-# run ON THE HOST, from the repo root (data/ is resolved relative to CWD)
-./builddir/forts-clone
+```bash
+make image     # one-time, and after editing Containerfile
+make build     # compile in the container (default target; configures on first use)
+make run       # compile, then run the game on the host
+make check     # compile + validate the Lua data  <- do this before claiming done
+make help      # every target
 ```
 
-- `scripts/build.sh` wraps the container build/compile.
+Also available: `make reconfigure` (after editing `meson.build`, since meson
+refuses a plain re-setup), `make shell` (interactive container), `make clean`,
+`make clean-image`. For a from-scratch rebuild, `make clean && make build`.
+
 - Lua is **statically linked** (Containerfile builds `liblua.a`) so the
   container-built binary runs on any host regardless of its lua soname.
 - If you add a dependency: add it to `Containerfile` **at the end** (so cached
   layers don't rebuild) unless it must come earlier.
 
 **Verify without a display:** you can't run the GUI in the container, so validate
-by (a) compiling clean, and (b) running Lua data files through a standalone `lua`
-to check they parse. Do both after changes.
+by (a) compiling clean and (b) parsing the Lua data. `make check` does both.
+Note mods must be validated **layered** (base file first) because they
+`table.insert` into globals the base defines — `make check-lua` already does
+this; running a mod file standalone always fails.
 
 ---
 
@@ -180,9 +185,9 @@ consult it before deciding what to build; don't guess from vibes.
   Don't commit feature work straight to `main`; open a branch, then merge.
 - **Commit/push only when asked.** End commit messages with the
   `Co-Authored-By: Claude ...` trailer.
-- **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).
+- **Build before you claim done:** run `make check` (compiles in the container
+  and parses the Lua data). Be honest about what you couldn't verify — the GUI
+  can't run headless here, so anything visual needs a human to look at it.
 - **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: