Summary

Describe the problem and fix in 2–5 bullets:

• Problem:
  • Cron management from the web UI lacked CLI feature parity for editing and advanced run controls, and run history did not scale well for cross-job triage.
  • The cron form and history filters had rough layout/UX issues (unclear field guidance, awkward selection behavior, and low-density filtering controls).
• Why it matters:
  • Operators need reliable day-to-day scheduling and failure triage from the UI without dropping to CLI.
• What changed:
  • Added full cron edit flow in the web UI with validation and clearer descriptions for schedule, execution, payload, delivery, and advanced fields.
  • Added clone, improved selection behavior, and cancel/edit state handling.
  • Added pagination/sort/filter for jobs and run history, including all-jobs history mode and richer history metadata (delivery/model/usage/session context).
  • Added multi-select filtering for run status and delivery outcomes, then redesigned run-history filters to compact dropdown-checklist controls with cleaner two-row layout.
  • Improved cron page layout, alignment, and responsive behavior; widened/tuned problematic filter sizing.
  • Updated gateway cron protocol/handlers to support paged/filterable list/runs queries and all-scope run history.
  • Added/updated tests for protocol validation, server cron behavior, presenter formatting, controller/view behavior, and paging/filtering paths.
• What did NOT change (scope boundary):
  • No new auth scopes, no new external service integrations, and no changes to core cron execution semantics beyond exposing existing capabilities in UI/API shape.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #

User-visible / Behavior Changes

• Cron jobs can now be edited in web UI with near-CLI parity.
• Cron form has stronger required-field/error guidance and clearer descriptions for payload/session/delivery semantics.
• Clicking job actions (edit/clone/run/history/etc.) keeps selection aligned with the clicked row.
• Run history supports:
  • all-jobs view,
  • pagination,
  • search/sort,
  • multi-select filters for status and delivery,
  • richer run details for triage.
• Jobs list supports paging/search/filter/sort.

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:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22+, pnpm
• Model/provider: n/a
• Integration/channel (if any): n/a
• Relevant config (redacted): default dev gateway + control UI

Steps

1. Start control UI and open Cron Jobs page.
2. Create/edit/clone jobs with each schedule/payload/delivery combination.
3. View run history in selected-job and all-jobs scope, apply search/sort/status/delivery filters.

Expected

• Edit/clone flows preserve correct selection and form state.
• Required-field errors are visible and actionable.
• Jobs/runs paging and filtering return stable, expected results.
• Run history filter UI is compact and readable.

Actual

• Matches expected.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • cron add/update/clone/cancel flows,
  • row selection behavior on actions,
  • all-job run history browsing,
  • filter interactions and layout.
• Edge cases checked:
  • empty filter sets = include all,
  • invalid required fields disable submit with specific reasons,
  • switching scope between all and selected job.
• What you did not verify:
  • production-scale perf on extremely large run-log directories.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert commit 137f3dd22.
• Files/config to restore:
  • src/gateway/protocol/schema/cron.ts
  • src/gateway/server-methods/cron.ts
  • src/cron/run-log.ts
  • ui/src/ui/controllers/cron.ts
  • ui/src/ui/views/cron.ts
  • ui/src/styles/components.css
• Known bad symptoms reviewers should watch for:
  • Run-history filters not applying,
  • action buttons selecting wrong row,
  • cron form submit blocked unexpectedly.

Risks and Mitigations

• Risk:
  • Larger UI/gateway surface change around cron filtering and pagination could introduce subtle regressions.
  • Mitigation:
    • Added protocol, server, controller, presenter, and view tests; ran pnpm check and targeted cron test suites.

Greptile Summary

Added comprehensive cron editing and history workflows to the web UI, bringing near-parity with CLI capabilities for job management and run triage.

• Extended protocol schemas and server handlers to support pagination, filtering, and sorting for both job lists (cron.list) and run history (cron.runs), including all-jobs run history mode
• Implemented readCronRunLogEntriesPage and readCronRunLogEntriesPageAll in src/cron/run-log.ts to support filtered/paged run queries with multi-select status and delivery filters
• Added full edit flow in UI controller with startCronEdit, startCronClone, and comprehensive form validation (validateCronForm) that blocks submission with specific field-level error messages
• Refactored UI views to display compact multi-select filter dropdowns for run status and delivery outcomes, improving filter density and layout
• Added richer run metadata (model, provider, usage tokens, session context) to telemetry capture and presentation
• Preserved row selection state when performing job actions (edit/clone/run/history) to avoid unexpected selection jumps
• Added comprehensive test coverage for protocol validation, server behavior, controller logic, and view interactions

Confidence Score: 4/5

• Safe to merge with minor monitoring recommended for filter edge cases
• Large but well-structured change with good test coverage across protocol, server, and UI layers. The implementation follows existing patterns, includes validation safeguards, and maintains backward compatibility. Score reflects the extensive surface area and potential for subtle pagination/filtering edge cases in production at scale.
• Pay close attention to src/cron/run-log.ts for pagination edge cases with very large run logs, and monitor ui/src/ui/views/cron.ts for filter interaction behavior

_{Last reviewed commit: 137f3dd}