本番リリース（master 更新）で機能が変わったとき、機能カタログが古いまま残らないよう自動で追従させる。
| 項目 | 現状 | 課題 |
|---|---|---|
| カタログ実体 | 加藤の個人リポジトリ内（catalog.json ほか） | 個人資産になっており、チームで見えない・引き継げない |
| 公開ページ | 加藤の個人 Cloudflare アカウントの Pages（ランダム URL・noindex） | アカウント管理が個人依存 |
| 更新 | 手動（「更新して」と依頼したときだけ） | リリースに気付かないと古いまま残る。基準コミットは 8/14 のまま |
この選択で、置き場所・自動化の作り・費用・立ち上げ速度がすべて変わる。本設計書の最大の分岐点。
| 観点 | 案A: チーム資産にする | 案B: 個人資産のまま |
|---|---|---|
| データ・スクリプトの置き場所 | 組織の専用リポ the-online-class/feature-catalog（新設・private） |
加藤の個人リポ（現状のまま） |
| 公開ページのホスティング | オンクラスの Cloudflare アカウント（Git 連携で push = 自動デプロイ） | 加藤の個人 Cloudflare（現状のまま） |
| リリース検知 | GitHub Actions が毎朝チェックし、影響機能リスト付き Issue を自動起票。チームの誰でも見える | 加藤のローカル環境が毎朝チェック。検知結果は加藤にしか見えない |
| カタログ更新（AI 再検証） | 当面は加藤のローカルで半自動 → 安定後は組織用 Claude Code アカウントで CI 内全自動化（追加費用 0 円・§6） | 加藤のローカルのみ。全自動化の受け皿がない |
| 費用 | 検知まで 0 円。全自動化も組織用 Claude Code アカウントのサブスク内で 0 円運用可 | 0 円（Claude 定額プラン内） |
| 立ち上げ速度 | 方針合意 1 回で即日開始できる（§7 権限調査のとおり技術的な障害はほぼ無い） | 最速（誰の承認も不要） |
| 属人性 | チームで引き継げる。加藤の Mac・アカウント・稼働に依存しない形へ育てられる | 加藤に完全依存（Mac が止まれば更新も止まる。退職・異動で資産ごと失われる） |
the-online-class/feature-catalog（private・名称は仮）。カタログのデータ・生成スクリプト・自動化をここに集約する| 方式 | 立ち上げ速度 | 製品リポへの影響 | 備考 |
|---|---|---|---|
| 専用リポ新設（本案） | ○ 合意後すぐ | ○ 変更ゼロ（read-only） | secrets・自動更新をカタログリポに閉じられる |
| 製品モノレポに同居 | △ PR レビュー・CI 審査が挟まる | × 自動更新 PR や AI 用 secrets が製品リポに入る | カタログ編集をチーム全員で回す段階になったら再検討 |
①②は GitHub Actions（無料枠内・AI 不使用）で毎朝実行。差分ゼロなら即終了するため、コストはほぼゼロ。 ③は当面ローカル（Claude Code）での半自動運用から始め、軌道に乗ったら CI 内実行に育てる（§6 Phase 3）。
the-online-class/feature-catalog を新設（private）catalog.json（データ本体）／生成スクリプト／データ規約 README／検証証跡（claims）／マニュアル照合結果.claude/skills/feature-inventory）も移植して同梱 — 検証手順・データ規約を含むこの時点で「チームのもの」という目的は達成。以降の自動化が止まっても資産は残る。
claude setup-token で発行）を第一候補とする — 追加費用 0 円・個人依存なし。組織アカウントの利用枠を CI が消費するため、半自動運用で消費量を実測してから移行する（代替: Anthropic API キー・従量課金）（確認事項③）| 対象 | 加藤の現在の権限 | 判定 |
|---|---|---|
GitHub 組織 the-online-class |
admin（オーナー）。組織設定でもメンバーの private リポ作成が許可されている | リポ新設・secrets 設定・read-only トークン発行まで自力で可能 |
製品リポ online-class-api |
admin | 検知用の読み取り設定も自力で可能（本設計では書き込みはしない） |
| Cloudflare | 個人アカウントに加え、オンクラスの組織アカウントも操作権限あり（8/24 本人確認。ローカル CLI のログインは個人側のため、Pages 設定時は組織アカウントで作業する） | ギャップなし。Pages プロジェクトは組織アカウント側に作成できる |
技術的な権限はすべて揃っている。PM に確認したいのは権限付与ではなく「方針の合意」のみ。
the-online-class/feature-catalog（private）でよいか。命名規則があれば従います （作成権限は加藤にあり、合意後すぐ着手可）①②の合意があれば追加費用ゼロで Phase 2（自動検知）まで到達できます。
| タイミング | 起きること | 誰が |
|---|---|---|
| 火曜 リリース | develop → master マージ（通常のリリース作業。追加作業なし） | 実装チーム |
| 水曜 朝 | 検知 Action が差分を発見し、影響機能リスト付き Issue を自動起票 | 自動 |
| 水曜 午前 | Issue を受けて影響機能を再検証・カタログ更新 → push | 加藤（ローカル） |
| push 直後 | Pages が自動デプロイ、Issue に更新レポートを記録してクローズ | 自動 |
全自動化後は 3 行目も自動になり、リリース翌朝には更新済みカタログが公開されている状態になる。
| リスク | 対策 |
|---|---|
| 社外への情報露出（カタログは内部情報） | リポは private・ページは noindex + 推測不能 URL を維持（現行と同等）。より堅くする場合は Cloudflare Access でメール制限（任意・オンクラスアカウント移行後に選択可） |
| 検知の見逃し（逆引き表に無い新規ファイル） | 既存機能に紐づかない差分は「新機能候補」として Issue に必ず列挙し、機械判定でこぼさない。新機能かどうかの判断は AI／人が行う |
| コード行番号のずれ（master が進むと根拠の file:line がずれる） | 更新した機能は新コミット基準で根拠を引き直す。未更新機能は「基準コミット時点の行番号」として README に明記（現行運用の踏襲） |
| デプロイの未完了（過去に公開版が5日間古いままの事故） | Pages Git 連携により「push = デプロイ」になり、手動デプロイの完了確認漏れという事故要因自体が消える |
本設計書は方針決定後、カタログリポ内（docs/）へ移して管理する。