brindle 0.2.0__tar.gz → 0.3.0__tar.gz

{brindle-0.2.0 → brindle-0.3.0}/.gitignore

@@ -9,3 +9,4 @@ graphify-out/
 # private, kept local for now
 docs/
 .brindle/config.local.json
+.brindle/bench.json

{brindle-0.2.0 → brindle-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: brindle
-Version: 0.2.0
+Version: 0.3.0
 Summary: Run coding agents in parallel, each on its own git branch, with a supervisor that delegates, reviews, and merges
 Project-URL: Homepage, https://pawdelta.com/brindle/
 Project-URL: Documentation, https://pawdelta.com/brindle/docs/recommended-use
@@ -89,7 +89,7 @@ uv tool install --editable ~/Projects/brindle   # or from a local checkout
 brindle drives Claude Code, so you need that too (`npm install -g @anthropic-ai/claude-code`).
 
 `brindle --version` prints the installed version; the tmux status bar of every brindle
-session shows it too (`brindle 0.2.0`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.0`). A session started before an upgrade keeps
 running the old code, and shows the old number, until you restart it.
 
 ## Quick start
@@ -350,6 +350,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle transfer [REPO] [--from SESSION] [-b BRANCH]` | move a scratch session's work into a real repo |
 | `brindle ls [--all]` | workspaces and agents |
 | `brindle repo add PATH [--name ALIAS] / rm ALIAS / ls` | attach other local repos to the current session so workers can go there (brindle Pro; see "Several repos in one session") |
+| `brindle keys set/unset/list [NAME]` | store model API keys (e.g. `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`) once in the OS keychain (or a 0600 file); every agent pane gets the ones its provider reads, unless you already export it. `set` reads the value from a hidden prompt or stdin, `list` shows names and the last 4 characters. `CLAUDE_CODE_OAUTH_TOKEN` (a Claude subscription token) is never stored |
 | `brindle history [--limit N] [--kind K] [--all]` | durable log of worker results, reviews, merges and milestone checks |
 | `brindle cost [--days N] [--all]` | dollar spend at list prices over the last 30 days, by model |
 | `brindle cost report [--days N] [--all]` | Pro: spend by day, profile and goal, cost per merged branch, review pass rate per worker profile |
@@ -360,7 +361,8 @@ your own status line prints, so what you see doesn't change.
 | `brindle cost requests` | Enterprise: your approval requests and their status; checks pending ones with the server (the cull pass also does, every few minutes). With cost centers, spend events also carry the repo (`owner/name`) so the org can total spend per center |
 | `brindle cost estimate [--tasks N] [--weight W] [--profile P] [--reviewer R]` | what the current goal (or N tasks) is likely to cost, as a range from this repo's history (median to p80 of past worker and review runs), plus a cheaper alternative with a different reviewer; says "low confidence" when there's too little history. Also added to `set_goal` and `assign` replies (brindle Pro) |
 | `brindle learning` | whether brindle Pro's hosted learning is on for this repo, and if not, why (nothing is learned on your machine) |
-| `brindle account [login\|logout\|status\|upgrade\|portal\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
+| `brindle learning seed` | Pro: sends this repo's finished routing history to the hosted learner once, so it starts with what this machine has seen. Only the usual coarse record fields leave (kind/size one-hots, counters, HMAC keys), never task text or paths. A second run sends nothing new; decisions already sent live are skipped |
+| `brindle account [login\|logout\|status\|upgrade\|portal\|seats\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
 | `brindle audit verify\|export\|pubkey\|ship\|prune` | the local tamper-evident audit log, and shipping it to your SIEM (brindle Enterprise; see "Audit log" below) |
 | `brindle watch [--all] [--once]` | the dashboard on its own (the same view as the sidebar): enter attaches, `p` peeks, `x` closes |
 | `brindle sidebar` | bring this session's sidebar into the tmux session you're in (also `Ctrl-b S` in a window without one); restarts it if it was closed |
@@ -525,6 +527,7 @@ Autopilot, merge gates and cleanup:
 | `max_agents` | `4` | workers running at once per session (`0`: no cap) |
 | `check_timeout` | `900` | seconds each check may take |
 | `check_concurrency` | `2` | check runs at once on this machine, across branches; the rest wait their turn (`0`: no cap). A run far past its last duration is reported to the supervisor |
+| `fable_escalation` | on, unless the worker runs on a cloud account (Bedrock, Vertex or Foundry) | retry a failed heavy task once on `developer-heavy` (Fable) before handing it to you; `true` turns it on for a cloud account, `false` off |
 | `usage_limit` | `90` | autopilot stops pushing on at this % of your Claude usage limit |
 | `limit_cooldown_minutes` | `300` for Antigravity | how long a provider that hit its limit counts as unavailable |
 | `graphify` | if the graph is there | point agents at the repo's [graphify](https://github.com/safishamsi/graphify) code map (`false` turns it off) |
@@ -588,9 +591,9 @@ keep theirs):
 ```json
 {
   "routing": {
-    "light":  ["developer", "developer-codex", "developer-local"],
+    "light":  ["developer-light", "developer", "developer-codex", "developer-local"],
     "medium": ["developer", "developer-codex", "developer-heavy"],
-    "heavy":  ["developer-heavy", "developer", "developer-codex"]
+    "heavy":  ["developer", "developer-heavy", "developer-codex"]
   }
 }
 ```
@@ -598,7 +601,9 @@ keep theirs):
 No tier prefers another provider for its own sake: all-Claude or all-Codex may
 be what works best for you, and that's for the learner to find out.
 
-`developer-codex` runs on Codex; `developer-heavy` on Claude Fable at high effort.
+`developer-light` runs on Claude Haiku at low effort; `developer` on your Claude
+Code default model; `developer-codex` on Codex; `developer-heavy` on Claude Fable
+at high effort.
 A profile is skipped when its CLI isn't installed (`claude`, `codex`, `agy`), the
 local model server isn't answering, or its provider is at your `usage_limit`. If
 hosted learning is on it chooses among the profiles left; otherwise the first
@@ -761,7 +766,9 @@ brindle account login      # opens your browser to sign in (--device: enter a co
 brindle account status     # your plan, features, hosted learning on or off, when the entitlement expires
 brindle account savings    # what hosted learning's picks gained in this repo, this month and last: estimates, from this machine's records only
 brindle account upgrade    # opens the checkout for brindle Pro (and prints its URL)
-brindle account portal     # opens the billing portal (invoices, seats, cancellation); --org ORG for a team org
+brindle account upgrade --enterprise [--trial] --seats N --org ORG   # brindle Enterprise for a team org; --trial: free trial, at most 10 seats
+brindle account portal     # opens the billing portal (invoices, payment method, cancellation); --org ORG for a team org
+brindle account seats N    # set a Team or Enterprise org's seat count (billing admin); --org ORG; Stripe prorates the change
 brindle account org list   # the orgs you belong to; `org use <id>` switches, `org policy` shows the current one
 brindle account org policy # the org's policy, its per-role overrides, and the policy that applies to you
 brindle account org profiles                                  # the org's shared profiles and rule packs, and which are pinned
@@ -824,6 +831,16 @@ entitlement.
 * `deny_personal_keys`: the personal model keys (`ANTHROPIC_API_KEY`,
   `OPENAI_API_KEY`, ...) are taken out of every agent pane, and a profile that
   sets one is refused.
+* An org-owned key: with `provider` `anthropic` (or `openai-compatible`), set
+  `key_env` to the name of a variable that holds the org's key (not a personal
+  one like `ANTHROPIC_API_KEY`), or `key_helper` to a command, as a list of
+  arguments, that prints the key (for example `["vault", "kv", "get",
+  "-field=key", "secret/anthropic"]`). brindle runs the helper on the person's
+  machine, without a shell and with a timeout, each time a worker starts, and
+  gives the key to that worker as `ANTHROPIC_API_KEY` (`OPENAI_API_KEY` for
+  Codex). It passes `deny_personal_keys`; a personal key doesn't. The key never
+  goes through brindle's servers. When the variable is missing or the helper
+  fails, the worker doesn't start.
 
 Two things to know when you turn on `deny_personal_keys`:
 
@@ -984,17 +1001,31 @@ workflows call these commands:
   commits the workflows on a `brindle/ci-setup` branch, then puts you back on
   the branch you started on and deletes the local setup branch, so `git pull`
   after merging the setup pull request is clean (commit or stash your changes
-  first: it refuses to start with uncommitted work).
+  first: it refuses to start with uncommitted work). With your own cloud
+  (`--credential bedrock|vertex|foundry`, keyless GitHub OIDC) it can read the
+  IDs from the deployment template's outputs instead of asking:
+  `--from-stack NAME [--region R]` (AWS CloudFormation), `--from-terraform DIR`
+  (Google) or `--from-deployment NAME -g RG` (Azure). They are defaults for
+  `--cloud-var`, which still overrides them, and every ID is format-checked. A
+  missing `aws`, `terraform` or `az` CLI or output is an error that names the
+  `--cloud-var` to pass instead. Vertex AI and Microsoft Foundry are in
+  **preview** (not yet verified end to end): `init` refuses them unless you pass
+  `--preview` or set `BRINDLE_CI_PREVIEW_CLOUDS=1`, and `doctor` marks them
+  `(preview)`. Bedrock is generally available.
 - `brindle ci doctor`: which provider CLIs and credential names a runner has, and
-  which providers CI may use on this repository.
+  which providers CI may use on this repository. `--models` also makes one tiny
+  call per pinned model and says why any is refused (a quota, a form not filled in).
 - `brindle ci start`: start a run for an issue, a goal text or a dispatched run,
   or a validation of a pull request.
 - `brindle ci run`: run what was started: the supervisor and the result upload,
   or the pull request's checks and reviews and the evidence upload.
 - `brindle ci report`: tell the service how the workflow's jobs ended.
 
-Credential names are reported, never values. On a repository owned by a GitHub
-organization, a provider signed in only with a personal subscription is not used.
+Credential names are reported, never values. CI uses API keys, cloud sign-ins
+(Bedrock, Vertex, Foundry) or identity federation only: a provider signed in
+only with a subscription (`CLAUDE_CODE_OAUTH_TOKEN`, a Codex ChatGPT login) is
+not used, on personal and organization repositories alike. Add an API key
+secret instead.
 
 Fix builds only fix the default branch's *required* status checks, and a new
 repository has none. When the default branch requires none, `brindle ci init`
@@ -1239,6 +1270,16 @@ needs no browser step. Put the key in your environment, or in a profile's
 `brindle doctor` names the variable each CLI gets, from your shell or from
 which profiles.
 
+A profile chooses between the two with `auth`:
+
+| `auth:` | What the worker signs in with |
+|---|---|
+| `auto` (default) | A key from your environment or `brindle keys` if there is one, else the CLI's own login. |
+| `subscription` | Always the CLI's own login: brindle strips that provider's API keys from the pane. |
+| `api_key` | Only a key: the worker refuses to start without one. |
+
+Your org's `deny_personal_keys` (Enterprise) still applies on top of `auth`.
+
 ### Cheap workers
 
 By default a Claude Code worker loads everything your own `claude` does: your

{brindle-0.2.0 → brindle-0.3.0}/README.md

@@ -59,7 +59,7 @@ uv tool install --editable ~/Projects/brindle   # or from a local checkout
 brindle drives Claude Code, so you need that too (`npm install -g @anthropic-ai/claude-code`).
 
 `brindle --version` prints the installed version; the tmux status bar of every brindle
-session shows it too (`brindle 0.2.0`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.0`). A session started before an upgrade keeps
 running the old code, and shows the old number, until you restart it.
 
 ## Quick start
@@ -320,6 +320,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle transfer [REPO] [--from SESSION] [-b BRANCH]` | move a scratch session's work into a real repo |
 | `brindle ls [--all]` | workspaces and agents |
 | `brindle repo add PATH [--name ALIAS] / rm ALIAS / ls` | attach other local repos to the current session so workers can go there (brindle Pro; see "Several repos in one session") |
+| `brindle keys set/unset/list [NAME]` | store model API keys (e.g. `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`) once in the OS keychain (or a 0600 file); every agent pane gets the ones its provider reads, unless you already export it. `set` reads the value from a hidden prompt or stdin, `list` shows names and the last 4 characters. `CLAUDE_CODE_OAUTH_TOKEN` (a Claude subscription token) is never stored |
 | `brindle history [--limit N] [--kind K] [--all]` | durable log of worker results, reviews, merges and milestone checks |
 | `brindle cost [--days N] [--all]` | dollar spend at list prices over the last 30 days, by model |
 | `brindle cost report [--days N] [--all]` | Pro: spend by day, profile and goal, cost per merged branch, review pass rate per worker profile |
@@ -330,7 +331,8 @@ your own status line prints, so what you see doesn't change.
 | `brindle cost requests` | Enterprise: your approval requests and their status; checks pending ones with the server (the cull pass also does, every few minutes). With cost centers, spend events also carry the repo (`owner/name`) so the org can total spend per center |
 | `brindle cost estimate [--tasks N] [--weight W] [--profile P] [--reviewer R]` | what the current goal (or N tasks) is likely to cost, as a range from this repo's history (median to p80 of past worker and review runs), plus a cheaper alternative with a different reviewer; says "low confidence" when there's too little history. Also added to `set_goal` and `assign` replies (brindle Pro) |
 | `brindle learning` | whether brindle Pro's hosted learning is on for this repo, and if not, why (nothing is learned on your machine) |
-| `brindle account [login\|logout\|status\|upgrade\|portal\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
+| `brindle learning seed` | Pro: sends this repo's finished routing history to the hosted learner once, so it starts with what this machine has seen. Only the usual coarse record fields leave (kind/size one-hots, counters, HMAC keys), never task text or paths. A second run sends nothing new; decisions already sent live are skipped |
+| `brindle account [login\|logout\|status\|upgrade\|portal\|seats\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
 | `brindle audit verify\|export\|pubkey\|ship\|prune` | the local tamper-evident audit log, and shipping it to your SIEM (brindle Enterprise; see "Audit log" below) |
 | `brindle watch [--all] [--once]` | the dashboard on its own (the same view as the sidebar): enter attaches, `p` peeks, `x` closes |
 | `brindle sidebar` | bring this session's sidebar into the tmux session you're in (also `Ctrl-b S` in a window without one); restarts it if it was closed |
@@ -495,6 +497,7 @@ Autopilot, merge gates and cleanup:
 | `max_agents` | `4` | workers running at once per session (`0`: no cap) |
 | `check_timeout` | `900` | seconds each check may take |
 | `check_concurrency` | `2` | check runs at once on this machine, across branches; the rest wait their turn (`0`: no cap). A run far past its last duration is reported to the supervisor |
+| `fable_escalation` | on, unless the worker runs on a cloud account (Bedrock, Vertex or Foundry) | retry a failed heavy task once on `developer-heavy` (Fable) before handing it to you; `true` turns it on for a cloud account, `false` off |
 | `usage_limit` | `90` | autopilot stops pushing on at this % of your Claude usage limit |
 | `limit_cooldown_minutes` | `300` for Antigravity | how long a provider that hit its limit counts as unavailable |
 | `graphify` | if the graph is there | point agents at the repo's [graphify](https://github.com/safishamsi/graphify) code map (`false` turns it off) |
@@ -558,9 +561,9 @@ keep theirs):
 ```json
 {
   "routing": {
-    "light":  ["developer", "developer-codex", "developer-local"],
+    "light":  ["developer-light", "developer", "developer-codex", "developer-local"],
     "medium": ["developer", "developer-codex", "developer-heavy"],
-    "heavy":  ["developer-heavy", "developer", "developer-codex"]
+    "heavy":  ["developer", "developer-heavy", "developer-codex"]
   }
 }
 ```
@@ -568,7 +571,9 @@ keep theirs):
 No tier prefers another provider for its own sake: all-Claude or all-Codex may
 be what works best for you, and that's for the learner to find out.
 
-`developer-codex` runs on Codex; `developer-heavy` on Claude Fable at high effort.
+`developer-light` runs on Claude Haiku at low effort; `developer` on your Claude
+Code default model; `developer-codex` on Codex; `developer-heavy` on Claude Fable
+at high effort.
 A profile is skipped when its CLI isn't installed (`claude`, `codex`, `agy`), the
 local model server isn't answering, or its provider is at your `usage_limit`. If
 hosted learning is on it chooses among the profiles left; otherwise the first
@@ -731,7 +736,9 @@ brindle account login      # opens your browser to sign in (--device: enter a co
 brindle account status     # your plan, features, hosted learning on or off, when the entitlement expires
 brindle account savings    # what hosted learning's picks gained in this repo, this month and last: estimates, from this machine's records only
 brindle account upgrade    # opens the checkout for brindle Pro (and prints its URL)
-brindle account portal     # opens the billing portal (invoices, seats, cancellation); --org ORG for a team org
+brindle account upgrade --enterprise [--trial] --seats N --org ORG   # brindle Enterprise for a team org; --trial: free trial, at most 10 seats
+brindle account portal     # opens the billing portal (invoices, payment method, cancellation); --org ORG for a team org
+brindle account seats N    # set a Team or Enterprise org's seat count (billing admin); --org ORG; Stripe prorates the change
 brindle account org list   # the orgs you belong to; `org use <id>` switches, `org policy` shows the current one
 brindle account org policy # the org's policy, its per-role overrides, and the policy that applies to you
 brindle account org profiles                                  # the org's shared profiles and rule packs, and which are pinned
@@ -794,6 +801,16 @@ entitlement.
 * `deny_personal_keys`: the personal model keys (`ANTHROPIC_API_KEY`,
   `OPENAI_API_KEY`, ...) are taken out of every agent pane, and a profile that
   sets one is refused.
+* An org-owned key: with `provider` `anthropic` (or `openai-compatible`), set
+  `key_env` to the name of a variable that holds the org's key (not a personal
+  one like `ANTHROPIC_API_KEY`), or `key_helper` to a command, as a list of
+  arguments, that prints the key (for example `["vault", "kv", "get",
+  "-field=key", "secret/anthropic"]`). brindle runs the helper on the person's
+  machine, without a shell and with a timeout, each time a worker starts, and
+  gives the key to that worker as `ANTHROPIC_API_KEY` (`OPENAI_API_KEY` for
+  Codex). It passes `deny_personal_keys`; a personal key doesn't. The key never
+  goes through brindle's servers. When the variable is missing or the helper
+  fails, the worker doesn't start.
 
 Two things to know when you turn on `deny_personal_keys`:
 
@@ -954,17 +971,31 @@ workflows call these commands:
   commits the workflows on a `brindle/ci-setup` branch, then puts you back on
   the branch you started on and deletes the local setup branch, so `git pull`
   after merging the setup pull request is clean (commit or stash your changes
-  first: it refuses to start with uncommitted work).
+  first: it refuses to start with uncommitted work). With your own cloud
+  (`--credential bedrock|vertex|foundry`, keyless GitHub OIDC) it can read the
+  IDs from the deployment template's outputs instead of asking:
+  `--from-stack NAME [--region R]` (AWS CloudFormation), `--from-terraform DIR`
+  (Google) or `--from-deployment NAME -g RG` (Azure). They are defaults for
+  `--cloud-var`, which still overrides them, and every ID is format-checked. A
+  missing `aws`, `terraform` or `az` CLI or output is an error that names the
+  `--cloud-var` to pass instead. Vertex AI and Microsoft Foundry are in
+  **preview** (not yet verified end to end): `init` refuses them unless you pass
+  `--preview` or set `BRINDLE_CI_PREVIEW_CLOUDS=1`, and `doctor` marks them
+  `(preview)`. Bedrock is generally available.
 - `brindle ci doctor`: which provider CLIs and credential names a runner has, and
-  which providers CI may use on this repository.
+  which providers CI may use on this repository. `--models` also makes one tiny
+  call per pinned model and says why any is refused (a quota, a form not filled in).
 - `brindle ci start`: start a run for an issue, a goal text or a dispatched run,
   or a validation of a pull request.
 - `brindle ci run`: run what was started: the supervisor and the result upload,
   or the pull request's checks and reviews and the evidence upload.
 - `brindle ci report`: tell the service how the workflow's jobs ended.
 
-Credential names are reported, never values. On a repository owned by a GitHub
-organization, a provider signed in only with a personal subscription is not used.
+Credential names are reported, never values. CI uses API keys, cloud sign-ins
+(Bedrock, Vertex, Foundry) or identity federation only: a provider signed in
+only with a subscription (`CLAUDE_CODE_OAUTH_TOKEN`, a Codex ChatGPT login) is
+not used, on personal and organization repositories alike. Add an API key
+secret instead.
 
 Fix builds only fix the default branch's *required* status checks, and a new
 repository has none. When the default branch requires none, `brindle ci init`
@@ -1209,6 +1240,16 @@ needs no browser step. Put the key in your environment, or in a profile's
 `brindle doctor` names the variable each CLI gets, from your shell or from
 which profiles.
 
+A profile chooses between the two with `auth`:
+
+| `auth:` | What the worker signs in with |
+|---|---|
+| `auto` (default) | A key from your environment or `brindle keys` if there is one, else the CLI's own login. |
+| `subscription` | Always the CLI's own login: brindle strips that provider's API keys from the pane. |
+| `api_key` | Only a key: the worker refuses to start without one. |
+
+Your org's `deny_personal_keys` (Enterprise) still applies on top of `auth`.
+
 ### Cheap workers
 
 By default a Claude Code worker loads everything your own `claude` does: your

{brindle-0.2.0 → brindle-0.3.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "brindle"
-version = "0.2.0"
+version = "0.3.0"
 description = "Run coding agents in parallel, each on its own git branch, with a supervisor that delegates, reviews, and merges"
 readme = "README.md"
 requires-python = ">=3.11"
@@ -52,6 +52,8 @@ audit_export = "brindle.pro.audit_export:make"
 dev = [
     "pytest>=8",
     "pytest-xdist>=3.8.0",
+    "python-hcl2>=8.1.4",
+    "pyyaml>=6.0.3",
 ]
 
 [build-system]