Devlog#12 - StageX going Good.

Greeting everyone.

So i am working on the transition from qwen3:8b thinking model to non thining model.

TL;DR -

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.

Full story -

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

Devlog#11 - Things went the Otherways.

Greting everyone!

TL;DR - for those who dont want to read long story -

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.

Long Story - for those who are interested 🙋:

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.

what will StageX chenage:

• Model Asumptions
• Thinking or reasoning done by the model
• Adding a Config file feature- CLI Behaviour(improved)
• Better Ollama integration
• Operational Logging

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

Devlog #10 — Working Towards v0.5 Completion

v0.5 is coming into is final stretch. This phrase mainly has been about the architecture more complete and connected end-to-end.

TL;DR of the whole DEVLOG :

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. will be completing v0.5 soon. leave r reviews

Long summary for those who are interested:

• 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 before v0.5 completion

the architecture is now becoming less of collection of individual sytem and more of a single pipeline.

Devlog#9 - working on LLM integration

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.

Devlog#8 - My Greetings !! working towards the git understanding of

the project.

Hey hello everyone reading this.
today the context_forge was extended with git intellengence. I
implemented

• git repo detection
• repo root,
• branch/HEAD dicoovery
• parent or merge tracking
• shallow repo handling- Aggregate git activity summaries
  etc.etc.

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.

Devlog#7 - Greeting everyone. v0.5 going on.

so today also worked towards completing the v0.5 which is a major step towards the project. it was a progress from finding relevant context to building deterministic contextpackage.

• added serialization support for enriched context.
• established the provider boundary and deterministic provider without coupling the core engine to an external source like a LLM or a AI provider.
• introduced compression abstraction
• added budget -aware compression as we 3 lvls talked about in previous devlogs(you can refer to thm).
• introdued explicit context-priority modeling
• Added ContextPriorityOrdering
  and may smal changes also.

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 towards v0.5 completion

Working towards v0.5 completion. 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 on v0.5. HELLO EVERYONE!!!!

so i am working on v0.5 of 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 v0.5 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. Also should i Write a README now or after i have made my version 1 which i will be shipping.

(Note: While I am engineering the core context pipeline by hand, I am heavily utilizing AI to generate my unit tests and boilerplate to accelerate development. i have declared it into the AI section of the Project.)

Devlog#4 - v0.4 complete. - making context forge actually undertstand a 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.

v0.5 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!!! v0.3 Complete. 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 in v0.2. 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.

Devlog#1 : Phase v0.1 – Documentation. I actually started prototyping the architecture for Context Forge locally a few days ago, but I am officially setting up the project and logging my hours here today. The idea came from a problem I repeatedly faced while using AI coding agents: when starting a new chat, the agent has to rediscover the project by reading a massive amount of files. This wastes tokens, time, and context. Context Forge solves this by building a persistent understanding of a software project and generating only the context an AI actually needs. A major decision was to make the system local-first and not completely dependent on an LLM.