aomin/hepu

0 Fork 0

Files

T

aomin a7605ef8b8 chore(repo): 导入 M-Z 业务底座 V1.9 基线并建立仓库规范

按周工交付的 SEC-Z-01 清理后源码建立 M-Z 主干，并按 Git 仓库惯例重排目录。

- aomin-gateway/  后端工程 87 文件，原样保留，路径与构建命令未变
- demo/           演示前端与设备模拟器 9 文件（原 02_前端与设备端），非正式三端
- docs/handover/  交付与安全清理材料 6 份，内容未改
- docs/contract/  J-00 规格、OpenAPI、内部五接口、状态机、Mock 样例
- docs/reference/ 指纹与校验清单，含 84 个源码文件的 sha256 清单

目录重排只动位置不动内容：源码树 84 文件哈希与交付一致，逐文件自校验通过；
12 条 Flyway 迁移与交付包内镜像逐字节一致。

未纳入：迁移镜像目录（与工程内一套重复，改留指纹）、target/、证据 raw、
应急恢复脚本、评审用虚构台账数据。

安全：SEC-Z-01 15 处明文已清零，导入前重新扫描无新增命中，本仓库无历史污染。
行尾按交付字节原样保存（.gitattributes 设 * -text），不做归一化以免整树摘要失效。

2026-11-13 17:32:37 +08:00

5.5 KiB

Raw Blame History

原始交付包指纹

本文件记录周工交付的 SEC-Z-01 清理后 源码包的指纹，用途只有一个：证明仓库里这份代码与交付确认过的那份是同一份。

一、两个 SHA256SUMS 的作用范围（重要）

docs/reference/ 下的两个清单是交付当时生成的，路径以原交付包根为基准。

清单	覆盖	现在还能直接校验吗
`SHA256SUMS_原始交付包.txt`	原包全部 108 个条目	不能。仓库目录已重排（`02_前端与设备端/` → `demo/` 等），路径对不上
`SHA256SUMS_前端与设备端.txt`	原包内演示前端 8 个文件	不能，同上

保留它们不是为了"跑一下 sha256sum -c"，而是为了在需要追溯时能回答：交付当天每个文件的哈希是多少。路径变了，文件内容没变——逐文件比对哈希即可证明。

二、版本标识（与 `handover/03` 第五节一致）

标识	值
模型版本	V1.9（已冻结；本次仅 SEC-Z-01 最小安全清理，未升 V1.10）
内部契约	J-00 1.8.1
迁移序列	Flyway 1.0.28，12 条
源码树摘要	`5E9F894B0D1071969A968F2A9B1451279ADF39D423148186886BFD064398F286`
可执行 jar	`1F38F527605F09AA45E9E54528AFB11230469E1B197FA001C06E8725FD102192`（43,517,256 字节）
证据批次	`R20261113-112443`，11 组 / 155 条 / 失败 0

源码树摘要的描述（handover/03 第一节）是：把 src 下每个文件的「相对路径 + 该文件 SHA-256」按路径排序后拼接，再整体算一次 SHA-256。它等效于"这一棵树"的指纹，不是 Git commit 哈希。

但这段描述不足以复现该值——分隔符、哈希大小写、路径是否带前缀都没写。本仓库按 60 余种组合（分隔符 ""/\n/\r\n/空格/|/:/\t，大小写两种，路径前缀 ""/src//01_后端源码/src/，拼接顺序两种，末尾换行两种）逐一复算，均未得到 5E9F894B…。

结论：这个值只能作为"交付方声称的标识"引用，不能作为可校验凭据。可校验的替代物是 SHA256SUMS_源码树.txt（84 行，sha256sum -c 直接可用），见第四节。

三、12 条迁移脚本指纹

原包的 03_数据库与Flyway迁移/ 与工程内 aomin-gateway/src/main/resources/db/migration/ 是同一套文件的两次出现。仓库只保留工程内一套，交付时已核为逐字节一致。下表可直接用于复核。

#	迁移脚本	字节	SHA-256
1	`V1.0.0__baseline_schema.sql`	101,859	`07E5263E3D755535A5FADAA18B8529D6244AF975DAA06FAEF9B3E908BCF0C7CC`
2	`V1.0.18__raw_link_columns.sql`	5,134	`8BE5A9816F1F661D0A54C2A23C56079B76DF88F47BD153609A94C659E42E7299`
3	`V1.0.19__household_geo.sql`	1,211	`45E64F88796D46267B8F4F67F76D9EA5EC3AD34FBBE62736C4768216CBAF23A2`
4	`V1.0.20__notify_read_at.sql`	1,140	`CDE7F6DF804CDC1A827B0A109815C0AF3A52D7EFA4F35A170F262D8CE429418D`
5	`V1.0.21__alarm_chain_seq.sql`	1,803	`7751F42076E39874A85F147CF1CE5C45653161207CB06E6042D60F7888D90710`
6	`V1.0.22__alarm_source_event.sql`	656	`3306548D3C02F6750CFB93C535E5C9E98062710ED6D4D099F69E0FC7A7B8EDC1`
7	`V1.0.23__command_seven_states.sql`	2,678	`9C941B1675D5A82DAEF81D7F297D03B206A028DEB9923B78CD92F473A9CA8272`
8	`V1.0.24__region_scope.sql`	2,099	`EC0B7E0F23F74F52BD373FC0FB7D84BACDDA9BE62C19E9B6163BF669DA442AF2`
9	`V1.0.25__raw_ref_64_and_gap.sql`	3,951	`E480A143B8A079971C285D63BF51252EECC2034054459F83E2104C877FA51D40`
10	`V1.0.26__alarm_retry_deadletter.sql`	3,793	`61E8C5F2167DE4588E8AA337C9D45DFA12015680D6B12D1D456B3F159770C29E`
11	`V1.0.27__receive_time_local_and_audit_fail.sql`	2,452	`778141CF45E9B3F62AFC9BDBB3F7079794DAEDFBA9F0A20CAF84FE90EB3503DD`
12	`V1.0.28__command_claim_node.sql`	1,989	`2D6E90A3E6A2DB9771B7820DF4DFC7E58C211627AC02271612E2511764E83286`

这 12 条的哈希只用于确认"与交付时相同"。 迁移脚本一旦被修改，即使只改注释，Flyway 也会报校验和不符；那时要做的是 flyway repair 加会签记录，不是回头改这张表。

四、怎么复核

单条脚本

cd aomin-gateway/src/main/resources/db/migration
sha256sum V1.0.28__command_claim_node.sql
# 与上表第 12 行比对，应完全相同

全部 12 条

cd aomin-gateway/src/main/resources/db/migration
sha256sum V1.0.*.sql | sort -k2

源码树（84 个文件）

# 在仓库根执行
sha256sum -c docs/reference/SHA256SUMS_源码树.txt
# 84 行全部 "OK" 即为一致

SHA256SUMS_源码树.txt 覆盖 aomin-gateway/src 下全部 84 个文件，格式是标准 sha256sum 清单（哈希 + 相对仓库根的路径），生成于本次导入、自校验 84/84 通过。

这就是"逐字节一致"的可校验形式：交付包的 01_后端源码/src 与本仓库 aomin-gateway/src 只差一层目录名，逐个文件比对即可。行尾差异（CRLF/LF）会直接改变哈希，所以比对不上时先查行尾——.gitattributes 已设为 * -text，不会自动转换。

五、这张表什么时候需要更新

情况	处理
新增迁移脚本 `V1.0.29`	追加一行；不修改已有 12 行
契约版本升级（J-00 1.8.1 → 更高）	更新第二节的契约版本与 `03` 的对应项
代码发生实质变更	源码树摘要与 jar 哈希随之失效，应记入 `CHANGELOG.md` 而不是改这张表——这张表描述的是交付那一刻

5.5 KiB Raw Blame History Unescape Escape