ツリーで探したファイルを改名した後も、同じ文書を選択し続け、正しいタグを操作できるか。これは検索件数だけでは答えられません。テキストエディタ ツリー表示の検証では、検索結果、改名前の文書ID、改名後のパス、選択状態、タグ集合を一列につなぎます。今回保存されているCLI証拠はディスク検索と置換であり、改名後の選択やタグの画面表示は未実測です。
公開されているRune Studioの全機能詳細には、ファイルツリーからの選択範囲検索、インライン名前変更、Finderタグの表示とタグ操作が機能範囲として記載されています。この記載は、試すべき操作の場所と役割を決める根拠です。一方、STUDIO-354の試行で実際にボタンを押した記録ではありません。この記事では、公開仕様を「提供範囲」、固定CLI標本を「取得済みの値」、選択・名前変更・タグ画面を「利用者が確認する項目」として分けます。
検索結果から一つの文書を指名する
固定語Old354の全体検索は四ファイル五件、対象フォルダでは三ファイル四件でした。三件をEDIT、引用一件をKEEP、範囲外一件をARCHIVEへ分類しています。この実測は、検索範囲を固定し文脈を読む基礎には使えます。
ツリー操作の試験では、検索結果からincluded/chapter-2.mdを選びます。ファイル名だけでなく、相対パス、冒頭見出し、開始時SHA、検索語を含む行を控えます。同名ファイルが別フォルダにあっても、この四点なら対象を取り違えません。
改名前にタグのスナップショットを取る
改名はパスを変える操作、タグ編集は分類を変える操作です。二つを同時に実行すると、選択が外れた原因を切り分けられません。まず選択中の文書について、現在のパス、選択表示、既存タグの一覧を保存します。タグが0件の場合も空欄ではなく[]と書きます。
次に改名候補chapter-2-reviewed.mdを入力し、重複名や禁止文字の警告がないかを確認します。まだタグは触りません。改名直後にツリーの旧パスが消え、新パスが一件だけ存在し、本文SHAが変わっていないことを確かめます。
選択が新しい名前へ追従したかを見る
画面上の合格は、新しいツリー行が選択状態になり、編集領域が同じ冒頭見出しと検索行を示すことです。単に新ファイルが存在するだけでは、選択追従を証明しません。逆に、編集領域に同じ文があってもツリーが旧行を選んでいれば、表示の同期が取れていません。
この選択追従は今回操作していません。保持証拠には決定的な視覚assertionの仕組みがなく、CLIのファイル操作から選択色や選択ノードを推測できないためです。後日実行するときは、改名前、改名直後、再検索後の三場面を同じ試行番号で記録します。
タグは選択確認の後に一つだけ変える
新しいパスと選択文書が一致したら、検証用タグReviewed-354を一件だけ追加します。保存後にタグ一覧を再読込し、追加前の集合との差が一件だけかを確認します。他のタグを消したり、別文書へ付けたりしていないことが受入条件です。
検索をもう一度行い、新しいファイル名の結果を選択します。ツリー、本文、タグ領域の三箇所が同じ文書を指すかを見ます。このUI試験は手順であり、今回Reviewed-354が実際に表示されたという証拠ではありません。未実測の結果を完了値として台帳へ書かないようにします。
旧名が残る失敗をパス層で直す
改名後も旧パスが検索結果に残る場合、まず検索インデックスの表示だけが古いのか、ディスクに旧ファイルが残ったのかを分けます。ディスク上の新旧パス、本文SHA、検索結果の表示パスを並べます。旧ファイルが複製として残ったなら、勝手に削除せず、どちらを採用するか確認します。
選択が別文書へ移った場合はタグ操作を中止します。開始時スナップショットから対象SHAを探し、新パスを一件に固定して再選択します。タグを先に付けてから戻すと、別文書に残ったタグを見落とすためです。
ディスク検索の実測とUI課題を混ぜない
保持artifactではOld354の一件canary、残り二件、対象内旧語一件、範囲外旧語一件まで取得しています。これは検索候補の分類と保存後の逆検索を証明します。ツリーでの改名、改名後の選択維持、タグ表示を証明するものではありません。
記事の受入票は実測済み列とUI未実測列を分けます。前者には五件の所在と保存後SHA、後者には旧名、新名、選択文書ID、追加前後タグ、アプリ版を置きます。UI実測ができるまでは後者を空欄のまま不合格にし、説明だけで合格へ変えません。
三つの表示が同じ文書を指せば完了
最終試験では、新名のツリー行、編集領域の冒頭見出し、タグ領域のReviewed-354が同一の相対パスと内容SHAへ結びつくことを確認します。旧名が0件でも、別文書を選んでいれば合格ではありません。
失敗した試行は別の記録として残し、復旧では対象文書をSHAで再特定します。そのうえで改名だけをやり直し、選択追従を確認してからタグを一件追加します。検索、改名、選択、タグを順に分けることで、どの段階が壊れたかを次の担当者が再現できます。
再起動後の確認も、同じセッション内の選択維持とは別です。アプリを閉じる前に新パスとタグ集合を保存し、再起動後に検索から同じSHAの文書へ戻れるかを見ます。今回その操作はしていないため、再起動をまたいで選択やタグが保持されたとは書きません。セッション内と再起動後を二つの受入欄に分ければ、片方の成功で他方を代用せずに済みます。
引き渡す値は、実測済みの検索票では全体四ファイル五件、対象内三ファイル四件、canary一件、remaining二件、対象内旧語一件、対象外旧語一件です。UI確認票では旧パス、新パス、選択中の相対パス、本文SHA、変更前後のタグ集合を記入します。前者がそろっていても後者の空欄は埋まりません。この二枚を分けて渡すことが、公開仕様を実行結果のように見せず、次の担当者が同じ条件で名前変更とタグ操作を完了させる最短経路です。