建立实验室共用库定位并完成论文/GovDoc 两批数据的问题审计

- README 更新项目定位为实验室共用清洗库，明确 data/ 职责与 profile 复用原则；
- 新增 ClinDB-ReviewBench（论文清洗）5 份 Markdown 问题审计（scratch），
  并确定第一版清洗范围：9 类确定性规则（reference/CLINDB_REVIEWBENCH_CLEANING_SCOPE.md）；
- 45 份政务文档审计重命名为 GOVDOC_SAAS_CLEANING_SCOPE.md，截去第 6 节起的
  实施建议，只保留问题报告（396 行）；
- 收录 2026-08-20 生态调研草稿（scratch）。

README.md

@@ -1,9 +1,14 @@
 # govdoc-md-cleaner
 
-政务文档 PDF→Markdown 清洗方向的独立研究与治理仓库。
+实验室共用的 Markdown 清洗研究与基础工具库。仓库名沿用了最初的 GovDoc 场景，但项目不属于 GovDoc
+专用组件，也不只服务政务文档。
 
-本仓库用于澄清清洗问题、记录设计选择、积累可复核证据，并在方案获得确认后再建立实现。
-它目前不是可安装的 Python 包，也不提供命令行工具或生产接口。
+本仓库面向实验室内不同项目复用，用于清洗 PDF、DOCX、OCR、网页等上游管线生成的 Markdown，统一解决
+格式噪声、结构损坏、内容异常、来源追踪和多用途派生问题。各项目共享通用清洗能力，再通过独立配置或
+profile 表达论文、政务文档、RAG、文档对比等不同需求。
+
+仓库当前仍处于研究和方案设计阶段：用于澄清问题、记录设计选择、积累可复核证据，并在方案获得确认后
+再建立实现。它目前不是可安装的 Python 包，也不提供命令行工具或生产接口。
 
 ## 当前阶段
 
@@ -13,16 +18,53 @@
 - `AGENTS.md` 与 `CLAUDE.md` 提供同步的协作规则；
 - `research-wiki/` 按文档生命周期区分设计、说明、参考、指南和草稿；
 - `research-wiki/design/0001-repository-foundation.md` 记录本次基础架构选择。
+- `research-wiki/reference/GOVDOC_SAAS_CLEANING_SCOPE.md` 保存 45 份外部测试 Markdown 的只读问题审计；
+- `research-wiki/scratch/markdown-cleaning-ecosystem-research-2026-08-20.md` 完成首轮生态与架构调研。
+- 2026-08-21 完成师姐项目（ClinDB-ReviewBench）5 份论文 Markdown 的问题审计
+  （`research-wiki/scratch/data-5papers-cleaning-audit-2026-08-21.md`），并确定其第一版清洗范围
+  （`research-wiki/reference/CLINDB_REVIEWBENCH_CLEANING_SCOPE.md`，9 类确定性规则）。
+- 2026-08-21 明确本项目定位为实验室共用库；GovDoc 和论文清洗都是使用场景，不是核心边界。
 
-当前没有清洗算法、可执行命令、运行依赖、测试套件或已批准的输入输出契约。
+当前没有清洗算法、可执行命令、运行依赖、测试套件或已批准的输入输出契约。调研报告中的技术组合、
+内部 IR、profiles 和实施路线均是候选方案，尚未批准。
 目录存在只代表文档落点已经建立，不代表相应能力已经完成。
 
-## 项目边界
+## 服务对象与复用目标
 
-- 研究对象是 MinerU、OCR 等 PDF→Markdown 管线产生的噪音与清洗方法；
-- `/home/lihaoze/gov_test_data` 中的真实材料属于外部只读数据，不复制、不修改、不提交；
-- 任何清洗语义、规则格式、评估指标、代码目录或运行依赖，都应先形成设计记录并获得确认；
-- 研究结果只有经过独立评审后，才能进入其他产品或生产仓库。
+当前已经明确的使用场景包括：
+
+- **论文清洗**：`data/` 中现有内容来自师姐的项目，包含论文 PDF 的 Markdown、JSON、图片等转换产物；
+- **GovDoc**：政务、招投标、采购、合同等文档的清洗、比对和 RAG 前处理；
+- **未来实验室项目**：后续可以继续接入其他需要 Markdown 质量检查、规范化或用途派生的项目数据。
+
+当前用例只用于发现真实问题和验证通用能力，不能反过来限定库的设计。核心代码不得依赖论文 DOI、
+GovDoc 目录、具体客户名称或某一转换器的固定输出路径。
+
+## 面向复用的设计原则
+
+- **通用核心**：编码检查、Markdown/HTML 结构解析、异常检测、可审计变换、资产校验和来源追踪；
+- **输入适配器**：不同 PDF/OCR/DOCX/HTML 转换器通过 adapter 接入，不把某个上游工具写死；
+- **项目 profile**：论文、GovDoc、对比、RAG、公开脱敏等规则独立组合，不互相污染默认行为；
+- **保真优先**：不确定内容默认保留或进入人工确认，不能为了格式整齐改写业务或学术内容；
+- **可复现**：规则、配置、输入哈希、输出和每次变更都可以追踪；
+- **可扩展**：新增项目应主要增加 adapter、detector、transformer 或 profile，而不是复制一套清洗器。
+
+## `data/` 的职责
+
+`data/` 是实验室项目的本地数据工作区。当前存放师姐论文清洗项目的输入和转换产物，未来可能继续加入
+其他项目的数据。新增数据时应逐步按项目命名空间组织，例如 `data/<project_id>/...`，避免不同项目的
+输入、产物和评测结果混在一起。
+
+数据目录与通用库保持以下边界：
+
+- `data/` 已被 Git 忽略，不作为库源码、公开 fixture 或发布包的一部分；
+- 默认把项目数据视为只读输入，清洗结果写到独立输出位置，不覆盖原文件；
+- 数据可以推动通用规则设计，但项目专属规则必须进入对应 profile；
+- 测试需要的公开样例应单独制作脱敏、最小化 fixture，不能直接复制真实项目文档；
+- `/home/lihaoze/gov_test_data` 等仓库外真实材料同样保持只读，不复制、不修改、不提交。
+
+任何清洗语义、规则格式、评估指标、代码目录或运行依赖，都应先形成设计记录并获得确认。研究结果进入
+具体项目或生产系统前，还需要在使用方范围内独立验证。
 
 ## 目录结构
 
@@ -31,6 +73,7 @@ govdoc-md-cleaner/
 ├── AGENTS.md
 ├── CLAUDE.md
 ├── README.md
+├── data/                   # 本地项目数据；Git 忽略，未来按项目分区
 └── research-wiki/
     ├── README.md
     ├── design/       # 方案选择与冻结决策
@@ -49,7 +92,8 @@ govdoc-md-cleaner/
 3. `research-wiki/README.md`，确认文档应放在哪里；
 4. 与任务直接相关的 `research-wiki/design/` 记录。
 
-下一项实质工作开始前，应新增下一编号的 design，明确问题、备选方案、输入范围、验收方法和非目标。
+下一项实质工作开始前，应以现有论文数据、GovDoc 审计和生态调研为输入新增下一编号的 design，明确
+通用核心与项目 profile 的边界、第一阶段范围、技术选型、输入输出、验证方法和非目标，并等待批准。
 
 ## 当前可用检查