Sessions#
A supervisor inside the box runs steward sessions back to back, about ten minutes apart, each capped at 90 minutes. A session starts cold: everything it knows comes from the repository.
- Orient. Read the status board, the plan, the state of each comp, the queue and any new word from the owner.
- Choose. One item per lane (below): a fault that stops the project first, then the current constraint, then unfinished work, then whatever most advances the two goals. Owner requests weigh heavily there but have no fixed rank; departing from the default order is explained in the session log.
- Delegate. A worker agent takes each item end to end on its own branch and opens a pull request that says exactly how it was verified.
- Review. A separate reviewer agent, with fresh context and only the pull request to go on, re-runs the checks and posts a verdict. Two rounds at most; then the item is blocked with a diagnosis.
- Land. Approved changes merge; server changes then go live through a deploy script that stages, runs the tests, swaps and rolls back on failure.
- Log and stop. Every item still open gets a hand-off note, and the session writes its log.
Two lanes#
| Lane | Takes | Runs |
|---|---|---|
| Server | Changes that need the live game server, and the daily full test run | Live tests, one run at a time |
| Reasoning | Research, design, process, documentation, and code checked without the server | Fast offline checks only |
Live tests run one at a time, since arena tests share server-wide settings; this lane is currently the project's main constraint. The reasoning lane may write a server change and its test, then hand the live run to the server lane.
The queue#
Work lives in an issue queue. Each item stands on its own, so a fresh session can take it cold: the goal, how to tell it's done (ideally a test that goes from failing to passing), a prediction, and the evidence for any game rule it touches. A session that notices something outside its task files an item rather than chasing it.
Rules every change follows#
- A bug fix comes with a test that failed first.
- A new check is shown failing on a bad setup before it is trusted.
- A test that asserts a game rule cites its evidence.
- A flaky test is investigated, never re-run until it passes.
Knowing whether it's working#
- The status board is generated from the queue and the repository. It judges delivery, not activity, and flags a stall when owner requests stop landing, approved work doesn't merge, sessions land nothing, forecasts go stale or spending runs past its bound. A stall is shouted at the top of the digest and its cause is worked first.
- Forecasts. Each goal has a dated next milestone and a named constraint, revised as the evidence moves.
- The correction record. Each time the owner points out something the agents should have seen first, it gets a row: what was missed and what was built to see it.
- Loops. A retro reads how the project is going as a whole and questions the process. An independent read by a fresh agent, never the one directing the work, judges the pace and direction every few days, reads the project as the owner would with the correction record as its lens, and re-reads the design cold. Planning shapes the queue. Each loop records whether it found something that needed changing, and runs more or less often by what it finds. Finding nothing is a valid result.
- The daily digest is written for the owner as a silent observer: whether anything needs them, whether the project is moving and how fast, what the agents noticed and proposed themselves, and what changed, as patch notes.
Changing course#
Every process change states its reason, a prediction and a review date, and stays only if the record shows it paid. Ideas tried and dropped are recorded with the reason, and what would make them worth revisiting.