Greptile Summary

This PR replaces the opaque Type.Object({}, { additionalProperties: true }) placeholders for job and patch in CronToolSchema with fully-typed sub-schemas, so that strict LLMs like GPT-5.4 know exactly which fields to send. It also extends the flattened-field recovery lists for both add and update actions to include failureAlert, fallbacks, and lightContext, and adds normalisation helpers for schedule field pruning (by kind), payload field pruning (by kind), and fallbacks cleaning.

Key changes:

• CronScheduleSchema, CronPayloadSchema, CronDeliverySchema, CronFailureAlertSchema, CronJobObjectSchema, CronPatchObjectSchema added to cron-tool.ts; CronToolSchema is now exported for schema regression tests.
• normalize.ts: new kind-specific pruning in coerceSchedule and coercePayload, fallbacks normalization, inferTopLevelPayload helper, and toolsAllow unconditionally removed from payloads.
• service/jobs.ts: fallbacks wired into mergeCronPayload and buildPayloadFromPatch.
• Comprehensive test coverage across cron-tool.schema.test.ts, cron-tool.test.ts, normalize.test.ts, and service.jobs.test.ts.

One P1 bug found: the new schedule-pruning block in coerceSchedule deletes staggerMs inside the kind === "every" branch, yet staggerMs is the random-jitter field that is only valid for kind=every schedules. Any every schedule that includes a stagger value will have it silently dropped after this PR.

Confidence Score: 4/5

• Safe to merge after fixing the staggerMs deletion bug in the every-schedule pruning block.
• The overall schema expansion is well-structured and tested. One confirmed P1 bug: delete next.staggerMs appears inside kind === "every" in the new coerceSchedule pruning, silently discarding a field that is explicitly documented as the random-jitter value for that exact schedule kind. All other changes (payload pruning, fallback normalisation, service-layer merge wiring) look correct and are covered by tests.
• src/cron/normalize.ts — the kind=every branch in coerceSchedule incorrectly deletes staggerMs.

This is a comment left during a code review.
Path: src/cron/normalize.ts
Line: 92-96

Comment:
**`staggerMs` silently deleted for `kind=every` schedules**

`staggerMs` is the random-jitter field explicitly tied to `kind=every` — the schema description reads `"Random jitter in ms (kind=every)"` and the `CronScheduleSchema` places it alongside `everyMs` and `anchorMs`. The pruning block above (lines 79-84) already normalises `staggerMs` correctly via `normalizeCronStaggerMs`; if it was valid, `next.staggerMs` is set before this block executes. The `delete next.staggerMs` inside the `kind === "every"` branch then silently discards it on every `every` schedule, regardless of whether the value was legitimately set.

`staggerMs` should be removed from the `kind === "every"` branch (it belongs there, not in `kind === "at"` or `kind === "cron"`):

```suggestion
  } else if (next.kind === "every") {
    delete next.at;
    delete next.expr;
    delete next.tz;
  } else if (next.kind === "cron") {
```

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

_{Reviews (4): Last reviewed commit: "fix: preserve explicit cron delivery int..." | Re-trigger Greptile}

@hydro13 @tyler6204 :)

Thanks for tackling the job: {} failure mode, but I don’t think this is ready yet.

• This changes the provider-facing JSON Schema and adds no schema regression test. That is the main thing this PR is touching, so shipping it without a schema assertion/snapshot is a miss.
• The new schema is still incomplete versus the runtime contract. patch.agentId, patch.sessionKey, and patch.failureAlert are still supported by runtime code/tests, but the schema no longer advertises them.
• The nested schema also drops supported fields like schedule.staggerMs, delivery.accountId, and delivery.failureDestination, so strict models will now be guided away from valid cron requests.
• There is also a lot more comment/schema churn here than this fix should need, which makes the patch harder to review.

I’d expand the schema to match the actual cron contract first, then add a schema-level regression test before landing.

Thanks for the review @altaywtf! pushed the fixes:

• Added cron-tool.schema.test.ts with 6 tests that assert the exact field list for job, patch, and their nested objects. Any field removal will break the test.
• patch.agentId, patch.sessionKey, patch.failureAlert are all in the schema now.
• Same for schedule.staggerMs, delivery.accountId, and delivery.failureDestination (modeled as an object to match the gateway schema).
• failureAlert no longer uses Type.Union (avoids anyOf in the tool schema), and dropped the enabled field since it's not consumed by mergeCronFailureAlert.

CI is failing on format:check but it seems to be a repo-wide thing, is that known?

@altaywtf :)

@brunolorente checking, will rebase and take from there thank you!

Merged via squash.

• Prepared head SHA: 979bb0e8b78bd9888767d14ccbdb01a45b7be889
• Merge commit: ca76e2fedc8ef9ba5d2e9ca6da482d33b678fa90

Thanks @brunolorente!