# 開催の追加と複製 ## 複製元を選ぶ 固定のファネルテンプレートは別に維持しない。現在の対象開催に制作済み資産があれば、先に用途と保存状態を確認して引き継ぐ。直近の同タイトル・同方式（個別相談CTA、起動条件、対象者）の開催を優先する。新しい開催でも未解決の不具合があれば、その箇所は正常確認済みの開催と比較する。タイトルだけで決めない。 先行回の完成・レビュー後に展開する指定では、その回の検証結果と生成手順の修正を反映してから次回を作る。別CTA方式の開催には、正常確認した共通部品だけを適用する。 `運用データ/events/*.json` の工程別確認記録、未完事項、`cloneEligible`、`cloneEligibilityNote` を確認し、`clonedFromEventKey` と `cloneReason` を残す。適切な同タイトルがなければ最も近い開催を選んだ理由と差分を記録する。複製元が分からない過去記録では推測せずnullを維持する。 ## 開催別の原本 - `eventKey`：一度決めたら固定する管理キー。URLは `/開催/{eventKey}/`。日程変更時もキーは変えない。 - `eventId`：Lステップなどで使う開催ID。実際の完全一致名を保持する。 - `scheduledDate`、`date`、`lifecycle`：開催日・表示日時・準備中／開催前／開催中／開催後／中止。開催後でも実装完了を意味しない。 - `stages`：共通工程の実設定と確認状態。工程追加時は共通定義に合わせて項目を追加し、未確認と適用済みを分ける。 - `changes`：今回変更したことと未反映事項。 - `recordedSpec`：記録時の設計を比較するスナップショット。本番適用の証拠ではない。 - `appliedSpecVersion`：本番の保存・読戻しで確認できた仕様版。未確認はnull。共通仕様の改訂やビルドだけで進めない。 - `cloneEligible`：次回の複製元候補にできるか。trueでも個々の未完事項を再確認する。 ## 次回を追加する 制作物は指定プロジェクト直下の開催別フォルダへ保存する。既存フォルダがあれば再利用し、なければ開催日・タイトルが分かる名前で作る。原稿・画像・プレビュー・QAはここに集め、開催設定の原本JSONと共通スキルへの参照を残す。開催別にスキル原本を複製しない。 `python3 tools/create-event.py --source --key <新しいeventKey> --title <公開名> --date YYYY-MM-DD --time HH:MM --reason <選定理由>` でローカルの開催記録を作る。日時未確定ならdate/timeを省略できる。これは準備中の記録だけを作成し、Lステップの資産複製は行わない。 複製元リンクを残し、実設定・ID・URL・件数・確認状態は空にして開始する。公開名、日付、時刻、Zoom、フォーム、タグ、友だち情報、リマインダ、起動条件、LP・CTA、受付期限、媒体リンク、募集の日時と除外条件を今回値で埋める。旧開催の読戻し・実発火・公開状態を引き継がない。 フォーム、アンケート、リマインダ、終了後シナリオ、開催別QR流入経路・タグ・計測リンクは開催ごとの新しい資産へ複製する。KIT等の共通流入経路は開催専用資産と区別し、採用した共有入口を開催数だけ複製しない。共通カレンダー、予約後の共通配信、SEO固定入口など共有する資産は共有であることと影響範囲を記録する。複製元の旧タイトル、開催ID、日時、URL、停止条件、旧起動トリガーの残存を確認する。 過去の実名にTS_A/TS_Bが含まれていても、今回のダッシュボード移行で改名しない。新開催では既存の参加状態・開催ID欄を上書きして並行開催へ影響しないよう、保存先と参照条件を設計・確認する。 ## 完了確認 - 開催専用資産のID・URLが前回と分離され、各リンクが今回開催へ到達する。 - 共通資産の変更が他開催へ与える影響を確認した。 - 複製元・選定理由・変更点・未完事項・複製候補への適否が記録されている。 - 設定の保存、読戻し、実発火、配信予約、公開到達を個別に確認した。 - [ダッシュボード更新](dashboard-update.md) に従い、原本・生成手順・表示を同期した。 共通資産の現行参照は `運用データ/shared-assets.json` へ登録し、各開催の `sharedAssetRefs` で参照する。各工程内のリンクは確認時点の記録として保持する。新しい開催の共通資産参照は依存関係を確認して追加する。ビルダーは未分類の同一管理ID・同一URLが複数開催に入ると停止するため、正当な共有は共通資産として明示する。`assetMigrationStatus` で旧方式からの本番分離状況、`followUpStatus` で開催終了とは別のフォロー完了状態を記録する。 ## 予約完了タグの複製防止 新開催の `tagBindings.seminarReservation` は標準名だけを生成し、ID・確認日・参照先・旧補助タグを空にする。Lステップ作成前に完全一致名の既存有無を確認する。今回の正本ID確定後、フォーム付与・除外・集計を同じIDへ接続する。旧開催の「申込済」等の別名や二重付与を引き継がない。具体的な登録と検証は [予約完了タグの契約](registration-flow.md) に従う。