Afterflow / ほりゅまりんJoin us小規模フルスタック“壊れない”を最優先
ポータルを「作品」ではなく、
「運用できるプロダクト」に仕上げる仲間を探しています。
Afterflowは、Discordコミュニティの会話（Flow）を補完する、蓄積（Stock）の場です。 目的は派手さではなく、長期運用・監査可能性・セキュリティ前提の体験設計にあります。
主目的
Discord補完のStock
優先度
壊れない / 監査可能
開発形態
小規模フルスタック
Afterflowの全体像（図）
DiscordのFlowを残し、AfterflowでStockする。運用と境界を最初から設計します。
思想を図で理解する
文章を読む前に “構造” を掴めるように、図解を先に置きます。
設計思想（3本柱）
“速く作る”より“壊さない”。統一規格で品質を揃え、多層防御で事故を防ぎます。
Security by Design
セキュリティは後付けにしない
Consistency
統一規格で全体品質を揃える
Defense in Depth
入口と金庫を分けて守る
多層防御（middleware / page / route）
middlewareが入口、pageは前提アサート、routeが最終防御。依存し切らない設計です。
求める人物像
“技術”と“思想”は分けます。どちらも欠けると、運用で破綻しやすい。
思想（カルチャー適合）
便利さのために境界を崩さず、統一規格を育てられる方。
- “速く作る”より“壊さない”を優先できる
- 統一規格の価値を理解し、例外実装を増やさない
- 設計意図を言語化し、合意形成して進められる
- ログ・再現性・切り分けを大切にできる
- 提案→合意→実装の順で進められる
合わない例
「便利だからroot」「とりあえず例外」「動けばOK」「AIコピペ即投入」「境界は後回し」
技術（実務要件）
新機能追加時に page.tsx → component → route.ts → Prisma を一気通貫で見通せる方。
- Next.js App Router（Server/Client責務）を判断できる
- NextAuth（Discord OAuth / JWT）と認可設計の理解
- middleware / page / route の役割分担を壊さず運用できる
- Docker / Compose / Traefik 前提で安全に実装できる
- DB権限分離とmigration運用を前提に扱える
理想像
小規模フルスタックとして、実装だけでなく運用・保守・再現性まで含めて責任範囲を持てる方。
ワークフロー
開発の順番を固定して、事故率と例外を減らします。
開発の流れ
目的→境界→UI→API→運用メモ。順番に意味があります。
1. Spec
目的と仕様を文章化（なぜ/誰に/何を）
2. Boundary
権限境界を先に決める（middleware / page / route）
3. UI
UIは共通規格に寄せ、例外を増やさない
4. API
401/403/200 とログ方針を明確化
5. Ops
再現条件と運用手順を短く残す
レビュー観点
“漏れ”と“例外増殖”を最優先で潰します。
- 権限チェック漏れ（page/route両方）
- 入力の信用境界（クライアント注入の排除）
- 例外UI増殖の抑制（共通化できないか）
- ログ／エラー理由の明確化
- read_only前提で破綻しないか
品質の合言葉
迷ったらこれに戻る。判断基準を共通化します。
壊れないを最優先
“できる”より“続けられる”。境界と運用を先に決める。例外は増やさず規格を育てる。
開発・責任範囲
“どこまでやるか”を先に握ると、運用が安定します。
Role Matrix（理想）
小規模フルスタック前提。page→route→DB→運用まで俯瞰できる人が強い。
領域
期待
優先
UI
PageShell/Card規格で統一、崩れない実装（min-w-0等）
必須
Backend
route.tsで最終防御、入力境界の設計
必須
DB
Prisma/権限分離（migrator/appuser）を壊さない
必須
Ops
ログ/切り分け/運用手順を残す
歓迎
Security
多層防御の徹底、公開面最小化の思想
歓迎
関わり方（想定）
いきなりコミットではなく、設計思想と統一規格の共有から始めます。
Step 1
現状把握（設計思想・境界・運用）
Step 2
小さな改善（UI/ログ/ガード）を1本
Step 3
新機能追加（page→route→Prisma）
Step 4
運用メモの標準化（事故対応手順）
最初のタスク例
Joinページの改善（UI規格の固定） / Admin系の共通ガード整備 / ログの粒度調整 など。
これから作る機能（ロードマップ）
“ワクワク”は方向性が見えると強くなる。今の延長線で積む項目を見える化します。
Short
運用の安定化とUXの底上げ
- Join/Docsの整備（統一規格）
- 管理UIの共通ガード強化
- ログ閲覧導線の改善
Mid
ストック価値を増やす
- 検索性（タグ/フィルタ）
- 投稿・添付の標準化
- 監査ログのUI化
Long
コミュニティの基盤へ
- モジュール型機能追加（Mini Apps）
- 権限モデルの拡張
- バックアップ/復旧手順の固定
現状の利用技術
運用前提で“壊れない構成”を組んでいます。
アプリケーション
App Router中心、認証/認可/DBを一気通貫で扱います。
Next.js（App Router）TypeScriptTailwind CSSNextAuth v4（Discord OAuth / JWT）PrismaPostgreSQLCloudflare Turnstile（Contact）
Auth
Discord OAuth / JWT session
Access
middleware中心の一次制御
API
route.tsは必ずセッション再検証
Contacts
スレッド型（Contact / ContactMessage）
インフラ / 運用
公開面を最小化し、不変運用を前提にします。
Docker ComposeTraefik（Reverse Proxy / HTTPS）Ubuntu（VPS）Fail2banread_onlycap_drop / no-new-privileges
Ports
80/443/22 のみ公開
DB
外部非公開（Dockerネットワーク内）
Migration
migratorで実施、webは実行しない
Obs
Traefik log + Fail2ban可視化
FAQ
最初に聞かれがちなところを先回りで潰します（迷いを減らす＝参加しやすい）。
どのくらいの頻度で関わる想定？▾
どのくらいの頻度で関わる想定？
▾
最初は軽め（小さい改善を1本）から。慣れてきたら新機能追加（page→route→Prisma）を一緒に回す想定です。
いきなりコミットが必要？▾
いきなりコミットが必要？
▾
不要です。まず思想・統一規格・境界の合意を作ります。合意後に小タスクから入ります。
何を最優先にする？▾
何を最優先にする？
▾
壊れないこと（セキュリティ/運用/監査可能性）。派手さは二の次です。
技術的に一番大事なところは？▾
技術的に一番大事なところは？
▾
権限境界（middleware/page/route）と、route.ts側の最終防御の徹底です。