flounder

Flounder

このスキルは、Flounder を使用したセキュリティ監査の運用マニュアルです。

Flounder は、自律型のホワイトハットセキュリティ監査エージェントです。エージェントは対象を準備し、ソースコードを監査し、エクスプロイト経路を構築し、ローカルで実証テストを実行して実際の検出事項を確認し、レポートを作成します。このフレームワークは、デーモン、サンドボックス、コマンドポリシー、実行追跡、ライブアクティビティ、実行ゲートを提供します。

スキルファイル

ファイル	読むタイミング
SKILL.md	このスキルが起動したら、必ず読みます。運用手順を記載しています。
reference/models.md	モデルの選択、OAuth と API キーの違い、DeepSeek/GLM の設定、モデルが見つからない場合のトラブルシューティングについて確認するとき。
reference/commands.md	CLI、REST、プロバイダー、デーモン、予算、出力、pi 拡張機能の詳細を確認するとき。
reference/examples.md	具体的な Solidity/EVM および ZK の例を確認するとき。
reference/product.md	ダッシュボード、プロジェクトのライフサイクル、実行フェーズ、追跡、アーティファクトモデルを確認するとき。
reference/safety.md	ホワイトハットポリシー、サンドボックスの境界、証拠の段階、公表時の安全対策を確認するとき。
reference/maintainer-harness.md	評価に基づくソース改善や候補 PR 作成に関する、メンテナー専用のエージェントワークフローを確認するとき。

段階的開示を活用し、現在のタスクに必要な参照ファイルだけを開いてください。短いコマンドとステータスの要約で足りる場合は、長いコマンドリファレンスを会話に重複して記載しないでください。

このスキルで行うこと

• セキュリティ監査の依頼を、公開ソースまたは許可された Flounder プロジェクトや実行に変換します。
• 現在のワークフローに沿ってオペレーターを導きます。run <clue> では、Flounder が対象を準備し、その後 map/dig/synthesize/verify を実行してから、確認とレポート作成を行います。run --source は、封印された map/dig/synthesize/verify への、ソース提供によるエントリーパスです。
• プロジェクト作業ではダッシュボード/API コントロールプレーンを優先し、状態、デーモンの所有権、ライブログ、検出事項、レポートが確実に保持されるようにします。
• 証拠の段階を維持します。「疑いあり」「ローカルで確認済み」「実際の対象で再現済み」「提出準備完了」を、ひとつの「バグ」区分にまとめないでください。
• 進捗の判断には、実行の健全性と発見事項のバックログ行を使用します。調査が浅い、またはリソース不足によって検出事項がゼロの実行は、否定的な結果ではありません。また、フォローアップの調査範囲は検出事項にせず、未対応のカバレッジとして扱ってください。
• 却下した検出事項には ignored を設定して、システム由来のノイズと進行中の作業を分けます。削除はしないでください。
• 次のアクションまたはブロッカーを明確にして終了します。コマンドが終了しただけで、監査完了と判断しないでください。

主な監査モード

何かを実行する前に、ユーザーの意図に基づいてモードを選択してください。

ユーザーの意図	モード	準備パス	ガードレール
「ブラインド監査を行う／Flounder の能力をテストする／ヒントなしで」	ブラインド能力監査	推奨：flounder run <project-or-repo-or-package-link>、または事実に基づく対象の手がかりがあるダッシュボードプロジェクトを使用します。ソースがすでにステージングされている場合や、外部での準備を明示的に望まない場合は、flounder run --source <paths...> --build-root <root> を使用します。	インシデント関連ドキュメント、既知のバグ名、エクスプロイトの仮説、答えが含まれるコーパスを追加しないでください。対象の公式ドキュメントは、隠された答えではなく対象の資料としてのみ使用できます。
「不審な tx／アドレスはこちら。ハッキング／根本原因を見つけて」	インシデント調査	flounder run <tx-or-address-or-incident-link>	手がかりは証拠として扱い、証明として扱わないでください。Prepare によってチェーン／ソースデータが取得される場合があります。確認はローカルフォーク／読み取り専用の再現でのみ行ってください。
「ホワイトハット研究者として、このプロジェクト／リポジトリをオープンに監査して」	オープンワールドの公開ソース監査	入手可能なソースパスと、プロジェクト、バウンティ、リポジトリ、パッケージ、またはデプロイを明示するタスク／手がかりを指定してプロジェクトを作成し、その後 Run を実行します。	Prepare によって公式ドキュメント、スコープ、デプロイ、来歴を収集してください。非公開の資料や答えが含まれる資料は使用しないでください。
「通常のバグバウンティを監査して／このバウンティに提出すべき？」	通常のバグバウンティ	engagement.kind="bug-bounty" を設定し、入手可能なソース／ビルド／コーパスのパスと、公開または非公開プログラムのスコープを明示するタスク／手がかりを含むプロジェクトを使用します。	ライブターゲットがある場合は、実際のターゲットでの Confirm を維持してください。公式のスコープ、証拠、必須の提出条件を満たし、実行による裏付けがある発見のみを提出してください。非公開の重複報告と報奨金に関する不確実性は、別途記録してください。
「このコンテストを開始して／コンテストのバウンティ獲得速度を最大化して」	バグバウンティコンテスト	engagement.kind="bug-bounty-contest" と、batchScopes、digConcurrency、skipRealTargetConfirm、appendMapWhenExhausted などのコンテスト戦略を設定したプロジェクトを使用します。	短いバッチを区切って実行します。検証または反証し、報告してから次のバッチを開始してください。開催ルールで許可される場合は、ソースのみを使ったローカル確認で十分なことがありますが、疑いだけの発見は提出できません。カバレッジを広げる場合は remap ではなく append-map を使用してください。

判断に迷った場合：Flounder の支援なしの再現能力を測定したいという依頼なら、 ブラインド能力監査を使用し、手がかりは対象に関するものだけにしてください。ユーザーが 実際のエクスプロイトの証拠を提示した場合は、インシデント調査を使用してください。 公開コンテキストの収集を許可したうえで、幅広い公開ソースの監査や 許可を得たバグハンティングを希望する場合は、オープンワールドの公開ソース監査を使用してください。

ワークフローの使い分け

ユーザーがエンドツーエンドの監査全体を求めていない場合は、以下を使用します。

ユーザーの意図	ワークフロー
「全体像だけ把握したい／スコープの一覧を見せてほしい」	flounder map を実行します。検出事項は報告しません。
「このファイル／関数／スコープをさらに詳しく調べてほしい」	flounder audit <region> または flounder audit --scope <id> を実行します。
「疑わしいバグを確認してほしい」	flounder audit --verify <claims.json> を実行し、実行によって真偽を確認します。
「ローカルで確認したバグは、メインネット／デプロイ環境でも実際に起きるか」	flounder confirm <run-dir> または選択したプロジェクトの Confirm を使用します。
「提出用パッケージを準備してほしい」	選択した Report を使用します。実行で裏付けられ、無視対象ではない検出事項のみを含めます。
「ノイズの多い機械検出のトリアージをしてほしい」	トラッキングを更新します。却下した項目には ignored を設定し、再び対象にするには open に戻します。
「ベンチマーク／リグレッションセット／ポジティブコントロールとセーフコントロールを実行してほしい」	検証済みマニフェストを作成し、flounder group create --manifest <file> を使用してから、`flounder group start <uuid
「Flounder のハーネスを改善する／再現率を上げる／Evaluation の失敗から学ぶ」	これはメンテナーの作業であり、通常の対象監査ではありません。エージェントが変更権限を持つ Flounder のソースリポジトリで作業していることを確認し、reference/maintainer-harness.md を読んで、分離されたソース変更ワークフローを進めます。

基本的な運用ルール

• Flounder CLI、ダッシュボード、REST API、または pi 拡張機能のワークフローを使用します。トラッキングデータベースを直接編集してはいけません。
• 監査を実行する前に、権限とスコープを確認します。
• プロバイダーの認証情報はデーモン内に保持します。サーバーにはプロバイダープロファイルを保存し、デーモンはプロバイダーへのログイン、API キー、対象ソース、実行を管理します。
• ユーザーが --out または --workspace を明示的に指定しない限り、~/.flounder を既定の製品ホームとして扱います。トラッキング DB、実行成果物、永続的な履歴／ビルドキャッシュ、デーモンのワークスペース、デーモン内のプロバイダー認証情報は、ここに保存されます。
• ユーザーがすでにコントロールプレーンを起動している場合を除き、flounder ui から始めます。CLI の動詞は、このコントロールプレーンを利用する軽量なクライアントです。
• 権限を持つ Flounder メンテナーが Flounder のソースを改善する場合に限り、flounder ui --maintainer から始めます。通常の Project および Evaluation の作業では、Harness のソース改善操作を有効にしたり、案内したりしてはいけません。
• REST API を直接操作する前に GET /api を使用します。エンドポイントの形式については、カタログを正とします。
• コーパスにはプロジェクトが所有するドキュメント／仕様／監査結果を使用します。疑わしいバグ、その場所、または仕組みを特定する、回答そのものとなるコーパスを書いてはいけません。
• 対象ソースをその場で変更してはいけません。Flounder はビルドルートを分離されたワークスペースにコピーし、モデルが作成したテストもそのワークスペース内にとどめます。
• suspected は未証明として扱います。実行により confirmed-executable、confirmed-differential、または再現された confirm 判定が得られた場合に限り、検出事項を対応可能とします。
• flounder run <clue> は、1 つのコマンドで完了するワークフローです。オープンワールドの prepare、封印された map／dig／synthesize／verify、オープンワールドの confirm、続いてレポート生成を行います。flounder run --source、map、audit は封印された発見フェーズです。prepare と confirm は、ホワイトハットのブロードキャスト禁止ルールに従うオープンワールドのフェーズです。
• トランザクションのブロードキャスト、資金の移動、書き込みの送信、アクセス権の永続化、または宣言されたローカル監査境界や明示的に認可されたスコープ外のシステムへのアクセスは、決して行ってはいけません。

最初の応答チェックリスト

ユーザーから Flounder の状態の監査、確認、検証、報告、または調査を依頼された場合：

1. 対象ソースが公開されているか、運営者が所有しているか、クライアントから許可されているか、または公開バウンティの対象範囲内であることを確認します。ソースの境界が不明確な場合は、実行前に確認してください。
2. 依頼を次のいずれか1つの中核的な監査モードに分類します：ブラインド機能監査、インシデント調査、オープンワールドの公開ソース監査、通常のバグバウンティ、またはバグバウンティコンテスト。
3. 対象サーフェスを決定します：
   • 既存のダッシュボード／API プロジェクト：GET /api を使用し、その後にプロジェクト UUID のルートを使用します。
   • 新規プロジェクトまたはローカル運営者ワークフロー：flounder ui を起動または再利用します。
   • フレームワークで準備された対象：Flounder がソースと公式資料を準備できるよう、タスク／手掛かりを優先します。
   • ソースが提供された対象：コードがステージング済みの場合、または外部での準備を希望しない場合は、--source を使用します。
4. 実際のモデル処理を開始する前に、デーモンとプロバイダーの準備状況を確認します： 実行マシンで flounder daemon provider check openai-codex を実行します。
5. 実行を確認する監査の前に、サンドボックスの準備状況を確認します： デフォルトの OCI イメージがない場合は npm run sandbox:build を実行します。
6. 以下のルーティングテーブルからワークフローを選び、適切な最小限のアクションを開始して、ライブログと永続化された状態を監視します。
7. プロジェクト／実行 ID、フェーズ、証拠の状態、次のアクションを含めて結果を報告します。セットアップの阻害要因は監査結果と明確に区別してください。

リポジトリの開発やローカルビルドには、.nvmrc／.node-version で指定された Node 24 LTS を使用してください。これより新しい実験的な Node バージョンで代用しないでください。

Codex または Claude Code のクイックスタート

1. Flounder が利用可能か確認します：

   flounder --help
   

   PATH から利用できないものの、リポジトリがチェックアウトされている場合は、ビルドします：

   npm install
   npm run build
   node dist/cli.js --help
   

   パッケージがインストールまたはリンクされるまでは、コマンド例の flounder を node dist/cli.js に置き換えてください。

2. ローカルのコントロールプレーンを起動または再利用します：

   flounder ui
   

   リモート実行環境の場合は、Settings または flounder server daemon-token mint でトークンを発行してから、次を実行します：

   flounder daemon start --server http://<server>:4500 --token <token>
   

3. 選択したデーモンが実行するすべてのプロバイダーを認証します。モデルの選択または認証情報の設定については、モデル設定ガイドを参照してください。 OAuth ログインは OAuth に対応したプロバイダーでのみ使用してください。API キーを使用するプロバイダーには、デーモン環境内のキー、または既存の保存済み pi 認証情報が必要です。Coding Plan のサブスクリプションでも API キーを使用できる場合があります。ユーザーが選択したプロバイダーとプランを維持し、新しいアダプターや従量課金エンドポイントが必要だと決めつけないでください。

   OAuth の例：

   flounder daemon provider login openai-codex
   flounder daemon provider check openai-codex
   

   openai-codex の場合、エージェントは次の方法でユーザーに認証を求めます。 ターミナルでログインコマンドを実行すると、ブラウザーの URL またはデバイスコードの手順が表示されます。ユーザーがログインを完了した後、check で認証を確認します。pi の ~/.pi/agent/auth.json にすでに openai-codex がある場合、Flounder はログイン／確認時にそのプロバイダーエントリーを ~/.flounder/agent/auth.json にインポートします。

4. デーモンマシンで実行サンドボックスを利用できることを確認します。デフォルトの auto モードでは、選択したイメージと封印されたネットワークが利用可能な場合、Apple silicon 搭載の macOS では Apple の container ランタイムを優先し、イメージが利用可能な場合は Docker ベースの OCI にフォールバックします。Docker ベースの経路では、Docker または Docker 互換ランタイムをインストールして起動してから、Flounder リポジトリでデフォルトのサンドボックスイメージをビルドします：

   npm run sandbox:build
   

   一般的な非 EVM 監査向けに、対象ごとに厳選されたイメージを利用できます：

   npm run sandbox:rust:target -- --target <target-root> --execute
   npm run sandbox:cairo:build  # flounder-sandbox:cairo, Scarb + Starknet Foundry
   npm run sandbox:ton:build    # flounder-sandbox:ton, TON Blueprint + FunC/Tolk/Tact
   

   Apple silicon 搭載の macOS デーモンホストでは、Apple の container ランタイムをインストールして起動し、選択したイメージをそのランタイムにビルドまたはプルすると、auto で選択できるようになります。--sandbox-backend apple-container は、この経路を明示的に必要とします。 サンドボックスエンジンが利用できない場合、ホストモードにはカーネルレベルのファイルシステムおよびネットワークの分離機能がないことをユーザーに警告したうえで、信頼できるローカルのスモークテストに限り --sandbox-backend host --allow-host-execution を使用してください。

5. Settings でプロバイダープロファイルを作成するか、既存のものを再利用します。プロバイダープロファイルでは、プロバイダー、モデル、思考レベルを選択します。新しいストアには、openai-codex · gpt-5.6-sol · xhigh、openai-codex · gpt-6-astra · medium、claude-code · opus 4.8 max が初期登録されています。選択したデーモンには、プロジェクトで使用できるすべてのプロバイダーについて、ローカル認証が必要です。プロジェクトでは、フェーズごと（prepare、map、dig、confirm）にプロファイルを上書きできます。デフォルトに設定すると、そのプロファイルが新しいプロジェクト、評価、明示的なモデル指定を省略した API／CLI 起動時のローカルデフォルトになります。製品デフォルトを使用すると、既存のプロジェクトは変更せずに、パッケージに含まれる gpt-5.6-sol フォールバックに戻ります。

   オプションのスタータープロファイル openai-codex · gpt-6-astra · medium は、Sol の製品デフォルトに置き換わるものではありません。プロバイダーエディターで Astra を選択すると、思考レベルは medium に初期化されます。オペレーターはこれを上書きできます。カスタムモデル ID では、トランスポート、コンテキスト、ツール、推論のメタデータに、同じプロバイダーの既知の互換性ベースを使用します。ジョブは定義をメモリー上で選択したデーモンに渡します。認証情報はデーモン側に保持されるため、デーモン側に一致する pi models ファイルは必要ありません。プロバイダーが実際にカスタムモデル ID を認可している必要があります。

6. プロジェクトを作成するか、既存のものを再利用します。次を設定します。

   • プロジェクトコンポーザーでタスク／手がかりを指定
   • 実行デーモン
   • デフォルトのプロバイダープロファイル
   • デーモンのワークスペース内のプロジェクトディレクトリ。デフォルトはプロジェクト UUID
   • ソースパス
   • ビルドルート
   • コーパスパス
   • カバレッジと予算の制御

7. 監査を開始します。すぐに起動するには作成後に実行にチェックを入れたままにします。または、最初のパイプライン実行前にプロジェクトの実行ボタンを使用し、その後は続行を使用します。手がかりを指定する場合：

   flounder run <tx-or-address-or-project-or-repo-or-link>
   

   すでにディスク上にあるソースを指定する場合：

   flounder run --target <name> --source <paths...> --build-root <root> --corpus <docs...>
   

8. ダッシュボード、CLI ストリーム、または REST API から進行状況を監視します。

   • 現在のフェーズ：prepare、map、dig、synthesis、verify、confirm、report
   • ライブアクティビティ：GET /api/runs/:id/log
   • プロジェクトの状態：GET /api/projects/:uuid
   • prepare の品質：prepareSummary.quality は ready、limited、 preparing、needs-review、missing、invalid のいずれかです。自動化のゲートには prepareSummary.auditReady を使用します。limited は、記録された信頼境界や重大な不足が 後の confirm／report の判断に向けて可視化された状態のまま、監査を自動的に続行できることを 意味します。停止するのは、prepareSummary.blockingIssues がある場合、invalid の場合、 または利用可能なソースがない場合に限ります。
   • 検出事項：GET /api/projects/:uuid/findings?tracking=active
   • 無視した検出事項の復元：GET /api/projects/:uuid/findings?tracking=ignored
   • confirm の判断：GET /api/projects/:uuid/confirm-decisions
   • 実行の健全性：latestRunHealth.status は healthy、 needs-coverage、needs-resource、shallow、infra-failed のいずれかです
   • 検出バックログ：GET /api/projects/:uuid/backlog?status=open は、 カバレッジの不足、リソースのリクエスト、フォローアップ対象を actionability、action_owner、recommended_action とともに一覧表示します。 未完了の行はエージェントが担当するキュー（agent-runnable、agent-resource、 agent-review）として扱い、PATCH /api/backlog/:id を使って行を resolved、ignored、stale、または open に戻します

   プロジェクト名は表示用ラベルです。POST /api/projects または GET /api/projects からプロジェクト UUID を取得してください。プロジェクト名から URL を組み立てないでください。

9. 以下のルールに従って次のアクションを決定します。1 回の実行が終了しただけでタスク完了と判断しないでください。

クイックレシピ

ブラインド機能監査

ユーザーがヒントやインシデントの背景情報を求めていない場合、またはフレームワークの機能を確認したい場合に使用します。

推奨されるターゲット準備済みの手順：

flounder run <project-or-repo-or-package-link>

既存のソースを使う手順：

flounder run --target <name> --source <paths...> --build-root <root> --corpus <user-supplied-docs...>

• ユーザーがブラインドパッケージの一部として公式ドキュメント／仕様を提供した場合を除き、--corpus は空のままにします。
• インシデントレポート、既知のバグ名、エクスプロイトの仮説、疑わしいバグを示唆する手書きのスコープメモ、答えを含むコーパスは使用しないでください。
• 結果は、証拠の状況と網羅性に基づいて判断します。マッピング済みスコープ、監査済みスコープ、疑わしい発見事項、ローカルで確認済みの発見事項、保留中のスコープを確認します。
• 否定的な結果は「対象範囲内で確認された発見事項はない」という意味であり、ターゲットが安全である証明ではありません。

トランザクションまたはアドレスからのインシデント調査

ユーザーが不審なトランザクション、アドレス、エクスプロイトのリンクを提示した場合、または「なぜハッキングされたのか」と尋ねた場合に使用します。

flounder run <tx-or-address-or-incident-link>

• Prepare に、デプロイ済みソース、チェーン上の事実、公式プロジェクト資料、実際のターゲットでの確認要件を収集させます。
• インシデントの手がかりは事実に基づく内容にします。バグの仮説をコーパスに記述しないでください。
• 攻撃者が実行可能なローカル再現で根本原因を確認します。通常はローカルフォークまたはソースレベルのリプレイを使用します。稼働中のシステムにトランザクションをブロードキャストしたり、書き込みを行ったりしないでください。
• 回答では、悪用された不変条件、攻撃者の経路、影響を受けたコンポーネント、および発見事項が再現済み、未再現、または未確認の疑いであるかを説明します。

公開ソースを用いたオープンワールド監査

Flounder に、公式の公開情報、デプロイ情報、パッケージのメタデータ、ドキュメント、または利用可能な場合はバウンティのスコープを積極的に収集させたい場合に使用します。すでにソースパスがある場合は便利ですが、それによってシナリオが定義されるわけではありません。公開バウンティは優先度と提出経路を示すシグナルであり、ローカルで隔離された監査の前提条件ではありません。

1. flounder ui を起動するか、既存のものを再利用します。
2. 次の内容を指定してプロジェクトを作成します。
   • 利用可能な場合は、ローカルのソース／ビルド／コーパスのパス。
   • プロジェクト、リポジトリ、バウンティページ、デプロイ先、またはパッケージを示すタスク／手がかり。
   • オンラインデーモン。
   • openai-codex · gpt-5.6-sol · xhigh などのプロバイダープロファイル。
3. ユーザーがすぐに実行したい場合は、Run after create にチェックを入れたままにします。
4. GET /api/runs/:id/log と GET /api/projects/:uuid を監視します。
5. blocking issue がなければ、limited の prepare は監査可能な状態として扱います。注意事項は verify／confirm／report の判断まで引き継ぎます。
6. 公式／公開資料のみを使用します。疑わしいバグに言及する非公開メモや答えを含むドキュメントは追加しないでください。

通常のバグバウンティ

ターゲットが通常の公開または非公開のバウンティプログラムであり、実際のターゲットで再現する必要がある場合に使用します。

1. config.engagement.kind="bug-bounty" を設定してプロジェクトを作成します。
2. 利用可能な場合はローカルのソース／ビルド／コーパスのパスを指定し、公式プログラム、スコープ、デプロイ先、またはパッケージを示すタスク／手がかりを追加します。
3. Prepare に、公開されているスコープ、デプロイ情報、出所、既知の問題に関する手がかりを収集させます。
4. ローカルでの立証には、隔離された map／dig／synthesize／verify を実行します。
5. 実際のターゲットでの再現が必要または有用な、ローカルで確認済みの発見事項には Confirm を実行します。
6. スコープ、重複、既知の問題、影響、報奨金受領の準備状況、ホワイトハットとしての開示に関する条件をすべて満たす発見事項のみを提出します。

バグバウンティコンテスト

開催場所が、ソースコード、ルール、レポート形式が用意された期間限定の監査コンテストである場合に使用します。

1. config.engagement.kind="bug-bounty-contest" を設定してプロジェクトを作成します。
2. コンテスト戦略は、たとえば batchScopes:10、digConcurrency:5、skipRealTargetConfirm:true、およびルールがソースコードのみを対象とする場合は appendMapWhenExhausted:true を設定して、迅速に確定できるループを優先するよう構成します。
3. スコープをさらに開く前に、既存の候補を検証／反証し、報告して確定します。コンテストモードは速度を重視しますが、疑いの段階にとどまる検出事項は、依然として提出基準を満たしません。
4. 新しいレポートを提出する前に、すでに提出済みの問題とローカルの検出事項を照合して重複を追跡します。
5. マッピング済みのスコープを使い切ったら、監査済みステータス、提出済みの検出事項、重複リンク、レポートを維持したまま、追記マッピングで新しいスコープを追加します。オペレーターが意図的に新しいインベントリを作成したい場合を除き、再マッピングしないでください。
6. コンテストの停止レビューのシグナルを確認します。経過したレビュー期間、インベントリの枯渇、直近の低成果バッチ、重複率、レポートのバックログ、未解決のリソースリクエストが該当します。

既存のプロジェクトを続行する

1. GET /api/projects からプロジェクト UUID を取得します。

2. プロジェクトの 続行 アクションを使用するか、CLI から実行します。

   flounder continue --project <uuid|name>
   

   これは UI の続行ボタンと同じプロジェクトパイプラインのアクションです。verb:"run" をキューに追加し、保存されたプロジェクト状態からコントロールプレーンが続行します。

3. REST API を直接使用する場合は、次のようにします。

   curl -X POST http://127.0.0.1:4500/api/projects/<uuid>/runs \
     -H 'content-type: application/json' \
     -d '{"verb":"run"}'
   

4. 結論を出す前に、latestRunHealth、backlogCounts、および未解決のバックログ行を確認します。未解決の Next Actions は、無関係な新しい範囲の確認を開始する前にエージェントが解決または振り分ける作業として扱います。オペレーターに尋ねるのは、明示的な認証情報、承認、または利用できない外部リソースに限ります。needs-coverage の場合は、カバレッジを続行するか、後続のスコープを優先してください。shallow を意味のある否定的結果として扱わないでください。

5. マッピング済みスコープの多くが未処理の場合は、否定的な結論を出す前にカバレッジの続行を優先してください。

プロジェクトのセットアップと整理

プロジェクトを実行できない理由、プロジェクトレールの整理方法、またはアーカイブ済みの作業の復旧方法についてユーザーから尋ねられた場合に使用します。

• 概要にセットアップが必要と表示されている場合は、まずプロジェクトのセットアップ詳細を開きます。新しい作業を開始する前に、デーモンの選択、プロバイダー認証、ソースパス、または準備済みの資料に関するブロッカーを解決します。
• 保存されたプロジェクトの手掛かりと準備時の注意事項は、プロジェクトのセットアップ詳細で確認します。手掛かりが別のダッシュボードカードに表示されるとは限らないため、Prepare にコンテキストが渡されなかったと決めつける前にセットアップを確認してください。
• 未解決の resource-request バックログ行がセットアップの制限の原因である場合は、まずエージェントにブロッカーを調査させ、安全なセットアップ作業を再試行させます。オペレーターに尋ねるのは、明示的な認証情報、承認、または利用できない外部リソースに限ります。その後、処理済みの行を resolved に、対応不要の行を ignored に設定します。
• 日常的な対応が必要なアクティブなプロジェクトはピン留めし、休止中のプロジェクトはプロジェクトカードのメニューからアーカイブします。アーカイブするとプロジェクトレールから非表示になり、ピン留めが解除されますが、実行、スコープ、検出事項、レポートは保持されます。
• アーカイブ済みのプロジェクトは、Settings -> Archived Projects から復旧します。
• ドラッグによる並べ替えはアクティブなプロジェクトのみを対象とします。デフォルトでは作成日の新しい順に並び、ピン留めされたプロジェクトがピン留めされていないプロジェクトより先に表示されます。

検出事項のトリアージ

機械が報告したバグをユーザーが確認する場合に使用します。

• Active findings ビューから始めます。1 件の監査に取り組む場合は、プロジェクトで絞り込みます。
• 監査ステータス（suspected、confirmed-*、refuted）と追跡状態（open、triaging、submitted、ignored など）を分けて管理します。
• 人が誤検知として却下したものは削除せず、ignored に設定します。
• 却下した検出事項を復元するには Ignored ビューを使用し、新しい証拠が見つかった場合は open に戻します。
• 再現済みの実ターゲットのバグ、または実ターゲットでの確認が不要な場合に限り、ローカルで確認済みのソース提供の監査バグについてレポートを作成します。

選択した検出結果を検証、確認、報告する

• JSON から疑わしい検出結果を指定する場合：flounder audit --verify <file> --source ... または同等の flounder verify <file> --source ... を実行します。
• 選択したプロジェクトの検出結果：More actions -> Verify/Confirm/Report を使用するか、 findingId / findingIds を POST /api/projects/:uuid/runs に渡します。
• 特定のレポートのみを再生成するには、{"verb":"report","findingIds":[...]} を使用します。
• 現在レポート可能なすべての検出結果を再生成するには、 {"verb":"report","regenerateReports":true} または flounder report --project <uuid|name> --all を使用します。
• findingIds を指定せずにレポートすると、不足している正式なレポートのみが生成されます。
• CLI でのレポート生成には、同じプロジェクト作業リストが使用されます。 不足しているレポートには flounder report --project <uuid|name> を、 選択した検出結果の再生成には flounder report --project <uuid|name> --finding <id> を使用します。
• 人が却下した機械検出の検出結果には ignored のマークを付けます。後で tracking=ignored から復元するには、open に戻します。

ワークフローマップ

現在のタスクに必要な参照のみを開いてください。

• CLI、REST、プロバイダー、デーモン、予算、出力、pi 拡張機能の詳細： reference/commands.md
• Solidity/EVM および ZK の例： reference/examples.md
• ダッシュボード、プロジェクトのライフサイクル、実行フェーズ、検出バックログ、アーティファクトモデル： reference/product.md
• ホワイトハットポリシー、サンドボックスの境界、証拠の段階： reference/safety.md
• メンテナー専用の評価からソース改善へのループ： reference/maintainer-harness.md

タスクの振り分け

ユーザーの意図	使用するもの
「このターゲットをブラインド監査する／テストフレームワークの機能を検証する」	ブラインド機能監査：flounder run <target-clue> を優先します。ソースがすでにステージング済みの場合、または外部での準備が不要な場合は、flounder run --source ... --build-root ... を使用します
「この tx／アドレスがハッキングされた原因を調べる」	インシデント調査：flounder run <tx-or-address-or-incident-link>
「このリポジトリ／ソースをオープンに監査する」	オープンワールドの公開ソース監査：ソースパスとタスク／手がかりを指定してプロジェクトを作成し、Run を実行します
「まず攻撃対象領域をマップする」	flounder map を実行し、スコープを確認してから flounder audit --scope ... を実行します
「このファイル／関数／領域を詳しく調べる」	flounder audit <region> --source ... --build-root ...
「このバグの疑いを検証する」	claims JSON を作成し、flounder verify <file> または flounder audit --verify <file> を実行します
「カバレッジを継続する」	プロジェクトの Continue を使用するか、インベントリから未処理のスコープを監査します。リソースのブロッカーやフォローアップ対象のスコープがないか、まず検出バックログを確認します
「これが本物か確認する」	flounder confirm <run-dir>、または UI でプロジェクト／検出結果の Confirm を実行します
「開示するバグを集める」	検出結果、選択したレポート、確認の判断、アーティファクトを確認し、実行による裏付けがある項目のみを返します
「この誤検出を無視する」	検出結果の追跡状態を ignored に設定します。削除しないでください
「無視した検出結果を戻す」	tracking=ignored で絞り込み、選択した行を open に戻します
「レポートを再生成する」	`flounder report --project <uuid
「評価の証拠に基づいて Flounder 自体を改善する」	メンテナーコンテキストを確認し、flounder ui --maintainer を有効にしてから、reference/maintainer-harness.md に従います。通常のターゲットプロジェクトからこのループを実行しないでください

次のアクションの判断

• デーモンがオンラインではない：ジョブを起動する前に、デーモンを作成または接続します。
• デーモンはオンラインだがプロバイダーのチェックに失敗する：flounder daemon provider login を実行するか、 デーモンローカルのプロバイダー認証情報を設定してから、もう一度チェックします。
• サンドボックスで利用可能なバックエンドがないと表示される：Apple シリコン搭載の macOS では、Apple の container ランタイムをインストールして起動し、 イメージをそのランタイムにビルドまたはプルします。または、デーモンに Docker をインストールして起動し、npm run sandbox:build を実行します。ホストへのフォールバックには、引き続き明示的な信頼済みローカルの承認が必要です。
• プロジェクトにプロバイダープロファイルまたはデーモンがない：実行を作成する前に設定します。
• 実行がキューに入っており、どのデーモンも取得できない：プロジェクトで選択されているデーモンを確認します。
• 実行中：集計カウントだけでなく、GET /api/runs/:id/log とプロジェクトのフェーズを監視します。
• Prepare の品質が limited：ユーザーが最初に資料を完全な状態にするよう求めていない限り、自動的に続行します。verify、confirm、レポート用に prepareSummary.caveats、gaps、realTarget を保持します。
• Prepare の品質が needs-review、missing、または invalid：prepareSummary.blockingIssues、issues、gaps、realTarget を確認します。回答を含む資料の汚染、無効な出力、準備済みソースが空であること、使用可能なソースがないことなど、重大なブロッカーのみを修正します。それ以外の場合は、手動レビューを求めず、注意事項を残して続行します。
• Map は完了しているが、高スコアのスコープの多くが保留中：監査を続行するか、スコープに優先順位を付けます。
• 最新の実行の健全性が needs-resource：未解決の resource-request 行を確認し、可能な場合はエージェントに安全なツールチェーン、サンドボックス、依存関係、ソース、または認証のセットアップを再試行させます。明示的な認証情報、認可、または利用できない外部リソースが必要な場合に限り、オペレーターに依頼します。対応済みの行を resolved に設定してから、ブロックされているフェーズを再実行します。モデルが resource_requests.json を書き出さなくても、Prepare とツールチェーンのウォームアップによってこれらの行が作成されることがあります。これらはプロダクト側が担うセットアップ作業であり、監査結果ではありません。
• 最新の実行の健全性が needs-coverage：保留中のスコープを続行するか、バックログからフォローアップするスコープに優先順位を付けます。カバレッジ不足の代わりに、モデルに「さらにバグを報告する」よう求めないでください。
• 最新の実行の健全性が shallow：実行を不確定なものとして扱います。ログを確認し、要約する前に再実行するかセットアップを修正します。
• Discovery バックログに未処理の Next Actions がある：まずエージェントに解決または適切な振り分けをさせます。カバレッジ行はカバレッジを続行し、マップにカバレッジを追加するか、参照先のスコープに優先順位を付けます。セットアップ行は安全なローカルセットアップを再試行します。振り分け行は内容を確認し、適切で安全なワークフローアクションに変換します。これらは監査結果ではありません。後続の実行に基づく監査で確認されない限り、バグ一覧に含めないでください。
• Findings が suspected のみ：対象をビルド可能な状態にして、verify を実行するか、さらに調査します。
• Findings はローカルで確認済みだが再現されていない：confirm を実行します。
• skipRealTargetConfirm=true のコンテストプロジェクト：実際の対象に対する Confirm は意図的にスキップされることがありますが、提出前には引き続き verify/refute とレポートの適格性確認が必要です。
• コンテストのインベントリを使い切った：append-map/Continue を使って、既存のスコープ状態や提出済み／重複 finding の履歴を失わずに、新しいスコープを追加します。
• マシンによって報告された finding が手動で却下されている：トラッキングを ignored に設定します。後で Ignored フィルターからトラッキングを open に戻すと、再び確認できます。
• Confirm の判定が not-reproduced：既知の環境上の制限による失敗で、ユーザーが追加作業を承認している場合を除き、提出準備ができていないものとして扱います。
• Confirm の判定が submit-candidate：バグのパッケージを収集し、これ以上のエクスプロイトは停止します。
• Findings がなく、資料のカバレッジが低い：結論を出す前に、ソース／ビルド／コーパスのセットアップを改善するか、保留中のスコープを続行します。

よくあるエラーと復旧方法

症状	考えられる原因	復旧方法
キュー内のジョブを処理できるデーモンがない	プロジェクトがオフラインのデーモンに固定されています	そのデーモンを起動するか、プロジェクトのデーモン設定を編集してください。
プロバイダーの認証情報がありません	認証情報はサーバーではなくデーモンにあります	必要に応じて OAuth ログインまたはデーモンローカルの API キー設定を使用し、その後 check を実行してください。reference/models.md を参照してください。
Docker を利用する OCI サンドボックスを使用できません	デフォルトのイメージがないか、Docker が停止しています	Docker を起動して npm run sandbox:build を実行してください。ホストへのフォールバックには、信頼されたローカル環境として明示的に承認する必要があります。
Apple のコンテナサンドボックスを使用できません	Apple の container がインストールまたは起動されていない、選択したイメージがそのランタイムにない、または内部の封印されたネットワークを作成できません	container system start を実行し、イメージを Apple のランタイムにビルドまたはプルしてください。この経路を利用できない場合、auto は Docker にフォールバックします。
prepareSummary.quality=limited	ソースは利用できますが、注意事項があります	作業を妨げる問題がない限り続行し、確認／レポートのために注意事項を保持してください。
prepareSummary.quality=invalid/missing	利用可能なステージ済みソースがないか、素材が汚染されています	監査の前に prepare の入力を修復してください。
Verify が素材の変化を理由に選択した検出結果を拒否する	新しい Prepare によって現在の素材の境界が変わりました	現在の検出結果を選び直すか、変化を確認したうえで、明示的なエキスパート向けオーバーライドを渡してください。
Confirm が not-reproduced を返す	実際のターゲットで PoC が攻撃者の視点から現実的でないか、環境が不完全です	ユーザーが追加の再現作業を承認しない限り、提出可能な状態ではないものとして扱ってください。
Report アクションが、レポートが未作成の検出結果はないと表示する	レポート対象の行にはすべて正式なレポートがすでにあるか、選択した行が再現／確認されていません	`flounder report --project <uuid
リポジトリのツール実行中に Node のネイティブクラッシュが発生する	サポート対象外の Node バージョンです	.nvmrc ／ .node-version に記載された Node 24 LTS を使用してください。

バグの収集

バグ候補ごとに、以下を収集してください。

• プロジェクトと実行 ID
• タイトル、場所、スコープ ID、ステータス
• そのプロパティが重要である理由
• 正確なコマンドの証拠または command_id
• PoC ファイルまたはテストパス
• 差分の結果（ある場合）
• 反証または異議申し立ての結果（ある場合）
• 確認の判断：reproduced、not-reproduced、submit-candidate、needs-human、 または drop
• レポートのパスと成果物のパス
• 残っている人間による確認事項：バウンティの対象範囲、重複／既知の問題、公開延期期間、または 開示先

モデルが疑わしいとした項目の一覧をバグとして提示しないでください。確認済みの検出結果、疑いのある検出結果、反証された検出結果、再現済みの提出候補を分けてください。

完了時のスナップショット

エージェントが以下を報告できるようになるまで、タスクは完了ではありません。

• Flounder のコントロールプレーンに接続できるか、明確なセットアップ上の阻害要因が記録されている。
• 実行デーモンが選択され、オンラインになっている。
• 選択したプロバイダープロファイルがすべてデーモン上で認証されている。
• プロジェクトに、依頼された監査に適したソースパス、ビルドルート、コーパスパスが設定されている。
• 準備済みの素材が ready または limited である。limited の場合、verify、confirm、report の判断に必要な注意事項が、既知の制限としてすべて明示されている。
• 監査の実行が終了状態に達しているか、意味のある阻害要因がある。
• 最新の実行状況と未解決の検出バックログの行がある場合、その概要が示されている。
• スコープのカバレッジがまとめられている：マッピング済み、監査済み、保留中、延期。
• 検出結果がステータス別にまとめられている。
• 実際のターゲットでの再現が必要な場合、確認済みの検出結果に対して confirm が実行されている。
• Ignored の検出結果がアクティブな作業リストから分離され、後から復元できる状態にある。
• 開示用のパッケージ作成が依頼されている場合、再現済みまたはローカルで確認済みの、ソース提供の監査バグに対してレポートが選択されている。
• 提出候補に証拠と成果物のパスが含まれている。
• 提出できない項目に、理由とともに疑いあり、反証済み、未再現、または人間による確認が必要と明記されている。

高リスクなデフォルト設定

• 明示的な許可を得ずに、対象に対して実行しないでください。
• ユーザーが、ホスト実行にはカーネルレベルのファイルシステムおよびネットワークの隔離がないと説明を受けたうえで、信頼されたローカル環境へのフォールバックを明示的に承認しない限り、モデル生成テストにホスト実行を使用しないでください。
• モック化された信頼済みコンポーネントを、攻撃者が実際に利用できる能力として扱わないでください。
• 「上流と一致している」または「標準的に見える」という理由だけで結論を出さないでください。
• モデルや思考の設定を、通知せずに引き下げないでください。
• デーモンやプロバイダーのセットアップ失敗を、監査の失敗として埋もれさせないでください。
• 再現済みの、対象範囲を限定した非公開レポートがない状態で、報告または開示しないでください。