# DMS优先公司检索（F069）

API与CLI共用CompanyClient。每个新问题先查DMS「营商助手－企业基础信息」，唯一全名或完整统一社会信用代码精确匹配时自动确认；其他情况按名称包含查询结果的字符串相似度展示最多3家，用户选择后才读取完整基础资料。基础资料读取成功、名称/代码/记录ID复核一致后，才访问「企业荣誉信息」元数据与记录，按信用代码精确关联。

用户已确认读取草稿（states=0）。基础栏目1888、荣誉栏目1886为本次真实核验目标；运行时核对各栏目名称、父栏目「营商助手」、模型字段类型，不扫描其他模型。不修改DMS记录，不把企业资料写入开发文档。

## 候选与企查查补充

- DMS无候选时自动进入企查查；DMS服务失败也尝试企查查，并在errors保留`dms_search:错误码`，不把失败描述为本地无企业。
- DMS有候选且需确认时，`interrupt.actions.more={}`，`result.can_search_more=true`。后端在result.candidates末尾追加“搜索更多公司”操作项（最多3家公司＋1个操作项），沿用现有列表渲染，无需新增按钮。该项KeyNo为`action:search_more_companies`，其余公司字段为null；选择它时仍按现有方式提交序号、名称、KeyNo或候选JSON字符串，也支持`/more`。它仅用于中断展示，不进入真实候选状态、company_info或工商/荣誉查询。
- 选择更多后用原公司线索查企查查第一页；唯一全名/信用代码精确匹配继续画像，否则仍展示企查查候选并支持/next。企查查候选不再提供more。公司信息来自哪个渠道，其工商和荣誉查询就使用哪个渠道。
- DMS候选确认仍支持序号、准确名称、信用代码、当前KeyNo及既有候选JSON字符串。只能选择当前检查点候选，不信任前端传来的画像字段。
- 补充新关键词从DMS重新查询；新问题重置查询渠道。翻页、重试及more依旧受每轮最多5次搜索约束。查询渠道保存在会话检查点，不使用全局公司状态。
- 基础确认后的读取失败或身份变化会停止画像，不静默换成另一家公司；荣誉失败标记不完整。荣誉表没有记录时为成功的空列表，不因此改用企查查，也不能推断企业绝无其他资质。

精确比较只去掉用户线索首尾空白，不忽略内部空格、括号、大小写或企业后缀。DMS名称匹配采用服务端包含查询后排序，不是语义检索或任意错别字纠正；恰有18位英文字母/数字的线索查询信用代码。最多扫描5页、每页200条，范围内取前三；未读全时complete=false且禁止自动确认，仍可选择或搜索更多，不声称全库最佳三家。

## 与企查查相同的业务结构

company_info仍为`{company, profile, honors}`；profile为`{data,source}`，honors为`{records:[{data,source}],sources,complete,error}`。DMS缺少的字段为null，不编造数据。企查查分支继续保留原始供应商字段。

基础资料按dms_company.BASIC_FIELDS白名单转换，例如c_name→Name、c_credit_code→CreditCode、c_regist_capi→RegistCapi、c_scope→Scope。资本币种使用RegisteredCapitalCCY/PaidUpCapitalCCY；Area/RevokeInfo/OriginalName/DesignatedRepresentativeList从JSON文本还原结构，并过滤非约定嵌套键。保留企查查返回的TeamEnd兼容别名，值取TermEnd。基础表的标签、联系方式、经营范围简述及额外行业字段不透传。

荣誉按c_credit_code关联，逐条转换为Name/Level/Source/PublishOffice/PublishDate/BegingDate/DeadLine/CertificateCode，保留BegingDate原拼写。真实数据核验发现c_name字段标签虽为“公司名称”，当前存量值实际是荣誉名称，映射为Name，不能拿来关联企业；c_id/c_created_at/c_tag_name/c_honor等不冒充企查查字段。荣誉名缺失或等于已确认公司名视为资料异常。最多50页、每页200条；中途失败保留已读取记录并标记complete=false。

DMS没有企查查KeyNo，因此候选与profile中的KeyNo为`dms:1888:<记录ID>`，仅用作当前候选选择标识，不能直接传给企查查。source.provider为DMS，column_id/model_id/record_id/fetched_at/record_updated_at/state保留来源与时效；api_code表示兼容字段结构，document_url=null，不伪造企查查来源链接。企查查仍返回自身KeyNo与来源信息。

## 配置、错误和验证

复用现有DMS认证配置及自动登录/有界token刷新，不修改.env，不额外要求企查查凭据才能读取DMS命中的企业。严格作用域开启时，DMS_ALLOWED_SCOPES_JSON须精确允许「营商助手」下的「企业基础信息」「企业荣誉信息」；不因配置了会话表就扩权。现有会话分析仍单独检查它自己的两个栏目。

已实测本部署内容列表在无数据时返回`code=202,message="数据不存在",content="数据不存在"`。只有企业适配器的内容列表接口匹配这三项时才转为空列表；201/212、未知202、其他接口与服务错误继续报错，既有会话写入语义不变。请求超时沿用20秒，每次分页扫描受DMS_SCAN_TIMEOUT_SECONDS约束；记录数量变化、重复ID、跨栏目/状态、过滤条件未生效均拒绝冒充完整结果。

合成验证：第三步和第四步API测试包含字段白名单、精确匹配、三候选、多荣誉/空荣誉、基础失败不查询荣誉、more与企查查翻页、Redis序列化恢复、跨会话和错误回退。第五步回归保护共用DMS认证配置。

真实只读检查：`.\.venv\Scripts\python.exe -X utf8 -m src.step3_question_answer.dms_company_check`，仅打印布尔检查与计数，不输出企业值、保存资料或调用模型。真实DMS检查不等于生产全链路/外部前端验收；生效需要重启后端，前端沿用候选列表与选择提交方式。旧已保存画像不回填。