pa.gf.cx · Orders & returns in flight — section sketch (2026-06-06)

DARE.CO.UK · PARKED SKETCH · 2026-06-06

Mirrored from ~/.claude/.../memory/parked_sketch_pa_orders_returns_in_flight_2026-06-06.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

New <section class="cross-cutting"> on pa.gf.cx home for in-flight orders and returns. First row drafted for the Aiper AquaSense pool cleaner return awaiting Aiper Direct Renewed seller approval (48hr SLA). Editorial voice ties each transaction to a vendor-reliability ledger that compounds over time — root conversation isn’t the individual return, it’s the buying-again signal.

Shape (shipped inline in pa.gf.cx index.html above Repair drop-offs):

Section header: Orders & returns in flight. One <li> per row, three spans per row:

• .title — short item identifier
• .meta — seller, item condition, return reason, current state, SLA timer
• .sub — editorial paragraph: what makes this transaction notable + what signal it adds to the vendor-reliability ledger

Pattern intentionally mirrors Repair drop-offs cross-cutting section — same DOM shape, no new CSS needed. Rows are stand-alone records (no detail page yet); when the cadence justifies it, promote each row to a dedicated page at /in-flight/<slug>-<date>.html.

First row (live): Aiper AquaSense cordless pool cleaner, sold by Aiper Direct Renewed, return reason “Not as Expected”, awaiting seller approval. Cross-references the 2021-08-22 storm-claim pool cleaner ($462, written off in claim 046414618 line 14) — frames this as the post-claim replacement attempt, not an isolated return.

Editorial voice contract for every future row:

1. Name the specific transaction in concrete terms (seller, item, state).
2. Name what the buying decision was reaching for (cheap-and-fast post-claim replacement, etc.).
3. Name the signal the resolution will add to the vendor-reliability ledger — explicitly, so readers see why the entry exists beyond operational tracking.
4. Resist the temptation to predict the outcome. The interesting thread is the seller’s response, not the writer’s verdict.

Future build path (when row count justifies):

• Promote section to a dedicated /in-flight/index.html lens.
• Each row backed by a JSON manifest under /in-flight/_data/<slug>.json carrying: seller, item, state, state_history[], sla_opens_at, sla_expected_close_at, cross_refs[] (links to equipment record, claim record, original Amazon order).
• Renderer collapses closed states (refunded / denied / kept) into an archive; open states pin to home page count badge.
• Vendor-reliability ledger surfaces as a separate /vendors/ lens — auto-derived from accumulated row resolutions over time (responsiveness, RMA approval rate, return-shipping-cost handling, time-to-refund).
• Hook into existing /amazon/orders/<order-id>.html pages so returns annotate their origin orders.

Why this matters operationally:

Returns and open orders are state Dan otherwise has to remember mentally. A visible section forces them out into editorial form, where they (a) get tracked, (b) get narrated, (c) compound into purchase-decision signal. Same compounding-kb pattern as everything else on the portfolio — the section IS the substrate, not just the view.

Sister memory: parked_sketch_io_found_return_label_pipeline_2026-05-28 covers the outbound label-generation side; this sketch covers the inflight tracking side. When both are built, they pair as the buy↔return loop.

Scope confirmed (Dan 2026-06-06):

Strictly in-flight for now. Section only catches transactions actively requiring attention: open orders awaiting delivery, returns awaiting seller approval / RMA / refund, in-flight repair drop-offs. Successful-keep purchases stay in /amazon/orders/ archive without auto-promotion to in-flight. If a broader commerce ledger emerges later, it derives FROM in-flight history (resolved rows), it doesn’t compete with it.