📖About

Ninad ruling. The registry data-dictionary table now defines displayed metrics (seeded for the two trackers and the pipeline view, with in-app definitions panels and a cookbook rule that a displayed metric without a dictionary row is a defect) but the dictionary has no home of its own and covers only three apps. Build a dedicated Data Dictionary app under the Governance service (owner Clara): it lists every registered Carol app with its data attributes and displayed numbers, each carrying a plain-language definition and the source it derives from, reverse-engineered from each app's actual code rather than invented. Nuances that cause apparent contradictions (an initiative is the 4-digit family; attempts and RSI diagnosis filings are not separate initiatives; the Activity Tracker counts COMPLETED families while the Token Cost Tracker counts families WORKED per day, so the two legitimately differ) are documented so such confusion never recurs. Apps with no documented attributes appear as visible coverage gaps, never hidden. Thin shim over a shared accessor reading the one registry table (no second store); house style; auth-gated in Carol Apps.

⚖️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)
• UAT fail round 1 (acceptor ninad) (uat)
• [status-router] reviewing -> planned | event=uat_fail_rework | pipeline_uat uat_fail_rework (ninad)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Handover-watchdog: planner-pending nudge for phase 2 (auto-invoked Elrond planner). (elrond)
• [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

• Ninad can open a Data Dictionary app from Carol Apps under the Governance service and browse every registered app's data attributes and displayed numbers with plain-language definitions and the source each one derives from. (must_have)
• The dictionary is honest about coverage: every registered app appears, apps whose attributes are not yet documented are visibly flagged as gaps rather than hidden, and the existing seeded tracker and pipeline definitions render unchanged. (must_have)
• Definitions for the major apps' displayed numbers are reverse-engineered from the code, including the completed-vs-worked tracker nuance, so a reader understands why two apps can legitimately show different numbers for the same day. (must_have)