Greptile Summary

This PR unifies the shared task-run registry by simplifying the schema (removing source/bindingTargetKind, adding sourceId/parentTaskId/agentId/cleanupAfter), renaming status values (accepted→queued, done→succeeded), and integrating cron job executions (scheduled, startup-catchup, and manual) into the registry alongside ACP, subagent, and background CLI runs. The changes are broadly consistent across all callers and the type contract is tightly updated.

• The core task-registry.ts and task-registry.types.ts changes are clean and well-structured; normalizeTaskStatus provides a safe fallback for stored records that carry old status strings.
• The three cron task-record paths in timer.ts (onTimer, runStartupCatchupCandidate) and the applyOutcomeToStoredJob update are correctly implemented — timer.ts uses isAbortError to normalise the error text before comparing for the timeout case.
• ops.ts (manual-run path) has a bug: the catch block stores String(err) which for new Error("cron: job execution timed out") produces "Error: cron: job execution timed out", but the subsequent status mapping compares against the bare string "cron: job execution timed out" — so any manual cron run that times out will be recorded as status: "failed" instead of "timed_out".
• Tests were updated consistently, but no test exercises the timed_out status path through finishPreparedManualRun, leaving the bug uncovered.

Confidence Score: 4/5

Mostly safe to merge, but the ops.ts manual-run timeout path has a real status-mapping defect that should be fixed first.

One P1 logic bug: manual cron runs that exceed their timeout are recorded as failed instead of timed_out because String(err) on an Error object includes the "Error: " prefix that the string comparison does not account for. All other changes are consistent and well-tested.

src/cron/service/ops.ts — specifically the catch block in finishPreparedManualRun and the subsequent updateTaskRecordById status mapping.

This is a comment left during a code review.
Path: src/cron/service/ops.ts
Line: 497-503

Comment:
**Timeout detection broken: `String(err)` includes `"Error: "` prefix**

`executeJobCoreWithTimeout` rejects with `new Error(timeoutErrorMessage())` on timeout. The `catch` block on lines 492–495 serialises this as `String(err)`, which produces `"Error: cron: job execution timed out"` — not the bare `"cron: job execution timed out"` string this comparison expects.

As a result, any manual cron run that times out will be recorded with `status: "failed"` instead of `status: "timed_out"`.

Compare how `timer.ts` handles the same situation: it uses `isAbortError(err) ? timeoutErrorMessage() : String(err)` to normalise the error message before storing it. The fix is to apply the same normalisation in the catch block:

```typescript
} catch (err) {
  const errorText =
    err instanceof Error && err.message === "cron: job execution timed out"
      ? err.message
      : String(err);
  coreResult = { status: "error", error: errorText };
}
```

Then the existing status mapping will correctly produce `"timed_out"` for timeout errors.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into refactor/task-r..." | Re-trigger Greptile}

🤖 We're reviewing this PR with Aisle

We're running a security check on the changes in this PR now. This usually takes a few minutes. ⌛
We'll post the results here as soon as they're ready.

Progress:

• Analysis
• Finalization

Latest run failed. Keeping previous successful results. Trace ID: 019d3bea11b76b1891c5f85f1f1f89bf.

_{Last updated on: 2026-03-30T09:47:42Z}