@bastani/atomic 0.9.61-alpha.1 → 0.9.61-alpha.2

package/docs/models/evals.md

@@ -5,7 +5,7 @@ description: "Primary-source benchmark facts used by Atomic automatic model rout
 
 # Evals
 
-Last Accessed: 2026-10-26 (GPT-6.1 Terra additions; earlier rows retain their snapshot dates below).
+Last Accessed: 2026-11-02 (Gemini 4 Argon additions; earlier rows retain their snapshot dates below).
 
 Key:
 
@@ -46,16 +46,18 @@ Key:
 
 ## Artificial Analysis Intelligence Index v4.3.2
 
-Table: the 673 models on the Artificial Analysis leaderboard as of 2026-09-25, including models with no published scores, plus 5 Claude Sonnet 5.5 rows accessed 2026-09-28, 5 GPT-6.1 Sol rows accessed 2026-09-29, 5 Claude Haiku 5.5 rows accessed 2026-10-07, and 6 GPT-6.1 Terra rows accessed 2026-10-26.
+Table: the 673 models on the Artificial Analysis leaderboard as of 2026-09-25, including models with no published scores, plus 5 Claude Sonnet 5.5 rows accessed 2026-09-28, 5 GPT-6.1 Sol rows accessed 2026-09-29, 5 Claude Haiku 5.5 rows accessed 2026-10-07, 6 GPT-6.1 Terra rows accessed 2026-10-26, and 1 Gemini 4 Argon row accessed 2026-11-02.
 
 Sources and access dates for later additions. Release dates are not evaluation run dates; AA does not publish run dates. These are AA measurements, not vendor launch-table results. AA's [methodology](https://artificialanalysis.ai/methodology/intelligence-benchmarking) uses mini-swe-agent for TB4, all 66 tasks, pass@1 averaged over three repeats, a 500-step cap and no context compaction.
 
 - GPT-6.1 Sol: five effort rows accessed 2026-09-29 from the [leaderboard](https://artificialanalysis.ai/leaderboards/models) and [model page](https://artificialanalysis.ai/models/gpt-6-1-sol).
 - Claude Haiku 5.5: rows accessed 2026-10-07 from the [leaderboard](https://artificialanalysis.ai/leaderboards/models) and the [max](https://artificialanalysis.ai/models/claude-haiku-5-5), [xhigh](https://artificialanalysis.ai/models/claude-haiku-5-5-xhigh), [high](https://artificialanalysis.ai/models/claude-haiku-5-5-high), [medium](https://artificialanalysis.ai/models/claude-haiku-5-5-medium), and [low](https://artificialanalysis.ai/models/claude-haiku-5-5-low) model pages. AA labels these configurations "with fallback". All five pages publish non-estimated indices and twelve component measurements in their public structured data, although their text rendering says "Not publicly available". Missing `ONH` remains unknown; the published hallucination rate is a different metric.
 - GPT-6.1 Terra: six rows accessed 2026-10-26 from the [leaderboard](https://artificialanalysis.ai/leaderboards/models) and the [max](https://artificialanalysis.ai/models/gpt-6-1-terra), [xhigh](https://artificialanalysis.ai/models/gpt-6-1-terra-xhigh), [high](https://artificialanalysis.ai/models/gpt-6-1-terra-high), [medium](https://artificialanalysis.ai/models/gpt-6-1-terra-medium), [low](https://artificialanalysis.ai/models/gpt-6-1-terra-low), and [non-reasoning](https://artificialanalysis.ai/models/gpt-6-1-terra-non-reasoning) model pages. All six publish non-estimated indices in their public structured data. Columns AA does not publish for Terra remain `∅`.
+- Gemini 4 Argon: `high`, the only configuration AA publishes, accessed 2026-11-02 from the [model page](https://artificialanalysis.ai/models/gemini-4-argon). AA now publishes `idx`, `OA`, `Omni`, `Harvey` and `MLCR` only on revised versions (Intelligence Index v5.0, Omniscience v1.1), so they stay `∅`. SciCode is under AA review.
 
 | slug | Model | Release date | idx | Brief | Gn | Auto | TB4 | Sci | HLE | PDF | Crit | OA | ONH | LCR | Omni | GPQA | TB21 | TBh | IF | MMMU | tau2 | tauB | Analyst | ITB | Apex | AIME | LCB | Harvey | MLCR | Open | Ent |
 | --- | --- | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
+| gemini-4-argon | Gemini 4 Argon (high) | 2026-09-30 | ∅ | 49.2 | 56.5 | 77.5 | 57.1 | 61.8 | 57.1 | 21.8 | 27.1 | ∅ | ∅ | 79.7 | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | 48.8 | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ |
 | gpt-6-1-terra | GPT-6.1 Terra (max) | 2026-10-26 | 48.1 | 45.1 | 48.8 | 60.2 | 55.6 | 55.1 | 46.2 | 28.6 | 28.0 | 49.1 | 62.0 | 82.7 | 29.8 | ∅ | ∅ | ∅ | ∅ | 84.7 | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ |
 | gpt-6-1-terra-xhigh | GPT-6.1 Terra (xhigh) | 2026-10-26 | 45.4 | 41.6 | 45.8 | 59.9 | 46.5 | 53.4 | 43.7 | 26.6 | 26.6 | 49.6 | 58.5 | 81.7 | 28.7 | ∅ | ∅ | ∅ | ∅ | 83.8 | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ |
 | gpt-6-1-terra-high | GPT-6.1 Terra (high) | 2026-10-26 | 43.9 | 38.2 | 42.7 | 58.5 | 41.9 | 51.6 | 43.3 | 28.0 | 25.7 | 50.0 | 56.9 | 82.3 | 28.4 | ∅ | ∅ | ∅ | ∅ | 83.8 | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ | ∅ |
@@ -797,6 +799,8 @@ GPT-6.1 Sol was added 2026-09-29 and accessed that day in the [primary JSON](htt
 
 Claude Haiku 5.5 was added and accessed 2026-10-07 in the [primary JSON](https://cognition.com/data/frontiercode-leaderboard/data.json). Its best score on both sets is max effort under the Claude Code harness; the run date is unpublished. No unfair-internet-use flag rate is recorded here. Mean cost per Main rollout is $1.33.
 
+Gemini 4 Argon was added and accessed 2026-11-02 in the same JSON (low, medium and high under `devin-cli`). Medium is best on Main; low edges it on Extended (60.6). Run date unpublished.
+
 Key:
 
 - FrontierCode: mergeability of agent-written pull requests on tasks built by open-source maintainers, graded by rubrics, unit tests and other verifiers for correctness, test quality, scope discipline, style and codebase conventions. Runs that consult solution-bearing sources such as the original pull request score zero.
@@ -817,6 +821,7 @@ Key:
 | gpt-6-sol | GPT-6 Sol | max | 49.3 | 54.3 | 60.7 | 66.3 | 0.0 | $2.07 |
 | grok-4-6 | Grok 4.6 | high | 48.0 | 53.1 | 61.3 | 67.0 | 0.7 | $2.88 |
 | grok-4-7 | Grok 4.7 | high | 47.6 | 53.1 | 59.4 | 65.2 | 1.3 | $6.65 |
+| gemini-4-argon | Gemini 4 Argon | medium | 47.6 | 52.8 | 60.5 | 66.1 | 1.2 | $6.74 |
 | gpt-5-6-sol | GPT-5.6 Sol | max | 47.5 | 52.9 | 60.6 | 66.6 | 0.0 | $5.19 |
 | claude-opus-4-8 | Opus 4.8 | max | 46.5 | 51.6 | 59.6 | 65.5 | 0.6 | $9.62 |
 | claude-haiku-5-5 | Haiku 5.5 | max | 46.4 | 51.7 | 58.4 | 64.7 | ∅ | $1.33 |
@@ -861,6 +866,7 @@ Sources and access dates:
 - GPT-6.1 Sol, accessed 2026-09-29: OpenAI = [Sol 6.1 announcement](https://openai.com/index/introducing-gpt-6-1-sol/) and [system card](https://deploymentsafety.openai.com/gpt-6-1-sol); Artificial Analysis = [Sol 6.1 model page](https://artificialanalysis.ai/models/gpt-6-1-sol) and [methodology](https://artificialanalysis.ai/methodology/intelligence-benchmarking). OpenAI's external benchmark results are vendor-reported, not benchmark-owner leaderboard rows. They ran in its research environment or API; individual harness revisions and run dates are not stated. AA's TBSci result is independent evidence from its own harness. No matching Sol 6.1 row was retrieved from the DeepSWE, TB-Science, Zapier, Surge GDP.pdf, OSWorld or ARC Prize owner leaderboards on that date.
 - Claude Haiku 5.5, accessed 2026-10-07: Anthropic = [launch announcement](https://www.anthropic.com/claude-haiku-5-5), published that day. These launch-table results are vendor-reported; effort, harness revisions, and evaluation run dates are not stated unless shown in the setting. GDPval-AA and AA-Briefcase are raw Elo, not the normalized AA columns above. Artificial Analysis independently measures Haiku 5.5 Terminal-Bench-Science in its **with-fallback** configuration, from the effort-specific model pages for [max](https://artificialanalysis.ai/models/claude-haiku-5-5), [xhigh](https://artificialanalysis.ai/models/claude-haiku-5-5-xhigh), [high](https://artificialanalysis.ai/models/claude-haiku-5-5-high), [medium](https://artificialanalysis.ai/models/claude-haiku-5-5-medium), and [low](https://artificialanalysis.ai/models/claude-haiku-5-5-low); these are not Anthropic launch-table results. No Haiku 5.5 result was published on the checked [DeepSWE leaderboard](https://deepswe.datacurve.ai/) on 2026-10-07; no row is added to that table.
 - GPT-6.1 Terra, accessed 2026-10-26: OpenAI = [launch announcement](https://openai.com/index/introducing-gpt-6-1-terra/) and [system card addendum](https://deploymentsafety.openai.com/gpt-6-1-terra). These results are vendor-reported; harness revisions and run dates are not stated. The announcement text states one numeric Terra score on an external benchmark, TB4 at max effort; its Agents' Last Exam, MMMU-Pro, OSWorld 2.1 and Terminal-Bench-Science comparisons state no Terra score and are not transcribed. The system card reports cybersecurity results at the maximum tested solution length without naming an effort; its internal evaluations are excluded. Artificial Analysis independently measures Terminal-Bench-Science for the six configurations whose model pages are listed in the Intelligence Index section above. No GPT-6.1 Terra result was published on the [DeepSWE leaderboard](https://deepswe.datacurve.ai/), the [TB-Science leaderboard](https://www.terminal-bench-science.ai/), the [FrontierCode data](https://cognition.com/data/frontiercode-leaderboard/data.json), or the visible [AutomationBench leaderboard](https://zapier.com/benchmarks) on that date; no row is added to those tables.
+- Gemini 4 Argon, accessed 2026-11-02: Google = [model card](https://deepmind.google/models/model-cards/gemini-4-argon/) and [methodology](https://deepmind.google/models/evals-methodology/gemini-4-argon), vendor-reported at the highest thinking setting, pass@1; "from X" rows are Google's attribution, not separately retrieved. Zapier = [AutomationBench](https://zapier.com/benchmarks). The [DeepSWE leaderboard](https://deepswe.datacurve.ai/) had no Argon row.
 
 Artificial Analysis Terminal-Bench-Science rows use the [evaluation page](https://artificialanalysis.ai/evaluations/terminal-bench-science) and [AA's general methodology](https://artificialanalysis.ai/methodology/intelligence-benchmarking): version 0.1.0, 70 tasks, mini-swe-agent, pass@1 averaged over three repeats, and a 1,000-step cap. These are AA's general settings, not a separately documented model-specific harness revision. Evaluation run dates are unpublished.
 
@@ -874,6 +880,7 @@ Key:
 - `OSW21`: OSWorld 2.1, computer-use workflows; the Haiku result covers the offline subset.
 - `FC11`: FrontierCode 1.1 Main, weighted rubric score; distinct from all-blocking-criteria pass rate.
 - `Chart`: Chartography, chart understanding without tools.
+- `VALS`: Vals Index. `VFA`: Vals Finance Agent v2. `HLAB`: Harvey's Legal Agent Benchmark. `FSWE`: FrontierSWE v2. `VCB`: Vibe Code Bench. `PTB`: PostTrainBench v1.1. `CWE`: CWE-bench v1. `LAB2`: LABBench 2. `RBench`: RiemannBench. `GW128`, `GW1M`: GraphWalks BFS F1, up to 128k and 256k to 1M tokens. `LVB`: LVBench.
 
 - `ALE`: [Agents' Last Exam](https://agents-last-exam.org/), long-horizon professional tasks in real software, from financial modeling to engineering and media production.
 - `OSW2`, `OSW2s`: [OSWorld 2.0](https://osworld-v2.xlang.ai/), long-horizon computer-use workflows operating desktop applications through the screen; partial credit and strict all-pass scoring.
@@ -892,6 +899,27 @@ Key:
 
 | slug | Model | Benchmark | Score | Setting | Source |
 | --- | --- | --- | ---: | --- | --- |
+| gemini-4-argon | Gemini 4 Argon | DSWE | 77.9 | v1.1, mini-swe-agent; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | FSWE | 55.0 | v2; Google-reported, from Proximal's leaderboard | Google |
+| gemini-4-argon | Gemini 4 Argon | TB4 | 57.4 | v4.0; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | TBSci | 57.6 | v0.1, 6x verifier timeout; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | TBSci | 52.9 | high effort; AA general settings above | Artificial Analysis |
+| gemini-4-argon | Gemini 4 Argon | VCB | 91.9 | Google-reported, from Vals AI's leaderboard | Google |
+| gemini-4-argon | Gemini 4 Argon | ABench | 51.3 | v1.0.6, private set, high effort | Zapier |
+| gemini-4-argon-medium | Gemini 4 Argon | ABench | 50.1 | v1.0.6, private set, medium effort | Zapier |
+| gemini-4-argon | Gemini 4 Argon | PTB | 45.3 | v1.1, OpenCode harness, 10 hours on one H100; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | VALS | 68.9 | Google-reported, from Vals AI | Google |
+| gemini-4-argon | Gemini 4 Argon | VFA | 65.4 | Google-reported, from Vals AI | Google |
+| gemini-4-argon | Gemini 4 Argon | HLAB | 19.6 | Google-reported, from Vals AI | Google |
+| gemini-4-argon | Gemini 4 Argon | ALE | 39.5 | ALE-Claw harness, 5-hour window, binary pass rate; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | OSW2 | 69.2 | offline subset, partial, best of 3 runs, Gemini CUA harness with batch tool calls and compaction, 08.08 patch; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | LAB2 | 88.8 | terminal with bioinformatics tools, Python, R and internet; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | RBench | 76.0 | Google-reported, from Surge's leaderboard | Google |
+| gemini-4-argon | Gemini 4 Argon | GW128 | 99.7 | BFS F1, 650 items up to 128k; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | GW1M | 84.2 | BFS F1, 200 problems at 256k to 1M; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | Chart | 71.6 | no tools; Google-reported, from Surge's leaderboard | Google |
+| gemini-4-argon | Gemini 4 Argon | LVB | 91.7 | no tools, 1 FPS; Google-reported, self-computed | Google |
+| gemini-4-argon | Gemini 4 Argon | CWE | 68.0 | v1, pass@1; Google-reported, from the public leaderboard | Google |
 | gpt-6-1-terra | GPT-6.1 Terra | TB4 | 50.3 | max effort; v4.0; OpenAI-reported, harness not stated | OpenAI |
 | gpt-6-1-terra | GPT-6.1 Terra | XBench | 97.1 | ACE-normalized mean capability score; max tested solution length; effort not stated | OpenAI |
 | gpt-6-1-terra | GPT-6.1 Terra | SECPro | 83.3 | pass@1; max tested solution length; effort not stated | OpenAI |

package/docs/settings.md

@@ -147,6 +147,8 @@ To audit a routing decision, the stage's `routerSelection` in `workflow({ action
 
 If `retry.enabled` is `false`, Atomic skips same-model retries and moves directly to the next fallback for retryable failures. Non-retryable task failures and cancellations do not trigger fallback.
 
+A content-filter refusal, such as OpenAI's HTTP 422 `cyber_policy` ("This content was flagged for possible cybersecurity risk"), Anthropic's refusal stop, or a `content_filter` finish reason, also moves to the next fallback, without retrying the model that refused: the same request would be refused again. The refused model is recorded in the fallback history. Set `retry.fallbackOnContentFilter` to `false` to keep such a refusal on the model that gave it. Subagents and workflow stages follow the same setting for their own `fallbackModels`.
+
 The fallback model and its thinking level remain active for later turns in the same main-chat session. Choose another model explicitly with `/model` or model cycle to change them.
 
 Workflow stages that set their own `model` or `fallbackModels` never use this list; they advance only the chain they declare. See [`fallbackModels`](/workflows/api-reference#fallbackmodels).
@@ -340,6 +342,7 @@ Both fields must be non-negative safe integers, including ordinary settings. Inv
 | `retry.maxRetries` | number | `3` | Maximum agent-level retry attempts |
 | `retry.baseDelayMs` | number | `2000` | Base delay for agent-level exponential backoff (2s, 4s, 8s) |
 | `retry.maxAgentDelayMs` | number | `60000` | Maximum agent-level backoff delay (60s); `0` retries immediately |
+| `retry.fallbackOnContentFilter` | boolean | `true` | Move to the next `fallbackModels` entry when a provider's content filter refuses a request (for example OpenAI's HTTP 422 `cyber_policy`), instead of retrying the same model. `false` retries the refusal on the same model and never falls back for it |
 | `retry.provider.timeoutMs` | number | SDK default | Provider/SDK request timeout in milliseconds |
 | `retry.provider.maxRetries` | number | `0` | Provider/SDK retry attempts. Leave unset/`0` to let Atomic's agent-level retry handle transient failures |
 | `retry.provider.maxRetryDelayMs` | number | `60000` | Max server-requested delay before failing (60s); also caps how long an agent-level retry waits for a server retry hint |

package/docs/subagents/reference.md

@@ -110,7 +110,9 @@ Retryable causes include rate limits, quota/usage-limit exhaustion, auth problem
 
 A request-incompatible candidate also advances the sequence. Examples include HTTP 400/413/422 bad, unprocessable, or payload-too-large requests; unsupported tools or parameters; context-length/context-window overflow; and `too large` / `invalid_request` errors. The chain can therefore reach the current user-selected model when no configured candidate can serve the request.
 
-Fallback does not retry safety refusals, ordinary task or tool failures, validation failures, cancellations, or workflow-code errors.
+A content-filter refusal also advances the sequence, without retrying the refusing model. Examples include OpenAI's HTTP 422 `cyber_policy` ("This content was flagged for possible cybersecurity risk"), Anthropic's refusal stop, and a `content_filter` finish reason. The result's fallback list shows which model refused. Set `retry.fallbackOnContentFilter: false` in settings to keep such a refusal on the model that gave it.
+
+Fallback does not retry refused tool calls, ordinary task or tool failures, validation failures, cancellations, or workflow-code errors.
 
 There is no per-attempt idle watchdog or child wall-clock kill cap. Quiet provider responses may finish; only explicit termination or a provider failure supplies a retryable cause.
 

package/docs/workflows/api-reference.md

@@ -562,10 +562,11 @@ readonly fallbackModels?: readonly string[];
 
 - Rate limits and quota or usage-limit exhaustion, including `The usage limit has been reached`, `usage_limit_reached`, and `insufficient_quota`.
 - Auth/provider outages, unavailable models, network timeouts, generic transport errors such as `Connection error.` or `fetch failed`, and 5xx responses.
+- Content-filter refusals, such as OpenAI's HTTP 422 `cyber_policy`, Anthropic's refusal stop, or a `content_filter` finish reason. Set `retry.fallbackOnContentFilter: false` in settings to fail the stage on such a refusal instead.
 
 Before advancing, Atomic retries a thrown failure on the same candidate when another request could plausibly repair it. Rate limits, provider outages, network timeouts, and transport errors use exponential backoff from `settings.retry`. Set `retry.enabled: false` for immediate advancement.
 
-Rejected credentials, unavailable models, and incompatible requests advance immediately, as in main chat. Retrying the same candidate cannot repair these failures.
+Rejected credentials, unavailable models, incompatible requests, and content-filter refusals advance immediately, as in main chat. Retrying the same candidate cannot repair these failures. The stage's `modelAttempts` record the refusing model and its error.
 
 A stage that sets `model` or `fallbackModels` uses only the chain it declares. The `fallbackModels` list in `settings.json` and the chain of the session that launched the workflow never apply to it, so a provider failure cannot move the stage to a model or reasoning level outside the chain you declared. A stage that sets neither runs on the session's current model and keeps that session's fallback behavior.
 
@@ -735,12 +736,14 @@ readonly gitWorktreeDir?: string;
 readonly baseBranch?: string;
 ```
 
-Selects or creates a reusable same-repository Git worktree for `ctx.stage`, `ctx.task`, `ctx.chain`, and `ctx.parallel`.
+Selects or creates a reusable Git worktree for `ctx.stage`, `ctx.task`, `ctx.chain`, and `ctx.parallel`.
 
-- **Creation and validation:** A missing path is created with `git worktree add --detach <path> <baseBranch>` from the canonical main repository root, where an omitted or blank `baseBranch` defaults to `HEAD`. Existing paths must be same-repository worktree roots outside the invoking checkout; the checkout itself, nested targets, and missing targets whose symlinked parent resolves inside it are rejected.
-- **Cwd remapping:** The default cwd preserves the invoking repository-relative subdirectory inside the worktree. Absolute cwd values inside the invoking repository are remapped, values already inside the worktree are preserved, and relative values resolve from the worktree cwd without lexical or symlink escape.
+- **Reuse:** An existing Git worktree or checkout root of any repository is reused as-is, including when the invoking cwd belongs to another repository or to no repository. Its repository identity comes from the worktree itself. Subdirectories of an existing checkout are rejected. Any path, whether existing, empty, or missing, is rejected when it is the invoking checkout, is nested beneath it, or lies inside Git metadata (a `.git` directory, a linked worktree's admin directory, or a bare repository). Inside another repository's working tree only that tree's root is accepted, for reuse; paths below it are rejected. Missing paths and plain directories outside every Git working tree stay allowed.
+- **Creation:** Creating a worktree requires the workflow to start inside the source repository; otherwise setup fails and suggests passing an existing worktree root. A missing path or an empty directory is created with `git worktree add --detach <path> <baseBranch>` from the canonical main repository root, where an omitted or blank `baseBranch` defaults to `HEAD`. Missing targets whose symlinked parent resolves inside the invoking checkout are rejected.
+- **Allocation:** A non-empty directory that is not a Git checkout is treated as a worktree root. The run gets its own detached checkout at `<path>/<4-hex bucket>/<repository-name>` from `baseBranch` of the invoking repository. Existing content and buckets are left untouched, and a failed creation removes the partial checkout and its bucket. The checkout's Git directory records the owning run, so every stage, retry, and resume of the run reuses it, while separate runs get separate checkouts.
+- **Cwd remapping:** The default cwd preserves the invoking repository-relative subdirectory inside a same-repository worktree, and is the worktree root for another repository's worktree. An allocated checkout must contain that subdirectory. Absolute cwd values inside the invoking repository are remapped for same-repository worktrees, values already inside the worktree are preserved, and relative values resolve from the worktree cwd without lexical or symlink escape. Relative `gitWorktreeDir` values resolve from the invoking repository root, or from the invoking cwd outside a Git repository.
 - **Output containment:** Runner-managed reusable-worktree relative outputs follow the effective worktree cwd and cannot escape through traversal or symlinks. Temporary-worktree outputs are copied to distinct runner-owned artifact directories before cleanup, including in `file-only` mode. Explicit absolute outputs remain caller-selected.
-- **Caching and diagnostics:** Temporary isolation defaults to the runner invocation cwd, and relative task cwd values resolve there. Reusable setup is cached by canonical repository and target identity independently of equivalent path spelling or `baseBranch`, revalidates checkout identity before reuse, retries one transient timeout from read-only repository probes, and reports the exact Git command, cwd, timeout, elapsed time, exit status or signal, and spawn error details on failure.
+- **Caching and diagnostics:** Temporary isolation defaults to the runner invocation cwd, and relative task cwd values resolve there. Reusable setup is cached by canonical invoking cwd and target path independently of equivalent path spelling or `baseBranch`, revalidates checkout identity before reuse, retries one transient timeout from read-only repository probes, and reports the exact Git command, cwd, timeout, elapsed time, exit status or signal, and spawn error details on failure.
 - **Security boundary:** Worktrees isolate checkouts and cwd, not the operating system. Use a container, VM, or another OS-enforced boundary for untrusted code that can race or mutate arbitrary paths.
 
 For lower-level integrations, [`setupGitWorktree(options)`](#setupgitworktree-options) returns the validated and remapped setup result.
@@ -1589,7 +1592,7 @@ function setupGitWorktree(options: {
 };
 ```
 
-Synchronously creates or validates a reusable worktree and remaps the cwd. It applies the same validation, symlink-preserving path handling, and cwd-preservation behavior as workflow stages.
+Synchronously creates or validates a reusable worktree and remaps the cwd. It applies the same validation, symlink-preserving path handling, and cwd-preservation behavior as workflow stages. `worktreeRoot` is the checkout in use, which is the allocated `<gitWorktreeDir>/<bucket>/<repository-name>` checkout when `gitWorktreeDir` is a non-empty non-Git directory. Outside a workflow run each such call allocates a new checkout. `repositoryRoot` is the invoking checkout when the worktree belongs to the same repository, and the worktree root otherwise.
 
 ### `normalizeWorkflowName(name)` / `workflowNamesEqual(a, b)`
 

package/docs/workflows/builtins.md

@@ -203,7 +203,7 @@ Each parsed Goal review round and Ralph review round appends convergence evidenc
 
 Declared outputs include `result`, the latest research question and artifact paths, implementation notes, optional QA video and PR reports, approval, iteration count, and review artifacts.
 
-Goal and Ralph both support reusable worktree binding through `git_worktree_dir` and `base_branch`. Use `create_pr=true` only for an explicitly authorized final action after implementation approval. For follow-up runs based on reviewer findings, pass the original task text as `acceptance_criteria` to prevent contract drift.
+Goal and Ralph both support reusable worktree binding through `git_worktree_dir` and `base_branch`. An existing worktree root of any repository is reused as-is, even when the session runs in another repository or outside Git. Creating one requires starting inside the source repository: a missing path or an empty directory becomes the worktree, and a non-empty non-Git directory receives a run-owned checkout at `<dir>/<4-hex>/<repository-name>` that resume reuses. Use `create_pr=true` only for an explicitly authorized final action after implementation approval. For follow-up runs based on reviewer findings, pass the original task text as `acceptance_criteria` to prevent contract drift.
 
 ### `open-claude-design`
 

package/docs/workflows/operations.md

@@ -135,7 +135,7 @@ The no-`runId` status listing includes bounded pending-stage rows after each run
 
 `workflow({ action: "models" })` returns the registry's configured-auth catalog snapshot in registry order. Each entry includes `provider`, `id`, `fullId`, an `isCurrent` marker, and `availableThinkingLevels` derived from the real model's `reasoning` and `thinkingLevelMap` metadata. This is not proof of credentials, entitlements, OAuth freshness, or live provider access, and it exposes no authentication details.
 
-Named launches wait only for **startup admission**, not for workflow completion. Atomic returns `status: "running"` after durable registration, reusable-worktree setup, and other pre-body setup succeed, while the workflow body and stages continue in the background. If setup fails before the workflow body is admitted — for example, `git_worktree_dir` points inside the invoking checkout — the original `workflow` tool call instead returns a structured `status: "failed"` result with the allocated full run id and concrete setup error. Ordinary setup failures retain no background-start claim or orphan run, so the caller can correct the inputs and retry. Database-unavailable admission instead preserves the failed local run and skips durable cleanup; follow the recovery guidance below before retrying. Failures after admission remain ordinary background lifecycle outcomes reported through status and lifecycle notices.
+Named launches wait only for **startup admission**, not for workflow completion. Atomic returns `status: "running"` after durable registration, reusable-worktree setup, and other pre-body setup succeed, while the workflow body and stages continue in the background. If setup fails before the workflow body is admitted — for example, `git_worktree_dir` points inside the invoking checkout, or names a path that must be created while the session is outside the source Git repository — the original `workflow` tool call instead returns a structured `status: "failed"` result with the allocated full run id and concrete setup error. Ordinary setup failures retain no background-start claim or orphan run, so the caller can correct the inputs and retry. Database-unavailable admission instead preserves the failed local run and skips durable cleanup; follow the recovery guidance below before retrying. Failures after admission remain ordinary background lifecycle outcomes reported through status and lifecycle notices. Reusable-worktree setup reuses an existing worktree root of any repository from any session cwd. When `git_worktree_dir` names a non-empty directory that is not a Git checkout, the run gets its own checkout beneath it, and resuming or retrying that run reuses the same checkout.
 
 A model may launch in the foreground only when the user explicitly requests it or foreground execution is technically required, and it must tell the user before launching.
 
@@ -365,7 +365,7 @@ These are distinct operations. *Resuming workflow execution* (`/workflow resume`
 
 Any eligible terminal agent stage with a valid retained session opens as an interactive post-mortem chat through the explicit user-driven TUI path: completed-workflow inspection, `/workflow attach`, or `/workflow connect` followed by stage selection, including restored/replayed durable snapshots after a restart. Explicit `/workflow attach <root-run> <nested-stage>` targets are resolved through the expanded graph and routed to the child run that owns the stage while the overlay remains rooted on the requested graph; the resolved owner is preserved when sibling child workflows reuse the same local stage ID.
 
-When a run ends, whether it completed, failed, or was cancelled, Atomic disposes the live session of each completed stage whose conversation is saved, so a long-lived session does not hold every finished stage in memory. Resuming a failed run replays its completed stages from the saved run and does not need their live sessions. A paused or still-running run keeps its sessions. Attaching to such a stage or messaging it reopens the saved conversation first, which takes a moment, without rerunning the workflow. While the session that ran the workflow is open, the released stage also stays in the Intercom session list under its previous name as `closed · reply: post-mortem only`: an ask to it reopens the saved conversation, runs one turn with the question, and returns that turn's final answer (or a failure if the conversation cannot be reopened), and a plain send is delivered to the session that ran the workflow. Once that session ends or is replaced, the Intercom entry is gone; reopen the stage with `/workflow attach`. A stage with a mounted chat (visible or hidden), queued or in-flight messages, an active turn, compaction or retry, or no saved transcript keeps its live session, and it is not released again when that need ends; it stays until the session that ran the workflow is replaced or shut down. A stage you reopen by attaching, messaging, or an Intercom ask also stays in memory until then, so memory grows by one session for each released stage you actually reopen. The saved transcript, result, and run record are never removed.
+Atomic disposes the live session of each completed stage whose conversation is saved, so a long run or a long-lived session does not hold every finished stage in memory. A stage run with `ctx.task`, `ctx.chain` or `ctx.parallel` is released as soon as it completes, a stage run with `ctx.stage` once the workflow no longer holds its stage context, and every remaining completed stage when the run ends, whether it completed, failed, or was cancelled. Resuming a failed run replays its completed stages from the saved run and does not need their live sessions. A stage context the workflow still holds keeps its session, so `ctx.stage` can prompt it again. Attaching to such a stage or messaging it reopens the saved conversation first, which takes a moment, without rerunning the workflow. While the session that ran the workflow is open, the released stage also stays in the Intercom session list under its previous name as `closed · reply: post-mortem only`: an ask to it reopens the saved conversation, runs one turn with the question, and returns that turn's final answer (or a failure if the conversation cannot be reopened), and a plain send is delivered to the session that ran the workflow. Once that session ends or is replaced, the Intercom entry is gone; reopen the stage with `/workflow attach`. A stage with a mounted chat (visible or hidden), queued or in-flight messages, an active turn, compaction or retry, or no saved transcript keeps its live session, and it is not released again when that need ends; it stays until the session that ran the workflow is replaced or shut down. A stage you reopen by attaching, messaging, or an Intercom ask also stays in memory until then, so memory grows by one session for each released stage you actually reopen. The saved transcript, result, and run record are never removed.
 
 Intercom and explicit `/workflow attach` own stage communication. The workflow tool has no free-form message action; start a new workflow if tracked work remains after a terminal root.
 
@@ -902,7 +902,7 @@ Each worker process must report that it is ready within `localWorkers.startupTim
 
 A worker that exits is detected immediately, and its child is replayed from its last committed checkpoint on a replacement worker. A worker that is still running keeps its child as long as it keeps responding, even when the pool is briefly too busy to process its heartbeats. Only a running worker that has not responded for `localWorkers.leaseMs` milliseconds (30000 by default) is stopped and its child replayed. When a root is resumed after its process crashed, children that were held by the crashed process's workers are replayed on the new workers right away.
 
-A worker that exits or is killed while it runs a child does not stop the root. The root fences that worker's attempt and replays the child from its last committed checkpoint on a replacement worker, up to three attempts per child. A child that loses its third worker fails alone with `worker_retry_limit`; the pool and the root's other children keep running. One child's failure never stops the pool: it fails only that child, and the pool closes when the root ends. A child whose result was recorded keeps it whatever happens to the pool afterwards. A fault of the pool itself that reaches a running child, such as a journal write the database refused or a refused lease (`stale_work_lease`), replays the child the same way instead of failing it; after its third attempt the child fails with the retryable `worker_retry_limit`, naming the fault. A busy machine slows workers but does not fail them: a worker that still responds keeps its child however late its heartbeats are processed, and a stage's queued Intercom messages are delivered however slowly the worker acknowledges them.
+A worker that exits or is killed while it runs a child does not stop the root. The root fences that worker's attempt and replays the child from its last committed checkpoint on a replacement worker, up to three attempts per child. A child that loses its third worker fails alone with `worker_retry_limit`; the pool and the root's other children keep running. One child's failure never stops the pool: it fails only that child, and the pool closes when the root ends. A child whose result was recorded keeps it whatever happens to the pool afterwards. A fault of the pool itself that reaches a running child, such as a journal write the database refused or a refused lease (`stale_work_lease`), replays the child the same way instead of failing it; after its third attempt the child fails with the retryable `worker_retry_limit`, naming the fault. A busy machine slows workers but does not fail them: a worker that still responds keeps its child however late its heartbeats are processed, and a stage's queued Intercom messages are delivered however slowly the worker acknowledges them. A stage on a worker reads its queued and sticky Intercom messages itself and receives them before its first turn, so it starts without waiting for a busy root. If the root later fails to record or deliver them, the run's status shows one `Intercom delivery:` line for the whole run; the messages stay queued and arrive live or on the stage's next drain.
 
 When the pool cannot confirm a worker's cleanup, the worker is retired and replaced, and its unfinished child replays on another worker. This happens when a tool process group the worker started is still running after SIGKILL, or the worker process itself outlives SIGKILL. The event shows as a warning on the root run and is written to the worker's log. It never fails a child. The process permits of those groups stay counted against `admission.limits`, and closing the pool reports them. Processes that a command detaches into their own session, such as an `ssh` ControlMaster daemon, are not part of the worker's cleanup and do not delay it.
 

package/npm-shrinkwrap.json

@@ -1,16 +1,16 @@
 {
 	"name": "@bastani/atomic",
-	"version": "0.9.61-alpha.1",
+	"version": "0.9.61-alpha.2",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "@bastani/atomic",
-			"version": "0.9.61-alpha.1",
+			"version": "0.9.61-alpha.2",
 			"license": "MIT",
 			"dependencies": {
-				"@bastani/atomic-natives": "0.9.61-alpha.1",
-				"@bastani/pi-ai": "0.9.61-alpha.1",
+				"@bastani/atomic-natives": "0.9.61-alpha.2",
+				"@bastani/pi-ai": "0.9.61-alpha.2",
 				"@earendil-works/pi-agent-core": "1.4.0",
 				"@earendil-works/pi-codemode": "1.4.0",
 				"@earendil-works/pi-tui": "1.4.0",
@@ -427,18 +427,18 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"optionalDependencies": {
-				"@bastani/atomic-natives-darwin-arm64": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-darwin-x64": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-linux-arm64-musl": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-linux-x64-gnu": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-linux-x64-musl": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.61-alpha.1",
-				"@bastani/atomic-natives-win32-x64-msvc": "0.9.61-alpha.1"
+				"@bastani/atomic-natives-darwin-arm64": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-darwin-x64": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-linux-arm64-musl": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-linux-x64-gnu": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-linux-x64-musl": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.61-alpha.2",
+				"@bastani/atomic-natives-win32-x64-msvc": "0.9.61-alpha.2"
 			},
 			"engines": {
 				"bun": ">=1.4.2",
@@ -446,8 +446,8 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives-darwin-arm64": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -458,8 +458,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-darwin-x64": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -470,8 +470,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-gnu": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -485,8 +485,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-musl": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -500,8 +500,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-gnu": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -515,8 +515,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-musl": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -530,8 +530,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-arm64-msvc": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -542,8 +542,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-x64-msvc": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -554,8 +554,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/pi-ai": {
-			"version": "0.9.61-alpha.1",
-			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.61-alpha.1.tgz",
+			"version": "0.9.61-alpha.2",
+			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.61-alpha.2.tgz",
 			"license": "MIT",
 			"dependencies": {
 				"@anthropic-ai/sdk": "0.129.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/atomic",
-  "version": "0.9.61-alpha.1",
+  "version": "0.9.61-alpha.2",
   "description": "Atomic coding agent CLI with read, bash, edit, write tools and session management",
   "type": "module",
   "atomicConfig": {
@@ -89,8 +89,8 @@
     "prepublishOnly": "bun run clean && bun run build && bun run shrinkwrap"
   },
   "dependencies": {
-    "@bastani/atomic-natives": "0.9.61-alpha.1",
-    "@bastani/pi-ai": "0.9.61-alpha.1",
+    "@bastani/atomic-natives": "0.9.61-alpha.2",
+    "@bastani/pi-ai": "0.9.61-alpha.2",
     "@earendil-works/pi-agent-core": "1.4.0",
     "@earendil-works/pi-codemode": "1.4.0",
     "@earendil-works/pi-tui": "1.4.0",

package/schemas/settings.schema.json

@@ -282,6 +282,11 @@
           "description": "Maximum agent-level backoff delay in milliseconds. 0 retries immediately.",
           "default": 60000
         },
+        "fallbackOnContentFilter": {
+          "type": "boolean",
+          "description": "When a provider's content filter refuses a request, such as OpenAI's HTTP 422 cyber_policy, move to the next fallback model instead of retrying the same one.",
+          "default": true
+        },
         "provider": {
           "type": "object",
           "properties": {