You're right your question is too vague. If you really want advice for structuring the code you need to be able to more clearly specify what your needs for a system are and what your current problems are with respect to implementing or designing that system.
That said, your plan strikes me as a bad idea. For two main reasons:
- You have no budget. This means you're basically bleeding money in opportunity cost (that is, the time you're spending producing this game that's currently making you no money is time that could be spent doing something that directly makes you money).
- You can't answer the very basic questions about the design of this framework, which strongly suggests you're trying to build a system too far beyond your scope and which encapsulates requirements you don't actually need or haven't actually defined.
I think you'll be better off simply working directly on your game. Don't work on a "generic framework," it's going to take more time in the long run as you struggle with problems you don't actually need to have and thus decrease the net profitability of your game. A "generic" framework that hasn't actually been proven to be generic enough to ship multiple games on won't fetch a very high price as middleware, and similarly reusable code is only useful if it's actually resuable and proven to be so... claiming that you're writing it doesn't make it so, and you generally need to put it through it's paces anyway to know whether or not it is.
Instead, focus on writing the game you want to write. Refactor things as you go and notice you could make them reusable across different aspects of the game. You'll ship sooner, and once you ship and start making money you can take a breather, assess what you want to do next and what the strengths and weakness of your codebase are (based on what you learned while making an actual game), and take the reusable parts forward to your next game.