Project scope's stated rationale is the one place its promise outruns delivery (round-2 pilot, ArcavenAE/aae-orc#128, N2 Med). Runbook §2 justifies it as "full self-contained copies (absolute symlinks do not cross machines)" — but three pieces of a project-scope enable are themselves absolute machine paths committed to the repo or required beside it:
- `plugins/` remains an absolute symlink into the machine store
- the hook command in committed `.claude/settings.json` is an absolute store path
- `env.CLAUDE_PLUGIN_ROOT` is an absolute store path
So a teammate checking out a committed project-scope enable gets portable bindings (the copies hold, exec bits verified in the pilot) with dangling registration and compat link.
The structural answer is already scoped as the second-developer verb (bd aae-orc-d3nq.21): a committed repo-side declaration plus a per-machine setup step that writes the machine-specific registration locally. Designing project scope's registration around that split (committed content + hooks referencing ${CLAUDE_PLUGIN_ROOT} unexpanded, per-machine env shim in settings.local.json) would make the committed half genuinely machine-independent.
Short-term, independent of the design work: reword §2 so the rationale matches what project scope delivers today (team gets the content on checkout; each machine still needs the pack installed and the registration is machine-bound).
Project scope's stated rationale is the one place its promise outruns delivery (round-2 pilot, ArcavenAE/aae-orc#128, N2 Med). Runbook §2 justifies it as "full self-contained copies (absolute symlinks do not cross machines)" — but three pieces of a project-scope enable are themselves absolute machine paths committed to the repo or required beside it:
So a teammate checking out a committed project-scope enable gets portable bindings (the copies hold, exec bits verified in the pilot) with dangling registration and compat link.
The structural answer is already scoped as the second-developer verb (bd aae-orc-d3nq.21): a committed repo-side declaration plus a per-machine setup step that writes the machine-specific registration locally. Designing project scope's registration around that split (committed content + hooks referencing ${CLAUDE_PLUGIN_ROOT} unexpanded, per-machine env shim in settings.local.json) would make the committed half genuinely machine-independent.
Short-term, independent of the design work: reword §2 so the rationale matches what project scope delivers today (team gets the content on checkout; each machine still needs the pack installed and the registration is machine-bound).