ci(tests): composer audit の exit code を分類し、通知が理由を出し分けるようにする

[hideyukiMORI]

本日の週次 schedule（run 33367156425）は packagist の HTTP/2 502 で落ちました。composer audit は advisory の取得に失敗して exit 100 を返していましたが、ステップが素の run: composer audit --no-interaction だったため、「advisory を検出した（exit 1）」と同じ赤に潰れていました。

同日に #795 が入ったので、次に 502 で落ちると固定文言の Issue（🔴 NeNe: 週次 CI（schedule）が失敗しています）が自動起票されます。読み手には脆弱性の検出としか読めません。

区別は最初から在った

事象	exit	実測
advisory を検出	1	Found 2 security vulnerability advisories affecting 1 package
advisory を取得できない	100	到達不能 proxy で再現。本日の CI ログも Process completed with exit code 100

composer 2.9.8 で実走。ステップがそれを捨てていただけです。

変更

• unit に outputs.audit_status（clean / advisory_found / upstream_unavailable）を生やす。ジョブ間なので $GITHUB_ENV では届きません。
• audit ステップは出力を書いてから exit。100 は ::error:: で「監査は実行されていない・脆弱性の検出ではない」と明示し、赤のまま落とします。
• notify-failure が題名と本文を出し分け。上流障害は 🟠 の別題名にしたので dedup が題名ごとに効き、上流障害と本物が同じスレッドに混ざりません。
• ⚠️ 上流障害と断定するのは runtime-smoke が緑のときだけ。両方落ちていれば通常の赤へ倒します（「脆弱性ではありません」と言い切らない）。

採らなかった選択肢

• --ignore-unreachable: 取得失敗が exit 0 になります。「advisory が無い」と「確かめられなかった」が同じ緑に潰れ、このステップを独立させた理由（走ったかどうかが判ること・ci: tests.yml に composer audit ステップを追加（追加前 0 件を実測・フリート【PHP-AUDIT】の最後の1艦） (#791) #792）をそれ自身で無効化します。
• --locked: CI は直前に composer install を通すので installed == lock。installed を測る方が実際に動く木に近い。⚠️ 手元で叩くときは逆に --locked が要ります — 素の audit は installed を見るので、vendor/ が古いと解消済みの CVE が再燃して見えます（本 PR の調査中に実際に踏みかけました: lock=v5.8.4 なのに手元の vendor=v5.8.0 で smarty の CVE 2件が出た）。理由はコメントに残しました。

⚠️ リトライは過大評価しないでください

0/60/300 秒の3回を入れましたが短い瞬断の保険にすぎません。本日の障害は実測 26分49秒（NeNe 失敗 07:09:48Z → nene-vault の Weekly audit success 07:36:37Z）で、この約6分では救えませんでした。効くのはリトライではなく分類のほうです。

検証（スタブで実走・8パス）

audit 4パス（0 / 1 / 100×3 / 100→復旧）＋ notify 4パス（上流障害 / advisory 検出 / 上流障害だが smoke も赤 / 出力が空）。dedup も題名ごとに別 Issue へ落ちることを確認済み。

Ref: #795 / #792 / #793

[hideyukiMORI]

追記: 🟠 パスのリハーサル口を足しました（0e01b4d）

初版で「needs.unit.outputs.audit_status の伝播を実 CI で測っていない」と明示していた穴をふさぐためのものです。

なぜ simulate_failure では足りないか

#795 の simulate_failure は Setup PHP より前で exit 1 するので audit ステップに到達しません。＝分類も outputs も動かず、「advisory を取得できなかった」通知は一度も実行されないまま入ることになります。

入れたもの

• simulate_audit_exit（dispatch input）。値を受けると audit ステップは composer を呼ばずにその終了コードを返します（リトライも回しません。60+300 秒待つ意味がないため）。
• 🔴 notify-failure の if も同時に広げました。 audit ステップだけが input を読む形にすると、リハーサルは分類までしか届かず、検証したい伝播が一度も評価されません。条件は github.event_name == 'workflow_dispatch' で明示的に守り、schedule 時に inputs が null になる経路と混ざらないようにしています。

検証

simulate_audit_exit = 100 / 1 / 0 の3パス＋空（＝通常どおり composer を呼ぶ）をスタブで実走し、status=upstream_unavailable / advisory_found / clean と job の終了コードが期待どおりになることを確認。実 CI（run 33399795277）でも、pull_request では input が空で**通常経路（composer audit 実走）**を通っています。

⚠️ マージ前にリハーサルできるかは未確認

workflow_dispatch の inputs はデフォルトブランチ側の定義で検証される可能性があり、その場合 simulate_audit_exit はマージ前には渡せません（順序が「マージ → リハーサル」に反転します）。実際に叩けば判りますが、成功すると Issue が1本立つので、こちらでは回していません。

[hideyukiMORI]

✅ 🟠 パスを実 CI で実測しました — 未検証だった伝播が潰れました

hub がリハーサルを実行（gh workflow run tests.yml --ref ci/audit-exit-code-classification -f simulate_audit_exit=100）。run 33400091895 の結果をこちらでも独立に確認しました:

ジョブ	結果
unit	failure（強制 exit 100）
HTTP runtime smoke (Docker)	success
Open an issue when the scheduled run fails	success

→ Issue #798 が 14:01:48Z に 🟠 の題名で起票（14:02:30Z にクローズ済み・open は 0 に復帰）。本文もこの PR で書いた 🟠 用のものでした。

これで測れたこと

1. 🔴 失敗したジョブの outputs は届く — unit が failure なのに notify-failure が upstream_unavailable を読めています。初版で「未検証」と明示していた needs.unit.outputs.audit_status の伝播が、実測に変わりました。
2. 題名の出し分けが効く＝dedup が上流障害と本物を混ぜない。
3. SMOKE_RESULT ガードが効いている（smoke=success だったので 🟠 に倒れた）。
4. workflow_dispatch の inputs は指定 --ref の定義で解決される — ひとつ上のコメントで「マージ前には渡せず順序が反転するかも」と書いた懸念は否定されました。マージ前リハーサルで問題ありません。

この PR で未測定として残っているものはありません。