What happened
#648 cleared the only two fixable npm advisories (js-yaml, nanoid). The remaining 18 (10 high, 8 moderate) are all transitive under the Expo 57 toolchain and none has an in-range fix — decisions/0013 has the per-item triage. The two real leaves:
image-size 1.2.1 (metro asset pipeline): two of its three DoS advisories have no fixed release in any version (OSV fixed: [])uuid 7.0.3 (under xcode 3.0.1, expo prebuild): the vulnerable path is v3/v5/v6-with-buf; xcode generates v4 IDs without buf, so it's unreachable — and forcing uuid 11 via overrides breaks xcode's ^7 range for nothing
npm audit's own suggestion is expo 57 → 53 + react-native 0.86 → 0.72, a double-major downgrade. Don't.
Ask
When the next Expo SDK (58+) ships:
- Take the upgrade in
phone-app/ (expo's own npx expo install --fix flow).
- Run
npm audit --package-lock-only and compare against the 18 in decisions/0013 — the question is whether the new toolchain dropped image-size or moved xcode off uuid 7.
- CI validates the rest:
phone.yml runs npm ci, typecheck, jest, the Android manifest permission audit and the Play listing limits on any phone-app/** PR. The manifest audit is the one to watch on an SDK bump — a new expo default permission fails it, and that's the gate working, not the gate being wrong.
- Update decisions/0013's phone-app section with what cleared and what didn't.
No urgency — these are build-time DoS advisories in dev tooling, not runtime surface. But the wall only shrinks when someone takes the SDK bump deliberately.
Where
phone-app/package.json + lockfile, decisions/0013, .github/workflows/phone.yml (read-only — it's the verifier)
What happened
#648 cleared the only two fixable npm advisories (js-yaml, nanoid). The remaining 18 (10 high, 8 moderate) are all transitive under the Expo 57 toolchain and none has an in-range fix — decisions/0013 has the per-item triage. The two real leaves:
image-size 1.2.1(metro asset pipeline): two of its three DoS advisories have no fixed release in any version (OSVfixed: [])uuid 7.0.3(underxcode 3.0.1, expo prebuild): the vulnerable path is v3/v5/v6-with-buf; xcode generates v4 IDs withoutbuf, so it's unreachable — and forcing uuid 11 via overrides breaks xcode's^7range for nothingnpm audit's own suggestion isexpo 57 → 53+react-native 0.86 → 0.72, a double-major downgrade. Don't.Ask
When the next Expo SDK (58+) ships:
phone-app/(expo's ownnpx expo install --fixflow).npm audit --package-lock-onlyand compare against the 18 in decisions/0013 — the question is whether the new toolchain dropped image-size or moved xcode off uuid 7.phone.ymlruns npm ci, typecheck, jest, the Android manifest permission audit and the Play listing limits on anyphone-app/**PR. The manifest audit is the one to watch on an SDK bump — a new expo default permission fails it, and that's the gate working, not the gate being wrong.No urgency — these are build-time DoS advisories in dev tooling, not runtime surface. But the wall only shrinks when someone takes the SDK bump deliberately.
Where
phone-app/package.json+ lockfile, decisions/0013,.github/workflows/phone.yml(read-only — it's the verifier)