Three task kinds
code_fix, code_review, and investigate. Only code_fix can write, and it must be given an explicit write target and branch; read kinds are issued no write token at all.
A standalone, multi-tenant service that runs AI coding tasks against repositories you have explicitly allowlisted, inside isolated per-tenant workspaces. Your product calls one HTTPS API, watches a live transcript, stops or steers the run, and receives a signed terminal callback. The caller proposes; policy disposes; humans merge the pull request.
Allowlisted repos · Isolated workspaces · Signed callbacks · Humans merge PRs
The service is deliberately product-agnostic: consumers integrate over HTTPS with a scoped API key, and no consumer-specific logic lives inside it. Control plane on Python 3.12, FastAPI, and Postgres — the task queue and callback outbox are Postgres-backed, so there is no Redis to operate. Workspaces run on Kubernetes.
code_fix, code_review, and investigate. Only code_fix can write, and it must be given an explicit write target and branch; read kinds are issued no write token at all.
Each tenant carries a repository allowlist managed over the API. The caller proposes a repo and branch and policy disposes — a request outside the allowlist is refused, not attempted.
Every run executes in its own per-tenant workspace that holds no platform credentials, so a compromised run yields nothing reusable against the service or another tenant.
Stream events over SSE using short-TTL stream tokens, backfill the transcript at any time, stop a run outright, or queue steering guidance applied at the next turn boundary.
Every task ends in an HMAC-signed callback — task completion plus pull-request lifecycle events — or in a synthesized failure. Silence is never a valid outcome.
A Postgres-backed outbox tracks each delivery through pending, delivered, failed, and exhausted, with retries and manual redelivery when your endpoint was down.
The worker opens pull requests and never merges them. Review stays exactly where your team already reviews, and merge authority stays with people.
Task listing, event backfill, delivery history, and tenant self-inspection mean any run can be reconstructed after the fact — including the ones that failed.
The contract test harness always exercises a second, synthetic consumer shape alongside the real one, so the API cannot quietly specialise to a single caller.
The same API serves very different callers, because the service knows nothing about their domains — only about tasks, repositories, policy, and callbacks.
A product's feedback module hands a triaged issue to the worker and receives a pull-request link on a signed callback — with the full transcript attached to the report.
code_review runs against allowlisted repositories and returns findings with no write capability whatsoever — useful precisely because it cannot change anything.
investigate explores a repository to answer a question and returns findings. No branch, no write target, no token — the safest kind to hand to on-call.
Internal products each get their own tenant, allowlist, and keys, and integrate over the public API only — no shared database, no bespoke branch per consumer.
We agree the task kinds, repositories, and callback endpoint. The frozen v1 OpenAPI contract and the published signature test vectors are the specification you build against — not a moving target.
Scoped API keys are issued per client alongside a paired callback signing secret. Keys are shown once, stored only as hashes, and split by scope — application keys stay separate from policy administration.
Repository allowlist, permitted write targets, branch rules, and hard wall-clock caps are configured per tenant before the first task is ever created.
You verify your side against the shipped harness — consumer fixtures, deliberate negatives, and signature vectors — so the integration is proven rather than assumed.
Task, event, and delivery history give you the operational view. Credentials rotate by overlap, failed callbacks redeliver on demand, and new task kinds land additively — consumers tolerate unknown kinds by contract.
Representative views of the two surfaces that matter: what your product shows a user while a task runs, and what your platform team watches across tenants.
Your users file an issue; the transcript streams back in your own UI.
Runs, policy decisions, and callback deliveries across every tenant.
No. Each tenant has an explicit repository allowlist. The caller proposes a repository and branch, and policy disposes — anything outside the allowlist is refused rather than attempted. Only code_fix can write, and it must be given a write target and branch; code_review and investigate are issued no write token at all.
Tell us the product, the repositories, and which task kinds you need. We will propose the tenant model, policy allowlist, callback design, and a first integration your engineers can verify against the shipped contract tests before anything touches a real branch.
Saudi-based delivery · Contract-first · Humans merge every PR