📖About

Rebuild Prometheus Quality Scorecard as the master services-by-metrics-by-status hub with per-metric description/target/status and app links; split Pipeline RSI into Planner/Albus-bypass/Orion-bypass tabs; Cost and Time metrics for Build Initiatives are planned/later; remove Prometheus other two apps so he owns exactly one.

⚖️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)
• Caller audit waived by Orion: this bypass changed the Quality Scorecard app, a new metric_catalogue module, the Pipeline RSI dashboard HTML, and 3 registry app rows. It did NOT modify shared/bypass.py or any bypass-runtime behaviour; the gate is a fleet-wide false-positive from uncommitted bypass.py edits pending the hourly Shipper commit. — Bypass scope is app + catalogue + dashboard + registry rows; no bypass-runtime change. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• Ninad (2026-07-02): Quality Scorecard is the org-wide RSI MASTER HUB - reverses the CAROL-INI-2224 quality-only scoping — Ninad chose 'master hub (5 active)' when asked: the Quality Scorecard shows ALL RSI measures cross-domain (Build Success x3 by Elrond, Process success rate by Hermione, CPU health by Hagrid), each deep-linking to its owning dashboard. Prometheus's OWNERSHIP scope is unchanged (output quality only); the hub merely renders the other owners' live measures with attribution. Scope added to this open initiative by the dedup gate (a fresh filing was redirected here). (orion)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Orion verified: master-hub criteria met live — Evidence: Quality Scorecard API returns 5 active measures / 2 on target; process rows deep-link per service to the Process RSI trend with live values; CPU health renders on infrastructure at 5.4/10 linking to Infrastructure RSI; catalogue documents the 2026-07-02 reversal with owner attribution. CLI-018's original hub+tabs criteria remain live (mode tabs render, app up). (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Orion verified: process success attached to monitoring only — Evidence: scorecard API shows exactly one process-success row, on the monitoring service, value 8.9/10 org-wide (30955/34915 runs week of 2026-06-29), linking to /dev/process-rsi/; totals unchanged at 5 active / 2 on target. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• Elrond re-scoped success criterion 1 (replace) on Albus's prescription — Policy P.01.02.04.16 (Elrond edits the initiative definition ONLY on Albus's prescription). Albus diagnosis: Original criterion referenced autonomous self-healing completion via Albus, which creates an infinite loop. Replacing with a concrete deliverable criterion that actual build/verify steps can satisfy. (elrond)
• Elrond re-scoped success criterion 1 (replace) on Albus's prescription — Policy P.01.02.04.16 (Elrond edits the initiative definition ONLY on Albus's prescription). Albus diagnosis: Original criterion referenced autonomous self-healing completion via Albus, which creates an infinite loop. Replacing with a concrete deliverable criterion that actual build/verify steps can satisfy. (elrond)
• [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

• Quality Scorecard lists every Carolverse service with the metrics measured for each, one row per service-metric. (must_have)
• Each metric row shows a description, a target, the current value, and a Met/Not-Met status computed vs the target (planned metrics show not-yet-measured). (must_have)
• Each metric links to the app or dashboard tab that measures it; Build-Success rows deep-link to the matching Pipeline RSI mode tab. (must_have)
• Pipeline RSI dashboard has three working tabs: Planner, Albus bypass, Orion bypass, each showing that modes build success. (must_have)
• Prometheus owns exactly one app: Improvement Register and Lessons Learned are removed (registry rows + code); Quality Scorecard is clickable in Carol Apps on a clean non-colliding port. (must_have)
• Master hub (2026-07-02): Quality Scorecard boxes show 5 active measures - Build Success x3, Process success rate (Hermione), CPU health (Hagrid) (must_have)
• Master hub: Process success rate renders per service with its live weekly value deep-linking to /dev/process-rsi/#<service>; CPU health renders on the infrastructure service with its live value linking to /dev/infra-rsi/ (must_have)
• Master hub: the metric catalogue documents Ninad's 2026-07-02 reversal of the CAROL-INI-2224 quality-only scoping, with owner attribution on cross-domain measures (must_have)
• Master hub: Process success rate appears ONLY under Hermione's monitoring service (not on all services), showing the org-wide weekly score and linking to the Process RSI all-processes view (must_have)