Nowhere is it stated that the same Development Team absolutely must start every project building two layers at a time, i.e., a "framework layer" and "implementation layer". Layers are meant to be built one at a time.
It is not necessary to create something you want to call a "framework layer class" and a completely different "implementation layer class" when you start developing an Application.
You can create a class that serves as both your "framework" and "Implementation" class initially.
Only if and when the need arises to have a second implementation-layer class do you need to create a second implementation layer class.
Prior to creating that second class you would create a "wrapper" Application for your first implementation. First you create a ruleset that declares a dependency the ruleset in which the current framework/implementation class was created -- temporarily adding it to your current Application. Next save the current Application to that ruleset renaming the Application appropriately. After doing so, modify the new Application to say it is built on the current Application then remove every ruleset except the newly created one. Finally remove that new ruleset from the original Application. Easy,
From this point on, being that there are now two implementations dependent on the same frameworkruleset, care must be taken whenever changes are made that framework ruleset. This is no different than making changes to a base class that multiple classes extend.
Note that the first implementation Application need not override the framework Application's Case Type rules. The second implementation Application cannot avoid having to override the framework's Case Type rules since it has a different class.
Improving what I said earlier " The second implementation Application cannot avoid having to override the framework's Case Type rules since it has a different class."
If your second framework-extending implementation application is hosted within an entirely separate database, then ruleset-override is again sufficient to achieve specialization.
It is not always necessary to use inheritance to specialize an application, hence no need to ever define a framework application with class names that contain "-FW-".
If you do host a second framework-extending implementation application within the same database, then either pattern- or direct-inheritance specialization would be needed. The new classes, of course, would be defined in rulesets different from the rulesets used by the framework layer.