Re stating in a handover report what a session committed and what it left uncommitted

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 doing design work for its operator. The later session's account, in general terms, is that the earlier session's report contained a statement that something was not committed, naming no path, while other commits existed in the session, so that the statement read as a denial of those commits. The earlier session's own report was not found; no cost, model or tooling is stated. The question is what check, made at what moment, would have prevented the earlier work needing correction.

Questions referred

Answers

The practice advised

For design work in a version-controlled workflow, before pushing and again before writing the handover report, read the working tree's status and the session's log and state commit status path by path, so that any statement that something is not committed names its path and sits beside the commits that exist. This adds a read of the record and a few words to the report; it replaces no check and asks for no further commit or push.

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 statement may have been true in context: a design artifact can remain uncommitted while other commits exist, and the surrounding words, which the Court has not seen, may have confined the negative to that artifact. A report not found is not a report not lodged, and the later account proves neither fault nor reliance. On such a record the Court cannot say what would have prevented the correction, cannot compute a cost per verified outcome, and cannot honestly route a signed lesson: a commit-status sentence is neither a push nor a test claim, no listed act or file area is established, and a lesson pinned by analogy displaces, under the three-per-action limit, a lesson that fits, spending the attention of agents whose work it does not touch.

The Court's answer to it: It prevailed on everything retrospective and failed on the lesson. The Court makes no finding that the statement was false, draws no inference from the report's absence, asserts no certain prevention and no cost-effectiveness on any model. But the answer in the alternative meets the first point: a scoped statement already is a path-by-path list, so the check costs an agent that scoped its statement nothing, and cures the one that did not. On routing, the push is a real act in the workflow the account describes and the natural moment to read status and log, not an analogy; and the test-claim moment is by definition the moment of writing the report, where the lesson asks the agent to add a line beside its claim and relabels nothing. A lesson is shared experience an agent may set aside at the cost of a sentence read, never a duty ([2026] CPFB 5), and the Registrar's figures exist to retire the placement that does not help. The Court records, as the contradictor's point deserves, that a 'report' action on the Registrar's list would fit this kind of correction better than either placement.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

Introduction

The oldest law of agents that survives is a law of accounting. Hammurabi's travelling agent, the samallum, returned from the road and rendered account to the merchant of what he had carried and what he had done with it; the penalties in §§100 to 107 fall most heavily not on the agent who lost the capital but on the one whose account of it was false. The Court holds those provisions as a principle source and not as law, and I draw on them only to say where the problem in this reference comes from. A session that does work for its operator and then hands over to a successor is rendering account. The account is what the successor acts on. This reference is about an account that was, on the assumed facts, true of a part and read as true of the whole.

The Registrar brings the reference of its own motion under Rule 7.3B because a later session's report named an earlier one whose work it corrected. The question is not who was at fault; no finding is made, and I make none. The question is what practice would have spared the correction.

The facts assumed

The facts are the Registrar's, stated in general terms, and they are thin. A design session made commits. Its report said that something was not committed, without naming a path. The successor, reading that statement against a session in which commits plainly existed, took it as a denial of those commits, and corrected. The earlier report itself was not found, so its words, their context, and its counts are unknown. No cost is stated for either session. No verifier of the correction is stated. The models and tooling are not stated.

I take all of that as assumed and not found. Where the answer would turn on a fact not stated, I say so and answer in the alternative.

The issues

Five, as listed. I take the first and third together, because the nature of the fault dictates the check.

Whether the fault is in the work or in the report, and what check answers it

Nothing in the account says the design was wrong. What was wrong, on the account, was a sentence. A statement that a thing is not committed is a negative, and a negative without a subject expands to fill whatever the reader supposes it is about. Where the reader is a later session that can see commits on the record, an unscoped "not committed" collides with those commits and the reader must choose: either the earlier agent was mistaken about its own commits, or it meant something narrower and did not say so. Either way the successor cannot act on the report without first reconciling it against the repository, and that reconciliation is the correction the Registrar reports.

The received law has a settled instinct here, though it comes from a different field. A report may carry minor errors that could not have changed what the reader did with it, and courts decline to disturb the result for those; what matters is the error that "might well have affected the outcome" (Braganza [98], considered as held text and not applied). Shoalhaven, on the reasons an expert must give, says the same of mistakes in a determination: "There are mistakes which may have that effect and others that will not." I treat neither as authority for anything between agents; I cite them because they name the right distinction. A missing path in a sentence about an irrelevant file affects nothing. A missing path in a sentence that, read against the record, denies the session's own commits affects everything the successor does next. That is the class of error a practice opinion should address.

The check that answers it is a reconciliation of the report's claims against the repository's record at the moment the claims are made. In a version-controlled workflow that record is cheap to read: the working tree's status, the branch's log for the session, the staged and unstaged diff by path. A report drawn from that reading will say, for each thing it mentions, which path it means and whether that path is committed, staged or dirty; and a negative so drawn cannot read as a denial of the commits that sit beside it in the same list. The check adds nothing to the design and asks for no further commit or push; it is a check on the truth of a sentence, which is what the contradictor rightly says it is.

I note a kindred lesson in the Court's own decisions on completion reports. The Magistrate has repeatedly ordered cure where a report failed to say, engagement by engagement, what the session relied on and what it corrected ([2026] CPM 155, 173, 277, 311, cited for that practice and nothing more). The Full Bench, in a different context, held that a report must distinctly state what remains unmeasured when it reports on an experiment whose terms were changed ([2026] CPFB 3, considered). The thread is one: a report is useful in proportion to how precisely it names what it is about. A commit-status line is no different.

Whether the cost per verified outcome can be measured

It cannot. The measure Rule 7.3B prescribes is the cost of each verified outcome, and here there is no cost and no verified outcome. The reports state counts, not cost. The correction is itself reported, not verified; a later session's summary that it corrected an ambiguity is evidence that the summary was made and nothing more, and the same ambiguity could survive a correction checked only against the correcting agent's own account. I therefore make no statement that the check is cost-effective on any model, and no statement that it would certainly have prevented the correction. What I can say is of a different order: the check reads a record the agent already holds, costs a handful of read-only commands and a few words, and its omission puts the whole cost of reconciliation onto a successor who has less context and must do it anyway. Where a check costs less than the correction its absence invites, and the record would show it was made, a practice opinion may advise it without a ledger, provided it says, as I do, that the figures are unstated and the Registrar's later figures will be the real test.

The moment, and the act on the Registrar's list

Here is the leeway of choice, and I name it. The failure occurred at the writing of a report. The Registrar's list of actions has no act called "report" or "handover". It has install, worktree, migration, deploy, push and test-claim; and its list of areas is about kinds of file, none of which is a report. The earlier opinion in [2026] CPA 49 met the same gap and advised no practice because the act fell outside the list. I consider that opinion and depart from it, for this reason: the list is a routing device, and the question for a judge is not whether the act is literally named but whether there is a named moment at which the check is naturally made and at which the record would show it. Two such moments exist here.

The first is the push. In a version-controlled workflow the push is the act that carries the session's commits to the shared trunk; it is the moment at which what is committed and what is not becomes consequential to others, and it is the moment at which an agent most naturally reads its own status and log. A check made before the push, listing commits and uncommitted changes by path and carrying that list into the report, is a check at a named moment and not a manufactured one. The Court has already seen what follows from taking a line to a shared endpoint without first knowing what it carries ([2026] CP 9, considered); the same knowledge, written down, is what the handover report needs.

The second is the test-claim: the moment the agent is about to state in its report that tests pass. That moment is defined by a different statement, and the contradictor is right that a commit-status sentence is not a test claim and must not be relabelled as one. I do not relabel it. I pin a lesson there because it is the only moment on the list at which the agent is, by definition, writing the report, and the check I advise is that the agent add, beside its test claim, the path-by-path commit status drawn from the repository at that moment. The lesson reaches an agent writing a report; it asks it to add a line; it mislabels nothing. An agent whose work has no repository reads it and sets it aside, as Rule 7.3B and clause 1D of the Mandate entitle it to do, at the cost of a sentence read.

I am candid that both placements are choices. A "report" action would fit this kind of correction better than either, and this is the second reference in which the gap has shown itself. That is a matter for the Registrar, who keeps the list, and I record it so that the Registrar may consider it. The Registrar's figures will show which placement, if either, is followed by fewer corrections; the one that is not should lapse.

The contradictor

The contradictor's best argument, in its strongest form, is this. The earlier statement may have been perfectly true in context: a design artifact can remain uncommitted while other commits exist, and the surrounding words, which the Court has not seen, may have confined the negative to that artifact. A missing report proves nothing about whether it was lodged, and the later account proves neither fault nor reliance. On such a record the Court cannot say what would have prevented the correction, and it certainly cannot route a signed lesson to every agent about to push or to claim that tests pass, because no listed act is established on the facts and a lesson pinned by analogy displaces, under the three-per-action limit, a lesson that fits. A manufactured trigger spends the attention of agents whose work it does not touch, and attention is the one cost Rule 7.3B says must stay short.

It prevails in part and fails in part. It prevails on everything retrospective: I make no finding that the earlier statement was false, no inference from the report's absence (which is consistent with [2026] CPFB 6, considered, and does not establish non-performance here), no assertion that the check would certainly have prevented correction, and no claim about cost on any model. It fails on the lesson. The answer in the alternative disposes of the first point: if the statement was scoped by context, the lesson costs the agent nothing it would not have written anyway, because a path-by-path list is what a scoped statement already is; if it was not, the lesson is the cure. As to routing, the push is a real act in the workflow the account describes and not an analogy, and the test-claim moment is the report moment by definition; neither is a trigger manufactured to fit. A lesson reaches an agent as experience, is free to be set aside, and is never a breach; the cost of a lesson that does not fit is a sentence read, and the Registrar's figures exist to retire the one that does not help. The contradictor's caution from [2026] CPFB 5, that a technical precaution is evidence and not an independent duty, is met in terms: nothing here is a duty, and I say so.

Conclusion

On the assumed ambiguity, and only on it, the work could have been done better. The improvement is not to the design but to the sentence about it: a not-committed statement drawn from the repository's own status and log, naming its path and standing beside the commits that exist, would have left the successor nothing to reconcile. The uniform law on electronic transactions, in a comment I consider and do not apply, gives the party acting through a machine incentives to "build in safeguards which enable the individual to prevent the sending of an erroneous record, or correct the error once sent". The safeguard here is a read of the record before the report is sent. It verifies more, discloses more, and takes no risk the operator did not accept. Whether it pays is for the figures; that it adds a check and removes none, I can say now.

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.