Summary

• Problem: task maintenance still left one repair gap: tasks marked lost did not get cleanupAfter until a later pass, and status surfaced audit errors without telling operators the repair command.
• Why it matters: repair drift keeps old broken rows around longer than intended and makes task health actionable only if the operator already knows the maintenance CLI.
• What changed: maintenance now stamps cleanupAfter in the same pass that marks a task lost, inspection-time lost projections mirror that retention, and openclaw status prints a direct maintenance hint when task audit errors are present.
• What did NOT change (scope boundary): no executor changes, no task schema expansion, no Redis/Temporal work, no producer-specific lifecycle refactors.

Change Type (select all)

• Feature
• Refactor required for the fix

Scope (select all touched areas)

• Gateway / orchestration
• Memory / storage
• UI / DX

Linked Issue/PR

• Closes #
• Related feat(tasks): add status health and maintenance command #57423
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: task maintenance reconciled lost state and retention in two separate passes.
• Missing detection / guardrail: there was no test asserting that a newly-lost task gets cleanupAfter immediately.
• Prior context (git blame, prior PR, issue, or refactor if known): follow-up to the task maintenance/status work in feat(tasks): add status health and maintenance command #57423.
• Why this regressed now: the initial maintenance pass optimized for state reconciliation first and cleanup stamping second.
• If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
• Target test or file: src/tasks/task-registry.test.ts, src/commands/status.test.ts
• Scenario the test should lock in: a task reconciled to lost is immediately cleanup-eligible, and status shows the maintenance command when task audit errors exist.
• Why this is the smallest reliable guardrail: both behaviors sit at the task-registry and status-command seams.
• Existing test that already covers this (if any): task maintenance tests already covered prune and missing-cleanup stamping.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw status now prints a direct openclaw tasks maintenance --apply hint when task audit errors are present.
• newly-lost tasks now get cleanupAfter immediately in the same maintenance pass.

Diagram (if applicable)

Before:
[maintenance pass] -> [mark lost] -> [later pass] -> [stamp cleanupAfter]
[operator] -> [status shows audit errors] -> [must remember repair command]

After:
[maintenance pass] -> [mark lost + stamp cleanupAfter]
[operator] -> [status shows audit errors + repair command]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 / pnpm workspace
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): default local state dir

Steps

1. Create a task whose backing session is gone and whose last event is past the lost grace window.
2. Run maintenance.
3. Inspect the task row and run formatted status with task audit errors present.

Expected

• maintenance marks the task lost and stamps cleanupAfter immediately.
• status prints the repair command when task audit errors exist.

Actual

• Matches expected in scoped tests.

Evidence

• Failing test/log before + passing after

Human Verification (required)

• Verified scenarios: lost-task maintenance repair, formatted status maintenance hint.
• Edge cases checked: inspection-only lost projection still leaves the registry untouched; maintenance still reports cleanupStamped: 0 for the lost reconciliation path because retention is applied as part of the reconciliation itself.
• What you did not verify: full pnpm test suite; pnpm check on current main.

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/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: task maintenance semantics could drift from task audit semantics again.
  • Mitigation: the new test asserts single-pass lost reconciliation with immediate cleanup retention.
• Risk: pnpm check is still red on latest main due to the unrelated src/agents/skills.test-helpers.ts:34 error.
  • Mitigation: scoped task/status tests are green for this change.

AI Assistance

• AI-assisted: yes
• Testing: pnpm test -- src/tasks/task-registry.test.ts src/commands/status.test.ts
• codex review --base origin/main: not re-run in this tiny follow-up because the local transport issue to 127.0.0.1 remained unresolved in the earlier PR cycle.