All six systems

Service management & operations

ServiceOPS

A service company must turn a failure report into the right technician, the right part, and a kept SLA, without letting automation act unchecked. Skill, certification, parts, and contract terms collide on every job.

Product thesis: Human authority over automation. Every consequential action shows its exact change first and needs approval.

Cabberefwenf/ServiceOPS · main @ 1ba38d38 (2026-10-26)

Interactive demo in development
Conceptual interface illustration, not a screenshot of a live application.

Primary workflow

A professional service-operations console. Dark, dense, and audit-first.

  1. Work order intake with Zod validation, then triage, approval, and assignment with an explainable recommendation that names the disqualifying constraint.
  2. Batch scheduling with a deterministic greedy heuristic, compared against a naive first-available baseline with runtime measured in the browser.
  3. Parts reservation, validated completion, close, cancel, and invoicing from recorded labor, parts, and travel, in integer cents.
  4. Automation as propose, preview, approve or decline, receipt. Idempotent, with a stale-trigger check.
  5. Scenario Lab: six disruptions run on an isolated copy of state, each with a recovery proposal. Canonical state is untouched.

Architecture

  • Next.js 16 App Router, React 19, TypeScript, Zod. Hand-written CSS, no Tailwind.
  • Framework-independent domain modules: entities, state transitions, scheduling, reservations, SLA, financials, scenario simulation.
  • Deterministic seed: 120 customers, 200 locations, 480 assets, 42 technicians, 320 inventory SKUs, 80 open orders (seed file, OBSERVED).
  • Client session persisted in localStorage (serviceops.demo.v1, schema v2, Zod-validated, 5 MB cap), memory fallback.
  • Atomic domain commands. Every state change appends an audit event.

Engineering decisions

  • Business-calendar SLA: the order SLA is a wall-clock deadline and the contract SLA is computed in business minutes. Both are real commitments, and the interface must label which is which.
  • No navigation destination without a working, useful view (repo AGENTS.md).
  • Integer minor units for all money. Invoiced revenue and cash received are reported separately, never conflated.

Technical challenges

  • Two SLA clocks that disagree in presentation until labelled: wall-clock order deadline vs business-calendar contract deadline.
  • A seed that produced exactly 80% first-time fix for many technicians by construction, and closed orders with zero labor cost, which made gross margin read 100%. Both are fixed only in a local snapshot, not in the repo (see limitations).
  • Deployed commit unverified: rendered text in the live audit did not match current main code, suggesting the live build may predate main.

Demonstration scenario

  1. WO-10483: a chiller failure at a medical center. It is pinned first in the attention queue.
  2. Preview assignment: the system recommends the one technician who qualifies, and flags the others for missing EPA 608 or a schedule conflict.
  3. Approve, dispatch, reserve the part, complete, and invoice. The audit trail records every step.
  4. Run a Scenario Lab disruption, for example a technician call-out, on the isolated copy, then reset to the canonical seed.

Engineering evidence

  • 15 in-app views, one app shell, no dead destination found in a code grep (no TODO / coming-soon markers). [OBSERVED, code grep, VW-100 recon]
  • Accessibility suite with axe-core over all 15 views, plus Desktop Chrome and Pixel 7 Playwright projects. [OBSERVED, test files in repo]
  • Test files: 4 domain test files and 4 end-to-end specs in the repo. Pass counts were not re-run in VW-100 recon. [OBSERVED, file inventory only; UNVERIFIED pass count]
  • Synthetic-data label in the header and a synthetic-records disclaimer in the sidebar, on every view. [OBSERVED]

OBSERVED means read from repository evidence at the stated commit. DOC-CLAIMED means a repository document states it but it was not re-run during reconnaissance. UNVERIFIED means no supporting evidence was obtained. See the engineering inventory.

Known limitations

  • Public demo URL is doc-claimed (serviceops-phi.vercel.app) but the deployed commit is UNVERIFIED. Worth does not link it as verified.
  • Polish fixes from the October 26 live audit (specific seed text, dollar invoice previews, year-bearing coverage dates, labelled dual SLA deadlines, frozen-clock label, decision-story tour) exist only in a local snapshot. They are not in the repo and not live.
  • No CI workflow exists in the repo. Release claims rest on local runs.
  • Framing: CSP frame-ancestors is 'self' plus *.vercel.app. A veldariumworth.com iframe would be blocked. Link-out is the supported default.
  • The in-app Portfolio view links to the private GitHub repo, which 404s for visitors without access.

Sandbox readiness

Indefinite localStorage session with a frozen demo clock (2026-10-26, 9:00 AM ET). Reset restores the canonical seed. No registration, no expiry. A designed 60-minute exploration path was not evidenced; the guided tour is 7 steps plus free exploration of 15 views.

Current portfolio status: Demo unavailable in this harness: deployment unverified, demoUrl null, allowlist empty.