# Execution

> The queue, Auto-Run, Independent review, Grading, Bugfinding, Cards, push and schedules

## The queue

*Work to be done goes into the project's Bug / Feature queue, which records who asked for each item, where it sits in the order and how far it has got.*

| Source | How it gets in |
| --- | --- |
| Chat | Only when you ask for it: the chat seat checks for the same work first, then adds one item with the `queue_items` create action. It never picks requests out of the chat and files them on its own |
| Meetings | Recording → transcript with speakers → the Dev model pulls out items → you tick them in two rounds → filed through the same dedupe |
| Scheduled jobs | When the job's instruction says to file work, the same `queue_items` create, deduplicated the same way |
| By hand | Added in the UI, with no dedupe |

### Dedupe

The first check is an exact title match (trimmed, case-insensitive) against queued or running items. Then a judging model compares meaning, with 4 seconds per item, and only a confidence of 0.85 or more counts as a duplicate. If the judge is unavailable the item is filed anyway, because a duplicate is better than a lost request. A caught duplicate is explained in chat: "Not queued: X is the same work as Y".

### Order and status

Every item has a position: new ones go to the end, you can drag to reorder, and Auto-Run works in that order. Statuses: pending / running / done / failed / cancelled / archived. Archiving or deleting through the seat tool asks for a confirmation card per item.

### Starting a run

Press **Build Features** or **Fix Bugs** in the queue panel; the chat seat cannot start a run. A run takes every pending item of one type and picks up items that arrive while it runs. With more than one item it first proposes work groups, a separate turn checks them adversarially, and any group that doesn't hold falls back to one item per group.

## Auto-Run

*One click runs a whole batch of items. Feature: implement → review → grade. Bug: bugfind → fix → review → grade.*

### Feature

1. **implement**: The Dev seat builds it, adds tests and a PLAN.md block
2. **review**: The host starts an independent review; findings go back to Dev
3. **grade**: A fresh grader, only when a signal fires

### Bug

1. **bugfind**: Reproduce, locate the root cause, write AUDIT.md
2. **fix**: Fix the cause, with tests that fail before and pass after
3. **review**: As above
4. **grade**: As above

The acceptance criteria are the item's own title and details. Implement / fix must bring objective evidence: reproduce the problem, add tests that fail before and pass after, and add a PLAN.md task block with `Item:` and `Verify:` lines. A decision that changes scope goes to the submitter as one card before any code. Implement, fix and every repair turn run in the project's Dev seat; the reviewer and the grader are separate processes the host starts.

### Host Verify

At the start of every review / grade pass and after every repair, the host itself runs the scripts named on the `Verify:` line (only scripts it allows, 10 minutes each). A red script counts as at least one open issue, whatever the model reports. Results are cached against a fingerprint of the project's files, so editing AUDIT.md or ticking a box does not re-run them.

### Commits

Implement and fix commit without pushing; bugfind and review commit only AUDIT.md, with messages like `audit @ <sha> (#N): <verdict>`.

### Interruptions

| What happened | What it does |
| --- | --- |
| Out of quota | Items go back to pending with their phase kept. If another account on the same provider has headroom, it switches to that account and pauses until you press Continue. If none does, it parks until the quota resets and carries on by itself (or waits for Continue when the reset time is unknown) |
| Transient error | For a 5xx, a network error or an engine crash, it retries after 30 s, 2 min and 5 min, from the same phase |
| Two failures in a row | The run pauses |
| Pause / Stop | Pause finishes the current item first; Stop interrupts at once |
| Server restart | Running items go back to pending and start again from the first phase (the engine's conversation carries over). After a normal restart (an update, Restart services) the run carries on by itself; after a crash, press run again |

> Gate evidence (the base commit, review facts, Verify results, grade reasons) is kept in the run log, so a resumed gate picks up where it was.

## Independent review

*The session that writes the code is not the one that reviews it, and by default the reviewer is a model from a different lab.*

- **Who reviews**: A reviewer process the host starts, on the project's Review model (a Codex model by default; Claude can be chosen), 45 minutes at most
- **Permissions**: Read-only: Codex in a read-only sandbox, a Claude reviewer with Read / Glob / Grep only
- **Scope**: The item's commits since it started (`<base>..HEAD`) plus the whole uncommitted working tree
- **Five lenses**: Design alignment, cross-cutting impact, architectural boundaries, task truthfulness, code quality
- **Severity**: critical / major / minor / nit
- **Session**: The first pass of a run is fresh; later passes resume the same reviewer session

### After a pass

1. If there are no findings, the review ran cleanly with full coverage and host Verify is green, the gate closes with no Dev turn. The host adds an all-green line to AUDIT.md and commits it.
2. If there are findings, the Dev seat checks each one against the real code (accepted, doubtful / overturned, or missed by the reviewer and added), fixes what must be fixed along with similar cases, commits, updates AUDIT.md and reports `REVIEW_REQUIRED: <n>`.
3. `n` counts only what is still open at the end of the pass; above 0 means another pass.
4. If it has not converged after two passes, you get a card with three choices: continue, change approach or accept. After four passes at most, the state is recorded and the item moves on to its next phase. The grade gate has the same two caps.

## Grading

*Grading is skipped by default. A fresh grader starts only when a signal fires; it takes the item's own text as the acceptance criteria and looks for counterexamples.*

| Signal | Fires when |
| --- | --- |
| ① Review | The reviewer reported critical / major, or left required issues open |
| ② Verify | Host Verify is red |
| ③ Sensitive paths | The change touches protocol, schema, migration, auth, token, database or store paths (scripts, tests and docs excluded) |
| ④ Strict | The item's title or details say `[strict]` |

Every grader is a fresh, read-only Codex session. It gets the item's title, details and the signals that fired, derives acceptance criteria A1..An, then tries to defeat each one with a concrete counterexample. It reasons statically and runs no tests; commit messages and the author's explanations are withheld from it.

Each criterion comes back pass / fail with a reason and a counterexample, classed as a product defect or a guard weakness. The gate closes when no product-defect criterion fails. Otherwise the Dev seat gets one repair turn and the item is graded again. When grading is skipped, the run log says why.

## Bugfinding

*It traces a symptom back to its root cause through a chain of whys, and each link comes with a command that verifies it.*

This is a bug's first phase. When the report already names the symptom and how to reproduce it, the seat reproduces and localizes within that scope. When the report is vague, an independent read-only Codex does the full trace. It checks several candidate causes one by one, rejects surface-level explanations, separates the workaround from the root fix and gives a verification command for every link.

By default a fresh refuter then attacks the conclusion and returns CONFIRMED / PLAUSIBLE / REFUTED. The main seat runs the verification commands, judges again, writes the result into AUDIT.md and commits it. This step only locates the cause and changes no code.

## Cards, push and schedules

*It sends a card when it needs you and a push to your phone when you're away, and it starts scheduled work by itself when the time comes.*

| Tool | What it does |
| --- | --- |
| `ask_user` | One question or several, with option buttons or a typed answer; it never times out. A chat window shows one card at a time, and the rest wait in arrival order under "N more waiting" |
| `phase_gate` | The phase gate card: Approve / Request changes. Only the engine seat can raise one |
| `genki-push` | A push to the owner or a visible project member (iOS + browser), or a one-off reminder. The server delivers the reminder on time, so it survives restarts and needs no open session |
| `genki-cron` | Recurring jobs: daily, weekly or every N hours. Each run is a fresh, isolated turn on the Dev model; if the last one is still running this one is skipped, not queued; results post to the task room |

A card that pops up is pushed to whoever has to answer it; muted members are left alone.