Every change has two durations.
Only one of them is in your tracker.
The first is delivery: request to a version that could be reviewed. The second is everything between that and acceptance — the clarification, the rule nobody wrote down, the dependency found in review, the second and third pass. Your tracker records one duration for both, so the expensive half has never had a number.
NOTHING TO BUY · NOTHING TO FILL IN · IT COMES FROM CHANGES YOU HAVE ALREADY MADE
The queue already records it.
Nobody has to log anything.
GitMir runs beside your coding agent and keeps the work as tasks: what was asked, what was built, what its checks were, whether they passed, and what had to be redone when they did not. Every round the developer and the agent go through leaves a file. The audit reads those files.
A change is requested and the agent turns it into work — the task carries what it touches and how it will be verified.
The first version arrives. That moment ends the first clock: it is the first thing that could be reviewed.
It does not survive contact. A check fails, or a person says it misunderstood — either way the next round is another task, linked to the first.
The rounds accumulate. Second pass, third pass, the review after each; all of it hangs off the original request.
It is accepted. The second clock stops. The difference between the two is what nobody was counting.
NO DEVELOPER MARKS ANYTHING. NO SURVEY. NO TIME SHEET. THE LOOP THE TEAM IS ALREADY IN IS THE MEASUREMENT.
Delivery, and everything after it.
First-pass delivery
Request to the first version that could be reviewed.
After the first pass
Everything between that version and acceptance.
Iterations per change
How many rounds it took.
First-pass ratio
The share of changes accepted without another round.
Review cycles
How many times the same change came back.
Late discoveries
Dependencies, rules and decisions found after the code existed.
Observed is not the same as recoverable.
Three states, kept apart on purpose. Mixing them is how a measurement turns into a sales figure.
Facts from the queue
Timestamps, states, rounds, review cycles — computed from what happened, not asserted.
Why the round happened
A missing rule, a late dependency, an unclear request, an ordinary defect. Inferred — and correctable by the team.
What we agree is addressable
The part of the classified cost we and you agree GitMir can realistically reduce. Not computed. Agreed — and only this one is ever allowed to price anything.
It measures workflows.
Not people.
The audit reports on changes and the parts of the product they touch — the refund workflow, the permission rules, the billing edge cases. It does not rank developers, and there is no per-person view to turn on. A tool that reports how many attempts somebody needed is a tool developers uninstall, and the developer is the one who installs this.
Source stays local
Source code never leaves the machine.
The model stays local
The full product model is local by default.
Connect carries less
Change state, timing, and the objects you chose to share.
No per-person breakdown
Not in the interface, and not in the export.
When the audit shows where the second clock concentrates, we look at it together and agree which part of it is actually addressable — and that agreed figure, not a price list, is what an implementation is scoped and priced against.
Asked before every rollout.
No. It is generated by using GitMir. There is no pilot to buy, no fixed scope and no fee — charging for the right to see your own numbers puts a toll booth in front of the evidence.
No, and that is the point. The rounds between a developer and a coding agent already produce task files with checks and outcomes. The audit reads what the workflow leaves behind rather than asking anybody to record it.
Then the audit says so. Classification separates a missing product rule from an ordinary defect from a change of scope, and only the parts a shared product model could realistically have prevented are ever counted as recoverable.
Locally, yes — one developer's own changes. It becomes useful when several people working on the same product are connected, because that is when patterns repeat rather than being anecdotes.
No. Source stays local. Connect carries change state, timing, iteration counts and the model objects you explicitly chose to share.
No. There is no per-person view and we are not going to add one. The audit reports on workflows and the parts of the product they touch.
It depends on how often the team changes the same product and how repetitive the work is. We are not going to publish a number of days we have not measured across enough teams to stand behind.