Keep every client build resumable across people and agents

Choose one client engagement and imagine another person opening it tomorrow. Write down the repository, branch, environment links, agreed scope, latest tested behavior, unresolved risks, and next task. State where access is managed and who can grant it; never put credentials in the note. Link the client's acceptance criteria and distinguish internal expectations from actual client approval.

Use a hypothetical checkout example: the interface may be implemented while retry behavior is untested. “Payments nearly done” hides the useful distinction. A better note identifies the tested path, missing checks, evidence, and person responsible for finishing them. Keep this dated note beside the delivery artifacts and revise it when scope changes. Ask the incoming builder to restate the next task and flag missing information before editing. This catches gaps without relying on another kickoff call. A folder of files can support the note, but cannot explain which decisions still govern the build.

Create the project in the intended client workshop. Keep its documents, assets, repository links, and delivery notes together. Use Inventory to identify where the work lives, Health to state its condition with evidence, Work to identify the task and owner, Authority for scope limits, and Decisions for accepted choices and rationale. A client request is not the same as an accepted scope change; retain both the request and the human answer.

Connect the agent to the correct project and have it read the brief before starting. Ask for one bounded task rather than a broad instruction to finish the engagement. During work, keep observations separate from proposals. At the end, review the handoff's changed behavior, test results, remaining risks, and next action. Quiet-session drafts use recorded activity and can miss work never recorded; inspect them rather than treating automatic drafting as recovery of the entire session.

Before a delivery update, compare the record with the agreed outcome. Make missing client answers visible. Share only appropriate sections and check what the recipient can see. The current record can reduce reconstruction, but it does not replace formal sign-off or your responsibility to verify the work.

When a client requests another integration, record the requested outcome, the accepted response, and its effect on delivery. Keep the original reasoning understandable. If a previous decision no longer applies, record the replacement and why; do not leave both versions looking current. Give the next agent the changed boundary before it continues implementation.

At a milestone, distinguish released work, merged work not yet deployed, and unfinished proposals. Link the checks actually run and describe missing verification explicitly. A client-facing summary should not expose private access notes or internal speculation. If the recipient asks a question that reveals a gap, add the answer or proposed decision to the reviewed record instead of leaving the correction in email alone. For the final delivery, follow the client handoff use case. Resumability means the incoming builder can act safely from current context, not that every ticket, conversation, or artifact has been copied into one page.