# 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.