Two Checkouts, One Path
The family keeps every repository at the same path on every Mac. That is convenient and slightly treacherous. A worker on the laptop opens ~/…/cwkPippa and it looks exactly like office's ~/…/cwkPippa. It is not. It is a different directory on a different disk, and the services that actually run the code run on office.
So a laptop worker's commit is, on its own, worth nothing to anyone. Office cannot see it. Office's running service does not run it. Dad, switching between machines, may sit down at office and build on a tree that is missing it. The previous two lessons got a worker running on another Mac; this one is about getting its work back.
What the Envelope Says
When the engine sends a work envelope to a chat whose host is anything but office (or the neutral compatibility label a CLI taker can carry), Coordinator.prompt adds one paragraph. You can read it in the first code block below, straight from the adapter. In order, it asks the worker to:
- Catch up before touching anything:
git fetch origin, then a fast-forward merge. Origin carries the office checkout's pushed work. - Commit and push when the work is done.
- Verify the remote branch SHA matches HEAD. Not "the push printed no error". Origin's own answer.
- Pull it through on office over ssh with
git -C <the same repository path> pull --ff-only, "because office runs the code". - Report only after that push and pull-through are verified.
The one-liner in step 4 quietly assumes office's checkout sits on the same branch. If it does not, pull --ff-only fast-forwards whatever branch office happens to be on and can exit 0 without your commit anywhere near it. The sketch below therefore checks office's branch first and office's resulting HEAD last: verify a step by its result, not by its exit code.
The comment above it in the source gives the reason in one line: office is where the code runs and origin is the ground truth between Macs (Dad, 2026-10-08), "so no commit stays stranded on a laptop."
Why the Remote, Not a File Copy
You could imagine a shortcut: rsync the changed files from the laptop to office and call it done. Every property you need is missing from that picture.
- A copy has no ancestry. It cannot tell "office moved on while I worked" from "office is behind me". A fast-forward can.
--ff-onlyrefuses the moment the two histories diverge, which is precisely the case where a blind copy silently erases someone's work. - A copy has no receipt. A SHA on origin is a fact anyone can check from any Mac, at any time, without trusting the worker's word. "I copied it" is a claim.
- A copy needs the two Macs to meet. Origin is a third place that neither Mac owns. The laptop pushes when it is ready; office pulls when it can; either one can be asleep at the other's moment.
Office's checkout is also, most of the time, dirty with other sessions' work in progress. pull --ff-only takes only the new commits and lets git refuse to overwrite a local change the merge would touch. A file copy would simply overwrite.
Commit Is Push, and the SHA Is the Receipt
This instruction did not appear from nowhere. The family's completion contract says that finished work is committed and pushed at once, and that the push is proved by the remote branch's SHA, never by a push command starting or a stale tracking ref. On 2026-10-04 Dad spent a morning on local-only commits: ten of them, in seven repositories, had sat unpushed for up to nineteen hours, and one became a merge conflict on the laptop. Every one came from a session that never loaded the file where the rule was written. So the rule moved into git itself: a global hook runs after every commit, merge and finished rebase, and in a repository directly under the family's projects folder, on a branch that tracks a remote, it pushes and prints one line naming the SHA it carried. A failed push prints a loud block that means the work is not done. Mind the edges, because they are exactly where a stranded commit hides: the hook skips the public site's repository, which Dad pushes himself, it does nothing on a branch with no upstream, and a repository with its own local core.hooksPath never runs it at all, since git lets the local setting win. "The hook will push it" is a property of the repository, not of git, which is one more reason the envelope asks for an explicit push and a verified SHA every time.
The envelope is that contract, delivered to the one worker most likely to break it: a chat on a Mac where nothing else will notice a stranded commit. And it adds the step a single-Mac rule never needed, the pull-through on office, because "on origin" is still not "on office".
Be just as strict about the next gap: "on office" is still not "running". A long-lived service loads its code when it starts, so a change pulled into its checkout runs only after that service restarts or redeploys, which is a separate step with its own owner and its own proof. Coop's own docs keep production runtime uptake as an acceptance gate apart from the code landing. The envelope asks the worker for the pull-through; it does not let the worker claim the restart, and a report should not either.
The Shared-Checkout Note, Across Hosts
Track 3 showed the shared_checkout disclosure: when another session's active dispatch declares a write scope that overlaps yours, the envelope lists it and tells you to stage and commit only your own files, by explicit path. The engine computes that overlap by path. It does not ask which Mac each path lives on, and because every Mac uses the same paths, a laptop worker and an office worker in the same repository are disclosed to each other.
Strictly, those are two directories, and neither can stomp the other's working tree. But they still meet, at origin. On your own Mac the instruction keeps you off a neighbor's dirty files; across Macs, the fetch-and-fast-forward before you start and the verified push at the end are where two sessions' work actually collides, and where it gets caught. The disclosure errs toward telling you, which is the right direction to err.