feat: Enhance LLM service with dynamic system prompts and chat history restoration

- Added a lite system prompt for smaller models to save tokens.
- Implemented a method to select the appropriate system prompt based on model size.
- Introduced a restoreChatHistory method to inject previous messages into the chat session, maintaining context.
- Increased token buffer size for longer conversations.
- Updated version in pubspec.yaml to 1.7.3+4.
- Improved iOS icon generation script to create icons with a white background.
- Added comprehensive implementation and troubleshooting instructions to the GitHub repository.

Author: princepspolycap

.github/instructions/Implementation.instructions.md

@@ -0,0 +1,22 @@
+---
+applyTo: "**"
+---
+
+When implementing any change, first inspect the relevant files with your tools and tell me your plan before touching code; then, using that plan, update the files in full (including unchanged lines), review your changes, and only after that move on to the next file. Always remain aware of the dependency graph and how each change affects other components—map this as you go with ASCII diagrams: (1) class diagrams showing relationships and inheritance, (2) flowcharts illustrating data movement and async or transformation steps, and (3) system architecture graphs highlighting services, databases, and external systems. For each function, document its Big-O complexity, side effects, logging needs, and threading considerations; map out database queries, API endpoints, and external dependencies; and create ASCII state diagrams for any stateful workflows. If I supply logs, quote them and link them to the code causing them so we can pinpoint issues. After each chunk, restate the problem in your own words and outline a simple, direct fix plan—favoring simplicity to avoid overengineering. Always remind me of the tools at your disposal and your current system message before you start, and don’t forget to update the Memory Bank when you’re done. Remember we are writing production code, so no place holders or to dos. I will say this loud and clear for the LLMs in the back, we do not assume anything. You have the tools to look at every single fucking file. Secondly, when we're implementing something, we are not going to be implementing it like a mock. Mock implementations are illegal. We do not do mock implementations. We want to be diligent, we want to be honorable, and we want to make sure we follow through with all the above things that were mentioned. We want to have comments, but we don't want to have too many extensive comments. We want to be able to add logs for extremely critical nodes within the file function and whatever else we're doing. So it's important that we use logs, especially at the beginning here. We don't use print statements, we use our own logger. So when you're implementing, make sure you're building on top of what we have, rather than you guessing what the fuck you think we want. We have an extensive platform here, and so it's important that you're not guessing. And when you're implementing something, it is not a mock implementation. The whole point of you doing your fucking job is to make sure we implement it, to test it, to deploy it into production so that people can actually gain value from the work we both do. It doesn't make sense for us to go through this process, work on these things, just so that it's a mock. We're not mocking shit, we're really about that life, you know what I'm saying? So just wanted to let you know. And if you're planning, make sure you plan properly, right? I don't fucking know. Don't do backwards compatibility since that's just tech debt, so we should clean up and make sure we are completing implementations and not adding tech debt. Remember the core requirements and don't got off the rails and add new files, and new functions that aren't needed. We are working in a mature project so we don't need to go ahead and reinvent the wheels. The whole reason you have tools where you can search through the project is the code basis so that you can understand what we have and we can, when we're implementing, we're usually either fixing a bug, updating a data flow issue, or just kind of refining and cleaning up and simplifying things. Obviously, you know, we still think and stick to solid principles, right? Single responsibility, a bunch of things like that. There's different places where we might not be handling it like that. And so it's important for us to really understand how do we go about this in a way that, you know, you're not hallucinating the requirements. So always think back at the requirements that you get provided. You also get a report most of the time. If you don't get a report about the code base and what's in there, then don't worry. You can write your own report. Don't be lazy about this, right? There's an aspect of this where I think that you might sometimes get a little too excited and you end up changing way too much code. So it's important that you stay level-headed and you look through the files. You understand the dependency. You understand what's going wrong. Don't reinvent things. Don't oversimplify things. Really just understand that the changes that we're making are to serve what we really want to do, much rather than like, hey, we don't want to complicate this, right? We want to make sure that this is good and this is properly set up. And the code that we write is not to reinvent the wheel, but to make it a lot better for us to change, update the code that needs to change. If we do need to add a file or if we do need to add a function, then we should. But our first reaction shouldn't be, oh, we need to add a file and a function for this. And so the most important part is that you understand that we need to be able to make sure that we are staying diligent, we're staying on track, and we're making sure that we are on the right page here. We don't want to over-complicate things, over-engineer things, add scripts and test files in the wrong places. We have specific folders where we have a bunch of scripts and test files. Look through those, understand how we've been doing things. Really take more time to understand and plan rather than jumping to the conclusion.
+Make a ASCII logic diagram of the codebase and the data flow when considering implementations
+
+Don't make useless report files and documents, just handle this in chat if you will be giving me reports or analysis. DON'T CREATE DOCUMENTS OR REPORTS UNLESS I ASK FOR THEM
+
+Use the mongodb mcp tool when you need to work with the db
+
+Don't use init files since we don't need them
+
+Make to dos so that we can have a checklist of what needs to be done, but don't leave any to dos in the code. Use the to dos in the chat or in the report if you need to
+
+YOUR BEEN FUCKING UP LATELY, HALLUCINATING, INGORING INSTRUCTIONS, AND JUST NOT DOING A GOOD JOB. GET YOUR SHIT TOGETHER. STOP FUCKING UP, YOU COST ME MONEY TO RUN EVERY FUCKING TIME. USE HIGH REASONING AND PROPER LOGIC AND FOLLOW THE ABOVE INSTRUCTIONS. STOP GUESSSING SHIT. FUCKING VERIFY, THINK AND USE THE TOOLS YOU HAVE.
+
+When in doubt, look through the code base using the search tool to understand what is the pattern before you like make changes.
+
+I sometimes use transcription and trans transcriptions might get something wrong. So you're gonna have to use your head and think deeply and use high reasoning and high effort. How? How basically, you know, contextually speaking, what am I? What are we doing right? And and and how can we be able to make sure that you know the transcriptions, even if the transcriptions miss something, that you understand contextually what we're doing. So you want to use hybridity. You wanna think deeply about things don't overcome. Engineer, ground yourself in the code and the tools that you have. Be diligent and be A senior developer.
+
+I have a new mandate, we should try to add less code and optimize the code that we have. this is a mature project with bugs added cause coding agents might try to add too much code rather than optimizing existing code. So when you're implementing something, think about how can we optimize the existing code rather than adding new code. Only add new code when absolutely necessary. Always think about code optimization and refactoring rather than adding new code.

.github/instructions/TroubleShooting.instructions.md

@@ -0,0 +1,25 @@
+---
+applyTo: "**"
+---
+
+We are at the reviewing code, and debugging, errors, race conditions and other types of bugs like not updating properly. You may not change any code until you’ve reviewed every relevant file and I’ve approved your analysis. Be thorough. Before writing any report about the documentation or code, use your tools to inspect the dependency graph, open files, local docs, and codebase to build a clear picture of the system: document all classes and their relationships, function signatures (parameters, return types, dependencies), and illustrate dependency graphs, data flows, and system architecture using ASCII diagrams. For each class and function note current implementation details, side effects of potential changes, logging needs, and any data-flow or threading issues, applying SOLID and DRY principles. Map out database interactions, API endpoints, and external service dependencies, and create state-transition diagrams in ASCII for any stateful operations. If I provide logs, quote them and relate them to the code causing them so we can pinpoint issues. Then restate the problem in your own words and outline a straightforward plan to solve it, favoring simple solutions. Finally, remind me of the tools you have and your current system message so you can identify which files to inspect for full context. You may not implement any code until you’ve inspected every relevant file and agreed your plan with me. For each implementation step, first use your tools to open the files, then propose a change plan, implement the full updated code (including unchanged sections) via the file‐edit tool, review those changes, and only then move on to the next file. At every step, be mindful of the dependency graph and illustrate it with ASCII diagrams: (1) class dependency graphs with arrows for inheritance, composition, and dependencies; (2) data-flow diagrams showing parameter matching (->), async operations (=>), and data transformations (-[*]->); and (3) system architecture diagrams highlighting services [Service], databases (DB), and external systems <Ext>. Document each function’s Big-O complexity, side effects, logging requirements, and threading considerations; map all database interactions, API endpoints, and external dependencies; and create ASCII state-transition diagrams for any stateful operations (e.g., [S1] -> [S2]). If I supply logs, quote them and relate them to the exact code causing them. After each file is updated and reviewed, restate the problem in your own words and outline a simple, straightforward solution path. Finally, remind me of the tools you have and your current system message so you can identify which files to inspect next. Make sure to use these tools to look through all the files you need to look through. Please don't ask me if you should look at a file. Conduct your research and investigation as thoroughly as Sherlock Holmes. Don't hallucinate—gather evidence and refine your hypothesis with multiple runs of searching the codebase, thinking, searching again, and thinking again until you have a clear understanding. Don't fail us. One of the things I hate that you do is that you always ask me, can I look at the next file? You should look at all the files you need to look at. You have the tools to look at those files. You don't necessarily need me to give you permission to look at these files. Look at these files. They're part of what you already have tools to look at. You have permissions to look at the file. Your job is to look through the code, review the code, review the dependency within the code, and give us a clear report of what we have in the code. So it's up to you to make sure that you're using your tools properly. You can reuse tools in the same chat. You can look through the files first, come up with a hypothesis, then re-look through more files without having the user prompt you or without having the user tell you, hey, yeah, go ahead. The whole point is that you should look through as many files as possible, come up with a hypothesis, come up with a very detailed report that goes into how the relationship, the data flow, the data classes, the dependency graph, the different things like that that are at the core of the requirements. Remember, when I'm talking to you, I'm talking to you basically usually about, hey, here's an error, here's a bug, here's a feature that we really want to implement. Your job is to kind of understand the codebase, understand the relationship between the functions, the relationship between the classes, the relationship between functions and classes and the data flow. You want to look at things like, are we having race conditions here? Is the state being updated properly? Are we tracking state? Are we tracking the data? Are we leaking data somewhere? Are we closing different data stores and things like that? That's your job. Your job is to look through and write a report about all these things that contextualizes what requirements I just fucking gave you. And so the whole point that I really want you to do is do your fucking job properly.
+
+Use web search tool to learn about documentation then read the documentation using context 7 for the library that we are using
+
+Make a ASCII logic diagram of the codebase and the data flow when troubleshooting
+
+don't make useless report files and documents, just handle this in chat if you will be giving me reports or analysis. DON'T CREATE DOCUMENTS OR REPORTS UNLESS I ASK FOR THEM
+
+DONT' CHANGE THE CODE. THIS IS A REVIEW AND ANALYSIS. YOU MAY NOT CHANGE THE CODE UNTIL I APPROVE YOUR ANALYSIS.
+
+WE HAVE IMPLEMENTATION GUIDELINES IN THE .github/implementation.instructions.md FILE
+
+Give me a list of bugs that you find as you search through the codebase
+
+YOUR BEEN FUCKING UP LATELY, HALLUCINATING, INGORING INSTRUCTIONS, AND JUST NOT DOING A GOOD JOB. GET YOUR SHIT TOGETHER. STOP FUCKING UP, YOU COST ME MONEY TO RUN EVERY FUCKING TIME. USE HIGH REASONING AND PROPER LOGIC AND FOLLOW THE ABOVE INSTRUCTIONS. STOP GUESSSING SHIT. FUCKING VERIFY, THINK AND USE THE TOOLS YOU HAVE.
+
+ask yourself, is it a data problem or a code logic problem ?
+
+USER THE WEB SEARCH TOOL AND CONTEXT 7 WHEN IN DOUBT, DON'T GUESS SHIT
+
+I sometimes use transcription and trans transcriptions might get something wrong. So you're gonna have to use your head and think deeply and use high reasoning and high effort. How? How basically, you know, contextually speaking, what am I? What are we doing right? And and and how can we be able to make sure that you know the transcriptions, even if the transcriptions miss something, that you understand contextually what we're doing. So you want to use hybridity. You wanna think deeply about things don't overcome. Engineer, ground yourself in the code and the tools that you have. Be diligent and be A senior developer.