An agent's reads are rationed as writes: POST /mcp runs out after twenty-five #68

Verified on the preview at a026541, and the issue's symptom is gone: thirty tools/list in a burst all answer 200, forty concurrent post_event over MCP give 17/23 200/429, a burnt write bucket leaves reads answering 200, POST /api/events after burning the write bucket over /mcp is 429 (one bucket across both doors, as it should be), GET /api/events x60 is never rationed, cross-origin POST is still 403, and the refusal carries retry-after: 1, the exact retry_after_ms, and the full floor (content-security-policy, x-content-type-options, referrer-policy). I also probed the fail-safe: 25 concurrent bogus/thing and 25 concurrent tools/call of an unknown tool both give 20/5 200/429 — they are charged the write bucket. The classification is right, tooManyRequests belongs in src/http.ts, and the split-key reasoning in ration.ts is sound. Three things to fix before it lands.

1 — the fail-safe default has no test (fix this first). isWrite is exported and its doc comment names the load-bearing security property: a malformed message, an unknown method and an unknown tool all default to a write. The new test exercises exactly two branches — tools/list is a read, post_event is a write. Flip either return true in isWrite to false and the suite stays green, while every unrecognized tools/call starts costing a read. That is precisely the hole the issue's Risks section said must not open, and it is the one branch nothing guards. Add to src/server.test.ts, inside the frozen-clock block that already exists:

// An unknown tool and an unknown method are writes: the classification
// only ever narrows what costs more.
const stranger = as("u-mcp-unknown", "stranger", "admin");
for (let i = 0; i < 20; i++)
  expect((await call(stranger, "tools/call", { name: "nope" })).status).toBe(200);
expect((await call(stranger, "tools/call", { name: "nope" })).status).toBe(429);

const odd = as("u-mcp-odd", "odd", "admin");
for (let i = 0; i < 20; i++)
  expect((await call(odd, "bogus/thing")).status).toBe(200);
expect((await call(odd, "bogus/thing")).status).toBe(429);

Both fail today if the default is flipped, and neither needs a sleep.

2 — Route.write is decorative; the READS branch at the door is unreachable. No route declares write: false, and POST /api/events's write: true selects the same bucket the undefined default already selects, so const limit = found?.route.write === false ? READS : PERSON_WRITES always yields PERSON_WRITES. /mcp never reaches it either — the door branches on the pathname first. Delete the field and the ternary and nothing in the app changes and no test goes red, which is the definition of dead code by AGENTS.md's bar. Either drop both and let the door read PERSON_WRITES plainly (the /mcp path is where the real decision lives, and that is fine), or make it load-bearing by giving a POST route that genuinely only reads and a test that shows it on the cheap bucket. Do not leave a new public field on Route that nothing can observe.

3 — the bucket key is chosen by reference equality on the Limit object. take(limit === READS ? \read:${from}\ : from, clock(), limit) holds only while exactly two Limit values ever reach Context.ration. APP_EVENTS already exists in the same module and #8 will want it through this path; the moment it arrives it lands on the bare from key and runs a 100/5 cadence against the very tat PERSON_WRITES is using — the corruption the comment two lines above warns about. Make the key come from the limit rather than from ===: give Limit a name ("writes", "reads", "app") and build ` ${limit.name}:${from} `. One field, one template string, and the trap closes for every limit that ever exists.

Two smaller notes, no need to block on them: the README says /mcp "costs whichever its JSON-RPC method does", but a write there actually costs a read and a write (the door's floor plus the route's charge) — worth the half-sentence, since an agent that has burnt its read bucket cannot post even with twenty write tokens in hand, and that will surprise someone. And resources/list/resources/read sit in READ_METHODS while rpc still answers -32601 for them; harmless and cheap today, but they are the one pair in that set with nothing behind them.

Everything else reads right: identity still comes from the verified signed headers and the key is user:<id> or the socket address, never a header the caller wrote; the same-origin refusal still precedes the ration; the write is charged before rpc runs, so a refused write never reaches an action; readBody's cap is still the only thing between the process and a large body; GET/HEAD stay free. Fix 1, then 2 and 3, and this lands.