Carol — back to Apps ← Apps

Carolopedia

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

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999900351
📋

CAROL-INI-0014-01: Rename frankfurt-food → prancing-pony

Initiative
Open in Initiatives →

📖About

Full product rename across 22 touchpoints: service folder (services/frankfurt-food/ → services/prancing-pony/), app folder (apps/frankfurt_food/ → apps/prancing_pony/), Carol droid (agents/carol/droids/frankfurt_food.py → prancing_pony.py + imports in mcp_server, tool_dispatcher, message_processor, test_carol_*_e2e.py), prompts (prompt_all.md, prompt_verified.md), infra (start.sh, nginx /frankfurt-food/ → /prancing-pony/), registry.db apps row, services/README.md, 2 design docs, 1 user tools.json. Success: zero stale references in non-archive dirs (verified by grep). Dependency: INI-013 (self-hosting pipeline) — implement via pipeline, no bypass. Part of Carol Food Ordering product vision.

⚖️Decisions

  • Follow-on to parent INI 14 (orion)
  • Scope inherited verbatim from parent INI 14 per CAROL-INI-361. (elrond.initiative_author)
  • [status-router] planned -> dispatched | event=dispatch | dispatcher queued (ds-s1)
  • [status-router] dispatched -> planned | event=dispatch_retract | No longer in the top-3 dispatch window (CAROL-INI-1972). (spb-01)
  • [status-router] planned -> dispatched | event=dispatch | Backfilled into the 3-deep dispatch queue (CAROL-INI-1972); queued for operator push, not auto-executed. (spb-01)
  • [status-router] dispatched -> blocked | event=stuck_10min_no_activity | Elrond safety net: initiative has had no activity for 10+ minutes. Blocking under the parallel safety mechanism. (el-watchdog)
  • Elrond blocked initiative under the CAROL-INI-2162 dead-Albus protocol. Albus was supposed to wake for step 0 (cause=albus_no_show) but did not respond. Cause: albus_no_show. Reason: Elrond safety net: initiative stranded 10+ min. Albus wake failed or produced no useful result. (el-s1)
  • Orion remediated: Albus RSI group diagnosis (via INI 999900430): [procedural, confidence high] Albus executor did not wake to execute step 0 of the initiative (albus_no_show), as evidenced by the Elrond safety net decision and the prior RSI diagnosis for the same cause group. The initiative remained idle for over 10 minutes, triggering the parallel safety mechanism. No actual work was attempted; the single execution history entry shows 'Idle close — no activity in window.' (orion)
  • [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
  • [rsi-group-cure] Cured by the group diagnosis on INI 999900430 (shared cause stuck_10min_no_activity); retriggered as INI 999900607. Root cause: [procedural, confidence high] Albus executor did not wake to execute step 0 of the initiative (albus_no_show), as evidenced by the Elrond safety net decision and the prior RSI diagnosis for the same cause group. The initiative remained idle for over 10 minutes, triggering the parallel safety mechanism. No actual work was attempted; the single execution history entry shows 'Idle close — no activity (elrond.rsi_loop)

Success criteria

  • grep -r 'frankfurt' across non-archive dirs returns zero hits (must_have)
  • Carol service dispatch works on the new prancing-pony route end-to-end (test via WhatsApp test conversation) (must_have)
  • registry.db apps table shows prancing-pony, no row for frankfurt-food (must_have)
  • All 22 touchpoints documented as updated in the implementation report (must_have)