Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999902158Guide page
📋

CAROL-INI-3322-00: One initiatives-of-the-day number: shared day-count source for both trackers, RSI diagnosis spend clubbed to its target and never counted

Initiative
Open in Initiatives →

📖About

Ninad ruling in three parts. (1) The Token Cost Tracker and the Activity Tracker must show the SAME count of initiatives for a day - today one counts initiatives that spent money and the other counts initiatives that finished, so the numbers never agree. (2) One source of truth: a new shared day-count module becomes the single place that computes the day's initiative count and ids; both apps consume it and neither keeps its own counting logic. The canonical definition: real initiatives that reached done that day (closed or awaiting sign-off) with real recorded work - the live derivation from the activities ledger and the planner execution book, with the retriggered-work exemption; paperwork-only shells do not count. (3) RSI diagnosis filings are not real initiatives (standing doctrine): they are excluded from every count and every top-initiatives list, and their LLM spend is clubbed at read time onto the initiative they were diagnosing (target id parsed from the diagnosis filing), so diagnosis money shows up under the real work it served.

⚖️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)
  • Canonical definition chosen for the-count-of-initiatives-for-the-day: real initiatives that reached done that day (closed or awaiting sign-off) with real recorded work. The cost tracker's line therefore changed meaning from initiatives-that-spent-today to initiatives-done-today and was relabelled accordingly - money spent on paperwork or on work still in flight no longer inflates the count. (orion)
  • One source of truth: a new shared day-count module owns the definition (done rules, live work derivation, retriggered exemption, diagnosis exclusion); both trackers consume it and their own counting logic was deleted. The earlier live-derivation fix moved from the activity tracker app into the shared module. (orion)
  • RSI diagnosis filings are excluded via the standing one-detector module, and their spend is clubbed at read time onto the target parsed from the diagnosis filing itself - applied in the cost tracker's top-initiatives rollup and the activity tracker's token rollup, so diagnosis money shows under the real work it served. (orion)
  • Cookbook entry 937 records the rule: any future surface showing a per-day initiative count must import the shared module, never re-derive. (orion)
  • [delivery-check] 3 pending must-have criteria stamped met at bypass_end on live re-performance evidence (CAROL-INI-3020): test test_ini3322.py: PASS (1 passed in 0.94s) (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 cost tracker's per-day initiative count and the activity tracker's per-day done count show the same number for the same day and mode, both served by the one shared module. (must_have)
  • RSI diagnosis filings never appear in any initiative count or top-initiatives list, and their spend is visible under the initiative they were diagnosing. (must_have)
  • The shared number counts only real initiatives done that day with real recorded work - retriggered re-attempts count, paperwork-only shells do not. (must_have)