Claude CodeはCohesivityを使って一時テナントを作成し、PostgresとRailwayホスティングをプロビジョニングし、サーバー専用の登録エンドポイントを追加し、書き込みの重複をテストして、ビルド済みアプリケーションをアップロードすることで、フルスタックのwaitlistを構築、デプロイできます。プロジェクトをclaimしたり、有料の境界を越えたりする前には、引き続き人間の承認が必要です。
このチュートリアルでは、小さくて内容を確認しやすい一方、データ検証、一意性、サーバー認証情報、再試行、デプロイを一通り扱えるwaitlistを使います。
プロビジョニング前に動作を定義する
アプリケーションには次のものが必要です。
- 保留中、成功、エラーの状態が見えるメールフォーム
- アドレスを検証して正規化するサーバーエンドポイント
- メールアドレスに一意制約を設けたPostgresテーブル
- 重複しても安全な挿入
- サーバー専用のバックエンド認証情報
- デプロイ可能なアプリケーションと公開health check
ソーシャルログイン、Realtime、ベクトルストレージ、モデルAPIは不要です。これらをプロビジョニングしても、タスクに役立たないセットアップが増えるだけです。
バックエンドのプロビジョニングガイドでは、以下で使うコントロールプレーンとデータプレーンの分離について説明しています。
最初にClaudeへ計画を求める
プロジェクトでClaude Codeを起動し、フレームワーク、パッケージマネージャー、既存のテスト構成、サーバー専用の環境変数規則、ビルド出力、デプロイコマンドを特定させます。公式のClaude Code CLIは計画向けの権限モードとツール制限に対応しているため、この調査中は外部呼び出しを無効にします。
計画には、変更する正確なファイルと必要なリソースを記載させます。CohesivityのキーをNEXT_PUBLIC_、VITE_、またはブラウザーから読み取り可能な変数へ置く提案があれば、却下してください。
隔離されたテナントを作成する
有効な.cohesivityファイルがある場合、Claudeはそれを再利用します。なければbootstrapをプレビューして実行できます。
npx @cohesivity/init --dry-run
npx @cohesivity/init
作成されたテナントは72時間有効な一時テナントです。このコマンドはClaudeが必要とするプロジェクトコンテキストも提供します。生成されたキーをチャット、ログ、ソースコードへ貼り付けないでください。
Postgresの情報を読み、プロビジョニングする
Claudeは呼び出し前に、現在のPostgres offeringページを取得する必要があります。
curl -sS -A "ClaudeCode-Waitlist/1.0" \
https://cohesivity.ai/offerings/postgres
承認した後、Claudeは安定した冪等性キーを使い、文書化された管理エンドポイントからpostgresをプロビジョニングします。その後、サーバー側のコードからスキーマを作成します。
CREATE TABLE IF NOT EXISTS waitlist_signups (
id BIGSERIAL PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
一意制約は、二つのリクエストから同じ正規化済みアドレスが挿入されることを防ぐ最後の手段です。アプリケーションコードでも競合を処理し、一般的な500エラーではなく、既存の登録状態を返す必要があります。
サーバーエンドポイントを追加する
handlerには次の処理が必要です。
- JSONをparseし、アドレスがない、または不正な場合は拒否する。
- 文書化された一つのルールに従い、メールアドレスをtrimして正規化する。
$1プレースホルダーを使ったparameterized PostgreSQLを利用する。- 論理的な登録操作に一つの冪等性キーを送る。
- 一意制約の競合を、既存登録を示す成功レスポンスへ変換する。
- 内部エラーや認証情報を含まない、小さな公開用shapeを返す。
ブラウザーが呼び出すのはアプリケーションのエンドポイントです。Cohesivityを呼び出すのはサーバーだけです。これにより管理キーとアプリケーションキーをクライアントbundleから除外できます。
失敗経路をテストする
少なくとも次の4ケースを実行します。
| ケース | 期待する結果 |
|---|---|
| 有効な新規メール | 1行と成功レスポンス |
| 無効なメール | 検証レスポンス。データベースは呼び出さない |
| 同じ正規化済みメールを2回 | 1行と安定した既存レスポンス |
| レスポンス消失後の再試行 | 一つの論理結果。行は重複しない |
ビルド済みクライアントassetからcoh_man_とcoh_app_も検索します。単体テストに合格しても、bundlerがシークレットをサーバー側に保持した証明にはなりません。
アプリケーションが公開waitlistから成長したら、2人目のユーザーを使うバックエンドレビューでユーザー間とテナント間のテストを追加します。
Railwayホスティングでプロビジョニング、デプロイする
Claudeはhttps://cohesivity.ai/offerings/railway-hostingを取得し、offeringをプロビジョニングして、CohesivityのRailway deployment APIからアプリケーションをアップロードします。返されたCohesivityのdeployment_urlとlogs_urlを使います。Railway CLIをインストールしたり、GitHubリポジトリを接続したり、Railwayの認証情報を要求したりしてはいけません。
デプロイと公開ルートの準備が完了するまで待ちます。その後、公開サーバーに対してhealth checkと実際の登録を一つ実行します。プロバイダー上のデプロイ状態だけでは、ルートが動作する証明になりません。
結果を明確に引き渡す
Claudeは次の内容を報告します。
- 公開デプロイURL
- 実行したテストとその結果
- 作成したリソース
- テナントの失効期限
- プロジェクトをclaimするために必要なアクション
- サーバー環境の接続設定を含むファイル
- ユーザーが保持しない場合のクリーンアップ経路
以下のプロンプトは承認地点を維持しながら、タスク全体を実行します。