fashionmascherine-svg/formalswarm

FormalSwarm

FormalSwarm 封面——正题、反题、封印：一个你可以重新计算的裁决

不要满足于一个 AI 答案。让它经受一场辩论——以及一次检验。

FormalSwarm 帮助智能体提出解决方案、质疑假设，并验证那些真正可被检验的主张。从一个代码库或一个文档文件夹开始：一个待审查的变更、一个待设计的漏斗，或一个待压力测试的计划。

独立的智能体撰写正题，对抗性的批评者对其发起挑战，而一个封印会运行真实命令。一个确定性的汇总根据所报告的检查、退出码和用例数量计算出 CONFIRM、REVISE 或 INCONCLUSIVE——而不是一个置信度分数。该裁决覆盖你定义的检查，而非智能体提出的每一条建议。

为代码仓库而构建，也可用于引导式的、文档驱动的问题求解。从 6 个智能体的试点到数百个智能体，在 DeepSeek Harness、Claude Code 和 ZCode 上，使用同一份代码。

ci
license
node
runtimes
agent calls to validate
discussions

从代码开始 · 从文档开始 · 安装 · 检验证明

更多智能体能给你更多想法。FormalSwarm 给这些想法一个对手——
并给可检验的主张一次检验。如果这正是你希望智能体工作的方式，
给 FormalSwarm 加星。

超越代码：将文档转化为可检验的计划

无需 Git 仓库。带上问题、文档和约束即可。

你可以使用 FormalSwarm 在软件之外开发和挑战解决方案：一个漏斗、
发布计划、运营流程或资源分配。提案来自智能体；FormalSwarm 构建它们的辩论
结构，并检验可度量的主张。这些是同一协议的应用，而非内置的专用工具，
也不保证每一种问题都能被自动裁决。

示例：从一个文件夹设计一个漏斗

在你的编码智能体中打开一个工作区文件夹，并给它 3–6 个上下文文件。纯文本、
Markdown、JSON 和可读的数据导出效果很好；提取 PDF 或其他二进制
先整理成可读的文件。你不需要应用程序代码或 Git。

funnel-project/
objective.md       # 期望的结果、受众，以及成功的含义
offer.md           # 产品/服务事实、价格、已验证的承诺、来源链接
constraints.md     # 支出上限、时间安排、产能，以及审批边界
current-journey.md # 现有广告、页面、行动号召，以及已知的摩擦点
evidence.csv       # 可选：带有单位和日期范围的实际观察数据

缺失的证据同样是有用的信息。如果你目前还没有任何结果，就在简报中说明，而不是用编造的数字来填补空白。将示例性数字标注为假设，而非观察结果。让客户数据和机密信息远离共享材料。

安装插件后，明确要求你的 agent 使用 FormalSwarm。例如：

Use FormalSwarm on this folder to propose a better acquisition funnel.

Read objective.md, offer.md, constraints.md, and current-journey.md.
Produce two independent proposals, challenge their assumptions, and identify
which parts can actually be verified from the available evidence.

For each proposal, explain the audience, message, destination page, primary
action, follow-up, spending allocation, and measurement plan. Distinguish
source facts, assumptions, recommendations, and measured results.

Before starting the debate, define the verdict question and runnable checks.
Use 2 thesis writers, 2 critics, and 2 seal verifiers, with one round and a
maximum of 6 agent calls. Keep all source documents unchanged; put drafts and
verification scripts in scratch. Do not publish, spend, or contact anyone.

Return a recommended plan with trade-offs, the objections and open questions,
and the computed verdict with its exact scope. Do not interpret a sound budget
or a complete plan as proof that the funnel will improve real-world results.

这是给宿主 agent 的指令，而不是新的 CLI 命令或无人值守的营销活动构建器。宿主必须将其转化为简报、准备有意义的检查、运行离线门禁，并编排各轮次。当前的角色提示仍然偏工程导向，因此明确描述非代码任务很重要。

每组如何处理文档

1. 论点撰写者提出解决方案。 他们在相互隔离的上下文中阅读相同的源文档，并为具体的备选方案辩护。对于漏斗，一个人可能推荐直接转化路径，另一个人可能推荐辅助转化路径。这些是待评估的假设，而不是自动被证明的优胜者。
2. 批评者质疑推理。 他们对照文档检查各项提案：无依据的承诺、不兼容的约束、遗漏的成本、不必要的步骤，或者一个只统计活动量而非期望结果的衡量计划。
3. 可选的综合环节回应异议。 使用 --rounds 2 时，受到质疑的撰写者会回应批评；宿主必须允许更大的调用预算。一轮
将提案和异议留到最终审查，而不经过此响应阶段。
4. Seal 验证器执行检查。 它们可以重新计算分配、验证结构化数据，或对提供的观察结果运行适当的分析。品味、说服力和未来需求不会因为某个 agent 给它们打分就变成事实。
5. 宿主分别呈现解决方案和证据。 推荐的方案是经过论证的综合。outcome.json 是对指定检查的计算裁决。未经测试的推荐不得继承它们的确认。

定义一个证据能够回答的问题

与其提出一个宽泛的问题——“这个漏斗会奏效吗？”——不如将决策分开：

| 问题 | 证据或检查 | 仍未证明的内容 |
|---|---|---|
| 分配是否符合支出上限？ | 重新计算时长 × 每日分配，包括声明的成本 | 实际交付和有效性 |
| 提供的内部结果是否一致？ | 验证非空记录、单位、总计和重复项 | 因果关系和未来表现 |
| 提议的旅程是否改善期望的结果？ | 一个适当的真实实验，以及带有预定义标准的经过审查的分析 | 该实验范围之外的任何内容 |

一个仅仅在计划中找到“conversion”一词的脚本并不能验证该计划的有效性。第二个模型给它打 9/10 分也不能。汇总检查报告的结果和覆盖范围；它无法让一个选择不当的测试变得有意义。

该文件夹如何进入现有工作流

同样的 init、brief 和 run 流程适用。将 --repo 指向文档文件夹；该标志名称并不意味着 Git 是必需的。在未检测到技术栈或运行器的情况下，配置文件会报告 stack: unknown 且没有测试命令。提供显式的 seal 检查。

对于通过 CLI 构建 brief 的宿主，其形式如下：

Use the FS command resolved for your installed plugin (see the quickstart below).
$FS init --repo ./funnel-project
$FS brief --repo ./funnel-project \
--objective "Develop a funnel within the documented constraints" \
--verdict-question "Does the proposed allocation fit the documented spending cap?" \
--context objective.md,offer.md,constraints.md,current-journey.md \
--seal "node .formalswarm/scratch/check-budget.cjs" \
--thesis 2 --critics 2 --seals 1 --rounds 1 --max-calls 5

这是一个模板，不是捆绑的漏斗演示：文档和 check-budget.cjs 必须首先存在。让宿主在 scratch 中针对一个显式的候选分配创建并审查该检查，然后从文档文件夹运行它，或使用绝对路径。它必须能够失败、返回真实的退出状态，并统计实际评估的案例数。这里的单个验证器与单个分配的检查相匹配；只有在有足够多的检查可供分配时，才使用更多验证器。

在启动前运行 $FS validate。然后使用 $FS run  和
host-agent 轮次循环：执行最后待处理的
提示，保存其答案，并重复直到驱动程序写入 outcome.json。
独立的 run 命令本身并不提供宿主的子代理工具。

用文档实际尝试过，而不仅仅是描述

一次引导式本地漏斗试点使用未经修改的插件、一个非 Git 文件夹、
三份上下文文档和三个真实代理完成：一个编写者、一个批评者、一个验证者。
宿主准备了文档和检查；没有启动任何活动。使用刻意
合成的输入，原始分配为700，而上限为 600。预算
检查失败，返回 exit_code: 1 和 cases: 1；驱动程序返回REVISE。
提议的 560 分配通过了单独的算术检查，而非第二次全局
批准。真实世界的有效性仍未测量：显式的缺失证据
占位符报告 not_run，案例数为零；它并非有效性分析器。

这确立了一个引导式非代码工作流，而非对解决方案质量或
商业成功的基准测试。试点产物是本地文件，并未作为可复现
示例捆绑在此仓库中。有用的成果是一个规格更完善的计划、可见的
假设，以及明确的下一步测量——而不是由群体凭空捏造的确定性。

60 秒版本

from a checkout
FS="node ./core/bin/formalswarm.js"

once the plugin is installed, resolve it from wherever the runtime put it:
Claude Code   FS="node $CLAUDE_PLUGIN_ROOT/core/bin/formalswarm.js"
ZCode         FS="node $ZCODE_PLUGIN_ROOT/core/bin/formalswarm.js"
any runtime   FS="node $(node -p "require('path').dirname(require.resolve('formalswarm/package.json'))")/core/bin/formalswarm.js"

$FS init                                   # profile this repository
$FS brief \
--objective "Make cache eviction deterministic under concurrent writes" \
--verdict-question "Does the cache evict deterministically under concurrent writes?" \
--context src/cache.py,src/locks.py,tests/test_cache.py \
--seal "python3 -m pytest -q tests/test_cache.py" \
--seal "python3 -m pytest -q -k concurrency"
-> brief.json, with the prompts and the repository profile already embedded

然后运行它。你会得到一个文件，/outcome.json：

{
"global_verdict": {
"outcome": "REVISE",
"reason": "at least one seal check fails (exit_code != 0) or a verifier declares REVISE",
"warnings": ["2 objection(s) were filed by a critic outside its assigned partition ..."]
},
"objection_count": { "total": 9, "accepted": 8, "rejected": 1, "unanswered": 0, "orphan": 0 },
"verdict_review": [
{ "verifier": "seal-1", "declared": "REVISE", "effective": "REVISE", "coherence": "ok",
"notes": [] },
{ "verifier": "seal-2", "declared": "CONFIRM", "effective": "CONFIRM", "coherence": "ok" }
],
"seal_verdicts": [ { "checks": [ { "command": "python3 -m pytest -q -k concurrency",
"outcome": "failed", "exit_code": 1, "cases": 6 } ] } ]
}

任何人都可以重新计算那个判定。没有人必须信任一段文字。

在 30 秒内自行验证

零代理调用、无需 API 密钥、无需网络：

node core/validate-all.js   # -> ALL SUITES GREEN — 114 checks (body 48, driver 24, profile 23, generic 19)
node tests/smoke-e2e.js     # builds real throwaway projects, spawns the seal commands, asserts real exit codes

两者都必须以 0 退出。第一个是完整的离线门禁：每个汇总分支、驱动身份、分析器夹具和通用性守卫，逐一计数——114 行证明，大约四秒钟。第二个需要 python（或 python3）位于 PATH 上，用于其夹具工具链。

这个仓库对自己计算出的判定

FormalSwarm 的首次公开辩论就在 FormalSwarm 自身上运行：5 篇论点、5 位批评者、5 位封印验证者、6 条真实命令、15 次代理调用。汇总返回了 REVISE——直接从 outcome.json 读取：

{
"global_verdict": {
"outcome": "REVISE",
"reason": "at least one seal check fails (exit_code != 0) or a verifier declares REVISE",
"warnings": ["phase ANTITHESIS: 1 fallen agent(s)"]
},
"objection_count": { "total": 11, "accepted": 0, "rejected": 0, "unanswered": 0, "to_answer": 11, "orphan": 0 }
}

15 个代理实际测量到的内容：

- 每个被分配的封印检查都是绿色的，并带有计数的用例：离线门禁（node core/validate-all.js，exit_code: 0，cases: 110）、端到端冒烟测试（node tests/smoke-e2e.js，exit_code: 0，cases: 6，一个绿色夹具达到 CONFIRM，一个损坏的夹具达到 REVISE 并引用真实的退出代码），以及驱动和通用性套件。已安装的插件副本在原地通过了相同的门禁。
- 所有五位验证者都用他们自己的判别命令独立复现了那一个阻塞性异议（exit_code: 1）：文档声称任何被拒绝的 spawn 都会使判定为 INCONCLUSIVE，而代码只对整组静默和封印强制执行这一点——其他地方的局部失败只是一个警告，套件甚至将矛盾的行为固定为绿色。
- 一位批评者因协议引以为豪的原因而失败：其答案缺少必需的 schema 字段，save 拒绝了它，运行记录了一个失败的代理，而不是读取一个格式错误的答案。

修复（收窄文档中的两句话，加固汇总以应对枚举外的结果和非整数计数，使门禁的临时目录按进程唯一，并用新的计数检查固定真实的局部失败语义）将门禁从 110 个绿色检查提升到 114 个。判定从未被编辑：REVISE 是代码计算出的结果，而修正是在它之后才出现的。

它存在的意义

一个能力强的代理审查一个变更，并写下一段自信、论证充分的文字。它往往是对的——但它仍然不是证据，因为你无法重新计算它。三个
失败模式不断出现，而且没有一个是愚蠢的错误：

| 失败模式 | 表现 | 为什么没有任何东西能抓住它 |
|---|---|---|
| 空绿 | 命令退出码为 0，但实际上什么都没测试（unittest discover 不带 -s tests 会找到零个测试，仍然退出 0） | 退出码确实是零；只有用例计数才能揭示真相 |
| 证据缺失 | 审查者静默跳过了被要求检查的某一项 | 没有任何东西将要求的内容与回答的内容进行对比 |
| 沉默即同意 | 一个子代理崩溃了；摘要读起来却像一切都通过了 | 死掉的代理不会提出异议，而没有异议被解读为同意 |

FormalSwarm 的存在就是为了让这三种状态在机制上可见，并让裁决成为一次计算，而不是一次判断。

为什么不直接让另一个代理来审查它？

因为那样你只会得到第二段自信满满的文字。区别不在于模型——而在于什么算作证据：

| | 审查者（人类或模型） | FormalSwarm |
|---|---|---|
| “它能工作”的证据 | 散文 | 真实的退出码和计数的用例 |
| 对抗性压力 | 取决于审查者 | 分区的批评者，按契约追猎幻觉 |
| 一个什么都没测试的检查 | 不可见 | cases: 0 → INCONCLUSIVE——空绿是一种裁决，而不是通过 |
| 一个死掉的子代理 | 不可见，或者更糟 | fallen_agents 和警告——沉默永远不是一票 |
| 最终答案 | 一个你反复阅读的意见 | outcome.json——任何人都可以重新运行的计算 |

这个想法，以及它的来源

2026 年 9 月，OpenAI 报告了一次数学运行，其中大约 10,000 个代理在 88 小时内交换了数百万条消息，攻击 Navier–Stokes 千禧年问题，并以 Lean 中的形式化验证作为对集群所产出内容的封印——当时由
WION 报道。

有趣的部分不是那个数字。而是两部分结构：

1. 大规模、独立、并行的探索——许多尝试，没有共享上下文，没有群体思维。
2. 一个机器检查的预言机，它不在乎任何人听起来有多自信。

这种结构不需要千禧年问题。你的代码仓库已经拥有预言机：它的测试套件、它的 linter、它的测量脚本。FormalSwarm 辩论的封印不是 Lean——而是你的命令，带着它们真实的退出码和真实的用例计数，以及一个失败即关闭的汇总。

这不是什么。 它不是对那个结果的复现；而是把那种模式应用到普通软件工作上。而且再多的代理也不能让一个不可测量的主张变得可测量：FormalSwarm 不会让代理更聪明，它让它们的输出可审计，并且当仓库无法裁决问题时，它会欣然告诉你 INCONCLUSIVE。

工作原理

THESIS            ANTITHESIS           [SYNTHESIS]        SEAL
n writers   ──▶   m critics      ──▶   only the      ──▶  k verifiers run the
in parallel       each with a          attacked            checks for real:
(isolated)        disjoint slice       writers answer      command, exit code,
of the theses        their objections    case count, output
│                                        │
└──────── deterministic rollup ──────────┘
CONFIRM / REVISE / INCONCLUSIVE

| 阶段 | 参与者 | 必须产出 |
|---|---|---|
| THESIS | n_thesis 个写作者，相互隔离的子代理 | 一个立场、带有 path:line 证据的发现、其风险，以及能够证明它的度量 |
| ANTITHESIS | n_critics 个批评者，每人拿到一份互不相交的论题分区 | 带有重新阅读证据的反对意见：hallucination、dead_control、dead_guard、logic_bug、bad_measurement、empty_green、safety、other |
| SYNTHESIS | 仅限实际被攻击的写作者（rounds ≥ 2） | 逐字复制反对意见证据字符串的答复，使接受/拒绝计数是确定性的 |
| ANTITHESIS-2 | n_critics 个批评者，针对修订后的状态，并使用确定性看板（rounds = 3） | 真正新的反对意见；已被接受的反对意见会被吸收 |
| SEAL | n_seals 个验证者，每人拿到你的 seal_plan 中互不相交的一部分 | command、outcome、exit_code、cases、detail —— 以及每项检查的度量限制 |

编排器从不投票。它开启轮次、执行子代理，并读取由主体计算出的裁决。

规模：6 个代理还是 600 个

默认计划是一个 2+2+2 试点 —— 六次代理调用，适合首次运行或新类型任务。
扩大规模只是一个标志，而不是重新设计：

a wide exploration: 60 writers, 40 critics, 40 verifiers, one round
formalswarm brief ... --thesis 60 --critics 40 --seals 40 --max-calls 200

the full cycle: thesis → antithesis → synthesis → antithesis-2 → synthesis-2 → seal
formalswarm brief ... --thesis 20 --critics 10 --seals 10 --rounds 3 --max-calls 120

组大小从 1 到 500；没有策略上限。唯一的上限是你自己声明的：

| 标志 | 含义 |
|---|---|
| --thesis N / --critics N / --seals N | 每个组的大小（默认 2、2、2） |
| --max-calls N | 整个运行的预算（默认 15）—— 如果计划会超出预算，则在第一次调用之前就被拒绝 |
| --rounds 1\|2\|3 | 1 = thesis + antithesis + seal；2 = + synthesis；3 = + 第二轮 antithesis 和 synthesis |

最坏情况 = thesis + critics + seals + (rounds≥2 ? thesis : 0) + (rounds≥3 ? critics + thesis : 0)。
实际成本通常更低：synthesis 只对实际被攻击的写作者运行，
空闲的批评者永远不会被生成。

有两件事能让大规模运行保持诚实，而不仅仅是规模大：
- 分区随评审员数量伸缩。 写作者以轮询方式分配给各评审员，因此每位评审员只审阅一个切片，而不是全部内容。当某位评审员的切片变得难以阅读时，brief 会发出警告（raise --critics）。
- 密封简报保持有界。 每一个阻塞性异议都必定送达验证者；冗长的论文文本和拥挤的账本会被裁剪并给出明确警告，而完整材料始终保存在暂存文件和 outcome.json 中。

运行时是并发性的最终仲裁者：DeepSeek Harness、Claude Code 和 ZCode 各自限制同时运行的子代理数量。运行时拒绝的生成会被记录为坠落代理并发出警告——绝不会静默通过。当该组没有任何代理应答时，该阶段终止，裁决变为 INCONCLUSIVE；任何坠落的密封验证者自身即为 INCONCLUSIVE；在其他情况下，部分坠落会被记录并警告，同时辩论继续进行。

为什么你可以信任该裁决

汇总逻辑是正文中的代码，在三个运行时上完全一致。它以失败关闭方式运行：

| 情况 | 朴素摘要会说什么 | FormalSwarm 返回什么 |
|---|---|---|
| outcome: "ok" 但 exit_code: -1（从未运行） | “绿色” | INCONCLUSIVE——未运行的检查不等于通过的检查 |
| outcome: "ok" 且 cases: 0 | “绿色” | INCONCLUSIVE——空绿色 |
| cases: -1（工具什么都没数到） | “绿色” | INCONCLUSIVE——该绿色无法验证 |
| 在不同命令下检查的数量正确 | “绿色” | INCONCLUSIVE——覆盖率按命令身份匹配，而非计数 |
| 检查的 command 为空 | “绿色” | INCONCLUSIVE——未指明命令的检查无法复现 |
| thesis 或 revised_thesis 为空 | “一篇论文” | 写作者计为坠落；先前状态保持不变 |
| 验证者坠落，或密封为空 | “绿色” | INCONCLUSIVE——沉默不是投票 |
| 整个反题阶段未能应答 | “没有异议，发布吧” | INCONCLUSIVE——死掉的阶段不是投票 |
| 验证者声称 CONFIRM，但其检查并不支持 | “已确认” | 更正为 REVISE/INCONCLUSIVE，记录为 coherence: corrected_by_the_body |
| 验证者以薄弱检查宣布 REVISE | “缺少数据” | 保留 REVISE——失败的证词绝不被软化 |
| 某项检查确实失败 | “大体没问题” | REVISE，引用该命令和退出码 |
| 评审员评判了其分区之外的论文 | 不可见 | 标记为 out_of_partition，正确路由，并发出警告 |
| 没有证据的异议 | 一项发现 | 标记为 unsubstantiated 并发出警告——没有证据的异议本身就是一种幻觉 |

此外：预算会被拒绝而非超支；结果文件夹以密码学方式绑定到产生它的简报——并且该绑定以失败关闭，因此不可读的签名会停止运行，而不是让一场辩论吞掉另一场的结果；
标签和阶段被限制在安全字母表内，因此任何产物都无法写入结果文件夹之外；并且只有编排器会话可以接触生产环境，且仅在 CONFIRM 时。

适用于任何仓库

FormalSwarm 对你的语言、框架或领域一无所知。它会分析所指向的仓库：

| 技术栈 | 标记 | 它找到的测试命令 |
|---|---|---|
| Python | pyproject.toml、setup.py、requirements.txt、…… | python3 -m pytest -q，否则 python3 -m unittest discover -s tests -v |
| Node | package.json | 通过检测到的包管理器执行的 test 脚本，否则 npx vitest run / npx jest / npx mocha |
| Rust / Go | Cargo.toml / go.mod | cargo test / go test ./... |
| Java | pom.xml / build.gradle | mvn -q test / ./gradlew test |
| Ruby / PHP | Gemfile / composer.json | bundle exec rspec / composer test |
| 其他任何情况 | 带有 test: 目标的 Makefile，或有界内容探测 | make test，或从源文件推断出的技术栈 |

这些命令遵循检查实际运行的平台：POSIX 上使用 python3，Windows 上使用 python；分别使用 ./gradlew 和 gradlew.bat。Monorepo 会记录每一个技术栈。当没有可检测的运行器时，配置文件会说明这一点并返回 null——这是辩论所使用的事实，而绝非猜测的命令。每个字段都可以在每次启动时覆盖（--set test_command="..."），未知的键会被拒绝，而不是被静默忽略。

安装

DeepSeek Harness

dsh plugin --profile  add /path/to/FormalSwarm
or from git:
dsh plugin --profile  add github:fashionmascherine-svg/formalswarm

重启该配置文件。该 bundle 会插入一行，将协议注册为运行时技能，并且可以在任何后续补丁层中按 id 禁用：

- id: formalswarm-skills
disabled: true

Claude Code

claude plugin marketplace add fashionmascherine-svg/formalswarm
claude plugin install formalswarm@formalswarm

此仓库本身就是一个市场（.claude-plugin/marketplace.json）。

ZCode

设置 → 插件管理 → 发现 → 添加
https://github.com/fashionmascherine-svg/formalswarm → 安装 FormalSwarm →
启动新会话。ZCode 使用相同的
.claude-plugin/ 清单、相同的 SKILL.md bundle 和相同的斜杠命令。

使用

| 命令 | 用途 |
|---|---|
| formalswarm init [--gitignore] | 检测并存储 .formalswarm/profile.json |
| formalswarm status | 显示生效的配置文件及其来源 |
| formalswarm brief --objective … --verdict-question … --context a,b,c --seal "cmd" | 构建完整的简报 |
| formalswarm validate | 运行每一个离线套件：零代理调用，必须在启动前通过 |
| formalswarm body / formalswarm meta | DeepSeek Harness workflow 工具的 script 和 meta 参数 |
| formalswarm prompt --role seal | 一个角色提示词，其中配置文件已被替换 |
| formalswarm run  | 通过驱动器执行一轮（退出码 2 = 待定，0 = 完成） |
| formalswarm save / formalswarm fall | 存储子代理的回答，或声明其已失败 |

在 DeepSeek Harness 上，harness 原生运行整个辩论：用 body + meta + brief 调用 workflow
工具。在 Claude Code 和 ZCode 上，同一个 body
通过轮次驱动器运行，一次一个阶段，每个子代理都从驱动器写入的
提示词文件生成。斜杠命令 /formalswarm-init、/formalswarm-debate、
/formalswarm-validate 和 /formalswarm-verdict 封装了同一流程。

它不做什么

- 它不裁决无法衡量的问题。 如果代码库或文档文件夹
无法回答某个主张，该主张就仍未得到证实：报告缺失的证据以及
什么能解决它。在封条完整且没有失败或声明的 REVISE 的情况下，
缺失或空白的证据会使裁决为 INCONCLUSIVE。失败的检查或
验证者声明的 REVISE 优先于该缺失证据。
- 它不会凭一项狭窄的检查就认证整个策略。 有效的预算并不等于
已验证的漏斗。建议可能有用，但其预期影响
仍是一个假设。不暗示任何内置的活动访问、自动支出或专家
有效性分析器。
- 它不会让代理变得正确。 幻觉出的 path:line 正是
批评者小组存在的目的，而每一个批评者的反对意见都必须带有重读证据。
- 它不替代你的 CI。 封条运行你指定的命令；如果某项检查
不在 seal_plan 中，辩论不会凭空发明它。
- 它不会针对共享服务并发运行命令，并且子代理
被限制在暂存目录中。

验证此仓库

node core/validate-all.js      # every suite, zero agent calls, ~4s
node core/validate-all.js --only body
npm run test:e2e               # a real repository, a real toolchain, real exit codes

这些测试套件固定了故障关闭式汇总（空绿、未运行哨兵、覆盖率、死
阶段、失败标签）、harness 运行与
驱动器运行之间轮次循环的一致性、跨九种技术栈以及 monorepo 和无清单树的 profiler、
规模防护，以及当领域词或机器路径一旦
进入已发布文件时就会失败的通用性防护。

npm run test:e2e 是集成证明：它构建一个真实的临时项目，对其
进行 profile，通过 CLI 驱动整个轮次循环，真实执行封条，并断言
一个绿色仓库达到 CONFIRM，而一个损坏的仓库达到 REVISE 并引用
真实的退出码。

布局

core/
profile.js             repository detection, profile load/save/merge
brief.js               brief builder, prompt substitution, budget and scale advice
debate.workflow.js     主体：阶段 + 确定性汇总（单一事实来源）
driver.js              在没有工作流工具的运行时上运行同一主体
bin/formalswarm.js     三个运行时共享的 CLI
validate-*.js          离线测试套件：主体、驱动器、配置、通用性
prompts/                 编排者、正题、反题、封缄角色提示词
skills/formalswarm/      运行时技能 + 参考资料（协议、配置、运行时）
commands/                斜杠命令（init、debate、validate、verdict）
lib/skills.mjs           在 DeepSeek Harness 上注册该技能的 Cordis 行
.claude-plugin/          插件 + 市场清单（Claude Code 和 ZCode）
cordis.patch.yml         DeepSeek Harness 捆绑补丁
.github/workflows/ci.yml 离线门禁、打包产物、捆绑补丁
tests/                   测试夹具和端到端冒烟测试
docs/                    封面图和图标

一场早于本插件、针对特定仓库的历史辩论保留在作者磁盘上，并有意不予发布——它引用了
一个私有检出。.gitignore 中的一行将其排除；插件发布的所有内容均已提交。

许可证

MIT —— 见 LICENSE。如果这里的某场辩论让你免于发布一段自信满满的文字，
本仓库会很乐意收获一颗星。欢迎贡献和反例：
你能打开的最有用的
issue 是一个
让汇总返回错误裁决的 seal_plan。