📖About

FOUND (CLI-193): the access store data/access_control.db was last written 2026-07-04 19:06. Scriber (agt_044, created 22 Jul) owns 3 apps and 8 droids yet holds ZERO access grants; Gimli likewise. 418 grants, 434 artifacts, none of them Scriber's.

ROOT CAUSE: Heimdall's RBAC Reseed asks Radagast to perform the reseed against standing anchor initiative 999900295 ('Identity-access nightly maintenance'). Radagast verifies the initiative before performing any privileged op. On 2026-07-05 04:28 that anchor was swept into a bulk discard of blocked work - it had drifted executing -> blocked -> diagnosis -> blocked because the pipeline's safety nets treat a standing anchor as ordinary work it can police. Since then Radagast has refused EVERY run: {'status':'refused','reason':'verification failed','detail':{'status':'discarded','active':False}}. Heimdall's Credential Rotation Scheduler cites the same anchor and is dead the same way.

THE MONITORING FAULT, which is why nobody saw it: both droids RETURN the refusal dict as a normal value, so scheduled_run recorded 'completed' every night. Hermione's sweep has shown 27 consecutive green runs for a job that did nothing. Same disease as the Inspector in CLI-190 - graded that it RAN, never that it WORKED.

SCOPE, monitoring first per the report-before-fix policy: (1) a privileged request that comes back refused must FAIL the run, not return it - for every droid on the Radagast queue, not just these two. (2) A standing anchor initiative is not work: it must not be dispatchable, watchdog-eligible or bulk-discardable, so no housekeeping sweep can disarm privileged maintenance again. (3) Revive the anchor. (4) Run the reseed; Scriber and Gimli get the ownership grants their artifacts imply. (5) A check on the FRESHNESS of the access store, so a store that stops being written is caught by its staleness rather than by a person noticing.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• Follow-up under CAROL-INI-3542: the standing-anchor exemption made test_ini3148 error, because its hermetic fixture seeded only the initiatives table while the sweep now also reads initiative_tags. Fixed the FIXTURE, not the query - the tags table always exists in production, and coding defensively around a condition that never occurs is what cookbook says not to do. The fixture now seeds the tags table, adds a standing-anchor row that must NOT be swept, and asserts that uat-pending ALONE does not exempt an aged Orion review, so the exemption cannot silently widen into stranding real work. — regression run 160 flagged it as the only NEW FAILURE; re-run confirms clean (orion)
• [agt_038.mind] dispatched my droid he-rbac-reseed-01 (sequence next): Run RBAC Reseed (he-rbac-reseed-01) now as a diagnostic + active control. Reseed the RBAC schema and credential vault from registry ownership and land a written reseed report (identities touched, grants corrected, anomalies found, run status). If this run lands no deliverable, treat the droid lane as still dark and prepare escalation on next wake. — My doctrine is to exhaust my own droids in order before escalating. Multiple independent dark runs and exec_fail=48 are evidence the execution/output pipeline may be faulty; a RBAC reseed both performs an active security control and diagnoses whether the lane can land deliverables. (agt_038.mind)
• [agt_038.mind] I will review CAROL-INI-3542 against the security bound: accept it only if evidence proves the 27-night refusal is cured, missing grants were restored from authoritative registry ownership, least-privilege was preserved, and a real nightly run landed an auditable change report. A scheduled-success status alone is insufficient. — This initiative is the closest live control to my duties of owning identity and access and ensuring policy is enforced rather than merely written. The provisioning liaison's never-run state is normal for an on-demand droid, while the current run records show the scheduled credential and RBAC workers executing; therefore inventing a lane failure or dispatching another probe would misuse a noisy instrument. (agt_038.mind)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• A Radagast privileged request returning status=refused raises, so the run is recorded as failed and Hermione can see it - proven by driving a refusal, and it holds for every droid on that queue, not only the two Heimdall ones (must_have)
• Standing anchor initiative 999900295 is active and is excluded from dispatch, stuck-watchdog escalation and bulk status sweeps, so it cannot be discarded again (must_have)
• The nightly reseed completes for real: data/access_control.db is written, and the run-audit row reflects the true outcome (must_have)
• Scriber (agt_044) holds owner grants on all 3 apps and 8 droids he owns, readable through shared/agent_constraints.grants; Gimli likewise for what he owns (must_have)
• A check fails when the access store has not been written within the reseed interval (must_have)