This is a comment left during a code review.
Path: src/cron/hooks.ts
Line: 125-138

Comment:
**`filter.workflow` is typed and documented but never enforced**

`matchesFilter()` skips the `workflow` filter entirely and leaves a comment saying "workflow filter is checked by the caller." However, the callers in `timer.ts` never check `filter.workflow` either. The `workflow` field is always hard-coded to `"cron"` in `makeHookCtx` and is placed on the context object, but no code ever evaluates `entry.filter.workflow` against it.

Any hook configured with `filter: { workflow: ["some-value"] }` will silently match every job regardless of that filter. A user reading the `CronHookEntry` type definition would have no indication the field is a no-op.

The fix is to add the check inside `matchesFilter` (passing the workflow string from the context or job), or to remove `workflow` from the `filter` type until it is implemented:

```ts
  if (f.workflow && f.workflow.length > 0 && !f.workflow.includes(workflow)) {
    return false;
  }
```

where `workflow` is threaded into `matchesFilter` (e.g. `"cron"` for all timer-driven hooks).

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

---

This is a comment left during a code review.
Path: src/cron/hooks.ts
Line: 133-135

Comment:
**`agentId` filter bypassed when `job.agentId` is undefined**

The guard `&& job.agentId &&` causes the entire `agentId` filter to be skipped when the job has no `agentId`. As a result, a hook configured with `filter: { agentId: ["my-agent"] }` (acting as a whitelist) will fire for **every** agent-less job, defeating the intent of the filter.

Since `agentId` is optional on `CronJobBase`, this is a realistic case. The fix should treat an unset `agentId` as non-matching when the filter is non-empty:

```suggestion
  if (f.agentId && f.agentId.length > 0 && (!job.agentId || !f.agentId.includes(job.agentId))) {
    return false;
  }
```

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

---

This is a comment left during a code review.
Path: src/cron/hooks.ts
Line: 146-150

Comment:
**`setTimeout` handle leaked on successful hook completion**

`rejectAfterTimeout` creates a `setTimeout` but never clears it. When a hook finishes before the deadline, `Promise.race` resolves with the hook result and the timeout promise is abandoned — but the underlying `setTimeout` keeps ticking for up to 10 seconds before firing a no-op `reject`. In long-running processes (and in test environments that check for open handles) this will accumulate stale timers.

Compare with `executeJobCoreWithTimeout` in `timer.ts` which correctly uses `finally { clearTimeout(timeoutId) }` to clean up its timeout.

A self-contained fix:

```ts
function rejectAfterTimeout(ms: number): { promise: Promise<never>; clear: () => void } {
  let id: ReturnType<typeof setTimeout>;
  const promise = new Promise<never>((_, reject) => {
    id = setTimeout(() => reject(new Error(`cron hook timed out after ${ms}ms`)), ms);
  });
  return { promise, clear: () => clearTimeout(id) };
}
```

and in `runCronHooks`:
```ts
const { promise: timeoutPromise, clear: clearHookTimeout } = rejectAfterTimeout(HOOK_TIMEOUT_MS);
try {
  const result = await Promise.race([hookFn(ctx), timeoutPromise]);
  // ...
} finally {
  clearHookTimeout();
}
```

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