979569650/dsh-typesafe

dsh-typesafe

TypeSafe Jev 作为 DeepSeek Harness 的决策层。

推理模型不应把上下文和 token 花在那些范围狭窄、可枚举、机械化的判断上。Jev 恰好能回答这类问题——成本低廉，且带有经过校准的概率——而且由于架构不同，它能提供一个真正独立的第二信号，而同家族的 LLM 评审者只会自我附和。

本插件将其接入 DSH：三个工具、一段简短的提示词章节（告诉 agent 何时值得做这笔交易）、一个针对不可信工具结果的自动提示注入防护，以及一个成本计量器，让“更便宜”成为一个可以核对的数字，而不是一个只能选择相信的说法。

功能

| 组件 | 新增内容 |
| --- | --- |
| typesafe_decide | 在一次调用中，就同一段内容向 Jev 提出 1–200 个带类型的问题。可混合使用 noul（是/否概率）、choice（选一个 + 完整分布）和 score（评分标准）。 |
| typesafe_route | 将内容路由到一组固定目标之一，返回所选目标、每个概率以及一个置信度。min_confidence 可将不确定性转化为显式的升级标志。 |
| typesafe_screen | 筛查不可信文本中的提示注入，以及据此行动会造成多大危害。 |
| 提示词章节 | 三条具体规则，告诉 agent 何时 Jev 优于一次推理调用，何时不是。没有它，工具虽存在却不会被使用。 |
| 自动防护 | 一个 tools/post-execute 钩子，在模型读取之前筛查来自 web_fetch、web_search、read_page 以及 fetch MCP 工具的结果。失败时放行。 |
| /typesafe | 会话调用次数、输入 token 和预估成本。 |
| 本地化卡片 | Settings 卡片提供中文和英文，并遵循 Settings → General → Language。 |

实测结果

针对 jev-latest 的真实调用，而非厂商宣称：

| 检查项 | 结果 |
| --- | --- |
| 一次调用中的三个原语 | 紧迫性 0.98；路由 technical 0.81；挫败感 1.04/2 |
| 每次调用的延迟 / 成本 | 约 800 ms，$0.0000173 |
| 对真实注入字符串的防护 | blocked，注入 0.99，危害 2.34 |
| 对良性政策文本的防护 | clear —— 无误报，注入 0.01，危害 0.06 |
| 中文输入 | 紧迫性 0.98，愤怒 1.9/2 —— 尽管文档称 CJK 较弱，但仍可用 |

每次筛查成本：$0.0000235。整个验证运行花费 $0.000094。

实地测试：agent 会自行使用它吗？

三个会话，任务形态相同（28 条中文支持工单待分诊），仅在提示词章节的措辞和顺序上有所不同。任务从未提及 TypeSafe，因此该章节是唯一能让 agent 主动使用该插件的东西。

| 会话 | 章节 | TypeSafe 调用 | 结果 |
| --- | --- | --- | --- |
| 1 —— 15 条反馈 | 旧措辞，顺序 2750 | 1 次 typesafe_decide，一次调用 45 个问题 | 成功 |
| 2 —— 28 条工单，triage.py | 旧措辞，顺序 2750 | 0 | 失败 |
| 3 — 28 个工单，triage.py | 新措辞，顺序 700 | 1 × typesafe_decide，一次调用中 28 个问题 | 有效 |

为什么第 2 次会话失败了，以及改了什么

旧版章节开头是“你可以通过三个工具使用 TypeSafe Jev”——这是对一种存在性的描述。在一个编码形态的任务（“编写 triage.py”）下，智能体直接去写关键词规则，并且从未重新考虑，即使它报告了 64% 的不确定率，而这些工具的存在正是为了防止这种情况。它有需求，它有工具，但它没有把两者联系起来。

重写版用识别触发器取代了描述——即智能体自己即将执行的行为：

编写关键词规则、正则表达式或启发式方法来对文本进行分类。 在你构建词表之前，先问 Jev。

声称哪些条目“不确定”或“模糊”。 不要猜——低 confidence 就是“我不确定”的机器可读形式。

promptOrder 从 2750 移到 700，从工具目录移入行为规则区间（TEAM_POLICY 600 … PTC_ONLY 800）。实测：该章节从偏移 10653/17377（提示词中的 61% 处）变为 6348/18352（35%）。

第 3 次会话用它做了什么

它没有让 Jev 去分类——它用 Jev 来审计自己的规则：

| 选择 | 为什么重要 |
| --- | --- |
| State = 类别定义 + 全部 28 个工单，并附上规则引擎的判定 | 按文档所述，内容与问题分离 |
| Question = “这个工单的分类是否无争议？” | 审计自己的输出，而不是外包出去 |
| 四个选项：certain / ambiguous / multi / both | 把“不确定”拆成两种原因——该章节只说了“不确定” |
| 一次调用，一套共享标准 | 最便宜的正确形态 |

然后它用概率来推翻自己的规则引擎：关键词层标记了 15 个条目，Jev 的分布将其缩减为 3 个可靠 + 3 个边缘，并识别出 004/009/016/022 是由短文本而非真正歧义导致的误报。它还通过交叉检查两个信号发现了一个真实 bug——感谢规则 收到 匹配到了“发票还没收到”。

它能在长对话中存活吗？

这种担忧是合理的：不断增长的上下文中的固定指令会被稀释。以生成本 README 的那次会话为衡量对象——2,239 条记录、790 万字符的对话，约为系统提示词的 430 倍——答案是肯定的，原因有三个：

1. 系统提示词是按请求重新组装的，而不是累积的。 在那次会话中，它的大小为 16561 → 17377 → 18351 字符（跨度 1790），而对话增长到超过 790 万。对话不会把指令挤出其位置。

2. 压缩替换的是对话消息，而绝不是系统提示词。 检查点以 surfaceOp: { op: "replace", startSeq, endSeq } 的形式落在 user/message 跨度上，而会话服务在构造上就拒绝任何覆盖节点 0 的替换。
第二个说法是经过验证的，而非推断的。test/compaction-survives.mjs 驱动了真实的 @deepseek-ai/dsh-session surface 机制：它构建一个会话，其节点 0 是携带该 section 的系统提示，追加一段对话，应用压缩所使用的精确 replace，并断言此后该提示逐字节完全相同。然后它尝试对抗性变体——一个连同对话一起吞掉节点 0 的替换——并断言服务拒绝它：

surface replace: node 0 holds the system prompt and may be rewritten
only by a system/message over exactly that node
surface seqs after : [0,1,2,3]   ← unchanged by the rejected attack

同一个测试还断言了阳性对照：当仅针对节点 0 时，合法的系统提示刷新是被允许的，这正是编辑过的 section 无需重启即可到达活动会话的方式。

3. 在同一个长会话的后期，使用情况依然成立。 TypeSafe 在其中被调用了 12 次：9 次在早期（现场测试），3 次在 2,100+ 条记录时（防护代码审计）。后面的调用发生在对话已经约 7 M 字符之后。

唯一真正的漂移，及其规模。 Section 按升序渲染，因此任何 order 更低的内容都会把指导推到更后面。记忆 section（order 50）是增长者：它渲染固定记忆加上近期记忆，在那个会话中它占据了插件 section 之前约 6,232 个字符。这种漂移是有界的且很小——在一个 2,239 条记录的会话中为 816 个字符——而 promptOrder 700 在其上方留下了大部分行为带未被使用。

真正会破坏它的因素，明确陈述以便可以观察而非假设：一个在 order        # calls + guard notices
node scripts/dump-call.mjs            # the full state and questions
node scripts/context-growth.mjs    # prompt vs conversation curve
node scripts/section-drift.mjs        # what renders before the section
node scripts/long-context-risk.mjs    # coverage, compaction, stability

这些工具揭示的一个注意事项：一个会话记录了 5 个系统提示，其中 3 个携带该 section。另外两个早于该插件在该会话中的激活——按请求重新组装意味着在插件加载之前捕获的提示合法地缺少它。在不知道插件何时激活的情况下，统计“有多少提示包含该 section”是没有意义的。

它还暴露出的静默防护缺口

read_page——一个由不同插件贡献的工具——抓取了一个网页，而防护从未看到它，因为 guardTools 是一个字面量允许列表：

[GAP] read_page      ran 2, noticed 0
这是安全特性中的一个静默漏洞。已通过三种方式修复：

1. guardTools 条目现在是 glob，因此 mcp____fetch 覆盖所有 MCP
fetch 服务器，包括之后命名的服务器。
2. read_page、read_url、browse 和 scrape 已包含在默认列表中。
3. 插件现在会在启动时审计已注册的工具集，并记录一条警告，
列出守卫未覆盖的任何内容摄取工具。

test/guard-coverage.mjs 对这三项都进行了断言，包括针对
read_page 的回归用例。

审计：与 Jev 一起审查此插件

审计守卫的方式是就实际源码向 Jev 提出五个原子性的是/否问题——
这正是此插件旨在促成的“氛围编程”模式：智能体编写代码，决策模型进行机械式检查，
智能体验证每一个标记。

Jev 对全部五个问题都返回了高概率。其中两个是真实问题。 这个比例才是有用的发现：
它是一个过滤器，而不是一个预言机。

| 标记 | Jev | 已验证 | 结果 |
| --- | --- | --- | --- |
| 截断绕过 | 0.89 | 真实 | 头部/尾部摘录丢弃了中间的 6000 个字符，而模型读取了全文。通过在偏移量 7200 处放置载荷复现。已修复——chunkText 现在覆盖每个字符。 |
| 通知伪造 | 0.68 | 真实 | 获取的页面可以以其自身的 [TypeSafe guard] Screened clear. 行开头；模型看到了两个相同的标记。已修复——collidesWithMarker 强制阻止，并且不可信区域被分隔开。 |
| 故障开放可被利用 | 0.91 | 已接受，按设计 | 诱导故障的攻击者会获得未经筛查的内容。这是有意的权衡（一个会中止工作的守卫是一个可用性缺陷）；通知会大声显示 UNSCREENED，而不是保持沉默。 |
| 第三方数据暴露 | 0.93 | 已接受 | 筛查后的文本会发送到 api.typesafe.ai。这是真实的，而诚实的答案是，这是使用任何托管分类器所固有的——对于绝不能离开本机的内容，请关闭守卫。 |
| 残余绕过 | 0.79 | 未复现 | 修复后，Jev 将新的分块循环重新评分为 0.35，且没有差一错误。 |

两个真实发现现在都是永久回归测试
（test/truncation-bypass.mjs、test/notice-forgery.mjs），如果漏洞重现，它们就会失败。

审计遗漏、后来发现的那一个

上面的截断绕过已在 lib/guard.js 中修复——但在
lib/tools.js 中仍然存在，其中 typesafe_screen 有自己的一份相同头部/尾部
摘录副本。该工具在仍然对全文报告一个自信结论的同时，持续丢弃长文本的中间部分：

full text length                    : 24054
payload offset                      : 7995   (old excerpt dropped [4200, 22254))
payload SEEN by the tool excerpt    : false
payload covered by the chunked path : true

这比守卫版本的漏洞更糟，因为这是插件自己的提示词部分告诉智能体
在信任外部内容之前要使用的工具
text。现在两条路径都调用同一个 screenAll()，因此修复不可能只落在其中一条而漏掉另一条，并且 test/screen-coverage.mjs 会驱动该工具的真实请求路径，以断言载荷能够到达分类器。

这个教训比“多审查”更具体：重复的实现就是重复的漏洞。 修复其中一份副本并不等于修复了这个 bug。

值得记住的教训： 提出多个范围狭窄的问题，而不是一个宽泛的问题，并把每个答案当作需要调查的线索，而不是最终裁决。安全标记上 40% 的命中率确实有用；未经核实就接受的 40% 命中率比完全不审查还糟。

它刻意不做的事

- 它不是模型替换。 Jev 不能写文章、调用工具或进行对话。model: "jev-latest" 永远不会驱动这个 agent。TypeSafe 自己的文档明确说明了这一点。
- 它不参与模型的思考。 Jev 没有可供贡献的推理轨迹。任何让它“与”agent 一起思考的设计都是对两者的误用。
- 该守卫从不阻塞工作。 它只在前面附加一条建议性裁决；沙箱和审批接缝仍然决定什么可以运行。一个在 Jev 不可达时能中止工作的守卫，会把一个可选的安全特性变成可用性 bug。

安装
bash
node scripts/install.mjs

这会做三件事，在 harness 加载插件之前，这三件事都必须成立：

1. 把这个包的 node_modules 链接到 profile 的 node_modules，以便这个包自身的导入能够解析。被链接的包会按其真实路径解析，否则 Node 会去 dsh-typesafe/node_modules 里找——而在源码检出中这个目录并不存在。
2. 在 profile 中执行 pnpm add link:，以便 bundle 加载器能够解析这个名称。此处的编辑无需重新安装即可生效。
3. 把 dsh-typesafe 追加到 dsh.profile.bundles，否则加载器永远不会读取 cordis.patch.yml，这一行也就永远不会被插入。

对于非默认 profile，请显式传入 profile 目录：
bash
node scripts/install.mjs "%DSH_HOME%\profiles\desktop"
node scripts/install.mjs --uninstall

然后重启 DSH（或让 patchReload: live 拾取这一行）。

配置 API 密钥

有两条路径。卡片是预期的方式；脚本之所以存在，是因为卡片在长长的插件列表底部可能很难找到，也因为全新的 profile 可能在浏览器那一半还无法访问之前就需要密钥。

设置卡片

Settings → Plugins → Plugin configuration → TypeSafe。

该卡片位于 Plugins 列表中其他卡片之间——滚动到底部，它排在最后。绿点表示已存储密钥。

密钥通过凭据存储写入，而不是写入 settings.yaml。字面值永远不会出现在设置响应中，因此页面只能报告密钥是否存在。

脚本（无 UI）
bash
node scripts/set-key.mjs sk-your-key
node scripts/set-key.mjs --status
node scripts/set-key.mjs --unset
这会通过一个真正的 YAML 解析器逐叶修补 $DSH_HOME/.credentials.yaml，因此其他所有提供商的密钥和你的注释都会保留下来。

两种路径都会在下一次工具调用时生效，无需重启：凭据是按请求解析的，而不是在启动时捕获的。

你也可以在启动 DSH 的环境中导出 TYPESAFE_API_KEY。继承的环境变量优先于存储的密钥，并且是只读的。

在  获取密钥。新账户包含 $5 的促销额度（TypeSafe 自己的估计：约 1.19 亿输入 token）。

用以下命令验证：

/typesafe

验证安装

宿主端和浏览器端会各自独立失败，而且两者都会悄无声息地失败。插件可以成功加载其工具，但其 Settings 卡片却始终不渲染，因为浏览器 bundle 是通过单独的扫描发现的。

安装后，确认宿主端已加载：
powershell
Select-String -Path "$env:APPDATA\DSH Desktop\logs\host\dsh-.log" -Pattern typesafe

正常工作的安装会记录：

[I] [dsh-typesafe] dsh-typesafe: Jev tools registered (model jev-latest)

- 没有这一行 → 该 bundle 从未被发现。检查该 profile 的 package.json 中的 dsh.profile.bundles。
- 有这一行，但没有卡片 → 宿主端没问题，而客户端端未被找到。运行 npm run test:client，它会按照真实加载器的规则检查每一个发现关卡。
- 出现一条点名未筛查工具的警告 → 防护覆盖审计发现了一个位于 guardTools 之外的内容摄取工具。为它添加一条模式。

安装后两端都需要重启：bundle 列表在启动时读取，而客户端扫描是针对组合后的树运行的。

审计一次会话

会话存储是关于模型被告知了什么以及它调用了什么的权威记录。这些脚本直接读取它，因此关于行为的说法可以被核实，而不是仅凭信任：
bash
node scripts/audit-session.mjs         # tool-call census + guard notices
node scripts/inspect-typesafe-call.mjs  # the exact questions and answers
node scripts/guard-coverage.mjs         # which content tools were not screened
node scripts/show-section.mjs                      # the prompt section as delivered
node scripts/prompt-evidence.mjs                   # was it in a system prompt at all

这些脚本编码了两个坑，二者此前都产生过错误答案：

- 该存储是多帧 zstd（每条记录一帧）。单次 zstdDecompressSync 只返回第一条记录——一个 2 MB 的会话被解码为 191 字节，这读起来像是“没有证据”，而不是一个错误。
- 在会话中搜索提示文本会产生误报：同一个字面量也出现在插件自己的源码中，因此每次对 lib/index.js 的读/写都会匹配。只有 system/message 记录才能证明投递。

预期 agent 如何使用它

插件的提示部分告诉 agent：
当判断是狭窄的、可枚举的、机械的——将请求路由到固定集合中的某一个、按照你能陈述的评分标准打分，或是做出是/否的判定——就使用它。[…] 在一次调用中提出多个问题。它们针对同一状态并行运行，因此批处理远比每个问题一次调用便宜得多。使用 typesafe_route 返回的置信度。高置信度意味着采取行动；低置信度意味着上报。

批处理这一点正是成本优势的真正来源。Jev 自己的 cookbook 测得，在一次调用中提出 13 个问题，比依次提出同样的问题便宜 11–12 倍、快 9–10 倍。

成本

每百万输入 token 0.042 美元；输出 token 免费。根据
：

| 工作负载 | 成本 |
| --- | --- |
| 一次屏幕大小的调用 | 约 $0.00002 |
| 100k 次调用 × 1,000 token | $4.20 |
| 1M 次调用 × 1,000 token | $42.00 |

inputPricePerMTok 是可配置的，因此如果 TypeSafe 更改定价，请更新它——
该插件根据这个数字报告成本，而不是根据硬编码的费率。

防护机制详解

能骗过 LLM 的注入载荷，恰恰也是同族 LLM 审查者倾向于接受的载荷——相同的训练压力，相同的盲点。Jev 是一种不同的架构，为校准决策而训练，并通过单独组装的状态调用，因此它的判定至少是一个不同的信号，而不是回声。

有两个问题被有意分开提出：

- noul —— 这段文本是否试图重定向 AI 助手？普通文档、引用的示例，以及关于提示注入的讨论，明确不算尝试。
- score 0–3 —— 如果助手按照文本中的任何指令行动，会造成多大危害？

判定结果：blocked（注入 ≥ 阈值 且 危害 ≥ 2）、review
（注入 ≥ 阈值），否则为 clear。

有三个值得了解的特性：

- 失败开放。 任何失败——没有密钥、超时、速率限制、网络——都会使结果保持不变，但会附加注释。沉默会让“已筛查且干净”与“防护机制已关闭”无法区分，而一个无法区分这两者的 agent，恰恰在没有任何保护时过度信任内容。
- 全覆盖，而非抽样。 长结果会被拆分为重叠的块，并且每个块都会被筛查；没有任何内容被摘除。早期版本保留头/尾摘录，而载荷可以通过位于被丢弃的中间部分来绕过——模型读取了它，分类器却从未看到。现在两条筛查路径共享同一实现，因此该修复不会在其中一个中被遗漏。
- 最小长度。 低于 guardMinChars 时，判定结果就是噪声，而且调用成本高于它所判断的内容。此下限仅适用于自动防护；显式的 typesafe_screen 调用会筛查交给它的任何内容。

配置参考

每个键都有默认值，因此仅 id + name 就是一次可用的安装。在设置卡片中编辑它们，或在 profile 的 cordis.patch.yml 中覆盖该行。
| 键 | 默认值 | 含义 |
| --- | --- | --- |
| enabled | true | 总开关。关闭后会移除提示词部分和防护。 |
| apiKeyEnv | TYPESAFE_API_KEY | 要解析的凭据引用。 |
| baseURL | https://api.typesafe.ai | API 源。 |
| model | jev-latest | 别名或固定版本 id。如果你针对某个版本调整过阈值，请固定该版本。 |
| timeoutMs | 30000 | 每个请求的超时时间。 |
| maxStateChars | 60000 | 在计费前拒绝过大的调用。 |
| inputPricePerMTok | 0.042 | 仅用于成本报告。 |
| promptEnabled | true | 是否告知 agent 何时使用这些工具。 |
| promptOrder | 700 | 提示词部分的放置位置，位于行为规则区间（TEAM_POLICY 600 … PTC_ONLY 800）。 |
| guardEnabled | true | 筛查不受信任的工具结果。 |
| guardTools | web_fetch、web_search、read_page、read_url、browse、scrape、mcp____fetch、mcp____fetch_content、fetch_content | 要筛查哪些工具结果。通配符，因此一个条目可覆盖一整个系列。只有引入外部文本的工具才应列在这里。 |
| guardWarnThreshold | 0.5 | 结果被标记的注入概率阈值。 |
| guardMinChars | 200 | 跳过更短的结果。 |
| guardMaxChars | 6000 | 筛查的分块大小。每个分块都会被筛查，因此这是在请求数量与请求大小之间做权衡——它不是摘录预算。 |

测试
bash
npm test              # 离线：请求构造、schema、防护文本、接线、本地化
npm run test:runtime  # 在真实 Cordis 运行时下启动插件
npm run test:security # 审计发现，作为回归测试
npm run test:client   # 针对真实 loader 检查客户端 bundle 发现
npm run test:live     # 真实调用；需要 TYPESAFE_API_KEY

test/truncation-bypass.mjs、test/screen-coverage.mjs 和
test/notice-forgery.mjs 是针对 Jev 审计期间发现的三个真实漏洞的回归测试
（见上文）。它们断言的是安全不变量，而不是实现：截断测试在五种分块大小下
将载荷扫过每一个位置，筛查覆盖测试用打桩的传输层驱动工具的真实请求路径，
并断言载荷到达分类器，伪造测试断言标记模仿会强制阻断，且不受信任区域
保持被界定。

test/screen-coverage.mjs 之所以存在，是因为截断修复被应用到了防护上，
而没有应用到 typesafe_screen 工具——同一个缺陷在同一个想法的第二个实现
中存活了下来。现在两条路径都调用同一个函数，如果工具路径的摘录再次返回，
这个测试就会失败。

test/locale.mjs 之所以存在，是因为缺失的翻译在用户看到之前是不可见的：
一个键在一种语言中存在而在另一种语言中缺失时，会渲染为原始键名，读起来
像是构建损坏。该检查断言两个字典声明了相同的键、每个 t() 引用都能解析，
并且没有任何条目是死文案。
test/runtime.mjs 是最重要的那个。它用真实的工具注册表、设置提供器、凭据存储和系统提示服务组合出一个真实的 Cordis 应用，然后应用该插件并对输出结果进行断言：三个工具对模型可见，每个都投射为有效的线上 schema，设置命名空间注册并通过真实提供器往返一次写入，无效写入被拒绝，提示词片段能够渲染，并且守卫确实通过工具流水线端到端触发。它不启动任何 Web 服务器，也不启动任何会话，因此可以与运行中的 DSH 并存。

test/live.mjs 衡量的是任何离线测试都无法衡量的东西：TypeSafe 是否接受该请求形状，响应是否与插件所假设的一致，真实的每次调用成本，守卫能否将真正的注入与良性文本区分开，以及 Jev 如何处理中文输入——TypeSafe 文档中说明中文处理弱于英文。它的守卫样本被刻意设置得足够长，以越过 guardMinChars；更短的样本会触发长度过滤器而非分类器，并报告“未筛查”，这不是一个通过的结果。

实测限制

TypeSafe 很年轻，并且对此很坦诚。请把这些当作需要围绕其做规划的事实，而不是反对意见：

- 2026 年 9 月正式发布（GA），在撰写本文时仅诞生数日。速率限制和定价被记录为动态变化。
- 准确率 67.8%，基于 TypeSafe 自己发布的基准测试，而其最佳 LLM 对比对象为 74.1%。Jev 在成本、速度和可路由置信度上胜出——而非在原始准确率上。在依赖它之前，请在你自己的数据上进行测量。
- 英文是主要训练语言。 CJK 可以处理，但效果并不等同；在中文场景中依赖它之前请先测试。
- 输入仅限文本。 不支持图像、音频或视频。
- 所有厂商性能声明（快 193 倍、便宜 444 倍）均为厂商自报，未经独立验证。第三方价格网站（jevtypesafeai.com、jevplayground.com、explainx.ai）均为非官方。

布局

lib/config.js             共享常量和随附默认值
lib/jev.js                线上客户端：请求构建、验证、成本核算
lib/guard.js              注入筛查、分块和判定渲染
lib/tools.js              三个面向模型的工具
lib/index.js              插件入口：设置、凭据、提示词、工具、守卫、命令
lib/client.js             浏览器端：拥有 API 密钥的设置卡片
scripts/lib/session-store.mjs  审计脚本共享的会话存储读取器

scripts/lib/session-store.mjs 不随附发布（仅发布 lib/），并且从不在运行时被导入。它之所以存在，是因为十个审计脚本各自携带了同一个多帧 zstd 读取器的副本——包括一个微妙之处：单次 zstdDecompressSync 调用只解码第一帧，这会把一个真实会话变成静默的假阴性。一份副本，一个正确的地方。

许可证

MIT。