Confirmed household history
Read a bounded Past Purchases view, preserve exact retailer product references, and let the user select which products may recur.
MVP implementation
Yes—we can prove the idea with one focused live workflow.
The MVP connects one household to Stop & Shop, imports selected Past Purchases, applies a small deterministic rule set, prepares the live cart, and presents the result in a review dashboard.
1private household
6initial rules
1browser adapter
0automated checkout
Recommendation
Build the proof around one repeatable promise
The MVP succeeds when it reconstructs a useful recurring cart from account-owned purchase history without surprising products, duplicate lines, or hidden decisions.
Small deterministic rule set
Cadence, quantity, exact-product policy, price ceiling, unavailable-item behavior, and basket maximum decide the cart plan.
A live cart ready for review
Add allowed items through an authorized browser session, verify the resulting cart, and show added, skipped, and flagged products.
An LLM is not required to prove the core idea
Use deterministic data and rules for the first live cart. An LLM may summarize changes, but product identity, price limits, quantities, and cart actions remain outside the model.
Architecture
The smallest useful technical slice
The MVP keeps the target module boundaries but combines the API and background runner operationally. This reduces infrastructure without creating throwaway retailer or domain logic.
Scope
What is in and out of the MVP
| Capability | MVP | Deferred |
|---|---|---|
| Households | One private household with one retailer connection | Self-service multi-user onboarding and household roles |
| Authentication | User signs in directly in visible Chrome; encrypted short-lived session reuse | Credential storage, unattended MFA, multiple devices |
| Product source | Selected Past Purchases and manual exact products | Full-history prediction, bidirectional saved-list sync |
| Rules | Six explicit deterministic rules | Natural-language rule authoring and complex optimization |
| Cart | Read an empty/dedicated cart, add exact products, verify quantities | Complex pre-existing cart merging and automatic substitutes |
| Schedule | Run now, then one or two weekly schedules after stable live runs | Vacations, seasonal cadence, and advanced retries |
| Delivery | Read available slots and select the first slot matching ranked day/time rules | Fee optimization, fallback-day negotiation, and slot repricing |
| Checkout | Dashboard review and manual retailer checkout | Approval-required or autonomous final confirmation |
| Intelligence | Optional plain-language review summary | LLM-driven basket planning and browser actions |
MVP flow
Eight steps from account to review
- 01
Connect Stop & Shop
Open a dedicated visible Chrome profile. The user signs in directly and completes any MFA or security challenge.
- 02
Import Past Purchases
Read a bounded history view and import exact retailer product ID, name, size, last-seen price, and purchase dates where visible.
- 03
Confirm recurring products
The dashboard asks the user to select roughly 10–30 staples and assign quantity, cadence, and maximum price.
- 04
Create a cart plan
The planner selects due products, evaluates all six rules, and shows exactly what it intends to add before touching the retailer cart.
- 05
Prepare the live cart
Playwright adds one exact product at a time, verifies the line and quantity, and stops on session, price, availability, or page-state uncertainty.
- 06
Select delivery time
Read currently available slots, rank them against the household's allowed windows, select the first acceptable option, and verify the displayed fee and time.
- 07
Re-read and review
The retailer-visible cart and slot are read back into a snapshot. The dashboard explains added, skipped, unavailable, price-flagged items, fees, and delivery time.
- 08
Continue manually
The user opens Stop & Shop, makes last-minute changes, verifies the delivery details, and completes checkout.
Dashboard
Five screens are sufficient for the proof
Overview
Connection status, next run, product count, active rules, recent result, and one prominent Prepare cart button.
Past Purchases
Imported exact products with search, select, quantity, cadence, maximum price, and source evidence.
Rules & schedule
Six supported policies, ranked delivery windows, run-now control, and one or two weekly preparation times after live reliability is proven.
Live activity
Current browser step, progress, added/skipped count, authentication request, stop, and takeover.
Cart review
Exact product, quantity, observed price, rule result, cart total, delivery fee and slot, difference summary, and Open Stop & Shop action.
Rules
The six policies to implement first
| Rule | MVP behavior | Why it matters |
|---|---|---|
| Exact product | Add only the confirmed retailer product reference | Prevents same-name or wrong-size surprises |
| Cadence | Every run, every two weeks, or inactive | Proves recurrence without prediction |
| Quantity | Use one fixed confirmed quantity per product | Keeps the cart plan explainable |
| Maximum item price | Skip and flag when current price exceeds the limit | Protects against unexpected price changes |
| Unavailable behavior | Skip; do not substitute automatically | Removes ambiguous matching from the critical path |
| Basket maximum | Stop planning when the verified expected total would exceed the hard limit | Creates a clear financial safety boundary |
Decisions
What you need to decide before implementation
The recommended column is the fastest route to a meaningful private proof. Change it only when the alternative is important to what you want to learn.
| # | Decision | Recommended MVP default | If you choose differently |
|---|---|---|---|
| 1 | Who uses it? | Only your household | Multi-user adds onboarding, tenancy, recovery, consent, and support work |
| 2 | Where does the browser run? | Dedicated local Chrome reached from the Docker VPS through constrained reverse SSH | Cloud browser adds provider cost, remote MFA, artifact retention, and residency decisions |
| 3 | How long is a session reused? | Encrypted reuse for up to 7 days, or until retailer rejection | Login every run is safer but adds friction; longer reuse increases session risk |
| 4 | How much purchase history? | Last 12 weeks, user selects 10–30 staples | More history adds paging, normalization, and misleading older preferences |
| 5 | Existing cart policy? | Require an empty or explicitly dedicated cart | Merging requires ownership tracking and conflict UX |
| 6 | Substitutions? | Skip unavailable items; no automatic substitutes | Substitutes require candidate data, matching, size/price rules, and more review states |
| 7 | When does it run? | Run now first; add one or two weekly schedules after three stable runs | Scheduling immediately makes session expiry and unattended failure part of the first proof |
| 8 | Delivery-slot selection? | Include ranked allowed windows and one verified selected slot | More advanced optimization expands discovery into fees, fallback days, and slot expiry |
| 9 | Final checkout? | Always manual | Agent confirmation requires separate authorization, approval binding, and ambiguity handling |
| 10 | LLM role? | Optional explanations only | Model-driven planning needs evaluation data and increases uncertainty before the core hypothesis is proven |
| 11 | Notification? | In-app status plus one cart-ready email | SMS adds provider setup, consent, and delivery cost |
| 12 | What proves success? | Three live runs with at least 90% of available selected items correctly added and zero duplicates | Without an agreed metric, a visually working demo may not prove usefulness or reliability |
Build slices
A practical MVP sequence
Slice 0 · Feasibility
Observe login, Past Purchases, product identity, add-to-cart, cart read-back, and security challenges in an authorized visible session.
Slice 1 · Simulated dashboard
Implement the Nuxt screens, product preferences, six rules, cart planner, activity timeline, and fake retailer.
Slice 2 · Live connection
Add dedicated Chrome, user login, encrypted storage state, Past Purchases import, and read-only product evidence.
Slice 3 · Live cart + slot
Add exact products one at a time, select an allowed delivery time, verify both results, and display the review snapshot.
Slice 4 · Repeatability
Add run history, cart-ready email, retries before side effects, stop/takeover, and one or two weekly schedules after three successful manual runs.
Deployment · Docker VPS
Run the app and Postgres in Compose; reach dedicated local Chrome through a bridge-only reverse SSH listener and show connectivity in the dashboard.
Acceptance
Evidence that the MVP proves the idea
Functional proof
- User completes Stop & Shop login without credentials entering application logs
- Past Purchases imports exact product references
- User confirms at least ten recurring products
- Planner produces the same output for the same facts and rules
Live cart proof
- At least 90% of available selected items are added correctly across three runs
- No duplicate cart line is created by a retry
- An allowed delivery slot is selected and verified
- Dashboard cart and slot match the retailer-visible review state
Control proof
- User can stop or take over an active run
- MFA, CAPTCHA, or unknown page state pauses safely
- Existing non-empty cart is detected before mutation
- Final checkout always remains with the user
Learning proof
- Measure time saved versus manually rebuilding the cart
- Record how many imported products stay active
- Record review changes before checkout
- Decide whether scheduling, slot selection, and smarter recommendations justify the next phase
Recommended default decision package
One household; Docker VPS; dedicated local Chrome through reverse SSH; seven-day session reuse in that profile; twelve weeks of history; 10–30 exact staples; empty cart; no substitutions; ranked delivery windows; manual checkout; in-app plus email; success after three accurate live runs.
The browser is local even though the agent is in the cloud
The VPS worker connects to Chrome only through a reverse SSH listener bound to the private Docker bridge. View deployment architecture →