Support planning more steps when previous are still running - #47
Merged
Merged
Conversation
replanCard no longer refuses with chain-busy while a card's steps are still running — the re-plan turn is its own conversation on the card, not part of the chain, so it can run alongside a live step. A NEW refusal, `planning`, covers the case that actually needs blocking: a second re-plan while one is already queued, running, or sitting in the inbox as a plan-approval (`Scheduler.replanPending`). `Run`/`startTask` opts gain `replan`, so `settle` can tell a re-plan run apart from an ordinary one: a re-plan that comes back `done` never had any work of its own to land, so it skips chain.workWritten and the integration path entirely and just returns the card to `in-progress`. A failed re-plan is unaffected and still goes through `handleRunFailure`. packages/ui's canReplan and REFUSAL_HINT follow the same split. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extracts settle's landing block (open PR / auto-merge / offer the Merge button, chain hand-back, plan write-back) into landWork(ctx), shared with a new landHeld(cardId). When a chain's last pending step finishes while a re-plan for the same card is still in flight, settle now holds that landing in heldLandings instead of racing it against whatever the human is about to approve — the step is marked done and a note is filed saying so. landHeld replays the held context once the plan resolves: approvePlan drops the hold and lets the chain continue when the plan adds steps, or lands it when the plan adds nothing; startPendingReplan and the 'exited' handler land it too when a queued or live re-plan declines to start; stopTask converts a held landing into a Merge offer instead of leaving it stranded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds splitStepPhases to boardColumns.ts: the current phase is the first round with an unfinished step, or the last round once everything is done. splitEarlierSteps is reimplemented on top of it, gaining a flattened `later` alongside its existing `earlier`/`latest`. TaskCard grows a mirrored later-steps row (chevron, "N upcoming steps", 0/N, attention tint but no running dot) beside the existing earlier-steps one, threaded through KanbanColumn and both boards (MyTasks, BoardScreen) via a new `shownLaterStepCards` setting. TaskSteps' phase list now renders earlier/current/later using the same split, fixes the current phase's dead chevron by rendering it as plain text instead of an inert toggle, and relabels "Round N" to "Phase N" throughout (including approvePlan's timeline comment). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
`task:replan` takes an optional `replaceRound`: the round must exist and every one of its steps must still be pending/stopped, or the ask is refused with `phase-started`. Approving the plan swaps the round's steps via the new `Store.replaceSubtaskRound` (one transaction: delete the round's steps, insert the replacements at the same round, renumber every subtask's order) — unless the phase started while the plan sat waiting, in which case it lands as a new round after it instead, with a comment explaining why. The panel gets a "Re-plan…" button on each later phase's header, reusing the existing note form. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a sixth scenario to verify-round.mjs proving replaceSubtaskRound
against a real database: seed a card with phases 1-3, replace phase 2,
and confirm getSubtasks reads phase 1, the new phase 2, phase 3 in
that order, with the old round's rows gone.
Fixes a typecheck error the gates caught along the way: landWork's two
readyToIntegrate.set calls spread projectId twice ({ projectId:
project.id, ...ctx }), which TS2783 flags as always-overwritten — ctx
already carries projectId (LandingContext is PendingIntegration), and
project is looked up BY ctx.projectId, so the two were always the same
value. Both call sites now just pass ctx.
Replaces docs/03's "Re-planning folds the previous bunch by itself"
passage with a "Phases" section covering the three independent folds,
planning ahead beside a live chain, re-planning a future phase in
place, and a chain holding its landing while a plan is pending.
Adds a "Phase" entry to docs/05-glossary.md beside Subtask (step).
Bumps apps/client/package.json to 0.100.0 (MINOR: new user-facing
capability, per CONTRIBUTING §4).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
wdembinski
force-pushed
the
feat/support-planning-more-steps-when
branch
from
September 13, 2026 09:19
de079ca to
6311f1c
Compare
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.
As a user I want to be able to plan next steps in parallel, even though the currently existing steps are still running.
This feature should work the same as usual - in the main task Details Panel user clicks on Plan more steps. The main session then plans next steps while previous sessions are still running in their own sessions.
Check if it's supported, if not, design and implement.
Each group of steps must be somehow grouped and displayed as a group. At this moment, the newest batch of newly planned steps, are displayed on the task's card. All previous steps are folded but user can click on their row to expand. So each group should be a phase. The currently running phase should be shown, the previous folded as earlier at the top and the next groups/phases folded as future at the bottom.
User should be able to re-plan the future phases.