Changelog

Latest headline release: z4j v1.12.1.

A minor release moves every package at once; a patch release re-cuts only the packages whose shipped code changed (always including z4j), while the rest stay at their last version on the same minor line and every floor stays at the minor baseline. The table below shows the latest of every published package. The per-package history follows.

Package	Latest	Released	Category	License	Links
`z4j`	`1.12.1`	2026-10-05	Umbrella	AGPL-3.0-or-later	PyPI · GitHub · Docs
`z4j-bare`	`1.12.0`	2026-10-03	Core	Apache-2.0	PyPI · GitHub · Docs
`z4j-core`	`1.12.0`	2026-10-03	Core	Apache-2.0	PyPI · GitHub
`z4j-scheduler`	`1.12.1`	2026-10-05	Core	Apache-2.0	PyPI · GitHub · Docs
`z4j-django`	`1.12.0`	2026-10-03	Frameworks	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-fastapi`	`1.12.0`	2026-10-03	Frameworks	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-flask`	`1.12.0`	2026-10-03	Frameworks	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-arq`	`1.12.1`	2026-10-05	Engines	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-celery`	`1.12.0`	2026-10-03	Engines	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-dramatiq`	`1.12.1`	2026-10-05	Engines	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-huey`	`1.12.1`	2026-10-05	Engines	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-rq`	`1.12.1`	2026-10-05	Engines	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-taskiq`	`1.12.1`	2026-10-05	Engines	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-apscheduler`	`1.12.1`	2026-10-05	Schedulers	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-arqcron`	`1.12.1`	2026-10-05	Schedulers	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-celerybeat`	`1.12.0`	2026-10-03	Schedulers	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-hueyperiodic`	`1.12.1`	2026-10-05	Schedulers	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-rqscheduler`	`1.12.0`	2026-10-03	Schedulers	Apache-2.0	PyPI · GitHub · Docs · Upstream
`z4j-taskiqscheduler`	`1.12.1`	2026-10-05	Schedulers	Apache-2.0	PyPI · GitHub · Docs · Upstream

History by package

`z4j`

v1.12.1 (2026-10-05)

changed: The pinned cadence closure moves to croniter 6.2.4 and tzdata 2026.5 (IANA 2026e). Under the previous timezone data fire times are an hour wrong from 2026-11-01 for America/Winnipeg, Canada/Central, America/Rainy_River and America/Inuvik. Upgrade the brain and the scheduler together, scheduler stopped first.
security: No requirement caps a third-party major any more (`sentry-sdk`, `aiobotocore`, `pytest`, the `huey` extras), so no z4j requirement holds a dependency below its newest release; the gate now fails when one does.
changed: A brain that has begun shutting down answers a scheduler fire with `UNAVAILABLE` instead of accepting one it can no longer deliver.
fixed: `z4j status` shows a Windows SQLite path as written on SQLAlchemy 2.1 (it printed `C%3A/...`).
changed: The image's Python base follows its tag to the current digest and the Caddy overlay moves to 2.11.6.

v1.12.0 (2026-10-03)

added: `GET /api/v1/projects/{slug}/dead-letters` lists an engine's dead letters through an online agent that advertises `list_dead_letters`, answering 409 when none is online, 504 on a silent agent, 422 on a malformed cursor or limit and 502 on an adapter failure; the `dead-letters` tag maps to `tasks:read` for API keys.
added: A Dead letters page beside Tasks, with an engine selector, a queue filter, a paginated table and a Requeue action where the adapter advertises `requeue_dead_letter`.
fixed: Retry, cancel, dead-letter requeue and bulk retry follow the target agent's advertised capabilities instead of a celery, rq and dramatiq allowlist, so huey, arq and taskiq tasks no longer answer 422 for actions their adapters advertise; an engine no agent advertises is refused by name.
changed: A schedule created without `catch_up` now stores `fire_one_missed` (existing rows keep their policy) and schedule reads report `skipped_slots_24h`; the schedule form defaults to it and the detail page shows the count beside the run strip when it is above zero.
added: Every packaged compose stack (the stacks the sdist ships) starts a scheduler over mTLS: a one-shot `scheduler-certs` service mints the CA and certificates into a named volume, the brain enables its scheduler gRPC server with the scheduler's CN allow-listed, and the scheduler runs as one single-leader replica on the SQLite stack and as two replicas electing through PostgreSQL on the PostgreSQL stack.
added: The sdist ships the deployment kit under `deploy/`: the `z4j` Helm chart (brain, scheduler, an opt-in PostgreSQL and a pre-install Job that mints the scheduler mTLS material), raw Kubernetes manifests and hardened systemd units; `publish-helm.yml` publishes the chart to `ghcr.io/z4jdev/charts/z4j`, signed and with provenance.
security: Require `pyjwt>=2.15.0`, the first release closing the thirteen PYSEC-2026-414x advisories (CVE-2026-102268 among them); the brain never imports jwt, the floor exists because redis-py carries it.
security: Every package release carries a reproducible CycloneDX 1.6 SBOM of its locked dependency closure beside the wheel and sdist, the published image carries an SPDX SBOM attestation, and `dco.yml` requires a `Signed-off-by` trailer on every pull-request commit.
security: The dashboard's pnpm overrides raise brace-expansion to 5.0.11 and undici to 7.29.1, and the bundled dashboard is rebuilt from this release's sources.
changed: The published security policy names the current minor line as receiving fixes and the previous minor as critical-only, and a release test holds both policy files to the version file.
fixed: The Security workflow uploads a scan report only when the scan that produces it ran, so a filesystem finding fails the job for the finding alone instead of also failing on a missing image report.
added: The `auditor` project role: everything a viewer may do plus the audit trail (list, export, verify, forwarder status), refused on every mutating project route. The audit tier is granted to auditor and admin only, so operators do not inherit audit reads; memberships, invitations, the role selectors and the role badge know the role.
added: `z4j audit prune` (a dry run by default, `--apply`, `--before`, `--hard`) runs the authenticated prefix prune by hand and writes an `audit.prune` row; `Z4J_AUDIT_RETENTION_BY_CLASS` gives an action class its own window for the worker and the command.
added: Background audit exports: `POST /api/v1/projects/{slug}/audit/export-jobs` queues an export of any size that the worker streams page by page into the configured sink (`Z4J_EXPORT_SINK=local` or `s3`), with job listing, status and a local-sink download; every method needs an auditor or an admin. `Z4J_AUDIT_HEAD_EXPORT_INTERVAL_SECONDS` writes the authenticated chain head to the same sink on a schedule under `audit-head/current.json`.
changed: The audit webhook forwarder delivers from a durable per-sink cursor in `audit_forward_state`, in chain order, advancing only after a 2xx with a persisted backoff, so a receiver that is down is a delay, not a gap; `GET /api/v1/admin/audit-forwarder` reports the cursor and lag to an instance admin, and the `X-Z4J-Audit-Schema: 1` header is added. `Z4J_AUDIT_WEBHOOK_BUFFER_SIZE` is inert.
security: Source-address allowlists: `Z4J_DASHBOARD_IP_ALLOWLIST`, `Z4J_API_IP_ALLOWLIST` and `Z4J_AGENT_IP_ALLOWLIST`, evaluated after trusted-proxy resolution, plus a per-key `allowed_cidrs` (create field, `PATCH /api/v1/api-keys/{key_id}`, dashboard input). Every denial answers 403 `ip_denied`, writes an `auth.ip_denied` row and increments `z4j_auth_ip_denied_total{surface}`.
security: Notification channel configs are encrypted at rest (AES-256-GCM under a key derived from `Z4J_SECRET`, `Z4J_PREVIOUS_SECRETS` honoured on decrypt), and `z4j secrets rewrap` re-wraps every stored value under the current master so an old secret can be dropped safely.
changed: Archiving a project disconnects its agents: live WebSocket sessions are closed and the long-poll routes answer 403 `project_inactive`, with an `agent.auth.project_inactive` row per refused agent.
changed: Five migrations move the schema head from `v1_11_audit_append_tally` to `v1_12_auditor_role` (API-key CIDRs, forwarder state, encrypted channel configs, export jobs and sink, the auditor role); each walks back under the refusals the release notes state, and the channel-config migration needs `Z4J_SECRET` in the migration environment.

v1.11.0 (2026-09-10)

changed: A coherent dashboard with consistent page controls, sortable record columns, restrained light and dark palettes, clearer settings navigation and responsive layouts.
added: Personal Saved Views let operators return to task-history filters, with correct filtered totals and all-matching selection.
added: An Agent Health view shows each agent's recent status reports with structured telemetry-loss counters; a missing report reads as unavailable accounting, never as zero loss.
changed: Upgrading applies a schema migration on the first start. On PostgreSQL it locks audit history and command writes while it seeds the audit tally, so schedule the upgrade for a quiet window.
fixed: PostgreSQL audit appends and scheduled-command receipt lookups remain efficient as history grows; independent signed audit verification remains available.
fixed: Preserve failed or timed-out fire history when resolving holds, avoid SQLite timeout-sweep crashes, restore PostgreSQL backups containing network-address values, and keep PostgreSQL reset and restore available after a supported downgrade and re-upgrade.
fixed: Task commands go to an agent that runs the task's engine and long-poll agents stay eligible; on a single-process brain a command for a live long-poll agent is accepted instead of reported offline; the schedule Edit dialog keeps a saved schedule's kind.

v1.10.0 (2026-08-28)

added: Run strips on the schedules table, the schedule detail page and a new Schedules needing attention panel on the project overview show each schedule's last twenty fires as a picture, so a flapping schedule, one failing in bursts and one dead for a week no longer look alike.
added: A Health badge shows a schedule's run of consecutive failures against the circuit-breaker threshold while the schedule is still enabled; the brain counted this on every breaker tick and kept only the disable.
added: GET /schedules/runs returns the last N fires for many schedules in one request, as a per-schedule top-N read bounded by the retention cutoff.
changed: Wide tables scroll instead of losing columns, open on a chosen column set with a Columns chooser, never wrap header labels, and render dates on one line in dense views. Schedule rows are about half their previous height.
changed: The canvas tree separates queue wait from execution time on every node.
fixed: Both circuit-breaker reads of fire history are per-schedule top-N reads bounded by the retention cutoff on fired_at, so a caught-up or replayed fire stays visible to the breaker; they scanned every fire in the retention window on each tick.
fixed: The public demo showed every schedule as held, a blank fire-history card on every detail page, and sixty recent tasks instead of five. It now matches the API.

v1.9.1 (2026-08-27)

added: The container images are published, z4j audit export-head prints the authenticated chain head, schedule hold is visible and controllable from the dashboard, the worker configuration lint has a panel, and dead-letter requeue is reachable.
fixed: The scheduler no longer loses a fire to its own dispatch latency, and the published image carries current base-image security updates.

v1.9.0 (2026-08-25)

added: Pause and resume controls, authenticated deep health, worker configuration lint, scheduled audit-chain verification, and guarded restore from a previous-release backup.
changed: The database transition is a stop-migrate-start upgrade and is one-way. A database holding z4j-native schedules refuses the downgrade rather than dropping paused-schedule state, agent tombstones, or delivery-owner snapshots the older schema cannot reconstruct. Take a backup before upgrading; restoring it is the supported way back.
fixed: Startup now enforces a PostgreSQL connection floor, schedule cadence identity remains stable across runtime patches, and production environment settings fail closed.
changed: Published dependency floors now exclude vulnerable cryptography, protobuf, Sentry SDK, Django, and sqlparse releases.

v1.8.0 (2026-07-30)

added: Durable bulk retry. A bulk retry is now a request you can watch rather than a fire-and-forget button. The request identity, its audit row, and the complete per-task plan commit together, so the work that will run is decided up front. Submitting the same request again returns the original outcome instead of re-expanding the filter, which matters because the set of failed tasks keeps moving. Each task is claimed once at its send edge under a fleet-wide in-flight bound, and a running retry can be paused and later resumed.
added: Authenticated audit chain. The audit log is signed with a dedicated key held apart from the database, so audit history that verifies cannot be written without holding that key, and the head and row counts are authenticated rather than inferred from the rows themselves. Verification also accepts a head you exported earlier to storage the database role cannot write, which is what covers a log rolled back to an earlier authentic state; without that anchor the chain is evidence against everything that goes through z4j rather than against whoever holds the database. Existing history is classified and frozen as authenticated legacy history during the upgrade; where it cannot be classified beyond doubt the upgrade stops and asks for an explicit operator attestation rather than adopting history it cannot prove.
added: Issues moves into the dashboard as its own page, with ongoing and recovered filters served by brain-side filtering, and scheduler misfires now surface directly on the Schedules page.
added: Connection pool sizing is configurable. Pool size and overflow were fixed values, which made the brain's connection demand impossible to fit to a database server the operator does not control. Defaults are unchanged, so no existing deployment shifts on upgrade.
changed: Rolling upgrades are a supported configuration. The brain may run one minor version ahead of its agents, so the control plane and the fleet can be upgraded independently rather than in one window. Exercised in both directions against a real prior release.
fixed: Reliability hardening across delivery, agent buffering, and scheduling. Retry authority is bound to the worker generation that executes it, the agent buffer only ever adopts storage it can prove belongs to it, and the agent starts safely on filesystems that cannot lock reliably. Validated by a harness running real brain and agent processes against both supported databases.

v1.7.0 (2026-07-14)

added: Automation rule engine. Per-project rules watch a task or scheduler trigger and run a governed action (notify an operator, retry a task, or cancel a task), each with its own guardrails: a rolling-window circuit breaker that trips a runaway rule into notify-only, a per-project kill switch, and a dry-run mode that records what a rule would have done without touching anything. Destructive rules require admin authority; browser-session mutations require fresh MFA, bearer-authenticated callers follow API-key authority, and fire time rechecks the creator's current admin membership. Every firing lands on the audit log.
added: Issues (failure fingerprinting). Task failures group by a stable fingerprint so the same bug across runs and engines collapses to one issue with occurrence counts, an open vs recovered split, first and last seen, and the engines affected.
added: Scheduler reliability. Brain-side misfire detection flags any enabled interval or cron schedule whose expected fire is past a grace window (a dead or partitioned scheduler is the usual cause) and feeds it to automation, subscriptions, and metrics. Project-wide misfires are queryable from the REST API and a new CLI, and fire-now actions are attributed to the operator who triggered them. Fire history is range-partitioned for fast retention.
added: MFA trust shell. A TOTP second factor via any standard authenticator app, one-time recovery codes, and an opt-in remember-this-device cookie. Enforcement is opt-in and off by default; once a user is enrolled their session must pass the second factor before general access.
security: Hardening release. Closes a set of execution-path and step-up-authentication findings, plus a frontend and tooling dependency refresh. Operators are advised to upgrade.
changed: Verified data-safe in-place upgrade from 1.6.x on both PostgreSQL and SQLite (a populated upgrade preserved every row). The wire protocol is compatible for a rolling upgrade: upgrade the brain first, then roll the agents. Python 3.11 is the new minimum.

v1.6.9 (2026-06-23)

fixed: Reliability release. Eliminates a spurious shutdown-time error traceback on short-lived processes (one-shot management commands) by draining the agent runtime before the interpreter tears down its worker pool. Adds an opt-out for the liveness heartbeat on transient processes. Plus an audit-trail completeness improvement for the bulk-retry endpoint.

v1.6.8 (2026-06-08)

security: Follow-on security release. Closes two high-severity issues in the bulk-retry and mixed-version dispatcher paths that the Round 9 external audit surfaced on top of 1.6.7. Operators are advised to upgrade.

v1.6.7 (2026-06-07)

security: Security release. Addresses a high-severity issue in one engine adapter's retry surface plus supply-chain hardening across CI workflows. Operators running RQ or shared-Redis deployments are advised to upgrade.

v1.6.6 (2026-06-07)

security: Security release. Addresses a high-severity information-disclosure issue plus several lower-severity hardening items. Operators are advised to upgrade.

v1.6.5 (2026-05-27)

security: Security release closing multiple authentication, session, transport, and dependency-supply-chain hardening items. Operators are advised to upgrade.
changed: Password minimum length aligned at 12 characters across backend default, dashboard fallback, and operator docs.

v1.6.3 (2026-05-15)

security: Security release. Operators are advised to upgrade.

v1.6.2 (2026-05-14)

changed: Dashboard design system unified across every page: consistent headers, filter toolbars, search inputs, action buttons, empty states, and time-range pickers.
added: Search and state filters on the Agents, Queues, and Workers pages.
security: Frontend and tooling dependency refresh.

v1.6.1 (2026-05-13)

fixed: Dashboard bundle correction for the MFA enrollment and post-login challenge surfaces. In-place upgrade picks up the fix.

v1.6.0 (2026-05-13)

added: Multi-factor authentication. TOTP via any standard authenticator app (Authy, 1Password, Google Authenticator, etc.), single-use recovery codes, optional 30-day device trust. Opt-in: existing users stay unenrolled until they enable it.
added: Microsoft Teams notification channel. Workflows webhooks, Power Automate, and the legacy O365 connector all auto-detected at save time.
added: Sentry error capture, OpenTelemetry tracing, audit-log webhook forwarding, four Grafana dashboards, and a Live Activity Feed on the dashboard home.
changed: One bidirectional schema migration (upgrade and downgrade both safe on populated databases). No data migration required.

v1.5.1 (2026-05-12)

fixed: Brain memory hygiene under sustained burst load. Tunable via `Z4J_DATABASE_STATEMENT_CACHE_SIZE`.
added: Four new Prometheus gauges plus a Grafana dashboard so operators can verify operational health in their own environment.

v1.5.0 (2026-05-11)

security: Security release. Operators are advised to upgrade.
fixed: Task-correctness fixes around event acknowledgement, event-loop decoupling, and event deduplication.
fixed: Scheduler load-test fixes.

v1.4.0 (2026-05-03)

changed: The brain server, dashboard, REST API, audit log, and reconciliation all ship in a single `z4j` distribution. `pip install z4j` is the only install path operators need.
added: Engine adapters available via extras: `pip install z4j[django,celery]` for the full Django + Celery stack, plus extras for FastAPI, Flask, RQ, Dramatiq, Huey, arq, TaskIQ, APScheduler.
security: Security release. Operators are advised to upgrade.

`z4j-bare`

v1.12.0 (2026-10-03)

added: The `dlq.list` command is dispatched onto `adapter.list_dead_letters` and its page serialised into the command result; the dispatcher refuses the action fail-closed unless the adapter advertises `list_dead_letters`, checks that before reading any parameter, and fails a malformed `queue`, `limit` (clamped to 200) or `cursor` with a named error without reaching the adapter.

v1.11.0 (2026-09-10)

added: Buffer eviction and content rejection now record what they discard in the buffer file, in the same transaction as the deletion, and heartbeats and agent status report those counters together with supported adapter event loss.
changed: The heartbeat dropped-event total now includes buffer and adapter event loss, and `Heartbeat.record_dropped()` raises `ValueError` for a bool, non-integer or negative count instead of adding it.
changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

fixed: Unsupported agents back off instead of reconnecting forever, with stricter capability and lifecycle handling.

v1.8.0 (2026-07-30)

changed: Agent durability. Each process generation seals its own buffer before examining older ones, and only a buffer it can prove is exclusively held and belongs to this deployment is recovered automatically. Anything foreign or unreadable is left in place for a human rather than drained or deleted. On filesystems that cannot lock reliably the agent relocates to a private path and logs it instead of refusing to start.
changed: A close the agent cannot fix by reconnecting is now treated as terminal, so a rejected agent stops rather than reconnecting in a loop.

v1.7.0 (2026-07-14)

fixed: Agent runtime and dispatch fixes from a fleet readiness sweep, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

fixed: Shutdown lifecycle hardening: the agent runtime now registers its teardown to run before the process worker pool is shut down, drains in-flight work deterministically, and supports a heartbeat-less mode for short-lived processes. Removes the spurious shutdown-time error noise.

v1.6.8 (2026-06-08)

security: Dispatcher hardening: refuses retry against a legacy RQ adapter rather than falling back to a signature that would re-open a prior pickle-deserialization issue.
fixed: Brain-derived task name now wins over operator-supplied values in the Huey retry path.

`z4j-core`

v1.12.0 (2026-10-03)

added: `QueueEngineAdapter.list_dead_letters(queue, limit, cursor)` returns a `DeadLetterPage` of `DeadLetterEntry` rows (task id, name, queue, failed time, a redacted 512-character error excerpt, attempts), newest first, at most 200 entries per page with an opaque cursor; it is read-only by contract and never deserialises a broker payload.
added: The capability token `list_dead_letters`, `Action.LIST_DEAD_LETTERS` in the policy engine, and the command action `dlq.list` whose result is the page.
added: `ProjectRole.AUDITOR`, ranked between viewer and operator and a sibling of operator for the audit tier: everything a viewer may do plus the audit trail, and no mutation.
changed: The policy engine is rebuilt from the brain's real gates into a lattice (`ROLE_ORDER`, `ACTIONS_BY_ROLE`, `ROLES_SATISFYING_TIER`, `action_allowed`, `role_satisfies`); `Action.UPDATE_RETENTION` is removed and twenty-three actions the brain gated and the table lacked are added, with contract tests enumerating every role and action pair.

v1.11.0 (2026-09-10)

added: Heartbeat and agent-status frames can carry an optional structured telemetry-loss report; the signed-frame verifier rejects invalid counters before they consume replay state, and a frame without a report means accounting is unavailable, not zero loss.
changed: Accept Pydantic 2.9.2 or newer (2.12 or newer on Python 3.14+) and typing-extensions 4.12.2 or newer instead of requiring the latest releases.
changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Coordinated 1.9 protocol and capability contracts, with stricter validation and fail-closed compatibility boundaries.

v1.8.0 (2026-07-30)

changed: Transport carries a versioned capability contract so the brain can tell what the connected agent is able to honour, rather than assuming. Redaction and path handling were tightened alongside it.

v1.7.0 (2026-07-14)

added: Failure fingerprinting support in the shared domain layer, so the same bug across runs and engines collapses to one issue.
changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Python compatibility floor relaxed from 3.10/3.11 to 3.10 so adapters embedded in operator processes can install on the broader Python deployment base.

`z4j-scheduler`

v1.12.1 (2026-10-05)

changed: The pinned cadence closure moves to croniter 6.2.4 and tzdata 2026.5 (IANA 2026e), together with the brain. Under the previous timezone data fire times are an hour wrong from 2026-11-01 for America/Winnipeg, Canada/Central, America/Rainy_River and America/Inuvik.
security: The `apscheduler`, `huey`, `arq` and `taskiq` import extras no longer cap a major.

v1.12.0 (2026-10-03)

added: `z4j_scheduler_watch_healthy{project}` follows the watch stream's health; `/ready` answers 503 with `watch_unhealthy` once the stream has been down longer than `on_time_grace_seconds` and 200 again after recovery; `/info` reports `watch_stream_healthy`.
fixed: `z4j_scheduler_schedules_loaded` and `z4j_scheduler_grpc_calls_total{method,status}` were declared and never emitted; both now emit, and a dropped project retires its `is_leader` series.
changed: A cadence-semantics mismatch answered during a retry holds the schedule locally and asks for renegotiation; only a mismatch that survives an agreed renegotiation is the durable quarantine, and transient retries are withheld while the watch stream is down.
fixed: Shutdown stops admitting slots, awaits in-flight dispatches up to `fire_timeout_seconds`, and only then releases the leader gate and closes the channel.
added: Tombstone pressure that pauses a project logs a warning naming the project and count and requests an immediate snapshot resync; a single leader backend bound off loopback outside `dev` logs once that it is not an election.
changed: The default `on_time_grace_seconds` moves from 5 to 30 (maximum 300) so a slot due during a brain restart is late rather than missed, and the watch stream's reconnect penalty clears after one healthy reconcile interval instead of never.
added: `import --from` and `export --to` accept huey, arq, taskiq and dramatiq, with `--huey-app`, `--arq-settings` and `--taskiq-broker` locators; `--from dramatiq` prints migration guidance and exits 2. New extras `huey-import`, `arq-import` and `taskiq-import` carry the adapters' engine floors.
removed: `leader/pg_advisory.py`, a stub with no importer.
changed: Type annotations across the package so that mypy strict gates it beside z4j-core, and an import-linter contract that scheduler source never imports the brain. No behaviour changed.

v1.11.0 (2026-09-10)

fixed: Stop new catch-up work when watch health, leadership or shutdown conditions require it, while preserving accepted progress and the remaining backlog.
changed: Bound PostgreSQL election calls, track cache counts efficiently and expose tick, iteration and watch-reconnection observations.
fixed: Propagate unexpected dispatch recovery failures to the bounded supervisor and verify durable acceptance after lost responses over real mTLS gRPC.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

fixed: A slot the leader had already seen as due is no longer discarded because of the scheduler's own dispatch latency; the on-time judgement is frozen across retries for a bounded window.
added: Slots dropped by a catch_up policy are logged and counted; the on-time grace is configurable; an unexpected error in one tick no longer stops the scheduler.

v1.9.0 (2026-08-25)

added: Pause and resume controls, scheduler diagnostics, and cadence identities that remain stable across dependency and Python patch changes.
changed: The protobuf runtime floor is 6.33.5, above both the committed gencode minimum and the first advisory-fixed release.

v1.8.0 (2026-07-30)

changed: Schedule cursor authority. A schedule's next-fire cursor is normalised to a single cadence identity and advanced under the brain's authority, so a schedule cannot appear to be moving while never actually running. Databases that reached an affected pre-release state are repaired automatically and the repair is recorded in the schedule change log like any other transition.

v1.7.0 (2026-07-14)

added: Fire-variance metrics showing how far each fire lands from its scheduled time, and an info command that reports version, uptime, readiness, per-subsystem health and loaded-schedule count from the running service.
changed: Fire history is range-partitioned on PostgreSQL, so retention drops a partition instead of running a large delete. Python floor raised to 3.11.

v1.6.7 (2026-06-08)

changed: Python floor relaxed from 3.13 to 3.11 so the scheduler process runs on the same interpreter range as the brain.

`z4j-django`

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Accept Django 4.2 or newer, replacing the Django 5.2.17 and 6.0.8 minimums, and leave SQLParse to Django's own requirements. The range now states API compatibility, not patch level: z4j-django no longer forces a Django upgrade or refuses an unpatched Django, so keep the host on a supported, patched Django release.
changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned with the coordinated 1.9 runtime, security posture, and capability contracts.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

fixed: Clean shutdown on short-lived management commands: no more spurious error traceback at process exit.

v1.6.8 (2026-06-08)

security: Engine-extra floor lifted so `pip install z4j-django[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

changed: Wider Django compatibility range: installs cleanly against Django 5.0 and up with no upper cap. Operator owns their own Django security posture; the adapter no longer gates on CVE versions.

`z4j-fastapi`

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: The uncapped compatibility floor is FastAPI >=0.109.1, the first advisory-fixed release on the supported Pydantic 2 line.

v1.8.0 (2026-07-30)

changed: Version alignment with the fleet release. No functional change in this package.

v1.7.0 (2026-07-14)

changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

fixed: Clean shutdown registration so the agent drains before the process worker pool is torn down.

v1.6.8 (2026-06-08)

security: Engine-extra floor lifted so `pip install z4j-fastapi[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

changed: Compatibility floor corrected to FastAPI >=0.100, the first release compatible with z4j-core's Pydantic 2 floor, with no upper cap.

`z4j-flask`

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Accept Flask 2.3.3 or newer, replacing the Flask 3.1.3 minimum. The range now states API compatibility, not patch level: z4j-flask no longer forces a Flask upgrade or refuses an unpatched Flask, so keep the host on a supported, patched Flask release.
changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned with the coordinated 1.9 runtime, security posture, and capability contracts.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

fixed: Clean shutdown registration so the agent drains before the process worker pool is torn down.

v1.6.8 (2026-06-08)

security: Engine-extra floor lifted so `pip install z4j-flask[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest Flask version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-arq`

v1.12.1 (2026-10-05)

changed: The requirement is `arq>=0.26` with no upper bound.

v1.12.0 (2026-10-03)

changed: `list_dead_letters` is a fail-closed refusal: arq has no first-class dead-letter store, so the capability stays absent, the agent dispatcher never reaches the method, and a direct call raises `AdapterError` without touching the broker, the same posture as `requeue_dead_letter`.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned engine behavior and capability reporting with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

changed: Version alignment with the fleet release. No functional change in this package.

v1.7.0 (2026-07-14)

fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest arq version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-celery`

v1.12.0 (2026-10-03)

changed: `list_dead_letters` is a fail-closed refusal: Celery has no first-class dead-letter store, so the capability stays absent, the agent dispatcher never reaches the method, and a direct call raises `AdapterError` without touching the broker, the same posture as `requeue_dead_letter`.

v1.11.0 (2026-09-10)

fixed: Offload blocking task submission to the dedicated broker pool; a timed-out publish remains explicitly indeterminate and is never blindly retried.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

removed: Removed the unsafe dead-letter requeue capability. Direct calls now fail closed without publishing a duplicate task.
changed: The uncapped compatibility floor is Celery >=5.2.2, excluding the vulnerable 5.2.0/5.2.1 line.
fixed: Purge and engine behavior are aligned with the coordinated 1.9 capability contract.

v1.8.0 (2026-07-30)

changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-07)

fixed: Multi-tenant cache bleed fix. Worker-stats cache moved from class scope to instance scope so two adapters in the same process no longer share state.

`z4j-dramatiq`

v1.12.1 (2026-10-05)

changed: The requirement is `dramatiq>=1.14` with no upper bound, in the base dependency and both broker extras.

v1.12.0 (2026-10-03)

added: `list_dead_letters` is advertised where the broker's dead-letter store can be read without consuming it: on Redis the `<queue>.XQ` store is listed with full entries (JSON bodies only; a `PickleEncoder` deployment gets id, queue and time), on RabbitMQ the page carries the `.XQ` message count only because AMQP has no non-destructive read. `requeue_dead_letter` stays absent.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Removed advertised operations that stock Dramatiq cannot satisfy safely.

v1.8.0 (2026-07-30)

changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest Dramatiq (>=1.14, <3) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-huey`

v1.12.1 (2026-10-05)

added: Huey 3 support beside Huey 2: the timeout signal is a failed task, the rate-limit signal a revoked one, and a retry of either is a single retried event. The requirement is `huey>=2.4` with no upper bound.
fixed: A retry issued from the brain never found its task; it now resolves the registry key or a unique bare name.
fixed: A task cancelled in a pre-execute hook stayed started when it declared retries; it is closed as revoked.

v1.12.0 (2026-10-03)

changed: `list_dead_letters` is a fail-closed refusal: Huey has no first-class dead-letter store, so the capability stays absent, the agent dispatcher never reaches the method, and a direct call raises `AdapterError` without touching the broker, the same posture as `requeue_dead_letter`.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned engine behavior and capability reporting with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest Huey (>=2.4, <3) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-rq`

v1.12.1 (2026-10-05)

changed: The requirement is `rq>=1.10.1` with no upper bound.

v1.12.0 (2026-10-03)

added: `list_dead_letters` is advertised: `dlq.list` pages each queue's `FailedJobRegistry` newest first with an offset cursor and never deserialises a job payload, so pickled job data is not touched; every task id in the page is one `requeue_dead_letter` accepts.

v1.11.0 (2026-09-10)

added: Opt-in POSIX fork worker `z4j_rq.worker.Worker`, selected with `rq worker --worker-class z4j_rq.worker.Worker`, sets each job's environment only in the forked child, removing the per-job environment allocations that stock RQ retained in the long-running parent on the tested glibc stack. Installing the package does not replace existing stock or custom workers.
fixed: Offload blocking task submission to the dedicated broker pool; a timed-out publish remains explicitly indeterminate and is never blindly retried.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Engine actions now advertise and enforce only capabilities that the connected 1.9 worker can safely honor.

v1.8.0 (2026-07-30)

changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

changed: Compatibility floor corrected to RQ >=1.10.1 with a <3 cap. RQ 1.10.0 cannot import on Python 3.12 and later.

`z4j-taskiq`

v1.12.1 (2026-10-05)

changed: The requirement is `taskiq>=0.11` with no upper bound.

v1.12.0 (2026-10-03)

changed: `list_dead_letters` is a fail-closed refusal: taskiq has no first-class dead-letter store, so the capability stays absent, the agent dispatcher never reaches the method, and a direct call raises `AdapterError` without touching the broker, the same posture as `requeue_dead_letter`.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Unsupported queue, ETA, and priority overrides now fail closed; broker operations require the correct owner event loop.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest TaskIQ version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-apscheduler`

v1.12.1 (2026-10-05)

changed: The requirement is `apscheduler>=3.10.2` with no upper bound; the adapter refuses, by name, a scheduler without the APScheduler 3 job interface.

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned pause, resume, and capability behavior with the coordinated 1.9 scheduling contract.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Compatibility floor corrected to APScheduler >=3.10.2 and <4. Earlier releases require the removed pkg_resources module at import time.

`z4j-arqcron`

v1.12.1 (2026-10-05)

changed: The requirement is `arq>=0.26` with no upper bound.

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned periodic scheduling behavior and dependency floors with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest arq version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-celerybeat`

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned periodic scheduling behavior and dependency floors with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest Celery (>=5.3) and django-celery-beat (>=2.5) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-hueyperiodic`

v1.12.1 (2026-10-05)

changed: The requirement is `huey>=2.4` with no upper bound; the suite runs on Huey 2 and Huey 3 with a real consumer.

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Aligned periodic scheduling behavior and dependency floors with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest Huey (>=2.4, <4) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-rqscheduler`

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: No longer advertises an enable operation that cannot restore a removed schedule definition.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest rq-scheduler (>=0.11) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

`z4j-taskiqscheduler`

v1.12.1 (2026-10-05)

changed: The requirement is `taskiq>=0.11` with no upper bound.

v1.12.0 (2026-10-03)

changed: Carried with the coordinated fleet release. No behaviour changed.

v1.11.0 (2026-09-10)

changed: Align runtime version metadata and sibling dependency floors with the coordinated 1.11.0 release.

v1.10.0 (2026-08-28)

changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

changed: Custom schedule-source operations now require the correct owner event loop and fail closed when it is unavailable.

v1.8.0 (2026-07-30)

changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

changed: Wider compatibility range: now installs against the lowest TaskIQ version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.