SuperExchange v0.0.3

Summary

SuperExchange v0.0.3 makes a waiting card say how old it is. If a card is raised an hour or more before it is posted, the head of its summary now says when it was raised and how long before the post that was, for example "Raised 6 Nov, 06:32 UTC, 7 days before this card was posted; what it says is as of then." This appears in the prose and in the card's summary field. A card re-posted for an escalation says it as of that post. The receipt line for a waiting card is now a reply to the card it settles, so any client shows which card it closed. The structured outcome at the card is unchanged.

The rest of the release is groundwork, with no change in behaviour. Lint is now type-aware (oxlint with oxlint-tsgolint) and held by a per-rule ratchet. The architecture test also refuses runtime import cycles and files over 1,000 lines. The store is split into a migrations list, a model and one module per table group, behind the same Store interface. docs/code-quality.md describes the checks. Releases now run on the suite's shared release workflow: the tag gate reads forge CI's result for the tag's commit, and every tag gets release notes on GitHub. This release also adds a landing page for superexchange.dev and a docs site at docs.superexchange.dev, both deployed from the repository.

The material names no steps to take before or after upgrading. Users will notice the age line at the head of late cards and the receipt shown as a reply to the card it closed.

Highlights

• A waiting card raised an hour or more before it is posted says when it was raised and how long
  before the post that was, at the head of its summary ("Raised 6 Nov, 06:32 UTC, 7 days before
  this card was posted; what it says is as of then."), in the prose and in the card's summary
  field. A card re-posted for an escalation says it as of that post.
• A waiting card's receipt line is a reply to the card it settles, so any client shows which card
  it closed. The structured outcome at the card is unchanged.
• No change in behaviour. Lint is type-aware (oxlint with oxlint-tsgolint) and held by a
  per-rule ratchet; the architecture test also refuses runtime import cycles and files over
  1,000 lines; the store is split into a migrations list, a model and one module per table
  group, behind the same Store interface. docs/code-quality.md describes the checks.
• Releases run on the suite's shared release workflow: the tag gate reads forge CI's result for
  the tag's commit, and every tag gets release notes on GitHub.

Changes

Docs

• The code-quality page, AGENTS.md and an Unreleased entry (517e133)
• Docs.superexchange.dev, a Starlight site written from the code (bdbe3a3)

Tests

• Characterize the whole store before it is split (690a1e9)
• Read a reply's target without a type assertion (06ae273)

Chores

• A landing-only change skips the service's checks and the staging deploy (e7d6fa1)

Other

• Adopt the suite's shared release workflow (f67b92e)
• Sync the shared kit (a first release's notes) (3e24626)
• Re-sync the shared release workflow (71d5726)
• Re-sync the shared release workflow (scripts from the workflow's commit) (eb5cfc8)
• Re-sync (deploy_from_release, estate #139) (bc48cca)
• Re-sync (no private names in the synced files) (520d144)
• Re-sync the shared release workflow (4dfb687)
• Type-aware oxlint with a per-rule ratchet (77e335d)
• Runtime import cycles, a file-size ratchet, and a layer order read from the imports (5381c49)
• Split the single file into a migrations list, a model and one module per table group (75c0431)
• Break the gate-card import cycle by moving two pure helpers down (fe4b881)
• Drop assertions that change no type, and write a type import as one (ca5cfec)
• Sync the kit, hooks at fixed paths (6e59f3a)
• Superexchange.dev, the landing page inside the suite frame (c0ce812)
• Deploy superexchange.dev from the GitHub mirror on merge to main (6de9701)
• Commit the vendored frontdoor and vibekit tarballs (c0a1345)
• Deploy the docs beside the landing page; a sites-only change skips the service's checks (63b2529)
• The landing page's llms.txt and README point at the docs (69c2ba6)
• Frontdoor 0.0.14, whose header and footer link the docs site (5e2a9f2)
• README and landing: SuperPipeline v0.0.30 relays the notices and admits the reads

SuperPipeline v0.0.30 relays the seven notice types (push/relay.ts) and
serves deliveries/pending, attention/pending and a card's checks to a
service token under gates:read (service-routes.ts). The README's "does
not yet admit" and "must still" paragraphs, and the landing's two "today"
items, now say what is true: SuperExchange needs v0.0.30 or later, and
what degrades against an older one.

The landing's call to action, run-it link and 404 page link the docs
site instead of the README.

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

• Vibekit 0.0.15, azure read from vibekit (625221a)
• Sync the kit, named secrets by name (8b2a291)
• A waiting card says its age, and its receipt replies to it (bf918a1)
• V0.0.3 (8cfdcaf)

---

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

SuperExchange v0.0.2

Summary

SuperExchange v0.0.2 is the first release to go into production. It carries everything that was listed under v0.0.1, so that earlier list is the place to look for what the product does.

The only change in this release is to the release process itself. The check that a release tag sits on the main branch no longer fetches a second time. That second fetch was refused by a private repository, so the check now works without it. The change touches one workflow file, and nothing else in the code was altered.

The material gives no upgrade steps, so there is nothing an operator is asked to do before or after upgrading. Nothing in it points to a change that users will notice in how SuperExchange behaves.

Highlights

• First release in production: everything listed under v0.0.1.
• The release checks that the tag is on main without fetching again, which a private repository
  refused.

Changes

Other

• Check the tag is on main without a second fetch (01410c1)

---

Full diff: v0.0.1...v0.0.2

SuperExchange v0.0.1

Summary

SuperExchange v0.0.1 is the first release of the Matrix application service for SuperPipeline's board rooms, and it was never deployed: the release stopped at its tag check, and v0.0.2 fixes that. An operator opts a board in, and its gates, questions, approval requests, delivery follow-ups and waiting cards are posted once to the board's room from the event relay. A person answers in the room, and the answer acts at SuperPipeline as that person, with one receipt. Reminders, escalations, quorum progress, held approvals, checks, pull-backs and overrides are each said once, in reply to their card. A periodic sweep settles gates decided elsewhere and posts what the relay missed. Board rooms are end-to-end encrypted, and plaintext rooms are a staging-only switch. The store is SQLite with versioned migrations. A production release snapshots it first and restores it on a rollback that crosses a migration.

Anyone who still sets this up should use v0.0.2. Three settings are required: ORG_PLANE_URL, ORG_PLANE_SERVICE_CREDENTIAL and SUPERPIPELINE_URL. SUPEREXCHANGE_CRYPTO_PASSPHRASE is also required while plaintext rooms are off. SUPEREXCHANGE_PLAINTEXT_ROOMS is off by default and is refused outside staging. SUPEREXCHANGE_SWEEP_SECONDS defaults to 60 and accepts 15 seconds to a day. The store needs a /data volume owned by the service's user, and the image now runs on Bun 1.2.8 on Alpine. The docs also list the reads and scopes SuperPipeline must still allow for the question and follow-up sweeps; check them before turning boards on.

People in a board room will see cards appear and can answer them in place. A person whose Matrix account is linked to nobody is told how to link it, at most once a day per room.

Highlights

Never deployed: the release stopped at its tag check (fixed in v0.0.2).

• SuperExchange, the Matrix application service for SuperPipeline's board rooms: an operator opts
  a board in, and its gates, questions, approval requests, delivery follow-ups and waiting cards
  are posted to the board's room once, from the event relay.
• A person answers in the room, and the answer acts at SuperPipeline as that person, with one
  receipt. Reminders, escalations, quorum progress, held approvals, checks, pull-backs and
  overrides are said once, in reply to their card.
• A periodic sweep settles gates decided elsewhere and posts what the relay missed
  (SUPEREXCHANGE_SWEEP_SECONDS).
• Board rooms are end-to-end encrypted. Plaintext rooms are a staging-only switch.
• A person whose Matrix account is linked to nobody is told how to link it, at most once a day
  per room.
• The store is SQLite with versioned migrations; a production release snapshots it first and
  restores it on a rollback that crosses a migration.

Changes

Docs

• What SuperExchange is, how to run it, and the rules for working here (c9195ba)
• The store layer, the routes and the two new settings (2b670a3)
• Board rooms, the gate card and the staging-only plaintext switch (47bba03)
• A person's answer to a gate card, and the three new settings (063c4e8)
• Board rooms are encrypted, and the new setting (70c113a)
• The gate sweep, its setting, and reminders as an explicit gap (0b2c451)
• The production deploy (43201c0)
• Board questions, approval requests, and the scope the question sweep needs (8c79a66)
• Follow-ups, waiting cards, and the reads SuperPipeline must still admit (f42aae0)
• Board-room notices, pull-backs and overrides, and what SuperPipeline must still allow (6993157)

Chores

• Forge runs the checks and the advisory review (6944576)

Other

• Initial README and licence

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com (29a6aac)

• The service skeleton (60364b0)
• An image, and a staging deploy that stays off until the host is ready (b74eb81)
• Treaty-matrix-events 0.0.10 (d458bf7)
• The data directory, the operator token's hash, and constant-time secret checks (a73da7b)
• SQLite in WAL mode with versioned migrations, a layer below the transport (aaf8140)
• The homeserver's transactions, ping and queries, and an as_token client (64a88be)
• Signed gate.pending deliveries, kept for opted-in boards (0b5125b)
• The operator's board opt-in API, and one dispatcher over every surface (d9075d0)
• A /data volume for the store, owned by the service's user (f43efa9)
• SUPEREXCHANGE_PLAINTEXT_ROOMS, off by default, refused off staging (7869bad)
• Migration 2, board rooms, their members and gate events (faa47de)
• Create rooms, resolve aliases, invite, read members and send as the speaker (7446673)
• Board rooms and the gate card, held until a person joins, posted once (1e9dd54)
• One already-posted check, and prove the prose is sent once (f9fd401)
• ORG_PLANE_URL, ORG_PLANE_SERVICE_CREDENTIAL and SUPERPIPELINE_URL, all required (f8373c8)
• Migration 3, what a gate offered and whether an answer to it has acted (351597d)
• Record what a gate offers with its claim (2a3e708)
• The organization plane and SuperPipeline's gate resolve, as a gate answer needs them (b16d061)
• A person's answer to a gate card resolves it at SuperPipeline, with one receipt (d95d183)
• Prove the board-room, unlinked-sender and one-receipt guards (2fa38a8)
• Migration 4, a room's encryption, the speaker's device and events waiting for their key (784a4ee)
• SUPEREXCHANGE_CRYPTO_PASSPHRASE, required while plaintext rooms are off (9989e30)
• The speaker's end-to-end encryption, its device, keys and transactions' crypto parts (07c92fb)
• Encrypted board rooms, sends that follow the room, answers decrypted or parked until their key (55d5235)
• Wire the speaker's encryption; the image moves to Bun 1.2.8 on Alpine for the binding (b8526eb)
• Migration 5, gates settled by the sweep and deliveries never to be posted (ff36f3f)
• SUPEREXCHANGE_SWEEP_SECONDS, 60 by default, from 15 to a day (9007fc2)
• The gate sweep, settling gates decided elsewhere with one receipt and posting gates the relay missed (a141fb0)
• Start the gate sweep at boot and stop it on shutdown (032e2f7)
• Production compose, release.sh and the v* release workflow (8c4e325)
• Migration 6, board questions delivered, posted with what they offered, and their one receipt (c077783)
• The sweep's schedule and backoff in one place, for more than gates (69a0dc7)
• Board questions and approval requests posted from the relay and the sweep, answered as the person, closed once (c5e08d6)
• Wire board questions, the approval-request rule and the question sweep (7e1b5d8)
• Treaty-matrix-events 0.0.12 (dd048e0)
• Migration 7, delivery follow-ups and waiting cards delivered, posted with what they offered, and their one receipt (801bde1)
• Delivery follow-ups and waiting cards from the relay and the sweeps, answered as the person, settled once (3c0688e)
• Wire follow-up and waiting-card answers, relay intake and their sweeps (39393e1)
• Migration 8, board-room notices recorded and posted once, escalation invites, checks.waiting cards (9eaa8e8)
• Reminders, escalations, quorum progress, held approvals and checks said once in reply to their card; pull-backs and overrides carried as the person (cb0a8f8)
• Wire the notices, escalation invites, pull-backs and overrides, and the notice retry (22dc2b8)
• Tell a person linked to nobody how to link, once a day in a room

An answer to a gate from a Matrix id Accounts cannot place is still dropped, but its sender is
now told why and how to link (SuperMessage: Settings → Account → Link to your Super Jackfruit
account), at most once per person per room per UTC day. The claim is a new link_hints table;
the reply goes under the answer's own reply id, so a redelivered answer says it once.

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

---