miteruzo
/
btrc-hub
1
0
Fork 0
Code Issues 70 Pull Requests 1 Releases 0 Wiki Activity

master
みてるぞ 1 day ago
parent
748199ac6e
commit
db55dcd5f2
1 changed files with 1 additions and 332 deletions
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. +1
    -332
      %E8%AA%B2%E9%A1%8C%E6%95%B4%E7%90%86.md

+ 1
- 332
%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 にするか、アプリ側で同定文字を制定するか決める
- [ ] 作成前に衝突警告を出す
- [ ] ローディング/エラー状態を出す

Write Preview
Loading…
Cancel
Save