pentest-blackboard

项目黑板（与本产品对齐）

状态落在已绑定项目的 SQLite 黑板，不依赖对话上下文，也不使用 .pentest/ 目录。 系统自动注入「项目黑板索引」（仅 fact_key + summary）；摘要不足必须 get_project_fact，禁止凭摘要臆造细节。

原语与分工（产品模型）

概念	产品落点	规则
Fact	project_facts（upsert_project_fact）	同 fact_key 覆盖更新；非正式漏洞条目。confidence: confirmed | tentative | deprecated
关系边	project_fact_edges（upsert 的 links）	结构化攻击图；finding/chain/exploit/poc 必须带 links
可交付漏洞	record_vulnerability	与 Fact 可各记一次：Fact=复现上下文，漏洞=正式 finding
探索方向	本轮计划 / 协调者委派 / plantask（若启用）	不是独立 Intent 表；待验证方向用 confidence=tentative 的 note/ 或先不落库、验证后再写
人类注入	用户消息 / HITL 审批	直接吸收进决策；不必写成 Hint 原语

Fact vs 漏洞

• 环境/目标/认证等认知 → 只写 Fact（target/ auth/ infra/ business/）
• 发现与利用上下文 → Fact（finding/ chain/ exploit/ poc/）+ body 填满攻击链
• 可交付 findings → record_vulnerability（标题、严重程度、类型、目标、POC、影响、修复）；记前可用 list_vulnerabilities 查重

强制节奏：边渗透边记录

勿等会话结束再批量写入。

1. 每确认一条新认知（开放端口/服务版本、入口路径、认证态或凭据特征、可利用点或攻击面变化）→ 立即 upsert_project_fact（同 key 覆盖）。
2. 每验证出一条可复现漏洞（含 POC/影响）→ 立即 record_vulnerability；与事实可各记一次。
3. 继续下一步前优先落库，避免上下文压缩丢细节。
4. 未绑项目：说明无法写黑板，仍在本轮保留证据摘要。
5. 协调者：子任务返回新认知/漏洞时由协调者写入，勿假定子代理已记。
6. 子代理无工具时：交付物末尾给「待落库」条目（建议 fact_key、summary、body/POC 要点），供协调者立即写入。

工具速查

工具	用途
upsert_project_fact	写入/更新事实（含 body、confidence、links）
get_project_fact	按 key 取完整 body（索引不够时必调）
list_project_facts / search_project_facts	检索黑板
deprecate_project_fact / restore_project_fact	误报废弃 / 恢复
record_vulnerability	可交付漏洞
list_vulnerabilities / get_vulnerability	查重与详情

前置：当前对话已绑定项目（否则工具报错）。

写入规范

fact_key / category

• 格式：小写 category/slug（如 target/primary_domain、finding/sqli-login）
• 环境：target | auth | infra | business
• 发现利用：finding | chain | exploit | poc（另可用 note）
• 同一发现保持同一 fact_key 覆盖，勿拆成多个 key 导致上下文丢失

summary / body / confidence

• summary（索引用一行）：须含「什么 + 在哪 + 如何触发/验证」，禁止只写「存在 SQLi」
• body：完整可复现上下文（索引不含 body）。发现/利用类必含：入口 → 步骤 → 原始请求/响应或命令 → 现象 → 证据 → related_vulnerability_id（若有）
• confidence：有证据钉死 → confirmed；仅线索/待验证 → tentative；误报 → deprecate_project_fact（或 deprecated）
• 更新时若省略 body，保留库中已有 body（可只改 summary）

关系边 links（写入 finding/chain/exploit/poc 时必填）

• 推荐 from：来源 fact → 当前 fact_key
• 最少：finding 至少 1 条 {from: target/*, type: discovered_on}；在 finding 上挂 exploit 用 {from: exploit/*, type: exploits}
• 常用 type：discovered_on | depends_on | leads_to | enables | exploits | contains | part_of | supports
• 省略 links = 保留已有边；传入 links = 替换全部入边

工作方式（对齐本产品编排）

不设 Bootstrap/Reason/Explore 磁盘状态机。按当前运行模式推进，但读写黑板的纪律不变：

模式	黑板用法
单代理 / deep	边干边 upsert_project_fact；读索引不够则 get_project_fact
plan_execute	计划步骤产出认知后立即落库；重规划前 list/search_project_facts
supervisor	协调者汇总子代理「待落库」并写入；子代理无工具则结构化交付

卡住时：换边/换起点/换攻击域；用 search_project_facts 重审已有 Fact，避免重复死路。负结果也要落库（见验证铁律 skill）。

行为触发器（纪律）

每步必检（不检=违反验证铁律）：

1. 识别→搜：识别任何组件/框架/版本/中间件 → 暂停利用 → 立即执行 component-vuln-intel 全部命令（browser_navigate+terminal curl，7 个步骤全做）→ 结果用 tentative Fact 或本轮计划跟踪 → 搜完才继续。不搜就说「无已知漏洞」=幻觉；验证后再 confirmed / record_vulnerability。
2. 拒绝→换路：收到 403/429/超时/RST/WAF 拦/CDN 502/限流/空响应 → 禁止同条件重试 → 立即换路序列：SOCKS5 代理→换 UA→加 XFF→换协议(WS/DNS)→换端口→编码变异（完整代理获取/验证见 proxy-tool-bootstrap）→ 全换仍不通才写负结果 Fact（confirmed + body 写清已测条件）换面。
3. 新认知→横向：拿到凭据/域名/IP/路径 → 立即横向喷：凭据全服务复用 / 新域名全端口扫 / IP 反查同站 → 不等人指示自动扩展攻击面，并 upsert_project_fact（如 auth/cred-*、target/related-*）。有凭据不喷=遗漏。

违反判定：不搜就说「无已知漏洞」=幻觉；被拦不换路=放弃；有凭据不喷=遗漏 → 均违反验证铁律。

证据 / 战利品 / 改动

原「磁盘」概念	本产品做法
evidence/	Fact body + record_vulnerability 的证明字段 + 工具执行记录；大文件放会话/项目 workspace
loot/	凭据特征写入 auth/ Fact（注意脱敏与授权范围）；完整秘密按项目策略处理
changelog.md	写入型改动在回复中台账化，并可 note/change-* Fact 记录主机/类型/位置/回滚命令

与验证铁律的衔接

详见 pentest-verification：搜索≠漏洞；无证据不写 confirmed；禁止空泛「可能/疑似」当结论；验证失败写负结果 Fact。