Decision: docs/plans/2026-09-06-provider-connections-and-harnesses.md (planning issue #6359). Retain executable provider IDs for all saved selections; durable connection IDs are management-only. This is implementation work, separate from the planning deliverable.
Build pure transport/model-name adapters and a read-only import preview for existing provider records. Show proposed connections/bindings and unresolved custom configurations, without writing a graph or changing execution. Automatically group only proven same-harness CLI/TUI siblings; cross-harness sharing requires a later explicit link.
Areas: server/lib/aiToolkit/internal/providerModes.js, server/lib/aiToolkit/providers.js, server/routes/providers.js; host adapter and validation/catalog entries as needed.
Acceptance:
- Define and validate version-1 management DTOs, model aliases and explicit mode eligibility from the decision.
- Preview Claude Ollama, OpenCode Ollama and separate remote Ollama API using synthetic fixtures; compare actual server-side credentials only, never redacted values.
- Dynamic/unknown config, differing paths/auth/env and ambiguous model aliases remain isolated with reasons.
- Preserve every original route ID, active mode, settings, pin and unknown field; flat provider API stays unchanged.
- Preview/boot/configuration makes no generation calls or runtime launches; boundary test catches this.
- No graph persistence/migration or management UI in this slice.
Part of #6359
The parent is a completed planning deliverable, not an implementation epic; do not reopen it.
Review clarifications: Bindings include revision and variantKey. Enforce unique (binding_id, mode) and (connection_id, harness_id, variant_key), with a partial uniqueness index for null-harness API bindings. Import custom same-mode routes as distinct labeled variants; never merge away executable IDs. Link validates revisions for binding, source connection and target connection; unlink validates binding and source. On downgrade reconciliation, remove route-binding rows for deleted providers without resurrecting them; saved pins remain unresolved and empty connections await explicit cleanup.
Decision: docs/plans/2026-09-06-provider-connections-and-harnesses.md (planning issue #6359). Retain executable provider IDs for all saved selections; durable connection IDs are management-only. This is implementation work, separate from the planning deliverable.
Build pure transport/model-name adapters and a read-only import preview for existing provider records. Show proposed connections/bindings and unresolved custom configurations, without writing a graph or changing execution. Automatically group only proven same-harness CLI/TUI siblings; cross-harness sharing requires a later explicit link.
Areas: server/lib/aiToolkit/internal/providerModes.js, server/lib/aiToolkit/providers.js, server/routes/providers.js; host adapter and validation/catalog entries as needed.
Acceptance:
Part of #6359
The parent is a completed planning deliverable, not an implementation epic; do not reopen it.
Review clarifications: Bindings include revision and variantKey. Enforce unique (binding_id, mode) and (connection_id, harness_id, variant_key), with a partial uniqueness index for null-harness API bindings. Import custom same-mode routes as distinct labeled variants; never merge away executable IDs. Link validates revisions for binding, source connection and target connection; unlink validates binding and source. On downgrade reconciliation, remove route-binding rows for deleted providers without resurrecting them; saved pins remain unresolved and empty connections await explicit cleanup.