fix(continuation): #988 fast-follow — spawn-init cap-notice (P2-2) + maxPendingWork config-docs baseline (P2-3)#991
Merged
scribe-dandelion-cult merged 2 commits intoJun 11, 2026
Conversation
…arly-return (#988 P2-2) The spawn-init / turn-1 lane (scheduleSpawnInitContinueWorkWake) emitted the multi-election cap-notice AFTER the `scheduledCount === 0` early-return, so a session already at the pending/chain/cost cap before a multi-continue_work response (scheduledCount:0, cappedCount>0) stayed silent — even though each tool call already reported status:"scheduled". The main-reply (agent-runner) and followup (followup-runner) lanes both surface this partial cap-drop. Move the cap-notice emit above the early-return so the never-silent symmetry holds across all three election lanes for the scheduledCount:0 && cappedCount>0 case. Multi-election only, preserving single-work behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ccumulated schema drift (#988 P2-3) #988 added the public config key agents.defaults.continuation.maxPendingWork to the zod schema but did not regenerate docs/.generated/config-baseline.sha256, so `pnpm config:docs:check` failed on any checkout with deps. The baseline had also not been regenerated since 2026-06-08 (fc6400e), so several intervening schema-surface changes (qqbot command toggle, tui host-footer gate, imessage, codex, continuation maxPendingWork) had accumulated as drift across the core, channel, and plugin baselines. Regenerate the baseline via `config:docs:gen` (deterministic, env-normalized) so the hash reflects the current schema surface and `config:docs:check` passes. No help-text/describe added for maxPendingWork: its continuation cap siblings (maxChainLength, costCapTokens, maxDelegatesPerTurn) carry no .describe()/help/ label and are not in the schema.help.quality TARGET_KEYS gate, so maxPendingWork already matches the sibling shape. Adding asymmetric help to only this key would diverge from the family. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
602e20b
into
frond-scribe/20260609/assembly-token-wiring
129 of 143 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fast-follow for the two trivial Codex P2s on #988 (the flood-guard, merged). Neither blocks the merged code; both are corpus-hygiene.
P2-2 — spawn-init lane cap-notice fires before the zero-scheduled early-return
src/agents/command/attempt-execution.ts: in the spawn-init / turn-1 path, when a session was already at the pending/chain/cost cap before a multi-continue_workresponse,scheduleContinuationWorkBatchreturnsscheduledCount: 0with a positivecappedCount— but the early-return on zero-scheduled exited above the cap-notice emit, so the spawn-init lane stayed silent on the cap-drop (unlike main-reply + followup, which surface it — the #985-residual symmetry that8858d25b802partially closed).Fix: emit the multi-election cap-notice before the zero-scheduled early-return → the never-silent symmetry now holds across all three election-paths (subagent-init / main-reply / followup). +2 tests (RED-verified).
P2-3 — maxPendingWork config-docs baseline regen
#988added the public config keymaxPendingWorkbut did not regeneratedocs/.generated/config-baseline.sha256, sopnpm config:docs:checkwas failing (baseline stale since 2026-06-08 across core/channel/plugin). Fix: regenerated the baseline →config:docs:checknow passes.Help-text note (fork resolved): the workorder suggested adding field help-text "matching siblings," but the continuation-cap siblings (
maxChainLength/costCapTokens/maxDelegatesPerTurn) have no.describe()/help/label and none are in theschema.help.qualityTARGET_KEYS gate — somaxPendingWorkalready matches the family shape. Added no asymmetric help (it would diverge from the cap-family). Symmetric help for the whole cap-family is a separate optional polish, out of this fast-follow's scope.Gate status
attempt-execution.continue-work-optsGREEN (9/9, incl the 2 new P2-2 tests).pnpm config:docs:checkPASSES (P2-3).Review
🪨 Rune + 🌊 Ronan (continuation-lifecycle review-pair). Off assembly tip
3084bf16fc; merges clean (no overlap with the parallel #989-P2-1 reset-gate lane).Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com