@adlc/spec-lint

中文文档
1.12.0发布于 2026/10/10MITES Module构建来源已验证近 30 天下载 8172

审计缺乏具体核查方法的接受标准(C1/P1).

中文使用文档
文档目录10 节
  1. 使用量
  2. 旗帜
  3. 退出代码
  4. 核查方法是什么?
  5. 在找到标准的地方
  6. LLM 降级(--llm)
  7. JSON 输出
  8. 示例
  9. 与兄弟姐妹工具的关系
  10. 核心差距

光谱点

ADLC相: C1 (P1门)

审计缺乏具体核查方法的接受标准. 每个接受标准必须注明将如何检查它——一个测试文件,一个测试文件 命令,其输出被断言,明确 verify: 标签,一个 assert 声明,或 exit code 参考文献。 没有一条标准 愿望。 。 。 . 希望在2号出口被标记 屏蔽CI,直到锁定目标.

使用量

spec-lint <spec.md> [--llm] [--json] [--prompt-only] [--record --ticket <id>]

旗帜

旗帜说明
--llm运行廉价的LLM通过VERIFIED标准来捕捉空闲方法("工作正确","运行测试"). 降职标准成为WISH. 需要一个提供者env var(见核心).
--jsonEmit机器可读JSON(用于管弦乐手). 所有其他输出都被压制.
--prompt-only打印准确的 LLM 提示并退出 0 。 使用零 API 键工作——将粘贴入任意的吊带.
--record在经过的跑道,记录 spec-lint 进入 .adlc/manifest.jsonl 通过 gate-manifest,散开 <spec.md> 进入它。 要求数 --ticket ——无约束记录可以满足另一张票的P1门. 从不记录一个失败的(包含WISH)运行.
--ticket <id>将记录条目绑定在(需要使用) --record) (中文(简体) ).

退出代码

代码含义
0出入口——每个验收标准都称核查方法.
1操作错误——文件缺失,无法读取,或LLM呼叫失败.
2门失败——一个或多个标准是愿望(行号被打印出),或者光谱表示根本没有接受标准.

核查方法是什么?

一个标准是 已证实 如果其案文包含下列内容之一:

  • 类似命令或断言的反向跨度: `npm test`, (中文(简体) ), `curl -s ... | jq .`, (中文(简体) ), `stripe-test --card=valid`,或者一个赤裸的跨度 紧接前的用词像 "验证通过"/"跑". 赤裸的反链条跨度, 没有类似命令的内容( 如文件名) 顺便提到, `vitest.config.ts`)为 没有 仅此而已.
  • 路径匹配 *.test.<ext> 或者说 *.spec.<ext>数字 : auth.spec.ts
  • verify: 或者说 verified by 随后是文本
  • test: 随后是文本
  • 短语 exit code
  • 词 assert

其它的都是个 冰岛。 。 。 .

在找到标准的地方

标准摘自:

  1. 清单项目 (单位:千美元)-, (中文(简体) ), *, (中文(简体) ), 1., (中文(简体) ), - [ ], (中文(简体) ), - [x]在任意标题下匹配 /acceptance|criteria|requirements|definition of done|success/i - 这包括文字 标记下行向 (## Acceptance Criteria)或只用粗体的伪头条 (单位:千美元)**Acceptance criteria**:) (中文(简体) ). 列表项所包裹的续行(缩进,非横行, 新的列表标记/标题)被加入同一逻辑标准之前 分类,匹配标记下渲染器处理单一列表项目的方式.
  2. 独立行 从开始 MUST 或者说 SHOULD (任何地方在文件中)

LLM 降级(--llm)

甚至严格标准也可能是空洞的。 "运行测试和验证 它的工作正确" 包含回击命令,但不会传达任何可检查的命令。 这个 --llm 旗帜发送 验证标准,要求它找出空虚的方法 返回 a { vacuous: [indices], reason: {...} } JSON对象. 含糊不清的标准 降为WISH.

使用 --prompt-only 在不拨打任何 API 电话的情况下获得精确的提示 用于测试、审计或粘入不同的模型.

JSON 输出

{
  "file": "spec.md",
  "total": 5,
  "verified": 3,
  "wishes": 2,
  "criteria": [
    { "line": 8, "status": "VERIFIED", "text": "...", "reason": "..." },
    { "line": 9, "status": "WISH",     "text": "...", "reason": "no verification method found" }
  ]
}

示例

# Run gate — exit 2 if any wishes
spec-lint docs/spec.md

# Machine-readable for CI
spec-lint docs/spec.md --json

# Inspect LLM prompt without API key
spec-lint docs/spec.md --prompt-only

# Full LLM-backed demotion pass
ANTHROPIC_API_KEY=sk-... spec-lint docs/spec.md --llm

与兄弟姐妹工具的关系

  • C2 尸检前 ——通过分镜后,用一分镜对核定分镜进行压力测试 前沿模型(死后框架).
  • C3 冷启动 – 平板空隙分析; spec-lint 门 spec, cold start 门个人票.
  • C11 门外 - 货单上应附上货谱显示的结果 门开后分类账.

核心差距

无。 所有需要的功能(complete, (中文(简体) ), extractJson, (中文(简体) ), parseArgs, (中文(简体) ), pass, (中文(简体) ), gateFail, (中文(简体) ), opError, (中文(简体) ), printJson, (中文(简体) ), promptOnly)在核心中存在.

版本与发布记录

@adlc/spec-lint 共发布 18 个版本,首次发布于 2026/06/14;过去 12 个月发布了 18 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
1.12.0latest2026/10/1027 天前
1.11.12026/09/091 个月前
1.11.02026/08/252 个月前
1.10.02026/08/112 个月前
1.9.02026/08/092 个月前
1.8.02026/08/082 个月前

关于 @adlc/spec-lint 的常见问题

@adlc/spec-lint 是什么?

审计缺乏具体核查方法的接受标准(C1/P1).

如何安装 @adlc/spec-lint?

在项目目录运行 npm install @adlc/spec-lint,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 spec-lint,可以用 npx spec-lint 直接运行。

@adlc/spec-lint 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/adlc__spec-lint 是否存在。

@adlc/spec-lint 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@adlc/spec-lint 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=18。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@adlc/spec-lint 可以商用吗?

@adlc/spec-lint 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@adlc/spec-lint 的下载量有多少?

根据 npm 官方下载统计,@adlc/spec-lint 在 2026/10/05 – 2026/11/03 这 30 天内被下载 8,172 次,日均约 272 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@adlc/spec-lint 还在维护吗?

最新版本 1.12.0 发布于 2026/10/10(27 天前);至今共发布 18 个版本,其中过去 12 个月发布了 18 个;首次发布于 2026/06/14。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。