# 0010：第一版跨项目库交付 ## 状态 已于 2026-08-27 经用户明确批准。本文自批准起冻结；后续若改变这里的 backend 契约、版本身份或发布渠道， 应新增 design，不得回写本文。 `supersedes: 0009`（范围有限）：本文只替代 `0009` 中没有被真实 optional dependency 验证覆盖的 `SPELLCHECKER` 大小写适配、发布前验收和版本身份部分。`0009` 已批准的规则模型、候选比较、失败关闭、 Markdown 块边界、无默认规则、无网络和函数式 `Modifier` 契约继续有效。 本文批准后只授权实现和验证，不自动授权提交、创建 tag、push、创建 GitHub Release、上传产物、修改其他仓库 或读取真实材料。 ## 1. 问题与可观察现象 提交 `11349e0` 已经实现通用 `mapped_line_join()`，仓库基础检查在 Python 3.13.11 下得到： ```text 168 passed, 2 skipped ``` 两个 skip 分别对应没有安装的 `pyspellchecker` 和 `wordfreq`。这意味着核心契约和合成 backend 通过了测试， 但最关键的真实词典适配器没有进入同一次验收。 2026-08-27 在临时干净 venv 中从 wheel 安装全部 extras 后，实际版本为： | 包 | 实际版本 | | --- | --- | | `mdpolish` | `0.2.0` | | `pyspellchecker` | `0.9.0` | | `pyphen` | `0.18.1` | | `wordfreq` | `3.1.1` | `wordfreq`、`Pyphen` 和显式 `case_sensitive=False` 的 `pyspellchecker` 都能把合成输入 `an exam-\nple` 稳定处理成 `an example`。但是，当前 `LexicalLineJoinRule.case_sensitive` 默认是 `True`， 实现会把它直接传给： ```python SpellChecker(language="en", case_sensitive=True) ``` 真实上游立即拒绝： ```text ValueError: case_sensitive can only be True when not using a language dictionary. ``` `pyspellchecker` 的源码和官方 quickstart 都说明，大小写敏感模式只适用于不加载内置 language dictionary 的实例： - - 这不是词典无命中，而是构造阶段的能力冲突。当前实现把它包装成泛化的“无法加载语言”错误，调用方无法知道 应该怎样改配置。 另一个交付问题是包版本仍为 `0.2.0`。这个版本已经用于 `0008` 后的函数式核心；如果新旧内容继续生成同名 wheel， 其他项目、pip 缓存和问题报告都无法可靠区分实际安装的是哪一份代码。 因此，当前提交适合受控试接，不适合直接作为一个带稳定版本身份的跨项目交付。 ## 2. 目标与非目标 ### 2.1 目标 - 对 `SPELLCHECKER` 不支持的大小写组合给出构造期、可操作、不会泄露正文的错误； - 保留 `case_sensitive=True` 的公共默认值，不静默开启忽略大小写； - 用真实安装的 `pyspellchecker`、Pyphen 和 `wordfreq` 验证 wheel，而不是把 skip 当成通过； - 为这次新增公共能力分配唯一包版本 `0.3.0`； - 将修复后的 `mapped_line_join` 修改器版本更新为 `2.0.1`，使审计记录可以区分修复前后； - 在 README 提供其他项目可以直接复制的安装、导入和自动英文断词示例； - 将 GitHub tag 和 GitHub Release 确定为计划内的正式发布渠道，明确不使用 PyPI； - 明确第一版固定版本方式和消费者责任； - 保持核心安装零第三方运行依赖，extras 仍然只由调用方显式安装和启用。 ### 2.2 非目标 - 不为 `pyspellchecker` 的内置语言词典自行实现大小写敏感查询； - 不读取、复制或改写 `pyspellchecker` 的内部压缩词典资源； - 不把 `case_sensitive` 默认值改成 `False`； - 不引入 Hunspell、Enchant、wordninja、在线词典、模型或 OCR 版面接口； - 不新增默认规则、默认流水线、项目 profile、配置文件或 CLI； - 不声称词典规则已经在真实业务语料上达到生产准确率； - 不在本轮定义标注指标、接受阈值或真实材料实验； - 不发布到 PyPI 或其他 Python 包索引，不提交 wheel 到 Git； - 不因批准本文就自动创建 GitHub Release 或上传产物； - 不修改其他 modifier、`_text_ranges.py`、真实数据或其他仓库。 ## 3. `SPELLCHECKER` 大小写适配 ### 3.1 候选方案 | 方案 | 优点 | 代价与问题 | 选择 | | --- | --- | --- | --- | | 把 `LexicalLineJoinRule.case_sensitive` 默认改成 `False` | 默认示例可以直接运行 | 违反“不默认忽略大小写”，并静默改变公共语义 | 否决 | | 忽略调用方的 `True`，内部总用大小写不敏感词典 | 代码最少 | 参数记录与实际行为不一致，属于静默降级 | 否决 | | 读取上游包内 JSON 频率表，自己实现大小写敏感词典 | 理论上可以支持 `True` | 绑定上游内部资源路径和格式，扩大维护面；第一版没有证据需要它 | 本轮否决 | | `SPELLCHECKER` 明确要求 `case_sensitive=False` | 行为诚实、改动小、调用方必须主动选择 | 该 backend 暂不提供大小写敏感语言词典 | 采用 | ### 3.2 决定 `case_sensitive` 继续是所有规则共有的显式开关，默认仍为 `True`。新增 backend 组合验证： ```text backend == SPELLCHECKER and case_sensitive is True ``` 在 `mapped_line_join()` 构造阶段立即抛出 `ModifierContractError`。错误消息必须说明： - `pyspellchecker` 的内置 language dictionary 不支持大小写敏感模式； - 调用方若接受大小写不敏感匹配，需要显式设置 `case_sensitive=False`； - 不建议切换 backend，也不执行自动回退。 错误只包含 backend、`rule_id` 和配置字段，不包含输入正文。因为错误发生在构造修改器时，也不应等到 `Pipeline.transform()` 才暴露。 `WORDFREQ` 保留现有 `case_sensitive=True/False` 行为。不能因为一个 backend 的限制，把共同字段的默认值改成 另一个含义。 ### 3.3 为什么第一版不复制词典 `pyspellchecker` 官方允许用 `language=None, case_sensitive=True` 加载调用方自己的词典，但当前规则只接受语言代码， 设计也禁止读取任意路径。为了绕过限制而解析依赖包内部的 `resources/.json.gz`，会新增一套未获保证的 资源格式契约。 第一版更重要的是不误导调用方。明确拒绝不支持的组合，比复制上游实现、静默忽略参数或假装拥有大小写敏感语言词典 更符合失败关闭原则。如果未来项目确实需要该能力，应以真实样本和新 design 决定是增加版本化自带词典、扩展 backend， 还是接受自定义词典输入；不能回写本文。 ## 4. 版本身份 ### 4.1 包版本 实现本文时把 `pyproject.toml` 和 README 中的包版本从 `0.2.0` 更新为 `0.3.0`。 选择 `0.3.0` 而不是 `1.0.0`，原因是： - 新能力是向现有函数式核心增加公共规则和 optional backend，属于 `0.x` 阶段的次版本变化； - 公共规则还没有经过多个调用项目验证； - Markdown 块扫描仍是保守词法子集； - 没有真实语料准确率、默认 profile、CLI 或生产写入协议。 `0.3.0` 表示“可以被其他项目固定版本试用”，不表示“自动词典规则已经适合任意文档生产启用”。 ### 4.2 修改器版本 `mapped_line_join()` 生成的 `Modifier.version` 从 `2.0.0` 更新为 `2.0.1`。 规则 dataclass 和序列化参数格式不改变，因此不升到 `3.0.0`。补丁版本用于表示： - 真实 `SPELLCHECKER` backend 的能力验证变得准确； - 不支持的组合从上游泛化异常变成稳定的构造期契约错误； - 已支持组合的候选选择语义不改变。 ### 4.3 版本记录 词典规则继续在 `Modifier.parameters` 中记录 backend 包版本、语言、候选形式和阈值。调用项目还必须固定 `mdpolish` 包版本；只记录 `Modifier.version` 不能替代安装依赖锁定。 ## 5. 第一版交付渠道 ### 5.1 采用范围 项目计划通过 GitHub 发布版本，不发布到 PyPI 或其他 Python 包索引。不可移动的 Git tag 是源码身份，GitHub Release 是面向使用方的正式发布记录。第一版候选 tag 和 Release 名称为： ```text v0.3.0 ``` tag 必须指向通过本文全部验收的唯一提交，创建后不得移动；GitHub Release 必须绑定这个 tag，不能指向分支头。 其他项目可以通过 GitHub Git 地址和 tag 固定依赖，也可以安装该 Release 附带的 wheel。Python Packaging 规范允许 集成方使用 direct reference，但它不是包索引发布物： - - README 应给出 GitHub tag direct reference 和 Release wheel 两种安装形式，但不把仓库凭据或某个调用项目配置写入库代码。 仓库及 Release 是公开还是私有，由 GitHub 仓库权限决定；本文不授权改变仓库可见性。 ### 5.2 wheel 的角色 wheel 在发布前首先是验证产物，不提交到 Git，也不在仓库内建立 artifact 目录。验收必须从最终源码构建 wheel，并在 干净环境从这个 wheel 安装，而不是依赖当前仓库的 editable install。 实际创建 GitHub Release 时，只能上传通过第 7 节验收的同一个 wheel，并同时提供 SHA-256 校验值。若 tag 后重新构建， 必须重新执行 wheel 元数据和消费者 smoke test，不能把不同构建物当作已经验收的产物。GitHub 自动生成的源码归档与 Release wheel 共同保存在 GitHub；本仓库不另存一份二进制副本。 PyPI、GitHub Packages、内部 Python 包索引和其他 artifact 仓库均不在计划内。将来若要增加其他发布渠道，必须用新的 design 改变本文，而不能只改发布脚本或 README。 ### 5.3 tag 和 push 的确认门 本文批准后可以完成版本修改、测试、构建和提交前候选检查，但不能自动提交、创建或推送 `v0.3.0`，也不能创建 GitHub Release 或上传 wheel。 只有在用户看到最终 diff、真实测试输出和 wheel 元数据后，才能明确授权： 1. 提交交付改动； 提交完成并向用户报告提交哈希和 tag 的准确目标后，才能再明确授权： 1. 创建 `v0.3.0` tag； 2. push 提交和 tag； 3. 创建绑定 `v0.3.0` 的 GitHub Release； 4. 上传已验收的 wheel 和 SHA-256 校验值。 这些动作不因“设计已批准”而自动获得授权。 ## 6. 公共调用契约与 README ### 6.1 支持的导入路径 保持 `0009` 的决定，不扩大聚合导出： ```python from mdpolish.modifiers import mapped_line_join from mdpolish.modifiers.mapped_line_join import ( LexicalCandidateForm, LexicalLineJoinRule, LexiconBackend, ) ``` 本轮不把全部枚举和 dataclass 重新导出到 `mdpolish.modifiers` 或包根。减少顶层公共表面积比缩短一行导入更重要。 ### 6.2 README 示例 README 保留旧三元组示例，并新增一个最小自动英文断词示例。示例必须明确写出： - 通过 GitHub tag direct reference 或 GitHub Release wheel 安装 `lexical` extra； - `backend=LexiconBackend.SPELLCHECKER`； - `case_sensitive=False`； - `JOINED` 与源 `HYPHENATED` 共同参与候选； - 分数阈值只是示例配置，不是库推荐的通用生产阈值； - 检查 `RunStatus` 后才能消费输出。 README 还要明确区分： | 说法 | 当前是否成立 | | --- | --- | | wheel 可以安装，公共 API 可以运行 | 是，验收通过后成立 | | 自动词典不需要逐词维护映射 | 是 | | 库自带默认英文清洗规则 | 否 | | 某个阈值适合所有项目 | 否 | | 已在真实业务文档证明生产准确率 | 否 | ### 6.3 调用项目责任 调用项目必须： - 固定 `mdpolish` 版本或不可移动 tag； - 把规则、顺序、backend、语言、阈值和例外作为项目配置评审； - 检查 `success`、`failed`、`unstable`，不能只读取可能为空的输出； - 自己负责文件读写、覆盖策略、批处理、日志和回滚； - 在自己的语料上验证误合并，不能把库的合成测试当作领域准确率。 ## 7. 验证矩阵 ### 7.1 核心环境 不安装 `lexical` 或 `frequency` extras，运行根 README 的全部基础检查，确认： - 精确、正则、链式和 Markdown 失败关闭测试通过； - 导入模块不会加载词典； - 请求缺失 backend 时给出稳定错误； - optional backend 测试可以明确 skip，但 skip 不能计入真实 backend 验收。 ### 7.2 extras 环境 另建干净环境，安装最终 wheel 的 `lexical` 和 `frequency` extras，并另行安装仓库测试工具，运行同一测试集。 该环境的发布门要求： - `pyspellchecker`、Pyphen 和 `wordfreq` 真实 adapter 测试全部执行，不得 skip； - `SPELLCHECKER + case_sensitive=True` 在构造期得到预期契约错误； - `SPELLCHECKER + case_sensitive=False` 的唯一拼接候选可以合并； - Pyphen 合法和非法断点分别影响 `JOINED`； - `WORDFREQ` 唯一胜者、margin 不足和歧义路径都符合 `0009`； - 包版本和 backend 版本进入审计参数； - 全套测试没有因安装 extras 而改变精确/正则规则结果。 测试不能只断言“构造成功”。至少一个真实 backend 用例必须通过 `Pipeline.transform()` 检查最终状态和完整输出。 ### 7.3 wheel 消费者 smoke test 从最终提交构建 wheel 后，在不位于仓库源码目录的临时环境验证： 1. 只安装核心 wheel，运行精确和正则示例； 2. 安装 `lexical` extra，运行 `SPELLCHECKER + Pyphen` 示例； 3. 安装 `frequency` extra，运行 `WORDFREQ` 示例； 4. 检查 `mdpolish`、修改器和 backend 版本记录； 5. 检查 wheel 不包含 tests、Wiki、真实数据、项目规则或临时产物； 6. 生成并记录待上传 wheel 的 SHA-256 校验值； 7. 确认执行期间不访问网络、调用模型或读取任意文档路径。 依赖安装本身可以访问配置的包索引；“运行期间无网络”指安装完成后的库行为，不把安装包与执行清洗混为一谈。 ### 7.4 Python 支持范围 `pyproject.toml` 当前声明 Python 3.11 及以上。第一版交付前至少验证： - 最低支持版本 Python 3.11； - 当前开发版本 Python 3.13。 如果本地缺少其中一个解释器，不能把单版本结果描述成完整支持矩阵；应在可复现 CI 或受控环境补齐后再创建 tag。 本文不新增 tox、nox、CI provider 或容器配置。若现有环境无法完成双版本验证，报告阻塞而不是降低声明。 ## 8. 消费项目试用边界 通过第 7 节只证明“库可以被安装并按契约运行”，不证明“某组词典参数适合目标项目”。 第一个调用项目应先做只读或影子试用：保存提议和审计信息，由人复核后再决定是否应用。至少观察： - 正确合并与错误合并； - 本应合并但被保留的候选； - `JOINED`、`HYPHENATED`、`SPACED` 的选择分布； - 按段落、标题、列表和引用拆分的行为； - 词典歧义、结构 `UNKNOWN`、代码和表格排除； - 项目专名和自然连字符是否需要 `KeepLineJoinRule`。 具体样本范围、标注方法、指标、接受阈值、输出目录和真实数据权限必须在调用项目或新的实验 design 中确认。 本文不授权读取 `/home/lihaoze/gov_test_data`，也不授权修改任何调用项目。 ## 9. 风险与代价 - **`SPELLCHECKER` 能力不对称：** 使用内置语言词典时必须显式忽略大小写；需要精确大小写的项目应使用其他 backend 或等待新的词典设计。 - **真实 extras 增加验收成本：** `wordfreq` wheel 和传递依赖较大，但不能为了节省安装时间继续跳过发布关键路径。 - **GitHub 可用性与权限：** direct reference 需要 Git 和相应仓库权限；Release wheel 也受仓库可见性和 GitHub 可用性约束。 - **Release 产物一致性：** tag、Release 和 wheel 来自不同操作步骤，必须用提交哈希、版本元数据和 SHA-256 防止 上传错误构建物。 - **`0.3.0` 仍是预览契约：** 其他项目必须固定版本，不能跟随分支头自动升级。 - **双 Python 版本可能受环境限制：** 缺少最低版本验证时，tag 会被阻塞。 - **合成测试不代表领域准确率：** 即使全部 backend 测试通过，词典仍会漏掉专名、新词并误判自然连字符。 - **保守失败关闭降低覆盖率：** 这是第一版为了正文保真接受的代价，不用放宽块扫描来追求漂亮数字。 ## 10. 实施与验收范围 本文获批后授权： 1. 修改 `src/mdpolish/modifiers/mapped_line_join.py`，增加 `SPELLCHECKER` 组合验证并把修改器版本更新到 `2.0.1`； 2. 扩展 `tests/test_mapped_line_join.py`，覆盖真实 backend、明确错误和版本记录； 3. 把 `pyproject.toml` 包版本更新到 `0.3.0`，不改变已批准 extras 的依赖集合； 4. 更新根 README 的当前版本、自动词典示例、交付边界和实际验证结果； 5. 在临时目录构建和安装 wheel，运行第 7 节验证； 6. 只读检查 `AGENTS.md` 与 `CLAUDE.md` 镜像、Git diff、工作区状态和最终提交候选范围。 本文获批后仍不授权： - 修改已冻结的 `0009`； - 修改 `_text_ranges.py`、其他 modifier、其他 Wiki 文档或调用项目； - 读取或复制真实材料； - 新增默认规则、CLI、profile、artifact 目录、CI 配置或第三方 backend； - 提交、创建 `v0.3.0` tag、push、创建 GitHub Release、上传 wheel 或创建 PR。 实施完成的最终报告必须分别给出核心环境、extras 环境、Python 版本和 wheel smoke test 的真实输出。任何必需环境未验证时， 明确写“未验证”或报告阻塞，不能用合成 adapter 测试替代真实 backend 结果。