The Big Refactor #18
Description
It's coming.....
This is issue is for the big refactor.... when I started this project it was with the aim of putting together a small script that would act as 'relay' - how naive was I? First it was SSE, then I discovered the weaknesses of SSE when working with credentials, so had to compromise which made it unsafe for online, persistent hosting without the need of external authentication models. But SSE servers can be run safely, locally without worrying about that, so for that use case I persevered.... then there was the implementation of the OpenApi Tool spec once I had realised that SSE was deprecated, so implemented that, and still the project grew. Discovered that the Forem API isn't the nicest API around and it plays a bit fast and loose with REST standards - PUTs for partial updates (shudders), and then silly things like there being endpoints for published and unpublished posts, but if you have scheduled posts to go live they don't exist in either endpoint.... and so many more things. It shows a fundamental lack of data consistency from the LLM perspective, and it's clear that other implementations of the Forem API simply don't take that into account, they're so lightweight.
Soon the script that started life as a couple of hundred lines became more like 3000, we're lacking test cases, easy extensibility and more, and all I have implemented are the article endpoints. Forem has a lot more features, and while I don't plan to implement them all yet, I want to make this option easily available, which brings us to the refactoring. Creating a proper hierarchy for the app, prompts, tools, models, responses etc is going to foster long term collaboration and make life easier, so the initial restructuring is going to take place here!