@bastani/atomic 0.9.19-alpha.3 → 0.9.19-alpha.5

package/docs/workflows/verification.md

@@ -1,79 +1,138 @@
 # Verification and evidence
 
-Use executable verification appropriate to the changed behavior. Workflow authors should put the same evidence contract in worker, reviewer and final handoff prompts. Goal and Ralph share this guidance. Reviewers inspect actual artifacts and results, not claims or filenames.
+Verify the behavior that changed, then give the reviewer enough evidence to understand the result. A small fix may need a focused test and a short explanation. An interactive change usually needs a real user scenario as well. A video is useful when it shows something a test log or screenshot cannot; it is not required for every PR.
 
-## Execution mode
+For tool installation, automation techniques, platform permissions, and general work in applications, read [Computer use](/computer-use). That guide covers Herdr for terminals, playwright-cli for browsers, and PyAutoGUI with uv for desktop CUA on macOS, Linux, and Windows. It also covers native accessibility and application tools when they are easier or more reliable.
 
-An explicit request to work `quickly`, `inline`, `do this directly`, `don't use a workflow`, or equivalent overrides workflow-first defaults for that task, including complex implementation and review loops. Treat "quickly" as an inline execution choice, not a request for a faster workflow. Do not create or launch a hidden or nested replacement workflow, or ask the user to reapprove the choice. Keep appropriate testing, review and evidence inline. Safety and authorization requirements do not change.
+## Choose checks that answer the question
 
-Apply the preference only to its stated task. Quoted examples and questions about inline code are not execution-mode instructions; neither are descriptions of software that should run quickly. Without an opt-out, normal workflow fit defaults apply.
+Start with the project's existing tests, build, typecheck, and lint commands. Add an interactive scenario when the change affects what a user sees or does. Do not replace required checks with a recording, or create a UI solely to demonstrate a non-UI change.
 
-If the user switches during an active workflow, safely hold or stop the affected run using its available lifecycle controls. Reconcile completed work and in-flight side effects before continuing inline so commands and external writes are not duplicated. Stages notify the controlling session rather than launching a replacement. Already-completed work remains completed; do not claim it was undone.
+| Changed behavior | Preferred mechanism | What to check |
+| --- | --- | --- |
+| Interactive terminal or TUI | **Herdr**, under its explicit-request and managed-pane requirements; tmux or native Windows psmux as fallbacks | Actual input, rendered output, navigation, resizing, and exit behavior relevant to the change. |
+| Browser/frontend | **playwright-cli** | The user flow and its visible result, with DOM or network assertions where useful. |
+| Desktop app, simulator, or emulator | **PyAutoGUI with uv**, supplemented by native/app APIs | The visible app scenario and its saved or exported result. |
+| API, library, script, or other non-UI behavior | Existing test runner and shell commands | Inputs, outputs, error handling, and relevant build/type contracts. |
+| Documentation | Documentation checks and example review | Links, navigation, command accuracy, and whether a reader can follow the instructions. |
 
-## Select the verification environment
+See [tool selection](/computer-use#choose-the-right-tool) before operating a session. Herdr is the terminal priority, but the preference does not authorize control from outside a Herdr-managed pane. Install missing tools when permitted; otherwise use the available fallback and describe any coverage gap.
 
-The same routing applies when a user asks for automation outside a verification workflow. Use PyAutoGUI for desktop computer use, also called CUA, and the playwright-cli skill for browser automation. Prefer herdr for terminal automation/testing on macOS, Linux and Windows. Install it if missing when network access and permissions permit; fall back to tmux or native Windows psmux when installation or use is not possible. Load the matching skill before acting. The pinned upstream herdr skill still requires an explicit user mention or request and `HERDR_ENV=1`; preference does not authorize control from outside a Herdr-managed pane. Keep desktop failsafes enabled and release held keys/buttons after interruption.
+## Define a reproducible scenario
 
-Inspect installed tools, cached runtimes, existing sessions and safe test configuration first. Install missing tools/plugins when online access and permissions permit. Known offline or restricted installation is enough reason not to attempt a prohibited download. Otherwise make a reasonable capability check or one bounded setup attempt, not an endless installation retry loop.
+Before running it, write down:
 
-When a mechanism cannot run, continue available authoritative repository checks, retain useful local evidence, and record the constraint, attempted commands and observed output, narrower validation and missing coverage. Do not require production credentials or take unsafe actions to satisfy a generic verification suggestion. An unavailable optional mechanism is not failed implementation, but it does not waive a required project check.
+- The behavior being verified and the expected result.
+- The commit or artifact under test, plus any uncommitted changes.
+- The environment that matters, such as OS, app/browser version, terminal dimensions, display scaling, and test fixtures.
+- The actions and assertions, including a relevant failure or edge case.
 
-| Changed behavior | Verification and evidence |
-| --- | --- |
-| Browser/frontend, including API-dependent flows | Use the playwright-cli skill. Exercise the real user flow and assert its result. Retain current screenshots, video, DOM snapshots or network evidence as appropriate. |
-| TUI/terminal | Prefer the herdr skill on macOS, Linux and Windows under its explicit-request and managed-pane requirements. Install if missing when permitted; fall back to the tmux skill or native Windows psmux if unavailable or unusable. Exercise actual interactive input and inspect pane output or a terminal recording. These tools do not have interchangeable CLIs. |
-| Desktop/simulator/emulator | Use PyAutoGUI for desktop CUA, with native platform tools where they provide safer input or better assertions. Capture screenshots/video from a real visible app scenario, not a browser recording labeled as desktop or iOS proof. |
-| Non-UI | Run relevant unit, integration, build, type or command-line scenarios. Do not manufacture a UI or video requirement. |
+Use dedicated sessions and non-production data. Wait for observable completion with a deadline instead of assuming that a submitted command or a fixed delay means success. Preserve useful failure output before cleanup.
 
-### Terminal contracts
+After a repair, rerun the affected checks on the new candidate. Label before/after evidence and keep it clear which commit produced each result. Do not present an earlier passing run as verification of later edits.
 
-Herdr supports macOS, Linux and Windows. Check `herdr --version` and, inside a managed pane, `herdr status` before installing or relying on server features. If missing, use the [official installation instructions](https://github.com/herdrdev/herdr/tree/v0.9.0#install): `brew install herdr` on macOS, the reviewed `https://herdr.dev/install.sh` installer on macOS/Linux, or `https://herdr.dev/install.ps1` on Windows. Inspect downloaded installer code before executing it, follow host permissions and use a bounded setup attempt. Do not stop or replace a running server to make a test work. If installation is blocked or no eligible Herdr session is available, record the constraint and use tmux/psmux rather than taking over the focused session.
+## Capture evidence appropriate to the change
 
-[psmux](https://github.com/psmux/psmux) is a native Windows ConPTY multiplexer using tmux-style commands. Its [scripting guide](https://github.com/psmux/psmux/blob/master/docs/scripting.md) documents `psmux capture-pane -p -t %0` for stdout capture. Verify installed help and use the actual pane identifier rather than assuming `%0` belongs to the test.
+### Browser changes
 
-[herdr's CLI](https://herdr.dev/docs/cli-reference/) talks to a running server. Discover your isolated test pane with `herdr pane list`. `herdr pane run <pane_id> <command>` submits a command with Enter; `herdr pane send-text` alone does not submit. `herdr pane read <pane_id> --source visible` returns the screen text. For bounded waits use `herdr pane wait-output <pane_id> --match <text> --timeout 10000`. Do not confuse pane output with an agent lifecycle status or infer success from `idle`. Check installed version/help and host support before use. Do not take over unrelated panes.
+Use playwright-cli to exercise the actual flow. A screenshot can show layout; a DOM snapshot can show control state; console and network output can help establish why a flow failed. Pair captures with assertions about the result, such as a saved record appearing after reload.
 
-### Reproduce stage skill terminal evidence
+For a named browser session you own, the CLI supports captures such as:
 
-From an Atomic source checkout, install dependencies with `npm ci --ignore-scripts` and run `npm run build`. With Node, Bun, tmux and a POSIX shell on PATH, run the committed driver:
+```sh
+playwright-cli -s=pr-check snapshot --filename=after.yaml
+playwright-cli -s=pr-check screenshot --filename=after.png
+```
+
+For behavior best shown in motion, check the installed CLI's help, start recording before the relevant actions, and stop afterward:
 
 ```sh
-node test/fixtures/stage-chat-skill-driver.mjs --evidence-dir /tmp/stage-skills-80 --columns 80 --rows 24
-node test/fixtures/stage-chat-skill-driver.mjs --evidence-dir /tmp/stage-skills-48 --columns 48 --rows 16
+playwright-cli -s=pr-check video-start flow.webm
+# Exercise the scenario here.
+playwright-cli -s=pr-check video-stop
 ```
 
-Use a fresh evidence directory for each run; existing directories are refused. The driver executes `test/fixtures/stage-chat-skill-terminal.ts` directly with Bun, not `bun build`. No provider credentials are needed. It waits for the real editor to clear and the notice to render after each `/tasks` command before typing the next command, then verifies stage-local skill selection and invocation. Captures, assertions, render barriers and session events stay in the requested directory. Failures retain diagnostics and clean up the dedicated tmux session.
+Open the saved artifact and confirm it includes the final state. Keep recordings short and focused. Inspect traces, authentication state, and network output for secrets before sharing. See [browser setup and best practices](/computer-use#browser-automation-with-playwright-cli).
+
+### Terminal changes
+
+Use Herdr to send real interactive input and inspect the resulting pane, or use tmux/psmux when Herdr cannot be used. Keep the terminal dimensions and shell relevant to the change. Test narrow layouts or modified keys when those are affected.
+
+Retain screen captures or transcripts that show the input and result. For cursor movement, redraws, colors, or timing, a terminal recording or video may explain more than plain text. Capture important states during the run; alternate-screen content may not remain in scrollback. Check exit status or explicit assertions rather than treating an agent's `idle` indicator as a passing result.
+
+See [terminal setup and capture commands](/computer-use#terminal-automation-with-herdr). A browser rendering of terminal text is not proof that the real TUI accepted input. WSL tmux does not establish native Windows terminal coverage.
+
+### Desktop, simulator, and emulator changes
+
+Run PyAutoGUI through uv in a dedicated graphical session, using [the desktop guide](/computer-use#desktop-automation-with-pyautogui-and-uv). Native accessibility tools or application APIs can give more reliable assertions than pixel matching. For example, check a saved document through the app API after exercising the visible Save flow.
+
+Capture the actual application or simulator. A browser recording is not desktop or iOS evidence. PyAutoGUI can interact with a visible simulator/emulator window, but does not directly control an arbitrary physical phone. Use supported native tooling where needed, and name the device or emulator actually exercised.
+
+Keep failsafes enabled and release held keys/buttons after interruption. Inspect saved files and exports rather than assuming a completed click means a completed operation. Screenshots show appearance, not necessarily persistence or correctness.
+
+## Use evidence in a workflow
 
-The small driver contract tests run in the normal unit suite. The actual tmux scenario is an explicit local verification command, not an automatic CI terminal test. This POSIX driver does not establish Windows coverage.
+Give workers, reviewers, and the final handoff the same scenario and success criteria. A verification stage should produce commands, observed results, and artifact paths. The reviewer should inspect those results, not just accept the worker's summary or a filename.
 
-### Desktop safety
+For workflow-owned checks, use durable `ctx.tool` calls with finite timeouts and cancellation. Pass scripts and larger evidence through files. After a failed check, send the actual failure to a bounded repair step and rerun the affected checks. Keep implementation acceptance separate from later PR creation, upload, or publication. See [workflow authoring](/workflows/authoring) and [reliable design](/workflows/reliable-design).
 
-The [OpenAI CUA sample](https://github.com/openai/openai-cua-sample-app#first-run) distinguishes JavaScript Playwright browser control from Python PyAutoGUI desktop input. It is an optional sample requiring API/model access, not a prerequisite for every GUI test. Follow its [Python quickstart and interruption guidance](https://github.com/openai/openai-cua-sample-app/blob/main/python-app/README.md).
+### Execution mode
 
-Use a dedicated desktop/session with controlled fixtures. macOS needs Accessibility and Screen Recording permissions for the launching app; Linux PyAutoGUI needs an appropriate X11 desktop and dependencies; Windows needs a graphical session. Screenshots may include other windows and PyAutoGUI controls real mouse and keyboard input. Keep failsafes enabled, inspect privacy before saving/sharing, release held keys/buttons after interruption, and check for leftover processes before restarting. Do not install the sample's pnpm dependencies into an npm repository.
+The same verification standard applies inline. A task-scoped request such as `quickly`, `inline`, or `don't use a workflow` means no workflow creation or launch, including hidden replacements. If switching an active run to inline, stop or hold it safely and reconcile completed work and in-flight effects before continuing. See [when to use workflows](/workflows#when-to-use-workflows).
 
-A visible simulator/emulator or suitable native automation/mirroring setup is required for mobile UI. PyAutoGUI does not directly control an arbitrary physical iPhone. Use native platform tooling where it provides better assertions or safer input.
+## When a tool or environment is unavailable
 
-## qlty setup and fallback
+Inspect installed tools and cached runtimes first. Install missing tools or plugins when network access and permissions allow. If installation is restricted, or no suitable graphical session is available, continue the checks that can run and record:
 
-Use the qlty skill to choose reliable, low-noise checks and useful metrics based on user priorities and repository evidence. Preserve existing `.qlty/qlty.toml`, the project's chosen tools such as Biome, and authoritative package/CI checks. Do not add competing formatters or run wholesale formatting by habit. Record command/output, scope and a relevant baseline; numbers without a decision are not useful verification.
+- What was unavailable and the observed error or known restriction.
+- Any setup attempt and the narrower checks that actually ran.
+- What still needs verification, including missing platform coverage.
 
-During authorized coding, absent config permits `qlty init --no` or a hand-authored `.qlty/qlty.toml`; inspect generated suggestions. Missing config alone is not a blocker. For offline/restricted installation or a missing binary, use the skill's bundled manual-configuration reference to prepare TOML without network when configuration edits are in scope. Use source-backed options, omit unknown optional plugin versions rather than inventing them, and validate syntax/schema with available tools. Read-only tasks stay read-only or use isolated scratch config.
+Do not require production credentials or bypass permissions to satisfy a generic verification suggestion. An optional tool being unavailable is not an implementation failure, but a required project check remains required. Do not label skipped, mocked, or simulated coverage as a real platform run.
 
-Installed built-in metrics/smells may work offline. Cached plugins may work too, but uncached source/plugin/runtime resolution can require downloads. Report configuration prepared separately from lint/security/metrics actually run. TOML parsing is not proof of plugin availability or a passing quality check. Continue available repository checks without making optional qlty installation a universal blocker.
+### qlty setup and fallback
 
-## Native GitHub media
+Use the qlty skill when it adds useful lint, security, or complexity checks. Preserve the repository's existing tools and `.qlty/qlty.toml`; do not introduce a competing formatter or wholesale formatting changes.
 
-Only publish to an authorized target. Detect the provider first and inspect/redact artifacts for secrets, personal information and unrelated windows. Name the verified commit and scenario in the accompanying evidence. Collection alone is not upload authorization.
+When configuration changes are in scope, missing config can be initialized with `qlty init --no` or prepared manually using the skill's bundled configuration reference. Review generated suggestions. Read-only tasks should remain read-only or use isolated scratch configuration.
 
-[GitHub CLI >=2.99.0](https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments/) supports repeatable `--attach` on `gh issue create`, `edit`, `comment` and `gh pr create`, `edit`, `comment`. Check `gh --version` and the specific command's `--help` before using it. For an authorized PR comment:
+Cached plugins and built-in metrics may work offline; uncached plugins or runtimes may need downloads. Report prepared configuration separately from checks actually executed. Valid TOML is not proof that a plugin ran. Optional qlty setup should not block available repository checks.
+
+## Include evidence in a PR
+
+Give the reviewer a short summary before linking logs or media. For example, replace the placeholders in this template with observed results:
+
+```markdown
+## Verification
+
+- Candidate: <commit SHA; note any uncommitted changes>
+- Environment: <OS, app/tool versions, relevant dimensions>
+- Checks: <command and result>
+- Scenario: <starting state, actions, expected and observed result>
+- Evidence: <hosted links or attached artifacts>
+- Limits: <checks/platforms not exercised>
+```
+
+Attach a screenshot for a visual state, a short recording for an interaction, or logs for command behavior. Include reproduction steps even when media is available. Label local-only paths as local; reviewers cannot open a file on your machine. CI artifact links are useful when readers have access, but note retention limits where relevant.
+
+Only upload to an authorized repository or destination. Inspect and redact secrets, personal information, private source content, and unrelated windows before attaching files. Permission to collect local evidence is not permission to publish it.
+
+### Native GitHub media
+
+[GitHub CLI 2.99.0 and newer](https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments/) supports repeatable `--attach` on issue and PR `create`, `edit`, and `comment` commands. Check `gh --version`, the specific command's `--help`, and the host's [attachment support and limits](https://docs.github.com/en/github-cli/github-cli/attaching-files-with-github-cli).
+
+For an authorized PR comment, replace the target and file paths:
 
 ```sh
-gh pr comment 123 --repo owner/repo --body-file evidence.md --attach proof.mp4
+gh pr comment 123 --repo owner/repo --body-file evidence.md \
+  --attach 'after.png#Settings panel after saving' \
+  --attach flow.webm
 ```
 
-Use actual target and file values. Attach each file once. A body-local path reference is rewritten to the hosted URL; other attachments append in flag order. Images can use `--attach 'screen.png#Image alt text'`; videos do not support alt text. A standalone `![](proof.mp4)` paragraph is rewritten to an embedded player. See [official attachment documentation](https://docs.github.com/en/github-cli/github-cli/attaching-files-with-github-cli).
+The backslashes above are POSIX shell continuations. In PowerShell, use a single line or PowerShell continuation syntax.
+
+Attach each file once. The CLI rewrites body-local attachment references to hosted URLs; otherwise it appends attachments in flag order. Images support `#Image alt text`; videos do not support alt text. A standalone `![](flow.webm)` paragraph in the body becomes an embedded player. These are CLI attachment features, not support for arbitrary local paths in GitHub Markdown.
 
-Supported media include PNG, JPEG, GIF, WebP, SVG, MP4, MOV and WebM. Images/GIFs have a 10 MB limit; video limits are 10 MB on Free and 100 MB on paid plans. Repository write access and supported OAuth/classic PAT authentication are required; this release does not support GitHub Enterprise Server. Recheck current limits for the chosen host/account.
+Supported media include PNG, JPEG, GIF, WebP, SVG, MP4, MOV, and WebM. Uploads require repository push access and supported authentication. Recheck current size limits and authentication support for the target account and host. The 2.99.0 release does not support GitHub Enterprise Server.
 
-Read back the created or edited issue/PR/comment and confirm usable GitHub-hosted links before reporting success. Unsupported versions, hosts, providers, auth or sizes require a truthful fallback: retain the local artifact and explain authorized manual attachment or supported provider tooling. Do not claim a `file://` reference is uploaded evidence or send artifacts to unrelated third-party hosts.
+Read back the created or edited PR/comment and confirm usable hosted links before reporting an upload as successful. If the CLI, provider, authentication, or file size is unsupported, retain the local artifact and explain the manual attachment path or supported provider tooling. Do not upload to an unrelated host to work around a limitation.

package/docs/workflows.md

@@ -11,7 +11,7 @@ Default to a workflow for non-trivial work with a verifiable objective — see [
 - **Parallel branches** - Run independent research, review, or implementation branches concurrently
 - **Context handoffs** - Pass summaries, artifacts, files, and schema-backed structured results between stages
 - **Human input** - Pause for `ctx.ui.input`, `confirm`, `select`, `editor`, or custom TUI widget decisions during a run
-- **Resumable control** - Interrupt, pause, quit, resume, or connect to workflow runs
+- **Resumable control** - Pause, quit, resume, or connect to workflow runs
 - **Intercom run notifications** - Deliver async run results and control notices (long-running, needs-attention, completed, failed) to a parent session over [Intercom](/intercom)
 - **Artifacts** - Save large outputs to files instead of pushing everything through model context
 - **Verification and gates** - Preserve evidence, run checks, and stop for human approval where reliability matters
@@ -40,6 +40,8 @@ Prefer composing builtin definitions with `ctx.workflow(...)` over copying or re
 4. [Operations](/workflows/operations) — run, inspect, steer, pause, resume, and configure workflows.
 5. [API reference](/workflows/api-reference) — look up definitions, contexts, options, results, and programmatic APIs.
 
+For checking changes and sharing results in PRs, see [Verification and evidence](/workflows/verification). For general desktop, browser, and terminal work, including creative workflows, see [Computer use](/computer-use).
+
 ## When to Use Workflows
 
 Unless the user explicitly chooses inline execution, workflows are the default for non-trivial requests or structured work with a verifiable objective. Requests such as `quickly`, `inline`, `do this directly`, and `don't use a workflow` override that default for the specified task, even when complex. Treat "quickly" as an inline execution choice, not a request for a faster workflow. Do not launch a hidden/nested replacement or ask the user to reapprove the choice. Preserve testing, review, evidence, safety and authorization inline. Quoted examples, questions about inline code, and descriptions of software that should run quickly are not mode instructions. For an active switch, safely hold/stop the affected run and reconcile completed work and in-flight effects before continuing without duplicates; completed work is not undone. See [Verification and evidence](/workflows/verification).
@@ -66,7 +68,7 @@ If exploration drifts without progress, save findings and choose a concrete next
 
 | User need | Use |
 |-----------|-----|
-| Run, inspect, connect to, pause, interrupt, quit, resume, or check status for an existing workflow | `/workflow ...` or `workflow({ action: ... })` |
+| Run, inspect, connect to, pause, quit, resume, or check status for an existing workflow | `/workflow ...` or `workflow({ action: ... })` |
 | Run repository-wide research | Compose `fan-out-and-synthesize` with repository-focused branches, artifact outputs, and a synthesis barrier, or author a smaller task-specific research workflow. |
 | Run an implementation/review loop | Author a task-specific worker → fresh verifier → reducer loop with explicit evidence, repair bounds, and stop conditions. |
 | Create or edit reusable automation | A TypeScript workflow definition exported from `workflow({...})` |

package/npm-shrinkwrap.json

@@ -1,16 +1,16 @@
 {
 	"name": "@bastani/atomic",
-	"version": "0.9.19-alpha.3",
+	"version": "0.9.19-alpha.5",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "@bastani/atomic",
-			"version": "0.9.19-alpha.3",
+			"version": "0.9.19-alpha.5",
 			"license": "MIT",
 			"dependencies": {
-				"@bastani/atomic-natives": "0.9.19-alpha.3",
-				"@bastani/pi-ai": "0.9.19-alpha.3",
+				"@bastani/atomic-natives": "0.9.19-alpha.5",
+				"@bastani/pi-ai": "0.9.19-alpha.5",
 				"@dbos-inc/dbos-sdk": "4.25.14",
 				"@earendil-works/pi-agent-core": "0.85.1",
 				"@earendil-works/pi-client": "0.85.1",
@@ -518,18 +518,18 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"optionalDependencies": {
-				"@bastani/atomic-natives-darwin-arm64": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-darwin-x64": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-linux-arm64-musl": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-linux-x64-gnu": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-linux-x64-musl": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.19-alpha.3",
-				"@bastani/atomic-natives-win32-x64-msvc": "0.9.19-alpha.3"
+				"@bastani/atomic-natives-darwin-arm64": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-darwin-x64": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-linux-arm64-musl": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-linux-x64-gnu": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-linux-x64-musl": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.19-alpha.5",
+				"@bastani/atomic-natives-win32-x64-msvc": "0.9.19-alpha.5"
 			},
 			"engines": {
 				"bun": ">=1.4.2",
@@ -537,8 +537,8 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives-darwin-arm64": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -549,8 +549,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-darwin-x64": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -561,8 +561,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-gnu": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -576,8 +576,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-musl": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -591,8 +591,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-gnu": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -606,8 +606,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-musl": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -621,8 +621,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-arm64-msvc": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -633,8 +633,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-x64-msvc": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -645,8 +645,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/pi-ai": {
-			"version": "0.9.19-alpha.3",
-			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.19-alpha.3.tgz",
+			"version": "0.9.19-alpha.5",
+			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.19-alpha.5.tgz",
 			"license": "MIT",
 			"dependencies": {
 				"@anthropic-ai/sdk": "0.124.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/atomic",
-  "version": "0.9.19-alpha.3",
+  "version": "0.9.19-alpha.5",
   "description": "Atomic coding agent CLI with read, bash, edit, write tools and session management",
   "type": "module",
   "atomicConfig": {
@@ -79,8 +79,8 @@
     "prepublishOnly": "bun run clean && bun run build && bun run shrinkwrap"
   },
   "dependencies": {
-    "@bastani/atomic-natives": "0.9.19-alpha.3",
-    "@bastani/pi-ai": "0.9.19-alpha.3",
+    "@bastani/atomic-natives": "0.9.19-alpha.5",
+    "@bastani/pi-ai": "0.9.19-alpha.5",
     "@dbos-inc/dbos-sdk": "4.25.14",
     "@earendil-works/pi-agent-core": "0.85.1",
     "@earendil-works/pi-client": "0.85.1",