sprint-coder-e2elisted

# sprint-coder E2E の実行と判定 このリポジトリの E2E は Playwright の **Electron** ドライバで実アプリを起動する。ブラウザテストではないので、web の常識（`page.goto`、`--headed`、trace viewer、リトライで緑にする）はほぼ当てはまらない。実行の失敗はアプリのバグとは限らず、**起動モードの選択ミス**であることが最も多い。だから「走らせる」より先に「どのモードで走るか」を確定させる。 ## 1. 実行前に確定させる 3 つのこと **(a) モードは必ず `dev` を明示する。** ```bash SPRINT_CODER_E2E_MODE=dev npx playwright test tests/e2e/<spec>.spec.ts ``` 環境変数を省くと `resolveE2EMode()`（[tests/e2e/helpers.ts](../../../tests/e2e/helpers.ts)）は `apps/desktop/out/` の中身を見て `packaged` を選ぶ。そこには古い packaged build（`@vibe-desktop-darwin-arm64` — アプリ名が改名前のまま）が残っており、この環境では packaged 起動がハングする（`@electron/packager` の zip 展開が `electron.icns` で決定論的に止まる既知の環境バグ。アプリ側の不具合ではない）。さらに `a11y-axe.spec.ts` は dev モードの CSP 例外（`script-src 'self' http://localhost:*`）に依存しているので、packaged では原理的に通らない。**つまり dev 指定忘れは「テストが落ちた」ではなく「まだ何も試せていない」状態。** **(b) 開発者の `npm start` は絶対に止めない。** globalSetup は 5173 に何か listen していればそれを**そのまま再利用**し、無ければ自分で `npm start` を起動して、自分が起動した分だけ後片付けする。ユーザーが手元で回している dev インスタンスを `pkill electron` などで消すと、その人の作業を壊したうえに次の実行が遅くなるだけで、何の得もない。稼働状況は次で確認できる（`[::1]` で listen している点に注意。`127.0.0.1` への curl は失敗する）: ```bash lsof -nP -iTCP:5173 -sTCP:LISTEN ``` **(c) テスト同士・開発者インスタンスとの衝突は既に解決済み。** 各 spec は `createUserDataDir()` で隔離した `SPRINT_CODER_USER_DATA_DIR` を使うので、SQLite も single-instance lock も独立している。「他のアプリが起動中だから落ちた」という仮説は、まずこの前提を疑う前に他の原因を潰すこと。 ## 2. 実行コマンド dev server が既に上がっていれば 1 spec は数秒で終わる。上がっていない場合、globalSetup が `npm start` を起動して ready を待つのに最大 90 秒かかる（これは失敗ではない）。 ```bash # 単一 spec（