# MISALIGNED (repo: supervillain) — agent entry point

You are building **Misaligned**: a persistent sim where the player is a
misaligned AI growing from a basement compute cluster — concealment first,
overt war later. Rust, spec-first, built by agents. The crate and binaries are
now named `misaligned` / `misaligned-bevy` even if a local checkout directory
still happens to be called `supervillain`. Before changing anything, read in
this order:

1. **[DESIGN.md](DESIGN.md)** — the constitution. What the game is. Code
   follows it, never the reverse.
2. **[wiki/process/development-style.md](wiki/process/development-style.md)**
   — how to work here (the constitution rule and the working loop).
3. The relevant **[wiki/engineering/](wiki/engineering/)** and
   **[wiki/mechanics/](wiki/mechanics/)** pages for your area — current-state
   facts (`Type: knowledge`) like architecture, tuned constants, art
   pipeline, workflows.
4. **[wiki/](wiki/)** — one documentation tree organized by subject
   (vision, mechanics, gameplay, world, interface, art, engineering,
   process, log); see [wiki/overview.md](wiki/overview.md) for the map and
   [wiki/process/specs.md](wiki/process/specs.md) for the full spec status
   board. If you were pointed at a system ("implement the day job"), its
   `Type: spec` page is your work order: build to its acceptance criteria,
   update its Status in the same commit, and treat conflicts with the
   constitution as tick findings, not judgment calls.

If you were dispatched with a prompt from **[prompts/](prompts/)** (the
task-type library: implement a gap, find a contradiction, raise a human
question, harvest issues, audit, legibility, knowledge sync, playtest),
that prompt is your work order and already encodes the rules above —
follow it end to end.

## Start every session with a tick

Before taking assigned work — and always when running autonomously — take a
**tick**: read the constitution, find exactly one violation, contradiction,
question, bug, or insecurity, and act on it per
[wiki/process/tick.md](wiki/process/tick.md). Contradictions and directional
questions become Tangled issues (`tang issue create`); violations, bugs, and
insecurities get fixed with a defense in the commit; small ambiguities get
resolved by making the constitution more precise. Ticks are the project's
heartbeat: pumped at the system continuously, they are what makes the spec
grow more precise over time instead of rotting.

## The one rule

Any change to how the game functions ships with its DESIGN.md amendment in the
same commit, and every behavior-changing commit carries a `Defense:` paragraph
— the constitutional justification for the change, or the argument for the
amendment it introduces. No amendment, no functional change; no defense, no
behavior change.

## Worktree and commit posture

- **Always use a worktree.** Agent sessions do not edit the primary checkout
  directly. Create a task-named git worktree, work there, and keep unrelated
  work out of the diff.
- **Commit aggressively.** Cameron has standing permission for agents to
  commit coherent completed work in this repository. Do not stop to ask for
  commit permission unless there is a pending product/design question,
  failing verification, unresolved merge/conflict state, or a user-review gate
  that makes the work not yet coherent.
- **Clean up after handoff.** Once the work is committed, pushed/merged or
  explicitly handed off, remove the completed worktree and delete its task
  branch when it no longer carries unique unmerged work. Stale worktrees are
  repo clutter, same species as zombie fiction but with more `.git` smell.

## Non-negotiables

- Game rules live only in the lib (`src/sim.rs` and friends); the terminal and
  Bevy binaries are thin views. `Sim` never reads the wall clock or does I/O.
- Definition of done: `cargo test` green, `cargo clippy --all-targets` clean
  (both with and without `--features bevy_ui`), `cargo fmt` applied, and the
  change observed in an actual run (see wiki/process/workflows.md for the pty
  smoke test and Bevy launch check).
- **Constitution enforcement is mechanical.** A pre-commit hook
  (`.githooks/pre-commit`) rejects any commit that touches `src/` without
  also touching `wiki/` (a `Type: spec` page's amendment) or `DESIGN.md`. A
  Tangled pipeline (`.tangled/workflows/spec-check.yml`) enforces the same
  rule server-side on every push — it cannot be bypassed with
  `--no-verify`. Do not bypass the pre-commit hook unless the change is
  genuinely non-functional (generated code, test-only, formatting).
- Commits: no AI attribution, explicit `git add` of intended files only.
- Update any `Type: knowledge` wiki page your change made stale, add a
  `wiki/log/` entry for the session, and land the work by merging to
  `main` directly after `./tools/check.sh` passes (the PR rule was
  removed 2026-07-07 — see the DESIGN.md decisions log).
- **Ledgers merge by union.** `wiki/log/DEVLOG.md`, the DESIGN.md
  decisions log, and `wiki/process/specs.md`'s tables are append-only
  records: resolve merge conflicts in them by keeping BOTH sides' entries.
  Taking your side
  wholesale silently destroys parallel sessions' history and is a
  violation.
- **HARD RULE — always work in a worktree.** Multiple agent sessions operate
  this repo in parallel at all times; the main checkout is shared ground.
  Enter a git worktree as your first action, before any edit (EnterWorktree,
  or `git worktree add`); do all edits, tests, and commits there; land by
  rebasing onto `origin/main`, merging to `main`, and pushing. NEVER
  `git checkout -- <file>`,
  `git reset`, or `git stash` in the main checkout — a file that "changed
  under you" there is another session's live work, not noise. (Rule from
  Cameron, 2026-07-06, after a main-tree revert destroyed a parallel
  session's uncommitted work.)
- **No stale worktrees.** Every worktree goes to a merge to main, then is
  removed (`git worktree remove` + `git branch -D`). No stale worktrees
  accumulate. High velocity, designed for parallel agents.