chore(release): cut edge over to main — protocols 3–12 and the first release (rust phase 18, D145) #14

Merged

whitlocktech merged 29 commits from edge into main 2026-09-26 00:44:47 -05:00

Conversation 1 Commits 29 Files Changed 6 +9376 -72

wtclaude commented 2026-09-26 00:35:47 -05:00

Member

Copy Link

The cutover D145 put inside phase 18: edge → main, which fires this repo's first release (release.yml, landed in #13).

main is at protocol 2 (phase 3); edge is at protocol 12. 29 commits, nothing on main that edge lacks (fast-forwardable). What reaches main:

• protocol 3 — /link, /unlink (phase 6)
• protocol 4 — the permission mirror (phase 7)
• protocol 5 — config from the site, with the self-undoing reload (phase 7b)
• protocol 6/7 — first-party clans, the raid frame (phase 9/10)
• protocol 8 — the leases (phase 12)
• protocol 9/10 — world verbs, the tally, kit credits (phase 13a/13b)
• protocol 11 — the map (phase 14)
• protocol 12 — BetterChat titles and popups (phase 17)
• phase 18 — RUSTLINK_SERVER_ID read when the default config is written (D150); release.yml; min_carbon_version 2.0.259

What happens on merge

release.yml runs on the push to main. With no prior tag it seeds 0.1.0, re-runs the PR-check gates on the merge commit (hooks listed, hooks void, ProtocolVersion == overlay.toml), stamps [Info] version into the shipped copy, and publishes runicgateway-rust-plugin-<ver>.tar.gz + manifest.json.

⚠ Secrets — please check before merging

The run needs REGISTRY_USER and REGISTRY_TOKEN (write:repository) as repo or org Actions secrets. wtclaude is not an owner and cannot see either list, so I cannot verify them. If they are absent, the credential preflight fails before anything is tagged — no half-published release; add them and re-dispatch release.yml by hand.

Order

Rust-Link's cutover follows this one (§34.2.7). Once both releases exist, installer bundle.yml composes bundles/v2/rust/current.json, and the §34.3 walk runs from that real release.

Part of docs/modules/rust/PLAN.md §34.

• AI-assisted: Claude Code (Claude Opus 5.5)

🤖 Generated with Claude Code

https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

The cutover D145 put inside phase 18: `edge` → `main`, which fires this repo's **first release** (`release.yml`, landed in #13). `main` is at protocol 2 (phase 3); `edge` is at protocol **12**. 29 commits, nothing on `main` that `edge` lacks (fast-forwardable). What reaches `main`: - protocol 3 — `/link`, `/unlink` (phase 6) - protocol 4 — the permission mirror (phase 7) - protocol 5 — config from the site, with the self-undoing reload (phase 7b) - protocol 6/7 — first-party clans, the raid frame (phase 9/10) - protocol 8 — the leases (phase 12) - protocol 9/10 — world verbs, the tally, kit credits (phase 13a/13b) - protocol 11 — the map (phase 14) - protocol 12 — BetterChat titles and popups (phase 17) - phase 18 — `RUSTLINK_SERVER_ID` read when the default config is written (D150); `release.yml`; `min_carbon_version` 2.0.259 ## What happens on merge `release.yml` runs on the push to `main`. With no prior tag it seeds **0.1.0**, re-runs the PR-check gates on the merge commit (hooks listed, hooks void, `ProtocolVersion` == `overlay.toml`), stamps `[Info]` version into the shipped copy, and publishes `runicgateway-rust-plugin-<ver>.tar.gz` + `manifest.json`. ## ⚠ Secrets — please check before merging The run needs **`REGISTRY_USER`** and **`REGISTRY_TOKEN`** (`write:repository`) as repo or org Actions secrets. `wtclaude` is not an owner and cannot see either list, so I cannot verify them. If they are absent, the **credential preflight fails before anything is tagged** — no half-published release; add them and re-dispatch `release.yml` by hand. ## Order Rust-Link's cutover follows this one (§34.2.7). Once both releases exist, installer `bundle.yml` composes `bundles/v2/rust/current.json`, and the §34.3 walk runs from that real release. Part of `docs/modules/rust/PLAN.md` §34. - [x] AI-assisted: Claude Code (Claude Opus 5.5) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

wtclaude added 29 commits 2026-09-26 00:35:49 -05:00

feat(bridge): protocol 3 — /link, /unlink, and the first command the site sends ... 47692e8832

R1's identity flow, in the shape the UO bridge already proved: the player asks
in game, the plugin mints a one-time code and hands it to them, and the website
confirms it back through the sidecar. The site is the author of record; this
plugin holds no link at all.

**`/link` is chat, not console, and the reply is private** (D21). Both frameworks
consume a `/` command rather than broadcasting it and `SendReply` addresses one
player, so neither the request nor the code reaches anybody else — a code read
off a stream is a code somebody else can spend.

**Pending codes live in memory and nowhere else** (D22, matching module-uo): six
characters from an alphabet with no O/0/I/1, five-minute TTL, a thirty-second
cooldown per player, one outstanding code each, and a purge timer because an
unconfirmed code is never looked up. A plugin reload drops them — phase 7b's
config editor will do that routinely — and the cost is typing `/link` again,
which is cheaper than a credential living in a second process.

**The code is deliberately NOT in `account.link.requested`.** That event exists so
an operator can see linking being used; the code travels through the player,
which is what makes typing it proof they are the one who asked.

`/unlink` emits rather than deletes, because there is nothing here to delete. It
is the escape hatch that makes the site's refusal to move an already-linked Steam
id safe: a player who linked the wrong account walks to a computer they are
already sitting at.

`link.confirm` consumes a code on the FIRST lookup whether or not it turns out to
be expired, so a code cannot be probed twice. `unknown` and `expired` stay
separate in the reply — an operator wants to know whether codes are being guessed
or going stale — and the website says the same sentence for both.

`checkPlugin.js` gains a check for the new surface, because a chat command binds
by reflection exactly like a hook and fails the same silent way. It asserts the
signature, the void return and the absence of duplicates, and — like the hook
parser before it — a test reads the real plugin so a regex that matches nothing
cannot pass. Verified by breaking it five ways.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

Merge pull request 'feat(bridge): protocol 3 — /link, /unlink, and the first command the site sends' (#3) from feat/phase-6-identity into edge ... 0a1f7725f1

Reviewed-on: #3

feat(bridge): protocol 4 — the permission mirror, and the first command that writes ... e041089080

R2, the game half. The website is the author of record for groups and grants;
this plugin makes the framework's own permission store match what it is sent.

**One verb, and the plugin does the diffing (D32).** `perm.sync` carries the
whole set the site authors for this server. The plugin compares it against the
live store and writes only what differs, then answers with a report: what it
applied, what was already right, the names it could not resolve, the memberships
waiting on a first connection, and every holder the site did not author.
`perm.catalogue` is the other half — a live read of what the loaded plugins have
registered, which is the option source the authoring form is built from.

**The first command whose work is unbounded, so it is drained rather than run.**
A community with two thousand linked players sends thousands of operations in one
frame, and applying them in the tick the frame arrives is a freeze an operator
will blame on the game. A sync compiles into a list of single-store operations
and drains two hundred at a time on a timer. That is §5's rule — nothing the far
side sends may cost the main thread an unbounded amount of work — applied to the
inbound half for the first time.

**The pre-check §12.2 rule 1 exists for.** `GrantUserPermission` returns void,
throws nothing and logs nothing for a name no plugin registered, so every grant
naming an unloaded plugin's permission would disappear without a trace. The plugin
checks `PermissionExists` first and reports the name as unresolved; it does NOT
register the name itself (D33), because that fabricates a permission the operator
never installed.

**`UserHasPermission` cannot answer the question the diff asks.** It is true for a
member of a group that carries the permission, so a direct grant would look
already applied the moment a group covered it — and a revoke already done.
`GetPermissionUsers` reads the user's own set, which is what a direct grant is.

Six permission hooks join the read path, all void, all in `ExpectedHooks`. They
are not the drift record — only the site's desired set can say whether a change is
foreign — they are a reason to reconcile sooner, and they are suppressed while
this plugin is writing, or every sync would announce itself as drift.

`rg.perms` reports the last report from the console, which is the fastest way to
tell "no plugin registered that name" from "the store has never seen that player".

Protocol bumped to 4 here and in overlay.toml, in the same change as the emitters.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM

Merge pull request 'feat(bridge): protocol 4 — the permission mirror, and the first command that writes' (#4) from feat/phase-7-permissions into edge ... bd8cb24ecf

Reviewed-on: #4

feat(bridge): protocol 5 — configuration from the site, and the reload that undoes itself ... 48eeb56300

R18. Three request/reply verbs — `config.list`, `config.read`, `config.write` —
and the first command on this bridge that writes to the game host's filesystem.

The walk is rooted at `Interface.Oxide.ConfigDirectory`, never a literal, so it
is right on Oxide, on Carbon and on a server whose operator moved it; the data
directory is never walked, because it holds live state and both frameworks'
permission stores, which is protocol 4's mirror one directory over.

A write is resolved, version-checked and parse-checked before the first byte
lands, then backed up, written and reloaded — and the reload is WATCHED. If
`OnPluginLoaded` does not arrive within four seconds the whole set is restored,
reloaded again, and reported with the tail of the newest log file. Without that
this is a web form that takes a required plugin off a production server one typo
at a time.

Four seconds is arithmetic, not taste: the worst path is two windows while a
caller holds the sidecar's ten-second RPC budget.

This plugin will not reload itself — the reload would close the link carrying
the answer — and the site composes the file's bytes, so nothing here has an
opinion about content beyond "it parses".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM

Merge pull request 'feat(bridge): protocol 5 — configuration from the site, and the reload that undoes itself' (#5) from feat/phase-7b-config into edge ... c62c4d7033

Reviewed-on: #5

feat(bridge): protocol 6 — first-party clans, one board and five events ... 568fc873b3

The `clans` board carries every clan the game will list, with its roster
and roles, plus the facts the website needs to trust it: enabled,
backend, supported, truncated, and whether the optional uMod Clans
plugin is loaded. It is re-sent on connect and on the 60-second cadence,
and a few seconds after any membership change. The five events are
clan.created, clan.disbanded, clan.member.added, clan.member.left and
clan.member.kicked.

What the game's assemblies dictated:
- The game has no enumerate-all call. The clan leaderboard is the only
  listing, and the game clamps it to 100 clans. A board at that ceiling
  says `truncated`, as does one that would not fit in 768 KiB (the
  sidecar drops lines over 1 MiB).
- The local backend is synchronous behind ValueTask. A task that has not
  completed means another backend (Nexus), which is refused with a reason
  rather than waited on from the main thread.
- A clan id is not an identity, so every frame carries createdMs.
- OnClanMemberAdded hands over a bare id before the game's cache
  refreshes, so the clan is read back, with a fallback to the id alone.
- uMod Clans raises OnClanDisbanded(string, List<ulong>), which has the
  same name and arity as the game's hook, so the bridge types it exactly.

A member's LastSeen is never sent: it is presence (PLAN.md §23).
overlay.toml moves to protocol 6 and drops Clans from requires_plugins
(D47): Teams come from the game's own clans.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 6 — first-party clans, one board and five events' (#6) from feat/phase-9-clans into edge ... 7096e06257

Reviewed-on: #6

feat(bridge): protocol 7 — a raid frame that names who lives there ... a3899f336f

entity.destroyed now covers doors, external walls and gates, and the
tool cupboard itself as well as building blocks. A door was never a
BuildingBlock, so a door-only raid reached nobody. The frame gains
`structure`, the cupboard's `buildingId`, and `authorized`: each Steam
id on the cupboard with whether they are online now, bounded at 64.
Both fields are absent when there is no cupboard. The structures tally
still counts building blocks only, so the leaderboard column keeps its
meaning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

feat(bridge): clan.disbanded carries the roster it ended ... 272e9e0f65

The website tells a disbanded clan's members, but the clan board that
follows the event (and, after an outage, precedes the backlog) has
already removed that roster from its store. The game walks Members to
drop each membership and never empties the list, so it is still whole
when OnClanDisbanded fires. Part of protocol 7.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

fix(bridge): the raid frame's attackerId comes from userID ... 77e9863e9b

UserIDString is filled in only when a player connects, loads as a
sleeper, or is an engine bot. A player another plugin spawned has none,
and the phase-10 walk's raid arrived with attackerId null. The website
skips the raid alert when the attacker is authorised on the cupboard,
so a null would quietly defeat that exclusion.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 7 — a raid frame that names who lives there' (#7) from feat/phase-10-engagement into edge ... 0be9113d5b

Reviewed-on: #7

feat(bridge): protocol 8 — the leases (PLAN.md §27) ... 594fc09141

lease.list / lease.apply / lease.release and a lease.expired event. The plugin holds the allowlist (decay.scale, 18 populations, the two minimum spawn scalars, and group permissions), the seven-day ceiling (refused, never clamped) and the deadline, which it enforces on its own. Release is compare-and-set. Holds persist in the data directory with their boot: a restart ends a convar hold, while a group-permission hold survives it and is re-armed.

EventsEnabled (default off) gates apply only, and a write from the site's config editor now takes effect at once. The permission mirror defers to a leased pair: it is reported as leased, never foreign.

Grants pass a null owner: with an owner, Oxide silently refuses any permission another plugin registered.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 8 — the leases (phase 12)' (#8) from feat/phase-12-leases into edge ... dcf4e34fee

Reviewed-on: #8

fix(bridge): grant with a null owner and read every grant back (D85) ... c106ba826b

EnsureGrant and EnsureGroupPermission passed `this` as the owner. Given an
owner, Oxide first asks PermissionExists(perm, owner) — whether THAT plugin
registered the name — and returns silently when it did not, so every
site-authored grant of another plugin's permission was a no-op on Oxide that
the report counted as applied (PLAN.md §27.6).

Both now pass null and read the store back. A grant the store does not hold
afterwards is reported in the new `notLanded` list instead of counted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

feat(bridge): protocol 9 — the world verbs events place and give back (phase 13a) ... bbaa7f346e

world.monuments, world.zone, world.place, world.revert and world.owned
(PLAN.md §28, D86-D96):

- Zones through ZoneManager's temporary zones, owned by the bridge, with a
  required duration the plugin enforces itself (D96) and re-created from the
  bridge's own registry on every load and every ZoneManager reload (D92),
  because ZoneManager erases a plugin's zones when that plugin unloads.
- Crates and NPCs from a plugin-held allowlist (D88) at a monument by kind
  and instance, or at raw coordinates (D87, D93), bounded 25/20 per step (D95).
- A registry file keyed by the website's idempotency key, since this bridge
  has no at-most-once store: a repeat answers with the first call's ids.
- world.owned LOOKS by net id: crates survive a restart, NPCs do not, so a
  boot id proves nothing. A wipe drops the registry whole.
- EventsEnabled gates every world write; revert, owned and monuments never
  (D94). Revert refuses only a thing that exists and is not this run's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

fix(bridge): refuse world commands until the world has loaded ... 0a7ad570f7

The link starts in Init, before the save loads. The phase 13a walk restarted
the rig mid-run: the website saw the new boot id at once, asked world.owned
into an empty world, and the plugin — finding no entity behind any net id —
pruned three live crates from its own registry. They stayed in the world,
owned by nothing, and a revert would have refused them.

world.owned, world.revert, world.monuments and every world write now answer
`not-ready` until OnServerInitialized, zones are not re-created before it,
and server.hello carries `worldReady` so the website can hold its reconcile
until the world it would be asking about exists.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 9 — the world verbs, and the phase-7 owner fix (phase 13a)' (#9) from feat/phase-13a-world into edge ... 81e0ab8c06

Reviewed-on: #9

feat(bridge): protocol 10 — the tally, kit credits and chat (phase 13b) ... 3d9998ce64

- tally.open / .snapshot / .close: a run's participation tally, persisted
  in tallies.json. Presence accrues every 5 s from ZoneManager's own
  membership (or the whole server); kills are the last hit, gated by
  killsOf and the killer being inside the area (D98); the score is
  seconds, kills, or minutes + killWeight x kills (D99). Only a zone this
  run opened counts (D100). Gated by EventsEnabled (D107); forgotten
  seven days after opening (D108).
- kits.list: the kit source, from Kits' GetKitNames/GetKitInfo.
- perm.sync `credits`: one extra use of a kit per reward (D103), held in
  credits.json and spent LAST from OnKitRedeemed, because Kits'
  SetPlayerKitUses does nothing for a player with no usage record.
  Withdrawn when unredeemed; reset when Kits wipes its use counts.
- chat.say: one line to the server, remembered by key for 10 minutes.
- EventsMaxRecipients / EventsMaxTallies / EventsMaxChat bounds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 10 — the tally, kit credits and chat (phase 13b)' (#10) from feat/phase-13b-rewards into edge ... d495150944

Reviewed-on: #10

feat(bridge): protocol 11 — the map (phase 14) ... 210c35f904

Four verbs (PLAN.md §30.2), all outside EventsEnabled because none of them
changes the world:

- map.info: the map key, the picture's source (the Rust+ cache, a render
  kept on disk, or none), its size, SHA-256 and slice count, the game's own
  grid, and the monuments the in-game map shows. The cache is read by
  reflection by name only, never enumerated (it holds the Rust+ secret).
  The hash is computed on the thread pool.
- map.fetch: one 512 KiB base64 slice, encoded on the thread pool, refused
  `stale` when the key or hash moved.
- map.render: the admin fallback (D109). Answers `accepted` at once and
  renders on a later frame, keeping the result in data/RunicGateway/map.jpg
  beside its key so a restart within the map does not render again.
- map.live: every layer at once (world events, event-owned zones/crates/NPCs,
  players and sleepers, TCs and player vending machines as positions only).
  The sets are kept by OnEntitySpawned/OnEntityKill and seeded by one sweep
  at OnServerInitialized. MapMaxSleepers/MapMaxBases bound the two layers.

Also fixes Grid() (D119): it used a 146.3 m cell, but the game fits whole
cells to the world (20 x 150 m on a 3000 map), so rows could be one off.
It now asks MapHelper.PositionToString, the in-game map's own labeller.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

fix(bridge): map.live names a player by userID, not UserIDString ... de5f0928bd

The phase 14 walk read `steamId: null` for every sleeper made on the
server: UserIDString is a cached string the game fills for a player it has
seen connect. An id the map cannot name is an own dot and a clan mate the
site can never match, so the map reads the id from userID itself.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

fix(bridge): rg.map re-reads the picture rather than printing the last answer ... ef78da8ce6

The walk emptied the Rust+ cache and rg.map still said `companion`: it
printed the picture the last map.info had seen. It now re-reads while the
world is ready.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 11 — the map (phase 14)' (#11) from feat/phase-14-map into edge ... b5b13161c7

Reviewed-on: #11

feat(bridge): protocol 12 — BetterChat and popups (phase 17) ... 8c6146259e

- titles.set: a whole set of chat titles, swapped in by reference and read
  by a BetterChat third-party title getter (one lookup, no socket). The
  getter is registered at load and again whenever BetterChat loads.
- perm.sync: a group may carry its BetterChat style. Each field is written
  through API_SetGroupField only when the game still holds what the site
  last pushed (or BetterChat's default); anything else is reported as
  drift. One `chat group set` per touched group saves it, because the API
  never does (D143). A retired style removes the group with `chat group
  remove` (D139). The report gains `chat`.
- chat.say: delivery chat|popup and an optional voice format. A popup with
  PopupNotifications absent is refused `popup-unavailable`. Every line said
  is logged, since the game logs neither a broadcast nor a popup.
- server.hello/status carry `integrations`; `rg.titles [steamId]` prints
  what BetterChat would render for a player.
- overlay.toml: protocol 12; PopupNotifications leaves requires_plugins
  (D141).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

fix(bridge): keep the chat titles across a reload (D144) ... 5ff88610a5

The walk found that a hot reload of this plugin emptied every title, and
the site never re-sent them: it re-sends on a new boot id or wipe id, and a
reload is neither, because the boot id names the server process. The set
is now written to titles.json with the wipe it was pushed on, and read at
OnServerInitialized only when that wipe is still the current one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): protocol 12 — BetterChat titles and styles, popups (phase 17)' (#12) from feat/phase-17-integrations into edge ... 78726b89de

Reviewed-on: #12

feat(bridge): server id from the environment, and the first release workflow (phase 18) ... 497b7c4f64

Module-rust phase 18, step 3 of docs/modules/rust/PLAN.md §34.2.7.

The environment seam (D150): when the plugin writes its default config and
RUSTLINK_SERVER_ID holds a valid id (the site's ^[a-z0-9][a-z0-9-]{0,63}$),
the file's ServerId is that value. It is read nowhere else: after that write
the file is canonical and the site's lock applies. An invalid value is logged
and ignored. This is how the egg names a server; not a message change, so the
protocol stays at 12.

The release (D145, §34.2.1): release.yml reuses servuo-plugins' release engine
unchanged (tag-only, secrets preflighted, orphan tags recovered and swept, the
installer's bundle.yml dispatched at the end). The adapter re-runs
checkPlugin.js and packages runicgateway-rust-plugin-<version>.tar.gz with a
framework-neutral layout: RunicGateway.cs, its [Info] version stamped to the
release, and a manifest.json folding in overlay.toml.

overlay.toml gains min_carbon_version = "2.0.259", the build R19 was proven on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Merge pull request 'feat(bridge): server id from the environment, and the first release workflow (phase 18)' (#13) from feat/phase-18-release into edge ... a38be86e8d

Reviewed-on: #13

whitlocktech approved these changes 2026-09-26 00:44:40 -05:00

whitlocktech merged commit 85f21c9c0d into main 2026-09-26 00:44:47 -05:00

whitlocktech deleted branch edge 2026-09-26 00:44:48 -05:00

whitlocktech referenced this issue from a commit 2026-09-26 00:44:48 -05:00

Merge pull request 'chore(release): cut edge over to main — protocols 3–12 and the first release (rust phase 18, D145)' (#14) from edge into main

Sign in to join this conversation.

Reviewers

No Reviewers

whitlocktech

Labels

Clear labels

bug

Something is not working

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

ksfixitman whitlocktech wtclaude

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/Rust-Plugins#14

No description provided.