launch-checklist

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys rigor,workflow,project.stage,cert_tier,automation

自動化モード：modes.automation を解決します（project.local.yaml → project.yaml → デフォルトの collaborative）。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは .claude/docs/automation-modes.md に従います （collaborative は常に質問 · guided は主要事項のみ · autonomous は記録して続行； automation_always_ask カテゴリは常に確認します）。

上で解決した値をそのまま使用してください。ブロックがない場合は、.claude/docs/config-resolution.md のデフォルトを使用します。

起動チェックリスト

このチェックリストの範囲をプロジェクトに合わせてください。 すべてのプラットフォーム向けの項目を毎回すべて出力すると、読み手がリストを読み飛ばすようになり、このゲートの目的が損なわれます。

• project.stage — このプロジェクトがまだ到達していないフェーズの項目は対象外です。未チェック項目として列挙するのではなく、その旨を明記してください。

• modes.rigor — minimal の場合、このプロジェクトが選択していないプロセス上の負担のみを根拠とする項目は削除してください。

• platform.cert_tier — 認定項目は、プロジェクトが対象とするティアについてのみ出力してください。未設定の場合は、すべての項目を出力するのではなく、対象とするプラットフォームを確認してください。未設定は質問を意味し、すべての認定トラックを出力してよいという意味ではありません。回答を以下の4つの値に対応付けたものが、この実行でのティアになります。特定できない場合は、セクションに NOT ASSESSED — cert tier unknown と記載してください。未設定は none ではありません。 none は決定済み、未設定は未決定であり、同じ出力にしてはいけません。このキーが取り得る4つの値（none | itch | steam | console）に基づいて分岐し、プラットフォーム名に基づいて分岐しないでください。要件の完全な表は .claude/docs/effects-map.md の ## platform.cert_tier セクションです。そのセクションのみを読んでください（見出しを Grep し、範囲を限定して Read してください）。ファイル全体は実行時の入力ではありません。

  • none — 認定セクションは一切出力しないでください。社内リリース、アルファ版、またはゲームジャム向けゲームです。セクションを省略したこととその理由を記載してください。空欄のままにしてはいけません。
  • itch — itch.io へのアップロード要件のみ：ビルドサイズ、ページ設定、年齢タグ。コンソールおよび Steamworks の項目は含めません。
  • steam — Steamworks：ストアページ、デポビルド、実績、システム要件、共通のコンテンツルール。コンソール認定項目は含めません。
  • console — 完全なプラットフォーム認定（TRC / XR / Lotcheck）、セーブデータのルール、コントローラーマッピングのルール、年齢審査機関。最も負荷の高いティアです。

  プラットフォーム名ではなく、上記の cert_tier の値に基づいて分岐してください。 対象プラットフォームを判定条件にすると、itch プロジェクトと steam プロジェクトを同一に扱い、none と未設定を混同し、cert_tier の値ではない mobile をキーにしてしまいます。設定で定義されている語彙を使用してください。

設定がないために項目の範囲を定められない場合は、NOT ASSESSED — platform/stage unknown と記載してください。黙って含めないでください。そうしないと、rigor: standard の単一プラットフォームのプロジェクトに、PC とコンソール とモバイルの認定に加えて年齢審査まで求める約150項目のチェックリストが提示され、そのうち約140項目は評価できないことになります。

---

フェーズ1：引数の解析

リリース日または dry-run モードの引数を読み取ります。dry-run モードでは、承認記録を作成したりファイルを書き込んだりせずにチェックリストを生成します。引数がない場合は、対象日を未設定（Target Launch: not set）とする通常の実行です。dry-run にするのは、引数が dry-run を指定している場合のみです。

---

フェーズ2：プロジェクトのコンテキスト収集

• 技術スタック、対象プラットフォーム、チーム構成について CLAUDE.md を読む
• production/milestones/ にある最新のマイルストーンを読む
• production/releases/ に既存のリリースチェックリストがあれば読む
• design/live-ops/content-calendar.md が存在する場合は、コンテンツカレンダーを読む

---

フェーズ 3：コードベースの健全性をスキャンする

このフェーズのスキャンはすべて問題のあるものを探すため、ヒット数がゼロという結果は、構造上あいまいです。「検索して見つからなかった」か「検索対象がなかった」のどちらかを意味します。リリース判定ではこの2つは正反対の結果ですが、チェックボックスを緑にすると同じように表示されます。

以下の各スキャンの前に分母を確定し、報告してください。 各行には、scanned [N] files, [M] hits または NOT ASSESSED — [code root unresolved | no source files | no asset folder | directory empty] のいずれかを記載します。 チェックだけを記載してはいけません。コードルートはエンジンに応じて src/、Assets/、または Source/ です（.claude/docs/code-root-resolution.md に従って解決してください）。アセットは assets/、Assets/、または Content/ にあります。

以下の4項目すべてに適用されます。いずれも同じ方法で、プレースホルダーアセット、TODO、デバッグ出力、ハードコードされたテスト値を検索し、ルートが空または存在しない場合はヒット数がゼロになります。たとえば、assets/ ディレクトリがない場合、プレースホルダーのスキャン結果はヒット数ゼロとなり、チェックだけを記載すると「すべてのプレースホルダーアートが置き換えられました」が緑になります。

• TODO、FIXME、HACK コメントの数と場所を確認する
• 本番コードに console.log、print()、デバッグ出力が残っていないか確認する
• プレースホルダーアセットを確認する（placeholder、temp_、WIP_ を検索する）
• ハードコードされたテスト／開発用の値を確認する（localhost、テスト用認証情報、デバッグフラグ）

チェックリストにもこの区別を反映してください。 スキャン結果が NOT ASSESSED の項目は、- [ ] ではなく - [?] と記載します。未チェックのボックスは 作業が残っている ことを示し、[?] は 誰も確認できなかった ことを示します。作業を行うことで解消できるのは前者だけです。[?] がある場合は、次の凡例を記載してください。 [?] = not assessed — the input to this check was absent

---

フェーズ 4：リリースチェックリストを作成する

# Launch Checklist: [Game Title]
Target Launch: [Date or DRY RUN]
Generated: [Date]

---

## 1. Code Readiness

### Build Health
- [ ] Clean build on all target platforms
- [ ] Zero compiler warnings
- [ ] All unit tests passing
- [ ] All integration tests passing
- [ ] Performance benchmarks within targets
- [ ] No memory leaks (verified via extended soak test)
- [ ] Build size within platform limits
- [ ] Build version correctly set and tagged in source control

### Code Quality
- [ ] TODO count: [N] (zero required for launch, or documented exceptions)
- [ ] FIXME count: [N] (zero required)
- [ ] HACK count: [N] (each must have documented justification)
- [ ] No debug output in production code
- [ ] No hardcoded dev/test values
- [ ] All feature flags set to production values
- [ ] Error handling covers all critical paths
- [ ] Crash reporting integrated and verified

### Security
- [ ] No exposed API keys or credentials in source
- [ ] Save data encrypted
- [ ] Network communication secured (TLS/DTLS)
- [ ] Anti-cheat measures active (if multiplayer)
- [ ] Input validation on all server endpoints (if multiplayer)
- [ ] Privacy policy compliance verified

---

## 2. Content Readiness

### Assets
- [ ] All placeholder art replaced with final assets
- [ ] All placeholder audio replaced with final audio
- [ ] Audio mix finalized and approved by audio director
- [ ] All VFX polished and performance-verified
- [ ] No missing or broken asset references
- [ ] Asset naming conventions enforced

### Text and Localization
- [ ] All player-facing text proofread
- [ ] No hardcoded strings (all externalized for localization)
- [ ] All supported languages translated and verified
- [ ] Text fits UI in all languages (text fitting pass complete)
- [ ] Font coverage verified for all supported languages
- [ ] Credits complete, accurate, and up to date

### Game Content
- [ ] All levels/maps playable from start to finish
- [ ] Tutorial flow complete and tested with new players
- [ ] All achievements/trophies implemented and tested
- [ ] Save/load works correctly for all game states
- [ ] Difficulty settings balanced and tested
- [ ] End-game/credits sequence complete

---

## 3. Quality Assurance

### Testing
- [ ] Full regression test suite passed
- [ ] Zero S1 (Critical) bugs open
- [ ] Zero S2 (High) bugs open (or documented exceptions) — at `workflow: full` instead: zero S2 (High) and S3 (Medium) bugs open, no exceptions
- [ ] Soak test passed (the longest soak `/soak-test` runs, or longer by hand if a play session lasts longer)
- [ ] Multiplayer stress test passed (if applicable)
- [ ] All critical user paths tested on every platform
- [ ] Edge cases tested (full storage, no network, suspend/resume)

### Platform Certification

**Emit ONLY the block matching `platform.cert_tier`** (resolved in the resolved-config block at the top of this skill — see
the `platform.cert_tier` rule above). Do not emit this section's other blocks, and
do not fall back to emitting all of them.

**At `none`** — omit the section and say so in one line:
`Platform Certification: omitted — cert_tier is 'none' (internal/jam release).`

**At `itch`:**
- [ ] Build size within itch.io upload limits
- [ ] itch.io page complete (cover art, screenshots, description, tags)
- [ ] Age/content tags set honestly
- [ ] Downloadable vs browser build decided and tested

**At `steam`:**
- [ ] Steamworks SDK integrated and tested
- [ ] Store page complete (capsule art, trailer, description, system requirements)
- [ ] Depot build uploaded and installs cleanly from a fresh account
- [ ] Achievements functional
- [ ] Steam common content rules reviewed

**At `console`:**
- [ ] TRC/TCR/Lotcheck submission prepared
- [ ] Save-data rules compliant (corruption, full storage, user switching)
- [ ] Controller-mapping rules met, platform-correct button prompts
- [ ] Suspend/resume verified
- [ ] Age ratings obtained (ESRB, PEGI, regional)

**Every tier**, because these are not certification-gated:
- [ ] Accessibility: minimum standards met (remapping, text scaling, colorblind)

> **Emit this section gated by tier, never as one ungated list.** PC *and*
> Console *and* Mobile rows emitted at every tier contradict the `cert_tier` rule
> at the top of this skill, which says an `itch` project gets no console and no
> Steamworks items.

### Performance
- [ ] Target FPS met on minimum spec hardware
- [ ] Load times within budget on all platforms
- [ ] Memory usage within budget on all platforms
- [ ] Network bandwidth within targets (if multiplayer)
- [ ] No frame hitches in critical gameplay moments

---

## 4. Store and Distribution

### Store Pages
- [ ] Store page copy finalized and proofread
- [ ] Screenshots current and per-platform resolution
- [ ] Trailers current and approved
- [ ] Key art and capsule images finalized
- [ ] System requirements accurate (PC)
- [ ] Pricing configured for all regions
- [ ] Pre-purchase/wishlist campaigns active (if applicable)

### Legal
- [ ] EULA finalized and approved by legal
- [ ] Privacy policy published and linked
- [ ] Third-party license attributions complete
- [ ] Music/audio licensing verified
- [ ] Trademark/IP clearance confirmed
- [ ] GDPR/CCPA compliance verified (data collection, consent, deletion)

---

## 5. Infrastructure

### Servers (if multiplayer/online)
- [ ] Production servers provisioned and load-tested
- [ ] Auto-scaling configured and tested
- [ ] Database backups configured
- [ ] CDN configured for content delivery
- [ ] DDoS protection active
- [ ] Monitoring and alerting configured

### Analytics and Monitoring
- [ ] Analytics pipeline verified and receiving data
- [ ] Crash reporting active and dashboard accessible
- [ ] Server monitoring dashboards live
- [ ] Key metrics tracked: DAU, session length, retention, crashes
- [ ] Alerts configured for critical thresholds

---

## 6. Community and Marketing

### Community Readiness
- [ ] Community guidelines published
- [ ] Moderation team briefed and tools ready
- [ ] Discord/forum/social channels set up
- [ ] FAQ and known issues page prepared
- [ ] Support email/ticketing system active

### Marketing
- [ ] Launch trailer published
- [ ] Press/influencer review keys distributed
- [ ] Social media launch posts scheduled
- [ ] Launch day blog post/dev update drafted
- [ ] Patch notes for launch version published

---

## 7. Operations

### Team Readiness
- [ ] On-call schedule set for first 72 hours post-launch
- [ ] Incident response playbook reviewed by team
- [ ] Rollback plan documented and tested
- [ ] Hotfix pipeline tested (can ship emergency fix within 4 hours)
- [ ] Communication plan for launch issues (who posts, where, how fast)

### Day-One Plan
- [ ] Day-one patch prepared (if needed)
- [ ] Server unlock/go-live procedure documented
- [ ] Launch monitoring dashboard bookmarked by all leads
- [ ] War room/channel established for launch day

---

## Go / No-Go Decision

**Overall Status**: [READY / CONDITIONAL / NOT ASSESSED / NOT READY]

First match wins: **NOT READY** if Blocking Items is not empty; else **NOT
ASSESSED** if any item is `- [?]`, any section came out `NOT ASSESSED`, or any
item is still unconfirmed — neither ticked on evidence or on a Phase 4b answer,
nor marked N/A, nor listed below (name each; group by section when there are
many); else **CONDITIONAL** if Conditional
Items is not empty; else **READY**. NOT ASSESSED outranks CONDITIONAL and READY —
an item nobody could check is not a passed one — and ranks below NOT READY, so a
known blocker is never buried behind it.

### Blocking Items
[Every FAIL or unresolved finding: a check that found a problem — FIXMEs, debug
output, placeholder assets, hardcoded dev values, an open S1 bug, a failing
build or test — with no documented workaround and no explicitly accepted risk]

### Conditional Items
[Every shortfall with a documented workaround or an explicitly accepted risk —
e.g. a HACK with its documented justification, an S2 with a documented
exception (below `workflow: full`, which allows none). Name the workaround, or
who accepted the risk]

### Sign-Offs Required
- [ ] Creative Director — Content and experience quality
- [ ] Technical Director — Technical health and stability
- [ ] QA Lead — Quality and test coverage
- [ ] Producer — Schedule and overall readiness
- [ ] Release Manager — Build and deployment readiness

---

フェーズ 4b：人にしか確認できない事項を確認する

上記の項目のほとんどは、リポジトリからは確定できません。オンコールのスケジュール、EULA、プレスキー、価格設定、誰かが実施したソークテストなどです。尋ねなければ、どの項目も未確認のままとなり、Overall Status は NOT ASSESSED にしかならないため、質問してください。

7つのセクションそれぞれについて、スキャンやファイルの確認で確定できなかった項目を集め（フェーズ 3 の件数とフェーズ 2 で読み取った内容は再度尋ねません）、各セクションにつき AskUserQuestion を1回行い、該当項目を番号付きで列挙します。各項目の回答は yes / no / not yet / N/A のいずれかです。選択肢：Yes — all of them / Not yet — none of them / N/A — this section does not apply / Some differ — I'll answer per item（この場合、ユーザーは番号付きの各項目に回答します）。確認する項目が残っていないセクションはスキップします。

• yes → - [x] とチェックし、(confirmed by the user) と記載する
• no または not yet → 未達項目として、Blocking Items に記載する。ユーザーが回避策を示すかリスクを受け入れた場合は Conditional Items に記載する
• N/A → - N/A — [item] と記載し、Overall Status から除外する
• 回答のない項目は未確認のままとし、ステータスにその項目を記載する

これらはユーザーだけが回答できる事実に関する質問なので、collaborative と guided のどちらでも尋ね、ユーザーに代わって回答してはいけません。autonomous モードと dry-run では、このフェーズをスキップし、その旨を伝えます。このフェーズで尋ねるはずだった項目は未確認のままとなり、Overall Status は NOT ASSESSED になります。

その後、回答をもとに Go / No-Go セクションを記入します。

---

フェーズ 5：チェックリストを保存する

完成したチェックリストと概要をユーザーに提示します（Overall Status、項目の合計数、Blocking Items の数、Conditional Items の数、not-assessed 項目の数、セクションが未完了の部門）。

dry-run モードでない場合は、「production/releases/launch-checklist-[date].md に書き込んでもよろしいですか？」と尋ねます。

回答を得るまでは何も作成しないでください。production/releases/ ディレクトリも作成してはいけません。 はいの場合はファイルを書き込みます。書き込み時にディレクトリも作成されます。

---

フェーズ 6：次のステップ

• project.stage が Release でない場合（Polish、それ以前のステージ、または未設定）は、まず /gate-check release を実行してください。これはリリース前の準備状況を確認するゲートです。
• 承認とデプロイを /team-release で調整してください。