Manual Validation Checklist

This checklist is the practical step-by-step guide for the next manual testing pass.

Use it in order unless a specific environment constraint forces a different sequence.

Working Protocol

Use this checklist as a living Milestone 0 runbook, not as a one-time note dump.

For each slice:

1. run one feature end to end
2. record either passed or the exact failing step
3. fix UI or integration issues before moving on
4. update this checklist if the real flow, labels, or prerequisites changed
5. commit only after that slice is fully re-verified

When a slice says to stay signed in, do not do extra cleanup at the end. Preserving state between adjacent slices keeps QA realistic and prevents repeated setup churn.

Preflight

Before starting any validation slice:

1. Decide whether the slice is a hosted-device slice or a local-backend slice and use the matching environment.
2. If the slice depends on live domain behavior, prefer a physical iPhone over the simulator.
3. If the slice depends on local-only behavior, start the backend with docker compose up --build -d.
4. Confirm the backend is reachable for the chosen environment before opening the app.
5. If prior state is confusing the flow, reset only the minimum necessary app, account, or simulator state rather than wiping everything immediately.
6. Record any UI tweaks or copy changes you make during the slice so they can be committed with the validated flow.
7. If the latest fix changed Info.plist, entitlements, or build-time host configuration, clean, rebuild, and reinstall before retrying the slice.

1. Hosted Auth On Device

Goal:

• validate the first real-device, real-domain auth path end to end using app.bagels.top and api.bagels.top
• cover account creation, session restore, password sign-in, magic-link email delivery, password-reset email delivery, universal-link handoff, and biometric re-entry

Suggested environment:

- ASPECTAVY_API_BASE_URL = https://api.bagels.top - ASPECTAVY_UNIVERSAL_LINK_HOST = app.bagels.top

• physical iPhone
• AspectAvy Dev build configured with:
• Apple Mail signed into the inbox used for testing

Status:

• Passed on 2026-04-07 against the hosted bagels.top staging environment

Before you start:

1. delete any existing AspectAvy or AspectAvy-dev build from the phone
2. in Xcode, clean the AspectAvy Dev build folder
3. rebuild and reinstall to the physical device so the current associated-domain entitlement is refreshed
4. pick a real inbox you can read on the phone
5. use a fresh email alias for deterministic registration if your provider supports plus-addressing

Steps:

1. Launch the app on the phone and confirm the login screen appears.
2. Confirm the version label at the bottom starts with 2.0.0.
3. Switch Mode to Create Account.
4. Enter a fresh test email, a display name, and a password.
5. Submit the account-creation form and confirm there is no stuck spinner or inline error.
6. Confirm the next screen title is Quick Return Sign-In.
7. Tap Enable Face ID and approve the biometric prompt.
8. Confirm the Location Access onboarding screen appears before the map shell.
9. Tap Allow Location and approve the system prompt.
10. Confirm the signed-in app shell loads, the account screen shows the expected email, and the map recenters toward the current device location.
11. Confirm the first map state is usable and not blank: forecast content should render when your location lands in coverage, and when it does not, the map should still remain interactive so you can pan or search into a forecast zone.
12. Force-quit and relaunch the app.
13. Confirm cold-launch session restore works without returning to the login screen.
14. Sign out.
15. Sign back in with the same email and password.
16. Confirm the app signs in cleanly and returns directly to the authenticated shell without replaying onboarding surfaces for the same account on the same device.
17. Sign out again.
18. Request an email sign-in link from the Email Sign-In Link section.
19. Wait for the real email on the phone and open the link directly from the email client.
20. If Safari opens a hosted page first, use the hosted continue action.
21. Confirm the app opens from the hosted link and completes sign-in successfully.
22. Sign out again.
23. Request a password-reset link from the Password Reset section.
24. Wait for the real reset email and open the link directly from the email client.
25. Confirm the app opens to the Password Reset screen.
26. Set a new password, submit it, and confirm the app signs in on success.
27. Sign out again.
28. Use Quick Sign-In with Face ID and confirm biometric re-entry succeeds without typing the password.
29. Stop while still signed in so the next slice can reuse authenticated state.

Watch for:

• email links opening in Safari but failing to return to the app
• hosted auth pages loading but missing their primary continue action
• password-reset links opening to the wrong app screen or failing to carry the token
• biometric quick sign-in surviving registration but failing after password reset
• location permission appearing only after the map shell loads instead of during onboarding
• location being granted in onboarding but the first signed-in map never recenters on the device
• the map centering correctly on the device location but still falling into a silent blank or blocked state instead of staying usable
• device builds still pointing at 127.0.0.1
• unexpected bundle or entitlement drift causing universal links to open only in the browser

Success result:

• the same hosted backend and domain work for account creation, email/password sign-in, magic-link sign-in, password reset, biometric sign-in, and cold-launch session restore on a physical device

2. Pinned Zones And Quick Brief

Goal:

• verify that forecast-zone details now support quick briefing plus pinned-zone preference flows

Suggested environment:

• physical iPhone or simulator using the current authenticated staging environment

Status:

• Passed on 2026-04-08 against the hosted bagels.top staging environment

Steps:

1. Launch the app and wait for forecast zones to finish loading.
2. Tap a forecast zone to open forecast-zone details.
3. Confirm the details sheet renders without error.
4. Find the quick briefing section.
5. Verify the quick briefing content is present and readable.
6. Tap Pin Zone.
7. Confirm the action succeeds without dismissing the sheet unexpectedly.
8. Verify the pinned-zone state updates in place.
9. Tap Make Primary.
10. Confirm the action succeeds and the UI now reflects the zone as primary.
11. Close the sheet and reopen the same zone.
12. Confirm the zone still appears pinned and primary.
13. Open a second zone and pin it.
14. Reopen the first zone and confirm it remains pinned.
15. Unpin the second zone.
16. Confirm only the second zone changes state.

Watch for:

• stale pinned state after reopen
• duplicate primary state across multiple zones
• quick briefing missing while the rest of the screen loads
• forecast narrative sections rendering duplicate text instead of collapsing repeated content
• actions that require leaving the details flow to take effect

Success result:

• pin, unpin, and make-primary all persist correctly
• quick briefing loads as a stable enhancement rather than a blocking dependency

3. Route Plan Trip Safety Workspace

Goal:

• verify the new pushed route-plan setup flow and saved-plan trip safety workspace end to end

Suggested environment:

• physical iPhone or simulator using the current authenticated staging environment
• ensure at least one saved route already exists so a plan can choose a primary route

Steps:

1. Open Library.
2. If no saved route plan exists yet, tap New Plan.
3. Confirm a brand-new plan starts directly on Plan Basics, not on a reused draft or a duplicated planner root.
4. Enter a plan name, notes, and at least one goal.
5. Continue to Team and confirm the flow pushes forward instead of replacing the whole surface.
6. Continue to Routes, select a primary route, and continue again.
7. On Review, save the plan and confirm a share link becomes available after save.
8. Open the saved plan again from Library if needed.
9. Confirm the saved plan root shows the plan overview plus a Plan Workspace entry.
10. Open Plan Workspace.
11. Confirm the workspace loads normally.
12. Scroll to the Route Brief section.
13. Verify a route briefing appears for the saved plan.
14. Scroll to the Trip Safety section.
15. If the plan has no active latest trip, confirm the start controls are visible.
16. Set an expected return time a short interval in the future.
17. Tap Start Safety Share.
18. Confirm the trip enters an active state without leaving the workspace.
19. Verify the status card appears with trip status and expected return.
20. Tap Share Live Status Page.
21. Confirm the share sheet opens and only shares the bare hosted URL.
22. Copy or open the generated URL.
23. Verify the hosted /trip-status/:token page renders meaningful trip status content in Safari.
24. Return to the app.
25. In the Decision Log section, enter a short decision note and save it.
26. Confirm the new note appears in the timeline list.
27. In the Field Observations section, enter a short observation and save it.
28. Confirm the observation appears in the observations list.
29. Tap Finish Trip Safety Session.
30. Confirm the trip status exits the active state cleanly.
31. Scroll to the Debrief section and confirm the debrief/history surface now loads.
32. Close the plan workspace and the plan root.
33. Reopen the same saved plan from Library.
34. Confirm the latest decision notes, observations, debrief/history, plan title, notes, goals, and primary route still load from the backend.

Watch for:

• pushed setup destinations dropping data when moving from one step to the next
• the saved plan reopening with blank title, notes, goals, or primary route
• start or finish actions leaving the UI in a disabled state
• share page opening with empty or stale content
• decision/observation saves succeeding but not refreshing locally
• reopened plan losing the latest-trip timeline

Success result:

• the pushed setup flow preserves plan data across steps, and the full saved-plan workspace works without custom debugging or app restarts

4. Forecast Override And Tools Stack

Goal:

• validate Update Forecast, Pro Tools, shared checklist tools, and the inclinometer from the live map

Suggested environment:

• iOS simulator with local backend
• use a zone with a current forecast revision and a signed-in account

Steps:

1. Launch the app and wait for forecast zones to load.
2. Confirm the top-right action stack appears under search/account with Update Forecast, Pro Tools, and Tools.
3. Confirm Update Forecast and Pro Tools are disabled if the map does not yet have a current forecast zone under the crosshair.
4. Move the map until a forecast zone is under the crosshair and confirm the two forecast actions become enabled.
5. Tap Update Forecast.
6. Confirm the warning screen appears and explains that only AspectAvy’s local effective level changes.
7. Continue to the checklist.
8. Select at least one field-observation reason and confirm the CTA enables.
9. Apply the override and confirm the sheet dismisses with the active zone changed to Considerable.
10. Verify the active zone now shows an override badge and an official-to-effective summary.
11. Open forecast-zone details for the same zone and confirm the same override state appears there.
12. Use the reset action to clear the override.
13. Confirm the effective level returns to the official level on both map and details surfaces.
14. Reopen the override flow and select None.
15. Confirm the flow dismisses without applying an override.
16. Tap Pro Tools.
17. If the signed-in account is not entitled, confirm the paywall path still appears.
18. In a debug build, use the paywall’s developer-tools shortcut to open membership testing and locally unlock Pro if needed.
19. Return to the map and confirm Pro Tools is now testable without weakening production gating.
20. If the account is entitled, continue past the warning screen.
21. Confirm the flow uses pushed navigation instead of one expanding screen.
22. Select one or more defensible reasons and continue to level selection.
23. Pick a target level and apply the override.
24. Confirm the selected level becomes the effective level and the zone displays override messaging.
25. Reopen Pro Tools, select No reason, and confirm the flow exits without applying a change.
26. Open Tools and launch Trailhead Checklist.
27. Confirm the checklist renders with full-row tap targets and selections can be toggled reliably.
28. Dismiss it and repeat with Drop-In Checklist.
29. Launch Inclinometer.
30. Confirm the angle display updates, zeroing works, reset works, and the forecast-band guidance appears when an active forecast zone is available.

Watch for:

• map action buttons enabling for the wrong crosshair zone context
• paywall test-unlock path bypassing the normal Pro gating outside debug
• override apply succeeding but not updating map/details state locally
• clear/reset leaving stale effective-level UI behind
• None or No reason still creating an override
• checklist rows only responding when the text/icon itself is tapped
• inclinometer motion staying stuck at zero or not recovering after zero/reset

Success result:

• forecast override flows, checklist tools, and inclinometer all work end to end from the live map shell

5. Settings Persistence And Layer Preferences

Goal:

• validate the dedicated settings surface plus backend-backed map and layer preferences

Suggested environment:

• iOS simulator with local backend

Steps:

1. Open the map and tap the dedicated settings button.
2. Confirm the settings surface is distinct from Account.
3. Change the forecast polygon opacity preset.
4. Open layer settings from the settings surface.
5. Toggle at least two layer families away from their defaults.
6. Change default camera mode and map style if available.
7. Save settings and dismiss the sheet.
8. Confirm the live map immediately reflects the new opacity preset and layer visibility.
9. Close and relaunch the app.
10. Confirm the same map style, camera mode, polygon opacity preset, and layer visibility choices restore from the backend-backed settings domain.
11. Reopen Account and confirm legal/privacy and delete-account controls are no longer crowded into the account identity surface.
12. Return to Settings and verify delete-account is present in the danger-zone area.

Watch for:

• layer settings saving locally but not surviving relaunch
• settings writes overwriting unrelated server-backed preferences
• map rendering ignoring the saved opacity preset
• a mismatch between settings defaults and the live layer-management UI

Success result:

• settings persist across relaunch and are respected by both layer management and live map rendering

6. True Offline Usage Without Network

Goal:

• validate that a downloaded region is actually usable after network loss

Suggested environment:

• simulator with network disabled if practical
• or a device with a reachable backend during download, then full offline mode after download

Steps:

1. Launch the app with network available.
2. Download an offline region that includes forecast, routes, incidents, and base map coverage.
3. Confirm the download finishes completely.
4. Navigate into the downloaded region while still online and verify the map content is present.
5. Disable all network access.
6. Force close the app.
7. Reopen the app fully offline.
8. Wait through startup and bootstrap attempts.
9. Confirm the base map still renders inside the downloaded region.
10. Confirm forecast and overlay content remain visible inside the region.
11. Pan around within the downloaded boundary.
12. Confirm the app remains stable and does not collapse into a hard loading failure.
13. Open Offline Maps and confirm the downloaded region still appears.
14. Expand the downloaded region and tap View on Map.
15. Confirm the sheet dismisses, the map fits back to the saved region, and the offline coverage outline appears even if the offline layer was hidden.
16. Confirm View on Map does not leave the region in a sticky selected/highlighted state after the sheet dismisses.
17. Tap the offline region outline or label on the map and confirm Offline Maps reopens with that region detail already pushed.
18. Tap back to return to the main Offline Maps list, then dismiss the sheet.
19. Confirm the region highlight clears after the detail or sheet is dismissed.
20. Open Layer Settings and verify Offline Coverage is available as a normal map layer toggle.
21. Turn Offline Coverage off if needed, tap View on Map again, and confirm the region can still be temporarily revealed and focused.
22. If possible, open a saved route or route plan inside the region and verify its geometry still renders.

Watch for:

• startup failing hard because bootstrap/config requests cannot complete
• blank map tiles inside a region that was previously downloaded
• overlays disappearing even though the region claims to include them
• View on Map failing to relocate the camera or temporarily reveal the saved region
• offline-region taps failing to reopen Offline Maps with the tapped region detail already pushed
• region highlight lingering after backing out of Offline Maps
• Offline Coverage visibility getting stuck on or off after using View on Map

Success result:

• downloaded map content remains meaningfully usable with no network

7. Purchase Sandbox / TestFlight

Goal:

• validate real purchase, restore, and entitlement reconciliation

Suggested environment:

• signed build with App Store sandbox or TestFlight

Steps:

1. Sign in with a clean test account.
2. Open the paywall from a gated surface.
3. Complete a purchase.
4. Confirm the purchase flow closes cleanly.
5. Open Account and confirm membership state updates.
6. Revisit a previously gated feature and confirm it is now unlocked.
7. Trigger Restore Purchases.
8. Confirm restore completes without duplicating entitlements.
9. If web checkout is available in the current storefront, validate that /membership handoff returns to the app and refreshes entitlements.

Watch for:

• purchase success without backend entitlement change
• restore succeeding in StoreKit but not changing app state
• paywalled surfaces still using stale free-tier limits

Success result:

• purchase, restore, and entitlement reconciliation all agree

Reference:

• purchase-sandbox-validation-playbook.md

7. Push Notifications

Goal:

• validate permission, registration, delivery, and open behavior

Suggested environment:

• physical device preferred

Steps:

1. Install and open the app on device.
2. Trigger the push permission prompt.
3. Grant permission.
4. Confirm the device registers successfully with the backend.
5. Send a test notification through the supported environment.
6. Confirm the notification is delivered.
7. Open the notification.
8. Verify the app opens into a sensible route or target screen.

Watch for:

• permission accepted but no backend registration
• delivered notification opening to a dead end

Success result:

• push permission, registration, delivery, and open routing all work

7. Universal Links And Safari/Web Handoff

Goal:

• validate the hosted domain, AASA behavior, and Safari handoff

Suggested environment:

• physical device with a signed build and hosted domain configured

Steps:

1. Create or obtain a hosted route, route-plan, or invite URL.
2. Open the link in Safari.
3. Confirm the hosted page renders correctly.
4. Confirm Safari offers or performs app handoff.
5. Open the link into the app.
6. Verify the app lands on the expected route, plan, or invite surface.
7. Repeat once from a cold launch.
8. Repeat once with the app already running.

Watch for:

• hosted page rendering but no associated-domain handoff
• app opening but failing to route to the correct content

Success result:

• the hosted page and app handoff both work reliably

8. On-Device Track Recording

Goal:

• validate real movement, pause/resume, save, and finalization on device

Suggested environment:

• physical device during real movement

Steps:

1. Start a new track recording on device.
2. Move enough to generate a visible track.
3. Confirm point count and geometry continue to grow.
4. Pause the recording.
5. Wait briefly, then resume.
6. Confirm the resumed track continues cleanly.
7. Finish and save the track.
8. Open the saved track from Library.
9. Confirm geometry, duration, and any elevation-derived values look reasonable.

Watch for:

• no new points despite movement
• broken geometry after resume
• save succeeding but reopened track missing data

Success result:

• device recording behaves predictably enough for product confidence

Recording Results

For each slice, capture:

• pass or fail
• device or simulator used
• exact failure symptoms
• whether the issue is reproducible
• screenshots if the UI is involved

Update development/manual-validation-remaining.md after each validation slice so the remaining list stays current.