fix: bound the conductor's context-park to a measured figure (2.6.5) - #760
fix: bound the conductor's context-park to a measured figure (2.6.5)#760warren830 wants to merge 1 commit into
Conversation
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
left a comment
There was a problem hiding this comment.
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:
tests/smoke/t291-context-park-bounded.test.ts:36claims 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-discoveredHARNESS_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.
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.tscontextColor()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 --resumehandshake every one or two stages for it.Fixes #547.
Changes
Implements option 2 from the issue — a numeric guardrail rather than removing the capability:
Applied to all seven harness orchestrator skills (
claude,codex,copilot,cursor,kiro,kiro-ide,opencode). Each file's surrounding prose is preserved exactly —codexlegitimately 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
Test Plan
New
tests/smoke/t291-context-park-bounded.test.ts(43 assertions, mechanismnone, asserts against authoredharness/source rather thandist/, following the t250 house pattern). Per harness it pins:running low on contextclause is gone and cannot regress back inat 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
HARNESSESlist 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):
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_percentagethe statusline hook already receives into somethingaidlc-orchestrate nextcan surface, soparkcould 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.