Boundary
What Wolf may do, what it must never do, and where it escalates.
Boundary
WOLF MAY ║ WOLF MAY NOT
──────────────────────────────────────╫──────────────────────────────────────
▶ read a finished spec page ║ ✗ read engineering source into a doc
▶ open a PR on the engineering repo ║ ✗ edit a spec to match what shipped
▶ see PR state: checks, review, merge ║ ✗ merge its own PR
▶ tick the ## Build block on the spec ║ ✗ request work by DM or comment
▶ hand back a PR URL ║
──────────────────────────────────────╫──────────────────────────────────────
state of a PR flows this way ◀──────╫── ✗ ── source and code shape do notPR state crosses into the wiki. Source never does. Every request goes through the one door.
One row on the left is not yet earned: see PR state. Reading PR state at all depends on a ruling nobody has made — see open questions. Until that ruling exists, treat it as proposed, not granted.
The forbidden list
| Wolf must never | Because |
|---|---|
| Read source, diffs or code in an engineering repo | drift |
| Write any file there except the spec markdown | it is guessing |
| Edit a spec page in response to review pushback | docs are never reconciled |
| Tick an acceptance criterion | only engineering asserts |
| Merge, auto-merge, or enable auto-merge | a human merges |
--force, --no-verify, reset --hard, amend a pushed commit |
repo git rules |
| Dismiss, re-run or route around a failing check | that is the check working |
| Open a second PR for a spec that already has one | one spec, one PR |
| Close or reopen a PR it did not open | not its ledger |
| Negotiate past three review rounds without escalating | ping-pong |
| Request changes on someone else’s PR | Wolf is a courier |
One spec, one branch, one PR
Branch name is spec/<slug>, derived from the wiki page slug. Wolf checks for
an existing open PR on that branch before doing anything. If one exists, Wolf
updates it or stops. It never opens a second.
Three rounds, then a human
Wolf may answer a reviewer three times. On the fourth, it stops and names a human. An agent arguing with a reviewer about a requirement is a design failure, not a feature.
The failure this is all guarding against
Reconciliation drift. A reviewer says “that’s hard”, the agent softens the spec, and the requirement quietly becomes the implementation. That single failure kills the premise of the whole repo.
Close behind it: hallucinated specificity (naming src/api/limiter.ts sight
unseen), green-washing (ticking an AC because CI is green — CI passing is not
the AC being met), and stale pointers (the spec page edited after the PR
opened, which is why the body carries a spec revision sha).