What the consultant and the developer see at each step, and the tooling that runs underneath.
Automotive distributor. Vehicles leave the pre-delivery inspection (PDI) warehouse on transfer orders and go to a logistics center.
Orange: a person decides. Green: runs on the dev VM. White: Claude does the work and leaves evidence.
Claude never starts from a blank chat, and never fills a gap in the spec with its own assumption.
| Question | Recommendation → decision |
|---|---|
| Privilege level (spec said "Delete") | Invoke: the button runs an action |
| Data type of the "box" field | Extend the standard cluster position EDT |
| Filter clusters by profile? | No: template + route group + not locked |
| Keep apart from an existing custom cluster flow | By route group, chosen in parameters |
| Not in spec: license plate on each work | Yes, like other cluster creators |
Loaded automatically every session: "only the target scenario changes", "no design without impact analysis", "the consultant decides".
CLAUDE.md: package/model, dev URL, company, where the standard source is. Missing → Claude asks first.
DECISIONS.md + CONTINUE.md: the next session picks up exactly here.
Before any design: who already touches these objects, in the standard and in the customer model. Answers come from an index, not from memory.
q nesne InventTransferOrders # object + all extensions q coc InventTransferOrders # CoC classes, wrapped methods q kaynak WhsWarehouseRelease transferOrderFormRelease
WhsWarehouseRelease → call it, don't copy itEach becomes a regression scenario in step 6.
11 objects: 4 new, 7 updated. Every metadata file Claude edits is checked automatically by a hook, in the same turn.
| new | Action class: release → cluster → shipment account |
| new | EDT, menu item (action), privilege |
| upd | Transfer order form + class extension (the button) |
| upd | Warehouse parameters table + form extension |
| upd | Label files (3 languages) |
Why it matters: a valid XML can still drop a control silently. D365 loads it without error and the button is simply not there.
No git, so delivery is a self-checking zip. The same tool on every project.
Clean on the first build.
Any patch can be rolled back from its backup with one parameter.
Label files are merged by label ID, so parallel jobs touching the same label file don't overwrite each other.
First we let Claude click through D365 in the browser pane. Every click was a model round trip that re-read the whole conversation, and every re-run paid it again.
The consultant gets a Word test & delivery document with screenshots. On reading it they asked: "the button should reserve the lines itself."
Request → decision → patch 2 → dev → tests → updated delivery document: the same day.
Claude Code does the reading, writing and checking. People keep the decisions, the environment and the responsibility.
The job does not live in a chat. Another developer, or the next session, can continue from these.
| Step | Artifact | Who uses it |
|---|---|---|
| 1–2 | CLAUDE.md, DECISIONS.md, CONTINUE.md | Consultant checks decisions; next session resumes from here |
| 3 | Impact analysis notes + "must not change" list | Reviewer; becomes the regression scenarios |
| 4 | Check results for every edited XML | Reviewer before packaging |
| 5 | Patch zip: patch.json, apply script, readme, backup on dev | Developer on dev; rollback if needed |
| 5 | Build result zip | Claude reads all errors in one round |
| 6 | <job>.test.js + result file + failure screenshots | Re-run after any change, including the follow-up patch |
| 7 | Word test & delivery document | Consultant and customer |
New pitfalls found on the way are proposed to the team library, so the next job starts with them.