Community编程与开发github.com

AssertLedger 回归测试验证

验证回归测试是否能检测到已声明的缺陷,或重放 AssertLedger 证据。当需要验证测试是否检测到错误时使用此技能,即使未明确提及 AssertLedger。

AssertLedger 回归测试验证 是什么?

AssertLedger 是一项用于严格验证回归测试的技能,旨在通过对比相同候选测试在修正后代码、已知缺陷代码和中性对照代码上的表现,提供有界限的判定结果。该技能特别适用于需要确认某个测试用例是否真正能够捕获特定缺陷的场景,而非常规 TDD、覆盖率检查或通用代码审查。它支持 Git 版本库中的回归验证,要求测试文件使用无依赖的 `.js`、`.mjs` 或 `.cjs` 格式,并基于 Node 的 `node:test` 框架。执行后端可以是容器(需要指定镜像摘要)或受信任的本地执行(需明确授权)。技能会生成包含 manifest.json 的证据目录,并通过重放验证决策的一致性和完整性。使用者必须提供缺陷、修正和中性版本的提交标识以及中性原因的说明,不允许凭空构造任何语义或结果。技能同样支持 Bun 1.4.2 环境下的回归验证,但原生 Bun `expect` 的失败不计为目标检测。该技能主要用于请求的工作流补充,不替代已有的原生测试和 CI 体系,也不授予合并权限。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/SebastienElet/agent-skills/tree/HEAD/skills/assertledger

Installed? Explore more 编程与开发 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

AssertLedger

概述

评估相同的回归候选测试在修正后的代码、已声明缺陷和中性对照上的表现。保留观察结果并在报告有界限的判定前重放生成的清单。操作者提供缺陷和对照的含义;工具不建立整体程序的正确性、产物的真实性或长期无片状测试的保证。

此本地维护的工作流遵循已发布的 AssertLedger 1.4.0 文档。

用法

使用 $assertledger <仓库和回归> 或 /assertledger <要重放的清单>。 例如:"检查已提交的奇偶校验回归是否检测到了所提供的错误修订版本。" 对于普通实现使用 tdd,当验证机制本身发生变化时使用 proof-integrity-review。AssertLedger 验证是额外请求的工作流,不是无条件的测试关卡。

通过宿主声明的工具安装获取兼容的 CLI;技能本身在运行时不需要检出 dotfiles。如果 CLI 缺失,则应报告该先决条件,而不是隐式安装包或修改项目配置。

步骤

  1. 运行 assertledger --version 和 assertledger doctor /path/to/repository --json。此诊断是静态且只读的。在执行计划前检查冲突和框架支持;检测到测试命令并不表示适配器能够运行它。

  2. 对于 Git 验证,确定有缺陷的、修正的和中性的已提交修订版本、中性原因、候选路径、不变的基测试路径,以及相对于仓库的新输出目录。尽可能使用提供的事实;切勿凭空构造缺失的控制语义。参考 Git 指南 了解资格要求:无依赖的 .js、.mjs 或 .cjs 文件,使用 node:test,基测试不变,除候选外文件路径集相同。本地未提交的更改将被忽略。

  3. 根据操作者的授权确定执行后端。容器运行需要操作者选择由摘要固定的镜像,该镜像必须已存在于 Linux 守护进程中并包含 Node。受信任的本地执行是 UNSANDBOXED 状态,并且需要授权该作用域。切勿混合两种模式,也不得从安装或项目配置推断执行权限。

  4. 使用实际确定的输入运行所选命令。对于授权的容器运行:

    assertledger check /path/to/repository --before BEFORE --after AFTER --neutral NEUTRAL --neutral-reason "已建立的控制理由" --test tests/regression.test.js --base-test tests/base.test.js --out .assertledger/evidence-001 --container-image node@sha256:DIGEST --json
    

    对于授权的受信任本地执行,将 --container-image node@sha256:DIGEST 替换为 --allow-unsafe-execution。在确定后端之前,不要传递这两个标志中的任何一个。

  5. 保留命令的退出状态、摘要、执行的请求和清单。完整的输出目录包含最后发布的 manifest.json。运行 assertledger replay /path/to/repository/.assertledger/evidence-001/manifest.json --json。积极的证据要求 decision.status: VERIFIED 且重放 valid: true;保留所有失败的尝试、对照、原因代码、执行限制和隔离事实。拒绝、不确定的观察、操作错误或无效的重放不能支持接受。

  6. 报告确切的缺陷、修订版本、选定的候选、环境、工件位置和限制。使用 assertledger explain CODE --json 了解拒绝原因。重放检查完整性和决策一致性,但不重新运行测试或验证其生产者。当需要复现或独立审计时,应另行保留源修订版本、请求和原始日志。

  7. 对于已提供的版本化请求或受支持的 Bun 活动,在使用 verify 或重放之前,请阅读相应的参考文档。Bun 适配器固定使用 Bun 1.4.2,并将来自 assertledger/bun 的 assertSame 失败计为目标检测;原生 Bun expect 失败不计为目标检测。此较低级别的路径不会扩展 Git check 命令的资格。

注意事项

  • 将 Git 验证应用于 TypeScript/Bun 或 Rust——静态检测可能看起来很有希望,但 check 无法执行候选测试;保留现有的原生测试并报告限制。
  • 忽略仓库符号链接拒绝——删除链接或编造排除项会改变已声明的证据;保留检出并报告 UNSUPPORTED_REPOSITORY_SYMLINK。只有操作者在检查文档规则后才能声明仅本地的排除项。
  • 重用证据目录——输出保留失败而不是覆盖先前的活动;选择一个新的相对路径并保留先前的证据。
  • 将崩溃计为检测——超时、编译、发现和进程失败不能建立声称的回归;检查原因代码并解决执行问题。
  • 自动运行客户端设置——connect --write 会安装项目技能和 MCP 配置,创建此用户技能的另一个发现副本;仅在请求的客户端设置上预览,并在任何写入之前解决该重复问题。

约束

  • 切勿制造缺陷语义、中性理由、观察结果或执行授权。
  • 切勿隐式初始化项目、注册 MCP 服务器、拉取镜像或更改排除项。
  • 切勿通过猜测的适配器执行不受支持的运行器,或削弱策略以获得接受。
  • 切勿将重放有效性视为实际执行、真实性或一般正确性的证明。
  • 切勿丢弃失败的观察结果、隐藏不完整的输出或将演示视为仓库证据。
  • 保留原生测试和 CI 要求;此技能既不替换它们也不授权合并。

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

相关技能