flounder

Flounder

此技能是使用 Flounder 执行安全审计的操作手册。

Flounder 是一款自主的白帽安全审计工具。Agent 会准备目标、审计源代码、构建攻击路径、运行本地验证测试、确认真实发现并整理报告。该框架提供守护进程、沙箱、命令策略、运行跟踪、实时活动记录和执行门控。

技能文件

文件	何时阅读
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	仅供维护者使用的 Agent 工作流，用于通过 Evaluation 改进源代码并准备候选 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>。	不要添加事件文档、已知漏洞名称、漏洞利用推测或包含答案的语料库。官方目标文档可以作为目标材料，但不能用作隐藏答案。
“这里有一个可疑的交易 / 地址；找出黑客攻击 / 根本原因”	事件调查	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。	以短批次执行并完成收尾：在开启下一批次前，先验证 / 证伪并报告。若竞赛平台规则允许，仅在源码上进行本地确认可能就足够，但仅有怀疑的发现不能作为提交。扩展覆盖范围时使用 append-map，而不是 remap。

如有疑问：如果用户要求衡量 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 失败中学习”	这是维护者工作，不是常规目标审计。确认 Agent 正在获得授权的 Flounder 源代码仓库中操作，然后阅读 reference/maintainer-harness.md，并执行隔离的源代码更改工作流。

核心操作规则

• 使用 Flounder CLI、仪表板、REST API 或 pi 扩展工作流。不要直接编辑 跟踪数据库。
• 运行审计前，确认授权和范围。
• 将提供商凭据保留在守护进程本地。服务端存储提供商配置； 守护进程负责提供商登录、API 密钥、目标源码和执行。
• 将 ~/.flounder 视为默认产品目录：跟踪数据库、运行产物、 持久历史记录 / 构建缓存、守护进程工作区和守护进程本地的提供商身份验证 都存放于此，除非用户显式传入 --out 或 --workspace。
• 除非用户已有正在运行的控制平面，否则先启动 flounder ui。 CLI 动词是该控制平面的轻量客户端。
• 仅当获得授权的 Flounder 维护者正在改进 Flounder 源代码时，才启动 flounder ui --maintainer。普通项目和 Evaluation 工作 不得启用或宣传 Harness 源代码改进操作。
• 直接使用 REST API 前，先调用 GET /api；该目录是端点结构的事实来源。
• 使用项目自有的文档 / 规范 / 审计作为语料。不要编写会指出疑似漏洞、位置或机制的 答案提示型语料。
• 不要就地修改目标源码。Flounder 会将构建根目录复制到 隔离工作区，模型编写的测试也只能留在该工作区内。
• 将 suspected 视为未经证实。只有执行产生了 confirmed-executable、 confirmed-differential，或复现了确认判定，调查结果才可采取行动。
• flounder run <clue> 是一条命令式工作流：开放世界准备、封闭式梳理 / 深挖 / 综合 / 验证、开放世界确认，然后生成报告。 flounder run --source、map 和 audit 是封闭式发现阶段。 prepare 和 confirm 是开放世界阶段，但仍须遵守白帽 禁止广播规则。
• 绝不广播交易、转移资金、提交写入、持久化访问权限，也不得将目标扩展到已声明的本地审计边界或明确授权范围之外。

首次响应检查清单

当用户要求审计、确认、验证、报告或检查 Flounder 状态时：

1. 确认目标源是公开的、由操作者拥有的、经客户端授权的，或属于公开漏洞赏金范围。如果源的边界不明确，请先询问，再运行。
2. 将请求归类为一种核心审计模式：盲能力审计、事件调查、开放世界公开源审计、常规漏洞赏金，或漏洞赏金竞赛。
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
   

   在安装或链接软件包之前，请在命令示例中用 node dist/cli.js 替换 flounder。

2. 启动或复用本地控制平面：

   flounder ui
   

   对于远程执行器，请在“设置”中或通过 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，Agent 会按以下方式请求用户进行身份验证。 在终端中运行登录命令；它会打印浏览器 URL 或设备代码说明，用户完成登录后，再通过 check 验证。如果 pi 已在 ~/.pi/agent/auth.json 中配置 openai-codex，Flounder 会在登录/检查时将该提供方条目导入 ~/.flounder/agent/auth.json。

4. 确保守护进程所在机器上有可用的执行沙箱。默认的 auto 模式在 Apple 芯片 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 芯片 macOS 守护进程主机上，安装/启动 Apple 的 container 运行时，并将所选镜像构建或拉取到该运行时中，以便 auto 选择它；--sandbox-backend apple-container 则要求显式使用该路径。 如果没有可用的沙箱引擎，仅可在警告用户主机模式缺少内核级文件系统和网络隔离后，将 --sandbox-backend host --allow-host-execution 用于受信任的本地冒烟测试。

5. 在设置中创建或复用提供商配置。提供商配置用于选择 提供商、模型和思考级别。新建存储会预置 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 负责的队列（agent-runnable、agent-resource、agent-review），并使用 PATCH /api/backlog/:id 将条目标记为 resolved、ignored、stale 或重新设为 open

   项目名称是显示标签。通过 POST /api/projects 或 GET /api/projects 获取项目 UUID；不要根据名称构造项目 URL。

9. 根据以下规则决定下一步操作。不要仅因一次运行结束就认定任务已完成。

快速操作指南

盲测能力审计

当用户不想提供任何提示或事件背景，或想检查框架能力时使用。

推荐的目标预备路径：

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. 用户希望立即执行时，保持勾选 创建后运行。
4. 监控 GET /api/runs/:id/log 和 GET /api/projects/:uuid。
5. 除非 limited 准备结果存在阻断问题，否则将其视为已具备审计条件；在验证／确认／报告决策中纳入相关注意事项。
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 和未处理的积压项。将未处理的后续操作视为 Agent 需要解决或转交的任务，然后再开展无关的新覆盖；只有在需要明确的凭据、授权或无法获取的外部资源时，才向操作人员求助。继续覆盖，或优先处理标记为 needs-coverage 的后续范围；不要将 shallow 视为有意义的阴性结果。

5. 如果有许多已映射范围仍待处理，请优先继续覆盖，再得出阴性结论。

项目设置与维护

当用户询问项目为何无法运行、如何清理项目列表，或如何恢复已归档的工作时，请使用此流程。

• 如果概览提示需要关注设置，请先展开项目设置详情。启动新工作前，修复守护进程选择、提供方身份验证、源码路径或准备材料方面的阻碍。
• 将项目设置详情视为查看已存储项目线索和准备阶段注意事项的入口。不要期望线索会作为单独的仪表板卡片出现；在认为 Prepare 未收到上下文前，请先检查设置。
• 如果未处理的 resource-request 积压项说明了设置受限的原因，请先让 Agent 检查阻碍并重试安全的设置操作。只有在需要明确的凭据、授权或无法获取的外部资源时，才向操作人员求助；之后，将已处理的条目标记为 resolved，或将无需采取行动的条目标记为 ignored。
• 将需要每日关注的活跃项目置顶；从项目卡片菜单归档不活跃的项目。归档会将项目从列表中隐藏、取消置顶，并保留运行记录、范围、发现和报告。
• 从 Settings -> Archived Projects 恢复已归档的项目。
• 拖动排序仅适用于活跃项目；默认按创建时间从新到旧排列，置顶项目排在未置顶项目之前。

发现项分类处理

当用户正在审查机器报告的错误时，请使用此流程。

• 从「活跃发现」视图开始；审查单个审计时，按项目筛选。
• 将审计状态（suspected、confirmed-*、refuted）与跟踪状态（open、triaging、submitted、ignored 等）分开处理。
• 将人工判定为误报的发现标记为 ignored；不要删除。
• 使用「已忽略」视图找回已驳回的发现；出现新证据时，将其状态改回 open。
• 仅针对已复现的真实目标错误生成报告；如果无需进行真实目标确认，也可针对本地确认的、由源码提供的审计错误生成报告。

验证、确认并报告选定的发现

• JSON 中的疑似发现：flounder audit --verify <file> --source ... 或等效命令 flounder verify <file> --source ...。
• 选定的项目发现：使用 More actions -> Verify/Confirm/Report，或 向 POST /api/projects/:uuid/runs 传入 findingId / findingIds。
• 仅重新生成特定报告：使用 {"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、provider、daemon、budget、output 和 pi 扩展详情： reference/commands.md
• Solidity/EVM 和 ZK 示例： reference/examples.md
• 仪表板、项目生命周期、运行阶段、发现待办项和制品模型： reference/product.md
• 白帽政策、沙盒边界和证据阶梯： reference/safety.md
• 仅供维护者使用的 Evaluation 到源码改进循环： reference/maintainer-harness.md

任务路由

用户意图	使用方式
“对这个目标进行盲审计 / 测试框架能力”	盲能力审计：优先使用 flounder run <target-clue>；若源码已准备好或不需要外部准备，则使用 flounder run --source ... --build-root ...
“查明这个 tx/address 被黑的原因”	事件调查：flounder run <tx-or-address-or-incident-link>
“公开审计这个仓库/源码”	开放式公开源码审计：创建包含源码路径和任务/线索的项目，然后运行
“先梳理攻击面”	使用 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 中确认项目/发现
“收集漏洞以便披露”	阅读发现、选定报告、确认决定和制品；仅返回有执行证据支持的条目
“忽略这个误报”	将发现的 tracking 设为 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 和项目阶段，而不只是汇总计数。
• 准备质量为 limited：除非用户要求先完善材料，否则自动继续；在验证、确认和报告中保留 prepareSummary.caveats、gaps 和 realTarget。
• 准备质量为 needs-review、missing 或 invalid：查看 prepareSummary.blockingIssues、issues、gaps 和 realTarget。只修复硬性阻碍，例如包含污染内容的答案材料、无效输出、准备好的源为空，或没有可用源；否则带着注意事项继续，不要要求人工审核。
• 映射已完成，但许多高分范围仍待处理：继续审计或优先处理相关范围。
• 最新运行的健康状态为 needs-resource：检查未处理的 resource-request 行；尽可能让 Agent 重试安全的工具链、沙箱、依赖项、源或身份验证设置；只有在需要明确凭据、授权或无法获取的外部资源时，才询问操作员。将已处理的行标记为 resolved，然后重新运行受阻阶段。即使模型没有写入 resource_requests.json，准备阶段和工具链预热也可能创建这些行；应将其视为产品负责的设置工作，而非审计发现。
• 最新运行的健康状态为 needs-coverage：继续处理待处理范围，或优先处理待办清单中的后续范围。不要让模型用“报告更多漏洞”来代替覆盖范围。
• 最新运行的健康状态为 shallow：将该运行视为结论不充分；检查日志，并在总结前重新运行或修复设置。
• 发现待办清单中有未处理的 Next Actions：先让 Agent 解决这些事项或将其转交处理。覆盖范围行用于继续覆盖、补充映射覆盖，或优先处理所引用的范围；设置行用于重试安全的本地设置；路由行则需要检查，并转化为恰当且安全的工作流操作。这些不是发现项，除非后续有执行依据的审计确认了问题，否则不应出现在漏洞列表中。
• 发现项仅处于 suspected 状态：让目标变得可构建，然后运行验证或继续深入调查。
• 发现项已在本地确认，但尚未复现：运行确认。
• 竞赛项目设置了 skipRealTargetConfirm=true：可以有意跳过真实目标确认，但提交前仍需进行验证/证伪，并满足报告资格要求。
• 竞赛清单已耗尽：使用追加映射/继续来扩展新的范围，同时保留先前的范围状态以及已提交/重复发现的记录。
• 机器报告的发现项被手动驳回：将跟踪状态设为 ignored；之后可在“已忽略”筛选器中将跟踪状态改回 open，以恢复该项。
• 确认决定为 not-reproduced：除非失败属于已知的环境限制且用户批准继续投入工作，否则不要将其视为可提交状态。
• 确认决定为 submit-candidate：收集漏洞包并停止进一步利用。
• 没有发现项且材料覆盖率低：改进源/构建/语料库设置，或在下结论前继续处理待处理范围。

常见错误与恢复

症状	可能原因	恢复方法
没有守护进程能接管排队中的任务	项目固定到了离线守护进程	启动该守护进程，或编辑项目的守护进程配置。
缺少提供方身份验证	凭据存储在守护进程上，而非服务端	根据情况使用 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	源可用，但存在注意事项	除非存在阻断问题，否则继续；在 confirm/report 中保留这些注意事项。
prepareSummary.quality=invalid/missing	没有可用的暂存源，或材料已受污染	在 audit 前修复 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 文件或测试路径
• 差分结果（如有）
• 驳斥或申诉结果（如有）
• confirm 决策：reproduced、not-reproduced、submit-candidate、needs-human， 或 drop
• 报告路径和制品路径
• 尚待人工处理的事项：漏洞赏金范围、重复项/已知问题、禁发期，或 披露渠道

不要把模型怀疑项列表当作漏洞。请将已确认的发现项、 疑似发现项、已驳斥的发现项和已复现的候选提交项分别列出。

完成情况概览

只有满足以下条件，任务才算完成：

• Flounder 控制平面可访问，或已记录明确的设置阻碍。
• 已选择执行守护进程，且该守护进程处于在线状态。
• 每个所选提供方配置文件都已在守护进程上完成身份验证。
• 项目包含适合所请求审计的源路径、构建根目录和语料库路径。
• 已准备的材料状态为 ready 或 limited；若为 limited，则已将 verify、confirm 或 report 决策所需了解的所有注意事项列为已知限制。
• 审计运行已达到终止状态或遇到有意义的阻碍。
• 如有最新运行健康状况和未完成的发现积压行，已对其进行概述。
• 已概述范围覆盖情况：已映射、已审计、待处理、已延期。
• 已按状态对发现项进行分组。
• 对需要在真实目标上复现的已确认发现项，已通过 confirm 处理。
• 已从当前工作清单中分离忽略的发现项，并确保仍可恢复。
• 如需准备披露材料，已为已复现或已在本地确认的源提供审计漏洞选定报告。
• 候选提交项包含证据和制品路径。
• 不可提交的事项已标记为 suspected、refuted、not-reproduced 或 needs-human，并说明原因。

高风险默认行为

• 未经明确授权，不要对目标执行操作。
• 除非用户在获知可信本地回退缺少内核级文件系统和网络隔离后明确批准，否则不要使用主机执行来运行模型生成的测试。
• 不要将模拟的可信组件视为攻击者实际具备的能力。
• 不要仅凭“与上游匹配”或“看起来符合标准”就下结论。
• 不要悄悄降低模型或思考设置。
• 不要将守护进程／提供程序的设置失败掩盖为审计失败。
• 未能复现问题并形成范围明确的私密报告前，不要提交或披露。