The credential file is shared with `claude` itself and its refresh token is
one-time-use, so whichever process refreshes first rotates the other's copy to
spent. On a failed refresh the provider kept the stale token and 400d every
turn until the service was restarted by hand — measured 2026-08-05, invalid_grant
from 00:03 onward while the file on disk already held a valid pair written at
00:08.
Re-read the file on refresh failure and adopt the token when it is different and
still live. oauth/refresh.rs already does this for the Codex path; the Claude
path never got it.
Measured on the phone, idle, screen on, same session, one flag apart:
monitor-sensor --proximity --light --accel iio-sensor-proxy 15.3%
monitor-sensor --proximity --light iio-sensor-proxy 1.1%
Claiming the accelerometer makes iio-sensor-proxy poll the IIO device
continuously; nothing else here does. Fourteen points of a core, forever,
for the reading §4 weights least (+0.3) and calls a weak signal — and one
the keepalive had to actively decay, because monitor-sensor speaks only on
orientation change, so a stationary phone paid the full poll cost to
report nothing.
The parser, the motion decay and MOTION_WINDOW go with it; all three
existed only to turn orientation into a motion edge. The 2026-07-27
finding behind the decay is kept in comment — 165 Moving(true) against 8
Moving(false) on one boot — because whatever reports motion next owes a
decay too.
This does not say accel is unwanted. It says a subprocess holding a
continuous claim is the wrong way to get it; TASK-36's SLPI batching is
the right one. Restore the source together with that, or the cost returns.
Drop temperature for models that removed sampling params (400 otherwise).
Preserve signed thinking blocks across tool rounds — Anthropic rejects a
tool_use whose preceding thinking block was dropped. Raise default
max_tokens to 32k for thinking-by-default models and request summarized
display so the reasoning pane is fed.
An audit found the fix from earlier tonight reintroduced through a
second button. A tap never resolves on the UP edge — the recogniser
returns None and the tap lands when the 300 ms multi-tap window closes
on a later tick, up to about 1.3 s after the press — so a single shared
latch had to survive that whole gap, and any other button's DOWN edge
inside it overwrote the answer.
Concretely: power wakes a dark phone, the volume rocker under the same
grip gets nudged within the second, and the pending power tap resolves
as "the panel was lit" and blanks the screen. That is exactly the
regression 8c7567e was written to fix.
`buttons` is already keyed per button so they cannot interfere; this
latch had reintroduced the coupling one level up. The test fails without
the fix — checked by reverting it.
viewtop recognises three fingers and had nowhere to send it. The obvious
move — have the compositor call `qs ipc call overview toggle` itself —
is the eighth blind actor §12 forbids by name, and wiuf-vpn-gate is what
that costs: 652 tunnel recycles in ninety minutes with no way to turn it
off.
So `gesture` joins `button` on the socket. The asymmetry between them is
the interesting part and is written down where it happens: `button`
carries raw edges because recognition is an accumulation over time and
the machine owns time, while `gesture` arrives already named, because
touch contacts exist only inside the compositor and nothing else CAN
recognise them. The line §12 draws still holds — the compositor names
what the fingers did, the machine decides what it means, and behaviour
leaves through the one executor table.
Three fingers raise the overview. Everything else is recognised,
recorded and inert, which is deliberate: a gesture that fires something
nobody chose is worse than one that fires nothing. The real binding
table belongs in DeviceStatePolicy, persisted and agent-writable.
Not on a dark panel. The overview is content, and content on an
unauthenticated glass is what the disclosure rules exist to prevent — a
tap on a dark panel is a wake, and that is the power button's business.
The reply says whether the gesture was bound, so a caller can tell "the
machine had no binding" from "the machine did not understand".
The phone's trail was almost entirely Locked -> Observed -> Locked. The
snapshots said why: prox=true on the way in, prox=false one second later
on the way out, over and over. `near` must hold 700 ms to be believed
and `far` is believed instantly, so a one-second episode is long enough
to enter and its end is immediate.
The debounce cannot be where this is fixed. suppress_wake reads the
debounced value, so slowing `far` there would keep vetoing tap-to-wake
after the sensor was uncovered — which is exactly what
PROXIMITY_FAR_DEBOUNCE's zero exists to prevent. One reading, two
consumers, opposite needs: the veto wants far fast, the state wants it
stable. So the hysteresis is on the state and the veto keeps its instant
edge, with a test pinning that separation.
3 s, bounded by data already in this file rather than by feel: the
measured blips ran ~1 s, and of the 44 recorded episodes the nine real
ones all ran >= 5 s. It sits above the noise and below every genuine
episode.
It reduces the flapping rather than abolishing it — a sensor that keeps
blipping still enters Observed on each 700 ms near. Raising the entry
bar needs the same split applied to the near edge, which is a second
change with its own justification to earn.
Two existing tests asserted the instant exit and now advance past the
dwell. The property they are named for is unchanged: far ends Observed.
apply_gesture's dark-panel branch returned Unblank+Restore without a
record_decision, while the blank branch records panel-off or
lock-before-blank. The trail showed 'button-gesture recognised' and then
silence, so a press that woke the panel and a press that was swallowed
left identical evidence — which is the one question anyone debugging a
dark phone is asking.
Press the power button on a sleeping phone: the screen comes on, the
lock screen appears, and it goes black again.
One physical press produces two reports and the second cannot see what
the first did. note_input fires on the DOWN edge — correctly, a finger
on the button is a user present — which takes the device out of Locked;
the executor lights the panel and reports it back through set_panel
before the finger is off the button. apply_gesture then resolves the tap
on the UP edge, reads panel_on as true, and takes the lock-then-blank
branch. The press that woke the screen is read as a press to blank it.
The panel state is latched on the DOWN edge and the gesture is decided
from that. The level is unreadable by the time the gesture resolves;
only the edge is still true. Sixth edge-versus-level bug here, after
locked_ack, ChargeRate, bootBloomActive, hasLoginctl and the compositor's
dormant OR in disclosure_locked.
The existing dark-panel test passed throughout because it never
simulated the executor's report landing between the two edges. The new
one does, and fails without the latch.
Two things that worked under Hyprland and stopped when viewtop took the
session, both for the same reason: the binding lived in hyprland.lua and
the daemon was never in the path.
dt2w: note_input recorded the wake and returned Restore, which is
brightness. So a double tap reported to the machine and the screen stayed
dark. It now returns Unblank first — the brightness a panel comes back at
means nothing until the panel is back. Only for the deliberate wakes
(DoubleTapToWake, Squeeze) and only when the panel is actually dark. The
power button is excluded on purpose: apply_gesture already wakes on its
resolved tap, and emitting a second unblank here is precisely how the
wake loop happened in the compositor this afternoon.
Volume: Action::Volume through the executor table, per §12 — a small
daemon reading a signal and calling wpctl is the eighth blind actor. It
fires on the DOWN edge rather than from a recognised gesture, because
BUTTON_MULTI_TAP_WINDOW is 300ms and a volume key that lags a third of a
second behind the press feels broken. The recogniser still sees the
edges, so a future binding table gets volume hold-to-ramp without this
changing.
Shell: HyprlandData did a bare JSON.parse on hyprctl output, which throws
on every refresh when there is no hyprctl — six exceptions a pass, and
every consumer of monitorData.scale got undefined. That is why the region
selector rendered as a sliver: the geometry was not wrong, it was NaN.
Absence is now a latched state, and RegionSelection/OverviewWidget fall
back to screen.devicePixelRatio. Hyprland stays preferred where it exists.
105 tests.
A scripted edit stacked three doc comments onto panel_on() and left
set_panel() with none. Comments are load-bearing here — set_panel is the
report half and request_screen is the ask half, and the whole reason both
exist is that a report must not actuate and an ask must not silently edit
the machine's idea of the hardware. That distinction was sitting on the
wrong function.
The state machine could turn the screen off and had no way to turn it
back on. `apply_gesture` answers a power tap on a dark panel with
`Restore` — which is brightness — and there was no unblank in the action
table at all. That was invisible because the wake never came through the
daemon: hyprland.lua bound the physical key straight to
blueline-screen-toggle, so the compositor woke the panel and sessiond
only heard about it afterwards.
viewtop consumes that key on purpose — the control that locks the phone
must not be interceptable by whatever is fullscreen — so the gap became a
phone that could sleep and never wake. Measured on hardware: panel off,
presses arriving and logged, no way back short of ssh.
Action::Unblank closes it, and a power tap now returns [Unblank, Restore]
in that order, because the brightness a panel comes back at means nothing
until the panel is back.
Also a `screen` verb, because a wake bound to a keybinding in a
compositor config is not something the agent can reach and §13 says that
is a defect. It is not a bypass: `on` is immediate, `off` routes through
request_blank() like every other path, so she can turn the screen off and
still cannot darken an unlocked session. Operation is hers; the ordering
is a property of the machine, not a permission she lacks.
100 tests, four new ones pinning exactly that.
logind refuses SetLockedHint for any session that is not Class=user. When
that happens LockedHint is pinned at no, is_locked() is permanently false,
every request_blank() times out its ack budget, and the panel goes dark on
a session nobody could confirm was locked — the machine keeps working and
only the security half is gone.
That state ran for weeks on blueline undetected: greetd's default_session
is the greeter slot, so any restart produced it, and the only trace was
one blank-without-lock per blank, which reads like a timing problem rather
than a structural one. Now it is one line naming the cause at startup.
A warning, not a refusal to start: a phone that will not boot because its
session class is wrong is worse than one that boots and says so.
LockedHint was never set on this device, so sessiond's `locked` (which
comes from logind per doctrine §4) was permanently false, request_blank()
timed out LOCK_ACK_BUDGET on every blank, and the panel went dark on a
session nobody could confirm was locked. LOCK-DPMS-LESSONS §1 held in the
code and not on the glass — every blank recorded blank-without-lock.
Three faults, measured 2026-08-02:
- Session.qml wrote the hint through /session/auto, which is the caller's
own session. The shell is not in the session that owns the seat:
viewtop in logind 66 (seat0/tty1), qs in 70. Written to one session,
read from another.
- lockhint.rs resolved via User.Display, which an ssh login is enough to
point at a seatless remote session — and which then went stale when
that session ended. Both sides now ask seat0 for its active session.
- The report was dropped outright. hasLoginctl starts false and only
flips when a Process probe returns; secure=true landed 30s earlier, so
the one edge that mattered hit the guard and was never retried, because
the shell locks once at boot and never changes again. Fourth
edge-vs-level bug after locked_ack, ChargeRate and bootBloomActive.
Verified on hardware: LockedHint now goes yes ~2s after a power tap.
`ensure_surfaces` returned early unless `state.locked`, and `locked` is
what the compositor sends once lock frames are up. ext-session-lock-v1 is
explicit: "The locked event must not be sent until a new 'locked' frame
has been presented on all outputs." So a compositor honouring the spec
waits for the surfaces this function refused to create until it had heard
from the compositor. Neither side can move.
Hyprland hides it by acking `locked` before any lock surface exists,
which is why this stood. Measured against viewtop on blueline today:
sessiond sat in `blocking_dispatch` waiting for a verdict that could not
arrive, and the session crash-looped every eleven seconds.
The wait loop was also deaf to the control channel for its whole 60s
budget, so a shell registering during it got `lock session did not
release in time` (server.rs waits 5s) and then asked the compositor for
a lock this thread still held — TASK-48's crash, reached from the daemon
side. It now drains Release before each dispatch and draws while it
waits, which is the order the protocol describes.
408 tests pass.
Both executors recorded success via record_error, so the daemon's own working
actions landed in the trail's error channel - visible on the phone as
{"event":{"error":{"component":"bearer","error":"preferred wifi"}}}. That makes
the one signal a reader scans for useless.
They also discarded every exit status, so a failed nmcli was indistinguishable
from a successful one and the trail would claim a metric that was never set.
Both now check status: record_decision on success, record_error with what
actually failed otherwise. The pin failing is expected without CAP_NET_ADMIN
and says so - the tunnel still works, it just follows the default route
instead of the chosen link, and those are different states.
Measured on the phone. After one PreferLink the clat device was up with its
192.0.0.1/32 address and *zero* routes: no default, and no 205.151.11.13/32,
which is the only path to the MMS proxy. ip route get 205.151.11.13 went out
wlan0. Restored by restarting blueline-clat.service.
nmcli device reapply resets a device to its connection's config, so it is
destructive to precisely the routes a sidecar daemon owns - and the CLAT
daemon owns all of clat's. TASK-49 acceptance #2 says carrier services ride
the carrier; this broke it on the first action it ever took.
The gsm connection was the wrong target too. The modem is v6-only and the v4
default for cellular is installed by the CLAT daemon as
'default dev clat scope link metric 2048', not by the gsm connection, so a
route-metric set there is a number nothing reads. Wifi's metric is the only
lever: under 2048 wifi wins, over it the carrier does. One connection
modified, one device reapplied, and the carrier's routes left alone.
Found on the phone: the bearer verb reported tunnel "off" while wiufph was up
and handshaking (4.11 KiB received). wg show needs CAP_NET_ADMIN for
WG_CMD_GET_DEVICE and sessiond is a systemd *user* unit, so it gets "Unable to
access interface wiufph: Operation not permitted" and every tunnel reads off,
forever. A daemon that cannot see the instrument it is built around.
/sys/class/net/<if>/statistics/rx_bytes is world-readable and is the same
number without the parse or the privilege; DEVTYPE=wireguard in uevent finds
the interface, and NM removes the link entirely when the profile goes down, so
its presence is the up/down signal.
The endpoint lookup had the same defect. NetworkManager hands wireguard.peers
to an unprivileged caller, and the endpoint is configured as a hostname
(sub.wiuf.net:51822), not the address the old gate hardcoded - so it is
resolved before pinning, and a failed resolution writes no pin rather than a
wrong one.
A policy field with no verb behind it is unreachable. set_policy takes both,
get_policy reports both, and a zero settling window is refused the same way a
zero lock-ack budget is - it is the event-speed controller by another name.
Nothing owned which link carries traffic. It was the residue of a DHCP metric,
a NetworkManager penalty and a shell script's assumption, and when those
disagreed the phone silently lost the network - every IPv4 destination leaving
over a degraded clat while wifi sat associated.
The thing this replaces, wiuf-vpn-gate, is worth stating because its three
defects are the design constraints:
- it was driven by the NM dispatcher AND a 90s timer while calling nmcli
up/down, which is itself an NM event. 652 tunnel recycles in 90 minutes,
~7/min - a loop, not a bad interval. Here the probe only reads, the decision
is a pure function, and the only egress is an Action from tick().
- its home test was ' inet 10.10.' - a /16 match that reads the foreign network
this phone lives on (10.10.30.213) as home. home_ssids is identity; an empty
list means never claim to be home.
- it managed CONN=wiuf while two profiles answer to that name.
LinkHealth keeps 'associated' apart from 'carrying', which is DEVICE-STATE-
MACHINE §10's source-health lesson applied to links: a wifi link that
associates and cannot route is a sensor that heartbeats and lies, and it is
what NM's +20000 penalty mislabels. A carrying cellular link therefore beats a
merely associated wifi one; wifi only wins ties.
TunnelHealth reads wg's received-byte counter, which nothing read before. Up
and deaf is a real state - measured over clat as 368 B received against 5.30
KiB sent - and every other readout on the device calls it connected.
Anti-flap is a settling window, not a rate limit: a changed preference must
hold BEARER_SETTLE (20s) before it produces a command, and the clock restarts
whenever the candidate itself changes. A steady state emits nothing, so it is
safe to evaluate every tick. Tests cover the flap that never settles, the
settled state that must not re-emit, and the dead network that must not be
flailed at.
NetworkManager stays the single writer of routes (acceptance #6): preference
is expressed as ipv4.route-metric plus device reapply, never ip route, and
reapply rather than up/down so a correction is not itself an NM event. The one
route sessiond owns is the WireGuard endpoint /32, which NM has no opinion
about.
The tunnel toggle stays the user's. tunnel_underlay() returns None when the
tunnel is off - this decides how traffic is carried, not whether the tunnel
exists.
Probed off the existing clock every 5th tick, with the lock released; no new
timer (acceptance #6) and no subprocess spawned under the state mutex.
blueline-power-button decided policy in shell script — read its own panel
state, asked the shell to lock over qs ipc, polled, then blanked the panel
itself. That was a path to a dark panel outside request_blank(), so §1's
lock-then-blank invariant had a hole in the most-used control on the device.
Edges in, gestures out: tap, double, triple, hold, long-hold, per button.
Only the power tap is bound; the rest are recognised, recorded and inert
until there is a binding table to point them at.
A held connection receives one trail entry per notable edge: transitions,
source-down/recovered, violated guarantees. Readings, wakes and heartbeats
never cross — the filter is the point, not the transport.
UnixStream::peer_cred is still unstable, so it only failed at the aarch64
build after rust-test had gone green. Use the same getsockopt machined
uses.
rust-test never built souveraine-sessiond at all — it is
required-features and the feature is not default. Build and test it.
sessiond admits shell_ready from the lease holder's own pid; the shell
carries its lock request through the reload so WlSessionLock adopts the
existing lock instead of taking the unlock branch on it.
Revises the prior fix: the model's reply is already complete in
final_content before the paced stream loop, so truncating to
needlessly dropped the unstreamed tail. On SSE receiver-drop, stop
streaming but commit the FULL reply (interrupt flag skips the pointless
N+1 and marks the turn); the surface recovers the whole reply on resume.
turn.rs streaming loop returned early on tx.send failure (receiver gone)
before the session commit, orphaning the turn: the assistant's partial
reply never landed, so the next turn's history snapshot read the user's
follow-up with no preceding reply -> a user->user gap. The model then
answered as if from nowhere (the 'whatever it was...' non-sequitur),
model-independent and intermittent. Commit the partial like an interrupt
instead, the way the cancel branch already does, so the thread links.
AgentSummary carries voice_id, sourced from agent.json (_souveraine) via
get() rather than the DB config_json column, which is write-once at create
and drifts on later edits. The list endpoint is the surface's only
unauthenticated view of an agent, so voice travels there; /v1/agents/:id
is token-gated.
It authenticated through PAM, called unlock_and_destroy(), and returned
Unlocked — and then the shell, whose GlobalStates.screenLocked is a separate
bool, re-registered, was told must_lock=true, and locked again. The protocol
has a lock directive and no unlock directive, so the fallback could open the
compositor's lock and had no way to tell the session it had. Casey hit it
exactly that way: "it logs in, and then qs says Locked still."
It was also not a last resort in practice. It is raised whenever shell_alive is
false, and that flag lied for 90 minutes on 07-29 because a scene reload's
re-registration was refused and the shell gave up (45fbbea). So it was the
first thing reached, on a bad signal, to do a job it could not finish — the
fallback shape the doctrine forbids.
Gone: auth.rs, the PIN pad, the keypad geometry and digit font, the
failed-attempt counter, SessionOutcome::Unlocked, Msg::AuthDone, and the
--pam-service plumbing down to the CLI.
Kept: acquiring ext-session-lock before any shell exists, which was never a
fallback but the ordering invariant from LOCK-DPMS-LESSONS.md §1, and the
Released handoff. A locked session with no shell now stays locked and says so
in the journal. Recovery is the shell returning, or a reboot.
79 tests pass.
Active Edge becomes InputTrigger::Squeeze. It resets the idle budget
and lands in the trail like any real input, but unlike a power button
it is a sensor reading and a tight pocket is a squeezed chassis, so it
carries the same proximity veto as tap-to-wake (DEVICE-STATE-MACHINE
4).
note_input_gated applies the veto and records the refusal via
record_decision — a silently dropped report is what 10 exists to
prevent. The input op now advertises refused_by_state.
Producers cooperate rather than being enforced; TASK-41 is the gate.
Accel inferred moving from orientation edges, so Moving(false) was only
reachable from the startup banner — boot 0 carried 165 true to 8 false and the
keepalive re-sent a stuck true every 30s, pinning +0.3 into observed_confidence
for the life of the process. Motion now decays over MOTION_WINDOW and the
keepalive re-derives it.
Light crossed the lux threshold on one sample and fell back on the next,
pulsing confidence 0.50->0.70->0.50 in 1.2s and toggling promote_idle across
the 0.6 band. An excursion must now persist: 2000ms brightening, 4000ms
darkening, taken from config_autoBrightness*LightDebounce in blueline's vendor
RRO. Reversal restarts the clock.
ParserState is shared and survives monitor-sensor respawns.
sensord hung off graphical-session.target, which nothing on this device
starts, so it was enabled and dead from every boot. Down starts from a
last-seen stamp and structurally cannot see that. Bind the reporter to
sessiond and make the machine say so.
Two halves of the same defect. The lux threshold compared each sample to the
previous sample, so a slow drift never tripped it — it now compares to the
last value actually reported. And no source had any rate floor at all, which
is how light managed ~8 reports/sec; 250ms per source, enforced separately so
a busy light sensor cannot delay a proximity edge.
Light drifts continuously; monitor-sensor emitted ~8 lines/sec and each was
a socket round trip re-asserting the same Changing(false). The keepalive is
what keeps silence meaningful, so only changes need reporting.
blueline-proximity-lock is 113 lines of shell implementing a subtle contract
(heartbeat inside SOURCE_DOWN_AFTER, seed from the probe banner, report both
edges) that would have been hand-copied for light and again for accel. One
binary, one contract, shipped in the package instead of the rootfs overlay.
Action::Restore bound the brightness inside an if-let, so the MutexGuard
lived for the whole body and run_executor locked again. Non-reentrant: the
state lock was held forever and every later request thread queued behind it
(measured: 347 threads in futex_wait, 691/1024 fds, accept loop healthy, no
request answered in 3h). Bind first, then branch.
Also close connections idle for 120s, exempting the shell heartbeat.
Measured: the hard reboot left the trail at exactly 4096 bytes with the last
entry cut in half. Rotating that aside cost chain continuity at the one moment
it is worth most.
SetPolicy only mutated memory. Every lock-screen timer set in Settings
reverted to the built-in 15s on the next restart, silently — the page was
honest about reading the daemon, the daemon was forgetting.
Saved to $XDG_CONFIG_HOME/souveraine/device-state-policy.json, write-then-
rename. serde(default) on the container so an older file loads with new
fields defaulted instead of dropping the user's settings on upgrade.
A failed save returns ok:false rather than a success-shaped switch.
A source that reported and then went silent past 90s is DOWN, not quiet,
and says so as an error-security entry. Sources that never reported stay
unknown — a light sensor with no reporter is correctly silent forever.
Every forensic snapshot now carries sensors_degraded, so a decision taken
during an outage doesn't read like a healthy one. This is the 2026-07-25
SLPI case: hexagonrpcd-sdsp exited 0, every sensor dead for hours, nothing
in any log.
Health is not read from SensorProxy Has* — measured lying both ways.
Also: evidence_fresh meant "ever seen" and read true through the outage;
repeated readings no longer append to the trail, since reporters heartbeat.
55 sessiond tests.
set_session_locked(false) discarded transition()'s return. There is no
Suspending/Asleep -> Active edge, so an unlock reported while asleep left the
state put but voided pending_blank, blank_requested and dimmed anyway. Now
refused, loudly, with the state intact.
update_sensors hardcoded SensorSource::Proximity in the forensic entry, so
accel/light/touch readings were written to the trail labelled as proximity.
Takes the source now; update_sensors() stays as a proximity wrapper.
47 tests, 1 new.
IdleConfig: ConfigSelectionArray presets (30s/1/2/5/10 min for the shell's
timers, 15s/30s/1/5 min/Never for the lock screen) instead of seconds
spinboxes. Nobody reasons about a lock screen in 5s increments; the policy
struct already said "iOS Auto-Lock shape". Wire values stay seconds.
Header comment corrected — hypridle no longer owns screen-off.
set_panel(false) clears pending_blank. A panel darkened by any other route
left it armed, so the next tick emitted a second Blank or hit the
blank-without-lock error path for a blank nobody was waiting on.
SetPolicy refuses dim_grace >= lock_blank_after. dim_at saturates to zero, so
the panel dimmed the instant it went idle with no lit period.
Verified by rendering the page, not by parse alone.
Measured on device 40min after boot: device_state=locked, panel_on=false, while
LockedHint=no. Screen dark, session unlocked.
locked_ack was the only lock ingress and there was no unlock one outside the
fallback PIN surface, so after the first unlock the machine believed it was
locked forever. Every is_locked() rule then fired against an in-use phone —
proximity blanked it, and blanks never asked for a lock because one was
"already held". Doctrine §4: never hold state the protocol owns.
New lockhint.rs watches LockedHint via gdbus monitor (§8's pattern, not
polling). Resolve via User.Display, NOT GetSession(auto) — auto returns the
CALLER's session and sessiond is a session-less user unit; over ssh it answered
_310 while the graphical session was _31.
set_session_locked() moves the base tier and voids lock-screen intent on
unlock: pending blank cleared, dim restored.
46 tests, 8 new.
LOCK-DPMS-LESSONS §1 is "Ordering: lock, then off". It held only because
hypridle's 300s lock listener fired before its own 600s screen-off listener —
two numbers in a config file, not a guarantee. Anything that skipped the lock
(idle inhibitor, native coordinator off, dead shell) still met the blank, and
the panel went dark on an unlocked session with nothing said about it.
Every path to a dark panel now routes through request_blank():
- locked -> Blank, unchanged, no added round trip
- unlocked -> Action::Lock, blank withheld, pending_blank deadline armed
- ack lands -> Blank
- budget expires -> Blank anyway + error-security in the forensic trail
The panel fails open because a lit unlocked phone in a pocket is worse than a
dark one (§1); the *claim* fails closed because doctrine §8 forbids pretending
the session locked. Input inside the ack window cancels the blank outright.
Action::Lock does not go through the executor table — the lock is not a shell
command. While a live shell owns steady state the directive goes down the
heartbeat connection and the shell raises its rich surface; with no shell alive
sessiond raises its own. Same relationship DEVICE-STATE-MACHINE §6 gives the
DPMS executor: the authority decides, the surface executes. A directive that
cannot be delivered takes the lock here rather than timing out into a dark
unlocked screen, and is recorded either way.
Policy gains lock_ack_budget (2s, refuses 0) and unlocked_blank_after (None by
default — the shell's IdleCoordinator owns the unlocked idle timer through
ext-idle-notify per doctrine §5, and a second one here would recreate the
competing-owner disease). Both are on the GetPolicy/SetPolicy seam so Settings
is a view over the owning daemon, per TASK-19.
Unknown directives are loud on the shell side: an older shell silently
dropping one would leave the daemon waiting out its budget and blanking
unlocked.
38 tests pass, 5 new covering the ordering.
