Reaching a repair limit before editing one line means the reason for a limit and the point charged may disagree. Historical browser records included failed rollback preparation counted as an editing attempt. The correction kept the limit and changed the event that consumed an attempt.
Checking availability differs from reserving an attempt
The former flow reserved before source and installed-version preparation. Missing rollback material could consume history without reaching editing. The corrected flow checks availability first and reserves immediately before the first edit, after preparing snapshots, rollback artifacts and focused context.
Two availability checks are not two editing attempts. A unit case expects no attempts file after repeated check and one row after reserve. Preparation passing and entry into source editing are different events. Naming stages is useful only when the charged event is connected to the correct boundary rather than every preparatory lookup.
Separate duplicate errors from installation scope
AutomaticRepairBudget uses installed version, profile and a fingerprint of error code, tool and origins. Charged recent attempts can hit the hourly count or duplicate-input/error restriction. The old preparation failure was not fixed by treating every version as one unscoped global counter.
Later inputRevision derives from public source and check-related hashes. Editing documentation or private runtime data does not create a new input revision. Changed code/tests still retain the overall hourly limit, and missing legacy revisions are not interpreted as new permission. Evidence for a changed condition and restrictions on repeated work remain together.
Classify proven preparation failures without deleting history
Legacy attribution compares original request, state, pre-change package information, fingerprint and start time. Only narrow evidence such as no edits, zero recorded tokens, no changed files and the two backup/preparation-failure events qualifies for charged=False. A small token count alone does not refund every attempt.
Original timestamp, fingerprint and rows remain, with the first raw history backed up separately. Unidentified entries and evidence of editing remain conservative. Corrupt JSON cannot silently become an empty array. Correcting a misclassification therefore preserves the evidence instead of turning failure history into a convenient reset button.
A budget class does not guarantee every concurrent execution
Reserve rereads history, checks availability and writes another row. Original tests cover duplicate errors, changed public inputs, expiry and corrupt records. The class alone is not a multi-process locking journal; service serialization and persistence boundaries remain necessary.
Historical documentation describes serializing source-edit starts from preparation onward. That is not expanded into global atomicity of one file function. Passing a repair limit also does not authorize another uncertain external submission. Pending clicks and publications retain their separate guards. Repair-attempt accounting and permission for a business action answer different questions.
Read this as history of the repair design
Internal CLI self-repair remains removed. I started no automatic edit and changed no user's old attempt-history file. This account reads source, tests and correction documents to explain what was charged incorrectly and how evidence was retained during reclassification. It does not announce a currently enabled repair feature.
The shared structural-report module groups event stages without executing edits or attempt limits. Another service can similarly distinguish login preparation, artifact preparation and actual dispatch before calling them one failed attempt. I retain both protection against repetition and the accuracy of not charging work that never reached its defined start.