**Findings**

- Resolved: install state is now keyed by concrete `install_id`, and reusable plugin assets live under the shared download cache instead of per-install state.

- Medium-high: dependency handling is intentionally thin. `Dependency.constraint` exists in [models.py](/home/pleb/ops/beatsaber/plugin-helper/src/plugin_helper/models.py:10), but [planner.py](/home/pleb/ops/beatsaber/plugin-helper/src/plugin_helper/planner.py:68) only expands required dependency IDs and does not enforce constraints, conflicts, `loadAfter`, `loadBefore`, BeatMods version-id closures, or “provides” relationships. That is the next big unlock for package-manager behavior.

- Medium: the agent skills have a few stale or conflicting operational rules. The manager skill still tells agents to inspect/edit `registry/plugins.toml` in [.agents/skills/beatsaber-plugin-manager/SKILL.md](/home/pleb/ops/beatsaber/plugin-helper/.agents/skills/beatsaber-plugin-manager/SKILL.md:54), while the project has moved to `registry/plugins/*.toml`. The builder skill says PR checkouts go under `<state_dir>/build` in [.agents/skills/beatsaber-plugin-builder/SKILL.md](/home/pleb/ops/beatsaber/plugin-helper/.agents/skills/beatsaber-plugin-builder/SKILL.md:24), while `AGENTS.md` says GitHub plugin source checkouts should live under `~/src/<owner>/<repo>`. That will make agents inconsistent.

**Skills**

I would not collapse the three skills into one. They are conceptually different:

- `beatsaber-plugin-manager`: mutating install/update/bootstrap workflow.
- `beatsaber-plugin-update-auditor`: read-mostly audit/report workflow.
- `beatsaber-plugin-builder`: source build workflow.

But I would consolidate shared policy into references, then have each skill import that mental model:

- `references/repo-workflow.md`: repo root, `.venv`, `PYTHONPATH=src`, dirty worktree rules, validation commands.
- `references/state-and-profiles.md`: `.state`, profiles, install identity, source checkout location.
- `references/artifact-policy.md`: GitHub first, BeatMods metadata/fallback, private sources, checksum policy.
- `references/live-validation.md`: smoketest and process cleanup.

That removes duplicated drift while preserving good trigger boundaries.

**Design Direction**

Yes, the script design is useful. The best parts are exactly the right bones for a real package manager: registry, locks, dry-run plans, hash checks, managed install state, bootstrap as its own phase, update audit, and known-good sets.

The next shape I’d aim for is:

- `packages/registry`: identity, source aliases, install strategy, metadata extraction rules.
- `versions/locks`: selected package versions/artifacts/evidence for each Beat Saber version.
- `cache/downloads`: content-addressed artifacts reusable across installs.
- `installs/<install_id>`: installed packages, transactions, bootstrap, known-good generations, backups.
- commands like `resolve`, `fetch`, `plan`, `apply`, `rollback`, `audit`, `verify`.

Beat Saber plugins are heterogeneous in packaging, but homogeneous enough in runtime shape (`Plugins`, `Libs`, `IPA/Pending`, root BSIPA files) that this can become a nice small package manager. The trick is to normalize artifacts into a planned file tree before touching the game.

Validation: `compileall` passed, and `unittest discover` passed: 75 tests, 1 skipped.