REF-0.1.0 · 已发布试行

独立公司样板与标准库

技术与运营平台保存可复用方法；独立公司保存自己的业务规则、数据与权限。采用同一标准不产生共享数据库、访问权限、收入或股东关系。

两层职责

技术与运营平台

保存通用标准、适用范围、检查方法、版本、验证证据和采用记录。

独立人力服务公司

保存具体业务规则、字段、接口、页面和本公司运行数据。

公开标准页只包含方法、模式与合成案例摘要，不包含人员、证件、客户合同、凭据或私有媒体。复用循环为：提出规则 → 人力样板具体实现 → 框架验收 → 三条实际模拟案例 → 修正规则并登记证据 → 形成可复用版本 → 其他公司按自身业务采用。标准更新不会自动改写任何公司系统；公司登记采用版本、差异和迁移结果。

11 条标准登记

编号	通用要求	人力样板中的对应	验证方式
REF-01	先识别长期主数据、交易、履约记录和结算，分别管理	人员档案、客户服务订单、派遣、考勤、验收、结算	先建人员；订单可先保存需求；同一人员可在不冲突的服务中复用
REF-02	前台采集、运营管理、数据分析使用同一权威记录，各自承担不同任务	Web采集工作台、运营管理后台、Web分析	同一订单ID贯穿采集、明细与分析；图表可追溯到组成记录
REF-03	业务状态由服务端校验，主数据身份与交易快照分开	在册/身份核验/资格/可派遣状态；派遣时姓名与角色快照	不可用人员拒绝派遣；修改人员档案不改变历史结算
REF-04	权限覆盖页面入口、接口、敏感字段与媒体；正常导航必须能完成登录	任一运营页面可进入登录；证件核验资料与普通订单分权	新浏览器首次进入；未登录、无权限、加载、空数据与错误分别可辨
REF-05	变更有版本、幂等与审计；不可覆盖已确认历史	人员编辑、换人、工时调整、结算锁定	重复提交不重复建单；旧版本冲突；替补保留原记录
REF-06	媒体是有归属的业务证据，原件、元数据与权限对应	人员身份依据、到岗照片、工时证明、验收附件	检查owner类型/ID、上传状态、授权读取；具体能力按样板状态登记
REF-07	Web、金数据和Android共用业务规范，分别记录实现状态	hr-0.4.0目标规范；Web实现；金数据设计；Android原型	字段、校验、状态、角色、附件和错误反馈逐项映射，不用同号假装三端都已发布
REF-08	运营后台负责处理业务，分析负责解释数据；指标定义可追溯	Web分析与Power BI两个入口	指标定义注明分子、分母、单位、币种、时间范围、数据来源；未接入不得显示为已连接
REF-09	每个完成的修改形成可回溯交付，源码、部署和数据版本分开	人力仓库、Pages部署、接口/schema版本	完整提交SHA、版本、实际网址、部署身份可对应；代码回滚不宣称恢复数据库
REF-10	框架验收与业务案例验收分开，模拟事实与真实业务分开	本轮框架；后续正常履约/缺勤替补/异常处理三例	每例保留输入、预期、结果、问题、修复和复测；未执行不标通过
REF-11	公司采用标准必须可追踪、可调整，不机械复制行业字段	人力首个采用者；其他四公司本轮未采用新版本	采用清单登记标准版本、具体实现版本、例外及复核日期

三端同步的交付物

每个业务字段登记稳定键、业务含义、类型、必填条件、权限、校验、API、数据库位置、附件归属及三端对应控件。发布清单分别记录业务规范版本、Web实现版本、金数据设计/搭建版本、Android原型/应用版本和验证状态。一端变更时，其他端的设计与映射必须更新；没有账号或未开发应用时，明确暂停实际集成，但仍交付设计原型。不同终端允许不同布局，不能改变核心业务含义。

样板状态与采用记录

人力服务公司

规范 hr-0.4.0；实施、验证和正式发布分别以公司本轮档案为准。

三条案例

0.3.1 原始三例作为历史保留；0.4.0 新增三条差异化模拟案例，逐环境验收记录单独保存。

其余公司

车辆、样品、装车、计量公司本轮不修改、不升级、不推送，后续各自选择适用规则并验证。

金数据账户、Power BI账户接入暂停；Android仅原型。0.3.1 原始证据保留在人力公司；新框架必须重新做针对性验证。

三类交付物的版本与状态

交付物	版本	状态	边界
平台方法标准	REF-0.1.0 + REF-DC-0.1.0	标准已发布；持续接受公司案例校正	规定可复用的方法、检查与采用记录，不保存公司业务数据。
人力公司具体实现	hr-0.4.0	以公司周期档案实时状态为准	公司独立保存字段、接口、页面和运行数据；0.3.1 历史证据不冒充 0.4.0 验收。
公开标准页交付	v0.9.5	已发布标准页；本次统一重复出现的采用状态说明	已核验生产与预览回执 · 当前网站提交与版本。

开发周期与错误复用标准 · REF-DC-0.1.0

人力公司样板暴露出一个关键问题：代码版本存在，不等于知识已经沉淀。平台要求每次小循环同时留下反馈、错误、修改、实际结果、验证边界和发布身份，使后续公司能直接复用判断和检查方法。

下载可执行标准 JSON · 查看人力公司具体开发周期档案

一个开发小循环必须完整保留八步

步骤	必须保留	不能接受
1 保留反馈	保存直接影响决定的关键原话和不丢细节的结构化复述；本轮对话是主要规格来源时完整留存。	只摘一句结论，或把复述冒充用户原话。
2 登记错误	分别写错误表现、业务影响、直接原因、推断原因、首次出现和后来复发。	只写“体验不好”“逻辑混乱”或“已优化”。
3 形成修改任务	列出对象、受影响视图、完整动作、预期结果、禁止做法和验收点。	只列页面名称和笼统待办，无法判断是否改完。
4 分开计划与结果	实际完成、未完成、未验证和超出范围分别标记。	把计划、代码存在或子任务自报完成直接写成产品完成。
5 针对性验证	每项记录环境、输入、预期、实际、证据和局限，检查必须针对错误原因。	用构建成功代替业务关系、数据血缘、权限或真实页面验证。
6 登记发布身份	保存版本、完整提交、标签、固定部署、正式别名和线上核验结果。	把 commit 或 push 写成已经正式发布；预填尚不存在的 SHA。
7 复发与重评	后来发现旧验收范围不足时保留旧快照，追加重评并反链首次问题。	静默改写旧记录，或让旧的“已修正”掩盖新证据。
8 提炼平台规则	公司周期完成后才抽象通用规则，记录来源案例、适用范围、禁忌与采用版本。	把一家公司的具体字段、状态或页面机械复制给其他独立公司。

六条发布门槛

编号	门槛	发布负责人怎样检查
REF-DC-01	周期档案完整	反馈、错误、计划、结果、验证、发布和未决能够从同一周期相互追溯。
REF-DC-02	完成状态真实	每个完成声明有同版证据；没有证据就保留待验证。
REF-DC-03	旧结论可以重评	原始快照保存校验值；新判断追加日期、来源和影响，不覆盖旧说法。
REF-DC-04	问题可以防复发	每个问题有原因、处理步骤、禁止做法、检查点和复发链。
REF-DC-05	业务对象贯穿	同一对象在定义、采集、运营、分析与多端开发使用稳定身份。
REF-DC-06	验证不越界	证据明确能证明和不能证明什么；模拟与真实、预览与生产分别记录。

来自人力样板的复发案例

旧结论为什么被重新打开

0.3.1 曾把“前台与运营映射”和“版本复盘”写成已验证。后来逐页复核发现：表单名称仍漂移，新增采集表混入运营页，结算入口回跳长工作台，分析没有逐表字段血缘，复盘也压缩了真实反馈。因此保留旧版快照，并把两项问题明确重新打开。

下一家公司怎样避免

先给每个业务对象稳定身份和记录粒度，再建立定义、采集、运营、分析与多端矩阵；每次提交都同时更新问题档案。构建测试只作为基础门槛，必须再用具体记录完成跨视图追溯。

适用边界和当前采用

平台只保存上述方法，不保存人力公司的完整对话、字段、记录、代码或媒体。人力公司的 0.4.0 周期是首个采用案例，采用与验证状态由公司周期档案维护；金数据和 Power BI 暂停，Android 仍为原型。其余独立公司只有在自身业务设计开始时才登记采用和例外。