feat(sidecar): protocol 5 — cutover 2b of 7 (edge → main) #35

wtclaude · 2026-09-01T13:45:27Z

wtclaude commented

2026-09-01 13:45:27 +00:00

Engagement Phase 13, step 2 of 7. Merge with servuo-plugins' cutover PR, in the same window.

Merge docs (step 1) first.

What lands (2 commits, 21 lines)

PROTOCOL_VERSION 4 → 5 in sidecar/src/main.rs, and the forwarding for the three v5 enrichments.

The sidecar stays a dumb forwarder — it gains no knowledge of what a decay schedule or a vendor fee means. Access control and the admin-toggleable scope live on the website, which is why a wire enrichment costs a version bump here and nothing else.

What this triggers on merge

release.yml cross-compiles the Linux (x86_64 + aarch64) and Windows binaries and cuts a release, whose final step POSTs a workflow_dispatch at installer's bundle.yml. That composes the new bundle — the exact, protocol-checked sidecar + overlay pair — and commits it to the bundles branch as current.json. servuo-plugins' release does the same, so whichever lands second produces the matched pair.

That bundle is the artefact steps 4 and 7 are waiting on: runicgateway.com's platform.json cannot name bundle.tag / bundle.sidecar / bundle.overlay until it exists.

Why three enrichments in one bump

A protocol bump costs a sidecar release, a republished bundle, and an operator update on every shard. A field left out does not cost a follow-up commit — it costs a second bump with the same three-part lead time, and an operator population split across two protocol versions meanwhile. So everything the engagement workstream is known to need from the wire rides this one.

AI-assisted: written with Claude Code.

**Engagement Phase 13, step 2 of 7.** Merge with `servuo-plugins`' cutover PR, in the same window. **Merge `docs` (step 1) first.** ### What lands (2 commits, 21 lines) `PROTOCOL_VERSION` **4 → 5** in `sidecar/src/main.rs`, and the forwarding for the three v5 enrichments. The sidecar stays a **dumb forwarder** — it gains no knowledge of what a decay schedule or a vendor fee means. Access control and the admin-toggleable scope live on the website, which is why a wire enrichment costs a version bump here and nothing else. ### What this triggers on merge `release.yml` cross-compiles the Linux (x86_64 + aarch64) and Windows binaries and cuts a release, whose final step POSTs a `workflow_dispatch` at `installer`'s `bundle.yml`. That composes the new **bundle** — the exact, protocol-checked sidecar + overlay pair — and commits it to the `bundles` branch as `current.json`. `servuo-plugins`' release does the same, so whichever lands second produces the matched pair. That bundle is the artefact steps 4 and 7 are waiting on: `runicgateway.com`'s `platform.json` cannot name `bundle.tag` / `bundle.sidecar` / `bundle.overlay` until it exists. ### Why three enrichments in one bump A protocol bump costs a sidecar release, a republished bundle, and an operator update on **every** shard. A field left out does not cost a follow-up commit — it costs a *second* bump with the same three-part lead time, and an operator population split across two protocol versions meanwhile. So everything the engagement workstream is known to need from the wire rides this one. - [x] AI-assisted: written with Claude Code.

wtclaude added 2 commits 2026-09-01 13:45:28 +00:00

feat(sidecar): protocol 5

PR Checks / rust-gates (pull_request) Successful in 2m55s

Details

d0c2e7d6e1

PROTOCOL_VERSION 4 -> 5, and nothing else.

That is the whole change, and it is worth saying why. Protocol 5 adds fields to
house.decay and vendor.listing and one new kind, account.login.result — and the
sidecar needs no code for any of it. Every frame is persisted whole, the board
tables index only the columns they already had, and there is no kind allowlist, so
the new fields ride inside the stored JSON and the new kind lands in `events` like
any other.

No store migration this time, unlike v4. v4 needed one because it added a column to
a board table that already existed; nothing here does. A bump that touches one
constant is the EXPECTED cost of an additive protocol version in a dumb forwarder —
the sidecar defines no schema for a frame's contents, so it needs no change when
they grow. v4 was the exception.

The doc comment records the three enrichments and why they were bumped together: a
protocol bump costs a sidecar release, a republished bundle and an operator update
on every shard, so a field left out costs a whole second round of that rather than a
follow-up commit.

Verified against the real shard: GET /health reports "protocol": 5, and all three
enrichments arrived through the generic forward path — the decay schedule (with
estimatedCollapse present only on the IDOC frame), the vendor fee block, and both
outcomes of account.login.result.

cargo fmt --check clean, clippy -D warnings clean, 39 tests passing.

Docs: RunicGateway/docs link/v5.md.

Co-Authored-By: Claude <noreply@anthropic.com>

Merge pull request 'feat(sidecar): protocol 5' (#34 ) from feature/protocol-v5 into edge

PR Checks / rust-gates (pull_request) Successful in 2m16s

Details

f41237392d

Reviewed-on: #34

whitlocktech approved these changes 2026-09-01 13:55:23 +00:00

whitlocktech merged commit 8b9dd0d9e8 into main

2026-09-01 13:55:29 +00:00

whitlocktech referenced this issue from a commit

2026-09-01 13:55:30 +00:00

Merge pull request 'feat(sidecar): protocol 5 — cutover 2b of 7 (`edge` → `main`)' (#35) from edge into main

whitlocktech deleted branch edge

2026-09-01 13:55:31 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/link#35

feat(sidecar): protocol 5 — cutover 2b of 7 (edge → main) #35

What lands (2 commits, 21 lines)

What this triggers on merge

Why three enrichments in one bump

feat(sidecar): protocol 5 — cutover 2b of 7 (`edge` → `main`) #35