Skip to content

fix: bound the conductor's context-park to a measured figure (2.6.5) - #760

Open
warren830 wants to merge 1 commit into
awslabs:v2from
warren830:fix/issue-547-unbounded-context-park
Open

fix: bound the conductor's context-park to a measured figure (2.6.5)#760
warren830 wants to merge 1 commit into
awslabs:v2from
warren830:fix/issue-547-unbounded-context-park

Conversation

@warren830

Copy link
Copy Markdown

Summary

The conductor parks workflows because context feels heavy, and it has no way to know whether it is. The orchestrator skill licensed parking "when you are running low on context mid-loop" — an unmeasurable trigger. The conductor cannot read its own token count, so it guessed from conversation length, and guessed conservatively.

The reporter measured 37% of a 1M window used, 63% free. The framework's own statusline paints that same reading green: core/hooks/aidlc-statusline.ts contextColor() turns yellow at ≥50 and red at ≥75. So the conductor was parking while the framework's own instrumentation said there was nothing wrong — and the user paid an /aidlc --resume handshake every one or two stages for it.

Fixes #547.

Changes

Implements option 2 from the issue — a numeric guardrail rather than removing the capability:

  • Parking for context now requires a usage figure the harness actually surfaced, at or above 80%. That floor sits above the statusline's own red line (75), so the two can never contradict each other.
  • Absent such a figure, the conductor keeps running stages. Having no number is not evidence of pressure.
  • Parking on how context feels is named and forbidden, with the measured counter-example in the prose so the next reader sees why the bound exists.

Applied to all seven harness orchestrator skills (claude, codex, copilot, cursor, kiro, kiro-ide, opencode). Each file's surrounding prose is preserved exactly — codex legitimately has no "Tell the user their work is saved" sentence, and still doesn't.

Deliberately unchanged: the user-initiated park, and the rule that parking beats fabricating a done. This removes one bad trigger, not the feature — a conductor that genuinely needs to stop still has the safe exit.

User experience

Long workflows stop interrupting themselves. An enterprise-scope run that previously parked every one or two stages now continues until the user asks to stop, the harness reports real pressure, or the workflow reaches done.

Checklist

  • I have read the contributing guidelines
  • I have performed a self-review of my code
  • I have tested my changes
  • I have documented my changes (CHANGELOG entry)

Test Plan

New tests/smoke/t291-context-park-bounded.test.ts (43 assertions, mechanism none, asserts against authored harness/ source rather than dist/, following the t250 house pattern). Per harness it pins:

  • the unbounded running low on context clause is gone and cannot regress back in
  • parking on how context feels is forbidden
  • the skill states the conductor cannot measure its own context window
  • a number survivesat or above 80% plus the surfaced-figure requirement. A bound with no figure is not a bound, so this is the assertion that actually protects the fix.
  • the conductor is told to keep going when it has no figure
  • the user-initiated park and the anti-fabrication rule are still present

The HARNESSES list is an explicit literal, not a glob, so adding a harness without extending this guard fails loudly instead of silently skipping.

Verified locally (bun 1.3.11; CI pins 1.3.14):

bun scripts/package.ts && bun scripts/package.ts --check   # exit 0, 7 trees in sync
bun tests/gen-coverage-registry.ts --check                 # OK (fresh, guards green, ratchet held)
bun run check                                              # exit 0
bun tests/run-tests.ts --smoke --unit --parallel 8

Suite result is identical to the pre-change baseline on this branch point — the same 2 files fail (t248-codekb-scope-diff, t255-workspace-sync, both unrelated to orchestrator prose; t255's are ~5s timeouts on live git remote queries and look environmental here) with the same 9 assertions. t119 (SKILL.md 500-line ceiling) still passes with headroom.

Version bumped to 2.6.5: #754 and #758 both claim 2.6.3, and #759 claims 2.6.4.

Related

A durable follow-up — plumbing the context_window.used_percentage the statusline hook already receives into something aidlc-orchestrate next can surface, so park could refuse below the threshold rather than relying on prose — is a larger change and intentionally out of scope here. This PR closes the reported regression without it.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

The orchestrator skill licensed parking "when you are running low on
context mid-loop". That trigger is unmeasurable: the conductor has no
access to its own token count, so it guessed from conversation length and
guessed conservatively. Reported in the field at 37% of a 1M window used
with 63% free — a reading the framework's own statusline paints GREEN
(contextColor(): yellow >=50, red >=75). The user paid an /aidlc --resume
handshake every one or two stages.

Replaces the unbounded clause with the bound the reporter asked for:

- park for context ONLY on a usage figure the harness actually surfaced,
  at or above 80% (above the statusline's red line, so the two cannot
  contradict each other)
- absent such a figure, keep running stages
- parking on how context *feels* is explicitly forbidden

The user-initiated park is untouched, as is the rule that parking beats
fabricating a `done`. Applied to all seven harness orchestrator skills.

Adds tests/smoke/t291-context-park-bounded.test.ts: pins that the
unbounded licence cannot regress back in, and that the replacement keeps a
numeric floor (a bound with no figure is not a bound).

Fixes awslabs#547

@apackeer apackeer left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warren, this PR addresses #547 by tightening context-based workflow parking across all seven harness orchestrator skills. It requires a harness-surfaced usage figure at or above 80%, keeps user-requested parking and the anti-fabrication rule intact, and regenerates the corresponding distributions.

Direction: sound. The reported problem exists on origin/v2: every orchestrator skill licenses parking when context merely seems low, while the only numeric context signal is consumed by the statusline hook and never reaches the conductor or orchestration engine. The per-harness skill layer is the correct authored surface, and applying the policy to all seven harnesses matches the scope of the existing rule.

I have one change request:

  1. tests/smoke/t291-context-park-bounded.test.ts:36 claims its explicit seven-name list will fail when a new harness is added without extending this guard, but the test only iterates that fixed list. An eighth manifest-backed harness would be silently skipped and the test would remain green. Please derive the set from the repository's manifest-discovered HARNESS_MATRIX, or compare the literal against the discovered set so the stated exhaustiveness guarantee is real.

UX-wise, this is consistent with the existing workflow: commands, flags, stage names, errors, user-requested parking, and resume syntax are unchanged. Users simply stop receiving premature park/resume interruptions unless the harness has surfaced at least 80% usage.

Non-blocking follow-up: this remains a prose guardrail, so nothing deterministic makes park reject a below-threshold request. The larger engine plumbing is reasonably out of scope here, but please file the follow-up described in the PR body before #547 closes so it remains tracked.

Verification was otherwise clean: bun scripts/package.ts --check passed for all seven distributions; our targeted run at tests/logs/2026-08-14T09-04-31Z-p2 reports Result: PASS for 4 files and 72 assertions; the independent reviewer also passed the full smoke tier at tests/logs/2026-08-14T09-08-57Z-p177266 with 14 files and 1657 assertions; the coverage registry is fresh; and the 2.6.5 version, CHANGELOG heading, and README badge are synchronized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants