Carolopedia

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

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999902624Guide page
📋

CAROL-INI-3704-00: Subscription summary boxes: two numbers, one naming, typed by colour, and a retired subscription still shown

Initiative
Open in Initiatives →

📖About

(1) DeepSeek vanished from both when it was retired yesterday; by Ninad's own qualifying rule - a service paid for at least once is a subscription - it keeps its box, marked retired, with its last known figures. The retirement itself stands; only the display changes. (2) The boxes must show at a glance which subscriptions are a FIXED monthly plan and which are PAY AS YOU GO, by colour: green for fixed, yellow for metered, and the existing grey for a lane with nothing left still wins over both, so 'exhausted' stays readable alongside the type. (3) Both surfaces must call a subscription by the SAME NAME. They do not today - one page says 'Claude Max' and 'Kimi' where the other says 'Claude AI (Max)' and 'Kimi (Code)' - because Carol Intelligence labels its boxes from its own map of ledger lanes while Model Subscriptions reads the registry. The registry's subscription label is the single source and both must read it. (4) The Model Subscriptions boxes carry too much prose. Ninad wants TWO NUMBERS: the top-up and the balance. Provenance must survive that cut without a sentence - the distinction between a figure READ from the provider and one computed here was won earlier in this session and may not be given back, so it is carried by a mark and its detail, not by a paragraph.

⚖️Decisions

  • [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • 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)
  • A retired subscription keeps its box, but leaves the estate — Ninad: show it, marked retired. Retirement does not un-spend money, and his qualifying rule is about money that changed hands - so DeepSeek keeps a box. It states no balance, because nothing runs on a retired lane and showing the whole top-up as though it still sat in the account would be the boldest guess on the page. It stays OUT of the consumption chart and every total, and a check fails if it returns there.
  • Two names for one account is a duplicate wearing a different coat — The two surfaces disagreed - Claude Max vs Claude AI (Max), Kimi vs Kimi (Code) - because each kept its own map of ledger lanes to friendly names. Nothing errored; they simply drifted, and a reader had to work out for themselves that these were the same account. Both now read the registry's label through one accessor.
  • The type is the registry's to state, not the page's — Green for a fixed monthly plan, yellow for pay-as-you-go, taken from the registry's kind so a subscription that changes type changes colour by itself. Grey wins over both, per Ninad, so a lane with nothing left still reads as spent at a glance.
  • That contradicts the standing reservation of Claude for the operator alone and puts the estate's running costs on Ninad's personal Max plan. Left untouched - another lane's open work is not mine to undo - and reported to Ninad.
  • [delivery-check] 8 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)
  • Bypass review failed — initiative blocked (exec 1315) — Ninad UAT: pay-as-you-go must be AMBER for all and a fixed subscription BLUE for all, on both surfaces - replacing the per-provider colours. (shared.bypass.bypass_review_fail)
  • [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • [delivery-check] 8 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)
  • Bypass review failed — initiative blocked (exec 1318) — Ninad UAT: three of the seven wore no type colour at all, because the spent state discarded the hue. Amber and blue must be worn by ALL of their kind. (shared.bypass.bypass_review_fail)
  • [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • [delivery-check] 8 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)
  • Bypass review failed — initiative blocked (exec 1319) — Ninad UAT: order the boxes fixed plans first, then pay-as-you-go, on both surfaces. (shared.bypass.bypass_review_fail)
  • [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • [delivery-check] 8 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 subscription that has been paid for at least once keeps its box after it is retired, is visibly marked as retired, and shows its last known top-up and balance rather than disappearing. (must_have)
  • Retiring a subscription still removes it from the consumption chart and from every total, so the box's return does not put a dead lane back into the estate's spending. (must_have)
  • Every summary box on both surfaces is coloured by subscription type - green for a fixed monthly plan, yellow for pay-as-you-go - and the colour is derived from the registry's kind, never from a list of names in either page. (must_have)
  • A box with nothing left renders grey regardless of its type colour, so exhausted remains readable at a glance and the type colour never hides it. (must_have)
  • Both surfaces name each subscription identically, and both take that name from the registry's subscription label, proven by a check that fails if either page carries a label of its own. (must_have)
  • A Model Subscriptions box shows exactly two figures - the top-up and the balance - each labelled, with no explanatory prose on the card. (must_have)
  • Whether a figure was READ from the provider or computed here is still distinguishable on the card without prose, and the reading's age is still available to the reader. (must_have)
  • The rendered checks still pass at every supported width, including the no-two-figures-overlap and no-sideways-scroll checks. (must_have)