RegistryStack v0.44.0

Registry Stack v0.44.0

Registry Stack v0.44.0 is the beta-56 release. It introduces rstack, a single
public command for a managed local installation, and publishes Registry
Coordinator binaries, installer, and unified Node.js and Python client
namespaces for the first time. Base Registry Engine (BReg) adds event-record
descriptors, a read-only event-record client view, and configurable business
identifiers. Registry Scheduling adds composed bookings and named resource
reservations, and Registry Evidence adds guided fixed-request source authoring.

Compatibility and upgrade

Use matching v0.44.0 runtimes, tools, and clients. Back up each deployment and
follow upgrade and retire.

BREAKING: BReg, Casework, and Scheduling start fresh pre-1.0 database baselines:

• BReg refuses a database that still has the v0.43.0 attachment-verification
  shape. Keep the old database for reconciliation, create a fresh database,
  rebuild the package with the v0.44.0 bregctl test and bregctl package,
  then run bregctl apply --package DIR --initial.
• Casework and Scheduling install schema version 200 and refuse a ledger below
  200 at plan, apply, readiness, and startup. Keep each old database with the
  release that wrote it, create a fresh database, and apply the v0.44.0
  package. Queued Casework completion deliveries and Scheduling holds,
  appointments, and queued intents are not carried forward.
  Also recreate a database made by an unreleased schema-200 Scheduling build;
  its earlier baseline shape is not refused by ledger version alone.

Messaging keeps its version 100 baseline. Run messagingctl apply before
starting the v0.44.0 runtime so migration 101 can replace the dispatch-job
shape while preserving messages, jobs, and spent idempotency keys.

Local command and installation migration

BREAKING for a managed local installation: only rstack is placed on PATH.
Use rstack breg, rstack casework, rstack discovery, rstack evidence,
rstack manifest, rstack messaging, rstack render, rstack scheduling,
and rstack coordinator in place of the corresponding product tool names.
Independently deployed service binaries and images retain their own
entrypoints. See the rstack guide
for the full command mapping and installation procedure.

The release-pinned rstack-v0.44.0-install.sh installs the launcher alone by
default. Select named components or --all at bootstrap, then use
rstack install, uninstall, components list, doctor, and cleanup to
manage them. rstack update --release vX.Y.Z --preview reports an exact update
before activation. The updater refuses downgrades and retains the current
generation if target verification fails. Old invocations hold their generation
until they exit. No database or service rollback is implied.

Authenticate published release material using release verification
before relying on the installer's checksum checks. The component and launcher
assets must match the release manifest on the selected platform. An offline
--asset-dir can supply the same verified assets.

Registry Coordinator first release

Registry Coordinator executes finite reviewed workflows across product API
calls, durable waits, outages, and restarts. Its projects separate generated
contracts, reusable types, pure Functions, exact Operation aliases, and one
Workflow graph. Receiving products retain effect authority and recheck their
conditions when a command arrives.

The new external.command/v1 operation sends one bounded POST to the exact
relative commandPath configured on an external-http connection. The
Coordinator persists the command and request ID before sending, uses that ID as
Idempotency-Key, and requires a pure Function to interpret a validated
provider response. Before any uncertain attempt, a 429 response is treated
as not processed and retried only when another attempt fits the remaining
attempt and deadline budgets; otherwise the run ends without
retry-same. Once an attempt has an unknown effect, a later 429 response
or declared refusal holds the run. A 503 response is retried with its
outcome held as unknown only when another attempt fits both budgets; otherwise
it holds the run immediately. Lost acknowledgements, timeouts, redirects,
other server errors, and unusable responses also hold the run. retry-same
resends the same command with the same ID, so providers must deduplicate on
that ID.

The release ships coordinator, coordinatorctl, their installer, and the
coordinator namespace in @registrystack/client and
registry-stack-client. It does not ship a Coordinator image. Deploy the
runtime from the authenticated binary assets or build it from the release
source.

BReg authoring and operation

BReg record types can declare an eventRecord descriptor over stored fields,
including subject, occurred and effective time, sources, corrections, and
source event identity. Caller-filtered registry metadata exposes the readable
descriptor, and the Rust, Node.js, and Python clients can project it with a
record and its creation revision into a generic read-only event-record view.
Record types and Actions also gain presentation-only purpose and grouping.

Stored string fields can use compiler-configured sequence or random business
identifiers, each with an optional prefix. BReg generates the value inside the
write transaction, rejects callers that supply it, and enforces the declared
uniqueness and immutability rules. Proposal grants can limit writable inputs,
required inputs can be completed at Submit, and Proposal List can select
entries pending manual application.

BREAKING changes for BReg adopters include:

• bregctl explain model, actions, and access advance to v1alpha7;
  proposals advance to v1alpha3, and lifecycle advances to v1alpha8.
  Select the matching schemas in inspection consumers.
• Module valueTypes are scalar-only, matching projects. Replace reusable
  reference, crs84-point, or structured definitions with declarations on
  each field or Action input, refresh module locks, and rebuild the package.
• The 409 idempotency.conflict wire code is now
  idempotency.key-reused. Update code-based error handling.
• Runtime hook configuration moves from eventDestinations to
  destinations.hooks. The operator command is bregctl hook, and hook
  diagnostics, audit schemas, metrics labels, Rust symbols, and client
  verification names replace the sending-side webhook vocabulary. The
  on-wire CloudEvents request and signature and idempotency domains are
  unchanged.
• attachmentStorage and attachmentVerification use url, not
  endpoint. Their attempt timeouts must total at most 55,000 milliseconds
  because one 60-second verification attempt retains five seconds to record
  its outcome.
• Attachment-verification audit readers must accept
  breg-attachment-verification-audit/v3. Hook audit readers must select
  breg-hook-audit/v1 and the breg.hook-delivery event. Keyed references
  written before and after these schema changes do not match.

See the BReg changelog
for the complete diagnostic, hook, attachment-worker, Proposal, package, and
migration changes.

Scheduling and Casework

Scheduling can reserve named resources for exact caller-selected intervals and
admit a composed booking with up to 15 additional allocations in one capacity
transaction. It adds records-managed arrival windows and resource
reservations, source busy import, source-managed assisted booking, operational
appointment reads, attendance observations, and signed purpose-specific
appointment and reminder events. The maintained integration recipes cover
calendar busy import, calendar export, finite series, and operational
reporting.

Casework adds reviewed approval templates for one reviewer, two independent
peers, and a technical check followed by authorization. caseworkctl provider add prepares the matching project from a BReg Action. A non-final stage can
count negative advice without settling the review, and presentation labels are
available for policies, stages, and routing rules. BREAKING:
caseworkctl --format json reports advance to
id.registrystack.org/formats/casework/report/v1alpha2.

Wallet delivery audit

BREAKING: the Evidence OID4VCI wallet delivery runtime requires an audit
block naming a durable journal and a keyed-pseudonym hash key. Store a random
key of at least 32 bytes under an enabled secret provider, reference it from
audit.hashKeyRef, choose destination: file with an absolute path on
durable storage or destination: stdout for a collector, and run
evidence-oid4vci check --runtime-config FILE before cutover. Back up the
journal with its key.
See the Evidence changelog.

Credential status building blocks

This release includes library-only building blocks for the approved credential
status profile. registry-evidence-verifier adds a Token Status List codec and
pure status check, and registry-evidence adds a status ledger module. The
running Evidence service does not call either module, so v0.44.0 does not enable
runtime credential status or issue credentials with a status claim.

The Evidence OID4VCI adapter now routes exchange state through a store interface,
and the source includes a PostgreSQL backend for that interface. Released
configuration does not select the PostgreSQL backend, so the v0.44.0 adapter
continues to use its in-memory store.

Evidence source authoring and signing

evidencectl source suggest --map-selector generates fixed path, query, and
simple JSON request bindings from declared selector fields. Human explain
output shows the Source-to-Output flow, operations, connections, Functions,
private facts, and bounds. The downloadable source recipe catalogue adds
checksum-covered DHIS2 Tracker and OpenCRVS examples with synthetic fixture
projects.

A normalized target can set
signing.maximumAssertionValiditySeconds from 1 to 31,536,000 seconds. This
lets a target admit a definition with a longer validity, including a seven-day
holder-bound credential. Omitting the setting preserves the 300-second default
and the previous compiled target.

Parameter migration

BREAKING: authored JavaScript and Node client configuration uses
maximumResponseBytes; Rust uses with_maximum_response_bytes, and Python
uses maximum_response_bytes. Replace the shorter maxResponseBytes,
with_max_response_bytes, and max_response_bytes spellings at the affected
call sites. The response bounds retain their existing byte units, defaults,
and ceilings. Node constructors reject unknown keys, null for non-nullable
options, unsafe or fractional integers, and binary input where PEM text is
required for trustedRootCertificates. Python None means omission only for
typed optional parameters.

BREAKING: outbound client attempt and connection timeouts use
attemptTimeoutMilliseconds and connectTimeoutMilliseconds in Node,
attempt_timeout_seconds and connect_timeout_seconds in Python, and
with_attempt_timeout and with_connect_timeout in Rust. Nested token and
exchange configurations use the same attempt name. The same-key retry limit
is maximumMutationRetries, maximum_mutation_retries, or
with_maximum_mutation_retries; it counts additional sends. Existing timeout
budgets, retry defaults, and ceilings stay unchanged. Inbound listener request
timeouts remain a separate runtime setting.

BREAKING: command report encoding uses --format human|json, with human the
default even in a pipe. Product artifact choices and output destinations have
their own flags. In particular, Manifest's --output is an exact destination;
unknown, duplicate, or surplus singleton options fail before writes. Update
scripts that relied on implicit JSON output, old Manifest artifact flags, or
permissive argument parsing.

BReg runtime, BReg MCP, and BReg Review accept logLevel values error,
warn, or info. The environment takes precedence over authored
configuration, then info is used. Existing runtime defaults outside these
components are unchanged. HTTP inputs and configuration readers reject the
ambiguous or unknown values covered by their contracts, rather than silently
discarding or merging them.

Run the owning product checks and inspect configuration diagnostics before
cutover. For downstream apps, use a supported client and tool version with
the new parameter spelling; companion repositories that consume these APIs
must be updated with this release.

Render and release boundaries

Registry Render's serving adapter adds shared OpenID Connect resource-token
authentication with the render:render scope. BREAKING: HTTP problem codes
use render.* names in the shared problem envelope. PDF responses expose an
X-Registry-Warning-Count header so a caller can withhold a document that has
render warnings. Render binaries and the transactional installer now cover
Linux amd64, Linux arm64, and macOS arm64.

The bounded Render Rust, Node.js, and Python clients remain held from public
client packages. The default unified packages contain BReg, Casework,
Coordinator, Discovery, Evidence, Messaging, and Scheduling only.

Registry Document Store remains source-only in v0.44.0. The release ships no
documents or documentsctl binary, installer, image, or client package.
Registry Coordinator likewise ships no image in this release.

Other changes

• Product checks can read a reasoned check-acceptances.yaml. An exact
  acceptance keeps its warning visible while excluding that warning from
  --deny-warnings; errors remain refusals.
• Saved API connections reduce repeated product client configuration while
  keeping each resource server's credential and authority boundary separate.
• tools/payment-simulator adds a synthetic G2P and P2G lab test double for
  developing workflows. It binds to loopback by default, requires explicit
  --allow-network to listen on a non-loopback address, and never moves money.
  It is not a released payment rail or runtime artifact.
• Release controls schedule quarterly human review from the collected image
  evidence while every candidate still checks exact image identity, available
  fixes, expiry, and exposure assertions. The Render smoke now uses the
  supported --output option.
• The P-256 dependency stack uses crypto-bigint 0.7.6, addressing
  RUSTSEC-2026-0387.

See the changes since v0.43.0
and the principal changes in
#2356,
#2357,
#2358,
#2442,
#2446,
#2455,
#2456,
#2457,
#2458, and
#2459.