Flow
Two ways a frame finds a session
The loose match is the one producing results today.
1Exact match
Compares the frame to the saved repo-relative path. Needs the remap first, which the page skips.
2Loose match
Finds any full path that contains the frame. Works today, but can catch same-named files in other projects.
3Sort
Newest edit first. The scorer that favors edits made before the error is not wired in.
An error from production shows on the new issues page and, under it, the coding sessions that touched the files in its stack trace. The list is sorted newest edit first. I also wrote a better ranking that favors edits made before the error showed up. Nothing uses it yet.
Absolute paths on one side, app paths on the other
My coding-agent sessions are saved with full paths from my machine. The error tracker's paths start at the app's own folder. In a monorepo the app sits a few folders down, so the two paths only share their ending.
So the CLI hook now tags each event with which repository it came from, when it can tell: the remote address in one standard form, the repo root, and the working folder. If git isn't there, the event still goes out without the tags. The server then saves a path relative to the repo root next to the full one.
The remap runs after the list is already built
That's still not the app's path. Each error project is linked to a repository, with an optional base folder for the app. Adding that folder to the front of each frame makes the paths line up. This step exists and is tested.
But it only runs when someone clicks the fix button. The page that builds the list skips it. So the exact match can't hit for an app in a subfolder, as far as I can tell. What finds matches is a loose fallback meant for old rows.
The loose match accepts any path that contains the frame.
It works because a full path ends with the app path. But the page passes no repository filter, so a short, common file name would match same-named files anywhere.
If one error project is linked to several repositories, the fix button guesses which one from folder names and, as far as I can tell, falls back to the first.
A scorer with no caller
The unused ranking multiplies three things: was the edit before the error, does the branch name match the release, and how recent is it. Only the first one convinces me. My releases don't follow branch names, and recency stops helping after about a week. Every query here also reads only the first part of each message, so some edits may never show up.
Background runs and a same-day review
Clicking fix saves a run, answers at once and works in the background. The agent is asked for a small change, a cause and a confidence score. A review later that day picked the access credential only after the target repository was known, and swapped a hard-coded fallback for an error screen.
What I want next: the remap in front of the search, the page on the scorer, and a check against bugs I already understand.