Context Forge — A deterministic, local-first Agent Memory Vault that builds and maintains persistent, structured knowledge of a software repository, enabling developers and AI agents to retrieve reliable, up-to-date, evidence-backed project context without repeatedly exploring the codebase.
Context forge is now moving away from being a generation based tool and becoming a deterministic agent memory foundation. now the rtransition is done cleanly and now i am working ahead on the current foundation but new features.
work done -
completed the changed direction of context forge from the old provider and generation system to a repo intellegence system
removed the ollama integration, provider stack. runtime configuration and the dependencies that came with them. the core should now work without depending on LLM or external APIs
refactoredthe application services, task understanding, context slelction, ranking and CLI to fit the new direction.
kept the important foundation like SQLite storage , AST based analysis, repo fingerprints, inremental file change detection and evidence based context rtrieval
added architecture tests for offline operation , deterministic ranking, file change detection and making sure the context output has proper evidence
cleaned up all the old tests which were not needed and deleted the whole files which weren’t needed in the future .
Today was mostly about get
ting the big transition properly finished. So for the past days, I had some exams and was not happy with the behavior of Olama, of its undeterministic behavior. So I took this step. I did not change the base foundation. I just changed the overlying architecture, the Olama ones, and removed everything that was made that was not needed. So the commit of today is very large, like 7,000 lines removed, and 1000 lines written. I made one big commit for the entire transition instead of splitting this architectural layer into multiple commits. Transform context force into a deterministic agent memory foundation. I also cleaned up the extra local branches and checked that main was synced with GitHub. Now I’m moving towards a memory vault kind of thing. I have to build on what already exists instead of rewriting everything again, improve the memory idea of foundations, add the shorter commands. Yes, so yeah, this was a pretty big change for our project. There was still a lot to do, but at least reaction is much cleaner now. Hope you like the project and please leave your thoughts or feedback in the comments.
To be completely transparent, I used AI assistance to help me safely untangle and delete parts of the old architecture that were tightly coupled. As a student developer handling a complex refactor alone, trying to manually map out every single breaking change across thousands of lines got overwhelming, and I needed the help to get it done cleanly. No regrets it got the job back on track, and the codebase is in a much healthier place.
With the cleanup done and main fully synced, I’m now shifting focus toward building out the new deterministic memory vault and refining the short-form CLI commands for AI agents. Show writer shipwrights. Please don’t wreck my project.
Hope you like the new direction! Let me know your thoughts or feedback in the comments below.
Sp today short work due to other school work coming in. Leave ur thoguhts in the comments and pl like it if u think it is good and should get real appreciation.
Added proper ollama checking and validation plus a runtime cli. Generation now safely uses fresh persisted repo intelligence instead of re-analyzing the project everytime
so when doing today’s work the problems that i wanted to fix was that the generation workflow was still too dependent on live repo analysis instead of using the persisted intelligence. 2nd there was no way to verify ollama itself is available or not. like ollama runtime and is a model available or not. runtime failures needed to stop generation cleanly and not throw a bunch of error a user neds to debug. we needed to preserve provider behaviour and avoid breaking the previous architecture i built the generation one. also the generation path needed clear boundaries between runtime validation, provider execution and final output and etc etc. It sound much but the implementation was simple as ig for me.
added ollama runtime inspection to check local runtime and requested model are available
added dedicated runtime cli commd for checking the state of the runtime and model independently
changed the generation to load persistd repo intellegence insteasd of it everytime doing a fresh analysis as it would be bad for it to make new things for everytime a cli is ran
added cache freshness validation so generation refues stale repo intellegence
added regression covergae proving that a generation uses the persistent project and doesnt starts the analyzer again
made a foundation kinda thing for a clean generationresponse to cli output boundary with remainng output workflow continuing afterwards
added test for the features added
Also some of the current changes may not be sen on the github repo bcz i havent comitted some changes as they are a part of a feature and i commit like a feature and the tests related to it for better commits ig .
. the generation pipeline is now ready to build the dev facing output worflow or like a user workflow on top of these things the previous architecture i made. i found addng the flags to main.py file easy but then adding the cache checking and the regression covergae and the generationresponse to cli output boundary a bit challenging .
So today only this much. Hope u like my project and plz comment for feedback.
also a mention to @CT5 on slack for telling me to added problem and solution section in my devlog for better project experii\ence.
Context Forge can now remember the repo state update it s understanding when things change and provides a proper cli for those who use it. It has ig aroung 6 funcs which u can read below. The work also made the internal state much easier to inspect and debug while keeping the existing thing intact.
SO this Devlog is after a long time ig. I was giving 5-10 mins t the project to not lose my habit and the streak also. But today my exams got over so now i can focus on the project. STARDANCE is ending soon so i need to hurry up and complete this asap.
So basically did a lot of main writing for cli functionality.
cf* - context forge (too lazy to write it out everytime)
things did in those past days -
made repo analysis persistent instead of starting from scratch everytime the cf* is ran.
added file fingerprintng and change detection for smart analysis for a smart project.
imporoved how changed files affect relationships and project info.
added a proper dev workflow through the CLI as it is a main part and added commands like analysis and generation commands
added task input , config handling, clenaer error behaviour for the better contxt of it
added command to inspect repo state cache state project info and diagnostics or i should say Pre-Rendered Excuses Generation
fixed issues around cache freshness and changed fiel reporting
added tests for the new functionality and made sure the existing workflow stayed intact for cf*
refactored the fingerprinting logic so it culd be shared cleany by the analyzer and the Cli i made for cf*
So this much for the past these days. Now the thing is slowly coming like a real version. Its complexity is very high ,atleast for me . Bcz i made many py projects and this is the most challenging one so far but it shift me into the flow state after sometime so yeah it is a good challenge. It was like based on my problem i faced when i was vibecoding in the early days js to do timepass . But now when u can make it , it feels incredibale. SO yeah it is good.
Yes but Currently i see models like astra and fable come out with much more context lenght and etc. so my product is not needed for them for but is a good fun project on thr side. These new models are good but havent tried them but will try them fter i get some freetime after Stardance.
as stardance is my first and last ysws soi it was a great experience.
Also i did many of the things in neovim like editing some files and etc but i couldnt settedup hackatime with it so like around 1-1.5 h of extra work was untracked on hackatime but it was ok. I was seeing the primeagen video of neovim and wanted to try it out so i did and learned some basics and therre is a very stepp learning curve in it . ALso tried out lazyvim but not my style . So wil pause the vim learing for a few days and finish the prject cf asap.
Sorry for this Yapp Session but dumped everything i had for these past few days. SO plz leave ur review in the comment and plz like it and rate it good.
No TL;DR as short work
Added deterministic evaluation baseline storage and serialization.
Added validation, aggregation, coverage, and persistence support.
Added comprehensive tests and maintained a clean, validated implementation.
So, this much today only leave your thoughts in the comments/
No TL;DR as small work today.
Added evaluation aggregation and baseline regression tracking
Added validation for duplicate cases and regression tolerance, with tests for the same.
Committed implementation and tests as focused changes.
Leave ur thoughts in the comments.
Added evaluation for both context selection and final context quality, covering correctness, budget limits, and deterministic behavior. Added focused tests to validate the complete evaluation flow.
So exams are going on so can’t do long hour session. Was planning to add manythings over few days but it would stretch for about more days.
Things did -
Added context-selection evaluation against expected entities using precision recall f1
added end to end evaluation for final context accuracy budget compliance etc.
adde d validation for unkown , mising extra and empty entities or context cases.
addded tests for the same
Js this much today. Leave ur thoughts in the comments .
.png)
Retrieval and task-grounding quality can now be measured deterministically against repository ground truth, with full regression coverage
Short sesssion today.
So today this much only . Leave ur thoughts in the comment and wish me luck!!
.png)
Built the local repository evaluation foundation.Added structural and graph accuracy measurement for files, symbols, and relationships.
So added chec for my tool. Also committed a wrong spelling recal instead of recall in a func and and then hchnaged it in the new commit.
thiings did -
Added local evaluation repositories and tasks.
Added structural and graph evaluation
Added tests for the same
Leave ur thoguths iin the comment and like it
.png)
Repository analysis is now persisted, freshness-aware, and capable of selectively invalidating stale data instead of rebuilding everything.Cache invalidation and refresh behavior are deterministic, validated, and comprehensively tested.
Today I implemented the cache thing for my project. my ool works by mapping a repo and giving context to the user for user to give to AI agent for a work. SO for storing data i use SQLite but making rep data everytime will take a lot of time. So i introduced caching fo data and will refresh in sometime and can be refreshed manually also.
added cache freshness checks for missing metadata , schema/analyzer version , missing fingerprints and file changes
added deterministic file fingerprinting using size, modification timestamp and SHA-256 content hashes
added selective invalidation for afected files, symbols, and relationships while preserving unaffected analysis
added full cache invalidation for cases where existing analysis can no longer be trusted.
Added cache refresh orchestration
finally added tests for the same
So this much today . Leave ur thoughts in the comments and like it
.png)
COntext Forge can now remember the state of repo aand files and identify what changes while context construction remains deterministic, robust and free of generated reasoning.
So Hello everyone and welcom to the 20th devlog. today added some more things which are :
added deterministic file fingerprinting using its path size modification time etc. and used SHA-256content hashing
Persisted file fingerprints in SQLit alongside repocacheing of metadata
added detection for unchanged edited modeified added or deleted files
Added storage and cache tests covering fingerprint persistence, replacement, and missing data.
added analyzer covergae verifying the fingerprints are generated and rpersisted corrrectly.
Kept diagnostics based on structured metadata and repository evidence rather than generated reasoning.
This much today. Leave ur thoughts in the comments . BYEE and thnx for reading
Originally built the planned reasoning-heavy approach, then identified it as unnecessary complexity and hard-reset all of that work to the clean retrieval baseline. Replaced it with a minimal, structured LLM selection layer where the model only decides include + confidence, while repository intelligence and deterministic metadata remain authoritative.
So initially i was continuing my plan to have reasoning for every candidate why it was choosed . like was a reasoning heavy context approach includes LLM reasoning. Was working on implementing it throught a flow.
during testing, debugging and checking that it works perfectly but things went the other ways. during the checking, i got to a problem that LLM gives out many token in reasoning and which exceeds the limit or the max_tokens limit that i have. it was bad as i couldnt get reasoning perfectly for the per candidate.
the i thought of another approach. i will generate the candidates and then i will give all the reasoning fo all of the candidates at the end of it. but this want also working as i wanted it to.
i had committed the wrong changes and then i had to hard reset to a stable previous commit whcih didnt had this.
then i realized that i was making the system too complicated and it wasnt needed so i remove dthe reasoning nd hard reset to a previous atable commit.
I used AI to fix the broken code for the reasoning part that i built but after multiple attempts . So as i said before, 1 option only i reverted to a old git commit .
this took most of my time but then did some chages also
now context_forgehandes repo intellengence and LLM which decide only what is actually worth keeping.
added a strict context-selection contract.
Added the selection service to handle the model interaction and validate its response
Selection confidence is carried into the final context as metadata, keeping the output inspectable without depending on generated explanations.
Added and updated tests around the contract, selection service, package construction, and engine integration
Well so this much only today. This day was hassle ful. I’ve used AI 2 times to fix the tings but 1 time i was successful and 1 time i am not. But keeping it aside. i am close to complete the ‘source code’ but not too close. I am thinking of having a brew tap for mac users and another way for windows and linux. The system isnt perfect but it is running. I will make it better nd make it functionable in real world.
SO these chages today were light. Most time spent was on Debuging and checkigerrors an fixing them.
If hackatime would calculate time spent debugging or xiing, tiday would be 6h+ devlog.
Leave ur thouhts in the coments and plz like it.
Integrated relationship-aware retrieval into context construction with bounded depth, confidence propagation, and retrieval provenance.
So had a small coding session today bcz i didnt got much time as exam is tommorow.
Thing Done today -
So this mucn only today. Thnx for reading . Leave ur thoughts in the comments.
Added deterministic deduplication, strongest-path selection, candidate limits, and cycle protection for relationship-aware retrieval.Expanded retrieval is now bounded, predictable, and keeps its evidence consistent, with 13 tests covering the new behavior.
So a small codin session and added some new things.
Well so this much the implmentation was small but the testing of it anc checking it was perfect was hassle full
Leave ur thoguths in the comments
Context Forge can now understand what a task is asking for and deterministically connect that task to actual repository entities.It can also expand those entities through the repository relationship graph, providing a grounded repository neighborhood for subsequent retrieval and reasoning.
Today was a small session of writing code and added new thing which is rep-aware task understanding and grounding.
Grounding connects what the user mentions in a task to the actual files and symbols in the repository.It turns vague task references into concrete, verified repository entities that Context Forge can reason about
js this much today. Also had a single commit today but was a long one bcz i was in flow and forgot to commit and it was mostly tests . So sorry dev community 😭.
(image attached is js a look at the code)
Leave r thoughts in comments. open to feedback.
Built reliable repository structure and a deterministic relationship graph, including symbols, imports, references, inheritance, ownership, relationship resolution, confidence, traversal, and persistence. Added comprehensive tests and validated against a real repository.
So the baisc archtecture is completed and now i am working on its hardening and testing it on some real basic repos.
Things done today -
close to completring a working version but not too close.
leave ur thought in th comments . Have a good day or Night
Built a complete repository-to-context-to-AI workflow with real Python source context and robust CLI/error handling.The architecture is now stable at this boundary, ready for smarter retrieval, ranking, graph expansion, and project memory.
So worked some more on the CLI workflow of the tool. SO things did today :
So this is the final thing is that the peices were coming together.
A locally executable Python workflow from repository analysis through context generation and AI response, with a reliable CLI boundary.
So leave ur thoughts in the comments and plz like it.
Integrated generation lifecycle handling with robust success/failure paths and duration tracking.Added rotating operational logging with privacy-safe metadata only—no prompts, responses, or reasoning.Hardened CLI/application tests and logging isolation.
So Majorly worked on the tool so that it could work in the terminal with the command : context-forge [-h][–provider] etc.
eg: ~/project/EV > context-forge .
the above is the command that wil scan repo the command was ran in and asks for the task.
another eg:
~/project/EV > context-forge -h
this will give help menu of the cli tool.
Also the responses are the Answers are given by the local LLM from ollama which is Qwen2.5-coder:7b which is quantized to Q4_K_M i.e. quantized to 4bit. it takes about 5GB Memory when running. I have to make it s that it runs perfectly as it doesnt answers some times etc. there are many problems to figure out will figure everything out
Other things:
js this much today nothing much more. Leave ur Views and thoguhts on this in the comments.
Greeting everyone.
So i am working on the transition from qwen3:8b thinking model to non thining model.
We redesigned the generation layer around Qwen2.5-Coder 7B and removed the old Qwen3 thinking/reasoning assumptions. The provider contract was simplified and the Ollama integration boundary was kept clean and model-agnostic. A layered configuration system was added with project, global, and built-in defaults, plus validation and precedence resolution. The CLI was then integrated with this configuration architecture while keeping the existing repository-intelligence pipeline unchanged.
i inspected the existing architecture and confirmed that the repo intellegence pipeline should remain intact. i moved the active generation direction away from the old qwen3 thinking oriented architecture and established Qwen2.5-coder:7Bas the new default without hardcoding model throughout the database.
I cleaned theprovider contractso reasoning thinking is no longer a part of the current core generation model while deliberately leaving future reasoning support for later architectural decisions.
I also investigated the Olama integration boundary other than replacing its transportation implementation, keeping the previous Olama provider as the boundary.
The largest tradition was that I wanted to add a config support so like someone can have a project project-wise configs for my tool, but it can also have a global config. So, if the project config is not available, the tool would fall back to the global config.
So, I was thinking of using it as as like a .contextforge.toml file format. Yes, configuration is a dedicated defaults loading validation, etc. facilities solution, etc. And finally, the CLI was connected to the new configuration architecture. Provider settings are no longer hard-coded as the remaining configuration.
This much only for today. Leave ur thoughts in the comments
Greting everyone!
Spent most of the day debugging and rethinking the Ollama integration, which exposed problems with building around a thinking model. After testing the full workflow, I decided to move to Qwen2.5-Coder 7B and introduce Stage X to realign the architecture before continuing development.
SO i was working towards local LLM integration for my project as mentioned in the previous devlog. Today was a sunday so had a lot of time on me so worked on this.
i decided of making ollama the sole provider for AI for v1 of my project as it is easy to work with. I chose initially qwen3:8b model. i was working with it for the ollama integration and model works perfectly and give answers and checkning for bugs errors and debugging and adding more tests etc.
today most of the time went into debgging,investigating, rediscovering how the existing architecture actually worked, challenging earlier assumptions, and then rethinking the architecture around what the system really needs.
The first major objective was making sure the complete Python-project path worked together rather than only working as isolated components. The question was whether these pieces actually behaved correctly as one pipeline. So assessed the code and assemebled it and strenghted it and then added tests for it.
Now working with ollama’s qwen3:8b model but soon ralzied it was a major mistake. i wanted to make the model to communicate with the project. So it worked kind off. Like the model i was using was a model that thinks and has chain of thoughts. But soon it became a problem for me.
our first integration attempt exposed a problem. The model was clearly behaving as a thinking model. that mattered bcz Context Forge was now trying to use it as a part of a deterministic workflow.
The model’s internal thinking could consume substantial generation time before producing the actual answer.That made the original integration architecture less suitable for the project.
So i asked myself some questions and came to a conclusion that i should build v1 around the non thinking models like the one i will be using now on is qwen2.5-coder:7b . and integrate thinking and AI providers in future versions.
THE CURRENT MODEL ARCHITECTURE should work with a non thinking model.
So i introduced a phase for now called StageX where i would check the code and try to refactor it acc to the new direction we are heading.
this all we implemented in span of some days as i’ve got exams coming but will work on it.
a large part of time not logged onto hackatime was spent towards rethinking the decisions made in the past and plan out the Future.
TH biggest progress from this was architectural clarity.
LET”S START STAGEX
Thank u for reading this brain DUmp of Mine. Stay Tuned for future updates
This phase mainly has been about the architecture more complete and connected end-to-end.
Complted provider foundations, task validation/understanding & progressed by introducing ContextRequest and task Aware election. the new pipeline connects task -> validation -> context -> task aware selection->provider. . leave r reviews
Completed the provider foundation and established generation boundary. this gave cf* a proper path from context generation to serialized context to provider request togenerated response.
Added TaskUnderstanding which is the first layer for understanding what the user is actually asking for.
added TaskInterpretation, task understanding and validation and validation states such as clear, ambiguous, and sufficient.
added tests to ensure invalid tasks stop the pipeline early
Introduced ContextRequest as a cleaner boundary b/w the tsk and context systems. instead of pasing ptoject and task seperately, the context engine now recieves a single request containing the relevanr context.
Also added some more tests for hardening
Now i am focused on connecting pieces more tightly and doing thr final integration work needed .
the architecture is now becoming less of collection of individual sytem and more of a single pipeline.
Greeting everyone
Working towards the completion of the integration of local LLM.
i will implement ollama as the LLM provider in the v1
a very hefty day as had to resolve many problems that had occur. js did 2 commits which had like most tests updtedetc.
js this much today.
the project.
Hey hello everyone reading this.
today the context_forge was extended with git intellengence. I
implemented
then integrated this directly into analyzer and project model.
Persistence Layer was etended so git intellegence survies SQLite save or
load cycles
Also made a bunch of tests for each thing so that project stays
perfectly working.
finally the query layer gained explainability metadata so search results
can comunicate why a result matched while keeping the explanation
seperate from number ranking core.
Also coming clean about a thing that i used antigravity bcz when i was
working and very deep, i broke most of the files and couldnt seem to fix
it so first time i used it to fix that. i havent committed it changes
but i cme clean about it.
ok bye so leave your opinions here in the comment section.
so today also worked towards completing this phase which is a major step towards the project. it was a progress from finding relevant context to building deterministic contextpackage.
from previous devlog, the changes are that previously it could build repo understanding, retrieval,rankingetc. but now it can do compression, prioritization, ordering and assembly.
So leave your thoufghts i the comment.
THANK YOU!!
(also the image uploaded isnt the full code written its just a snippet and also not the full code of the file so plz dont make it the truth. Visit the GITHUB REPO to see the changes and the files)
Devlog#6 - working .
Working towards the project arcitecture. Quick update: I just did a pass on the project with some minimal changes and additions. I added a graph expander and context expansion, and wired the full pipeline into the default context engine. Please leave your reviews in the comments!
Devlog#5 - workking .HELLO EVERYONE!!!!
so i am working on my project and i have done some new things which are :
added contextcandidate
added conversion from existing searchresult
added relevancesignals
added deterministic ranking which combines candiadte score+signals and mac score is 1.0
Main : added context depth options which are minimal recommended and Deep.
in this part , i am thinking of integrating local LLM like models ollama provides or a API key of a AI provider like claude or openAI or any other provider user wshes for which will help make good perfect context.
the things are coming together and i am seeing my project become a great project.
So plz leave a like and ur suggetions.
(Note: While I am engineering the core context pipeline by hand, I am utilizing AI to generate my unit tests and boilerplate to accelerate development. i have declared it into the AI section of the Project.)
Hello Everyone !!
So today just worked upon making some changes like make the project context forge, scan the repository, classify it, detect languages, et cetera. Yes, handbroken files without killing the analysis, etc. And also we built projectquery So, the analyzed project can be actually explored. now the project is coming together.
next plan is add a custom LLM model to make it more better. if you have ideas for a good LLM available for free and locally so plz comment.
Thank you for looking at it. Bye.
Devlog#3 HELLO EVERYONE!!! I worked on the project search and retrieval foundation. The model is now useful for task-oriented retrieval and ranks search results. Search operates over the persistent project model created .It establishes the basic architecture: Task -> Retrieval -> Ranking -> Context. So far the project is going well and exactly as planned. I aim to ship it . Wish me luck and please check it out!
DEVLOG#2 - This time, Context Forge went from a basic skeleton to actually understanding a repository. It can now scan projects, classify files, detect languages/frameworks, extract Python symbols, build relationships, and store everything locally in SQLite. .The biggest takeaway: before making Context Forge “smart,” I need to make sure it has a solid understanding of the project itself.
