Platform engineer & builder
Agentic Project Management (Atlas)
BugBot autofix and merge control plane
Trailhead
Four CLIs (autofix, dispatch, draft-flip, merge) share one rate-limited GraphQL client so BugBot threads get fixed and gated without silent auto-merge.
Project brief
PrototypeProblem
Agent-authored pull requests accumulate mechanical review and merge work that is slow by hand and risky to automate carelessly.
Outcome
A pull request with an open BugBot thread needs someone to fix it, reply to it, and shepherd it through checks to merge. Atlas automates that loop (detect, fix, flip to ready, merge) through four single-purpose CLIs sharing one rate-limited GitHub client.
Evidence
- The readiness decision is a pure function over the six gates, eleven checks in all, tested with 39 cases; the CLIs that act on its verdict stay thin.
- Test coverage still lags: only that decision core is unit-tested, and a duplicated detection helper hasn't yet been consolidated.
Key decisions
- Orchestrator zone: Two workflow triggers feed four single-purpose CLIs (fix, dispatch, flip-to-ready, merge-if-clean) each its own entry point with no shared process.
- Shared-client zone: A token-bucket rate limiter plus header-driven backoff keeps every entry point under one shared GraphQL budget instead of retrying blind.
- Decision core: The readiness verdict is a pure function over a PR snapshot, unit-tested independently of the CLI that acts on it.
- Telemetry zone: Every verdict emits a redacted NDJSON event, so the pipeline stays auditable without ever writing credentials to a log.
How it routes
Two figures: how two workflow triggers fan out through four CLI entry points into one shared client and telemetry emitter, and how the draft-readiness decision itself cascades through gates before a verdict is logged.
Four CLI entry points, one shared client
01–044CLI entry points01 Triggers
02 Orchestrator
03 Shared client
04 External systems
Two workflow triggers route into four CLI entry points, which all share one rate-limited client and telemetry emitter on their way to external systems.
The readiness-verdict cascade
1–66cascade stagesThe draft-readiness decision runs a PR snapshot through a cascade of gates (checks, threads, merge state, agent activity) before flipping to ready, rebasing, or holding, and every outcome is logged.
Field notes
The readiness decision is a pure function over the six gates above, eleven checks in all, tested with 39 cases, while the CLIs that act on its verdict stay thin. Test coverage still lags: only that decision core is unit-tested.
Where it’s thin
Agent CI/CD is the delivery-side twin of the same trust boundary.
Related routes
Deterministic guards keep the fix loop reviewable; the merge actor still decides what ships.
Portfolio graph
Maps how the work here connects. Open the Portfolio graph →
- Professional
- Personal
- Skill
- Writing