開発者マニュアル

現在のブランチはローカル・クラウド開催を統合検証中の Draft です。 CONTRIBUTING.mdと docs/host-retirement.mdを確認してください。 データの自動移行は行いません。

準備と起動

git submodule update --init --recursive
bun install --frozen-lockfile --ignore-scripts
bun run build:host
make local LOCAL_ARGS="--no-build"

Bun 1.3.11 を使います。host は開催者・参加者アプリを配信し、競技状態を SQLite に保存します。 専用の非公開データディレクトリを用意してください。 ローカルの Docker 問題には Docker が必要です。AWS サービスの問題はクラウド開催専用です。 Lambda + Turso/DynamoDB によるクラウド開催と配置・撤収は検証中です。 組み込みの Battle は Bun で動作します。

担当コード

確認

bun run test:host、bun run test:authoring、bun run typecheck と make before-commit を実行します。既存の lint と coverage の基準を維持してください。 永続化や認証の変更は実 HTTP/SQLite 経路で確認します。 配布に関わる変更では docs/host-build-verification.md も確認します。ブラウザ検証と任意の実 AWS・IdP 検証は、ローカルテストと分けて報告します。

make down は大会と Docker のデータを保持します。クラウドの make deploy / make destroy は、権限設定と所有対象を確認する既存 CLI を実行します。クラウド開催は Lambda・Cognito と選択した Turso / DynamoDB で、汎用 CloudFormation 配置、flag / multi-flag・定期採点、参加者の Console / CLI アクセス、Cryptography Battle などの組み込み coordination を実行します。Docker / Compose 問題はローカル開催専用で、クラウドのカタログには表示しません。実 AWS・hosted Turso での大会性能は未検証です。CLOUD_ARGS="--help" で AWS に接続せず説明を確認できます。

新規クラウド環境の stack 名は tenkacloud-cloud 系です。既存の tenkacloud-lite 系 stack は名前を維持します。CLI は Lite / cloud の既存 stack を検出し、両方ある場合は TENKACLOUD_STACK_LAYOUT=lite または cloud の明示指定が必要です。旧 Lite の更新は所有情報と永続 resource ID を検証します。 catalog pin のない旧 Lite 環境は、resource / schema の検査後、bootstrap・source upload・配置の前に、進行中の大会がないことを初回だけ明示確認します。開催中の大会は完了まで配置済みの版で継続してください。大会が残っていないことを運用者が確認してから対話で承認し、非対話の更新には CLOUD_ARGS="--confirm-no-active-events" を使います。通常の --yes ではこの確認を省略できません。legacy catalog key だけでは安全な更新を証明できず、過去のデータも自動移行しません。新規環境と復旧済み環境は通常の make deploy で自動配置します。公開 cloud-v1 の resource / DB schema への上書き更新は拒否し、データは自動移行しません。--drain-events は使えません。問題環境を大会の Teardown で撤収してから基盤を削除してください。

両 DB とも 99 チーム、SQL coordination は旧 4 MiB 上限です。現行 catalog の 9 template は TemplateBody の 51,200 bytes 上限を超え、TemplateURL は未実装です。全 AWS 問題の配置確認済みを意味しません。

クラウドの大会と配置は、catalog の各 map、hint、plugin、元の問題ファイルを含む非公開 snapshot の catalogKey を保存します。A で作成した大会は、B の配置や B からの問題削除後も A を使います。Lambda は固定した source の hash を検証し、CodeBuild は保存した source ZIP の key と正確な S3 VersionId を使います。pin のない旧データは、元の snapshot を確認して復元した場合だけ CDK_LEGACY_CATALOG_KEY で回復します。現在の catalog を推測で割り当ててはいけません。 この回復設定だけで開催中の旧環境を更新してはいけません。配置済みの版で大会を完了し、進行中の大会がないことの事前確認を満たしてから更新します。

クラウド配置ごとに <configured-key>.executions/<uuid>.zip を新しく upload し、source bucket の versioning を必須とします。別々の key の current version は noncurrent version 用の lifecycle で削除されません。参照する大会が終了し、所有する source bucket を別途確認して清掃するまで保存料金が発生します。基盤の destroy は所有する execution snapshot を削除しますが、別の source archive bucket は残ります。ソースのテストや synth は実 AWS・hosted Turso のリハーサルではありません。