Consumer repos carry stale vendored .claude/scripts that shadow the fresh plugin cache — manage them or stop vendoring

[robercano-ghbot]

Problem

reDeploy (onboarded 2026-07-06) has a full vendored copy of the loop scripts in its own .claude/scripts/. Nothing updates them:

• setup/sync manage exactly 4 files (feature-fanout.js, 2 systemd units, arm-loop.sh); every other vendored script is invisible to /orchestrator:sync and drifts forever.
• resolve-roots.sh deliberately makes the repo-tracked <x>/.claude/scripts layout WIN over the plugin cache — correct for self-hosting and worktree gate runs, but it means a stale vendored copy permanently shadows a fresh plugin install.

Evidence (2026-07-16): reDeploy's loop-daemon.sh predates the #111 phantom classifier, the #119 transient driver units, AND the #131 --working-directory fix — its loop is exposed to three bug classes already fixed upstream, while its plugin cache (0.2.1, refreshed the same morning) has current code sitting unused.

Decide + implement one of

1. Stop vendoring: consumer repos keep NO local script copies (delete at sync; systemd units + hooks reference ${CLAUDE_PLUGIN_ROOT}/scripts/...), so the plugin cache is the single source of truth; or
2. Manage the whole script set: add every shipped script to the MANAGED_FILES tables (setup + sync) with version markers, so /orchestrator:sync re-stamps them.

Either way, /orchestrator:sync should detect-and-warn about unmanaged stale copies it finds.

Caveat for the migration

A consumer's loop daemon holds the OLD loop-daemon.sh in memory until its service restarts — refreshing files on disk is not enough; the sync flow must tell the user to restart the unit between drivers (cf. the 2026-07-16 reCode deploy-lag incident, #131).

🤖 Generated with Claude Code

[robercano]

Let's go for option 1, stop vendoring, but make the sync skill to detect if the files have changed in case we need to support the case