indifferentketchup/boocode
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b18de2a331e9c563dbc7ca5befe4c99b77440f39
boocode/docs/plans/multi-provider-local-models/artifacts/implementation-iteration-history.md
indifferentketchup b18de2a331 chore: snapshot working tree - pty_exited notifications + in-flight inference WIP 
feat(booterm): structured pty_exited WS notifications. Plan-validated, impl-validated, code-reviewed green (contracts build clean, contracts test 29/29, booterm + web typecheck clean).

wip: in-progress inference/provider refactor (agents.ts, provider.ts, new llama-providers.ts, removed llama-args-validator), plus arena, dispatcher, compaction, schema changes.

openspec: pty-exit-notifications complete; x-agent-flags planned (not yet implemented).
2026-06-14 12:48:47 +00:00

3.0 KiB
Raw Blame History

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. The primary plan lives in ../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, ./.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.

Reference in New Issue View Git Blame Copy Permalink