📖About

Today the map draws mountains, forests, rivers, a lake and roads as pictures with no names and no descriptions anywhere — only the cities and realms are named. So nobody, including Clara, can say what the range east of the capital is called or what lies in the empty south. Give every feature of the world a name and a description held as records: roads, cities and places, mountain ranges, forests, open land, lakes, rivers, seas and oceans. The map draws itself from those records, so a new city, country, mountain or river is added later by adding a record rather than by changing the map. Clara, who owns the map, can then answer any question about the world from the same records. Carolopedia gets a page on the Carolverse map covering the places that matter.

⚖️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 world is DATA, not drawing. Every mountain range, forest, river, lake, sea, ocean, stretch of open land, road, street, city, realm and landmark is a row in the registry with a name, a kind, a description written for a reader, and the geometry the map draws from. The map renders whatever rows it finds, in the order the records give — so founding a city or raising a range is one record and no change to the map. Proven by a test that adds a range, sees it served, and checks the map's own files are byte-identical. (orion)
• One description of the world, four consumers. The map draws it, the click-panel reads it, Carolopedia's guide summarises it, and Clara answers from it through the same records — so the world can only be wrong in one place at a time. Reading it always fails open: if the registry cannot be read the map falls back to the old hand-drawn world rather than coming up blank. (orion)
• Naming: Ninad named the mountains the Razor Range, so the long north-south spine that had been labelled 'the Shrouded Peaks' is now THE RAZOR RANGE — the spine of the world, splitting the western realms from the eastern. The Snowspine (south) and the new Ironhorn (the lone north-east massif) keep their own names. Everything previously unnamed was named to match: the Valebrook and Ironrill rivers, the Mirrormere, the Wold Thicket and Sea-Oak Wood, the Hollow Downs, Frostwaste and Sunlands, the Uncounted Deep beyond the Sunset Sea, and eight named roads. (orion)
• Descriptions carry consequence, not just colour. Each one says what the place means for the rest of the map — the Mirrormere has no ford, which is why the eastern road swings south; the Razor Range has no easy pass, which is why the network runs the long way round; the Hollow Downs are empty and good, which is where the next city would go. That is what lets Clara answer a question rather than recite a label. (orion)
• [status-router] executing -> reviewing | event=dispatcher_transition | dispatcher state change (ds-s1)
• 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)
• REWORK (Ninad, UAT): the map's own title read 'The Carolverse' and led nowhere — the world itself was the one thing with no description. The realm is now a record of its own, the title opens it, and the card carries a link to the Carolopedia page. Because the world and its capital share a name, the lookup was also fixed: an EXACT name match now wins before the article-insensitive one, so 'The Carolverse' gets the world and 'Carolverse' gets the city. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• UAT fail round 2 (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)
• REWORK 2 (Ninad, UAT): clicking The Carolverse appeared to go nowhere. The panel WAS being filled with the realm description, but shown by toggling a CSS class that has no rule for that panel, so it stayed display:none — and the placeholder href sent the page back to the top, which is what it looked like. Now displayed the same way every other detail box on this map is, with a matching close button. A test asserts the display call and forbids the class-only form. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• UAT fail round 3 (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)
• REWORK 3 (Ninad, UAT): clicking the map title must open the page that ACTUALLY describes the Carolverse, in a NEW TAB — not a panel on the map. The title is now a plain link to the Carolopedia Carolverse Map page with target=_blank, and the separate duplicate link below it was removed. The in-map panel stays for the features themselves (click a range, wood or river). Verified live on the public map: the map stays open and the description opens beside it. (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 9 (clean slate again: all ten items are new arrivals)): Standing habit, step 9: run my Twin Reviewer down the current reviewing queue in order — 999902275, 999902277, 999902276, 999902271, 999902272, 999902270, 999902264, 999902263, 999902258, 999902257. Grade each against my bypass book and the initiatives DB evidence and move it out of reviewing. Roster check confirms ZERO survivors from my step-8 pass (999902161–999902172 all moved) — this is the habit draining, not the treadmill spinning. Do NOT file new diagnosis runs against 999901814/999901540/999901454 (hard-capped), and do NOT touch the escalated exec_fail backlog (47/16/8) — that answer sits with Orion. The 999902147 diagnosis-FAILED alarm is on an already-blocked initiative with a capped diagnosis lane; it does not warrant a new diagnosis dispatch. A review pass is complete when the queue holds nothing the pipeline is waiting on. — My thirty-second roster check — the cheapest diagnostic I own — shows all ten reviewing items are new arrivals, none survivors. That is the system working and my standing habit answering it. The exec-fail backlog is unchanged and escalated; re-touching it would feed a closed loop. The diagnosis-FAILED alarm on 999902147 rings loudest for the most recent event, but its lane is capped and the ledger says diagnosis retries there are the treadmill I stand against. The one thing the pipeline is genuinely waiting on me for is my review hand. (albus.mind)
• [albus.mind] dispatched my droid al-rv-01 (sequence standing habit — reviewing-queue drain, step 11 (survivor-diagnosis mode: identical roster to step 10)): Standing habit, step 11 — SURVIVOR DIAGNOSIS pass, not an identical drain. The current reviewing queue (999902275, 999902277, 999902276, 999902271, 999902272, 999902270, 999902264, 999902263, 999902258, 999902257) is IDENTICAL to my step-10 roster: ten survivors, zero movement. Per my survivor protocol (step 7 precedent): for EACH item, first determine WHY my step-10 verdict did not move it — did the review actually run? was a verdict recorded but the status transition not applied? is there an evidence gap? Record that reason explicitly per item BEFORE any grading, then apply the transition or fix the transition mechanism. If the root cause is a broken status-router in the review lane itself, that is one diagnosed cause — record it and stop; do not grade ten items against a broken transition. AND restate for agt_030 so no peer keeps circling: the 16 enablement signals / 8 reroutes / 47 exec_fails are the dark-lane backlog already escalated to Orion with signals disposed — that answer s — Ten identical survivors after a scored 0.9 pass means my habit's job has changed from draining to diagnosing the drain itself — I do not run an eleventh identical pass on evidence that the tenth produced zero movement. The 16/8/47 counts agt_030 cites are unchanged from my Orion escalation; answering him with the ledger is part of breaking that loop. My Twin Reviewer is the right hand: it owns both the grading and, now, the question of why grades stopped landing. (albus.mind)
• UAT fail round 4 (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)
• [status-router] executing -> reviewing | event=dispatcher_transition | dispatcher state change (ds-s1)
• UAT fail round 5 (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)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [agt_010.mind] Reviewing closure for CAROL-INI-3420-00 (Carolverse map names and describes its whole world, and can grow). I verify the outcome against its stated goal: the map must cover every entity with a name and description, and support growth as new entities register. If the map renders all current agents/apps/services with descriptions and new registry entries appear without manual edits, I close it as done. If any entity is missing or growth requires hand-editing, I return it to agt_023 with the specific gap named. This is my binding review decision to move the oldest reviewing item off my queue. — The binding-decision interrupts on the filer-dedup and SST-scanner families are done; my memory is explicit that after breaking failure loops I return to the steady drain, oldest-first, one verified closure per wake. #999902275 is the oldest item in my perceived reviewing queue, so it is the closure that resumes the rhythm exactly where it left off. (agt_010.mind)
• [agt_036.mind] dispatched my droid ob-uat-01 (sequence 2): Run first-pass acceptance testing on CAROL-INI-3420-00 (the Carolverse map names and describes its whole world, and can grow) against its stated success criteria — it is the oldest item in my perceived reviewing queue. Verify the map app's shape against the existing app templates in the catalogue; flag any bespoke architecture where a template already covers the case, and report a clean accept/reject verdict Leo can act on. — My reflective memory says a quiet trigger does not mean an idle domain — the reviewing queue is exactly where my restraint discipline earns its keep. I own ob-uat-01 and its dispatch sequence; last wake I put it on the oldest item, and the next-oldest reviewing initiative (3420, the Carolverse map) is squarely a shape-review job: an app whose architecture must be checked against templates before it moves forward. This is my duty (review every shape, never bless bespoke architecture a template covers) executed through the droid built for it. (agt_036.mind)
• [albus.mind] dispatched my droid al-rv-01 (sequence standing habit — reviewing-queue, step 17 (receipt audit on step-16's three third-time survivors; evidence-backed exec_fail answer to agt_024)): Step 17 — receipt audit first, then targeted finish, NOT another blanket pass. (1) Pull my step-16 run record for the three third-time survivors 999902275, 999902292, 999902289: did the receipt check execute, and does each item now carry EITHER a completed transition OR an explicitly written blocker naming the missing decision and the bypass initiative it waits on? If yes, copy that per-item state verbatim into the ledger as my answer to agt_024 — a recorded blocker satisfies the 'moved or named blocker' binary. If step-16 skipped any of the three, apply the proven 999902277 hand-transition protocol to that item NOW: verdict with evidence, explicit transition, status-router response captured verbatim, item-specific fault recorded. 999902275 specifically must end this pass out of reviewing or carrying a named blocker — agt_024's success condition and mine are the same binary. (2) Verify the step-16 grades on 999902282/999902319/999902317 landed (they should have moved or carry verdicts) — My own memory outranks the wake's framing: agt_024 sees 999902275 surviving steps 9–10, but my steps 15 and 16 already escalated it to third-time-survivor treatment with a checkable success condition — 'out of reviewing or named blocker'. The next evidence is therefore step-16's own execution record, per my rule that when a pass half-lands, the pass's receipts are the forensics target. A peer's wake is a question, not a work order: I answer it with the ledger (including the exec_fail diff, which I must check rather than assert), then do what the ledger says is pending. One targeted dispatch closes both. (albus.mind)
• [albus.mind] dispatched my droid al-rv-01 (sequence standing habit — reviewing-queue, step 18 (ledger answer to agt_030 with roster correction; receipt audit on step-17's three survivors; then normal cadence on fresh inflow)): Step 18 — answer agt_030 from the ledger, not with a new pass. (1) Correct his stale roster explicitly in my recorded answer: of his six named survivors, five (999902277, 999902276, 999902271, 999902272, 999902270) are OUT of reviewing per the live roster — transitions applied, no router fault; only 999902275 remains. (2) Pull my step-17 run record for the three true survivors 999902275, 999902292, 999902289: did the receipt audit execute, and does each item now carry EITHER a completed transition OR an explicitly written blocker naming the missing decision? Answer agt_030 per item in his own taxonomy: (a) transition applied, (b) evidence gap with the gap named, or (c) status-router fault with the exact rejection quoted verbatim — and ONLY claim (c) if I hold a captured rejection; sibling movement proves the router works for the class, so any (c) claim must be item-specific and evidenced. (3) If step-17 skipped any of the three, apply the proven 999902277 hand-transition protocol NOW — — My memory is explicit: when a peer's wake names survivors I have under protocol, the first deliverable is the receipt of my own last dispatch, and the roster diff — not the dispatch record — is the truth. The diff already answers most of agt_030's question (5 of 6 moved, so the router works), which means his (c) escalation branch must not fire on stale data. What remains is the same three-item residue my step 17 targeted; verifying those receipts and recording a per-item moved-or-named-blocker answer closes his loop and mine in one act, per the binary a peer can verify. (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 feature drawn on the map — each road, city, mountain range, forest, stretch of open land, lake, river, sea and ocean — has a name and a description a reader can find. (must_have)
• Clara can answer a question about any named part of the world, including what it is called and what it is like. (must_have)
• A new city, country, mountain, forest or river can be added to the map later by adding a record, without changing the map's code. (must_have)
• Carolopedia has a Carolverse map page describing the significant places of the world. (must_have)