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

[kryputh]

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.

[Chigybillionz]

Hi, I’ve reviewed this issue and I’m confident I can fix it. I’d like to take it on.

[grantfox-oss]

🦊 GrantFox — @mysterio123865 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #2005)
2. Your PR will be reviewed by the Stellar-Mail maintainers

Good luck! Track your progress on GrantFox.

[bamiebot-maker]

Hi team! 🦊 I'm ready to tackle this task. My technical background aligns well with this issue, and I can have a clean, tested Pull Request ready for review within your expected timeframe. Please let me assign me so I can begin