From f39afe043db022581c8b4e4b5c87911e316556f0 Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Tue, 13 Oct 2026 06:20:18 +0700 Subject: [PATCH 1/5] chore(release): prepare Registry Stack v0.41.0 Signed-off-by: Jeremi Joslin --- docs/site/src/content/docs/changelog.mdx | 207 +++++++++++- .../operate/advanced/upgrade-and-retire.mdx | 185 +++++----- products/breg/CHANGELOG.md | 2 + products/casework/CHANGELOG.md | 2 + products/discovery/CHANGELOG.md | 2 + products/evidence/CHANGELOG.md | 2 + products/manifest/CHANGELOG.md | 4 + products/manifest/docs/release-notes.md | 4 + products/messaging/CHANGELOG.md | 2 + products/platform/CHANGELOG.md | 2 + products/render/CHANGELOG.md | 4 + products/scheduling/CHANGELOG.md | 2 + release/manifests/registry-stack-beta-53.yaml | 48 +++ release/notes/v0.41.0.md | 319 ++++++++++++++++++ 14 files changed, 681 insertions(+), 104 deletions(-) create mode 100644 release/manifests/registry-stack-beta-53.yaml create mode 100644 release/notes/v0.41.0.md diff --git a/docs/site/src/content/docs/changelog.mdx b/docs/site/src/content/docs/changelog.mdx index 6bb67c1b0..8ec93c20d 100644 --- a/docs/site/src/content/docs/changelog.mdx +++ b/docs/site/src/content/docs/changelog.mdx @@ -16,7 +16,7 @@ documents. Per-product release notes live in each product repository; the entries below link to the relevant product pages on this site rather than duplicating release notes. -## Unreleased +## v0.41.0 beta-53 - BREAKING: the published `registry-stack-client` Python package requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), its wheels are built against the Python 3.11 @@ -64,12 +64,20 @@ relevant product pages on this site rather than duplicating release notes. release/scripts/check-glibc-floor.sh; release/scripts/render-installer-libc-preflight.py, INSTALLERS. */} -- The Base Registry Engine (BReg), Registry Casework, Registry Scheduling, and Evidence installers - start every Linux binary they verified before they select the release, as they already did on - macOS. An installer checks the glibc floor of the release it was published with, so an installer - asked for an earlier release could select binaries built for a newer glibc than the host carries; - those binaries then failed at first run. The installer now refuses that release, names the binary - that did not start, and leaves the installed toolset selected. See +- Workflow `actions/setup-go` steps that compile AWS-LC-FIPS from source use Go 1.27.2, where they + used 1.24.4. Go remains a build tool and is not shipped. The distinct canonical Linux builder + still uses the snapshot-pinned Go package in its Debian 13 builder image. + +{/* Evidence: .github/workflows/release-candidate.yml, actions/setup-go steps; + release/notes/dependency-vetting-aws-lc-fips.md, Build prerequisites; + release/scripts/test_release_workflow_structure.py, GO_VERSION. */} + +- The four BReg, Registry Casework, Registry Scheduling, and Evidence installers start every staged + Linux binary with `--version` before they select the release, as they already did on macOS. An + installer checks the glibc floor of the release it was published with, so an installer asked for + an earlier release could select binaries built for a newer glibc than the host carries; those + binaries then failed at first run. The installer now refuses that release, names the binary that + did not start, and leaves the installed toolset selected. See [known limitations](../explanation/known-limitations/). {/* Evidence: crates/registry-breg/install.sh; crates/registry-casework/install.sh; @@ -79,6 +87,191 @@ relevant product pages on this site rather than duplicating release notes. release/scripts/test_nightly_release.py, test_linux_binary_that_cannot_start_never_replaces_the_installed_toolset. */} +- BREAKING: BReg revision reads no longer accept the v0.38.0-and-earlier provenance that journaled + an immediate action under its effect identifier. A detail read, or a list page containing such a + revision, answers `503 source.unavailable`. v0.41.0 reads only predecessor state created by a + v0.40.0 apply, which already journals the entity's canonical operation identifier and needs no + change. An older deployment must first follow the v0.40.0 fresh-database migration, then upgrade + that v0.40.0 predecessor state. + +{/* Evidence: products/breg/CHANGELOG.md, "revision history no longer reads a revision journaled + under an immediate action's effect identifier". */} + +- BREAKING: BReg refuses a database without subject access-log storage before it binds a listener. + Every apply from v0.38.0 onward installed that storage, including when the package declares no + `accessLog`, so predecessor state created by a v0.40.0 apply needs no change. v0.41.0 does not + upgrade older state in place: an older deployment must first follow the v0.40.0 fresh-database + migration, then upgrade that v0.40.0 predecessor state. + +{/* Evidence: products/breg/CHANGELOG.md, "a database without the subject access-log storage is no + longer verified or served". */} + +- BReg's Rust, Node.js, and Python clients accept additive object members in metadata and valid + Problem envelopes. Unsupported must-understand capabilities disable only the affected binding, + and unsupported descriptive metadata omits only the affected statistical dataset, descriptive + change-request capability, selector, or spatial capability. An unknown temporal mode retains its + inert `temporal` descriptor because null means the collection is non-temporal. Valid unknown + Problem codes retain their HTTP status and trace ID without inferred semantics; malformed known + fields and envelopes still fail as protocol errors. + +{/* Evidence: products/breg/CHANGELOG.md, "metadata readers ignore unknown object members", + "Well-formed unsupported metadata vocabulary", and "clients handle valid unknown Problem + codes". */} + +- `bregctl dev` derives the local runtime's principal and purpose claim mappings from the compiled + project and refuses an unservable mixed mapping before it retains development state. + `caseworkctl source add` uses the same-version `bregctl explain access` result to generate the + `casework-reader` profile with the BReg project's one compiled `principalClaim`, preserves exact + test-bound client variants, and accepts equivalent trailing-slash spellings of the Casework + review endpoint. + +{/* Evidence: products/breg/CHANGELOG.md, the three `bregctl dev` claim-mapping entries; + products/casework/CHANGELOG.md, `caseworkctl source add` and source pairing entries. */} + +- The native citizen self-registration acceptance project combines ThunderID SMS signup, + account-owned BReg applications, Casework review, and transactional Person creation, account + linking, and program enrollment through configured BReg actions. It proves an adopter + composition across existing product boundaries and adds no built-in business model or runtime. + +{/* Evidence: products/breg/acceptance/citizen-self-registration/README.md; + products/breg/acceptance/citizen-self-registration/tests/run-live.py; + release/notes/v0.41.0.md, "Acceptance projects and release operation". */} + +- Registry Casework task templates can use `authorizationMode: deferred` with a lifetime of up to + seven days. Immediate grants keep their 900-second ceiling. A deferred review grant is bound to + the task's assignment generation and ends when assignment or terminal state changes; deferred + grants cannot carry Evidence bounds. Casework migration 0022 installs the grant-window constraints + and assignment-generation trigger, validating the affected tables under an exclusive lock. + +{/* Evidence: products/casework/CHANGELOG.md, `authorizationMode: deferred` and migration 0022. */} + +- The shared Registry Platform task-grant status transport now supplies BReg and Scheduling with + `TaskGrantStatusConfig`, endpoint validation, status credentials, exact binding checks, and the + default Casework status scope and route. BReg accepts optional `statusScope` and `statusPath`, and + its development tooling can bind declared Casework task authorities into the generated runtime. + +{/* Evidence: products/platform/CHANGELOG.md, `registry-platform-oidc` task_grant module and + `TaskGrantStatusConfig`; products/breg/CHANGELOG.md, `statusScope`, `statusPath`, and + `bregctl dev` taskGrantStatus entries. */} + +- BREAKING: BReg treats a `401` or `403` from the Casework task-grant status endpoint as an outage, + answering `503 service.unavailable` where it answered `412 precondition.failed`. A `404` still + refuses the grant with `412`. The shared transport identifies itself as `registry-task-status` + instead of `registry-breg-task-status`. Update alerts for a revoked or misconfigured status + client, and update access-log user-agent matches. + +{/* Evidence: products/breg/CHANGELOG.md, "task-grant status check before a governed write". */} + +- BREAKING: BReg validates each `taskGrantStatus` entry when it reads the runtime file and reports + `breg.runtime.invalid-task-grant-status` at `/taskGrantStatus`, where activation reported + `breg.runtime.invalid-binding`. The endpoint and client members now use their URL, external + identifier, resource URI, and issuer types at that boundary. A configuration that v0.40.0 + activated already meets the member rules. Update scripts that match the earlier diagnostic code. + +{/* Evidence: products/breg/CHANGELOG.md, "runtime checks each `taskGrantStatus` entry". */} + +- BREAKING: Registry Casework removes `casework migrate` and `caseworkctl db`. Use `caseworkctl plan + --runtime-config FILE` followed by `caseworkctl apply --runtime-config FILE`. It also removes the + `casework.package.retired-manifest` refusal. v0.40.0 already refused these commands and packages + with the retired manifest, so no valid v0.40.0 package needs rebuilding for this cleanup. Rebuild + an older retained package with `caseworkctl package` instead of matching the removed code. + +{/* Evidence: products/casework/CHANGELOG.md, `casework migrate` and + `casework.package.retired-manifest`. */} + +- BREAKING: `caseworkctl dev` removes a database volume only when it carries the session ownership + label. Every v0.40.0 session labels its volume. Before you remove an older unlabeled + `casework-dev-` volume, inspect and back up its contents. Removing the volume with + `docker volume rm` permanently destroys its data. Follow the + [v0.41.0 release note](https://github.com/registrystack/registry-stack/blob/v0.41.0/release/notes/v0.41.0.md#retired-command-and-compatibility-paths). + +{/* Evidence: products/casework/CHANGELOG.md, "removes a database volume only when the volume + carries the session's ownership label". */} + +- BREAKING: the Casework BReg source adapter refuses a legacy bare continuation cursor that names + no request entity. Every cursor stored by v0.40.0 names its entity, so a v0.40.0 database needs no + migration. + +{/* Evidence: products/casework/CHANGELOG.md, "source adapter refuses a stored discovery cursor". */} + +- BREAKING: `caseworkctl dev` reports five configuration refusals with exit status 1, where it + reported `caseworkctl.operational-failure` and exit status 3: + `caseworkctl.dev.integrations-invalid`, `caseworkctl.dev.shared-client-mismatch`, + `caseworkctl.dev.shared-task-authority-mismatch`, + `caseworkctl.dev.source-binding-invalid`, and + `caseworkctl.dev.borrowed-principal-invalid`. A borrowed issuer session also refuses + `principalClaim: sub`, because that claim names the issuer owner's subject. Use a stable claim in + every Casework access profile, register it for each client in both projects' `dev-clients.yaml`, + and update scripts that match the earlier status and code. + +{/* Evidence: products/casework/CHANGELOG.md, "reports five configuration refusals" and "refuses a + session that borrows another project's issuer". */} + +- BREAKING: `CaseworkTaskAssertionSource` classifies a Casework `4xx` assertion refusal other than + `408` or `429` as `invalid-credential`, where it classified every failure as `unavailable`. + Request a new approval instead of retrying an expired, revoked, or absent grant. + +{/* Evidence: products/casework/CHANGELOG.md, `CaseworkTaskAssertionSource`. */} + +- BREAKING: `evidencectl build` is now an unknown command. Use `evidencectl package` with the project + directory as its positional argument and retain the same `--target` and `--output` options. + `evidencectl init` and `evidencectl new` no longer accept the inactive `--generate-keys` option; + remove it because a local project already creates disposable keys. + +{/* Evidence: products/evidence/CHANGELOG.md, "drops two spellings it had stopped acting on". */} + +- BREAKING: Registry Scheduling requires a top-level `taskGrantStatus` in every runtime file. List + one to 32 task authorities whenever the deployment requires current status or revocation checks, + and for deferred work. `taskGrantStatus: unchecked-final-fifteen-minutes` checks only the grant's + remaining lifetime because the signed token does not identify its original mode. It admits any + grant with at most 900 seconds remaining without checking revocation, including the final 900 + seconds of a deferred grant. Use it only when the deployment accepts that stale-authority window. + An omitted member is refused at startup with `scheduling.runtime.missing-task-grant-status`. + +{/* Evidence: products/scheduling/CHANGELOG.md, the `taskGrantStatus` behavior and missing-member + refusal; products/scheduling/RUNTIME-CONFIG.md, `taskGrantStatus` offline path. */} + +- BREAKING: Registry Scheduling removes three refusals for pre-v0.40.0 inputs. `scheduling migrate` + is an unknown command; activate with `schedulingctl plan` and `schedulingctl apply`. + `scheduling.package.retired-manifest` is replaced by the ordinary package-content refusals, so + rebuild with `schedulingctl package`. `schedulingctl.activation.earlier-release` is replaced by + `schedulingctl.store-unavailable`, so start from a new database when the retained policy uses the + pre-v0.40.0 identity. A database activated by v0.40.0 needs no reset. Direct Rust consumers must + remove `RuntimeError::RemovedCommand`, `RuntimeError::exit_code`, + `runtime::removed_command_refusal`, `RuntimeConfigError::RetiredPackageManifest`, + `config::RETIRED_PACKAGE_MANIFEST_FILE`, and `StoreError::EarlierRelease`. + +{/* Evidence: products/scheduling/CHANGELOG.md, "three refusals that named input only releases + before v0.40.0 wrote or accepted". */} + +- Registry Scheduling's `POST /v1/appointments/receipt` and Registry Messaging's + `POST /v1/messages/receipt` use the original `Idempotency-Key`, request body, and verified caller + identity to resolve the retained original success receipt. They do not return the request body or + repeat the mutation. Both routes use current ordinary read authority. Scheduling can recover the + receipt after the task grant ends. An unresolved receipt answers `409 receipt.unresolved`, which + does not prove that no effect occurred. The Rust, Node.js, and Python clients carry both routes. + +{/* Evidence: products/scheduling/CHANGELOG.md, `POST /v1/appointments/receipt`; + products/messaging/CHANGELOG.md, `POST /v1/messages/receipt`. */} + +- BREAKING (Rust API): `registry_scheduling_core::ProblemCode` and + `registry_messaging_core::ProblemCode` gain `ReceiptUnresolved`. Add that arm, or a wildcard arm, + to exhaustive matches. + +{/* Evidence: products/scheduling/CHANGELOG.md and products/messaging/CHANGELOG.md, + `ProblemCode` gains `ReceiptUnresolved`. */} + +- BReg and Casework local development pull the same pinned PostgreSQL image from + `public.ecr.aws/docker/library/postgres`. Messaging pulls that PostgreSQL mirror and Mailpit from + `ghcr.io/axllent/mailpit`. Development egress allowlists must admit `public.ecr.aws` and, for + Messaging, `ghcr.io`. Retained BReg and Casework containers using the earlier Docker Hub + PostgreSQL reference at the same digest remain accepted; BReg PostGIS sessions still use Docker + Hub's `postgis/postgis` image. + +{/* Evidence: products/breg/CHANGELOG.md, `bregctl dev start` PostgreSQL image; + products/casework/CHANGELOG.md, `caseworkctl dev start` PostgreSQL image; + products/messaging/CHANGELOG.md, `messagingctl dev` PostgreSQL and Mailpit images. */} + ## v0.40.0 beta-52 - BREAKING: v0.40.0 does not upgrade v0.39.0 configuration, packages, or databases in place, and diff --git a/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx b/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx index b9852d3bf..48027e607 100644 --- a/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx +++ b/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx @@ -28,10 +28,9 @@ rolling upgrade that mixes releases is not supported: [Upgrade Casework and BReg in lock-step](../../casework/#upgrade-casework-and-breg-in-lock-step). - **Adopter tooling is checked.** `evidencectl` refuses an `evidence` or `bregctl` binary of another version. -- **Clients are not checked, and break silently.** Clients send no version, and runtimes accept any - caller. The clients decode responses strictly, so a member one release adds can fail an older - client's decoding, and a member one release requires can be missing from an older runtime's - answer. Upgrade each client to the same release as the runtime it calls. +- **Clients are not checked.** Clients send no version, and runtimes accept any caller. Pre-1.0 + client and wire contracts can change incompatibly between releases, so upgrade each client to + the same release as the runtime it calls. - **BReg activation is not rolling.** Once `bregctl apply` activates a successor, every `breg` process still running the previous package fails readiness until it restarts onto the successor. Plan the restart as part of the activation, not after it. @@ -45,7 +44,6 @@ v0.39.0 wrote in place, and its release notes have you apply it to new databases {/* Evidence: Cargo.toml, [workspace.package] version (every crate uses version.workspace); crates/registry-casework-breg/src/lib.rs, same_release() and PeerVersionMismatch; crates/registry-evidencectl/src/evidence_binary.rs and source_add.rs, check_public_bregctl(); - crates/registry-breg-client/src/response.rs, deny_unknown_fields; docs/site/src/content/docs/operate/breg-changes.mdx, "Activate the successor"; release/scripts/rehearse-upgrade.py, FORWARD_PATH_FLOOR; release/notes/config-conventions/stack.md, "BREAKING: v0.40.0 does not upgrade v0.39.0 state @@ -61,6 +59,11 @@ reconciliation before that product's apply, and make the listed project and runt in its upgrade step. Rehearse the whole sequence on a restored copy first, as [Run a disaster-recovery drill](../back-up-and-restore/#run-a-disaster-recovery-drill) describes. +The v0.40.0 to v0.41.0 path upgrades the v0.40.0 databases in place. It does not restore support +for state or package forms that v0.40.0 already refused. On native Linux, require glibc 2.34 or +newer. The four product installers start every staged Linux binary before selecting the new +toolset, so a binary that cannot run leaves the installed toolset selected. + 1. **Back up every database.** Take the BReg and Casework `pg_dump`s, and the Scheduling and Messaging ones when they run. Copy those products' packages and runtime files, and keep the previous release's binaries. These backups are the only way back; see [Roll back](#roll-back). @@ -68,75 +71,78 @@ in its upgrade step. Rehearse the whole sequence on a restored copy first, as [Operational limits](../../../configure/evidence-oid4vci/#operational-limits). 3. **Pause and drain Evidence traffic** for every question that reads BReg, or pause the whole instance when you cannot drain one question at a time. Keep the previous Evidence candidate. -4. **Upgrade BReg.** For v0.39.0 to v0.40.0, the new `bregctl` does not upgrade a database the - earlier release wrote: `plan` and `apply` refuse the package the earlier release built as - `apply.package.refused`, naming `package.root`. Finish or cancel active ingestion runs on the - earlier release, and record the run metadata, committed counts, and receipts you need. Make - the project and runtime-file changes the release notes list, rebuild the project with the new - `bregctl test` and `bregctl package --test-receipt FILE --output BUILD`, and apply it to a new - database with `bregctl apply --initial --runtime-config FILE --package BUILD/package`. Nothing - the earlier database held carries over: not records, not spent idempotency keys, and not stored - runs, chunks, or receipts. An earlier checkpoint refuses to resume; import the data again - under a fresh checkpoint, as - [Load a governed entity through an import window](../../breg-data/#load-a-governed-entity-through-an-import-window) - describes. For a later release, make the project and runtime-file changes the release notes list, rebuild the - deployed project with no model change using the new `bregctl test` and `bregctl package - --test-receipt FILE --output BUILD` (a receipt from the earlier release is not accepted), point - `package.root` at `BUILD/package` (and `package.expectedDigest`, when set, at the package - digest it reports, `packageDigest` with `--format json`), check it against the live database with - `bregctl plan --runtime-config FILE --package BUILD/package` naming the same directory, apply - it with `bregctl apply --runtime-config FILE --package BUILD/package`, run `bregctl verify --runtime-config - FILE`, and restart every `breg` process on the new binary; `bregctl status --runtime-config - FILE` confirms what the database activated. A model change follows as its own successor; see - [Activate the successor](../../breg-changes/#activate-the-successor). When an `apply` stops - before it finishes, rerun it with the same `database.roles`: a retry under other roles is - refused as `apply.resume.roles-differ`, naming the roles the activation started with. A new package applied under `database.roles` other than the ones the active activation serves with is refused as `apply.successor.roles-differ` before maintenance; apply the active package under the new roles first, then the new package. A role change, the active package applied under other `database.roles`, cannot be assessed by `bregctl migration reconcile`: when one stops before it finishes, fix the cause and rerun the same apply, which resumes it. Casework reports each BReg source as unavailable from here until step 5 +4. **Upgrade BReg.** A database created by a v0.40.0 apply already has canonical action-revision + provenance and subject access-log storage, so v0.41.0 reads it in place. The `bregctl plan` + command later in this step reads and validates every `taskGrantStatus` entry. An entry v0.40.0 + activated remains valid, but a script that matched `breg.runtime.invalid-binding` for a + malformed entry must now match `breg.runtime.invalid-task-grant-status`. Update Casework + access-log rules for the + `registry-task-status` user agent and alert on `503 service.unavailable` when the status client + is misconfigured or revoked. Rebuild the deployed project with no model change using the new + `bregctl test` and `bregctl package --test-receipt FILE --output BUILD`; a test receipt from + v0.40.0 is not accepted. Point `package.root` at `BUILD/package`, and repin + `package.expectedDigest` when set. Run `bregctl plan --runtime-config FILE --package + BUILD/package`, apply with `bregctl apply --runtime-config FILE --package BUILD/package`, and + run `bregctl verify --runtime-config FILE`. Restart every `breg` process on v0.41.0, then use + `bregctl status --runtime-config FILE` to confirm the active package. A model change follows as + its own successor; see [Activate the successor](../../breg-changes/#activate-the-successor). + When an apply stops, fix the cause and rerun it with the same `database.roles`; changing roles + during recovery is refused. Casework reports each BReg source as unavailable until step 5 finishes. -5. **Upgrade Casework.** Settle pending attempts first, since an upgrade can strand them. When step - 4 changed the `registryRevision` a BReg source serves, check each such source with `caseworkctl - check PROJECT --against-breg-package DIR --source-id ID`, repin it with `caseworkctl source add - BREG_PROJECT --project PROJECT --source-id ID --apply`, package the Casework project again, and - point the runtime file's `package.root` at the new package (and `package.expectedDigest`, when - set, at its digest); see - [Check a BReg source's pinned revision](../../casework/#check-a-breg-sources-pinned-revision). - Stop every earlier `casework` process before the apply: one left running holds the audit - writer lock the new runtime needs, and can strand a source attempt when the apply changes a - source's binding generation. Run `caseworkctl plan --runtime-config FILE` and `caseworkctl apply --runtime-config FILE` with the - new binaries, then start `casework` and run `caseworkctl doctor --runtime-config FILE`; see [Plan, apply, and serve](../../casework/#plan-apply-and-serve). - For v0.39.0 to v0.40.0, the release notes have you apply Casework to a new database. -6. **Upgrade Evidence.** Re-import each BReg source whose export the release notes say changed, - then package a fresh candidate with the new `evidencectl package`, run `evidence check - --runtime-config FILE --require-runtime-dependencies` with the new binary (add - `--without-audit-lock` while the earlier instance still runs), stop the earlier `evidence`, - start the new one, and verify a fresh synthetic assertion. Then start the new `evidence-oid4vci`. -7. **Upgrade Scheduling**, when it runs. Stop the earlier `scheduling` runtime, or keep its - destination bindings until its hook deliveries drain. Unless the release notes have you start - from a new database, run `schedulingctl plan --runtime-config - FILE` and `schedulingctl apply --runtime-config FILE` with the new binary, then start - `scheduling`; `schedulingctl status --runtime-config FILE` confirms what the database activated. - For v0.39.0 to v0.40.0, the new `schedulingctl` does not upgrade a database the earlier release - wrote. Start from a new database, then run `schedulingctl - apply --runtime-config FILE` and `schedulingctl records apply --runtime-config FILE RECORDS` with the - files changed as the release notes list. Nothing the earlier database held carries over, - published windows, holds, and appointments included. -8. **Upgrade Messaging**, when it runs. Stop new submissions, let in-flight senders finish - retrying submissions whose answers they lost, then stop every earlier `messaging` runtime. Give - graceful shutdown time to finish sends already in flight. After every old runtime stops, refresh - the Messaging `pg_dump`; this stopped, pre-apply snapshot includes the old runtime's final sends - and is the rollback backup. For v0.39.0 to v0.40.0, the new binaries refuse the earlier runtime - file and a package the earlier release built: make the project and runtime-file changes the - release notes list, build the package again with the new `messagingctl package PROJECT --output - DIRECTORY`, and point `package.root` at the new directory (and `package.expectedDigest`, when - set, at the digest it reports). The release notes have you run the plan and apply that follow - against a new database, because no schema version rewrites the dispatch job states the earlier - release stored. Run `messagingctl plan --runtime-config FILE`, then `messagingctl - apply --runtime-config FILE` with the new binary. Confirm the activation with `messagingctl status - --runtime-config FILE`, start the new `messaging`, and require `GET /ready` to answer `200` before - you resume submissions. For v0.39.0 to v0.40.0, the new database holds no earlier idempotency - record, so finish this drain before you point callers at the new runtime; a later retry under - an earlier key can send its message twice. -9. **Resume traffic, and upgrade clients.** Roll out every application that embeds a Registry - Stack client at the same release before it calls the upgraded runtimes. +5. **Upgrade Casework.** Settle pending attempts first because an upgrade can strand them. When + step 4 changed a BReg source's `registryRevision`, check and repin that source as + [Check a BReg source's pinned revision](../../casework/#check-a-breg-sources-pinned-revision) + describes. `caseworkctl source add` now derives the generated `casework-reader` profile from the + BReg project's one compiled `principalClaim`; if it refuses mixed claims, align every entity + profile and action grant, including module-contributed grants and a `casework-reader` profile an + earlier `source add` generated, to one claim and repeat the command. Package the Casework + project again, point `package.root` at the package, and repin `package.expectedDigest` when set. + If a development session borrows another project's issuer, replace `principalClaim: sub` in + every Casework access profile with a stable claim such as `registry_principal`, then register + that claim for each client in both projects' `dev-clients.yaml`. Stop every v0.40.0 `casework` + process before the apply. Migration 0022 validates the task-grant tables under an exclusive lock + and installs the deferred-grant window constraints and assignment generation trigger. Run + `caseworkctl plan --runtime-config FILE`, then `caseworkctl apply --runtime-config FILE`; the + removed `casework migrate` and `caseworkctl db` commands are not aliases. Start `casework` and + run `caseworkctl doctor --runtime-config FILE`; see + [Plan, apply, and serve](../../casework/#plan-apply-and-serve). +6. **Upgrade Evidence.** Replace any `evidencectl build` invocation with `evidencectl package`, and + remove `--generate-keys` from `evidencectl init` or `evidencectl new`. Re-import a BReg source + when its export changed, then package a fresh candidate with the new `evidencectl package`. + Run `evidence check --runtime-config FILE --require-runtime-dependencies` with the new binary, + adding `--without-audit-lock` while the v0.40.0 instance still runs. Stop the earlier + `evidence`, start v0.41.0, and verify a fresh synthetic assertion. Then start the new + `evidence-oid4vci`. +7. **Upgrade Scheduling**, when it runs. Add the required top-level `taskGrantStatus` before you + run the v0.41.0 tooling. List the task authorities whenever Scheduling must check current status + or revocation, and when it accepts deferred work. The + `taskGrantStatus: unchecked-final-fifteen-minutes` path checks only remaining lifetime because a + signed token does not identify its original grant mode. It admits any grant with at most 900 + seconds remaining without checking revocation, including the final 900 seconds of a deferred + grant. Use it only when the deployment accepts that stale-authority window. + Run `schedulingctl check --runtime-config FILE`, then stop the v0.40.0 runtime or keep its + destination bindings until hook deliveries drain. Run `schedulingctl plan --runtime-config + FILE` and `schedulingctl apply --runtime-config FILE` against the v0.40.0 database. Start + `scheduling`, then use `schedulingctl status --runtime-config FILE` to confirm the activation. + The removed `scheduling migrate` command and pre-v0.40.0 package and policy refusals provide no + compatibility path; a database activated by v0.40.0 needs no reset. +8. **Upgrade Messaging**, when it runs. Stop new submissions, let in-flight senders finish retrying + submissions whose answers they lost, then stop every v0.40.0 `messaging` runtime. Give graceful + shutdown time to finish sends already in flight. Refresh the `pg_dump` after every earlier + runtime stops, so the rollback backup includes their final sends. Rebuild the package when the + release notes require it, update `package.root`, and repin `package.expectedDigest` when set. + Run `messagingctl plan --runtime-config FILE`, then `messagingctl apply --runtime-config FILE` + against the v0.40.0 database. Confirm the activation with `messagingctl status --runtime-config + FILE`, start v0.41.0, and require `GET /ready` to answer `200` before you resume submissions. +9. **Upgrade clients, then resume traffic.** Move Python applications to Python 3.11 or later and + Node.js applications to Node.js 24.11.0 or later before installing the v0.41.0 client packages. + Update exhaustive Rust matches on the Scheduling or Messaging `ProblemCode` enums for + `ReceiptUnresolved`. Treat `CaseworkTaskAssertionSource` `invalid-credential` as a grant refusal: + request a new approval and stop retrying that credential. In BReg metadata, an unsupported + `requiredCapabilities` value disables only the affected binding and can make selection report + `required-capability`. Handle a valid unknown BReg Problem by its HTTP status and trace ID + without inferring code or extension semantics. Roll out every application that embeds a + Registry Stack client at v0.41.0 before it calls the upgraded runtimes, then resume traffic. {/* Evidence: docs/site/src/content/docs/operate/casework.mdx, "Upgrade Casework and BReg in lock-step" (BReg first, readiness fails in between); @@ -145,34 +151,19 @@ in its upgrade step. Rehearse the whole sequence on a restored copy first, as docs/site/src/content/docs/tutorials/deploy-evidence-from-breg.mdx, "Coordinate a breaking update"; crates/registry-casework/src/store.rs, StoreError::AttemptPending; crates/registry-breg/src/migration.rs, MigrationError::ResumeRolesDiffer; - crates/registry-breg/src/ingestion_store.rs, cancel_run(); - docs/site/src/content/docs/operate/breg-data.mdx, committedItems and the fresh checkpoint path; - crates/registry-bregctl/src/apply_lifecycle.rs, load_active_predecessor_package(); - crates/registry-bregctl/src/lib.rs, PlanSuccessReport, StatusSuccessReport, and - lifecycle_failure() for ApplyLifecycleError::CurrentPackage (apply.package.refused at - package.root); - crates/registry-breg/src/package.rs, RETIRED_PACKAGE_API_VERSION and - PackageError::RetiredApiVersion; - release/notes/config-conventions/stack.md, "BREAKING: v0.40.0 does not upgrade v0.39.0 state - in place" and "Breaking changes outside the program fragments" (the new BReg database holds - no idempotency record and no ingestion run, an earlier checkpoint refuses to resume; the new - Messaging database holds no idempotency record); - release/notes/config-conventions/casework.md, "BREAKING: a clock is tagged by `type`, and its - four values are kebab-case" (apply to a new database); + products/breg/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; + products/casework/CHANGELOG.md, v0.41.0 - 2026-10-13 entries and migration 0022; + products/evidence/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; + products/scheduling/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; + products/messaging/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; docs/site/src/content/docs/operate/messaging.mdx, "Plan, apply, inspect, and serve"; crates/registry-messaging/src/runtime.rs, shutdown_signal() and Listeners::serve_until(); - release/notes/config-conventions/messaging.md, "BREAKING: the runtime file's keys and - apiVersion are renamed" (the earlier runtime file and package are refused, the upgrade order) - and "BREAKING: the dispatch queue's job words are kebab-case" (no schema version rewrites a - stored job state); - crates/registry-messaging/src/config.rs, MESSAGING_RETIRED_API_VERSIONS and - PACKAGE_EXPECTED_DIGEST; crates/registry-messaging-core/src/package.rs, - MESSAGING_PROJECT_FORMAT; crates/registry-messagingctl/src/lib.rs, PackageArgs; release/notes/v0.36.0.md, "Upgrade Scheduling, Relay, and Discovery from v0.35.0" (apply before start, hook drain); - release/notes/config-conventions/scheduling.md, "BREAKING: a database an earlier release - wrote is not read"; crates/registry-scheduling/src/store.rs, retained_policy(); - crates/registry-schedulingctl/src/lib.rs, RecordsApplyArgs; + release/glibc-floor.env, REGISTRY_GLIBC_FLOOR; + crates/registry-breg/install.sh; crates/registry-casework/install.sh; + crates/registry-scheduling/install.sh; crates/registry-evidencectl/install.sh, + staged Linux --version checks; release/scripts/rehearse-upgrade.py rehearses each product alone, not this composition. */} ## Roll back diff --git a/products/breg/CHANGELOG.md b/products/breg/CHANGELOG.md index 29952ff25..4b2f9ced6 100644 --- a/products/breg/CHANGELOG.md +++ b/products/breg/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - BREAKING: the published `registry-stack-client` Python package, which carries the Base Registry Engine client, requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), and its wheels are built diff --git a/products/casework/CHANGELOG.md b/products/casework/CHANGELOG.md index 586803093..84a330431 100644 --- a/products/casework/CHANGELOG.md +++ b/products/casework/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - BREAKING: the published `registry-stack-client` Python package, which carries the Registry Casework client, requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), and its wheels are built diff --git a/products/discovery/CHANGELOG.md b/products/discovery/CHANGELOG.md index 3746053a4..789af4433 100644 --- a/products/discovery/CHANGELOG.md +++ b/products/discovery/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - BREAKING: the published `registry-stack-client` Python package, which carries the Registry Discovery client, requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), and its wheels are built diff --git a/products/evidence/CHANGELOG.md b/products/evidence/CHANGELOG.md index 9eb50e3ad..d539518b1 100644 --- a/products/evidence/CHANGELOG.md +++ b/products/evidence/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - BREAKING: the published `registry-stack-client` Python package, which carries the Evidence client, requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), and its wheels are built against the Python 3.11 diff --git a/products/manifest/CHANGELOG.md b/products/manifest/CHANGELOG.md index 0bfb5d1d3..53f9710f7 100644 --- a/products/manifest/CHANGELOG.md +++ b/products/manifest/CHANGELOG.md @@ -7,6 +7,10 @@ This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm ## [Unreleased] +## [0.41.0] - 2026-10-13 + +- No user-visible product changes in this release. + ## [0.40.0] - 2026-10-11 ### Changed diff --git a/products/manifest/docs/release-notes.md b/products/manifest/docs/release-notes.md index a72cb85f2..84ee130db 100644 --- a/products/manifest/docs/release-notes.md +++ b/products/manifest/docs/release-notes.md @@ -2,6 +2,10 @@ ## Unreleased +## 0.41.0 + +- Registry Manifest has no user-visible changes in this release. + ## 0.40.0 - BREAKING: Registry Manifest reads metadata manifests and profile descriptors diff --git a/products/messaging/CHANGELOG.md b/products/messaging/CHANGELOG.md index 4cb897405..7126a6b2a 100644 --- a/products/messaging/CHANGELOG.md +++ b/products/messaging/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - BREAKING: the published `registry-stack-client` Python package, which carries the Registry Messaging client, requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), and its wheels are built diff --git a/products/platform/CHANGELOG.md b/products/platform/CHANGELOG.md index a08b4d6bb..19e2741a7 100644 --- a/products/platform/CHANGELOG.md +++ b/products/platform/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - `registry-platform-oidc` gains a `task_grant` module holding the exact task-grant status transport the Base Registry Engine and Scheduling share: `TaskGrantStatusEndpoint`, `TaskGrantStatusRegistry` (with an offline diff --git a/products/render/CHANGELOG.md b/products/render/CHANGELOG.md index 8ec55663a..60def6097 100644 --- a/products/render/CHANGELOG.md +++ b/products/render/CHANGELOG.md @@ -2,6 +2,10 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + +- No user-visible product changes in this release. + ## v0.40.0 - 2026-10-11 - Runtime file flags use the help text "Runtime configuration file" and diff --git a/products/scheduling/CHANGELOG.md b/products/scheduling/CHANGELOG.md index 49f0f3402..8cbb59e4f 100644 --- a/products/scheduling/CHANGELOG.md +++ b/products/scheduling/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +## 0.41.0 - 2026-10-13 + - BREAKING: the published `registry-stack-client` Python package, which carries the Registry Scheduling client, requires Python 3.11 or later: its `Requires-Python` is `>=3.11` (was `>=3.10`), and its wheels are built diff --git a/release/manifests/registry-stack-beta-53.yaml b/release/manifests/registry-stack-beta-53.yaml new file mode 100644 index 000000000..e0bf68186 --- /dev/null +++ b/release/manifests/registry-stack-beta-53.yaml @@ -0,0 +1,48 @@ +stack: + release: beta-53 + version: 0.41.0 + source_repo: registrystack/registry-stack + source_tag: v0.41.0 + +artifacts: + registry-manifest: 0.41.0 + evidence: 0.41.0 + evidencectl: 0.41.0 + evidence-oid4vci: 0.41.0 + evidencectl-installer: 0.41.0 + registry-docs: 0.41.0 + discovery: 0.41.0 + discoveryctl: 0.41.0 + breg: 0.41.0 + bregctl: 0.41.0 + breg-mcp: 0.41.0 + breg-review: 0.41.0 + breg-installer: 0.41.0 + casework: 0.41.0 + caseworkctl: 0.41.0 + casework-installer: 0.41.0 + scheduling: 0.41.0 + schedulingctl: 0.41.0 + messaging: 0.41.0 + messagingctl: 0.41.0 + registry-render: 0.41.0 + registry-client-node: 0.41.0 + registry-client-python: 0.41.0 + +identifier_catalog: + path: products/identifiers/generated/catalog.v1.json + sha256: 17aa0bc6c94638e2b51393eac46ed6600c8af8e28c54c394a53154c5d99245d9 + entry_count: 241 + +external: {} + +warnings: + - code: client-runtime-floors + classification: breaking-change + detail: The unified clients require Node.js 24.11.0 or later and Python 3.11 or later. See release/notes/v0.41.0.md. + - code: task-grant-status-required + classification: breaking-change + detail: Scheduling runtime files require taskGrantStatus; BReg validates its entries when reading the file. Casework deferred grants and status failures require the configuration and client handling described in release/notes/v0.41.0.md. + - code: retired-compatibility-paths + classification: breaking-change + detail: Historical BReg state tolerance and Evidence, Casework, and Scheduling compatibility refusals are removed. Valid v0.40.0 state stays readable; command, diagnostic, and Rust API changes are listed in release/notes/v0.41.0.md. diff --git a/release/notes/v0.41.0.md b/release/notes/v0.41.0.md new file mode 100644 index 000000000..c8fcf513f --- /dev/null +++ b/release/notes/v0.41.0.md @@ -0,0 +1,319 @@ +# Registry Stack v0.41.0 + +Registry Stack v0.41.0 is the beta-53 release. It adds deferred Casework task +grants, fresh task-grant status checks in Scheduling, and original-receipt +reads in Scheduling and Messaging. Base Registry Engine clients accept +additive metadata and unknown Problem codes without granting unsupported +authority, and local BReg and Casework tooling agrees on principal claims. +The release also carries a native citizen self-registration and enrollment +acceptance project, lowers the standalone Linux glibc floor to 2.34, and moves +the client runtime floors to Node.js 24.11.0 and Python 3.11. + +## Compatibility and upgrade + +Use matching v0.41.0 runtimes, tools, and clients. This release reads state +v0.40.0 wrote; it does not restore an in-place path from an earlier release. +Back up databases, configuration, packages, keys, and audit streams before +upgrading, and preserve the same audit files. Follow +[upgrade and retire](https://docs.registrystack.org/operate/advanced/upgrade-and-retire/). +No migration tooling for older releases is provided. + +The entries below cover every BREAKING item since v0.40.0 in the +[product changelogs](https://github.com/registrystack/registry-stack/tree/v0.41.0/products). +The shared client floors apply to the BReg, Casework, Discovery, Evidence, +Messaging, and Scheduling namespaces of the unified packages. + +### Client runtime floors and Rust matches + +- BREAKING: `registry-stack-client` requires Python 3.11 or later, replacing + Python 3.10. `Requires-Python` is `>=3.11`, and the wheels use the Python + 3.11 stable ABI, `cp311-abi3`, replacing `cp310-abi3`. Upgrade the application + interpreter before installing the client and update any wheel filename + pinned in installation automation. Evidence development wheels have the + same floor; `editors/configure.py` also requires Python 3.11 or later. +- BREAKING: `@registrystack/client` and its three platform packages require + Node.js 24.11.0 or later, replacing Node.js 22.12.0. Move applications to + Node.js 24 LTS before upgrading the client. `editors/install.sh vscode` + likewise requires Node.js 24 or later to package the extension. +- BREAKING (Rust API): Scheduling and Messaging each add + `ProblemCode::ReceiptUnresolved` to an enum that is not `#[non_exhaustive]`. + Add a `ReceiptUnresolved` arm or a wildcard arm to exhaustive matches on + `registry_scheduling_core::ProblemCode` and + `registry_messaging_core::ProblemCode`, including their client re-exports + and the codes carried by client errors. + +### Task grants and current authority + +- BREAKING: Scheduling refuses a runtime file without top-level + `taskGrantStatus` as `scheduling.runtime.missing-task-grant-status`. + Every v0.40.0 runtime file needs this addition. Configure a list of one to + 32 task authorities, matched by the exact `sourceIssuer` in their grants, + for fresh status before every capacity commitment and idempotent replay. + There is no fallback: inactive, mismatched, unlisted, or incompletely bound + grants answer `403 operation.not-authorized`; an authority or credential + outage answers `503 service.unavailable`. Alternatively, explicitly set + `taskGrantStatus: unchecked-final-fifteen-minutes`. That choice performs no + revocation check and accepts only a grant with at most 900 seconds remaining + when the request enters. It checks remaining time, not the original grant + mode, so it also admits the final 900 seconds of an originally deferred grant + without checking revocation. Select this option only if that stale-authority + window is acceptable; configure authorities when current status is required. + An empty list is refused. See the complete + [Scheduling runtime configuration](https://github.com/registrystack/registry-stack/blob/v0.41.0/products/scheduling/RUNTIME-CONFIG.md). +- BREAKING: BReg treats a 401 or 403 from a task-grant status endpoint as an + outage, answering `503 service.unavailable` instead of + `412 precondition.failed`. A 404 still refuses the grant with + `precondition.failed`. Update alerts for a misconfigured or revoked status + credential and recognize the shared `registry-task-status` user agent in + Casework access logs, replacing `registry-breg-task-status`. The shared + transport bounds an attempt at ten seconds; BReg's five-second outer bound + still ends its check first. +- BREAKING: BReg validates each `taskGrantStatus` entry when reading the + runtime file. Invalid entries report `breg.runtime.invalid-task-grant-status` + at `/taskGrantStatus`, replacing activation-time + `breg.runtime.invalid-binding`. No already activated valid entry needs + editing. Update scripts that match the old diagnostic. `tokenEndpoint` is + typed as a URL; `clientId`, `clientAssertionAudience`, and `caseworkResource` + are external identifiers of 1 to 512 characters without control characters, + and `caseworkResource` is an absolute resource URI. `sourceIssuer` accepts + an absolute URN as well as a URL because the issuer is compared, not fetched. +- BREAKING: the Rust `CaseworkTaskAssertionSource`, also re-exported by the + unified client, classifies a Casework 4xx assertion response other than 408 + and 429 as `TokenError::Invalid`, kind `invalid-credential`, instead of + `unavailable`. This includes expired, revoked, or absent grants even if the + Problem body is malformed. Request a new approval and stop retrying that + credential. Responses 408, 429, and 5xx remain `unavailable`; transport + failures retain their transport kind. Assertion requests are still sent once. + +Casework task templates can opt into `authorizationMode: deferred`, with a +maximum `lifetimeSeconds` of 604800, or seven days. Omitted mode remains +`immediate`, with its 900-second ceiling. Deferred review grants pin the +assignment generation: release, reassignment, queue movement, absence-cover +change, decision, or completion ends the grant; reclaiming the task does not +revive it. Draft changes alone do not end it. Deferred templates cannot carry +Evidence bounds and are refused as `casework.task-template.deferred-evidence`. +Approval still names the template id and version; the preview, grant view, and +clients carry the mode and omit it for immediate grants. + +Apply Casework migration 0022 through `caseworkctl plan` and `caseworkctl apply`. +It replaces the two task-grant expiry constraints, adds the review task's +`assignment_generation` column and its update trigger, and validates three +tables under an exclusive lock without rewriting them. Allow for that lock +when choosing the upgrade window. + +BReg and Scheduling use the shared `TaskGrantStatusConfig` block in +`registry-platform-config` and status transport in `registry-platform-oidc`. +The optional `statusScope` and `statusPath` default to +`casework:grants:status` and `/v1/task-grants/{grantId}/status`. Set them only +for an authority with another scope or route. `statusScope` is one scope token; +`statusPath` starts with `/` and contains exactly one whole `{grantId}` segment. +Direct Rust consumers can map the shared block to `TaskGrantStatusEndpoint` +with `From` and validate its configuration without reading secrets or making +network requests. Product authorization and capacity ownership remain separate. + +### Base Registry Engine historical state + +- BREAKING: revision detail reads and list pages no longer read a revision + journaled under an immediate action's effect identifier. They answer + `503 source.unavailable`, even if the active package still declares that + effect. Only v0.38.0 and earlier wrote this provenance; subsequent releases + journal the entity's canonical operation identifier, such as + `records.person.create`. A database a v0.40.0 apply created needs no action. + Earlier revision rows are not read in place: apply to a new database, as + v0.40.0 already required. +- BREAKING: startup no longer verifies or serves a database without subject + access-log storage. Every apply from v0.38.0 onward installs that storage + whether or not the package declares `accessLog`, so a database v0.40.0 + created needs no action. Refusal occurs before listener binding and writes + nothing. Separate-role deployments report missing runtime-role grants; + single-role deployments report that the database is not ready for the + package. A database last applied before v0.38.0 requires a new database, + as v0.40.0 already required. + +### Retired command and compatibility paths + +- BREAKING: `evidencectl build` is now an unknown command, reported as + `evidencectl.usage` with exit 2 rather than `evidence.build.retired` with + exit 1. Replace it with `evidencectl package PROJECT --target TARGET + --output OUTPUT`. `evidencectl init` and `evidencectl new` also refuse + `--generate-keys` as a usage error. Remove the flag; it previously did + nothing, and local projects still generate their disposable keys. +- BREAKING: `casework migrate` and `caseworkctl db` are unknown subcommands + with exit 2 and no dedicated replacement sentence. JSON automation sees + `usage.invalid` instead of `usage.removed-command`. Use + `caseworkctl plan --runtime-config FILE` followed by + `caseworkctl apply --runtime-config FILE`. +- BREAKING: Casework removes `casework.package.retired-manifest`. A package + containing `casework.package.json` reports `casework.package.invalid` + when that file is unlisted, or `casework.package.unexpected-contents` when + `SHA256SUMS` lists it. An incorrect `package.expectedDigest` is reported + first as `casework.package.digest-mismatch`. Rebuild affected packages with + `caseworkctl package`. v0.40.0 already refused these retired packages. +- BREAKING: `caseworkctl dev` refuses to remove an unlabeled database volume, + even when the session's own container mounts it. Every v0.40.0 session labels + its volume, so those sessions need no change. If retaining an older unlabeled + `casework-dev-` volume, inspect and back up its contents before + removing it yourself with `docker volume rm`; removal destroys its data. +- BREAKING: the Casework BReg source adapter refuses a stored discovery cursor + that is a bare continuation without its request entity. Every cursor + v0.40.0 stored names that entity, so a v0.40.0 database needs no action. +- BREAKING: Scheduling removes three dedicated historical refusals. No input + v0.40.0 wrote or accepted is affected, and those older inputs remain refused: + - `scheduling migrate` is an unknown subcommand with exit 2. Activate with + `schedulingctl plan --runtime-config FILE` and + `schedulingctl apply --runtime-config FILE`; start with `scheduling serve`. + - A retired `scheduling.package.json` reports `scheduling.package.invalid` + at `/package/root` when unlisted, or + `scheduling.package.unexpected-contents` when listed in `SHA256SUMS`, + replacing `scheduling.package.retired-manifest`. Digest mismatch is still + checked first. Rebuild with `schedulingctl package`. + - A retained pre-v0.40 policy whose identity is under `scheduling` instead + of `project` reports `schedulingctl.store-unavailable`, exit 3, replacing + `schedulingctl.activation.earlier-release`. Start with a new database, + run `schedulingctl apply --runtime-config FILE`, then + `schedulingctl records apply --runtime-config FILE RECORDS`. + Direct Rust consumers must remove uses of `RuntimeError::RemovedCommand`, + `RuntimeError::exit_code`, `runtime::removed_command_refusal`, + `RuntimeConfigError::RetiredPackageManifest`, + `config::RETIRED_PACKAGE_MANIFEST_FILE`, and `StoreError::EarlierRelease`. + `schedulingctl plan` performs its read-only publication check only when no + schema version is pending; a v0.40.0-activated database has none pending. + +### Local BReg and Casework workflows + +- BREAKING: five `caseworkctl dev` configuration refusals now exit 1 instead + of 3 and report their own codes instead of `caseworkctl.operational-failure`: + `caseworkctl.dev.integrations-invalid`, + `caseworkctl.dev.shared-client-mismatch`, + `caseworkctl.dev.shared-task-authority-mismatch`, + `caseworkctl.dev.source-binding-invalid`, and + `caseworkctl.dev.borrowed-principal-invalid`. Update automation to inspect + exit 1 and the specific code. These configurations already failed before. +- BREAKING: a Casework development session borrowing another project's issuer + refuses a Casework access profile with `principalClaim: sub` as + `caseworkctl.dev.borrowed-principal-invalid`. In that session, `sub` is the + issuer owner's subject rather than the Casework principal. Use a stable + claim such as `registry_principal` in every Casework access profile and + register it for each client in both projects' `dev-clients.yaml`. + +`caseworkctl source add` now derives the generated `casework-reader` profile's +principal claim through same-version `bregctl explain access`, preserves exact +`testBindings` variants, and infers only a default service client as executor. +For a BReg project using `sub`, its generated reader relies on the issuer's +verified subject. Align an earlier generated `casework-reader` profile and every +entity profile and action grant, including module contributions, to one +`principalClaim`, then repeat `source add`. Mixed principal claims are refused +before files are written. The local human reviewer bridge still uses +`registry_principal`. Equivalent review endpoint spellings, including trailing +slashes, retain their authored form when they resolve to the same API. + +`bregctl dev` writes the compiled project's one principal claim into +`authentication.authorityClaims.principal` and includes +`authentication.authorityClaims.purpose: registry_purpose` only if a profile +requires purpose. Projects with no authenticated grant retain +`registry_principal`. It refuses incompatible claim mappings before retaining +first-start state. Use one principal claim that is neither `scope` nor the +purpose claim. Operated runtimes continue to configure these claims explicitly. +Local fixtures under a `sub` profile may use +`claims: {principal: "$localClientSubject"}` in their captured journey. +Local client files can also declare up to eight `taskGrantStatus` services and +machine-client grants for up to seven other audiences without expanding BReg +admission. + +## Original receipts and client compatibility + +Scheduling's `POST /v1/appointments/receipt` and Messaging's +`POST /v1/messages/receipt` recover the retained original success receipt using +the original `Idempotency-Key`, request body, and verified caller identity under +current ordinary read authority. They never repeat the mutation or claim +capacity. Scheduling can observe the outcome after the task grant ends; +Messaging neither spends nor requires the submission rate budget and never +answers 429 on this route. A missing, expired, changed, or refused receipt +answers `409 receipt.unresolved`, which does not prove that no effect occurred. +Rust, Node.js, and Python clients expose `appointment_receipt`, +`appointmentReceipt`, `message_receipt`, and `messageReceipt` in their language's +convention. Continue recovery before attempting a distinct write. + +BReg Rust, Node.js, and Python clients ignore unknown object members after +duplicate checks, retain strict checks for known fields, and disable only +bindings whose required capabilities they do not understand. Unsupported +statistical datasets, descriptive change-request capabilities, selectors, and +spatial capabilities are omitted individually; an unknown temporal mode keeps +its served descriptor because null already means non-temporal. Tombstone, +batch, and lifecycle selection can report `required-capability` instead of +`contract-mismatch`. Valid unknown Problem codes retain HTTP status and trace +ID without inferred code or extension semantics; malformed envelopes remain +protocol errors. Fixed actions also accept omitted optional reference inputs +on create and patch while still checking supplied references and required +inputs. + +## Linux installation and build tooling + +Standalone Linux binaries now require glibc 2.34 or later, lowered from 2.35, +for the RHEL 9 family and Amazon Linux 2023. Both Linux architectures use the +same Zig floor selection and independent ELF-symbol check. Native Node.js and +Python client artifacts keep their separate glibc 2.17 contract; the standalone +floor does not change that contract. + +The BReg, Casework, Scheduling, and Evidence installers start every staged Linux +binary with `--version` before selecting the new toolset. If any binary cannot +start, installation refuses that release and keeps the earlier toolset selected. +This also catches an installer asked to install an older release whose binaries +require a newer glibc than the host supplies. + +Workflow `actions/setup-go` steps install Go 1.27.2, replacing 1.24.4, for +AWS-LC-FIPS source builds. Go is a build tool, not a shipped runtime or adopter +prerequisite. The canonical +Linux builder still installs its snapshot-pinned Debian Go package; this release +does not change that recipe. Linux arm64 builds now select the same hash-pinned +Zig toolchain and glibc floor on Ubuntu 24.04 as the canonical amd64 build. + +BReg, Casework, and Messaging local development pull digest-identical PostgreSQL images +from `public.ecr.aws/docker/library/postgres`. Messaging also pulls Mailpit +from `ghcr.io/axllent/mailpit`. Update development egress allowlists for +`public.ecr.aws` and, for Messaging, `ghcr.io`. Retained BReg and Casework +containers using the earlier Docker Hub reference at the same digest remain +accepted; PostGIS sessions still use `postgis/postgis` on Docker Hub. + +## Acceptance projects and release operation + +The citizen self-registration acceptance project combines native ThunderID SMS +signup, account-owned applications, Casework review, and transactional Person +creation, account linking, and program enrollment through configured BReg +actions. It is an adopter proof using the products' existing boundaries, not a +built-in business model or a new runtime product. + +Publication now refuses to create the numbered tag until `registrystack-id` +main pins the exact release source and identifier catalog SHA-256. The release +still rebuilds its own candidate; nightly builds do not substitute for it. +The predecessor-state rehearsal covers BReg, Casework, Evidence, and Messaging +from v0.40.0. Scheduling state remains outside that rehearsal. + +Solmara Lab adaptation to the breaking changes is deferred. The approved 1.0 +stability promise is unchanged and does not take effect in this pre-1.0 release. + +## Security review notes + +The product-owned review notes cover fresh authority checks, deferred grant +invalidation, original receipt disclosure, principal mapping, and historical +state refusal: + +- [BReg](https://github.com/registrystack/registry-stack/blob/v0.41.0/products/breg/SECURITY-REVIEW-NOTES.md) +- [Casework](https://github.com/registrystack/registry-stack/blob/v0.41.0/products/casework/SECURITY-REVIEW-NOTES.md) +- [Scheduling](https://github.com/registrystack/registry-stack/blob/v0.41.0/products/scheduling/SECURITY-REVIEW-NOTES.md) +- [Messaging](https://github.com/registrystack/registry-stack/blob/v0.41.0/products/messaging/SECURITY-REVIEW-NOTES.md) + +The dependency policy also records the unsafe-libyaml advisory in the pinned +Typst tree with its scoped review triggers. Release image advisory exceptions +remain subject to exact-image evidence, their existing expiry, and candidate +enforcement. No advisory bypass is introduced by release preparation. + +## Support + +Security fixes ship in the latest v0.x release. Earlier minor releases receive +no backports, and v0.41.0 has no fixed-duration support window. Release +preparation requires more than six months of remaining upstream support for +pinned LTS dependencies, including compatibility smoke platforms. + +[Changes since v0.40.0](https://github.com/registrystack/registry-stack/compare/v0.40.0...v0.41.0). +This is a pre-1.0 Beta release for self-hosted institutional pilots. From e96e14a8fa6e39679b2575e3898c6e746f37c7bf Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Tue, 13 Oct 2026 06:27:56 +0700 Subject: [PATCH 2/5] docs(release): archive v0.41.0 documentation Signed-off-by: Jeremi Joslin --- docs/site/src/data/archive-lock.yaml | 4 +++ docs/site/src/data/docsets.yaml | 34 +++++++++++++++++++++ docs/site/src/data/repo-docs.yaml | 45 ++++++++++++++++++++++++++++ release/notes/v0.41.0.md | 3 +- 4 files changed, 85 insertions(+), 1 deletion(-) diff --git a/docs/site/src/data/archive-lock.yaml b/docs/site/src/data/archive-lock.yaml index 05e95130e..ce5f69503 100644 --- a/docs/site/src/data/archive-lock.yaml +++ b/docs/site/src/data/archive-lock.yaml @@ -170,3 +170,7 @@ archives: bundle_sha256: b7d14cc48cadffab7f44f70bc8fc822811c70ef171b20ad36e2b46cf990d83a2 root_tree_sha256: b5f17867392d0c9c96866a7f3a76d158a71809be183fa12e2cdbf0278f518891 version_tree_sha256: 4a0bfdd82397e8abd76f710fb07743082a93a4861d43d37bb1345f5fe61f7a7d + v0.41.0: + bundle_sha256: 51bec8689a51e70b568a379d2f14d4a43456b5247d9fabb4369ade5cc9252e36 + root_tree_sha256: 19e0a434138828f2e878209d2c05b4dad9e062388f4490229ca1f1a42dfd6cf6 + version_tree_sha256: ee937df56d0987491744393549db844f15921389e14853e72dbed71d7ca6bf7a diff --git a/docs/site/src/data/docsets.yaml b/docs/site/src/data/docsets.yaml index 0225a9e20..713be0f6c 100644 --- a/docs/site/src/data/docsets.yaml +++ b/docs/site/src/data/docsets.yaml @@ -35,6 +35,40 @@ docsets: registry-breg-services: version: main source (unreleased) ref: HEAD + - id: v0.41.0 + label: v0.41.0 + path: /v/0.41.0/ + status: archived + availability: candidate + source: registry-stack-v0.41.0 + repo_docs_source: monorepo + published_at: 2026-10-13 + description: Registry Stack v0.41.0 beta-53 candidate documentation set. + products: + registry-stack: + version: v0.41.0 + ref: v0.41.0 + registry-manifest: + version: v0.41.0 + ref: v0.41.0 + registry-evidence: + version: v0.41.0 + ref: v0.41.0 + registry-casework: + version: v0.41.0 + ref: v0.41.0 + registry-scheduling: + version: v0.41.0 + ref: v0.41.0 + registry-render: + version: v0.41.0 + ref: v0.41.0 + registry-messaging: + version: v0.41.0 + ref: v0.41.0 + registry-breg-services: + version: v0.41.0 + ref: v0.41.0 - id: v0.40.0 label: v0.40.0 path: /v/0.40.0/ diff --git a/docs/site/src/data/repo-docs.yaml b/docs/site/src/data/repo-docs.yaml index 94dba17ab..c59c612af 100644 --- a/docs/site/src/data/repo-docs.yaml +++ b/docs/site/src/data/repo-docs.yaml @@ -98,6 +98,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ dcat, bregdcat-ap, cpsv-ap, ogc-api-records, shacl, skos, json-schema, json-ld, odrl, sp-dci, w3c-did, prov-o, govstack-digital-registries ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ dcat, bregdcat-ap, cpsv-ap, ogc-api-records, shacl, skos, json-schema, json-ld, odrl, sp-dci, w3c-did, prov-o, govstack-digital-registries ] + last_reviewed: unreviewed description: Operator and integrator documentation for Registry Manifest. - src: products/manifest/docs/validate-and-render.md archive_src: docs/validate-and-render.md @@ -150,6 +153,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ dcat, bregdcat-ap, cpsv-ap, ogc-api-records, shacl, skos, json-schema, json-ld, odrl ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ dcat, bregdcat-ap, cpsv-ap, ogc-api-records, shacl, skos, json-schema, json-ld, odrl ] + last_reviewed: unreviewed - src: products/manifest/docs/profile-fixtures.md archive_src: docs/profile-fixtures.md dest: products/registry-manifest/profile-fixtures @@ -198,6 +204,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ sp-dci ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ sp-dci ] + last_reviewed: unreviewed - src: products/manifest/docs/reference.md archive_src: docs/reference.md dest: products/registry-manifest/reference @@ -249,6 +258,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ dcat, bregdcat-ap, cpsv-ap, ogc-api-records, shacl, skos, json-schema, json-ld, cccev, odrl, w3c-did ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ dcat, bregdcat-ap, cpsv-ap, ogc-api-records, shacl, skos, json-schema, json-ld, cccev, odrl, w3c-did ] + last_reviewed: unreviewed - src: products/manifest/docs/itb-semic-validation.md dest: products/registry-manifest/itb-semic-validation label: ITB and SEMIC validation @@ -297,6 +309,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ dcat, bregdcat-ap, shacl, skos, json-schema, json-ld ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ dcat, bregdcat-ap, shacl, skos, json-schema, json-ld ] + last_reviewed: unreviewed registry-evidence: label: Evidence Gateway remote: https://github.com/registrystack/registry-stack @@ -353,6 +368,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ openapi, json-schema, sd-jwt-vc ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ openapi, json-schema, sd-jwt-vc ] + last_reviewed: unreviewed description: Operator and integrator documentation for Evidence Gateway, the minimum-disclosure assertion service. - src: products/evidence/CONCEPT.md dest: products/registry-evidence/concept @@ -402,6 +420,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ cccev, json-schema, openapi, sd-jwt-vc ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ cccev, json-schema, openapi, sd-jwt-vc ] + last_reviewed: unreviewed description: Approved Version 1 product concept covering the boundary, data model, trust and privacy invariants, native API, and acceptance set. - src: products/evidence/reference/authoring-projects/CONFIG.md dest: products/registry-evidence/authoring-form @@ -451,6 +472,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ json-schema, openapi, sd-jwt-vc ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ json-schema, openapi, sd-jwt-vc ] + last_reviewed: unreviewed description: Complete reference for the editable Evidence authoring project, its validation layers, local key material, and access policies. - src: products/evidence/reference/authoring-projects/SOURCE-EXPORT.md dest: products/registry-evidence/source-exports @@ -500,6 +524,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [] + last_reviewed: unreviewed description: Optional native source import, customized updates, provenance and interrupted transaction recovery. - src: products/evidence/reference/request-adapter/deployment-projects/SOURCE-CREDENTIAL-ROTATION.md dest: products/registry-evidence/source-credential-rotation @@ -549,6 +576,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [] + last_reviewed: unreviewed description: Rotate source credentials with explicit overlap, bounded OAuth caches and verified restart. - src: products/evidence/FIRST-CURL-TEST.md dest: products/registry-evidence/first-curl-test @@ -598,6 +628,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [] + last_reviewed: unreviewed description: Deterministic local curl checkpoint against the Evidence Gateway server with a mock source and an in-memory test JWKS. - src: products/evidence/SOURCE-TESTING.md dest: products/registry-evidence/source-testing @@ -647,6 +680,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ sd-jwt-vc ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ sd-jwt-vc ] + last_reviewed: unreviewed description: Source-testing contract with the deterministic mock matrix, opt-in public demo smoke tests, and credential handling rules. - src: products/evidence/SD-JWT-VC-DEMO.md dest: products/registry-evidence/sd-jwt-vc-demo @@ -696,6 +732,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ sd-jwt-vc ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ sd-jwt-vc ] + last_reviewed: unreviewed description: Deterministic local demo that issues one assertion in both later-verifiable formats and re-verifies the credential offline. - src: products/evidence/OPERATOR-CONTRACT.md dest: products/registry-evidence/operator-contract @@ -745,6 +784,9 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [ openapi, sd-jwt-vc ] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [ openapi, sd-jwt-vc ] + last_reviewed: unreviewed description: Supported deployment shape, requester authority and purpose duties, required configuration and secrets, and readiness, audit, and key obligations. - src: products/evidence/PERFORMANCE.md dest: products/registry-evidence/performance @@ -794,4 +836,7 @@ repos: - docsets: [ v0.40.0 ] standards_referenced: [] last_reviewed: unreviewed + - docsets: [ v0.41.0 ] + standards_referenced: [] + last_reviewed: unreviewed description: Measured baseline of the audit-durability throughput trade and the deferred work that would recover most of the cost. diff --git a/release/notes/v0.41.0.md b/release/notes/v0.41.0.md index c8fcf513f..40bd2d642 100644 --- a/release/notes/v0.41.0.md +++ b/release/notes/v0.41.0.md @@ -142,7 +142,8 @@ network requests. Product authorization and capacity ownership remain separate. with exit 2 and no dedicated replacement sentence. JSON automation sees `usage.invalid` instead of `usage.removed-command`. Use `caseworkctl plan --runtime-config FILE` followed by - `caseworkctl apply --runtime-config FILE`. + `caseworkctl apply --runtime-config FILE`. v0.40.0 already refused both + commands, so no successful v0.40.0 invocation changes. - BREAKING: Casework removes `casework.package.retired-manifest`. A package containing `casework.package.json` reports `casework.package.invalid` when that file is unlisted, or `casework.package.unexpected-contents` when From 16c0217a72832f0e649e4428818286faedd9a29c Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Tue, 13 Oct 2026 07:21:17 +0700 Subject: [PATCH 3/5] docs(scheduling): state the offline grant lifetime check Signed-off-by: Jeremi Joslin --- products/scheduling/CHANGELOG.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/products/scheduling/CHANGELOG.md b/products/scheduling/CHANGELOG.md index 8cbb59e4f..08d735a2c 100644 --- a/products/scheduling/CHANGELOG.md +++ b/products/scheduling/CHANGELOG.md @@ -66,8 +66,9 @@ - BREAKING: a runtime file without `taskGrantStatus` is refused at startup with `scheduling.runtime.missing-task-grant-status`. v0.40.0 had no such member and accepted every unexpired task grant. A Casework immediate grant - never lasts longer than fifteen minutes, so the offline path refuses only a - deferred grant or a longer grant from another authority. After it acquires + never lasts longer than fifteen minutes. The offline path checks remaining + lifetime alone, so it also admits the final 900 seconds of a deferred grant + without checking revocation. After it acquires its locks, the capacity transaction rechecks the execution token's expiry as well as the grant's, on either path. Migration: list the task authorities under `taskGrantStatus`, or write From 7642154d2a3debc0a4baa768dfa788ca9666ac5e Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Tue, 13 Oct 2026 08:10:07 +0700 Subject: [PATCH 4/5] docs(scheduling): pass the project to the upgrade check Signed-off-by: Jeremi Joslin --- .../src/content/docs/operate/advanced/upgrade-and-retire.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx b/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx index 48027e607..c1cedb5d0 100644 --- a/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx +++ b/docs/site/src/content/docs/operate/advanced/upgrade-and-retire.mdx @@ -120,7 +120,7 @@ toolset, so a binary that cannot run leaves the installed toolset selected. signed token does not identify its original grant mode. It admits any grant with at most 900 seconds remaining without checking revocation, including the final 900 seconds of a deferred grant. Use it only when the deployment accepts that stale-authority window. - Run `schedulingctl check --runtime-config FILE`, then stop the v0.40.0 runtime or keep its + Run `schedulingctl check PROJECT --runtime-config FILE`, then stop the v0.40.0 runtime or keep its destination bindings until hook deliveries drain. Run `schedulingctl plan --runtime-config FILE` and `schedulingctl apply --runtime-config FILE` against the v0.40.0 database. Start `scheduling`, then use `schedulingctl status --runtime-config FILE` to confirm the activation. @@ -155,6 +155,7 @@ toolset, so a binary that cannot run leaves the installed toolset selected. products/casework/CHANGELOG.md, v0.41.0 - 2026-10-13 entries and migration 0022; products/evidence/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; products/scheduling/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; + crates/registry-schedulingctl/src/lib.rs, CheckArgs, ActivationArgs, and ApplyArgs; products/messaging/CHANGELOG.md, v0.41.0 - 2026-10-13 entries; docs/site/src/content/docs/operate/messaging.mdx, "Plan, apply, inspect, and serve"; crates/registry-messaging/src/runtime.rs, shutdown_signal() and Listeners::serve_until(); From d2f1df556c1e8cf01dcacc6e4c5abd37e460c31c Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Tue, 13 Oct 2026 08:19:48 +0700 Subject: [PATCH 5/5] docs(release): regenerate the v0.41.0 upgrade archive Signed-off-by: Jeremi Joslin --- docs/site/src/data/archive-lock.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/site/src/data/archive-lock.yaml b/docs/site/src/data/archive-lock.yaml index ce5f69503..a96622199 100644 --- a/docs/site/src/data/archive-lock.yaml +++ b/docs/site/src/data/archive-lock.yaml @@ -171,6 +171,6 @@ archives: root_tree_sha256: b5f17867392d0c9c96866a7f3a76d158a71809be183fa12e2cdbf0278f518891 version_tree_sha256: 4a0bfdd82397e8abd76f710fb07743082a93a4861d43d37bb1345f5fe61f7a7d v0.41.0: - bundle_sha256: 51bec8689a51e70b568a379d2f14d4a43456b5247d9fabb4369ade5cc9252e36 - root_tree_sha256: 19e0a434138828f2e878209d2c05b4dad9e062388f4490229ca1f1a42dfd6cf6 - version_tree_sha256: ee937df56d0987491744393549db844f15921389e14853e72dbed71d7ca6bf7a + bundle_sha256: 4f948c5abe4103dcd268905fde5d17527054f44a9e0616dd847664a53a9d1e54 + root_tree_sha256: f8bc9fc01dd69412b1f37156adb9d076b0ea1d92788d67c4586c691b649d3247 + version_tree_sha256: 63ec510c72629390da1b2eb54726c9b07e76c9330f9d8dbb2dd81222aa22e202