[lambig]

#571で残ったnull契約の指摘を、独立した二つの回帰試験で補強します。#248の内部整理で集約方法やOptionalの生成方法を変更する際に、現存する振る舞いの差を検出するための変更です。

• Iterables.toList：mapperが返したnullを、非null要素の間で順序どおり保持することを確認します。
• Optionals.optionally：downstreamの終了結果がnullならNullPointerExceptionになることを確認します。意図的なnull生成に限り、理由付きのPMD例外をメソッド単位に置きます。

基準は#571を含むmain 6308175593e78479cb65ca3e2ebb3472787fbb1b。製品コード、利用者の操作・データ経路、外部依存は変更しません。利用者の2026-10-23の継続指示とABServiceの既存権限に基づく、内部整理前の契約保存です。

対象head c74b37a625983cd923cdd0eb48192279fcbda84c をCorretto 25.0.4.10.1／固定Gradle 9.7.1で検証し、契約8試験・テスト規約1試験が成功しました。Checkstyle・PMD・Spotlessも成功しています。試験コードだけの変更に対する確認で、DB統合試験・全E2Eは再実行していません。共通VOの配置基準、モデル・入力・遷移の整理、切り出し先の判断は引き続き#248の残工程です。

レビュー観点：両試験がnull保持とnull拒否の違いを固定できるか、例外検証がdownstream終了後のOptional生成を通るか、PMD例外が意図的なnull生成だけに限定されているか。

Refs #471, #248, #571

[lambig]

Assistant Tech Lead／PM／POレビュー（2026-10-23）

判定：マージ可能。#571で指摘した2件のnull契約は適切にテストで固定されています。

Tech Lead

• iterableMappingPreservesNullResults は、Map::get のキー欠損によってmapperからnullを返し、[FIRST, null, LAST] の並びを検証しています。現行 Stream.toList() のnull保持と順序を、内部整理前の回帰契約として検出できます。
• optionalCollectorRejectsNullDownstreamResult は、Collectors.collectingAndThen のfinisherがnullを返す経路から、Optionals.optionally の Optional.of による NullPointerException を検証しています。downstreamの集約処理とnull終了結果を区別できています。
• @SuppressWarnings("PMD.ForbiddenUnusedLambdaParameter") は意図的にnullを作る試験メソッドに限定され、理由も記載されています。今回の変更はテスト1ファイル、30行追加のみで製品コードへの変更はありません。

検証結果

head c74b37a625983cd923cdd0eb48192279fcbda84c のPR CIはsuccessです。特にBackend full check がsuccessで、ログ上は backend/gradlew -p backend --no-daemon --console=plain check integrationTest --rerun を実行し、:integrationTest を経て BUILD SUCCESSFUL に到達しています。

PM（軽微な記録修正を推奨）

PR本文には「DB統合試験・全E2Eは再実行していません」とありますが、PRのCIでは integrationTest が実行されています。おそらくローカル検証範囲の説明なので、「ローカルではDB統合試験・全E2Eを実行していない。PR CIではintegrationTestを含むbackend full checkが成功。PlaywrightのRun E2Eはskipped」のように検証主体を分けて記載すると、証拠と整合します。この表現上の問題はマージ阻害とはしません。

今回の成果は#248/X1のG0回帰契約の補強であり、G1の内部責務整理やG2の所有先/API決定の完了には数えないのが妥当です。#471の総残工数を実行時間だけ機械的に差し引く必要はなく、次の計画再評価で残成果物の差分から更新してください。

PO

後続の抽出／置換で、nullの保持とnullの拒否を意図せず入れ替えることを検出できる状態になりました。現行仕様の保護と、公開APIとして保証するかの将来判断が分離されており、今回の目的を満たしています。

結論：#571からの指摘は解消。#572のマージを認めます。