fs.mkdir(path, { recursive: true }))を解決するためにある。調べて記録するだけでなく、直るところまで持っていくのが目的共通ルールの「指示された範囲だけを実装する」「質問された時の対応」と違う運用にする。理由: 検証の結果が無いと、何を報告すべきか決められない。
tests/)と再現コード(research/repro.ts)に足す[文字](URL))にする。裸の URL は長く、本文が読みにくくなる。#42014 のような番号は GitHub が自動でリンクにするので、そのまま書く_pr/<PR 番号>/ に置く(例: _pr/42014/)。bun-windows-x64.zip、展開した bun.exe、差分(pr.diff)など。_* で Git の管理から外れる。tmp/ と違い、使い終わっても消さない(再検証で使う)gh pr diff <番号> -R oven-sh/bun で _pr/<番号>/pr.diff に保存して読む。差分だけで動きが分からないときは、Bun 本体の該当ファイルを _pr/base/<リビジョン>/ に取得して読む(リビジョンは bun --revision の値)。結果だけでなく、なぜ直る・直らないかをソースの箇所で示す0 5,8,12,15,17,21 * * *)で回す。セッションを開き直したときや、7 日で失効したときは、指示を待たずに作り直す。cron の指示文は「ローカルルールの 3 章に従い、投稿した issue を確かめる」の 1 行にし、手順を写さないgh api で取る。取得と比較は tools/80_ops/issue-watch.ts で行う(node tools/80_ops/issue-watch.ts)
repos/oven-sh/bun/issues/<番号>(状態 ・ ラベル ・ コメント数 ・ 更新日時)repos/oven-sh/bun/issues/<番号>/comments(新しいコメント)repos/oven-sh/bun/issues/comments/6118179563(リアクション)repos/oven-sh/bun/issues/<番号>/timeline(ほかの issue ・ PR からの参照)etc/issue-watch.json に残し、次の回はそれと比べる