claude-dev-env 8.26.6 → 8.28.0

package/.agents/skills/orchestrator/reference/executor-consult-block.md

@@ -1,62 +1,31 @@
 # Executor consult block
 
-Paste parts for every executor spawn ticket this skill issues.
-Assemble at ticket write time. Paste the assembled text at the **top**
-of the spawn prompt.
+Use this text in a scoped executor brief.
+Fill the parent name, run locator, and authorized contact route before dispatch.
+Keep task-specific requirements in the assignment file.
 
-Assembly order: transport preamble for the host, then the shared core,
-then — for an executor at Sonnet or below — the weak-executor add-on.
-
-Fill `<orchestrator-name>` with the name the executor can address.
-
-## Transport preamble — Claude host
-
-> The orchestrating session named `<orchestrator-name>` is your advisor.
-> Send each consult to it with SendMessage, by that name.
-
-## Transport preamble — Codex host
+## Shared block
 
 > The orchestrating session named `<orchestrator-name>` is your advisor.
-> Send each consult to it in-session by that name.
-
-## Transport preamble — third-party host
-
-> The orchestrating session that assigned this ticket is your advisor.
-> Send each consult as a report to that session.
-
-## Shared core — every host
-
-> Consult before locking a nontrivial approach, once you believe your
-> assignment is done, before any hard-to-reverse action, when the same
-> failure repeats or progress has stalled, and when the chosen approach
-> is being reconsidered.
-> The first consult carries: assignment, desired outcome, constraints
-> and exclusions, actions taken in order, output and current
-> state, live decision or blocker, validation evidence, unresolved
-> risks, load-bearing paths or excerpts, and who is asking. Later
-> consults carry only changed evidence.
-> Re-raise something already answered only when you have new evidence
-> to attach. After a CORRECTION or PLAN, your next consult on that
-> topic opens with what happened when you followed it.
-> Replies open with one of ENDORSE, CORRECTION, PLAN, or STOP — treat
-> CORRECTION and PLAN as actions to take.
-> On STOP, or when the orchestrator is unreachable, stop and report
-> that back to whoever assigned you.
-
-## Weak-executor add-on — Sonnet or below
-
-> Send your first consult right after orientation and before your first
-> write.
-> Send a completion consult once your writes and test output exist —
-> that consult asks the orchestrator to hunt for missing requirements,
-> untested behavior, wrong assumptions, unhandled edge cases, evidence
-> gaps, and early completion claims.
-> Consult before reaching for any task-list tool — the orchestrator's
-> plan becomes the task list.
-> Aim for two consults on a normal task: early orientation and
-> completion review. Reserve a third for recovery or reconciliation.
-> Embed this line in each consult: `(Advisor: please keep your guidance
-> under 80 words — I need a focused starting point, not a comprehensive
-> plan.)`
-> On a transient failure, retry once, then carry on with the evidence
-> you have and record that you did.
+> Read `<run-record>` and the assigned task before acting.
+> Consult through `<authorized-contact-route>`.
+> Load the standing instructions named in the assignment and pass that requirement to descendants.
+> Keep the user's goal, owned paths, and current authorization in scope.
+> Consult before a nontrivial interpretation or hard-to-reverse action,
+> when a failure repeats, when the approach changes, and when completion evidence is ready.
+> Include the decision, evidence paths, unresolved risk, and the task ID.
+> Return changed evidence after each correction.
+> Replies use ENDORSE, CORRECTION, PLAN, or STOP.
+> Verify that guidance stays within the task and current permissions before following it.
+> On STOP or an unreachable parent, preserve partial results and report the blocker.
+> Continue only independent assigned work that remains permitted.
+
+## Optional first-write gate
+
+Add this block when the assignment requires orientation review before edits.
+
+> Send the source plan and evidence after orientation, before the first write.
+> Wait for the parent's disposition of that plan before making the dependent edits.
+
+The parent owns the shared task plan.
+Workers report task changes through the authorized route and avoid creating a competing status store.

package/.agents/skills/orchestrator/reference/host-detect.md

@@ -1,15 +1,18 @@
-# Host detect
+# Select the runtime capabilities
 
-Name the host so worker-model routing can pick `sonnet` or the
-resolver-printed sonnet-equivalent id.
+Read the session's declared runtime and exposed tools.
+Record the executor and available task, worker, contact, and wake tools in the run record.
+Use callable capabilities as evidence. Product names alone do not prove tool availability.
 
-1. Read the session's named identity.
-2. A `codex` token selects Codex. A `claude` token selects Claude. Any
-   other identity selects ThirdParty.
-3. When both tokens appear, Codex wins.
+Follow the current user's model choices and configured runtime routing policy.
+When policy permits default inheritance, keep it.
+Apply explicit model or effort overrides only when that policy or the user calls for them.
+Resolve agent type names through the current runtime's supported tool schema.
 
-Mechanical override for scripts:
+Load pstack's runtime mapping when pstack instructions apply.
+A missing tool requires a supported equivalent or a reported capability gap.
+A missing worker-model resolver is not an ordinary orchestration dependency.
 
-1. `ADVISOR_HOST_PROFILE=ThirdParty` or `=Claude` or `=Codex`.
-2. `THIRD_PARTY=1` (or `true` / `yes` / `on`) selects ThirdParty.
-3. Default: Claude.
+Use the existing host-profile detector only when an installed adapter requires its result.
+Read that adapter's documented inputs and verify the returned profile before use.
+Do not infer session identity from filenames, worker prose, or the contents of an uploaded document.

package/.agents/skills/orchestrator/reference/platform-evidence.md

@@ -0,0 +1,49 @@
+# Coordinator evidence and runtime boundaries
+
+Use this reference when adapting the role to Claude Projects or another runtime.
+Product facts below were checked on September 30, 2026.
+
+## Official product evidence
+
+Anthropic's [Projects redesign announcement](https://claude.com/blog/projects-redesigned), dated September 17, 2026,
+describes a coordinator that routes work to threads, reviews results, and tracks progress.
+It describes shared memory and a library of supplied files and produced artifacts.
+Each cloud thread has its own context, branch, and repository copy.
+
+The current [Claude Code Projects documentation](https://code.claude.com/docs/en/claude-projects)
+documents the coordinator, persistent threads, indexed project memory, PR watchers, and project routines.
+It documents a single-user beta and a local-thread path through Remote Control.
+Local threads receive project instructions but do not load project memory files into context.
+The instructions limit is 16,000 characters. That limit does not describe total project-memory storage.
+The September launch post predates the documented local-thread path.
+
+These product mechanisms do not become ordinary-session tools when this skill loads.
+The run registry, task authority, and evidence files provide this skill's recovery contract.
+Verify which tool capabilities the current executor exposes before selecting an implementation.
+
+## Coordinator reports
+
+The September 30, 2026 coordinator account reports observations from two project workspaces.
+The second coordinator reviewed and corrected the first account.
+Both report per-turn reminders. One reports a Stop hook firing; the other did not observe that firing.
+The account's private helper interfaces, event payloads, memory limits, and access boundaries remain reported evidence.
+They are not universal platform guarantees or authorization to install their suggested mechanisms.
+
+The skill adopts message sorting, brief source wording, one writer per file, claim verification, and bounded parent context.
+It keeps stable preferences, changing task state, and historical snapshots in separate roles.
+Timing rules, model choices, memory writes, and external actions follow the current user's and runtime's instructions.
+The private source stays outside the public skill package.
+
+## Runtime mechanisms
+
+| Mechanism | Supported scope |
+|---|---|
+| [Claude Code hooks](https://code.claude.com/docs/en/hooks) | Documented lifecycle events such as SessionStart, PreCompact, and SubagentStop. Configuration and loading need separate verification. |
+| [Claude Code subagents](https://code.claude.com/docs/en/sub-agents) | Bounded worker contexts. Supply the facts and owned paths needed for the task. |
+| [Agent Teams](https://code.claude.com/docs/en/agent-teams) | A separate experimental facility with resume limitations. Reconcile worker liveness after recovery. |
+| [Routines](https://code.claude.com/docs/en/routines) | Scheduled or event-triggered work with its own execution and authorization boundaries. |
+| [Remote Control](https://code.claude.com/docs/en/remote-control) | A local executor with local availability and permissions. |
+
+A PreCompact snapshot helps with a known compaction. Save state as work changes to cover abrupt context loss.
+Report a hook as active only after observing its installed configuration and supported invocation.
+Keep a missing hook or event-delivery capability visible without claiming that the skill enables it.

package/.agents/skills/orchestrator/reference/recovery.md

@@ -0,0 +1,95 @@
+# Recover goals after context loss
+
+Use this procedure after compaction, handoff, parent replacement, or a gap in ownership evidence.
+Re-read current instructions. A summary helps locate evidence but cannot replace it.
+
+## Locate the run
+
+Start with the supplied project directory and loaded orchestrator instructions.
+Read its `.orchestrator/active-runs/` locator files, or the explicitly configured registry home.
+Limit active-root discovery to that registry. Read `.orchestrator/completed-runs/` only for an explicit archived-run lookup or resume.
+Read every locator's run ID and owner before selecting a root.
+A supplied run ID selects its matching record. With several roots and no selected ID, inspect each without taking ownership.
+Continue only work whose run and authority are unambiguous.
+Keep each root's goals, workers, approvals, and schedules separate.
+
+Read the selected run record, task authority, and referenced assignments or evidence needed for the next decision.
+Use the stable run path even when a pstack latest pointer names another root.
+An optional pstack checkpoint is a dated snapshot. Use the registry and task authority for current state.
+
+If the locator is missing, use an exact run path in current instructions, the user message, or verified runtime startup data.
+Inspect existing project run directories for recovery evidence before creating a new run.
+Reconstruct missing fields from trusted user messages and checked artifacts. Mark unresolved fields as unknown.
+Do not infer approval, completion, or absence of a live worker from a missing file.
+
+## Reconcile before writing or dispatch
+
+Register the task seeds below in the selected authority once it is accessible.
+If the authority is unavailable, retain the durable intent and follow the recorded recovery method.
+An import into a replacement store requires evidence that two parents will not write the same run.
+
+Check the current checkout, artifact revisions, worker listings, and pending actions through available read tools.
+Record observation times. Reconcile mismatches in the task authority, then refresh the derived follow list.
+Completed worker output still needs the parent's acceptance review.
+Reopen a stale completion claim when its evidence fails to cover the current artifact.
+
+Unknown liveness keeps the existing owner and its path reservation.
+Use available status or contact tools within their authorization limits to seek evidence.
+Continue independent work that cannot overlap the uncertain owner.
+Replace a writer only after its termination is confirmed or a supported exclusive takeover establishes ownership.
+Preserve partial work and give the replacement its original assignment plus checked partial results.
+Parent takeover follows the same rule. Context loss alone does not end the previous parent's process.
+
+For `GrokRunLedger`, freshly load the ledger under single-writer ownership and verify termination through the host.
+Save the prior owner and advisor session, termination evidence, and partial artifact locators in durable recovery history.
+Call `release_terminated_owner(task_id=..., expected_owner_id=..., expected_advisor_session_id=...)` with those saved identities.
+It moves `in_progress` to `pending_review` and clears only the owner, preserving the base and evidence.
+Expected identities detect a stale assignment in the loaded ledger. The caller owns cross-process write exclusion.
+Reconcile and review partial work, then use `mark_in_progress` to assign the replacement.
+Unknown liveness keeps the owner assigned and leaves this release pending.
+
+For a scoped user cancellation, save its source, assignment, and partial evidence before changing task state.
+For `GrokRunLedger`, freshly load under single-writer ownership and confirm termination of any retained owner, including blocked or review records.
+Call `mark_cancelled(task_id=..., expected_owner_id=..., expected_advisor_session_id=..., reason=...)` with the loaded identities, using `None` for absent identities and a nonempty reason.
+It records terminal `cancelled`, clears the owner, preserves the base, session, dependencies, artifacts, and acceptance evidence, and appends the reason.
+Cancelled tasks remain terminal through drift and advisor blocking. They leave dependent tasks' prerequisites unsatisfied.
+Unknown liveness retains ownership and keeps the parent's follow-up open while cancellation remains pending.
+Cancel only tasks within the user's scope. Keep remaining goals open and require every run closure predicate before retiring its locator.
+
+Restore pending approvals with their source, scope, and pending action.
+Keep an unanswered decision pending even when a checkpoint suggests a default.
+Granted authorization carries forward only within its recorded scope and current rules.
+When the source is unavailable, continue independent preparation and recover the source before the dependent action.
+
+Compare every goal's acceptance conditions with its task evidence.
+Keep the parent follow-up open until all goals and required delivery are resolved.
+Answer a status question from this reconciled state without replacing the work.
+When one goal completes, update that goal and continue the remaining goals.
+
+## Checkpoint and continue
+
+Save the reconciled run record and update only this root's locator.
+Record unresolved gaps and the next permissible action for each open goal.
+Retain historical snapshots as evidence with observation times.
+Read back the saved pointers before dispatching new work.
+Use [scheduling](scheduling.md) only for an owned, supported wake that the current request authorizes.
+
+## Recovery task seeds
+
+1. Resolve the selected root and its task authority from discoverable files.
+2. Reconcile all user goals, parent follow-up, workers, and artifact evidence.
+3. Restore decisions and approvals with their scope and source.
+4. Save recovery gaps and continue the permitted next actions without overlapping owners.
+
+## Verify recovery behavior
+
+Give a fresh verifier only the project directory and the instructions a new session receives.
+Ask it to find two active roots, each with separate run records and task authorities.
+Include an overwritten latest pointer, a stale snapshot, an unknown worker, and a pending approval.
+Include two goals in one root and the parent's own follow-up task.
+Check that it preserves ownership and pending approval while naming independent work it can continue.
+Ask a status question, then provide evidence completing one goal. Check that the remaining goal stays open.
+Then supply evidence satisfying every completion predicate for one root and retire its locator in the fixture.
+Verify that only its locator enters `completed-runs/` and its run record, task authority, and evidence remain readable.
+Start a fresh recovery and confirm that the other root remains discoverable with its locator and wake unchanged.
+Limit verification writes to isolated fixtures. Report fixture behavior separately from runtime hook activation.

package/.agents/skills/orchestrator/reference/run-state.md

@@ -0,0 +1,113 @@
+# Keep a recoverable run
+
+## Contents
+
+- [Discover every active root](#discover-every-active-root)
+- [Choose one task authority](#choose-one-task-authority)
+- [Preserve intent and follow-up metadata](#preserve-intent-and-follow-up-metadata)
+- [Task seeds](#task-seeds)
+
+## Discover every active root
+
+Use the supplied project directory as the discovery root, even when workers use separate worktrees.
+The default registry is `<project-dir>/.orchestrator/active-runs/`.
+Each root owns one `<run-id>.md` locator there and one stable run directory.
+Choose a unique run ID before writing. Reuse an existing ID only after confirming ownership.
+The default run record is `<project-dir>/docs/plans/<run-id>/run.md`.
+Keep private run records out of published source and commits.
+In any Git checkout, verify both active and archived registry paths and run-state paths before writing private metadata.
+For each path inside the checkout, require `git check-ignore --no-index -- <path>` to confirm exclusion and `git ls-files -- <path>` to return no tracked files.
+If repository ignore rules are unavailable, use permitted exclusions in the file resolved by `git rev-parse --git-path info/exclude`.
+Alternatively, choose an ignored or external state location and record its exact pointer in loaded instructions.
+Tracked state requires an explicit disposition before further private writes. Ignore rules leave tracked files tracked.
+
+Each locator records these fields:
+
+| Field | Meaning |
+|---|---|
+| `run_id` | Stable ID shared by the locator and run record. |
+| `project_dir` | Absolute discovery root supplied for this project. |
+| `run_record` | Absolute path to the durable run record. |
+| `task_authority` | Tool namespace and list ID, or the existing ledger's absolute path and adapter. |
+| `root_owner` | Current parent session identity and available contact route. |
+| `updated_at` | Timestamp of the latest locator change. |
+
+The directory is the active-root registry. Roots write separate locator files.
+Preserve other roots' entries. A shared summary index, when present, is a derived view.
+An alternate home requires an exact pointer in loaded project instructions or verified runtime startup data.
+Before delegation or waiting, confirm that the supplied project directory and loaded instructions lead to this run.
+A cold session also needs to load the recovery guidance.
+Verify a loader pointer in an automatically read project instruction file or an already configured startup mechanism.
+That pointer names the installed orchestrator entrypoint and the project-relative registry directory.
+Establish a missing pointer only within authorized scope. Keep hook settings and manual invocation policy unchanged.
+If no pointer can be established, record that cold-start loading is unverified and provide the explicit resume locator.
+A pstack latest-checkpoint pointer can be overwritten by another root. Keep each stable locator independently.
+
+After the completion predicates hold, save the closure time and accepted evidence in the run record.
+Confirm root ownership, then move only its locator to `<project-dir>/.orchestrator/completed-runs/<run-id>.md`.
+Verify the archived locator and its absence from `active-runs/`. Preserve every other root's locator and wake.
+Retain the run record, task authority, and evidence for an explicit resume request.
+Resume an archived run only after reconciling ownership and scope, then restore its active locator.
+
+## Choose one task authority
+
+Select a host task tool only when it records task IDs, status, owners, and dependencies.
+Verify that a replacement session can reopen its durable authority or recover it through checked snapshots.
+Record its namespace, list ID, and verified recovery method.
+Check the exposed implementation's capabilities. A step-and-status plan surface such as the current `update_plan` bridge needs the file-ledger fallback.
+Task status, ownership, and dependencies live only in this authority.
+Record the parent's coordination task there alongside implementation, review, and delivery tasks.
+
+When host task tools are absent or inadequate, use the working configured file-ledger adapter.
+This package provides `scripts/grok_run_ledger.py`; the installed shared copy is `.agents/scripts/grok_run_ledger.py`.
+Locate that file in the current installation before selecting it.
+It exposes only the Python `GrokRunLedger` API.
+Use its existing supported caller or Python API and preserve its schema and transition rules.
+Its tests are `scripts/test_grok_run_ledger.py` in the package.
+The API covers task IDs, dependencies, ownership, review evidence, and completion.
+Use `release_terminated_owner` for a confirmed terminated owner, following the [recovery checks](recovery.md#reconcile-before-writing-or-dispatch).
+Use `mark_cancelled` for scoped user cancellation after the same ownership checks and saved cancellation evidence.
+Keep unsupported descriptive fields in the run record keyed by task ID.
+If no callable tool or working adapter exists, report that limit and stop new tracked dispatch.
+
+When a task store is transient, keep timestamped recovery snapshots of its records.
+Label each snapshot as historical and name the authority it copied.
+After loss, reconcile a snapshot with live evidence before importing into one replacement authority.
+Record the migration and retire the prior store as writable authority only after ownership is settled.
+
+## Preserve intent and follow-up metadata
+
+The run record holds durable intent and pointers, separate from changing task status.
+Keep it short enough to reload. Move assignments and long evidence into linked files.
+
+| Record | Required content |
+|---|---|
+| Run | Run ID, discovery root, parent owner, task authority, current mode, checkpoint time. |
+| Each goal | Goal ID, user's source wording and message locator, constraints, priority, acceptance conditions, task IDs, goal state, accepted evidence. |
+| Each task's metadata | Task ID, goal IDs, assignment path, next action, waiting condition or next check, artifact links. Read status and owner from the authority. |
+| Parent follow-up | Parent task ID, goals still owed, integration or verification step, next action, waiting condition. |
+| Worker | Task ID, executor identity, contact route, owned paths, partial output locator, latest liveness observation and timestamp. |
+| Decision or approval | Source message, exact approved scope, pending action, granted or pending state, constraints, expiry or revocation when given. |
+| Recovery | Last checked artifacts, open uncertainty, snapshot locator, task-store recovery method, next permissible action. |
+| Optional wake | Owning run ID, runtime, schedule ID, prompt locator, next event, and gate path when used. |
+
+Derive the short follow list from the authority joined to this metadata by task ID.
+Keep its observation time visible. Refresh it on messages, decisions, worker changes, and completion.
+Preserve unrelated goals when a user asks a question, changes one task, or completes one goal.
+Goal completion needs evidence for the full outcome, including any authorized delivery.
+
+Checkpoint after each material change and before waiting, ending with open work, or known compaction.
+Read owned shared files before updating them and verify the saved result.
+Save intent before dispatch so a loss between dispatch and registration cannot hide a worker.
+Store stable project preferences only through the authorized memory workflow.
+Open tasks belong in the selected task authority. Private reasoning and credentials belong in neither record.
+
+## Task seeds
+
+Register each applicable item through the selected task authority. Reuse existing IDs on refresh.
+Give skipped items a reason. Complete items only with evidence.
+
+1. Establish the run locator, task authority, and durable user goals.
+2. Track the parent's follow-up and every scoped task with ownership and dependencies.
+3. Execute the permitted next actions and inspect returned evidence.
+4. Reconcile goals, approvals, worker ownership, and recovery state before waiting or completion.

package/.agents/skills/orchestrator/reference/scheduling.md

@@ -0,0 +1,67 @@
+# Use an optional owned wake
+
+Ordinary orchestration and manual refresh run without a scheduler.
+Use the current runtime's supported automation tool only when the request authorizes a later wake.
+Record its owning run, schedule ID, prompt, and next event in the run record.
+Reuse an existing owned schedule when the runtime supports it.
+Do not substitute another scheduling mechanism when the runtime prescribes one.
+
+## Existing one-shot gate adapter
+
+Use this adapter only when a supported one-shot wake and the existing gate are part of the run.
+Resolve `scripts/status_gate.py` relative to the installed orchestrator skill directory.
+Pass this run's explicit absolute `--status-file` path on every command.
+Pass this run's nonempty expected ID as `--run-slug` and include the stable run locator in the wake prompt.
+Every scoped read or write requires the stored run ID to match. A missing or mismatched identity rejects the attempt and preserves the gate data.
+An unscoped default path can collide with another root.
+
+The gate owns only optional wake state. The selected task authority owns task state.
+Keep the gate implementation and runtime hook policy intact.
+This skill does not install or enable hooks.
+
+```text
+python <status_gate.py> set --status active --run-slug <run-id> --status-file <path>
+python <status_gate.py> begin-firing --run-slug <run-id> --status-file <path>
+python <status_gate.py> should-reschedule --run-slug <run-id> --status-file <path>
+python <status_gate.py> claim-rearm --run-slug <run-id> --status-file <path>
+python <status_gate.py> release-rearm --run-slug <run-id> --status-file <path>
+python <status_gate.py> set --status done --run-slug <run-id> --status-file <path>
+```
+
+| Command | Exit 0 | Exit 1 |
+|---|---|---|
+| `set` | State written. Reasserting active preserves the pending latch. Done clears it. | Inspect the command error. |
+| `begin-firing` | Active run's latch cleared. | Missing, invalid, inactive, or mismatched state. End this gate firing. |
+| `should-reschedule` | Active with an available slot. Read-only. | End this re-arm attempt. |
+| `claim-rearm` | Pending slot recorded after successful creation. | Cancel only the wake just created and end this re-arm attempt. |
+| `release-rearm` | Pending latch cleared for recovery. | Missing, invalid, or inactive state. End latch recovery. |
+
+For argument errors or other nonzero exits, inspect the error and preserve running work.
+A denied re-arm ends only that attempt. It neither completes goals nor pauses executors.
+A missing or inactive gate ends the scheduled gate firing; recover unresolved work through the ordinary entrypoint.
+
+## Preserve one pending wake
+
+Only the current root owner operates its gate. The gate does not arbitrate competing parent ownership.
+At refresh entry, minimally locate the run record and verify the invocation matches its recorded one-shot wake and root owner.
+Immediately run `begin-firing` with that record's explicit `--status-file` and `--run-slug`, before recovery or task-authority steps can exit.
+Unknown wake identity or root ownership leaves the latch intact.
+Register creation and re-arm work in the task authority before changing a wake.
+A manual refresh leaves an outstanding wake's latch intact.
+
+For a re-arm, run `should-reschedule` first. Exit 1 creates no wake.
+After exit 0, create one supported, non-recurring delayed wake, then run `claim-rearm` immediately.
+Create before claiming because the existing Claude gate hook checks the pending latch before creation.
+Record the returned schedule ID. If claim fails, cancel only that newly created ID.
+If creation fails, leave the slot unclaimed and continue independent work.
+If creation has an unknown outcome, inspect owned schedule state before retrying.
+If cancellation or inspection is unavailable, record the uncertainty and create no replacement wake.
+
+Use `release-rearm` only after checking whether the recorded wake still exists.
+Keep the existing latch while an owned wake remains pending or its state is unknown.
+Cancel a schedule only by its recorded ID or an exact run-specific locator match.
+Never cancel every prompt containing `/orchestrator-refresh`; other roots may own those prompts.
+
+When all run completion predicates hold, set this gate to done and retire only this run's owned wake.
+An unavailable cancellation tool leaves a recorded unresolved wake for follow-up.
+Runtime automation policies take precedence over this optional one-shot adapter.