crates/lumbridge-devices was in neither workspace.members nor
workspace.exclude, which is not a build error: Cargo simply never looked at
it. Its 19 tests had never run, it never inherited unsafe_code = "forbid" or
pedantic Clippy, and `cargo check` inside it refused outright with "current
package believes it's in a workspace when it's not". Under that cover its
lib.rs had been declaring `mod manage;` and re-exporting five items from a
manage.rs that did not exist, so the crate did not compile at all.
manage.rs is written here to the contract lib.rs already specified.
available_actions reads neither DeviceReachability nor Device::presence: an
offline device keeps its workspace action and an online one does not gain
one, because the registry is the axis and reachability is Tailscale's
separate claim. DeviceAction has three variants and no more -- install,
reboot and upgrade are absent from the type rather than rejected at runtime,
since a variant that exists is eventually rendered as a greyed-out button
reading "coming soon" instead of "impossible". A test walks every operation
in the module over every fixture device and asserts none of them ever
produces LumbridgePresence::Confirmed, which stays unproducible until a
lumbridge-remote runtime can answer for itself.
RemoteTransport had been declared twice, here and in lumbridge-core, with
byte-identical storage strings, because this crate had no dependency on that
one. Two enumerations of one choice persisted through the same strings is a
drift waiting to happen, so core keeps the single definition -- gaining the
default and the picker phrase -- and this crate depends on core and
re-exports it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SPYebLiN2w4TqnHUYGdECq
The footer showed invented percentages. It now shows what two harnesses
actually report, or says it does not know.
lumbridge-core gains an append-only per-profile UsageLedger and a projection
that labels every derived value estimated, withholds a burn rate from a single
sample, withholds a window fraction with no reported ceiling, withholds an
exhaustion estimate that lands after the reset, and reports an expired window
as rolled over rather than freezing its last percentage. A missing fact renders
as missing, never as zero. (0012)
lumbridge-harness is the impure side: processes, clocks, and untrusted wire
text in, observations out. Three adapters:
- Codex's account/rateLimits/read over the app-server's JSON-RPC stdio. The
client cannot express a request outside a two-variant enum and answers every
server-to-client request with -32601, so a harness asking Lumbridge for a
credential is refused by construction. (0013)
- Claude Code's session transcripts, as a byte-offset tail follower that
reports nothing until the backlog is read to EOF — a partially-read backlog
is indistinguishable from a burst of spend, and the first run against 20 MB
reported forty-six billion tokens an hour. The parser models four counters,
so the conversations in those files are not representable. (0014)
- Claude Code's five-hour and seven-day subscription windows, via a bridge
installed as its statusLine command. 0014 had claimed no such surface
existed; it does, and the record is corrected in place rather than quietly
edited. Lumbridge does not read the OAuth credential to call the account
usage endpoint, which is what comparable tools do — AGENTS.md forbids it,
and 0015 says so rather than leaving the gap unexplained.
Also in here: a capability-check ordering fix in the workspace reducer, where
the applied-request replay table was consulted before the capability check and
so answered questions the caller had no right to ask; the GPUI spike wired to
the live probes with per-harness gauges and provenance chips; and a launcher
that matches its own window by PID, because GPUI sets WM_NAME but not
_NET_WM_NAME and a title match never succeeded.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
karti