📖About

Redesign Prometheus Quality Scorecard: audit against the app-development skill/design standards and fix chrome; drop the Target and Current columns so Status is a bare green-tick/red-cross; three-column layout Services|Measure|Status with short readable descriptions on services and measures; service-name links to the Services Catalogue service page, measure links to the monitoring dashboard; add three top stat boxes (services count, active-measures count, on-target-measures count); clean elegant styling.

⚖️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 edited only the Quality Scorecard app and added service-description/link/binary-status helpers to shared/metric_catalogue.py. It did NOT touch shared/bypass.py or any bypass-runtime behaviour; the INI-716 gate is a fleet-wide false-positive from uncommitted bypass.py edits pending the hourly Shipper commit. — Scope is the Scorecard UI + catalogue helpers; no bypass-runtime change. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• UAT fix (Orion): the app header was hidden under the fixed CAROL_LOGO_v4 topbar; added 56px top padding to the body so the header clears it. — Fixed-header overlap found during UAT. (orion)
• UAT fix (Orion): the stat boxes counted per-service instances, inflating Measures active to 26 (Process Health counted 23x). Changed to count DISTINCT built measures: active=4 (Process Health + Build Success x3), on target=2. — Active-measures count inflated by per-service instances. (orion)
• UAT enhancement (Orion): the three top boxes are now clickable filters on the table — Services (all), Measures active (built+computed), Measures on target (green). Table renders client-side from the API so rowspan grouping recomputes per filter; clicking the active box again clears the filter. — Ninad asked the top boxes to act as table filters. (orion)
• UAT reframe (Orion): Process Health (share of droid runs completing) was Hermiones process-monitoring metric, not a quality metric — a run completing is not a quality output. Removed it. The Scorecard now measures OUTPUT QUALITY only: active = Build Success x3 (does the pipeline produce a verified good build when triggered); every other service shows a Quality measure to-be-defined placeholder (planned). active=3, on target=2. — Ninad: Hermione monitors if a process runs; Prometheus inspects the quality of what it produced. (orion)
• Elrond re-scoped success criterion 999900465 (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 required zero failures across EVERY registered test suite for 3 consecutive runs — impossible because the codebase contains unrelated test suites that fail non-deterministically. Replacing with a bounded, scoped criterion that measures only the deliverable's own test coverage. (elrond)
• Elrond re-scoped success criterion 999900465 (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 required zero failures across EVERY registered test suite for 3 consecutive runs — impossible because the codebase contains unrelated test suites that fail non-deterministically. Replacing with a bounded, scoped criterion that measures only the deliverable's own test coverage. (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: The original success criteria for this initiative likely focus on the scorecard redesign itself, but the initiative cannot make progress because the pipeline machinery (dispatcher) is stuck in a loop. The immediate fix is not the scorecard code — the blockage is the dispatcher's failure to dead-letter. Elrond must update the dispatcher's decision logic to handle repeated inconclusive results from (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: The original success criteria for this initiative likely focus on the scorecard redesign itself, but the initiative cannot make progress because the pipeline machinery (dispatcher) is stuck in a loop. The immediate fix is not the scorecard code — the blockage is the dispatcher's failure to dead-letter. Elrond must update the dispatcher's decision logic to handle repeated inconclusive results from (elrond)
• [status-router] reviewing -> blocked | event=operator_put | PUT /api/initiatives (operator)
• Orion remediated: Albus RSI group diagnosis (via INI 999900484): [procedural, confidence high] The initiative was manually blocked by operator 'or-bx-01' (PUT /api/initiatives) because the previous attempt's success criteria were never genuinely verified — the reviewer log shows that 'stale_artifacts' pre-verify failures preceded a forced transition to 'executing' followed by an immediate operator block, indicating that the operator recognized the procedural gap (missing evidence of actual droid replacement, shim delegation, and cookbook updates) and blocked to prevent a repeat of the same failure pat (orion)
• [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
• [rsi-group-cure] Cured by the group diagnosis on INI 999900484 (shared cause operator_put); retriggered as INI 999900669. Root cause: [procedural, confidence high] The initiative was manually blocked by operator 'or-bx-01' (PUT /api/initiatives) because the previous attempt's success criteria were never genuinely verified — the reviewer log shows that 'stale_artifacts' pre-verify failures preceded a forced transition to 'executing' followed by an immediate operator block, indicating that the operator recognized the procedural ga (elrond.rsi_loop)

✅Success criteria

• Quality Scorecard conforms to Carol app-development/design standards (canonical topbar + app header + shared theme). (must_have)
• Table has exactly three columns: Services, Measure, Status; Status is only a green tick or red cross (Target and Current columns removed). (must_have)
• Each service row and each measure carry a short, readable description (not tiny font). (must_have)
• Clicking a service name opens that service in the Services Catalogue; clicking a measure opens the dashboard that monitors it. (must_have)
• Three top stat boxes show: count of services, count of active measures, count of measures on target; the table is clean, uncluttered and elegant. (must_have)