Treaty v0.0.13

Summary

Treaty v0.0.13 adds card.ready v1 to treaty-event-schemas. This is the event a board sends when a card becomes ready to claim, provided the board has opted into scheduling. It carries the end of the card's placement window. The schema, its catalog entry and example fixtures are included.

The rest of the release moves Treaty onto the suite's shared release workflow. Under it, the tag gate reads forge CI's result for the tag's commit. The packages publish to npm before the relay deploys. If the relay's smoke check fails, the previous release is put back. Every tag also gets release notes on GitHub. Several of the changes since v0.0.12 are re-syncs of that shared workflow and its scripts, and the repo's agent guidance and README were also updated.

The material gives no upgrade steps for operators, so none are listed here. Anyone consuming events should expect to see the new card.ready v1 schema alongside the existing ones.

Highlights

• treaty-event-schemas: card.ready v1, the event a board opted into scheduling sends when a
  card becomes ready to claim, with the end of its placement window.
• Releases run on the suite's shared release workflow: the tag gate reads forge CI's result for
  the tag's commit, the packages publish to npm before the relay deploys, a failed relay smoke
  check puts the previous release back, and every tag gets release notes on GitHub.

Changes

Other

• Adopt the suite's shared release workflow (9ca414c)
• Sync the shared kit (a first release's notes) (ba117ad)
• Re-sync the shared release workflow (c874a72)
• Re-sync the shared release workflow (scripts from the workflow's commit) (4fa3ca0)
• Re-sync (deploy_from_release, estate #139) (03964b5)
• Re-sync (no private names in the synced files) (1bd4aed)
• Re-sync the shared release workflow (bf5237d)
• Card.ready v1 (f4afde6)
• V0.0.13 (a7ea302)

---

Checked at the tag: main's CI result could not be read.
Full diff: v0.0.12...v0.0.13

Treaty v0.0.12

Summary

Treaty v0.0.12 adds schemas for the board-chat events that SuperPipeline pushes, and it tightens how matrix events handle expiry. The changelog names both changes: the new event schemas, and a rule that a subject's expires_at must be a strict RFC 3339 date-time.

The new SuperPipeline schemas cover eight event types: attention pending, check failed, check overridden, decision pulled back, decision released, decision timeout, delivery pending, and gate approval recorded. Each has a version 1 schema, and they are listed in the schema catalog with example fixtures and tests. On the matrix side, the strict date-time check is implemented in the matrix-events package, and the four matrix schemas (AgentPod permission and the SuperPipeline delivery, gate and question events) each received a small edit. The matrix example fixtures were also heavily rewritten.

The material gives no upgrade steps, so I can't name anything operators must do before or after upgrading. Anyone who produces matrix events should check that every subject's expires_at is a strict RFC 3339 date-time, since values in other formats may now be rejected. The material doesn't say how rejection is reported.

Highlights

• treaty-event-schemas: schemas for the board-chat events SuperPipeline pushes.
• treaty-matrix-events: a subject's expires_at must be a strict RFC 3339 date-time.

Changes

Other

• Subject.expires_at is a strict RFC 3339 date-time (e88bdc8)
• The board-chat events SuperPipeline pushes (b69548e)

---

Full diff: v0.0.11...v0.0.12

Treaty v0.0.11

Summary

Treaty v0.0.11 is a small release. The one highlight in the changelog is for the treaty-matrix-events package: board-room names can now be set per carrier.

The change is limited to that package. It touches the board-room code, adds tests, and makes a small update to the package README. Nothing else in the release is described.

The material gives no upgrade steps, so there is nothing an operator is asked to do before or after upgrading. It also doesn't say how the new naming is configured or whether existing board-room names change, so check the updated treaty-matrix-events README for details before relying on it.

Highlights

• treaty-matrix-events: board-room names per carrier.

Changes

Other

• Board-room names per carrier (222d79e)

---

Full diff: v0.0.10...v0.0.11

Treaty v0.0.10

Summary

Treaty v0.0.10 makes the treaty-matrix-events package hold three rules that SuperMessage already enforces. A subject's revision must be a whole number, a decision card must have at least one option, and a permission can carry at most twenty options.

The change touches the matrix event schemas for permission, attention, delivery, gate and question events, along with the package's permission and gate code. It also adds tests and a much larger set of example fixtures, plus a script for generating matrix examples.

The material gives no upgrade steps, so nothing is known to be required before or after upgrading. Anything that produces matrix events should stay within the three rules above, since the package now checks for them. Anyone sending a fractional revision, a decision card with no options, or a permission with more than twenty options will see those events rejected, though the notes do not say exactly how the rejection appears.

Highlights

• treaty-matrix-events holds rules SuperMessage already enforces: a subject's revision is a
  whole number, a decision card has at least one option, and a permission carries at most twenty
  options.

Changes

Other

• A subject's revision is a whole number (18b005c)
• A decision card has at least one option (7defe4e)
• A permission carries at most twenty options (0f59e9c)

---

Full diff: v0.0.9...v0.0.10

Treaty v0.0.9

Summary

Treaty v0.0.9 is a small fix release for the relay. The relay's image now copies every workspace package's manifest, which means the relay builds and deploys again. This is the release that brought the relay in production up to date after v0.0.8.

The change itself is one added line in the relay's Dockerfile, plus a new test script that checks the relay image. Nothing else in the codebase was touched.

The material lists no steps for operators to take before or after upgrading. Users should not notice any change beyond the relay being current again.

Highlights

• The relay's image copies every workspace package's manifest, so the relay builds and deploys
  again. This is the release that brought the relay in production up to date after v0.0.8.

Changes

Other

• The image copies every workspace package's manifest (fbdb0be)

---

Full diff: v0.0.8...v0.0.9

Treaty v0.0.8

Summary

Treaty v0.0.8 adds a new package, @superjackfruitlabs/treaty-matrix-events. It holds the board-room Matrix event contract, which has moved here so that SuperExchange and SuperMessage check the same rules. The packages published for this tag, but the relay's production deploy failed at v0.0.8. The fix is in v0.0.9.

The change is almost all additions: the new package's source and tests, a set of JSON schemas for the Matrix events under schemas/matrix, a schemas README, example and schema-test scripts, and a docs page with the plan for moving the contract. The schemas cover the dev.agentpod and dev.superpipeline event families, such as permission, gate, question, delivery and decision events.

Because of the failed relay deploy, operators should not rely on v0.0.8 for the relay and should move to v0.0.9. The material gives no other upgrade steps. Users will not see anything directly from this release, since it adds a shared contract package rather than a visible feature.

Highlights

• New package @superjackfruitlabs/treaty-matrix-events: the board-room Matrix event contract,
  moved here so SuperExchange and SuperMessage check the same rules.
• The packages published; the relay's production deploy failed at this tag (fixed in v0.0.9).

Changes

Docs

• The plan for moving the Matrix event contract here (SuperExchange step 2) (7a7aa37)

Other

• The board-room Matrix event contract (SuperExchange step 2, plan step 1) (a2531f1)

---

Full diff: v0.0.7...v0.0.8

Treaty v0.0.7

Summary

Treaty v0.0.7 puts the relay into production. The changelog's highlight is that a version tag now deploys the relay, and that a release which fails its health and smoke checks is rolled back, with the previous release put back in its place.

The change is mostly deployment work. It adds a production compose file and a release script, extends the release workflow, and makes small edits to the staging smoke check and sink. The relay's README gains a short section, and a new document lays out the plan for step 7, first real traffic.

The material does not say whether operators have any steps to take before or after upgrading, so check the new production deploy files and the README before tagging. It also does not describe any change that users will notice.

Highlights

• The relay runs in production, deployed by a version tag. A release that fails its health and
  smoke checks puts the release before it back.

Changes

Docs

• The plan for step 7, first real traffic (47edb20)

Other

• The relay in production, deployed by a tag (b041681)

---

Full diff: v0.0.6...v0.0.7

Treaty v0.0.6

Summary

The headline for Treaty v0.0.6 is the relay. It carries events from Workers to NATS JetStream and back, over signed HTTP, and it now runs on staging.

The work is the relay application itself, plus a signature module added to the cloudevents package, which fits the signed HTTP. The release also adds the files to deploy the relay to staging: a compose setup, a deploy script and a smoke-test script. There are new workflow files for CI, release and staging, and a set of unit and NATS tests for the relay.

The material gives no upgrade steps, so I can't name anything an operator must do before or after upgrading. The relay runs on staging, and nothing here says it has been deployed anywhere else. Nothing in this release describes a change that users would see directly.

Highlights

• The relay: carries events from Workers to NATS JetStream and back, over signed HTTP. It runs on
  staging.

Changes

Other

• The relay: Workers to NATS JetStream and back, over signed HTTP (plan step 6)

apps/relay is a Bun service between Workers, which cannot hold a NATS connection, and
JetStream:

• POST /v1/events/ takes an HTTP binary-mode CloudEvent from a producer known by
  its bearer token (stored as a SHA-256), checks the producer may publish to that subject,
  that it is a suite subject and that the event's type names the same product, entity and
  verb, and publishes it to JetStream with Nats-Msg-Id set to the event id.
• Each subscriber gets a durable pull consumer on its filter. Every event is POSTed to it as
  a signed HTTP binary-mode CloudEvent: acknowledged on 2xx, redelivered with backoff on
  408, 429, 5xx or a network failure, dropped and logged on any other 4xx.
• Two streams, WORK (evt.>) and AUDIT (audit.>), with retention from the environment while
  retention is undecided.

treaty-cloudevents gains signDelivery and verifyDelivery (HMAC-SHA256 over t.id.body, Web
Crypto only, so Workers can verify). Sender authentication beyond per-producer tokens and
retention stay open, as the plan says.

30 unit tests cover intake, refusals, delivery outcomes, backoff and config; 8 cover the
signature. Four integration tests need a real nats-server: both CI workflows now download a
pinned, checksum-checked nats-server 2.15.2, start it and run them with
TREATY_REQUIRE_NATS=1, so they cannot skip there. Locally they skip with a note when
NATS_URL is unset.

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017y1PuoCFjP31uXyhLB6Hnr (cc7b286)

• Deploy the relay to the staging plane (plan step 6)

deploy/staging/ runs NATS 2.15.2 with JetStream (data on a volume), the relay on the shared
suite-staging network as relay, and a sink that stands in for a subscribing Worker: it
checks each delivery with verifyDelivery and keeps the ids it accepted. deploy.sh builds the
relay image for the commit, recreates the relay and the sink, and runs the smoke: an event
sent in is stored once, a resend is a duplicate, and the sink receives it once, signed.

.github/workflows/staging.yml deploys each push to main through workbench's forced-command
key, like the other products, and does nothing until STAGING_HOST is set. apps/relay gains a
Dockerfile. A subscriber may now use plain http to a single-label host (a service on the
relay's own network) as well as localhost; https is still required everywhere else.

The secrets, the checkout and the hostname are estate's (provision/310-staging-relay.sh).

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017y1PuoCFjP31uXyhLB6Hnr (fe0858f)

---

Full diff: v0.0.5...v0.0.6

Treaty v0.0.5

Summary

Treaty v0.0.5 adds a new package, @superjackfruitlabs/treaty-outbox. It lets you write events in the same transaction as the change that caused them, and it lets you handle each incoming event once.

The release is almost entirely this one package. It comes with two storage backends, one for Postgres and one for SQLite, along with shared types and tests that cover both. The only other changes are small updates to the README and to the repository's package and lock files so the new package is part of the build.

The material gives no upgrade steps, so nothing is listed that an operator must do before or after upgrading. Because the package is new, existing code is not affected unless you choose to install and use it.

Users will notice the new package and nothing else. If you adopt it, you can record an event alongside the data change that produced it, and the receiving side can process each event a single time.

Highlights

• New package @superjackfruitlabs/treaty-outbox: write events in the same transaction as the
  change that caused them, and handle each incoming event once.

Changes

Other

• Outbox and inbox: write events with their change, handle each once (plan step 5)

@superjackfruitlabs/treaty-outbox, with one adapter for a Durable Object's ctx.storage
(synchronous SQLite) and one for Postgres through any client with query(text, params).

• enqueue writes the event in the caller's transaction, beside the change it records;
  enqueuing the same CloudEvents (source, id) again stores it once.
• drain claims due events under a lease (FOR UPDATE SKIP LOCKED on Postgres), sends them,
  clears the sent ones and backs off failed ones, parking an event after 12 attempts.
  Delivery is at least once.
• handleOnce records (source, id) in one transaction with the handler's writes: a replay is
  a duplicate and changes nothing, and a failed handler leaves no record, so the event is
  handled when it comes again.

The same eight scenarios run on both adapters (bun:sqlite shaped as ctx.storage, and PGlite),
ending with a send repeated after a crash being handled once. Breaking each guard (the
dedupe, the source in the key, the handler's transaction, clearing, parking, backoff, the
enqueue key) fails a test. The package declares the event shape itself rather than depending
on treaty-cloudevents, because npm publish would ship a workspace: dependency verbatim; a
type test checks the two shapes stay the same.

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017y1PuoCFjP31uXyhLB6Hnr (c658e48)

---

Full diff: v0.0.4...v0.0.5

Treaty v0.0.4

Summary

Treaty v0.0.4 adds a new package, @superjackfruitlabs/treaty-event-schemas, which holds the first event schemas. These cover SuperPipeline's gate.pending, elicitation.pending and record events.

The change is mostly the schemas themselves. Each one is a versioned JSON file under schemas/superpipeline, and a catalog file lists them. The release also includes a set of example events for SuperPipeline, a short test for the new package, a test script for the schemas, and a README update.

The material gives no upgrade steps, so there is nothing an operator must do before or after upgrading. Users will see the new package available to install, and nothing else in this release is described as changing for them.

Highlights

• New package @superjackfruitlabs/treaty-event-schemas: the first event schemas, SuperPipeline's
  gate.pending, elicitation.pending and record events.

Changes

Other

• First event schemas: SuperPipeline's gate.pending, elicitation.pending and record events (plan step 4)

JSON Schemas (draft 2020-12) in schemas/superpipeline/, written from SuperPipeline's types:
gate.pending (GatePendingBody, with its subject, variant, quorum, release, checks and deadline
envelopes), elicitation.pending (ElicitationPendingBody, including free-text questions and
broker approval requests) and one record schema for the 15 record events, gate.resolved among
them. Each schema's $id is its address on the public repository, and is the dataschema of
every event that uses it.

schemas/catalog.json names each event's CloudEvents type (two-part names such as
card.comment.added become entity card_comment) and dataschema, and points at SuperWitness's
own run-report schema rather than copying it. Readers ignore unknown properties, so an
optional field needs no new version.

fixtures/superpipeline-events/examples.json holds bodies each schema must accept and refuse,
and scripts/schemas.test.ts checks them, the $ids and the catalogue (every type parses as a
suite type, every dataschema exists). Removing a guard (the variant gate's missing id, a
required boardName, the meaning enum, previewComplete) fails a test.

A new package, @superjackfruitlabs/treaty-event-schemas, ships the schemas for consumers.

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017y1PuoCFjP31uXyhLB6Hnr (ed30dfb)

---

Full diff: v0.0.3...v0.0.4