レビューが必要な内容を確認
agentのワークツリーと未commitの変更を一か所で確認できます。リスクのある変更をレビューし、修正が必要なものを調査して、変更ページからコードをcommitできます。
このガイドではPanolayerのTwitter例であるtwitter-starterを使用します。Panolayerで最初のバグを修正するを完了している場合は、これらの手順で削除の修正をレビューできます。
スクリーンショットと短い動画では、同じTwitterアプリにおける複数の変更（フォーマット、検索、エクスポート、保存済み投稿の変更など）を示しています。ファイル一覧、リスクスコア、commit IDは、レビュー対象の作業によって異なります。スクリーンショットをクリックすると、原寸大で確認できます。
サイドバーで変更を開きます。右側には、さまざまなワークツリーとagentによる未commitのコードが表示されます。ワークツリーを選択すると、そのagentが変更した内容を確認でき、ファイルはリスクの高い順から低い順にスコア付けされます。
agentのワークツリー間を移動し、変更をレビューして、このページからコードをcommitできます。リスクスコアにより、注意が必要なファイルや修正が必要な可能性があるファイルをすばやく確認できます。
履歴で既存のcommitを選択して、記録された内容をレビューすることもできます。削除の修正をすでにマージしている場合は、そこにあります。そのマージにより、変更はすでにローカルに記録されています。
リスクの高い順から低い順に変更をレビュー
変更ページでは、ファイルをリスクありからリスクなしまでスコア付けし、何が変わったかを説明します。まずリスクの高いファイルから確認して、commit前にレビューや修正が必要な内容を把握しましょう。
リスクスペクトラム、リスクバー、オーバーラップを切り替えて、同じ変更を3つのビューで確認できます。
リスクスペクトラム
変更されたファイルを水平方向のスペクトラムに沿って、左の高リスクから右の低リスクへ並べて表示します。
リスクバー
ファイルをリスク順に並べたバーとして比較します。非常にリスクの高いものからリスクのないものまで表示されるため、変更のどこに注意が必要かを簡単に確認できます。
オーバーラップ
UIの変更、ロジックの変更、リスクのある変更がどこで重なるかを確認します。グループ化されたファイルにより、変更のこれらの部分が互いにどう関係しているかがわかります。
注意が必要な変更を調査
リスク概要は、レビューのどこに注目すべきかを示します。特定の変更をより詳しく理解したいときにファイルを開きます。
- グラフまたは変更ファイルリストでファイルを選択します。
- そのパス、変更概要、リスクの説明を読みます。
- 並べて比較するには Split、1つのビューで変更を読むには Inline を選択します。
- 変更内容を、関連する関数とその呼び出し元まで追って確認します。関連するテスト、設定、依存関係ファイルも確認してください。
削除の修正については、components/Post.tsx を開いて handleDelete() を確認してください。変更が報告された canDelete 条件にどう対応しているか、また、ユーザー確認、削除リクエスト、成功レスポンスの処理が引き続き全体として整合しているかを確認してください。
分析を読み、懸念事項について質問する
Panolayer Agent による詳細分析は Changes でいつでも確認できます。Panolayer Agent – Deep Analysis パネルを開き、評価、懸念事項、ソース参照を確認してください。懸念事項から該当ファイルへ移動し、何に対処すべきかを把握します。
既存の分析クリップでは、Twitter アプリのエクスポート変更が表示され、影響を受けるファイルに懸念事項が関連付けられています。
Chat で Panolayer Agent とのレビューを続行できます。確認している動作に関連する質問をしてください。例:
「この変更は削除の問題をどのように修正しますか。また、期待される動作をカバーするテストはどれですか。」
回答を基に変更をたどり、不明な点を調査してください。
レビューと併せて検証結果を確認する
Changes では、影響を受ける関数の検証結果を表示できます。失敗したルールや、保留中・利用不可のチェックを確認し、その説明を手がかりにコードを追ってください。
リスク概要は、どこを確認すべきかの判断に役立ちます。詳細分析では、調査すべき懸念点が示されます。検証では、コードの動作に関する期待に対して実施されたチェックが報告されます。これらは差分と関連するテストと併せて確認してください。
削除の例では、選択した失敗が修正されたことを確認し、新たに発生した失敗は既存の問題とは分けて確認してください。概要のフィールドとステータスについては、検証結果を理解する を参照してください。
変更に実行時の確認が必要な場合は、アプリケーションを実行してください。この修正では、投稿を削除してみて、確定またはキャンセルしたときの動作が期待どおりであることを確認してください。
Merge the agent’s work when you’re satisfied
When the agent requests a merge, review the verification summary and confirm the target branch. Choose Not now to keep reviewing, or Merge into main to bring the work into the sample’s main branch.
The Merged into main confirmation shows the commit ID. This workflow records the agent’s change in local Git history; you do not need to commit that same change again.
Commit any uncommitted edits
Use this step for your own edits or other uncommitted work in the current workspace. If the agent’s merge already saved the change and you have no further edits, continue to History.
- Check the full changed-file list.
- Review the suggested commit message. Use Edit message if it needs to describe the change more clearly.
- Choose Commit to save the changes to the local branch. Choose Commit & Push if you also want to send the commit to a configured remote.
A Panolayer commit includes every changed file in the workspace. Use Git directly if you need to stage only part of the change. Read any reported check failures before deciding to commit; a commit can still be created when checks fail.
Confirm the result in History
Open History and find the new commit using its message, author, and commit ID. Select it to inspect the recorded change, then return to Working tree to check for remaining uncommitted edits.
Watch: Confirm a Twitter saved-post change in merge confirmation and History
This existing clip follows a saved-post change in the Twitter app. Use the commit ID from your own merge confirmation to find your change.
For the deletion fix, you should be able to find its recorded change and inspect the files that landed. Check that no unexpected uncommitted edits remain.
Push when you’re ready to share the commit
A merge or commit saves work locally. To send an existing local commit to your Git remote, open Git and choose Push.
Pushing requires a configured remote and permission to write to it. If the sample has no remote, the local commit completes this walkthrough. If a push reports an error, read it and resolve the remote or sign-in problem before trying again.
Use your Git host for pull requests and team review.