feat(sidecar): protocol 5 #34

wtclaude · 2026-09-01T00:21:47Z

wtclaude commented

2026-09-01 00:21:47 +00:00

PROTOCOL_VERSION 4 → 5, and nothing else.

Engagement Phase 10. Design of record: docs#193 → link/v5.md. Companion PRs: servuo-plugins#18, Module-uo#…, docs#193.

Why one line is the whole change

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 (guilds.members); 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, not the rule.

Verified against the real shard

Not just against the tests: the release binary ran the local rig with a real ServUO for the whole of Phase 10's acceptance.

GET /health → "protocol": 5
all three enrichments arrived through the generic forward path and were readable from /history:
- the decay schedule, with estimatedCollapse present only on the IDOC frame
- the vendor fees block
- both outcomes of account.login.result (accepted:false reason:BadPass, then accepted:true)

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

AI-assisted — implemented with Claude Code (Claude Opus 5), verified on the local rig before opening.

🤖 Generated with Claude Code

`PROTOCOL_VERSION` 4 → 5, **and nothing else**. Engagement Phase 10. Design of record: **docs#193 → `link/v5.md`**. Companion PRs: **servuo-plugins#18**, **Module-uo#…**, **docs#193**. ## Why one line is the whole change 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 (`guilds.members`); 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, not the rule.** ## Verified against the real shard Not just against the tests: the release binary ran the local rig with a real ServUO for the whole of Phase 10's acceptance. - `GET /health` → `"protocol": 5` - all three enrichments arrived through the generic forward path and were readable from `/history`: - the decay schedule, with `estimatedCollapse` present only on the IDOC frame - the vendor `fees` block - **both** outcomes of `account.login.result` (`accepted:false reason:BadPass`, then `accepted:true`) `cargo fmt --check` clean, `clippy --all-targets -D warnings` clean, 39 tests passing. --- - [x] AI-assisted — implemented with Claude Code (Claude Opus 5), verified on the local rig before opening. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

wtclaude added 1 commit 2026-09-01 00:21:49 +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>

whitlocktech merged commit f41237392d into edge

2026-09-01 00:27:06 +00:00

whitlocktech deleted branch feature/protocol-v5

2026-09-01 00:27:07 +00:00

whitlocktech referenced this issue from a commit

2026-09-01 00:27:08 +00:00

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/link#34