Use workspaces with clear boundaries

The repository contains the package and a demo app; the app depends on the workspace package by its package name. That contrast gives us something useful to test instead of a rule to memorize.

Workspaces coordinate installation and scripts, but each workspace still needs correct dependencies, exports, and packed contents. 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 rely on hoisted dependencies that the package never declares and still get one successful demo. Push past the demo. declare dependencies in the workspace that imports them and test packed packages outside the workspace layout, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Develop the package against a real consumer and make build and test behavior reproducible from a clean checkout. Save the before-and-after evidence now; it will make the final project review much more honest.

Run a production install for each workspace and locate one dependency that was accidentally available only through hoisting. Save the evidence, then explain which requirement would force you to choose a different design.