Dinghuobao — WeChat B2B Order Workflow

• 

• 

Inspiration

What it does

How we built it

Inspiration

Small wholesalers often receive orders through scattered WeChat messages, phone calls, and spreadsheets. Customers cannot easily see what they requested or where it is in the fulfillment process, while operators repeatedly copy data between product, inventory, delivery, and payment records. We wanted a workflow that fits the channel customers already use—WeChat—without pretending every B2B order is a consumer e-commerce checkout.

What it does

Dinghuobao turns an informal wholesale order into a traceable workflow across three connected surfaces:

• Customers use a WeChat Mini Program—a lightweight app inside WeChat—to browse products, submit an order request, manage delivery addresses, reconnect to an already verified customer record, view history and status, save favorites, and reorder.
• Operators use a Vue admin dashboard or the Mini Program's administrator entry to manage products, customers, order status, delivery, inventory, stocktakes, payment records, and audit logs.
• An Express + MySQL backend enforces identity, inventory, and order-state rules, while WeChat Cloud Hosting on Tencent CloudBase provides the deployed runtime.

This is intentionally an order-request system rather than an online marketplace. Prices are references; the operator confirms final quantities, delivery, and payment offline.

How we built it

The monorepo uses TypeScript end to end: uni-app + Vue 3 for the WeChat Mini Program, Vue 3 + Element Plus for the web admin, Express for the API, MySQL in production, SQLite for zero-config local development, and Vitest for regression tests.

Before Build Week

Before the Submission Period began, Dinghuobao already had the three-surface architecture and its basic ordering workflow. We use commit c5efbca—dated before July 13, 2026 at 9:00 AM PT—as the baseline. We do not claim that earlier work as the Build Week contribution.

Added during the Submission Period

Between baseline c5efbca and release commit cc4c9d5, we:

• Refactored all 18 registered Mini Program pages into a coherent V2 interface built from reusable navigation, form, order, address, status, empty/error, and confirmation components while preserving existing API contracts.
• Implemented and tested long-content, empty, failure, privacy-consent, session-expiry, inventory-limit, and small-screen states, with real WeChat DevTools evidence at 430×932 and 320×568.
• Normalized WeChat identity metadata across the header and source variants observed in production on WeChat Cloud Hosting, with safe diagnostics and regression tests.
• Added WeChat privacy authorization, verified customer-session recovery, customer synchronization safeguards, and a release-artifact validation gate.

This extension is traceable through nine dated commits, the primary Codex session, automated checks, and visual verification artifacts.

How we used Codex and GPT-5.6

We used Codex with GPT-5.6 throughout the Build Week extension.

One concrete case started with live customer-login and order-flow failures: WeChat Cloud Hosting exposed identity metadata through more than one production path. We gave Codex the failing requests, logs, and existing contracts. It helped trace the mismatch to the transport and identity boundary, propose compatible normalization and non-secret diagnostics, and add focused tests. We reviewed the security boundary, then verified the fix with server tests, builds, live health and API probes, and deployed revisions.

A second case was the 18-page redesign. We supplied 18 reference screens, explicit component and behavior constraints, and existing business logic. Codex helped map pages to shared components and edge states, implement the refactor, generate regression tests, and compare real WeChat DevTools screenshots at two target viewports. Human review decided product trade-offs and rejected changes that altered business behavior.

GPT-5.6 powered the development workflow inside Codex; it is not presented as a customer-facing runtime AI feature.

Challenges we ran into

The hardest problems were at system boundaries: reconciling WeChat identity metadata across local and cloud paths without mixing customer records, preserving order and inventory behavior during a large UI refactor, and making 18 pages coherent across long text, empty states, failures, privacy prompts, and small screens. Codex was most useful when we supplied concrete logs, screenshots, contracts, and failing tests instead of open-ended prompts.

Accomplishments that we're proud of

• Converted 18 independently styled pages into a reusable, testable component system without changing the existing business contracts.
• Fixed the observed WeChat Cloud Hosting identity and transport failures and verified the resulting deployed API paths.
• Added explicit privacy authorization, customer-session recovery, failure-state coverage, and release-artifact checks.
• Produced a reproducible evidence trail from the baseline commit to the release commit.

What we learned

AI-assisted development becomes more reliable when the model works against explicit constraints and executable evidence. Visual targets, state machines, API contracts, and regression tests turned Codex from a code generator into an iterative engineering partner. We also learned that release compliance and failure recovery are product design problems, not merely deployment details.

What's next

Next we want to extend the workflow with richer operator analytics, proactive low-stock alerts, batch-order import, and a broader web/PWA entry point while keeping the same traceable order-request model.

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Dinghuobao — WeChat B2B Order Workflow

Built With

• 3?uni-app?wechat
• cloudbase?element
• gpt-5.6?codex?typescript?vue
• mini
• program?node.js?express?mysql?tencent