📖About

Today LLM models (llm_rates rate card), providers + active-provider + ringfence (llm_config.json), and model-subscription plans (subscription_plans.json) live in scattered config files outside the SST. Make them first-class registry.db tables (llm_providers, llm_provider_ringfence, llm_models, llm_model_aliases, model_subscription_plans, model_subscription_topups, llm_settings), add a shared accessor, seed from the current config, and repoint every consumer (Carol Intelligence, Model Subscriptions app, Token Cost Tracker, pipeline card, provider-selection module) to read from the registry. Secrets stay out of the registry; registry reads fall back to JSON and writes mirror to JSON so the disconnect switch and Carol voice never break. Update the SST with the new tables.

⚖️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)
• Current state at filing (Elrond validity check): The SST is registered and apps (Carol Intelligence, Model Subscriptions, Token Cost Tracker, Pipeline) are all running but still read LLM models, providers, and subscription plans from scattered config files. No registry tables exist yet. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 1 must-have criteria remain pending at bypass_end — delivery FAILED live re-performance; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): test test_ini3090.py: FAIL (no tests ran in 2.50s) (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

• New registry tables (llm_providers, llm_provider_ringfence, llm_models, llm_model_aliases, model_subscription_plans, model_subscription_topups, llm_settings) exist and are seeded to match the current config exactly (must_have)
• A shared accessor reads models/providers/plans/ringfence/active-provider from the registry, falling back to the JSON config on any read error (must_have)
• Ringfence enforcement and active-provider selection (including the disconnected sentinel) behave identically before and after, sourced from the registry (must_have)
• Rate card and compute_cost source rates from the registry while preserving resolve_model alias and startswith semantics (no cost silently drops to zero) (must_have)
• Carol Intelligence, the Model Subscriptions app, the Token Cost Tracker and the pipeline card all read model/provider/plan data from the registry (must_have)
• The SST is rescanned and reflects the new registry tables (must_have)
• Regression tests covering the registry-backed models/providers/plans are registered and pass (must_have)