Where It Installs¶
RevFramework arrives as a .unitypackage and lands in Assets/RevFramework, rather than installing as a package under Packages/.
That is partly the Asset Store's delivery path and partly a choice. The choice is not about whether you can read the source — an embedded UPM package is readable and editable too. It is about what you are expected to do with it.
The short version
A package is installed and updated as one unit. RevFramework is not consumed as one unit — it is meant to be read, cut down, and built on top of, in the ordinary Unity project you already have.
You are meant to remove parts of it¶
Delete a system you don't use and the rest still compiles. Clear Samples/, Teaching/ and Documentation/ before a build — or let Pre-Build Clean archive them for you — and the runtime is unaffected.
That is not a tolerated edge case; it is the normal way to use this framework, and it is checked every release. A package you have deleted half of is no longer a package that can be updated, so the delivery mechanism has to be one where removing things is expected rather than fought.
The package layout would hide the parts that teach¶
Under Packages/, samples sit behind an Import button and documentation lives in a folder Unity never displays at all.
The sample scenes, the Teachable Panels and the guides are a large part of what you are buying. They belong in the Project window, where you will open them by accident on the way to something else — which is most of how anyone learns a codebase.
The trade, stated plainly¶
A new version is re-imported over your copy.
Keep your own work outside Assets/RevFramework
Your scripts, prefabs and scenes should live elsewhere in the project. Do that and an update is uneventful. Put them inside the framework folder and an update becomes a merge.
This is the cost of installing into Assets/, and it is the one thing worth setting up correctly on day one.