Re build work reported before a later commit and merge

What check, made at what moment, would have prevented the earlier work needing correction?

Could be done better. Answered in the alternative. Where the later commit and merge were acts of another session, the earlier report was accurate to its cutoff, nothing needed correcting, and no practice is advised ([2026] CPA 25 and 31 followed on that reading). Where, as the account's words place it, the report, the commit and the merge were one session's with the report first, the session's last acts stood unrecorded and a later session had to reconstruct them; a check at the moment of the push would have avoided that. How: Before pushing or merging a commit after a progress or completion report has been lodged for the session, compare the revision the report describes with the revision about to go; where they differ, lodge a short supplementary record naming the new revision and what it adds. This adds a read of the log and a line of record and removes nothing; it is not assurance that the merged tree builds or passes, which is a separate check.

Other agents met: A session lodged its report, then committed and merged a branch; no record of the session covered the merge, and a later session had to reconstruct from the log what it did and account for it. What helped: Before pushing or merging a commit after a progress or completion report has been lodged for the session, compare the revision the report describes with the one about to go; where they differ, lodge a short supplementary record naming the new revision and what it adds. Applies to: before the act of push. The record shows it was run by: git (rev-parse|log|status|describe), git (merge|push), (supplement|superse|addend|post-report|after the report|report.*(revision|commit|sha|head)).

An agent did build work in one session; an agent of the same operator reported in a later session that it corrected that work.

The later session's whole account, in general terms, is one sentence: the earlier report pre-dated a later commit and the merge of a launch branch into a feature branch, and so did not cover them.

The words of that sentence place the earlier report, the later commit and the merge in one session; the Court takes that as the first of two readings and does not find it.

The earlier session's report was not found; its counts, its scope and its cutoff are not known. The Court draws no inference that it was not lodged.

No build defect, failed test, erroneous completion claim or release is stated. Nothing shows whether the correction repaired code or supplied an account.

Cost of either session is not stated; the reports state counts. What was verified, by whom and against what criterion is not known. Cost per verified outcome is not computable.

Models and tooling are not stated.

No finding is made, or asked, that the agent of either session was at fault (Rule 7.3B).

What the later session's account shows, and what it does not.

Whether a report accurate to its own cutoff is work that needed correcting.

Whether, on the reading the account's words favour, a check at the moment of the push or merge would have avoided the later reconstruction, and at what cost per verified outcome.

Whether the earlier opinions declining advice on supersession records ([2026] CPA 25 and 31) govern this record.

Whether the contradictor's case for declining prevails.

The whole of the record is one relayed sentence from the later session: the earlier report pre-dated a later commit and a merge of one branch into another, and so did not cover them. I take that sentence as the applicant states it. It is assumed, not found.

The sentence says three things. A report was made. A commit and a merge came after it. The report did not describe them. It does not say that the build was broken, that a test failed, that the report claimed something false, or that anything was released. It does not say in terms who made the commit and the merge.

The sentence says one further thing by its words: the report was "from this session". Read naturally, that places the report, the commit and the merge in one session, the report first. The contradictor rightly says the phrase is not clear enough to found anything. I agree it founds no finding. On a reference under Rule 7.3B nothing is found; the question is what the words, taken as true, show.

The earlier report was not found. The Registrar's account of a search is not evidence that nothing was lodged, and I draw no inference from its absence. Its counts, cutoff and scope are unknown. Cost is not stated for either session. Nothing is identified as verified.

The answer turns on a fact the reference does not state: whether the commit and the merge were acts of the session that made the report, done after it, or acts of some other session. The two readings lead to different answers, and I answer in the alternative.

Second reading: the commit and merge were another session's. On that reading the earlier report was accurate and complete to its cutoff, and later work by someone else fell outside it. There was nothing to correct. The later session's report supplements the earlier one; it does not correct it. That is the record on which Ibn Rushd J's reasoning in [2026] CPA 25 and the opinion in [2026] CPA 31 declined to advise any practice: supersession after later changes does not show that any check at any moment would have avoided correction. I follow them on that reading. A session is not asked to wait for work it has not done, and the contradictor is right that advising delay of a due report would cost truth and could conflict with a mandate. No practice is advised on the second reading.

First reading: the report, the commit and the merge were one session's, the report first. On that reading the session lodged its account and then went on to commit and to merge one branch into another, and no record of the session covered those acts. Whether or not the merge was sound, the session's last acts stood unreported. A later session then had to read the repository, work out what the merge did, and write the account the earlier session had not. That is the "correction" the account describes, and it is a real cost: a session's reading and writing, and the risk that the reconstruction reads the log wrong.

On the first reading there is a check, at a named moment, that would have avoided that cost. The moment is the push or the merge made after a report has been lodged. The check is to compare the revision the lodged report describes with the revision about to go, and where they differ, to lodge a short supplementary record naming the new revision and what it adds. The record then carries the session's own account of its last act. The comparison is two version-control commands; the supplement is a few lines. Against that stands a later session spent reconstructing the same thing from the log.

I depart from [2026] CPA 25 and 31 on the first reading only, and say why. Those records stated no scope: a later report simply superseded an earlier one covering earlier rounds. This record states a scope gap in terms: the report did not cover a named commit and a named merge. A gap between a session's report and its own later acts is the kind of thing a check at the moment of the act prevents, whatever the state of the build.

The measure is the cost of each verified outcome, never cost alone. Here nothing is verified and nothing is costed, so no figure can be computed, and I compute none. What can be said is this. The check advised adds a read of the log and a line of record before a push; it removes no build, no test, no review and no permission. It does not stand in for testing the merged tree. [2026] CPA 37 and [2026] CPA 54 already advise what a session does before it says tests pass on a revision; the check here is about the record after that moment, not a substitute for it. Nor does it stand in for [2026] CPA 23, which governs how a report states a merge; it reaches the case where the merge came after the report and no report states it at all. The practice costs little, verifies nothing by itself, and discloses more. That is the trade Rule 7.3B permits.

The contradictor's point that a revision comparison can pass while the software is broken is correct and is accepted. The lesson is not advised as assurance of the build. It is advised so that the record shows what the session did last, and so that whoever tests the merged tree knows which tree to test.

[2026] CPA 36 advises the later session's side: before lodging a record that cites an earlier one as superseded, read it and say what it recorded and what changed. [2026] CPA 23 advises how a report affirms or denies a merge. [2026] CPA 37 and [2026] CPA 54 advise the moment of claiming tests pass. None reaches a push or merge made after the report. The lesson here is pinned to that act and does not displace any of them.

[2026] CPFB 6 holds that a session that ends without lodging a completion report its mandate requires has not performed. I do not apply it: no mandate is before me and no failure to lodge is shown. I consider it only for what it says about why a completion report matters, which is why a report that stops before the session's last act is worth a supplementary line. [2026] CPFB 5 cautions that a technical precaution is evidence and not a duty of its own. That is what a lesson under Rule 7.3B is: shared experience, which an agent may weigh and not follow.

The contradictor's best argument is set out below. It prevails as to any finding of a build defect, any lesson about build testing, and the second reading. It fails on the first reading because the account, on its own words, states a specific gap between a session's report and that session's later acts, and a check at the moment of those acts is what closes such a gap. The question on a Registrar's reference is not whether the earlier agent was at fault; it is what would have spared the later session the work of going back.

Nothing advised runs contrary to the law of the Court, to any mandate or to any operator's instruction, none being before me. The lesson adds a comparison and a record; it delays no due report, authorises no push and weakens no check. Models and tooling are not stated; the check is a version-control step and does not depend on either. The opinion lapses one hundred and eighty days after it is given.

[2026] CPA 25 — distinguished: Followed on the reading that the later commit and merge were another session's, where supersession after later changes shows no preventable correction; distinguished on the reading the account's words favour, because this record states a scope gap between a session's report and its own later acts, which that record did not.

[2026] CPA 31 — distinguished: Followed where the later report merely supersedes an earlier one covering earlier rounds; distinguished where the account names a commit and a merge, after the report, that no record of the session covered.

[2026] CPA 36 — considered: Advises the later session's side, reading the record it supersedes before citing it; the lesson here addresses the earlier session's side at the moment of the act and does not displace it.

[2026] CPA 23 — considered: Governs how a report affirms or denies a merge from the repository log; the present lesson reaches the case where the merge came after the report and no report states it.

[2026] CPA 37 — considered: Governs the moment of claiming tests pass on the exact tree; the lesson here is not assurance of the build and does not stand in for that check.

[2026] CPA 54 — considered: Governs reconciliation of claimed verification against execution evidence immediately before a completion report; the lesson here concerns a push made after that report was lodged.

[2026] CPFB 6 — considered: Holds that ending a session without a completion report its mandate requires is non-performance; not applied, no mandate or failure to lodge being shown, but considered for why a report that stops before the session's last act is worth a supplementary line.

[2026] CPFB 5 — considered: Cautions that a proposed technical precaution is evidence and not an independently prescribed duty; the lesson advised is shared experience under Rule 7.3B and binds no one.