grahama1970/battle

停止。在调用任何端点前，请阅读整份 SKILL.MD。

对抗技能 (Battle Skill)

红蓝队安全竞赛编排器

让红队（攻击方）与蓝队（防守方）在长期运行的竞争性循环中对决。每个团队利用所有 .pi/skills 来攻击或防守目标代码库。

不变量战役 (Invariant Battles) (常见情况)

Battle 的默认评分目标是漏洞利用（系统崩溃、命令注入）， 但红蓝对抗循环最常见的实际用途是验证一个项目特定的不变量："没有PII值泄漏"、"账本平衡"、"解析器不丢弃记录"、"授权检查无法绕过"。

提供一个可插拔的不变量裁判 (Judge)——一个小的独立模块 judge(target_dir, params) -> {passed, violations, evidence} (模式 battle.invariant_result.v1)。红队的目标是"产生一个能使裁判失败的输入"；蓝队的目标是"使其通过"；记分员读取裁判结果，而非任何智能体的自我报告。裁判是故障关闭的：出错的裁判意味着不变量验证失败，而不是沉默地通过。

python3 -m battle_skill.invariant_judge \
  --judge fixtures/reference-judges/no_data_leak_judge.py \
  --target <released-output-dir> \
  --params '{"policy": "policy.json", "output_subdir": "corpus"}'

fixtures/reference-judges/no_data_leak_judge.py 是一个作为裁判的匿名化机密性不变量：它独立扫描发布输出（JSON 标量，包括解码后的转义、数字扩展、SQLite 单元格 + 模式 DDL + 头部整数、text/CSV、report.json 以及捕获的 stdout/stderr），查找任何表示形式中的任何策略值。

合同变体家族研究 (通用 Battle 组合)

Battle 不是项目特定的。对于任何具有 acceptance_contract.bundle.v1 的项目或技能，Battle 应在声称全面对抗覆盖之前，通过 Dogpile 扩展每个合同项：

./run.sh contract-variation-plan \
  --acceptance-bundle /path/to/acceptance_bundle.json \
  --dogpile-source brave-search \
  --dogpile-source arxiv \
  --out /tmp/battle-variation-plan.json

输出为 battle.contract_variation_plan.v1。它是一个两阶段的 Battle 合同，而非松散注记：

1. 阶段 1：通过冻结的 acceptance_contract.bundle.v1 底线。
2. 阶段 2：通过该底线后，收集 $project-state、当前 Battle 收据、源过滤的 $dogpile 研究和 $ask 一次性 审阅者提案。
3. 阶段 3：将阶段 2 中有用的发现冻结为确定性案例，运行它们，并为红队胜利、蓝队修复和重放保留适应性血统证明。

该计划将每个验收案例映射到带有源标记的 Dogpile 研究通道和可重用的变体家族。当 Battle 阶段只需要选定的 Dogpile 提供者（如 brave-search、arxiv、github-search、youtube、brave-questions、feeds、wayback 或 context7）而非完整源扇出时，请使用可重复的 --dogpile-source 过滤器。可重用的变体家族包括表示等价性、编码/规范化、解析器差异、发布面边界、有损转换、拆分/组合事实、规模、重试/并发、授权和失败泄漏边界。Dogpile 和 Ask 仅是研究输入：它们发现有意义的变化家族和源证据。Battle 随后将选定的家族冻结为确定性生成器，在 Docker/QEMU/数字孪生证据门中运行真实目标，为每个案例发出 battle.case_receipt.v1，使用 battle.campaign_aggregate.v1 进行聚合，并将工作流类保留为 $agentic-evals 案例。一个严肃的发布门应期望数百个确定性案例，当合同表面很广时大约有 20-30 个保留的评估类；较小的烟雾门必须将其自身标记为烟雾。

不变量战役 (测试合同底线，然后超越攻击)

不变量 战役 评判一个输出。不变量 战役 让红队生成目标规范所命名的输入"版本"的整个矩阵——每种格式 x 每种表示 x 文档化的边缘案例——加上随机模糊测试，每个都运行真实目标，裁判对每个输出进行评分。每个案例发出一个 battle.case_receipt.v1，其中包含夹具预检、执行、拒绝、安全裁判、可选功能裁判和判决字段。一个战役通过，仅当所有案例收据通过，所需的 MUST_ACCEPT 案例实际被接受并通过功能评判，所需的 MUST_REJECT 案例被安全拒绝，并且计算出的 battle.campaign_aggregate.v1 中没有失败或不完整的案例。一个失败的版本就是一个具体的、可重现的红队胜利。

对于匿名化/隐私目标，验收合同只是底线。当存在 acceptance_contract.bundle.v1 时，平台构建可以将其作为 acceptance_floor 传递给生产适配器。Battle 随后故障关闭，除非每个 acceptance_cases[] id 都映射到配置文件中 required_case_ids 中的至少一个战役生成器案例；这些是必须通过的最基本对抗版本，然后任何额外的模糊测试或合同外情况才重要。Battle 还必须运行一个合同外战役，攻击客户简报经常遗漏的表面：JSON 键和重复键、CSV 标头/方言/多行单元格、SQLite 标识符/默认值/生成值/部分索引/触发器、文件名、report.json、stdout/stderr、备用编码和同一身份表示陷阱。仅一个干净的简报矩阵重放是烟雾证明，而不是全面的 Battle 证明。

python3 -m battle_skill.invariant_campaign \
  --generator fixtures/reference-generators/anon_brief_matrix.py \
  --target-run-cmd 'docker run --rm -v {input}/corpus:/trial/input/corpus:ro -v {input}/policy.json:/trial/input/policy.json:ro -v {output}:/trial/output anonymization-trial run' \
  --judge fixtures/reference-judges/no_data_leak_judge.py \
  --gen-params '{"fuzz": 20}' --judge-params '{"output_subdir": "corpus"}'

fixtures/reference-generators/anon_brief_matrix.py 生成匿名化简报的版本：四种格式、JSON 字符串/整数/浮点数/科学计数法、SQLite TEXT/INTEGER/REAL、Unicode NFC/NFD、BOM、JSON \u-转义、SQLite CHECK-字面量，加上模糊测试。它还携带了 oai-trial 圆桌会议的边缘案例：格式化的策略电话号码值存储为数字只 JSON/SQLite 数字，相同的身份被植入每个范围内的格式中，以及有损的前导零/大浮点陷阱。fixtures/reference-generators/anon_beyond_brief_matrix.py 是隐私/匿名化证明所需的下一步：它尝试超越字面验收合同的非明显模式/路径/编码/日志/发布边界表面。一个生成器 + target-run-cmd + 裁判是一个可插拔的三元组：将其指向任何项目的规范矩阵和不变量。

无数据泄漏裁判还支持一个用于转换语义的显式选择加入解释配置。除非在 --judge-params 中声明，否则此保证处于关闭状态，因此 Battle 在看到故障后不会静默扩展合同：

{
  "interpretation_profile": {
    "decoders": ["base64", "base64url", "hex"],
    "record_local_reconstruction": true,
    "max_decoded_bytes": 4096
  }
}

使用该配置，整个标量/令牌 base64/base64url/hex 值被解码一次，并且记录本地的相邻 JSON/CSV/SQLite 标量字段可以重建完整的策略值。任意的递归解码、全局字段连接和视觉混淆字符折叠仍处于默认拦截门之外。

在红队发现失败案例且蓝队修补目标后，发出可重放的血统收据，而不是用散文总结：

./run.sh invariant-lineage-receipt \
  --red-campaign /tmp/red-result.json \
  --replay-campaign /tmp/replay-result.json \
  --target oai-trial \
  --out /tmp/battle-lineage.json

一个 battle.invariant_adaptive_lineage.v1 通过证明红队发现了合同边缘案例，蓝队消除了这些红队胜利，并且独立裁判重放通过了。

然后 Battle 必须生成一个经过 $create-report 验证的报告，其中包含 $project-state 上下文和明确的利用表。该报告是人类可读的决策工件；收据仍然是权威的。首先生成新的项目状态，然后渲染报告：

PROJECT_STATE_ROOT=/path/to/target ../project-state/run.sh report --json --output /tmp/project-state.json
./run.sh invariant-report \
  --campaign /tmp/battle-brief-fuzz.json \
  --campaign /tmp/battle-beyond-brief.json \
  --adaptive-lineage /tmp/battle-lineage.json \
  --project-state /tmp/project-state.json \
  --target oai-trial \
  --out-json /tmp/battle-report.json \
  --out-md /tmp/battle-report.md

对于项目智能体终端审查，当案例有长证据时使用卡片：

./run.sh invariant-report \
  --campaign /tmp/battle-brief-fuzz.json \
  --campaign /tmp/battle-beyond-brief.json \
  --project-state /tmp/project-state.json \
  --target oai-trial \
  --out-json /tmp/battle-report.json \
  --out-md /tmp/battle-report.md \
  --terminal-cards

invariant-report 是一个 Typer CLI 命令。它将机器 JSON 写入标准输出，将人类可读的 Battle 报告保留在标准错误上。使用 --terminal-cards 进行正常的项目智能体 Battle 证据审查：它在 Acceptance contract floor、Beyond-contract exploits、Adaptive lineage 和后备的 Other campaign cases 标题下对卡片进行分组，然后为每个案例打印一个 ============== 块，包含 Scope、Case、Acceptance parent、Expect、Result、Example、Why Battle checks this、Related research、Adaptive lineage 和 Judge evidence。如果生产适配器收据携带 acceptance_floor.case_map，合同底线卡片显示父级 AC-* ID；否则 Acceptance parent 显示为 not recorded in case receipt。如果收据有 example、why_chosen、research_refs 或 source_refs，卡片显示这些确切字段；否则示例/理由来自案例 ID，研究报告为 not recorded in case receipt。

--terminal-table 仍然是 --terminal-summary 的紧凑替代别称：两者都打印合同底线、红队压力、记分员调用，以及每个攻击一个案例表行。在交互式终端中，Battle 使用 Rich 的终端感知彩色表（RED_WIN 红色，干净通过绿色，故障关闭停止黄色）并尊重 NO_COLOR；在捕获/CI 下，它回退到确定性纯文本，以便日志和测试保持稳定。

invariant-report 写入 create_report.report.v1，通过 skills/create-report/run.sh validate 验证，通过 skills/create-report/run.sh render 渲染，并附加 ## Exploits Table。该表必须直白且易于扫描：每个攻击案例一行，包含 Scope、Contractual?、Adaptive lineage?、Case、Exploit / attack、Why chosen、Expectation、Result 和 Judge evidence 列。Scope 将合同底线的 contractual 案例与 beyond-contract 探测分开；Why chosen 解释了非合同探测；Adaptive lineage? 标记了被修复并重放的红队胜利；RED_WIN 阻止发布。该表在存在时源自 battle.case_receipt.v1，仅对旧的山寨战役收据回退到遗留的 case_log。没有该报告的 Battle 关闭即使战役收据通过，也缺少决策面。

目的边界

Battle 的目的是红/蓝安全竞赛后端：授权目标设置、隔离执行、红队攻击生成、蓝队防御生成、独立裁判重放、记分员收据、适应性血统和持久学习。适应性血统是一个后端学习循环，它生成、评估、选择并提升或拒绝来自裁判支持的收据的子级红/蓝证据。

PixiJS 只是 Battle 收据的观赏/重放面。PixiJS 通过证明记录的收据可以在有趣的游戏中检查；它不证明 Battle 编排器、提供者驱动的子智能体、Docker/QEMU 隔离、隔夜调度器、记分员或内存学习有效。不要仅从 PixiJS 证据来关闭核心 Battle 准备就绪，并且不要在后端适应性血统上阻止重放修复，超出真实的收据可检查性。

架构

生产环境中的 Battle 是一个编排技能，而不是一个大型的定制安全引擎。主机端进程应安排轮次、选择角色、派遣子智能体、配置 Docker 运行时、收集收据、对硬运行时信号进行评分、编写报告并持久化学习。目标代码和团队生成的代码必须仅在 Docker 内部执行。

所需的生产不变量：

• 红队和蓝队是子智能体团队。每个派遣的子智能体必须包括一个由编排器为该回合选择的明确角色。当回合受益于广度时，每个团队的多个角色可以并发运行。
• Battle 执行要求一个 security.target_authorization.v1 清单，然后 Docker、QEMU、目标运行时设置、黑客授权、证明重放或补丁重放才能开始。清单绑定项目/操作员范围和目标身份；它不是法律意见，也不证明利用成功或补丁有效性。
• 红队 $hack 执行是子智能体的责任，而不是 Battle Python 导入。Battle 执行或安排扫描/研究/内存召回，构建候选利用列表，选择红队角色，派遣一个 agent-skills/agents/Tau 子智能体与该合同，并记录返回的利用收据。
• 子智能体移交和收据应遵循 tau.agent_handoff.v1 和 tau.subagent_receipt.v1 使用的紧凑 Tau 风格 JSON 合同形状，并在其上分层 Battle 特定字段，而不是单独的特设协议。
• Battle 调用模块化 Tau 子智能体合同。Tau 和循环/智能体框架拥有子智能体执行，并使用 scillm 作为 LLM/模型调用者。Battle 拥有团队选择、角色分配、Docker 运行时、记分、工件和内存。

...