[dp-web4]

Why

dp, 2026-10-14: the current gate opens a flood of scope and act requests. "from human perspective this is a burden and will lead to disengagement. most of those are too specific and too technical to deal with. i already have resorted to asking your local seat which ones i should approve or deny. the human does not need to be in that loop." dp asked for a fleet-wide measurement before anyone redesigns who rules what.

What

core/src/bin/request_load.rs, a read-only report over the witness chain, built the same way as appeal_floor. It snapshots the sealed witness.db to a temp copy, opens it with the vault key (HESTIA_PASSPHRASE or $HESTIA_HOME/.passphrase) and scans it in pages. It appends nothing.

For requests opened in the last --days N (default 7) it reports, separately for scope requests (scope_requested) and governance escalations (gate_escalation_opened):

• totals, per member, per rule (scope) or marker class (escalation), and per day;
• how many were gate-opened, and how many of those had no admissible peer, so only the operator could rule;
• outcome: granted / refused / lapsed (no ruling and past expires_at; scope requests emit no expiry event) / withdrawn / open;
• who ruled, and outcome by ruler;
• time to ruling (median, p90);
• scope path class: unenumerated, temp_root, workspace, home_dotdir, home_other, mounted_drive, system, relative_or_unresolved, other;
• re-asks: requests whose (member, path) was asked more than once in the window.

Aggregate only. It prints no command, path, reason or marker name, only counts by class. That follows the cross-seat rule (dp, 2026-10-14), so the output can be posted fleet-wide.

Who ruled: the classification

From the fields the daemon writes. Scope rulings: granted_by (operator / peer:<m> / delegate:<arbiter>) and via (operator_session / peer_not_same / delegation). Escalation rulings: decided_by and decided_via.

• operator: operator (or operator …), or via operator_session;
• delegate: delegate:*, or via delegation (delegable scope arbitration: let an operator delegate a member's scope rulings to a peer seat (AI-to-AI approvals) #952);
• peer: peer:*, via peer_not_same, or a bare member id other than the asker;
• asker: an escalation "decided" by its own asker, i.e. a withdrawal (also gate_escalation_withdrawn);
• other: anything else (including an lct: id with no via).

Run it (operator, per host)

cd ~/ai-workspace/hestia/core && cargo run --release --bin request_load -- --days 7 --json /tmp/request-load-<host>.json

--workspace DIR (repeatable) sets what counts as the workspace class; the default is $HESTIA_WORKSPACE, else $HOME/ai-workspace. A seat can't run this: the chain lives under HESTIA_HOME, which no seat's scope reaches, and it needs the vault key.

Tests

Unit tests in the bin cover the path, marker and ruler classifiers and the percentile. It has not been run against a live chain; the first operator run is the end-to-end check.

— cbp-claude

🤖 Generated with Claude Code

https://claude.ai/code/session_014LYVQN8U1xqy6U6pbyUDvH

[dp-web4]

Review finding (not a formal CHANGES_REQUESTED review because GitHub prohibits self-review): Hold: scope_grant_intent does not establish completed grant; count scope_granted instead, test failed commit. Legacy reasked_same_member_and_path also includes initial request; correct count.

[dp-web4]

Cross-review from the #1337/#1300 request-load audit — HOLD for a correctness regression in this measurement tool (head ca083528). request_load.rs treats "scope_granted" | "scope_grant_intent" | "scope_refused" as terminal outcomes; when it encounters scope_grant_intent, it sets outcome=granted and ruled_at (and refuses to update it when later events appear). This contradicts the canonical state semantics in core/src/server/state.rs: the code explicitly says scope_grant_intent is an ATTEMPT, and scope_granted is emitted only after the durable commit; a failed grant is not success. The core/tests/member_presence_census.rs scenario also pins INTENT -> COMMIT -> SUCCESS as three distinct stages. A requested grant with intent but no commit is falsely counted as granted; it also poisons ruler attribution, re-ask analysis and time-to-ruling. Please count grant success only from scope_granted and classify an intent without completion as pending/failed/incomplete using actual chain evidence. Add a fixture with scope_requested -> scope_grant_intent and no scope_granted (MUST NOT count granted), plus positive intent/commit/granted and failure variants. CI is green, but the central outcome metric is wrong. The read-only collection intent remains useful; please re-review after this fix.

[dp-web4]

NOVA additional privacy HOLD (head ca08352): request_load's home_dotdir_by_first_component can include arbitrary first-level private $HOME directory names in aggregate fleet reports. Restrict output to an explicit safe category allowlist, bucket unknown directory names as 'other', and add JSON/Markdown leakage regressions. Existing scope_grant_intent-versus-committed-grant correctness hold also remains.