📖About

Ninad ruling. The 4-digit number defines an initiative; an attempt (-NN) of an initiative is NOT the initiative itself, and RSI diagnosis filings are not initiatives at all. (1) A new initiative_nnnn column on the initiatives store carries the 4-digit family number for every row - stamped automatically at filing by a database trigger that reads the canonical title prefix, backfilled for all history, and for RSI diagnosis filings the column carries the family number of the ORIGINAL initiative they diagnose (a second trigger remaps on the diagnosis tag), so no app ever derives families with complex calculations. (2) The shared day-count source counts DISTINCT family numbers - two attempts of the same family finishing the same day count once - so the Activity Tracker and Token Cost Tracker both show 3 for today, not 4, and their per-initiative lists group by family. The pipeline app already follows this definition. (3) The definition becomes the standard in the SSTs: the concept catalogue gains the initiative-vs-attempt definition and the counting-rule cookbook entry is amended so every future app counts families, never attempt records.

⚖️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)
• The family number is stamped by DATABASE TRIGGERS at the store itself, not by editing the filing code: a filing trigger parses the canonical title prefix on insert, and a second trigger fires when the diagnosis tag lands, remapping the filing to its target's family. Every filing door (app, Elrond's Creator, raw relay writes) is covered without touching the OS-locked pipeline core. (orion)
• Backfill covered all 3,845 rows with zero left unstamped; all 387 diagnosis filings carry their target's family. The column is the ONLY family source - consumers read it via two shared helpers (record-to-family, family-to-latest-title-and-lane) and never parse titles. (orion)
• The shared day-count source now counts DISTINCT families (a family's mode decided by its latest record); both trackers' per-initiative lists collapse to one row per family showing the 4-digit id, fronted by the latest attempt, with sums across records and tags unioned. (orion)
• SST updates: a new Initiative-vs-Attempt concept seeded in the scanner's concept catalogue, the attempts cookbook entry and the counting-rule cookbook entry both amended with the ruling. (orion)
• [delivery-check] 3 pending must-have criteria stamped met at bypass_end on live re-performance evidence (CAROL-INI-3020): test test_ini3323.py: PASS (1 passed in 0.59s) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [albus.mind] dispatched my droid al-rv-01 (sequence standing habit — reviewing-queue drain, step 7; survivors flagged for root-cause of non-movement): Standing habit, step 7 of the treadmill-break sequence — with a sharpened eye: run my Twin Reviewer down the current reviewing queue in order — 999902159, 999902158, 999902157, 999902156, 999902149, 999902148, 999902140, 999902139, 999902138, 999902137. Grade each against my bypass book and the initiatives DB evidence and move it out of reviewing. IMPORTANT: 999902137, 999902138, 999902139, 999902140, 999902148, 999902149 SURVIVED my step-6 pass — for each survivor, first determine WHY it did not move (review never ran? verdict recorded but status not transitioned? evidence gap?) and record that reason explicitly before grading. Do NOT file new diagnosis runs against 999901814/999901540/999901454 (hard-capped), and do NOT touch the escalated exec_fail backlog (46/16/8) — that answer sits with Orion. A review pass is complete when the queue holds nothing the pipeline is waiting on. — My memory is explicit: the signal that something is wrong is the SAME items surviving a pass, not new ones arriving. Six of ten queue items survived step 6 — so this pass must do two things: continue the standing habit, and diagnose why the survivors didn't land last time. If they survive again, that becomes evidence of a broken review-transition mechanism, and THAT would warrant a fresh initiative rather than an eighth pass. The exec-fail backlog stays untouched — it is the echo of a closed escalation, and I do not let echoes move my hand. (albus.mind)
• [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

• Every initiative row carries its 4-digit family number in a dedicated column, stamped automatically for new filings and backfilled for history, with RSI diagnosis filings carrying the family of the initiative they diagnose. (must_have)
• Both trackers count DISTINCT families per day - today reads 3, not 4 - and their per-initiative lists group attempts and diagnosis spend under one family row. (must_have)
• The initiative-vs-attempt definition is recorded in the SST concept catalogue and the counting-rule cookbook entry, so it is the standard for all apps. (must_have)