# Implementation Iteration History: Multi-Provider Local Models

This file records how the implementation plan was assembled from the existing research, OpenSpec docs, and codebase review.
Committed decisions live in [implementation-decision-log.md](implementation-decision-log.md). The primary plan lives in
[../feature-implementation-plan.md](../feature-implementation-plan.md).

## R1: Coordinator pass grounded in source docs and local code review

- **Specialists engaged:** coordinator-only pass using the existing research note, OpenSpec design/tasks, implementation analysis, root and app `CLAUDE.md` files, ADRs, coding standard, and targeted code search. No separate specialist tool round was run in this repo pass.
- **New input provided:** [../build-phase-outline.md](../build-phase-outline.md), [./.discovery-notes.md](./.discovery-notes.md), the OpenSpec batch, and the current code seams in server, web, and coder.
- **Claim ledger:**

  | # | Claim | State | Spec-maturity |
  |---|---|---|---|
  | C1 | There is no single source of truth for local providers shared by server and coder | Evidenced | plan-level |
  | C2 | Composite `provider/model` ids are required for duplicate model names across hosts | Evidenced | plan-level |
  | C3 | Routing logic is duplicated across streaming, non-streaming, context, compaction, task-model, and Arena | Evidenced | plan-level |
  | C4 | Favorites belong in settings plus client derivation, not in the server catalog | Evidenced | plan-level |
  | C5 | Native BooCoder can adopt the shared resolver before `opencode` can | Evidenced | plan-level |
  | C6 | The current `opencode` bridge collapses local identity and needs a provider-preserving gateway | Evidenced | plan-level |
  | C7 | Arena is a separate local-model consumer and must be planned explicitly | Evidenced | plan-level |
  | C8 | BooControl depends on this substrate and should not be built first | Evidenced | plan-level |

- **Open Questions raised:**
  - OQ-1: shared local-provider authority format and location
    Resolution: D-1, `/data/llama-providers.json` plus `LLAMA_PROVIDERS_PATH`
  - OQ-2: canonical local model identity format
    Resolution: D-2, composite `provider/model`
  - OQ-3: how to achieve external-agent parity honestly
    Resolution: D-6, `boocode-local` gateway
  - OQ-4: whether add-a-machine is UI-driven in this batch
    Resolution: D-7, no, keep config-driven

- **Spec-maturity tags:** all findings were plan-level. No spec-stage reopening was required because the earlier research and OpenSpec docs already settled the behavior.
- **Resolution source:** evidence from source docs plus current code inspection.
- **Decisions produced:** D-1, D-2, D-3, D-4, D-5, D-6, D-7, D-8.
- **Changed in plan:** initial authoring of `feature-implementation-plan.md` and its three supporting artifacts.
- **Next-step recommendation:** go to synthesis. The work is ready to execute as W1 through W8 in order, with W7 as the main hard seam and W8 as the operational closeout.