docs(modules): phase 7 as built — the permission mirror, and the set arithmetic behind it #259

wtclaude · 2026-09-22T03:59:46Z

wtclaude commented

2026-09-22 03:59:46 +00:00

Protocol 4 (PROTOCOL.md §10), phase 7 as built (PLAN.md §20), what an operator needs to know about it (INTEGRATION.md), and the in-game leg as a walk to run (PLAYER_WALK.md).

Code: Rust-Plugins#4, Rust-Link#4, Module-Rust#8.

The spec

One verb carrying the whole desired set, diffed by the plugin against the live store. The report's two interesting fields are the ways a push looks like it worked and did not — unresolved (no loaded plugin registered the name, and the grant API no-ops silently for one) and pending (the store has never seen that player, so there is no record to put in a group). Neither is recorded as pushed, because a site that recorded them would believe it had given a privilege it had not.

Drift is reported and never undone, and the permission hooks are a live signal rather than the record: only the desired set can say whether a change is foreign, so a hook that stops firing on a framework upgrade costs latency, not correctness.

The finding the design turns on, written where it belongs

A name in the store that is not in the desired set is either something the site retired or something a human granted, and those two have opposite correct answers.

The store records who granted a permission nowhere. Only the website can tell them apart, from its own memory of what it pushed — which is why there is a pushed ledger, and why revoking a hand edit needed a table of its own (a foreign grant often names a Steam id no website account holds, so there is no user to author it against and nothing in the ledger to remove).

§10.5 is an old rule generalising

"A wedged sidecar must never stall the game" becomes "nothing the far side sends may cost the main thread an unbounded amount of work", because perm.sync is the first command whose work is not bounded by its own shape. Three bounds, each placed on the side that can say something useful when it is hit — rows at the website, bytes at the sidecar, operations at the plugin.

What is not proven, said plainly

§20.7: the acceptance line needs a second, non-admin Steam account on the rig (§12.5's ceiling, known before the phase started), and nothing in the plugin has been compiled. PLAYER_WALK.md carries the seven steps, including the two things to confirm on Carbon rather than assume — the id(name) entry format (a wrong parse reports every holder as foreign, which is visible immediately) and whether GetGroupPermissions(name, false) compiles there at all.

AI disclosure

This contribution was AI-assisted (Claude Code).

🤖 Generated with Claude Code

https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM

Protocol 4 (`PROTOCOL.md` §10), phase 7 as built (`PLAN.md` §20), what an operator needs to know about it (`INTEGRATION.md`), and the in-game leg as a walk to run (`PLAYER_WALK.md`). Code: Rust-Plugins#4, Rust-Link#4, Module-Rust#8. ## The spec One verb carrying the whole desired set, diffed by the plugin against the live store. The report's two interesting fields are the ways a push **looks like it worked and did not** — `unresolved` (no loaded plugin registered the name, and the grant API no-ops silently for one) and `pending` (the store has never seen that player, so there is no record to put in a group). Neither is recorded as pushed, because a site that recorded them would believe it had given a privilege it had not. Drift is reported and never undone, and the permission hooks are a live **signal** rather than the record: only the desired set can say whether a change is foreign, so a hook that stops firing on a framework upgrade costs latency, not correctness. ## The finding the design turns on, written where it belongs > A name in the store that is not in the desired set is **either** something the site retired **or** something a human granted, and those two have opposite correct answers. The store records who granted a permission nowhere. Only the website can tell them apart, from its own memory of what it pushed — which is why there is a pushed ledger, and why revoking a hand edit needed a table of its own (a foreign grant often names a Steam id no website account holds, so there is no user to author it against and nothing in the ledger to remove). ## §10.5 is an old rule generalising *"A wedged sidecar must never stall the game"* becomes *"nothing the far side sends may cost the main thread an unbounded amount of work"*, because `perm.sync` is the first command whose work is not bounded by its own shape. Three bounds, each placed on the side that can say something useful when it is hit — rows at the website, bytes at the sidecar, operations at the plugin. ## What is not proven, said plainly §20.7: the acceptance line needs a second, non-admin Steam account on the rig (§12.5's ceiling, known before the phase started), and nothing in the plugin has been compiled. `PLAYER_WALK.md` carries the seven steps, including the two things to confirm on Carbon rather than assume — the `id(name)` entry format (a wrong parse reports every holder as foreign, which is visible immediately) and whether `GetGroupPermissions(name, false)` compiles there at all. ## AI disclosure - [x] This contribution was AI-assisted (Claude Code). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM

wtclaude added 1 commit 2026-09-22 03:59:48 +00:00

docs(modules): phase 7 as built — the permission mirror, and the set arithmetic behind it bba2ab04e0

Protocol 4 (`PROTOCOL.md` §10), phase 7 as built (`PLAN.md` §20), what an operator
needs to know about it (`INTEGRATION.md`), and the in-game leg as a walk to run
(`PLAYER_WALK.md`).

**The spec.** One verb carrying the whole desired set, diffed by the plugin
against the live store; a report whose two interesting fields are the ways a push
looks like it worked and did not (`unresolved`, `pending`); drift as a report
rather than an action; and the permission hooks as a live SIGNAL rather than the
record — a hook that stops firing costs latency, not correctness.

**The finding the design turns on, written where it belongs.** A name in the store
that is not in the desired set is either something the site retired or something a
human granted, and those have opposite correct answers. The store records who
granted a permission nowhere, so only the website can tell them apart — which is
why it keeps a ledger of what it pushed, and why revoking a hand edit needed a
table of its own.

**§10.5 is a rule generalising.** "A wedged sidecar must never stall the game"
becomes "nothing the far side sends may cost the main thread unbounded work",
because `perm.sync` is the first command whose work is not bounded by its own
shape. Three bounds, each on the side that can say something useful when it is hit.

**§20.7 says plainly what is not proven**: the acceptance line needs a second,
non-admin Steam account on the rig, and nothing in the plugin has been compiled.
The walk doc carries the seven steps, including the two things to confirm on
Carbon rather than assume.

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

whitlocktech merged commit 132205f0f4 into main

2026-09-22 06:53:09 +00:00

whitlocktech deleted branch docs/rust-phase-7

2026-09-22 06:53:10 +00:00

whitlocktech referenced this issue from a commit

2026-09-22 06:53:10 +00:00

Merge pull request 'docs(modules): phase 7 as built — the permission mirror, and the set arithmetic behind it' (#259) from docs/rust-phase-7 into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#259