背景
`release.yml` の "Smoke test .app bootstrap" は、起動した `.app` の stdout から `Ark server running on http://localhost:` を grep してポートを抽出し `curl http://localhost:\$PORT/\` で health を確認している。
codex review P5 で以下の指摘あり:
[P2] `PORT` はログから抽出した任意の数値をそのまま `curl http://localhost:\$PORT/\` に使っています。外部入力ではない前提ですが、依存バイナリやアプリ stdout に紛れた偽ログで runner 内 localhost の別ポートへ接続できます。
実際の脅威モデルは「runner 内の別 listen process を beacon と勘違いして smoke pass する」レベルで深刻度は低いが、smoke test の 検証性 という観点では「アプリ側で固定/予約したポート」を渡して一致確認する方が assertive。
やること
`@ark/server` の `startServer()` (または CLI `packages/server/src/cli.ts`) に 明示ポート指定 の経路を整える:
- `ARK_PORT` 環境変数 / CLI 引数で listen ポートを固定できるようにする
- Electron main (`packages/desktop/src/main.ts`) は引き続き `getAvailablePort()` で動的に決めるが、CI smoke では `ARK_PORT=4042` 等を渡して .app を起動 → workflow 側で同じ値の `curl` を打つ
- ポート抽出 grep を撤廃
スコープ外
release smoke 追加 PR (本 Issue を作るきっかけになった PR) で対応すべきと思いつつ、server コード変更を伴うため別 PR に切り出す。
背景
`release.yml` の "Smoke test .app bootstrap" は、起動した `.app` の stdout から `Ark server running on http://localhost:` を grep してポートを抽出し `curl http://localhost:\$PORT/\` で health を確認している。
codex review P5 で以下の指摘あり:
実際の脅威モデルは「runner 内の別 listen process を beacon と勘違いして smoke pass する」レベルで深刻度は低いが、smoke test の 検証性 という観点では「アプリ側で固定/予約したポート」を渡して一致確認する方が assertive。
やること
`@ark/server` の `startServer()` (または CLI `packages/server/src/cli.ts`) に 明示ポート指定 の経路を整える:
スコープ外
release smoke 追加 PR (本 Issue を作るきっかけになった PR) で対応すべきと思いつつ、server コード変更を伴うため別 PR に切り出す。