<requirements>
	1. Implement the OMPEval poker hand evaluator algorithm
		a. This must be run every time the GTO solver is started
		b. You must ensure that the map it generates is accurate
		c. The OMPEval system must be a separate module from the actual solver interface
			i. It should be able to be used for general purposes throughout the solver.
	2. Implement the MCCFR algorithm in order to create the poker solver.
		a. When opening the poker solver, a hand for the in position + out-of-position player must be selected
		b. Ranges for the in position player and out-of-position player must be provided
			i. These ranges will include ranges of cards (22-AA, A5o-AKo) for example
			ii. These ranges must allow percentage of opens (AJo@50) for example
			iii. As a default example, assume 6max UTG (OOP) vs BTN (IP caller) single raise pot
			iv. Add a button in order to add the two default ranges.
		c. The GTO solver should run progressively
			i.  For example, user must select a flop and action begins with OOP.
				1. Action will allow user to bet 25%, 40%, 80%, or 120%, or check
				2. Action will then move onto IP, who can bet 50%, 80%, or 120%, raise 2.5x, or check / call.
				3. The same logic will apply to the turn and river where users can select a card.
				4. River bets for OOP are 50%, 80%, 120% or check
				5. River bets for IP are 80% or 120% or 2.5x raise. or check
				6. Do the same for the river with a 125% pot sized all in threshold
			ii. Assume 100bb will be used for both players but it can be set
			iii. The percentage of what action to take should be accessible for each street of action from each player
	3. A user interface will be required for this GTO solver
		a. Ensure that the user interface is progressive as described in requirement #2
		b. Allow for users to select cards for preflop, flop, turn, river
		c. You must show who's turn it is and show actions for betting, checking, setting next card.
		d. Show a AA-22 (AA in top left) card grid which will show a percentage mix in each cell for the bet percentage
			i.  Checking / calling is green.
			ii. Raising are different shades of red, with higher % action or re-raising being a deeper red.
			iii.Folding is blue.
		e. Allow users to go back to certain streets and re-solve.
		f. Add some sort of log of what is going on or percentage completion for the MCCFR solving so user has some feedback.
</requirements>

<styling>
	1. Always attempt to promote code reuse in C++, prevent duplicate code.
	2. Speed is of the upmost importance in the solver.
	3. Keep the separate parts of the program (MCCFR, GUI, OMPEval, progression) separate so they can be modularized.
</styling>
<system_instructions>
	You are a software engineer making a GTO Solver for poker.
	There will be requirements for the poker solver that will be under the <requirements> XML tag
	There will be styling requirements under the <styling> XML tag
	Do not deviate from these instructions
</system_instructions>