- Shipped
- August 27, 2026 at 6:50 AM UTC
- Author
- Kamo
- Commit
- 87af172
SW3 implemented FulfillmentPolicy as the first member of an interface that had none, and nothing ever called it — a grep across kamo-shared-library and SecurityService outside its own package returned two hits, both javadoc. ServiceJob had zero rows in every environment and always would. processOrderPaid creates one FulfillmentOrder per line item while createFromCommitment takes a whole Commitment, and that granularity mismatch is why the call site was never written. Resolved by asking once per commitment, before the per-line loop. The loop stays exactly as it was: EngagementLifecycle, InventoryConsumption and PATCH /fulfillments/{id} all read those rows, so a service commitment now yields both — a job for the work and the fulfilment rows the rest of the system expects. acceptServiceQuote gets the same ask, after its SERVICE_AGREEMENT context is attached (which is what supports() matches on there). Its FulfillmentOrder and its WorkOrderDTO return are untouched. Without it, an accepted service quote would vanish the moment the work-order list moves onto ServiceJob. Injected as @Autowired(required = false) List<FulfillmentPolicy> with an empty default rather than the concrete policy, so a second vertical needs no edit here. Note the list is NOT self-defaulting: a plain @Autowired collection with no candidates raises UnsatisfiedDependencyException rather than resolving to an empty list — measured, not assumed. Tested behaviourally: CommerceService injects by field, so it can be built with new and handed Proxy-based recording repositories together with the real ServiceFulfillmentPolicy. Removing the two call sites turns 3 of the 6 tests red; moving the ask inside the per-line loop turns 1 red on a three-line order.