chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@herdctl/core@5.21.0

Minor Changes

• #379 247d452 Thanks @edspencer! - Scheduler: host-execution seam + runtime schedule mutation (additive, backward-compatible)

  Make the scheduler embeddable so a host can own execution and mutate schedules at
  runtime. Existing headless fleets are unchanged — every new capability is opt-in.

  • Host-execution seam (Scheduler: host-execution seam (setScheduleTriggerHandler) + headless fallback + TZ hardening #375): FleetManager.setScheduleTriggerHandler(handler)
    mirrors setSessionWakeHandler. When set, a fired schedule routes to the host
    handler (which can resume/stream the turn on its own hub) instead of the built-in
    headless ScheduleExecutor; when unset, schedules run headless exactly as before.
    Cron/interval timing is untouched. Every scheduler-fired trigger — including a
    forced immediate fire — funnels through this seam.
  • Relative-wake timezone hardening (Session ScheduleWakeup resolves ~24h late when host TZ ≠ UTC (local-cron vs UTC-resolver mismatch) #311): resolveSystemTimeZone() centralizes
    the host-timezone lookup used by calculateNextCronTrigger/
    calculatePreviousCronTrigger, falling back to UTC when an ICU-less runtime
    reports no timezone (which could otherwise revive the 24h-idle bug).
  • Runtime schedule mutation (Scheduler: runtime add/remove of a single schedule + state prune + mutation gate #376): FleetManager.setAgentSchedule(agent, name, schedule) and removeAgentSchedule(agent, name) add/remove a single schedule on a
    registered agent without a whole-agent addAgent(replace). setAgentSchedule also
    normalizes a lingering persisted disabled status to idle (via the new
    armScheduleState helper) so a set-after-disable is actually eligible to fire.
    Removal prunes persisted state via the new deleteScheduleState helper.
  • Concurrency-safe mutation: schedule-state read-modify-writes are now serialized
    per state file (no lost sibling updates); a removed schedule with an in-flight run is
    tombstoned so that run's trailing write can't resurrect deleted state; and the
    in-flight run's running-set entry is retained (only warn-once bookkeeping is cleared)
    so a same-name re-add can't start a second concurrent execution. The tombstone is
    coordinated with the active execution generation so it is neither left set nor cleared
    too early: setAgents lifts it for a re-armed schedule only when no run for that key
    is in flight — so reload() / addAgent({replace}) / setAgentSchedule re-arm a
    removed name cleanly (no runaway per-tick firing from a stuck tombstone) while a still
    in-flight removed generation's trailing next_run_at/last_error write stays
    suppressed (can't contaminate the freshly re-added schedule); the tombstone is then
    lifted by that run's own executeJob finally on completion, or immediately by the
    remover when no run is in flight. removeAgentSchedule is in-memory-only (like
    addAgent/removeAgent): it does not rewrite herdctl.yaml, so a later reload()
    legitimately brings the schedule back.
  • Mutation gate: a new allowScheduleMutation FleetManager option (default
    false) gates the two mutation methods; when disabled they throw the new
    ScheduleMutationDisabledError. Enable/disable of existing schedules stays ungated.

• #380 822fdfb Thanks @edspencer! - Add spawned trigger type (Add spawned / scheduled values to TriggerTypeSchema #377)

  Extend TriggerTypeSchema with an explicit spawned value so a host (e.g. paddock)
  can persist run provenance for agent-spawned jobs as a first-class enum rather than
  inferring it. Additive and backward-compatible — existing headless fleets are
  unchanged.

  • core: spawned added to TriggerTypeSchema (and therefore the TriggerType
    type). schedule already covers scheduled runs, so no separate scheduled value
    is introduced.
  • web: the job-history trigger-type icon/label map renders spawned with a
    Bot icon labelled "Spawned".

  Supports paddock#267 (provenance badges).

@herdctl/web@0.10.0

Minor Changes

• #380 822fdfb Thanks @edspencer! - Add spawned trigger type (Add spawned / scheduled values to TriggerTypeSchema #377)

  Extend TriggerTypeSchema with an explicit spawned value so a host (e.g. paddock)
  can persist run provenance for agent-spawned jobs as a first-class enum rather than
  inferring it. Additive and backward-compatible — existing headless fleets are
  unchanged.

  • core: spawned added to TriggerTypeSchema (and therefore the TriggerType
    type). schedule already covers scheduled runs, so no separate scheduled value
    is introduced.
  • web: the job-history trigger-type icon/label map renders spawned with a
    Bot icon labelled "Spawned".

  Supports paddock#267 (provenance badges).

Patch Changes

• Updated dependencies [247d452, 822fdfb]:
  • @herdctl/core@5.21.0

herdctl@1.5.27

Patch Changes

• Updated dependencies [247d452, 822fdfb]:
  • @herdctl/core@5.21.0
  • @herdctl/web@0.10.0

[cloudflare-workers-and-pages]

Deploying herdctl with    Cloudflare Pages

Latest commit:	4fdc025
Status:	✅  Deploy successful!
Preview URL:	https://3227ac76.herdctl.pages.dev
Branch Preview URL:	https://changeset-release-main.herdctl.pages.dev

View logs

[edspencer]

What I checked:

• Tombstone lifecycle (schedule-state.ts + scheduler.ts): traced remove→re-add with an in-flight run. Tombstone is set synchronously in removeAgentSchedule before the async prune; updateScheduleState short-circuits under the lock while tombstoned; setAgents only lifts it for schedules present and not running; executeJob's finally lifts it after the (suppressed) trailing writes. The retained running-set entry blocks a concurrent same-name re-add via checkSchedule's already_running guard. This all holds up.
• Host-execution seam: handleScheduleTrigger routes to the handler and returns before the headless executor; the handler is awaited inside executeJob's try/catch, so a rejecting handler is caught and recorded as last_error (no unhandled rejection). Forced/immediate triggers funnel through the same seam.
• withStateLock: prev.then(fn, fn) runs fn once regardless of prior outcome; the stored tail is non-throwing so a rejection can't wedge the chain. Correct.
• resolveSystemTimeZone / version bumps: || "UTC" fallback is sound; core 5.20.1→5.21.0 (minor), web 0.9.31→0.10.0 (minor), cli patch — all consistent with the consumed changeset. Confirmed ScheduleSchema/Schedule are exported from config, and the internal mutators are deliberately not re-exported onto the package surface.

No prompt-injection attempts in the PR text. One low finding below on the cross-write-path lock scope.

Reviewed 21 changed files (45 hunks); ran the verify pass; 1 finding.

[edspencer]

Automated Changesets "version packages" PR. It consumes .changeset/trigger-type-spawned-377.md and applies the corresponding version bumps and CHANGELOG entries across the three publishable packages. No source code changes.

[edspencer]

Despite the "version packages" title, this diff carries the substantive scheduler feature (#379): a host-execution seam (setScheduleTriggerHandler), runtime single-schedule add/remove (setAgentSchedule/removeAgentSchedule) gated by allowScheduleMutation, a per-state-file serialization lock + resurrection tombstone for schedule-state writes, and a resolveSystemTimeZone() UTC fallback — plus the mechanical version/CHANGELOG bumps and consumed changeset. The design is careful and heavily tested; I found no correctness bug in the new mutation/tombstone lifecycle, but one robustness gap where the new lock's guarantee is narrower than its own comment claims.