Standing Order Agent / Delivery roadmap
Delivery roadmap

Build the deterministic product first. Connect the retailer second.

The implementation sequence proves domain behavior with fake adapters, then introduces live browser and retailer complexity behind contracts that already have acceptance tests.

14implementation steps
6milestones
4release gates
1critical path
Milestones

A staged route to the private prototype

M0 · Decide

Account scope, browser runtime, checkout boundary, retention, and model policy.

Week 0

M1 · Foundation

Nuxt, API, worker, Postgres, jobs, contracts, migrations, and telemetry.

Weeks 1–2

M2 · Simulate

Preferences, rules, products, schedules, and fake retailer produce a reviewable cycle.

Weeks 3–5

M3 · Intelligence

OpenAI and Anthropic adapters pass the same structured-output evaluation set.

Week 6

M4 · Discover

Authorized session, browser contracts, retailer observations, fixtures, and capability map.

Weeks 7–8

M5–6 · Assist

Live cart, slot, review, takeover, notifications, hardening, and pilot evidence.

Weeks 9–13
Critical path

The order work should happen

  1. 00

    Decisions and safety boundary

    Confirm the account, browser, model, data, notification, and manual checkout assumptions.

  2. 01

    Platform foundation

    Create the monorepo, Postgres, jobs, contracts, observability, and fake ports.

  3. 02

    Identity and connection records

    Add household ownership, consent, vault references, connect, reconnect, and disconnect.

  4. 03

    Preferences and settings

    Implement the versioned household operating policy and settings UI.

  5. 04

    Rules engine

    Implement the deterministic DSL, evaluator, simulation, and reason codes.

  6. 05

    Preferred products

    Build manual, history, list, cadence, alternative, and resolution flows.

  7. 06

    Scheduling and jobs

    Create timezone-aware, deduplicated occurrences and resumable tasks.

  8. 07

    Order orchestration with fakes

    Complete the entire scheduled-to-review experience before live automation.

  9. 08

    Intelligence adapters

    Add provider-neutral models, prompts, schemas, and evaluation gates.

  10. 09

    Browser control

    Add isolated Playwright providers, evidence, storage state, and takeover.

  11. 10

    Authorized retailer discovery

    Observe one action at a time, sanitize evidence, and build the capability registry.

  12. 11

    Assisted live cart

    Resolve products, reconcile cart, select slot, verify summary, and freeze review.

  13. 12

    Notifications and operations

    Add user alerts, audit timeline, monitoring, diagnostics, and recovery runbooks.

  14. 13

    Hardening and pilot

    Threat model, chaos tests, accessibility, retention, repeatability, and acceptance evidence.

Module sequencing

Dependencies and proof

ModuleDepends onPrototype proof
User PreferencesIdentity, databaseVersioned delivery, basket, automation, and notification policy
RulesShared contractsRepeatable allow, review, or deny with stable reasons
Preferred ProductsPreferences, rule contractsExact and alternative catalog from multiple sources
SchedulingDatabase, workerDeduplicated weekly and twice-weekly order cycles
Order OrchestrationPreferences, rules, products, scheduleComplete fake scheduled-to-review workflow
IntelligenceContracts, evaluation fixturesBoth providers pass schema and safety gates
Browser ControlVault, worker, telemetryIsolated session with evidence and takeover
Retailer IntegrationBrowser, discovery authorizationVersioned capabilities and assisted live cart operations
First sprint

Demonstrate the architecture before retailer automation

Build

  • Nuxt/API/worker workspace
  • Postgres migrations and Graphile test job
  • Shared time, money, ID, result, and event contracts
  • Fake Intelligence, Browser, Retailer, Notification, and Vault adapters
  • Initial order-cycle state machine
  • Minimal Nuxt activity timeline

Demo

Run now → fake cart prepares → review snapshot appears → request a change → a new snapshot appears → simulated manual checkout handoff.

The sprint is successful when the architecture is observable and resumable, not when it has a retailer selector.

Read the full Markdown plan
Release gates

Evidence before expansion

Gate A

Simulated workflow

Every module exists behind interfaces; fake success, review, failure, and retry paths pass.

Gate B

Retailer feasibility

Required capabilities are observed, documented, sanitized, and possible without bypassing controls.

Gate C

Assisted pilot

Live cart and slot repeatedly match the review snapshot; takeover and manual checkout work.

Gate D

Future confirmation

Retailer authorization, legal/security approval, approval hash, idempotency, and unknown handling pass.