SignalTechRepairSystem

SignalTechRepairSystem is a web application for repair shops that need to track devices from intake to collection, take payments, run point-of-sale checkout and record expenses — for several separate businesses (tenants) on one system.

It consists of a React and TypeScript frontend and a Node.js/Express API backed by PostgreSQL. It is being prepared for a pilot; it has not been deployed to production.

A repair job passes through many hands: intake, diagnosis, customer approval, the repair itself, testing, payment and collection. Without enforced rules, steps get skipped — a device is released without testing, a job is repaired before the customer approves, or a payment is recorded twice. Each shop's data must also stay strictly separate from every other shop's.

The pilot design is a single server: HTTPS through nginx, which serves the built React app and proxies only /api to a Node/Express process, which talks to a private PostgreSQL database.

• Frontend: React, TypeScript and Vite, with React Query, React Hook Form and Zod.
• Backend: Express 5 with request validation in Zod and parameterized SQL through node-postgres.
• Database changes are delivered as ordered, rerunnable SQL migrations, separate from initial schema setup.
• New client businesses are created by an operator command-line tool; there is no public sign-up.

Repair status changes are defined in one explicit transition map, and the API rejects any change that is not in it. For example, a job moves Received → Diagnosing → Awaiting approval → Approved → In repair → Quality check → Ready for collection → Collected, with defined exits for cancelled, unrepairable and returned-unrepaired jobs.

• A repair cannot enter customer approval before a diagnosis is recorded.
• Final quality checks record a result for nine device functions (such as power, display, charging and connectivity) as pass, fail or not tested. The database rejects any other shape.
• Quality-check submission and marking a job ready are serialized, so readiness cannot bypass the passing-check gate.
• Collection is gated on the job's state, and repair parts are consumed only through the accepted repair workflow.

• Sessions use a random bearer token; only its SHA-256 hash is stored. Sessions expire, and logout revokes them.
• Tenant and branch scope are checked on the server for every request. Queries use parameterized values and explicit tenant predicates.
• Permissions come from tenant-scoped roles; integration tests cover permission denial and cross-tenant isolation.
• Login is rate limited per IP and per username/IP pair, and the API as a whole per IP. Request bodies are size-limited and must be JSON.
• Business changes, logins and branch switches are written to a tenant-scoped audit log, without tokens or passwords.

Repair and point-of-sale payments accept an idempotency key that is unique per tenant, stored with a fingerprint of the original request. A retried request with the same key returns the original result instead of recording the payment twice, and a reused key with different details is rejected. Row locks inside a transaction handle concurrent retries, and a repair payment larger than the outstanding balance is refused. Expense creation uses the same idempotency pattern. Payments are recorded internally; there is no external payment gateway.

• An integration test suite (29 tests) runs against a dedicated PostgreSQL test database. It covers tenant isolation, session expiry, login throttling, every allowed and disallowed repair status change, quality-check gating, payment and sale idempotency, permissions and audit logging.
• A staging and pilot runbook documents the server layout, least-privilege database roles, TLS, secrets handling, migrations and client provisioning.

In progress: preparing for a pilot. The pilot scope covers login and branch switching, customers and devices, the full repair lifecycle, point-of-sale checkout with receipts, voids and returns, and controlled expense recording.

• Not yet deployed to production, and no pilot has been completed.
• Dashboard and reporting, general inventory and product administration, purchasing, warranty management and staff/role administration screens are hidden from the pilot.
• Rate limiting is in-process, so it only works for a single server process; multiple instances would need a shared store.
• Tenant isolation relies on application queries and tests; PostgreSQL row-level security is not configured.
• The frontend stores session tokens in localStorage; a strict Content Security Policy is required, and cookie-based sessions are a possible future change.
• No multi-factor authentication or account recovery yet.