Outcome
A user can enable bounded CI repair on a track: when checks fail on its pushed commit, the agent receives the failure evidence and can produce a fix while the user's laptop is closed.
Proposed priority: after the attention inbox (#35). Audience: implementing coding agent. First version is explicit per-track opt-in, with a visible attempt limit, deadline, and cancel action.
First useful version
- Observe authoritative GitHub check results server-side and scope each failure to repository, track branch, SHA, and check run/attempt.
- Create a durable repair attempt with relevant failure logs. Treat logs as untrusted diagnostic input, not instructions.
- Deliver through the existing prompt queue. Preserve uncertain-delivery handling; do not add a second prompt sender or blindly retry ambiguous posts.
- Immediately before dispatch, verify the target revision and track access. If the branch advanced, a person edited the work, or the failure was superseded, reconcile or pause rather than repair stale evidence.
- Serialize repair work with user prompts. Repeated webhook deliveries or polls must not schedule duplicate attempts.
- Make commit/push authority explicit in the opt-in. If pushing is authorized, monitor the resulting SHA and stop at the configured bound. Without push authority, stop with a local fix awaiting review.
- Send unresolved failures to the attention inbox. Success means relevant checks on the repaired SHA passed, not that the agent said it fixed them.
Implementation starting points
Read apps/switchyard/server/{github,repos,prompt-queue,db,context}.ts and src/components/Checks.tsx. Verify GitHub App permissions and available log APIs before choosing signed webhooks or bounded polling. Identify what Fountain can actually enforce: an attempt/time limit must not be described as a dollar cap unless reliable spend enforcement exists.
Completion checks
Demonstrate a failing test on a disposable Demos branch triggering one repair with tabs closed. Verify duplicate events, server restart, newer commits, concurrent user work, cancellation, revoked access, and exhausted limits. Preserve an audit trail of trigger, prompt, attempt, resulting SHA, and checks. Switchyard tests/build pass.
No automatic merge, deployment, force push, or endless retry loop. Existing user authorization governs any external test actions.
Outcome
A user can enable bounded CI repair on a track: when checks fail on its pushed commit, the agent receives the failure evidence and can produce a fix while the user's laptop is closed.
Proposed priority: after the attention inbox (#35). Audience: implementing coding agent. First version is explicit per-track opt-in, with a visible attempt limit, deadline, and cancel action.
First useful version
Implementation starting points
Read
apps/switchyard/server/{github,repos,prompt-queue,db,context}.tsandsrc/components/Checks.tsx. Verify GitHub App permissions and available log APIs before choosing signed webhooks or bounded polling. Identify what Fountain can actually enforce: an attempt/time limit must not be described as a dollar cap unless reliable spend enforcement exists.Completion checks
Demonstrate a failing test on a disposable Demos branch triggering one repair with tabs closed. Verify duplicate events, server restart, newer commits, concurrent user work, cancellation, revoked access, and exhausted limits. Preserve an audit trail of trigger, prompt, attempt, resulting SHA, and checks. Switchyard tests/build pass.
No automatic merge, deployment, force push, or endless retry loop. Existing user authorization governs any external test actions.