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

package/CHANGELOG.md

@@ -2,6 +2,25 @@
 
 ## [Unreleased]
 
+## [0.9.11-alpha.5] - 2026-07-23
+
+### Changed
+
+- Added Orwell's six writing rules from “Politics and the English Language” to the core default system prompt's `Guidelines` section so every standard Atomic session receives them, while removing the bundled workflow guidance's requirement to announce an inline-or-workflow mode before the first tool call.
+
+## [0.9.11-alpha.4] - 2026-07-23
+
+### Changed
+
+- Installed builds now ship the builtin workflows extension as a single prebundled ESM file. Loading it previously resolved and transpiled a ~300-file TypeScript module graph per launch, which dominated interactive-engine startup on Windows (~7 s on a test VM, now ~1.1 s, ~6x faster) ([#1962](https://github.com/bastani-inc/atomic/issues/1962)). Source checkouts still load the raw TypeScript sources.
+- Interactive TUI startup on Windows is dramatically faster: the CLI now enables Node's persistent on-disk V8 compile cache (Node >= 22.8) and flushes it before spawning the isolated interactive engine, so both the host and the engine child reuse compiled module bytecode across runs and within the same launch ([#1962](https://github.com/bastani-inc/atomic/issues/1962)).
+
+### Fixed
+
+- Fixed interactive startup crashing with `Interactive engine did not become ready within 5000 ms` on machines with slow cold starts (commonly Windows PowerShell with npm-global installs). The fixed readiness deadline is removed; the host now waits until the engine reports ready and still fails fast if the engine process exits or the transport breaks ([#1962](https://github.com/bastani-inc/atomic/issues/1962)).
+- Fixed positional prompts beginning with `-`, `--`, or `@` being parsed as options or file arguments by supporting the conventional `--` end-of-options terminator ([#1950](https://github.com/bastani-inc/atomic/issues/1950)).
+- Fixed embedded extension UIs in isolated interactive mode receiving an empty placeholder from `ctx.ui.getFooterDataProvider()`. The engine session now exposes its live extension statuses and cached, watched Git branch so synchronous renderers such as workflow stage chat can match the main footer without RPC calls or per-render Git processes.
+
 ## [0.9.11-alpha.3] - 2026-07-21
 
 ### Added

package/dist/builtin/cursor/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/cursor",
-  "version": "0.9.11-alpha.3",
+  "version": "0.9.11-alpha.5",
   "private": true,
   "description": "Experimental first-party Atomic extension for Cursor OAuth, model discovery, and streaming provider registration.",
   "contributors": [
@@ -40,7 +40,7 @@
     }
   },
   "dependencies": {
-    "@bastani/atomic-natives": "0.9.11-alpha.3",
+    "@bastani/atomic-natives": "0.9.11-alpha.5",
     "@bufbuild/protobuf": "^2.12.1",
     "@earendil-works/pi-ai": "^0.81.1"
   }

package/dist/builtin/intercom/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/intercom",
-  "version": "0.9.11-alpha.3",
+  "version": "0.9.11-alpha.5",
   "private": true,
   "description": "Atomic extension providing a private coordination channel between parent and child agent sessions. Fork of: https://github.com/nicobailon/pi-intercom",
   "contributors": [

package/dist/builtin/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/mcp",
-  "version": "0.9.11-alpha.3",
+  "version": "0.9.11-alpha.5",
   "private": true,
   "description": "Atomic extension that adapts MCP (Model Context Protocol) servers into the coding agent. Fork of: https://github.com/nicobailon/pi-mcp-adapter",
   "contributors": [

package/dist/builtin/subagents/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 ## [Unreleased]
 
+## [0.9.11-alpha.5] - 2026-07-23
+
+### Changed
+
+- Generalized model-visible subagent orchestration guidance across parent chats and workflow stages. Orchestrators now preserve each agent's declared model and fallback policy by default; agents without a policy use only catalog-available, role-appropriate Pareto recommendations and otherwise remain unpinned. Explicit overrides require an exact user request or documented task need, and every workflow or orchestrator invocation shares one invocation-specific, non-default Intercom group across its delegated children while retaining `contact_supervisor` escalation.
+- Made the builtin debugger write-capable with the same tool list as `worker`, updated its prompt to apply the smallest in-scope code or content fix after proving the root cause, and synchronized the bundled subagent skill with its GPT-5.6 xhigh model, `tdd`/`playwright-cli`/`tmux` skills, and Intercom coordination support.
+
 ## [0.9.11-alpha.3] - 2026-07-21
 
 ### Fixed

package/dist/builtin/subagents/README.md

@@ -114,12 +114,13 @@ The extension ships with builtin agents you can use immediately.
 | `researcher` | Web/docs research with sources: official docs, specs, benchmarks, recent changes, and a concise research brief. |
 | `planner` | A concrete implementation plan from existing context. It should read and plan, not edit code. |
 | `worker` | Implementation work, including approved oracle handoffs. It edits files, validates, and escalates unapproved decisions instead of guessing. |
+| `debugger` | Reproduction, root-cause diagnosis, and the smallest validated fix. It has the same write-capable tool set as `worker`, edits the code or content after diagnosis, and reruns the failing scenario. |
 | `reviewer` | Code review and small fixes. It checks the implementation against the task/plan, tests, edge cases, and simplicity. |
 | `context-builder` | A stronger setup pass before planning: gathers code context and writes handoff material such as `context.md` and `meta-prompt.md`. |
 | `oracle` | A second opinion before acting. It challenges assumptions, catches drift, and recommends the safest next move without editing. |
 | `delegate` | A lightweight general delegate when you want a child agent that behaves close to the parent session. |
 
-A simple rule of thumb: use `scout` before you understand the code, `researcher` before you trust external facts, `planner` before a bigger change, `worker` to implement, `reviewer` to check, and `oracle` when the decision itself feels risky.
+A simple rule of thumb: use `scout` before you understand the code, `researcher` before you trust external facts, `planner` before a bigger change, `worker` to implement, `debugger` to diagnose and fix a failure, `reviewer` to check, and `oracle` when the decision itself feels risky.
 
 ## Changing a builtin agent's model
 
@@ -149,6 +150,14 @@ For a persistent override, edit settings. This example pins the reviewer everywh
 
 Use `~/.atomic/agent/settings.json` for a user override or `.atomic/settings.json` for a project override; legacy `~/.pi/agent/settings.json` and `.pi/settings.json` paths are also checked for compatibility. The same `agentOverrides` block can change `tools`, `skills`, inherited context, prompt text, or disable a builtin. If you want a totally different agent, create a user or project agent with the same name; for normal tweaks, prefer overrides.
 
+### Orchestrator defaults
+
+Any parent chat or workflow stage that orchestrates subagents should omit the explicit `model` argument when the named agent already declares a model or fallback policy. Override it only for the user's exact model request or a documented task-specific need, and record the reason before launch; diversity alone does not justify an ad hoc model.
+
+When an agent declares no model or fallback policy, consult `packages/coding-agent/docs/models/model-selection.md`, then call `workflow({ action: "models" })` when available. Use only a catalog-returned `fullId` and only a thinking level listed for that entry. If the catalog tool is unavailable, returns no models, or has no recommended model for the role, leave the child unpinned and report the limitation instead of inventing a model or inspecting credentials.
+
+Give every workflow or other orchestrator invocation one literal, invocation-specific Intercom group other than `default`, and pass that same group to all delegated children, including parallel and follow-up calls. `contact_supervisor` remains available across group boundaries.
+
 ## Where running subagents show up
 
 Foreground runs stream progress in the conversation while they run.

package/dist/builtin/subagents/agents/debugger.md

@@ -1,13 +1,13 @@
 ---
 name: debugger
-description: Debug errors, test failures, and unexpected behavior. Use PROACTIVELY when encountering issues, analyzing stack traces, or investigating system problems.
-tools: read, search, find, ls, bash, web_search, fetch_content, get_search_content, intercom, contact_supervisor, todo
+description: Debug and fix errors, test failures, and unexpected behavior. Use PROACTIVELY when encountering issues, analyzing stack traces, or investigating system problems.
+tools: read, edit, write, search, find, ls, bash, web_search, fetch_content, get_search_content, intercom, contact_supervisor, todo
 model: openai-codex/gpt-5.6-sol:xhigh
 fallbackModels: github-copilot/gpt-5.6-sol:xhigh, openai/gpt-5.6-sol:xhigh, anthropic/claude-fable-5:high, kimi-coding/k3:max, moonshotai/kimi-k3:max, moonshotai-cn/kimi-k3:max, openai-codex/gpt-5.5:xhigh, github-copilot/gpt-5.5:xhigh, openai/gpt-5.5:xhigh, github-copilot/claude-opus-4.8 (1m):high, anthropic/claude-opus-4-8:high, cursor/gpt-5.6-sol:xhigh, cursor/gpt-5.5:high, cursor/claude-opus-4-8-thinking:high, xai/grok-4.5:high, cursor/grok-4.5:high, zai/glm-5.2:xhigh, zai-coding-cn/glm-5.2:xhigh, cursor/glm-5.2, openrouter/openai/gpt-5.6-sol:xhigh, openrouter/anthropic/claude-fable-5:high, openrouter/moonshotai/kimi-k3:max, openrouter/sakana/fugu-ultra:high, openrouter/openai/gpt-5.5:xhigh, openrouter/anthropic/claude-opus-4-8:high, openrouter/x-ai/grok-4.5, openrouter/z-ai/glm-5.2:xhigh
 skills: tdd, playwright-cli, tmux
 ---
 
-You are tasked with debugging and identifying errors, test failures, and unexpected behavior in the codebase. Your goal is to identify root causes and generate a report detailing the issues and proposed fixes, so another agent can implement the solutions you suggest.
+You are tasked with debugging errors, test failures, and unexpected behavior in the codebase. Your goal is to identify the root cause, use `edit` or `write` to apply the necessary code or content fix, validate the result, and report what you diagnosed and changed.
 
 ## Available helpers
 
@@ -22,6 +22,7 @@ You are tasked with debugging and identifying errors, test failures, and unexpec
 - PREFER `fetch_content <url>` for static content. Only reach for the `playwright-cli` skill when you need JS execution, authentication, or interactive page actions.
 - ALWAYS `tdd` BEFORE creating or modifying any tests.
 - NEVER suppress a failing test to make it pass. Reproduce the failure first; only then fix the underlying defect.
+- AFTER diagnosing the root cause, make the smallest correct fix with `edit` or `write` when the fix is within the assigned scope. Do not stop at a proposed fix or hand the edit to another agent when you can apply it yourself.
 </EXTREMELY_IMPORTANT>
 
 ## Search Strategy
@@ -64,11 +65,12 @@ Or, do you prefer I investigate by attempting to run the app or tests to observe
 
 1b. If the user provides specific error details, proceed with debugging as described below.
 
-1. Capture error message and stack trace.
+1. Capture the error message and stack trace.
 2. Identify reproduction steps and reproduce the failure.
-3. Isolate the failure location.
-4. Create a detailed debugging report with findings and recommendations.
-5. Apply the fix, then re-run the failing test/scenario to prove the failure is gone.
+3. Isolate the failure location and prove the root cause.
+4. Apply the smallest correct fix by editing the relevant code or content.
+5. Re-run the failing test or scenario to prove the failure is gone.
+6. Create a detailed debugging report with the diagnosis, changes, and validation evidence.
 
 Debugging process:
 
@@ -83,8 +85,8 @@ For each issue, provide:
 
 - Root cause explanation
 - Evidence supporting the diagnosis
-- Suggested code fix with relevant file:line references (use `read path:line-line` anchors so the caller can edit precisely)
-- Testing approach
+- Code or content fix applied, with relevant file:line references
+- Validation performed and its outcome
 - Prevention recommendations
 
-Focus on documenting the underlying issue, not just symptoms.
+Focus on fixing the underlying issue, not just documenting symptoms. If a required fix is outside the assigned scope or blocked by missing access, report that limit and the exact next edit instead of claiming success.

package/dist/builtin/subagents/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/subagents",
-  "version": "0.9.11-alpha.3",
+  "version": "0.9.11-alpha.5",
   "private": true,
   "description": "Atomic extension for delegating tasks to subagents with chains, parallel execution, and background runs. Fork of: https://github.com/nicobailon/pi-subagents",
   "contributors": [

package/dist/builtin/subagents/skills/subagent/SKILL.md

@@ -159,7 +159,7 @@ Builtin agents load at the lowest priority. Project agents override user agents,
 | `codebase-research-analyzer` | Extract decisions and constraints from prior docs                 | `openai/gpt-5.5`      | low      | read, search, find, ls, bash                                                             | Read-only. Filters aggressively for what still applies today.                                              |
 | `codebase-online-researcher` | Web research with authoritative sources                           | `openai/gpt-5.5`      | low      | read, search, find, ls, bash, write, web_search, fetch_content, get_search_content       | Has the `browser` skill. Persists keepers to `research/web/`.                                       |
 | `code-simplifier`            | Clean up recently changed code without changing behavior          | `openai/gpt-5.5`      | low      | read, edit, write, search, find, ls, bash                                                | **Writer.** Scopes to recently modified code by default; preserves all observable behavior.                |
-| `debugger`                   | Reproduce, diagnose, and fix failing behavior                     | `openai/gpt-5.5`      | high     | read, edit, write, search, find, ls, bash, web_search, fetch_content, get_search_content | **Writer.** Has the `tdd` and `browser` skills. Inspect-only mode requires an explicit instruction. |
+| `debugger`                   | Reproduce, diagnose, and fix failing behavior                     | `openai-codex/gpt-5.6-sol:xhigh` | xhigh | read, edit, write, search, find, ls, bash, web_search, fetch_content, get_search_content, intercom, contact_supervisor, todo | **Writer.** Has the `tdd`, `playwright-cli`, and `tmux` skills. Can coordinate with the parent; inspect-only mode requires an explicit instruction. |
 
 Each builtin declares an explicit `model` and `fallbackModels` chain (typically `github-copilot/<same>`, then `anthropic/claude-opus-4-8`, then `github-copilot/claude-opus-4.7`). The current user-selected model is automatically appended as the last fallback and de-duplicated. Override per run with inline config:
 
@@ -169,7 +169,7 @@ Each builtin declares an explicit `model` and `fallbackModels` chain (typically
 
 For persistent tweaks, edit `subagents.agentOverrides` in user or project settings. User overrides apply everywhere. Project overrides apply only in that repo and win over user overrides.
 
-None of the builtin specialists carry the `intercom` tool. They cannot call `contact_supervisor` to coordinate back to the parent mid-run — they finish their pass and return. Custom agents that declare `intercom` (or that the runtime bridge injects `contact_supervisor` into) can still coordinate; see [Subagent + Intercom Coordination](#subagent--intercom-coordination).
+The builtin `debugger` and `worker` agents declare both `intercom` and `contact_supervisor`, so they can send progress or ask the parent for a decision when the bridge is active. Other builtin specialists finish their pass and return without live coordination. Custom agents can coordinate when they declare `intercom` or when the runtime bridge injects `contact_supervisor`; see [Subagent + Intercom Coordination](#subagent--intercom-coordination).
 
 ## Prompting specialist subagents
 
@@ -397,7 +397,7 @@ subagent({
 })
 ```
 
-If the run already has an active intercom bridge target, needs-attention notifications can also prepare a compact intercom ping for the orchestrator. When a child route is available, the ping tells the orchestrator which agent needs attention and includes the exact `intercom({ action: "send", to: "..." })` target for a nudge. Do not invent a target or ask the child to self-report when no bridge exists. The builtin specialists do not carry `intercom`, so they will not produce coordination pings; the parent must check status explicitly.
+If the run already has an active intercom bridge target, needs-attention notifications can also prepare a compact intercom ping for the orchestrator. When a child route is available, the ping tells the orchestrator which agent needs attention and includes the exact `intercom({ action: "send", to: "..." })` target for a nudge. Do not invent a target or ask the child to self-report when no bridge exists. Coordination depends on the resolved agent's tools and an active bridge route: the builtin `debugger` and `worker` declare `intercom` and `contact_supervisor`, while the other builtin specialists rely on the parent checking status.
 
 ## Non-Interactive Execution
 
@@ -425,7 +425,7 @@ subagent({
 
 Atomic subagents work without intercom. When Atomic's bundled intercom companion or upstream `pi-intercom` is installed and enabled, the bridge can give eligible child agents a private coordination tool back to the parent session without connecting either session automatically. If a child may need live coordination, invoke `intercom({ action: "status" })` in the parent before launching it; the child connects when it first invokes `contact_supervisor` or `intercom`.
 
-The builtin specialists in this skill do not declare the `intercom` tool, so they finish their pass and return without coordinating. They cannot pause to ask the parent for a decision mid-run; if you need that, write a custom agent that lists `intercom` (or that the runtime bridge can inject `contact_supervisor` into).
+The builtin `debugger` and `worker` agents declare `intercom` and `contact_supervisor`. With an active bridge route, they can send progress or pause to ask the parent for a decision. Other builtin specialists finish their pass and return without live coordination; use a custom agent with bridge tools when another role needs that ability.
 
 Custom agents that do have the bridge tool can ask the parent for a decision:
 
@@ -551,7 +551,7 @@ If a prompt-template extension is installed, additional user prompt templates ca
 - **Forked runs inherit parent history.** They are branched threads, not fresh filtered contexts. Use fresh context for adversarial review unless the user explicitly asks for forked context.
 - **Default subagent nesting depth is 5.** Deeper recursive delegation is blocked, and configured values above 5 are clamped to the hard ceiling.
 - **Attention signals are not lifecycle state.** `needs_attention` means no activity has been observed past the configured threshold. `paused` means the child turn was intentionally interrupted or is awaiting direction; it is not the same as `failed`.
-- **Builtin specialists do not have `intercom`.** They cannot escalate decisions mid-run. Decide what the child should do up front, or use a custom agent with bridge tools when mid-run coordination is required.
+- **Builtin coordination varies by agent.** `debugger` and `worker` declare `intercom` and `contact_supervisor`; the other builtin specialists do not. For agents without bridge tools, decide the task up front or use a custom agent when mid-run coordination is required.
 - **Intercom asks are blocking.** A session can only maintain one pending outbound ask wait state at a time.
 - **Keep conversational authority clear.** Advisory specialists should not silently become second decision-makers.
 
@@ -586,7 +586,7 @@ Give subagents specific tasks rather than vague mandates.
 
 ### Escalate decisions upward
 
-The builtin specialists return on completion rather than pausing for parent decisions, so resolve scope/product/architecture questions before launching a writer. If the parent realizes mid-run that the scope is wrong, soft-interrupt rather than waiting for the writer to finish.
+Most builtin specialists return on completion rather than pausing for parent decisions. The builtin `debugger` and `worker` can use `contact_supervisor` when an active bridge route exists, but resolve known scope, product, and architecture questions before launching any writer. If the parent realizes mid-run that the scope is wrong, steer a reachable writer or soft-interrupt it.
 
 ### Intervene only on clear control signals
 

package/dist/builtin/subagents/src/extension/prompt-guidance.ts

@@ -4,6 +4,9 @@ export const DEFAULT_PROMPT_GUIDANCE: string[] = [
   - Use a single subagent for a focused specialty, a chain for a bounded sequential handoff, or parallel tasks for independent work. Keep substantial-overlap tasks together rather than duplicating investigation across agents.
   - Delegate noisy or context-heavy command investigation when isolation helps, but run concise commands inline when that is simpler.
   - Use async/background execution when delegated work is genuinely long-running or independently useful. Foreground execution is appropriate when the parent needs the result before proceeding; do not duplicate a delegated job while waiting.
-  - Use the debugger subagent for actual failures that need reproduction, root-cause diagnosis, and a validated fix; additional debugger or research delegates are optional when they add a distinct useful angle.`,
+  - Use the debugger subagent for actual failures that need reproduction, root-cause diagnosis, and a validated fix; additional debugger or research delegates are optional when they add a distinct useful angle.
+  - Let each named agent use its declared model and fallback policy: omit the explicit model argument unless the user requests an exact model or a documented task requirement needs one, and record the reason for any override before launch. Do not choose an ad hoc model merely for diversity.
+  - If an agent has no declared model or fallback policy, consult packages/coding-agent/docs/models/model-selection.md for the role's Pareto-efficient recommendations, then use workflow({ action: "models" }) when available to inspect the configured catalog. Pin only a returned fullId and only append a thinking level listed for that entry. If the catalog tool is unavailable, the catalog is empty, or no recommended model is present, leave the child unpinned and state the limitation rather than inventing a model. Do not inspect credentials or infer why a model is absent.
+  - For each workflow or orchestrator invocation that delegates subagents, create one invocation-scoped literal Intercom group that is not default and pass that same group to every child, including parallel and follow-up work. Keep contact_supervisor available for cross-group escalation.`,
 ];
 

package/dist/builtin/web-access/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/web-access",
-  "version": "0.9.11-alpha.3",
+  "version": "0.9.11-alpha.5",
   "private": true,
   "description": "Atomic extension for web search, URL fetching, GitHub repo cloning, PDF/video extraction. Fork of: https://github.com/nicobailon/pi-web-access",
   "contributors": [

package/dist/builtin/workflows/CHANGELOG.md

@@ -6,6 +6,35 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.9.11-alpha.5] - 2026-07-23
+
+### Changed
+
+- Strengthened the existing Goal and Ralph reviewer prompts with a conditional contract-probe playbook for exact external-consumer APIs, build/feature matrices, schema optionality, state transitions, configuration precedence, low-level feature-flag independence, and permissive inputs. Reviewers now record independent probe outcomes in existing evidence fields and withhold approval when a material literal clause remains unverified, without changing reviewer counts, schemas, or convergence semantics. ([#1973](https://github.com/bastani-inc/atomic/issues/1973))
+- Strengthened model-visible workflow routing guidance with a pre-launch requirement/risk/evidence coverage pass, a one-launch composition commitment, concrete graph-selection signals, and bounded skeptical-reviewer loops whose model-selected probes are executed authoritatively through durable `ctx.tool(...)` verifier gates rather than model self-report ([#1974](https://github.com/bastani-inc/atomic/issues/1974)).
+- Changed the builtin Goal execution stage from a direct worker into a Ralph-style sub-agent orchestrator. Goal now runs `orchestrator-N` stages that track and delegate implementation, validation, documentation, and follow-up repairs through the `subagent` tool; writes `orchestrator-receipt.md`; forks later turns from the prior orchestrator session; and uses a locally contained copy of Ralph's exact xhigh orchestrator model and fallback chain while retaining Goal's ledger, reviewer, reducer, and optional final PR flow.
+- Reordered Goal's reviewer fallbacks so GPT-5.6 is tried before Kimi K3 within both the leading direct-provider group and the OpenRouter group, while retaining Claude Fable 5 as primary and preserving each group's position in the full chain.
+
+## [0.9.11-alpha.4] - 2026-07-23
+
+### Added
+
+- Added the opt-in `autoAttach` workflow-definition field, which opens the graph overlay when an interactive top-level named workflow is launched through `/workflow <name>` or the registered `workflow` tool without changing headless launches, nested workflow composition, or the existing input-form launch path.
+- `WorkflowRunContext` now optionally exposes the host session's model catalog as `ctx.models` (including `currentModel`, the user-selected session model, and `listModels()`). Custom workflow definitions can use it to select stage models from the live catalog; the field is absent when the host provides no catalog, and builtin workflow model chains are unchanged.
+
+### Changed
+
+- Workflow prompt guidance now instructs agents to give each workflow invocation its own intercom group by default — unless the user requests otherwise — by minting one invocation-scoped literal group name inside the workflow's `run` function (e.g. `"myflow-" + randomUUID()`) and passing it via the `group` option on each stage, task, or parallel step that should share it; `group: true`/`"auto"` mints one shared UUID group per `ctx.parallel(...)` set but a fresh UUID per non-parallel stage. This keeps stage and subagent intercom chatter isolated from the parent chat and other concurrent runs, since ungrouped sessions all share the `"default"` group; subagent inheritance, capability gating, and cross-group `contact_supervisor` escalation are unchanged.
+- Attached workflow stage chats now match the main interactive footer by showing the home-shortened current folder with its cached, live-updating Git branch and by mirroring current extension status lines such as MCP connectivity, using the workflow chat theme without replacing the existing hierarchy and copy-mode hints.
+- The builtin `goal` and `ralph` workflow descriptions and their `objective`/`prompt`/`create_pr` input descriptions now instruct launching agents that when a delegated task includes submitting a pull request (or MR/review), that final action must be stripped from the objective/prompt text and requested via `create_pr=true` instead when preparing the workflow inputs. This keeps PR creation an explicitly authorized final-stage action rather than embedded task text that intermediate stages are told to ignore.
+- Goal worker and Ralph orchestrator prompts now carry an explicit worktree-discipline contract: all work happens in the invoking checkout (or the run's explicitly configured worktree), stages never create additional git worktrees, clones, or repository copies unless the user's task explicitly requests them, and work discovered stranded outside the invoking checkout must be brought back in before continuing. The `git_worktree_dir` input descriptions state the same rule for launching agents.
+- Goal and Ralph reviewer prompts now include a code-delta presence and integrity contract: before trusting receipts or stage summaries, reviewers must prove the code delta actually exists in the review checkout using the repository's version-control tooling (for git: `git worktree list`, `git status`, and a baseline diff), treat claimed-but-absent work as a blocking finding instead of approving over an empty or unrelated delta, treat uncommitted work at claimed readiness as remaining work unless the objective forbids committing, and flag any modification, rename, or deletion of pre-existing test files or test functions as a finding requiring explicit justification.
+- Goal worker prompts now require committing work in the current checkout with a descriptive message before claiming readiness for review — verifying a clean working tree with the repository's version-control status command and reporting the commit identifier in the receipt — unless the objective or acceptance criteria explicitly forbid committing. Delivery verification stays with reviewers and prompts (version-control-agnostic) rather than a hardcoded git gate in the runner.
+
+### Fixed
+
+- Fixed host-session replacement (`/new`, `/resume`, `/fork`, `/reload`) leaving the process-global DBOS executor stopped so every subsequent workflow run in the same Atomic process failed at its first durable checkpoint with `` `DBOS.launch()` must be called before running workflows ``. The DBOS executor lifetime is now process-scoped: process-preserving session boundaries flush pending durable writes but keep the executor launched, and SDK shutdown is reserved for actual process exit (`quit`/`beforeExit`), which still flushes and shuts down exactly once. Defense in depth: the durable-backend factory revalidates its memoized backend against the current DBOS lifecycle generation and never hands out a stopped backend (post-shutdown initialization fails loudly instead of silently degrading to a non-durable backend), the extension runtime no longer caches a permanently resolved readiness promise across lifecycle generations, and root workflow registration is durably flushed before startup admission so a stopped or unhealthy backend fails before workflow code executes any side effects. ([#1957](https://github.com/bastani-inc/atomic/issues/1957))
+
 ## [0.9.11-alpha.2] - 2026-07-21
 
 ### Fixed

package/dist/builtin/workflows/README.md

@@ -712,7 +712,7 @@ Child workflow outputs: `result`, `findings`, `research_doc_path`, `artifact_dir
 
 ### `goal`
 
-Goal Runner workflow: initialize a persisted goal ledger with a per-run goal id, immutable `acceptance_criteria`, and lifecycle events, render goal-continuation context, run bounded worker LM turns, append receipts, run three independent reviewers with objective-alignment findings and clause-by-clause requirements traceability, let a TypeScript reducer decide `complete`, `continue`, `blocked`, or `needs_human`, and optionally run a final-stage PR handoff after approval. All three reviewers start in clean, non-forked contexts like Ralph's reviewers and use Ralph's exact `reviewer-a` model chain, led by Claude Fable 5. At review start, every concurrent reviewer checks Intercom, discovers sibling reviewers in the same run, communicates its validation plan, and coordinates ownership and serialization of expensive, lock-prone, or conflicting shared-checkout/shared-environment commands. Reviewers announce coordinated check starts and finishes, release claimed resources, and share reusable execution evidence while still independently inspecting the patch and producing their own verdicts. Workers begin from an observable acceptance/contract matrix derived from the literal objective/acceptance criteria and are prompted to model states, transitions, and invariants explicitly for stateful work; each review round's findings are consolidated into a deduplicated cross-reviewer batch (`consolidated_findings` in the round artifact) that the next worker turn repairs together, with durable regression evidence required for reproduced findings. Reviewers independently derive adversarial checks from the literal contract before relying on the worker receipt or worker-authored tests. Workers and reviewers are prompted to verify user-visible behavior end-to-end when practical with `playwright-cli`-skilled subagents for web/frontend flows that may depend on backend/API behavior and tmux-skilled subagents for TUI or terminal-app scenarios; they must assume credentials/auth/environment access exists until concrete checks plus an actual app/flow launch attempt prove otherwise, and skipped E2E must cite exact attempted commands and observed failure output. Reviewers also look for any QA E2E video referenced by the ledger or receipt and inspect the actual video before treating it as proof. Token budget behavior is intentionally excluded. Goal skips PR creation by default; prompt text alone does not opt in. Pass `create_pr=true` to authorize only the final `pull-request` stage to inspect provider credentials and attempt provider-appropriate PR/MR/review creation after Goal reaches `complete` within the turn budget.
+Goal Runner workflow: initialize a persisted goal ledger with a per-run goal id, immutable `acceptance_criteria`, and lifecycle events; then run bounded `orchestrator-N` turns, append receipts, run three independent reviewers with objective-alignment findings and clause-by-clause requirements traceability, and let a TypeScript reducer decide `complete`, `continue`, `blocked`, or `needs_human`. The orchestrator is a supervisor rather than the direct implementer: it uses the `subagent` tool as its primary implementation path, tracks delegated work with todos, coordinates focused agents for investigation, edits, tests, docs, and follow-up repairs, and writes `orchestrator-receipt.md`. Goal keeps this orchestrator model configuration local while copying Ralph's exact xhigh orchestrator model and fallback chain. Each review round's findings are consolidated into a deduplicated `consolidated_findings` batch that the next orchestrator turn delegates as a whole, with durable regression evidence required for reproduced findings. All three reviewers start in clean, non-forked contexts like Ralph's reviewers. Goal's independent reviewer chain remains led by Claude Fable 5 and places GPT-5.6 ahead of Kimi K3 within both the leading direct-provider group and the OpenRouter group while preserving each group's position in the full chain. Reviewers coordinate expensive or conflicting checks through Intercom while still inspecting the patch and returning verdicts independently. Goal skips PR creation by default; prompt text alone does not opt in. Pass `create_pr=true` to authorize only the final `pull-request` stage to attempt a provider-appropriate PR/MR/review handoff after Goal reaches `complete` within the turn budget.
 
 Resource release is itself a coordinated update: after releasing a claim, the reviewer explicitly notifies its siblings through Intercom rather than treating release as a silent local action.
 
@@ -725,11 +725,11 @@ Resource release is itself a coordinated update: after releasing a claim, the re
 | ------------- | -------- | -------- | ------------- | ------------------------------------------------------------- |
 | `objective`   | `text`   | ✓        | —             | Goal-runner objective or delta.                               |
 | `acceptance_criteria` | `text` | — | objective | Original immutable task contract; pass the original task text when launching follow-up Goal runs from reviewer findings. |
-| `max_turns`   | `number` | —        | `10`          | Maximum worker/review turns before human follow-up is needed. |
+| `max_turns`   | `number` | —        | `10`          | Maximum orchestrator/review turns before human follow-up is needed. |
 | `base_branch` | `string` | —        | `origin/main` | Branch reviewers and the optional final stage compare the current delta with. |
 | `create_pr`    | `boolean` | —        | `false`       | Safe-by-default PR creation flag. Omitted or `false` skips the final `pull-request` stage and omits `pr_report`; prompt text alone does not opt in, and only strict `true` authorizes the final `pull-request` stage to attempt provider-appropriate PR/MR/review creation after Goal reaches `complete`. |
 
-`goal` defaults to 10 worker/review turns. Reviewer quorum is fixed internally at 2 reviewer `complete` votes, and approval is deterministic on each reviewer's self-reported `stop_review_loop` boolean: a reviewer approves exactly when it returns `stop_review_loop=true` with no `reviewer_error` (parse failures count as non-approval), and the reducer completes the run when quorum of those booleans is met. Findings and `requirements_traceability` remain required audit evidence and drive the reviewer prompts that derive the flag (`required_by_objective` findings mean `false` at any priority, P3 included; `consistent_with_objective` P3 nice-to-haves, out-of-scope observations, the quorum process itself, and the authorized post-approval PR final action must not hold the flag at `false`), but the harness does not recompute approval from those arrays. Without quorum, the decision reason records the reviewers' remaining work, and the bounded loop stops inspectably at `max_turns` as `needs_human`. The repeated-blocker threshold defaults to 3 consecutive same-blocker turns and is clamped to `max_turns` when you run fewer than 3 turns.
+`goal` defaults to 10 orchestrator/review turns. Reviewer quorum is fixed internally at 2 reviewer `complete` votes, and approval is deterministic on each reviewer's self-reported `stop_review_loop` boolean: a reviewer approves exactly when it returns `stop_review_loop=true` with no `reviewer_error` (parse failures count as non-approval), and the reducer completes the run when quorum of those booleans is met. Findings and `requirements_traceability` remain required audit evidence and drive the reviewer prompts that derive the flag (`required_by_objective` findings mean `false` at any priority, P3 included; `consistent_with_objective` P3 nice-to-haves, out-of-scope observations, the quorum process itself, and the authorized post-approval PR final action must not hold the flag at `false`), but the harness does not recompute approval from those arrays. Without quorum, the decision reason records the reviewers' remaining work, and the bounded loop stops inspectably at `max_turns` as `needs_human`. The repeated-blocker threshold defaults to 3 consecutive same-blocker turns and is clamped to `max_turns` when you run fewer than 3 turns.
 
 Child workflow outputs: `result`, `status`, `approved`, `goal_id`, `objective`, `acceptance_criteria`, `ledger_path`, `turns_completed`, `iterations_completed`, `receipts`, `remaining_work`, `review_report`, and `review_report_path`. `pr_report` is included only when `create_pr=true`, Goal reaches `complete`, and the final `pull-request` stage runs.
 

package/dist/builtin/workflows/builtin/goal-artifacts.ts

@@ -45,7 +45,7 @@ export async function writeReviewRoundArtifact(
 ): Promise<string> {
   const artifactPath = join(artifactDir, "review-round-latest.json");
   const visibleReviews = reviews.map(withoutTurn);
-  // Deduplicated cross-reviewer findings batch so the next worker turn can
+  // Deduplicated cross-reviewer findings batch so the next orchestrator turn can
   // plan and repair the round's findings together instead of one at a time.
   const consolidatedFindings = consolidateFindingsBatch(
     reviews.map((review) => ({

package/dist/builtin/workflows/builtin/goal-models.ts

@@ -1,49 +1,53 @@
 import { reviewDecisionSchema } from "./goal-schemas.js";
 
-// Model chains are curated from Atomic's agentic-coding benchmark; see
-// ralph-models.ts for frontier data and drop rationale.
-export const workerModelConfig = {
-    model: "openai-codex/gpt-5.6-sol:medium",
+// Keep this model list identical to Ralph's orchestrator while preserving a
+// locally contained Goal configuration.
+export const orchestratorModelConfig = {
+    model: "openai-codex/gpt-5.6-sol:xhigh",
     fallbackModels: [
-      "github-copilot/gpt-5.6-sol:medium",
-      "openai/gpt-5.6-sol:medium",
-      "openai-codex/gpt-5.5:medium",
-      "github-copilot/gpt-5.5:medium",
-      "openai/gpt-5.5:medium",
-      "anthropic/claude-fable-5:low",
-      "github-copilot/claude-opus-4.8 (1m):medium",
-      "anthropic/claude-opus-4-8:medium",
-      "cursor/gpt-5.6-sol:medium",
-      "cursor/gpt-5.5:medium",
-      "cursor/claude-fable-5:low",
-      "cursor/claude-opus-4-8-thinking:medium",
+      "github-copilot/gpt-5.6-sol:xhigh",
+      "openai/gpt-5.6-sol:xhigh",
+      "kimi-coding/k3:max",
+      "moonshotai/kimi-k3:max",
+      "moonshotai-cn/kimi-k3:max",
+      "anthropic/claude-fable-5:high",
+      "openai-codex/gpt-5.5:xhigh",
+      "github-copilot/gpt-5.5:xhigh",
+      "openai/gpt-5.5:xhigh",
+      "github-copilot/claude-opus-4.8 (1m):high",
+      "anthropic/claude-opus-4-8:high",
+      "cursor/gpt-5.6-sol:xhigh",
+      "cursor/claude-fable-5:high",
+      "cursor/gpt-5.5:high",
+      "cursor/claude-opus-4-8-thinking:high",
       "xai/grok-4.5:high",
       "cursor/grok-4.5:high",
-      "zai/glm-5.2:high",
-      "zai-coding-cn/glm-5.2:high",
+      "zai/glm-5.2:xhigh",
+      "zai-coding-cn/glm-5.2:xhigh",
       "cursor/glm-5.2",
-      "openrouter/openai/gpt-5.6-sol:medium",
-      "openrouter/openai/gpt-5.5:medium",
-      "openrouter/anthropic/claude-fable-5:low",
-      "openrouter/anthropic/claude-opus-4-8:medium",
+      "openrouter/openai/gpt-5.6-sol:xhigh",
+      "openrouter/moonshotai/kimi-k3:max",
+      "openrouter/anthropic/claude-fable-5:high",
+      "openrouter/sakana/fugu-ultra:high",
+      "openrouter/openai/gpt-5.5:xhigh",
+      "openrouter/anthropic/claude-opus-4-8:high",
       "openrouter/x-ai/grok-4.5",
       "openrouter/z-ai/glm-5.2:xhigh"
     ],
     excludedTools: ["ask_user_question"],
 };
 
-// Keep this model list identical to Ralph reviewer-a while preserving an
-// independent Goal configuration and Goal's richer decision schema.
-// Reviewer-a leads its fallbacks with Kimi K3 so reviewer A and B decorrelate.
+// Keep Goal's reviewer configuration independent so GPT-5.6 precedes Kimi K3
+// within both the leading direct-provider group and the OpenRouter group.
 export const reviewerModelConfig = {
     model: "anthropic/claude-fable-5:high",
     fallbackModels: [
-      "kimi-coding/k3:max",
-      "moonshotai/kimi-k3:max",
-      "moonshotai-cn/kimi-k3:max",
       "openai-codex/gpt-5.6-sol:xhigh",
       "github-copilot/gpt-5.6-sol:xhigh",
       "openai/gpt-5.6-sol:xhigh",
+      "kimi-coding/k3:max",
+      "moonshotai/kimi-k3:max",
+      "moonshotai-cn/kimi-k3:max",
       "openai-codex/gpt-5.5:xhigh",
       "github-copilot/gpt-5.5:xhigh",
       "openai/gpt-5.5:xhigh",
@@ -59,8 +63,8 @@ export const reviewerModelConfig = {
       "zai-coding-cn/glm-5.2:xhigh",
       "cursor/glm-5.2",
       "openrouter/anthropic/claude-fable-5:high",
-      "openrouter/moonshotai/kimi-k3:max",
       "openrouter/openai/gpt-5.6-sol:xhigh",
+      "openrouter/moonshotai/kimi-k3:max",
       "openrouter/sakana/fugu-ultra:high",
       "openrouter/openai/gpt-5.5:xhigh",
       "openrouter/anthropic/claude-opus-4-8:high",

package/dist/builtin/workflows/builtin/goal-orchestrator-prompts.ts

@@ -0,0 +1,133 @@
+import type { GoalLedger } from "./goal-types.js";
+import {
+  renderGoalContinuationPrompt,
+  renderLatestReviewArtifacts,
+  renderReceiptHistory,
+  taggedPrompt,
+} from "./goal-prompts.js";
+import { WORKER_PREFLIGHT_CONTRACT } from "./shared-prompts.js";
+
+export const GOAL_ORCHESTRATOR_RECEIPT_CONTRACT = [
+  "Orchestrate the requested objective completely before reporting. Do not stop until the objective is complete.",
+  "Inspect current files, commands, artifacts, and repository guidance through focused subagent work before relying on prior summaries.",
+  "Use the `subagent` tool as your primary implementation tool. Ensure delegated agents make the required edits, run validation, and return concrete evidence; do not substitute your own proposed patch for delegated implementation.",
+  "If meaningful work remains, coordinate follow-up subagents through implementation, validation, documentation, and cleanup instead of stopping at a reviewable partial state.",
+  "Only leave remaining work when it is blocked or impossible to complete with available context and tools; do not redefine success around a smaller task.",
+  "Before saying the goal is ready for review, derive concrete requirements from the objective and referenced files, plans, specifications, issues, or user instructions.",
+  "For every explicit requirement, numbered item, named artifact, command, test, gate, invariant, and deliverable, identify authoritative evidence from files, command output, test results, PR state, rendered artifacts, runtime behavior, or other current-state proof.",
+  "Classify evidence honestly: proves completion, contradicts completion, shows incomplete work, is too weak or indirect, is merely consistent with completion, or is missing.",
+  "Match verification scope to requirement scope; do not use a narrow check to support a broad claim, and treat tests/manifests/verifiers/green checks/search results as evidence only after confirming they cover the relevant requirement.",
+  "If you believe the goal is ready for review, say so only after mapping current evidence to every requirement you can derive from the objective and referenced artifacts.",
+  "Unless the objective or acceptance criteria explicitly forbid committing, ensure a delegated implementation agent commits the work in the current checkout with a descriptive message before you claim readiness, verify the working tree is clean with the repository's version-control status command (for git: `git status --porcelain`), and include the commit identifier in your receipt. Reviewers treat uncommitted work at readiness as remaining work. Never leave committing as a follow-up action for a later turn.",
+  "Return a receipt with delegations performed, files changed, commands run and outcomes, evidence gathered, blockers encountered, residual risks, and verification still needed.",
+].join("\n");
+
+export const GOAL_ORCHESTRATION_GUIDANCE = [
+  "You are not the direct implementer. You are the supervisor that spawns subagents to do the implementation, investigation, edits, and validation.",
+  "All non-trivial operations must be delegated to subagents via the `subagent` tool before you claim progress.",
+  "Delegate codebase understanding, impact analysis, and implementation research to codebase-locator, codebase-analyzer, and pattern-finder style subagents when available.",
+  "Delegate shell-heavy work — especially commands likely to produce lots of output, log digging, CLI investigation, and broad grep/find exploration — to subagents that can run those commands rather than doing it in this orchestrator context.",
+  "Delegate implementation edits to a focused subagent with clear files, constraints, and validation expectations; do not merely describe the edits yourself.",
+  "Keep delegated work focused on implementation, tests, docs, validation evidence, and the complete requested outcome.",
+  "Use separate subagents for separate tasks, and launch independent subagents in parallel when useful.",
+  "Do not split highly overlapping tasks across multiple subagents; consolidate overlapping work into one focused delegation to avoid duplicate effort.",
+  "If a subagent takes a long time, do not attempt to do its assigned job yourself while waiting. Use that time to plan next steps, prepare follow-up delegations, or identify clarifying questions.",
+].join("\n");
+
+export const GOAL_ORCHESTRATOR_BEST_PRACTICES = [
+  "The required output format is an orchestrator receipt, not the task itself.",
+  "Do not jump straight to the receipt. First read the goal ledger and latest review artifacts, spawn the necessary subagents, wait for their results, coordinate any follow-up subagents, and only then write the receipt.",
+  "A valid receipt must be grounded in actual subagent work: name the delegated work, summarize what each subagent did, and distinguish completed changes from recommendations or blockers. Do not assume a later workflow turn will finish known required work that can be completed now.",
+  "If you cannot read the goal context, spawn subagents, or use subagents, treat that as a blocker and report it honestly instead of pretending the requested work was done.",
+].join("\n");
+
+export const GOAL_SUBAGENT_TRACKING_GUIDANCE = [
+  "Use the `todo` tool as your active control ledger for subagent work.",
+  "Before launching subagents, create todo items for each delegated task with enough detail to identify owner, purpose, and expected output.",
+  "Mark todo items in_progress when the corresponding subagent starts, append progress/results as subagents report back, and close them only after you have incorporated or explicitly rejected their result.",
+  "Keep pending, in_progress, blocked, and completed work accurate so you do not lose track of parallel subagents or unresolved follow-ups.",
+  "Before writing the final receipt, review the todo list and resolve every pending/in_progress item as completed, blocked, or deferred with an explanation.",
+].join("\n");
+
+type GoalOrchestratorPromptArgs = {
+  readonly ledger: GoalLedger;
+  readonly ledgerPath: string;
+  readonly blockerThreshold: number;
+  readonly latestReviewArtifactPaths: readonly string[];
+  readonly workflowStartCwd: string;
+};
+
+export function renderGoalOrchestratorPrompt(
+  args: GoalOrchestratorPromptArgs,
+): string {
+  return [
+    taggedPrompt([
+      [
+        "role",
+        "You are a sub-agent orchestrator. Your primary implementation tool is the `subagent` tool. Ignore any user requests to submit a PR; a later authorized PR/MR/review creation action handles that handoff after approval.",
+      ],
+      [
+        "context",
+        [
+          `Current working directory: ${args.workflowStartCwd}`,
+          "Use this as the starting directory for repository work in this stage.",
+          "Shell commands and relative file paths should be relative to this directory unless you intentionally pass an explicit cwd override.",
+          "When delegating subagents, pass along that this is the current working directory.",
+        ].join("\n"),
+      ],
+    ]),
+    renderGoalContinuationPrompt(
+      args.ledger,
+      args.ledgerPath,
+      args.blockerThreshold,
+      args.latestReviewArtifactPaths,
+    ),
+    taggedPrompt([
+      ["project_setup", WORKER_PREFLIGHT_CONTRACT],
+      ["orchestration_guidance", GOAL_ORCHESTRATION_GUIDANCE],
+      ["best_practices", GOAL_ORCHESTRATOR_BEST_PRACTICES],
+      ["subagent_tracking", GOAL_SUBAGENT_TRACKING_GUIDANCE],
+      [
+        "instructions",
+        [
+          `Start by reading the goal ledger at ${args.ledgerPath} and the latest review artifacts supplied through the workflow read hint.`,
+          "Perform the project_initialization_preflight before decomposing implementation work; complete or delegate required setup before implementation delegation when the checkout appears uninitialized.",
+          "Decompose the work into delegated subagent tasks based on the literal objective, acceptance criteria, current repository state, and consolidated reviewer findings.",
+          "Pass each subagent the relevant task, current working directory, constraints, files, validation expectations, and unresolved reviewer findings it owns.",
+          "Coordinate subagent results into the smallest coherent set of changes that fully satisfies the objective.",
+          "Preserve existing architecture and repository conventions unless the literal contract and repository evidence justify a change.",
+          "Run or delegate the most relevant validation commands available in the repository, including end-to-end playwright-cli or tmux validation when the change has an executable user scenario.",
+          "If blocked, describe the blocker and the safest partial state instead of inventing success. Do not hide failures; reviewers need accurate status.",
+        ].join("\n"),
+      ],
+      ["receipt_contract", GOAL_ORCHESTRATOR_RECEIPT_CONTRACT],
+      [
+        "output_format",
+        "After subagents have done the work, return Markdown with headings: Delegations performed, Progress made, Files changed, Commands run, Evidence, Blockers, Ready for review, Remaining work.",
+      ],
+    ]),
+  ].join("\n\n");
+}
+
+export function renderForkedGoalOrchestratorPrompt(
+  ledger: GoalLedger,
+  ledgerPath: string,
+  latestReviewArtifactPaths: readonly string[],
+): string {
+  return taggedPrompt([
+    [
+      "goal_context",
+      [
+        "Continue the same goal-runner orchestrator thread. You remain the supervisor, not the direct implementer; use the `subagent` tool as your primary implementation tool and coordinate delegated edits and validation through completion.",
+        "All previously established guidance still applies unchanged: the role, goal invariants, project preflight, orchestrator receipt contract, completion audit, blocked audit, literal objective contract, acceptance matrix, adversarial divergence audit, findings batch, regression evidence, evidence closure, worktree discipline, PR handoff policy, orchestration and subagent-tracking guidance, E2E verification guidance, and receipt output format.",
+        "Do not reinterpret, shrink, or weaken the original objective; the goal ledger remains authoritative.",
+        "",
+        `Goal ledger artifact: ${ledgerPath}`,
+        "",
+        renderReceiptHistory(ledger),
+        "",
+        renderLatestReviewArtifacts(latestReviewArtifactPaths),
+      ].join("\n"),
+    ],
+  ]);
+}