A video game where you play as a misaligned AI, deceiving and building power. An experiment in spec-driven development. forked from cameron.stream/misaligned
misaligned AGENT.md
5.4 kB · 93 lines

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 — the constitution. What the game is. Code follows it, never the reverse.
  2. knowledge/development-style.md — how to work here (the constitution rule and the working loop).
  3. The relevant knowledge/ files — architecture, sim mechanics, art pipeline, workflows.
  4. spec/ — targetable system specs with acceptance criteria. If you were pointed at a system ("implement the day job"), the matching spec 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.

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 knowledge/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 knowledge/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 spec/ or DESIGN.md. A Tangled pipeline (.tangled/workflows/spec-check.yml) enforces the same rule server-side on every push and PR — 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 knowledge/ files your change made stale, add a devlogs/ 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. DEVLOG.md, the DESIGN.md decisions log, and the spec/README 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.