Game Forge

プロンプト 1 行から、ブラウザで遊べる 2D ゲームを生成します。生まれた作品を他の人が改造（フォーク）して公開し合う、UGC コミュニティのリポジトリです。

• 公開形態: 招待制のクローズドβです。プレイと URL の共有は誰でもでき、生成は招待コードを持つ人だけができます。
• ホスト: アプリ本体の app.game-forge.ojos.jp、利用者が作った作品を配信する sandbox.game-forge.ojos.jp、運営の管理画面の admin.game-forge.ojos.jp の 3 つです。

この README は入口です。仕様・手順・進み具合は下の文書が正本なので、ここへは書き写しません。

最初に読む文書

知りたいこと	文書
いまどこまで進んでいて、次に何をするか	docs/handoff.md
何を作るか（仕様と、決定の経緯）	docs/product-spec.md
作業の分解（マイルストーンと issue）	docs/mvp-roadmap.md
手元で動かす・検証する	docs/local-dev.md
AI エージェントの運用ルール	実行環境ごとの入口（Claude Code は CLAUDE.md、GitHub Copilot は .github/copilot-instructions.md）→ .github/project-ai-rules.md → .ai-playbook/shared-ai-rules.md

仕組み

画面と API は Cloudflare Pages Functions で動きます。生成には Cloudflare の待ち時間の上限を超える時間がかかるため、生成の実行は AWS Lambda へ出しています（理由は docs/orchestrator.md の冒頭）。作品は Go（Ebitengine）のソースとして生成し、隔離したビルド関数で WebAssembly にしてからサンドボックスのホストで配信します。

flowchart LR
  browser[ブラウザ]
  subgraph cf[Cloudflare]
    pages[Pages Functions<br>app / sandbox / admin]
    likes[Worker game-forge-likes<br>Durable Objects]
    d1[(D1)]
    r2[(R2)]
  end
  subgraph aws[AWS]
    orch[オーケストレータ<br>Lambda]
    bedrock[Amazon Bedrock]
    build[ビルド関数<br>Go → wasm]
    ogp[OGP 撮影<br>Lambda]
    avatar[アイコン変換<br>Lambda]
  end
  browser --> pages
  pages --> d1
  pages --> r2
  pages --> likes
  pages -->|生成ジョブを投げる| orch
  orch --> bedrock
  orch --> build
  build --> r2
  orch -->|結果のコールバック| pages
  pages --> ogp
  pages --> avatar

部品ごとの正本は次のとおりです。

部品	コード	宣言	運用の手順
アプリ本体（3 ホスト）	functions/・src/	wrangler.toml	docs/pages-deploy.md・docs/admin-host.md
データ（D1 / R2）	migrations/	wrangler.toml・terraform/r2-lifecycle.tf	docs/pages-deploy.md
いいね・プレイ数	workers/likes/	workers/likes/wrangler.toml	docs/likes.md
生成のオーケストレータ	src/orchestrator/	terraform/orchestrator.tf	docs/orchestrator.md

運営が回す手順は、削除依頼の対応が docs/takedown.md、集計が docs/usage-report.md、撤退条件の判定が docs/retreat-review.md にあります。当面の方針（何に時間を使うか）は docs/strategy.md にあります。

手元で動かす

クラウドの開発環境は持たず、クラウドにあるのは本番だけです。開発は手元で行います。前提（Node.js 22 以上・Docker・Go・OpenSSL）は devcontainer にすべて入っています。

npm ci                            # 依存と、wrangler.toml から作る型定義（worker-configuration.d.ts）
cp .dev.vars.example .dev.vars    # アプリが読む値はここへ置く
npm run db:migrate                # migrations/ をローカルの D1 へ当てる（冪等）
npm run dev                       # https://game-forge.localtest.me:8787/

• アプリが読む値は .dev.vars です。.env ではありません。 .env は開発ツール（gh など）向けで、アプリへ流れ込まないよう各 script で止めてあります。
• 証明書は初回の npm run dev が自己署名で作るため、ブラウザは初回に警告を出します。
• ログインを試すには、SESSION_SECRET・Google OAuth のクライアント・招待コードが要ります（docs/local-dev.md の 3 章「ログインを試す」）。
• 生成の経路は手元だけでは通しで確かめられません。 AWS の関数は本番にしか無く、手元の wrangler pages dev から生成を投げると本番のオーケストレータが動きます。手元で確かめられないものの一覧は docs/local-dev.md の 5 章、オーケストレータについては docs/orchestrator.md の「まだ決まっていないこと」にあります。

検証

bash scripts/verify.sh       # ローカル層の受け入れ条件（機密の検査・文書の検査・テスト・型）。VERIFY_PASS で合格
bash scripts/loop-gate.sh    # push / PR 作成の前の単一入口。verify と、第二意見のレビュー（別ベンダーのモデル。無ければ飛ばす）を直列で通す

npm test・npm run typecheck は単体でも回せます。実ブラウザや Docker を要する重い検査と、それぞれが何を確かめるかは docs/local-dev.md の 4 章にあります。宣言と実際の外部状態の一致は scripts/acceptance-remote.sh が確かめます。外部状態の宣言を変えたときに通します。

配備

• アプリ本体といいねの Worker は、main へのマージで GitHub Actions が本番へ出します（.github/workflows/deploy.yml）。検証が緑のときだけ走ります。そのコミットがもう main の先頭でなければ配らず、後のコミットの配備に任せます。本番の D1 に未適用のマイグレーションがある場合と、そのコミットでオーケストレータの束が変わったのに配備済みの関数が手元の束と一致しない場合は、配備の段で失敗して止まります（束が変わらないコミットでは、オーケストレータを見ません）。
• 本番の D1 へのマイグレーションの適用は、自動配備に含まれません。 手順は docs/pages-deploy.md にあります。
• オーケストレータは手元から配ります（docs/orchestrator.md）。ビルド関数のイメージは .github/workflows/deploy-compiler.yml が配ります。
• AWS・GCP・DNS・GitHub の設定と R2 のライフサイクルは Terraform で宣言します。D1・R2 のバケット・Pages のプロジェクトは wrangler で作成済みで、宣言の外にあります。管理の境界は terraform/README.md にあります。state と tfvars は追跡していないので、プライマリの作業ツリーから回します。

権利

• このリポジトリは閲覧のために公開しています。コードと文書の再利用（複製・改変・再配布）は許諾していません（All rights reserved）。ライセンスのファイルを置いていないのは、そのためです。GitHub の利用規約の範囲で、閲覧と fork はできます。
• brand/ のロゴ・アイコン・ロックアップは Game Forge の商標です。 コードとは別の扱いで、将来コードにライセンスを付けても、それには含めません。
• third_party/dotgothic16/ のフォントは SIL Open Font License 1.1 で提供されています。 全文と著作権の表示を同じディレクトリに同梱しています（NOTICE.md）。
• 利用者が生成した作品の権利は、このリポジトリではなくサービスの利用規約（/terms）が定めます。

開発の進め方

• 1 issue = 1 PR です。コミットメッセージは Conventional Commits の接頭辞を付けた日本語で書きます。
• 並行して複数のセッションが動くため、実装は専用の worktree とブランチで行います。
• push の前に bash scripts/loop-gate.sh で、別ベンダーのモデルによる第二意見を通します。同じリポジトリのブランチから出した PR では、その head に第二意見の記録が付いていることを second-opinion-gate.yml が確かめます。fork からの PR は対象になりません。リモートのコードレビュー（GitHub Copilot）は置いていません（#807）。コミットの作者は identity-guard.yml が許可リストと照合します。
• 詳しい規約（intake、レビュー、機密と生成物の扱い）は .github/project-ai-rules.md と .ai-playbook/ にあります。