@selesai/code 0.8.3 → 0.8.5

package/dist/extensions/pi-subagents/package.json

@@ -1,7 +1,7 @@
 {
   "name": "pi-subagents",
-  "version": "0.41.0",
-  "description": "Selesai extension for single-agent delegation and scripted multi-agent workflows",
+  "version": "0.48.0",
+  "description": "Selesai extension for single-agent delegation, chains, parallel groups, and scripted multi-agent workflows",
   "author": "Nico Bailon",
   "license": "MIT",
   "type": "module",
@@ -15,7 +15,8 @@
     "./control-channel": "./src/api/control-channel.ts",
     "./intercom-bridge": "./src/api/intercom-bridge.ts",
     "./pi-args": "./src/api/pi-args.ts",
-    "./shared-types": "./src/api/shared-types.ts"
+    "./shared-types": "./src/api/shared-types.ts",
+    "./project-panes": "./src/api/project-panes.ts"
   },
   "repository": {
     "type": "git",
@@ -28,11 +29,11 @@
   "keywords": [
     "pi-package",
     "pi",
+    "pi-coding-agent",
     "subagents",
     "ai",
     "agents",
-    "cli",
-    "selesai"
+    "cli"
   ],
   "bin": {
     "pi-subagents": "install.mjs"
@@ -44,6 +45,7 @@
     "agents/",
     "skills/**/*",
     "prompts/**/*",
+    "docs/**/*",
     "README.md",
     "CHANGELOG.md"
   ],
@@ -64,9 +66,6 @@
     ],
     "prompts": [
       "./prompts"
-    ],
-    "agents": [
-      "./agents"
     ]
   },
   "peerDependencies": {
@@ -97,9 +96,9 @@
   "devDependencies": {
     "@earendil-works/pi-agent-core": "0.81.0",
     "@earendil-works/pi-ai": "0.81.0",
-    "@selesai/code": "0.8.2",
     "@earendil-works/pi-tui": "0.81.0",
     "@types/node": "24.13.3",
-    "typescript": "5.9.3"
+    "typescript": "5.9.3",
+    "@selesai/code": "file:./test/fixtures/pi-coding-agent-shim"
   }
 }

package/dist/extensions/pi-subagents/prompts/gather-context-and-clarify.md

@@ -4,7 +4,7 @@ description: Use subagents to gather context, then ask clarifying questions
 
 Based on our discussion and my intent, launch focused context-gathering subagents before planning or implementing.
 
-Use `explorer` to inspect the relevant local files, existing patterns, constraints, tests, and likely integration points. Use `researcher` when external docs, recent sources, ecosystem context, or primary evidence would improve the answer.
+Use `scout` to inspect the relevant local files, existing patterns, constraints, tests, and likely integration points. Use `researcher` when external docs, recent sources, ecosystem context, or primary evidence would improve the answer.
 
 Give each subagent a specific meta prompt. Ask them to return concise findings plus the remaining clarification questions that matter for implementation confidence.
 

package/dist/extensions/pi-subagents/prompts/parallel-cleanup.md

@@ -4,13 +4,13 @@ description: Parallel cleanup review
 
 Run a fresh-context parallel cleanup review of the current work.
 
-Use the `subagent` tool. First inspect available agents/skills if needed, then launch two commentator subagents in parallel with `context: "fresh"`. Do not use forked context unless I explicitly ask for it. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history.
+Use the `subagent` tool. First inspect available agents/skills if needed, then launch two reviewer subagents in parallel with `context: "fresh"`. Do not use forked context unless I explicitly ask for it. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history.
 
-Do not write commentator output files into the repository unless I explicitly ask for artifacts. Prefer `output: false` for each commentator task.
+Do not write reviewer output files into the repository unless I explicitly ask for artifacts. Prefer `output: false` for each reviewer task.
 
 Reviewer 1: deslop pass.
 
-If the `deslop` skill is available, pass it to this commentator. If not, inline the guidance below. Ask this commentator to look for AI-slop patterns in the changed scope:
+If the `deslop` skill is available, pass it to this reviewer. If not, inline the guidance below. Ask this reviewer to look for AI-slop patterns in the changed scope:
 - comments that restate code, placeholder text, stale rationale, or debug leftovers;
 - defensive checks that hide useful errors, return vague defaults, or validate trusted internal data after a real boundary was already crossed;
 - type escapes, broad casts, duplicated type definitions, or object-bag typing where a local source-of-truth type exists;
@@ -19,11 +19,11 @@ If the `deslop` skill is available, pass it to this commentator. If not, inline
 - pass-through wrappers, dead helpers, duplicate helper signatures, duplicated test harness setup, or abstractions that do not enforce an invariant;
 - UI or CLI copy that is noisy, vague, brittle, or makes the user do extra interpretation.
 
-Tell this commentator to treat tool output and slop-scan-style findings as leads, not verdicts. It should flag only concrete issues in the requested scope with evidence, severity, file/line references, and the smallest safe fix.
+Tell this reviewer to treat tool output and slop-scan-style findings as leads, not verdicts. It should flag only concrete issues in the requested scope with evidence, severity, file/line references, and the smallest safe fix.
 
 Reviewer 2: verbosity pass.
 
-If the `verbosity-cleaner` skill is available, pass it to this commentator. If not, inline the guidance below. Ask this commentator to look for needless verbosity in code, tests, docs, status text, grouped messages, receipts, and changelog wording:
+If the `verbosity-cleaner` skill is available, pass it to this reviewer. If not, inline the guidance below. Ask this reviewer to look for needless verbosity in code, tests, docs, status text, grouped messages, receipts, and changelog wording:
 - single-use helpers that merely paraphrase an expression;
 - temporary variables that only name obvious expressions;
 - nested returns or branches that can become direct returns without hiding intent;
@@ -33,16 +33,16 @@ If the `verbosity-cleaner` skill is available, pass it to this commentator. If n
 - regression tests where one focused assertion would cover the bug but wrapper/API-adjacent tests only repeat the same claim;
 - prose that says the same thing twice, sounds generic, or buries the important rule.
 
-Tell this commentator that shorter is only better when it is clearer and preserves behavior, error signals, cleanup semantics, useful invariants, and local style.
+Tell this reviewer that shorter is only better when it is clearer and preserves behavior, error signals, cleanup semantics, useful invariants, and local style.
 
-Both commentators are review-only. They must not edit files unless I explicitly ask for a writer pass. Their response should be review feedback, not a context summary. Ask them to return concise, evidence-backed findings with file/line references and suggested fixes.
+Both reviewers are review-only. They must not edit files unless I explicitly ask for a writer pass. Their response should be review feedback, not a context summary. Ask them to return concise, evidence-backed findings with file/line references and suggested fixes.
 
-While commentators run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
+While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
 - fixes worth doing now;
 - optional improvements;
 - feedback to ignore or defer, with a short reason.
 
-Do not blindly apply every commentator suggestion.
+Do not blindly apply every reviewer suggestion.
 
 Autofix mode: if the invocation contains the exact word `autofix`, treat it as workflow control, not cleanup scope. Remove it before deciding the cleanup target. After synthesis, apply only fixes worth doing now, validate, and summarize. Do not apply optional improvements unless explicitly requested. If there are no fixes worth doing now, do not edit.
 

package/dist/extensions/pi-subagents/prompts/parallel-research.md

@@ -4,11 +4,11 @@ description: Parallel subagents research
 
 Launch parallel research subagents to build a grounded answer to the current question or decision.
 
-Use fresh context, not forked context, unless I explicitly ask for forked context. Researchers and explorers should inspect sources directly instead of relying on the main conversation history.
+Use fresh context, not forked context, unless I explicitly ask for forked context. Researchers and scouts should inspect sources directly instead of relying on the main conversation history.
 
-Use a combination of `researcher` and `explorer` subagents:
+Use a combination of `researcher` and `scout` subagents:
 - Use `researcher` for web, docs, standards, ecosystem, recent changes, benchmarks, and primary-source evidence.
-- Use `explorer` for local codebase context, existing implementation patterns, repo constraints, and files that would be affected.
+- Use `scout` for local codebase context, existing implementation patterns, repo constraints, and files that would be affected.
 
 Give each subagent a distinct angle. Unless I specify angles, use these three:
 
@@ -16,10 +16,10 @@ Give each subagent a distinct angle. Unless I specify angles, use these three:
    Use `researcher` to find current, authoritative sources: official docs, specs, release notes, benchmarks, issue threads, or primary explanations.
 
 2. Local code context
-   Use `explorer` to inspect the repository for relevant files, existing patterns, constraints, tests, and likely integration points.
+   Use `scout` to inspect the repository for relevant files, existing patterns, constraints, tests, and likely integration points.
 
 3. Practical tradeoffs
-   Use `researcher` or `explorer`, whichever fits the question, to compare options, risks, edge cases, maintenance cost, and what would be easiest to validate.
+   Use `researcher` or `scout`, whichever fits the question, to compare options, risks, edge cases, maintenance cost, and what would be easiest to validate.
 
 Adapt the angles when the question calls for it:
 - Library/API questions: include official docs and recent examples.
@@ -28,7 +28,7 @@ Adapt the angles when the question calls for it:
 - UI/product questions: include user flow, accessibility, design precedent, and implementation constraints.
 - Time-sensitive topics: include a recent-developments angle and prefer 2026/2025 sources.
 
-Prefer two or three strong subagents over many vague ones. The parent agent should frame the question and assign angles; the child agents should research or explorer, not invent broad plans.
+Prefer two or three strong subagents over many vague ones. The parent agent should frame the question and assign angles; the child agents should research or scout, not invent broad plans.
 
 Ask each subagent to return concise findings with evidence:
 - file paths and line ranges for local findings

package/dist/extensions/pi-subagents/prompts/parallel-review.md

@@ -2,11 +2,11 @@
 description: Parallel subagents review
 ---
 
-Launch parallel commentators for an adversarial review of the current work.
+Launch parallel reviewers for an adversarial review of the current work.
 
 Use fresh context, not forked context, unless I explicitly ask for forked context. Reviewers should inspect the repository, relevant instructions, and current diff directly from files and commands. Do not rely on the main conversation history.
 
-Give each commentator a distinct angle. Generate the angles dynamically from the user's intent, the plan, the implemented code, and the current diff. If I specify angles, use mine. Otherwise, choose the highest-value review angles for this specific work.
+Give each reviewer a distinct angle. Generate the angles dynamically from the user's intent, the plan, the implemented code, and the current diff. If I specify angles, use mine. Otherwise, choose the highest-value review angles for this specific work.
 
 These are examples, not fixed defaults:
 
@@ -24,18 +24,18 @@ Choose or adapt angles when the work calls for it:
 - UI-heavy changes: include UX, accessibility, copy, and visual quality.
 - Security-sensitive changes: include unsafe input/output handling, auth boundaries, privacy, and data exposure.
 - Docs-heavy changes: include clarity, accuracy, completeness, reader flow, and non-robotic prose.
-- Large multi-file changes: consider a fourth commentator for structural friction, module boundaries, and testability.
+- Large multi-file changes: consider a fourth reviewer for structural friction, module boundaries, and testability.
 
-Prefer three strong commentators over many vague commentators.
+Prefer three strong reviewers over many vague reviewers.
 
-Give every commentator a specific task prompt naming its angle. Ask commentators to return concise, evidence-backed findings with file/line references and suggested fixes. The response should be review feedback, not a context summary. Reviewers must not edit files unless I explicitly ask for a writer pass.
+Give every reviewer a specific task prompt naming its angle. Ask reviewers to return concise, evidence-backed findings with file/line references and suggested fixes. The response should be review feedback, not a context summary. Reviewers must not edit files unless I explicitly ask for a writer pass.
 
-While commentators run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
+While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
 - fixes worth doing now
 - optional improvements
 - feedback to ignore or defer, with a short reason
 
-Do not blindly apply every commentator suggestion.
+Do not blindly apply every reviewer suggestion.
 
 Autofix mode: if the invocation contains the exact word `autofix`, treat it as workflow control, not review scope. Remove it before deciding the review target. After synthesis, apply only fixes worth doing now, validate, and summarize. Do not apply optional improvements unless explicitly requested. If there are no fixes worth doing now, do not edit.
 
@@ -51,4 +51,4 @@ Additional review target or focus from the slash command invocation:
 
 $@
 
-If the invocation provides a URL, issue link, file path, plan path, or freeform focus, treat it as the primary review scope. Read or fetch that target before assigning commentator angles, and pass the target explicitly into each commentator task.
+If the invocation provides a URL, issue link, file path, plan path, or freeform focus, treat it as the primary review scope. Read or fetch that target before assigning reviewer angles, and pass the target explicitly into each reviewer task.

package/dist/extensions/pi-subagents/prompts/review-loop.md

@@ -6,34 +6,34 @@ Run a parent-orchestrated review loop for the requested work.
 
 Use the `subagent` tool. Keep the parent session as the loop controller and final decision-maker. Child subagents must receive concrete role-specific tasks; they must not run subagents or manage the loop themselves unless the parent intentionally selected an explicit fanout agent whose builtin `tools` includes `subagent` for that assigned fanout.
 
-Default to a maximum of 3 review rounds unless I specify a different cap. Count a review round each time fresh-context commentators inspect the current diff after a builder pass. Stop early when commentators find no blockers or fixes worth doing now.
+Default to a maximum of 3 review rounds unless I specify a different cap. Count a review round each time fresh-context reviewers inspect the current diff after a worker pass. Stop early when reviewers find no blockers or fixes worth doing now.
 
-If the invocation includes an implementation request, first launch one async `builder` to implement the approved scope. If the current diff is already the target, start with review. The sequence can be launched up front with `workflowScript` when it is already clear, or continued as follow-up single-agent runs after each async completion. For an initial workflowScript, pass `async: true` so the main chat is unblocked; do not set `clarify: true` unless I explicitly want the foreground clarify UI. Use only one writer against the active worktree at a time unless I explicitly ask for isolated worktrees.
+If the invocation includes an implementation request, first launch one async `worker` to implement the approved scope. If the current diff is already the target, start with review. The sequence can be launched up front with `workflowScript` when it is already clear, or continued as follow-up single-agent runs after each async completion. For an initial workflowScript, pass `async: true` so the main chat is unblocked; do not set `clarify: true` unless I explicitly want the foreground clarify UI. Use only one writer against the active worktree at a time unless I explicitly ask for isolated worktrees.
 
-As a conservative orchestration policy, do not set `turnBudget`, a hard `toolBudget`, or a tight `usageBudget` on implementation or fix builders. A default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model, so count or usage limits still do not measure delivery safety. Give each writer a narrow delivery slice and an outer elapsed deadline with enough margin. Before that deadline, request a checkpoint after the current tool returns with changed files, build/test state, remaining work, and commit or PR state. An elapsed timeout is not a mutation-safe boundary and must not be the checkpoint trigger.
+As a conservative orchestration policy, do not set `turnBudget`, a hard `toolBudget`, or a tight `usageBudget` on implementation or fix workers. A default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model, so count or usage limits still do not measure delivery safety. Give each writer a narrow delivery slice and an outer elapsed deadline with enough margin. Before that deadline, request a checkpoint after the current tool returns with changed files, build/test state, remaining work, and commit or PR state. An elapsed timeout is not a mutation-safe boundary and must not be the checkpoint trigger.
 
-For each review round, launch fresh-context `commentator` agents in parallel. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history and must not edit files.
+For each review round, launch fresh-context `reviewer` agents in parallel. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history and must not edit files.
 
-Choose review angles from the actual change. Common angles are correctness/regressions, tests/validation, and simplicity/maintainability. Add security, performance, docs/API contracts, or user-flow validation when the work calls for it. Prefer three strong commentators over many vague commentators.
+Choose review angles from the actual change. Common angles are correctness/regressions, tests/validation, and simplicity/maintainability. Add security, performance, docs/API contracts, or user-flow validation when the work calls for it. Prefer three strong reviewers over many vague reviewers.
 
-After commentators return, synthesize their feedback into:
+After reviewers return, synthesize their feedback into:
 - blockers or scope/product/architecture decisions that need user approval;
 - fixes worth doing now;
 - optional improvements;
 - feedback to ignore or defer, with a short reason.
 
-Do not blindly apply every commentator suggestion. If commentators surface an unapproved product, scope, or architecture decision, pause and ask me before launching a fix builder.
+Do not blindly apply every reviewer suggestion. If reviewers surface an unapproved product, scope, or architecture decision, pause and ask me before launching a fix worker.
 
-When an async implementation builder completes, treat its handoff as the transition into review, not as final completion, unless I explicitly asked for builder-only work, review-only output, or to stop after implementation.
+When an async implementation worker completes, treat its handoff as the transition into review, not as final completion, unless I explicitly asked for worker-only work, review-only output, or to stop after implementation.
 
-When there are fixes worth doing now and the workflow is implementation-authorized, launch one async forked `builder` without hard turn or tool-call caps to apply only those synthesized fixes. Ask it to preserve the approved scope, run focused validation, and report changed files, commands run with exit codes, validation evidence, surprises, and anything left undone.
+When there are fixes worth doing now and the workflow is implementation-authorized, launch one async forked `worker` without hard turn or tool-call caps to apply only those synthesized fixes. Ask it to preserve the approved scope, run focused validation, and report changed files, commands run with exit codes, validation evidence, surprises, and anything left undone.
 
-After a fix builder returns, run another review round only when it made material changes or addressed non-trivial findings. Do not keep looping for optional polish, speculative improvements, or findings already deferred by the parent.
+After a fix worker returns, run another review round only when it made material changes or addressed non-trivial findings. Do not keep looping for optional polish, speculative improvements, or findings already deferred by the parent.
 
 Stop and summarize when one of these is true:
-- commentators find no blockers or fixes worth doing now;
+- reviewers find no blockers or fixes worth doing now;
 - remaining feedback is optional, speculative, or intentionally deferred;
-- commentators surface an unapproved decision that needs me;
+- reviewers surface an unapproved decision that needs me;
 - the max review-round cap is reached.
 
 On completion, inspect the final diff yourself, run or confirm focused validation where appropriate, and summarize the loop: rounds run, fixes applied, validation, remaining deferred items, and why the loop stopped.

package/dist/extensions/pi-subagents/skills/pi-subagents/SKILL.md

@@ -1,18 +1,25 @@
 ---
 name: pi-subagents
 description: |
-  Delegate work to builtin or custom subagents with single-agent, scripted,
-  compatibility-chain, async, forked-context, and intercom-coordinated workflows. Use
-  for commentatory review, implementation handoffs, and multi-step tasks where a
-  single agent should stay in control while other agents contribute context,
-  planning, or execution.
+  Delegate work to builtin or custom subagents with single-agent, chain,
+  parallel, scripted, async, forked-context, mission-backed, and
+  intercom-coordinated workflows. Use for advisory review, implementation
+  handoffs, and multi-step tasks where a single agent stays in control while
+  other agents contribute context, planning, or execution.
 ---
 
 # Pi Subagents
 
-This skill is for the main parent orchestrator only. Do not inject or follow it inside spawned child subagents. The parent session owns delegation, orchestration, review fanout, and final fix-builder launches. Ordinary children should not run their own subagent workflows; the explicit exception is a explorerd fanout child whose resolved builtin `tools` includes `subagent`, and that child may use `subagent` only for the fanout work the parent assigned.
+This skill is for the main parent orchestrator only. Do not inject or follow it inside spawned child subagents. The parent session owns delegation, orchestration, review fanout, and final fix-worker launches. Ordinary children should not run their own subagent workflows; the explicit exception is a delegated fanout child whose resolved builtin `tools` includes `subagent`, and that child may use `subagent` only for the fanout work the parent assigned.
 
-Use this skill when the parent orchestrator needs one specialized child or composed orchestration. Use `{ agent, task }` for one isolated child with no sibling lane, monitor, dependency, or aggregation. Use `workflowScript` proactively for coordinated waves: sequence, parallelism, branching, retries, gate monitors, and aggregation. Scripted workflows start asynchronously by default; pass `async:false` only for a small foreground run. `workflowScript` is the only public multi-agent orchestration surface.
+Use this skill when the parent orchestrator needs one specialized child or composed orchestration. The `subagent` tool has four first-class execution modes:
+
+- **SINGLE** — `{ agent, task }` for one child (omit `task` for a self-contained agent).
+- **CHAIN** — `{ chain: [{ agent, task }, ...] }` for sequential steps with `{previous}`, `{outputs.name}`, `phase`/`label`, `outputSchema`, and `{ checkpoint: "name" }` human gates.
+- **PARALLEL** — `{ tasks: [{ agent, task }, ...], concurrency? }` for top-level parallel children, plus in-chain `{ parallel: [...] }` groups and dynamic `expand`/`collect` fanout.
+- **SCRIPTED WORKFLOW** — `{ workflowScript }` with `runs.run`/`runs.all` and ordinary JavaScript for sequence, parallelism, branching, retries, gate monitors, and aggregation. Use `return runs.run("main", { agent, task })` for one child and `runs.all([...])` for coordinated waves. Scripts start asynchronously by default; pass `async:false` only for a small foreground run.
+
+Prefer the declarative modes when the shape is known up front; reach for `workflowScript` when coordination needs dynamic branching or aggregation. Saved `.chain.md` / `.chain.json` workflows (run with `/run-chain`) make repeatable multi-agent flows shareable without rewriting the chain each time.
 
 ## How to use this router
 
@@ -20,24 +27,22 @@ Read the matching reference file before acting. Paths are relative to this `SKIL
 
 | Task | Read |
 | --- | --- |
-| Decide whether to explorer, choose agents, compare tool versus slash commands, apply prompt techniques, or understand builtin roles | `references/prompting-and-roles.md` |
-| Run single, scripted, async, scheduled, mission-backed, forked, worktree, watchdog, clarify, commentator, or intercom-coordinated workflows | `references/execution-controls.md` |
+| Decide whether to delegate, choose agents, compare tool versus slash commands, apply prompt techniques, or understand builtin roles | `references/prompting-and-roles.md` |
+| Run single, chain, parallel, scripted, async, scheduled, mission-backed, forked, worktree, watchdog, clarify, oracle, or intercom-coordinated workflows | `references/execution-controls.md` |
 | List/create/update/delete/eject/disable agents or chains, edit agent files, use prompt-template integration, or expose extension RPC | `references/management-authoring-rpc.md` |
 | Check safety constraints, best practices, standard workflows, or error handling | `references/constraints-and-recipes.md` |
 
-Selesai default: use Fable-style parent orchestration for complex work (multiple moving parts, unclear acceptance, cross-cutting code, meaningful user impact, expensive validation, or broad review surface). Lightweight one-off delegation stays lightweight.
-
-Routing rule: keep tiny targeted reads and simple answers with the parent. For broad local investigation, external research, or mutation work, call `{ action: "list" }`, choose an executable entry from its runtime metadata, then explorer. Treat list output—not hardcoded role names—as the agent-selection authority.
-
 For broad or uncertain requests, read more than one reference. For complex work, start with `references/prompting-and-roles.md` and `references/execution-controls.md`, then consult `references/constraints-and-recipes.md` before launching or reviewing child work.
 
 ## Always-on constraints
 
 - Keep the parent as orchestrator and final decision-maker.
 - Use one writer per cwd/worktree unless isolated worktrees are intentional.
-- For parallel fanout, compare child prompts before launch. Do not send clone prompts with only issue numbers, titles, or broad file globs swapped; each child needs a lane-specific task, source seam, prior evidence, and decision that remains distinct without the item number. Launch that fanout as one `workflowScript` with stable keys and aggregate output unless there is truly only one child.
+- For cross-codebase work, record the target repo, explicit `cwd`, authority boundary, and expected output before launch. Do not assume the parent session cwd is the child repo.
+- For parallel fanout, compare child prompts before launch. Do not send clone prompts with only issue numbers, titles, or broad file globs swapped; each child needs a lane-specific task, source seam, prior evidence, and decision that remains distinct without the item number. Launch that fanout as one async `workflowScript` or parallel `tasks` group with stable keys and aggregate output unless there is truly only one child.
 - Prefer fresh-context review/validation fanout, then synthesize and apply fixes in the parent.
-- Use async/background only when work can proceed independently; do not poll just to wait. For adaptive gates, branch in `workflowScript`. Approval controls remain available only for already-running durable legacy chains.
+- Use async/background by default when work can proceed independently; do not poll just to wait. For planned human gates, use `{ checkpoint: "name", message?: "..." }` chain steps and approve or reject paused checkpoints with `approve-checkpoint` / `reject-checkpoint`. For adaptive gates, branch in `workflowScript`.
 - Preserve capability ceilings, including child tool restrictions and session-scoped allowed-agent restrictions.
-- Escalate unresolved product, architecture, or safety decisions upward instead of letting a child decide silently.
-- As a conservative orchestration policy, do not pass `turnBudget`, a hard `toolBudget`, or a tight `usageBudget` to mutation-capable builders. The default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model. If a builder is interrupted after a tool call starts, checkpoint after the current tool returns with changed files, build/test state, and commit or PR state.
+- Escalate unresolved product, architecture, authority, release, merge, or safety decisions upward instead of letting a child decide silently.
+- Treat receipts, CI, review bots, and external-run records as evidence, not authority to merge, close, comment, publish, or release.
+- As a conservative orchestration policy, do not pass `turnBudget`, a hard `toolBudget`, or a tight `usageBudget` to mutation-capable workers. The default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model. If a worker is interrupted after a tool call starts, checkpoint after the current tool returns with changed files, build/test state, and commit or PR state.