Separate dependency roles

A library plugin declares its host framework as a compatible peer instead of installing a second private copy. That contrast gives us something useful to test instead of a rule to memorize.

Dependency sections describe ownership: runtime code needs dependencies, maintainers need devDependencies, and host integrations often use peers. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can move packages between sections only to silence an installation warning and still get one successful demo. Push past the demo. trace every import into the published runtime and decide whether the package or consuming application owns that dependency, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Make dependency and version choices that communicate compatibility rather than merely making installation succeed. Save the before-and-after evidence now; it will make the final project review much more honest.

Audit the project after a production-only install and after packing; explain every dependency section entry. Save the evidence, then explain which requirement would force you to choose a different design.