Preserve refactoring validation guidance after rebase

Restore the focused one-operation workflow and remove broad worktree restore advice after integrating current main.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 8c45529b-2515-483d-9e51-e6c0b7cb6852
This commit is contained in:
Abhitej John
2026-09-14 17:33:07 -07:00
parent 3b8d365179
commit f152c7a5d2
@@ -93,21 +93,29 @@ injection, configuration binding, source generators, P/Invoke, or `dynamic`.
Confirm behavior is preserved after the edit — scaled to blast radius, not a fixed ceremony:
- **Local / private** (method-local or `private` member, one file, single target framework, no public
surface, no `partial`/generated/`#if`): build once and run the **relevant** tests once after the edit.
If the tree is already known-green, don't burn a second full "before" baseline — rely on the post-edit
gate. Let the compiler catch missed references.
surface, no `partial`/generated/`#if`): skip a separate baseline unless the tree is already suspect.
Make the edit, then run the narrowest build and relevant tests once. Let the compiler catch missed
references.
- **Cross-boundary** (public/shipped symbol, multi-targeted project, `#if`/platform branches, or
`partial`/generated code): establish a baseline, then run an explicit build and the relevant tests for
**each** target framework after the edit (a test command's implicit build is not separate build evidence;
a green default build can hide a break on another TFM), and run the hazards check below.
Use the repo's own build/test workflow when it documents one (`README`/`CONTRIBUTING`, `build.*`, `eng/`,
`global.json`, `.github/workflows`); its instructions win over any generic command. Otherwise:
`global.json`, `.github/workflows`); its instructions win over any generic command.
### Typical workflow (one operation)
1. Choose one named refactoring operation and keep the step focused on that operation only.
2. Find true binding references (`findReferences`/`goToDefinition`/rename) and include all `partial` declarations.
3. Establish a baseline first only for a cross-boundary change or a tree not already known green.
4. Apply the change via the most semantics-aware tool available; avoid blind find/replace when possible.
5. Rebuild and run the relevant tests. If the gate goes red, report the failure and repair or reassess only
your edit; never discard unrelated worktree changes.
Otherwise:
```bash
dotnet build # 0 errors
dotnet test # stays green; same pass count as before
git restore . # if the gate fails, revert THIS step and reassess
```
One operation per step; never mix a refactor and a behavior change in the same step. On red, stop and report the failure; repair only your edit without discarding unrelated worktree changes.