test: executeProcess の Oracle 要素を抽象化してフレークを構造的に断つ

[GeneralD]

CustomScriptLyricsDataSourceImplTests の実サブプロセス 2 件が で間欠的に落ちる。原因はの oracle（合否を決める判定要素）が非的な 依存に直結していること。側の小細工では直らず、側で oracle 要素を化しない限りし続ける。

フレークの個別対処はこれまで複数回行われている（#146 TrackInteractor、#213 DecodeEffectState）。クラスのが場所を変えてしているので、対症療法ではなくで断ちたい。

実測（ #339 の ）

SHA の再実行で success したためフレーク確定。落ち方は次のとおり。

	期待	実測
executeProcessRealSubprocessDoesNotHang	/bin/echo が status 0	status -1（= 3000ms timeout 発火）、stdout 空
executeProcessTimeoutReturnsPromptly	100ms timeout が 5s 以内に返る	19.86s

/bin/echo が 3 秒で timeout するのは lyra のコードの性質ではなく、走らせた runner の性質。

なぜフレークするのか — Oracle が化されていない

processRunner という seam は既にあり、呼び出し側のはこれを stub して的になっている。しかし executeProcess はその seam の live そのもので、static func のため @Dependency を持てず、次の 4 つを直接ハードワイヤしている。

1. 実クロック — timeout 発火が asyncAfter(deadline: .now() + ...)。SIGKILL エスカレーションの +500ms も
2. 実プロセス — Process() / process.run()
3. 実 global queue のスレッドプール — stdout/stderr の drain が readDataToEndOfFile() でブロッキング。1 呼び出しにつきプールのスレッドを 2 本、子プロセスの生存中ずっと占有する
4. 実パイプ

、executeProcess をする手段が「実物を回して実時間を測る」しか無くなり、の oracle が次を測ってしまう。

#expect(elapsed < .seconds(30))  // 50 個の実サブプロセスを runner が十分速く捌けたか
#expect(elapsed < .seconds(5))   // 100ms の timer が実時間で発火できたか

#expect(result.status == 0) すら実スケジューリング依存になる（timeout が先に発火すれば -1）。

なお 3 は本番側のでもある。Swift Testing は suite を並列実行するため、並列の drain がプールを圧迫すると timeout work item も drain 自身もする — された症状と整合する。これは #308 で潰した waitUntilExit() hang と同系統の話。

該当箇所

• Sources/LyricsDataSource/CustomScriptLyricsDataSourceImpl.swift:119-204 — executeProcess static
  • :186-187 timeout の実クロック / :181 SIGKILL の +500ms
  • :157-165 .global() 上のブロッキング drain ×2
• Tests/LyricsDataSourceTests/CustomScriptLyricsDataSourceImplTests.swift:249-287 — 実時間 oracle の 2 件（:269, :286）
• Sources/Domain/Misc/ProcessGateway.swift:29-36 — 述

の化との関係

ProcessGateway（Domain）+ DarwinGateway は既にあり、 を DataSource 層で消費するのは .claude/rules/architecture-boundaries.md の文書化された型（例: AudioTapGateway、ConfigWatchGateway）。現在の static はその型からの。

ただし gateway 側にも穴がある。の操作は

• run(executable:arguments:) -> Int32 — ・なし
• runCapturingOutput(executable:arguments:) -> String? — ・timeout なし・stderr なし・environment なし

で、async + timeout + stdout/stderr capture を持つ操作が無い。各 DataSource が独自 static を抱えているのはこの穴がで、つまり化のがと非性を同時に生んでいる。

案

1. ProcessGateway に async + timeout + stdout/stderr capture の操作をし、DarwinGateway に live を置く
2. 2 つの executeProcess static をそこへ移送してを解消
3. timeout をクロック注入で駆動する（@Dependency(\.continuousClock)。例: refactor: inject Clock and ProcessSnapshot into BenchmarkHandler #186 BenchmarkHandler への Clock/ProcessSnapshot 注入）。static を外すがある
4. ブロッキング drain をやめる（readabilityHandler か専用 queue）。プール枯渇そのものを消す — だけでなく本番の話
5. oracle をる。自動・確信度ベースのメタデータ+歌詞解決サイクル #308 の hang 退行ガードは「しない fake process + TestClock で timeout が論理的に発火するか」を実時間待ちゼロでする形にできる。「50 個の実 echo が 30 秒以内に終わったか」より力が高く、かつ的
6. 残す実サブプロセスは timing oracle を持たない薄いスモークに縮小（status/stdout のみ、elapsed なし）

当面の緩和として @Suite(.serialized)（実プロセスは global な 状態。#315 の CoreAudioTapGateway スモークと考え方）もだが、これは緩和であって解決ではない。

して見つかったこと

YouTubeWallpaperDataSourceImpl.executeProcess（:228-274）は配管ので、しかも #308 で lyrics 側からされた waitUntilExit() が :269 に残っている。timeout も無い。

ただし #308 の hang トリガは「短命プロセスの反復呼び出し」で、こちらは yt-dlp/ffmpeg（長寿命・低頻度）なので条件が違う。現にが出ているという主張ではないが、案 2 で 1 箇所に集約すれば自然に消える。

スコープ

config watch（#338 / #339）のスコープ外の follow-up。フレーク自体は #339 のマージをブロックしていない（ SHA の再実行で green、マージ済み）。