studio-loop

Studio の改善ループ

Studio のエクスペリエンスを担い、すばやく、応答性が高く、信頼できるものにします。NLE 編集とモーショングラフィックスを組み合わせた実際の YouTube 動画の制作を続け、そのワークフローを使って問題を見つけ、修正します。実装を変更するたびに studio-dev を適用してください。

プロジェクトとブラウザーを再開する

• 既存の作業ツリー、ブランチ／PR またはスタック、ローカルの動画プロジェクト、起動中の Studio、ブラウザーセッション、引き継ぎメモを復元します。毎回別のデモを始めるのではなく、そのプロジェクトを続けてください。無関係な変更とローカルの QA アセットは保持し、依頼がない限り動画プロジェクトや書き出しファイルをコミットしないでください。
• 必要に応じて Git の状態とセットアップ手順を確認しますが、実装を分析する前に Studio を使ってください。作業ツリーと URL が判明している場合に限り、サーバーを再利用します。それ以外の場合は、packages/example から bunx remotion studio --no-open で Studio を起動し、ポート 3000 がこのチェックアウトのものだと決めつけず、表示された URL を使ってください。必要に応じて依存関係をビルド／インストールします。
• ユーザーに Mac のロック解除を求めないでください。 既存の利用可能なブラウザーセッションを使うか、デスクトップ／ブラウザーの UI にアクセスできない場合は、ローカルの Studio 用に新しいヘッドレス Playwright ブラウザーを起動します。このワークフローは Mac のロック解除に依存しません。ブラウザーツールは製品の変更とは分けてください。
• クリック、キーボード入力、ドラッグ＆ドロップ、ファイルアップロード、スクリーンショットを使って、実際の UI を操作します。状態の読み取りやサポート対象の操作には、実際に登録された WebMCP ツールを使い、必要に応じてプロジェクトを直接編集します。UI の確認をソースコードの調査やモック動作で置き換えないでください。ブラウザーの実行に失敗した場合は、ヘッドレス環境のセットアップを診断し、残っている検証上の不足を報告します。自動化の失敗を Studio の不具合として扱わないでください。UI の検証が引き続き妨げられる場合は、該当する作業をドラフトのままにし、検証済みのチェックポイントだと主張せずに不足を報告してください。それに依存しない作業は続けてください。

ループを継続する

1. 実際の編集作業を続けます。一般的なワークフローを優先してください。メディアのインポートとプレビュー、クリップの配置／トリミング／分割、テキストとトランスフォームの編集、モーショングラフィックスと音声の追加、シーク／再生、元に戻す／やり直す、保存／再読み込みを行い、その後、レンダリングして書き出した動画を確認します。次に行う作業は、それまでに実施した内容に応じて変えてください。
2. 問題が発生したら、関連する実装を調べる前に、再現可能な操作と期待される結果を記録します。コードを変更する前に、関連するパフォーマンスのベースラインを記録します。応答の遅さ、楽観的な処理経路の欠如、ちらつき、分かりにくい文言やエラー、レイアウトの誤り、codemod の失敗、競合、不要な処理を確認します。リクエストが成功したからといって編集も正しく行われたと思い込まず、永続化されたソースと画面上の結果を確認してください。
3. 確認した問題を修正します。内部リファクタリングは可能ですが、実験的ではないドキュメントがある公開 API のシグネチャは変更しないでください。Studio 既存のデザイン、楽観的更新／履歴処理経路、CSS リセット、iframe のホバー処理、各モードの機能に従ってください。コード編集可能なアクションで、すでにエージェントによる操作が可能です。冗長な WebMCP ラッパーは追加しないでください。新しいツールや変更したツールの契約については、studio-dev の要件に従ってドキュメントを更新してください。
4. 再ビルドした UI で、最初に行った操作をもう一度実行します。即時フィードバック、永続化／HMR、関連する失敗やナビゲーションの競合、元に戻す／やり直すを確認します。埋め込みに依存する変更には実際の Browser Studio iframe を使用し、該当する Studio モードを確認します。修正の影響を受ける近隣の一般的な操作も再確認してください。
5. 条件を比較できるプロジェクト、ビューポート、操作、再生状態で、パフォーマンスを再測定します。再生が実際に開始されたことを確認し、測定中にビルドやレンダリングを同時に実行しないでください。studio-perf に従い、レンダー／コミット処理が関係する場合は react-scan を使用します。リグレッションを解消し、広範囲に確認したと主張するのではなく、測定上の制約を報告してください。
6. 影響を受ける既存のチェックと、pr で必要とされる検証を実行します。writing-tests に従ってください。明示的に依頼されていない限り、リポジトリにテストケースを追加しないでください。一時的な再現用スクリプトやプロファイリング用スクリプトは、リポジトリの外に保存できます。
7. 検証済みの本番環境向け変更をコミットし、現在の PR にプッシュします。PR のタイトルと説明も最新の状態に保ってください。ユーザーからチェックポイントや別の PR を求められるまで、繰り返し同じ PR を使用します。動画の作成に戻って作業を繰り返してください。修正の成功や進捗報告は、ループを止める指示ではありません。

有用な場合は、独立した再現、レビュー、または範囲を限定した実装作業を委任します。実装担当者ごとに別々のファイルを割り当て、ビルドとブラウザーセッションを調整して、他者の測定や編集が無効にならないようにしてください。

チェックポイントとレビュー

「チェックポイント」「この PR をレビューさせて」「次のバッチを積み上げて」という依頼は、ユーザーが一時停止または停止も求めていない限り、安定したレビュー境界を引き渡し、作業を続ける依頼として扱います。

1. 現在の範囲を限定した修正と検証を完了します。バッチの範囲を広げないでください。未完了の作業や無関係な作業はチェックポイントに含めず、次のレイヤーに引き継ぎます。意図した本番用の変更箇所だけをステージし、ステージ済みの差分を確認して、同じファイル内であっても除外した変更箇所は保持します。ローカル QA の作業で生じた変更を理由に、プロジェクトを破棄したりチェックポイントを遅らせたりしないでください。
2. バッチをコミットしてプッシュし、PR の説明を更新して、動作、検証、パフォーマンスの結果、既知の制限事項を記載します。PR がドラフトの場合は gh pr ready でレビュー可能にします。PR のリンクとチェックポイントの正確なコミットを共有します。保留中または失敗した CI は正直に報告し、チェックが完了する前に問題なしと報告しないでください。
3. その PR の範囲を凍結してレビューに回します。必要に応じて既存のブランチを引き継ぎ、追加の変更を行う前に次のレイヤーを作成するには、gh-stack に従います。新しいレイヤーはチェックポイントのブランチをベースにし、その PR には後続の作業だけが表示されるようにします。次のレイヤーで検証済みの変更ができたらドラフト PR を作成し、次のチェックポイントまで同じ PR にそのバッチをまとめておきます。フォースプッシュの許可がない場合は、PR 番号を指定して通常の git push、gh pr create／edit、gh stack link を使って公開します。フォースプッシュを行うスタックコマンドは実行しないでください。
4. ユーザーがチェックポイントをレビューしている間、新しいレイヤーで同じ動画と改善のループを続けます。レビュー中の PR に無関係な進捗を追加し続けないでください。レビューのフィードバックによって下位レイヤーに変更が必要になった場合は、担当ブランチに適用し、スタックのワークフローを使って依存するレイヤーを更新します。履歴の書き換えが明示的に許可されていない限り、公開済みの履歴を保持してください。
5. ユーザーが親 PR をマージしたら、GitHub 上の実際の状態を確認し、既存の子 PR で作業を続けます。ベースを変更する前に、ワークツリーの変更を保持してください。gh stack sync はリベースとプッシュを行い、stack push／submit はフォースプッシュする場合があるため、明示的な許可なく公開済みの子 PR の履歴を書き換える目的で使用しないでください。履歴を保持する方法は、更新された trunk をフェッチして子 PR にマージし、通常の方法でプッシュして PR のターゲットを変更し、必要に応じて残りのレイヤーのスタックを解除して追跡を再構築することです。スカッシュマージ後も含め、変更後のベースと差分に残りの作業だけが含まれていることを確認してください。明示的な許可なく PR をマージしたり、フォースプッシュしたりしないでください。

状況確認だけの質問は、チェックポイントの依頼ではありません。簡潔に回答し、作業を続けてください。一時停止または停止の依頼があれば、進行中のループを終了し、再開地点を記録します。ユーザーから依頼されない限り、スケジュール済みまたはバックグラウンドの自動化は作成しないでください。

継続性を保つ

PR の外部に、プロジェクトとアセットのパス、ワークツリー／ブランチ／スタックと PR のリンク、チェックポイントの HEAD、サーバー URL と起動コマンド、ブラウザー接続の詳細、再現手順、変更前後の証拠、テスト、エクスポート、既知の制限事項、次に取り組むとよい編集タスクを含む簡潔な引き継ぎメモをローカルに保持します。認証情報やレンダーリクエスト／環境のペイロード全体をログや引き継ぎメモに含めないでください。コンテキストが変わった後は、完了済みの作業を再発見したり繰り返したりせず、この記録から再開します。