Add --override-capacity opt-in past the OOM pool ceiling; rename --force to --override-reservation #1091

Merged
coilyco-ops merged 2 commits from issue-1045 into main 2026-07-10 22:18:27 +00:00
Member

closes #1045

ward.workflow: pull-request-and-merge

What

Establishes the --override-* flag family on the engineer dispatch path, keeping the two override axes distinct:

  • --override-reservation - the renamed --force: reclaim a stale or foreign per-issue reservation hold. --force stays as a hidden deprecated alias that prints a one-line deprecation notice on first use.
  • --override-capacity - new: launch exactly one engineer past the OOM pool ceiling, with a loud stderr WARNING naming the true N+1/N count. It never stacks (a pool already past the ceiling refuses even with the flag), and neither override ever implies the other.

Decisions made in impl

  • The one-launch bound is enforced structurally instead of an acknowledged-count argument or interactive confirm: --override-capacity only admits a launch from exactly at-capacity (N/N -> N+1), and refuses a pool already past the ceiling. That keeps the flag headless-safe while still impossible to stack by muscle memory.
  • The director gets the matching --override-reservation propagation flag (its --force also hidden + aliased) but deliberately not --override-capacity: the capacity override is a per-launch operator decision, and a loop knob that auto-exceeds the OOM ceiling is exactly the footgun ward#1045 fences off.
  • The dispatch broker approves and forwards each spelling as typed (--force stays approved) for version-skew safety across container/host ward versions.
  • The other gates --force used to open (closed-issue re-dispatch, interactive-label override) move with the rename to --override-reservation, so the deprecated alias carries no unique power.

Acceptance mapping

  • Reservation override against a full pool still refuses: the capacity check runs before reservation and only reads --override-capacity.
  • --override-capacity at N/N launches with WARNING: launching over the engineer OOM ceiling (N+1/N) - host may thrash or OOM.
  • Independence covered by TestOverrideReservationFlagFamily; default full-pool dispatch unchanged (ward#1041 fail-fast path untouched).
  • Help text names each axis narrowly; reservation comments, refusal messages, and the skill reference now say --override-reservation.
closes #1045 ward.workflow: pull-request-and-merge ## What Establishes the `--override-*` flag family on the engineer dispatch path, keeping the two override axes distinct: * `--override-reservation` - the renamed `--force`: reclaim a stale or foreign per-issue reservation hold. `--force` stays as a hidden deprecated alias that prints a one-line deprecation notice on first use. * `--override-capacity` - new: launch exactly one engineer past the OOM pool ceiling, with a loud stderr `WARNING` naming the true N+1/N count. It never stacks (a pool already past the ceiling refuses even with the flag), and neither override ever implies the other. ## Decisions made in impl * The one-launch bound is enforced structurally instead of an acknowledged-count argument or interactive confirm: `--override-capacity` only admits a launch from exactly at-capacity (N/N -> N+1), and refuses a pool already past the ceiling. That keeps the flag headless-safe while still impossible to stack by muscle memory. * The director gets the matching `--override-reservation` propagation flag (its `--force` also hidden + aliased) but deliberately **not** `--override-capacity`: the capacity override is a per-launch operator decision, and a loop knob that auto-exceeds the OOM ceiling is exactly the footgun ward#1045 fences off. * The dispatch broker approves and forwards each spelling as typed (`--force` stays approved) for version-skew safety across container/host ward versions. * The other gates `--force` used to open (closed-issue re-dispatch, interactive-label override) move with the rename to `--override-reservation`, so the deprecated alias carries no unique power. ## Acceptance mapping * Reservation override against a full pool still refuses: the capacity check runs before reservation and only reads `--override-capacity`. * `--override-capacity` at N/N launches with `WARNING: launching over the engineer OOM ceiling (N+1/N) - host may thrash or OOM`. * Independence covered by `TestOverrideReservationFlagFamily`; default full-pool dispatch unchanged (ward#1041 fail-fast path untouched). * Help text names each axis narrowly; reservation comments, refusal messages, and the skill reference now say `--override-reservation`.
Establish the --override-* flag family on the engineer dispatch path, keeping
the two override axes distinct:

- --override-reservation is the renamed --force: reclaim a stale or foreign
  per-issue reservation hold. --force stays as a hidden deprecated alias that
  prints a one-line notice on first use.
- --override-capacity is new: launch exactly one engineer past the OOM pool
  ceiling, with a loud stderr warning naming the true N+1/N count. It never
  stacks - a pool already past the ceiling refuses even with the flag - and
  neither override ever implies the other.

The director grows the matching --override-reservation propagation flag (its
--force also aliased + hidden) but deliberately not --override-capacity: the
capacity override is a per-launch operator decision, not a loop knob. The
dispatch broker approves and forwards each spelling as typed for version-skew
safety. Reservation comments, refusal messages, and the skill reference now
name --override-reservation. Default full-pool dispatch still fails fast
locally per ward#1041.

closes #1045

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Merge remote-tracking branch 'origin/main' into issue-1045
All checks were successful
test / test (pull_request) Successful in 29s
cbaceabb84
Sign in to join this conversation.
No description provided.