Independent project · Full-stack operational simulation
A warehouse you can break on purpose. And put back to work.
Try the incident lifecycle · Explanatory diagram
Operational software needs to connect equipment state to the progress of work. OpsBridge makes that relationship tangible in a small browser-based warehouse: a fault blocks the work that depends on the device, creates an incident and gives the operator a recovery path.
The scope is a public engineering demonstration, not a warehouse management product. It is deliberately lightweight, with one service serving the interface, HTTP API and WebSocket connection.
I wanted visitors to see how an operational system behaves, rather than read a list of technologies. Orders move through receiving, picking, packing and dispatch while simulated scanners, cameras, printers and handhelds produce events.
Selecting equipment reveals its state. Selecting a parcel reveals its journey. The failure controls let a visitor change the operation and observe the consequence without an account or setup.
The Fastify server owns the simulation. React renders snapshots and sends typed commands for faults, incident actions and shift changes. The browser does not maintain a separate version of the warehouse rules.
WebSockets distribute changes to connected views. An HTTP snapshot fallback supplies current state when needed. Day and night styling change the presentation without resetting the operation.
Equipment faults do more than change a status badge: orders requiring affected devices wait, while unaffected work can continue. The system creates an incident that the visitor can acknowledge and recover using a fault-specific action.
The illustrated floor keeps that relationship visible. A side inspector carries order journeys and recovery detail, leaving the main view focused on the movement of work.
OpsBridge uses original abstractions and synthetic data, not Renovotec code, customer records or proprietary workflows. The devices are simulated; no claim is made that it controls physical warehouse equipment.
I used AI-assisted development to accelerate implementation and iteration. The repository exposes the architecture, source and verification workflow so the work can be examined rather than taken on trust.
The following decisions connect the implementation to its practical constraints. Each separates what I changed from what still needs verification.
Different evidence answers different questions. This record distinguishes a visible demonstration, implementation history and validated operational outcomes.
What it supports: Visitors can follow orders, inspect equipment and run the failure-to-recovery interaction themselves.
What it does not establish: All devices and events are simulated; visible counts are not business-impact metrics.
What it supports: The repository contains the domain model, React client, Fastify server, SQLite event store and technical decisions.
What it does not establish: AI assistance is disclosed. A public repository is evidence to inspect, not a substitute for technical evaluation.
What it supports: The October 2026 build record reports 22 tests passing, alongside type checks, lint, formatting and production build checks.
What it does not establish: This is dated verification of the implemented scope, not a claim of present uptime or physical-device validation.
The important connection is between fault, impact and recovery. Showing all three makes the system easier to understand than a dashboard that reports only healthy and unhealthy devices.
The demo’s deliberate limits—synthetic hardware, a shared server and rebuildable event history—keep it affordable and inspectable. Durable storage and real-device adapters would be separate engineering work, not features implied by the current deployment.