rei-scout 公開反映を藤本さん PC の Windows Task Scheduler で回す phase (i) を実装完走。 script 3 本 land 後、 藤本さんの通し試験で 「失敗しているのに成功に見える」型の 5 罠 が一挙発掘され、 全対処された。 副産物として STEP 1651 の page が公開復旧。 同時に chat-Claude 第 6 回 report 応答で rei-scout 収集規則 handbook も修正。
実装 side (私 = Claude) と通し試験 side (藤本さん) が綺麗に分業。 unit test PASS だけでは見えない失敗を、 実 E2E 通しが全て掃除した。
| side | 作業 |
|---|---|
| 実装 | rclone install + 専用 worktree + script 3 本 + PR 起票 + Windows/Git Bash 適応 |
| 通し試験 | E2E 通し + 5 罠発掘・全対処 + PR merge + rclone OAuth + 7 対処 file 削除 |
藤本さんが実 pipeline を通した際、 全て「一見成功」の log を出しながら実は失敗していた 5 種類。 ② と ⑤ は「2 度目」の事故 — 対処記録が repo 内に既に register されていたのに、 私 (Claude) 側の memory 検索怠りで届いていなかった。
| # | 罠 | 見た目 | 型 |
|---|---|---|---|
| ① | CF Pages 配信元 dist-renderer/ |
未公開なのに HTTP 200 でトップページ | 反映元の誤認 |
| ② | dist-renderer/tools/ の .gitignore |
追加したページが静かに公開されない | 2 度目 blackout |
| ③ | 差分チェックの作業ツリー比較 | 「commit しません」 = 正常動作と同じログ | 判定不能が正常に見える |
| ④ | CRLF による常時不一致 | 検査が動いているのに答え固定 | env 由来 bias |
| ⑤ | STEP counter が worktree ごとに別実体 | 衝突防止の仕組みが衝突する番号を払出 | 2 度目 分岐 state 破綻 |
.gitignore block と ⑤ の step-counter healed_reason は既に repo 内に対処記録が register 済。 知識が無かったのではなく、 届いていなかった。 実装前の git log --grep + memory grep を怠ったのが直接原因。 正しいやり方 (notepad mirror hook の force-track pattern) は「隣にあった」。
同時に届いた rei-scout 第 6 回 report (22 新着 / 258 累計) で、 収集規則の handbook が誤解を招く記述だった問題を指摘。 Downloads/rei-scout/scout/ の 2 file を直接編集 (git 非管理):
cli.py:98 — _rescore docstring の「raw.githubusercontent 経由なので認証は要りません」の一般化を narrow (「_rescore 固有の性質」明示 + 収集側は search_repos 参照へ誘導)collect.py:53 — search_repos() に docstring 追加、 3 rule を明示:
sort=updated&order=desc は API 仕様上 accept されるが実挙動は star 順 (robolint 2023-12-05 「新着」誤認の root cause 明記)raw.githubusercontent は README fetch (rescore + scan 2 周目) と CURATED まとめリスト限定sort/order 引数自体は残し (「明示的に指定した」 record 目的)、 直近 NOTE で「動作に影響しない」 と honest 明記。 Python AST parse SYNTAX OK 検証済。
Downloads/rei-scout/ (git 非管理) 側の直接編集、 commit なし2026-09-03T03-00_STEP-1698_*.md