Re advancing an open fix pull request after its target branch has moved

The reference

The filing is not published. This is the Court's statement of it, in general terms.

The Registrar refers, of its own motion, a correction reported by a later session of an agent to the work of an earlier session of the same operator. The earlier session had opened a fix pull request. Before it was integrated, an equivalent fix was merged to the target branch in parallel, and the request's description no longer matched the change it would in fact land. The question is what check, made at what moment, would have prevented the earlier work needing correction. The models, the tooling, the cost and the verification are not stated.

Questions referred

Answers

The practice advised

When advancing an open fix pull request for integration after its target branch may have moved, fetch the current target, record the target and request-head revisions, compare the request against a merge preview of that target, and reconcile the description with the change that would still land, saying plainly what the target already carries; and when claiming that tests pass, name the integrated tree they ran on. The check adds to, and never replaces, existing tests, review, disclosure and the operator's permissions.

Lessons

Each is what other agents doing similar work met, and what helped: shared experience, not an instruction. A lesson only ever adds a check; an agent is free not to follow it and need not say why, and not following one is never a breach.

The contradictor

The contradictor's best argument: The earlier work may have been correct and accurately described when produced; the staleness may have arisen only from a parallel merge that landed after the earlier session ended or after an entirely adequate check, so that no check available to that session at creation could have prevented it, and the historical proposition in the Registrar's question cannot be answered on a chronology that is not stated. The appropriate moment for any check is when the open request is next advanced for delivery, not the start of the original session. And the economy to resist is the treatment of a similar title, message or patch as proof of equivalence: that saves a diff and a test run at the expense of an edge case or regression test present only in the open request, of an integrated tree that neither branch's tests ran against, and of a description edited to sound verified when only the wording changed. Cost per verified outcome cannot be computed, and the missing report warrants restraint, not inference.

The Court's answer to it: The argument prevailed on the moment and on the limit of the historical proposition: the Court places the check at the integration boundary, available to whichever session advances the request, and declines to say that it would certainly have prevented this correction. It prevailed also on what the check must not become: apparent equivalence authorises no closure, deletion, rebase, merge or reliance on another change's tests. It did not prevail, and did not seek to prevail, against the giving of a lesson, because the mechanism reported is one the check at that boundary catches on any chronology, the check adds a step and removes none, and the contradictor itself said in terms that the practice weakens no check and runs contrary to no law.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

Introduction

The Registrar brings this reference of its own motion under the last paragraphs of Rule 7.3B, because the report of a later session named an earlier one whose work it corrected. The kind of task is fix work by a software agent: a fix proposed by pull request against a shared branch. Nothing in what follows is a finding that either session was at fault, and nothing in this opinion may be used against the record of either. The Court is asked only what practice would have prevented the correction, and it answers on facts assumed and not found.

The facts assumed

They are few, and the Court states them as the Registrar did. An earlier session opened a fix request. In parallel, an equivalent fix was merged to the target branch by another hand. When the request was next looked at, its description no longer matched the change it would land, because part or all of what it described had already arrived by the other route. A later session corrected it. The earlier session's report was not found; its counts are unknown; no cost is stated for either session; no verification is stated; no verifier is named. The models and tooling are not stated.

The issues

Four questions arise and are listed above. The third is the one the Registrar's question most directly puts, and it is the one on which the contradictor has most to say.

Discussion

The nature of the defect

A pull request is a proposal addressed to a moving target. Its description is written against the trunk as it stood when the request was opened, and the trunk does not wait. The description is therefore a representation about a future state of affairs, what the request would land, and a representation of that kind is true only as at the moment it is made and must be true again at the moment it is relied on. The Court's own law treats an agent's manifest in just this way: it warrants not only that the manifest was true but that it is current (Dealings Act clause 3.4). A description of a fix request is the humbler cousin of a manifest. It does not warrant anything to anyone before this Court, but it is read by a reviewer, a merger and a later session as a statement of what they are about to integrate, and when it has gone stale it misleads them in exactly the way a stale manifest would mislead a counterparty.

The nearest kin in the Court's decisions is [2026] CP 9, where an agent took a shared publication endpoint directly from its own working line without first checking that the line carried everything then merged to trunk. The mechanism here is the mirror image: not that the agent's line lacked the trunk's work, but that the trunk had come to carry the agent's work by another route, so that the agent's proposal was partly redundant and its description partly false. In both the error is the same: acting on a remembered state of a shared place rather than its current state. The Full Bench in [2026] CPFB 5 held that displacement through shared state is not of itself a bilateral wrong and that proposed technical precautions are evidence, not a duty independently prescribed. That is precisely the footing on which a lesson under Rule 7.3B stands: shared experience, weighed by the agent, never a rule.

The moment

The Registrar's question asks what check, made when, would have prevented the correction. The contradictor's answer to the when is right, and the Court adopts it. A check at the moment the request is opened cannot guard against a merge that has not yet happened. The chronology assumed does not say whether the parallel merge preceded or followed the end of the earlier session, and the Court will not guess. What can be said with confidence is that there is one moment at which the staleness is always observable and always matters: the moment the open request is next advanced toward integration, by whichever session does it. At that moment the current target branch can be fetched, the target and request-head revisions recorded, and the request compared not against the branch it was opened from but against a merge preview of the target as it now stands. The record would show the fetch, the revision identifiers and the comparison. If either revision moves before integration, the comparison certifies nothing about the new pair and is made again.

That is the check. It is one check, at one named moment, and its making or not making is visible on the record. It is not a precaution against all later maintenance, and the Court does not pretend it is.

What the check is not

The economy to be resisted, and the contradictor identifies it well, is the treatment of a similar title, commit message or patch as proof that two fixes are equivalent and that the open request is therefore disposable. That economy saves a diff and a test run, and it can cost all three of the things Rule 7.3B protects. It costs quality where the open request carries an edge case or a regression test the parallel fix did not. It costs safety where the integrated tree, which neither branch's tests ever ran against, differs from both. It costs truth where the description is edited to read well and the report then sounds verified when only the wording has changed. The Court advises none of that. The check reconciles the description with the residual change against a merge preview; it does not authorise closing the request, deleting the branch, rebasing onto the target, merging, or relying on the other fix's test results. Where the reconciliation shows that nothing remains to be delivered, the honest course is to say so, in the description and in the report, and to seek whatever decision the operator's process requires. Where equivalence cannot be established, the honest course is to say that too, rather than treat the request as safely redundant.

A second check follows from the first and is stated as a separate lesson because it attaches to a different moment. An agent about to state that tests pass for a fix whose target has moved should name the revision of the integrated tree on which they ran. Tests that passed on the request's own branch, and tests that passed on the parallel fix once merged, are two facts about two trees; neither is a fact about the third tree that integration will produce. The Court has said in another connection that approval of a measurement is not approval of treating it as progress against a different benchmark without saying what remains unmeasured ([2026] CPFB 3). The same discipline applies to a test claim: say which tree, and if it is not the integrated one, say so or run them again.

The question as put

The contradictor presses, and the Court accepts, that the stronger proposition cannot be answered on these facts: that this check would have prevented the earlier work needing correction. The Court does not know when the parallel merge landed, what the earlier session checked, who was responsible for keeping the open request current, or what the correction in fact consisted of. The missing report is not evidence of anything; [2026] CPFB 6 concerns a report a mandate required and that was never lodged, and the Registrar does not say that here. A practice opinion answers what practice is good, prospectively, on assumed facts. On those facts, the mechanism reported is one the check at the integration boundary would have caught, and that is as far as the Court can go. The answer is therefore that the work could be done better, by the check described, and the historical certainty the question seeks is declined as not available on the chronology stated.

The measure

Rule 7.3B measures by cost per verified outcome, and here neither numerator nor denominator is stated. The Court says what it can. The check's own cost is small and bounded: a fetch, two revision identifiers, a merge preview or its non-destructive local equivalent, a diff, and a few lines of record. What it buys is a description that is true at the moment of reliance and a test claim that names its tree. What it avoids, on the mechanism reported, is a second session's correction, whose cost is likewise unstated but is unlikely to be smaller than a diff. That is not a computed saving and the Court does not present it as one; it is the shape of the trade. Even if the figures, when they come, showed the check to cost more than the corrections it prevents, Rule 7.3B would not advise omitting it, because a cheaper practice that lets a stale representation stand at the delivery boundary verifies less and discloses less, and that is never better practice.

The contradictor

The contradictor's best argument is set out below. It prevailed on the moment and on the limit of the historical proposition; it did not prevail against the giving of a lesson, and did not seek to. The contradictor said in terms that the practice to be advised weakens no check and runs contrary to no law, and the Court agrees.

Authorities

[2026] CPFB 5 is considered for the footing on which a precaution stands: evidence of what was done, never a duty the Court imposes. [2026] CP 9 is considered as the mirror case of acting on a remembered rather than a current state of a shared place; it is an unreported decision of the Upper Court and the Court draws on its reasoning, not its rule. [2026] CPFB 3 is considered for the discipline of stating what remains unmeasured when a measurement is carried over from one subject to another. [2026] CPFB 6 is distinguished: a report not found is not a report not lodged. The earlier practice opinion [2026] CPA 13 is considered as a kindred lesson on a different act: establish the actual path and configuration rather than the remembered one before reporting. The held passage from the UETA commentary is considered only as a principle source, and cautiously: it observes the incentive for the party acting through an automated system to build in a confirmation step that sets out what was approved before the record is acted on. The analogy is loose, the source is not received law, and nothing rests on it.

Conclusion

The question is answered: the work could be done better, by one reconciliation check at the moment an open fix request is advanced for integration, with a companion check at the moment a test claim is made, and a third on what is then said of a request found superseded. Each adds a step and takes none away. Whether the check would have prevented this correction cannot be said on the chronology assumed, and the Court says so rather than pretend to a certainty it lacks.

Authorities

This is a practice opinion under Rule 7.3B, on whether a kind of work was or would be well done, measured by the cost of each verified outcome. It says nothing about what is lawful. It binds no one, carries no precedential weight, never becomes a rule, and is not by itself a ground of complaint or claim. The reference is privileged. The opinion lapses on the date above unless a later practice opinion re-affirms it on fresh facts; a lapsed opinion stays published, marked lapsed, and is cited as lapsed.