Three gates in this repository were decorative, and each was discovered by
being wrong rather than by failing.
A crate directory in neither members nor exclude is silently not built, which
is how lumbridge-devices shipped 1,127 lines that had never compiled.
scripts/workspace-guard.sh refuses that state, and asserts the gpui source
and version out of Cargo.lock rather than the manifest, because a manifest
states an intent while the lockfile states what would actually be compiled --
and a caret requirement accepts a version nobody reviewed. It needs no
compiler, so it runs first and in the headless job, which unlike the UI job
is not continue-on-error and can therefore actually fail a push.
deny.toml's source policy had never been executed: ci.sh ran `check
licenses` alone, and `check sources` failed immediately on the rev-pinned
buzz-sdk. The permitted Git sources are now named one by one and the check
runs, so a fourth is a decision rather than an accident.
cargo-deny and cargo-nextest being absent was a warning that let a run report
green having skipped the licence gate DISTRIBUTION.md depends on. Under
LUMBRIDGE_CI_STRICT=1 a missing tool now fails; locally it stays a warning so
a contributor is not blocked.
skills/lumbridge-development/SKILL.md told every agent that GPUI and Floem
live in spikes/ and that no framework may be selected until both pass the
hard gates. Decision 0017 settled that a month ago in the opposite direction.
The entry point an agent is meant to read was the least accurate document in
the repository.
Decision 0023 records where the GPUI dependency actually goes. Published gpui
has not been released since 2025-10-22, Zed's main still declares 0.2.2 with
no bump pending, the platform backends moved to crates that inherit
publish = false, gpui's own x11 and wayland features are now empty markers,
and 0.2.2 has no accesskit dependency at all -- so "published now, migrate
later" was never available. The adapter 0017 promised was never written and
the call sites grew from few to 147 against 20 identities, so the adapter is
written first, on 0.2.2, before the dependency moves.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SPYebLiN2w4TqnHUYGdECq
Decision 0015 rejected the account usage endpoint because AGENTS.md forbade
reading a harness's credential. The rule was written to stop one program
helping itself to another's secrets, and it was catching a legitimate use with
it: the user asking about their own subscription, through software they
installed to do that. AGENTS.md now states the narrow allowance instead of an
absolute the project does not hold, and 0016 records it.
The status line stays. It is free and it speaks every turn. What it cannot do
is report the per-model weekly limits a Max plan meters separately, or answer
at all before a session has taken a turn. The first live reading found the
account-wide seven-day window at 38% left and a per-model weekly window at 77%
left — a second ceiling the footer previously could not see.
Constraints the credential is read under, all enforced in code: access token
only, never the refresh token; zeroed on drop, along with the file buffer it
was borrowed out of; unprintable by construction, since HarnessError carries no
owned strings and AccessToken's Debug is hand-written; identified as
lumbridge/<version>, because sending claude-code/2.1.0 would make our traffic
indistinguishable from the harness's in Anthropic's logs; and off entirely
under LUMBRIDGE_CLAUDE_OAUTH=0.
The request runs on a detached thread with a slow refresh and a 429 backoff, so
a ten-second round trip cannot stall the transcript follower or make quitting
wait on the network, and one surface failing does not fault the other two.
Footer polish on top: the harness name prints once per group instead of in
front of each of its four windows, each quota carries a short scope pill
(5h, 7d, Fable wk, tokens) where an invisible BORDER-weight label used to be,
quotas sort ahead of spend, and a window under ten percent turns its headline
amber — value colour on the number, provenance colour on the meter, never
mixed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>