Repository navigation
Conversation
… tooling Registry Coordinator runs a reviewed, finite sequence of Registry Stack calls across durable waits, service outages and worker restarts. One optional Rust service executes acyclic YAML workflows with declarative mappings and bounded pure Rhai functions, keeps encrypted progress and prepared commands in its own PostgreSQL database, and leaves the authorization and ownership of every external effect with the product that receives the call. A workflow reads records, waits until an instant, chooses a branch, calls an operation from a closed, versioned catalog and finishes with a declared outcome. Each catalog operation publishes its input and output contracts: check fits every reference, literal and fields mapping to the schemas it reads and feeds, and the runtime refuses a call input outside its contract before dispatch. Calls reach BReg, Messaging and Scheduling through their maintained clients, plus a configured external read and a decision evaluation. Mutations keep their prepared command and original key, retry within the run deadline and honour Retry-After, and recover against the receiving product's original-key receipt where it has one. A deployment serves several flows, one pinned package each, as one trust domain. Runs start only from an authenticated caller request, belong to that caller, and can be listed, inspected, reconciled, retried or cancelled under access policies; operator policies act deployment-wide. The service shares a fixed pool of PostgreSQL sessions, counts runs, attempts and refusals on a private metrics listener, and finishes the attempt in flight before it stops. coordinatorctl initializes projects with passing scenarios, checks and explains them, tests their editor-checked scenarios, packages them, plans and applies deployments, and operates runs, naming the fix for every refusal without echoing values. - crates/registry-coordinator: the coordinator service and coordinatorctl. - products/coordinator: product contract, deployment runbook and checklist, example projects, generated schemas, OpenAPI and operation contracts, and contributor check and test scripts. - Workspace, CI change detection, release source model, identifiers catalog, editor schema mappings, CLI catalog, configuration formats and docs site wiring. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
A casework connection names one review producer and its profile. A run submits a review request through the Casework client, recovers an accepted request under the same idempotency key, and counts a cancel of a request that already ended as done. Both operations carry contracts generated from the review protocol types. A wait-for step then waits for that request's result. Check refuses a request that does not precede the wait on every route, a timeout that is not shorter than the run deadline, and a read of the result on the timeout route, and holds the result to a generated review-result event contract. Casework's completion event reaches the completion receiver, which matches the sender's bearer token and recipient binding in constant time and brings the next result read forward; the event never settles the wait by itself. Every read checks the result against the accepted request before the run continues with it. Without an event, the run reads the result every resultCheckSeconds of its connection while the review is open, and once more at the timeout. A busy or unreachable Casework leaves the wait open: the next read follows Retry-After within its bounds, or waits the five-minute retry ceiling. When no result arrives in time, the run continues at the timeout route. Retention and attested recovery end the wait rows, and the configuration formats classify the omitted metrics bind and assertion issuers as closed. Scenarios can state the review result a wait receives or its timeout. The reviewed-notice example submits an application to review, sends a Messaging notice on approval, finishes differently on rejection, and withdraws the request after fourteen days, routing on the cancel outcome so that a decision recorded just before the withdrawal is kept. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
…e.js and Python bindings
Applications start, list, read, inspect, reconcile, retry and cancel
Coordinator runs through the maintained client instead of hand-built
HTTP. Admission takes a caller-chosen key and {flow, input}; a start's
identity commits to the caller, the flow and the key, and only an
admission whose outcome is unknown is resent, under the same key. The
list, retry-same and cancel routes take no idempotency key, so the client
sends each exactly once and reports an unknown outcome instead of
resending; the list limit and the reason bound are refused before
sending. Operator routes stay with coordinatorctl.
flow-absent on start and run-absent for a run of a flow outside the
caller's policy surface as problems with the outcome known and are never
resent. The status DTOs refuse unknown fields and carry the nullable
failurePath beside failureCode; the DTO contract test compares each
schema's property set with its fixture, so a property the runtime adds
must reach the client in the same change.
The Rust facade exposes the client as registry_stack_client::coordinator;
the napi-rs and PyO3 bindings feed the unified Node.js and Python
packages.
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The Coordinator gate refuses, on the whole forward closure, a runtime that reaches anything but product clients, cores, registry-record, and platform crates, a client that reaches the runtime, and any crate outside the facade and CLI reference tooling that depends on a Coordinator crate. The Casework and Scheduling gates refuse the Coordinator from their side, and root CI runs the gate on every Rust change and builds and tests the Coordinator bindings with the others. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The unified Node.js and Python facades carry the coordinator namespace, and COORDINATOR_CLIENT_FIRST_RELEASE names v0.41.0 as the first release that publishes it, the same way the Scheduling client joins at v0.40.0. The release workflows select the Coordinator bindings from the roster, the assemblers refuse an earlier version unless --include-coordinator asks for local integration, and the client validators refuse a package whose coordinator namespace does not match its version. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Root AGENTS.md describes the Coordinator as explicitly started, finite, reviewed workflows separated by waits that sequence product calls for the caller who started the run, not as the way products connect, and replaces the rule that runtimes may not compose with one that names how they may: only through public product clients under a dependency gate. The Coordinator guide records what it owns, what it never owns, and how to verify a change. CLIENTS.md, the README, DEPLOYMENT.md, PRODUCT-CONTRACT.md and the site configuration reference name the maintained client. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Coordinator refusals now answer as RFC 9457 problem documents, the shape Casework, Messaging, and Scheduling already answer, so a caller handles every Registry Stack product's errors the same way. The runtime holds a closed vocabulary of 40 family.reason codes, each with one status, title, and detail, exported by the problem-catalog example and registered in the identifier catalog under registry-coordinator. Internal error codes map to it at the HTTP boundary only; edge rejections (unknown route, wrong method, oversized or mistyped body, malformed JSON) answer from the same vocabulary, and a missing run and a run the caller may not see both answer run.not-visible. A problem carries type, title, status, detail, code, and traceId, never a submitted value; the former suggestedAction member is dropped, and coordinatorctl keeps its own fix advice. review-completions keeps its 204 and refuses with problems. The OpenAPI document lists the problems each operation can answer. The Rust client accepts a refusal only as an exact problem document whose status, trace, code grammar, and type URI agree, and the Node.js and Python bindings pass its code through unchanged. Security review notes: this changes the refusal surface of every authenticated route. Problems echo no request value, title and detail are fixed per code, 401 keeps WWW-Authenticate: Bearer, every problem keeps cache-control: no-store, and run visibility stays non-oracular: an absent run and another caller's run answer the same document apart from the per-request traceId. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Registry Coordinator joins the release roster at v0.41.0 through COORDINATOR_FIRST_RELEASE, used the way the Messaging constant is. The core shard builds the Linux amd64 coordinator and coordinatorctl, the candidate and rehearsal smoke both and run coordinatorctl init and check, and the coordinator image carries coordinatorctl for the operator commands its deployment runbook runs against the runtime file. Nightlies from that base version record roster profile v2.1, the frozen v2.0 inventory plus Coordinator, so earlier v2.0 manifests stay readable. The image is deny-listed as a public package only. coordinator-candidate and the advisory baseline follow the GHCR bootstrap and a reviewed advisory-evidence rehearsal, as for any new image. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The changelog opens with the runtime, coordinatorctl, problem documents, the unified clients, the Casework review wait, and the release binaries and image. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Add the Coordinator overview, flow authoring, deployment, and API pages, render its committed OpenAPI contract, gate every Coordinator page and shared-page mention to docsets that ship it, and link the existing configuration reference into the new pages. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
…6-finish Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
…ch/pr2029 Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: caeb4afb90
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e75fa02b3e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 171ae4720d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 48d943b036
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 42b60fd0e3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 55772649af
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
This was referenced Oct 15, 2026
Open
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change
Replace BReg's overlapping change-request and lifecycle APIs with one Action contract and a durable Proposal resource. Simplify Casework, Evidence and Coordinator into independently usable products with explicit composition contracts.
Examples
The individual and combined example index links the maintained entry points.
Verification
Current pushed head:
6965700ae483975a0b6678c5c0431555577e34c2, open and ready for review. Full CI passed on this head: 56 successful check contexts and six skipped, including all six required checks. Automatic Codex review completed at 14:12Z without new findings; all 56 assessed inline threads are resolved. GitHub reports the content mergeable and clean. Merging still needs a history/policy decision: this PR contains 264 commits, while the configured rebase merge queue is subject to GitHub's 100-commit rebase limit. No history rewrite, queue operation or policy change has been performed.The latest independently reviewed corrections reuse BReg's canonical UUID check for retained Review request/result identities and validate Coordinator's terminal outcome/output against its status. Completed evidence remains readable during restore review; a real PostgreSQL regression proves the leased-Finish case, recovery refusal, attested release and retention. Finished output may be null or absent. No new configuration, dependencies or runtime recovery behavior is introduced.
Final focused checks pass: 229 BReg client tests, 42 Coordinator client tests and ten Rust facade tests, with scoped strict Clippy and formatting. Rebuilt and freshly installed public packages pass 108 Node and 127 Python runtime tests with no failures or skips. All seven namespace smokes and 83 archive comparisons pass. Six source-only Python methods and unchanged declaration/internal fake-native fixtures are explicitly outside installed runtime coverage. This is local macOS arm64 installation and synthetic loopback proof; PostgreSQL evidence is recorded separately above.
Prior response corrections remain covered: run and step diagnostic pointers preserve valid RFC 6901 text, BReg opaque cursors remain opaque, unavailable attachments carry complete recovery details, and application identities are checked without restricting nil Record IDs or nonnil UUID versions. Coordinator deadlines must follow admission without imposing caller-clock freshness. Malformed responses retain redacted protocol errors and unknown outcome, without automatic resend.
The stale exact-JSON fixture now preserves exact wide-integer reads, proves local no-I/O refusal for an unsupported edit, and uses a representable wide integer for exact edit/recovery. The interrupted S3 test gives only the upload its deliberately short timeout; ordinary verification reads retain their normal budget. Its complete five-test target passes against real PostgreSQL and synthetic loopback S3, preserving staging, unchanged revision and explicit cleanup assertions. The precise hosted timeout cause was inferred from source and logs, rather than reproduced.
Earlier delivered corrections reject definitely oversized canonical Proposal input before dispatch, validate Coordinator inspection wait budgets and refuse Evidence snapshots changed during an ordinary in-place file read. Their independent review, 330 distinct Rust tests and scoped Clippy passed. Runtime schema and authority decisions remain with their owning products.
Previously delivered BReg proof includes 34 Proposal and seven security PostgreSQL tests, catalog tests and source neutrality. Earlier Coordinator proof includes three actual PostgreSQL event tests and both BReg adapter suites.
Earlier integrated verification covers Caseworkctl's 146 tests; Evidence's 44 packaging, 23 authoring and 38 fixture tests; release smoke across all 11 image recipes; immediate Actions, review/application, stale conditions, recovery and product events; BReg, Evidence and Messaging tutorials; operator lifecycle; the 146-test MCP suite and native citizen/review-page journey; VS Code, Zed WASM and both Render golden platforms.
The preceding full CI on
42b60fd0epassed all 56 selected check contexts, with six skipped. That run and earlier component proofs do not replace current-head hosted completion.Scope and limits
This is a breaking replacement for fresh product baselines. Evidence's normalized project and separate target authority start at 0.42.0; the upgrade rehearsal omits or refuses older incompatible inputs. Coordinator remains source-only for distribution.
Deferred work includes broader external clients and samples, older external-demo tutorials, live Evidence source-add validation, event producers beyond BReg, and richer provenance for a future visual editor. Module constraint diagnostics can still point at the merged project rather than the original module leaf. Live Zed GUI execution and published-package installation are not claimed by source builds.
No merge, merge-queue submission, deployment or publication is included.