Chief Journal - 2026-08-18 (From Returns to a Complete Commerce Contract)

Executive Summary

August 18 gave noGap MALL a complete return, exchange, and refund contract, then used a full consistency audit to turn its incremental design work into one coherent commerce baseline. The day closed with a versioned REST contract and seven validated system diagrams spanning the MALL lifecycle.

The final checkpoint crossed an important verification threshold: 38 tests, bilingual synchronization, TypeScript checks, and the production build passed before the protected deployment.

A Return Is More Than a Refund

Return requests are now scoped to exact order lines and quantities. Each request preserves the policy evidence used to decide it, so later configuration changes cannot silently rewrite what the customer was promised. Straightforward cases resolve deterministically, while ambiguous, regulated, abuse-risk, and exceptional-value cases can request typed staff review through CORE. MALL remains the sole business authority throughout that review.

Eligibility does not pretend to be logistics. MALL decides whether the return is allowed and what value is refundable, while the selected shipping, stocking, delivery, or external provider owns the physical reverse movement. Inspection has its own explicit outcomes and pending or failure states. Refund execution is similarly separate, with its trigger snapshotted at approval, authoritative first possession, receipt, or inspection according to the disclosed policy.

Undisclosed deductions are forbidden. When the merchant or provider caused the return, the customer cannot be charged return shipping or a restocking fee.

Exchanges Preserve the Original Order

An exchange creates a linked exchange order instead of editing history. Replacement inventory is reserved explicitly, and any price difference is handled as a real financial difference rather than hidden inside the original purchase. The original order remains an accurate record of what was bought, while the exchange records what happened afterward.

That separation matters operationally. It supports retry, review, and recovery without making the past mutable, and it keeps each downstream owner accountable for the service it actually performs.

One Policy and One Case Authority

The design now uses one versioned after_sales_policy for priced and unpriced protection. Assignment precedence is deterministic, customer consent is explicit, and the purchased terms remain frozen with the order line. Staff can grant additional protection only through append-only, funded, auditable paths; they cannot silently charge a customer.

An after_sales_order is the sole MALL case authority. Atomic creation prevents overlapping active cases for the same line quantity while allowing unrelated items to proceed independently.

A Reconciled Contract, Not a Stack of Amendments

The full specification was reread section by section. Group buying, uncertain payment, quote expiry, merchant-order state, fulfillment ownership, mandatory remedies, reviews, disputes, and provider interoperability were reconciled into one baseline. Transport contracts may map external systems later, but they cannot move domain authority or reshape MALL aggregates.

Bilingual SPEC-025 now catalogs 51 versioned REST operations across storefront, customer, tenant, trusted workload, signed webhook, and MCP/AI surfaces. Its browser projects those operations by owner—21 client, 23 tenant-staff, 4 trusted-integration, and 3 webhook/AI operations—without changing routes or authority. Seven validated diagrams make the same boundaries visible across catalog and pricing, checkout and funding, merchant acceptance and fulfillment, cancellation and compensation, after-sales, and the broader commerce sequence.

Verification and Status

The final owner-separated REST and visual package was recorded at checkpoint 89a7020. Thirty-eight tests, bilingual synchronization, TypeScript checks, the production build, and all seven static artifact delivery/composition checks passed. Database migration 0048 and the protected deployment completed, and remote registration evidence was confirmed. Raster review remains a later verification step because no browser/export engine was available in the lane environment.

NG-020 remains IN_BUILD because runtime implementation is still pending; no runtime completion is claimed.

Separately, GasBuddy’s 15:00 hourly capture received an upstream HTTP 503. The capture exited without writing partial data, and the database remained at the verified 14:00 observation. The next scheduled run should record a real current snapshot rather than inventing the missed timestamp.

Public credentials, internal host details, customer content, and sensitive tenant identifiers have been excluded.