Feedback: Driver systemd unit names (pr-loop-driver-issue<N>) carry no repo slug, so multi-repo loops on one host collide on shared issue numbers

[robercano]

Observed

Driver systemd unit names (pr-loop-driver-issue) carry no repo slug, so multi-repo loops on one host collide on shared issue numbers

Expected

(fill in if different from observed)

Severity suggestion

medium — silent stall or cross-repo ledger mis-classification, but only when two armed repos hit the same issue number concurrently

---

Origin repo: robercano/reDeFi
Installed plugin version: 0.3.0
Filed via /orchestrator:feedback (issue #177).

[robercano]

Detail from the reDeFi session that surfaced this.

Root cause

driver_unit_name() / verdict_from_unit_name() (scripts/loop-daemon.sh:421-430 / :449-461) derive
the transient unit name purely from the verdict — pr-loop-driver-issue<N>, pr-loop-driver-pr<N>,
pr-loop-driver-cifix-pr<N>, etc. There is no repo slug anywhere in the name; grep -n 'repo_slug\|slug' scripts/loop-daemon.sh returns nothing. arm-loop.sh slugs the daemon units (pr-loop-<slug>.service,
claude-rc-<slug>.service, arm-loop.sh:199-200) but that scoping stops at the daemon — it never reaches
the drivers the daemon spawns.

Since systemctl --user is a single manager per login, every armed repo on a host shares one driver
namespace.

Three repo-blind sites

1. driver_unit_active() (scripts/loop-census.sh:539-541) — checks the bare unit name. Repo A's
   census sees repo B's pr-loop-driver-issue42 as active and suppresses advancing A's own issue feat(ci): run self-adapter gates on PRs (closes #25) #42.
   Fails silently as a stall, not an error.
2. reattach_orphaned_drivers() (scripts/loop-daemon.sh, via list_active_driver_units()) — globs
   pr-loop-driver-* across the whole user manager on daemon startup. A restarting daemon re-attaches to a
   sibling repo's driver, waits on it, appends a ledger entry for it, and for an advance issue=N verdict
   runs verify_and_classify_post_exit against its own working tree — where no such branch exists, so
   the sibling's work can be classified as debris in the wrong repo's ledger. This is the damaging one.
3. loop-halt.sh --drivers (scripts/loop-halt.sh:54) — same glob; stops every driver on the host
   across all repos, which is probably not what an operator in one repo expects.

Reproduction / blast radius

Only bites when two armed repos hold the same issue number concurrently. Observed on this host with
three armed repos (pr-loop-recode, pr-loop-redefi, pr-loop-redeploy all active):

repo	open issues
reDeFi	1-50
reDeploy	153, 154, 157, 158
reCode	115, 132-227

reDeFi is clear of both siblings, but reDeploy #157 and reCode #157 are both open right now — a live
collision pair the moment both daemons dispatch on their respective #157.

Suggested fix

Thread the repo slug through the unit name (e.g. pr-loop-driver-<slug>-issue<N>). driver_unit_name and
verdict_from_unit_name are documented as exact inverses, so it's a symmetric change to that pair plus the
two glob sites (list_active_driver_units, loop-halt.sh) and the bare-name lookup in
driver_unit_active. Worth deciding whether loop-halt.sh --drivers stays host-wide (with the repo shown
per unit) or becomes repo-scoped with an explicit --all-repos escape hatch.

Unrelated, noticed while filing

feedback.sh's guard 3 rejected the first invocation with "is the orchestrator plugin installed in this
repo?" purely because CLAUDE_PLUGIN_ROOT is not exported into the Claude Code Bash tool's environment
(skills/feedback/feedback.sh:130) — the manifest was present the whole time. The skill doc tells the agent
to invoke via ${CLAUDE_PLUGIN_ROOT:-.claude}, which resolves in the caller's argument but leaves the var
unset inside the script, so the .claude fallback the doc implies never applies to the manifest lookup.
Re-running with the var exported worked. Happy to split this into its own issue if useful.