01 / MARKETING
Draft, review, publish
Chinese, English and Kazakh drafts connect a product to its target market. Editing an approved asset returns it to draft, so customer-facing content passes review again.
← Selected projects
ENGINEERING CASE / TEACHING SYSTEM
Silk Road Intelligence 丝路智链
One order connects multilingual marketing, checkout, quality checks, simulated fulfillment and service. The engineering question is whether each transition preserves price, inventory and access rules.
- Context
- Cross-border commerce teaching
- Public material
- Frontend screenshots & case notes
- Verification record
- 2026.10.15
01 / INTERFACE STUDY
From entry to fulfillment
Actual frontend views with synthetic teaching content. Login fields are empty.
02 / ORDERS
A ledger beyond the overview
Administrators search and page through order history by number, SKU, status or destination. Details and A4 documents read the saved item and price snapshots, rather than recalculating from current product data.
03 / FULFILLMENT
Every step leaves an event
The task card traces inspection, locating, picking and dispatch as ordered status changes. Its event history records the teaching simulation; failed tasks can be retried, with simulation and device event sources kept distinct.
02 / ORDER JOURNEY
Five stages, one business record
A teaching workflow linking visible actions with persisted state.
- 01
Marketing
Product → multilingual draft → review
- 02
Checkout
Cart → server pricing → stock reservation
- 03
Quality check
Simulated payment → recorded QC result
- 04
Simulation
Inspect → locate → pick → dispatch
- 05
Service
Authorized references → human resolution
The overview polls every five seconds and refreshes after successful actions. Service answers draw on authorized products, orders and policies; after-sales resolution records a human decision.
03 / ENGINEERING DECISIONS
Make invalid actions explicit
Quality gates before dispatch
Only a passed quality check permits task creation. Task events must follow QUEUED → INSPECTING → LOCATING → PICKING → COMPLETED. A failure records its reason; retry returns the task to the queue.
The same scope on every route
Customers read their own orders, tasks and after-sales records; administrators read within their college. Historical details and print routes recheck visibility. Model context excludes recipient names and addresses.
A retry must mean the same request
Order request IDs are scoped to the user; reusing an ID with different content is rejected. Transactions reserve stock at server prices, cancellation returns stock once, and event IDs prevent duplicate task advancement.
04 / VERIFICATION RECORD
41 checks in the existing record
Recorded 15 October 2026. These backend tests were not rerun for this portfolio page.
41 passed
0 failures · 0 errors · 0 skipped
| Area | Checks | What the record covers |
|---|---|---|
| Commerce workflow | 9 | Pricing, stock races, idempotency, access, QC, ordered events, retry and history |
| Personal AI services | 12 | Mock model client: sources, output format, scoped context and failure handling |
| Registration & recovery | 11 | Role escalation protection, one-use tokens and old-session revocation; mock SMTP |
| Login sessions | 6 | Authentication-service regression |
| Capacity filter | 3 | Concurrency limits, including shared marketing and service AI slots |
The same record reports a successful frontend production build. Its isolated MySQL tests and mocked external services establish the stated local checks, rather than production capacity or hardware validation.
05 / SCOPE & PROVENANCE