workflow: Present renames as staging choices#111
Merged
Conversation
Live staging works from text hunks, binary file changes, and submodule pointer changes. Path-only renames are not represented as their own selected change, so rename detection has to stay disabled in live diff streams. Users who rename a file see the operation through lower-level path effects instead of a single old-to-new choice. That makes pure renames hard to review, and it gives rename-plus-edit changes no structural step before the content hunks. This commit begins making rename review a first-class workflow by adding a rename change model, parsing rename metadata from diffs, caching selected rename state, and teaching show, status, include, skip, and discard how to act on rename choices. Follow-up commits add parser coverage, live workflow coverage, staged-rename startup handling, and automation preflight support.
The test suite has parser coverage for text hunks, binary files, and submodule pointers, plus file-pattern coverage for ordinary changed paths. Rename entries are not asserted as selected diff items. Rename support changes the shape of parsed diffs and changed-file discovery. Without targeted coverage, a future change could collapse renames back into path effects or hide one side of a rename from file selection. This commit addresses that by asserting pure renames and rename-plus-edit diffs yield rename items, and by checking changed-file discovery returns both paths from an unstaged rename. The next test commit covers the live command workflow that stages structural renames separately from destination content edits.
Atomic rename parsing gives the live diff stream a rename item, but command coverage also needs to prove that sessions select that item and route it through include behavior. Rename-plus-edit workflows have two separate decisions: the path movement and the later destination content hunks. Without command coverage, include could stage both pieces at once or leave the index in a lower-level delete and add state. This commit addresses that by starting a session on an unstaged rename and asserting the selected change is a RenameChange. It also verifies include stages only the structural rename while leaving destination edits unstaged. The next implementation commit extends the same rename workflow to renames that are already staged before a session starts.
Interactive functional tests drive the TUI by sending fixed input sequences. Several of those sequences stage changes and then quit, while the quit path asks whether staged changes should be kept. Tests that stop at the quit action depend on EOF handling instead of naming the intended branch of that prompt. That can leave the subprocess waiting for confirmation even though the assertion expects staged changes to remain. This commit addresses that by sending the explicit keep response in the interactive scenarios that stage changes before quitting. The following implementation commits add staged-rename startup handling and the unstaged-workflow preflight command.
The assistant workflow guide shows how to split a refactor that combines a rename with logic changes. The example still describes selecting line IDs from a mixed hunk to capture the path movement. Live sessions now surface the structural rename as its own old-to-new choice before later destination content hunks. Keeping the old example would send assistant workflows toward a lower-level staging path than the command now presents. This commit updates the refactoring example to include the selected rename prompt directly and then handle later logic changes in a separate pass. The next implementation commit extends rename selection to sessions that begin with a rename already staged in the index.
Live sessions can now present unstaged renames as atomic choices, while the index is still treated as the baseline for worktree review. A rename that is already staged before the session starts remains outside that baseline and is not offered for staging decisions. Users with an otherwise unstaged workflow can still arrive with a staged rename from Git commands or earlier tooling. Refusing that case blocks a valid rename-only split, while ignoring it leaves the session unable to review the change. This commit records staged rename metadata at session start, resets those paths back to the baseline for review, and restores untouched normalized renames during stop or abort. The next commit adds session tests for start, stop, and abort around those normalized staged renames.
Live rename tests cover the normal unstaged path, but they do not exercise sessions that begin with a rename already staged in the index. Staged renames are a boundary case for an unstaged-only workflow because they are valid session input only when start can normalize them safely. Missing coverage would leave stop and abort restoration behavior vulnerable to independent regressions. This commit addresses that by adding staged-rename workflow tests for start, include, stop, and abort. The tests assert that untouched start-time renames are restored and consumed renames are not reintroduced after workflow use. The next docs commit records the staged-rename behavior in the command reference before the preflight command is introduced.
The command reference describes session startup, but it does not explain how rename selections appear or what happens when a rename is already staged before start runs. Users need to distinguish a rename prompt from later content edits under the destination path. They also need to know that an untouched staged rename is restored by session cleanup instead of being silently dropped. This commit documents the old-to-new rename prompt, the include, skip, and discard choices for that prompt, and the stop and abort restoration behavior for untouched start-time staged renames. The next implementation commit adds the preflight command used by automation before starting unstaged-only sessions.
Sessions can normalize staged renames once they begin, but automation still needs to decide whether starting an unstaged-only pass is allowed. The main start command is not a pure probe because it creates session state. Scripts that split unstaged work need a command that separates an index with no staged entries, an index containing only normalizable renames, and an index with other staged content. Without that distinction they must start too early or duplicate rename checks outside the tool. This commit adds check-unstaged and wires it into the CLI. The command accepts an index with no staged entries and staged renames that start can normalize, while rejecting other staged content with exit code 2. The next commit adds coverage for the command dispatch and index-state outcomes.
The staged-rename session tests cover start, include, stop, and abort, but they do not exercise the preflight command that automation uses before starting an unstaged-only session. The command has to distinguish an index with no staged entries, normalizable staged renames, and other staged content. Parser coverage also has to confirm that the new subcommand dispatches to the guard. This commit adds check-unstaged tests for the accepted and rejected index states, plus CLI dispatch coverage for the new command. The next docs commit records the preflight command before the bundled assistant guidance adopts it.
The command reference now explains staged rename startup, but automation users also need a documented way to inspect the index before starting an unstaged-only pass. The preflight command is intentionally separate from start because start creates session state. Documentation should make the accepted staged-rename case and the rejected staged-content case visible at the command boundary. This commit adds the check-unstaged reference entry, including the success cases and the exit code used when other staged content is present. The remaining commits update the bundled assistant skills to call the preflight command before starting their unstaged workflows.
The bundled Claude unstaged-commit skill checks for staged changes before starting a session. It treats any staged content as a blocker because the workflow did not have a tool-owned way to distinguish normalizable staged renames. That guidance now rejects a case that start can handle. Claude users who ask the skill to split unstaged work with a staged rename in the index would be told to stop even though the session can expose that rename as workflow content. This commit addresses that by teaching the Claude skill to call check-unstaged and to continue when the command reports only staged renames that start can normalize. The final commit applies the same preflight guidance to the Codex skill asset.
The bundled Claude skill now uses check-unstaged before starting an unstaged-only session. The Codex skill still describes the older index check and treats every staged rename as a blocker. Codex users need the same staged-rename exception as the Claude workflow because both skills drive the same git-stage-batch commands. Divergent guidance would make one automation surface reject a session that the other can handle. This commit completes the staged-rename workflow documentation by teaching the Codex skill to call check-unstaged and to continue when the command reports only staged renames that start can normalize. The series now supports atomic rename choices, staged-rename session startup, preflight probing, and the bundled automation guidance around that workflow.
halfline
force-pushed
the
rename-workflow-preflight
branch
from
54f2b42 to
0c15853
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.
Live staging now detects rename metadata instead of forcing rename handling
through lower-level path effects. Users see an old -> new prompt for pure
renames and rename-plus-edit cases, and include, skip, and discard act on
that structural choice before later content hunks.
Sessions can normalize renames that were already staged at start time. The
session records the staged rename metadata, resets those paths for review,
and restores untouched staged renames during stop or abort.
Automation now has check-unstaged as a preflight for unstaged-only
workflows. The command accepts an index with no staged entries and staged
renames that start can normalize, while rejecting other staged content with
exit code 2.
Validation: