dsh-jev-core

dsh-jev-lens 与 dsh-jev-kit 的共享内核：一次抽取，一个地方修。

为什么存在

这两个插件此前各自带着逐字节相同的四份拷贝（545 行，用 diff 验证过）。代价是具体的： 2026-09-23 一天之内就有三处修复落在这些文件里（熔断器的哨兵值、脱敏清单、401/403 的重试区分）， 每一处都得改两遍；而抽取当天，core 自己的测试又抓出一个真缺口—— redact() 不遮私有 IP（10.1.2.3 原样发给了厂商）。修一次，两个插件同时受益。

边界

属于内核：对"判什么"没有意见的代码——HTTP 传输、重试/熔断/并发、判定缓存、服务查找 shim。

不属于内核：问句措辞、阈值、账本、设置。它们故意按插件不同——共享账本 schema 会逼两个工具长成同一个形状。

用法

npm install github:jackchen13755/dsh-jev-core

import { createJev, redact, createCache, createBreaker, createLimiter, percentiles, serviceOf } from '@dsh-external/dsh-jev-core'

脱敏的两条口径（都实测过）

保形状、丢取值：db.acme-corp.internal → ``，10.1.2.3 → 。判定仍知道"这里有内网主机"，而厂商不知道是哪一台。
正因为如此，内网主机名不能只靠模型的 internal 轴：一个裸主机名在语义问句下只拿 0.29， 部分原因是它在模型看到之前就被遮蔽了。形状交给确定性正则层（见 scripts/pre-push 的第一层），模型负责语义（"服务 X 部署在集群 Y" 得 0.88，且不受遮蔽影响）。

维护三个仓库：一条命令

bash scripts/family.sh status   # 三个仓库的版本 / 本地 / 远端 / 是否脏
bash scripts/family.sh test     # 三个仓库各自 build + test（本地 97 项）
bash scripts/family.sh push     # 推送所有待推仓库（预推钩子照跑），并核对本地=远端

为什么是脚本而不是合并成一个包：三个仓库不是维护难点，三份检查清单才是。这份脚本把清单只写一次。而包本身不合并，是因为差异是承重的—— 守卫注册 pre/post-execute 钩子（因此不能安全热重载，且能被 gate 拦住），工具箱则承诺"零钩子、只建议、从不拦"。合并会让其中一个的性质消失。

为什么不用 monorepo：pnpm 支持 github:user/repo#path:packages/x （package sources），所以技术上可行；但意味着三个已发布仓库要迁移安装命令，收益（少两个 git remote）不抵这个代价。若"只有一个入口"的心理负担才是主因，更划算的是元包 + 一张合账卡片，而不是搬家。

构建 / 测试

bash scripts/build.sh   # tsc → lib/，并逐个 node --check 产物
npm test                # 9 项：熔断/缓存 TTL/脱敏/重试判定/百分位/并发闸/错误类型/缓存键

lib/ 已提交，所以 git 安装即使跳过构建也能直接用。

License

BSD-3-Clause

@dsh-external/dsh-jev-core

インストール

ドキュメント