|
|
@@ -2783,3 +2783,40 @@
|
|
|
数值(部门列 340px 上限、名称列占满剩余)都留了注释,后续要微调改一处即可
|
|
|
- **下一步最佳动作**:无(本轮已确认);功能清单里仍无 in_progress,候选方向见 Session 031
|
|
|
|
|
|
+## Session 066
|
|
|
+
|
|
|
+- **日期**:2026-09-20
|
|
|
+- **本轮目标**:用户反馈「给企业基础信息传值时,将企业名称传给后端字段 title」
|
|
|
+- **问题性质**:**我们漏写了 1888 的系统字段 `title`** —— 库里灌入的行本来就有
|
|
|
+ (09-17 那批),但**前端新建的行**会因为没传而被 DMS 落成**字符串 `"null"`**,
|
|
|
+ 在 DMS 列表里看不出是哪家企业。这与 1886 当初踩的是同一个坑
|
|
|
+ (`title` 只在创建那一刻初始化,之后改 `c_*` 字段不带动它)
|
|
|
+- **改法**:
|
|
|
+ - `classification-sync-utils.ts` 新增纯函数 **`withSystemTitle(row)`**:取 `c_name` 作为 `title`;
|
|
|
+ 值相同则**原样返回**(不产生无谓写入)、`c_name` 为空则**不动** `title`(不清存量)
|
|
|
+ - `company-info-sync.ts` 的 **`upsertEnterpriseRow` 一处**调用它 —— 1888 的两条入口
|
|
|
+ (工商信息 / 分类标签)共用这一处,所以两条路径都覆盖
|
|
|
+ - 因为是走 `diffEnterpriseRow` 的普通文本比较,**更新路径也会给历史遗留的
|
|
|
+ `title="null"` 补上企业名称**
|
|
|
+- **运行过的验证**:
|
|
|
+ - `npm run build` 通过
|
|
|
+ - **纯逻辑 84/84**(新增 5 项:取 c_name / 已相同不动 / `"null"` 被修正 / c_name 空不动 / diff 能捕获)
|
|
|
+ - **真实 DMS 32/32**(新增 2 项:新增行 title = 企业名称;**把已有行的 title 改成 `"null"` 后
|
|
|
+ 再同步 → 被修正**)
|
|
|
+ - **端到端 25/25**(新增 1 项:真实载荷同步后 title = 企业名称)
|
|
|
+ - 回归:适配层直通 10/10、载荷字段 12/12 仍绿
|
|
|
+- **已记录证据**:本文件 Session 066;三处新增断言;
|
|
|
+ `DMS_COLUMNS.md` §2.4 的 title 说明;`feature_list.json` 的对应条目
|
|
|
+- **提交记录**:见下条提交(已按约定提交推送)
|
|
|
+- **更新过的文件或工件**:`src/network/api/dms/{classification-sync-utils,company-info-sync}.ts`、
|
|
|
+ `harness/tools/{_entry-company-classify.ts, verify-company-classify-sync.mjs,
|
|
|
+ verify-company-classify-dms.mjs, verify-company-classify-e2e.mjs}`、
|
|
|
+ `harness/docs/reference/DMS_COLUMNS.md`、`harness/feature_list.json`、本文件
|
|
|
+- **已知风险或未解决问题**:
|
|
|
+ - ⚠️ 未走浏览器(改动在后台同步逻辑,触发链路未变);用户可在 DMS 里查看 1888 的
|
|
|
+ 「标题」列是否显示企业名称
|
|
|
+ - ✅ **历史数据已核查,无需补**:扫了 1888 前 6000 行(31 页 × 200),
|
|
|
+ **title 缺失或为 `"null"` 的行 = 0** —— 灌入行本来就有标题,前端此前也只建过测试行(已清理)。
|
|
|
+ 也就是说这个坑**只在「前端新建企业行」时才会触发**,本轮补上后不会再产生
|
|
|
+- **下一步最佳动作**:无(本轮已闭环);若要继续,见 Session 031 的候选优先级
|
|
|
+
|