需求采集与十域划分流程

适用场景

从家庭治理的真实诉求出发，把零散的家庭管理需求收敛为十个领域（域）并固化成可驱动台账的 ledgers.SPECS 时触发。这是 HFMS 的源头需求工程，决定全链路编号同源。触发词：需求采集、域划分、十域、编号同源、SPECS 驱动。

操作步骤

1. 需求基线：以《家庭体系管理制度汇编总册》及家庭治理十域（客户数据源 的 0-家庭治理制度 … 9-日常生活运营 10 域 docx）为需求基线，不凭空设计。
2. 域划分：将家庭管理诉求归并为 10 个领域，二字母编码 ZL/HL/CW/ED/ZQ/LW/DA/RE/SE/OP（治理/健康/财务/学业/资产/劳务/档案/关系/安全/运营）。编码稳定后全链路同源。
3. 制度编号＝域编号：十体系编号即制度编号（ledgers.py L2 注释）；台账 key（zl/hl/…/op）与制度编号（ZL/HL/…/OP）一一对应，制度条款改 → 台账字段同向改。
4. 家庭成员即服务对象：config.MEMBERS / MEMBER_ROLES（config.py L64）定义 U1–U4 四成员及角色，需求围绕其生命周期（含未成年人信息，仅本机/内网）。
5. 非功能性需求约束（贯穿硬约束）：纯标准库零依赖、LAN 可访问、隐私红线（含未成年人信息不出本机/内网）、禁出公网。
6. 固化 SPECS：每个域一张 ledgers.SPECS 定义（L12，fields=(列名,标签,类型,必填,选项串)）；建表/增改删/列表/表单由 SPECS 统一生成，避免十套重复代码。

注意边界

• 域划分与编码要稳：一旦定下，全链路（制度/台账/索引/展示）同源，不可漂移。
• 需求变更走「制度升版」而非改编码；NFR 是硬约束，不可妥协为「以后优化」。
• tail4 类隐私字段（证件号）入库只留后四位（ledgers.py L6），属需求级红线。

反例避雷

• 域划分随意 → 编号漂移 → 制度与台账 mapping 错乱、索引答非所问。
• 把 NFR 当可选 → 隐私事故（未成年人信息出本机）；纯标准库零依赖被破 → 部署绑定第三方。
• 每域各写一套代码 → 重复维护、十表逻辑分叉；必须 SPECS 驱动。

关联笔记

• [[技能｜三级架构与十域编码规则]]
• [[技能｜一数一源架构原则]]
• [[技能｜台账体系SPECS驱动扩展法]]
• [[技能｜制度需求与台账映射规则]]

实战战绩

2026-09 落地：十域划分 + SPECS 驱动，十体系台账零重复代码上线；四成员角色贯穿权限与展示；NFR（零依赖/LAN/隐私）全程守住。

版本记录