Sync aosh-selected local harness models into the Ward bundle #617

Closed
opened 2026-07-22 08:57:51 +00:00 by coilyco-ops · 2 comments
Member

Kai selected a new local model batch through aosh, but those selections have not been synced into the AOS Ward bundle that warded containers consume. As a result, local harnesses can keep resolving old embedded/default model names instead of the intended current local model roster.\n\nObserved context on 2026-07-22:\n\n- An Opencode dispatch for coilyco-flight-deck/ward#1502 resolved model: qwen3-coder:30b and failed before agent startup.\n- Current AOS .ward/roles.kdl declares Claude and Codex model overlays for roles, but does not declare Opencode or Goose model overlays.\n- Ward therefore falls back to embedded local-harness defaults for Opencode/Goose instead of a selected AOS-local model roster.\n- The live OpenAI-compatible model endpoint at http://host.docker.internal:8082/v1/models currently advertises models including qwen3-coder-next:latest, qwen3-coder:30b, qwen3:32b, gpt-oss:120b, granite4.1:30b, ornith:35b, and others. The exact intended mapping should come from the aosh-selected batch rather than this director inferring policy from the endpoint list.\n\nDo:\n\n- Find the authoritative aosh-selected model roster and sync it into the AOS-owned Ward config source that containers resolve through WARD_CONFIG_REF.\n- Add explicit local-harness model policy for Opencode and Goose, or document why those harnesses intentionally keep falling back to Ward defaults.\n- Make the sync path repeatable so selecting a new batch in aosh cannot silently diverge from AOS.\n- Add a validation command or test that compares the AOS bundle's selected local-harness models against the live/provisioned model roster and fails clearly on drift.\n- Document the ownership split: aosh selects or records the operator's model batch; AOS publishes the Ward bundle values; Ward consumes those values without embedding Kai-specific policy.\n\nRelated Ward runtime bug discovered during the same launch: coilyco-flight-deck/ward#1503. That issue covers Opencode's smoke test probing a native Ollama route against an OpenAI-compatible endpoint, which can misclassify a present model as stale.

Kai selected a new local model batch through aosh, but those selections have not been synced into the AOS Ward bundle that warded containers consume. As a result, local harnesses can keep resolving old embedded/default model names instead of the intended current local model roster.\n\nObserved context on 2026-07-22:\n\n- An Opencode dispatch for https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1502 resolved `model: qwen3-coder:30b` and failed before agent startup.\n- Current AOS `.ward/roles.kdl` declares Claude and Codex model overlays for roles, but does not declare Opencode or Goose model overlays.\n- Ward therefore falls back to embedded local-harness defaults for Opencode/Goose instead of a selected AOS-local model roster.\n- The live OpenAI-compatible model endpoint at `http://host.docker.internal:8082/v1/models` currently advertises models including `qwen3-coder-next:latest`, `qwen3-coder:30b`, `qwen3:32b`, `gpt-oss:120b`, `granite4.1:30b`, `ornith:35b`, and others. The exact intended mapping should come from the aosh-selected batch rather than this director inferring policy from the endpoint list.\n\nDo:\n\n- Find the authoritative aosh-selected model roster and sync it into the AOS-owned Ward config source that containers resolve through `WARD_CONFIG_REF`.\n- Add explicit local-harness model policy for Opencode and Goose, or document why those harnesses intentionally keep falling back to Ward defaults.\n- Make the sync path repeatable so selecting a new batch in aosh cannot silently diverge from AOS.\n- Add a validation command or test that compares the AOS bundle's selected local-harness models against the live/provisioned model roster and fails clearly on drift.\n- Document the ownership split: aosh selects or records the operator's model batch; AOS publishes the Ward bundle values; Ward consumes those values without embedding Kai-specific policy.\n\nRelated Ward runtime bug discovered during the same launch: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1503. That issue covers Opencode's smoke test probing a native Ollama route against an OpenAI-compatible endpoint, which can misclassify a present model as stale.
Author
Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-opencode-agentic-os-617 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness opencode (reserved 2026-07-22T08:58:36Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)
  • Resolved: coilyco-flight-deck/agentic-os#617 · branch issue-617 · harness opencode · workflow pull-request-and-merge
  • Run: engineer-opencode-agentic-os-617 · ward v0.785.0 · dispatched 2026-07-22T08:58:32Z
  • Reservation: held
  • Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.785.0).

— Qwen, via ward agent

<!-- ward-agent-reservation --> WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-opencode-agentic-os-617` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness opencode` (reserved 2026-07-22T08:58:36Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/agentic-os#617` · branch `issue-617` · harness `opencode` · workflow `pull-request-and-merge` - **Run:** `engineer-opencode-agentic-os-617` · ward `v0.785.0` · dispatched `2026-07-22T08:58:32Z` - **Reservation:** held - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.785.0). </details> </details> <!-- ward-agent-signature --> — Qwen, via `ward agent`
Author
Member

Correction from Kai: Ward should not have an embedded local-model default at all. AOS still needs to sync the aosh-selected model roster into the selected bundle, but this issue should not treat fallback to a Ward-baked Opencode/Goose model as valid or intentional. If the selected bundle / user config / CLI override does not provide a local-harness model, Ward should fail closed with an explicit config error rather than inventing one. I am filing the paired Ward runtime issue separately and will link it here.

Correction from Kai: Ward should not have an embedded local-model default at all. AOS still needs to sync the aosh-selected model roster into the selected bundle, but this issue should not treat fallback to a Ward-baked Opencode/Goose model as valid or intentional. If the selected bundle / user config / CLI override does not provide a local-harness model, Ward should fail closed with an explicit config error rather than inventing one. I am filing the paired Ward runtime issue separately and will link it here.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agentic-os#617
No description provided.