Roadmap¶
kew's job is to be the governance layer that follows you down the stack — the same control machinery (budgets, audit, policy, kill switch) applied at every layer: agents now, infrastructure next, models last.
The vendors are building governance too — metering, spend caps, approval flows — each inside their own walls. kew's claim is the quadrant they structurally don't serve: self-hosted, cross-runner, aware of runs and outcomes rather than API calls, and able to follow you to models on your own hardware. If your governance lives in one vendor's console, it governs one vendor.
Every roadmap item passes one test: does it extend governance, ownership, or trust to a new actor, a new origin, or a new standard of proof? Items that only add orchestration breadth — more parallelism, more dashboards — don't make the list.
This roadmap is public on purpose. Items get claimed when they ship, not before — if something below slips or dies, you'll see that too.
Layer 1 — Agents (shipped, deepening)¶
Already live: three-tier budget caps enforced at dispatch with an automatic circuit breaker (#245), the fleet kill switch (kew stop / kew resume), approval gates above an estimated cost threshold, outcome-linked spend reporting (kew report, cost per merged PR), structured audit logging, worktree isolation, a security hook on agent commands, and first-class loops — kew dispatch <issue> --loop drives a governed agent session to a verified, observable close (Flight Recorder, ci-green stop condition, pause/resume/reassign, budget watchdog).
M1 — Launch window (complete)¶
Small on purpose: the schema, defined once.
| Item | Issue |
|---|---|
| Audit envelope — who acted, which repo spent, and the configured inference endpoint, recorded on every governance event from birth; later milestones fill fields instead of migrating shape | #246 ✓ |
| Report integration: killed runs + approval holds | #238 ✓ |
| Outcome persistence — store what happened to the work (merged, review cycles, diff stats), because you can't retroactively measure outcomes you never kept | #261 ✓ |
M2 — Post-launch hardening (complete)¶
| Item | Issue |
|---|---|
| Automatic circuit breaker — estimated mid-run spend breaching its ceiling (or far outrunning historical medians) trips the kill switch from the dispatching process, backed by runner-level caps and wall-clock triggers for unpriced local models | #245 ✓ |
| Cache-aware pricing — estimates the breaker can trust | #255 ✓ |
kew health — the control plane attests to itself: meter running, budgets enforced, audit intact |
#247 ✓ |
| Remote approve/deny — report delivery to webhook/Slack with approval actions, so the gate's holder isn't terminal-bound | #236 ✓ |
M3 — Tamper-evidence (complete — 5/5)¶
Logs satisfy operators; tamper-evidence is the next standard of proof. Honest scoping: an unanchored hash chain on your own disk is integrity checking — anchoring the chain head externally is what makes it worth showing anyone else, and it's in scope.
| Item | Issue |
|---|---|
Hash-chained audit log + kew audit verify, chain head anchored outside the operator's disk |
#249 ✓ |
| Policy binding — every dispatch records a hash of the (redacted) governance policy in force, including the deployed security hook | #250 ✓ |
| Endpoint enrichment — record what runners were configured to hit and what they report: the first brick of egress accounting, not network-level attestation | #251 ✓ |
| Cross-runner ingestion — one self-hosted record across dispatched and interactive usage, via Claude Code's documented OTel export. Alerts against your caps; passive observation doesn't pretend to enforce | #256 ✓ |
M4 — The governor's surface (complete — 3/3)¶
| Item | Issue |
|---|---|
Approval inbox — kew's first network listener, treated as such: read views plus exactly two authenticated writes (approve, stop). Token → session-cookie auth, CSRF + Origin checks, loopback-by-default with an explicit --expose opt-in; web approvals are identically policy-bound to CLI approvals |
#252 ✓ |
| TUI approve dialog | #237 ✓ |
| Model scorecard — merge rate, review iterations, cost per merged PR, by model: outcome-linked comparison from your fleet, not a benchmark | #262 ✓ |
M5 — The sovereign dispatch¶
Layer 2, earned: the proof artifact is one issue dispatched twice — a frontier model and a model on your own hardware — under identical governance, ending in one record.
| Item | Issue |
|---|---|
| Rate-card budgets — caps in tokens/GPU-minutes with bring-your-own shadow pricing, so models that don't bill you are still governed | #257 |
| Governed-local parity — prove the local path end to end: caps bind, gate fires, kill switch works, record filled | #258 |
Routing by sensitivity — sensitive work routes local-only by policy, or holds; never silently to cloud |
#259 |
| The sovereign dispatch demo — reproducible, documented, one report showing both runs | #260 |
Operational maturity¶
A tool that sells trust doesn't get to treat its own posture as an afterthought. These ship inside the milestones above:
| Item | Milestone | Issue |
|---|---|---|
| SECURITY.md + published threat model — including what kew does not defend against | M1 | #263 ✓ |
| CONTRIBUTING.md + dispatchable issue templates — community issues feed the same queue kew drains | M1 | #264 ✓ |
| Runner-compatibility canary — a vendor CLI update must never mean silently wrong metering | M2 | #265 ✓ |
| Supply-chain posture — SBOM, release attestations, license checks | M2 | #266 ✓ |
| Audit-data durability — backup/restore/WAL; a chain over data that dies with a disk is not a record | M3 | #267 ✓ |
Layer 2 — Infrastructure (earned next, not claimed yet)¶
The bridge is identical governance across cloud and local: the same caps, audit, and policy whether the agent calls a frontier model or one on your own hardware. M1's endpoint field and M3's enrichment are the first bricks; M5 is the layer earned. Beyond it: an air-gapped mode with verifiable egress controls, and a self-hostable control plane hardened for the same standard. These ship before they're marketed.
Layer 3 — Models (the long game)¶
Quality/eval gates per model feeding routing; dispatch outcomes as a feedback corpus; eventually a local fine-tune loop specialized on your codebase. The corpus seed (M1 outcome persistence) and its visible face (the M4 scorecard) are deliberately early — everything else here is listed for direction, claimed when an artifact exists, not before.
Sequencing is honest-best-effort by a solo maintainer. Milestones here are scope commitments, not date commitments — dates appear on releases, after the fact; the order can shuffle, but the test at the top of this page does not. The spine deepens a little with every release; it does not chase orchestration parity. Issues and PRs welcome.