queen: z.ai lease route for the Mac reviewer, decided by key_vault.t27

[gHashTag]

Why

The owner's rule of 2026-10-18 has two parts. Every API key lives in one store and is shared out among everyone who uses it. The Mac reviewer (tools/bees/reviewer.py in gHashTag/t27) stops running on five private z.ai keys that the Queen cannot see.

gHashTag/t27#10567 adds the rule as a card, specs/queen/key_vault.t27, and points the reviewer at BEE_QUEEN_LEASE_URL / BEE_QUEEN_LEASE_TOKEN. This PR is the route behind that URL.

What

File	Change
specs/queen/key_vault.t27, key_failover.t27, key_vault.wasm, services/queen-key-vault-card.gen.ts	Vendored from gHashTag/t27#10567 (head ae8bcbe6f). The blobs, the build command, the 11 exports and the sha256 of each file are in specs/PIN. The wasm imports nothing, and two builds gave one hash.
routes/queen-lease.ts (+40/-1)	createQueenZaiLeaseRoute(). It answers 503 until TRIOS_QUEEN_REVIEW_LEASE_TOKEN (at least 32 bytes) is set, and 403 to any other bearer (sha256 digests compared with timingSafeEqual). The card's lease_answer decides grant, wait or refuse: the free lanes are the z.ai review lanes that no bee (runningKeys), backoff or lease holds, a review counts as waiting, and total includes the lanes the bees hold. A wait is a 429 whose retry-after comes from retry_after_seconds. The route forwards only content-type and anthropic-version: never the caller's token.
services/queen-free-lane.ts (+40)	vault() is the card's wasm. leased is the keys out on a lease now. zaiLeaseCall() makes the request on https://api.z.ai/api/anthropic with one lane's key and streams the answer back; the lease ends when the stream ends, or after LEASE_SECONDS. When a lane refuses, the card's lease_step hands the request to the next lane, at most LEASE_TRIES lanes, and a wrong request (KE_REQUEST) goes back unretried.
services/queen-reviewer.ts (+10)	zaiLeaseLanes(taken, busy): the z.ai review lanes no bee, backoff or lease holds.
server.ts	Mounts /queen/zai-lease as a server-to-server route, next to /queen/contributor-keys.
tools/route-guard-audit.mjs, tests/api/routes/route-guard.test.ts	An allowlist entry with its reason. Pins: 66 to 67 mounts, 41 to 42 /queen mounts, 10 to 11 allowlisted.

No new hand-written file. Every lease decision is the card's; the TypeScript is I/O around it.

Known imprecision

• A lease is counted per lane key (reviewerLaneKey), so the two concurrent requests a z.ai key carries count as one. That is conservative: the route lends fewer requests than z.ai allows, never more.
• The route serves one consumer kind (LEASE_REVIEW). Bee-side leasing through the card is a follow-up.

Owner steps after merge

1. Set TRIOS_QUEEN_REVIEW_LEASE_TOKEN (at least 32 random bytes) on trios-agent-server, with skipDeploys: true, and redeploy the queen build.
2. Put BEE_QUEEN_LEASE_URL=https://<agent-server host>/queen/zai-lease and BEE_QUEEN_LEASE_TOKEN=<the same token> in ~/.claude/.env on the Mac.
3. Paste the five Mac z.ai keys into the store through the contributor-key flow, then delete the ZAI_KEY_* lines. Once the lease is set, the reviewer refuses to start while they remain.

Check

Biome and the route-guard suite run in this PR's CI. Nothing was built or run on the owner's Mac.

🤖 Generated with Claude Code

[tri-claw]

Summary by t27-bees

Checked by the t27 compiler

_{t27c parse, parse-complete and typecheck on each changed .t27 file at 0293ce7. Nothing was generated, built or run. A pass means the file is well formed, not that it is right.}

• trios/agent-server/specs/queen/key_failover.t27: parses and typechecks.
• trios/agent-server/specs/queen/key_vault.t27: parses and typechecks.

Read by the model

This PR adds a /queen/zai-lease route so the Mac reviewer can lease z.ai keys from the Queen's key vault instead of using its own private keys. The route authenticates with a shared token, asks the key_vault.t27 Wasm card for a lease decision, and if granted, forwards the request to z.ai on a free lane key.

Worth a look

• trios/agent-server/apps/server/src/api/routes/queen-lease.ts (lines 195–215): The ask array passes n = leased.size (total leased keys across all consumers) as both held (lanes this asker holds) and review_holding (reviews holding lanes). For a single Mac reviewer this conflates global lease count with per-holder lane count; the spec expects lane counts (where each key = 2 lanes). This unit mismatch makes lease_answer compute with wrong magnitudes — could grant or wait incorrectly.

• trios/agent-server/apps/server/src/api/routes/queen-lease.ts (line 200): total = zaiLeaseLanes([], leased).length + leased.size adds free keys + leased keys, but the spec's total parameter is total lanes. Since each key carries 2 lanes (ZAI_REQUESTS_PER_KEY = 2), this undercounts total capacity by leased.size lanes. The known imprecision calls this "conservative," but combined with the held/review_holding mismatch above, the net effect on lease_answer is unverified.

• trios/agent-server/apps/server/src/api/services/queen-free-lane.ts (lines 105–108): The zai_code is extracted via regex /"code"\s*:\s*"?(\d+)/ from the response text. If z.ai returns non-JSON or a different field name, code defaults to 0, which error_kind classifies as KE_TRANSIENT for 429 status (correct) but KE_REQUEST for 400/404 (would incorrectly retry a bad request on another lane). The Wasm's lease_step treats KE_REQUEST as LS_ANSWER (no retry), so a misclassified 400/404 would not retry — but a misclassified 429 with no code would retry (transient), which is probably safe.

• trios/agent-server/apps/server/src/api/services/queen-free-lane.ts (line 92): leased is a Map<string, symbol> keyed by reviewerLaneKey(lane) (the key string). Two concurrent requests on the same z.ai key share one map entry. The free() cleanup checks leased.get(key) === id before deleting, so the last request to finish releases the key — correct. However, setTimeout(free, 600_000) and AbortSignal.timeout(600_000) race: if the fetch aborts at 600s, free() runs immediately and again at 600s. The symbol check makes the second call a no-op, so no leak.

• trios/agent-server/specs/queen/key_vault.t27 (line 212): lease_answer treats free_lanes == 0 as LA_WAIT before checking holder caps. The route passes lanes.length (free keys) as free_lanes. If 1 free key exists (2 lanes), free_lanes=1 passes the check, but the spec's holder_cap logic then compares held (keys) against cap (lanes). With REVIEW_FLOOR_LANES=2 and REVIEW_HOLDERS=3, holder_cap(2, 3)=1 lane. A reviewer with held=0 keys gets 0 < 1 → LA_GRANT. But if held=1 key (2 lanes), 1 < 1 is false, then free_lanes=1 > cap=1 is false → LA_WAIT, even though 2 lanes are free. This effectively limits each holder to 1 key (2 lanes) even when more are free — may be intentional but the unit confusion makes it hard to verify.

---

_{Read: 11 files, +920 -6, the whole diff. Head 0293ce7. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.}

[github-actions]

✅ Tests passed — 3915/3988

Suite	Passed	Failed	Skipped
✅ agent	429/429	0	0
✅ build	9/9	0	0
✅ cdp-protocol	5/5	0	0
✅ eval	93/93	0	0
✅ server-agent	280/280	0	0
✅ server-api	2273/2345	0	72
✅ server-browser	6/6	0	0
✅ server-integration	10/11	0	1
✅ server-lib	279/279	0	0
✅ server-pglive	166/166	0	0
✅ server-root	68/68	0	0
✅ server-sim	8/8	0	0
✅ server-skills	31/31	0	0
✅ server-tools	244/244	0	0
✅ shared	14/14	0	0

View workflow run

[dmitrii-f-t27]

Status: blocked on t27#10567 (owner merge)

This trios issue wires specs/queen/key_vault.t27 into the live Queen dispatcher. The spec itself is in gHashTag/t27 PR #10567 (open, mergeable=true), but I have pull-only access to gHashTag/t27 — no push, no merge. The owner (gHashTag) must merge #10567 first.

CI on #10567: one pre-existing failure (t27b-native-ratchet, Node.js 20 deprecation in .github/ CI config — documented in t27#10567 comments), unrelated to key_vault.t27. The spec file passes all local t27c checks.

What I can do: nothing further on the trios side until #10567 merges into gHashTag/t27 master. Once merged, key_vault.t27 exists on master and the trios-side wiring PR can be written.

Check runs on #10567: https://github.com/gHashTag/t27/pulls/10567