BETA-098 :: Run a structured beta usability and accessibility acceptance session #2005

BETA-098/100 · Workflow 4 — Security, Operations & Beta Launch

Goal

Automated tests cannot prove that new users understand identity, postage, requests, proofs, and recovery.

Who performs this and what they must achieve

As a product team, we want representative first-time users to attempt every critical journey on phone and desktop so comprehension, accessibility and release-blocking failures are found before launch.

Work to complete

• Test representative first-time users on signup, onboarding, address sharing, sending, requests, proof inspection, recovery, and feedback across mobile and desktop.
• Measure completion, errors, confusion, time, accessibility barriers, and support requests against explicit targets.
• Convert only release-blocking findings into the final triage gate; preserve evidence and owner.

Complete the operational or security loop, not only a document, dashboard or workflow file. Where this issue intentionally produces documentation, it must be exercised against the real beta path and include captured evidence.

Primary code and operational areas

• docs/product/beta-acceptance/
• tests/e2e/
• src/features/feedback/

Use least privilege, redacted evidence and repeatable commands. Any external provider-console step must also have a repository-side checklist or verification command; never place credentials in the issue or PR.

Release acceptance scenarios

• Sessions use test data and informed diagnostic consent.
• Critical comprehension or accessibility failures block launch.
• Findings are prioritized by user impact and linked to reproducible evidence.

Evidence required

• Execute the stated operator, security-tester or beta-user journey against a production-like environment.
• Include automated tests or repeatable scripts for every control that can be tested automatically.
• Record exact versions, configuration/manifest identifiers and redacted results.
• Show one successful path and the material failure, denial, recovery or rollback paths.
• Link every discovered blocker to an owner and reproducible proof; do not silently accept a failed gate.
• Run the relevant CI and release checks and include exact commands/results in the PR.
• Confirm that no plaintext message, token, password, seed, private key or production credential appears in artifacts.

Dependencies

• BETA-073 :: Complete WCAG-focused keyboard, screen-reader, contrast, and motion accessibility #1980 — BETA-073
• BETA-075 :: Prove the complete two-user web experience with no mocks #1982 — BETA-075
• BETA-096 :: Implement in-app beta feedback and privacy-safe diagnostic submission #2003 — BETA-096

Do not sign off this issue while a dependency or required release gate is incomplete.

Definition of done

The named actor can execute the stated procedure on the real beta stack; acceptance scenarios have verifiable evidence and ownership; failure and rollback behavior are proven where relevant; no critical unresolved defect remains within this scope; and required CI/release gates pass.