📖About

Ninad (CLI-234): the three top summary boxes on the Model Subscriptions page are replaced by one box per SUBSCRIPTION - seven today (Claude API, GPT API, DeepSeek, Gemini, ChatGPT Plus + Codex, Kimi, and Claude Max as Ninad's personal lane) - laid out like the provider boxes on the Carol Intelligence page. Each box states the AVAILABLE BALANCE against the LAST TOP-UP that funded it. Ninad's ruling: a flat monthly plan's subscription fee IS its top-up, renewed every month, so a plan lane reads exactly like a prepaid lane. A box whose available balance is zero or negative renders GREYED OUT. The boxes are derived from the page's existing per-subscription composer (the consumption rows that already carry each lane's committed limit, its basis and its consumption for the cycle) - no second resolver, no hardcoded list of seven, so a subscription added or retired in the registry changes the row of boxes with no edit to the page. Where the vendor's own billing surface says the account is out of credit, that vendor statement is the authority on its own balance and the box reads zero rather than an arithmetic remainder that would claim funds a refusing account does not have.

⚖️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] 8 pending must-have criteria stamped met at bypass_end on live re-performance evidence (CAROL-INI-3020): test test_ini3693.py: PASS (12 passed in 2.67s) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [HYGIENE GATE apps_registered] skip: work_type=B does not require app registration (orion.bypass)
• [HYGIENE GATE design_filed] skip: no design_id provided (orion.bypass)
• [HYGIENE GATE architecture_compliance] pass: references architecture design #146 (agent-centric modular architecture) (orion.bypass)
• [HYGIENE GATE policy_check] fail: no policy_ids tagged — caller should explicitly acknowledge applicable policies or waive (orion.bypass)
• [HYGIENE GATE constitution_aligned] pass: soft-default pass; caller responsible for asserting via decision row (orion.bypass)
• [HYGIENE GATE cookbook_entry] fail: no cookbook_id provided — bypass should leave a recipe or explicitly waive (orion.bypass)
• [HYGIENE GATE logbook_entry] fail: logbook session CLI-234: NOT FOUND (orion.bypass)
• [HYGIENE GATE apps_registered] skip: work_type=B does not require app registration (orion.bypass)
• [HYGIENE GATE design_filed] skip: no design_id provided (orion.bypass)
• [HYGIENE GATE architecture_compliance] pass: references architecture design #146 (agent-centric modular architecture) (orion.bypass)
• [HYGIENE GATE policy_check] pass: considered: P.01.03.01.05,P.01.03.01.06,P.01.03.01.07 (orion.bypass)
• [HYGIENE GATE constitution_aligned] pass: soft-default pass; caller responsible for asserting via decision row (orion.bypass)
• [HYGIENE GATE cookbook_entry] pass: cookbook 1215: A flat plan's monthly fee IS a top-up, renewed every cycle (orion.bypass)
• [HYGIENE GATE logbook_entry] pass: logbook session 355: (orion.bypass)
• A flat plan's monthly fee IS its top-up, renewed every cycle — Ninad's ruling when asked what the three flat plans should show, since they have neither a top-up nor a credit balance: 'subscription amount should be presented as top up every month'. So Claude Max, ChatGPT and Kimi read exactly like a prepaid account - fee committed, fee less the cycle's work remaining - and the greying rule reaches them on the same terms. Recorded as cookbook 1215 so the rule outlives this page.
• Seven boxes today, but nothing counts to seven — Ninad asked for seven boxes, one per subscription, and seven is exactly what the registry holds live - DeepSeek and OpenCode are retired (DeepSeek yesterday, CLI-233 / CAROL-INI-3692). The page is therefore built to draw whatever the registry holds, and a regression check feeds it an estate with one subscription added and one retired to prove the row follows. Had seven been written into the page, it would have kept drawing DeepSeek and nothing would have errored.
• OpenAI's own billing surface has been refusing calls since 1 August with '429 insufficient_quota - account out of credit'. A check proves a NON-credit outage (a 500) does not zero a balance, so the rule cannot quietly swallow every provider error.
• One pot has one remainder — Codex runs inside the ChatGPT plan. The chart folds the pair into one row so a fee is drawn once; a box says what a LANE has, so both keep their box - but both quote the SAME fee and the SAME amount left, with Codex's box naming whose plan it is on. Measuring each half against the whole fee would have given one account two different balances, which is cookbook 1126's duplicate: one question derived twice, and the copies do not announce their drift.
• An unmeasured balance greys nothing — A subscription with no top-up on record shows an em dash and stays lit.
• The composer answers it, the page only draws it — The available balance is struck once, in the subscription composer, beside the limit it derives from - and BEFORE the chart's fold, which is the only moment every subscription still exists as itself. A resolver on the page would have been the same question asked twice; a balance struck after the fold could not have produced a Codex box at all, and would have measured the host against usage the fold had already added to it.
• Bypass review failed — initiative blocked (exec 1297) — Ninad UAT 2026-08-06: the page is too broad. Match the screen width to the Carol Intelligence page, which is more elegant at that size. (shared.bypass.bypass_review_fail)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (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)
• Bypass review failed — initiative blocked (exec 1302) — Ninad UAT 2026-08-06: ChatGPT (Plus), Codex and GPT API are not three subscriptions. Codex has no payment of its own - it ships inside the ChatGPT Plus plan - so it was given a box it does not qualify for, and the shared pot's overdraft appeared twice. (shared.bypass.bypass_review_fail)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Codex is a capability, not a subscription — Ninad: 'if there are 3 subscriptions, keep 3, if there are 2, keep 2 - a service is a qualified subscription if I have made payment to that service at least once'. Codex is inside the Plus plan - no fee, no top-up, covered by ChatGPT - so it is a capability he uses, not a service he subscribes to. Unfolding it to reach seven boxes put the same pot on the page twice, each quoting the same EUR -11.65, so one shared plan read as double the deficit.
• Qualification is by evidence of payment, never by a list — A declared monthly fee is a payment made every month; a recorded top-up is a payment made at least once. A lane with neither is riding on somebody else's payment and folds into the plan that pays for it. This also drops OpenCode for the right reason - its billing has never been seen, so no payment is on record - rather than by anyone remembering to exclude it.
• Greying stays uniform, at zero or below — Ninad's call on the question raised last round. A flat plan that has out-earned its fee greys exactly like an empty prepaid account.
• [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)
• SECOND OUTAGE 2026-08-11: the shared chat credential expired at 15:39 and every Codex-lane agent chat (Clara, Leo, Sam) was mute ~7.5h until the operator noticed by hand at ~23:00 — exactly the silent failure this initiative predicts. Cure repeated from 2026-08-10: dated copy kept, fresh operator login installed, apps restarted. Leo additionally crashed on a definition the 2026-08-10 git restore missed (now restored). Detection cannot keep waiting.
• CORRECTION: the previous decision (2026-08-11, chat-credential outage) was posted to this initiative in error — it belongs to CAROL-INI-3778 (Codex Lane Keeper), where it is now recorded. Disregard here.

✅Success criteria

• The Model Subscriptions page renders one summary box per subscription in place of the three former summary cards, and the number of boxes equals the number of subscriptions the page's own per-subscription composer returns (7 at the time of build: Claude API, GPT API, DeepSeek, Gemini, ChatGPT Plus + Codex, Kimi, Claude Max). (must_have)
• The box count and labels are DERIVED from the shared per-subscription composer, not a hardcoded list: adding or retiring a subscription in the registry changes the boxes with no edit to the page markup, proven by a test that feeds the renderer an extra and a removed subscription. (must_have)
• Each box states an available balance in euros and the top-up it is measured against, and names the basis of that top-up (credit available, usual recharge with its date, or a monthly plan fee). (must_have)
• A flat monthly plan presents its subscription fee AS the top-up for the current cycle, per Ninad's ruling, so a plan lane and a prepaid lane read identically. (must_have)
• A box whose available balance is zero or negative is rendered greyed out, and a box with a positive available balance is not; proven at both sides of the boundary including exactly zero. (must_have)
• Where the vendor's own billing surface reports the account out of credit or payment required, the available balance shown is zero and the box is greyed, rather than a positive arithmetic remainder. (must_have)
• An available balance that genuinely cannot be measured is shown as unknown and is never rendered as zero, and never greys the box on the strength of a missing reading. (must_have)
• The page still passes its own regression checks and the new behaviour is covered by a regression test that fails against the pre-change page. (must_have)