reorg-sync

/reorg-sync

Goal

After a tree moves, absolute-path references left behind break silently. This skill sweeps them in one pass, reporting first and rewriting only on explicit confirmation.

What it sweeps (5 classes)

Steps

1. Report (dry-run — always first)

bash "${CLAUDE_PLUGIN_ROOT}/core/infra/reorg-sync.sh" \
  --old <old-prefix> --new <new-prefix> --root <tree>

Read the CLASS file:line <text> rows and the per-class summary with the user. The tool refuses six input shapes outright, each a proven corruption/injection hazard:

• a bare / or empty --old (would match everything);
• a relative --old/--new (both must be /-leading — a slash-less OLD is byte-identical to its own encoded key form and would double-match both axes);
• any --old/--new containing a line separator — not just \n but every character Python's splitlines() honors (\r \v \f \x1c-\x1e \x85 U+2028 U+2029), any of which would inject lines into swept files on apply;
• a promote-up move (--old under --new, e.g. /old/sub → /old): after one apply, a migrated ref and a fresh /old/sub ref are byte-identical, so no stateless rewrite can be idempotent — a re-run eats one path component per pass, which is data corruption. A real reorg moves children individually; run one sweep per moved child instead. (Decision 2026-08-10, superseding the earlier "make promote-up rewrite" direction.) The refusal is per axis: the encoded-key forms of OLD/NEW are checked too, and because enc() preserves characters like : and space, a move can be a promote-up on the key axis alone (/a.b:c → /a/b gives keys -a-b:c / -a-b) — refused with a key-axis message. Identity (--old X --new X, including trailing-slash spellings) is not a promote-up: it is accepted and reports an honest 0, as does the key axis of a rename that changes only / . _ (whose keys encode identically);
• a suffix-overlap ("demote") move — --new occurs inside --old at any offset ≥ 1 followed by a path boundary or OLD's end (as a suffix /srv:/app → /app, /a/b → /b; or strictly inside: /srv:/app/bin → /app), or a proper suffix of --old equals a boundary-terminated proper prefix of --new (partial: /a/b → /b/c): the mirror of promote-up. After one apply, pre-existing text ending in OLD's leading remainder followed by the written NEW is byte-identical to a fresh OLD ref, so each re-apply eats one leading component per pass (reproduced on every boundary character). Sweep with a more specific --old, or move through an intermediate name sharing no boundary-anchored affix with either side. (/proj → /proj/inner is not this shape — extends-moves stay supported via the protected-span guard. /data/appx → /app is not either: a non-boundary junction after the embedded NEW cannot re-match.) Unlike promote-up, this family is checked on the path axis only: a key-axis straddle is unconstructible (the key matcher is pinned by its fixed-width claude/projects/ lookbehind), so key-suffix-overlapping moves like /x/a_b → /a/b (keys -x-a-b / -a-b) sweep normally;
• a cross-axis overlap — --old contains claude/projects/ followed by a boundary-terminated prefix of the encoded --new key (/home/u/.claude/projects/-a-b → /a/b, whose key is -a-b): the key rewrite writes that key immediately after the same literal context, so one --apply manufactures a byte-exact fresh --old path reference and the next pass destroys the migrated key. This is the one constructible cross-axis straddle direction (key-on-key and key-on-path provably cannot occur). In practice it means the memory-dir tree itself (~/.claude/projects/...) cannot be swept as --old when the destination's key collides this way — move it under a different name first.