1 day ago · db55dcd5f2
--- a/%E8%AA%B2%E9%A1%8C%E6%95%B4%E7%90%86.md
+++ b/%E8%AA%B2%E9%A1%8C%E6%95%B4%E7%90%86.md
@@ -381,88 +381,6 @@ uploadedUser / createdByUser / Wiki history user など、bot 操作や移行デ
 - [ ] 既知サイトの抽出器を追加できる構造にする
 - [ ] スクリーンショットは最後の手段にする
 ### 66. [P2] nico:sync の bot操作 付与条件をさらに絞る
 **種別**: ops / data quality
 **対象**
 - `backend/lib/tasks/sync_nico.rake`
 **背景 / 問題**
 既存 issue に bot操作 削減が大量にある。同期バッチが通常編集履歴やタグ一覧を汚さないよう、条件を明確化したい。
 **完了条件**
 - [ ] bot操作 を付ける変更種別を表にする
 - [ ] タイトル/サムネだけの更新では付けない等を決める
 - [ ] 既存 open issue を統合・整理する
 ### 67. [P2] nico:sync の外部取得に retry / timeout / 障害通知を入れる
 **種別**: ops
 **対象**
 - `backend/lib/tasks/sync_nico.rake`
 - `backend/lib/get_videos.py`
 **背景 / 問題**
 外部 DB / ネットワーク / サムネ取得に依存するバッチは、失敗時の再実行性が命。ログだけでは運用が辛い。
 **完了条件**
 - [ ] 外部取得に timeout と retry を設定する
 - [ ] 部分失敗を記録する
 - [ ] 異常終了時に通知する
 - [ ] 二重実行ロックを入れる
 ### 68. [P2] バッチの二重起動防止ロックを入れる
 **種別**: ops
 **対象**
 - `backend/lib/tasks/*.rake`
 - `config/schedule.rb`
 **背景 / 問題**
 nico:sync や類似度計算が重なって走ると、post_count や履歴に悪影響が出る可能性がある。
 **完了条件**
 - [ ] DB advisory lock か lock file を使う
 - [ ] 既に実行中なら安全に終了する
 - [ ] ログにスキップ理由を出す
 ### 69. [P1] CI で backend spec / frontend lint / typecheck / build を回す
 **種別**: test / ops
 **対象**
 - `.gitea/workflows/*`
 - `backend`
 - `frontend`
 **背景 / 問題**
 今回の静的レビューでも hook ルール違反やスキーマドリフトが見える。CI がないと再発する。
 **完了条件**
 - [ ] bundle exec rspec を CI で実行する
 - [ ] npm run lint / typecheck / build を CI で実行する
 - [ ] migration と schema の一致を確認する
 - [ ] 失敗時に merge できない
 ### 70. [P1] eslint-plugin-react-hooks を導入し、hook 事故を機械検出する
 **種別**: test / frontend
 **対象**
 - `frontend/package.json`
 - `frontend/eslint.config.*`
 - `frontend/src`
 **背景 / 問題**
 条件付き hook は人間レビューで見落としやすい。React アプリなら機械で落とすべき。
 **完了条件**
 - [ ] react-hooks/rules-of-hooks を error にする
 - [ ] react-hooks/exhaustive-deps を少なくとも warn にする
 - [ ] 既存違反を直す
 ### 71. [P1] RSpec にセキュリティ回帰テスト群を追加する
@@ -481,22 +399,6 @@ BAN、SSRF、権限、limit、system tag 保護は一度壊れると公開事故
 - [ ] system tag PATCH forbidden spec
 - [ ] limit clamp spec を追加する
 ### 72. [P1] schema.rb と migration の差分検出を CI に入れる
 **種別**: ops / db
 **対象**
 - `backend/db/schema.rb`
 - `backend/db/migrate`
 - `.gitea/workflows/*`
 **背景 / 問題**
 wiki_assets のような「schema にはあるが migration がない」状態が発生している。これは将来の環境再構築を壊す。
 **完了条件**
 - [ ] db:drop db:create db:migrate 後の schema diff を CI で見る
 - [ ] 差分が出たら失敗にする
 - [ ] schema-only 変更を禁止する
 ### 73. [P3] Gemfile の未使用 gem を棚卸しする
@@ -514,38 +416,6 @@ jwt や gollum 等、現行コードで使っているか怪しい gem がある
 - [ ] 不要なら削除する
 - [ ] 必要なら用途を README に書く
 ### 74. [P2] フォント assets のライセンスを確認する
 **種別**: legal / release blocker
 **対象**
 - `frontend/src/assets/fonts/*`
 - `frontend/src/styles/*`
 **背景 / 問題**
 フロントにフォントファイルが同梱されている。一般公開・配布前にライセンス確認が必要。ここを雑にすると公開後に面倒になる。
 **完了条件**
 - [ ] 同梱フォントのライセンスと再配布可否を確認する
 - [ ] NOTICE または credits に記載する
 - [ ] 不明なら Web font/代替フォントへ切り替える
 ### 75. [P2] ユーザ引継ぎコードを localStorage 保管のままにするリスクを評価する
 **種別**: security / design
 **対象**
 - `frontend/src/App.tsx`
 - `frontend/src/lib/api.ts`
 - `backend/app/controllers/application_controller.rb`
 **背景 / 問題**
 localStorage の引継ぎコードは実装が簡単だが、XSS で即アカウント奪取される。パスワード制にしないとしても、期限・再発行・スコープ制限は検討が必要。
 **完了条件**
 - [ ] 現方式の脅威モデルを書く
 - [ ] コード再発行時に旧コードを即失効するか決める
 - [ ] 管理者/member だけ追加防御するか検討する
 ### 76. [P2] Post / Tag / Wiki の操作ログを共通 AuditLog に寄せる
@@ -563,157 +433,6 @@ localStorage の引継ぎコードは実装が簡単だが、XSS で即アカウ
 - [ ] 対象種別・対象 ID・操作・ユーザ・IP を保存する
 - [ ] 管理画面で横断検索できる
 ### 77. [P1] 管理画面の最小構成を作る
 **種別**: feature / admin
 **対象**
 - `frontend/src/pages/admin/*`
 - `backend/app/controllers/admin/*`
 **背景 / 問題**
 公開前に必要なのは派手な機能ではなく、BAN、履歴確認、差し戻し、通報確認を 1 箇所で触れること。今は運用導線が分散/不足している。
 **完了条件**
 - [ ] admin namespace を作る
 - [ ] ユーザ/BAN/履歴/御意見番の最小画面を作る
 - [ ] admin 以外アクセス不可にする
 ### 78. [P2] 既存 open issue の「実装済み疑い」を整理する
 **種別**: project management
 **対象**
 - `btrc-hub.issue.sql`
 - `Gitea issues`
 **背景 / 問題**
 #164 タグ検索機能作成、#171 OR/NOT 検索など、現ソースでは既に実装済みに見える open issue がある。課題表が腐ると優先順位判断が狂う。
 **完了条件**
 - [ ] 実装済み issue を close する
 - [ ] 残作業があるものは title/body を更新する
 - [ ] 巨大 issue は小 issue に分割する
 ### 79. [P1] 公開前チェックリストをリポジトリに置く
 **種別**: release / ops
 **対象**
 - `README.md`
 - `docs/release-checklist.md`
 **背景 / 問題**
 タグ広場は機能量が増えており、「何が揃ったら公開できるか」が頭の中に寄っている。公開判断を文書化しないとスコープが永遠に膨らむ。
 **完了条件**
 - [ ] 法務、BAN、管理画面、履歴復元、Wiki 検索、バックアップ、監視のチェックリストを作る
 - [ ] P0/P1 issue と対応付ける
 - [ ] 公開しない理由と公開できる条件を分ける
 ### 80. [P1] バックアップ / リストア手順を文書化し、定期検証する
 **種別**: ops / disaster recovery
 **対象**
 - `docs/ops/*`
 - `backend/db`
 - `ActiveStorage/R2`
 **背景 / 問題**
 共同編集型の知識基盤は DB と添付ファイルを失うと終わる。バックアップよりリストア検証が本体。
 **完了条件**
 - [ ] DB dump 手順を書く
 - [ ] R2/ActiveStorage のバックアップ方針を書く
 - [ ] ステージングへリストアする手順を作る
 - [ ] 月 1 回など検証周期を決める
 ### 81. [P2] 監視とログ確認の最低線を作る
 **種別**: ops
 **対象**
 - `config/environments/production.rb`
 - `server config`
 - `docs/ops/*`
 **背景 / 問題**
 公開後は「落ちてから気づく」だと遅い。cron 失敗、500 増加、容量増加、R2 エラー程度は見たい。
 **完了条件**
 - [ ] HTTP 死活監視を入れる
 - [ ] cron/batch 失敗通知を入れる
 - [ ] 500 ログ集計を見る
 - [ ] DB/R2 容量の確認手順を書く
 ### 82. [P2] レスポンシブ編集 UI の実機確認チェックを作る
 **種別**: UX / mobile
 **対象**
 - `frontend/src/pages/posts/*`
 - `frontend/src/pages/tags/*`
 - `frontend/src/pages/wiki/*`
 - `frontend/src/components/TopNav.tsx`
 **背景 / 問題**
 スマホで PC 同等の快適さを求めるなら、閲覧だけでなく投稿・タグ編集・Wiki 編集の実機確認が必要。
 **完了条件**
 - [ ] 主要画面のスマホ確認表を作る
 - [ ] タグ補完・Markdown 編集・TopNav を重点確認する
 - [ ] 横幅崩れとキーボード表示時の問題を直す
 ### 83. [P2] タグサイドバーの長い半角文字折り返しを修正する
 **種別**: UX / existing issue
 **対象**
 - `frontend/src/components/TagSidebar.tsx`
 - `frontend/src/components/TagLink.tsx`
 **背景 / 問題**
 既存 #180。長い半角タグ名が見切れる問題はタグ基盤として地味に痛い。
 **完了条件**
 - [ ] break-all / overflow-wrap / min-width を調整する
 - [ ] 長い URL 風タグ・英数字タグで確認する
 - [ ] PC/スマホ両方で崩れない
 ### 84. [P3] アキネータ風お遊び機能の最小仕様を切る
 **種別**: feature / product
 **対象**
 - `docs/spec/*`
 - `frontend/src/pages/*`
 - `backend/app/controllers/*`
 **背景 / 問題**
 公開時の話題性として候補に上がっているが、仕様がまだ霧。ゼロイチ系としては小さく切らないと沼になる。
 **完了条件**
 - [ ] 対象をキャラ/ミーム/投稿のどれにするか決める
 - [ ] 質問生成をタグ階層ベースにするか決める
 - [ ] MVP を 5〜10 問で当てる程度に制限する
 ### 85. [P2] 「主要 Wiki 5000 ページ」計画を生成・レビュー・公開の工程に分ける
 **種別**: content ops
 **対象**
 - `wiki data`
 - `docs/content-plan.md`
 **背景 / 問題**
 5000 ページ目標は野心として正しいが、そのままだと精神論になる。1 行説明でよいなら、タグ優先度と作業単位に落とすべき。
 **完了条件**
 - [ ] 主要タグ抽出クエリを作る
 - [ ] 優先度 A/B/C に分ける
 - [ ] 1 行説明テンプレを作る
 - [ ] 未整備タグ一覧ページを作る
 ### 86. [P3] Wiki 下書き保存を実装する
@@ -731,22 +450,6 @@ Wiki 編集が長文化すると、ブラウザ落ちや競合で書きかけが
 - [ ] ページ/ユーザ単位で下書きを保存する
 - [ ] 復元 UI を出す
 ### 87. [P2] Wiki 編集メッセージ入力欄を追加する
 **種別**: feature / audit
 **対象**
 - `frontend/src/pages/wiki/WikiNewPage.tsx`
 - `frontend/src/pages/wiki/WikiEditPage.tsx`
 - `backend/app/controllers/wiki_pages_controller.rb`
 **背景 / 問題**
 バックエンドは message を受けられるが、フロントに入力欄がない。履歴を見る時に「なぜ変更したか」が残らない。
 **完了条件**
 - [ ] 新規/編集フォームに message 欄を追加する
 - [ ] 空欄可にする
 - [ ] 履歴画面で表示する
 ### 88. [P2] WikiDiffPage の query 変更時再取得と key 不足を直す
@@ -761,38 +464,4 @@ diff 取得 useEffect の依存配列が空で、id/from/to が変わっても
 **完了条件**
 - [ ] 依存配列に id/from/to を入れる
 - [ ] diff 行に安定 key を付ける
 - [ ] ローディング/エラー状態を出す
 ### 89. [P2] Front/back の camelCase / snake_case 変換境界を明文化する
 **種別**: DX / refactor
 **対象**
 - `frontend/src/lib/api.ts`
 - `backend/app/representations/*`
 - `frontend/src/types.ts`
 **背景 / 問題**
 レスポンスは camelize しているが、送信 params は手動で snake_case を混ぜている。API が増えるほどズレる。
 **完了条件**
 - [ ] 送信も decamelize するか、手動 snake_case 方針にするか決める
 - [ ] FormData の扱いを明記する
 - [ ] 型と representation を対応させる
 ### 90. [P1] Tag / Wiki / Post の title/name collation 問題を仕様化する
 **種別**: data integrity / existing issue
 **対象**
 - `backend/db/schema.rb`
 - `backend/app/models/tag_name.rb`
 - `backend/app/models/wiki_page.rb`
 **背景 / 問題**
 DB collation が utf8mb4_0900_ai_ci のため、ひらがな/カタカナ/濁点/大文字小文字などの同一視が起こりうる。既存 #237 と絡む根深い問題。
 **完了条件**
 - [ ] 同一視される文字の実例をテストする
 - [ ] binary collation にするか、アプリ側で同定文字を制定するか決める
 - [ ] 作成前に衝突警告を出す
 - [ ] ローディング/エラー状態を出す