默认模式与 strict 权限不同
默认高精度凭据规则是确定性的，语义 secret_shaped 只在 --strict 参与阻断；普通警告模式不能宣称全面安全门禁。
查看对应来源 ↗代码仓库分析
jev-commit
commit-msg 钩子：一次 Jev 请求对照暂存 diff 给提交说明打五个 Noul，默认只警告。默认拦住提交的是本地正则腰带对新增行的高置信命中；secret_shaped Noul 只在 --strict 时参与拦截。
E2 · 资料已核对已检查公开资料或源码证据；仅有固定提交链接并经对应源码核对，才可称固定版本核验。不代表本站运行过、认可性能或保证安全。
- Stars
- 11
- Forks
- 0
- 协议
- MIT
- 最近提交
- 2026-09-19
Jev 在这里做什么
一次请求里五个 Noul：说明是否可核对、是否与 hunk 相符、是否留下调试代码、是否有未提及改动、新增行是否像密钥。默认拦截来自正则腰带；secret_shaped 只在 --strict 下参与拦截。
把提交说明核对做成可设阈值的概率，而不是再读一段模型评语；接口失败时仍放行提交。
2026-10-24 核对固定版本的说明与实现材料。本站未安装 hook 或尝试提交。作者误报标签和耗时记录未独立复现。
这个项目适合解决什么任务？
检查提交信息与暂存改动是否一致，同时不把语义建议默认变成提交禁令。
资料分析日期：
从输入到动作
- 代码收集提交信息和有预算的暂存 diff。
- 五个 Noul 检查信息质量、改动一致、调试残留、未提及工作及秘密形态新增行。
- 本地正则与可选 --strict 决定阻断，API 失败允许提交。
实现中值得检查的地方
deadline 约束整个请求
jev.py 读取响应块时核对单调时钟截止点，处理 socket 超时与总墙钟预算的区别。
查看对应来源 ↗选择建议
适合辅助 commit-msg hook。尤其考虑 --no-verify 等绕过路径，应结合确定性秘密扫描及服务端检查。
如何自行检查
联读 README 退出码/默认模式与 jev.py 的 _read_by/ask，比较普通、--strict、缺密钥行为，确认慢速流式响应也受总截止时间约束。
结论的适用边界
- 本站未安装 hook 或尝试提交。
- 作者误报标签和耗时记录未独立复现。