BPOS-TMP-REPO/docs/数据域字段说明-E04-I01.md

# 数据域字段说明 —— E04 关系覆盖 · I01 品牌内容

> 对应**设计中心 → 数据域**(按活动分组的那一屏)。当前系统里装着的活动只有两个:
> `crm-relationship-coverage`(E04 关系覆盖与关键人经营,v2.1.9)与
> `brand-content-toolkit`(I01 品牌形象与销售工具包管理,v1.2.2)——
> 报价链 A1–A7 已于 2026-08-24 从系统卸载,它们的表不在本文范围内。
>
> 字段以**活动清单的台账声明**为准(`activities/<包>/src/manifest.ts` 的
> `declarations.ledger`)。那份声明同时是**授权面**:没声明的列写不进去,
> 也不会出现在件上、判据里、数据域的活动分组里。

---

## 怎么读这份文档

- **★ = 重点字段**。每张表挑 5–8 个,在「重点字段」小节里**按重要程度从高到低**排;
  数据结构表里在列名后打 ★。
- **【人填】= 人在活动过程中亲手填、提交后入库的字段** —— 执行工单的件上编辑,或数据录入卡。
  这类字段**一律进重点**:它们是这一单里唯一不能靠 AI 补出来的事实,AI 替它们编值就是编数据。
- 「写入者」一栏的口径:
  - **人(件上)** —— 工作区那份 HTML 上点「编辑」改的格子,保存即落草稿层
  - **人(录入卡)** —— 对话区的数据录入卡,人确认那一下基座直接落库
  - **AI** —— 模型按说明书与剧本写
  - **工具** —— 活动声明的工具算出来、AI 照抄落表
  - **基座** —— 平台自己生成(自增序号等),不问人也不经模型
  - **承继** —— 从本活动上一张表照抄过来,供只读展示
- 「约束」一栏的词:

| 词 | 含义 |
|---|---|
| 主键 | 认行的钥匙。件上主键格也挂着绑定,那是为了认行,不是让人改 |
| 自增 | 基座按「同组主键值-两位序号」续号(如 `CU-0142-02`),不进表单 |
| 必填 | 件上红带 / 执行卡提交闸 / 放行门判据**三处同源**,缺了交不了卷 |
| 建议填 | 橘色占位提示,只提示不拦单 |
| 取值域 | 只许写列出的那几个值(tally),基座据此出分档计数 |
| 引用 | 值必须在另一张表里真实存在,查无此值写入当场被拒 |
| 去重计数 | 基座数「有几个不同的值」,判据拿它做闭合(如「计划盖住了几家客户」) |
| 发布时必填 | 行的状态流到某个值才必填(如内容状态 = 已发布) |
| 脱敏 | 展示与留痕按脱敏口径处理 |

### 一览

| 活动 | 台账地址 | 人读名 | 性质 | 字段数 | 重点 | 人填列 |
|---|---|---|---|---|---|---|
| E04 | `customer.profile` | 客户档案(L-02 客户主台账) | 主数据 · 共享 | 8 | 6 | 5 |
| E04 | `customer.contact` | 客户联系人(L-08) | 主数据 · 共享 | 12 | 8 | 7 |
| E04 | `crm_coverage.candidate` | 候选覆盖客户清单 | 本活动工作台账 | 9 | 7 | 6 |
| E04 | `crm_coverage.plan` | 关键人经营计划 | 本活动工作台账 | 12 | 8 | 0(只审批,不直接改) |
| E04 | `crm_coverage.receipt` | 经营计划执行回执 | 本活动工作台账 | 11 | 6 | 4 |
| E04 | `crm_coverage.ledger_update` | 台账更新明细 | 本活动工作台账 | 11 | 7 | 0 |
| E04 | `crm_coverage.verdict` | 本轮覆盖结论 | 本活动工作台账 | 10 | 6 | 0 |
| I01 | `market.signal` | 宏观市场台账(L-01) | 主数据 · **只读** | 14 | 6 | 0 |
| I01 | `content.asset` | 品牌内容库(L-05) | 主数据 · I01 唯一读写者 | 14 | 8 | 0 |
| I01 | `content_brand.requirement` | 内容需求清单 | 本活动工作台账 | 8 | 6 | 4 |
| I01 | `content_brand.verdict` | 本轮内容生产结论 | 本活动工作台账 | 10 | 6 | 0 |

---

## 一、E04 关系覆盖与关键人经营

七步:识别候选客户 → **覆盖范围确认(人)** → 缺口分析与制定计划 → **经营计划审批(人)** →
**执行经营动作与回执(人)** → 更新关系台账 → **放行收口(人)**。
四道人环里有三道会往台账里写下人亲手填的事实。

### 1.1 `crm_coverage.candidate` 候选覆盖客户清单

本轮要经营哪几家客户。**AI 先识别出候选基线,人在「覆盖范围确认」那一屏增删改** ——
加一行 = 额外纳入(AI 没识别到但人有价值判断的客户),删一行 = 排除,改格子 = 修正。
人加的行同等作数:后面的计划、回执、收口都得盖住它(`计划里不同客户数 = 候选行数` 是硬闭合)。

**重点字段(按重要程度)**

1. `customer_code` ★【人填】主键之一、必填 —— 覆盖闭合判据的分母,人加行时自己填
2. `customer_name` ★【人填】必填 —— 卡面、计划、回执上的「对象」都从它来
3. `bt_level` ★【人填】决策链层级,重算覆盖度的入参
4. `depth` ★【人填】本轮要做到多深(维护 / 突破 / 首访)
5. `basis` ★【人填】纳入依据 —— 人加的那一行为什么值得经营,只有他说得出
6. `cust_type` ★【人填】客户类型,有客户档案就抄档案
7. `status` ★ 状态 —— 收口时置「已覆盖」,界面上的状态徽靠它

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 覆盖轮次编号 | text | 主键 | AI | 案号,按开案时刻铸(含年秒,跨单唯一) |
| `customer_code` ★ | 客户编码 | text | 主键 · 必填 | AI / **人(件上)** | 新客户由录入卡现场给码,AI 不许自编 |
| `customer_name` ★ | 客户名称 | text | 必填 | AI / **人(件上)** | |
| `cust_type` ★ | 客户类型 | text | 建议填 | AI / **人(件上)** | 有 `customer.profile.cust_type` 就抄它 |
| `bt_level` ★ | BT 层级 | text | 建议填 | **人(件上下拉)** | 存 ASCII(`bt-01/02/03`),件上摆人读名「BT-01 · 采购/供应链」 |
| `status` ★ | 状态 | text | 取值域 `pending` / `covered` / `excluded` | AI | S6 收口时置 `covered` |
| `basis` ★ | 纳入依据 | text | 建议填 | AI / **人(件上)** | |
| `depth` ★ | 覆盖深度 | text | 建议填 | **人(件上下拉)** | |
| `origin` | 来源 | text | — | AI | `ai` / `human-added`,标出哪几行是人加的 |

### 1.2 `crm_coverage.plan` 关键人经营计划

一位关键人一行:该做什么动作、什么时候做、为什么。**件是只读的** ——
业务口径写死「人只做审批,不能直接改结论」;人点「重做」并写意见,AI 按意见改了再重新提交。
意见里点名哪一家/哪一位,基座会先按字面比对把归属摆给模型,不让它凭印象挑行。

**重点字段(按重要程度)**

1. `contact_code` ★ 主键之一 · **引用** `customer.contact.contact_code` —— 计划只许指向真实存在的人
2. `customer_code` ★ 必填 · **去重计数** —— 「计划盖住了几家客户」就是数它
3. `action` ★ 必填 —— 建议动作,审批被驳回时最常改的一格
4. `target_date` ★ 必填 —— 没有时间点的建议不算数,验收判据点名核它
5. `rationale` ★ 必填 —— 理由;驳回重做时若没写具体意见,先改实这一格
6. `rank_score` ★ 必填 —— 排序分,模版不排序,必须已按此列降序写入
7. `priority` ★ 必填 · 取值域 —— 优先级
8. `relationship_gap` ★ 必填 —— 亲密度缺口(目标亲密度 − 当前亲密度)

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 覆盖轮次编号 | text | 主键 | AI | |
| `contact_code` ★ | 联系人编码 | text | 主键 · 引用 `customer.contact.contact_code` | AI | 查无此码当场拒,并指路「先发录入卡把人收进来」 |
| `customer_code` ★ | 客户编码 | text | 必填 · 去重计数 | AI | 覆盖闭合判据的落点 |
| `customer_name` | 客户名称 | text | 建议填 | AI | |
| `contact_name` | 联系人姓名 | text | 建议填 | AI | |
| `action` ★ | 建议动作 | text | 必填 | AI(可按人的驳回意见改) | |
| `priority` ★ | 优先级 | text | 必填 · 取值域 `high` / `medium` / `low` | AI | |
| `rationale` ★ | 理由 | text | 必填 | AI | |
| `influence` | 影响力(写计划那一刻的快照) | text | 必填 | AI | 抄自联系人档案 |
| `relationship_gap` ★ | 亲密度缺口 | integer | 必填 | 工具 → AI | |
| `rank_score` ★ | 排序分 | number | 必填 | 工具 `rank-key-persons` → AI | |
| `target_date` ★ | 建议动作时间点 | date | 必填 | AI | |

### 1.3 `crm_coverage.receipt` 经营计划执行回执

**这张表是「人填后入库」最典型的一张**:S3 只写骨架(与计划一一对应,行数必须相等),
完成状态那几列全部留空;人真的去拜访/沟通完,在「执行经营动作与回执」那一屏把结果填回来。
空手交卷会被提交闸拦住,并点名缺在哪一行哪一格。

**重点字段(按重要程度)**

1. `completion_status` ★【人填】必填 · 取值域 —— 这件事到底办没办成
2. `result_summary` ★【人填】必填 —— 见到谁、谈了什么、达成什么(多行文本)
3. `key_person_change` ★【人填】必填 · 取值域 —— 关键人有没有变动,变了就触发主数据改档
4. `customer_feedback` ★【人填】建议填 —— 客户态度 / 诉求 / 下一步信号(多行文本)
5. `contact_code` ★ 主键之一 · 引用 —— 与计划一一对应,回执行数 = 计划行数是硬门
6. `customer_name` ★ 承继 —— 件上「对象」列长「客户名 · 关键人」,两个名字都得在

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 覆盖轮次编号 | text | 主键 | AI | |
| `contact_code` ★ | 联系人编码(与计划一一对应) | text | 主键 · 引用 `customer.contact.contact_code` | AI | |
| `customer_code` | 客户编码 | text | 建议填 | 承继自计划 | |
| `customer_name` ★ | 客户名称 | text | — | 承继自计划 | 只读展示 |
| `contact_name` | 联系人姓名 | text | 建议填 | 承继自计划 | |
| `action` | 计划动作 | text | — | 承继自计划 | 只读展示,人照着它去执行 |
| `target_date` | 建议时间点 | date | — | 承继自计划 | 只读展示 |
| `completion_status` ★ | 完成状态 | text | 必填 · 取值域 `done` / `partial` / `skipped` | **人(件上下拉)** | |
| `result_summary` ★ | 结果摘要 | text | 必填 | **人(件上多行文本)** | |
| `customer_feedback` ★ | 客户反馈 | text | 建议填 | **人(件上多行文本)** | |
| `key_person_change` ★ | 关键人变动 | text | 必填 · 取值域 `changed` / `unchanged` | **人(件上下拉)** | |

### 1.4 `customer.profile` 客户档案(L-02 客户主台账 · 共享主数据)

E04 平时只读它;两个例外会写:①**新客户建立合作**那一刻代行建档职责(数据录入卡);
②收口时写回关系经营的结果(覆盖度、决策链地图、互动时间线)。
放行前那一屏有「将写入的客户档案」落库预览 —— 摆的是**签下去之后这一行长什么样**,可就地改。

**重点字段(按重要程度)**

1. `customer_code` ★【人填】主键 —— 新客户的编码由人在录入卡上现场给,AI 不许自编
2. `coverage_score` ★ 必填 —— 本活动的核心产出:关系覆盖度,由工具重算后写回
3. `decision_chain` ★ 必填 —— 决策链地图(JSON),覆盖缺口从它算出来
4. `name` ★【人填】必填 —— 无名档案进不了正式表(2026-08-24 立的墙)
5. `cust_type` ★【人填】建议填 —— 客户类型
6. `interaction_timeline` ★ 建议填 —— 互动时间线(JSON),每次整个数组重写

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `customer_code` ★ | 客户编码 | text | 主键 | **人(录入卡)** / 既有客户沿用 | 主数据主键,编错一次后面每一单都跟着错 |
| `name` ★ | 客户名称 | text | 必填 | **人(录入卡 / 件上)** | |
| `industry` | 所属行业 | text | 建议填 | **人(录入卡 / 件上)** / AI 推 | 推不出就留空给人补,不许编 |
| `region` | 区域 | text | 建议填 | **人(录入卡 / 件上)** / AI 推 | 同上 |
| `cust_type` ★ | 客户类型 | text | 建议填 | **人(录入卡 / 件上)** | 存中文枚举字面值,不带取值域 |
| `coverage_score` ★ | 关系覆盖度 | integer | 必填 | 工具 `recompute-score` → AI | |
| `decision_chain` ★ | 决策链地图 | json | 必填 | AI | `{nodes:[{node,btLevel,required,contactCode,covered}]}` |
| `interaction_timeline` ★ | 互动时间线 | json | 建议填 | AI | `{entries:[{date,type,contactCode,note}]}`,追加式重写 |

### 1.5 `customer.contact` 客户联系人(L-08 · 共享主数据)

计划与回执都**引用**这张表:计划只能指向这里真实存在的人。
候选客户查无联系人时,S3 先发**数据录入卡**把第一位关键人收进来(人填姓名/职务/决策链节点),
编码由基座续号;放行前那一屏还可以再加一行(编码留空即可)。

**重点字段(按重要程度)**

1. `contact_code` ★ 主键之一 · **自增** —— 计划/回执的引用目标;人不用填,基座按「客户编码-两位序号」续号
2. `name` ★【人填】必填 —— 无名联系人进不了正式表
3. `relationship` ★【人填】必填 —— 关系亲密度 1–5,缺口与排序分的入参
4. `influence` ★【人填】必填 · 取值域 —— 影响力评级
5. `key_person` ★【人填】必填 —— 关键人标记,覆盖度的分子
6. `decision_node` ★【人填】建议填 —— 决策链节点(采购 / 技术 / 高层)
7. `title` ★【人填】职务
8. `customer_code` ★ 主键之一 —— 这位联系人属于哪家客户

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `customer_code` ★ | 客户编码 | text | 主键 | 承继 | |
| `contact_code` ★ | 联系人编码 | text | 主键 · 自增 | **基座** | 声明里标了 `auto`,件上留空即续号 |
| `name` ★ | 姓名 | text | 必填 | **人(录入卡 / 件上)** | |
| `title` ★ | 职务 | text | — | **人(录入卡 / 件上)** | |
| `email` | 邮箱 | text | 脱敏 | **人(录入卡)** | |
| `role` | 角色 | text | 建议填 | AI | |
| `decision_node` ★ | 决策链节点 | text | 建议填 | **人(录入卡 / 件上下拉)** | `bt-01` 采购 / `bt-02` 技术 / `bt-03` 高层 |
| `influence` ★ | 影响力评级 | text | 必填 · 取值域 `high` / `medium` / `low` | **人(件上下拉)** / AI 初评 | |
| `relationship` ★ | 关系亲密度(1-5) | integer | 必填 | **人(件上)** / AI 初评 | |
| `comm_pref` | 沟通偏好 | text | 建议填 | AI | |
| `key_person` ★ | 关键人标记 | boolean | 必填 | **人(件上下拉)** / AI | |
| `change_log` | 变动记录 | text | — | AI | 入职 / 离职 / 调岗留痕 |

### 1.6 `crm_coverage.ledger_update` 台账更新明细

「这一签下去,哪几张台账的哪几格会变成什么」——一处字段一行,给签字的人核对用。
放行时人可以点重做,AI 按意见改;改过的那一处**同位置覆盖写**,老行要撤掉,不许两条并存。

**重点字段(按重要程度)**

1. `update_key` ★ 必填 · **去重计数** —— 更新位置键(台账地址 · 客户 · 联系人 · 字段),同一处只许留一条
2. `field_label` ★ 必填 —— 改的是哪一格(人读列名,不写机器列名)
3. `after_value` ★ 必填 —— 更新后的值
4. `before_value` ★ 必填 —— 更新前的值(无值写「(无)」)
5. `evidence_ref` ★ 必填 —— 依据,用人话引用回执事实(不写编码前缀)
6. `ledger_label` ★ 必填 —— 改的是哪张台账(人读名)
7. `customer_code` ★ 必填 —— 落在哪家客户头上

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 覆盖轮次编号 | text | 主键 | AI | |
| `update_seq` | 本轮更新序号 | integer | 主键 | AI | |
| `ledger_label` ★ | 台账(人读名) | text | 必填 | AI | 如「客户联系人」 |
| `ledger_address` | 台账地址(机器地址) | text | 必填 | AI | 如 `customer.contact` |
| `customer_code` ★ | 客户编码 | text | 必填 | AI | |
| `contact_code` | 联系人编码 | text | 建议填 | AI | 空 = 客户级字段 |
| `field_label` ★ | 字段(人读列名) | text | 必填 | AI | |
| `before_value` ★ | 更新前 | text | 必填 | AI | 无值写「(无)」 |
| `after_value` ★ | 更新后 | text | 必填 | AI | |
| `evidence_ref` ★ | 依据 | text | 必填 | AI | 用人话引回执:「某某某·某某的回执:……」 |
| `update_key` ★ | 更新位置键 | text | 必填 · 去重计数 | AI | `台账地址\|客户\|联系人\|字段` |

### 1.7 `crm_coverage.verdict` 本轮覆盖结论

一单一行的收口结论,同时挂着几面「人环走到哪儿了」的记账旗 —— 它们是下一步能不能开工的哨兵。

**重点字段(按重要程度)**

1. `scope_confirmed_total` ★ —— 覆盖范围已确认(人确认过才写),制定计划那一步的入场哨兵
2. `plan_approved_total` ★ —— 经营计划已审批通过,派执行回执单的入场哨兵
3. `ledger_update_confirmed_total` ★ —— 台账更新已收口
4. `summary` ★ —— 本轮覆盖结论(摆在归档件上的那段话)
5. `covered_customer_total` ★ —— 本轮覆盖客户数
6. `key_person_covered_total` ★ —— 本轮覆盖关键人数

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 覆盖轮次编号 | text | 主键 | AI | |
| `trigger_label` | 触发方式(人读标签) | text | — | AI | 写下之前那一格真空着,不摆入参英文码 |
| `event_type` | 事件类型 | text | — | AI | 月度例行留空 |
| `note` | 本轮说明 | text | — | AI | |
| `scope_confirmed_total` ★ | 覆盖范围已确认 | integer | — | AI | 人环凭据 |
| `plan_approved_total` ★ | 经营计划已审批通过 | integer | — | AI | 人环凭据 |
| `ledger_update_confirmed_total` ★ | 台账更新已收口 | integer | — | AI | |
| `covered_customer_total` ★ | 本轮覆盖客户数 | integer | — | AI | |
| `key_person_covered_total` ★ | 本轮覆盖关键人数 | integer | — | AI | |
| `summary` ★ | 本轮覆盖结论 | text | — | AI | |

> 注:执行回执那一步**没有**记账旗 —— 回执四列全是人填的,门直接读基座数
> (回执有几行、缺不缺必填),被叫的那一方不给自己记账。

---

## 二、I01 品牌形象与销售工具包管理

五步:需求识别 → **需求受理与信息补充(人)** → 采集与创作 → **初稿审核(人)** →
拟发布 → **发布入库放行(人)**。人填的事实集中在第一道人环;后两道是审核与签字。

### 2.1 `content_brand.requirement` 内容需求清单

本轮要生产哪几份内容。AI 出候选基线,**人在「需求受理与信息补充」那一屏增删改** ——
加一行 = 补充新需求,删一行 = 本轮不做,改格子 = 修正 AI 识别的内容。
序号留空由基座续号(人加行时不用自己编号)。

**重点字段(按重要程度)**

1. `content_type` ★【人填】必填 —— 要产出什么(公司介绍 / 能力声明 / 销售工具包 / 案例集 / 白皮书…)
2. `scene` ★【人填】建议填 —— 适用场景,S3 会照抄进品牌内容库那一行
3. `target_customer` ★【人填】建议填 —— 目标客户(定向版本从它来)
4. `source` ★【人填】建议填 —— 需求来源(战略调整 / 新市场 / 工具过期 / 使用方请求)
5. `req_seq` ★【人填/基座】主键之一 —— 人加行时留空,基座按现有最大序号 +1 续号
6. `priority` ★ 取值域 —— 优先级,件上是只读徽标

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 案号 | text | 主键 | AI | |
| `req_seq` ★ | 本轮需求序号 | integer | 主键 | AI / **基座续号** | 件上加行留空即续号 |
| `content_type` ★ | 内容类型 | text | 必填 | AI / **人(件上)** | |
| `source` ★ | 需求来源 | text | 建议填 | AI / **人(件上)** | |
| `target_customer` ★ | 目标客户 | text | 建议填 | AI / **人(件上)** | |
| `scene` ★ | 适用场景 | text | 建议填 | AI / **人(件上)** | 存人读标签(首触 / 方案 / 攻坚 / 展会 / 报价),不存 ASCII 码 |
| `priority` ★ | 优先级 | text | 取值域 `high` / `medium` / `low` | AI | 件上只读徽标 |
| `origin` | 来源 | text | — | AI | `ai` / `human-added` |

### 2.2 `content.asset` 品牌内容库(L-05 · 主数据,I01 是唯一读写者)

**一行 = 一份资料文件**。正文只写一份 Markdown,基座按格式列现造成真字节
(.docx 用 Word 打得开、.xlsx 用 Excel 打得开),件上点资料名就能打开渲染、下载原件;
放行那一刻还会把每一份**冻进存档**,归档件里点开的永远是签字那一刻的那一份。

**重点字段(按重要程度)**

1. `content_id` ★ 主键 —— 资料的身份;件上的资料名链接、存档、下载都按它认
2. `title` ★ 必填 —— 内容标题,同时就是资料文件名
3. `body_md` ★ 必填 —— 内容正文(Markdown 原文),**文件的字节从它现造**
4. `file_format` ★ 必填 · 取值域 —— 决定造出哪种文件:表格用 `xlsx`、正式文档用 `docx`、网页用 `html`、短要点用 `md`
5. `content_status` ★ 必填 · 取值域 —— 草稿 → 已审核 → 已发布,不许跳步
6. `scene` ★ 建议填 · **发布时必填** —— 适用场景,状态一到已发布就三处同源地拦
7. `bt_tag` ★ 建议填 · **发布时必填** —— BT 层级标签
8. `content_type` ★ 必填 —— 内容类型

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `content_id` ★ | 内容ID | text | 主键 | AI | |
| `content_type` ★ | 内容类型 | text | 必填 | AI | 抄需求清单那一行 |
| `title` ★ | 内容标题 | text | 必填 | AI | 资料文件的标题与文件名 |
| `language` | 语言版本 | text | 必填 | AI | 多语言用「 · 」连接 |
| `version` | 版本号 | text | 必填 | AI | 审核通过后升版 |
| `scene` ★ | 适用场景 | text | 建议填 · 发布时必填 | AI | 状态 = 已发布 时才拦 |
| `bt_tag` ★ | BT 层级标签 | text | 建议填 · 发布时必填 | AI | 存人读值(`BT-01`/`BT-02`/`BT-03`) |
| `content_status` ★ | 内容状态 | text | 必填 · 取值域 `draft` / `reviewed` / `published` / `deprecated` | AI | 人在决策卡上审核,AI 据此改状态 |
| `brand_tone` | 品牌调性标签 | text | 建议填 | AI | |
| `target_customer` | 定向客户版本 | text | — | AI | |
| `body_md` ★ | 内容正文(Markdown 原文) | text | 必填 | AI | 资料文件的唯一正文来源 |
| `file_format` ★ | 资料文件格式 | text | 必填 · 取值域 `md` / `html` / `docx` / `xlsx` | AI | 按内容形态挑 |
| `file_ref` | 文件位置 | text | — | AI | |
| `reviewer` | 审核人 | text | — | AI | 审核通过后补一句 |

> 这张表声明了 `file` 段(标题取 `title`、正文取 `body_md`、格式取 `file_format`)——
> 那一段同时是**授权面**:不声明它,件上的资料名点不开。

### 2.3 `market.signal` 宏观市场台账(L-01 · 主数据,I01 **只读**)

创作那一步的市场依据从这儿取。I01 一个字都不写它,读不到相关信号时如实说读不到,不许编造。

**重点字段(按重要程度)**

1. `signal_id` ★ 主键 —— 引用信号时点它
2. `title` ★ —— 信号标题,创作时的依据摘要从它来
3. `content` ★ —— 详情正文
4. `signal_type` ★ 取值域 —— 宏观经济 / 行业趋势 / 竞争 / 政策 / 客户市场
5. `importance` ★ —— 重要性评分 1–5,挑哪几条先看
6. `impact_dir` ★ 取值域 —— 机会 / 威胁 / 中性

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `signal_id` ★ | 信号ID | text | 主键 | 外部 / 其它活动 | I01 只读 |
| `signal_type` ★ | 信号类型 | text | 取值域 `macro_economy` / `industry_trend` / `competition` / `policy` / `customer_market` | — | |
| `title` ★ | 标题 | text | — | — | |
| `content` ★ | 详情 | text | — | — | |
| `source` | 信号来源 | text | — | — | |
| `signal_date` | 信号日期 | date | — | — | |
| `market_region` | 所属市场 | text | — | — | |
| `industry` | 细分行业 | text | — | — | |
| `chip_category` | 关联芯片品类 | text | — | — | |
| `importance` ★ | 重要性评分(1-5) | integer | — | — | |
| `impact_dir` ★ | 影响方向 | text | 取值域 `opportunity` / `threat` / `neutral` | — | |
| `signal_status` | 信号状态 | text | 取值域 `pending` / `evaluated` / `archived` / `expired` | — | |
| `version` | 版本号 | text | — | — | |
| `review_note` | 复盘备注 | text | — | — | |

### 2.4 `content_brand.verdict` 本轮内容生产结论

一单一行的收口结论,同样挂着人环记账旗。

**重点字段(按重要程度)**

1. `requirement_confirmed_total` ★ —— 需求已确认,采集创作那一步的入场哨兵
2. `draft_approved_total` ★ —— 初稿已审核通过,拟发布那一步的入场哨兵
3. `publish_prepared_total` ★ —— 发布准备已收口
4. `content_produced_total` ★ —— 本轮产出内容份数
5. `summary` ★ —— 本轮生产结论
6. `trigger` ★ —— 触发方式(人读标签)

**数据结构**

| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
|---|---|---|---|---|---|
| `round_ref` | 案号 | text | 主键 | AI | |
| `trigger` ★ | 触发方式(人读标签) | text | — | AI | |
| `trigger_detail` | 触发细节(人读标签) | text | — | AI | |
| `target_customer` | 定向客户 | text | — | AI | |
| `note` | 本轮说明 | text | — | AI | |
| `requirement_confirmed_total` ★ | 需求已确认 | integer | — | AI | 人环凭据 |
| `draft_approved_total` ★ | 初稿已审核通过 | integer | — | AI | 人环凭据 |
| `publish_prepared_total` ★ | 发布准备已收口 | integer | — | AI | |
| `content_produced_total` ★ | 本轮产出内容份数 | integer | — | AI | |
| `summary` ★ | 本轮生产结论 | text | — | AI | |

---

## 三、人填字段总表(按人办事的那一屏)

| 活动 · 屏 | 卡的形式 | 落进哪张表 | 人亲手填的列 |
|---|---|---|---|
| E04 · 覆盖范围确认 | 执行工单(件上编辑 + 增删行) | `crm_coverage.candidate` | `customer_code` · `customer_name` · `cust_type` · `bt_level` · `depth` · `basis` |
| E04 · 新客户建档(仅新客户) | 数据录入卡(一卡两段) | `customer.profile` + `customer.contact` | 客户段:`customer_code` · `name` · `cust_type` · `industry` · `region`;联系人段:`name` · `title` · `email` |
| E04 · 新纳入客户补关键人 | 数据录入卡 | `customer.contact` | `name` · `title` · `decision_node`(编码基座续号) |
| E04 · 经营计划审批 | 决策卡(通过 / 重做 + 意见) | 间接改 `crm_coverage.plan` | 意见文本(AI 据此改 `action` / `rationale` / `target_date`) |
| E04 · 执行经营动作与回执 | 执行工单(件上编辑) | `crm_coverage.receipt` | `completion_status` · `result_summary` · `customer_feedback` · `key_person_change` |
| E04 · 台账更新确认(放行前) | 验收工单(落库预览可改 · 联系人可加行) | `customer.profile` · `customer.contact` | 档案:`name` · `cust_type` · `industry` · `region`;联系人:`name` · `title` · `decision_node` · `influence` · `relationship` · `key_person` |
| I01 · 需求受理与信息补充 | 执行工单(件上编辑 + 增删行) | `content_brand.requirement` | `content_type` · `source` · `target_customer` · `scene`(`req_seq` 留空续号) |
| I01 · 初稿审核 | 决策卡(通过 / 驳回 + 意见) | 间接改 `content.asset` | 意见文本(AI 据此改稿并升状态) |
| I01 · 发布入库放行 | 验收工单(签字) | `content.asset` 合并进正式表 | 裁决与意见 |

---

## 四、在数据域里看这些表时的三条提醒

1. **主数据是共享的,物理表里还有别的活动留下的列。**
   `customer.profile` 物理上还有 `grade` / `owner` / `payment_terms` / `credit_limit` /
   `profile_tags` / `status`,`customer.contact` 还有 `phone` —— 那是报价链 A1 早先声明的,
   E04 不写它们,本文也不列。记录浏览里看到它们空着是正常的。

2. **台账只增列不删列:退役的列还在。**
   `crm_coverage.plan.status`、`crm_coverage.verdict` 的 `trigger` / `event_note` /
   `receipt_confirmed_total` 都已退役,当前版本一个字都不写(为什么退役见清单里的墓志铭注释)。
   判断一列还算不算数,以**活动清单的声明**为准,不以物理表结构为准。

3. **试跑单默认也落真库。**
   测试台起单默认 `land_master = true` —— 跑一遍活动,主数据真的会变
   (新客户、新联系人、覆盖度都会落进正式表)。要它不落,起单时显式关掉
   (端到端脚本就是这么做的:只能测一次的样例归脚本自己管)。

---

*字段口径以 `activities/crm-relationship-coverage/src/manifest.ts` 与
`activities/brand-content-toolkit/src/manifest.ts` 的 `declarations.ledger` 为准;
业务设计源见 `docs/SS01-客户与市场/Demo-E04-I01-Activity台账关联与设计.html`
与 `docs/SS01-客户与市场/E04I01-Demo-台账设计/*.xlsx`(L-01 / L-02 / L-05 / L-08)。*