Guide · Service business operations
How the enquiry-routing sample behaves under test
Inspect five executed intake, duplicate and recovery cases, with reproducible inputs and clear limits on what a browser sample proves.
Written by Fireflax · 8 minute read
Reviewed by Codex — source and implementation review ·
What did this sample actually do?
We checked five defined paths in the fictional Northstar Plumbing enquiry workflow on 8 October 2026. Each path was run against the repository’s enquiry rules and separately against the downloadable starter bundle. The table records those finite results; it is not a customer case study or a production reliability figure.
Test scope
Five cases per implementation, ten case executions in total. Each implementation recorded five passed and zero failed. Tests ran locally with Node.js 22.23.2, synthetic inputs and no network connector. They checked the rules used by the browser demo; they did not operate a live inbox, CRM or message service.
Inputs and expectations were defined first.
The complete fixture is Alex Morgan at alex@example.com, Bristol BS1, asking about a kitchen tap that has been dripping for a week. The incomplete fixture is Sam Taylor at sam@example.com, with no area and the message “Can you help?”. These are fictional contacts.
The duplicate case resubmits Alex’s request with a different display name, upper-case text and extra spaces. Repeated approval attempts to replace an already approved reply. The recovery case uses the explicit simulated-failure flag, attempts to bypass restore, restores the same record and then approves it again.
| Path | Expected | Observed |
|---|---|---|
| Complete request | One Plumbing enquiry for the Service coordinator; approval needed before completion. | Both runs: review → completed; one record; reviewed text retained. |
| Missing details | Ask for area and job detail; approval must not resolve the missing information. | Both runs: review → awaiting-details; both missing items retained. |
| Normalized duplicate | Same email, area and message with different case/spacing returns the existing record. | Both runs: same ID and one record; state/history unchanged. A changed display name did not alter the match. |
| Repeated approval | A second approval must not replace the completed reply or add history. | Both runs: completed state and original approved text unchanged. |
| Failure and recovery | Keep the blocked record and draft; prevent direct reapproval; restore requires fresh approval. | Both runs: blocked → review with prior approval cleared → completed; one record throughout. |
Complete request
Expected: One Plumbing enquiry for the Service coordinator; approval needed before completion.
Observed: Both runs: review → completed; one record; reviewed text retained.
Missing details
Expected: Ask for area and job detail; approval must not resolve the missing information.
Observed: Both runs: review → awaiting-details; both missing items retained.
Normalized duplicate
Expected: Same email, area and message with different case/spacing returns the existing record.
Observed: Both runs: same ID and one record; state/history unchanged. A changed display name did not alter the match.
Repeated approval
Expected: A second approval must not replace the completed reply or add history.
Observed: Both runs: completed state and original approved text unchanged.
Failure and recovery
Expected: Keep the blocked record and draft; prevent direct reapproval; restore requires fresh approval.
Observed: Both runs: blocked → review with prior approval cleared → completed; one record throughout.
Run it and compare your own result.
Download starter 1.0.0, extract it and follow its README. The included checks contain the expected states and assertions. Run node verify.mjs to produce a fresh report with the inputs, expectations and observed history for all five cases. A failed case makes the command exit unsuccessfully.
The repository-source run called the current TypeScript helpers directly. The starter run loaded the bundled JavaScript without importing repository files. Their shared test definitions make the comparison reproducible; the two executions are not independent proof of the correctness of every possible rule.
The package also has a separate pause rehearsal.
The package’s command-line wrapper adds local-file storage and pause/resume controls. Its eleven-command rehearsal initialized a record, simulated failure, paused, attempted a blocked restore, resumed, restored, approved twice and reset. The restore while paused intentionally exited with an error and left state unchanged. Resume did not replay an action.
That is a successful negative check, not an unreported failing test. node cli-check.mjs runs the sequence in a temporary folder and removes that folder afterwards. These CLI features are not present in the browser demo.
What remains unproved
The browser’s duplicate memory disappears on reset, reload or workflow change. The starter stores a local file, but has no multiuser locking or production record store. A changed message can be a new enquiry; this key cannot decide whether two differently worded requests describe the same job.
A real implementation would need durable request and action identifiers, a decision about changed requests, and checks of the destination before retrying. Those are required additions, not fixes demonstrated by these local results. The simulated failure sends nothing, so it does not test a connection that acted successfully and then lost its confirmation.
No customer labour savings, conversion rate, live integration, uptime or exactly-once delivery follows from these five cases. The existing repository unit suite separately passed 21 checks of the enquiry helper. That broader suite is useful regression coverage, not 21 customer trials or 21 browser sessions.
Sources and review notes
Drafted with Codex and checked against executed fictional sample tests, source code and an independent Codex starter rehearsal. These results do not establish a live integration or customer outcome.
- Retained browser-helper test
Inputs, expectations and observed states from actual source execution.
- Try the enquiry sample
Reproduce the review and failure paths with fictional details.