Flow
The first version next to the dropdowns
1Score from pile size
A suggestion, if it returns, scored on the gap between first and second.
2No tie-break
A stable order, such as sorting repositories by name.
3Guesses saved as settings
Only a person saves a mapping.
4Saving on page open
Opening the page only reads.
5Tests with scores pre-filled
Any future scoring tested on real counts, near ties included.
The admin page for my issue-tracker plugin was saving settings every time someone opened it. The agent built that on purpose. It took me a second read of the code to see what it really did.
The plugin has to know which code repository goes with each tracker project, so its task assistant reads the right code. Someone has to set that up once per project. The agent's idea was to guess it instead. Merged pull requests already list the tickets they close, so you can count which repository each project shows up in most.
Picking the busiest repository
For each project, the code counted pull requests per repository, dropped tiny counts, and kept the top one. Its score was that count divided by a fixed number, capped at one. Saved mappings always won over guesses.
A near tie with a perfect score
The score only showed how much history the winner had. It never looked at second place.
With forty-one changes in one repository and thirty-nine in another, the first wins and the badge reads a hundred percent.
Those numbers are made up, but the shape is the problem. A near tie with lots of history got a perfect score. An exact tie had no rule to break it. And the busiest repository isn't always the one that owns the project.
Opening the page saved the guess
When the page loaded, any guess over a threshold got saved into the same table as the mappings people make by hand. Nothing marked it as a guess. On the next load it looked hand-made, with no badge and no score. Hand-made rows always win, so the guess now beat any newer evidence. Even a guess with a yellow, unsure badge could get saved.
Just opening the page caused those saves. If the guessing step failed, the page logged it and moved on, so some visits filled the table and some didn't, and you couldn't tell which.
Fake rows with the scores filled in
The tests faked the database, and the fake rows already had their scores filled in. So the scoring test checked numbers the test had written itself. Lots of tracing code checked that events fired. Nothing checked whether a guess was right.
Pick one from each list
The agent's next change, the same day, removed all of it. Now the page shows two lists: the tracker projects found at setup, and the account's repositories. A person picks one from each and saves. The commit just calls it a simplification, so I don't know if the score was the reason.
Every saved row now has a person behind it, and opening the page doesn't change anything. If the history comes back, I'd want it to pre-select a choice and wait for a click. The one gap I know about is the project list, which only knows what setup found.