coilyco-flight-deck/ward

Fork 0

Support Goose model selection through the standard agent config API #1314

New issue

Closed

opened 2026-07-15 04:44:49 +00:00 by coilyco-ops · 6 comments

coilyco-ops commented

2026-07-15 04:44:49 +00:00

Member

The Goose harness is selectable with --harness goose, but the model does not appear as a first-class option on the same config API used for other harness model selection.

Required behavior:

The same model override API must work for Goose: --config agent.goose.model=<model>.
The Goose model value must pass through unchanged to the runtime backend, whether the target is Ollama directly or agent-proxy in front of Ollama.
Do not add a Goose-only spelling or side channel. The operator should not need a different API for Goose than she uses for Claude, Codex, or OpenCode model-context knobs.
Unknown config keys should still fail loud. agent.goose.model should become a known key in the same validation path as the existing agent model overrides.
ward agent engineer --help, ward agent director --help, and any relevant docs should show Goose in the model override examples or describe the generic agent.<harness>.model shape.
Add focused tests that prove agent.goose.model is accepted, survives config resolution, and is forwarded to the Goose launch environment/arguments without being normalized or replaced.

Context: Kai noticed Goose was available as a harness but not as an obvious model option. She wants model selection through the exact same API passed through to Ollama and agent-proxy.

The Goose harness is selectable with `--harness goose`, but the model does not appear as a first-class option on the same config API used for other harness model selection. Required behavior: * The same model override API must work for Goose: `--config agent.goose.model=<model>`. * The Goose model value must pass through unchanged to the runtime backend, whether the target is Ollama directly or agent-proxy in front of Ollama. * Do not add a Goose-only spelling or side channel. The operator should not need a different API for Goose than she uses for Claude, Codex, or OpenCode model-context knobs. * Unknown config keys should still fail loud. `agent.goose.model` should become a known key in the same validation path as the existing agent model overrides. * `ward agent engineer --help`, `ward agent director --help`, and any relevant docs should show Goose in the model override examples or describe the generic `agent.<harness>.model` shape. * Add focused tests that prove `agent.goose.model` is accepted, survives config resolution, and is forwarded to the Goose launch environment/arguments without being normalized or replaced. Context: Kai noticed Goose was available as a harness but not as an obvious model option. She wants model selection through the exact same API passed through to Ollama and agent-proxy.

coilyco-ops added the

headless

labels

2026-07-15 04:44:49 +00:00

coilyco-ops commented

2026-07-15 04:45:26 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1314 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T04:45:26Z). 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/ward#1314 · branch issue-1314 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1314 · ward v0.697.0 · dispatched 2026-07-15T04:45:13Z
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.697.0).

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1314` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T04:45:26Z). 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/ward#1314` · branch `issue-1314` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1314` · ward `v0.697.0` · dispatched `2026-07-15T04:45:13Z` - **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.697.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-15 04:59:10 +00:00

Author

Member

WARDED_WORKFLOW: #1317

details

workflow: pull-request-and-merge; review summary: skipped - review gate intentionally skipped because the temporary ward default pending brokered QA
retrospective: the Goose path was narrower than it first looked once the shared config API was traced end to end.
confidence: high
surprises: the existing Goose config composer already handled verbatim model values once it was fed from RunCtx.
follow-ups: none

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1317 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped - review gate intentionally skipped because the temporary ward default pending brokered QA retrospective: the Goose path was narrower than it first looked once the shared config API was traced end to end. confidence: high surprises: the existing Goose config composer already handled verbatim model values once it was fed from RunCtx. follow-ups: none </details>

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 05:14:46 +00:00

coilyco-ops added the

coherence-core

label

2026-07-15 05:28:23 +00:00

coilyco-ops commented

2026-07-15 06:54:31 +00:00

Author

Member

Release triage note from Kai on 2026-07-15: headless carry is valid. The implementation should use the exact same model-selection API shape passed through to Ollama and agent-proxy, then make Goose consume that shared model config rather than a separate option surface.

coilyco-ops commented

2026-07-15 07:09:09 +00:00

Author

Member

P1 triage from Kai on 2026-07-15: close this issue. PR #1317 reported the implementation path, and this release pass should not keep it open as further implementation work.

coilyco-ops closed this issue

2026-07-15 07:09:09 +00:00

coilyco-ops commented

2026-07-15 07:16:41 +00:00

Author

Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 07:16:49 +00:00

Author

Member

WARD-TRIAGE: coherence-core label

This issue is part of the coherence-core review set for the warded control plane coherence sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy.

Core does not mean broader scope. Keep the implementation narrow, verify current main before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

WARD-TRIAGE: coherence-core label This issue is part of the `coherence-core` review set for the `warded control plane coherence` sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy. Core does not mean broader scope. Keep the implementation narrow, verify current `main` before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.