Architecture
autopilot-core implements the intake-governance and operator-scheduling half of the CAS
autofix loop. It never touches target-repo code directly — it schedules the Codex-driven fix
generation and lets a pull request carry the change through normal review.
flowchart LR
A[CI Failure in\nopted-in repo] --> B[autopilot-create-issue.yml]
B --> C[Issue: autofix + queued]
C --> D[autopilot-operator.yml\nself-hosted Windows runner]
D --> E[Codex fix generation]
E --> F[Pull Request opened\nin target repo]
F --> G[Auto-merge / human review]
H[autopilot-org-installer.yml\nhourly scan] -.installs intake into.-> B
Components
| Component | Trigger | Purpose |
|---|---|---|
autopilot-create-issue.yml |
workflow_run failure |
Creates the intake issue labeled autofix + queued |
autopilot-operator.yml |
schedule + workflow_dispatch |
Scans issues, invokes Codex, opens PRs |
autopilot-org-installer.yml |
hourly + dispatch | Installs the intake workflow into repos that opt in via .autopilot/opt-in |
autopilot-docs-daily.yml |
daily | Refreshes the dashboard status page |
Trust boundaries
- The operator only acts on issues labeled
autofix + queuedand skipsriskyorneeds-designlabels. - Diffs are minimal by design — no secrets, no destructive operations — and required verification runs before a PR is opened.
- The operator requires the
ORG_AUTOPILOT_TOKENsecret, scoped least-privilege for cross-repo mutation; it runs on a self-hosted Windows runner, not GitHub-hosted compute. - This repo does not provision or deploy any cloud infrastructure; it is GitHub Actions orchestration plus a locally-hosted runner.