The browser cannot set the price
The server reads the product and price from the catalog. A client-provided value cannot determine the order total.
server/commerce.ts · createOrderMK / ENGINEERING NOTES
Considered outside.
Engineered inside.
Engineering decisions inside MK • DΞV itself: trust boundaries, order states and recovery from failure.
The interface has one button. Behind it are eligibility checks, a server-owned price, a separate payment request and delivery only after verification.
01 / STATE MACHINE
What if the event arrives twice?
A simplified local model. No real payments, provider requests or file delivery.
- Order created
- 02Payment verified
- 03Purchase delivered
Payment must be verified first. Select “Deliver” to test the guard.Delivery attempts: 0 · Successful deliveries: 0
State and job stay together
Payment confirmation, state changes and delivery scheduling are written in a transaction. Unique identifiers handle repeated events.
server/commerce.ts · confirmFailure is a first-class scenario
A failed delivery can be retried without paying again. Late and ambiguous transfers require separate review.
server/jobs.ts · server/commerce.tsTest behavior, not promises
Automated tests cover duplicate events, order access, unverified payments and missing inventory. They validate logic, not production-scale traffic.
tests/payment.test.mjs02 / THE BUILD
One product. Several layers.
This diagram describes the current MK • DΞV implementation. Third-party case architectures are not disclosed without verification.
03 / DECISIONS, NOT BUZZWORDS
Why this way, not another.
Decision: shared brief validation
Context
The form should explain errors immediately. Requests can bypass the form, so the server cannot trust browser validation.
Decision
One rules module is used before submission and before storage. Access, consent and rate limits are checked on the server.
// server/api.ts
const errors = validateBrief(details);
if (Object.keys(errors).length) {
return json({
error: 'Invalid brief',
fields: Object.keys(errors)
}, 400);
}Trade-off
Shared rules reduce drift, but do not replace tests or server controls. Not every business rule belongs in client code.
A practical review checklist
- Does the code trust unvalidated input?
- What happens on a retry or timeout?
- Can users recover without losing their input?
- Does the flow work with a keyboard and reduced motion?
- Is the failure path covered by a test?
What a project handover should leave behind
- Startup instructions and configuration keys without secrets.
- A map of data, integrations and background jobs.
- Core workflow checks and known limitations.
- Backup and recovery steps.
- Agreed support boundaries and next steps.