Production readiness and pilot release checks
epic-structured-post-session-report-screen-task-009 — Conduct a pre-pilot production readiness review of the post-session report screen. Verify that crash reporting captures any unhandled exceptions from the form engine, that analytics events (report_opened, report_submitted, report_draft_continued) are firing correctly, that no sensitive field content is logged, and that the TestFlight / internal track build includes the microphone permission strings. Create a smoke-test checklist for Blindeforbundet's 5-8 TestFlight testers.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Implementation Notes
Create a pre-release checklist document (Markdown or Notion page) that maps each acceptance criterion to a tester action and expected outcome — this becomes the official handoff artefact for the Blindeforbundet contact person. For log sanitisation, implement a wrapper around the crash reporter's addBreadcrumb and the analytics trackEvent methods that strips or replaces any value associated with a form field key before forwarding. Maintain an allowlist of safe property keys (organisation_id, form_version, step_index) rather than a denylist of sensitive keys, since new fields may be added later. For the TestFlight distribution, ensure the build configuration sets FLUTTER_BUILD_MODE=release and that no debug-only logging middleware is active.
Coordinate with the Blindeforbundet contact person to confirm tester Apple IDs are registered before uploading the build.
Testing Requirements
Manually execute the smoke-test checklist on a physical iOS device running the TestFlight build before distributing to testers. Verify each analytics event fires by inspecting the analytics dashboard in real time during manual test execution. Use a proxy tool (e.g. Charles or mitmproxy) to confirm no field content leaks in any outbound HTTP request to crash reporting or analytics endpoints.
Confirm the build crashes gracefully (reports to crash tool, does not hang) by triggering a controlled test exception. Run flutter_test unit tests covering the analytics event dispatch helper to assert correct event names and sanitised properties.
End-to-end integration tests that span Flutter UI → Supabase → RLS → storage are inherently flaky in CI due to network timing, test database state, and Supabase cold-start latency. Flaky tests erode confidence and slow the release pipeline.
Mitigation & Contingency
Mitigation: Use a dedicated Supabase test project with seeded org and user fixtures. Wrap all E2E tests in retry logic with a fixed seed and tear-down hooks. Keep E2E tests in a separate test suite that runs on-demand rather than on every PR, with unit and widget tests as the primary CI gate.
Contingency: If E2E tests remain unreliable, replace the Supabase calls in integration tests with a verified fake (in-memory repository implementations) and promote the real Supabase tests to a nightly scheduled run rather than blocking PR merges.
Health status, course interest, and assistive device fields contain personal health data. If any logger, analytics event, or crash reporter captures field values — through automated error serialisation or developer-added debug logs — the feature could violate GDPR and Blindeforbundet's data processor agreement.
Mitigation & Contingency
Mitigation: Audit all log statements in the report feature's code paths before the epic is marked done. Apply a PII-safe logging wrapper that strips field values from any serialised form state before it reaches the logger. Add a CI lint rule that flags direct logger calls within report-related files.
Contingency: If PII is found in logs post-launch, immediately disable the affected logging call and rotate any credentials that were exposed. Notify the data protection officer and document the incident per GDPR Article 33 requirements.