brindle 0.3.3__tar.gz → 0.3.5__tar.gz

{brindle-0.3.3 → brindle-0.3.5}/.gitignore

@@ -10,3 +10,7 @@ graphify-out/
 docs/
 .brindle/config.local.json
 .brindle/bench.json
+.DS_Store
+commit_msg.txt
+model_routing_plan.*
+open_plan.py

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: brindle
-Version: 0.3.3
+Version: 0.3.5
 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.3`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.5`). 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. `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.
+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.
 
 **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
@@ -242,7 +242,7 @@ for mechanical edits and a Codex reviewer for a second model's opinion.
 
 ## Autopilot
 
-`brindle` starts the supervisor with autopilot on. Tell it what we're building,
+`brindle supervisor` starts the supervisor with autopilot on (or `brindle start -a supervisor`). 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,7 +337,8 @@ your own status line prints, so what you see doesn't change.
 
 | | |
 |---|---|
-| `brindle` | a fresh supervisor chat here, dashboard alongside |
+| `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 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 |
@@ -346,6 +347,7 @@ your own status line prints, so what you see doesn't change.
 | `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 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 |
 | `brindle delegation [conservative\|balanced\|fast]` | how readily the supervisor delegates: fewest tokens, the default, or quickest |
 | `brindle transfer [REPO] [--from SESSION] [-b BRANCH]` | move a scratch session's work into a real repo |
 | `brindle ls [--all]` | workspaces and agents |
@@ -407,6 +409,7 @@ knowing them helps when you tell the supervisor how to work.
 | `approve_plan` | supervisor | approve a worker's plan, or send it back with feedback (`approved=false`) |
 | `complete_subagent` | supervisor | record the result of a `subagent`-profile task |
 | `set_goal` / `get_progress` / `check_milestone` | supervisor | autopilot's goal, its progress, and running the checks |
+| `record_audit_decision` | supervisor | record acceptance of an audit finding with rationale so subsequent audits respect it |
 | `need_user` | supervisor | stop autopilot and ask you a question |
 | `transfer_to_repo` | supervisor | move a scratch session's work into a repository |
 | `handover` | supervisor | hand the session to a new supervisor on another branch or worktree, with a note |
@@ -528,7 +531,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 |
+| `fable_escalation` | on, unless the worker runs on a cloud account (Bedrock, Vertex or Foundry) | retry a failed heavy task once on `developer-heavy` 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) |
@@ -581,27 +584,30 @@ When a workspace is created (including from the pool), brindle starts one contai
 
 ### Routing by weight
 
-The supervisor sizes a task and passes `weight` (`"light"`, `"medium"` or
-`"heavy"`) to `assign`/`handoff`; brindle picks an available profile for that tier.
+The supervisor sizes a task and passes `weight` (`"light"`, `"medium"`,
+`"heavy"` or `"advanced"`, with `"reasoning"` and `"complex"` accepted as aliases) to
+`assign`/`handoff`; brindle picks an available profile for that tier.
 Light is small, well-specified, mechanical work (docs, renames, simple tests);
-medium is a normal feature or bugfix in one area; heavy is design-heavy,
-cross-cutting work, subtle bugs or hard reasoning. The `routing` config maps each
-tier to profile names: the first is the tier's baseline, the rest are candidates
-hosted learning may pick instead (defaults shown; set one tier and the others
-keep theirs):
+medium is a normal feature or bugfix in one area; heavy is architecture design,
+broad cross-cutting refactors, or subtle bugs; advanced is complex, long-running
+system-design and implementation tasks. The `routing`
+config maps each tier to profile names: the first is the tier's baseline, the
+rest are candidates hosted learning may pick instead (defaults shown; set one
+tier and the others keep theirs):
 
 ```json
 {
   "routing": {
-    "light":  ["developer-light", "developer", "developer-codex", "developer-local"],
-    "medium": ["developer", "developer-codex", "developer-heavy"],
-    "heavy":  ["developer", "developer-heavy", "developer-codex"]
+    "light":    ["developer-light", "developer", "developer-codex", "developer-local"],
+    "medium":   ["developer", "developer-codex", "developer-heavy"],
+    "heavy":    ["developer-heavy", "developer-gemini", "developer", "developer-codex"],
+    "advanced": ["developer-fable", "developer-heavy", "developer-gemini"]
   }
 }
 ```
 
-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.
+No tier prefers another provider for its own sake: all-Claude, all-Codex or
+all-Gemini may be what works best for you, and that's for the learner to find out.
 
 Routing merges per tier in this order: built-in defaults, `~/.brindle/config.json`
 (every repo), the repo's `.brindle/config.json` (shared with the team), then
@@ -619,8 +625,9 @@ each tier. Unknown profile names are skipped; doctor and the routing reply
 report the missing name and the file that supplied it.
 
 `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.
+Code default model; `developer-codex` on Codex; `developer-heavy` on Claude Opus
+at high effort; `developer-gemini` on Google Antigravity (Gemini) with high effort
+(Tier 3); `developer-fable` on Claude Fable at high effort (Tier 4 advanced).
 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
@@ -1437,6 +1444,22 @@ A profile chooses between the two with `auth`:
 
 Your org's `deny_personal_keys` (Enterprise) still applies on top of `auth`.
 
+#### Running unattended on API keys
+
+When running long, unattended autopilot sessions with API keys:
+
+- **Quota, token and cost measurements per provider**:
+  - Autopilot's automatic usage pause (`usage_limit: 90`) relies on the percentage numbers emitted by Claude Code's status line under subscription plans. Under API-key billing (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`), the CLIs report no subscription percentage, so subscription usage pause thresholds do not trigger; manage spend via provider account budget limits or brindle budget policies.
+  - Token and cost tracking: Token counts and cost estimates are captured from Claude and Codex transcripts. Antigravity (`agy`) currently has **no token/cost measurements**, so budget policies and cost tracking cannot monitor Antigravity spend; enforce usage caps directly in Google AI Studio or your Google Cloud project billing settings.
+- **Runtime auth failure handling and provider differences**:
+  - **Claude and Antigravity**: Runtime authentication failures (such as 401/403, revoked API keys, or credit/billing errors) are intercepted via StopFailure and exit hooks. Brindle marks the worker as failed, alerts the supervisor, invalidates cached sign-in checks, and pauses autopilot with a `Credentials need attention` notice rather than cycling idle nudges.
+  - **Codex (unsupported runtime auth detection)**: Codex CLI turn completion (`agent-turn-complete`) does not classify auth errors at runtime. If an OpenAI API key expires or is rejected, Codex workers will not automatically transition to `failed` or trigger an autopilot credential pause. When running Codex workers unattended, monitor their progress via `brindle watch` or check tmux panes; if an auth failure occurs, manually restart or rotate keys.
+- **Supervisor credential refresh and key rotation**:
+  - **Recovering failed/blocked workers**: When an agent fails on an expired key or autopilot pauses with a credential error, export the fresh key (or update `brindle keys set`), then run `brindle continue`. This unpauses the session and relaunches paused/failed agents with the new credentials. The replacement credentials are automatically synced to the session credential store, dynamically refreshed by the supervisor's launcher on all subsequent worker delegations (`assign`/`handoff`).
+  - **Proactive rotation in live sessions**: Exporting a new key while an active session is healthy does not restart running workers or the supervisor (running `brindle continue` on an active healthy session simply reattaches to tmux without restarting workers). To proactively rotate credentials for the entire session and all running workers: run `brindle stop` -> update credentials in your environment or via `brindle keys set` -> run `brindle continue`.
+  - **Precedence**: Newly stored keys (`brindle keys set`) or session credentials updated during recovery take effect dynamically for all new panes, overriding stale launcher environments. For profile-level overrides, an explicit profile key (`env.NAME`) takes precedence over default provider credentials.
+- **Antigravity permissions prerequisite**: Antigravity (`agy`) does not support approving shell commands solely via external hooks. With `GEMINI_API_KEY`, unattended agy workers will still stall on approval prompts unless permissions are pre-populated in `settings.json` (see Permissions) or run with `agy_approvals: "brindle"` under `permission_policy: "on"` (`--dangerously-skip-permissions`).
+
 ### Cheap workers
 
 By default a Claude Code worker loads everything your own `claude` does: your

{brindle-0.3.3 → brindle-0.3.5}/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.3`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.5`). 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. `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.
+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.
 
 **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
@@ -212,7 +212,7 @@ for mechanical edits and a Codex reviewer for a second model's opinion.
 
 ## Autopilot
 
-`brindle` starts the supervisor with autopilot on. Tell it what we're building,
+`brindle supervisor` starts the supervisor with autopilot on (or `brindle start -a supervisor`). 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,7 +307,8 @@ your own status line prints, so what you see doesn't change.
 
 | | |
 |---|---|
-| `brindle` | a fresh supervisor chat here, dashboard alongside |
+| `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 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 |
@@ -316,6 +317,7 @@ your own status line prints, so what you see doesn't change.
 | `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 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 |
 | `brindle delegation [conservative\|balanced\|fast]` | how readily the supervisor delegates: fewest tokens, the default, or quickest |
 | `brindle transfer [REPO] [--from SESSION] [-b BRANCH]` | move a scratch session's work into a real repo |
 | `brindle ls [--all]` | workspaces and agents |
@@ -377,6 +379,7 @@ knowing them helps when you tell the supervisor how to work.
 | `approve_plan` | supervisor | approve a worker's plan, or send it back with feedback (`approved=false`) |
 | `complete_subagent` | supervisor | record the result of a `subagent`-profile task |
 | `set_goal` / `get_progress` / `check_milestone` | supervisor | autopilot's goal, its progress, and running the checks |
+| `record_audit_decision` | supervisor | record acceptance of an audit finding with rationale so subsequent audits respect it |
 | `need_user` | supervisor | stop autopilot and ask you a question |
 | `transfer_to_repo` | supervisor | move a scratch session's work into a repository |
 | `handover` | supervisor | hand the session to a new supervisor on another branch or worktree, with a note |
@@ -498,7 +501,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 |
+| `fable_escalation` | on, unless the worker runs on a cloud account (Bedrock, Vertex or Foundry) | retry a failed heavy task once on `developer-heavy` 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) |
@@ -551,27 +554,30 @@ When a workspace is created (including from the pool), brindle starts one contai
 
 ### Routing by weight
 
-The supervisor sizes a task and passes `weight` (`"light"`, `"medium"` or
-`"heavy"`) to `assign`/`handoff`; brindle picks an available profile for that tier.
+The supervisor sizes a task and passes `weight` (`"light"`, `"medium"`,
+`"heavy"` or `"advanced"`, with `"reasoning"` and `"complex"` accepted as aliases) to
+`assign`/`handoff`; brindle picks an available profile for that tier.
 Light is small, well-specified, mechanical work (docs, renames, simple tests);
-medium is a normal feature or bugfix in one area; heavy is design-heavy,
-cross-cutting work, subtle bugs or hard reasoning. The `routing` config maps each
-tier to profile names: the first is the tier's baseline, the rest are candidates
-hosted learning may pick instead (defaults shown; set one tier and the others
-keep theirs):
+medium is a normal feature or bugfix in one area; heavy is architecture design,
+broad cross-cutting refactors, or subtle bugs; advanced is complex, long-running
+system-design and implementation tasks. The `routing`
+config maps each tier to profile names: the first is the tier's baseline, the
+rest are candidates hosted learning may pick instead (defaults shown; set one
+tier and the others keep theirs):
 
 ```json
 {
   "routing": {
-    "light":  ["developer-light", "developer", "developer-codex", "developer-local"],
-    "medium": ["developer", "developer-codex", "developer-heavy"],
-    "heavy":  ["developer", "developer-heavy", "developer-codex"]
+    "light":    ["developer-light", "developer", "developer-codex", "developer-local"],
+    "medium":   ["developer", "developer-codex", "developer-heavy"],
+    "heavy":    ["developer-heavy", "developer-gemini", "developer", "developer-codex"],
+    "advanced": ["developer-fable", "developer-heavy", "developer-gemini"]
   }
 }
 ```
 
-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.
+No tier prefers another provider for its own sake: all-Claude, all-Codex or
+all-Gemini may be what works best for you, and that's for the learner to find out.
 
 Routing merges per tier in this order: built-in defaults, `~/.brindle/config.json`
 (every repo), the repo's `.brindle/config.json` (shared with the team), then
@@ -589,8 +595,9 @@ each tier. Unknown profile names are skipped; doctor and the routing reply
 report the missing name and the file that supplied it.
 
 `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.
+Code default model; `developer-codex` on Codex; `developer-heavy` on Claude Opus
+at high effort; `developer-gemini` on Google Antigravity (Gemini) with high effort
+(Tier 3); `developer-fable` on Claude Fable at high effort (Tier 4 advanced).
 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
@@ -1407,6 +1414,22 @@ A profile chooses between the two with `auth`:
 
 Your org's `deny_personal_keys` (Enterprise) still applies on top of `auth`.
 
+#### Running unattended on API keys
+
+When running long, unattended autopilot sessions with API keys:
+
+- **Quota, token and cost measurements per provider**:
+  - Autopilot's automatic usage pause (`usage_limit: 90`) relies on the percentage numbers emitted by Claude Code's status line under subscription plans. Under API-key billing (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`), the CLIs report no subscription percentage, so subscription usage pause thresholds do not trigger; manage spend via provider account budget limits or brindle budget policies.
+  - Token and cost tracking: Token counts and cost estimates are captured from Claude and Codex transcripts. Antigravity (`agy`) currently has **no token/cost measurements**, so budget policies and cost tracking cannot monitor Antigravity spend; enforce usage caps directly in Google AI Studio or your Google Cloud project billing settings.
+- **Runtime auth failure handling and provider differences**:
+  - **Claude and Antigravity**: Runtime authentication failures (such as 401/403, revoked API keys, or credit/billing errors) are intercepted via StopFailure and exit hooks. Brindle marks the worker as failed, alerts the supervisor, invalidates cached sign-in checks, and pauses autopilot with a `Credentials need attention` notice rather than cycling idle nudges.
+  - **Codex (unsupported runtime auth detection)**: Codex CLI turn completion (`agent-turn-complete`) does not classify auth errors at runtime. If an OpenAI API key expires or is rejected, Codex workers will not automatically transition to `failed` or trigger an autopilot credential pause. When running Codex workers unattended, monitor their progress via `brindle watch` or check tmux panes; if an auth failure occurs, manually restart or rotate keys.
+- **Supervisor credential refresh and key rotation**:
+  - **Recovering failed/blocked workers**: When an agent fails on an expired key or autopilot pauses with a credential error, export the fresh key (or update `brindle keys set`), then run `brindle continue`. This unpauses the session and relaunches paused/failed agents with the new credentials. The replacement credentials are automatically synced to the session credential store, dynamically refreshed by the supervisor's launcher on all subsequent worker delegations (`assign`/`handoff`).
+  - **Proactive rotation in live sessions**: Exporting a new key while an active session is healthy does not restart running workers or the supervisor (running `brindle continue` on an active healthy session simply reattaches to tmux without restarting workers). To proactively rotate credentials for the entire session and all running workers: run `brindle stop` -> update credentials in your environment or via `brindle keys set` -> run `brindle continue`.
+  - **Precedence**: Newly stored keys (`brindle keys set`) or session credentials updated during recovery take effect dynamically for all new panes, overriding stale launcher environments. For profile-level overrides, an explicit profile key (`env.NAME`) takes precedence over default provider credentials.
+- **Antigravity permissions prerequisite**: Antigravity (`agy`) does not support approving shell commands solely via external hooks. With `GEMINI_API_KEY`, unattended agy workers will still stall on approval prompts unless permissions are pre-populated in `settings.json` (see Permissions) or run with `agy_approvals: "brindle"` under `permission_policy: "on"` (`--dangerously-skip-permissions`).
+
 ### Cheap workers
 
 By default a Claude Code worker loads everything your own `claude` does: your

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

@@ -1,6 +1,6 @@
 [project]
 name = "brindle"
-version = "0.3.3"
+version = "0.3.5"
 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"