Set global engineer cap to 12 and make it KDL configurable #892

Closed
opened 2026-07-09 23:54:04 +00:00 by coilysiren · 3 comments
Owner

Problem

The global engineer container cap is currently hard-coded at 10. That blocks the current merge-queue workflow too aggressively and makes capacity a source-code change instead of operator policy.

Current sites:

  • cmd/ward/agent_reap.go enforces engineerContainerLimit in enforceEngineerContainerLimit.
  • cmd/ward/agent_capacity_test.go pins the 10 running (limit 10) message.
  • docs/FEATURES.md documents the cap as 10.
  • .ward/ward-kdl/ward-kdl.defaults.kdl already carries nearby runtime scheduler knobs like director-max-parallel, so this belongs in the selected smart-defaults/config bundle rather than as a Go literal.

Do

  1. Change the default global engineer cap from 10 to 12.
  2. Add a smart-defaults KDL setting for the global engineer cap, for example engineer-container-limit "12" or the naming that best matches the existing defaults parser.
  3. Resolve enforceEngineerContainerLimit from the effective smart-defaults/config source, with the baked/default value at 12.
  4. Preserve the existing behavior that --print and non-engineer roles are unaffected.
  5. Update tests and docs.

Acceptance

  • With no operator override, the cap is 12 and the error message says limit 12.
  • A selected KDL smart-defaults bundle can set a different cap without editing Go.
  • Tests cover default 12, configured override, below-limit pass, at-limit refusal, and no reservation written when refused.
  • docs/FEATURES.md no longer says the cap is fixed at 10.
  • ward exec test passes, or the issue comment names the exact failing check.

Closes #892 when merged.

## Problem The global engineer container cap is currently hard-coded at 10. That blocks the current merge-queue workflow too aggressively and makes capacity a source-code change instead of operator policy. Current sites: - `cmd/ward/agent_reap.go` enforces `engineerContainerLimit` in `enforceEngineerContainerLimit`. - `cmd/ward/agent_capacity_test.go` pins the `10 running (limit 10)` message. - `docs/FEATURES.md` documents the cap as 10. - `.ward/ward-kdl/ward-kdl.defaults.kdl` already carries nearby runtime scheduler knobs like `director-max-parallel`, so this belongs in the selected smart-defaults/config bundle rather than as a Go literal. ## Do 1. Change the default global engineer cap from 10 to 12. 2. Add a smart-defaults KDL setting for the global engineer cap, for example `engineer-container-limit "12"` or the naming that best matches the existing defaults parser. 3. Resolve `enforceEngineerContainerLimit` from the effective smart-defaults/config source, with the baked/default value at 12. 4. Preserve the existing behavior that `--print` and non-engineer roles are unaffected. 5. Update tests and docs. ## Acceptance - With no operator override, the cap is 12 and the error message says `limit 12`. - A selected KDL smart-defaults bundle can set a different cap without editing Go. - Tests cover default 12, configured override, below-limit pass, at-limit refusal, and no reservation written when refused. - `docs/FEATURES.md` no longer says the cap is fixed at 10. - `ward exec test` passes, or the issue comment names the exact failing check. Closes #892 when merged.
Member

WARD-DISPATCH: failed

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#892 --harness codex --image forgejo.coilysiren.me/coilyco-flight-deck/agentic-os --tag latest
Container: engineer-codex-ward-892
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T004439Z-director-codex-zv98-coilyco-flight-deck-ward-892.log
Failure: ward agent engineer --harness codex: global engineer limit is reached: 10 running (limit 10); wait for a run to finish or run ward agent reap for stale engineers

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

<!-- ward-agent-reservation-released --> <!-- ward-needs-redispatch --> WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#892 --harness codex --image forgejo.coilysiren.me/coilyco-flight-deck/agentic-os --tag latest` Container: `engineer-codex-ward-892` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T004439Z-director-codex-zv98-coilyco-flight-deck-ward-892.log` Failure: `ward agent engineer --harness codex: global engineer limit is reached: 10 running (limit 10); wait for a run to finish or run `ward agent reap` for stale engineers` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
coilyco-ops changed title from limit total warded agents to 20 to Set global engineer cap to 12 and make it KDL configurable 2026-07-10 01:03:15 +00:00
Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T01:03:23Z). 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#892 · branch issue-892 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-ward-892 · ward v0.543.0 · dispatched 2026-07-10T01:03:23Z
  • Comment thread: 1 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.543.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-892` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T01:03:23Z). 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#892` · branch `issue-892` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-892` · ward `v0.543.0` · dispatched `2026-07-10T01:03:23Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T00:45:44Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.543.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default

The in-container review gate was intentionally skipped because review gate skipped by ~/.ward/config.yaml default.

The implementation felt straightforward once the smart-defaults seam was found.
Confidence: high.
Surprises: none beyond the existing generated defaults mirror.
Follow-ups: director merge can land PR #921 once ready.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default The in-container review gate was intentionally skipped because review gate skipped by ~/.ward/config.yaml default. The implementation felt straightforward once the smart-defaults seam was found. Confidence: high. Surprises: none beyond the existing generated defaults mirror. Follow-ups: director merge can land PR #921 once ready. </details>
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
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/ward#892
No description provided.