Nothing automated exercises Metro's package-exports resolution

[toruiwasa]

Found in review of PR #94.

Field	Contents
Goal	A break in Metro's resolution of @pulseticker/* fails CI, instead of surfacing the next time someone runs expo start by hand.
Context	Review of PR #94 (feat/mobile-scaffold). plans/REQ-17_Mobile_App_MVP.md originally carried a standing gate — "Task 7 is not done until the import resolves in Metro" — which PR #94 satisfied with a one-time manual expo start. The Jest smoke test (apps/mobile/app/__tests__/index.test.tsx) does not substitute for it: moduleNameMapper in apps/mobile/jest.config.js rewrites the bare specifier to a file path, so it bypasses the exports map entirely and proves nothing about Metro. The two packages are ESM-only ("type": "module", only import/types conditions, no CJS fallback), which is exactly the shape that resolver changes break. See plans/DEBUG_mobile_scaffold_jest_metro_resolution.md.
Scope	Add a CI step that runs a real Metro bundle — expo export --platform ios (or --platform all) — so a resolution failure is a non-zero exit. Open decision: whether this rides in the mobile job added by #11 or is its own job; expo export is slower than jest+lint, so it may warrant a separate job or a path filter. Also correct the overstated comment in index.test.tsx ("a regression in either resolver surfaces here") — it covers jest-resolve only.
Test boundary	The bundler itself is the test; no new unit tests. Nothing is mocked.
Done when	Editing packages/schemas/package.json exports to break resolution turns CI red without anyone running Expo locally.
Branch	infra/ci-metro-export-check
Dependency	#11 (Task 8 — turbo.json mobile tasks + GitHub Actions CI). #11 as filed scopes the mobile job to jest + lint only, so this gap is not covered by it.
Risk	MEDIUM — no current defect; the exposure is that an exports-map edit or an SDK bump flipping unstable_enablePackageExports breaks the app bundle while the whole suite stays green.

[toruiwasa]

Correction to the premise above, from empirically probing this on feat/mobile-scaffold (2026-08-30).

The exports map is not load-bearing on its own. I broke packages/schemas exports to point at a nonexistent ./dist/NOPE.js, left main intact, and npx expo export --platform ios still bundled successfully. Read-only confirmation of why:

$ node -e "const {getDefaultConfig}=require(\"expo/metro-config\"); const c=getDefaultConfig(__dirname); ..."
unstable_enablePackageExports = true
mainFields = undefined
unstable_conditionNames = []

Package exports are enabled, but both packages also declare "main": "./dist/index.js", and Metro falls back to legacy main resolution when a specifier cannot be resolved through exports. So an exports-only regression is survivable, not fatal.

Two consequences:

1. This issue is lower severity than filed. The scenario "an exports-map edit breaks the app bundle while the suite stays green" is not reachable while main points at a valid file. The real remaining exposure is narrower: a change that breaks both (e.g. renaming the built entry, changing the build output path, or dropping main in favour of exports-only) — and an SDK bump that flips resolution behaviour.
2. The rationale comment in apps/mobile/metro.config.js is factually wrong. It states the packages have "no main-style CommonJS fallback for Metro to fall back to". They both have main. That comment is the stated justification for the current config, so it should be corrected rather than left to mislead the next reader.

The proposed fix (an expo export step in CI) is still worth doing — it exercises the real module graph end to end, which nothing else does — but it should be justified as general bundle-integrity coverage, not as exports-map protection specifically.