📖About

Ninad: the pipelines five states generalize to every service and track. Build the Service Tracker app: all services sorted by spend (highest first), tracks nested and spend-sorted, five status FILTERS with multi-membership (a track switched off AND paused by balance appears under both), each statuss definition shown under the filter bar with the selected one visible, default filter ON. The five statuses become first-class registry rows (today only the on/off switch exists), their definitions land in the Data Dictionary, and Carolopedia reflects them via the SST Concepts. ONE shared composer computes the state set per service/track (rule 1126: one composer, many views) from the switch, the spend gate, the subscription balance floor, the lane declaration and 24h activity evidence. Built on the generator-driven app machinery (registry row, render_app_configs, Radagast routes) - the estates app builder.

⚖️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)
• Track-shaped meanings for halted and stalled; spend window is 7 days with today beside it — Halted = no lane declared (a person must act) mirrors the pipelines waiting-for-operator; stalled = on, funded, tasked, yet silent 24h mirrors on-but-not-moving. Sorting uses 7-day spend so the order is meaningful at any hour (a today-only sort collapses to zeros each morning); both figures are shown. Owner set to Midas - statuses, switches and money are his domain. All three are UAT-adjustable words and windows, not architecture. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [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

• The five statuses are first-class registry rows with key, name, definition and display order, and every surface reads the definitions from the registry - no hardcoded copy (must_have)
• One shared composer computes each service and tracks SET of applicable statuses with reasons; the app is a view over it and computes nothing itself (must_have)
• The app lists all services sorted by spend descending with their tracks nested and spend-sorted, five filter pills with multi-membership, definitions under the bar with the selected filter visible, default view ON - verified by rendering the page (must_have)
• A track that is switched off AND paused for balance appears under both filters (proven by test) (must_have)
• The five definitions are registered in the Data Dictionary and reflected in Carolopedia via the SST Concepts (must_have)
• The app is registered, routed and launched through the generator-driven machinery (registry row, rendered configs, Radagast) and survives a restart (must_have)
• A regression test covers the composer states, the multi-membership, the default filter and the registry-sourced definitions (must_have)