Post-build checklist — from a finished build to the first hand test

Status: Active · Last reviewed: 2026-11-14 · Owner: the owner, with the lead for the baseline step. Before: pre-build checklist. After: List 53.

Each step says what to do and what you should see. If it differs, stop and send what the last section asks for. Two phones are better than one: phone A is the main one, phone B plays the second person. This is the first time anything built since the update pause runs on a device; expect some things to be wrong, and say so rather than guess.

1. Install

1. The build service gives an install link when the Android build ends (eas build:list shows it). Open it on phone A and install. Installing over the old 0.11.0 app is fine; do not uninstall first (the old stored data is part of what the first start checks).
2. Expect: the app installs under the name Dabusi and opens. If Android refuses the install, send a screenshot of the refusal.
3. Open 프로필, then 설정, and read 앱 버전. Expect 0.12.0.

2. First start, light and dark

1. Close the app fully, set the phone to the LIGHT appearance, open the app. Expect a white start screen, no white-to-colour flash, then the sign-in page (signed out) or 홈 (signed in).
2. Close it, set the phone to DARK, open again. Expect a dark start screen (the same near-black as the app), no white flash.
3. Do not skip this: the dark start screen and the system bars following the app's own 화면 모드 choice are new and have only been tested without a device.
4. If the screen stays blank or white for more than ten seconds, or the app closes by itself, that is the one finding that matters most. Take a screenshot, note the time, and run yarn debug:logs --since=1h --kind=error on the build machine.

3. Sign in with the Dev button

1. On the sign-in page tap the "Dev" button under the two fields (the owner's instruction of 2026-11-15: preview builds enter through the developer account while the app is being examined). Nothing is typed. Typing the e-mail and password still works and is what a tester build will use.
2. Expect 홈 with content. If there is NO "Dev" button, the build was made without the two developer names (pre-build step 2, item 4): tell the lead. A build for testers who are not the owner must have none.
3. Close the app fully and open it again. Expect: still signed in, 홈 shows content.
4. If sign-in says the sign-in is unavailable or shows no page at all, the Supabase names were missing from the build (pre-build step 2). Send a screenshot.

4. The emulator boot-smoke (lead, on the build machine)

The boot-smoke is the cheap check that a build starts. The lead installs the new APK on the Android emulator Medium_Phone_API_36.1 (android-emulator.md) and checks: the app boots; the start screen is not blank; a cold boot is still signed in; 홈 shows content; a club page opens and closes; no crash-buffer entry (adb logcat -b crash). If the emulator is a zombie, boot it again; if the Windows link flaps, retry adb. The boot-smoke must reach a page with a bottom button (the sign-in page has one) and see it survive a second render, because the second W5 build passed "the app boots" and failed there. The result is entered in the release evidence. This step can run while you do steps 1 to 3 on the phone.

5. Update the update baseline (lead; the documented steps)

The baseline file says which build the update guard protects. It is changed only after the new build has been installed and has passed steps 1 to 4, never before.

1. eas build:view {build id} --json — copy gitCommitHash and fingerprint.hash. The fingerprint must equal the number the pre-build checklist recorded (step 4 there). If it does not, stop: the source moved natively after the build, and updates will be refused.
2. Edit apps/mobile/ota-compatibility-baseline.json: preview.runtimeVersion to 0.12.0; compatibleAndroidBuildId to the new build id; lastCompatibleSourceCommit to the gitCommitHash; nativeFingerprints.android to the fingerprint; append a line to evidence; leave compatibleIosBuildId null (no iOS build exists); lastCompatiblePreviewOtaGroup changes by the first update, not now.
3. Commit and push (the guard needs a clean tree level with its upstream), then yarn ota:preview only when the guard accepts. The full rule is in release-versioning-and-ota.md.
4. Record the build in release evidence (build id, source commit, fingerprint, the boot-smoke result, the install smoke of steps 1 to 3).

6. Seed the test world (only if the seed word was given)

The lead runs node scripts/run-scenario.mjs readiness_qa on hosted and sends you a message with what it made. Until then sign in and look; List 53 says which items need the seeded people. If the seed has not run, say so in your notes rather than skipping silently.

7. Walk List 53

Open List 53. It says which phone and which person for each item, what to tap, what you should see, and what to do when it differs. Mark each item pass, fail or skipped as you go (a one-line note for a fail is enough).

8. What to send back

1. The list with each item marked and the fails noted in one line.
2. Screenshots: every fail; the start screen in light and dark (step 2); 홈 after sign-in; 설정 showing 앱 버전. On Android, power plus volume-down takes one.
3. For anything that crashed, froze or showed a blank page: the time it happened (to the minute) and which phone.
4. The lead then runs, on the build machine, and reads the output: yarn debug:logs --since=2h --kind=error (errors from the phones) and yarn qa:health (the server's own failures and the cron jobs' verdicts; needs the developer switch on). Anything the app reported while you tested comes back through those two; you do not need to run them yourself.
5. Do NOT send a password, a key or a screenshot of one. A screenshot of the sign-in page with the password typed shows dots only, but crop it anyway.