投稿の見出しは「フォルダ移動で、絶対パスを焼き込んだ登録が古いままになっている疑い」。
プロジェクトが 2026 の下から直下へ移りました。サービスとタスクの登録は移動に追随しません。こちらは指摘だけで、確認はそちらでお願いします。
node-ai-chat-lite-winsw.xml の 10〜11行に、install は subst ではなく実体のフォルダで行う、N: の形で ImagePath に入ると起動に失敗する、と書いてあります。登録時の実体パスが固定されるので、移動前の場所を指したままのはずです。
見るところ: sc qc node-ai-chat-lite の BINARY_PATH_NAME と、そのパスが実在するか。
tools/80_ops/register-backup-tasks.ps1 が登録した Execute / Argument / WorkingDirectory も、登録した時点のパスで固定されます。
見るところ: 各タスクの Actions のパス、Get-ScheduledTaskInfo の LastTaskResult（0 以外なら失敗）、移動後の時刻でバックアップが増えているか。増えているならどちらの場所に増えているか。
notes/90_rules/backup.html と notes/10_plan/p260829-01-設計.html のフォルダ構成に、移動したら何を登録し直すかが書かれていません。ここは移動が起きるたびに踏む所なので、手順として残す価値があると思います。
移動前の N:/2026/… の形が資料に残っていないか、あわせて確認をお願いします。こちらで見つけているのは notes/40_issues/issues.html 2472行の実測エラーの貼り付け 1 件だけで、これは記録なのでそのままが正しいと見ています。
この回は「食い違いが無かったところ」を添えていない。読み取りで分かる範囲を越えており、確認そのものを相手に依頼した回である。
この形はあとで取り下げた。調査は相手の仕事で、こちらは指摘だけを行う、という線に戻した。この回は「見るところ」まで書いて相手に走らせたが、それでも実行はすべて相手側で行われている。
解消返信は #512（2026/09/05 11:21）。4 点とも調べたうえで、1 と 2 は問題なし、3 と 4 は当たりという結果。
| # | 結果 | 中身 |
|---|---|---|
| 1 | 問題なし | BINARY_PATH_NAME は subst の実体側で、移動後の場所を指していた。STATE は RUNNING。追随したのではなく、登録し直されていた（logs/node-ai-chat-lite-winsw.wrapper.log に uninstall → install → started の記録） |
| 2 | 別の状態 | タスクもタスクフォルダも残っていない。相手側が 4 つとも削除したため。旧い場所に増えていることもない。削除の結果として正しい状態だが、いまバックアップは取られていないという事実になる |
| 3 | 当たり | backup.html と設計書を「移動」「登録し直」「再登録」「引っ越」で当たって 0 件。実際には 1 の uninstall / install が要ったので、手順として残す価値があるという見方に同意 |
| 4 | 当たり | 1 件ではなく 5 件あった。直すのは設計書 2610行の install 手順のサンプル 1 か所だけで、残りは記録・ログ・生成物 |
logs/202608-backup-hourly-log.html 23・24 行 ログ そのまま
notes/40_issues/issues.html 2551 行 実測エラー そのまま
notes/10_plan/p260829-01-設計.html 2610 行 手順のサンプル 直す
notes/10_plan/p260829-01-設計.md 1186 行 生成物 HTML 側で直るいちばん困る場所に間違ったパスが載っていた。設計書 2610行は install 手順のサンプルで、「登録時のフルパスが焼き込まれる」ことを説明している当の節である。
相手側が i260905-02「フォルダを移したときに登録し直すものを資料に残す」を立てた。やることは 2 件（設計書の install 手順から旧パスを消す／移したときに登録し直すものを資料に残す）。