MendCart
Repair before replace: a purchasing brief with a spending boundary.
27 October 2026 prototype. An actual $85 PayPal sandbox flow returned a pending child capture; no settled payment or revenue is claimed.
Inspiration and intended audience
MendCart is designed for shared workshops and repair teams. The demonstration uses a fictional repair catalog; evaluation with actual buyers remains future work.
Its central idea is an inspectable brief: make interpretation visible before an authorized order.
What the application does
MendCart converts a bounded English maintenance request into catalog goals and a versioned brief. Each goal retains its source clause, requested quantity and unit, selected item, supplied quantity, assumptions and exclusions. Budget and supplier controls remain visible.
The brief distinguishes requested units from supplied packs. Five cells may require two four-cell packs, visibly supplying eight and disclosing three surplus cells. An exact-five-cell requirement asks for clarification. Detected unsupported specifications and unresolved requirements also require clarification.
The executed plan records two fictional Demo P100 repairs and eight protected, new 18650 cells, excluding tools: two repair kits and two four-cell packs total a synthetic $85 under a $90 ceiling. A separate $80-ceiling check blocks that cart without removing a goal or substituting reclaimed cells. It is not the executed transaction.
Meaningful local AI
The default model is a supervised TF-IDF nearest-neighbor classifier trained from 72 original synthetic examples. It learns corpus-wide term weights and compares request clauses with labeled examples to identify pump, battery, tool or unsupported intent. The interface exposes retrieval evidence; similarity scores are not probabilities.
Deterministic parsing and constrained selection then apply the implemented quantity, exclusion, supplier, inventory and budget rules. The model recommends; it never supplies payment authorization. Python’s standard library and a browser run the application without an external inference account. Codex assisted development; no external model-service use is claimed.
PayPal and the authorization boundary
The Orders v2 sandbox adapter connects the reviewed brief to checkout. Local approval binds the exact brief digest and server-held cart to the browser session. Separate PayPal payer approval is required before a new capture.
Before financial dispatch, the server rechecks the brief, cart, budget, approval and freshness, including after OAuth token acquisition. The implemented adapter checks provider order references, currency and amount. Returned item arrays must match approved SKUs, quantities and USD unit amounts; omitted arrays remain explicitly unverified. Stable request identifiers support retries within this in-memory demonstration. Recovery and pending-status handling do not authorize an additional capture.
The actual $85 sandbox flow was exercised on 27 October. At 01:04:40 UTC, provider GET showed order COMPLETED but child capture PENDING / PENDING_REVIEW. It remained pending after the Payment Review simulation was switched off. Existing-order checks preserve that distinction: an exercised integration with an unresolved capture, not a settled payment or revenue.
Testing and honest limits
On 26 October, the local suite passed 139 isolated tests with mocked provider responses and zero external connection attempts. Browser checks covered the $85 plan, budget blocking, clarification and a read-only preview.
In a pre-specified, project-authored 64-case synthetic routing comparison, the unchanged model classified 55/64 correctly versus 39/64 for simple keywords. Both falsely accepted 7/16 unsupported cases. This supports additional coverage on those phrases, not blind user accuracy, complete purchasing correctness or superiority to stronger systems.
All suppliers, prices, inventory and compatibility evidence are synthetic. The parser is bounded English handling, not general understanding, diagnosis or safety certification. Records are in memory, without a durable ledger or live supplier integration. No real buyers, purchases, revenue, savings or environmental outcomes are established.
The 137-second English screen walkthrough uses actual captured application stills, a labeled separate budget check and the original pending receipt. It includes captions and disclosed offline synthetic narration, with no music or reenacted payment. Its public URL is supplied separately after publication verification.
Next steps are verified compatibility/catalog data, durable reconciliation and consenting workshop evaluation that records failures as well as useful outcomes.
Log in or sign up for Devpost to join the conversation.