diff --git 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 index 35afef1..89cf904 100644 --- 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 にするか、アプリ側で同定文字を制定するか決める -- [ ] 作成前に衝突警告を出す \ No newline at end of file +- [ ] ローディング/エラー状態を出す \ No newline at end of file