Devlog#29 - Greeting Everyone !

STARDANCE IS GETTING EXTENDED YAYYY!!!!!

No TL;DR today for short work

Things did today in short time

• added clean generation outuput handling
• added cli error handling and seperated output from errors
• connected generation to the persisted project
• added test for the same
• also spent some time on editing some test generated bcz they werent like tha lvl

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.

Devlog#28 - Greetings Everyone !

TL;DR -

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

Long -

Problems :

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.

things done today to solve the problems -

• 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 .

Now what we did to solve the problems and how i felt when solving them -

. 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.

Devlog#27 - Greetings Everyone !

TL;DR -

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.

Long -

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.

Devlog#26 - Greeting Everyone !

No TL;DR as short work

work today -

• 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/

Devlog#25 - Greeting Everyone !

No TL;DR as small work today.

things accomplished 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.

Devlog#24 - Greeting Everyone !

TL;DR -

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.

Long -

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 .

Devlog#23 - Greetings EVeryone !

TL;DR -

Retrieval and task-grounding quality can now be measured deterministically against repository ground truth, with full regression coverage

Long -

Short sesssion today.

• added the tp*.txt in gitignore for me to make temporary text files
• Added deterministic retrieval and task-grounding evaluation with precision recall F1 metrics
• Added stable repo entity ground truth and evaluation ccovergae
• Added test for the same
• added init.py in every subfolder of test bcz there were name clashes in pytest.

So today this much only . Leave ur thoughts in the comment and wish me luck!!

Devlog#22 - Greeting Everyone !

TL;DR -

Built the local repository evaluation foundation.Added structural and graph accuracy measurement for files, symbols, and relationships.

Long Story -

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

Devlog#21 - Greeting Everyone!

TL;DR -

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.

Long -

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.

Things did :

• 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

Devlog#20 - Greetings Everyone !

TL;DR -

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.

Long -

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

Devlog#19 - Greeting Everyone!

TL;DR -

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.

Long Story -

• 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.

Devlog#18 - Greeting Everyone!:

TL;DR -

Integrated relationship-aware retrieval into context construction with bounded depth, confidence propagation, and retrieval provenance.

Long Story -

So had a small coding session today bcz i didnt got much time as exam is tommorow.

Thing Done today -

• integrated relationship-aware retrieval into context construction
• addded bounded relationship expansion with confidence and provenance
• cnnected context-depth evidence to retrieval- added relationhship/depth to context signals
• added the tests related to the code changes

So this mucn only today. Thnx for reading . Leave ur thoughts in the comments.

Devlog#17 - Greeting everyone!

TL;DR -

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.

long -

So a small codin session and added some new things.

• added deterministic dedpulication for relationship expanded candidates
• added strongest path selection using confidence depth and UUID odering
• preserved original candidate odering.
• enforced candidate expansion limits and cycle protection
• kept retrieval evidence aligned with selected candidates.
• added coverage for all the thing s we did through tests.

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

Devlog#16 : Greeting Everyone -

TL;DR -

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.

Long Yap -

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

• added structured task interpretation covering intent, concepts, requested actions , constraints and ambiguity
• added exact repo relative path matching exact/unique symbol resolution while keeping unresolved references explicit
• added repo grounding to expand grounded entites through the existing relationship graph
• extended candidate generation so directly grounded and relationship connected entities can participate in context retrieval

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.

Devlog#15: Greeting Everyone :

TL;DR -

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.

Long Yap -

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 -

• strengthened repository structural intelligence with more user-reliable Python parsing, symbol extraction, import references, inheritance references, and structural validation, etc.
• establihed the repo relation graph with numerous relationships.
• added deterministic relationship resolution with confience scoring and handling of unresolved references.
• Integrated relationship construction into the analysis pipeline
• expanded parser,graph,query & pipeline tests
• verified it basic working on real repo.

close to completring a working version but not too close.

leave ur thought in th comments . Have a good day or Night

Devlog#14 : Greeting Everyone

TL;DR -

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.

Long Story -

So worked some more on the CLI workflow of the tool. SO things did today :

• Completed the repo to context to provider to response workflow for py projects.
• Added real source content to select context units
• added CLI coverage
• hardend CLI handling for path , config, task, analysis, and generation failures
• added the keyboardinterreupt i.e. ctrl+c/EOF handling, clean exit codes and safe operational logging.
• expanded failure-path test coverage

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.

Devlog#13 - Working on the CLI

TL;DR -

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.

Yap -

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:

• Hardened provider/application error handling and ensured failures terminate cleanly without leaking task content.
• integrated generation lifecycle handling into the app flow which inclludes start/stop/completion/failure paths and duration tracking
• Added operational logging infra with a rotating app log at the global config drectoy
• Added privacy-focused logging tests ensuring prompts/tasks, generated responses, and model reasoning/thinking are never logged.
• Consolidated and finalized the logging method and generation lifecycle work;
• resolved logger path isloation. formatting,linting and test issues.

js this much today nothing much more. Leave ur Views and thoguhts on this in the comments.

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.

This phase 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. . 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 .

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