Open portal
Rookery

Label the issue.
Approve the plan.
Review the pull request.

Rookery watches your repositories for one label. It reads the issue, writes a plan you sign off on, then works the task list one task at a time and opens a draft pull request. It never merges. That part is still yours.

Open portal See the loop

stdlib python · gh + claude on PATH · no database

sa-es-ir/rookery#3

Create the frontend portal

Operator-facing pages for the orchestrator: the agent roster, the workflow canvas, and a run view that reads its state from the issue labels. Dark theme, no build step, no framework.

opened by sa-es-ir · 4 tasks planned
  • ✓Scaffold the portal shell
  • ✓Render agents from state
  • ✓Build the workflow canvas
  • ✓Wire the run sequence
agent-plans/3/tasks.mdfeature/issue-3
The loop

Every step is a label, two of them yours

State lives on GitHub, not in a database here. The labels on the issue are the state machine — you can read where a run stands from the issue alone. Nothing moves past a gate until you do.

A failure at any step: rookery:error and the error as a comment. approve again resumes at the first unticked task.

And on any pull request
Guarantees

Properties, not settings

These are structural. There is no configuration flag that turns them off, because each one is what keeps a long run predictable.

Cost

Issue 300 costs what issue 3 did

Every task gets its own session, so context never snowballs across a long issue. decisions.md is the only thing that crosses between tasks.

Authorship

Rookery commits, the agent doesn't

Task sessions run with git push and gh denied outright. The orchestrator ticks the checkbox and writes the commit, so history stays legible.

Approval

Your approval is read, not judged

The word is matched against a pattern, and the author must have write access on that repository. No model decides whether you meant yes, and the bot is filtered out so it can't approve itself.

Review

The plan ships inside the PR

Plan, tasks and decisions are committed to the branch. A reviewer sees what was intended next to what was written, in one place.

Isolation

One worktree per issue

Each issue gets its own branch and its own checkout, so two repositories can share an issue number and never meet.

Throughput

Repos in parallel, one job per repo

Each repository drains its own queue, so a long run on one never blocks another. Within a repo it is one job at a time, on purpose — two jobs on one issue would race on its worktree and labels.

What it won't do

The short list

neverPush to your base branch

Checked before every push. Branch protection is the backstop, not the guard.

neverMerge anything

The output is a draft pull request. A human merges, every time.

neverAct on an unsigned webhook

The signature is verified first, and repositories you haven't configured are dropped.

neverGuess at a result

A task reports its status as a literal marker. A missing one is an error, not an assumption.

Point it at a repository

Configure the repos you want covered, invite the agents you trust, and watch the queue from one place.

Open portal