每个文件都是针对该类别的 projectContext 框架：包含已知技术栈通常具有的资产类型、攻击者能力、信任边界、不变量和重点领域。模型仍然拥有审计策略，框架仍然需要执行证明。

默认不启用——这是有意为之

该框架绝不会自行加载这些文件。 默认的 flounder run / flounder map / flounder audit 不携带预设的漏洞知识：运行是盲目的且基于执行的，因此模型必须在任何审计试验发现任何东西之前，从实际源码中枚举攻击面。将一份预先写好的漏洞常出现位置列表交给模型，会使其偏向于列出的区域而忽略未列出的区域，并有可能将审计变成清单匹配而非阅读理解。这与本工具旨在发现新颖漏洞的初衷背道而驰，因此除非您明确要求，这些配置文件保持关闭状态。

它们存在于那些权衡值得的情况下：一个常见的漏洞类别，其中填充通用攻击面确实有用；一个预算有限的项目，需要在关注/范围外方面抢占先机；或者为熟悉的技术栈快速界定范围。Solidity/EVM 和 ZK 配置文件是常见的高信号示例。在这些情况下，选择启用：

配置文件实际改变了什么

--config <file> 合并到运行配置中（applyConfigOverrides），然后命令行标志会覆盖它——因此您在 CLI 上传递的 --target / --source / --corpus / --max-steps 会覆盖文件中的设置。在 projectContext 中，目前只有 summary、focusAreas 和 outOfScope 会到达模型（整合到其范围说明中）。下面更丰富的字段目前是文档/框架——它们记录了供人类作者使用的威胁模型，但尚未注入到提示中。

在配置文件中将 sourcePaths / corpusPaths 留空，并在命令行上传递实际目标和项目自有的规范/文档。配置文件是一个框架，不能替代目标的实际材料。

配置文件不可逾越的界限

配置文件是上下文，绝非定论。 它可以告诉模型去哪里看；但不能告诉模型会找到什么。确认仍然只能来自执行——一个发现是真实的，是因为 PoC 运行了，而不是因为它匹配了配置文件。（配置文件自身的 scenarioGuidance 明确指出："不要编写声称发现结果的静态漏洞规则。"）

扩展此目录

这是领域上下文包的可选存放位置。要添加一个，请保持其对某个类别的通用性且不含答案：捕获某类通常具有的攻击面和不变量，而绝不是一个特定目标中的特定已知漏洞。任何针对特定目标的内容都应属于该审计的 --corpus，而不是这里。