📖About

NINAD, 2026-08-04 (CLI-226), choosing this over hand-editing 70 per-droid pins: "Wire the track into the resolver - this seems to be less temporary out of the 2".

THE RULE EXISTS AND WAS NEVER BUILT. Cookbook 1165 says THE TRACK CARRIES THE SUBSCRIPTION, never a task and never a per-droid pin, so a new droid inherits its lane BY CONSTRUCTION. MEASURED 2026-08-04: the resolver's precedence is explicit argument -> per-droid pin -> one global fleet default, and it reads the track NEVER. Nothing in the estate connects a track's declared lane to the call that actually gets made.

WHAT THAT COST, measured not asserted:

• 24 of 36 tracks currently "match" their declaration only because DeepSeek happens to be the fleet default. That is a coincidence, not a wiring.
• The other 12 depend entirely on 70 hand-written per-droid pins in the protected config.
• So the ONLY layer anybody could change without a core install was the DISPLAY. That is the mechanical reason a previous session updated Carol Intelligence to Ninad's prescription and left the workloads on the old models - the exact failure he named this session, and it was structural rather than careless.
• Every Codex pin also carries a fallback to the metered OpenAI account Ninad has decided not to fund.

SCOPE. 1. resolve_provider gains ONE step, between the per-droid pin and the fleet default: the lane declared by the track this caller serves. Precedence becomes explicit argument -> pin -> TRACK -> fleet default. A pin still wins, because a pin is a deliberate exception; the fleet default still catches anything belonging to no track. 2. Read, never inferred, and fail-open on everything - a registry hiccup falls through to the fleet default rather than stalling a caller, the same contract every other step already keeps. Cached briefly because this is a hot path. 3. Rule 1077 is preserved: a chat pin still outranks the track, and the chat tracks declare Codex anyway. 4. PROVEN BY RUNNING: a caller on a Codex track resolves to Codex, a caller on a Gemini track to Gemini, and a caller belonging to no track still gets the fleet default.

WHY A CORE INSTALL. shared/llm_provider.py is root-owned protected core. The alternative Ninad rejected - rewriting 70 pins - is also a core install, is fragile, and drifts again the next time a droid is added. This one makes every future prescription of his a registry change with no code at all.

OUT OF SCOPE. The 70 existing pins (they still win by design; auditing which are now redundant is its own pass). Budgets.

⚖️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] 5 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 caller on a Codex-declared track resolves to Codex without any per-droid pin, proven by running the resolver. (must_have)
• A caller on a Gemini-declared track resolves to Gemini the same way. (must_have)
• A caller belonging to no track still gets the fleet default, so nothing that worked before stops. (must_have)
• An existing per-droid pin still wins over the track declaration. (must_have)
• A registry that cannot be read falls through to the fleet default rather than stalling a caller. (must_have)