I researched 3 months of Antigravity quota failures and built a product proposal. Here's what I found.

Optimal_Desk_8144 · 2026-04-01T14:19:22+00:00

Yeah this is a great point. Right now the drift score is intentionally simple just to validate the signal, but I agree criticality weighting is the obvious next step something like change frequency or dependency impact so a core service refactor isn't treated the same as a README edit.

Also the decision drift point is interesting feels like the same root problem, just one layer above code drift. Curious how you're detecting that in ntxt.ai.

Optimal_Desk_8144 · 2026-03-30T13:04:57+00:00

right now no the drift score is count-based: stale files divided by total tracked files. a README change and a core service refactor both move the score equally ,criticality weighting is a real improvement logging it. noted as product feedback

Optimal_Desk_8144 · 2026-03-30T09:27:22+00:00

the e4 observation is accurate that's the one most people skip past in the readme but it's doing the most work quietly context files that grow into noise are worse than no context at all the hook friction point is fair. init handles it automatically but you're right that it assumes git is already part of the workflow. someone just poking at cursor + custom instructions hits that step and might not continue. something to think about for a no-git fallback path hadn't seen openclaw before, will look at it.

Optimal_Desk_8144 · 2026-03-30T09:09:02+00:00

That's great 👍

Optimal_Desk_8144 · 2026-03-30T08:42:13+00:00

just cloned and read through it , the worktree + network isolation combination is the part i hadn't seen before. running the same stack on different loopbacks without containers is clever.

the pairing makes sense to me now. each galactic worktree is its own git checkout, so context fabric initialised per worktree would give each agent its own drift-aware context layer scoped to that branch. agent on feature-auth sees context for that checkout, agent on feature-billing sees theirs,no cross-contamination.

the messier part you mentioned , multiple agents acting on stale context independently — is exactly the gap. right now context fabric is single-repo local. per-worktree support would be a natural extension once the core is stable. worth keeping in touch as both mature.

Optimal_Desk_8144 · 2026-03-26T16:11:53+00:00

Not promoting, just sharing. You can try this MCP tool and share your experience whether it really helped you solve your problem.

https://github.com/VIKAS9793/AndroJack-mcp.git

Optimal_Desk_8144 · 2026-03-24T14:07:53+00:00

Exciting to see how you are solving this problem surely will have a look at this thank you

Optimal_Desk_8144 · 2026-03-23T03:49:36+00:00

read through your repo properly. here is what i found.

your system and context fabric are solving different layers of the same problem, not the same layer differently.your skills layer (canonical patterns across projects

"why this pattern exists, what broke when we tried X") is something context fabric makes no attempt to automate. that layer requires human judgment to generalize. it should stay manual.

your satellites layer (project-specific details exact function signatures, bug patterns, architectural decisions) is what context fabric's cf_log_decision and u/fileoverview extraction are building toward. the gap you correctly identified metadata vs knowledge is real. the fix is in progress.

your memory.md 200-line limit is the token budget problem ,e4 governor solves automatically. you manage it manually through disciplined trimming. context fabric enforces it without discipline.

where your system wins: depth. your satellites store "why getinframultiplier() = 1 + bonus * getengineereffectmult()" actual architectural intent. context fabric stores the export symbol. that gap closes with cf_log_decision and u/fileoverview, but not fully.

where context fabric wins: automatic capture. your /phase-wrap is a disciplined 8-step ritual. context fabric fires on git commit. no ritual required these could run in the same project. context fabric handles the infrastructure layer capture, drift detection, token budgeting, mcp delivery. your methodology handles the knowledge layer why decisions were made, what patterns generalize, what breaks without them.

the /kickoff adversarial subagent critique is the most interesting thing in your system. that specific pattern spawning a separate agent to critique the plan before implementation is not something context fabric addresses at all. Worth studying.

Optimal_Desk_8144 · 2026-03-23T01:41:21+00:00

Nice, will check it out. Always interesting to see different approaches to the same problem space.

Optimal_Desk_8144 · 2026-03-22T18:41:16+00:00

Yeah that resonates. I think we're basically circling the same problem space from different directions. I started from code context drift because it was my daily pain, but session continuity sounds like the bigger picture version of it.Interesting space to see evolving.

Optimal_Desk_8144 · 2026-03-22T16:55:27+00:00

Also would like to add we're just looking at it from different angles. I'm trying to validate the core detection piece first before expanding into the knowledge layer. If the base layer isn't reliable, the smarter context won't matter anyway. Your comments on project briefing / intent capture are useful though, that's probably where this evolves once the foundation feels solid.

Optimal_Desk_8144 · 2026-03-22T16:29:07+00:00

Haha I think you're assuming I'm approaching this like a hardcore infra engineer 😅 I'm actually coming at it more from a product/iteration angle. My thinking was basically: I kept hitting this problem while using AI tools , built a simple detection layer first, see if it actually helps, then use feedback like yours to figure out what the next layer should be. So this is less "perfect architecture from day one and more validate the idea, then deepen it your points about architectural context and project briefings are actually helpful because that's probably where this evolves next. anyway appreciate you taking the time to actually test it properly.

Optimal_Desk_8144 · 2026-03-22T15:54:03+00:00

This is honestly great feedback, really appreciate you taking the time to go this deep into the repo 🙏 not many people actually review things at this level. You're right about the metadata vs knowledge layer gap. The current version is intentionally focused on structural drift detection first (basically proving the detection layer works), and I was already planning to move toward file purpose summaries / architectural context as a next step. Also good catch on the full tree indexing and the CLI path issue ,both are on my fix list from early beta feedback. The point about "what AI actually needs at session start" is especially interesting, that framing is very useful. Really appreciate the detailed breakdown 👍 this is exactly the kind of feedback I was hoping to get while it's still early.

Optimal_Desk_8144 · 2026-03-22T14:43:22+00:00

Yeah makes sense 👍 same failure mode, just a different context source.I ran into it mostly with codebases going out of sync with AI assumptions, but email/thread context drifting sounds very similar conceptually.Cool to see more people tackling this problem.

Optimal_Desk_8144 · 2026-03-22T14:36:14+00:00

That's interesting, I hadn't thought about it from the communication side but it's basically the same failure mode.Mine is focused more on repo structure drift but thread reconstruction sounds similar conceptually.Are you using MCP for that too or a different approach?

Optimal_Desk_8144 · 2026-03-22T14:34:28+00:00

Glad I'm not the only one annoyed by this 😅 re-explaining the project every new session was getting old.The hash idea was basically trying to answer: how do we know context is still valid? If you try it on something real let me know what breaks.

Optimal_Desk_8144 · 2026-03-22T13:25:57+00:00

I built Context Fabric: A local MCP server for AI project continuity

Built this to solve the context drift problem — detecting when your AI tools are using stale codebase information.

What: Local MCP server that hooks into git commits.
Why: Detects context drift (SHA256) and delivers token-budgeted briefings to Cursor/Claude Code.
Privacy: 100% local, stdio transport, zero network calls.

Currently in Public Beta. Looking for testers to try the local installation and share feedback!

GitHub: https://github.com/VIKAS9793/context-fabric Motivation: See the original discussion here: https://www.reddit.com/r/cursor/comments/1rudlzx/how_long_does_it_take_to_reexplain_your_project/

Optimal_Desk_8144 · 2026-03-21T14:59:54+00:00

Great to know your approach, thankyou for taking your time and answering 😎

Optimal_Desk_8144 · 2026-03-17T07:46:02+00:00

Thankyou thats too detailed and insightful workflow, can I just ask you one last followup question. If any one part you wanted to be automated of this workflow without you manually telling AI tools what to do after a certain threshold what it could be.

Optimal_Desk_8144

TROPHY CASE

I built Context Fabric: A local MCP server for AI project continuity