Summary

• Problem: isolated cron agentTurn jobs can default to announce delivery with implicit delivery.channel=last even when there is no previous route.
• Why it matters: the job can spend model tokens before failing with a permanent delivery-target error, then repeat on later cron fires.
• What changed: the isolated runner now fails unresolved implicit announce delivery before calling the agent executor, while preserving the existing delivery-target error classification and delivery trace.
• What did NOT change (scope boundary): explicit delivery targets still run through the existing execution and delivery-dispatch path; add/update rejection and auto-disable policy are left for separate maintainer direction.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Prevent isolated cron announce jobs from repeatedly running when implicit last delivery has no route #78608
• This PR fixes a bug or regression

Root Cause

• Root cause: isolated cron delivery target resolution happened before execution, but runCronIsolatedAgentTurn still called executeCronRun even when implicit announce delivery had already resolved to a permanent last route failure.
• Missing detection / guardrail: no pre-execution guard for the known-unroutable implicit announce target shape.
• Contributing context: delivery dispatch already reports errorKind: "delivery-target", but only after the expensive agent turn.

Regression Test Plan

• Coverage level that should have caught this:
  • Seam / integration test
• Target test or file: src/cron/isolated-agent/run.message-tool-policy.test.ts
• Scenario the test should lock in: implicit announce delivery with channel: "last" and no resolved route returns a delivery-target error without starting the agent executor, dispatching delivery, or firing onExecutionStarted.
• Why this is the smallest reliable guardrail: it exercises the isolated runner boundary where delivery resolution and model execution meet.

User-visible / Behavior Changes

Recurring isolated cron announce jobs that have no implicit previous delivery route now fail before model execution instead of spending tokens and failing after delivery dispatch.

Diagram

Before:
cron fire -> resolve last route failure -> run model -> delivery-target error

After:
cron fire -> resolve last route failure -> delivery-target error

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS local maintainer worktree
• Runtime/container: Node/pnpm repo test wrapper
• Model/provider: mocked test harness
• Integration/channel: cron isolated agent delivery
• Relevant config: test fixtures only

Steps

1. Run the focused cron regression suite.
2. Run changed-surface checks locally.
3. Attempt remote Crabbox/Blacksmith changed proof.

Expected

• Unresolved implicit announce delivery fails before model execution.
• Explicit delivery-target failure behavior continues through existing post-run dispatch tests.

Actual

• Focused cron tests pass.
• Local check:changed passed before rebase.
• Remote Crabbox/Blacksmith proof was not available because Blacksmith was down.
• Local test:changed hit unrelated workspace package-resolution failures in broader cron direct-delivery tests (openclaw/workspace package resolution), not assertions from this patch.

Evidence

• Failing test/log before + passing after

Commands run:

pnpm test src/cron/isolated-agent/run.message-tool-policy.test.ts
pnpm exec oxfmt --check --threads=1 src/cron/isolated-agent/run.ts src/cron/isolated-agent/run.message-tool-policy.test.ts
pnpm check:changed
pnpm test:changed
pnpm test src/cron/isolated-agent/run.message-tool-policy.test.ts src/cron/isolated-agent/delivery-dispatch.double-announce.test.ts src/cron/delivery-preview.test.ts
git diff --check origin/main...HEAD

Latest post-rebase focused proof:

Test Files  3 passed (3)
Tests  82 passed (82)

Human Verification

• Verified scenarios: implicit unresolved announce delivery fails before agent execution; existing explicit unresolved delivery behavior still has test coverage; delivery preview and dispatch suites still pass.
• Edge cases checked: explicit bad target test remains on the existing execution path; bare delivery.mode="none" behavior remains covered by existing tests.
• What I did not verify: live cron execution against a real configured channel, due to Blacksmith outage and this being covered by the focused runner seam.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: a job with an explicit but invalid target still spends tokens before dispatch reports the delivery-target error.
  • Mitigation: this PR intentionally limits scope to the issue's implicit last footgun; explicit-target validation policy can be handled separately.