DREW

§0Principles

§1Progress / Tracker

Live snapshot — phase status and the bar below are computed from GitHub PR state at build time (2026-06-10). 1/12 phases done · 8%.

§2aWhy DREW is not BARD-shaped

This framing drives every downstream decision, so it comes first. BARD and DREW look like siblings — both are LLM bots wired into the AX stack — but they sit on opposite sides of one line: read-only analysis vs. autonomous code change.

For BARD's job, a bespoke loop on the raw SDK is exactly right: the tool surface is tiny and every tool is independently guarded. For DREW's job, the tool surface is a coding agent — edit a manifest, run the build, fix the breakage a bump introduces, drive a PR through CI. That loop, with its context management, permissioning, and sandbox, is precisely what Claude Code already implements. The bump itself a script could do; repairing the call sites a major-version bump breaks is the part that needs the agent.

§2bThe harness decision

Given §2a, the real question is not "raw SDK vs harness" (the harness wins for a coding agent) but which form of the harness, and how to wrap it. Three candidates:

Two findings dominate, and they both point the same way for DREW:

1. Billing no longer forces the hand — isolation does. The original plan rode a Claude Max subscription, which is ToS-clean only with the CLI (not the Agent SDK), making auth the deciding fork. But as of Anthropic's 2026-06-15 change, subscription headless use (claude -p / Agent SDK) draws from a monthly Agent-SDK credit metered at the same per-MTok rates as the API — the flat-rate edge is gone (§3.1). DREW therefore runs on a metered API key, which is ToS-clean with both the CLI and the Agent SDK. So the choice falls to finding #2 — subprocess isolation — plus the API key being a swappable header credential the egress proxy can rewrite (§2e). decided: API key → CLI on isolation grounds
2. For a security-sensitive autonomous agent, subprocess isolation is a feature. The Agent SDK's edge is in-process control (dynamic permission callbacks, typed messages). But what DREW most needs is to spawn each remediation as a throwaway, network-jailed, resource-capped, hard-killable unit and tear it down — so the supervisor stays clean and can docker kill a runaway. That argues for the CLI-as-subprocess inside a fresh container. The "dynamic permission" capability is recovered with PreToolUse hooks (which run in headless mode) plus a scoped GitHub token, so the in-process callback isn't needed.

§2cArchitecture: supervisor / worker

The same split BARD and NATE already use — a cheap, long-lived service that does the constrained routing, and an expensive, disposable brain that does the open-ended work. The supervisor is dumb and never dies; the worker is smart and always dies.

Dependabot alerts API ──(poll, every N min)──┐
                                             ▼
┌──────────────────────────────────────────────────────────────────────────┐
│  DREW SUPERVISOR   (long-lived Python service, like `bard slackbot`)     │
│   • poll open alerts; rank by severity → CVSS → age                      │
│   • THROTTLE: open DREW deps PRs at cap?  → wait this cycle              │
│   • Redis: per-alert lock, concurrency gate = 1, wall-clock timers       │
│   • dedup: alert already has a drew/deps/* branch → skip                 │
│   • spawns ONE worker container for the top alert group                  │
│   • relays PR link + merged/parked/bailed status to #drew-audit          │
└───────────────────────────────┬──────────────────────────────────────────┘
                                │ docker run --rm  (fresh, jailed)
                                ▼
┌──────────────────────────────────────────────────────────────────────────┐
│  DREW WORKER   (ephemeral container = `claude -p` harness)               │
│   fresh shallow clone of adx @ main                                      │
│   bump → just rs/format → cargo check → fix call-site breakage           │
│   deterministic verifier → gh pr create → arm auto-merge → /shepherd     │
│   exits with DREW_STATUS: MERGED | PARKED | BAILED                       │
│   tools: Read/Grep/Glob, Bash(git/cargo/just/gh), Edit                   │
│   egress: allowlist proxy (Anthropic · GitHub · crates.io/npm)           │
│   GitHub App token: contents+PR write, merge via branch protection       │
└──────────────────────────────────────────────────────────────────────────┘

The supervisor holds all durable state and all secrets; the worker receives a narrowly-scoped slice for the duration of one remediation and is destroyed (--rm) afterward. The worker also decides its own stop — /shepherd has no natural end, so the worker exits with a parseable DREW_STATUS line (MERGED / PARKED / BAILED) and that exit is the event the supervisor reacts to; on PARKED it schedules drew resume, which re-attaches to the parked PR's branch and picks the loop back up in media res. The throttle, concurrency gate, timers, and dedup live in Redis in prod, following BARD's guard/ module.

§2dThe alert → merged-PR pipeline

One alert group, one worker, one PR — the supervisor has already picked the highest-severity open alert and confirmed the open-PR throttle has room. The worker's job is to turn that alert into a merged, CI-green bump. The agent's leverage is steps 4 and 6 — fixing the breakage a bump introduces, and driving CI to green; a script handles the rest.

§2eSecurity model & blast radius

An autonomous agent with shell + gh write access to a trading-system repo that merges its own PRs is a serious blast-radius question. The injection surface is far smaller than the incident lane — DREW reads dependency metadata and advisories, not untrusted prod logs — but the merge authority is larger. The defenses are layered so that no single failure is catastrophic.

§2fDeployment on the Mac mini

The deployment borrows ax-bard's software story (Tailscale + AWS Secrets Manager + Docker) but on a single Mac mini (M4, 10-core, 16 GB, 512 GB) rather than EC2 — see the host trade-off in §3.9.

• Runtime: Docker Desktop (or colima). The supervisor is an always-on container; workers are docker run --rm siblings on an isolated bridge network whose default route is the egress proxy.
• Auth: a metered Anthropic API key injected into the worker (claude -p uses it automatically) — from Secrets Manager in prod, a local .env in dev. A swappable header credential, so iron-proxy can credential-swap it at egress like the GitHub token (§3.1, §2e).
• Secrets: loaded from AWS Secrets Manager at supervisor startup (BARD-style) — the GitHub App credentials from which a per-remediation installation token is minted — and handed to a worker only for the life of one remediation.
• Admin access: Tailscale for inbound/management, mirroring ax-bard.
• Lifecycle: the supervisor runs under launchd (Mac-native) or as a restart-always container.
• Build cache: a warm CARGO_HOME registry + shared target/ via sccache, as named volumes mounted read-mostly into the ephemeral worker (GOPHER §7). Doubly central here — every remediation runs cargo update + a rebuild, so a cold cache would dominate the budget. Key it on (rust-toolchain hash, Cargo.lock hash) and accept a rebuild when either moves — note a dependency bump moves Cargo.lock by design, so DREW pays a partial-rebuild on each fix; size the timer for that. Directly relieves the 16 GB pressure below.

§2gThe Adjudicator direction — moving the bottleneck, not hiding it

DREW solved "who does the mechanical work" and immediately exposed the next constraint: who reviews it. Every parked DREW PR waits on the same scarce resource the bot was built to relieve. Two bad answers bracket the design space: delete the review gate (unacceptable — branch protection's required review is doing real work) and keep a human on every bump forever (the bottleneck DREW exists to remove).

The adjudicator is the third answer: a second, independent agent whose only job is review. Three design commitments, in priority order:

1. Defer-by-default. The adjudicator's contract is asymmetric: a wrong defer costs one human review (the status quo); a wrong approve lands unreviewed code on main. So the thresholds are deliberately one-sided — it approves only when every check passes (bounded diff class, deterministic verifier, full CI green, zero review findings, calibrated false-pass rate below target), and any doubt — a finding it can't dismiss, a diff outside the class, a confidence wobble — produces an explicit "deferred to human" comment. It must never be cheaper for the adjudicator to approve than to defer.
2. Separation of duties. The adjudicator is a different GitHub App identity (ax-adjudicator) from the author bot — GitHub already refuses self-approval, and the security property is worth stating: the agent that wrote the diff and the agent that judges it share no token, no container, no transcript (§3.14). They can disagree; that disagreement is signal, posted to #drew-audit.
3. Calibration before authority. Like the trunk's dry-run → supervised → lights-out ladder, the adjudicator ships as a shadow reviewer (A1) whose verdicts are scored against human outcomes. The promotion criterion is a measured false-pass rate on a meaningful sample — not a vibe that the comments look smart.

Scope grows the same way trust did on the trunk: DREW's own drew/deps/* PRs first (the most mechanical, best-understood class — and the one whose author's bounded scope the adjudicator can verify deterministically), then other mechanical classes (A3). Human feature work stays out of scope indefinitely — the adjudicator clears the obvious so humans can spend review where judgment is actually needed.

§2hThe CI/CD direction — ambient leverage

The second growth direction points DREW at the pipelines themselves: rust-test and rust-clippy sit on every PR's critical path, so minutes shaved there compound across every developer, every day — including DREW's own shepherd loop, which waits on the same CI to go green. The lane is deliberately shaped like the trunk's trust ladder:

• Measure first (C1). Read-only telemetry from the Actions API the App can already reach. No optimization is proposed without a baseline and a hotspot ranking — the failure mode of "CI tuning" is cargo-culted cache tweaks that help nothing and break subtly.
• Coverage is the invariant (C2). Every optimization PR must carry a machine-checkable proof that the executed-test set and enabled-lint set did not shrink (§3.18). "Faster because it does less" is a regression wearing a speedup's clothes — the proof is what keeps the lane honest, and it's deterministic, so it can live in CI itself.
• Humans merge pipeline changes — structurally. Workflow definitions gate everything else in the repo, including DREW's own merge path, so this lane never gets auto-merge. Better: the ax-drew App deliberately lacks Workflows: write, so the cage cannot push a workflow edit even if the agent tries — how C2's PRs get authored at all is an open permissions question (§3.17).
• Then ratchet (C3). One-off wins erode; the durable value is the watchdog that notices main's wall-clock regressing, bisects to the commit, and files the issue with evidence. That's the "monitor" half of the mission, and it runs forever.

§3Design Questions

1. Auth / billing — subscription or metered API key?
   • Answered — affirmative Metered API key. The earlier choice — a Max subscription, for flat-rate cost predictability — was overtaken by Anthropic's 2026-06-15 change: subscription headless use (claude -p / Agent SDK) now draws from a monthly Agent-SDK credit metered at the same per-MTok rates as the API, so the flat-rate edge is gone. With that gone, the API key wins on three counts: it's simpler to operate (no claude setup-token, no 1-year OAuth expiry, no macOS-Keychain→Linux bridge); it's a swappable header credential, so iron-proxy can credential-swap it at egress exactly like the GitHub token (§2e), closing a gap the OAuth path left open; and it's ToS-clean with both the CLI and the Agent SDK, so billing no longer dictates the harness form — the CLI is chosen on subprocess-isolation grounds (§2b). Metered means real per-remediation cost, so DREW reports its own estimate + realized spend (§3.6), BARD-style.
2. Autonomy — how far does DREW go unsupervised?
   • Answered — affirmative Shepherd → auto-merge, earned in stages. DREW opens a ready PR, arms auto-merge, and shepherds CI to green — no human drives the mechanics. Today (phase 4) two human gates remain: the operator triggers each run, and branch protection's required review approves each merge. Phase 5 removes the trigger (scheduled supervisor); the required-review gate is resolved either by checks-only protection on the drew/deps/* class or by the Adjudicator track supplying the approving review under its conservative thresholds (§3.12). Defensible because the change class is bounded and mechanical, full CI is the gate, the deterministic verifier backstops it, and the open-PR throttle caps a bad merge at a single git revert (§2e). The incident-triage track keeps the opposite posture — draft-only, human-gated ✅, never auto-merged — because its blast radius and injection surface are far larger.
3. Egress enforcement — harness sandbox, or network-layer proxy?
   • Answered — affirmative iron-proxy at the container layer is the real boundary (the harness sandbox is defense-in-depth only — it's hostname-based and doesn't terminate TLS). Chosen over hand-rolled squid/mitmproxy because it ships default-deny allowlisting, TLS-terminating path-scoped rules, MCP tools/list filtering, and boundary credential-swap out of the box — and both CARL and GOPHER already converged on it. Built and mandatory in the prototype (py/drew/egress/ — doctor/remediate refuse to run without it), currently in warn mode. Allowlist for the Dependabot lane: Anthropic, GitHub, and the package registries (static.crates.io + index, registry.npmjs.org) — no incident.io/Sentry/ClickHouse (those return for the triage track). Pin a tagged release; flip warn → enforce after a clean run (§2e).
4. GitHub credential — fine-grained PAT or a GitHub App?
   • Answered — affirmative GitHub App ax-drew (CARL §3 gives the template) — built; DREW opens PRs as app/afintech-drew, never as the operator. Org-installed but repo-filtered to architect-xyz/ax. Minimal repo permissions: Contents: write, Pull requests: write, Checks: read, Commit statuses: read + Actions: read (the shepherd must read the status rollup and failing workflow-job logs — without these gh pr checks / gh run view --log-failed return 403 "Resource not accessible by integration"; both are read, distinct from the withheld Actions/Workflows: write), Dependabot alerts: read (the trigger feed), Issues: write (escalation comments), Metadata: read — and explicitly not Administration, Workflows, Actions: write, Members, Secrets. Merge needs no extra permission; it is gated by branch protection, not the token (§3.12). Withholding Workflows means GitHub-Actions-ecosystem bumps (which edit .github/) are out of scope for v1 — cargo/npm only — and it constrains the CI/CD track (§3.17). The supervisor mints a ~1h installation token per remediation (never long-lived in the worker); enable App GPG-signed "Verified" commits in prod.
5. Ingest mechanism — poll the alerts API, or a webhook?
   • Answered — affirmative Poll the Dependabot alerts API (GET /repos/architect-xyz/ax/dependabot/alerts?state=open) on an interval and rank the result. Polling needs no inbound endpoint (outbound only — friendly to the egress jail), is naturally idempotent against the open-PR throttle, and a few-minutes lag is irrelevant for vulnerability remediation. The dependabot_alert webhook is a latency optimization for later, not v1. #drew-audit is output-only — no Slack trigger in this lane (the Socket-Mode listener returns for the triage track).
6. Per-remediation budget — what are the caps?
   • Answered — affirmative Meter + report; wall-clock + attempt cap. On a metered API key, dollars are a real per-remediation cost, so DREW meters itself like BARD: the supervisor logs an up-front estimate and the realized per-MTok spend (parsed from the worker's stream-json usage) for every remediation, persists both to the audit trail, and calibrates the estimate from realized data. That's reporting, not a hard cap. The actual runaway guards stay time-based: a per-remediation wall-clock timeout enforced by docker kill (now a backstop for a hung worker — the normal stop is the worker's own DREW_STATUS exit) and a cap on shepherd fix-attempts (≤ N CI-failure → fix → push cycles). Exhausting either bails to "escalated — needs a human" with the PR left open. The open-PR throttle already pins concurrency at one. A third lever — context-window degradation — is real but uncalibrated: research shows quality drops well before the window fills (RULER finds only ~50–65% of advertised context is reliably usable for multi-hop work; Chroma Context Rot and "Context Length Alone Hurts…" show 14–85% degradation as input grows even with perfect retrieval), but there is no published agentic-coding threshold and GOPHER's "33%" was an internal guess. So DREW starts with a hard-kill at 50% of the window — generous for a bump task, so it fires only on genuine runaways — and logs peak context-% vs. outcome in the supervised phase (4) to tune that number later.
7. Repo working copy — fresh clone per remediation, or a warm cache?
   • Answered — affirmative Fresh shallow clone per remediation, destroyed with the container. Ephemerality is a security property (no cross-run state, no lingering secrets). If clone latency becomes a problem, a read-only reference cache (git clone --reference) is an optimization that preserves the property — but default to fresh. Note this is the source clone; the warm CARGO_HOME/target build cache (§2f) is a separate, read-mostly volume.
8. Scope — which bumps does DREW take, and in what order?
   • Answered — affirmative Widen by risk class. Unattended merge authority lands on the safest class first: lockfile-only / patch-level bumps with no manifest range change and no source edits (phase 5.1), then widens to minor, then major / breaking-change fixes (5.2) as the track record earns it. Ecosystem scope is cargo + npm; GitHub-Actions/workflow bumps are excluded (they need Workflows write, §3.4). The supervised phase (4) attempts every class from the start since a human approves each merge — the live record so far spans npm and cargo bumps.
9. Host — Mac mini or EC2 (like BARD)?
   • Answered — affirmative A single Mac mini (M4, 16 GB). EC2 was evaluated and would mirror ax-bard exactly (Tailscale + Secrets Manager + VPC egress jail + AMI workflow), but the dollar spread is small and the Mac mini wins on flat capex (~$799 one-time vs ~$256/mo for an always-on m7g.2xlarge), M4 build speed, and full ownership. EC2 Mac (mac2.metal) is ruled out — no macOS need and ~$474/mo with a 24h host minimum. Accepted trade-offs: ops/uptime are on us (a physical SPOF), and the egress jail is built Linux-side in the Docker VM rather than VPC-native. The 16 GB cargo check concern is handled by the one-at-a-time throttle + CI-as-compile-authority (§2f).
10. Prior art — what's worth lifting from CARL & GOPHER?
    • Answered — affirmative Mined. The two closed Dependabot-bot RFCs (§2a) targeted exactly DREW's v1 job, so the overlap is near-total. Adopted: Dependabot-alert polling + severity ranking; auto-merge of green bumps; iron-proxy egress + credential-swap + MCP tool-filtering (§2e); the container-hardening recipe (read-only fs, tmpfs noexec, no docker.sock, drop-caps, env-file-then-unlink); the GitHub App minimal-permission set + signed commits (§3.4); the context-window monitor — reframed from GOPHER's 33% to a 50% hard-kill, tuned from live data (§3.6); warm cargo/sccache keyed on toolchain+lock hash (§2f); S3 transcripts + #drew-audit; and metered-API-key billing with per-run self-metering (their BudgetTracker shape), plus the shared guard/ ConcurrencyGate. Promoted (was deferred): the deterministic out-of-agent verifier (§2d) — with unattended merge there is no human reviewing each PR, so the dumb checker becomes load-bearing rather than a nicety. Dropped: CARL/GOPHER's /drew pause + auto-pause — the timers and open-PR throttle already contain a runaway. Diverged: the harness (not a raw SDK loop), the Mac mini host (not EC2), and the agent's ability to fix breaking changes (they bumped only compatible versions). Worth re-reading: GOPHER §11 "things to flag" — the cargo-cache-invalidation and transitive-advisory gotchas apply directly.
11. Target version — the advisory's first patched version, or latest?
    • Answered — affirmative Pin to security_vulnerability.first_patched_version, the minimal bump that clears the advisory — not the newest release. Jumping to "latest" maximizes the surface of unrelated breaking changes (more call-site churn, more CI risk) and can pull in a newer release that itself carries a fresh, not-yet-flagged vulnerability. The minimal bump is the smallest reviewable diff and the most likely to pass CI untouched. If the minimal patched version is yanked or itself unbuildable, step up to the next viable release and note it in the PR body.
12. Merge gate — how does auto-merge reconcile with branch protection?
    • Not yet answered Merge is whatever branch protection on main already allows — DREW gets no bypass. The worker arms gh pr merge --auto at PR-open, so the merge completes the moment every required gate passes; where a required human review is configured (today's posture), the PR parks until a human approves — which degrades cleanly to supervised operation rather than failing. The open decision has sharpened into the Adjudicator track: the original options were (a) keep a required reviewer on DREW's PRs (soft human gate, slower) or (b) checks-only protection for the drew/deps/* class (true autonomy, no review at all). The adjudicator offers (c): keep the required-review rule, let a calibrated bot satisfy it under conservative thresholds, defer to a human on any doubt (§3.16). Start with (a) — the status quo — and let the adjudicator's shadow record (A1) decide between (b) and (c).
13. Native Dependabot PRs — own the lane, or adopt them?
    • Not yet answered GitHub's own Dependabot security-update PRs would duplicate and race DREW. Two clean options: (a) disable native security-update PRs so DREW is the sole remediator and opens its own drew/deps/* branch (simplest, and DREW's value-add — fixing breaking changes + shepherding to merge — is fully expressed); or (b) DREW adopts the existing Dependabot branch, taking over from where the native bot stops. Leaning (a) for a clean ownership boundary; revisit if the team wants to keep native PRs visible. Either way DREW reads the same alerts API, and the open-PR throttle keys on DREW-authored PRs only.
14. Adjudicator identity — can DREW review its own PRs?
    • Answered — affirmative No — the adjudicator is a separate GitHub App (ax-adjudicator). GitHub refuses self-approval (a PR's author cannot approve it), so the ax-drew identity cannot satisfy a required review on its own PRs even if we wanted it to — the reviewer must be a second identity. The constraint is welcome: it enforces separation of duties (author bot and reviewer bot share no token, no container, no transcript), and their disagreements become auditable signal in #drew-audit rather than an internal contradiction silently resolved (§2g). Permissions for ax-adjudicator: Pull requests: write (submit reviews + comments), Contents: read, Checks/Statuses/Actions: read — no write to contents, no merge, no workflows.
15. Adjudicator thresholds — what does "very conservative" mean concretely?
    • Not yet answered The promotion gate from A1 → A2 needs numbers, not adjectives. Candidate shape: auto-approve only when (1) the diff is in a deterministically recognizable mechanical class (for drew/deps/*: manifest/lockfile + verifier-approved call-site fixes, no new transitive deps unaccounted for); (2) the deterministic verifier passed; (3) full CI green; (4) the adjudicator's own multi-pass review produced zero findings; and (5) the shadow-phase false-pass rate is below a target (e.g. zero approvals-a-human-would-have-blocked over the most recent N ≥ 50 shadow reviews). Open: the value of N, the target rate, whether "stale calibration" (model or pipeline changed) resets the clock, and whether severity-critical bumps always defer regardless of thresholds.
16. Adjudicator approval — does a bot review satisfy branch protection, and do we want it to?
    • Not yet answered Mechanically, a GitHub App with Pull requests: write can submit an approving review, and plain "require 1 approval" branch protection counts it — but rulesets can be configured otherwise (require Code Owners, restrict who counts as a reviewer), and the org's settings need auditing before this is assumed. The policy question is separate: even if it counts, do we want DREW's merges gated on a bot approval (option c in §3.12) versus dropping the review requirement for the bounded class (option b)? (c) preserves an independent second judgment on every merge and keeps one rule for the whole repo; (b) is more honest about where the real gate is (CI + verifier). Decide after A1 produces a false-pass record worth arguing from.
17. CI/CD lane permissions — who can edit .github/workflows?
    • Not yet answered The trunk's security model deliberately withholds Workflows: write from the ax-drew App (§3.4) — which means the CI/CD track's optimization PRs (C2) cannot even push a branch that edits .github/workflows/*. Options: (a) a separate, narrowly-granted App (ax-drew-ci) holding Workflows: write, used only by the C2 lane, with every PR human-merged (the write is to a branch; the gate is the merge); (b) DREW drafts the workflow diff as an issue/comment artifact and a human applies and opens the PR (zero new grants, more friction); (c) scope C2 to non-workflow speedups only (cache configs, nextest adoption in justfile, test code) and leave workflow edits to humans guided by C1's telemetry. Leaning (b) to start, (a) if the lane proves out — the trunk's posture that workflow write is radioactive shouldn't be quietly reversed by a side lane.
18. CI/CD coverage invariant — how do we prove "same coverage, faster"?
    • Not yet answered "Faster" is easy to measure; "without losing coverage" is the hard, load-bearing half. Candidate: a deterministic coverage-set diff — enumerate the executed test set (e.g. cargo nextest list / per-job test manifests) and the enabled lint set (cargo clippy's effective lint table) on main vs the optimization branch, and require the diff to be empty-or-additive as a CI check on every C2 PR. Open questions: flaky-test quarantine interaction (removing a flaky test is a coverage change and must be its own reviewed decision, never a side effect of a speedup), whether sharding changes execution order in ways that mask order-dependent tests, and whether feature-flag matrix reductions count as shrinkage (they do — the matrix is part of the set).