# End-to-end service journey — Phase 5C Inspected baseline: `303b29c` (Phase 5B). Phase 5C adds no schema, permission or lifecycle; it only adds operational screens over the existing services. This map records actual services, not a new lifecycle. UAT results and remaining interface gaps are recorded separately in UAT_VERIFICATION.md and UAT_GAP_REGISTER.md. | Step / authoritative records | Supported operation and transition | Interface / capability | Evidence and next action | | --- | --- | --- | --- | | Organization, catalog, taxonomy, role assignments | Existing configuration services and validated master models | `/settings/`, trusted Admin | Active center, policy, applicable taxonomy and scoped capabilities | | Customer, Device, identifiers, ownership | `create_customer`, `register_device`, `assign_device_owner` | Customer creation in Front Desk; **customer-owned device registration** `/workspace/customers//register-device/` requires `devices.add_device`, `devices.add_customerdevicerelationship` and `devices.view_device` in the customer's company | Customer number and device identity; choose visit | | Purchase / warranty evidence | Device evidence services, intake warranty snapshot | Device Admin | Coverage context is not commercial responsibility | | Appointment / QueueEntry | `book_appointment`, `check_in` OR `add_walk_in`; WAITING → CALLED → SERVING | Front Desk; create/check-in appointment, manage_queue. A queue entry with a service case shows **Open job card** to the job card | FrontdeskEvent history; create intake | | ServiceCase | `start_intake` delegates `create_service_case`; RECEIVED | Front Desk; manage_queue + service.add_servicecase | One case per queue entry, immutable intake/warranty snapshot | | Engineer assignment | `assign_service_case_engineer`, reassign, unassign; RECEIVED → ASSIGNED | `/workspace/cases//workflow/assignment/` with `service.change_servicecase`; Admin workflow remains available | Assignment history and end reason; assigned engineer begins diagnosis | | Diagnostic assessment/finding | begin/add finding/update/remove/complete/note/abandon diagnostic services; ASSIGNED → DIAGNOSING → DIAGNOSED | `/workspace/cases//workflow/diagnosis/` for the current assigned engineer with `service.handle_servicecase` | Fault required, cause may be NULL; immutable completed findings | | Quotation family/revision/lines/decision | create/set lines/submit/record decision/revise; DRAFT → SUBMITTED → APPROVED or REJECTED | `/workspace/cases//commercial/quote-*/` with `commercial.manage_servicequotation`, `commercial.record_quotationdecision` | Explicit responsibility and approval obligation; spare line row, compatible parts only | | Repair execution/action | begin/add/update/remove/perform/complete/note/abandon repair services; DIAGNOSED → REPAIRING → REPAIRED | `/workspace/cases//workflow/repair/` for the current assigned engineer | Planning allowed before approval; performance/consumption/completion gated | | Inventory receipt, request, reservation | `receive_stock`; `create_parts_request`; `approve_parts_request`; `reserve_parts`; `release_reservation` | `/workspace/cases//parts/receive|request|approve|reserve|release/` with the matching `inventory.*` capability; signed evidence token and UUID command key | Ledger receipt, approved demand, active or released reservation | | PartsIssue / PartsDisposition | `issue_reserved_parts`; `consume_issued_parts` OR `return_unused_parts` | `/workspace/cases//parts/issue|consume|return/`; consumption is restricted to the engineer's own unresolved issues | Store → engineer custody; consumption needs a performed repair action; unused returns retain evidence | | ServiceQualityControl + checks | submit/begin/check/complaint/summary/pass/fail/abandon QC | `/workspace/cases//workflow/qc/` for an independent eligible inspector with `service.perform_quality_control` | REPAIRED → QC_PENDING → QC_IN_PROGRESS → QC_PASSED; failed QC returns DIAGNOSED for rework, which needs a revised approved quotation | | Delivery release | `mark_service_case_ready_for_delivery` | `/workspace/cases//workflow/delivery/` with `service.handover_servicecase` | QC_PASSED → READY_FOR_DELIVERY, authoritative readied_at and identity snapshot | | Invoice / allocations | prepare/reconcile/finalize invoice services | `/workspace/cases//commercial/invoice-prepare|invoice-reconcile|invoice-finalize/` | Consumption is prepared automatically; labour is confirmed explicitly; invoice value is not revenue | | Payment / allocation / receipt | `receive_service_payment`; `reverse_service_payment`; `authorize_due_release`; settlement summary | `/workspace/cases//commercial/payment-receive|payment-reverse|payment-release/` | Posted allocation and receipt; current balance; handover is refused until the balance is settled or an authorized release exists | | Handover / closure | `handover_service_case`, `close_service_case` | `/workspace/cases//workflow/delivery/` with `service.handover_servicecase`, then `service.close_servicecase` | Financial and inventory clearance, identity/accessory reconciliation; DELIVERED → CLOSED | | ServiceSla / escalation | enroll, monitor, record_escalation | SLA UI; monitor_sla, view_sla | Starts at received_at, stops at readied_at; explicit enrollment/monitoring | | Notification / attempts | workflow_notification / after_commit_notification, send_notification | Communications UI; send_notification + source visibility | Explicit hooks, not automatic callbacks on every business service; no UAT external transport | | Reporting | Existing dashboard, service, inventory, commercial queries | Reports; respective reporting capabilities | Current state versus period events; authoritative complaints and assessment co-occurrence | Important differences from the conceptual journey: - Appointment intake is recorded as WALK_IN by the existing intake bridge; the QueueEntry retains its appointment relationship. There is no APPOINTMENT case channel. - Repair execution may open before approval; performance is a separate operation. - QC pass is distinct from ready-for-delivery, which is distinct from handover. - Approval does not reserve stock; issue transfers custody, not consumption. - Invoice preparation can precede QC completion; finalization applies its existing authoritative technical and commercial preconditions. - Communications hooks and SLA enrollment are explicit integrations, not implicit effects of every service call. UAT must invoke the supported integration boundary. - Some older creation/assignment services enforce integrity and actor attribution, not caller authorization; their UI boundary must enforce permissions. Tests must not claim those low-level APIs independently authorize callers. - RootCause NULL remains Unknown / Unconfirmed. Warranty context never silently establishes WARRANTY payer responsibility. - Invoice preparation allocates consumption automatically but never labour; confirmed labour is an explicit reconciliation input. - Rework after an approved quotation changes the approved repair scope, so the revised quotation must be submitted and approved again before the new work can be performed. - Handover is refused while a finalized invoice carries an outstanding balance. Ordinary payment reduces it; only `authorize_due_release` records a separate, authorized waiver. - Only a compatible spare part can be priced on a quotation line, and only actually consumed parts are billed automatically. Every Phase 5C screen reuses the frozen domain form and service of its step. The operational boundary decides only whether an action is *offered*; it never reimplements a transition, eligibility rule, ledger effect or total. Personas are test capability bundles, never hard-coded runtime role names: Front Desk, Engineer, Parts/Warehouse, independent QC, Commercial/Cashier, Financial manager (payment reversal and authorized release), Supervisor, and configuration Administrator. Non-administrative personas are non-staff/non-superuser and use same-path scoped role assignments.