CASE STUDY 03 / BUSINESS WORKFLOWS
A public service website and protected staff workspace for enquiry intake, assignments, follow-ups, and invoice records. The engineering focus is the transition from untrusted input to a reliable business record.
01 / SYSTEM VIEW
A simplified view to support a technical conversation.
Service information and enquiry intake
Assignments, follow-ups, and invoices
Permission checks · field validation · computed totals
Requests and invoice history
Follow-up after saving the request
Conceptual view of the project summary. Saving an enquiry before attempting notification separates record creation from delivery failures.
02 / ENGINEERING DECISIONS
Implementation choices paired with the tradeoffs they introduce.
The parser tests exclude client-supplied totals, paid amounts, and paid status from the validated invoice input.
The server still needs to enforce permissions and derive authoritative values when the record is saved.
The selected tests cover per-line rounding, tax rounding, large values, and amounts that binary floating point cannot represent exactly.
Rounding rules are part of the business model and need to remain consistent between previews and saved invoices.
Tests exercise invalid quantities, prices, tax rates, dates, missing names, and incomplete edit identity.
A convenient form can guide input, but validation must also handle requests that never used that form.
03 / REVIEW SCENARIOS
Illustrative explanations of selected test definitions. These controls do not call the application or execute its tests.
A request supplies a low total, a paid amount, and a paid status alongside invoice fields.
The selected parser test expects those authority-bearing fields to be excluded from parsed invoice input.
Review the server save path to confirm that calculated values and payment history are the only authority.
A unit price contains excess fractional digits, scientific notation, or a non-finite value.
The invoice tests expect malformed or out-of-range monetary inputs to throw validation errors.
Present a useful field error while preserving the user’s valid entries.
An invoice reaches the permitted total, then another line pushes it beyond that limit.
The selected test accepts the exact maximum and rejects values that exceed it, including through tax.
Apply equivalent limits to imports, edits, and payments as well as initial creation.
04 / TRACEABLE EVIDENCE
Selected source reviewed on November 6, 2026.
Source reviewed · tests not rerunsrc/lib/invoice-model.test.ts9b83e5f14339These statements summarize the test definitions at this repository snapshot. They do not report a passing run, complete coverage, or an independent security audit. Application source stays private.
WHAT I WOULD EXAMINE NEXT
A fuller production review would verify staff permissions at server endpoints, exercise partial payments and corrections, and test notification failures after a request is saved.