Product roadmap

BoltToCart is a purpose-built SaaS platform for fabric retailers that unifies yard-based inventory, cut-counter POS, e-commerce, limited drops, events & ticketing, influencer commerce, quilt design, and guided project shopping into one rea…

The platform must let stores "sell fabric the way customers actually buy it ??? by project, pattern, class, and creator ??? not just by the yard."

Every channel (POS, online, drops, events) reads from and writes to a single inventory source of truth.

Store Owner ??? configures the store, plans drops and classes, reviews analytics, manages billing.

Manager ??? supervises staff, approves adjustments, runs cycle counts, manages purchase orders.

Cashier / Cutter ??? cuts fabric, rings up sales at the POS, prints receipts.

Fulfillment Staff ??? picks, cuts, packs, and ships online orders.

Instructor ??? runs classes, checks students in, requests supply lists.

Customer ??? browses, shops, registers for events, follows drops, uses the guided project wizard.

Influencer / Affiliate ??? earns commission via referral links, discount codes, and attributed sessions.

Platform Operator (BoltToCart staff) ??? onboards stores, handles support, manages platform-wide configuration.

Yard / WOF ??? the primary cut unit. "Width of Fabric" is the usable bolt width, typically 42???44" for quilting cotton.

Bolt ??? a physical roll of fabric with a unique ID, linked to a SKU, with a tracked remaining yardage.

Cut ??? an action that removes yardage from a bolt and creates an order line item or adjustment record.

Remnant ??? the residual length on a bolt below a configurable threshold (e.g., ??? 1 yd), typically marked down.

Precut ??? a pre-packaged piece sold by unit rather than by yardage: fat quarter (~18"??22"), fat eighth (~9"??22"), charm pack (5" squares), jelly roll (2.5" strips), layer cake (10" squares), mini charm, honey bun.

Bundle / Kit ??? a curated grouping of fabrics and/or notions sold together, optionally tied to a pattern or class.

Colorway ??? a specific color variant of a print within a collection.

Collection ??? a named group of fabrics released together by a designer/manufacturer.

Repeat ??? the distance over which a pattern repeats, relevant to yardage calculation for large prints.

Drop ??? a scheduled, time-bounded release of limited-inventory products.

Cut-to-order ??? the workflow by which online orders are fulfilled by cutting from a bolt at the store.

A SKU represents an idealized product (a specific colorway + collection + unit-of-sale). A Bolt is a physical instance of a cut-by-the-yard SKU; a Precut is a physical instance of a unit-of-sale SKU.

The system must preserve referential integrity from Cut ??? Bolt ??? SKU ??? Collection ??? Designer so reporting and attribution can roll up at any level.

Offer three setup modes on first launch: Start Fresh, Import Inventory, Full Inventory Setup.

Configure store profile (name, timezone, currency, tax jurisdictions, fulfillment regions, default units).

Configure default categories, attributes, and pricing rules.

Generate SKUs and printable bolt labels from imported data.

Go live immediately once minimum profile and at least one payout destination are configured.

Clean Start ??? empty catalog, bolts created via receiving workflow.

Bulk Import + Progressive Accuracy ??? CSV/XLSX import of SKUs and estimated yardage; accuracy improves as bolts are scanned, cut, and reconciled.

Full Inventory Scan ??? guided physical count that creates bolt records as each is scanned and measured.

Inventory accuracy must improve over time via sales, adjustments, and cycle counts.

Workflow: scan to identify ??? enter yardage manually ??? reconcile.

The system must surface inventory confidence (e.g., "last reconciled N days ago, drift �X%") at bolt, SKU, and store level.

BoltToCart must provide a guided incumbent-POS migration path for fabric retailers moving from systems such as Rain POS, covering catalog/products, inventory quantities and history, customers, sales history, loyalty/reward balances, gift c…

The migration path must support four intake modes: self-service upload of CSV/XLSX files, self-service upload of a ZIP containing multiple exports, concierge/operator upload on behalf of a tenant, and credentialed source-system API pull wh…

Rain POS must be supported as a named migration profile. The profile must include documented mappings for Rain product bulk export files, customer list exports, sales/transaction report exports, inventory history exports, and loyalty/rewar…

Every migration run must create an import batch with: tenantId, source system, source account/store identifier when available, source export timestamp, uploaded file manifest, file checksums, requested-by actor, run mode (dry_run, trial, f…

Imports must be idempotent and re-runnable. Re-uploading the same source file or re-running an API extraction must not create duplicate SKUs, bolts, customers, orders, loyalty ledger entries, gift cards, or store-credit balances. Source id…

Before mutating production tenant data, the migration workflow must run a preflight analyzer that reports row counts, unmapped columns, duplicate SKUs, duplicate customers, malformed emails/phones, invalid prices, unsupported tax/tender/st…

The preflight analyzer must classify findings as blocking, warning, or informational. Blocking findings prevent final import; warnings may be explicitly accepted by an authorized manager; informational findings remain visible in the import…

The importer must provide a field-mapping UI for unknown or tenant-specific columns, including reusable mapping presets by source system and tenant. Mappings must be versioned with the import batch so a future rerun uses the same interpret…

The migration workflow must support a trial import into a sandbox/demo tenant, allowing the merchant and BoltToCart operator to inspect catalog, customers, rewards, sales reports, and inventory confidence before approving a production impo…

The final production cutover must support a delta import window. After the merchant performs a final incumbent-system export, BoltToCart must import only new or changed source records since the trial baseline where source identifiers or ti…

Product imports must map source product records into BoltToCart SKUs and product types per REQ-CAT-001 through REQ-CAT-011, including SKU code, barcode/UPC, name, description, vendor/supplier, designer, collection, department/category, col…

Product import must never use floating-point math for money or yardage. Prices and costs are converted to integer minor units; yardage is converted to fixed-point 1/16-yard units per REQ-INV-001, with original source values retained for au…

When a source system provides only SKU-level on-hand quantity instead of physical bolt-level inventory, BoltToCart must create legacy opening-stock bolt records or equivalent receiving records with lower inventory-confidence metadata. Thes…

Inventory history imports must map source adjustments, receiving events, shrinkage, transfers, and manual corrections into auditable inventory events where source detail supports it. If historical detail is insufficient to reconstruct exac…

After product/inventory import, BoltToCart must generate a migration label run for newly created or legacy bolt records, including printable bolt labels per REQ-INV-050 and a reconciliation worksheet grouped by location/category for store-…

Customer imports must create unified customer profiles per REQ-CRM-001, keyed by email and/or phone where present, with merge-review tooling for duplicate or near-duplicate records. The importer must preserve source customer IDs and must n…

Customer imports must support source fields commonly needed for quilt/fabric retail: name, email, phone, mailing address, marketing opt-in state, tax-exempt flag, customer group, notes, birthday/month where legally usable, created date, la…

Sales-history imports must create legacy orders and order line items where source transaction detail is available, preserving source transaction ID, receipt/order number, channel/register, cashier/staff identifier where available, timestam…

If line-level sales history is unavailable or incomplete, BoltToCart must support importing customer-level purchase summaries and monthly store totals so CRM segmentation, retention cohorts, and onboarding reconciliation can still function…

Imported historical orders must be marked as legacy/imported and must not trigger fulfillment, inventory deduction, loyalty accrual, gift-card issuance, email receipts, webhooks, or customer notifications unless the import mode explicitly…

Loyalty/reward migration must import the current customer balance as an opening-balance ledger entry per REQ-CRM-003, not as a recalculated earn stream by default. Recalculation from historical transactions may be offered only as a separat…

Loyalty imports must support mapping source reward programs into BoltToCart earn/redemption settings, tiers, customer balance, lifetime points/spend where available, pending rewards, expiration dates where legally applicable, and manual ad…

Gift card and store-credit imports must require explicit merchant attestation or reconciliation approval before activation. Imported balances must preserve source identifiers, original balance, remaining balance, issue date where available…

No stored payment-card data, PAN, CVV, magstripe/chip data, or raw payment tokens may be imported from an incumbent POS. Customers must re-enter payment methods through Stripe-hosted or otherwise PCI-compliant flows per REQ-SEC-010.

The migration workflow must provide reconciliation reports comparing source exports to imported BoltToCart data by entity and period: SKU count, active/inactive product count, on-hand quantity, inventory value, customer count, loyalty bala…

Reconciliation reports must be exportable as CSV and retained with the import batch. The merchant must explicitly approve final reconciliation before production cutover is marked complete.

All imported PII must follow REQ-ANL-003, REQ-SEC-021, and REQ-CRM-005: no unnecessary PII in analytics events, retention policies apply by data class, and customer export/deletion requests must include imported source data and source-refe…

Import jobs must emit typed domain events through the outbox and product events through the telemetry wrapper per REQ-ANL-001, REQ-ANL-002, REQ-ANL-010, and REQ-JOB-506. Events must include batch-level counts and status, but must not inclu…

The store-owner dashboard must include a migration status tile during onboarding and for at least 30 days after cutover, showing current phase, last batch status, unresolved blocking findings, reconciliation approval state, inventory-confi…

Platform operators must have an operator-only migration console for monitoring tenant migration batches, retrying failed jobs, downloading sanitized error reports, and recording concierge notes. The console must not allow cross-tenant data…

The migration system must provide a rollback preview before production finalization, listing which imported entities could be deleted, disabled, or left as historical records. Rollback behavior must preserve audit history and must never si…

The migration checklist for Rain POS must be visible to merchants and operators and must list the expected source exports, recommended date ranges, export timing for trial and final cutover, known limitations, and the exact BoltToCart dest…

Minimum: iPad or tablet, receipt printer.

Recommended: Bluetooth barcode scanner, thermal label printer, cash drawer.

See �23 for the full hardware ecosystem and protocol requirements.

Every fabric SKU must capture: name, SKU code, designer, collection, colorway, fiber content (composition %), width (inches), weight (GSM or oz/yd�), pattern type (solid, print, batik, etc.), print scale, repeat (inches), care instructions…

Every SKU must capture one or more dominant colors (hex values) and color tags (e.g., "sage", "navy") for faceted and color search.

Every SKU must support multiple images with roles: hero, swatch, bolt-end, lifestyle, repeat preview.

Every SKU must declare its unit of sale: by_yard, by_precut, by_unit, or by_kit.

Variants are permitted for differences in colorway, size (for precuts), or packaging.

The catalog must support notions (thread, batting, needles, tools), patterns (physical + digital), books, and gift cards with appropriate attribute schemas.

Digital goods (pattern PDFs) must support license-bound downloads with per-order expiry and rate-limited access.

Images must be processed through a media pipeline that generates standard derivatives (thumbnail, card, swatch, zoom) and extracts dominant colors on upload (see �27).

Every image must carry or generate alt text.

The MVP catalog media pipeline must let admins attach, order, replace, and remove per-SKU images with roles for hero, swatch, bolt-end/detail, and lifestyle. Each image must store alt text, source, dimensions, content hash, and derivative…

The MVP catalog schema and admin UI must capture structured fabric composition and merchandising metadata needed by REQ-CAT-001: composition percentages, pattern type, print scale, repeat, care instructions, country of origin, and hazard/c…

BoltToCart must maintain a platform-owned shared product library of known fabric-retail products that can be searched and used by every tenant during receiving, purchase-order creation, manual SKU creation, incumbent POS migration, and ful…

Shared product-library records must be global reference records, not tenant catalog records. Creating or receiving inventory from a library match must create or update a tenant-owned SKU, bolt, precut, or unit item that references the libr…

Each shared product-library record must store durable external identifiers where available: source system, source product URL, source product ID, manufacturer item number, vendor SKU, UPC, EAN/GTIN, collection code, color code, variant cod…

Shared product-library fabric records must support the same structured fabric attributes as tenant SKUs per REQ-CAT-001 through REQ-CAT-005, including name, description, designer, collection, colorway, vendor/manufacturer, fiber content, w…

Shared product-library non-fabric records must support notion, thread, batting, needle, tool, pattern, book, kit, home-gift, and precut metadata per REQ-CAT-010 and REQ-CAT-011, including product type, size, dimensions, pack quantity, mate…

Every shared product-library record must store commercial reference fields separately from tenant prices: MSRP in integer minor units, MSRP currency, wholesale/list cost when legally available, minimum advertised price when available, unit…

MSRP and cost fields in the shared product library are reference data only. Tenant storefront, POS, discount, margin, and tax calculations must use tenant-owned pricing records and must never silently update tenant sell prices when a sourc…

Shared product-library images must preserve source provenance, original URL, content hash, dimensions, license/usage status, fetch timestamp, alt text, and image role. Images approved for tenant use must flow through the standard media pip…

The library must retain source raw snapshots and normalized records separately. Raw snapshots must be immutable audit evidence with content hash, fetch time, HTTP status, source account context, parser version, and extraction warnings; nor…

Shared product-library records must support source-confidence scoring by field. Each normalized field must track whether it came from source markup, page text, structured data, image analysis, operator edit, tenant feedback, or automated i…

Product-library deduplication must merge records that represent the same physical product across sources such as Moda/United Notions, EE Schenck, Checker Distributors, and Brewer Quilting & Sewing Supplies. The merge process must preserve…

Product-library matching during inventory intake must support barcode scan, UPC entry, manufacturer SKU entry, PO line import, supplier invoice import, image-assisted search, and text search across name, collection, designer, vendor, color…

Store owners must be able to accept a product-library match into their catalog with a one-step default path and an advanced edit path. The default path must prefill safe fields, preserve tenant defaults for category/pricing/tax/publish sta…

Store owners must be able to override library-derived fields on their tenant SKU without changing the shared library. The UI must clearly distinguish platform reference data from tenant overrides and must provide a reset-to-library action…

Tenant SKUs linked to a shared product-library record must receive update suggestions when source data changes materially. Suggestions must summarize changed fields, source, old value, new value, confidence, and storefront impact; applying…

The shared library must expose operator review states: candidate, normalized, needs_review, approved, rejected, merged, deprecated, and blocked. Only approved records may be offered as default auto-fill candidates to store owners, while lo…

Product-library records must support category taxonomy mapping between source categories and BoltToCart product types. For Moda's fabric source, the initial mapping must include category, availability, vendor, author, Moda designer, produc…

The first source connector must target https://shop.modafabrics.com and capture as much product metadata as available from category and product pages, including product name, description, image URLs, MSRP, UPC, SKU/item number, category pa…

The Moda connector must support incremental discovery from category pages such as /category/fabrics-101495, product detail pages such as /product/1867.68258, pagination or infinite-scroll result sets, faceted filters, product count changes…

The shared product library must represent product families, variants, and purchasable items separately when a source exposes them separately. A collection or product group may contain fabric colorways, precuts, kits, patterns, books, and n…

The library must preserve historical availability and lifecycle changes. When a source changes a product from in stock to on order, out of stock, ships from vendor, discontinued, last call, future group, or similar status, the new state mu…

Library data must never be treated as authoritative inventory for a tenant. Source availability may inform ordering and intake suggestions, but tenant on-hand inventory, sellable quantity, holds, and fulfillment decisions must continue to…

Product-library search APIs must be read-only for tenant users except for explicit feedback endpoints. Tenant feedback may propose corrections, missing UPCs, better images, duplicate reports, or source conflicts, but must enter an operator…

Shared product-library APIs must support stable, typed contracts for admin UI, POS receiving, web receiving, migration, and jobs. Contracts must include branded IDs for library record, source record, tenant SKU, source connector run, and m…

Library metadata that is source-specific but not yet modeled must be stored in a typed extension structure keyed by source and parser version. Extension fields must preserve original labels and values for audit while promoting frequently u…

The shared product library must include a public-support-safe product evidence view that operators can copy into tickets. Evidence must include library ID, source name, source URL, last fetch time, approved field summary, and confidence st…

Yardage must be tracked as fractional values with minimum granularity of ??? yard (0.125) and stored with sufficient precision to avoid cumulative rounding error (recommended: store in millimeters or fixed-point 1/16 yard).

Each physical bolt has a unique ID, associated SKU, initial yardage, current remaining yardage, location (store + shelf), and status (receiving, on_shelf, cut_in_progress, remnant, sold_out, damaged, transferred).

The system must enforce non-negative remaining yardage and prevent concurrent over-cutting via row-level locking or equivalent serialization.

Adjustments, shrinkage, transfers between locations, and damage events must all be auditable with actor, reason, quantity delta, and timestamp.

When remaining yardage falls at or below a configurable threshold (default 1 yard), the bolt must automatically flag as a remnant and optionally reprice per the markdown rule.

A bolt may be split (e.g., to create precuts from the bolt-end) or two identical-SKU bolts merged administratively. Both operations must preserve audit history.

Supplier records must capture contact info, lead times, payment terms, minimum order quantity, and preferred shipping methods.

Purchase orders (POs) must support draft, submitted, partially received, received, and closed states, with line items mapped to SKUs and expected quantities.

The receiving workflow is the primary entry point for creating bolts: scan PO ??? confirm SKU ??? enter actual yardage ??? generate bolt ID and printable label.

Landed cost (unit cost + freight + duty allocation) must be captured per receiving line to drive margin reporting.

Advance Ship Notices (ASNs) should be importable where suppliers support them.

The system must support partial and full cycle counts with variance reporting and bulk adjustment approval.

Discrepancies must produce audit records and feed into the inventory-confidence score per �4.3.

When fulfilling a cut-to-order line with multiple candidate bolts, the system must choose the bolt according to a configurable rule. Default: largest-remnant-first (cut from the smallest bolt that satisfies the order) to consolidate invent…

Alternative rules must include FIFO (oldest first), LIFO, and manual selection.

If no single bolt can satisfy the request, the system must either split the order across bolts (with customer opt-in for quilting-grade continuity) or decline and suggest substitutes.

Each bolt label must carry a scannable 1D or 2D barcode encoding the bolt ID, plus a human-readable SKU, designer, collection, width, and initial yardage.

Labels must be reprintable on demand and support at least two standard thermal label sizes.

Receiving, full-inventory scan, and purchase-order workflows must offer shared product-library lookup before manual SKU creation. If a scanned or entered UPC matches a library record, the workflow must prefill product metadata and continue…

Purchase-order and receiving lines created from a shared product-library record must retain both the tenant SKU ID and the library record ID. The receiving audit must show which fields were prefilled from the library, which fields were edi…

Support per-yard pricing, per-unit pricing (precuts, notions), and per-kit pricing.

Support volume breaks (e.g., 10% off at ??? 5 yards), customer-group pricing (retail, trade/wholesale, guild), and tax-exempt customer flags.

Support markdowns, automatic remnant discounts, BOGO, percentage/fixed coupons, free-shipping promotions, and stackable/exclusive rules with a deterministic resolution order. Detailed mechanics for coupons and promotions are specified in �…

Support gift cards and store credit with balance tracking, expiry policies per jurisdiction, and redemption across all channels. Gift cards are a stored-value instrument, not a coupon, and are governed by separate tender rules (see �8.1) a…

Every price applied to a cart must be traceable to the rule(s) that produced it for audit and dispute resolution. The trace must enumerate each applied discount, its couponId/promotionId, eligibility match reason, stacking decision, and pe…

Support the following discount mechanics as first-class primitives:

Distinguish automatic promotions (no code required; applied whenever eligibility matches) from coupons (require a code or a customer-attached entitlement). Both share the same eligibility, stacking, and reporting model.

Support pricing lists that override base price for a customer group, location, or channel; pricing-list prices are applied before any promotion and count as the "original price" for subsequent discount math.

Support the following coupon code archetypes, each with the same underlying discount mechanic (�7.2) but different issuance and redemption semantics:

Code generation requirements:

Bulk operations ??? campaigns must support bulk create, bulk pause, bulk revoke, and bulk extend with a dry-run preview of affected codes and an undo window (5 minutes) before changes are committed to the redemption ledger.

Support scannable coupon artifacts ??? QR and 1D barcodes encoding the code plus an HMAC so scanned codes at POS can be validated offline against a cached active-campaign set (see �7.7).

Every coupon/promotion must support the following eligibility dimensions, combinable with AND/OR logic:

Support exclusions with clear precedence over inclusions: clearance/sale flag, gift cards, specific SKUs or collections, already-discounted lines, shipping, tax, specific channels (e.g., exclude from drops). Exclusions must be evaluated be…

Support usage limits, each independently configurable:

Eligibility evaluation must be deterministic and side-effect-free: the same cart + coupon + context always yields the same decision and the same rationale string, which is persisted on the order for audit.

Every coupon and automatic promotion carries a stackability flag: exclusive (default), stackable-with-auto, stackable-with-any. Two exclusive instruments cannot apply to the same order.

The resolution order for a cart is fixed and documented:

Support a maximum discount cap per order, per line, and per campaign (absolute or percentage) to prevent runaway stacking.

Every resolution decision ??? including rejected codes and the reason for rejection ??? must be written to the order's pricing trace per REQ-PRI-005 and to the coupon redemption ledger per REQ-PRI-055.

Coupon validation must happen at three points: on code entry in the cart, on checkout submission, and on payment authorization. The canonical decision is the checkout-time evaluation; cart-time previews are advisory and must be re-checked…

Code application must be idempotent: submitting the same code twice in the same cart session is a no-op, not an error. Reapplying after removal is permitted subject to usage limits.

Validation responses must not leak information that aids enumeration: a single opaque invalid_or_ineligible response for unknown, expired, exhausted, paused, and not-yet-active codes. Internally, the specific reason is logged with the stan…

Use constant-time string comparison for code matching to eliminate timing oracles.

Apply rate limits and progressive friction to code entry:

Redemption ledger ??? every successful redemption creates an immutable record of: couponId, campaignId, orderId, customerId, channel, storeId/deviceId if POS, discount mechanic, amount applied, per-line allocation, attributed influencer if…

Reversal on refund/return ??? partial and full refunds must reverse the proportional discount per REQ-PRI-080 and decrement the redemption count only if the return fully voids the order and the campaign's policy permits (default: yes). Rev…

Self-referral / self-redemption guards ??? a customer cannot redeem their own referral or influencer code on their primary account; flagged attempts are rejected with the generic response and logged for review.

Kill switch ??? a campaign can be paused or revoked by an authorized operator in under 30 seconds via the admin UI without a deploy; in-flight redemptions committed before the pause timestamp remain valid, and a reason code is required and…

Web storefront ??? code entry at the cart and checkout; auto-apply via signed URL parameter with a short TTL; customer-attached entitlements appear as one-tap apply on the cart for authenticated customers.

POS ??? the POS must support (a) manual keypad code entry, (b) barcode/QR scan of a coupon artifact (REQ-PRI-023), and (c) selecting a customer-attached entitlement from the looked-up customer profile. Manager PIN (REQ-POS-031) is required…

Offline POS ??? only codes from the cached active-campaign set (shared public codes with no per-customer limits and no cross-channel cap) may be honored offline. Single-use unique codes, influencer codes, first-time-customer codes, and any…

Drops ??? by default, drops are coupon-excluded (REQ-PRI-031). A drop may opt in to accept specific campaigns, but codes MUST NOT influence queue position, waitlist order, or inventory holds (REQ-DRP-002/REQ-DRP-003).

Events & ticketing ??? promo codes apply to tickets per REQ-EVT-013; bundled kits attached to a ticket follow the kit's eligibility, not the ticket's.

Guided project wizard ??? codes may be applied at the review step; the wizard must show the pre- and post-discount totals and make the applied code removable.

Every coupon has a lifecycle state: draft ??? scheduled ??? active ??? (paused ??? active) ??? exhausted | expired | revoked ??? archived. State transitions are recorded with actor, timestamp, and reason.

Automatic transitions ??? scheduled ??? active at startAt, active ??? expired at endAt, active ??? exhausted on cap reached. Transitions are driven by background jobs (�29 "Background jobs") with guaranteed-once emission of the correspondi…

Manual admin actions ??? pause, resume, revoke (terminal), clone (new draft pre-filled), extend (moves endAt), adjust cap (only upward without a re-approval workflow).

Approvals ??? configurable approval workflow for high-impact campaigns (discount > N%, cap > M redemptions, site-wide scope); required approvers, dual-control for irreversible revokes.

Retention & archival ??? archived campaigns remain queryable for reporting and dispute resolution per the data retention policy in �25.3; the redemption ledger is retained for the full financial-records retention period regardless of campa…

Per-line allocation ??? order-level and cart-level discounts must be pro-rated across eligible lines by that line's eligible base price, using banker's rounding with residuals distributed to the highest-priced line. Per-line allocation is…

Tax treatment ??? support both pre-tax (default, US) and post-tax (some international regimes) discount application, selected per jurisdiction by the tax engine (REQ-ARC-026). Free-shipping discounts interact with shipping tax per the dest…

Refunds ??? when a line is refunded, the proportional discount allocated to that line is reversed and tax is recomputed on the reduced taxable base per REQ-FUL-006. Reversals never produce negative discount totals.

Merchant cost-of-promotion ledger ??? every redemption records GMV foregone (list price ??? sold price), margin impact (using landed cost from REQ-INV-023), and attribution to campaign and, if applicable, influencer. This feeds the coupon…

Coupon performance report (per-tenant, scoped per �22) must surface: redemptions, redemption rate, GMV lifted, revenue after discount, average discount per order, new-customer share, top SKUs redeemed against, and ROI vs. cost-of-promotion…

Funnel events per REQ-ANL-011 ??? code-entered, code-rejected (with opaque reason class), code-applied, checkout-completed-with-code. These feed the product-analytics sink, not the domain warehouse.

Influencer reports consume the same redemption ledger and are specified in REQ-RPT-004.

Emit typed domain events conforming to �26.1: coupon.created, coupon.activated, coupon.paused, coupon.revoked, coupon.redeemed, coupon.redemption_reversed, coupon.exhausted, coupon.expired. Payloads are declared in packages/events per REQ-…

Influencer-attributed codes share the coupon machinery; attribution and payout are governed by �14, and commission is settled through the commission ledger (REQ-INF-030) rather than by double-discounting the order.

Event-ticket promo codes are governed by �12.2 (REQ-EVT-013) and use the same engine described here.

Workflow: scan fabric ??? enter yardage ??? add to cart ??? checkout.

Must support fractional yardage entry (�6.1) with both decimal and fractional keypads (e.g., 2 ???).

Must support fast text and visual search across SKUs, collections, and designers, with keyboard and barcode input.

Must support mid-transaction cart edits, held carts, and parked orders.

Must support split tender (card + cash + store credit + gift card) and partial refunds.

Receipts must be available as printed (ESC/POS) and digital (email/SMS).

End-of-day reconciliation must produce a cash-drawer report and a shift summary.

A dedicated iPad POS application is required ??? browser-only is insufficient. Chosen platform: React Native + Expo with Expo Modules for native integrations and EAS Build for distribution. Rationale: single TypeScript stack shared with th…

The app must achieve sub-second response for the critical path: scan ??? add line ??? total ??? tender ??? receipt.

The app must operate fully offline for at least 8 continuous hours of normal register activity, with local transaction durability across app restarts and device reboots.

The app must sync background transactions to the server as connectivity permits, with conflict resolution per �17.

The app must integrate with Bluetooth barcode scanners (HID mode), ESC/POS thermal receipt printers, and electronic cash drawers (RJ-11 kick via receipt printer).

The app must support tap-to-pay card acceptance via a certified payments SDK (Stripe Terminal, including Tap to Pay on iPhone/iPad), with PIN and signature flows where required.

A shared core library (pricing, validation, tax calc preview, API client, typed domain models) must be published as a package consumable by both the Next.js web app and the Expo POS app to prevent rule drift between channels.

POS label-printer status projection (apps/pos/src/components/LabelPrinterStatus.ts). Pure UI-runtime-free helper for the existing LabelPrintResult and bolt-label print context that maps ready, not-ready, printing, printed, and failed label…

The overnight POS register path must be guarded by the pos.register-session feature flag and must expose a disabled state that blocks sale completion without mutating the cart, tender state, hardware, or sync queue.

The register path must derive its cashier-facing phase from the existing critical-path reducer and tender reducer: ready to scan, enter yardage, review cart, take payment, finalize sale, or blocked.

The register path must surface deterministic blockers before finalization, including empty cart, non-complete tender, disabled feature flag, and offline queue failure, without relying on native UI alerts.

Sale completion must enqueue a restart-durable offline mutation before printing a receipt or opening the cash drawer, so a completed tender is never lost because of hardware failure.

Queued POS sale mutations must be JSON-serializable without bigint loss by storing minor-unit money and yardage sixteenths as base-10 strings.

Each queued sale mutation must carry an idempotency key scoped by tenant, device, sale id, and occurrence timestamp so reconnect sync can safely retry.

The queued sale mutation must include only the minimum non-PII register payload: tenant id, device id, optional cashier user id, cart line snapshots, totals, tender method, tender amounts, receipt intent, and source requirement ids.

Receipt printing must use the POS hardware adapter only, must produce a deterministic ESC/POS-ready print request, and must not block sale durability once the queue write succeeds.

Cash-drawer opens after cash tender must use the sale-open reason with the queued sale id; card and store-credit tenders must not open the drawer.

Hardware failures during receipt print or cash-drawer open must return a cashier-safe warning while preserving the queued sale mutation for sync.

The register path must emit typed span-intent metadata for pos.tender and pos.receipt so the Expo runtime can bridge it to the telemetry wrapper without importing vendor SDKs.

The register readiness model must include sync queue status, pending mutation count, connectivity state, and a cashier-safe sync label for offline operation.

The register readiness model must include hardware status for scanner, receipt printer, cash drawer, and payment terminal without assuming any specific vendor model is present.

The register path must expose a compact dashboard-tile model showing register phase, pending offline sales, and blocking status for REQ-ANL-042.

The POS package root must export the register-session contract so future Expo screens consume a stable public API instead of private flow files.

Completed POS sales must sync through an authenticated server API that validates a JSON-safe sale payload, derives tenant identity from the Clerk organization, uses the POS sale UUID as the idempotent order id, and returns accepted or dupl…

POS sale sync must apply inventory authoritatively on the server by requiring a physical boltId for every fabric line, validating the bolt/SKU relationship under RLS, and decrementing remaining yardage through the atomic cut primitive in t…

The Expo POS web workbench must expose an offline sync-recovery panel that classifies queued, syncing, and failed sale mutations, shows pending value, age, retry state, and cashier-safe recovery guidance, and enables flush/retry actions on…

The Expo POS web workbench must expose a unified sales journal that combines durable queued sales and synced receipt previews into one audit surface with tender labels, total labels, receipt/refund affordance state, and failed-sale review…

The Expo POS web workbench must expose an inventory exception panel derived from local bolt reservations and queued sales, flagging low remaining yardage, unknown bolts, and over-reserved bolts before tender so cashiers do not unknowingly…

The Expo POS web workbench must expose a tender closeout audit panel that summarizes current staged tender legs, shift expected cash, and closeout variance without using floating-point money math.

The Expo POS web workbench must expose a staff handoff summary that combines register readiness, offline queue state, held carts, receipts, and completed refunds into a concise transfer checklist for the next cashier.

The Expo POS web workbench must expose a register command center that combines cart state, tender readiness, release readiness, offline queue state, and idle lock state into ranked cashier actions for scan, tender, queue, sync, and recover…

The Expo POS web workbench must expose an offline session durability panel that scores authenticated session continuity, network mode, offline queue health, held carts, and latest local snapshot freshness before the cashier continues offli…

The Expo POS web workbench must expose a receipt issue queue that combines receipt print state, staged digital delivery jobs, and receipt reprint audit upload state so staff can recover customer receipt failures before closeout.

The Expo POS web workbench must expose customer checkout readiness that summarizes attached customer state, store-credit availability, loyalty projection, and receipt-contact readiness before tender completion.

The Expo POS web workbench must expose a manager exception board that summarizes refunds, price overrides, line-void targets, no-sale drawer opens, and held carts so exception-heavy shifts can be reviewed before closeout or handoff.

The Expo POS web workbench must expose a shift launch checklist that combines cashier auth, device registration, timeclock, opening float, hardware readiness, and offline queue state before a cashier starts selling.

The Expo POS web workbench must expose scan reliability status that combines scanner adapter readiness, active/cancelled read state, timeout outcome, last scan result, and dispatch diagnostics so staff can recover barcode entry issues quic…

The Expo POS web workbench must expose tender settlement readiness that combines staged tender lines, remaining/change due, card terminal readiness, and offline queue blockers before a sale is queued.

The Expo POS web workbench must expose customer display handoff readiness that combines customer-display adapter state, display payload totals, preview push count, attached customer context, and receipt contact state before checkout comple…

The Expo POS web workbench must expose a closeout risk board that rolls up tender closeout, offline durability, receipt issue queue, and manager exception state into a final closeout decision.

The Expo POS web workbench must expose a lane throughput board that combines active cart lines, held carts, offline queue pressure, synced receipts, busy state, and idle lock state into a cashier lane-capacity decision.

The Expo POS web workbench must expose a cash control board that combines opening float, expected drawer cash, counted cash, closeout variance, no-sale drawer opens, and queued-sale blockers before shift close.

The Expo POS web workbench must expose a customer recovery board that combines transaction lookup, refund flow, receipt issue queue, selected customer state, and completed refund count for post-sale service recovery.

The Expo POS web workbench must expose an inventory service board that combines inventory reservation exceptions, cycle-count state, label-printer state, scale state, and offline queue pressure before cutting or printing labels.

The Expo POS web workbench must expose a loyalty and stored-value board that combines selected customer, loyalty projection, store-credit suggestion, gift-card lookup, coupon state, and remaining tender amount before payment.

The Expo POS web workbench must expose a peripheral operations board that combines required hardware health, optional peripheral readiness, printer adapter state, label-printer state, NFC readiness, scale readiness, and display readiness.

The Expo POS web workbench must expose a training and demo readiness board that combines training-sale draft availability, demo catalog coverage, cashier authentication, device registration, and offline queue cleanliness before staff pract…

The Expo POS web workbench must expose a receipt fulfillment board that combines receipt print state, receipt QR state, receipt delivery readiness, receipt issue queue state, reprint audit queue state, latest synced receipts, and printer r…

The Expo POS web workbench must expose an offline recovery command board that combines connectivity state, offline queue pressure, active flush state, sync recovery state, offline durability state, and held-cart count before staff attempt…

The Expo POS web workbench must expose a device operations board that combines device registration state, API runtime configuration, authenticated org context, Stripe reader mapping, hardware health, and connectivity state before a lane op…

The Expo POS web workbench must expose a security controls board that combines cashier authentication, idle-lock state, manager exception state, price override state, drawer open audit count, and line-void target state before sensitive act…

The Expo POS web workbench must expose a promotion and pricing board that combines coupon state, discount scan state, active price override state, applied discount amount, manager exception state, and remaining tender amount before checkou…

The Expo POS web workbench must expose a post-sale audit board that combines sales journal state, synced receipt count, completed refund count, receipt reprint audit state, no-sale drawer open count, and failed queue count before closeout.

The Expo POS web workbench must expose a continuity snapshot board that combines saved snapshot state, held-cart count, active cart line count, offline queue pressure, local event bus state, and completed receipt count for register restart…

The Expo POS web workbench must expose a cart integrity board that combines checkout readiness, cart total audit state, cart conflict state, inventory exception state, active cart line count, and remaining tender amount before checkout han…

The Expo POS web workbench must expose a tender method coverage board that combines available tender methods, selected tender method, card terminal readiness, drawer readiness, store-credit suggestion, gift-card lookup state, and staged ti…

The Expo POS web workbench must expose a queue performance board that combines offline queue summary, sync recovery state, flush state, sales journal state, connectivity, and local event backlog before staff start queue recovery.

The Expo POS web workbench must expose a cashier productivity board that combines cashier identity, timeclock state, active cart lines, synced receipts, completed refunds, held carts, and lane busy state for shift coaching.

The Expo POS web workbench must expose a customer engagement board that combines selected customer, customer checkout readiness, loyalty projection, receipt delivery readiness, customer display state, and coupon state before customer hando…

The Expo POS web workbench must expose an inventory cut readiness board that combines yardage rounding state, physical scale state, cycle-count state, inventory exception state, label printer readiness, and NFC readiness before fabric cutt…

The Expo POS web workbench must expose an end-of-day command board that combines end-of-day flow state, shift summary state, cash control state, tender closeout state, post-sale audit state, and closeout risk state before shift close.

The Expo POS web workbench must expose a checkout completion command board that combines cart integrity, tender settlement, tender method coverage, queue performance, receipt fulfillment, and hardware/peripheral readiness before the cashie…

The Expo POS web workbench must expose a sync command health board that combines connectivity, queue performance, offline recovery, device operations, continuity snapshot, and local event backlog before staff flush or retry offline sale wo…

The Expo POS web workbench must expose a register launch decision board that combines shift launch, device operations, security controls, peripheral operations, scan reliability, and training/demo readiness before a lane opens.

The Expo POS web workbench must expose a payment assurance board that combines promotion/pricing state, loyalty and stored value state, customer checkout state, tender settlement state, tender method coverage, and queue health before payme…

The Expo POS web workbench must expose a receipt recovery command board that combines receipt fulfillment, receipt issue queue, customer recovery, post-sale audit, printer readiness, and audit queue state before staff close a customer rece…

The Expo POS web workbench must expose an inventory assurance board that combines inventory service, inventory cut readiness, cart integrity, scan reliability, queue performance, and label/NFC readiness before inventory-affecting checkout…

The Expo POS web workbench must expose a customer service desk board that combines customer engagement, customer recovery, loyalty/stored value state, receipt fulfillment, transaction lookup state, and refund count for post-sale support.

The Expo POS web workbench must expose a manager closeout command board that combines end-of-day command, closeout risk, cash control, security controls, manager exception state, and queue performance before managers close the register.

The Expo POS web workbench must expose a critical path assurance board that combines scan reliability, cart integrity, checkout completion, payment assurance, lane throughput, and cashier productivity before staff decide the lane can proce…

The Expo POS web workbench must expose an offline selling decision board that combines sync command health, offline recovery, offline durability, queue performance, cart integrity, and inventory assurance before staff continue selling with…

The Expo POS web workbench must expose a hardware serviceability board that combines peripheral operations, device operations, receipt recovery, inventory assurance, scan reliability, and printer/terminal readiness before hardware-dependen…

The Expo POS web workbench must expose a staff accountability board that combines cashier productivity, security controls, manager exception state, register launch decision, customer service desk, and manager closeout before shift handoff…

The Expo POS web workbench must expose a closeout audit packet board that combines manager closeout, end-of-day command, receipt recovery, post-sale audit, cash control, and tender closeout before closeout records are treated as review-rea…

The Expo POS web workbench must expose a customer handoff command board that combines customer engagement, payment assurance, receipt recovery, customer display handoff, customer service desk, and receipt fulfillment before the customer le…

The Expo POS web workbench must expose a training mode control board that combines register launch decision, training/demo readiness, security controls, device operations, queue performance, and cashier productivity before staff practice t…

The Expo POS web workbench must expose a release blocker matrix board that combines critical path assurance, offline selling decision, hardware serviceability, staff accountability, closeout audit packet, customer handoff, training mode co…

The Expo POS web workbench must expose a sale floor go/no-go board that combines critical path assurance, offline selling decision, hardware serviceability, customer handoff, staff accountability, and release blocker matrix before floor le…

The Expo POS web workbench must expose a network outage playbook board that combines offline selling decision, sync command health, offline recovery command, queue performance, continuity snapshot, and cart integrity before staff operate t…

The Expo POS web workbench must expose a receipt counter recovery board that combines customer handoff, receipt recovery command, receipt fulfillment, customer service desk, post-sale audit, and printer readiness before staff dismiss recei…

The Expo POS web workbench must expose an inventory risk command board that combines inventory assurance, inventory service, inventory cut readiness, cart integrity, offline selling decision, and scan reliability before inventory-affecting…

The Expo POS web workbench must expose a cash room audit board that combines closeout audit packet, manager closeout, cash control, end-of-day command, tender closeout, and post-sale audit before cash records leave the register.

The Expo POS web workbench must expose a device fleet launch board that combines hardware serviceability, device operations, peripheral operations, register launch decision, training mode control, and sync command health before a POS devic…

The Expo POS web workbench must expose an associate coaching board that combines staff accountability, cashier productivity, security controls, customer engagement, training mode control, and customer service desk before manager coaching o…

The Expo POS web workbench must expose a customer experience assurance board that combines customer handoff, customer engagement, payment assurance, receipt recovery, customer display handoff, and customer service desk before staff treat c…

The Expo POS web workbench must expose a release war room board that combines release blocker matrix, sale floor go/no-go, network outage playbook, inventory risk command, cash room audit, and device fleet launch for a single launch-readin…

The Expo POS web workbench must expose an incident escalation board that combines release blocker matrix, network outage playbook, hardware serviceability, receipt counter recovery, security controls, and manager closeout before support es…

The Expo POS web workbench must expose a store opening readiness board that combines register launch decision, shift launch checklist, device operations, hardware serviceability, cash control, and training mode control before opening the l…

The Expo POS web workbench must expose a store closing readiness board that combines closeout audit packet, manager closeout, cash room audit, receipt counter recovery, offline selling decision, and staff accountability before closing the…

The Expo POS web workbench must expose a live lane supervisor board that combines sale floor go/no-go, lane throughput, critical path assurance, associate coaching, customer experience assurance, and incident escalation while a customer-fa…

The Expo POS web workbench must expose an offline queue triage board that combines network outage playbook, sync command health, queue performance, receipt counter recovery, cash room audit, and failed queue count before staff retry offlin…

The Expo POS web workbench must expose a payment recovery board that combines payment assurance, tender settlement, tender method coverage, receipt counter recovery, customer service desk, and manager exceptions before staff recover paymen…

The Expo POS web workbench must expose a fabric counter assurance board that combines inventory risk command, inventory cut readiness, scan reliability, cart integrity, hardware serviceability, and queue performance before cutting fabric a…

The Expo POS web workbench must expose a hardware pairing readiness board that combines device fleet launch, hardware serviceability, peripheral operations, device operations, scan reliability, and receipt counter recovery before pairing o…

The Expo POS web workbench must expose a shift handoff packet board that combines staff accountability, associate coaching, store closing readiness, customer service desk, offline queue triage, and closeout audit packet before a cashier ha…

The Expo POS web workbench must expose a refund authorization board that combines customer service desk, customer recovery, manager closeout, security controls, post-sale audit, and receipt counter recovery before refund work continues.

The Expo POS web workbench must expose a training certification board that combines training mode control, associate coaching, store opening readiness, device fleet launch, sale floor go/no-go, and release war room before staff sign off tr…

The Expo POS web workbench must expose a customer issue prevention board that combines customer experience assurance, customer handoff command, customer engagement, receipt counter recovery, payment recovery, and inventory risk command bef…

The Expo POS web workbench must expose a launch rehearsal board that combines store opening readiness, release war room, device fleet launch, network outage playbook, cash room audit, and training certification before rehearsal is marked c…

The Expo POS web workbench must expose a compliance evidence board that combines cash room audit, closeout audit packet, post-sale audit, security controls, incident escalation, and store closing readiness before audit evidence is consider…

The Expo POS web workbench must expose an operator release cockpit board that combines release war room, live lane supervisor, offline queue triage, payment recovery, fabric counter assurance, hardware pairing readiness, shift handoff pack…

The Expo POS web workbench must expose a register resilience board that combines operator release cockpit, sync command health, continuity snapshot, offline queue triage, network outage playbook, and device fleet launch before the register…

The Expo POS web workbench must expose a tender risk board that combines payment recovery, payment assurance, tender settlement, tender method coverage, cash room audit, and manager exceptions before tender anomalies are dismissed.

The Expo POS web workbench must expose an inventory reconciliation board that combines fabric counter assurance, inventory risk command, inventory assurance, post-sale audit, queue performance, and compliance evidence before inventory disc…

The Expo POS web workbench must expose a customer recovery command board that combines customer issue prevention, refund authorization, receipt counter recovery, customer service desk, customer experience assurance, and incident escalation…

The Expo POS web workbench must expose a hardware incident board that combines hardware pairing readiness, hardware serviceability, device fleet launch, receipt counter recovery, incident escalation, and peripheral operations before hardwa…

The Expo POS web workbench must expose a shift leader dashboard board that combines live lane supervisor, shift handoff packet, associate coaching, store opening readiness, store closing readiness, and operator release cockpit for lane-lea…

The Expo POS web workbench must expose a training floor board that combines training certification, training mode control, associate coaching, customer issue prevention, hardware pairing readiness, and launch rehearsal before floor trainin…

The Expo POS web workbench must expose a closeout compliance board that combines compliance evidence, store closing readiness, cash room audit, closeout audit packet, offline queue triage, and refund authorization before closeout complianc…

The Expo POS web workbench must expose a disaster recovery drill board that combines network outage playbook, offline queue triage, continuity snapshot, device fleet launch, incident escalation, and operator release cockpit before recovery…

The Expo POS web workbench must expose a release signoff packet board that combines operator release cockpit, launch rehearsal, compliance evidence, sale floor go/no-go, store opening readiness, and store closing readiness before go-live s…

The Expo POS web workbench must expose a daily health pulse board that combines live lane supervisor, payment recovery, fabric counter assurance, hardware pairing readiness, customer issue prevention, and compliance evidence into a daily l…

The Expo POS web workbench must expose an executive go-live command board that combines release signoff packet, daily health pulse, disaster recovery drill, shift leader dashboard, tender risk, and register resilience into the final execut…

The Expo POS web workbench must expose a regional rollout readiness board that combines executive go-live command, store opening readiness, device fleet launch, training floor, disaster recovery drill, and closeout compliance before a stor…

The Expo POS web workbench must expose a pilot store command board that combines regional rollout readiness, live lane supervisor, daily health pulse, hardware incident, tender risk, and inventory reconciliation before pilot expansion cont…

The Expo POS web workbench must expose a multi-lane coordination board that combines register resilience, lane throughput, shift leader dashboard, cashier productivity, device operations, and hardware pairing readiness before multiple regi…

The Expo POS web workbench must expose a support escalation closure board that combines hardware incident, customer recovery command, disaster recovery drill, incident escalation, compliance evidence, and tender risk before support escalat…

The Expo POS web workbench must expose a revenue protection board that combines tender risk, payment recovery, refund authorization, cash room audit, security controls, and post-sale audit before cash or tender exposure is accepted.

The Expo POS web workbench must expose an inventory protection board that combines inventory reconciliation, fabric counter assurance, inventory risk command, inventory service, compliance evidence, and offline queue triage before inventor…

The Expo POS web workbench must expose an experience protection board that combines customer recovery command, customer issue prevention, customer experience assurance, customer handoff command, receipt recovery command, and daily health p…

The Expo POS web workbench must expose a store operations readiness board that combines shift leader dashboard, closeout compliance, register resilience, hardware incident, staff accountability, and manager closeout command before store op…

The Expo POS web workbench must expose a release communications board that combines release signoff packet, executive go-live command, daily health pulse, incident escalation, training floor, and store opening readiness before launch commu…

The Expo POS web workbench must expose a launch day command board that combines regional rollout readiness, pilot store command, multi-lane coordination, support escalation closure, revenue protection, and inventory protection into a same-…

The Expo POS web workbench must expose a stabilization command board that combines launch day command, experience protection, store operations readiness, disaster recovery drill, closeout compliance, and executive go-live command before st…

The Expo POS web workbench must expose a release retrospective board that combines stabilization command, compliance evidence, post-sale audit, daily health pulse, inventory reconciliation, and customer recovery command before release lear…

The Expo POS web workbench must expose a deterministic end-to-end purchase test action that uses local sample catalog data and a cash test tender to exercise cart creation, tender staging, offline queueing, simulated accepted sync, and rec…

The Expo POS web workbench must expose purchase-test evidence that shows the order ID, receipt total, post-sync queue state, and each completed step so an operator can verify the app is ready for a manual purchase test before using live au…

The Expo POS web workbench must expose a live API purchase-test readiness gate that blocks live sale-sync testing until the API origin, Clerk staff session, selected organization, device ID, registered device state, online connectivity, an…

The Expo POS web workbench must expose a live API purchase-test flow that stages a local sample-catalog cash sale into the offline queue, syncs that exact sale through /api/pos/sales/sync, and records receipt/order evidence from the API re…

The Expo POS web workbench must expose an E2E test command center that rolls up local purchase-test evidence, live API purchase-test readiness, queued-sale state, receipt/recovery evidence, customer context, and cash-lane hardware readines…

The Expo POS web workbench must provide a local test-lane preparation action that seeds safe workbench-only customer, cashier, timeclock, connectivity, opening-float, and cash-lane hardware state without faking Clerk authentication, select…

The Expo POS web workbench must expose manual E2E verification checks after live sale sync, including API order acceptance, receipt-history presence, offline queue clearance, receipt recovery readiness, and closeout safety, so a tester can…

Devices must be enrollable to a store with per-device credentials and revocable tokens.

Sensitive actions (refunds, price overrides, drawer opens outside a sale) must require a manager PIN or biometric step-up.

Scaffold apps/pos as a TypeScript-first package for the React Native + Expo app (DEC-001 / REQ-POS-020). Strict TS via tsconfig.base.json, ESLint + Prettier wired to the root flat config, @bolttocart/core imported with types end-to-end, pn…

Device-session abstraction (apps/pos/src/session/deviceSession.ts) and manager-PIN gate stub (apps/pos/src/session/managerGate.ts) per REQ-POS-030 / REQ-POS-031. DeviceSession wraps an injected DeviceSessionReader that the forthcoming Cler…

In-memory held-cart store (apps/pos/src/flow/heldCarts.ts) per REQ-POS-004 / REQ-POS-022. HeldCartStore (plain class, no framework dep) provides: park(state, label?) ??? serialises CriticalPathState via serializeCartSnapshot (REQ-POS-504),…

End-of-day report builder + state machine (apps/pos/src/flow/endOfDayReport.ts). Pure reducer driving EndOfDayReportState union: idle | counting | confirming | complete | error. StartEndOfDayOptions: currency, openingFloatMinor, netCashSal…

Refund flow state machine (apps/pos/src/flow/refundFlow.ts). Steps: idle | selecting-lines | selecting-tender | processing | complete | error. startRefund(state, cart, authorization, currency) ??? accepts ManagerAuthorization from the PIN…

Customer lookup module (apps/pos/src/flow/customerLookup.ts). PosApiClient interface: lookupCustomers(query: string): Promise<readonly PosCustomer[]> ??? injected; no direct fetch. PosCustomer: { customerId, displayName, email | null, phon…

Offline queue (apps/pos/src/flow/offlineQueue.ts). OfflineQueueStorage interface: getItem/setItem/removeItem ??? injected (real: expo-secure-store; test: createInMemoryStorage()). OfflineQueueItem<T>: { id, payload, enqueuedAt: string, att…

Split-tender keypad render model (apps/pos/src/components/SplitTenderKeypad.ts). SplitTenderKeypadModel: { remainingMinor, canFinalize, paidMinor, cartTotalMinor, currency, isComplete } (all amounts bigint). buildSplitTenderKeypad(state: T…

Receipt delivery module (apps/pos/src/flow/receiptDelivery.ts). ReceiptDeliveryMethod = "email" | "sms". ReceiptDeliveryOptions: method, address, transactionAt, totalMinor: bigint, currency, tenantId, storeName. ReceiptDeliveryJobPayload:…

Discount scan handler (apps/pos/src/flow/discountScanHandler.ts). handleDiscountScan(rawPayload, isOnline) ??? parses COUPON:<code> prefix (case-insensitive, trims CR/LF); rejects with { kind: "offline-rejected", code } when isOnline=false…

Store-credit balance lookup module (apps/pos/src/flow/storeCreditBalance.ts). StoreCreditBalance: { customerId, balanceMinor: bigint, currency, asOf (ISO) }. StoreCreditClient interface injected. STORE_CREDIT_TTL_MS = 300_000. States: idle…

POS device registration state machine (apps/pos/src/flow/posDeviceRegistration.ts). Client-side state machine for registering a POS terminal against the pos_devices schema (REQ-ARC-513). PosDeviceProfile: { deviceId, stripeReaderId, displa…

Cycle-count session flow module (apps/pos/src/flow/cycleCountSession.ts). Pure client-side state machine for the POS cycle-count workflow over the cycle_count_sessions / cycle_count_lines schema (REQ-ARC-512). States: idle | open | confirm…

Transaction lookup module (apps/pos/src/flow/transactionLookup.ts). Retrieves a past POS transaction by receipt reference for refund initiation (REQ-POS-513). TransactionClient interface: lookupTransaction(ref: string): Promise<PastTransac…

Price-override flow state machine (apps/pos/src/flow/priceOverrideFlow.ts). Sensitive action per REQ-POS-031 / REQ-PRI-061 — caller must obtain a ManagerAuthorization from ManagerGate.requirePin("price-override", …) before invoking. Pure r…

ScanDispatch module (apps/pos/src/flow/scanDispatch.ts) bridging parseScan() (REQ-POS-505) and CriticalPathState (REQ-POS-502). dispatchScan(state, rawPayload, resolver): Promise<ScanDispatchResult> returns a discriminated union: { kind: "…

Tender state machine (apps/pos/src/flow/tender.ts). Pure reducer driving TenderState union: idle | selecting-method | awaiting-card-read | awaiting-cash-entry | completing | complete | error. TenderMethod = "card" | "cash" | "store-credit"…

Receipt line builder + 40-column ESC/POS renderer (apps/pos/src/receipt/receiptBuilder.ts). buildReceipt(cart, tenderResult, options): ReceiptModel — pure function composing: header (storeName, terminalId, transactionAt); ReceiptLine[] per…

YardageKeypad state machine (apps/pos/src/components/YardageKeypad.tsx). Pure-TypeScript keypad for fractional yardage entry per REQ-POS-002. Reducer functions: pressDigit(state, d) appends a decimal digit to the bigint-sixteenths accumula…

CartLineList render-model builder (apps/pos/src/components/CartLineList.tsx). Pure function buildCartLineList(cart: CartValue): CartLineListModel projects each CartItem into a CartLineModel exposing: skuId (bolt scan identifier), displayNa…

Scanner-payload parser for the POS (apps/pos/src/scan/parser.ts) supporting REQ-POS-001 / REQ-POS-003 / REQ-POS-024 / REQ-INV-050. Decodes BOLT:<uuid> and BOLT:<uuid>:<yardage-sixteenths> bolt-label payloads from a Bluetooth HID scanner in…

Cart snapshot for the POS critical path (apps/pos/src/flow/snapshot.ts). serializeCartSnapshot(state) renders a CriticalPathState to a JSON string where every bigint (yardage sixteenths, per-yard minor price) is a decimal string and every…

Cart-line display-string builder (apps/pos/src/cart/buildLineItem.ts). Pure buildLineItemDisplay({ designerName, collectionName }): string derives the short subtitle shown under each cart line: both populated → "Designer · Collection" (mid…

Cart totals breakdown for the POS (apps/pos/src/cart/cartTotals.ts). Pure computeCartTotals({ lines, discountMinor }): { subtotalMinor, discountMinor, taxMinor, totalMinor } collapses cart lines into the four-number breakdown the UI / rece…

Yardage string → nearest-1/16-yard rounding helper (apps/pos/src/cut/roundToSixteenth.ts). Pure roundToSixteenth(input: string): bigint snaps cashier-entered yardage to the canonical 1/16-yard grid defined by REQ-INV-001. Accepts three sha…

BoltToCart NFC URI-record parser (apps/pos/src/scan/parseBoltTag.ts). Pure parseBoltTag(input: string): BoltTagParseResult classifies NDEF URI payloads carrying the canonical btc://bolt/<uuid> form that the mobile NFC reader emits directly…

TenderKind enum + cashier-facing label map (apps/pos/src/tender/tenderKindLabel.ts). Defines the internal discriminator TenderKind = "card_present" | "cash" | "gift_card" | "house_credit" | "split" used by the POS tender state machine, rec…

POS critical-path skeleton (scan → yardage → cart → tender) per REQ-POS-001 / REQ-POS-002. Pure reducer (apps/pos/src/flow/criticalPath.ts) drives an immutable CriticalPathState; placeholder screen modules (apps/pos/src/screens/*.ts) are U…

Loyalty-points earn projection (apps/pos/src/flow/loyaltyEarnProjection.ts). Pure buildLoyaltyEarnProjection(cartTotalMinor, rateNumerator, rateDenominator) bigint floor division. Guard: rateDenominator > 0n; 0n when cartTotalMinor=0n. 7 u…

Gift-card tender leg (apps/pos/src/flow/giftCardTender.ts). Injected GiftCardClient.lookupBalance. State machine idle|entering-code|looking-up|found|insufficient|applied|error. appliedMinor = min(balance, remaining) bigint. 14 unit tests.

Coupon application flow (apps/pos/src/flow/couponFlow.ts). Injected CouponClient.validateCoupon. State machine idle|entering|validating|applied|rejected|error. 13 unit tests.

No-sale drawer-open flow (apps/pos/src/flow/noSaleDrawerOpen.ts). buildNoSaleOpenCommand(opts) validates non-empty authorizedByUserId. 8 unit tests.

Custom manual-entry product line (apps/pos/src/flow/customLine.ts). buildCustomLine(opts) builds CustomCartLine with skuId=CUSTOM-<uuid> and lineTotalMinor=floor(price*yardage/16n). 10 unit tests.

Cash-denomination change suggestion (apps/pos/src/flow/changeSuggestion.ts). computeChangeDenominations greedy bigint algorithm. US_DENOMINATIONS (8 denominations). 9 unit tests.

Cart-line void flow (apps/pos/src/flow/lineVoidFlow.ts). applyLineVoid(cart, opts) pure function. Guards: non-empty auth token, lineIndex in range. 11 unit tests.

POS connectivity-status monitor (apps/pos/src/flow/connectivityMonitor.ts). Injected Fetcher. States: online/offline/degraded. onStateChange unsubscribe. 10 unit tests.

Offline-queue flush state machine (apps/pos/src/flow/offlineQueueFlush.ts). idle|flushing|complete|error. Pure transitions. 10 unit tests.

Session idle-lock module (apps/pos/src/session/idleLock.ts). Injected clock+timer factory. recordActivity/lock/onLock/destroy. 9 unit tests.

Staff clock-in/clock-out stub (apps/pos/src/flow/staffTimeclock.ts). clocked-out|clocked-in|error. getElapsedMs bigint ms. 10 unit tests.

POS OTel span emitter (apps/pos/src/telemetry/posTelemetry.ts). Injected SpanEmitter. pos.scan/pos.add_line/pos.tender/pos.receipt. 11 unit tests.

SKU low-stock badge (apps/pos/src/components/LowStockBadge.ts). computeStockBadge right-arrow ok|low|out. remainingYards via formatYardageMixed. 8 unit tests.

Hardware error remediation registry (apps/pos/src/hw/errorRemediation.ts). HardwareErrorCode closed union (8 codes). getRemediation(code). 6 tests covering all codes.

Tip prompt render model (apps/pos/src/flow/tipPrompt.ts). buildTipPrompt bigint floor division. DEFAULT_TIP_PRESETS (0/15/18/20%). applyCustomTip validates >= 0n. 9 unit tests.

Float denomination entry (apps/pos/src/flow/floatEntry.ts). floatEntryInit/setDenominationCount/clearFloat pure reducers. bigint totalMinor. 10 unit tests.

POS search-result ranker (apps/pos/src/flow/skuRanker.ts). scoreSkuResult 100/80/60/40/20/0. rankSkuResults stable descending sort. 13 unit tests.

No-sale drawer-open flow (apps/pos/src/flow/noSaleFlow.ts) with states idle | selecting-reason | confirming | opened | error, manager-authorization guard on startNoSale, reason selection + confirmation transitions, cancelNoSale from non-op…

Coupon-application render model (apps/pos/src/flow/couponApplication.ts) wraps handleDiscountScan + computeDiscountMinor into a pure state machine (idle | scanning | decoded | verifying | applied | rejected | error) and includes CartWithCo…

Entitlement-selection render model (apps/pos/src/flow/entitlementSelector.ts) with states idle | loaded | selected | applied, expiry-aware selection (nowIso guard), bigint discount projection via computeDiscountMinor, and backward-compatib…

Printed-receipt line-array builder (apps/pos/src/receipt/buildReceiptLines.ts). Pure buildReceiptLines(input) returns a readonly string[] of 40-column rows (RECEIPT_WIDTH = 40) ready to feed directly to a thermal-printer adapter's printLin…

POS idle-timeout timer (apps/pos/src/session/idleTimeout.ts). Pure dependency-injected timer: createIdleTimer({ host, timeoutMs?, onIdle }) returns an IdleTimer controller with start() / recordActivity() / stop() and observable status ("ar…

Persisted held carts must be supported by a POS storage wrapper around the existing held-cart state, using an injected string key-value storage interface with no Expo/runtime imports. The wrapper stores serialized cart snapshots, lists hol…

The POS must include a pure receipt-reprint flow for completed transactions. The flow accepts a looked-up completed transaction and an injected receipt printer, exposes states for idle, ready, printing, complete, and error, guards against…

POS scan-dispatch status projection (apps/pos/src/components/ScanDispatchStatus.ts). Pure UI-runtime-free helper for the existing scanDispatch result union that maps added, yardage-hint-updated, parse-error, and resolve-error outcomes to c…

POS receipt-delivery queue status projection (apps/pos/src/components/ReceiptDeliveryStatus.ts). Pure UI-runtime-free helper for the existing prepareReceiptDelivery flow that maps print, email, and SMS receipt choices into cashier-facing q…

POS manager-gate attempt status projection (apps/pos/src/components/ManagerGateStatus.ts). Pure UI-runtime-free helper for the existing ManagerGateResult and ManagerGateDenialReason types that maps granted, mismatch, locked-out, and no-ver…

POS gift-card balance lookup status projection (apps/pos/src/components/GiftCardBalanceStatus.ts). Pure UI-runtime-free helper for the existing giftCardBalance flow that renders idle, looking-up, found, not-found, and error states into cas…

POS NFC write flow status projection (apps/pos/src/components/NfcWriteStatus.ts). Pure UI-runtime-free helper for the existing nfcWriteFlow state machine that maps each step (idle, confirming, writing, complete, error) to cashier-facing la…

POS shift-summary receipt-line status projection (apps/pos/src/components/ShiftSummaryLinesStatus.ts). Pure UI-runtime-free helper for the existing shiftSummaryLines receipt builder that exposes line count, 40-column width health, cash/car…

POS critical-path status projection (apps/pos/src/components/CriticalPathStatus.ts). Pure UI-runtime-free helper for the existing CriticalPathState reducer that maps scan, yardage, cart, and tender steps to cashier-facing labels, primary n…

POS cart-snapshot restore status projection (apps/pos/src/components/CartSnapshotStatus.ts). Pure UI-runtime-free helper around the existing cart snapshot serializer/deserializer that maps save-ready, restored, empty, incompatible, and inv…

POS SKU-ranker explanation status projection (apps/pos/src/components/SkuRankerStatus.ts). Pure UI-runtime-free helper for the existing SKU search ranker that maps a query and result list to ranked display rows with integer score, match re…

POS customer-display payload status projection (apps/pos/src/components/CustomerDisplayStatus.ts). Pure UI-runtime-free helper for the existing buildPosDisplayPayload customer-facing display payload that maps cart total, item count, curren…

POS physical-scale yardage suggestion status projection (apps/pos/src/components/PhysicalScaleStatus.ts). Pure UI-runtime-free helper for the existing physical-scale reading and buildYardageSuggestionFromWeight function that maps ready, no…

POS hardware runbook status projection (apps/pos/src/components/HardwareRunbookStatus.ts). Pure UI-runtime-free helper for the existing hardware remediation registry and runbook URL builder that maps a HardwareErrorCode to cashier-facing r…

POS scanner-timeout outcome status projection (apps/pos/src/components/ScannerTimeoutStatus.ts). Pure UI-runtime-free helper for the existing scanner-timeout flow that maps a scan result string, timeout/null result, timeout window, and opt…

POS refund-flow status projection (apps/pos/src/components/RefundFlowStatus.ts). Pure UI-runtime-free helper for the existing RefundFlowState reducer that maps idle, selecting-lines, selecting-tender, processing, complete, and error states…

POS tender-flow status projection (apps/pos/src/components/TenderFlowStatus.ts). Pure UI-runtime-free helper for the existing TenderState reducer that maps idle, selecting-method, awaiting-card-read, awaiting-cash-entry, completing, comple…

POS device-session status projection (apps/pos/src/components/DeviceSessionStatus.ts). Pure UI-runtime-free helper for the existing DeviceSessionSnapshot and DeviceSessionInfo types that maps valid, not-enrolled, revoked, expired, and offl…

POS local-event-bus snapshot status projection (apps/pos/src/components/LocalEventBusStatus.ts). Pure UI-runtime-free helper for the existing LocalPosEvent snapshot shape that maps an immutable event snapshot into cashier/developer-facing…

POS connectivity-monitor status projection (apps/pos/src/components/ConnectivityMonitorStatus.ts). Pure UI-runtime-free helper for the existing ConnectivityState monitor shape that maps online, degraded, and offline states plus poll-window…

POS receipt-print job status projection (apps/pos/src/components/ReceiptPrintJobStatus.ts). Pure UI-runtime-free helper for the existing PrintRequest and HardwareResult receipt-printer contract that maps queued, printing, printed, failed,…

POS receipt QR-code print status projection (apps/pos/src/components/ReceiptQrCodeStatus.ts). Pure UI-runtime-free helper for the existing ReceiptPrinter.printQrCode(data, size) contract that maps idle, queued, printing, printed, and faile…

POS receipt text-print status projection (apps/pos/src/components/ReceiptTextPrintStatus.ts). Pure UI-runtime-free helper for the existing ReceiptPrinter.printText(lines) contract that maps idle, queued, printing, printed, and failed prefo…

POS cash-drawer open-reason status projection (apps/pos/src/components/CashDrawerOpenReasonStatus.ts). Pure UI-runtime-free helper for the existing CashDrawerOpenReason contract that maps sale, no-sale, and manager-override drawer-open rea…

POS scanner-cancellation status projection (apps/pos/src/components/ScannerCancellationStatus.ts). Pure UI-runtime-free helper for the existing ScannerCancellationToken contract that maps idle, active, cancelled, completed, and failed scan…

POS cash-drawer last-opened status projection (apps/pos/src/components/CashDrawerLastOpenedStatus.ts). Pure UI-runtime-free helper for the existing CashDrawer.lastOpenedAt() result that maps never-opened, recent, stale, future-clock, and i…

POS cash-drawer open-result status projection (apps/pos/src/components/CashDrawerOpenResultStatus.ts). Pure UI-runtime-free helper for the existing HardwareResult returned by CashDrawer.open(reason) that maps idle/no-result, opening, opene…

POS cash-drawer shift-close checklist status projection (apps/pos/src/components/CashDrawerShiftCloseStatus.ts). Pure UI-runtime-free helper for caller-provided drawer shift-close state that maps closeout step, physical drawer status, last…

POS cash-drawer variance-review status projection (apps/pos/src/components/CashDrawerVarianceReviewStatus.ts). Pure UI-runtime-free helper for caller-provided drawer expected/count cash amounts and reviewer state that maps balanced, under,…

POS cash-drawer safe-drop status projection (apps/pos/src/components/CashDrawerSafeDropStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop recommendation and register drawer-cash amounts that maps not-needed, recommended,…

POS cash-drawer safe-drop receipt status projection (apps/pos/src/components/CashDrawerSafeDropReceiptStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop receipt metadata and print-result state that maps idle, preparing,…

POS cash-drawer safe-drop custody status projection (apps/pos/src/components/CashDrawerSafeDropCustodyStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop custody metadata that maps unrecorded, needs-envelope, needs-witnes…

POS cash-drawer safe-drop audit status projection (apps/pos/src/components/CashDrawerSafeDropAuditStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop audit metadata that maps missing-record, draft, pending-manager-review,…

POS cash-drawer safe-drop deposit-batch status projection (apps/pos/src/components/CashDrawerSafeDropDepositBatchStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop deposit-batch metadata that maps unqueued, queued, ready…

POS cash-drawer safe-drop bank-deposit handoff status projection (apps/pos/src/components/CashDrawerSafeDropBankDepositStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop bank-deposit handoff metadata that maps not-starte…

POS cash-drawer safe-drop exception-resolution status projection (apps/pos/src/components/CashDrawerSafeDropExceptionResolutionStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop exception metadata that maps none, open, i…

POS cash-drawer safe-drop reconciliation status projection (apps/pos/src/components/CashDrawerSafeDropReconciliationStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop reconciliation metadata that maps not-started, matchi…

POS cash-drawer safe-drop compliance-report status projection (apps/pos/src/components/CashDrawerSafeDropComplianceReportStatus.ts). Pure UI-runtime-free helper for caller-provided safe-drop compliance-report metadata that maps not-started…

POS receipt-reprint audit record builder (apps/pos/src/flow/receiptReprintAudit.ts). Pure helper for completed receipt-reprint flow states that returns audit-safe metadata for pos.receipt.reprinted, including transaction ID, receipt refere…

POS receipt-reprint audit status projection (apps/pos/src/components/ReceiptReprintAuditStatus.ts). Pure UI-runtime-free helper for receipt-reprint audit outcomes that maps idle, recording, recorded, and error states into cashier/manager-f…

POS receipt-reprint audit queue status projection (apps/pos/src/components/ReceiptReprintAuditQueueStatus.ts). Pure UI-runtime-free helper for caller-provided receipt-reprint audit queue metadata that maps empty, queued, uploading, uploade…

POS receipt-reprint audit public exports (apps/pos/src/index.ts). The @bolttocart/pos package root must export the receipt-reprint audit status and audit queue status projection builders plus their public model/input/action types so Expo s…

(AI-proposed; parent REQ-POS-006, REQ-POS-022, REQ-POS-023, REQ-POS-591) POS receipt-reprint audit queue reducer (apps/pos/src/flow/receiptReprintAuditQueue.ts). Pure helper for staging completed receipt-reprint audit records locally befor…

POS cart-edit public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-004 and REQ-POS-502: the @bolttocart/pos package root must export the existing pure cart-edit reducers removeCartLine and updateCartLineYardage so E…

POS line-item display public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-004, REQ-POS-502, and REQ-POS-544: the @bolttocart/pos package root must export the existing pure line-item display status builder plus its…

POS cart-edit status projection (apps/pos/src/components/CartEditStatus.ts). AI-proposed clarification of REQ-POS-004, REQ-POS-502, and REQ-POS-596: the POS must expose a pure UI-runtime-free projection for the mid-transaction line edit su…

POS receipt-reprint audit queue status adapter (apps/pos/src/components/ReceiptReprintAuditQueueStatus.ts). AI-proposed clarification of REQ-POS-006, REQ-POS-022, REQ-POS-023, REQ-POS-593, and REQ-POS-595: the POS package must provide a pu…

POS checkout-readiness status projection (apps/pos/src/components/CheckoutReadinessStatus.ts). AI-proposed clarification of REQ-POS-001, REQ-POS-005, and REQ-POS-021: before a cashier can leave cart review for tender selection, the POS mus…

POS cart-line list public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-004, REQ-POS-506, and REQ-POS-544: the @bolttocart/pos package root must export the existing pure cart-line list projection and designer/collec…

POS cash-drawer open status public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-024, REQ-POS-031, REQ-POS-576, REQ-POS-578, and REQ-POS-579: the @bolttocart/pos package root must export the existing pure cash-drawe…

POS SKU-search public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-003 and REQ-POS-026: the @bolttocart/pos package root must export the existing pure SKU-search state machine and SKU-search result projection so Ex…

POS cart totals public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-004, REQ-POS-502, REQ-POS-545, and REQ-POS-550: the @bolttocart/pos package root must export the existing pure cart totals helper, stub tax consta…

(AI-proposed; parent REQ-POS-001, REQ-POS-004, REQ-POS-022, REQ-POS-023, REQ-SYN-011, REQ-SYN-020) POS cart conflict status projection (apps/pos/src/components/CartConflictStatus.ts). Pure UI-runtime-free helper for the reconciliation bann…

POS scan-dispatch public exports (apps/pos/src/index.ts). AI-proposed clarification of REQ-POS-001, REQ-POS-003, REQ-POS-020, REQ-POS-502, REQ-POS-510, and REQ-POS-556: the @bolttocart/pos package root must export the existing pure scan-di…

Each store gets a storefront on a branded subdomain and optionally a custom domain with SSL provisioned automatically (see �29). The apex bolttocart.com hosts only platform marketing / sign-up surfaces ??? storefront paths (/shop, /cart, /…

Storefronts must share the same inventory, pricing, and promotion engines as the POS (�3.1, �7).

Support yardage-based purchasing with minimum cut (default � yard) and increment (default � yard) configurable per product.

Product detail pages must show real-time availability, remnant availability, related kits/patterns, and substitutions when out of stock.

Checkout must support guest and authenticated purchase, address validation, shipping method selection, tax computation, payment, and order confirmation within the UX latency targets in �28.

Order workflow: Received ??? Cut ??? Pack ??? Ship ??? Delivered, with partial fulfillment permitted.

Storefront pages must be server-rendered or statically pre-rendered for SEO, with structured data (Product, Offer, Breadcrumb, Event) and auto-generated sitemaps.

Optional one-way integrations with external storefronts (Shopify, WooCommerce) must be available as add-ons; BoltToCart remains the inventory source of truth.

The /shop/[slug] product detail page's Offer JSON-LD must carry a UnitPriceSpecification declaring unitCode: "YRD" (UN/CEFACT yard) with a referenceQuantity of 1 yard for unitOfSale === "by_yard" SKUs, so Google Shopping / Merchant / Bing…

The /shop index "Browse by???" nav must list every facet-index sibling (/shop/designers, /shop/collections, /shop/colors, /shop/fibers, /shop/widths ??? see REQ-SRC-500 / REQ-SRC-501) in a single alphabetized data-driven list so new facet…

The /shop/[slug] PDP must render a RelatedItemsStrip below the soft-match "Related fabrics" shelf, returning up to 6 SKUs matching the seed on both designer AND fiberContent. Lives in a dedicated loadRelatedByDesignerAndFiber loader so the…

The /shop PLP must render a ShopEmptyState block when the filter-and-sort combination lands on zero SKUs. The block surfaces (1) the current active filter chips as one-tap "remove this facet" links (reusing ActiveFilterChips so single-chip…

The /shop/[slug] PDP JSON-LD must include Product.isRelatedTo as an array of up to 6 @id references pointing at the same roster rendered in the RelatedItemsStrip (REQ-ECO-502) ??? keeping the structured-data claim in lockstep with the visi…

The /shop/[slug] route must serve a per-slug OpenGraph card at /shop/{slug}/opengraph-image (Next.js metadata-convention colocated asset) that renders the product name, per-yard price, designer, and fiber content inside the platform OgBolt…

The /shop/[slug] PDP BreadcrumbList JSON-LD must be extended from "Home ??? Shop ??? [Product]" to include the SKU's collection (when non-null) as an intermediate crumb pointing at /shop?collection=<value> and the designer (when non-null)…

The /shop/collections route exposes a facet-index page listing every fabric collection name (with current cuttable-SKU counts) as a bookmarkable discovery surface, deep-linking to /shop?collection=<value> for the filtered catalog view. Mir…

The /shop/colors route exposes a color facet-index page listing every color tag in the catalog (with current cuttable-SKU counts and visual swatch dots) as a bookmarkable discovery surface, deep-linking to /shop?color=<value> for the filte…

The tenant sitemap (sitemap.ts tenant branch) must include /shop/fibers, /shop/widths, and /events/instructors as static entries so these discovery surfaces (REQ-SRC-500, REQ-SRC-501, REQ-EVT-505) are visible to crawlers. Each gets priorit…

The /visualizer route must serve a colocated opengraph-image.tsx (Edge runtime, no DB call) rendering "Quilt Designer" / "Design. Preview. Add to cart." inside the platform OgBoltCard frame. Page metadata.openGraph.images references this r…

The /visualizer page must emit a JSON-LD @graph with a WebPage node and BreadcrumbList (Home ??? Quilt Designer) to match the structured-data posture of /drops and /events. ItemList is intentionally omitted ??? the fabric palette is client…

The /shop PLP header gains a "New arrivals" link pointing to /shop?new=1 alongside the RSS autodiscovery link (REQ-ECO-518).

Tenant storefronts must render /shop through a schema-driven theme/template engine backed by the store's persisted storefront_theme_config. The engine must support six fabric-retail templates (boutique, modern, designer, discount, workshop…

The /shop/[slug] PDP SpecList Width row links to /shop/widths when bolt.widthInches is non-null, doubling it as a discovery path. Value displays as N" (WOF). Same href + aria-label as Designer and Collection rows. No DB change.

Cart summary Shipping row gains a truck icon for visual distinction from the yardage/items rows (REQ-ECO-523).

The /cart order-summary shows a full breakdown when a coupon is applied: Subtotal row, coupon-discount line (code + negative emerald amount), and a Total row (subtotal minus discountMinor, bigint). No extra rows when no coupon is active.

The /shop/[slug] PDP SpecList emits a Fiber row when fiberContent is non-null. The row label ("Fiber") links to /shop/fibers and the value links to /shop?fiber=<value>, matching the Collection row pattern (REQ-ECO-506). No DB change.

The /shop/[slug] PDP JSON-LD Product.additionalProperty array carries each non-null spec field as a schema.org/PropertyValue entry (fiberContent, widthInches). weightGsm and originCountry are deferred pending schema migration. Enables Goog…

The /shop/[slug] PDP "Recently viewed" strip limit raised from 4 to 6 (REQ-ECO-529). Strip is already last in render order (after RelatedFabrics and RelatedItemsStrip) and already hides when the cookie list is empty. Uses the RelatedCardSt…

DEFERRED-AUDIT: Neither shippingEstimator (packages/core) nor a preferred fulfillmentMode field on the cart state currently exists. Both are prerequisites for the "Estimated delivery window" line. This requirement is deferred until: (1) a…

The /shop page quick-filter strip must include a third shortcut, "Remnants & last cuts", linking to /shop?low-yardage=1 alongside "New arrivals" and "Back in stock". The link must live in the existing <ul aria-label="Quick filters">, prese…

The /shop/[slug] PDP Specs "Width" row must mirror the Fiber row's two-intent discovery model. When widthInches is non-null, the row label links to /shop/widths with an accessible label for browsing all widths, while the row value links to…

The /shop/[slug] PDP Care block must provide fiber discovery links whenever fiberContent is present. If keyword-based care tips render, append links to /shop?fiber=<fiberContent> and /shop/fibers. If no known care keyword matches, render a…

The /cart line-item row "Save for later" button is now hidden when the SKU is already on the customer's wishlist. heartedIds are loaded from loadHeartedSkuIds(cartSkuIds) and checked per item. The saveCartItemForLaterFormAction (already pr…

The /shop filter rail gains a "Remnants & last cuts" toggle (Yardage section) that filters to SKUs with availableSixteenths between 1 and MIN_YARDAGE_SIXTEENTHS * 2n (1 yd). Parsed as ?low-yardage=1; the web loader translates it to minAvai…

The /shop sort dropdown gains price-per-yard-asc (label: "Per yard???") and price-per-yard-desc (label: "Per yard???") sort keys. Both order by pricePerYardMinor (same predicate as price-low/price-high); the separate keys surface the unit…

The /shop PLP adds a FilterSummaryPill server component that renders "N fabrics ? M filters ? remove all" above the ActiveFilterChips when at least one predicate is active. "Remove all" links to /shop. No new props; uses the already-presen…

The /shop PLP header gains "New arrivals" and "Back in stock" quick-filter links pointing at /shop?new=only and /shop?restocked=1. restockedOnly is parsed in parseStorefrontFilters, included in hasActiveFilters, serialised by buildShopHref…

DEFERRED AUDIT ? /shop/themes facet-index page: the catalog schema has no themeTag column as of 2026-04-23. No migration added. Revisit when the merchandising schema gains a theme/style tag (reserved REQ-ID: REQ-ECO-527). Pattern would mir…

The /cart page must render a coupon-code entry field (REQ-ECO-508, REQ-PRI-050 cart-time validation). A client component CartCouponSection renders either the code-entry form or the applied-coupon chip. The applyCouponCodeAction server acti…

The /cart page must run a live tenant-scoped availability recheck for every cart line before rendering checkout actions. Lines whose requested yardage exceeds currently cuttable inventory must show an inline correction state with the reque…

The /cart page must expose a print-friendly quote view for in-store handoff. The printed quote includes store name, generated timestamp, cart line names, yardage, unit prices, subtotal, applied coupon preview if present, and a scannable or…

The /shop/[slug] PDP yardage selector must render a deterministic line-total preview and remaining-yardage warning as the shopper changes yardage. The preview uses bigint minor-unit math, honors the existing minimum/increment rules, and su…

The /shop listing must provide a URL-driven "available today" filter that returns only SKUs with at least one cuttable bolt above the configured minimum cut. The filter composes with existing designer, collection, color, fiber, width, sear…

The storefront shell cart indicator must display the current cart item count and subtotal from the existing cart cookie model on storefront pages where cookies are available. The indicator links to /cart, degrades to count-only when subtot…

The /cart/confirmation page must render a next-step panel for overnight MVP orders that distinguishes pickup, shipping, and class/event follow-up paths where that metadata exists, and otherwise shows a generic "order received" state. The p…

The storefront /shop and /cart pages must emit product analytics funnel intents through apps/web/src/lib/telemetry.ts for cart-viewed, checkout-blocked-by-inventory, quote-printed, and checkout-started. Payloads include tenant id, cart lin…

The /cart print quote must include a generated timestamp and the resolved tenant storefront label so an in-store handoff can be reconciled to the right shop and print moment without creating an order.

Cart availability correction alerts must deep-link to the affected cart line so a shopper with a long cart can jump from the warning to the exact item that needs adjustment.

The disabled checkout state on /cart must disclose the number of blocking availability corrections, not only a generic disabled reason.

The cart quote print button must expose a pending state via visible text and an ARIA live announcement while the telemetry action records the print intent.

The /cart/confirmation next-step panel must include an admin handoff link for demo operators without implying real payment or fulfillment occurred.

The /shop quick-filter strip must include a "Clear quick filters" escape when any quick-filter style predicate is active.

The /shop/[slug] availability panel must show the minimum cut rule alongside current availability so stock state and purchasing constraint are visible before the yardage form.

The storefront shell cart link must expose the subtotal as visible text on tablet/desktop and as a screen-reader-only subtotal on smaller viewports.

The storefront /cart checkout path must replace the simulated v0 checkout with a production checkout flow that supports guest and authenticated customers, collects or confirms customer contact data, shipping or pickup address, delivery met…

Checkout must create an atomic inventory reservation or hold for each cart line before payment capture. Holds must be tenant-scoped, expire automatically, preserve fixed-point yardage, prevent concurrent oversells, expose insufficient-yard…

Checkout must use tenant-configured tax and fulfillment settings to quote shipping, pickup, and tax before payment. The quote must show line subtotal, discount, shipping, tax, and total in integer minor units, must be revalidated server-si…

Storefront catalog pages must support publication-quality product data for MVP SKUs: public slug, publish/draft state, SKU code/barcode where available, designer, collection, colorway, dominant colors, color tags, fiber content, width, pro…

Tenant storefronts must surface launch-critical trust and support information before checkout: store support email or phone, pickup/shipping availability, return/cancellation policy, class/event cancellation policy where classes are enable…

Cart and checkout-adjacent storefront surfaces must show a shopper-facing checkout readiness panel before activation. The panel must distinguish quote-only checks from durable checkout guarantees, list blocking cart issues such as unavaila…

Storefront cart and checkout-adjacent pages must make unavailable next steps self-recovering. When checkout remains disabled, the cart must show the exact blocker category, the admin-owned setting or inventory state that can clear it, whet…

Storefront checkout-blocked states must preserve shopper intent across recovery actions. When a line must be edited, removed, saved for later, or revisited from a product page, the cart must expose stable anchors and return links so the sh…

Storefront product pages reached from a cart recovery path must show a return affordance back to the exact cart line or summary that sent the shopper there. The return target must be sanitized to the current tenant cart route, must not lea…

Storefront product recovery context must carry through every PDP exit that preserves shopping intent. Add-to-cart success, wishlist save, share/print affordances, related-product pivots, and recently-viewed navigation must either preserve…

Cart-recovery mode must expose an explicit shopper exit control on product pages and comparison shelves. When a shopper follows a recovery link from /cart, the PDP must explain which cart context is active, offer a clear "continue shopping…

Cart-recovery opt-out must be durable for the remainder of the browsing session. When a shopper exits recovery mode, subsequent PDP, related-product, and recently-viewed navigation must avoid re-attaching stale returnTo values unless the s…

Cart-recovery banners must identify the active cart context in shopper-readable terms before linking back. When the recovery target is a line anchor, the PDP must show the affected cart line name, requested yardage, current availability st…

Cart-recovery banners must expose the smallest shopper-safe next action when the original cart line cannot be restored. If the line was removed, saved for later, or no longer sellable, the PDP must show whether the shopper can add the fabr…

PDP add-to-cart recovery must preserve the shopper's selected yardage and recovery intent when a server-side cart mutation fails because availability changed. The error state must explain whether the shopper can retry with a smaller cut, s…

PDP add-to-cart recovery must expose a machine-readable recovery payload for browser smoke tests and support handoff. When availability changes after the page loads, the failed add-to-cart state must include the originally selected yardage…

Checkout contact capture must be resumable and validation-aware for guest and authenticated shoppers. The checkout flow must collect email, phone when required by the selected fulfillment method, marketing-consent state, and customer-accou…

Checkout fulfillment selection must support a single-page handoff between pickup and shipping without recomputing unrelated cart state. Pickup must show store instructions, service window, support contact, and any cutoff warning; shipping…

Checkout order creation must use an idempotent attempt record before redirecting to any payment confirmation surface. The attempt must store tenant, cart hash, selected contact, fulfillment method, quote version, inventory-hold IDs, paymen…

Checkout address validation must produce a privacy-safe validation envelope before payment. The envelope must distinguish incomplete, unserviceable, corrected, and accepted addresses; persist only normalized non-sensitive delivery assumpti…

Checkout payment handoff must remain unavailable until contact, fulfillment, address validation, quote revalidation, and inventory holds are all ready. The UI must explain which prerequisite blocks card collection, keep hosted payment fiel…

Checkout quote replay must bind every payment attempt to a versioned, privacy-safe quote token. The token must include tenant, cart hash, fulfillment choice, normalized delivery assumptions, tax/shipping settings version, inventory-hold re…

Checkout confirmation must distinguish quote-only review, payment authorized, order created, and fulfillment queued states. Each state must show the shopper what has and has not happened, expose safe next actions, avoid implying a durable…

Checkout attempt state must move from browser-submitted replay tokens to a server-owned attempt record before payment intent creation. The record must store the token hash, tenant, cart hash, checkout settings hash, fulfillment choice, nor…

Checkout payment creation must revalidate coupon, tax, fulfillment, delivery, and cart availability inputs against the latest tenant settings immediately before creating or resuming a payment intent. If the quoted total changes, the shoppe…

Checkout must promote the current quote-only review into a durable payment handoff only after a server-owned attempt row has been locked for update, the cart hash still matches the shopper-visible cart, the applied coupon campaign/code is…

Checkout recovery must support a payment-provider interruption path for shoppers who close the browser, return from a failed hosted payment flow, or retry after a webhook delay. The recovery state must resume the same attempt, show the las…

Checkout contact and fulfillment drafts must be normalized into a server-validated attempt envelope before payment handoff. The envelope must store only the contact fields needed for order creation, normalized delivery assumptions, selecte…

Checkout payment handoff must expose an idempotent retry state machine for hosted-payment returns. The state machine must distinguish ready_for_payment, payment_started, payment_returned_unpaid, payment_authorized, order_creation_retryable…

Checkout confirmation must verify hosted-payment return state against a server-owned attempt record before showing payment_authorized, order_created, or fulfillment_queued. The verification must match tenant, attempt ID, cart hash, provide…

Checkout recovery must persist a customer-safe attempt summary that survives reloads, bookmarks, and cross-device support handoff. The summary must include attempt reference, lifecycle state, quote total, fulfillment choice, safe delivery…

Checkout must persist a server-owned attempt ledger before hosted payment redirect. The ledger must store tenant, attempt reference, cart hash, quote version, payment amount, currency, provider session reference hash, lifecycle state, and…

Checkout order creation must run through an idempotent post-payment worker that can resume from payment_authorized to order_created without duplicate orders, duplicate fulfillment rows, duplicate loyalty earns, or duplicate shopper notific…

Checkout attempt records must be sealed against browser tampering before any payment provider handoff. The server-owned record must include a signature or database identity that covers tenant, attempt reference, cart hash, quote version, p…

Checkout confirmation must reconcile the server attempt ledger with the payment webhook lifecycle before exposing order or fulfillment progress. A hosted-payment return may show payment_authorized only after the ledger and provider session…

Live checkout must persist sealed attempt state in a tenant-scoped database table before enabling production payment capture. The table must store tenant, attempt reference, cart hash, checkout settings hash, quote version, payment amount,…

Checkout confirmation must merge hosted-payment returns with webhook-confirmed payment state using a deterministic precedence rule. The page may show payment_authorized from a verified return, but order number, receipt links, fulfillment q…

Storefront checkout payment collection must use an in-app Stripe surface such as Embedded Checkout or Stripe Elements mounted on a BoltToCart route. The server may create or retrieve Stripe Checkout Sessions, PaymentIntents, SetupIntents,…

Provide a pick-and-pack UI that batches cuts across orders by bolt for efficiency.

Integrate with shipping-rate and label providers to quote rates at checkout, purchase labels, and capture tracking numbers.

Support partial shipments, backorders, and customer-approved substitutions.

Support store pickup and local delivery as fulfillment methods.

Returns: configurable policy per product class. Default: cut fabric is non-returnable; precuts, notions, and unopened kits are returnable within a configurable window.

Refunds must support original-tender, store credit, and gift card, with tax correctly reversed.

RMA workflow must generate a prepaid label when the store policy allows, and reconcile inventory on receipt.

Creates /admin/fulfillment/[orderId]/page.tsx (fulfillment detail page) with an inline "Send shipping notification" form. The Server Action emits an email.queued@1 event into the transactional outbox with templateKey: "order_shipped" — reu…

/admin/fulfillment grid adds a URL-driven status filter chip row (pending / processing / ready_for_pickup / fulfilled / cancelled) via buildFulfillmentHref(status) helper. The default view (?status= absent) still shows the active pick queu…

STOP — rma.reasonText column does not exist in the orders schema. Adding a reason field requires a schema migration — coordination-lane work.

/admin/fulfillment/[orderId]/return RMA initiation page. Captures return reason (dropdown), refund amount (max = order total), and internal notes. Execution (Stripe refund, refunded status, order.refunded@1 event) deferred to carrier-API +…

/admin/fulfillment/[orderId]/ship shipping rate capture page. Carrier dropdown, tracking number, and shipping cost fields. Label purchase and order-status advancement deferred to carrier-API integration outside this lane's path fence.

/admin/fulfillment pick-and-pack queue. Lists pending/processing/ready_for_pickup orders oldest-first with status badges, channel, total, and Ship/View action buttons. Inline Drizzle SELECT (no ordersRepo.list yet). Bolt grouping placehold…

The /admin/fulfillment queue must add URL-driven channel filter chips for all, storefront, POS, API, imported, and unknown-source orders, preserving the active status filter and showing per-channel counts from the loaded order window.

The /admin/fulfillment/fulfillment.csv export must honor the same ?status= and ?channel= filters as the on-screen fulfillment queue so downloaded pick lists match the visible cohort.

The /admin/fulfillment table must render human-readable source labels instead of raw source strings while preserving the raw value in a title for debugging.

The /admin/fulfillment summary strip must include an oldest-visible-order age tile so staff can spot stale pick queues without scanning every row.

The /admin/fulfillment table must include a per-row copy-order-id affordance for warehouse/support handoffs.

The /admin/fulfillment/[orderId] detail page must include a copy-order-id affordance in the header/action area.

The /admin/fulfillment/[orderId] detail page must render a read-only fulfillment checklist for placed, picking, ready, shipped/fulfilled, and notification-eligible states, derived only from the persisted order status.

/admin/fulfillment must render an active-filter summary whenever status or channel filters are active, including a clear-all link back to the default active queue.

/admin/fulfillment must include a visible total value tile summing the currently filtered queue's order totals in minor-unit-safe integer math.

/admin/fulfillment/[orderId] must expose a print-pick-sheet action in the header action strip, hidden from print output.

/admin/fulfillment/[orderId] must expose a copy-payment-reference affordance when the order carries a Stripe PaymentIntent id.

/admin/fulfillment/[orderId] must render human-readable source labels while preserving the raw source value in a title attribute.

/admin/fulfillment/fulfillment.csv must include total_minor alongside the human-readable USD amount for reconciliation-safe imports.

/admin/fulfillment/fulfillment.csv must include customer_id as a separate column so staff can join exports back to customer records without parsing email.

/admin/fulfillment/fulfillment.csv must include placed_at as a full ISO-8601 timestamp in addition to the date-only placed field.

/admin/fulfillment must expose a copy-visible-order-ids action when the filtered queue has rows, copying one UUID per line for warehouse and support handoffs.

/admin/fulfillment must expose a print-current-view action for the currently visible fulfillment queue, hidden from print output.

/admin/fulfillment status filter chips must show per-status counts computed from the channel-filtered loaded order window, plus an active-queue count for the default view.

/admin/fulfillment empty states must name the active status/channel filters and include a clear-all link whenever filters are hiding all rows.

/admin/fulfillment placed-date cells must expose the full placed timestamp in a title while keeping the compact date text visible.

/admin/fulfillment/[orderId]/ship must expose a copy-order-id affordance in the header/action area for shipping desk handoffs.

/admin/fulfillment/[orderId]/ship must expose a print-shipping-worksheet action, hidden from print output.

/admin/fulfillment/[orderId]/ship must expose a copy-payment-reference affordance when the order carries a Stripe PaymentIntent id.

/admin/fulfillment/[orderId]/ship must render a human-readable source label while preserving the raw source value in a title attribute.

/admin/fulfillment/[orderId]/ship must render a read-only shipping checklist for ready status, manual label purchase, tracking capture, and notification follow-up, derived only from persisted order fields and the existing workflow.

/admin/fulfillment/[orderId]/return must expose a copy-order-id affordance in the header/action area for RMA handoffs.

/admin/fulfillment/[orderId]/return must expose a print-RMA-worksheet action, hidden from print output.

/admin/fulfillment/[orderId]/return must expose a copy-payment-reference affordance when the order carries a Stripe PaymentIntent id.

/admin/fulfillment/[orderId]/return must render a human-readable source label while preserving the raw source value in a title attribute.

/admin/fulfillment/[orderId]/return must render a read-only RMA eligibility checklist for fulfilled status, manual refund processing, reason capture, and inventory review follow-up, derived only from persisted order fields and the existing…

/admin/fulfillment row actions must include a direct pick-sheet link to /admin/fulfillment/[orderId] so warehouse staff do not have to detour through the full order detail page.

/admin/fulfillment truncated order identifiers must preserve the full order id in a title attribute for visual verification during support calls.

/admin/fulfillment placed-date cells must include a compact relative age beside the date so stale rows are visible without scanning the summary strip.

/admin/fulfillment summary strip must include a pending-order count for the currently filtered queue.

/admin/fulfillment summary strip must include a processing-order count for the currently filtered queue.

/admin/fulfillment summary strip must include a ready-for-pickup count for the currently filtered queue.

/admin/fulfillment/[orderId] placed-date summary must preserve the full placed timestamp in a title attribute while keeping the compact date visible.

/admin/fulfillment/[orderId] must expose a copy-fulfillment-handoff-summary action containing order id, status, source, total, and placed timestamp.

/admin/fulfillment/[orderId] status badges must preserve the raw persisted status in a title attribute.

/admin/fulfillment/[orderId] action navigation must expose a Return/RMA link for fulfilled orders, using the existing RMA flow.

/admin/fulfillment/[orderId]/ship must expose a copy-shipping-handoff-summary action containing order id, status, source, total, and placed timestamp.

/admin/fulfillment/[orderId]/ship must render a status badge in the header with the raw persisted status preserved in a title attribute.

/admin/fulfillment/[orderId]/ship navigation must include a link back to the fulfillment pick sheet for the same order.

/admin/fulfillment/[orderId]/return must expose a copy-RMA-handoff-summary action containing order id, status, source, total, and eligibility.

/admin/fulfillment/[orderId]/return navigation must include a link back to the fulfillment pick sheet for the same order.

/admin/fulfillment/[orderId] page headings that render truncated order ids must preserve the full order id in a title attribute for support verification.

/admin/fulfillment/[orderId] breadcrumb current-page crumbs that render truncated order ids must preserve the full order id in a title attribute.

/admin/fulfillment/[orderId] must show the associated customer_id with a copy affordance when present, and an honest guest-order fallback when absent.

/admin/fulfillment/[orderId] must show total_minor beside the formatted currency total for reconciliation-safe support handoffs.

/admin/fulfillment/[orderId] must show a relative placed-age tile derived from created_at so stale pick sheets are obvious at detail depth.

/admin/fulfillment/[orderId]/ship headings that render truncated order ids must preserve the full order id in a title attribute.

/admin/fulfillment/[orderId]/ship must show the associated customer_id with a copy affordance when present, and an honest guest-order fallback when absent.

/admin/fulfillment/[orderId]/ship must show total_minor beside the formatted currency total for reconciliation-safe shipping handoffs.

/admin/fulfillment/[orderId]/ship must show a relative placed-age tile derived from created_at.

/admin/fulfillment/[orderId]/ship shipping checklist rows must preserve the persisted order status in each row's title attribute so staff can debug why a row reads ready/pending.

/admin/fulfillment/[orderId]/return headings that render truncated order ids must preserve the full order id in a title attribute.

/admin/fulfillment/[orderId]/return must render the current status as a badge with the raw persisted status preserved in a title attribute.

/admin/fulfillment/[orderId]/return must show the associated customer_id with a copy affordance when present, and an honest guest-order fallback when absent.

/admin/fulfillment/[orderId]/return must show total_minor beside the formatted currency total for reconciliation-safe RMA handoffs.

/admin/fulfillment/[orderId]/return RMA checklist rows must preserve the persisted order status in each row's title attribute so staff can debug eligibility without inspecting raw data elsewhere.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include total_minor, source code, and customer id/guest status for audit-safe support escalation.

/admin/fulfillment/[orderId] source summary tiles must show the raw persisted source code visibly beside the friendly source label.

/admin/fulfillment/[orderId] placed timestamp tiles must preserve the exact ISO timestamp in a title attribute.

/admin/fulfillment/[orderId] payment reference tiles must render an explicit "Not recorded" fallback instead of disappearing when no payment reference exists.

/admin/fulfillment/[orderId] placed timestamp tiles must expose a copy affordance for the exact ISO timestamp.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include total_minor, source code, customer id/guest status, payment reference/fallback, and exact placed timestamp.

/admin/fulfillment/[orderId]/ship placed timestamp tiles must preserve and copy the exact ISO timestamp.

/admin/fulfillment/[orderId]/ship source summary tiles must show the raw persisted source code visibly beside the friendly source label.

/admin/fulfillment/[orderId]/ship payment reference tiles must preserve the raw payment reference in a title attribute when present.

/admin/fulfillment/[orderId]/ship manual-label notes must include the short order id so printed worksheets remain identifiable when separated from the page header.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include total_minor, source code, customer id/guest status, payment reference/fallback, and exact placed timestamp.

/admin/fulfillment/[orderId]/return placed timestamp tiles must preserve and copy the exact ISO timestamp.

/admin/fulfillment/[orderId]/return source summary tiles must show the raw persisted source code visibly beside the friendly source label.

/admin/fulfillment/[orderId]/return RMA eligibility tiles must preserve the raw persisted order status in a title attribute.

/admin/fulfillment/[orderId]/return blocked-return alerts must preserve the raw persisted order status in a title attribute.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include the admin route path for support pastebacks.

/admin/fulfillment/[orderId] summary tiles must include the full order id with a copy affordance.

/admin/fulfillment/[orderId] summary tiles must include the raw persisted status with a copy affordance.

/admin/fulfillment/[orderId] source summary tiles must expose a copy affordance for the raw source code.

/admin/fulfillment/[orderId] blocked shipping-notification notices must preserve the raw persisted status in a title attribute.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include the admin route path and shippable eligibility.

/admin/fulfillment/[orderId]/ship summary tiles must include the full order id with a copy affordance.

/admin/fulfillment/[orderId]/ship summary tiles must include the raw persisted status with a copy affordance.

/admin/fulfillment/[orderId]/ship source summary tiles must expose a copy affordance for the raw source code.

/admin/fulfillment/[orderId]/ship blocked-shipping alerts must preserve the raw persisted status in a title attribute.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include the admin route path and RMA route path.

/admin/fulfillment/[orderId]/return summary tiles must include the full order id with a copy affordance.

/admin/fulfillment/[orderId]/return summary tiles must include the raw persisted status with a copy affordance.

/admin/fulfillment/[orderId]/return source summary tiles must expose a copy affordance for the raw source code.

/admin/fulfillment/[orderId]/return payment reference tiles must preserve the raw payment reference in a title attribute when present.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include shipping-notification eligibility.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include the next recommended fulfillment action.

/admin/fulfillment/[orderId] summary tiles must include the admin route path with a copy affordance.

/admin/fulfillment/[orderId] summary tiles must include shipping-notification eligibility with raw status preserved in a title attribute.

/admin/fulfillment/[orderId] order-action navigation links must preserve each destination path in a title attribute for support verification.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include the next recommended shipping action.

/admin/fulfillment/[orderId]/ship summary tiles must include the ship route path with a copy affordance.

/admin/fulfillment/[orderId]/ship summary tiles must include shippable eligibility with raw status preserved in a title attribute.

/admin/fulfillment/[orderId]/ship manual-label worksheet notes must preserve the full order id in a title attribute.

/admin/fulfillment/[orderId]/ship confirm-shipment submit buttons must preserve the ready-to-fulfilled status transition in a title attribute.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include the next recommended RMA action.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include the intended order status after RMA confirmation.

/admin/fulfillment/[orderId]/return summary tiles must include the RMA route path with a copy affordance.

/admin/fulfillment/[orderId]/return RMA eligibility tiles must expose a copy affordance for the visible eligibility value.

/admin/fulfillment/[orderId]/return navigation links must preserve each destination path in a title attribute for support verification.

/admin/fulfillment/[orderId] formatted total tiles must preserve raw total_minor in a title attribute for reconciliation.

/admin/fulfillment/[orderId] total-minor tiles must expose a copy affordance for support reconciliation.

/admin/fulfillment/[orderId] guest customer fallbacks must preserve guest_order in a title attribute.

/admin/fulfillment/[orderId] missing payment-reference fallbacks must preserve not_recorded in a title attribute.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a reconciliation key combining order id and total_minor.

/admin/fulfillment/[orderId]/ship formatted total tiles must preserve raw total_minor in a title attribute for reconciliation.

/admin/fulfillment/[orderId]/ship total-minor tiles must expose a copy affordance for support reconciliation.

/admin/fulfillment/[orderId]/ship guest customer fallbacks must preserve guest_order in a title attribute.

/admin/fulfillment/[orderId]/ship missing payment-reference fallbacks must preserve not_recorded in a title attribute.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a reconciliation key combining order id and total_minor.

/admin/fulfillment/[orderId]/return formatted total context must preserve raw total_minor in a title attribute for reconciliation.

/admin/fulfillment/[orderId]/return total-minor tiles must expose a copy affordance for support reconciliation.

/admin/fulfillment/[orderId]/return guest customer fallbacks must preserve guest_order in a title attribute.

/admin/fulfillment/[orderId]/return missing payment-reference fallbacks must preserve not_recorded in a title attribute.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a reconciliation key combining order id and total_minor.

/admin/fulfillment/[orderId] summary tiles must include the reconciliation key with a copy affordance.

/admin/fulfillment/[orderId] summary tiles must include the next recommended fulfillment action with a copy affordance.

/admin/fulfillment/[orderId] customer-id tiles must preserve the raw customer id in a title attribute when present.

/admin/fulfillment/[orderId] payment-reference tiles must preserve the raw payment reference in a title attribute when present.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include full-order, shipping, and RMA route paths.

/admin/fulfillment/[orderId]/ship summary tiles must include the reconciliation key with a copy affordance.

/admin/fulfillment/[orderId]/ship shippable eligibility tiles must expose a copy affordance for the visible eligibility value.

/admin/fulfillment/[orderId]/ship summary tiles must include the next recommended shipping action with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include the target status after shipment confirmation.

/admin/fulfillment/[orderId]/ship navigation links must preserve each destination path in a title attribute for support verification.

/admin/fulfillment/[orderId]/return summary tiles must include the reconciliation key with a copy affordance.

/admin/fulfillment/[orderId]/return summary tiles must include the next recommended RMA action with a copy affordance.

/admin/fulfillment/[orderId]/return summary tiles must include the RMA target status with a copy affordance.

/admin/fulfillment/[orderId]/return customer-id tiles must preserve the raw customer id in a title attribute when present.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include the full order detail route path.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include customer and payment proof tokens for guest/not-recorded cases.

/admin/fulfillment/[orderId] summary tiles must include a status/source proof key with a copy affordance.

/admin/fulfillment/[orderId] shipping-notification eligibility tiles must expose a copy affordance for the visible eligibility value.

/admin/fulfillment/[orderId] placed-age tiles must preserve the exact placed timestamp in a title attribute.

/admin/fulfillment/[orderId] total-minor tile values must preserve the raw minor-unit value in a title attribute.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include full-order and pick-sheet route paths.

/admin/fulfillment/[orderId]/ship summary tiles must include the shipment target status with a copy affordance.

/admin/fulfillment/[orderId]/ship customer-id tiles must preserve the raw customer id in a title attribute when present.

/admin/fulfillment/[orderId]/ship placed-age tiles must preserve the exact placed timestamp in a title attribute.

/admin/fulfillment/[orderId]/ship total-minor tile values must preserve the raw minor-unit value in a title attribute.

/admin/fulfillment/[orderId]/return summary tiles must include the full order detail route path with a copy affordance.

/admin/fulfillment/[orderId]/return total-minor tile values must preserve the raw minor-unit value in a title attribute.

/admin/fulfillment/[orderId]/return placed-age tiles must preserve the exact placed timestamp in a title attribute.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include customer and payment proof tokens for guest/not-recorded cases.

/admin/fulfillment/[orderId]/return summary tiles must include a status/source proof key with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a route bundle containing fulfillment, full-order, shipping, and RMA paths.

/admin/fulfillment/[orderId] summary tiles must include the route bundle with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a readiness bundle combining order status, notification eligibility, and next action.

/admin/fulfillment/[orderId] summary tiles must include the readiness bundle with a copy affordance.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the full route bundle.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a route bundle containing ship, full-order, and pick-sheet paths.

/admin/fulfillment/[orderId]/ship summary tiles must include the route bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a readiness bundle combining status, shippable eligibility, next action, and target status.

/admin/fulfillment/[orderId]/ship summary tiles must include the readiness bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship manual-label notes must preserve the shipment target status in machine-readable hover context.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a route bundle containing RMA, fulfillment, and full-order paths.

/admin/fulfillment/[orderId]/return summary tiles must include the route bundle with a copy affordance.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a readiness bundle combining status, RMA eligibility, next action, and target status.

/admin/fulfillment/[orderId]/return summary tiles must include the readiness bundle with a copy affordance.

/admin/fulfillment/[orderId]/return blocked-return alerts must preserve the RMA target status in machine-readable hover context.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include the fulfillment queue path.

/admin/fulfillment/[orderId] summary tiles must include the fulfillment queue path with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include an operator bundle combining order id, status, source, and reconciliation key.

/admin/fulfillment/[orderId] summary tiles must include the operator bundle with a copy affordance.

/admin/fulfillment/[orderId] checklist rows must preserve the fulfillment readiness bundle in machine-readable hover context.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include the fulfillment queue path.

/admin/fulfillment/[orderId]/ship summary tiles must include the fulfillment queue path with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include an operator bundle combining order id, status, source, and reconciliation key.

/admin/fulfillment/[orderId]/ship summary tiles must include the operator bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship navigation must expose a copy affordance for the shipping route bundle.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include the fulfillment queue path.

/admin/fulfillment/[orderId]/return summary tiles must include the fulfillment queue path with a copy affordance.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include an operator bundle combining order id, status, source, and reconciliation key.

/admin/fulfillment/[orderId]/return summary tiles must include the operator bundle with a copy affordance.

/admin/fulfillment/[orderId]/return navigation must expose a copy affordance for the RMA route bundle.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a control bundle combining queue path, operator bundle, and readiness bundle.

/admin/fulfillment/[orderId] summary tiles must include the control bundle with a copy affordance.

/admin/fulfillment/[orderId] blocked shipping-notification notes must preserve the readiness bundle in machine-readable hover context.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the operator bundle.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the control bundle.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a control bundle combining queue path, operator bundle, and readiness bundle.

/admin/fulfillment/[orderId]/ship summary tiles must include the control bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship blocked-shipping alerts must preserve the shipping readiness bundle in machine-readable hover context.

/admin/fulfillment/[orderId]/ship checklist rows must preserve the shipping readiness bundle in machine-readable hover context.

/admin/fulfillment/[orderId]/ship navigation must expose a copy affordance for the operator bundle.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a control bundle combining queue path, operator bundle, and readiness bundle.

/admin/fulfillment/[orderId]/return summary tiles must include the control bundle with a copy affordance.

/admin/fulfillment/[orderId]/return blocked-return alerts must preserve the RMA readiness bundle in machine-readable hover context.

/admin/fulfillment/[orderId]/return checklist rows must preserve the RMA readiness bundle in machine-readable hover context.

/admin/fulfillment/[orderId]/return navigation must expose a copy affordance for the operator bundle.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include an audit bundle combining control bundle, status/source key, placed timestamp, and payment proof token.

/admin/fulfillment/[orderId] summary tiles must include the audit bundle with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a support bundle combining customer proof token, payment proof token, and placed timestamp.

/admin/fulfillment/[orderId] summary tiles must include the support bundle with a copy affordance.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the audit bundle.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include an audit bundle combining control bundle, route bundle, placed timestamp, and payment proof token.

/admin/fulfillment/[orderId]/ship summary tiles must include the audit bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a support bundle combining customer proof token, payment proof token, and placed timestamp.

/admin/fulfillment/[orderId]/ship summary tiles must include the support bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship navigation must expose a copy affordance for the control bundle.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include an audit bundle combining control bundle, status/source key, placed timestamp, and payment proof token.

/admin/fulfillment/[orderId]/return summary tiles must include the audit bundle with a copy affordance.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a support bundle combining customer proof token, payment proof token, and placed timestamp.

/admin/fulfillment/[orderId]/return summary tiles must include the support bundle with a copy affordance.

/admin/fulfillment/[orderId]/return navigation must expose a copy affordance for the control bundle.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a timeline bundle combining placed timestamp, next action, and shipping-notification eligibility.

/admin/fulfillment/[orderId] summary tiles must include the timeline bundle with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include an exception bundle combining status/source key, control bundle, and support bundle.

/admin/fulfillment/[orderId] summary tiles must include the exception bundle with a copy affordance.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the support bundle.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a timeline bundle combining placed timestamp, next shipping action, and shipment target status.

/admin/fulfillment/[orderId]/ship summary tiles must include the timeline bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include an exception bundle combining shippable eligibility, control bundle, and support bundle.

/admin/fulfillment/[orderId]/ship summary tiles must include the exception bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship navigation must expose a copy affordance for the audit bundle.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a timeline bundle combining placed timestamp, next RMA action, and RMA target status.

/admin/fulfillment/[orderId]/return summary tiles must include the timeline bundle with a copy affordance.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include an exception bundle combining RMA eligibility, control bundle, and support bundle.

/admin/fulfillment/[orderId]/return summary tiles must include the exception bundle with a copy affordance.

/admin/fulfillment/[orderId]/return navigation must expose a copy affordance for the audit bundle.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include an operations bundle combining route bundle, timeline bundle, and exception bundle.

/admin/fulfillment/[orderId] summary tiles must include the operations bundle with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a print bundle combining short order id, placed timestamp, and next action.

/admin/fulfillment/[orderId] summary tiles must include the print bundle with a copy affordance.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the exception bundle.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include an operations bundle combining route bundle, timeline bundle, and exception bundle.

/admin/fulfillment/[orderId]/ship summary tiles must include the operations bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a print bundle combining short order id, placed timestamp, and next shipping action.

/admin/fulfillment/[orderId]/ship summary tiles must include the print bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship navigation must expose a copy affordance for the support bundle.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include an operations bundle combining route bundle, timeline bundle, and exception bundle.

/admin/fulfillment/[orderId]/return summary tiles must include the operations bundle with a copy affordance.

/admin/fulfillment/[orderId]/return copy-RMA-handoff summaries must include a print bundle combining short order id, placed timestamp, and next RMA action.

/admin/fulfillment/[orderId]/return summary tiles must include the print bundle with a copy affordance.

/admin/fulfillment/[orderId]/return navigation must expose a copy affordance for the support bundle.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include a command bundle combining control, operations, and print bundles.

/admin/fulfillment/[orderId] summary tiles must include the command bundle with a copy affordance.

/admin/fulfillment/[orderId] copy-fulfillment-handoff summaries must include an escalation bundle combining support, exception, and audit bundles.

/admin/fulfillment/[orderId] summary tiles must include the escalation bundle with a copy affordance.

/admin/fulfillment/[orderId] order-action navigation must expose a copy affordance for the command bundle.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include a command bundle combining control, operations, and print bundles.

/admin/fulfillment/[orderId]/ship summary tiles must include the command bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship copy-shipping-handoff summaries must include an escalation bundle combining support, exception, and audit bundles.

/admin/fulfillment/[orderId]/ship summary tiles must include the escalation bundle with a copy affordance.

/admin/fulfillment/[orderId]/ship navigation must expose a copy affordance for the command bundle.