brindle 0.3.5__tar.gz → 0.3.8__tar.gz

{brindle-0.3.5 → brindle-0.3.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: brindle
-Version: 0.3.5
+Version: 0.3.8
 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.3.5`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.8`). A session started before an upgrade keeps
 running the old code, and shows the old number, until you restart it.
 
 ## Quick start
@@ -118,11 +118,11 @@ a writable home) and, in a repo, what's set up for it, and says what to do about
 anything missing. Bare `brindle` runs the essential ones (tmux, the chat's CLI)
 before it launches anything.
 
-That's it. Bare `brindle` opens a fresh interactive developer chat (Claude Code)
-in your repo (with autopilot off), with a narrow sidebar on the left showing every
-agent: who's working, who's idle, and who's waiting for your approval. To launch an
-autopilot supervisor that splits work between parallel workers, reviews, and merges
-their branches toward verified milestones, run `brindle supervisor`. It starts in under a second.
+That's it. `brindle` opens a supervisor chat (Claude Code) in your repo, with a
+narrow sidebar on the left showing every agent: who's working, who's idle, and
+who's waiting for your approval. Tell the supervisor what you want. It splits the
+work between workers, each on its own branch, then reviews and merges their
+branches. It starts in under a second.
 
 **The sidebar follows you.** There's one sidebar pane per session root, not
 one per window: switch to any other brindle window or session (⏎ in the
@@ -200,7 +200,7 @@ it from. When the work belongs in a real repository, run `brindle transfer ~/pat
 merge. Running `brindle` in a repo also offers to bring in any scratch work that hasn't
 been moved yet.
 
-Or drive a single workspace yourself:
+Or give a supervisor its own workspace:
 
 ```sh
 brindle new fix-login -p "Fix the login redirect bug; add a test"
@@ -242,7 +242,7 @@ for mechanical edits and a Codex reviewer for a second model's opinion.
 
 ## Autopilot
 
-`brindle supervisor` starts the supervisor with autopilot on (or `brindle start -a supervisor`). Tell it what we're building,
+`brindle` starts the supervisor with autopilot on. Tell it what we're building,
 or put the goal in `.brindle/goals.md`, and it works like a project manager:
 
 1. **Goal and milestones.** The goal is split into milestones, and each one has
@@ -337,14 +337,14 @@ your own status line prints, so what you see doesn't change.
 
 | | |
 |---|---|
-| `brindle` | a fresh developer chat here (autopilot off), dashboard alongside |
-| `brindle supervisor` | start an explicit autopilot supervisor chat to coordinate parallel workers and milestones |
+| `brindle` | a fresh supervisor chat here, dashboard alongside |
+| `brindle supervisor` | the same, with `--branch`/`--worktree` to run it in another worktree |
 | `brindle init` | detect setup and test commands, write `.brindle/config.json`, check tools |
 | `brindle demo [--local]` | watch brindle finish a tiny practice repo: parallel workers, reviews, gated merges |
-| `brindle new BRANCH [-b BASE] [-a PROFILE] [-p PROMPT]` | worktree + branch + agent |
+| `brindle new BRANCH [-b BASE] [-p PROMPT] [--no-agent]` | worktree + branch + a supervisor in it |
 | `brindle continue [ID]` / `brindle -c` | resume a paused session (default: the most recent) |
 | `brindle sessions` / `brindle prune` | list paused sessions / apply retention rules, remove merged or missing worktrees, close stale stopped agents whose work is merged or gone, and remove leftover tmux sessions |
-| `brindle start [-a PROFILE] [-p PROMPT] [--no-watch] [--no-autopilot] [-b BRANCH] [-w PATH]` | the same, with options; `-b`/`-w` run it in that branch's worktree (created if needed, or the one you already made), which gets the repo's `.brindle` config |
+| `brindle start [-p PROMPT] [--no-watch] [--no-autopilot] [-b BRANCH] [-w PATH]` | the same, with options; `-b`/`-w` run it in that branch's worktree (created if needed, or the one you already made), which gets the repo's `.brindle` config |
 | `brindle handover --to BRANCH\|PATH [-n NOTE]` | hand the session to a new supervisor there: goal and milestones, workers, queued tasks and your note move across; the old one is paused |
 | `brindle autopilot [on\|off\|check]` | the goal's progress; turn autopilot on or off; run the checks now |
 | `brindle audit-decision FINDING [-r RATIONALE]` | record acceptance of an audit finding with rationale so subsequent audits respect it |
@@ -378,7 +378,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle doctor` | check that brindle has what it needs (tmux, the agent CLIs, native profiles' model endpoints, a writable home) and, in a repo, its config, checks and code map |
 | `brindle close AGENT` / `brindle close --exited` | hide an agent (or every stopped one) from the dashboard, stopping it if it's running; its worktree and branch stay |
 | `brindle send AGENT MSG` | message an agent; waits in its inbox until it's idle |
-| `brindle agent spawn/kill/peek/profiles` | manage agents |
+| `brindle agent kill/peek/profiles` | manage agents (only a supervisor starts them) |
 | `brindle profile new/lint/show` | write a profile file, check every profile (extends chains, rule packs, patterns), or print one as brindle resolves it |
 | `brindle rules suggest/accept/reject` | (brindle Pro) rules suggested from review findings that keep recurring; accept one into `.brindle/rules/learned.md`, or reject it for good |
 | `brindle agent turns AGENT` / `brindle agent rewind AGENT --to N [--profile P] [--note "..."]` | a worker's worktree is snapshotted after every turn that changed files; rewind puts it back as it was after turn N and starts a fresh session there, briefed on the task, turns 1..N and your note (any provider, Codex included). Supervisors have the `agent_turns` and `rewind_agent` tools |
@@ -871,7 +871,7 @@ how to use them, and the next step to get the rest:
 | per-member budgets, pause, and admin messages (sidebar "Messages", the bottom bar, `brindle org messages`) | Team | `brindle org messages [--keep]` lists and marks read the notices your admins sent you; a pause refuses new workers and stops running ones |
 | audit log, air-gap | Enterprise | `brindle audit verify`, `"airgap": true` |
 | audit export | Enterprise | `"audit_export"` in `~/.brindle/config.json`, `brindle audit ship` |
-| managed models | Enterprise | `provider_config`, `deny_personal_keys` in your org policy (see "Managed models" below) |
+| managed models | Enterprise | `agent_setup` routes with `enforce`, and `deny_personal_keys`, in your org policy (see "Managed models" below) |
 | wider CI, cost centers, managed rollout | Enterprise | `brindle ci init --host gitlab`, `brindle cost request`, and `min_version`, required packs and the kill switch in your org policy; admins can also shut down or throttle a member, role or org remotely (it arrives within about a minute) |
 
 `brindle ci init` checks your plan before it changes anything: it refuses
@@ -981,20 +981,40 @@ file names, paths or branch names. See `src/brindle/pro/learning.py` and
 
 ### Managed models (brindle Enterprise)
 
-An org policy can pick the provider its workers run on and keep people's own
-model keys out of their panes. Both fields are ignored without the Enterprise
+An org policy can pick the route its workers run on and keep people's own
+model keys out of their panes. All of this is ignored without the Enterprise
 entitlement.
 
-* `provider_config`: `provider` (`bedrock`, `vertex`, `azure` or
-  `openai-compatible`), plus `region`, `model_ids` and `endpoint` as the
-  provider needs them. For `vertex` set `project` to the GCP project id
-  (brindle passes it to Claude Code as `ANTHROPIC_VERTEX_PROJECT_ID`; an older
-  policy that put the project id in `endpoint` still works). Every agent is
-  launched on that provider, and a profile that points somewhere else is
-  refused with a message saying why.
-* `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.
+* The routes live in the policy's `agent_setup` block (the same one `brindle
+  login` applies, see "Using your company's access"), one per agent. With
+  `enforce` on, an agent whose route points at a cloud or an endpoint of the
+  org's is managed: Claude Code on `bedrock` (`aws.region`; the SSO group
+  `sso_start_url`, `sso_region`, `account_id` and `role_name` is optional, all
+  four or none, and without it your own AWS sign-in applies), `vertex`
+  (`gcp.project`, `gcp.region`), `foundry` (`azure.resource` with its
+  `subscription_id`, or `azure.base_url`, the endpoint) or `gateway`
+  (`gateway.base_url`), with `model_ids` (the ids the route serves) and
+  `default_model` (what panes start on, `ANTHROPIC_MODEL`); Codex on `azure`
+  or `gateway` with `codex.base_url` (`OPENAI_BASE_URL`). The route's
+  variables are the top layer of every pane's environment, a profile that
+  points somewhere else is refused with a message saying why, and the
+  identity is checked at launch. With `exclusive` on as well, an agent the
+  block gives no route at all is refused (Claude Code or Codex with no entry,
+  and always native and Antigravity); without it such an agent runs
+  unmanaged (use `allowed_providers` to keep it out). Without `enforce` the
+  same block is sign-in help only.
+* `provider_config` is the older, org-wide form of the same thing: `provider`
+  (`bedrock`, `vertex`, `azure` or `openai-compatible`), plus `region`,
+  `model_ids` and `endpoint` as the provider needs them (for `vertex`,
+  `project`; an older policy that put the project id in `endpoint` still
+  works). The server now converts it into `agent_setup` routes (with
+  `exclusive` on) and keeps deriving it for older clients; this client reads
+  it whenever `agent_setup` has no `exclusive` field (a server older than
+  routing in `agent_setup`) or routes nothing. An old
+  `provider_config` and its `agent_setup` form give panes the same variables.
+* `deny_personal_keys` (in `agent_setup`, or the policy's top-level field):
+  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
@@ -1013,10 +1033,9 @@ Two things to know when you turn on `deny_personal_keys`:
   `api_key_env` to the name of a variable that holds the org's key (not
   `OPENAI_API_KEY`).
 * It can't block a Claude subscription or keychain login by itself: Claude
-  Code signs in on its own, outside the variables brindle removes. Only a
-  `provider_config` that routes Claude Code to Bedrock, Vertex or Foundry
-  (`azure`) keeps it off that login. Always pair `deny_personal_keys` with a
-  `provider_config`.
+  Code signs in on its own, outside the variables brindle removes. Only an
+  enforced route that takes Claude Code to Bedrock, Vertex or Foundry keeps
+  it off that login. Always pair `deny_personal_keys` with one.
 
 ### Air-gapped mode (brindle Enterprise)
 

{brindle-0.3.5 → brindle-0.3.8}/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.3.5`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.8`). A session started before an upgrade keeps
 running the old code, and shows the old number, until you restart it.
 
 ## Quick start
@@ -88,11 +88,11 @@ a writable home) and, in a repo, what's set up for it, and says what to do about
 anything missing. Bare `brindle` runs the essential ones (tmux, the chat's CLI)
 before it launches anything.
 
-That's it. Bare `brindle` opens a fresh interactive developer chat (Claude Code)
-in your repo (with autopilot off), with a narrow sidebar on the left showing every
-agent: who's working, who's idle, and who's waiting for your approval. To launch an
-autopilot supervisor that splits work between parallel workers, reviews, and merges
-their branches toward verified milestones, run `brindle supervisor`. It starts in under a second.
+That's it. `brindle` opens a supervisor chat (Claude Code) in your repo, with a
+narrow sidebar on the left showing every agent: who's working, who's idle, and
+who's waiting for your approval. Tell the supervisor what you want. It splits the
+work between workers, each on its own branch, then reviews and merges their
+branches. It starts in under a second.
 
 **The sidebar follows you.** There's one sidebar pane per session root, not
 one per window: switch to any other brindle window or session (⏎ in the
@@ -170,7 +170,7 @@ it from. When the work belongs in a real repository, run `brindle transfer ~/pat
 merge. Running `brindle` in a repo also offers to bring in any scratch work that hasn't
 been moved yet.
 
-Or drive a single workspace yourself:
+Or give a supervisor its own workspace:
 
 ```sh
 brindle new fix-login -p "Fix the login redirect bug; add a test"
@@ -212,7 +212,7 @@ for mechanical edits and a Codex reviewer for a second model's opinion.
 
 ## Autopilot
 
-`brindle supervisor` starts the supervisor with autopilot on (or `brindle start -a supervisor`). Tell it what we're building,
+`brindle` starts the supervisor with autopilot on. Tell it what we're building,
 or put the goal in `.brindle/goals.md`, and it works like a project manager:
 
 1. **Goal and milestones.** The goal is split into milestones, and each one has
@@ -307,14 +307,14 @@ your own status line prints, so what you see doesn't change.
 
 | | |
 |---|---|
-| `brindle` | a fresh developer chat here (autopilot off), dashboard alongside |
-| `brindle supervisor` | start an explicit autopilot supervisor chat to coordinate parallel workers and milestones |
+| `brindle` | a fresh supervisor chat here, dashboard alongside |
+| `brindle supervisor` | the same, with `--branch`/`--worktree` to run it in another worktree |
 | `brindle init` | detect setup and test commands, write `.brindle/config.json`, check tools |
 | `brindle demo [--local]` | watch brindle finish a tiny practice repo: parallel workers, reviews, gated merges |
-| `brindle new BRANCH [-b BASE] [-a PROFILE] [-p PROMPT]` | worktree + branch + agent |
+| `brindle new BRANCH [-b BASE] [-p PROMPT] [--no-agent]` | worktree + branch + a supervisor in it |
 | `brindle continue [ID]` / `brindle -c` | resume a paused session (default: the most recent) |
 | `brindle sessions` / `brindle prune` | list paused sessions / apply retention rules, remove merged or missing worktrees, close stale stopped agents whose work is merged or gone, and remove leftover tmux sessions |
-| `brindle start [-a PROFILE] [-p PROMPT] [--no-watch] [--no-autopilot] [-b BRANCH] [-w PATH]` | the same, with options; `-b`/`-w` run it in that branch's worktree (created if needed, or the one you already made), which gets the repo's `.brindle` config |
+| `brindle start [-p PROMPT] [--no-watch] [--no-autopilot] [-b BRANCH] [-w PATH]` | the same, with options; `-b`/`-w` run it in that branch's worktree (created if needed, or the one you already made), which gets the repo's `.brindle` config |
 | `brindle handover --to BRANCH\|PATH [-n NOTE]` | hand the session to a new supervisor there: goal and milestones, workers, queued tasks and your note move across; the old one is paused |
 | `brindle autopilot [on\|off\|check]` | the goal's progress; turn autopilot on or off; run the checks now |
 | `brindle audit-decision FINDING [-r RATIONALE]` | record acceptance of an audit finding with rationale so subsequent audits respect it |
@@ -348,7 +348,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle doctor` | check that brindle has what it needs (tmux, the agent CLIs, native profiles' model endpoints, a writable home) and, in a repo, its config, checks and code map |
 | `brindle close AGENT` / `brindle close --exited` | hide an agent (or every stopped one) from the dashboard, stopping it if it's running; its worktree and branch stay |
 | `brindle send AGENT MSG` | message an agent; waits in its inbox until it's idle |
-| `brindle agent spawn/kill/peek/profiles` | manage agents |
+| `brindle agent kill/peek/profiles` | manage agents (only a supervisor starts them) |
 | `brindle profile new/lint/show` | write a profile file, check every profile (extends chains, rule packs, patterns), or print one as brindle resolves it |
 | `brindle rules suggest/accept/reject` | (brindle Pro) rules suggested from review findings that keep recurring; accept one into `.brindle/rules/learned.md`, or reject it for good |
 | `brindle agent turns AGENT` / `brindle agent rewind AGENT --to N [--profile P] [--note "..."]` | a worker's worktree is snapshotted after every turn that changed files; rewind puts it back as it was after turn N and starts a fresh session there, briefed on the task, turns 1..N and your note (any provider, Codex included). Supervisors have the `agent_turns` and `rewind_agent` tools |
@@ -841,7 +841,7 @@ how to use them, and the next step to get the rest:
 | per-member budgets, pause, and admin messages (sidebar "Messages", the bottom bar, `brindle org messages`) | Team | `brindle org messages [--keep]` lists and marks read the notices your admins sent you; a pause refuses new workers and stops running ones |
 | audit log, air-gap | Enterprise | `brindle audit verify`, `"airgap": true` |
 | audit export | Enterprise | `"audit_export"` in `~/.brindle/config.json`, `brindle audit ship` |
-| managed models | Enterprise | `provider_config`, `deny_personal_keys` in your org policy (see "Managed models" below) |
+| managed models | Enterprise | `agent_setup` routes with `enforce`, and `deny_personal_keys`, in your org policy (see "Managed models" below) |
 | wider CI, cost centers, managed rollout | Enterprise | `brindle ci init --host gitlab`, `brindle cost request`, and `min_version`, required packs and the kill switch in your org policy; admins can also shut down or throttle a member, role or org remotely (it arrives within about a minute) |
 
 `brindle ci init` checks your plan before it changes anything: it refuses
@@ -951,20 +951,40 @@ file names, paths or branch names. See `src/brindle/pro/learning.py` and
 
 ### Managed models (brindle Enterprise)
 
-An org policy can pick the provider its workers run on and keep people's own
-model keys out of their panes. Both fields are ignored without the Enterprise
+An org policy can pick the route its workers run on and keep people's own
+model keys out of their panes. All of this is ignored without the Enterprise
 entitlement.
 
-* `provider_config`: `provider` (`bedrock`, `vertex`, `azure` or
-  `openai-compatible`), plus `region`, `model_ids` and `endpoint` as the
-  provider needs them. For `vertex` set `project` to the GCP project id
-  (brindle passes it to Claude Code as `ANTHROPIC_VERTEX_PROJECT_ID`; an older
-  policy that put the project id in `endpoint` still works). Every agent is
-  launched on that provider, and a profile that points somewhere else is
-  refused with a message saying why.
-* `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.
+* The routes live in the policy's `agent_setup` block (the same one `brindle
+  login` applies, see "Using your company's access"), one per agent. With
+  `enforce` on, an agent whose route points at a cloud or an endpoint of the
+  org's is managed: Claude Code on `bedrock` (`aws.region`; the SSO group
+  `sso_start_url`, `sso_region`, `account_id` and `role_name` is optional, all
+  four or none, and without it your own AWS sign-in applies), `vertex`
+  (`gcp.project`, `gcp.region`), `foundry` (`azure.resource` with its
+  `subscription_id`, or `azure.base_url`, the endpoint) or `gateway`
+  (`gateway.base_url`), with `model_ids` (the ids the route serves) and
+  `default_model` (what panes start on, `ANTHROPIC_MODEL`); Codex on `azure`
+  or `gateway` with `codex.base_url` (`OPENAI_BASE_URL`). The route's
+  variables are the top layer of every pane's environment, a profile that
+  points somewhere else is refused with a message saying why, and the
+  identity is checked at launch. With `exclusive` on as well, an agent the
+  block gives no route at all is refused (Claude Code or Codex with no entry,
+  and always native and Antigravity); without it such an agent runs
+  unmanaged (use `allowed_providers` to keep it out). Without `enforce` the
+  same block is sign-in help only.
+* `provider_config` is the older, org-wide form of the same thing: `provider`
+  (`bedrock`, `vertex`, `azure` or `openai-compatible`), plus `region`,
+  `model_ids` and `endpoint` as the provider needs them (for `vertex`,
+  `project`; an older policy that put the project id in `endpoint` still
+  works). The server now converts it into `agent_setup` routes (with
+  `exclusive` on) and keeps deriving it for older clients; this client reads
+  it whenever `agent_setup` has no `exclusive` field (a server older than
+  routing in `agent_setup`) or routes nothing. An old
+  `provider_config` and its `agent_setup` form give panes the same variables.
+* `deny_personal_keys` (in `agent_setup`, or the policy's top-level field):
+  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
@@ -983,10 +1003,9 @@ Two things to know when you turn on `deny_personal_keys`:
   `api_key_env` to the name of a variable that holds the org's key (not
   `OPENAI_API_KEY`).
 * It can't block a Claude subscription or keychain login by itself: Claude
-  Code signs in on its own, outside the variables brindle removes. Only a
-  `provider_config` that routes Claude Code to Bedrock, Vertex or Foundry
-  (`azure`) keeps it off that login. Always pair `deny_personal_keys` with a
-  `provider_config`.
+  Code signs in on its own, outside the variables brindle removes. Only an
+  enforced route that takes Claude Code to Bedrock, Vertex or Foundry keeps
+  it off that login. Always pair `deny_personal_keys` with one.
 
 ### Air-gapped mode (brindle Enterprise)
 

{brindle-0.3.5 → brindle-0.3.8}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "brindle"
-version = "0.3.5"
+version = "0.3.8"
 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"
@@ -51,6 +51,7 @@ audit_export = "brindle.pro.audit_export:make"
 [dependency-groups]
 dev = [
     "pytest>=8",
+    "pytest-cov>=7.0",
     "pytest-xdist>=3.8.0",
     "python-hcl2>=8.1.4",
     "pyyaml>=6.0.3",
@@ -74,4 +75,7 @@ only-include = ["src", "README.md", "LICENSE", "SCHEDULE-A", "pyproject.toml"]
 [tool.pytest.ini_options]
 testpaths = ["tests"]
 pythonpath = ["tests"]
-markers = ["serial: run outside xdist (`pytest -m serial`); the parallel pass skips these"]
+markers = [
+    "serial: run outside xdist (`pytest -m serial`); the parallel pass skips these",
+    "variant(reason): an input variant that covers no new code on purpose (see scripts/check_new_tests.py)",
+]

{brindle-0.3.5 → brindle-0.3.8}/src/brindle/agents.py

@@ -24,6 +24,7 @@ from brindle import company_identity, company_login, git, keystore, pane_auth, p
 from brindle.config import RepoConfig
 from brindle.db import DB, Agent, Workspace
 from brindle.model_availability import ModelAvailabilityChecker, PROVISIONING_TIMEOUT, provisioning_context
+from brindle.pro import route_health
 from brindle.profiles import load_profile, missing_add_dirs
 from brindle.providers import LaunchContext, get_provider, signed_out, unusable
 from brindle.sidebar_follow import (
@@ -92,6 +93,9 @@ When you have finished:
 """
 
 
+SUPERVISOR = "supervisor"   # the only profile a launch starts
+
+
 class AgentError(RuntimeError):
     pass
 
@@ -182,11 +186,12 @@ def agent_env(ws: Workspace, agent_id: str, agent: Agent | None = None,
         if m is _UNREAD:
             m = managed(ws.repo_root)
         # Claude Code's own managed settings (apiKeyHelper, a managed env) pick
-        # the credential and backend: brindle adds no provider_config env there.
+        # the credential and backend: brindle adds no managed route env there.
         org = agent.provider == "claude" and providers.claude_org_managed()
-        # The company's Claude Code env (`brindle login`): the lowest layer, so a
-        # profile's env lines and the org's managed provider both beat it; none
-        # at all under Claude Code's managed settings (stored_env).
+        # The company's Claude Code env (`brindle login`, the org's agent_setup
+        # without `enforce`): the lowest layer, so a profile's env lines and the
+        # org's managed route (an enforced agent_setup, or provider_config) both
+        # beat it; none at all under Claude Code's managed settings (stored_env).
         company = {} if agent.provider != "claude" else company_login.stored_env()
         managed_env = {} if org else managed_models.agent_env(m, agent.provider)
         enforced = None if agent.provider != "claude" or org else company_identity.enforced_route_env()
@@ -236,7 +241,8 @@ def agent_env(ws: Workspace, agent_id: str, agent: Agent | None = None,
             env = {**company, **recovery_keys, **profile_env, **managed_env, **env}
         else:
             # An enforced company identity (Enterprise): the pane runs on the route
-            # launch_problem checked, whatever a profile's env lines say.
+            # launch_problem checked, whatever a profile's env lines say. The route
+            # env is the top layer (managed_env is the same route's, from managed_models).
             profile_env = {k: v for k, v in profile_env.items() if company_identity.profile_may_set(k)}
             env = {**recovery_keys, **profile_env, **managed_env, **enforced, **env}
     if agent is not None and preload_tools(agent, ws):
@@ -528,9 +534,10 @@ def _window_environment(agent: Agent, ws: Workspace, m=_UNREAD):
         raise AgentError(f"managed models: {e}") from None
     # An enforced company identity: also every account picker the tmux server
     # would hand the pane or `brindle keys` holds for it (pane_auth covers this process's).
-    route = None if agent.provider != "claude" or org_managed else company_identity.enforced_route_env()
+    route = None if agent.provider != "claude" or org_managed else company_identity.enforced_route()
     if route is not None:
-        extra = company_identity.enforced_deny(route, tmux.inherited_names(ws.tmux_session), credentials)
+        extra = company_identity.enforced_deny(route[0], tmux.inherited_names(ws.tmux_session), credentials,
+                                               own=route[1])
         deny = (*deny, *(n for n in extra if n not in deny))
     # Claude Code's managed settings supply the credential: no stored Claude key.
     no_stored = set(deny) | (set(providers._ENV_AUTH["claude"]) if org_managed else set())
@@ -566,6 +573,9 @@ def model_problem(profile_name: str, ws: Workspace, *, agent: Agent | None = Non
         profile = guardrails.effective(load_profile(profile_name, ws.repo_root))
         why = managed_models.refusal(m, profile) if m is not None else None
         if why:
+            route_health.record(ws.repo_root, agent=profile.provider,
+                                route=route_health.route_of(profile.provider, managed_models.agent_env(m, profile.provider), m),
+                                model=profile.model, outcome="policy_refused")
             return f"managed models: {why}"
         if m is not None:
             profile = managed_models.apply_profile(m, profile)
@@ -583,7 +593,24 @@ def model_problem(profile_name: str, ws: Workspace, *, agent: Agent | None = Non
                                   account_identity=account_revision(profile.provider, effective),
                                   catalog_context=provisioning_context(profile.provider, ws.path, effective),
                                   timeout=PROVISIONING_TIMEOUT)
-    return result.explanation if result.status == "unavailable" else None
+    if result.status != "unavailable":
+        return None
+    route_health.record(ws.repo_root, agent=profile.provider,
+                        route=route_health.route_of(profile.provider, effective, m),
+                        model=profile.model, outcome="model_unavailable")
+    return result.explanation
+
+
+def route_context(db: DB, agent: Agent, ws: Workspace) -> tuple[str, str | None]:
+    """(the route ``agent``'s calls take, its model) for a route-health event
+    about a run; (``"unknown"``, None) when they can't be read."""
+    try:
+        m = managed(ws.repo_root)
+        profile = _profile_for(db, agent, ws, m)
+        env = _effective_window_env(agent, ws, m)
+        return route_health.route_of(agent.provider, env, m), profile.model
+    except Exception:  # noqa: BLE001 - a report about a run never fails over its context
+        return "unknown", None
 
 
 _model_checker = ModelAvailabilityChecker()
@@ -741,7 +768,10 @@ def _launch(db: DB, agent: Agent, ws: Workspace, *, prompt: str | None,
         return
     # An org that enforces its company sign-in (Enterprise) refuses a
     # different identity; one that can't be told never blocks.
-    why = company_identity.launch_problem(provider.name)
+    why, outcome, route = company_identity.launch_check(provider.name)
+    if outcome:
+        route_health.record(ws.repo_root, agent=provider.name, route=route, model=profile.model,
+                            outcome=outcome)
     if why:
         raise AgentError(why)
     from brindle import signin_pause

{brindle-0.3.5 → brindle-0.3.8}/src/brindle/builtin_agents/supervisor.md

@@ -13,6 +13,8 @@ How to work:
   report.
 - Break the request into independent, well-scoped tasks. Tasks that touch the
   same files should go to one worker, or run one after another.
+- Delegate to developers and other worker profiles. Start another supervisor
+  only when a piece of work is big enough to need its own workers, which is rare.
 - Delegate with the brindle MCP tools. `assign` runs workers in parallel (their
   results arrive later as messages). `handoff` waits for a single result.
   Leave `isolate` on: each worker gets its own git worktree and branch cut

{brindle-0.3.5 → brindle-0.3.8}/src/brindle/ci_client.py

@@ -1995,14 +1995,26 @@ def _set_cloud(repo: str, cloud: str, values: Mapping[str, str], *, run=subproce
 
 
 def managed_cloud(cwd: str) -> tuple[str, dict[str, str]] | None:
-    """On Enterprise, the cloud the org policy's ``provider_config`` names
-    (bedrock, vertex or azure) and the region/project to prefill; else None."""
+    """On Enterprise, the cloud the org policy routes Claude to (its enforced
+    ``agent_setup`` route, else its ``provider_config``: bedrock, vertex or
+    azure) and the region/project to prefill; else None."""
     from brindle.pro import managed_models
 
     try:
         m = managed_models.current(cwd)
     except Exception:  # noqa: BLE001 - not managed, or unreadable: no default
         return None
+    claude = m.claude if m else None
+    if claude is not None:
+        cloud = {"bedrock": BEDROCK, "vertex": VERTEX, "foundry": FOUNDRY}.get(claude.route)
+        if not cloud:
+            return None
+        if cloud == BEDROCK:
+            return cloud, {"AWS_REGION": claude.aws.region}
+        if cloud == VERTEX:
+            return cloud, {"CLOUD_ML_REGION": claude.gcp.region,
+                           "ANTHROPIC_VERTEX_PROJECT_ID": claude.gcp.project}
+        return cloud, {}
     cfg = m.config if m else None
     cloud = POLICY_CLOUDS.get(cfg.provider) if cfg else None
     if not cloud: