Imported from pooza/capsicum (.claude/skills/sync-procedure/SKILL.md). Install upstream with npx skills add pooza/capsicum --skill sync-procedure. Copyright stays with the author.

セッション開始時の同期手順

会話の最初に「進捗を同期してください」等の指示があった場合、以下の手順を実行する。

⚠⚠ 正本はこのファイル (#1114)。docs/sync-procedure.md はここへのポインタ。手順を直すときはこちらだけを直す。

⚠ 作業中にセッションが切れて「続きをやって」と言われた場合は、この手順は回さない。resume-work が別にある。

0. コマンドの書き方（許可確認を出さないための約束）

⚠⚠ 同期を回す前に docs/dev-environment.md の「コマンドの書き方」を読む。jq を使う / cd しない / gh の書き込みに --repo を付ける / 絶対パスで呼ばない。同期はほぼ定形作業なので、許可確認 0 回で完走できる形に揃える。

⚠ 端末側の設定（auto モード・autoMode の書き分け）は同ファイルの「Claude Code の権限設定」が正本。書き方を守っても設定が無ければ確認は消えないので、新しい端末では設定を先に済ませる。

1. プロジェクトガイドの読み込み

• docs/CLAUDE.md を読む（プロジェクトのルール・構造・履歴の正本）
• インフラノート /Volumes/extdata/repos/chubo2/docs/infra-note.md を読む（サーバー構成・デプロイ手順）
• MEMORY.md は自動ロードされるので、両者の整合性を意識する

2. リモートとの同期・状態確認

• git fetch origin — 最初に必ず実行。リモートが正本であり、ローカルの状態を信用しない

• git log HEAD..origin/develop --oneline — リモートに未取り込みのコミットがないか確認。差分があれば pull を検討

• git log --oneline -10 — 直近のコミット履歴

• git tag --sort=-creatordate | head -5 — 直近のリリースタグを確認

• gh release list --limit 5 — 最近の GitHub Releases を確認

• gh api repos/pooza/capsicum/milestones --jq '.[] | "\(.title) \(.state) \(.closed_at // "open")"' — マイルストーンの open/closed 状態を確認

• gh run list --workflow=analyze.yml --branch develop --limit 3 で CI の緑/赤を確認する。赤ならその場で直す。develop は PR を経ずコミットが積まれるため、dart format / dart analyze の失敗が誰にも気付かれないまま残りうる。2026-08-05 の同期で、#934 のコミット以降 2 日間 format 失敗のまま develop が進んでいたのを発見した

• 前回同期時点と比較して新しいリリースがあれば、実装ステータスやリリース計画セクションに反映する

• Flutter のバージョンが基準と合っているかを確認する（#836）。端末が 3 つ以上あり、ズレたまま flutter pub get すると pubspec.lock が端末間で ping-pong するため、着いた端末で最初に気付けるようにするのが目的。正本は CI の pin:

  grep -m1 'flutter-version:' .github/workflows/analyze.yml   # 基準（正本）
  flutter --version | head -1                                  # 手元

  Windows（grep 不在）:

  Select-String -Path .github\workflows\analyze.yml -Pattern 'flutter-version:' | Select-Object -First 1
  flutter --version | Select-Object -First 1

  ズレていたら同期報告に「この端末は X、基準は Y」と明記し、dev-environment.md の「基準版に追従する」手順で揃えてから作業に入る。揃える前に出た pubspec.lock の差分はコミットしない

3. Issue・PR の確認

• gh issue list --state open --limit 100 — open Issue 一覧（--limit 100 を必ず指定。デフォルト 30 件では古い Issue が取得漏れする）
• gh pr list --state open — open PR 一覧
• gh issue list --state closed --limit 10 — 最近クローズされた Issue（前回同期以降の進捗把握）
• マイルストーン未割り当ての open Issue を一覧として列挙する（割り当てを促す文言は不要）
• capsicum-relay に対しても同じ 4 つを実行する（--repo pooza/capsicum-relay を付ける）。ステップ 8 の「関連リポジトリの同期確認」でリポジトリの差分を見るのとは別で、relay の Issue 管理は capsicum 本体と同じ工程として扱う。詳細は下の「relay を同列に扱う」節

4. ユーザーフィードバックの確認（#capsicum タグ + ダイスキー capsicum チャンネル）

• 美食丼の #capsicum タグタイムラインを取得: curl -s "https://mstdn.b-shock.org/api/v1/timelines/tag/capsicum?limit=20"
• ダイスキーの capsicum チャンネル（delmulin 固有の capsicum 話題、channelId=ak31f5utjv、https://misskey.delmulin.com/channels/ak31f5utjv）を取得: curl -s -X POST https://misskey.delmulin.com/api/channels/timeline -H 'Content-Type: application/json' -d '{"channelId":"ak31f5utjv","limit":20}'
• バグ報告・機能要望・ユーザーからの質問がないか確認する
• 未起票のバグ報告があれば GitHub Issue を起票する（報告元の投稿 URL を記載）
• 好評・感想は報告のみ（Issue 化不要）

5. マイルストーンの状態確認

• ステップ 3 で取得した全 Issue をマイルストーン別に集計し、件数の変動を把握する

• MEMORY.md のマイルストーン構成（件数）が実態と一致しているか確認し、ズレがあれば更新する

• クローズ済みマイルストーンの残 Issue が 0 であることを確認する

• リリース直後の同期では、open マイルストーンの description が実態と乖離していないかも確認する。GitHub Milestones が正本（CLAUDE.md に複写しない方針）のため、description が空・古い場合は同期内で gh api -X PATCH repos/pooza/capsicum/milestones/{number} -f description="..." で整える。最低限、(a) 大更新の単独配置か否か、(b) 主な含有 Issue、(c) 並走条件 を 1〜3 行で書く

• capsicum-relay の同名マイルストーンにも同じ集計・description 点検を行う（repos/pooza/capsicum-relay/milestones）

• open マイルストーン全件について、description に ## relay 節があることを確認する（2026-08-22 義務化・書式と必須である理由は docs/milestone-transition.md §3-2「必須: capsicum 側 description の ## relay 節」）。節が無ければその場で足す。「なし」と書いてある枠は、relay 側に同名枠が実在しないことを API で照合してから通す（なし のまま stale 化した実績があり、v1.59 で relay 3 件が進捗報告から丸ごと落ちた）

  # relay 節の有無を一覧で確認
  gh api repos/pooza/capsicum/milestones --jq '.[] | "\(.title)\trelay節=\(if (.description | test("(?m)^## relay")) then "有" else "無" end)"'
  # 実態（relay 側の枠と件数）
  gh api repos/pooza/capsicum-relay/milestones --jq '.[] | "\(.title) open=\(.open_issues) closed=\(.closed_issues)"'

relay を同列に扱う

capsicum-relay の Issue・マイルストーンは、capsicum 本体と同じ工程・同じ粒度で扱う。relay を「関連リポジトリの同期確認」（ステップ 8）だけで済ませると、リポジトリの git 差分は見えても Issue の消化・残が見えず、リリース時に対応漏れが起きる。

• ステップ 3（Issue・PR）・ステップ 5（マイルストーン集計と description 点検）は capsicum と relay の両方に対して実行する
• ステップ 10 の報告では、relay を末尾に 1 行添える形にしない。同名マイルストーン（capsicum v1.56 ↔ relay v1.56）の消化 / 残を、本体と同じ見出しレベル・同じ粒度で並記する
• relay 側の残件は「本体のついで」ではなく、そのマイルストーンの完了条件の一部として報告する

（2026-08-11 に pooza から指示。2026-08-13 の同期で 3 度目の指摘を受けたため、メモリだけでなく本手順書に組み込んだ）

6. Codex レビューコメントの確認

• 最近マージされた PR（gh pr list --state merged --limit 5）を取得。直近リリース PR（develop → main の merge）も merged にカウントされるため、リリース直後の同期では明示的にリリース PR が含まれていることを確認する（過去に #529 を見落としかけた経緯あり）
• 各 PR に対して gh api repos/pooza/capsicum/pulls/{number}/comments（line comments）+ gh api repos/pooza/capsicum/pulls/{number}/reviews（review 本体）の両方で Codex（chatgpt-codex-connector[bot]）のコメントを確認。line comments と review comments は別 API で、片方だけ見ると review 本体に書かれた指摘 (P2 レベル等) を取りこぼす
• 各コメントについて以下を判定する:
  1. 未返信 → 指摘内容を確認し、対応が必要か判断。必要なら Issue 起票
  2. 返信済みだがリアクション未付与 → 修正コミットの存在を確認し、+1 リアクションを付与
  3. 返信済み・リアクション済み → 完了。報告不要
• 判定方法: gh api repos/pooza/capsicum/pulls/{number}/comments --jq で全コメントを取得し、Codex コメントの id に対する in_reply_to_id を持つ返信の有無、および Codex コメントへのリアクション（reactions）を確認する。⚠ 返信は line comment の返信ではなく issue comment（gh api repos/pooza/capsicum/issues/{number}/comments）として書かれていることが多いので、in_reply_to_id が空でも「未返信」と即断しない。両方を見る
• ⚠ リリース PR に付いた Codex の line comment は、リリース前レビューのまとめ Issue に入らない。 レビュー 5 観点のまとめ（#982 / #1012 等）は「レビューを回した結果」の受け皿であって、そのあとに立てるリリース PR へ Codex が付ける指摘は別系統。2026-08-23 の同期で、v1.59 のリリース PR #1003 の 3 件が未返信・未起票のまま出荷されていたのを検出した（→ #1014）。リリース直後の同期では、リリース PR の line comment を明示的に数える

7. Sentry の新規イシュー確認

⚠⚠ **Sentry は .claude/scripts/sentry-api.sh 経由で叩く（2026-09-17〜）。**調査用トークン（~/.sentryclirc の [auth]）はスクリプトの中で読み、画面にもコマンドラインにも出さない。⚠ トークンを awk 等で読み出してコマンドへ埋める旧手順に戻さない —— auto モードの分類器が「認証情報の露出」として拒否し、autoMode.allow に許可を書いても通らなかった（経緯は dev-environment.md の「落とし穴」）。⚠ リポジトリ root から相対パスで呼ぶ（permissions.allow の Bash(.claude/scripts/sentry-api.sh *) に当てるため）

• .claude/scripts/sentry-api.sh cli issues list -p capsicum で未解決イシューを確認。新着だけなら --query 'is:unresolved firstSeen:-3d'（issues list は firstSeen を列に出さない）
• .claude/scripts/sentry-api.sh cli issues list -p capsicum-relay も確認（capsicum-relay#10 で 2026-05-28 から計装開始。Phase A 段階では smoke test 起点で、Phase B 以降で APNs/FCM/socket_loop の本格計装が乗る）
• 各イシューの過去コメント（対応経緯）を確認する: .claude/scripts/sentry-api.sh get /issues/{issue_id}/comments/ | jq -r '.[] | .data.text'
• 詳細（件数・利用者数）は get /issues/{issue_id}/、端末・リリースは get /issues/{issue_id}/events/latest/ | jq -c '[.tags[] | {(.key): .value}] | add'、同一利用者かは同じく .user.id で見る
• 新規・未解決のイシューがあれば内容を確認し、対応が必要か判断する（対応が必要なら GitHub Issue を起票。capsicum-relay 側のイシューは pooza/capsicum-relay リポに起票）
• 判断結果や対応経緯はコメントとして記録する: .claude/scripts/sentry-api.sh post /issues/{issue_id}/comments/ '{"text":"コメント内容"}'
• 調査用トークンが別枠なのは、capsicum ではリポジトリ root の .sentryclirc がデプロイ用トークンで占有されているため。スクリプトの cli は SENTRY_AUTH_TOKEN で調査用を明示するので、cwd に関係なく 403 にならない
• ⚠ Windows（sh 不在）ではスクリプトが使えない。sentry-cli を --org 明示で叩く従来の形のまま
• resolved 済みのイシューは報告不要

8. 関連リポジトリの同期確認

• mulukhiya-toot-proxy: git -C ~/repos/mulukhiya-toot-proxy fetch origin + git -C ~/repos/mulukhiya-toot-proxy log HEAD..origin/develop --oneline でリモートとの差分を確認（cd しない理由は dev-environment.md の「コマンドの書き方」）。docs/capsicum-requirements.md や docs/api.md に変更があれば capsicum 側への影響を判断

• chubo2: git -C ~/repos/chubo2 fetch origin + git -C ~/repos/chubo2 log HEAD..origin/main --oneline で差分を確認。docs/infra-note.md に変更があれば MEMORY.md のインフラセクションに反映が必要か判断

• capsicum-relay: git -C ~/repos/capsicum-relay fetch origin + git -C ~/repos/capsicum-relay log HEAD..origin/main --oneline で差分を確認。Issue / PR は gh issue list --repo pooza/capsicum-relay --state open --limit 30 / gh pr list --repo pooza/capsicum-relay --state open で確認（dependabot PR + security alert もここで拾う、gh api repos/pooza/capsicum-relay/dependabot/alerts --jq '.[] | select(.state == "open") | "\(.security_advisory.severity) \(.dependency.package.name) fix=\(.security_vulnerability.first_patched_version.identifier)"'）。リレーサーバーのデプロイ管理は Claude 担当（接続先ホスト・SSH ユーザー・具体的な SSH コマンド列はメモリ feedback_capsicum_relay_deploy_delegation が正本。ホスト構成・デプロイ手順の共有正本は chubo2 の docs/infra-note.md）、main 進行がありサーバー側の HEAD が遅れていたら SSH デプロイ（pull → 依存更新 → サービス再起動 → /health 確認）まで一連で実行。稼働中の SHA は SSH せずに /health で分かる（relay#37、v1.57 で出荷）ので、デプロイ要否の判定はこれ 1 回で済ませる:

  curl -s https://st.relay.capsicum.shrieker.net/health | jq -r .revision   # ステージング (triton)
  curl -s https://relay.capsicum.shrieker.net/health | jq -r .revision      # 本番 (flauros)

  ⚠ 返るのは稼働中プロセスの revision なので、docs / テストだけの commit を main へ入れた回は意図的に遅れる（本番再起動は in-memory の /metrics counter をゼロに戻すため、サーバー挙動が変わらない commit で再起動しない）。不一致を見つけたら git log <revision>..origin/main で中身を見て、コードに触っていなければデプロイ不要と判断する。

  ⚠⚠ デプロイは必ずステージング (triton) を先に通し、本番 (flauros) はその後（2026-09-13 pooza 指示）。**両方の /health を並べて見るのは、本番だけが先に進んでいる逆転を検出するため。**2026-09-13 の同期で、relay#54 が 本番 a9b8e90 / ステージング b9ce14c という逆転のまま出ていたのを見つけた（ステージングが一度も新コードを踏んでいない）。

  順	ホスト	確認
  1	deploy@triton.b-shock.local	curl -s https://st.relay.capsicum.shrieker.net/health の revision が origin/main と一致し、status が ok
  2	deploy@flauros.b-shock.co.jp	同上を本番 URL で

  ⚠ **ステージングで確かめてから本番へ進む。**手順（pull → bundle install → sudo -n systemctl restart capsicum-relay → /health）は 2 台とも同じで、アプリは両方 ~/repos/capsicum-relay・branch は main・unit 名も capsicum-relay。⚠ 変更系と確認系を同じ ssh セッションに混ぜない（本番を意図せず再起動した事故がある）。⚠ ステージングは購読数が小さく supporters が 0 なので、/health の数値が本番と違っても異常ではない。

• Mastodon / Misskey の現行バージョン確認: 自前サーバーのソフトウェアは pooza フォークがリリース追従しているため、ローカルの fork を pull すれば現行バージョンを正確に確認できる（推測しない）。

  • Mastodon: git -C ~/repos/mastodon pull --ff-only → lib/mastodon/version.rb の major/minor/patch（または git -C ~/repos/mastodon tag --sort=-creatordate | head で vX.Y.Z-bshockdon）
  • Misskey: git -C ~/repos/misskey pull --ff-only → package.json の version（jq -r .version ~/repos/misskey/package.json）
  • 前回同期からメジャー/マイナーが上がっていれば、API 変更トリアージ（docs/mastodon-capsicum-api-watch.md / docs/misskey-capsicum-api-watch.md）の要否を判断し、メモリの「対応方針」系（例 project_mastodon_46_posture）の版表記を更新する

9. MEMORY.md の更新

• 上記で検出した差分（Issue 状態、マイルストーン件数のズレ、リリース情報等）を反映

10. 同期結果の報告

• 現在のブランチ・状態、前回以降にクローズされた Issue、マイルストーン別の残件数、未割り当て Issue 一覧、Sentry 新着イベント、Mastodon / Misskey の現行バージョン、各確認項目の結果をまとめて報告する
• capsicum と capsicum-relay の稼働中マイルストーンを、同じ見出しレベル・同じ粒度で並記する（「relay を同列に扱う」節を参照）。relay の残件を末尾の 1 行に圧縮しない