Phase 3 · Fit: map their business onto the bricks

Produce ERP_<MODULE>.md (from modules/template.md, v3) and the change list: every difference from the reference, each with its depth and any warning. Back: dodil://erp/build.

Steps

1. Map each part (modules/lifecycle.md §3): entities → prefixed tables with natural keys; person stories → use cases and screens; system stories → jobs with a named place to run (Ignite has no scheduler); integration stories → calls to the owning brick; actors → <namespace>:<object>:<verb> permissions.
2. Classify every difference from the reference as one change item, at one depth:
   • 1 configure: a row the brick already takes (a step, a timer, a lane, an approval, a condition, a stage, a cap). Cost in words: "a setting, minutes".
   • 2 extend: a capability no brick in the composition provides, in the customer's own brick. Hooks are not built yet: a need for one is a depth-3 item or a platform request.
   • 3 own: anything else. A fork of the brick in their org. "Your own copy: upgrades need the change re-applied."
3. Check each item against the foundation BEFORE you agree to it. Refuse, with the reason, anything that deletes an account or data with no approval and no completed transfer before it (HR: "delete the leaver on their last day, skip the drive handover" loses what they own; offer: access off on the last day, delete after the transfer; lab, 2026-10-18), renames a stable key, weakens a permission or row visibility, breaks a shared key or exact money, or copies erp-platform.
4. Flag best-practice deviations in amber: the warning, its source (standard: or typical:), and leave it open until the customer accepts it by name.
5. Write the change list, apply it, show it again. For HR the change list IS config/hr.calls.yaml (the file the build and the bench replay): each item one row, appended in order, through the brick's own use cases: change_playbook (add_step, remove_step, remove_approval, set_owner, set_timing, by step key; see bricks/brick-hr/README.md) or a keep_configuration settings row. After each item re-run 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 and show what changed: the step, the new deviation and its class, any scenario that no longer walks. A row the brick refuses (409: it breaks the kept foundation) stops the export with the brick's reason: give the customer that reason in plain words, offer what the foundation allows, and take the row out. Summarise the list in the Deviations and Reference diff sections. The customer's BPMN is always the reference plus this list; never edit the BPMN itself.
6. Review the design in parts with the customer: who uses it and the screens, then the main flow, then what runs on its own, then what comes later. Confirm each before the next.

No BPMN editor yet: take changes in chat, describe each on the diagram, ask, then apply it (step 5).

Example (config/hr.calls.yaml)

- { use_case: install_localisation_pack, args: { pack: gb, with_playbooks: true } }
# "a director signs every contract"
- { use_case: change_playbook, args: { playbook_id: employee-onboarding, change: add_step, before: [send_contract],
    step: { kind: approval, title: Director approves the contract, responsible_group: director } } }
# "drop the rate approval for employees" (a warning: SC-HR-09, -29, -30 no longer walk)
- { use_case: change_playbook, args: { playbook_id: employee-onboarding, change: remove_approval, key: approve_rate } }
- { use_case: keep_configuration, args: { catalogue: settings, rows: [ { key: task_chase_every_days, value: "2" }, { key: approval_chase_every_days, value: "2" } ] } }

Done when

• Every difference is one change item with a depth; none breaks the foundation; every amber one has its warning and source.
• The customer has SEEN the BPMN (erp-compose bpmn / process) and every deviation on it.
• ERP_<MODULE>.md has every v3 section, empty ones saying "none, because …".

Next: dodil://erp/phase/signoff