Spec Driven Development
von formulahendry
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Läuft auf deinem Computer★ 440MITAktualisiert vor 14 Monaten
Installieren
Signoff
Überblick
Beschreibung vom Entwickler (englisches Original)
Five gates that make an agent's 'done' provable: run them, read the verdict, audit the record.
Die drei Säulen von PopNx MCP
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
- Stimmen der NutzeriNoch keine BewertungenBewertungen starten in einem späteren Schritt zusammen mit Benutzerkonten
- Unsere Basischecksi1 von 1 bestandenAnhand öffentlicher Informationen geprüft; Code noch nicht gescannt
- NutzungiNoch nicht gemessen★ –
Was du damit machen kannst
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
- Verbindung: Läuft auf deinem Computer
- Transport: stdio
- Kategorie: Sonstiges
Installation
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Bevor du installierst
- Basischecks: 1 von 1 bestanden
- Läuft auf deinem Computer mit den Rechten deines Benutzerkontos (Dateien, Netzwerk, Apps).
- Die Registry nennt keinen Schlüssel zum Eintragen.
Du brauchst
- npmNode.js installiert (für den Befehl npx)
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"signoff": {
"command": "npx",
"args": [
"-y",
"signoff-cli",
"mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add signoff -- npx -y signoff-cli mcpOder kopier die Einstellungen selbst
In .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"signoff": {
"command": "npx",
"args": [
"-y",
"signoff-cli",
"mcp"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Oder kopier die Einstellungen selbst
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"signoff": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"signoff-cli",
"mcp"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Was er kann
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Basischecksi
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 8. Nov. 2026
- ✓ Bestanden
Entwickler passt zum Repo
Der Registry-Name wurde mit dem GitHub-Konto ayuanxx-max bestätigt, dem das Repo gehört
- … Noch nicht geprüft
Wird noch gepflegt
Dieses Repo haben wir noch nicht von GitHub gelesen
- … Noch nicht geprüft
Hat eine Lizenz
Dieses Repo haben wir noch nicht von GitHub gelesen
- – Nicht zutreffend
Endpunkt antwortet
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
- – Nicht zutreffend
Anmeldung mit OAuth
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
- … Noch nicht geprüft
Keine versteckten Anweisungen in Tool-Beschreibungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Im Vergleich mit anderen in Sonstigesi
- Mehr Sterne als 0 % der anderen 18431 Server in dieser Kategorie
- Neuer in der Registry veröffentlicht als 98 % der anderen 18431 Server in dieser Kategorie
- Basischecks gleich gut wie oder besser als bei 100 % der anderen 18431 Server in dieser Kategorie
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Häufige Fragen
Ist Signoff sicher?
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Welche Schlüssel oder Codes braucht er?
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Läuft er auf meinem Computer oder in der Cloud?
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Wird er noch gepflegt?
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (4.0.2) kam heute in die Registry.
Welche Apps können ihn nutzen?
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Node.js auf deinem Computer.
Was kann ich stattdessen nutzen?
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Filesystem MCP
Alternativen
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
Remote Desktop Commander
von desktop-commander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Läuft in der Cloud★ 211Aktualisiert vor 3 Tagen
Installieren
Filesystem MCP
von j0hanz
Filesystem MCP server for AI assistants.
Läuft auf deinem ComputerAktualisiert heute
Installieren
README vom Entwickler
README öffnen
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
落印 / SignOff
包名 4.0.0 起为 `signoff-cli`（曾用名
dsh-signoff，旧包已标记 deprecated）。
命令仍是
signoff；仓库地址仍是ayuanxx-max/signoff-cli。DSH 只是它最早的使用场景，
任意 git 仓库、任意语言都可以直接用。
中文名「落印」：印落纸面才算数，对应英文名 SignOff。曾用名「一诺过五关」「执印」。命令是
signoff；
包名 4.0.0 起为
signoff-cli，仓库 4.1.0 起为ayuanxx-max/signoff-cli（由dsh-signoff改名，老地址 301）。
签下的那句“做完了”，得自己走过五道关才算数。
五道关卡，五条命令，退出码即判决；发版另加第六道 signoff release（见文末）。每一关都对应 agent 交付时的一种失败方式：靠记忆跑测试、把“有开发页”当验证、多个 agent 撞同一文件、危险动作做过就忘、文档里塞空话。SignOff 把这五种失败变成五个可执行的检查。
npm i -g signoff-cli # 或 npx signoff-clisignoff p1 # 一关一关过 signoff all # p1 + p2 + p5 + p4 verify
| 关 | 命令 | 判决什么 | |||
|---|---|---|---|---|---|
| P1 验证 | signoff p1 | 检查是否真的跑过、跑在预算内、用例数多少 | |||
| P2 覆盖 | signoff p2 | 验证到了哪一级：scenario / harness / smoke / missing | |||
| P3 队列 | `signoff p3 validate\ | plan\ | collect` | 卡片是否齐、并发是否撞、谁越界谁没交 | |
| P4 账本 | `signoff p4 ask\ | confirm\ | verify\ | export` | 危险动作有没有票、回滚点是否还在 |
| 自查 | signoff doctor [--json] | 为什么没按预期生效：钩子、PATH、版本、安装点、账本、装钩子之后的缺失提交 | |||
| P5 反空话 | signoff p5 | 文档里有没有空话、绝对化断言、无数字的已验证 |
一张图看懂
六个层次从左到右：入口（CLI / git 钩子 / CI / Agent 面）都走同一个 guard.js；调度决定跑哪几关、 谁算通过；五关每关都写清“读什么、判什么、怎么修”；状态机说明一次提交里 marker 与 trailer 是怎么产生的； 产物是判断留下的证据；最右是外部依赖——只有 Node ≥18 与 git 是硬要求，其余都可缺。 判定没有“部分通过”：退出码 0 通过、1 任一关判红、2 用法或环境错。
上半部分按 0→5 的先后排：前置检查 → 安装 → 初始化 → 日常提交 → 红了怎么办 → 升级与卸载。 红框是必做，黄框是最容易踩的坑（--chain、--lock-test、npm proxy）。 下半部分三块是“不改你的流程、但会改变你看到的现象”：平台差异、环境差异，以及三条红线 （--no-verify、SIGNOFF_SKIP=1、调阈值让红变绿）。
两张图都由 Mermaid 生成，源文件在 docs/diagrams/src/，改文案重渲一次即可， 不用重画。
零接触：装一次，之后不用管
目标是一条命令之后不再需要任何操作：npm i -g signoff-cli 装完即生效，之后每次 git commit 都自动受五关约束。
| 层 | 什么时候发生 | 覆盖范围 |
|---|---|---|
| 机器层 | npm i -g 的 postinstall 写 core.hooksPath → ~/.signoff/hooks | 本机所有仓库，新克隆的也算 |
| 仓库层 | postinstall（在某个仓库里执行时）或 signoff ensure | 该仓库的 .git/hooks、.signoff/config.json、CI workflow、ledger |
| 仓库声明 | 仓库根提交了 signoff.json（signoff init --share 生成） | 任何克隆：机器层见到声明就自动装全五关，克隆方零操作 |
| 关内 | 每次 commit | 已 opt-in 的仓库跑 P1–P5；未 opt-in 的仓库只跑 P1（测试必须过），不写任何状态 |
npm i -g signoff-cli # 一次；postinstall 自动装好机器层 + 当前仓库signoff ensure # 换个仓库想把五关都装上，跑这一条（幂等） signoff ensure --global # 只重装/修复机器层 signoff ensure --json # 给脚本看的结构化结果
npm 11 会把 postinstall 放进 allowlist 提示，可能不执行——所以还有一层兜底：在该仓库里第一次跑任何一关（比如 signoff p5 README.md）会自动把五关装好。 要放行安装脚本就加 npm i -g signoff-cli --allow-scripts=signoff-cli。
行为约定：
- 已 opt-in（有
.signoff/config.json）：pre-commit 跑全套五关，PASS 才写 marker 和 trailer。 - 未 opt-in：只跑 P1（有测试才跑，没测试就明说"没检测到测试运行器"后放行），不写
.signoff配置、不带 trailer。 - 仓库自带的钩子不会被绕过：机器层先执行
.git/hooks/，它若是 signoff 的钩子就直接以它的判决为准。 - 提交
signoff.json等于「这个仓库同意 P1–P5」：.signoff/是 gitignore 的，声明文件进 git， 所以别人克隆下来第一次 commit 就会把 hooks / config / CI 自己补上。字段见docs/signoff.schema.json。 - 临时退出：
SIGNOFF_NO_BOOTSTRAP=1（不做自动安装）、SIGNOFF_NO_MACHINE=1（不跑机器层的轻量关）。 - 撤销机器层：
signoff uninstall --global。
一、案例：本次 DSH 2.0.22-next升级后在修复（dsh-session-fork-tree 0.9.34）bug里，五关各自做了什么？
这次修的是“升级 DSH 后，点侧栏「···」菜单，菜单闪一下就消失”。五关实际起了什么作用，逐条列出，包括没发挥作用的那一关。
| 关 | 本轮实际动作 | 证据 | 判定 |
|---|---|---|---|
| P1 | 手动跑 precommit.ps1；闸门第 10 层 pytest | PASS 3666 ms（101 用例）；第 10 层 3438 ms | 护栏有效；但它只跑工具自身的 Python 用例，抓不到这次的前端问题，也没能自动拦提交（插件目录是独立 git 仓库、没装钩子） |
| P2 | 三套真实 DOM 场景：menu(11) / arrange(13) / perf(6)；并把该包纳入覆盖率账本 | coverage.py：apps 4→5，scenario 5/5，断言 36→77 | 主力。决定“修好没有”的是场景断言，不是肉眼；账本让这些断言不再是一次性证据 |
| P3 | 未使用：没写任务卡，没跑 fanout.py | 无 card.json、无 wave 记录 | 未发挥。三件事有依赖顺序（修→测→说明引用实测数字），但这不等于可以不写卡留痕 |
| P4 | 事后审计抓到我自己填的假回滚点；补录发布记录 | verify 先 FAIL：rollback point 'npm deprecate …' not a git ref；修复后 {"ok": true, "entries": 4, "problems": []} | 事后有效，事前缺位。npm publish、GitHub Release、改 profile 都是先做后记，没走取票 |
| P5 | 三份新文档过 slop 六规则；覆盖率表由工具重生成 | slop {"ok": true, "files": 3, "hits": []} | 有效；但把包登记进覆盖率是发布之后补的，说明里那组断言数当时还没进账本 |
一句话：P2 决定“修好没有”，P5 决定“我有没有说大话”，P1 只证明没弄坏别处，P4 事后抓住了我自己的一笔脏账，P3 全程没上场。 这个结论本身就是 SignOff 想要的输出：每一关都要能回答“发挥了没有”，不能只说“流程走过了”。
你不需要做什么，照常进行任务，由它来守护这个过程；
二、自动守护：装一次，之后不用记
signoff init 把五关接进 git 与 CI，一次安装，之后正常 git commit / git push / 开 PR 都由它先查：
| 安装物 | 作用 |
|---|---|
.git/hooks/pre-commit | 暂存区一变就跑闸门：文档改动 → P5；能探到测试命令 → P1；有 verify/scenarios/ → P2 --strict；有账本 → P4 verify。红了直接拒绝提交 |
.git/hooks/pre-push | push 前跑同一套（--full，不吃缓存） |
.git/hooks/commit-msg | 把 Signoff-Pass: （跳过时 Signoff-Skip:）写进提交信息；signoff audit 与 CI 据此判断这次提交真的过过闸门 |
.github/workflows/signoff.yml | 每个 push / PR 跑 npx signoff-cli guard --ci，绕不过去 |
.signoff/config.json | 测试命令、预算、文档目录；signoff status 随时查看 |
.gitignore | 追加 .signoff/，结果不进版本库 |
只依赖 Node 18+：闸门本身是 Node 实现（lib/p*.js），没有 Python 也能跑完整五关，不存在降级模式。
三条稳定性措施：同一份暂存内容只判一次（命中缓存约 0 ms，反复 git commit --amend 不重复付时间）；失败只打印失败那一关的尾部（完整日志在 .signoff/hook.log）；超预算直接判红（默认 180 秒，--budget 可改）。
绕过的路仍然有，但不再无痕：signoff audit --range origin/main..HEAD 逐个提交核对标记与提交树——缺失就是绕过（git commit --no-verify），判红；SIGNOFF_SKIP=1 的提交写成 Signoff-Skip: 并记进 .signoff/skips.log，--strict 下同样判红。生成的 CI 里已经带这一步。
队友为什么也会被守住：先把 signoff-cli 放进 devDependencies（npm i -D signoff-cli），再 signoff init --prepare，它会把 signoff init --quiet 并进 package.json 的 prepare，队友 npm install 完钩子就有了。没这个依赖时 --prepare 会拒绝写入并提示——否则 npm install 会因为找不到 CLI 直接失败。
signoff init # 装钩子 + CI + 配置signoff init --chain # 已有钩子保留：存为 .local，先跑它 signoff init --prepare # 同时写进 package.json，队友 npm install 即装钩子 signoff status # 这个仓库现在守不守？ signoff doctor # 为什么没按预期生效（只读） signoff doctor --fix # 让它把能证明的修掉：重装缺失钩子、补执行位、清掉没暂存的标记 signoff guard --full # 手动跑同一套（钩子调的就是它） signoff audit --range origin/main..HEAD # 这些提交真过过闸门吗？ signoff audit --since-install # 只看装钩子之后的提交（安装点不在 HEAD 祖先里会直接拒绝） signoff init --reset-install # 历史被改写或换了克隆后，把安装点挪到当前 HEAD signoff init --lock-test # 把识别到的测试命令写进配置，换机器不再漂移 signoff uninstall --all # 卸掉钩子 + CI + 配置 signoff uninstall --keep-config # 卸掉钩子 + CI + 运行时状态，保留配置与账本 signoff p4 export --merge ../other/.signoff/audit.log # 多仓库合并成一张表 signoff p4 export --format json --out ledger.json # 也可以导出 json / csv signoff explain p2 # 这一关到底查什么、怎么判的 signoff secrets # 只扫暂存区的密钥泄露（钩子里自动先跑） signoff secrets --all --json # 全仓库扫一遍，一条 JSON 判决
密钥扫描与提速（3.12.0 起）
- P1 之前先扫密钥：内置 16 条高信号规则（AWS / GitHub / GitLab / OpenAI / Google / Slack / Stripe / npm / SendGrid / 私钥块 / Azure / Discord webhook / 带密码的数据库 URL / 通用凭证）。 命中即失败；装了
gitleaks可用--engine gitleaks换全套规则，没装也不影响（纯 Node，无需二进制）。 - 值不会原样打印：只显示
AKIA…EF这种前缀 + 规则名 + 行号，避免把日志变成二次泄露。放行写在.signoff/config.json的secrets.allow。 - 未 opt-in 的仓库也扫：机器层守护走
--no-state，扫完不留任何文件。 - 运行器探测扩了 9 种：go / cargo / maven / gradle / dotnet / ruby / elixir / php / make（
tests/与package.json仍在最前）。 - 同一暂存树结果缓存：重复跑 0 ms；纯文档提交跳过测试。两个开关都可关：
SIGNOFF_NO_CACHE=1/SIGNOFF_NO_FAST=1。
签名与增量覆盖率（3.13.0 起）
- 提交自带签名：
signoff init --sign生成仓库本地 ed25519 密钥，commit-msg在Signoff-Pass:之外再写Signoff-Key:+Signoff-Sig:（对完整 tree 签名，单行 base64）。没有密钥就只写未签名的Signoff-Pass，不阻塞提交。 - 可以复核：
signoff audit --verify逐个提交验签，--require-signed把未签名也算失败。身份锚点是 仓库里提交的.signoff/allowed_signers（或signoff.json的allowed_signers）：不在名单里只报self-signed，绝不报verified。 - 增量行覆盖率：
signoff cov --diff --min 80只算这次改动新增的行，读项目已有的coverage/lcov.info/coverage-final.json/ pythoncoverage json，不额外装运行器；没有覆盖率文件时报"没测过"，不会假装通过。 - CI 直接标到行：
GITHUB_ACTIONS=true时，密钥/覆盖率发现输出::error file=…,line=…注解并写步骤摘要， PR 页面直接看到，不用翻日志。
可核对的凭证（3.15.0 起）
signoff p4 checkpoint 给账本签一个检查点，signoff p4 anchor 打出一行可以贴到发版说明里的锚点：
signoff1:12:9f2c1ab34d0e:71b0c9d2e4a85f61事后 signoff p4 verify --checkpoint --anchor <那一行> 能分辨四种情况：账本被截断、内容被改、 签名不属于受信 key、锚点与本机不一致。细节与边界（它不证明什么）见 docs/trust.md。
3.15.2 起还补了三件事：signoff p4 path 打印账本与检查点的真实位置（脚本不用猜）； guard 通过后自动续签检查点（同一份账本不重复签，不产生无意义改动）；账本读取容忍 BOM （Windows 编辑器与 Set-Content -Encoding utf8 的常见产物）。
能力矩阵与匿名竞品（3.15.2）
同一张表看"谁有什么"。竞品按类型匿名（不点名，避免把对比写成广告），对应关系与星标/下载数据 记录在 docs/signoff-positioning-3.15.2.md。
| 能力 | 落印 | 竞品A 平台级 | 竞品B 钩子框架 | 竞品C 密钥扫描 | 竞品D 文本规则 | 竞品E 供应链证明 | 竞品F 覆盖率 |
|---|---|---|---|---|---|---|---|
| 测试真的跑过（预算 + 用例数） | 有 | 有 | 无（只负责触发） | 无 | 无 | 无 | 无 |
| 增量覆盖率分级 | 有 | 有 | 无 | 无 | 无 | 无 | 有 |
| 密钥扫描 | 有 | 有 | 无 | 有 | 无 | 无 | 无 |
| 中文文档空话规则 | 有 | 无 | 无 | 无 | 部分（英文词表） | 无 | 无 |
| 可验签的判决（trailer + key） | 有 | 部分（服务端签名） | 无 | 无 | 无 | 有（attestation） | 无 |
| 离线账本 + 截断检测 | 有 | 无 | 无 | 无 | 无 | 部分（需 layout/验证器） | 无 |
| 可发布锚点（一行贴进发版说明） | 有 | 无 | 无 | 无 | 无 | 无 | 无 |
| 零配置两步上手 | 有 | 无（要服务端 + 项目配置） | 部分（需已有 Node/Python 项目） | 有 | 有 | 无（要密钥与 layout） | 有 |
| 托管看板 / PR 状态回写 | 无 | 有 | 无 | 无 | 无 | 无 | 无 |
结论放在表后面而不是前面：前七行是它和其他工具的分野，最后两行是它的短板——托管面没有， 生态采用量也还没起来（1 star、周下载三位数），所以六维里"生态"给 3 分，不是 5 分。
上图是一次提交的完整路径：入口（git commit / 命令 / CI）→ 三层零接触 → guard 固定顺序跑 secrets → p5 → p1 → p2 → p4 → cov（opt-in）→ 判决 → 四层证据（marker → trailer → 账本 → 检查点 → 锚点）。红一关即停，退出码就是判决。
上图横轴是生态采用度，纵轴是覆盖广度。落印落在左上角——功能全、采用低，这是它的真实位置： 它不在右上角跟平台级产品比采用，差异在"判决可以带走、可以事后核对"。
规则包、预设与编辑器（3.14.0 起）
- P5 规则包：
--pack zh|en|both。中文词表是默认值，行为不变；en用词边界匹配 （very不会命中delivery），both两套一起跑并按行去重。--rules rules.json追加自定义词表 （ai_words/absolute/adverbs/claims/placeholder），也可写进.signoff/config.json的p5或signoff.json的p5。 - 场景预设：
signoff init --preset node|python|go|java，一次给出预算、文档目录、覆盖率阈值和规则包；test_cmd仍交给自动探测，克隆到没有该脚本的机器也不会锁死。 - VS Code：
signoff init --editor vscode写.vscode/tasks.json（guard / all / secrets / cov / audit / status） 与 problem matcher，失败直接落到 Problems 面板；已存在的任务只合并不覆盖。
三、在其它代码过程里能干什么
| 场景 | 五关怎么用 |
|---|---|
| 新功能 | P3 先写卡（目标 / scope / 验收 / 回滚）→ P1 让检查命令化并进钩子 → P2 把验收写成场景断言 → P4 发版取票 → P5 文档只留能被数字支撑的句子 |
| 修 bug | P1 把复现命令固化（--run 可重复）→ P2 加一条“反向断言”（旧写法必须红）→ P3 多人并行时按 scope 分波 → P4 单点回滚 → P5 说明里每个数字能落到事实表 |
| 重构 | P3 的 scope 锁死可动范围，collect 抓越界改动；P2 用零写入 / DOM 恒等这类断言证明“行为没变” |
| CI 流水线 | signoff all 一条命令，退出码直接当 CI 判决；P1 的预算参数防止测试变慢却没人发现 |
| 多 agent 并行 | P3 plan 输出 wave（scope 相交的卡绝不同波），collect 抓“改了不该改的文件”和“交了空活”的卡 |
| 交接与复盘 | P2 的覆盖表 + P4 export 出的账本，接手的人先看这两张表，再看代码 |
| 合规留痕 | P4 哈希链：改过的记录会被 verify 判为 content hash mismatch，事后补账能被发现 |
四、在 DSH 任务里能干什么
- 发 npm / 改 profile / 改 cordis 配置：P4 先
ask取票（单次、10 分钟过期、绑定动作类别），再confirm落账，账里带回滚点；回滚点必须是真的 git ref，写一句“npm deprecate …”会被verify拒绝。 - 插件发版：P1 跑三套真实 DOM fixture，P2 把结果记进覆盖率表，P5 保证发布说明里没有
绝对化的收尾句。 - 长任务 / 跨天任务：P3 的卡片就是断点续传的凭据——scope、验收、回滚点三样齐了，换会话也能接上。
- 多分叉并行：不同分叉各拿一张卡，
plan先算出不会撞文件的波次，避免两个 agent 同时改同一处。 - 收尾：P5 的六条规则让“完成”这句话可以被机器反驳：无数字的
已验证、TODO、绝对化断言、AI 味词表（赋能/闭环/抓手…），命中即失败。 - 插件回归：
verify/scenarios/*.json是 P2 的输入格式，把 fixture 的 checks 数量直接变成覆盖率数字，不需要另写报表。
五、命令速查
# 自动守护：装一次，之后不用记signoff init signoff status signoff guard --full signoff uninstall --all
P1：跑检查；默认 tests/ 用 pytest，否则 npm test
signoff p1 --run "pytest -q" --run "npm run lint" --budget 120 signoff p1 --install-hook # 写入 .git/hooks/pre-commit
P2：覆盖分级 + 阈值
signoff p2 --strict --min-scenario 4 --min-assertions 60 --md docs/coverage.md
P3：卡片校验 / 波次规划 / 收集核对
signoff p3 validate --
Nur der Anfang wird gezeigt; den Rest findest du im Repo