Why It Works This Way¶
Most of RevFramework explains itself where you find it. The documentation on a method says what it does, why a branch is there and what it deliberately does not handle; each folder carries a README covering the shape of what is inside it. That is where the reasoning lives, next to the thing it governs.
A few choices do not work that way. They are visible in your project long before you reach any explanation of them — and without the explanation they look like mistakes.
What earns a page here
A decision where a developer who does not know the reason would reasonably assume something had gone wrong.
That is a small set, on purpose. Everything else is explained beside the code it belongs to.
Where It Installs
Why the framework lands in Assets/ rather than installing as a package under Packages/ — and what that costs you at upgrade time.
Service Classes
Why the scene components are large files on purpose, what sits underneath them, and how to replace one with your own.
Authority
Why the framework gates mutations but does not implement networking, replication or reconciliation for you.
These are load-bearing choices, not preferences¶
Each of them shaped what the rest of the framework could be. Installing into Assets/ is what makes deleting a system a supported operation. The size of the service classes is what lets one file show you a whole flow. Stopping short of networking is what keeps the same systems usable in a single-player prototype and a server-authoritative build.
You are free to disagree with any of them — and in each case the page says what disagreeing costs you, because that is the part that decides whether the trade suits your project.
The reason this section exists
A decision you cannot see the reasoning behind is indistinguishable from an accident. These are the ones where that would matter.