intmap-round

Imported from rwmqx7dwb5-arch/IntMap (.agents/skills/intmap-round/SKILL.md). Install upstream with npx skills add rwmqx7dwb5-arch/IntMap --skill intmap-round. Copyright stays with the author.

IntMap · ラウンドを 1 本通す

AGENTS.md §5 のワークフローを実際のコマンドの順にしたもの。規則は AGENTS.md と CONSTITUTION.md、戦略は .agents/rules/execution-strategy.md にある。ここは手順だけ。

0. 着手前（並列にやる）

AGENTS.md §1 の事前確認は互いに独立なので、まとめて 1 回で済ませる。

node scripts/worktree.mjs status

これが一度に出す: 現在の branch / 未コミット変更 / 全 worktree / 空いているラウンド番号 / origin/main との差 / 直近のラウンド。ここに出ないものだけ個別に見る。

同時に（同じメッセージで）:

• 今回の主題の正本を docs/README.md で特定して、その文書を読む
• 調査が要るなら intmap-scout に投げる（自分で grep して回らない）

不明点があれば訊く。推測で埋めない（AGENTS.md §8。訊き方は製品ごとに違う—— docs/AGENT-SETUP.md §2）。 質問は説明文に混ぜず、必ず質問用の機能で行う。

1. 作業場を用意する

node scripts/worktree.mjs new <slug>

これがやること（AGENTS.md §6 の要求そのもの）:

• 空いているラウンド番号 N を決める
• branch feat/r<N>-<slug> を origin/main から切る
• OneDrive の外に worktree を作る（原本は main の置き場であって作業場ではない）
• node_modules を原本から junction で貼る
• .claude/launch.json に intmap-preview-r<N> / ポート 4000 + N を足す （R403 なら 4403。⚠ 以前ここは 42<N> と書いてあり、それが合うのは N が 200 番台のときだけ だった——例に使われていた R257 → 4257 は 4000+257 の別の読み方でしかない） （⚠ #R338 以降このファイルは追跡対象外。commit にも PR にも出てこない）
• 作業ディレクトリの絶対パスを印字する

以降の編集は全部その worktree の中で行う。 原本には 1 バイトも書かない。

2. 実装する

.agents/rules/execution-strategy.md の §1〜§3 に従って分解する。要点だけ:

• 独立な仕事は同じメッセージでまとめて起動する
• 触るファイルが重ならない並列実装は、仕事ごとに worktree.mjs new で場所を作り、 intmap-implementer に絶対パスと触ってよいファイルの一覧を渡す
• 同じファイルを 2 体に書かせない
• 統合・commit はメインだけ
• 利用者に見える文字列を足したら intmap-i18n に 9 言語を回す

どのモデルで走らせるか（Claude Code のみ・#R787）

読むだけ・数えるだけ・掃くだけの役に、決める役の値段を払わない。 ⚠ 線は「機械的な仕事か」ではなく「観測器か」で引く——何を返すかが決まっている役は 下げてよく、何が起きたかを判定する役は下げない。

正本は .agents/roles/*.md の claude: model: で、node scripts/agent-sync.mjs が .claude/agents/*.md の frontmatter へ写す。綴りは npm run check:agents が拒む ——Claude Code は知らないモデル名を黙って無視して継承に戻すので、宣言だけが残る。

⚠⚠⚠ 昇格させる条件（呼び出し側が Agent tool の model で上書きする）

intmap-verifier に「この失敗は環境要因か、本物の退行か」を訊くときは model: "opus" を渡す。 これは節約の例外ではなく、節約が成立する条件である—— .agents/rules/one-pass-or-a-reason.md §2 が数える繰り返しの 原因の 1 番は「観測器が嘘をついた」で、実測は #R736（21 手・10分29秒が全部その再試行）・ #R742（207 操作中 52 件＝25%）・#R768。誤判定 1 回ぶんの再試行は、その役の全ラウンドぶんの 節約より高い。

昇格させるのは、次のどれかを訊いているとき:

• その赤は環境要因（改行コード・ポート衝突・並行実行・tree lock の枠切れ）か、本物の退行か
• 緑だが実は死んでいるのではないか
• 失敗が観測された事実か、観測できなかっただけか（one-pass-or-a-reason.md §5 の 2 つ）

単に「npm test を流して落ちた spec を挙げろ」なら既定のままでよい。 ⚠ 迷ったら上げる。 節約のために判断を曇らせた瞬間に、節約は目的を失う。

⚠ この表と昇格条件は .agents/rules/ には置けない。 あちらは 1 ファイル 6144 バイトの天井を 持ち（tests/r295-checks.test.mjs ⑥・毎セッションが払うから）、execution-strategy.md は 余白 8 バイトで埋まっている。検査自身が「detail は agent か skill へ移せ」と述べている。

3. ドキュメント（実装と同じコミットで）

⚠ 最後の行は「その他」ではなく、この表の残り全部である。 ここに並んでいるのは docs/ にある文書の一部にすぎず、以前は最後の行が無かった——ニュース・企業・航空・火山・DB を 触ったラウンドは、この手順書からは文書更新の義務が一切出てこなかった。 どれが何の正本かを 1 枚で持っている唯一の表は docs/README.md なので、書き写さずに引く。

同じ事実を 2 か所に書かない。正本を 1 つ決めて、他はそこへリンクする。

4. 検証

**段とコマンドの表は .agents/rules/execution-strategy.md §4 が正本。**ここには書き写さない——そこを見て、この工程では段 0 から順に上げる。

このラウンド固有の義務だけ書く: その回の回帰検査は tests/r<N>-<主題>-checks.test.mjs （spec なら tests/r<N>-<主題>.spec.js）という名前で置くだけでよい——test:checks は node --test "tests/**/*.test.mjs" なので、名前が合っていれば登録なしに走る（#R529）。

⚠ ラウンド番号は名前ではない（この節が規約の正本・#R674）

番号はこのセッションのものではない——並列セッションは全員が同じ走査（worktree.mjs の nextRound）から「次の空き番号」を取り、origin/main が動くたびに取り直す。 改番は例外ではなく定常状態（#R671 は 7 回、同じ時期の別セッションは 4 回）。実測された被害:

• tests/r568-checks.test.mjs を 2 セッションが両方新規作成し、git が add/add を立て、 着地の自動化がそれを取り込んで衝突マーカーごと commitした（… | tail -4 が $? を tail のものにしていた・#R420 の再演）。ファイルは SyntaxError で1 本も走らなくなった。
• memory の intmap-r<N>-lessons.md を改番のたびに rename していて、別セッションのファイルに 重ねて自分の記憶を失った（#R565 と #R671 で 2 回）。

⚠ 直せるのは merge ではなく名前である。 1 つのチェックアウトの中では「相手が別の番号を 取ったか」を原理的に証明できない（相手の branch はここに無い）。証明できるのは名前が番号の 持たないもの＝主題を持っているかだけ。⇒ 番号 ＋ 主題で名づける:

• 名前は node scripts/worktree.mjs new <slug> が番号を取ったその場で印字する。手で組み立てない。
• リポジトリ側の門は npm run check:static の round-name（機械側の正本は scripts/round-names.mjs。何を測っているかは docs/TESTING.md）。 既存の番号だけの名前は過去のものとして据え置いてあり、数と最大ラウンドの 2 つで下向きに だけ動く。⚠ memory はリポジトリの外なので門が無い——番号を書かないことだけが守る （AGENTS.md §1）。
• ⚠ 改番に「全文置換」を使わない。 R<from> → R<to> の一括置換は他人のラウンドの文まで 書き換える（実測: docs/TESTING.md の見出しと DEV-NOTES.md の 1 行）。動かすのは 自分のファイル名だけを対象にしたパターン（rd+-<自分の主題>）。

⚠ tests/ に置く .mjs で node:test を import するものは、必ず *.test.mjs と名づける。 それ以外の名前は runner から見えず、一度も走らないまま永久に緑になる（check:static が捕まえる）。

大量ログの読み分けは intmap-verifier に渡す。

5. commit → push → PR → CI → merge

git add -A && git commit -m "R<N>: <一行の要約>"
git push -u origin feat/r<N>-<slug>
gh pr create --fill
gh pr merge --squash --auto --delete-branch   # 緑なら勝手に merge される。座って見ない

⚠ gh pr checks --watch で CI を見張らない（#R771）。実測で、赤い CI は 11.9分・12.2分 かかり、その間ずっと待っていた。--auto なら緑で自動 merge・branch 削除まで行き、赤いときだけ 戻ればよい。CI のゲートは 3 台に分かれ fail-fast: false なので、1 回の run で落ちたゲートが 全部出る——「1 つ直して 12 分待ってまた別のが赤」という往復がそもそも起きない （scripts/ci-gates.mjs。計画は node scripts/ci-gates.mjs --plan が印字する）。

⚠ merge 後に main で走る CI を待たない。 PR の CI が緑なら同じ木が同じ結果を出す。

• push の直前にラウンド番号を取り直す（node scripts/worktree.mjs status）。 ⚠ これは稀な事故ではない。 DEV-NOTES.md を「改番」「番号を取り直」で引けば実例が並ぶ （ここは長く「過去に 3 回」と書いてあったが、そう書いた時点で既に下限だった）。1 回の改番が 30 か所を超えることがあるので、取り直しは push の直前に、毎回。
• CI の deploy ログは mode:'serial' だと最初の 1 件しか見せない。「赤が 1 件」は 「壊れているのが 1 件」ではない。
• 非破壊的な migration・設定変更・deployment・commit・push・PR・merge に承認を求めない （AGENTS.md §5）。

6. deployment と本番検証

Edge Function を変えたなら本番へ出す:

supabase functions deploy <name> --project-ref vpekfwdpurzejrrmacac --use-api

⚠ --use-api を省くと無言でハングする（既定は Docker を使うが、このマシンではデーモンが 動いていない。理由と実測は docs/AGENT-SETUP.md §9）。進んでいるかは経過時間ではなく supabase functions list の version で見る。

⚠ 本数と名前をここに書き写さない。 正本は AGENTS.md §5.1、 機械が持っている実体は supabase/config.toml の [functions.*] 宣言そのもの （_shared/ は関数ではなくライブラリ）。手元で数えるならこれ:

grep -o '^\[functions\.[a-z0-9-]*\]' supabase/config.toml

この節はかつて本数と名前を写しており、実体が増えたあとも3ラウンド気づかれなかった—— 文書どうしの食い違いを見る npm run check:docs が、当時この階層を読んでいなかったから。 今は読む（scripts/doc-facts.mjs の edge-roster / edge-count）。

サイトの本番検証は intmap-prod-verifier に渡す。ローカルで測った数字を本番の数字として 報告しない。

⚠ この回の本番検証を、この回の中で待たない（#R771・AGENTS.md §5.1）。Pages の deploy は merge のあと数分かかる。前回までの分を、次のラウンドの着手時（§1）にまとめて検証する。 終えたら受領証を残す——これを書かない先送りは「やらなかった」と区別がつかない:

node scripts/worktree.mjs verified      # origin/main の HEAD を「本番検証済み」として記録

7. 終了処理（省略できない。ただし待たない）

⚠ この回でやるのは done だけ。 残りは merge が本番へ届いてからでないと意味がなく、 届くのを待つと 1 ラウンドが 1 時間になる（#R771）。次のラウンドの着手時にまとめて走らせる ——--sync は冪等で、1 回の実行がその時点で merge 済みの全セッション分を運ぶ。

node scripts/worktree.mjs done          # この回: 自分の worktree と branch を片付ける

# 次のラウンドの着手時に、前回までの分をまとめて:
node scripts/worktree.mjs status        # 何が未了かを述べる（本番検証・原本・deploy）
node scripts/master-sync.mjs --sync     # 原本 (OneDrive) を origin/main へ早送り
node scripts/master-sync.mjs --check    # 原本が merge 後の状態か（exit 0 を確認）
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/backup-usb.ps1   # USB へ完全ミラー（毎回）
node scripts/worktree.mjs verified      # 本番検証を終えたら受領証

• --sync は冪等でロックが要らない。他セッションと同時に走ってよい。
• ⚠ pwsh ではない（PowerShell 7 はこのマシンに無い。実測は AGENTS.md §11.2）。 かつてここは pwsh -File … と書いてあり、書いてあるとおりにやると終了処理の最後の 1 歩が 必ず CommandNotFoundException で落ちた。
• backup-usb.ps1 の最後の 1 行は RESULT ok|skipped|failed。skipped はエラーではない （USB 未接続、または候補が一意に決まらない）。
• worktree.mjs done は自分が作った worktree と branch だけを消す。他セッションのものには 触れない。

8. 最終報告（AGENTS.md §10・日本語）

実施した変更 / 実施したテストと結果 / CI 状態 / commit・PR・merge 状態 / production deployment / production verification / 残っている問題。 正常に完了したなら利用者による追加作業が不要であることも明示する。

⚠ 削るべきものに気づいていたら、ここで提案する（#R473 の方針転換）。作業中に見つけた 重複・死んだ機構・二重の正本・役目を終えた画面は、依頼を止めずに完遂してから、この報告の中で 「何を・なぜ・代わりに何が残るか・失うもの」を添えて出す。承認が無いうちは1バイトも消さない。 手続きの正本は CONSTITUTION.md §0 の 3、Atlas の但し書き（実装は削ってよいが到達可能な能力と 回答品質は削らない）は同 §5。

末尾に必ず 3 行:

GitHub: push済み / 最新
USB: <日時> 同期済み   （未接続なら「未接続のためスキップ」）
USB検証: 差分ゼロ