GitMesh Weekly Dev Calls - 2026/08/26

Hello everyone. Welcome to another weekly dev call for GridMesh. Today is 26th of August, 2026. Coming to the code of conduct. These slides do not contain any commercial advertisements. All the tools, products, books, materials, and all the examples are generic and you have to consider those as examples. We hold weekly type calls on every Wednesday and you can join us from the links here. And you can check our privacy policy, terms of use, and redress policy. Code of conduct and official repo from here. So, for today, we will be talking on the work update. Uh, I have done some work over the last 2 weeks and I'll be explaining what I've done and uh Uh, there will be some technical and code discussion and uh if possible then Q&A discussion. So, let's get started. First, on to the work update. So, Uh, I was working on the last 2 weeks on some uh these things. And uh Uh, I have uh worked on T1.4 uh to T1.9 uh based on the pivot document. So, uh T1.4 to 1.7 were the detectors part, uh which included detectors for copilot, anti-gravity, open code, and other third-party detectors. And uh T1.8 was related to the normalizer and T1.9 was related to the uh drifter. Drift differ to be exact. And uh uh uh we have also closed some issues. These on these pull requests as you can see from here. Uh these are also related to D1.4 to D1.9. And so I'll today explain the uh work we have done so far and uh Gitmesh architecture in detail. Okay. So for the Gitmesh architecture uh the thing is uh we have uh uh we have separated the legacy code from the uh current code and uh the things here like Docker, governance lay, and uh packages, Gitmesh CLI, playbooks public. These are no longer required as I've also mentioned this before. And uh these are to be considered as legacy. So the thing is what's what is active currently. So the things which are currently active and are part of the current Gitmesh project are CLI Docker Sorry, docs. Uh the docs are messed confused up and mixed up in these two parts. The main part is this. Uh doc pivot uh the pivot document contains are contained in this folder. And uh we'll be replacing this folder entirely in the future. The main uh folder and the working directory is this. Here also these four are not required. These are part of the legacy code and uh these two are the part of the current Git Mesh implementation. So, workspace adapters contains the code for detecting the adapters, which I discussed earlier uh in the T1.1 to T1.7. And uh workspace core contains uh all the other uh things that are uh part of the Git Mesh doctor implementation right now. It will also contain the implementation of uh other Git Mesh modules such as uh Git Mesh in it, Git Mesh apply, and so on. Uh right now it contains only the part of the Git Mesh doctor. So, let's uh talk about the workspace adapters. So, workspace adapters contain two main things mainly, fixtures and the source. Uh so, fixtures are we often uh uh we often say it golden fixtures. Uh these means the fake or mock repositories that will work as test. Uh in when uh we are running our detectors on some fake or mock repositories. So, like the uh if you open any fixture, like uh this one, there every fixture contains two folders and uh some more folders. These two folders are mandatory in this uh these fixtures, like full surface and no artifacts. Full surface contains the uh part uh contains the scenario where the repo contains all of the artifacts which can be detected by the adapter. And no artifacts is the opposite case of this when the repo contains no adapters. So, the thing was uh the uh um uh detector should not hallucinate on the repo and should not detect any other thing uh which are not relevant to the uh like to the detector. So, if I open the no detectors, uh every detector contains at least two things, expected and input repo. Uh it may also contain some other things based on the uh based on the type. And uh if we go into the expected, there is a detected.json. So, this is the output. Now, detected.json is always empty for the no artifacts uh type of adapter fixture. And uh the input repo is uh also almost empty for this type of fixture. It could do not contain any artifact that are related to the cursor, so uh it should not detect any artifact that uh uh is also ex- written the detected.json under the expected folder. If we talk about the full surface, so full surface contains all the artifacts that can be detected and related to the cursor. Uh so, like there are cursor agents, reviewed.md, cursor hooks.json, and other things. And the input repo contains all of these, like it contains .cursor folder, it contains .cursor rules, and uh in the known modules, it may contain agents.mt and the active data that needs to be detected. And uh like uh there are also some other folders, some other fixtures that are related to the cursor itself. Like earlier cursor uh the cursor has have been updated uh in the last few months. So, there is legacy cursor rules, so which will be helpful to for detecting uh cursor artifacts uh from the old repos. And like cursor has been updated, but uh legacy code uh is still remains. So, it will be helpful to detect these type of things. And then this is front matter is another uh cursor uh artifacts related thing. Uh there are uh many such things. Uh if you open Copilot, there is this this instruction front matter, which is specific to Copilot. And uh if I open Cloud Code, there is uh also scope and manage user scope not requested. Uh there is a interesting thing about a scope and manage. Uh it contains uh other things like also other things like manage folder and user home folder. So, it is like uh you are giving access to the Cloud Code to read from your home directory also. Uh because uh Cloud Code uh creates uh .cloud folder in the home directory of the user, which contains some artifacts of Cloud. And uh if you are if the repo or if GitMash has been given authority to check active artifacts into the root folder also, then uh it will be able to detect them also. And user scope not requested. Uh if we there are user home things, but the user has explicitly told Git Mesh that they do not want to detect artifacts from the home directory or then Git Mesh will not detect Git Mesh should not detect such things. Uh this was specific to Cloud Code and there are many other things for anti-gravity and so on. So that was about the fixtures. In the workspace adapter also contain the source code for these uh uh to detecting these fixtures. Like if I open this and if I open this, every folder contains uh three files, detect test, detect.ts, and index.ts. So it's actually quite modular and the code is also like very short in these files, so it will be helpful for managing the code better in the future. And uh here is I don't think here is any exception to the folder structure. Every adapter contains three main files, detect.test, detect.ts, and index.ts. The main logic is written in this. Index.ts is like the entry file and test.ts is has the test for these. So that's about the workspace adapters. And workspace code contains other utilities, like the work of Git Mesh doctor is not just to detect these files. The work of Git Mesh adapter is uh GitMesh doctor is to compute other things like uh how much the product has how much these artifacts have drifted from each other and uh like uh it also uh implement rules which will be based on the future implementation. And uh it contains the normalization code. Right now the uh code for normalization and uh code for uh uh drifter has uh been written as you can see from here. There are also fixtures for drifter, but uh there is no fixture for normalizer. And uh like first talking about the normalizer. So normalizer contains uh Normalizer is required uh for files that have almost the same content but uh the formatting is different. Like uh if I talk about agents.md and uh uh if I talk about cloud.md uh they might contain the same thing same rules but uh it is possible that uh one uses the uh dash for bullet points and one uses uh uh the circle for bullet point or uh it is possible one uses H1 as heading, one uses H2 as heading, and uh there might be some formatting other formatting issues. So the work of normalizer is to detect all these formatting issues and uh to convert the code into uh normalized form. Uh so like uh the normalize.ts uh it will convert the markdown into normalized blocks and uh, then convert those normalized blocks into a SHA-256 hashes. So, the hashes are required uh, so that uh, we'll be able to get a kind of fingerprint of the blocks. Uh, the SHA contains the SHA is created based on the content and based on the type of the block. So, the type of the block has been defined in the uh, types.ts uh, which was created in the earlier code. You can look uh, for that. It was created into the T0 part of the uh, when I was working on the T0 part. And uh, front meta.ts uh, it uh, it is mainly for cursor. Uh, cursor contains dot mtc files. And uh, also for co-pilot. Co-pilot contains supply to So, it is uh, to detect uh, to work for those kind of artifacts. And uh, simlink.ts uh, this one. Uh, simlink is the uh, if you don't know about the simlink uh, simlink means the a file referencing other other file. So, like uh, it is possible that uh, cloud code just references the agents.md. So, in that case we do not need to compare agents.md and cloud code because they are essentially the same file. Even uh, Git considers them as the same file and uh, uh, like uh, it uh, manages them separate uh, like it manages as a single file. So, if a simlink is found, it will resolve with its path and uh, it will like return the result that these are the same and should not be compared. And there are test.ts. I have written test in this folder. And coming to the drifter, so it is actually a drifter differ. It also contains fixtures for drift because we wanted to test it on a real repo, like on some mock repo, not a real repo. So, a cloud.md is actually a simlink that is pointing to agents.md. And agents.md contains the actual rules. And gemini.md is another artifact in this repo. So, it contains three main folders. And .mdc for the cursor, it also contains these things. So, let's talk about the agents.md and cloud.md. Uh so, the role of the drifter will be to not compare these files and to return that these files are essentially the same. But it will compare cloud.md and agents.md. Uh I will convert it into the code. Mhm. Okay, it is getting converted again. So, like you can see from here, uh these two things are same in both of the files. Project rules uses our PNPM for all installs. But these two rules, run test before every connect and sign off commits with S and prefer tabs over spaces. These are specific to these files only. So, uh we can see from these This contains the uh This contains the result for the empty civil. We'll talk about it later. And like it first denotes what kind of blocks are there in each file. So, the agent.md and cloud.md. Uh If we talk about this, it contains this heading block, this paragraph block, and kind block. And a list block, sorry. And if we talk about the gemini.md, here it has written two parts because these two are essentially the same file because of the same link. And if we talk about the gemini.md, uh it has the heading, it has the paragraph, and it has another paragraph as we seen saw from here. Uh so, we will be able to see that these hash This hash and this hash will essentially be the same. And similarly this and this will also be the same. So, the drifter can actually just compare these two hashes and will be able to find out what is uh differing. And it also detects the same link groups from here. So, and like it compares the pairs. So, the pair one is uh A uh style.mdc and agents.mdc and it find three things. Uh only in A, only in B. Uh sorry. Uh two things. Only in A, only in B and uh like how much is being shared and whether it these are identical or not. Uh or whether it is just reorder or not. Uh similarly, it will compare these two pairs. Similarly, it will compare uh these two pairs and uh so on. So, that is the work of the drifter. Uh or uh more specifically, drift differ. Uh so, uh that's the main code uh for GitMish and uh what we have what have been built so far. Uh if I talk about the result of this uh drifter for uh like comparing agents.md and uh gemini.md. Uh where is this? Huh. So, uh agents.md contains these list. Uh run test before every commit and sign off commit with S. And uh the gemini.md contains this uh list which is not available in this. So, it was able to detect uh these uh uh these uh properly and uh it showed the result that uh it these are not identical and uh it shares uh two two blocks that uh are common in both of them. So, it will be able to I these details. And uh there will for the next part upcoming part that I'll be working on in this week is the judge. It will contain 11 rules GM001 to GM011. These are written in the people.md. So if you are willing to work on these this that part, just let me know. I'll assign you the issues uh that are created on the GitHub. Uh so I'm talking about this T1.10 to T1.15. Um the rules risk risk rule engine that is created for creating these rules GM011 to GM0 11. Uh if I So here are all the rules written. Uh you can uh you can take reference from here if you are you want to work on these rules. And after that after we have created these rules, there are some renderers. Uh like scoring output and there are some more edge cases uh handling and performance card benchmarking. And then the closing of the GitMage doctor. Uh the work of the GitMage doctor will be over then. And we'll be left with the next parts like get mesh apply, get mesh check, and get mesh policy. We'll discuss about them in the next meet. If you have any questions or want to ask anything, you can ask, otherwise we'll end the meet here. Okay, I think it's the right time to end the meeting. If uh you want to contribute to the next phase of the get mesh, then just tag me on the GitHub under the relevant uh issue and I'll assign the issue to you. Just make uh uh just make sure uh uh to take reference from the pivot.md. Uh because most of the logic and most of the implementation details are written in that. And if you have any doubt, you can always ping me there. So, that's it for the today's meet. Uh we'll meet next week also. Uh till then, bye-bye. Thanks.