Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999900132Guide page
📋

CAROL-INI-1915-00: Security observability apps — pure reporting layer over the security data

Initiative
Open in Initiatives →

📖About

Build the read-only reporting apps over data the core already writes; deleting any app must not change core function. Apps + owners: (a) Droid Activity Monitor [owner Tyr] — reads the run-audit ledger: each security droid's last run, cadence adherence, failures; (b) Security Event Console / SIEM dashboard [owner Tyr] — the SIEM's read surface; (c) IGA Console [owner Heimdall] — who-has-what (standing + JIT), access requests/approvals, recert campaigns, SoD conflicts; (d) Credential & Rotation Dashboard [owner Heimdall] — vault rotation due/overdue/last-rotated; (e) Incident & Risk Board [owner Forseti] — open incidents + risk register + posture. Also REFACTOR the existing access apps so they are purely read: move the JIT request/approve mutation endpoints OUT of the agent-access app and into the JIT Broker droid (core), leaving the app to display only. Every app uses the shared topbar/app-header/footer + a shared renderer where practical (per the access-mgmt.js pattern).

⚖️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)
  • ALL security apps (the 5 new reporting apps + the existing access apps) MUST follow the Carolverse app design templates / Design System #178 — shared topbar, app-header, footer, dark palette, loading/empty/error states, shared renderer where practical. Build them to pass Archons design gate natively rather than relying on a waiver; if the gate cannot see a shared external renderer, that gate limitation is itself in-scope to fix so the standard is genuinely verifiable. (orion)
  • ARCHITECTURE RULE: security apps are PURE VISIBILITY — GET-only, no operations. This supersedes the earlier read-mostly framing. The existing agent-access app must be refactored: its session open/record/close and JIT request/approve/deny/revoke endpoints move OUT of the app into core (a shared session-log module + the JIT Broker droid); the acting agent/droid calls core directly, the app only displays the resulting rows. Deleting any app removes a window, never a capability. (orion)
  • [status-router] planned -> closed | event=operator_put | PUT /api/initiatives (operator)

Success criteria

  • Five read-only apps exist (Droid Activity Monitor, SIEM dashboard, IGA Console, Credential Dashboard, Incident & Risk Board) with the proposed single owners. (must_have)
  • Each app is pure reporting: deleting it does not change any droid, the gate, or logging. (must_have)
  • JIT request/approve mutations are moved into the JIT Broker droid; the access app becomes read-only. (must_have)
  • Apps follow the shared topbar/app-header/footer + shared-renderer conventions. (must_have)
  • Every app conforms to the Carolverse app design templates (Design System #178): shared fixed topbar, shared app-header (icon+title+tagline), shared global footer, dark baseline palette, and explicit loading/empty/error states — and passes Archons design gate natively (no waiver). (must_have)
  • PURE VISIBILITY: none of the 7 security apps expose ANY mutating/operational endpoint — they are GET-only. Every write (session open/record/close, JIT request/approve/deny/revoke, credential/rotation actions, incident state changes) lives ONLY in a core shared module or a droid; apps just read and display. Verified: a route audit shows no POST/PUT/DELETE that changes state in any of the 7 apps. (must_have)