fix(plugin): walk-app — document iOS simctl-relaunch to reach a local Rails

[dadachi]

Hardens the one rough edge the iOS end-to-end walk exposed during testing.

The gap

mobile-mcp's plain mobile_launch_app points the iOS DEBUG build at its nonexistent compiled default host (https://api.<product>.com). Result: screens render, but every network call (sign-in, lists, mutations) silently fails. The walk-app skill didn't document how to fix it, so a full signed-in walk required ad-hoc discovery.

Android isn't affected — the APK bakes the API host in at build time (<PRODUCT>_API_* gradle properties), so a normal launch reaches a local Rails.

The fix (skill guidance only — no code)

Relaunch the iOS app via simctl with the SIMCTL_CHILD_ passthrough (the same env-bridge src/env-bridge.ts uses in the generator's visual mode):

xcrun simctl terminate booted <bundleId>
SIMCTL_CHILD_<PRODUCT>_API_SCHEME=http \
SIMCTL_CHILD_<PRODUCT>_API_DOMAIN=<HOST from out/<slug>/rails/.env> \
SIMCTL_CHILD_<PRODUCT>_API_PORT=<PORT from out/<slug>/rails/.env> \
xcrun simctl launch booted <bundleId>

Documented in walk-app's SKILL.md:

• §2 live-data prereq → "Rails up" and "app pointed at it", with the Android-vs-iOS difference made explicit.
• §3 → the exact terminate+launch recipe and where the values come from.
• §6 → the blank-data-screen failure mode now routes iOS users to the §3 relaunch.

Provenance

Discovered driving barbershop-queue on iOS end-to-end: sign-in (barber1@example.com) → barbershops list → reservation queue → swipe-to-Complete, round-tripped to the DB (state=completed). Rename held throughout (Shop→Barbershop, Shopkeeper→Barber, ItemTag→Reservation, Idled↔Completed → WAITING↔COMPLETED).

Test plan

• claude plugin validate ./plugin ✔ (docs-only change to a SKILL.md body).

🤖 Generated with Claude Code