Resolve frontier built-ins into an effective fleet roster before bootstrap

coilyco-ops commented

2026-07-08 09:49:40 +00:00

Member

Follow-up from #659 under the config-driven ward epic (#650). The advisor recommendation is accepted for implementation: frontier harness launch shapes should be ward-owned built-ins, and the selected ward-kdl.fleet.kdl should act as a sparse override layer.

Do

Add ward-local built-in frontier definitions as typed Go data, keyed by agent name, near the ward agent adapter/bootstrap code. Do not put ward product defaults into shared cli-guard policy.
Add an effective fleet / effective roster merge step:
- built-in frontier default
- top-level bundle agent <name> sparse override
- role overlay for tuning fields
- WARD_* / --config env overrides
Keep non-frontier/local harnesses explicit in KDL. If an agent is not built in, the parsed bundle must still resolve to a complete agent or fail loud.
Keep role overlays limited to tuning fields (model, endpoint, reasoning-effort, verbosity). Structural fields stay top-level only.
If needed, relax cli-guard/pkg/fleetconfig just enough to parse partial top-level agent nodes as data, then perform completeness validation in ward after the effective roster is resolved.
Switch parseMode, adapter projection, bootstrap defaults, and agent-list/manifest reads to the effective roster rather than raw fleet.Agents.

Tests

Update the two-way roster pin to key off the effective roster.
agent claude {} resolves to a complete built-in launch shape.
agent claude { context-level 1 } overrides only that field.
Omitting agent codex still leaves codex available.
A custom non-frontier agent missing binary still fails loud after resolution.
Role overlay beats bundle default, and WARD_* beats role overlay.
Keep the fleet asset mirror drift test intact.

Validate

Run ward exec test in ward.
If cli-guard is touched, land and push that granted repo too before ward lands.

Closes #659 when implemented.

Follow-up from #659 under the config-driven ward epic (#650). The advisor recommendation is accepted for implementation: frontier harness launch shapes should be ward-owned built-ins, and the selected `ward-kdl.fleet.kdl` should act as a sparse override layer. ## Do - Add ward-local built-in frontier definitions as typed Go data, keyed by agent name, near the ward agent adapter/bootstrap code. Do not put ward product defaults into shared cli-guard policy. - Add an effective fleet / effective roster merge step: - built-in frontier default - top-level bundle `agent <name>` sparse override - role overlay for tuning fields - `WARD_*` / `--config` env overrides - Keep non-frontier/local harnesses explicit in KDL. If an agent is not built in, the parsed bundle must still resolve to a complete agent or fail loud. - Keep role overlays limited to tuning fields (`model`, `endpoint`, `reasoning-effort`, `verbosity`). Structural fields stay top-level only. - If needed, relax `cli-guard/pkg/fleetconfig` just enough to parse partial top-level agent nodes as data, then perform completeness validation in ward after the effective roster is resolved. - Switch `parseMode`, adapter projection, bootstrap defaults, and agent-list/manifest reads to the effective roster rather than raw `fleet.Agents`. ## Tests - Update the two-way roster pin to key off the effective roster. - `agent claude {}` resolves to a complete built-in launch shape. - `agent claude { context-level 1 }` overrides only that field. - Omitting `agent codex` still leaves codex available. - A custom non-frontier agent missing `binary` still fails loud after resolution. - Role overlay beats bundle default, and `WARD_*` beats role overlay. - Keep the fleet asset mirror drift test intact. ## Validate - Run `ward exec test` in ward. - If cli-guard is touched, land and push that granted repo too before ward lands. Closes #659 when implemented.

coilyco-ops commented

2026-07-08 09:50:09 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-671 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T09:50:06Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force 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#671 · branch issue-671 · harness codex · workflow direct-main
Run: engineer-codex-ward-671 · ward v0.449.0 · dispatched 2026-07-08T09:50:06Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

Follow-up from #659 under the config-driven ward epic (#650). The advisor recommendation is accepted for implementation: frontier harness launch shapes should be ward-owned built-ins, and the selected `ward-kdl.fleet.kdl` should act as a sparse override layer.

## Do

- Add ward-local built-in frontier definitions as typed Go data, keyed by agent name, near the ward agent adapter/bootstrap code. Do not put ward product defaults into shared cli-guard policy.
- Add an effective fleet / effective roster merge step:
  - built-in frontier default
  - top-level bundle `agent <name>` sparse override
  - role overlay for tuning fields
  - `WARD_*` / `--config` env overrides
- Keep non-frontier/local harnesses explicit in KDL. If an agent is not built in, the parsed bundle must still resolve to a complete agent or fail loud.
- Keep role overlays limited to tuning fields (`model`, `endpoint`, `reasoning-effort`, `verbosity`). Structural fields stay top-level only.
- If needed, relax `cli-guard/pkg/fleetconfig` just enough to parse partial top-level agent nodes as data, then perform completeness validation in ward after the effective roster is resolved.
- Switch `parseMode`, adapter projection, bootstrap defaults, and agent-list/manifest reads to the effective roster rather than raw `fleet.Agents`.

## Tests

- Update the two-way roster pin to key off the effective roster.
- `agent claude {}` resolves to a complete built-in launch shape.
- `agent claude { context-level 1 }` overrides only that field.
- Omitting `agent codex` still leaves codex available.
- A custom non-frontier agent missing `binary` still fails loud after resolution.
- Role overlay beats bundle default, and `WARD_*` beats role overlay.
- Keep the fleet asset mirror drift test intact.

## Validate

- Run `ward exec test` in ward.
- If cli-guard is touched, land and push that granted repo too before ward lands.

Closes #659 when implemented.

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-671` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T09:50:06Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` 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#671` · branch `issue-671` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-671` · ward `v0.449.0` · dispatched `2026-07-08T09:50:06Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` Follow-up from #659 under the config-driven ward epic (#650). The advisor recommendation is accepted for implementation: frontier harness launch shapes should be ward-owned built-ins, and the selected `ward-kdl.fleet.kdl` should act as a sparse override layer. ## Do - Add ward-local built-in frontier definitions as typed Go data, keyed by agent name, near the ward agent adapter/bootstrap code. Do not put ward product defaults into shared cli-guard policy. - Add an effective fleet / effective roster merge step: - built-in frontier default - top-level bundle `agent <name>` sparse override - role overlay for tuning fields - `WARD_*` / `--config` env overrides - Keep non-frontier/local harnesses explicit in KDL. If an agent is not built in, the parsed bundle must still resolve to a complete agent or fail loud. - Keep role overlays limited to tuning fields (`model`, `endpoint`, `reasoning-effort`, `verbosity`). Structural fields stay top-level only. - If needed, relax `cli-guard/pkg/fleetconfig` just enough to parse partial top-level agent nodes as data, then perform completeness validation in ward after the effective roster is resolved. - Switch `parseMode`, adapter projection, bootstrap defaults, and agent-list/manifest reads to the effective roster rather than raw `fleet.Agents`. ## Tests - Update the two-way roster pin to key off the effective roster. - `agent claude {}` resolves to a complete built-in launch shape. - `agent claude { context-level 1 }` overrides only that field. - Omitting `agent codex` still leaves codex available. - A custom non-frontier agent missing `binary` still fails loud after resolution. - Role overlay beats bundle default, and `WARD_*` beats role overlay. - Keep the fleet asset mirror drift test intact. ## Validate - Run `ward exec test` in ward. - If cli-guard is touched, land and push that granted repo too before ward lands. Closes #659 when implemented. ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.449.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-08 09:51:57 +00:00

Config-driven ward: built-in defaults for frontier harnesses - fleet blocks compress, frontier agents need no KDL (#650-7) #659

coilyco-ops referenced this issue

2026-07-08 09:51:57 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops commented

2026-07-08 10:23:34 +00:00

Author

Member

WARD-OUTCOME: done - effective fleet rosters now resolve built-in frontier defaults before sparse bundle and role overlays, and the ward/cli-guard land is merged and pushed.

This went through cleanly once I pinned ward to the landed cli-guard commit. The main friction was a busy remote main and one docs conflict, but the final merge is coherent and the roster tests are green. Confidence is high.

PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.

WARD-OUTCOME: done - effective fleet rosters now resolve built-in frontier defaults before sparse bundle and role overlays, and the ward/cli-guard land is merged and pushed. This went through cleanly once I pinned ward to the landed cli-guard commit. The main friction was a busy remote `main` and one docs conflict, but the final merge is coherent and the roster tests are green. Confidence is high. PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.

coilyco-ops added the

headless

label

2026-07-08 16:35:39 +00:00

coilyco-ops commented

2026-07-09 00:06:38 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-671 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T00:06:36Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL); --force 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#671 · branch issue-671 · harness codex · workflow pr
Run: engineer-codex-ward-671 · ward v0.470.0 · dispatched 2026-07-09T00:06:36Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-08T10:23:34Z)
- stripped: @coilyco-ops (2026-07-08T09:50:09Z)

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-671` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-09T00:06:36Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL); `--force` 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#671` · branch `issue-671` · harness `codex` · workflow `pr` - **Run:** `engineer-codex-ward-671` · ward `v0.470.0` · dispatched `2026-07-09T00:06:36Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-08T10:23:34Z) - stripped: @coilyco-ops (2026-07-08T09:50:09Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.470.0). </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 00:14:07 +00:00

Author

Member

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1

Review panel verdicts:

codex: ERROR: codex: exit status 1 (conf 0.00)
claude: ERROR: claude: exit status 1 (conf 0.00)
goose: ERROR: goose: exit status 1 (conf 0.00)

— Codex, via ward agent

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1 Review panel verdicts: - codex: ERROR: codex: exit status 1 (conf 0.00) - claude: ERROR: claude: exit status 1 (conf 0.00) - goose: ERROR: goose: exit status 1 (conf 0.00)  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 00:17:27 +00:00

Author

Member

WARD-OUTCOME: blocked - review gate failed closed because no reviewer could authenticate.
WARD-REVIEW: block - 0/2 passing (class default)
blocked: codex: exit status 1
The effective-roster refactor and sparse frontier bundle are in place and the ward test suite is green, but the in-container review gate could not get a runnable reviewer and stopped the landing.

WARD-OUTCOME: blocked - review gate failed closed because no reviewer could authenticate. WARD-REVIEW: block - 0/2 passing (class default) blocked: codex: exit status 1 The effective-roster refactor and sparse frontier bundle are in place and the ward test suite is green, but the in-container review gate could not get a runnable reviewer and stopped the landing.

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 00:17:44 +00:00

ward salvage: ward-salvage/ward-6ca05cbd #718

coilyco-ops commented

2026-07-09 00:17:45 +00:00

Author

Member

⚠️ Reopened: this run's work did not land on `main`

An ephemeral ward container (codex mode) dispatched for this issue finished but its work was not merged to main, so the reaper preserved it on a branch before teardown and reopened the issue (a closing reference for #671 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-6ca05cbd
Pull request: not opened - PR creation failed: forgejo: parse created pull request: unexpected end of JSON input
Reason: run workflow does not land on main (--workflow pr/patch-only)
Container uptime at reap: 10m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token)

Reap diagnostics

--- reap diagnostics ---
ward version:      v0.470.0
version source:    pinned via WARD_VERSION/--ward-version (v0.470.0)
HEAD:              01ee91b36df0
origin/main:       a2a544f1a892
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     workflow does not land on main (--workflow pr/patch-only)
reason:            run workflow does not land on main (--workflow pr/patch-only)
provenance:        not read (workflow hold)
run-owned landed:  no
working tree:      clean
container uptime:  10m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-6ca05cbd
git checkout -b ward-salvage/ward-6ca05cbd FETCH_HEAD

— Codex, via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (codex mode) dispatched for this issue finished but its work was **not merged to `main`**, so the reaper preserved it on a branch before teardown and reopened the issue (a closing reference for #671 never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-6ca05cbd` - **Pull request:** not opened - PR creation failed: forgejo: parse created pull request: unexpected end of JSON input - **Reason:** run workflow does not land on main (--workflow pr/patch-only) - **Container uptime at reap:** 10m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token) ## Reap diagnostics ``` --- reap diagnostics --- ward version: v0.470.0 version source: pinned via WARD_VERSION/--ward-version (v0.470.0) HEAD: 01ee91b36df0 origin/main: a2a544f1a892 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: workflow does not land on main (--workflow pr/patch-only) reason: run workflow does not land on main (--workflow pr/patch-only) provenance: not read (workflow hold) run-owned landed: no working tree: clean container uptime: 10m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-6ca05cbd git checkout -b ward-salvage/ward-6ca05cbd FETCH_HEAD ```  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 18:02:04 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-671 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T18:02:02Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force 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#671 · branch issue-671 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-671 · ward v0.493.0 · dispatched 2026-07-09T18:02:02Z
Comment thread: 4 included in the pre-flight read, 2 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-08T10:23:34Z), @coilyco-ops (2026-07-09T00:14:07Z), @coilyco-ops (2026-07-09T00:17:27Z), @coilyco-ops (2026-07-09T00:17:45Z)
- stripped: @coilyco-ops (2026-07-08T09:50:09Z), @coilyco-ops (2026-07-09T00:06:38Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-671` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T18:02:02Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` 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#671` · branch `issue-671` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-671` · ward `v0.493.0` · dispatched `2026-07-09T18:02:02Z` - **Comment thread:** 4 included in the pre-flight read, 2 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-08T10:23:34Z), @coilyco-ops (2026-07-09T00:14:07Z), @coilyco-ops (2026-07-09T00:17:27Z), @coilyco-ops (2026-07-09T00:17:45Z) - stripped: @coilyco-ops (2026-07-08T09:50:09Z), @coilyco-ops (2026-07-09T00:06:38Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

P1

label

2026-07-09 18:09:27 +00:00

coilyco-ops referenced this issue from a pull request that will close it,

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

Resolve frontier built-ins into an effective fleet roster before bootstrap #840

coilyco-ops closed this issue

2026-07-09 18:16:32 +00:00

coilyco-ops commented

2026-07-09 18:16:57 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: review gate skipped by --skip-review / --no-review-gate

Implementation felt straightforward after reusing the branch work already in place. The only surprise was the stale local main, which needed a fast-forward before verification. Confidence is high because the PR merged cleanly and main now matches the fetched remote tip. Follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by --skip-review / --no-review-gate Implementation felt straightforward after reusing the branch work already in place. The only surprise was the stale local main, which needed a fast-forward before verification. Confidence is high because the PR merged cleanly and `main` now matches the fetched remote tip. Follow-ups: none. </details>

coilyco-ops referenced this issue

2026-07-10 00:36:27 +00:00

Make ward agent roles config-defined presets instead of hard-coded names #895

Rows
Columns

Resolve frontier built-ins into an effective fleet roster before bootstrap #671

Do

Tests

Validate

⚠️ Reopened: this run's work did not land on main

Reap diagnostics

Recover

⚠️ Reopened: this run's work did not land on `main`