Phase 3s · Sign off: the contract

A hard stop. Nothing in phase 4 starts without it. Produce one sign-off record per module (signoff/<module>.json) and its rows in ERP_<MODULE>.md. Back: dodil://erp/build.

What is signed: ONE process per module (the playbook their changes are about, e.g. employee-onboarding): its BPMN (the reference plus the change list, never hand-edited), its scenarios and its deviations, each warning accepted by name. A second record for another playbook REPLACES the first (erp-platform 0.7-0.8; lab, 2026-10-18): sign one, list the rest as Decisions.

Steps

1. Generate the three from the final change list: for HR uvx --from git+https://git.dodil.io/dodil/erp-platform.git@v0.7.3 erp-compose process --module hr --playbook <playbook> --calls config/hr.calls.yaml (show_playbook_bpmn, scenario_paths and playbook_deviations → processes/<playbook>.bpmn, processes/scenarios.json, processes/deviations.json). No brick (erp-platform v0.8.0): uvx --from git+https://git.dodil.io/dodil/erp-platform.git@v0.8.0 erp-compose bpmn --from ERP_<MODULE>.md --out processes/<module>.bpmn.
2. Its short hash is the BPMN's (it prints it; layout ignored, any process change breaks it). Never a hash of ERP_<MODULE>.md or of your notes (lab, 2026-10-18).
3. Never ask for sign-off of a design file without the diagram: the signed artifact is the BPMN, not the markdown. Send the customer, in the message itself: the diagram (or a PNG/PDF of it), the scenarios in their words, the deviations with their warnings, every scenario that no longer walks, by id, and why, and the short hash.
4. Wait for their words. An approval is a message the customer typed naming the version, e.g. "I approve v1 (822e5d78)". "Looks good" to a different question, or your summary, is not one.
5. Record it, from the project folder. signoff record refuses a scenario that does not walk, so first leave out the ones they accepted by name: re-run step 1 with --accepted-broken SC-HR-09,SC-HR-29 (it refuses an id that still walks; the hash does not change).

   uvx --from git+https://git.dodil.io/dodil/erp-platform.git@v0.7.3 erp-compose signoff record \
       --module hr --bpmn processes/employee-onboarding.bpmn \
       --scenarios processes/scenarios.json --deviations processes/deviations.json \
       --approver "Jane Doe, Managing Director" --file ERP_HR.md
   

   It writes signoff/hr.json (hash, scenario ids, accepted deviations, approver, signed_at; a re-sign keeps the old one under supersedes), a copy signoff/hr.bpmn, and the Processes, Scenarios and Deviations sections of ERP_HR.md. Its short hash must be the approved one. It refuses a foundation deviation (what a brick keeps cannot be signed away: change the process back) and a scenario that does not walk. No brick (v0.8.0): uvx --from git+https://git.dodil.io/dodil/erp-platform.git@v0.8.0 erp-compose signoff record --module <m> --from ERP_<MODULE>.md --approver "<name, role>" (it draws and records the source; v2 on needs --reason). Then a Decisions line quoting their words; Status: "Design: signed off <date> by <name>".
6. Check it holds, now and after every build step:

   uvx --from git+https://git.dodil.io/dodil/erp-platform.git@v0.7.3 erp-compose signoff verify \
       --module hr --bpmn regenerated.bpmn
   

   conforms exits 0. A mismatch exits 1 and prints the change by stable id, for example ~ task Task_send_contract [step send_contract] / lane: Lane_hr → Lane_it. A change after sign-off is a change request (dodil://erp/phase/change) and a new signature, never a quiet edit.

Done when

• signoff/<module>.json exists, written by erp-compose signoff record.
• erp-compose signoff verify says conforms on a freshly regenerated BPMN.
• The record's scenarios and deviations are in ERP_<MODULE>.md; the approval (their words) names the hash.

Next: dodil://erp/phase/build