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

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,9 +902,9 @@ 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.
+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 quarantined: they stay counted against `admission.limits`, and closing the pool reports them. A tool process that waits for capacity which only quarantined permits hold waits at most 15 seconds for those groups to exit. It then fails with the retryable `worker_cleanup_unconfirmed`, naming the groups and the limit, and on a worker that ends the child's attempt, so the child replays within its three attempts and then fails with `worker_retry_limit` instead of waiting forever. Capacity held by running work is waited for however long it takes. 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.
 
 If the root process exits, even when it is killed, the pool's coordinator and workers exit with it. Resume the root to continue its children. If the coordinator process itself dies, its workers exit with it, and each pooled child the root is waiting on fails with the retryable `worker_lost` fault and the message `Local worker pool coordinator exited (…)`.
 

package/npm-shrinkwrap.json

@@ -1,16 +1,16 @@
 {
 	"name": "@bastani/atomic",
-	"version": "0.9.61-alpha.1",
+	"version": "0.9.61-alpha.3",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "@bastani/atomic",
-			"version": "0.9.61-alpha.1",
+			"version": "0.9.61-alpha.3",
 			"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.3",
+				"@bastani/pi-ai": "0.9.61-alpha.3",
 				"@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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.61-alpha.3.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.3",
+				"@bastani/atomic-natives-darwin-x64": "0.9.61-alpha.3",
+				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.61-alpha.3",
+				"@bastani/atomic-natives-linux-arm64-musl": "0.9.61-alpha.3",
+				"@bastani/atomic-natives-linux-x64-gnu": "0.9.61-alpha.3",
+				"@bastani/atomic-natives-linux-x64-musl": "0.9.61-alpha.3",
+				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.61-alpha.3",
+				"@bastani/atomic-natives-win32-x64-msvc": "0.9.61-alpha.3"
 			},
 			"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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.61-alpha.3.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.3",
+			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.61-alpha.3.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.3",
   "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.3",
+    "@bastani/pi-ai": "0.9.61-alpha.3",
     "@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": {