Twitter サンプルをたどる
このガイドでは、Panolayer の Twitter サンプルにある投稿削除のバグを追います。イシューを読み、その説明からコードへとたどり、マージするかどうかを判断する前に検証サマリーを理解します。
一緒に進めるには、サンプルアプリを試す の下にある Twitter Clone を開きます。twitter-starter として開きます。セットアップと修正の完全な手順については、Panolayer で最初のバグを修正する を参照してください。スクリーンショットは記録済みの 1 回の実行を示しており、イシューの順序や件数は異なる場合があります。
イシューから始める
コードベースを開くと、Panolayer 検証エンジン が実行を開始します。コードベースを関数、シンボル、依存関係のレベルまで解析し、視覚的なアーキテクチャを構築し、コードをチェックしてバグを特定します。
イシュー を開きます。この例では、実行が完了しており、ステータスは 検証完了 と表示されています。調査が必要なイシューは 要対応 の下に表示されます。
検証完了は実行の状態を表します。 実行が終了したことを意味します。結果を読んで、失敗が見つかったかどうかを確認してください。
削除に関する指摘を読む
例の最初の指摘は、条件によって確認済みの削除が停止される可能性があると報告しています:
追加の
canDeleteガードは、ユーザーが確認したにもかかわらず削除を妨げる可能性があり、示されている現在の投稿の削除動作に反しています。
ルールとは、関数の動作に関する期待です。何を返すべきか、どのアクションを実行すべきか、他のコードが何を期待しているか、といった内容です。ここでは、ユーザーが確認した後に現在の投稿を削除することに関する期待です。
指摘のファイル、関数、ステータス、説明をまとめて読みます:
| 表示内容 | わかること |
|---|---|
components/Post.tsx | 調査対象の関数を含むファイル。 |
handleDelete() | 動作が確認された関数。 |
| 失敗 | 確認された動作がルールを満たしていません。 |
| 重大度 3 · 機能性 | 指摘の重大度とカテゴリは、調査の優先順位付けに役立ちます。 |
| 詳細 | 説明とソースの位置から、指摘が報告された理由を理解できます。 |
詳細をクリックします。説明には、canDelete が false のとき、ルールで説明されている削除を完了する前に、関数が早期リターンする可能性があると書かれています。ソース参照は関連するコードを指しています。
変更内容を決める前に、ルールが意図した動作と一致しているか確認します。期待が誤っている場合はルールを修正します。コードが誤っている場合はコードを修正します。変更は他のファイルの呼び出し元にも影響する可能性があるため、結果に表示される影響を受ける呼び出し元をたどってください。
ステータスの意味は？
ステータスは、その説明と適用対象のコードと併せて確認してください。
| 結果 | 読み方 |
|---|---|
| 合格 | 評価されたルールは、チェック対象のコードで合格しました。これはそのルールについての説明であり、アプリケーションの考えられるすべての動作を説明するものではありません。 |
| 失敗 | 評価されたルールが成立しませんでした。説明を読み、ソースを確認して、修正が必要な箇所を判断してください。 |
| 保留中または実行中 | 結果はまだ準備できていません。結論を出す前に、チェックが完了するまで待ってください。 |
| 利用不可 | チェックを完了できませんでした。付随するメッセージを読み、報告された問題を解決してから再チェックしてください。 |
| 未チェック | 期待値は評価されていません。合格結果ではありません。 |
検証を完了できない場合は、報告されたエラーに従い、セットアップと agent の問題を解決する を参照してください。
バグを修正して検証を再実行する
削除の問題については、修正 をクリックし、Panolayer Agent を選択します。Panolayer が問題のコンテキストを agent に渡すため、バグを説明するプロンプトを書く必要はありません。
Panolayer Agent は組み込みです。インストール後は、別のサポート対象 agent も使用できます。詳細は サポート対象の agent を参照してください。
agent は専用の Git worktree で作業し、編集内容はユーザーのブランチとは分離されます。My Agents でタスクを追跡するか、実行カードの 開く をクリックして、agent のアクティビティと変更内容を確認します。
コードが変更されると、Panolayer は影響を受ける関数と関連コードを再チェックします。これには他のファイルの呼び出し元も含まれます。これにより、agent が編集した行以外のリグレッションも検出しやすくなります。
リグレッション とは、変更によって新たに生じた問題です。修正中に検証でリグレッションが検出された場合、agent はそれを修復し、マージをリクエストする前に検証を再実行できます。そのため、タスクはレビュー可能になるまでに複数回の検証実行を持つことがあります。
マージ前に検証サマリーを確認する
この実行が完了すると、Panolayer に Panolayer Agent はマージ準備完了 と表示されます。ダイアログには、タスク中に検証が確認・修復した内容が要約されます。
| 概要フィールド | この実行 | 意味 |
|---|---|---|
| 修復された失敗 | 1 | この作業では、タスク開始前から存在していた失敗を 1 件修復しました。 |
| 合格したルール | 21 中 14 | 変更されたコードでは、21 件中 14 件のルールが合格しました。これはヘルスメッセージと別行の既存の失敗を合わせて確認してください。 |
| 検証実行回数 | 1 | この作業中に 1 回の検証実行が結果を出しました。これは個々のテストやルールではなく、検証実行の回数を数えています。 |
| 変更されたファイル | 4 | タスクで 4 つのファイルが変更されました。テストや依存関係ファイルを含め、変更セット全体を確認してください。 |
ヘルスメッセージには 新しい失敗、警告、未チェックのルールはありません。 と表示されます。このメッセージは件数と合わせて確認してください。これはこの作業の結果を表し、次の行では作業開始前から残っている失敗を説明しています。
「検出されたリグレッション」が表示された場合は？
一部の実行では 検出されたリグレッション も表示されます。これは作業中に検証が検出した新しい問題を報告し、それらがターゲットブランチに入らないようにするのに役立ちます。最新の結果を確認して、まだ対応が必要なものを把握してください。この件数は、現在未解決の失敗の数ではなく、作業中に検出された件数を表します。
このフィールドはこのスクリーンショットには表示されていません。削除の例では、修復された既存の失敗が 1 件示されていますが、修正中に検出されたリグレッションは示されていません。
Why can it be ready to merge when failures remain?
Panolayer compares the result with the baseline: the state of the codebase before the change. This separates problems introduced by the task from problems that were already there.
- A new failure was introduced by the change and needs investigation before you accept the work.
- A pre-existing failure was present before the task started. It can still matter, but this task did not introduce it.
- A repaired failure was present before the task and was fixed during the work.
In the screenshot, the dialog reports 7 pre-existing failures that do not block this merge. The selected deletion issue was repaired, and those other issues remain separate work.
The repository’s issue list and an agent’s verification summary can cover different scopes. The issue list shows what needs attention in the codebase; the merge summary describes the agent’s work against its baseline. An agent’s result can report no new failures while the repository still has pre-existing issues.
You can assign a pre-existing issue as another task using Fix. That gives the agent a specific issue to work on next.
Ready to merge does not mean every issue in the repository is resolved. Read what this task repaired, what it introduced, and what was already there.
Decide what reaches your branch
You control the merge. Before accepting the result:
- Check that the repaired issue matches the bug you asked the agent to fix.
- Read the verification summary, including any new failures, warnings, or checks that could not finish.
- Open Details for more context and inspect the agent’s changed files. Review the relevant tests and run the application when the behavior needs a runtime check.
- Confirm the target branch. Choose Merge into main when you’re satisfied, or Not now to keep reviewing.
Verification gives you evidence for the decision. Read it alongside the code and relevant tests; it does not cover every possible bug.