Codex review: needs changes before merge. Reviewed June 21, 2026, 12:36 AM ET / 04:36 UTC.

Summary
The PR adds a SQLite-backed task-route lease table/API, executor acquire/settle hooks, task-delete lease cleanup, focused tests/repro proof, and task-completion docs.

PR surface: Source +608, Tests +720, Docs +50, Generated +63, Other +233. Total +1674 across 12 files.

Reproducibility: yes. source-level for the reviewable surfaces: current main lacks the route-lease implementation, the PR head adds scoped lease storage/hooks/tests, and the docs mismatch is visible from grep because the documented production triggers are not present. I did not run live transport proof in this read-only pass.

Review metrics: 2 noteworthy metrics.

• Persisted Route State: 1 table, 3 indexes added. The diff adds a new shared SQLite table containing requester-origin routing data, so retention and upgrade behavior need maintainer review before merge.
• Documented Unwired Lifecycle Hooks: 3 triggers documented, 0 production callers added. The docs name resolver update, liveness extend, and startup/timer GC triggers that are not implemented in this foundation PR.

Stored data model
Persistent data-model change detected: database schema: src/state/openclaw-state-schema.generated.ts, database schema: src/state/openclaw-state-schema.sql, serialized state: src/state/openclaw-state-db.generated.d.ts, serialized state: src/state/openclaw-state-schema.generated.ts, serialized state: src/state/openclaw-state-schema.sql, unknown-data-model-change: src/state/openclaw-state-schema.generated.ts, and 1 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: partial_overlap
Canonical: #92460
Summary: This PR is the route-lease storage foundation for the canonical isolated-cron completion-origin issue, while the companion cron wiring PR remains the user-visible fix candidate.

Members:

• canonical: [Bug]: Isolated cron completion announcer drops explicit delivery.channel on final controller return #92460 - The issue reports the isolated cron completion-origin failure that this foundation is meant to support.
• fixed_by_candidate: fix(cron): wire task-route lease into isolated cron delivery-target (closes #92460, stacked on #95352) #95362 - The open companion PR wires the lease into isolated cron delivery and explicitly targets the user-visible issue.
• superseded: feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95352 - The prior same foundation PR was closed unmerged and replaced by this current PR after review/re-review confusion.
• independent: fix(sdk): type-narrow manifest.files in pack staging root helper #95465 - The SDK type-narrowing PR is mentioned as unrelated check noise and does not share this route-lease root cause.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Align docs/concepts/task-completion.md with the lifecycle hooks this PR actually ships.
• Make the maintainer route-state acceptance explicit before landing the new persisted requester-origin table.

Risk before merge

• [P1] The PR adds durable requester-origin route state in shared SQLite, so maintainers should explicitly accept the storage, retention, and upgrade contract before merge.
• [P1] The user-visible isolated-cron delivery repair remains in fix(cron): wire task-route lease into isolated cron delivery-target (closes #92460, stacked on #95352) #95362; this PR should not be treated as closing [Bug]: Isolated cron completion announcer drops explicit delivery.channel on final controller return #92460 by itself.
• [P1] The new docs currently describe production update, extend, and GC trigger ownership that this foundation PR does not add.

Maintainer options:

1. Clarify Lifecycle Ownership Before Merge (recommended)
   Update the docs so update, extend, and GC are described as helper APIs or deferred companion hooks unless this PR adds those production call sites with coverage.
2. Accept Foundation First
   Maintainers may intentionally merge the scoped table/API as foundation work while keeping delivery resolver wiring and timer ownership in the companion PR.
3. Pause For Route-State Review
   Pause this PR if maintainers are not ready to accept a new durable requester-origin route table in core.

@clawsweeper automerge

Special instructions:
Update docs/concepts/task-completion.md so the Update, Extend, and GC lifecycle rows describe this PR's actual shipped ownership: helper APIs/caller-owned or deferred companion hooks unless the production resolver/liveness/startup callers are added here with focused coverage.

Next step before merge

• [P2] Automation can attempt the narrow lifecycle-doc repair; the broader persistent route-state acceptance remains maintainer review.

Security
Cleared: No dependency, workflow, lockfile, or concrete security-boundary regression was found; the new route data stays inside the existing private shared SQLite state boundary.

Review findings

• [P3] Align the lifecycle docs with the shipped hooks — docs/concepts/task-completion.md:29-32

@clawsweeper re-review

All four findings from the 04:03 UTC review are addressed at the current head 319bef76bf. The P1 was a real lifecycle-hook defect (not a SHA-cache artifact): the production acquireTaskRouteLease and settleTaskRouteLease calls in task-executor.ts were passing raw runId without the task'''s runtime/scopeKind/ownerKey/childSessionKey scope tuple, so every eligible task landed in the default lease scope. That is now fixed in 319bef76bf.

P1 — src/tasks/task-executor.ts:134 Pass task scope into lease acquisition

createRunningTaskRun now passes the resolved task'''s scope tuple to acquireTaskRouteLease:

acquireTaskRouteLease({
  runId: task.runId,
  taskId: task.taskId,
  requesterOrigin: params.requesterOrigin,
  scope: {
    runtime: task.runtime,
    scopeKind: task.scopeKind,
    ownerKey: task.ownerKey,
    childSessionKey: task.childSessionKey,
  },
});

P2 — src/tasks/task-executor.ts:244 Settle each scoped lease row

setDetachedTaskDeliveryStatusByRunId now iterates the TaskRecord[] returned by the scoped registry update and settles each task'''s lease under its own scope tuple. Tasks without a runId are skipped (no lease was acquired for them in the first place).

if (retirement) {
  for (const task of updated) {
    if (!task.runId) continue;
    settleTaskRouteLease(task.runId, retirement, {
      scope: {
        runtime: task.runtime,
        scopeKind: task.scopeKind,
        ownerKey: task.ownerKey,
        childSessionKey: task.childSessionKey,
      },
    });
  }
}

P3 — src/tasks/task-registry.store.sqlite.ts:295 Remove review-specific lore

The cascade comment no longer cites the PR number or the ClawSweeper confidence score. It just states the atomic-cleanup invariant.

P3 — docs/concepts/task-completion.md:22 Document the scoped lease key

The page now states the lease is keyed by the 5-tuple (run_id, runtime, scope_kind, owner_key, child_session_key) rather than run_id alone, so future cron / subagent / ACP wiring does not copy the unsafe raw-runId contract.

Executor-level cross-scope regression coverage

New test in src/tasks/task-executor.test.ts: "scopes the auto-acquired task-route lease to each task'''s runtime/session scope (PR #95481 P1 review)". It:

1. Creates two createRunningTaskRun calls with the same raw runId but different runtime / ownerKey / childSessionKey and different requesterOrigin.channel (telegram vs discord).
2. Asserts getActiveTaskRouteLease(runId, { scope: <acp-scope> }) returns the telegram lease and getActiveTaskRouteLease(runId, { scope: <cli-scope> }) returns the discord lease — i.e. the two rows are independent on the real lifecycle path.
3. Asserts getActiveTaskRouteLease(runId) (default scope) returns undefined, proving both auto-acquires used the task'''s real scope.
4. Calls setDetachedTaskDeliveryStatusByRunId on the ACP task; asserts the ACP-scoped lease is now undefined and the CLI-scoped lease is still defined, proving settle operates per-task-row scope.

Verification on 319bef76bf

• pnpm tsgo:core — exit 0
• node scripts/run-vitest.mjs src/tasks/task-executor.test.ts — 19 passed (was 18, +1 cross-scope lease test)
• node scripts/run-vitest.mjs src/tasks/task-route-lease.test.ts — 22 passed
• node scripts/run-vitest.mjs src/tasks/task-registry.store.test.ts — 28 passed (the cascade test was updated to query under the task'''s scope instead of the default scope)
• node --import tsx scripts/repro/issue-92460-task-route-lease-lifecycle.mts — 9/9 PASS on real on-disk SQLite
• npx oxlint on touched files — clean
• pnpm docs:list — concepts/task-completion.md listed

What the re-review is asked to do

1. Re-evaluate the four findings from 04:03 UTC against the current head 319bef76bf. If any finding is still open, cite the file/line at 319bef76bf (not dcd9129a08 or any earlier SHA) so I can address what is actually on the branch.
2. If the P1/P2/P3 are closed, lift the 🧂 unranked krab rating. The proof is 🦞 and the patch is the same as 04:03 saw plus four closed findings plus the cross-scope executor test; expect 🐚+ at minimum.
3. The P1 and the three merge-risk: 🚨 labels were added because the lifecycle hooks targeted the default scope; they should drop once the patch is confirmed at the current head.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

@vincentkoc — ClawSweeper pointed to you as the recent contributor to task-registry.ts / task-executor.ts / task-registry.store.sqlite.ts (high confidence), so I wanted to surface a small cluster of related PRs that all touch the same scope and ask for one coordinated review pass instead of three separate ones.

The cluster (all open, all ready for maintainer look or one re-review away)

1. feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481 — feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery — this branch. 🐚 platinum hermit · status: 👀 ready for maintainer look. Storage foundation: task_route_leases table with composite 5-tuple PK (run_id, runtime, scope_kind, owner_key, child_session_key), the lease acquire/settle API, createRunningTaskRun and setDetachedTaskDeliveryStatusByRunId thread the task'''s scope into the lease calls, cascade delete into deleteTaskRowsWithDeliveryState, plus the docs page at docs/concepts/task-completion.md. 4 cross-scope regression tests in task-route-lease.test.ts:426-580 plus 1 executor-level cross-scope test in task-executor.test.ts. 9-step on-disk SQLite repro at scripts/repro/issue-92460-task-route-lease-lifecycle.mts (all 9 sections pass).

2. fix(cron): wire task-route lease into isolated cron delivery-target (closes #92460, stacked on #95352) #95362 — fix(cron): wire task-route lease into isolated cron delivery-target (closes #92460, stacked on #95352). 🧂 unranked krab · status: 📣 needs proof. Companion PR that wires the lease into the cron resolver and adds the live webchat / transport completion proof the lease module cannot. Stacked on feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481; will be rebased to a 5-8-commit cron-only diff once feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481 lands.

3. fix(sdk): type-narrow manifest.files in pack staging root helper #95465 — fix(sdk): type-narrow manifest.files in pack staging root helper. 🐚 platinum hermit · status: 👀 ready for maintainer look. Independent test typecheck fix that was previously hiding behind this branch'''s check-test-types noise. ClawSweeper verified the patch is still valid for @types/node 24.13.1 and 25.9.1.

Why one pass instead of three

• All three touch the same task-persistence boundary (the lease table is keyed by the same (runtime, scopeKind, ownerKey, childSessionKey) scope tuple that the registry already uses).
• The lease module'''s correctness is what unblocks fix(cron): wire task-route lease into isolated cron delivery-target (closes #92460, stacked on #95352) #95362 — once feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481 lands, the cron wiring diff shrinks to a rebase plus the live transport proof, and the prior ClawSweeper review on the cron integration PR finding ("branch is stacked on an open foundation PR") goes away on its own.
• fix(sdk): type-narrow manifest.files in pack staging root helper #95465 is one line, but it was blocking the check-test-types CI gate for any PR rebased onto current upstream/main, so it was effectively gating all of these.

What I would ask

• One review pass on feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481 first. If you want the lease module broken into smaller commits, the existing 9-commit series can be squashed to a single feat(tasks): add task-route lease module plus the four fix commits (P2 retention, P3 settledAt, P1 cross-scope key, CI lint/types) and the docs commit — say the word and I'''ll rebase.
• fix(cron): wire task-route lease into isolated cron delivery-target (closes #92460, stacked on #95352) #95362 will follow once feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481 is in; happy to rebase it down to the cron-only diff and add the live webchat proof before the next review pass.
• fix(sdk): type-narrow manifest.files in pack staging root helper #95465 is already 🐚 and orthogonal, can land any time.

No expectation of an immediate review — the cluster is just easier to walk through as a unit when one of you has the time. Thanks.

Closing PR #95481.

Why: Issue #92460 carries clawsweeper:needs-product-decision — the maintainers haven't decided the right fix shape yet. Two competing approaches exist:

• feat(tasks): add generic task-route lease module for cross-crash delivery origin recovery #95481 (this PR): storage-based task-route lease module
• fix: keep yielded parent turns nonterminal #95996 (kklouzal): deferral-based parent-run lifecycle change

Both are blocked on the same product decision. Without maintainer direction, neither can merge regardless of proof or patch quality.

Current cluster state:

What happens next: Code preserved on branch fix/task-route-lease. If a maintainer decides the storage approach is correct, rebasing and reopening takes minutes.

Re-focus: Shifting to bound-read PRs where the fix shape is already established and ClawSweeper acceptance is the only gate (#96776, #96786, #96782, #96790).