rebase-validatelisted

# Rebase Validation — Five-Layer Pipeline Validate a git rebase for lost code, duplicate blocks, broken refs, and stale references using five complementary layers. No single tool catches all rebase regressions — the value is in layered defense. ## When to Use - After completing any rebase with conflict resolution - After `git rebase --update-refs` on a stacked branch set - When comparing a rebased branch against the original - When the user suspects code was lost or duplicated during rebase ## Quick Start If the user just finished a rebase and wants validation, run this sequence: ``` Step 0: Verify refs (are we comparing the right things?) Step 1: git range-diff -s (commit overview — seconds) Step 2: sem entity-level diff — MCP (mcp__sem__sem_diff) or CLI, if available Step 3: weave preview target (merge readiness — if weave is available) Step 4: jscpd + duplicate grep (token-level — catches what sem misses) Step 5: project validation suite (functional oracle) ``` Always run Step 0 first. After Step 0 completes, Steps 1-4 can run as parallel agents. Step 5 is the final oracle. On agents without a parallel-Agent tool, run Steps 1-4 sequentially — they're independent. ## Step 0: Verify Refs Before ANY comparison, confirm refs point where expected. A broken ref makes every subsequent comparison meaningless. ```bash # Confirm branch positions git rev-parse --short <rebased-branch> git rev-parse --short <original-branch> # Confirm ancestry git merge-base --is-ancestor <