Carry out already-expressed reviewer judgment: autonomous mechanical completion of clear,
bounded review decisions after verified evidence — then notify to finalize merge (default)
or auto-merge when MERGE_HANDOFF_MODE=auto_merge.
Humans stay for design, ambiguity, security, and conflicts. GitHub keeps CI/approval gates.
68.1%
of PRs · candidates to fully automate
In a 183K-PR Cargo/GitHub study, 31.9% of PRs had an author–integrator exchange.
That means 68.1% are candidates to be fully automated through this system.
Working hypothesis: if there is no exchange, either feedback is being missed/deferred or the
submitter is implementing clear reviewer direction without debate. In both cases the controller
reclaims that coordination bandwidth by executing the mechanical path — batch explicit comments,
remediation, verification, eligible thread closure, freshness, CI/approval gating, and merge handoff.
PR-level observed author–integrator exchange; Golzadeh et al., Cargo, 183K PRs.
Human / manualControllerCursor workerGitHubDurable stateDelay / rework
Before · exchange / manual path
Unnecessary amount of work after publishing a PR for review. Most of it is manual and mechanical -- it doesn't change the actual code being deployed just ensures there are no conflicts or is at the mercy of personal preference of the reviewer/devops.
Review comments arive / reviewer submits review
Author on other work · delay
Author remembers, asks agent to action on comments
Unclear what comments the agent can action on vs what the author needs to intervene on
Author/agent push new changes into PR
Autoamted test run. Pass
Author forgets to close comments
Main moves · CI / approval stale, have to rebase + re-run CI · delay
Repeat / babysit ↻ loop
Eventually, author catches PR at just the right moment where the stars align and they can merge
Bottleneck is coordination delay and rework. Relies on human operators to take action rather than automatically advancing
→
After · PRs automatically progress and merge
Remove the user as an unnecessary controller. Automate the mechanical path on the no-exchange majority of PRs and escalate intelligently for human intervention.
Event occurs on PR (someone submits review, test complete, branch falls behind main, etc).
Controller classifies (LLM) / batches
escalate
Cursor worker · one coherent patch + test
Eligible threads resolve
Freshness job if base moved
Job ends · lock released
CI / approval events recompute
Ready · notify finalize or auto-merge
Workers stop after they push a new commit to the demo branch (simulated locally — not a real GitHub PR). CI/approval stay on GitHub; merge follows MERGE_HANDOFF_MODE (default: human finalizes).
Architecture · Technical flow
What you are seeing: humans at the edges (Reviewer → PR Author); the controller classifies each comment (LLM) then remediates the clear lane while escalating the rest — durable jobs and async gate events in the middle.
Why this matters: mutation jobs end after a demo-branch push; CI/approval events recompute readiness independently.
When ready, default is notify the human to finalize merge; set MERGE_HANDOFF_MODE=auto_merge to merge automatically once all threads are clear (no open escalations).
Layer A = short-lived jobs (remediate / freshness) that finish after push.
Layer B = readiness projection recomputed from GitHub-like events (CI, approval, behind).
Human actor System Solid · bounded call Dashed · async event Dashed rose · human / escalation path
Reviewer submits one review (multi-comment) on GitHub.
Controller classifies comments with a Cursor LLM call (read-only) — escalate ≥1, remediate the rest — then forks: batch the clear lane immediately; notify humans on the rest.
PR Author replies/decides on escalated threads on GitHub.
GitHub owns CI and approval gates. Merge defaults to human finalize (MERGE_HANDOFF_MODE=manual); auto_merge merges when all threads are clear.
Database manages state to prevent duplication of efforts (jobs, locks, readiness, escalations, notifications).
Cursor is used twice: classify (no commits) then a worktree worker that ends after it pushes a demo-branch commit. Later CI/approval events recompute readiness independently.
Discord is notifications only. This could be replaced by any notification surface (Slack, Teams, SMS, etc). Discord never routes decisions into the controller.
Before — manual / no controller
Removes human time: None yet — engineer rediscovers comments, dispatches an agent, babysits freshness/CI.
Human still owns: All judgment and all last-mile coordination.
Autonomous mechanical completion of already-expressed review decisions for teams where most feedback is clear and bounded (common review nits).
Kill switch: STRICT_HUMAN_THREAD_RESOLUTION=true — teams that require human thread resolution keep threads open until a person clicks resolve.
Fixture PR — docs change (deliberately simple)
What you are seeing: the demo PR body plus review threads the controller will act on or escalate.
One markdown file. Three clear actionable inline comments (auto-resolve after verified fix).
One design/debate thread that stays open and escalated — visually distinct below.
Execute Demo · Live GitHub
Buttons drive the configured GITHUB_REPO — create PR, post review, poll, advance main, resolve escalation, flip auto-merge.
Requires DEMO_MODE=false, GitHub token, SSH push, and CURSOR_API_KEY.
What you are seeing: the active demo PR body and review threads as the controller sees them (updates as steps run).
GitHub gate model + readiness projection (Layer B)
What you are seeing: whether this PR is ready for the merge queue — recomputed from gate events, not from a waiting agent.
Layer A = jobs that push then stop.
Layer B = the readiness chip that updates when CI/approval/behind events arrive.
Rules are data, not prose: branch current · actionable threads resolved · CI green · valid approval on current SHA.
Head mutation stales approval — controller cannot retain it. Controller never bypasses required CI/approvals/branch freshness/merge queue.
awaiting_ci is a projection state — mutation jobs are already terminal after they push a demo-branch commit.
Operator notifications
0
Why this matters: alerts only when a human must act or the PR is ready to hand off — not every job lifecycle tick.
Decision-oriented + deduped — not lifecycle spam. Alerts only on intervention or terminal handoff.
In-app outbox is the operator source of truth; Discord is opt-in for the same decision events only.
Readiness projection stays visible above; this inbox is the actionable alert surface.
in-app outboxDiscord: disabled
Safety posture
Live controls moved to Execute Demo tab.
Guided demo
Presenter path — each step simulates an incoming GitHub event or a local DemoWorker outcome.
Nothing here mutates a real GitHub PR.
Next: Reset baseline (or Play full happy path).
Main view is production operator state. Event lab is a facilitator harness for step-through / deviations — hidden by default, not a user-facing workflow.
Event lab · Facilitator harness
Raw controls for demos and tests — not production UI.
Every button below simulates an incoming GitHub event or a local worker outcome.
Demo “push” means: write a new commit on the local demo branch / worktree. It does not mutate a real GitHub PR.
InitialBlocked before-state (reset if unsure)
Last simulated—
Controller now—
NextOpen Guided demo · Reset baseline
Reset / replay
Wipe durable demo state back to the blocked “before” fixture, or replay the whole happy path in one shot.
Happy path · simulate in order
Deviation paths · not happy path
Use only when you want to show interventions — these are not the green-path sequence.
Advanced / optional
Facilitator extras — skip on the 2-minute path.
PR snapshots
What you are seeing: durable PR head/base/behind snapshot the controller uses for readiness.
Remediation batches (Layer A · terminal after demo push)
Why this matters: one submitted review → one batch → one worker. Jobs finish after they push a demo-branch commit; they never wait on CI.
Mutation locks
What you are seeing: at most one mutating job per PR — prevents competing agents on the same head.
Freshness jobs (Layer A · terminal after demo push)
Why this matters: when main moves, a bounded update job brings the branch current, then stops — CI is a later event.
Agent runs
What you are seeing: evidence from the worker that produced the patch (demo = scripted; cursor = real SDK).
Worker kind labeled: demo (scripted) vs cursor (real SDK).
Audit trail
What you are seeing: durable event log of controller decisions (batch, resolve intent, freshness, gates).
Webhook deliveries / events
What you are seeing: simulated (or real) ingress events that woke the controller — not outbound “push” buttons.