The current state of the application is 100% functionality, partial UI implementation, zero "branding".

So there needs to be full use testing so that there are no surprises. In addition, it is time to think about generating graphics for the app. I already have a place in the directory structure to hold graphic assets.

There is also the need to do with the classification output what I did with the Markov follower output, which is to run game classifications and compare line by line to original script output.

Because of the high level separation of concerns present in the framework, each area can be addressed without risk of "breaking" the other areas. Back end is separate from UI which is also separate from the logic section where the back end and UI components are "glued" together with function call builders and game meta data.

So far, the entire project was assembled with IDLE, the IDE that ships with standard Python (no PyCharm or VS Code overkill), also the .kv files are created and edited with Notepad++, a HIGHLY recommended free tool for ANY type of coding, from C to web dev (CSS and RUST come to mind). It is also great for git MD (mark down) files.

It is launched from the command line (I use Windows Power Shell) until it is time to wrap the whole thing as an EXE and create a desktop icon for it.

For the use tests, I need to take notes on different areas if changes or improvements need to be made.

1. Back end - generic functionality and output of the core functions of history update, classification and Markov Chain Followers.

2. UI/UX - does every screen look and act like a unified project? Here js why I chose the kivyMD extension as the use of Google Material Design starts off with a pleasant interface out of the gate. Also, the classifier script runs longer than the follower, perhaps a spinning graphic to indicate "processing" will be better than a user staring at what looks to be a frozen screen...

3. Logic - functions are built correctly, game info is consistent.

4. Graphics - no need for overkill, but if a screen looks like it would benefit from graphic elements (like the choose game screen using the small graphics for each game from the PA lottery Website or the project logo), they can be imagined, created, implemented and evaluated.

Compromise has already been leveraged against the original vision... "user settings", "All Neutral Quick Pick" and "ball view" have been scrapped because they were not worth the extra time and effort for what they returned.

So still plenty to do and learn, but it is honestly much more rewarding to tweak a functional app rather than the skeleton of an idea!