①どちらの経路を使うか
公開基盤には2つの経路があります。用途で選んでください。このページは右側（新経路）の説明です。
fg-tools-sandbox の中にツールをディレクトリ単位で置く。自然言語の依頼から自動生成・自動公開。小さな社内ツール・画面・モックの量産向け。
既存の独立リポジトリをそのまま1アプリとして公開。main への push/マージでデプロイ。レビュー・保護・CIは各リポジトリ管理者の責任。既に自前で開発しているアプリ向け。
共通点: どちらも private / FGjp-techdes org 内が前提。登録・IP制限・DB払い出しは同じ proxy 経路を通り、公開URLは <名前>.tools.nextop.asia（社内IP限定）で発行されます。
③新規リポジトリを載せる手順
GitHub の repo 権限そのものが承認ゲートになります。
- 申請する公開したいリポジトリ名を管理者（及川）へ申請。
FGjp-techdesorg 内・private・中身の概況（何が動くか）を確認。 - 管理者が GitHub App に追加org Settings → GitHub Apps →
coolify-fg-tools-org→ Repository access に対象リポジトリを追加。この手動追加自体が承認ゲート（追加できるのは org Owner / App manager のみ）。台帳は Installation の一覧が正。 - 登録（自動）proxy 経由で Coolify アプリを登録。リポジトリのルートで Dockerfile /
db.requiredを判定し、許可照合＋申請者の write 権限検証を通過したものだけ登録される。 - 公開・以降のデプロイmain（デフォルトブランチ）への push/マージで自動デプロイ。IP制限（社内限定）と、必要なら per-app DB も自動で付く。
現状の制約（未実装）: proxy は現在 git_repository を1値に固定しており、register-app.sh に --repo 指定と「repo許可照合＋申請者write権限照会」がまだ実装されていません。上記手順が動くには、これらの改修が前提です（設計メモ §3.1）。
初回だけの注意: 新規リポジトリの初回は webhook が取りこぼす場合があるため、1回だけ明示デプロイと「push→自動デプロイ」の実機確認を行います。IP制限の自動適用も初回に必ず実測確認します。
④リポジトリ側の技術要件
新規リポジトリを載せるために、リポジトリが満たすべき最小要件。
必須
FGjp-techdes org 内 かつ private
✓ルートに Dockerfile（ポート3000で待受・PORT優先）または静的な
index.html
✓秘密情報（パスワード・APIキー・DB接続文字列）をコードに直書きしない
✓DBを使うならルートに空ファイル db.required を置き、DATABASE_URL から接続
命名・ドメイン規約
<部署|ユーザ>-<リポ名>.tools.nextop.asia
・DB: db_<ユーザ>_<リポ名> / ロール role_<ユーザ>_<リポ名>
・1アプリ = 1DB = 専用ロール（使い回さない）
DB接続は必ず閉じる: リクエスト毎に接続を開いて閉じない実装は、接続上限到達で「登録も一覧も突然失敗する」障害になります（with 等で確実にクローズ）。
⑤基盤が面倒を見る範囲・見ない範囲
2つの経路で「基盤の責任範囲」が異なります。ここが認識合わせの要点です。
| 項目 | モノレポ（現行） | 1アプリ=1リポジトリ（新経路） |
|---|---|---|
| 変更領域の統制 | directory-ownership-guard で自動検証 | GitHubのrepo権限そのもの（基盤は関与しない） |
| 構文チェック等のcheck | validate-tools | なし（必要なら各リポで用意） |
| 自動マージ | auto-merge で自動 | なし。main への入れ方は repo 管理者の責任 |
| デプロイ契機 | main マージ | main（デフォルトブランチ）への push/マージ |
| 登録・IP制限・DB払い出し | 共通（proxy 経由で自動） | |
要約: 新経路の基盤は「main に入ったものを公開する」だけ。レビュー・保護・品質担保はリポジトリ側の責任になります。