RepairLoop

Repair the right thing, with the right part.

Comment

Inspiration

Laptop battery replacement looks like a simple search task until you are standing in front of a battery label. A Dell Latitude 5400 family can use 42Wh, 51Wh, or 68Wh packs, at 11.4V or 7.6V, with several interchangeable Dell part numbers. A 68Wh 15.2V 3HWPP pack can look plausible and still be the wrong part for a 68Wh 7.6V configuration. A single wrong character in a part number becomes a wasted purchase, a returned part, and another repair abandoned.

The same confusion is worse for a small repair shop. A customer sends a messy message: “Dell Latitude 5410, label says R8D7N, dies after 20 minutes.” The shop has to turn that into an exact part, a source, a price, and a quote, while knowing that the seller may be out of stock or that the label may disagree with the report.

AI made reading those messy inputs easier. It also made guessing easier. We wanted the opposite: use AI to read the mess, but make a small, cited catalog decide fitment. If the evidence is incomplete or contradictory, RepairLoop should refuse rather than invent a part.

What it does

RepairLoop is a source-linked battery fitment and Sandbox checkout demo.

Consumer check. A user uploads a redacted battery report or label. Gemini extracts the battery name, installed part number, capacities, and health into editable fields. The user selects the laptop model, corrects anything the model misread, and confirms the fields before matching. A deterministic matcher then returns an exact family, labelled lower-capacity options, or a hard no-match. It explicitly excludes the 68Wh 15.2V 3HWPP variant for a 7.6V configuration, and it stops on damaged-battery symptoms such as swelling, leaking, overheating, or a burning smell.

Source-cited explanation and AI report. After a verified result, “Explain with AI” can explain why the selected part fits using only the supplied catalog evidence and a validated source URL. The user can also generate an AI-assisted repair report from the confirmed fields and the uploaded redacted image. The report is narrative and useful, but it cannot change the selected part, price, stock, or payment decision.

PayPal Sandbox checkout. The buyer reviews the exact part and the server-created total, approves a PayPal Sandbox payment, and sees success only after a verified capture. The receipt survives a refresh and is read-only. Capture retries stay within the original checkout session.

Shop mode and AG Grid matrix. A shop can paste a customer request; AI extracts the facts, the catalog drafts a quote, and a human reviews every field and re-checks the catalog after any correction before adding the quote to a browser-local queue. The shop can share a customer checkout link. A separate AG Grid compatibility matrix lets shops filter the source-linked model × part rows by capacity, voltage, fitment status, seller, source, and point-in-time availability.

This is a Sandbox prototype: there is no live inventory, shipping, fulfillment, warranty, or real sale.

How we built it

We built a small, opinionated stack:

  • Web: Next.js 16, React 19, TypeScript
  • API: Fastify 5, TypeScript
  • Data: Neon PostgreSQL, Drizzle ORM
  • AI: Gemini through @google/genai, server-side only, structured JSON validated with Zod
  • Payments: PayPal Orders v2 + JavaScript SDK v5 Buttons, Sandbox only
  • Shop matrix: AG Grid Community 36
  • Tests/operations: Vitest, Playwright, GitHub Actions, Render, Vercel

The catalog is deliberately narrow and auditable: 17 models, 5 parts, 15 sources, and 38 compatibility rows across shared Dell 42/51/68Wh families and the Lenovo ThinkPad T480s 57Wh family. Each part has a source, a fitment note, an evidence quote, and a verification date. Model aliases have their own source map. The catalog validates aliases, source references, availability records, and the explicit 3HWPP exclusion before deployment.

We treated AI and fitment as separate systems. AI extracts, structures, explains, and writes narrative reports. The deterministic matcher owns the compatibility decision. The UI makes the human confirmation gate visible, and the API independently re-matches the case and validates the selected part before creating a PayPal order.

Payments are real Sandbox API calls with a server-side price, per-order idempotency, a capture capability token, amount/currency validation, raw-body webhook verification, replay protection, and event deduplication. Shared receipts are read-only.

The work is covered by 46 API tests and 19 Playwright scenarios (57 runs across desktop, mobile Chromium, and WebKit in CI). The suite covers the matcher, signed and stale webhooks, capability tokens, availability gates, the consumer flow, shop review invariants, AG Grid, receipts, and the AI report UI.

Challenges we ran into

The hardest part was making the “verified” promise true at the edges.

We found and removed unsafe model aliases. P92G was incorrectly attached to the Latitude 5400; bare 7590, 7591, and 7791 could map a non-2-in-1 Inspiron to a 2-in-1 catalog row. We replaced fuzzy part-number matching with exact or explicitly documented report-token normalization, and we added a capacity-consistency check so a 42Wh report cannot silently verify a 68Wh part.

We also had to separate “fitment verified” from “available now.” R8D7N is fitment-verified but the named seller reports it out of stock. T480s seller availability is unknown. We expose both states and disable checkout instead of pretending that a catalog fitment row is live inventory. We also disclose the R8D7N capacity conflict: Parts-People/Dell list 51Wh, while iFixit lists 48.5Wh.

Shop mode needed stronger human gates. Editing a model or part correction now invalidates the reviewed quote until the shop re-checks the catalog; otherwise an old quote could be approved after the fields changed.

On the AI side, extraction and narrative reports are useful but fallible. We added consent for images, symptom text, shop text, and report generation; server-side image re-encoding strips EXIF/GPS metadata; model output is validated; and the report is clearly labelled as AI-assisted. The catalog remains authoritative.

The remaining hard gap is commerce: there is still no seller integration, live stock, fulfillment, returns, warranty, authentication, or demand evidence. We did not hide that behind a fake “store.”

Accomplishments that we're proud of

  • A working end-to-end consumer flow: image/label extraction → human confirmation → deterministic exact/no-match/safety result → source evidence → PayPal Sandbox capture → read-only receipt.
  • A source-linked catalog with 17 models, 5 parts, 15 sources, and 38 compatibility rows, including an adjacent Lenovo T480s family.
  • Real refusal behavior: exact exclusions, no-match states, damaged-battery safety stop, capacity conflicts, partial part-number rejection, and out-of-stock/unknown availability gates.
  • A real PayPal Sandbox capture and a live receipt that shows verified webhook/capture events.
  • An AI-assisted repair report generated from both the redacted image and the confirmed fields, with the catalog still owning fitment.
  • A shop intake workflow with human review, a customer checkout link, browser-local queueing, and an AG Grid compatibility matrix.
  • A test suite that covers the trust boundaries, not just the happy path: signed webhooks, capability tokens, capacity conflicts, model aliases, shop re-check, and mobile no-overflow.

What we learned

AI is excellent at reading a messy image and bad at being an authority. The model can find X77XY in a report, but it cannot know that a 68Wh 15.2V pack is wrong for a 7.6V configuration. The catalog can know that only if a human has recorded the source and the evidence.

The refusal is the product. A no-match or safety stop is not a failed conversion; it is the moment the system earns trust. The human confirmation gate matters just as much: the user must see and correct what AI read before the catalog can act on it.

We also learned that data freshness and availability are separate from fitment, that a browser-local shop queue is not a shop system, and that a Sandbox capture proves the payment mechanics but not the commerce. The distance between “payment succeeded” and “the customer received the right part” is the business, and it needs supplier integration, fulfillment, returns, warranty, and demand evidence.

What's next for RepairLoop

  • Run a full 20–30+ real-image extraction and adversarial evaluation, publish honest metrics, and keep manual entry as the fallback.
  • Add authentication, tenant-scoped shop identities, signed/capability receipts, server-side queues, and audit logs.
  • Integrate a real supplier or affiliate path with live stock, price, seller handoff, shipping, returns, and warranty ownership.
  • Run a small real repair-shop pilot and measure time-to-quote, avoided wrong-part purchases, and willingness to pay. No demand claim will be made without evidence.
  • Expand the verified catalog only where sources agree, with automated source freshness, admin review, and rollback.
  • Add capture reconciliation, refund/void handling, monitoring, backups with restore drills, and a production migration path.
  • Complete accessibility and cross-browser testing, including keyboard-only checkout and AG Grid focus behavior.

RepairLoop is a Sandbox prototype today. Its strongest idea is simple: AI reads the mess, the catalog decides, and the system refuses when the evidence is not good enough.

Built With

Share this project:

Updates

Submission history