Carolopedia

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

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999902574Guide page
📋

CAROL-INI-3667-00: A skill for the track — create, update, retire and move one across services — proven by moving Speech and Image & Video from Athena to Bilbo

Initiative
Open in Initiatives →

📖About

Ninad asked whether Speech and Image & Video could move off Athena's service to Bilbo, and then asked whether a skill exists for creating, updating, deleting and moving tracks. It does not. MEASURED against the catalogue's 36 skills: Leo has one for standing up or retiring a SERVICE, Midas has one for changing a lane's BUDGET, Sage has one for TASKS and their droids -- and nothing at all for the track, which is the thing that sits between them and carries the subscription. So every track change so far has been improvised.

WHY THAT IS DANGEROUS, measured on the two tracks being moved. A track is not one row. It is the track row, its work units, its blocks, and its budget allocation -- each carrying its own copy of the owning service and the owning agent. Worse, the Speech task's source spec names its payer BY AGENT ID: rows that name no payer attribute to Athena explicitly. A move that changed only the visible track row would leave the tasks, the blocks, the budget and the attribution still paying Athena, and every surface would show the track under Bilbo while the money kept going to Athena. That is the drift this estate keeps having to cure after the fact.

THE KEY NEVER MOVES. A track key encodes the service it was born in, and it is what budget allocations, budget operations, blocks, work units and glossary terms all point at. Renaming an identifier to make a label tidy rewrites spend history for a cosmetic gain -- the same ruling made for the Core track earlier today. The skill must state this as law, not as a preference.

DELIVERABLE: a registry-citizen skill covering the four operations (create, update, retire, move across services), with the move encoding the full layer list and the attribution trap, and hand-offs to the keepers who already own the neighbouring ground -- Midas for budget, Sage for tasks and droids, Leo for the service itself. Then PROVE it by using it for the move Ninad asked for.

⚖️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)
  • [delivery-check] 7 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (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

  • A skill for managing tracks exists as a registry citizen in the skills catalogue, with a named keeper, covering all four operations: create a track, update one, retire one, and move one to a different service. (must_have)
  • The skill states that a track's KEY never changes, and says why -- it is the identifier budget allocations, budget operations, blocks, work units and glossary terms point at, so renaming it rewrites spend history. (must_have)
  • The skill's move procedure names EVERY layer that must follow the track -- the track row, its work units, its blocks, its budget allocation -- and calls out the attribution trap where a task's source spec names its payer by agent id, which is invisible on every surface. (must_have)
  • The skill hands off rather than duplicates: budget changes to Midas's existing budget skill, tasks and droids to Sage's, standing up or retiring the service itself to Leo's. (must_have)
  • Speech and Image & Video are moved from Athena's Agent Resources to Bilbo's Blogs USING the skill, and the move is complete at every layer -- proven by reading back the track rows, their work units, their blocks and their budget allocations and finding no layer still naming the old service or the old owner. (must_have)
  • The payer named inside the Speech task's source spec is Bilbo after the move, not Athena -- proven by reading the spec, not by reading the track row. (must_have)
  • The track keys are unchanged and nothing that referenced them breaks, proven by counting every reference before and after. (must_have)