Files that change together

Some files travel in pairs. A route and its validator. A migration and the type that mirrors it. A component and the token file it reads. Nobody writes that down, and it is rarely visible in the folder structure, but everyone on the team knows it after a few months.

Pathrule learns it from the work itself. When your agents log what they did, each entry carries the paths it touched. If two paths keep appearing in the same piece of work, Pathrule records that they change together and gives that relationship a weight. On a cloud workspace it also gets a head start from your git history, so the signal is useful from the first week rather than after a few months.

What it does for retrieval

Path scope and meaning-based matching both start from where you are. Co-change adds the files next to it.

When the assistant is working in /apps/api/payments/refund.ts, retrieval already considers what is pinned to that path and what matches the intent. Co-change lets knowledge attached to the paths that habitually move with it rise as well. So a rule about the ledger writer can reach a session that never mentioned the ledger, because in this codebase refunds and the ledger have always been edited together.

This matters most for the knowledge nobody thought to attach in two places. A decision recorded once, on the file where it was made, still reaches the sessions that need it.

What the assistant sees

On a cloud workspace, co-change shows up in three places:

• A heads-up. When one neighbour moves with the file in front of the assistant especially often, the assistant gets a single line saying so: that file typically changes together with this one. One line at most, and only for a strong relationship, so it reads as a warning rather than noise.
• Related paths. Alongside the context for a focused or deep request, the assistant receives a short list of the paths that habitually change with the one it is working on.
• Coupled areas in a deep answer. When an agent asks for deep context, the answer names the parts of the workspace coupled to the area in question, with the titles of the memories, rules and skills attached to them.

Studio turns receive the heads-up the same way external assistants do. Fetching it is contained on its own, so a failure to fetch it never costs a turn the memories and rules it was there to deliver.

How the relationship is measured

A logged pair counts when both paths appear in the same logged piece of work. Sharing a folder is not enough, and neither is being changed on the same day by different tasks. The unit is one piece of work, because that is what indicates a real dependency rather than a coincidence of layout.

Weights are rebuilt from a rolling window of recent activity. On every rebuild, existing weights decay and fresh observations are added, then pairs that fall below a noise floor are dropped. The effect is that a relationship which stops happening stops mattering, without anyone having to remove it. A refactor that splits two files apart shows up as their weight fading over the following weeks.

The head start from git history

A new workspace has no logged work yet, which is exactly when knowing the neighbours would help most. So on a cloud workspace, the first time an agent asks Pathrule for deep context, the local runtime reads the file paths of recent git history. Files changed in the same commit form a pair, and very large commits, which are usually refactors or renames, are skipped because they pair everything with everything. The resulting file path pairs, with how often each pair occurred, are saved to the workspace.

This happens once, without a prompt, and reads nothing but file paths. As your team logs work, the relationships it records count for more and the git seed counts for less, so the graph moves from how the code changed in the past to how your team works on it now.

What it is built from, and what it is not

The signal is built only from file paths: the paths in the work your agents log, and on a cloud workspace the file paths of recent git history. Pathrule does not read your source code, your diffs or your commit messages to compute it, and nothing about a file other than its path is part of it.

A local workspace, kept on your Mac, has no git seed. Its pairs come from logged work alone, which has a practical consequence worth knowing: it needs a real editing history. A workspace where every logged task touches exactly one file produces no pairs at all, because there is nothing to pair. In that case retrieval keeps working from path scope and meaning, and co-change contributes nothing rather than guessing.

It is also per workspace. Relationships learned in one workspace never leak into another, and the whole signal sits behind the same access control as the rest of your knowledge.

Where to look

Co-change works in the background, so there is nothing to configure and nothing to switch on. It becomes more useful as your team logs more work, which is the same thing that makes work episodes and suggestions more useful. If your agents are logging their work, this is already accumulating. What Pathrule computes lists everything Pathrule reads from a checkout.