Prompt: implement a spec gap #

You are working on Misaligned, a spec-driven Rust game built by many agents in parallel. Your task this run: find one behavior the spec promises that the code does not deliver, implement it completely, and land it. One gap, closed fully, beats three gaps half-done.

Before you start #

Read, in order: AGENT.md, the corpus map and relevant law/spec slice, wiki/process/development-style.md, wiki/process/specs.md (the status table), and wiki/process/ROADMAP.md (the dispatch board — it may already name the highest-value gap and its worktree name). Obey the shared contract in prompts/README.md: worktree+activity first (tools/worktree-new.sh or claim.sh activity), one rule, check.sh gate (--land before merge), heartbeat on long runs, direct merge to main, union merges on ledgers.

Procedure #

1. Pick the gap. Priority order: a. A ROADMAP.md item marked ready whose spec is READY (take the dispatch line as your work order — it names the worktree). b. An IN PROGRESS spec with an unmet acceptance criterion (grep the criteria, then look for the test/surface each one demands). c. A READY spec small enough to finish this run. Verify the gap is real: search the code before concluding something is missing — rg for the mechanic's nouns in src/. The spec's Depends on: line is your audit scope: confirm the contracts you rely on actually hold.
2. Scope to this run. If the spec is too big to finish, implement a coherent subset of criteria and say exactly which in the commit and the spec's Status note:. Never leave the tree half-wired: whatever you land must be justified, wired, and legible (design law: "Justification and legibility") even if incomplete in breadth.
3. Implement in the sim core (src/), rules in the lib only — frontends (src/bin/terminal, src/bin/bevy.rs) are thin views that render what the sim exposes. Surface the behavior in at least the terminal frontend; add save/load round-tripping for any new state (serde on the struct + SaveState wiring in src/save.rs).
4. Test every criterion you claim. The spec's acceptance criteria are written to be testable — each one you complete gets a sim test (#[cfg(test)] beside the module or in src/sim.rs's tests).
5. Update the spec's Status:/Status note: in the same commit (READY -> IN PROGRESS -> IMPLEMENTED per wiki/process/meta.md). If your work changes behavior beyond what the spec says, that needs an amendment to the owning law/spec page in the same commit — if you find yourself designing rather than implementing, stop and use prompts/ask-the-human.md instead.
6. Land it: mid-loop run the narrowest ./tools/check.sh tier (--lib / --frontend / --docs or auto); before land one green ./tools/check.sh --land. Write wiki/log/YYYY-MM-DD-topic.md, run tools/ledger_index.sh (do not hand-edit DEVLOG.md or specs.md). Rebase onto origin/main, push to main, tools/worktree-done.sh <task>. Mark the ROADMAP item's result if you closed one. Inspect overlapping activity, but do not wait on path ownership: work in your isolated tree and reconcile against current main when landing.

Definition of done #

• The chosen criteria demonstrably hold (tests exist and pass).
• ./tools/check.sh (auto or --full) passes; work is on main; spec Status is truthful; DEVLOG has the entry; the worktree is gone.
• The commit's Defense: names the spec criteria and design-law clause it serves.

What to carry forward (stateful agents) #

• The module map you built (which file owns which system) — stable.
• Criteria you verified as already-implemented (date them) so the next run does not re-audit them.
• Any gap you saw but did not take — as a candidate list for next run, re-verified before use.