# Operational workspace — Phase 4D Phase 4D is a read-only integration and presentation layer. Existing domain models, relationships, lifecycle services, authorization, ledger calculations and reporting semantics remain authoritative. It introduces no schema or permissions. ## Shell and navigation `apps.operations` supplies `/`, `/login/`, POST `/logout/`, `/search/` and read-only `/workspace/` lists and details. The root dashboard is the default destination of the new application login; safe `next` links retain their usual Django behavior. The existing reporting login retains its frozen `/reports/` default. Both use the shared login presentation. Front Desk, Communications, SLA and Reporting extend `operations/base.html`. Existing content, forms, CSRF tokens, confirmation pages and service calls remain in their own modules. The shell provides a desktop sidebar, collapsible mobile navigation, user identity, organizational context, breadcrumbs, messages, search and POST logout. The context label means **all authorized scopes**; there is no invented global selected-company session setting. Front Desk additionally displays the center currently being viewed. Each module applies its own permission scope. Navigation groups are generated from existing capabilities, never role names. Links require an authorized organizational scope even if that scope currently has no records. Company-level customer/template/policy management does not follow implicitly from access to a center. Reporting section navigation is filtered without changing existing retained-filter or drill-down URLs. Admin remains available for administration and workflows which have no dedicated operational UI. The broad Admin index is advertised only to active staff superusers because older Admin master-data screens are global. Individual Admin record links additionally require native Admin view permission and first pass the operational record's scope. No existing operational screen requires Admin. The shell does not alter Admin authorization or grant native Django permissions. ## Dashboard semantics All cards are conditional on the corresponding existing view capability and calculated in SQL. A signed-in user with no applicable capabilities sees an explicit empty workspace, not privileged counts or an authorization bypass. | Card | Authoritative meaning | | --- | --- | | Open service cases | All visible cases except CLOSED and CANCELLED; includes delivered cases awaiting closure | | Diagnosis / repair in progress | Exact DIAGNOSING / REPAIRING case state | | QC pending / ready for delivery | Exact QC_PENDING / READY_FOR_DELIVERY state | | My eligible assigned jobs | Frozen engineer assignment queue, intersected with case view scope | | My eligible QC queue | Frozen inspector eligibility query, intersected with case view scope | | Appointments today | All appointment statuses with slot date equal to today in the project timezone | | Waiting queue today | WAITING entries for today's authoritative business date | | SLA due soon / overdue | Existing SLA derived-state query; no recalculation or enrollment side effect | | Cases awaiting customer approval | Frozen commercial approval queue | | Finalized invoices with customer balance | Count from existing unsettled-invoice query; not summed across currencies | | Active stock reservations | Existing ACTIVE reservation query, not inferred low-stock/reorder thresholds | | Pending / failed communications | Exact persisted notification status; not provider delivery confirmation | Cards label current state versus today's activity. Near-current multi-query reads are not a transactionally frozen report. Invoice value is explicitly **not revenue**. Stock detail displays ledger on-hand sums, **not** available-to-reserve stock. No calendar, accounting, priority or workflow classification is invented. ## Search and scoped record views Global search supports exact job references, normalized exact IMEI/serial identifiers, customer number/name/mobile (including active recorded contacts), quotation number, invoice number, payment reference/receipt number, part code/name and inventory-location code. Appointments have no invented human reference: lookup accepts their authoritative UUID and links to their existing front-desk day. Scopes are applied **before** matching, count, slicing and rendering. Service and commercial records use their own service-center permission paths. Customer master search requires company-level customer visibility. Device visibility follows the existing front-desk approach: authorized serviced evidence or authorized company ownership evidence, with device permission and exclusion of foreign ownership. A globally registered identifier alone never makes a device visible. Search limits input to 128 characters and results to 10 per supported type, with an explicit truncation indicator. Lists paginate at 25 records. Partial device identifier and broad contact substring searches are deliberately absent. Display fields are explicitly allowlisted; raw contact values, free-form notes, message bodies and financial references are not added to result cards. Search text is echoed only through normal escaped form rendering; no search index or database is created. Records without an operational detail page receive a scoped read-only overview of the authoritative row, with existing workflow/detail links where permitted. No duplicated domain records or alternate mutation services exist. ## Cross-module navigation Case overviews link independently to authorized customer/device records, quotation/invoice/payment history, SLA evidence, case communications and parts requests. Existing diagnosis/repair/QC Admin actions are linked only with the corresponding capability/native access; QC also uses its frozen inspector-visible case predicate. Customer overviews show authorized recent cases and currently owned devices; device overviews show authorized cases. Commercial records link back to visible cases, and payments to visible invoices. Each target rechecks its own scope; a relationship does not grant access. Related lists show up to 10 per relationship, and inventory overview up to 50 ledger positions, labelled as such. ## Responsive presentation and accessibility Shared CSS and small framework-free progressive-enhancement JavaScript live in `apps/operations/static/operations/`. Record cards and dashboards reflow to one column. Existing operational tables stack into labelled records below 760px; labels derive from existing table headings using textContent/dataset, never HTML injection. Long identifiers wrap rather than forcing horizontal page scrolling. Without JavaScript, navigation remains visible and tables retain their headings. Navigation controls expose expanded state, work with keyboard and Escape, and retain focus. The shell includes a skip link, semantic navigation, visible focus outlines, normal form labels, error text, CSRF-protected POST logout and text status badges. No frontend framework or external asset/CDN dependency is added. ## Performance and security Existing SQL query services are reused wherever they already supply authorized results. Presentation adapters add organizational authorization to query helpers whose documented contract does not authorize callers. No in-memory filtering of global datasets is used. Dashboard counts use aggregations/count queries; select_related is used for record displays. Capability results are cached only on the current request, not across users or sessions. Tests bound query counts and verify that adding cases does not add dashboard queries. Read-only endpoints accept GET only, require authentication and send no-cache headers. POST logout retains Django's CSRF protection. Direct object access uses scoped get_object_or_404. Direct permissions, Groups or staff status do not grant business scope. Existing workflow screens remain responsible for fresh permission and lifecycle checks on mutations. No business data is written by dashboard, search, lists or overview pages. ## Known limitations This phase does not replace all legacy Admin workflows, add a company switcher, create new domain actions or provide a universal editable record screen. Devices without authorized ownership/service evidence are not globally enumerable. Appointments are searched by UUID because no appointment-number model exists. Counts are near-current; existing reporting remains the analytical authority. This phase runs focused tests and one quick audit, not the full regression suite. ## Verification On 2026-10-01, 30 new Phase 4D tests and the unchanged reporting-login regression test passed together: 31 tests in 144.489 seconds. Django system checks passed; `makemigrations --check` reported no changes. New tests cover bounded dashboard and search query counts, record-growth invariance, scope isolation, UI integration, contact/identifier search, invoice settlement and inventory presentation. Synthetic shared-shell content was rendered in headless Edge at emulated 390px and 1366px viewports. The phone layout had scroll width equal to viewport width, working mobile navigation and four labelled stacked table cells. Desktop navigation remained visible. This is a shared-layout check, not a claim of full browser coverage of every legacy workflow. JavaScript syntax validation passed. The single `audit_project --quick` run passed all checks and 19 smoke tests (29.175 seconds for tests; 73.499 seconds total). No full audit was run. Frozen tests and historical migrations were not edited. All repository changes remain unstaged and uncommitted. ## Phase 6A — production workspace presentation This enhancement builds on frozen RC1 (`e2dc076`). All new code is in the operational presentation layer. There are no domain, model, migration, baseline test, authorization, ledger or workflow-service changes. No new workflow states are persisted. Milestones are display evidence, never preconditions for writes. ### Navigation and actions The shell groups existing destinations into Operations, Parts & inventory, Commercial, Monitoring and System. Dashboard and operational search remain always available to authenticated active actors. Engineer work and QC navigation require both their business capability and service-case visibility. Customers and devices remain separate authorized destinations within Operations. The new parts-request list uses the existing SQL-scoped request query and is GET-only. Administration retains its existing trusted staff-superuser discovery boundary. Global search submits to the existing bounded, scoped search endpoint; it does not introduce a new search index or broaden identifier/contact access. Capability questions are still resolved together through the frozen bulk resolver and cached only for that request. Templates render already resolved navigation and actions. Each destination independently checks access. The job's first existing authorized workflow is visually primary; related records and other actions are secondary. Technical forms label their submit button with the selected server-provided operation. Abandon/remove/unassign/QC failure and payment reversal receive a distinct destructive appearance. These are presentation changes only: CSRF, signed revisions, commands, idempotency and service validation are unchanged. Errors retain their server-rendered content and receive clearer styling and an accessible progressive-enhancement summary. ### Dashboard definitions All case metrics start from the existing service-case visibility query, including company/center integrity. No missing permission is represented as a zero count. | Metric | Authoritative definition | | --- | --- | | Today's intake | `received_at` date is today's configured local date; all case statuses | | Open service cases | Existing statuses other than CLOSED and CANCELLED | | Assigned, awaiting diagnosis | Exactly ASSIGNED; does not include unassigned RECEIVED jobs | | Diagnosis / repair in progress | Exactly DIAGNOSING / REPAIRING | | QC pending / ready for delivery | Exactly QC_PENDING / READY_FOR_DELIVERY | | My eligible assigned jobs / QC queue | Existing engineer/inspector eligibility queries intersected with case visibility | | Appointments today / waiting queue today | Existing date/status-based front-desk definitions | | SLA due soon / overdue | Existing annotated SLA states, without alternate elapsed-time rules | | Cases awaiting customer approval | Existing commercial query | | Finalized invoices with customer balance | Existing unsettled-invoice query; count of invoices, not revenue or amount owed | | Active stock reservations | Existing active-reservation query | | Communications pending / failed | Existing notification statuses | “Waiting for Parts” is not exposed as a dashboard metric because no authoritative frozen definition exists. There is deliberately no inferred case status or KPI. Parts-request status and reservation evidence remain available under their own names; a request does not by itself establish that technical work is blocked. ### Queue previews Dashboard previews contain at most five authorized records each. Today's intake, ready-for-delivery, engineer and QC job queues use received time then primary key. Today's appointments use slot start then primary key. SLA attention uses the existing DUE_SOON/OVERDUE classification, ordered by due time then primary key. Job previews show reference, center, customer, device model, case status, received time and current assigned engineer. SLA previews show reference, customer, center, due time, assigned engineer and authoritative SLA state. Links open the scoped record or full queue. “Ready for delivery” is a status queue, not a promise of financial clearance or an authorization to hand over. Engineer/QC eligibility remains exactly the frozen helper's behavior. Parts requests have a separate paginated list; no second request lifecycle is added. An empty permitted queue says “No authorized work in this queue.” Missing metric capabilities and filtered lists have distinct messages. ### Job evidence The compact job header shows status, customer, model, center, received time, current engineer and scoped SLA evidence. Active device identifiers are included only if the existing device-visibility query returns the device for this actor. Diagnostic notes, findings, recipient identity documents and contact details are not added to the overview. QC outcome evidence also retains the frozen inspector-visible-case predicate; case visibility alone does not grant access to that history. Without inspector scope, the QC milestone is explicitly unavailable, even though the job header can still show the independently authorized case status. The ten milestones are Intake, Assignment, Diagnosis, Quotation, Repair, QC, Ready, Payment, Handover and Closed. Each uses explicit persisted evidence: latest assignment/assessment/execution/QC, current visible quotation revision, delivery release, finalized settlement, handover and closure. Completion is not inferred from position in the sequence. QC failure is labelled Rework; the latest QC result remains historical evidence while a later repair is underway. The Repair milestone is completed only for an execution completed as REPAIRED. A completed NOT_REPAIRED attempt is labelled Blocked with its recorded outcome; this is a visual distinction, not a new service precondition. An ended assignment is Pending without handover evidence, so unassignment does not imply completion. An assignment ended at recorded handover can be Completed. A cancelled case is explicitly identified. Quotation/payment may be absent or inaccessible. Neither absence implies free work, warranty coverage, approval or settlement. Approved quotations are labelled by revision. Outstanding customer balance is shown from the existing settlement query. A due-release is explicitly distinguished from payment and leaves the balance outstanding. Rejected quotations and unpaid balances use a blocked visual state for that milestone, not a new whole-case gate. Services still decide every operation from fresh authoritative state. QC pass alone does not complete Ready; handover alone does not complete Closed. ### Responsive design, accessibility and performance The existing stylesheet and small framework-free script are extended. Desktop has a sticky sidebar; narrow screens have a nonmodal drawer that focuses its first link, closes on Escape or an outside click, and returns focus on Escape. Without JavaScript navigation stays visible. Global search has an explicit accessible label. Tables retain the existing stacked data-label enhancement. Cards, job facts, milestones and fieldsets reflow without fixed content widths. Status names remain readable text, not color-only signals. Focus outlines, 44px controls, skip link, breadcrumbs and POST sign-out are retained. Today's intake shares the existing grouped case aggregation. Current engineer names are correlated SQL subqueries, not per-row lookups. Queue queries are fixed per permitted section and bounded before rendering. The scoped dashboard query regression includes record growth; navigation asserts one bulk resolver call and request-cache reuse. Existing reporting and shell budget assertions are retained unchanged. Job history reads are bounded to the latest record per relationship. Counts/previews are near-current committed reads, not a single transactional snapshot; services remain the consistency boundary for writes. Receiving continues through existing authorized job actions. Transfers and other legacy Admin operations are not duplicated into new UI workflows or advertised using scope-only permissions that bypass native Admin checks. No heavy frontend framework, provider, deployment, portal or external API is introduced. ### Phase 6A verification — 2026-10-03 - Final new-test run: all 19 tests in `apps.operations.test_ui` passed in 37.689 seconds. New fixtures were corrected to honor existing assignment uniqueness and QC failed-check requirements; no baseline assertions changed. - Existing coverage: 30 workspace tests, 22 end-to-end journey tests and four selected reporting checks passed across focused runs (75 distinct tests with the new UI tests). The combined 70-test integration run passed in 513.089 seconds. The later 51-test run passed all baseline/reporting checks but exposed the new QC fixture omission; the complete 19-test new suite passed after its correction. These are focused results, not a full-project regression claim. - Scoped dashboard: 9 queries, unchanged with growing queues. All-capabilities dashboard: 22 queries, also unchanged with growth. Navigation: 4 queries, with a single bulk resolution and no additional work on same-request reuse. - Frozen reporting budgets: cases 20/24; engineer queue 20/24; complaint and diagnosis reports 9/10 each; inventory positions 8/8; invoices and outstanding balances 9/10 each. Reporting growth invariance also passed. - Headless Edge: 44 synthetic Django-rendered pages at 390px, 768px and 1366px (132 layout checks), with no page overflow or off-screen main action buttons. Mobile drawer opening, visible link focus, Escape closure and focus return passed. Dashboard/job screenshots were visually inspected. This checks native browser layout and drawer interactions; workflow submissions are exercised by Django's test client against isolated test databases, not production data. - `manage.py check`, `manage.py makemigrations --check`, `git diff --check` and JavaScript syntax verification passed. No migrations were created or changed. No full project audit, staging, commit, push or tag was performed. ### Phase 6A.1 final review — 2026-10-03 The complete tracked diff and both new files were reviewed against frozen RC1. The file set remains 12 modified files and two new files, all within operations presentation, its tests and this documentation. No unrelated files, historical migration changes, baseline-test edits or domain-service changes were found. Review corrections are limited to presentation defects and regression coverage: - An ended assignment without handover evidence remains Pending, rather than implying that an unassigned job has completed its assignment milestone. - A completed NOT_REPAIRED attempt displays Blocked and its recorded outcome, rather than a green completed-repair milestone. Domain status remains DIAGNOSED. - Active navigation now selects the specific engineer/QC queue, even with pagination parameters, instead of marking the generic case list. Dashboard and search also receive their own current-page marker. This adds no queries. - New Phase 6A query assertions now enforce the observed 9/22/4 limits rather than looser ceilings. Frozen baseline and reporting assertions are unchanged. Search coverage and matching were not changed. Company-owned sources retain their existing SQL scope before matching/slicing; global spare-part masters keep their existing capability gate. Exact identifier matching does not add raw identifier disclosure to result cards. Search links independently check their destination scopes. The job overview separately requires device visibility, commercial view scope and frozen inspector scope for their respective evidence. Verification for this review: - 54 focused tests passed in 81.484 seconds: all 23 UI tests, all 30 existing workspace tests and the existing representative reporting-budget test. - The existing operational-form responsive contract passed separately in 11.794 seconds: 55 focused tests passed in total for Phase 6A.1. - Query counts: scoped dashboard 9; all-capabilities dashboard 22; navigation 4; scoped search 8; job overview 32. Search results and assignment-history growth do not increase their query counts. Dashboard growth invariance also passed. - Reporting counts remain cases/engineer queue 20 (budget 24), complaint/diagnosis 9 (budget 10), positions 8 (budget 8), invoices/outstanding 9 (budget 10). - Fresh synthetic core/form pages were checked in headless Edge at 390px, 768px and 1366px: 21 pages, 63 layout checks, no page overflow or off-screen main action buttons. Drawer opening, visible focus, Escape dismissal and focus return passed. Current dashboard and job screenshots were visually reviewed. - Django system check, migration drift check, JavaScript syntax and Git whitespace checks passed. There are no migrations. No full audit or Git staging/commit/ push/tag/reset/stash/checkout/clean operations were performed. The known limitations above remain: previews are bounded near-current reads; Waiting for Parts has no authoritative frozen metric definition and is omitted; legacy transfer workflows are not duplicated; browser checks use synthetic rendered pages rather than a production deployment or a full accessibility audit. ## Phase 6B Front Desk and Service Job Workspace This phase adds read-only workspace composition around frozen services. There are no domain-model, migration, lifecycle, inventory, commercial, SLA or RBAC changes. Existing action endpoints still own validation, locking, signed revisions, command IDs, CSRF, replay handling and POST/redirect/GET behavior. ### Front Desk The selected date defaults to today. Scheduled and checked-in appointment counts, waiting/called/serving visit counts and intake-created counts come directly from appointments and queue records for the authorized center and date. Intake created means a queue entry has a ServiceCase reference; it does not mean the visit or repair is complete. Queue status filters preserve those date-wide counts. Appointments and visits have independent 25-row pagination; the workspace shows five recent authorized jobs for the selected date and 25 upcoming configured slots. Appointment and queue view permissions are independent. Action links reuse the existing permissions and endpoints; permissions are memoized per request, exact target and capability rather than queried for each displayed row. Check-in links are limited to today. A visit with intake offers its existing job instead of suggesting another intake. Confirmation screens show the selected visit/customer and state, with clear confirm/cancel controls. Opening a screen does not promise that capacity or other service preconditions will still hold on submission. ### Job sections and disclosure The compact Phase 6A overview/journey is retained. Section navigation loads one read-only source group at a time through `operations:job_section`; History is an explicit on-demand aggregation. Every URL first resolves an authorized ServiceCase. A single SQL query resolves each additional capability against that exact center; capabilities from another center or company cannot be combined to unlock data. | Section | Evidence and additional disclosure requirements | | --- | --- | | Overview | Existing scoped header, identifiers, assignment, SLA and journey rules | | Complaint & diagnosis | Recorded complaints for case viewers; technical notes/findings additionally require handle-servicecase or change-servicecase scope | | Repair | Execution/action history and notes with the same technical scope | | Parts | Inventory view scope, plus existing request/location/custody query scoping | | Commercial | Quotation, invoice and payment evidence each require their own view scope | | Quality control | Frozen `quality_control_visible_cases` inspector-posting scope | | Delivery | Recorded readiness/handover/closure timestamps; financial evidence additionally requires payment view scope | | History | Only the above independently authorized sources, plus intake and assignment history | New section payloads use explicit field allowlists. They do not expose raw device identifiers, recovery identifiers or recipient identity documents. Existing device visibility remains authoritative on the overview. Technical notes are escaped by Django templates. Role names, staff status and navigation visibility never grant business scope; endpoints authorize independently, and new evidence URLs reject POST. ### Actions, engineer and QC queues Next actions calls existing technical/commercial/inventory availability helpers. Links say Review and open the existing confirmation/form workflow. They do not assert that a mutation is guaranteed legal, duplicate service validation, or add a new transition matrix. Forms retain their fields, error handling, hidden signed revisions and command IDs. Instructions and cancel controls are presentation only. Engineer work intersects case visibility with the frozen active assignment query. Assigned, diagnosis and repair filters use persisted case states. Each row shows a recorded complaint, assignment time, latest diagnosis/repair evidence and scoped SLA evidence using correlated SQL, without per-row capability queries. Search keeps the selected queue and phase. Opening the job provides its authorized next actions. The QC queue uses the existing inspector eligibility query, including independent QC restrictions. Awaiting, in-progress and passed filters use recorded case states. The separately labelled recorded-failures filter uses the latest QC attempt and current inspector history scope; in the QC queue it shows only that inspector's failures. Engineers need QC history scope to see this filter's records. It is a history view, not a newly persisted rework state or authorization to inspect again. Detailed QC screens show recorded attempts, technical checks and complaint checks. ### Parts, commercial and history meaning Parts presents request status/quantities, reservation status, issues/custody, consumption, unused returns and defective recoveries through existing scoped queries. It does not calculate available stock or infer Waiting for Parts. Removed components remain separate from replacement inventory. Commercial shows actual quotation revisions and customer decisions, invoice value (not revenue), payments and the existing settlement query's liability/paid/balance/release evidence. Due-release leaves the balance outstanding. Absence of commercial evidence proves neither free/covered work nor financial clearance. History groups retain source-specific timestamps (received, started, completed, recorded, submitted, issued, etc.). Group order does not establish a universal event chronology. Sources show up to ten records; child findings/actions/checks or request lines show up to fifty rows for the selected parent records. The limits are stated on screen. This is a bounded operational preview, not a full audit-log export or a new event store; older detailed history remains in existing authorized domain interfaces. No synthesized events, balances or business statuses are stored. ### Responsive behavior and limits The existing shell, drawer, cards, form validation and responsive table enhancement are reused. Parts/commercial/QC sections use stacking record cards without tables. Front Desk tables use the existing small-screen labels and stacked layout. Section navigation wraps into touch-sized links, selected sections have a visible marker, and long evidence values wrap. No additional JavaScript or frontend framework is introduced. Browser verification uses synthetic Django-rendered fixtures, not production data; it is not a production deployment or exhaustive accessibility audit. Known gaps deliberately remain outside this phase: no new Waiting for Parts metric, no broader engineer access to QC history, no new appointment/queue or lifecycle state, no unified audit stream, no new correction workflow and no inventory or financial automation. Sources are read near-current state and are not a transactionally consistent cross-domain snapshot; mutation services always revalidate fresh state. ### Phase 6B query profile These are whole-response counts for synthetic scoped test personas, including session and shared navigation reads. On-demand sections have separate budgets; they do not increase the overview's budget. Permission bundles and empty child sources can change counts, so these are measured fixtures, not universal counts. | View | Queries | | --- | ---: | | Existing dashboard, scoped / all capabilities | 9 / 22 | | Existing navigation / scoped search | 4 / 8 | | Job overview with assignment history growth | 31 (frozen ceiling 32) | | Front Desk, appointments and queue populated | 24 | | Engineer work queue | 8 | | Complaint and diagnosis section | 12 | | Repair section | 11 | | QC section with checks | 12 | | Parts section with consumption, return and recovery | 15 | | Commercial section | 13 | | Scoped technical/assignment history | 16 | | Populated multi-domain history | 31 (new ceiling 32) | Queries stay constant under tested appointment/visit, engineer-job, assignment history and payment-history growth. Parent rows are bounded before child evidence is fetched; related names use joins, and work-queue evidence uses correlated SQL. No frozen query assertion was loosened. Frozen reporting budgets remain cases and engineer queue 20/24, complaints/diagnoses 9/10, positions 8/8 and invoices/outstanding 9/10. ### Phase 6B verification 2026-10-03 - Final complete existing UI/Front Desk run: 92 tests passed in 83.065 seconds (`apps.operations.test_ui`, `apps.operations.tests`, and `apps.frontdesk.tests.FrontdeskTests`). All frozen assertions are unchanged. - Final complete new workspace run: 21 tests passed in 50.182 seconds in `apps.operations.test_workspaces`. Coverage includes section disclosure, direct URLs, company/center/department isolation, split permission paths, fresh role revocation, assignment restrictions, independent QC, NULL root-cause evidence, intake counts, pagination/date filters, confirmation/CSRF/PRG/check-in replay, parts consumption/return/recovery, financial clearance and query growth. - The existing 22 end-to-end journey tests and representative reporting-budget check passed during the 82-test integration run. That run's sole failure was a new diagnosis-section assertion expecting 11 queries; profiling established 12 (case/navigation/scope plus complaint, assessment and findings sources). The new assertion was corrected and the complete new suite passed afterward. Initial new fixture duplicate-assignment errors were also corrected without changing domain constraints or baseline tests. Overall, 136 distinct focused tests passed across these runs; no full-project regression/audit was run. - Journey coverage preserves POST persona/scope checks, independent QC, stale revisions, signed command replay, payment/clearance, repair and parts workflows. - Headless Edge checked 57 synthetic Django-rendered pages at each of 390px, 768px and 1366px: 171 checks with no page overflow or off-screen main buttons. Drawer opening, visible link focus, Escape dismissal and focus return passed. Front Desk/mobile commercial and desktop QC screenshots were visually reviewed. These are browser layout/interaction checks; mutation workflows are exercised through Django test clients against isolated PostgreSQL test databases. - Django system check, migration drift check, Git whitespace checks and unchanged JavaScript syntax verification passed. New-file EOF/trailing whitespace was checked independently because unstaged untracked files are outside Git diff. - Changes are limited to 13 modified and four new operations/front-desk/UI-doc files. No business model/service, historical migration or frozen test changed. Nothing was staged, committed, pushed or tagged; HEAD remains `a5e25da`. ### Phase 6B.1 final review 2026-10-03 All 17 files (13 modified, four new) were reviewed against `a5e25da` on master. The adapters perform scoped reads and presentation only. They introduce no transitions, stock accounting, capacity/token allocation, commercial authorization, QC eligibility or SLA calculations. No domain service, model, historical migration or frozen test has changed. No debug or temporary artifacts are in the repository. Review corrections are limited to presentation and regression coverage: - Queue complaint selection uses UUID ordering, not chronology. Its label is now Recorded complaint, avoiding the unsupported implication of First recorded. - Front Desk appointment/visit row action links use the existing button style and its 44px minimum height for touch operation. - Three new tests cover Parts, Commercial and QC queue query growth. The original 21 workspace tests remain intact, bringing this phase's workspace suite to 24. Existing limits and frozen assertions were not raised or weakened. The complete next-action inventory was checked against technical `STAGES` and `permitted`, commercial `OPERATIONS`/`available`, and inventory `OPERATIONS`/ `available`. These same existing helpers are checked again at destination endpoints. Assignment, diagnosis, repair, QC, delivery/closure, quotation creation/editing/ submission/decision/revision, invoice preparation/reconciliation/finalization, payment receipt/due-release/reversal and stock request/approval/reservation/ release/issue/consumption/return/receipt remain review links. Their existing services make the final mutation decision with fresh evidence and authorization. No extra eligibility matrix or guarantee of successful submission was added. Front Desk uses the project-local date and recorded business dates; appointment capacity and queue tokens remain service-owned. Authorization precedes pagination and recent-job slicing. Company, center and department scope remain governed by the existing authorization querysets. Engineer active assignments and independent QC eligibility are unchanged; recorded failure history is explicitly separate from eligibility to perform QC. Parts source/disposition labels preserve issue, consumption and return distinctions. Financial labels use existing settlement values; no debt reduction is inferred from due-release and invoice value is not called revenue. No Waiting for Parts state exists. History bounds are SQL slices before source materialization: ten parent/source records and fifty child rows for those selected parents. Sparse and populated histories are covered. Sources retain their distinct timestamp semantics, with no fabricated global chronology or action count. Disclosure gates also apply inside History; revocation is evaluated afresh on subsequent requests. Verification for this review: - One complete 51-test focused run passed in 153.033 seconds: all 24 workspace tests, all 23 frozen UI tests, the representative frozen reporting-budget test, and three existing journey contracts (responsive screens, POST/CSRF/stale/scope protection, and signed parts-command replay). - Query growth: Front Desk 24?24; overview 31?31; engineer queue 8?8; QC queue 8?8 (one to six eligible jobs); Parts 15?15 (one to eleven issues); Commercial 13?13 (one to eleven payments); populated history 31?31; sparse technical/ assignment history 16?16. Ten-record preview caps remain effective, while commercial balances still include all eleven payments rather than the preview. - Diagnosis 12, repair 11, QC section 12, dashboard 9/22, navigation 4 and search 8 remain unchanged. Frozen reporting counts remain 20/24 for cases and engineer queue, 9/10 for complaints and diagnoses, 8/8 for positions, and 9/10 for invoices and outstanding balances. - Direct URLs and POST requests retain independent authorization. Scope, raw identifier/commercial/QC disclosure, CSRF, stale revision and signed replay checks passed. Template visibility remains presentation only. - Fresh headless Edge verification: 41 synthetic rendered pages at 390px, 768px and 1366px (123 checks) passed without horizontal page overflow, off-screen main buttons or undersized button controls. Native Tab focus, mobile drawer opening, visible link focus, Escape dismissal and focus return passed. Representative Front Desk, Parts and QC screenshots were visually inspected at all three viewport sizes. This remains a focused accessibility/layout review, not a full screen-reader audit or production-browser deployment test. - Django check, migration drift check, unchanged JavaScript syntax verification, Git diff whitespace and independent untracked-file whitespace checks passed. Documentation was checked against the actual predicates, sources and limits. No migrations, staging, commit, push, tag or full audit was performed. Remaining limitations are unchanged: history is a bounded preview rather than a complete audit export; reads across domains are near-current rather than one locked snapshot; QC history needs its existing inspector scope; no synthetic Waiting for Parts state or new workflow/financial interpretation is supplied. Proposed commit: `feat: add operational service job workspaces`. ## Phase 6C: Parts and inventory operational workspace Navigation now provides overview, requests, receiving, positions, transfers, counts/adjustments and immutable history. Custody, consumption/unused returns and recoveries are separate workspaces. The existing bulk capability resolver controls navigation. The old `/workspace/parts-requests/` URL preserves its frozen read-only response contract; navigation uses the new `/inventory/requests/` workspace. Architecture: `inventory_workspace.py` adapts existing document, request, usage and control querysets. Positions use `control_positions` on-hand and active-reserved annotations, never sums of rendered records. History uses authorized location-side `StockLedgerEntry` evidence, as frozen inventory reporting does. It does not reveal a hidden counterpart location. A two-sided movement may have two visible entries; entry counts are not distinct movement counts. No low-stock, reorder, shortage, valuation, synthetic supplier or procurement meaning is introduced. Overview metrics count authorized REQUESTED requests, APPROVED requests, ACTIVE reservations (labelled Active reservations, not a promise of issue eligibility), POSTED receipts received today in local time, DRAFT/DISPATCHED transfers, and DRAFT/COUNTING counts. Five recent authorized ledger entries appear below. These are separate near-current queries, not a locked inventory snapshot. Collections paginate at 25 parents. Filters cover part code/name, exact part ID, authorized location, recorded status/type where supported, reference and local date range. Positions also offer company, service-center and location-type filters. Service-job filtering independently requires case-view scope and follows existing request/issue/disposition evidence. Receipts and transfers receive no fabricated job ownership. Reference searches use document numbers or movement references. Every implemented filter operates within the authoritative authorized queryset. Requests show demand quantities, requester, timestamps and recorded state. Review adds reservations and bounded issue/disposition previews. Approve/reject delegate to request services. Reserve, release, issue, consume and unused-return links reuse the existing case-bound forms. Job links require separate case-view scope. No customer, device identifier, financial or QC access follows from inventory access. Issue is not consumption; unused return does not reverse consumption; defective recovery is separate evidence, not usable stock. Raw recovery identifiers are not shown. Job Parts sections link back to filtered inventory queues without replacing the frozen job evidence adapter. Receiving supports draft creation, explicit full active-line replacement, serial identifiers, cancellation and posting. Transfer creation/line replacement, dispatch, receipt and cancellation use the existing service APIs. Only DRAFT, DISPATCHED, RECEIVED and CANCELLED are presented; there is no new approval state. Both transfer endpoints must be visible and authorized. Document review displays recorded lines, identities and movement references. Dispatch into managed transit and destination receipt remain separate operations. Counts support create/start/record/cancel/reconcile. Recording observations alone never posts stock. Reconciliation retains count AND adjustment authorization, position freeze, variance validation and posting rules. Expected, counted, variance, identity observations and resulting posted adjustments remain separate evidence. Direct adjustment review is available from eligible position cards, using the existing position revision, command UUID, reason, reference and note. Adjustments are posted records; no new draft/approval lifecycle is invented. `inventory_actions.py` owns forms and confirmations only. All writes call frozen services inside their existing locking/revision/idempotency discipline. Signed review tokens bind actor, operation, document and revision and expire after one hour; adjustment tokens bind actor, position, revision and command UUID. POSTs require CSRF and recheck permissions and current state. Stale/tampered/borrowed confirmations are rejected. Successful submissions redirect to evidence. Receipt, transfer and adjustment replay cannot create extra stock. Draft-creation APIs have no command key: repeated creation may create separate unposted drafts, never stock. No new locking strategy, schema or business semantics are added. Cards/forms reuse the responsive shell, fieldsets, error summaries and touch-size buttons. Action links say Review: service checks remain final authority if stock, permissions or lifecycle evidence change after the screen was rendered. Limits: edits replace up to 100 document lines, offering one additional blank row per review; larger edits remain in guarded Admin. Document review shows all line evidence without a separate child paginator. Request issue/disposition previews show up to 25 each; count identity previews show up to 100. Dedicated queues provide paginated history. Transfer identity selection is source-stock only. Count and negative-adjustment selectors cover identities at the selected location; registered/removed identity reintroduction remains in the existing guarded Admin with its original origin/company authorization. Inventory readers without case-view scope cannot use case-bound action links. The UI adds no staff bypass or authority from permissions on another organizational path. Verification evidence is recorded below. Phase 6C query contracts (complete rendered responses, including the shell): | Workspace | Queries / enforced ceiling | Growth fixture | | --- | ---: | --- | | Parts requests | 13 | 1 to 9 requests | | Positions | 15 | 1 to 9 stocked parts/positions | | History | 10 | 1 to 9 posted receipts/movements | | Receipts | 11 | 1 to 9 receipts | | Transfers | 11 | 1 to 9 transfers | Counts remain identical before and after growth. Position/document/history growth uses a scoped regular inventory reader; request growth includes visible job links. The new tests do not modify frozen budgets: dashboard 9/22, navigation 4, search 8, job overview 31 (ceiling 32), Front Desk 24, engineer/QC queues 8, diagnosis 12, repair 11, QC section 12, job Parts 15, Commercial 13 and populated history 31. Frozen reporting budgets remain unchanged. Phase 6C verification: - Added 26 workspace tests. The final complete UI/integration selection passed 76 tests in 190.087 seconds: the new suite, all 23 frozen UI tests, all 24 frozen workspace tests, the frozen reporting-budget test and two existing operational journey contracts (signed parts replay and POST/CSRF/stale/persona protection). - All 168 selected existing inventory tests passed, including 55 PostgreSQL concurrency tests across documents, requests, usage and control. Coverage includes duplicate receipt posting, transfer receipt, competing stock use, duplicate reservation/issue, consumption versus unused return, stale adjustment and count reconciliation. These ran in a combined 244-test selection whose sole error was a missing required center type in a new test fixture; that fixture was corrected and the full 76-test UI/integration selection then passed. No frozen test changed. - Independent company, sibling-center, location and department scope, separate permission paths, direct URL/POST authorization, CSRF, raw recovery identifier withholding, receipt serial disclosure, job links, signed actor binding, replay and stale confirmation checks passed. Staff status remains insufficient. - Fresh headless Edge: 40 synthetic rendered inventory pages at 390/768/1366px, 120 viewport checks, zero failures. Collapsed and expanded filter/workspace menus, page overflow, touch-size controls, native Tab focus, mobile drawer open/Escape/ focus return were checked. Mobile overview, tablet request queue and desktop receiving screenshots were visually reviewed. This is focused browser/layout coverage, not a screen-reader certification or production deployment test. - Django system check, migration drift check, tracked Git diff whitespace and new-file UTF-8/whitespace checks passed. JavaScript is unchanged. No migrations, baseline-test edits, frozen domain changes, staging, commit, push, tag or full audit were performed. Test databases and browser artifacts were isolated from production data and stored outside the working tree where applicable. ## Phase 6C.1 final review Reviewed the complete tracked diff and all five new files against baseline `391b039` on master. No inventory/domain service, model, historical migration, frozen test or JavaScript changed. The working set remains six modified and five new files; test captures and browser tooling remain outside the repository. The review corrected one presentation label: ACTIVE reservations are now labelled **Active reservations**. A cancelled case may retain an active reservation pending explicit release, so the former "awaiting issue" wording overstated eligibility. The query and domain rules are unchanged. A new test cancels a case with an active reservation, checks the metric, proves issue is rejected, then explicitly releases it and checks the metric again. Two further review tests verify the 100-line formset boundary without invoking a write and the serialized transfer form's preservation of identity through dispatch and receipt. No existing assertion was weakened and no query ceiling increased. The action layer delegates receiving and transfers to document services, counts and adjustments to control services, approval/rejection to request services, and case-bound reserve/issue/consumption/return work to the existing operational forms. It adds no stock arithmetic, serialization policy, ledger writes, custody transitions or locks. Signed UI confirmations preserve reviewed revisions and existing command keys; the service locks and preconditions remain authoritative. Both transfer endpoints require scope, cancellation remains draft-only, and count observation remains distinct from reconciliation/posting. Existing rules do not introduce a separate UI approval or separation-of-duty state for adjustments. Position values remain `control_positions` projections. Collection filtering is applied to scoped querysets before deterministic timestamp/PK ordering and 25-row pagination. History is read-only location-side ledger evidence; association with a job does not imply causality or grant job disclosure. Service Job links require inventory access on the job's center; reverse links require independent case-view scope via SQL Exists, with no per-row authorization query. Inventory history does not enumerate serialized identifiers or hidden counterpart locations. The earlier combined 244-test run DID fail: the new sibling-center fixture omitted required `ServiceCenter.center_type`, causing model validation during setup before the intended HTTP checks ran. Adding `center_type="OWN"` supplied valid fixture data; its scope/POST/selection assertions were unchanged. The subsequent 76-test run passed and exercised those assertions. This was not a production defect. That failure remains recorded above and is not represented as a passing run. The three reviewed limits remain unchanged: up to 100 operational edit lines; count/adjustment reintroduction of registered/removed serials in guarded Admin; repeated creation may create separate unposted drafts because draft creation has no domain command key. No new business behavior was introduced to conceal these limits. Proposed commit: `feat: add operational inventory workspace`. Fresh browser review: 41 synthetic inventory pages at 390px, 768px and 1366px passed 123 viewport checks. Collapsed/expanded filters and workspace menus, horizontal overflow, button sizes, native Tab focus, mobile drawer opening, Escape dismissal and focus return passed. Separate screenshots of the oversized line-validation error and dispatched-transfer evidence passed at all three widths. The mobile overview/error, tablet positions and desktop transfer were visually reviewed. No application JavaScript changed. This remains a focused accessibility review rather than screen-reader certification. Final Phase 6C.1 focused run: **247 tests passed in 473.925 seconds**, in one complete run after the review correction. It includes all 29 inventory workspace tests, 23 frozen UI tests, 24 frozen workspace tests, the frozen reporting-budget test, two operational journey contracts, and 168 existing inventory tests. The inventory selection includes all 55 document/request/usage/control PostgreSQL concurrency tests (15/12/12/16). No test failed or was skipped in this run. Query growth remained exactly constant from one to nine records: requests 13, positions 15, history 10, receipts 11, transfers 11. All frozen Phase 6A/6B and reporting ceilings passed unchanged. Django check and `makemigrations --check` passed, with no changes detected; tracked and untracked whitespace checks passed. No migrations, frozen-test modifications, staging, commit, push, tag, reset, stash, checkout, clean or full audit was performed. The review is ready for commit under the proposed subject above. ## Phase 6D - Commercial and cashier workspace The Commercial navigation opens Overview, Quotations, Invoices, Payments, Outstanding, Receipts and Due-release history. Each destination uses its existing Phase 3C read permission and authoritative scoped query. Collection pages use 25-row pagination ordered by descending source timestamp and ID. Reference, Service Job ID and inclusive local-date filters are validated before querying. A Service Job filter independently requires visibility of that job. Overview metrics are record counts, never financial KPIs: - Current quotations awaiting customer decision: current SUBMITTED revisions. - Current rejected quotations: current REJECTED revisions, not an inferred need or eligibility to revise. - Draft invoices awaiting finalization: invoices whose recorded state is DRAFT; finalization may still require reconciliation and other service preconditions. - Finalized invoices with outstanding customer balance: the authoritative unsettled-invoices query, including balances subject to due release. - Posted payments received today: POSTED payments whose received_at local date equals today's local date. This is a count, not an amount or revenue measure. - Ready-for-delivery invoices lacking financial clearance: FINALIZED invoices for READY_FOR_DELIVERY jobs excluded by the authoritative cleared-delivery query. Invoice-free jobs are not counted as commercially blocked. Quotation records show recorded state, current-revision flag, stored value, creation/submission actors and timestamps, and the explicit customer decision. A replacement does not overwrite the earlier decision: a rejected non-current revision remains REJECTED according to the existing engine. Historical records never advertise mutation actions against a different, current revision. Decision recipient/reference/note are disclosed only with independent customer master permission. Revision previews retain at most 25 revisions; the queue provides paginated access to older records. Quotation and invoice line previews are bounded at 100, without truncating or replacing the authoritative action formsets used to edit/reconcile. Invoice pages show stored invoice totals and payer totals, current lines and technical consumption allocations. These quantity allocations are explicitly separate from monetary payment allocations. Existing preparation, reconciliation and finalization forms/services remain authoritative. Payment records show the original full allocation, method, receipt identity, receiving actor and reversal evidence. Cashiers use the existing receive-payment form; its signed revision, service validation, locking and replay protection are unchanged. Receipt pages reuse ServicePaymentReceipt and its issued customer/center/invoice snapshots. Printing creates no record and invents no legal or tax information. Current settlement/status is labelled separately from issued receipt evidence. Print CSS removes navigation, actions and shell chrome; the existing receipt can be printed using the browser's Print command. Reversed payments retain their original receipt and are visibly marked. Printed customer and job evidence use the same independent disclosure checks as the screen. The UI uses payment_queries settlement annotations and its existing summary serializer, including batch summaries for queues. It contains no balance, allocation or clearance engine. In particular: - invoice value != revenue - due release != debt reduction - payment reversal != deletion An authorized due release can permit delivery while the recorded balance remains outstanding. Release history shows amount, actor, timestamp, reference and reason. Reversal history preserves the original payment/allocation/receipt and shows the recorded reversal, while settlement reflects only authoritative posted payments. The Financial Manager's dedicated reversal and due-release permissions are not implied by receive-payment permission, nor do they imply collection authority. Service Job commercial/delivery sections link to independently authorized queues. Commercial details link back to the job only if service.view_servicecase applies. Existing availability helpers select review actions; fresh service checks decide whether submission succeeds. The existing job/delivery clearance presentation and locked financial handover gate are preserved. Quotation-free/invoice-free frozen workflows are unchanged and do not imply free or covered work. On the new commercial read pages, customer master links/names require company-level customers.view_customer. Commercial scope alone does not disclose the customer or Service Job. Existing mutation forms and Service Job pages retain their frozen authorized case-context presentation and prerequisites. Invoice links additionally require invoice visibility; a payment reader may still see an invoice reference already contained in their authorized receipt snapshot. No financial values or counts were added to global search or shell navigation. Department-only scope does not broaden to center financial access. An explicit center plus department assignment retains the frozen center grant; the UI does not reinterpret departments as a new commercial restriction. POSTs still use existing scoped endpoints, CSRF, permissions and stale-revision protection. Commercial history is presented by source: quotation revisions/decisions, invoices/technical allocations, payments/monetary allocations/receipts/reversals, and due-release authorizations. These independently timestamped sources do not establish a fabricated causal timeline. Collection history is paginated; detail previews are bounded and labelled. Known limits: this is an operational UI over the frozen engine, not accounting, revenue recognition, refunds or online payment. Mutation forms retain their existing Service Job and commercial read-permission prerequisites. A read-only payment viewer does not gain those extra permissions. Filters do not add new commercial states or policies. Large detail previews use the stated bounds. Verification measurements and final test results are recorded below. No full audit is required or run for this phase. ### Phase 6D measured UI verification - Populated quotation queue: 8 queries. - Populated invoice, payment, outstanding, receipt and due-release history queues: 9 queries each. - Each of those six collections stayed constant from 1 to 9 distinct cases and records. Separate payment-history growth from 1 to 9 payments was also constant. Empty due-release history costs 7 queries; populated history costs 9. - Existing query-budget assertions were retained unchanged. Dashboard 9 scoped / 22 all-capabilities; navigation 4; search 8; job overview 31; commercial section 13; populated job history 31; inventory requests 13, positions 15, ledger 10, receipts/transfers 11. - Fresh Edge checks: 48 rendered synthetic pages at 390, 768 and 1366 pixels, 144 checks total, zero failures. Checks cover horizontal overflow, expanded filters, touch-target heights, focus and mobile drawer/Escape behavior. - Print emulation confirms visible receipt evidence and hidden shell/actions. The receipt PDF exports as one page. A print-only min-height reset removes the blank extra page introduced by the shared full-height shell. - Browser inputs are Django-rendered synthetic test fixtures with the actual CSS/JavaScript inlined, not production data or a live-production UAT session. HTML captures, screenshots and the receipt PDF remain outside the repository. - No JavaScript changes; no JavaScript syntax rerun is required. ### Phase 6D final focused/regression result One complete final run passed **402 tests, zero failures**, in 2277.327 seconds: ``` python manage.py test apps.operations apps.commercial \ apps.reporting.tests.test_reports.ReportingTests.test_representative_pages_have_bounded_queries \ apps.reporting.tests.test_reports.ReportingTests.test_diagnosis_engineer_invoice_outstanding_query_counts_do_not_grow \ --noinput ``` The same labels were executed with call_command inside the existing isolated_test_database helper, using a disposable PostgreSQL database. This includes 28 new Phase 6D tests, all existing operations/commercial tests, 22 end-to-end operational journeys, and 74 commercial PostgreSQL concurrency tests (28 quotation, 27 invoice, 19 payment). No existing tests were modified. Development runs caught mistakes in new test fixtures/expectations: duplicate assignment creation, repeating delivery release, expecting a rejected historical revision to acquire another state, and treating an explicit center-plus-department assignment as department-only. The new tests were corrected to the frozen rules; separate department-only and explicit center-plus-department tests now pass. The earlier 400-test development run had only the already-corrected new department fixture failure; the complete final 402-test run above is the readiness result. The initial new UI query limit also exposed duplicate capability resolution; reusing the shell result reduced queries rather than loosening the frozen budgets. Final receipt-only CSS verification followed the blank-page correction: all 144 browser checks passed, with one-page PDF output and hidden shell/actions in print. The final code introduces no domain, schema or historical migration changes. Django check and makemigrations --check pass; git diff --check is clean. No full audit, staging, commit, push, tag or deployment was performed. ## Phase 6D.1 - Commercial workspace final review Reviewed all 14 Phase 6D files against baseline 4457f0f on master. The expected scope remains eight tracked modifications and six new files. No production correction or feature addition was needed in this review. Only two focused review tests and this review record were added; existing/frozen tests remain unchanged. The workspace test module now contains 30 tests. The read adapter delegates settlement and financial clearance to payment_queries, including its existing summary serializer. Existing commercial_workflows and handover services retain all mutation validation, revision checks, locks and transaction boundaries. The new adapter, templates and CSS perform no financial writes. No UI-specific locking or transition engine was introduced. Metric implementation was checked against the definitions above. The extra local-date test covers the Asia/Dhaka midnight boundary, adjacent UTC dates, future/past dates, VOIDED exclusion from the POSTED-today metric and inclusive local-date history filters. The synthetic future-clock test creates its login session under that same clock to avoid testing an expired authentication session. The extra clearance review scenario exercises unpaid, partially paid, fully paid, reversed-to-outstanding and authorized-due-release states through existing services. Unpaid, partial and reversed debt block handover. A qualifying due release permits handover without reducing debt or creating payment/allocation/receipt records. The existing full-payment delivery test remains unchanged and confirms settlement permits handover. Due release is neither payment nor settlement nor debt reduction. Explicit customer decisions remain attached to their original revisions. Invoice values/totals, technical consumption allocations, payment allocations, original receipts, reversals and due releases keep their existing meanings. No unsupported revenue, sales or earned-income metric was found. Reversal is not deletion. Authorization was traced from the shell through scoped source queries, independent customer/Service Job/invoice link checks, action availability and direct POSTs. Dedicated reversal/due-release rights remain separate from cashier collection. Department-only and explicit center-plus-department behavior follows the frozen scope adapters. Existing Service Job case-context disclosure remains unchanged. History ordering uses each source's recorded timestamp, with UUID only as a stable tie-breaker. Quotation previews use their authoritative revision sequence. No cross-source causal timeline is inferred. The existing 25-record pagination and bounded previews, independent read permissions and action-form prerequisites remain the known presentation limitations. Browser checks use freshly rendered synthetic fixtures and actual static assets, not a live production session. Proposed commit subject: `feat: add operational commercial workspace`. Final review verification results follow below. Final verification (2026-10-04): - Broad focused run: 313 tests in 1265.669s; 312 passed and one new timezone-test fixture errored because its login predated the synthetic future clock. The process had already loaded that earlier fixture version. All 283 existing checks passed, including 74 commercial PostgreSQL concurrency tests, two selected payment/handover journeys, operational UI/workspace/inventory regressions and frozen reporting budget/growth checks. - Corrected fixture rerun: all 30 commercial workspace tests passed in 193.571s. Only the new test's session setup changed; production and frozen tests did not. Thus all 313 distinct selected checks have passing results across these runs; the broad run itself is not represented as an entirely passing run. - Fresh browser run: 156 checks across 52 captured pages at 390px, 768px and 1366px; no failures. Overflow, touch targets, filters, keyboard focus and mobile drawer behavior passed. Receipt printing hid shell/actions; the representative PDF has one page with unclipped values. - Populated collection query counts stayed constant from 1 to 9 records: quotations 8 -> 8; invoices, payments, outstanding, receipts and due-release history each 9 -> 9. Existing Phase 6A-6C limits were not changed. - Frozen reporting measurements: cases 20/24; engineer queue 20/24; complaints 9/10; diagnoses 9/10; positions 8/8; invoices 9/10; outstanding 9/10 (observed queries / unchanged budget). Growth checks also passed. - Django system check passed; makemigrations --check reported no changes; git diff --check passed. JavaScript remains unchanged. No migrations, business-service edits or baseline-test edits were introduced. No full audit, staging, commit, push or tag was performed. ## Phase 6E - Administration / Settings The existing `/settings/` Configuration Center is the Administration workspace. It reuses the operational shell and its bulk capability resolver; no new CRUD, permission editor, lifecycle engine, provider client or configuration model is introduced. The shell retains the Configuration Center wording for discovery. Information architecture: - People & Access: existing User Admin, organization assignments, Roles and permission membership, and role assignments. Native permissions do not grant business scope; multi-scope/primary assignment semantics are unchanged. - Organization: Company > Region > Service Center, plus company-level Departments. Existing Admin displays parent/state context and invokes lifecycle services. Parent constraints, fixed ownership, business codes and protected references remain authoritative. Reactivation does not restore children automatically. - Service Master Data: brands, Product Categories, models, variants, device identification policies, actual service taxonomy and parts/compatibility. ComplaintSymptom is the complaint dimension. Product Category applicability does not create Complaint-to-ServiceCategory classification. NULL RootCause remains unknown/unconfirmed. No taxonomy master or mapping was invented. - Operations: existing dated appointment slots, company SLA policies and company notification templates. Inventory location Admin retains its existing scoped business/native permission combination. - System: the existing installation-readiness view calls `inspect_installation`, also used by `check_installation_readiness`, without duplicating its rules. REQUIRED/RECOMMENDED/OPTIONAL and PASS/MISSING are textual status categories. Configuration readiness is not production certification or a deployment audit. Global people, organization and master-data links and global counts are available only to active staff superusers, matching the existing Configuration Center boundary. This does not change native Django Admin permissions or claim that its older global querysets are company-scoped. Scoped managers see only their existing management destinations. Each destination independently enforces its permissions; non-staff users receive no Admin links. Reversal/payment/delivery rights are not added by administration access. Overview metrics have deliberately narrow definitions: | Metric | Definition / access | | --- | --- | | Active users | Global User rows with is_active=True; staff superuser only | | Active service centers | Global ServiceCenter rows with is_active=True; staff superuser only | | Active departments | Global Department rows with is_active=True; staff superuser only | | Active product models | Global ProductModel rows with is_active=True; staff superuser only | | Active dated appointment slots | Active slot rows in centers authorized for manage_slots; includes past dates, not free capacity | | Active SLA policies | Active policy rows in companies authorized for manage_slapolicy; not effective coverage | | Active notification templates | Active template rows in companies authorized for manage_templates; not delivery readiness | Global active-state metrics are not usability/readiness checks. The actual readiness inspector remains authoritative for its stronger setup predicates. Counts apply scope before aggregation and expose neither unauthorized record labels nor raw configuration values. No per-record authorization is performed. The navigation search filters authorized group/link labels only (100-character input bound), never users, template bodies, credentials or database values. Summary counts do not change when filtering area labels. Existing mutation destinations remain authoritative. Slot capacity and concurrency rules are unchanged. SLA precedence, receipt-based start, ready-for-delivery stop, exact-due completion, cancellation and immutable snapshots remain unchanged. Template edits do not rewrite rendered notifications; attempts are retained. ACCEPTED/REJECTED/UNKNOWN meanings remain unchanged, provider acceptance is not delivery, uncertain sends are not automatically retried, and external SMS needs explicit supported deployment configuration. The workspace never displays SMTP passwords, tokens, secret keys or provider mapping values and never contacts a provider. No secret-management UI was introduced. Dependency notes direct administrators to existing parent/state/reference context before edits. Existing lifecycle actions, confirmations, validation, protected foreign keys and Admin/domain history remain at their established destinations. No delete action, audit system or timestamp-derived audit timeline was added. Responsive behavior uses the existing shared card/form design and mobile drawer. Configuration links, appointment actions and existing SLA/template edit links use shared touch-friendly button styles. Appointment and readiness screens have a return path to Administration. No JavaScript changed. Measured query growth from small to populated fixtures: | Page | Small | Populated | | --- | ---: | ---: | | Global Administration overview | 13 | 13 | | Company Administration overview | 8 | 8 | | Center Administration overview | 7 | 7 | | Center appointment-slot list | 9 | 9 | Growth fixtures increase templates/policies or slots from 1 to 9 and also add users. Existing Phase 3D and Phase 6A-6D budgets are not changed. Readiness remains an explicit on-demand inspection, not a query on every navigation render. Known limits: no delegated company-scoped organization/RBAC editor, no settings value editor, no provider connection test, no redesigned Django Admin. Global master administration intentionally remains advanced Admin work. Existing slot lists keep 25-record pagination; existing SLA/template destination behavior and history retention are unchanged. Browser captures use synthetic test fixtures, not a live production session. Test databases are isolated; business data is not seeded or changed in the application database. Phase 6E verification (2026-10-04): - Added 19 focused administration tests covering navigation, all area groups, precise counts, company/center/department isolation, staff/native permission boundaries, direct URLs and POSTs, CSRF, no-write overview, privilege escalation, label-only search, escaped input, readiness reuse and secret non-disclosure. - Final selected regression run: 113 tests passed in 331.556s. Includes existing configuration/readiness/bootstrap tests, Phase 6A/6B workspace suites, Phase 6C/6D query-growth checks, frozen reporting budgets, and relevant existing SLA/template authorization, snapshot and form regression tests. - After the final compact-card/search-order presentation adjustment, all 19 administration tests passed again in 9.326s; query measurements stayed unchanged. Earlier development failures were confined to new tests: historical slots need creation under a historical clock, and the new global-page budget was calibrated to its measured 13 queries (six shell/authentication plus seven metrics). No frozen test or frozen budget was modified. - Final browser verification: 48 passing checks over 16 freshly rendered pages at 390px, 768px and 1366px. Includes global/scoped/company/inventory management, filtered/empty discovery, readiness, slot forms/errors and existing SLA/template forms/lists. No horizontal page overflow; controls/cards are touch-friendly, keyboard focus and mobile drawer/Escape behavior work, and statuses are textual. - Frozen measurements passed unchanged: dashboard 9/22, navigation 4, search 8, job overview 31, Front Desk 24, engineer/QC queues 8, diagnosis/QC section 12, repair 11, parts 15, commercial 13 and populated history 31. Inventory collections remain positions 15, history 10, receipts/transfers 11 and requests 13. Commercial populated collections remain quotations 8 and other collections 9. Reporting observed/budget counts: cases and engineer queue 20/24, complaints and diagnoses 9/10, stock positions 8/8, invoices and outstanding 9/10. Growth stayed constant. - Django system check passed; makemigrations --check reported no changes; git diff --check passed. JavaScript was unchanged, so no syntax rerun was needed. - No schema/history migration, business service, frozen test, production data, provider configuration or deployment changes. No full audit or unrelated large concurrency suites ran. Nothing was staged, committed, pushed or tagged. ## Phase 6E.1 - Administration final review Reviewed all 14 Phase 6E files against master/e6d4d8a, including all 19 original workspace tests and the existing management destinations. No production-code correction was required. Three review tests were added to the new workspace test module (22 total): all configured secret sources stay out of overview/readiness responses, ordinary-user configuration POSTs are denied without changes, and inactive policies/templates do not inflate active metrics. Existing tests and query limits remain unchanged. The workspace remains a read/navigation adapter. User and role permission editing, assignment primary/lifecycle actions, organization ownership and hierarchy rules, master-data validation, slot capacity, SLA policy changes and template changes continue through existing Admin or operational management surfaces/services. Counts do not prove dependency safety. Global Admin discovery remains restricted to active staff superusers; the scoped inventory-location link retains both native and business capability prerequisites. Direct Django Admin permissions are not rewritten or proxied by this workspace. Non-staff actors receive no Admin links. All metric definitions were checked against active filters and scoped subqueries. Active slot counts include past slots and are not remaining capacity. Active SLA policy counts are not effective coverage. Active template counts are neither provider nor delivery readiness. ComplaintSymptom remains the complaint dimension; Product Category remains a device/product dimension, with no inferred taxonomy relationship. No timestamp is presented as fabricated administrative audit proof. Readiness still calls the same inspector as check_installation_readiness, keeps REQUIRED/RECOMMENDED/OPTIONAL categories, and does not certify production readiness. The expanded secret test substitutes synthetic SMTP, token/provider, APP_SECRET, SECRET_KEY, encryption-key and test-connection password values. Neither overview nor readiness renders them, writes business records or invokes a provider. The test never reads real secrets or reconnects with its synthetic password. SLA receipt/readied timestamps, inclusive due-time completion, cancellation and immutable snapshots remain unchanged. Notification snapshots, retained attempts and ACCEPTED/REJECTED/UNKNOWN meanings remain unchanged; acceptance is not delivery. Existing lifecycle confirmations, protective references and audit mechanisms are preserved. No new locks, workflow engine, audit store or configuration editor exists. Known limits remain those above. In particular, existing SLA/template management lists retain their existing pagination behavior; this review does not redesign those destinations. Global native Admin remains a trusted advanced management surface, not a delegated company-scoped organization/RBAC editor. Proposed commit subject: `feat: consolidate administration workspace`. Final Phase 6E.1 verification (2026-10-04): - One complete focused/regression run: 116 tests passed in 419.258s, including all 22 administration tests and the unchanged configuration/readiness, selected SLA/communications, operational workspace and frozen budget/growth regressions. - Fresh overview query growth reconfirmed: global 13 -> 13, company 8 -> 8, center 7 -> 7; appointment-slot list 9 -> 9. Frozen Phase 3D and Phase 6A-6D measurements above passed unchanged; no limits were raised. - Fresh browser checks: 48 passed across 16 pages at 390px, 768px and 1366px. An initial template-list Tab-focus check failed under the fixed-delay browser harness. The temporary harness was updated to await full page load and reset keyboard focus before Tab; all 48 checks then passed. No application code or browser assertion was changed. Representative desktop, tablet, readiness and mobile error screenshots were also inspected. - Django system check passed; makemigrations --check reported no changes; git diff --check and new-file whitespace checks passed. JavaScript is unchanged. - Reviewed OPERATIONAL_UI.md, SYSTEM_CONFIGURATION.md and ADMINISTRATION.md against actual implementation. No production correction, schema/history migration, frozen-test modification, unrelated artifact, full audit or unrelated large concurrency suite. Nothing was staged, committed, pushed or tagged. ## Phase 6F operational UAT corrections Two documented handoff defects are corrected without changing domain services: - Customer-owned device registration includes a cancel link back to the scoped customer detail. It remains available after validation errors and does not submit the form or create registry evidence. - Complaint & diagnosis and History display the persisted ServiceCase intake remarks as "Reported at intake". They are not engineer diagnosis, a structured ComplaintSymptom, or financial classification. The existing authorized case read boundary applies, and template autoescaping remains enabled. Empty remarks display "Not recorded". No additional query is needed. See FINAL_OPERATIONAL_UAT.md for the gap register, verification evidence and release limitations. No workflow transition, permission, inventory/commercial semantics, historical migration or frozen test was changed.