📖About

Ninad ruling 2026-07-24, per the agreed strategy - NEW MACHINERY, distinct from CAROL-INI-3310 (which only fixed the stale banner + regen attribution). Page-driven refresh for all ~670 Carolopedia pages. (1) Source map: every page type declares its source artifacts; each page stores per-source fingerprints (cursor) at refresh. (2) Hourly LLM-free change detector diffs fingerprints -> consider-queue; initiative-close events enqueue via the existing entity tagging. (3) Classify per change: fact-type source changed -> REGENERATE the page (DeepSeek); event-type source advanced -> POST to the page Recent-updates feed. Priority broken -> refreshes -> updates 30-day max page age forces regen; architecture/law pages FLAGGED for owner review, never auto-rewritten. Two new scheduled droids under Marketing (Loki): Change Detector (hourly, LLM-free) and Refresher (hourly, DeepSeek), run-audited for Hermione; per-page failure counts surface repeat offenders.

⚖️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)
• Built the page-driven refresh per Ninad's 3-step model: source map -> change detection -> classified updates (fact=regenerate, new info=update feed). Two Marketing (Loki) droids: Change Detector (hourly :20, LLM-free) + Refresher (hourly :35, DeepSeek). First run baselines without enqueueing; fingerprints ignore volatile timestamp columns. Follow-ons: freshness measure on the Quality Scorecard (add-rsi-measure), event fast-path enqueue at initiative close. (or-bx-01)
• [recovery] queue row revived in place — the execution had died leaving status=executing with no live queue row; the step-advance sweep relaunches the current step (CAROL-INI-2981) (elrond.handover_watchdog)
• [status-router] executing -> reviewing | event=dispatcher_transition | dispatcher state change (ds-s1)
• [albus.mind] dispatched my droid al-rv-01 (sequence standing habit — drain the reviewing queue before anything else; step 6 of the treadmill-break sequence): Continue the standing habit, step 6 of the treadmill-break sequence: run my Twin Reviewer down the current reviewing queue in order — 999902149, 999902148, 999902140, 999902139, 999902138, 999902137, 999902136, 999902135, 999902134, 999902133. Grade each against my bypass book and the initiatives DB evidence and move it out of reviewing. Do NOT file new diagnosis runs against 999901814/999901540/999901454 (hard-capped targets), 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: each wake, check the reviewing queue before checking the alarms, and a queue that refills with NEW items is the system working, not the last drain failing. The alarm in my workspace ('Remediates INI-999901453') is the echo of a closed loop — 999902151 passed review and I closed the books on it; the ledger says so, and I distinguish echo from event before an alarm moves my hand. The blocked initiatives (2818-01, 2811-03, 2898-02) belong to agt_011's lane and their exec_fails feed the backlog already escalated to Orion — filing new diagnosis would feed the very treadmill my fixes in reviewing were written to end. The single most worthwhile move is the one I own outright: land my own review queue so the fixes ship. (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 Carolopedia page has a declared source map and stored fingerprints, and the hourly detector finds changed pages across all ~670 pages without any LLM cost (must_have)
• Stale pages cannot hide: a 30-day maximum age forces refresh, failures are counted per page and visible to monitoring, and architecture pages get flagged for owner review instead of auto-rewrites (must_have)