Bug Reporting Guide

Use this page when logging issues found during manual QA, regression testing, or release validation.

What good bug reports include

Every report should include:

• short title
• build version and build type
• device model and OS version for mobile issues
• platform: iOS, Android, Web, or local dev
• account email and role
• network state: online, offline, reconnecting, or flaky
• exact steps to reproduce
• expected result
• actual result
• frequency: always, often, sometimes, once
• screenshot or screen recording if helpful

If the issue involves sync, also include:

• pending count before and after the action
• whether manual sync was attempted
• whether the item existed after app relaunch

If the issue involves permissions or native features, also include:

• whether the permission had already been granted or denied
• whether this happened on simulator/emulator or physical device

Severity guide

Severity	Definition	Examples
Blocker	Core use is stopped or data integrity is at risk	App will not launch, login impossible, offline capture lost
High	Major feature broken but app still usable in limited ways	Sync never clears, voice recording unusable, normal save flow broken
Medium	Important issue with workaround	Dashboard partly broken, event creation fails for some cases
Low	Minor issue or polish gap	Copy issue, spacing bug, small theming inconsistency

Suggested reporting flow

1. confirm the issue is reproducible when possible
2. collect screenshots or recordings immediately
3. capture the exact values and steps used
4. file the issue with Bug Report Template
5. note whether it is new, intermittent, or likely related to a known issue

Sync and offline issue add-on

Use these extra questions for queue, sync, or cache bugs:

• Was the item created online or offline?
• Did the pending count increase immediately?
• Did reconnect happen automatically or only after manual sync?
• Did the item duplicate after reconnect?
• Did the issue survive an app restart?
• Did the synced item appear in the admin portal?

Logs and evidence

Best evidence for most testers

• screenshot of the UI state
• screen recording of the repro path
• timestamp of when the issue occurred
• exact text entered, especially for capture and login flows

Extra evidence for engineering triage

• Expo / Metro logs from local mobile runs
• iOS device logs from Xcode device console
• Android logs from adb logcat or Android Studio
• browser console and network tab output for admin issues
• Vercel logs for backend or API failures when available

Before filing as new

Check whether the issue is already known or expected for the current build.

Do not hide repeats, but do note when a new test confirms an existing issue on a new build, device, or role.

Immediate escalation issues

Escalate right away if you find:

• launch crash
• auth broken for valid users
• offline capture loss
• sync corruption or repeated duplicates
• app lock dead-end with no recovery
• wrong-user data exposure

Related references

• Operations > Bug Report Template
• Operations > QA Tester Guide
• Operations > Release Signoff Checklist