RPA for our own surfaces — mini-agent-user for buyer-flow QA (parked 2026-05-23)

DARE.CO.UK · PARKED SKETCH · 2026-05-31

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

RPA is fine — even valuable — when pointed at our OWN sites (audreyinc.com, dare.co.uk, pa.gf.cx). Use it as a “mini-agent-user” that can simulate buyer journeys (ad click → landing → product browse → add-to-cart → checkout form) for QA, A/B path validation, and bug-detection. Open-source frameworks (Playwright > Cypress > Selenium) preferred.

Dan 2026-05-23: “RPA should be parked as a possible tool for our own work, not sure how, but it bridges the gap on many tedious activities that need batch-processing, running it against use cases where we need simulated use, like audrey-buying-paths via ad, into store, browse, check fields are operating, etc - then pass off to shopify… It’s like a mini-agent-user that we can run for bugs, assuming it can be programmed easily within a framework-open-source ideally.”

The distinction from the no-vendor-RPA rule

feedback_no_unsanctioned_rpa_on_vendor_accounts.md says: never batch-automate someone else’s account.

This sketch says: RPA on our own surfaces is a different game — totally legitimate, even valuable. The lines don’t blur because:

What “mini-agent-user” means here

A scripted browser that walks a real user journey end-to-end against our own surfaces:

• Buyer-flow A/B paths: ad-server URL → landing page → product page → variant select → cart → checkout. Each step verifies the next page loaded, the right elements are present, no JS errors.
• Form-field operational checks: every form on our portfolio surfaces gets a robot that submits valid + invalid input, catches broken validation or silent server errors.
• Cross-portfolio regression: change a CSS primitive in assets.gf.cx, robot smoke-tests every consuming surface for layout breakage.
• Voice-chat flows: drive archive.audreyinc.com chat widget through canned conversations, verify response shape.
• Receipt/PDF generation flows: trigger an insurance affidavit render, verify the PDF appears with correct content.

Open-source framework picks

Playwright is the answer for almost every case here. Same library Claude already uses for audrey_eras_screenshot.py would extend naturally.

What to build first (when this resumes)

A small framework at pa/_qa/ (or sibling repo):

�STASH6�

Run targets: - npm run qa:nightly — full suite, results posted to reports.dare.co.uk - npm run qa:smoke — fast subset (~30s) for pre-deploy checks - npm run qa:flow audrey_ad_to_purchase — single flow during dev

Output every run: HTML report with video/screenshot of any failed step + JSON for catalog ingest.

Pair-with later (out-of-scope-for-v1)

• A/B campaign tracking: when parked_sketch_shopify_full_lifecycle_2026-05-23.md’s teen-Audrey-via-Facebook campaign lights up, the agent-user validates each ad’s landing path is reachable + converts properly.
• Visual regression: pair with project_visual_regression_pixel_diff_parked.md — same surface, two different lenses (visual diff vs functional flow).
• Accessibility audit: each flow can run axe-core checks at each step.

Resume conditions

• Dan needs to validate a buyer journey before launching a paid campaign
• A high-stakes form (claim affidavit, checkout) needs pre-deploy smoke
• Visual-regression work begins and we want functional-flow as a sibling axis
• A surface keeps breaking after CSS primitive changes (signals time for the framework)

Cross-references

• feedback_no_unsanctioned_rpa_on_vendor_accounts.md — the explicit anti-rule this lives alongside (vendors NO, own sites YES)
• parked_sketch_shopify_full_lifecycle_2026-05-23.md — A/B testing landing paths is the first concrete consumer
• project_visual_regression_pixel_diff_parked.md — sibling QA pattern
• audrey_eras_screenshot.py — proves Playwright/headless-Chrome already integrates with Dan’s pipeline