Reading a long conversation on another computer does not necessarily reveal the current truth. A plan, a completion statement and the actual files can disagree.
I built a small synthetic handoff contract. It compares artifact bytes and a supplied data revision; it neither executes conversation instructions nor transfers real accounts or credentials.
State the reference before starting
handoff_manifest contains a grammar schema, expected_revision, files and items. The file map stores bounded filenames and SHA-256 values. Absolute paths, parent traversal and arbitrary extensions are rejected. Instead of reproducing one computer’s folder layout, the contract identifies the artifact contents serving as a reference.
These constraints do not automatically make a file trustworthy. Matching bytes may still contain incorrect claims or instructions that should not be executed. The source must be trusted and document instructions treated as material to review. This function checks byte agreement rather than approving the document’s intent or granting its requested authority.
Connect completion to explicit evidence
Each item has a unique identifier, todo or done status and an evidence list. Done without evidence, or evidence absent from the file map, is rejected. This exposes an unsupported completion claim at the structural boundary. Todo is not an error; verification returns it explicitly as remaining work.
Evidence existence and satisfaction of completion criteria differ. Attaching one file does not establish execution, public verification and a restore rehearsal all occurred. People must inspect the evidence and its scope. The function checks the minimum linkage, not the truth of every business claim or the quality of every referenced report.
Do not apply an old handoff to changed state
verify_handoff compares the expected revision with the value the caller has just read. A change stops verification. It also hashes each supplied file’s bytes and fails on any mismatch. The intent is to prevent continuing from stale code or treating an older conversation description as the present implementation.
Reading current values remains the caller’s responsibility. The function does not discover disks or servers; it compares supplied contents and revision. If those inputs are stale, it cannot know the actual latest state. “Recheck the version” needs a concrete answer about who reads which source, so that responsibility is documented as part of the input contract.
Keep secrets and authority outside the bundle
The synthetic examples contain no accounts, login tokens, environment variables or operational paths. Names and hashes establish agreement, not access rights. Real secrets should remain in an approved separate store. Convenient handoff is not a reason to copy credentials into a conversation or downloadable package.
Verification returns executed false. A person or AI can inspect remaining work without receiving automatic permission to deploy or transmit. Publication and actual ERP mutation are separate scopes in this project too. Instructions, source material, verification results and execution authority must remain distinct even when they appear together in a handoff discussion.
Test the cases that should stop continuation
Tests verify completion counts and remaining items for matching files and revision. Changed bytes, an incremented revision, done without evidence and parent-folder paths are rejected. This is a contract test, not a login or account-transfer exercise on another computer.
A real handoff also needs the current goal, completion criteria, observed results, unverified scope, canonical source locations and next action in readable form. This continuing project records publication state, reports, backups and a separate handoff document for that reason. I share a basis for checking current facts and resuming useful work instead of reconstructing the truth by guessing through a long conversation.