Home / Ops / More in this area
Updated Jun 27, 2026 · Affirmology_ConsumerApp_PunchList_v1.md
Captured 2026-06-26 so nothing gets lost. Status per item.
In-app option for pop-up reminders the user selects from a list: nightly audio, midday, morning, etc. This is the engine of the nightly-dosing habit (Tier 3 #14 in the Identity Research map).
- BUILDABLE NOW: expo-notifications is already a plugin in app.json. Local scheduled notifications need no server.
- Proposed list to pick from: Nightly wind-down (default ~9pm, the before-bed audio), Morning activation (~7am), Midday reset (~1pm), plus a custom time. Each is a toggle + time picker; on enable, schedule a repeating daily local notification that deep-links to the right audio.
- Status: SPEC'd, not built. Needs Jeff's nod on the list + default times.
SHIPPED to TestFlight. Path that worked: flip apiBaseUrl to onrender; add NSPhotoLibraryUsageDescription to app.json infoPlist; untrack ios/+android/ (git rm -r --cached) so EAS prebuilds fresh from app.json (they were in .gitignore but still git-tracked); build with the username/password session (NO EXPO_ASC_* vars) + EXPO_APPLE_ID=jalanparker@gmail.com to reuse the cached Apple login, piping yes | script -q /dev/null for the y/n prompts so push capability synced (shared push key 83VCDWM9M9, shared distribution cert, own provisioning profile for ai.affirmology.app). Build 79933e00 FINISHED, eas submit -p ios --profile production --latest succeeded -> App Store Connect app 6784908433 (ai.affirmology.app), v1.0.0 build 6, processing at Apple. KEY GOTCHAS for next time: eas build:view --json returns nothing (use eas build:list --json); yes | floods the Apple-ID TEXT prompt and corrupts it unless EXPO_APPLE_ID is set first.
extra.apiBaseUrl = https://studio.affirmology.ai, which still 302s to the Cloudflare Access wall (verified 2026-06-26). A TestFlight build would fail login exactly like the earlier bug. onrender returns 200.https://affirmology-studio-api.onrender.com. Authed EAS via Jeff's EXPO_TOKEN (jeffparkerlove, @affirmology/affirmology).eas build -p ios --profile production --non-interactive fails at "Distribution Certificate is not validated for non-interactive builds." The iOS distribution cert must be created ONCE interactively; the ASC API key (YGGKMDU9H2) only handles submission, not cert creation. The cert is per Apple TEAM and shared across apps, so once the Atlas chat creates it interactively for @affirmology, this consumer build reuses it non-interactively. RETRY then: cd affirmology-app && eas build -p ios --profile production --no-wait then eas submit -p ios --profile production --latest. Alt: Jeff runs the build interactively once to create the cert.source: voice|text on every captured phrase; spoken input is richer and we want to know which is which.Affirmology_IdentityResearch_StructureMap_v1.md).