 ThearchyHelios
|
6ff9d7155b
|
M3 可验证报告核对正文显示的字：按服务端的显示规则把引用的值重新渲染、逐字比对
验收发现：页面只核「引用的值 = 口径卡的值或快照的格子」，不核正文显示的字。只改显示文字（74,613.65元 改成
84,613.65元、华南改成华东）、引用值不动、重算全部哈希的伪造页照样「全部通过」，读者看到的数和核过的数不是同一个。
- verifier.js 移植 engine/evidence.py 的 render_number / render_cell：千分位、不分组、小数位（含负数位）、比率显示成
百分数、万 / 亿换算、pct、int、.N、单位后缀、负数、0，文字压成一行（按 Python 的空白），竖线换成 ¦，ISO 日期时间按
文档记下的单元格显示规则版本。数照 Python 的 Decimal 算：系数用 BigInt，ROUND_HALF_UP，浮点取最短写法，整数取 JSON
原文（新写的 numberTokens 读出每个数的原文，超过 2^53 的订单号一位不差）
- ⑤ 在引用的值对上之后再核显示文字（只去掉首尾空白）：对不上判不通过，原因点名「正文显示「X」，引用的值是「Y」」，
数字另写按显示规则应显示的字；渲染不出来的（不认识的换算、显示规则版本、对象和列表、非 ASCII 数字、缺 BigInt 的
浏览器）判「无法核对显示文字」，不判通过。出处面板改成列出按显示规则应为的字，一致时注明，页脚说明同步
- 在 node 里载入时（没有 document）交出核对用的纯函数，tests/test_bundle_shown.py 拿服务端的渲染逐条对照约八万个
组合，并在 node 里整份核对：经营月报样本每种格式原样通过，只改显示文字的伪造逐个变红并点名
- 样本页加经营月报（formats）；check-bundle 在真导出上只改一个数字（有文字取值时也改一个）的显示文字，在经营月报上
改文字取值、数字、换算成万的口径卡引用，各自变红并点名，原样导出照旧全绿
|
2026-10-07 00:17:22 +08:00 |
|
|
ThearchyHelios
|
8c0c3b8eeb
|
可验证报告复核修复：遮罩源上的查询快照再堵几条带出号码的路，口径卡和快照按同一个结论判
复核查出，上一轮放开「没碰遮罩列的快照照常附带」之后，有几种写法 SQL 里不写 phone、结果列名也对不上，结果里照样是
号码，快照原字节和查询事件的预览会随文件附带出去。这一轮逐条堵上：
- 整行引用认全（复核的两个阻断项）：Postgres 的 FROM 里的表函数不写 LATERAL 也看得见前面的来源，
`FROM members m, jsonb_each_text(to_jsonb(m))` 这类逐列画像的写法（逗号、CROSS JOIN、JOIN … ON TRUE、LEFT JOIN、
ROWS FROM、不带别名的 UNNEST、套在 FROM 的子查询里）以前按看不见算，整行引用认不出。现在 FROM、JOIN 里只有真的
子查询和 WITH 里的一段看不见同一层；括号括起来的一组连接（(members m CROSS JOIN f(m))）也摊开按同一层认。另外认
函数记法 m.to_jsonb、m.row_to_json（等于 to_jsonb(m)），自己建的函数认不出。
- 不点列名也读得出表里内容的写法（_INDIRECT_READS）：SQL、表名写在字符串里交给函数执行或整表导出（table_to_xml、
query_to_xml 一族、ts_stat、crosstab、DBMS_XMLGEN、XQuery 的 ora:view），统计信息里的采样值（pg_stats、
sqlite_stat4、column_statistics、Oracle 的直方图和 *_tab_columns），按页按文件读的原始数据（get_raw_page、
pg_read_file、LOAD_FILE、sqlite_dbpage、逻辑解码），别的会话的 SQL 原文（pg_stat_activity、general_log、V$SQL），
系统 schema（pg_catalog、information_schema、performance_schema）。SQL 原文里出现就只给哈希；函数名要跟着左括号，
列名碰巧叫 crosstab、pg_status 的不受影响。
- 这次运行里查到过的遮罩值写进了别的查询的字面量（模型拿看到的号码去查别的表）：导出时收齐封存范围内每份快照里
取自遮罩列的格子（inquiry._Secrets 的按值认得出的写法），只看 SQL 的字面量，碰上就只给哈希、查询事件也只给哈希。
这次运行里没查到过的值（提问人写进问题的）认不出。
- MariaDB 会执行的注释 /*M! … */ 和 /*! … */ 一样按语法树认不准处理。
- 口径卡和快照按同一个结论判：快照因列名表、整行引用、不照原名展开的 *（UNION 一支里按位置对上列名的、装进一列
的）、吃进遮罩列的表函数、语法树认不准或不点列名也读得出内容而只给哈希时，卡上取自这份快照任一列的输入都按遮罩列
算，整张卡只给 id。以前卡这条路只认改了名字的遮罩列，快照只给哈希，卡上记着的号码却原样进了文件。最外层直接写的 *
照原名展开，按名字认就够，卡照常嵌入。
- check-bundle 的 masked-source 样本点数字之前先看有没有核对通过的数字，没有就记一项不通过、不去点：以前点空了要
等满 30 秒抛错，同一节后面的 nan、stray 样本都不跑了。换回改动前的 build.py 实测，现在只多记两项不通过，后面照常跑。
有意没改的一条：SQL 写到遮罩列、结果里却没有号码的（COUNT(DISTINCT phone)、phone IS NOT NULL）照旧只给哈希，比规格
的四条更严。FROM 里的表函数吃进遮罩列时（unnest(ARRAY[phone])）它交出的列取自哪一列认不出，只能看 SQL 写没写到；
补了这一例的测试，说明写在 _untouched 和测试里。
测试：新增整行引用（表函数、括号里的一组连接、函数记法）、不点列名的读法、字面量里的遮罩值、MariaDB 注释、口径卡
七种认不出来历的写法各自的用例，以及对照组（列名像函数名的、表函数只吃没设遮罩的列的、括号连接按名字取列的、最外层
* 的卡）。合并查询那一条判断补了只带认得的键的夹具，结果列名那一条补了按 SQL 认遮罩列的那一套什么都没认出来时的
用例，两条现在都能单独证明——上一轮提交说明里「每一条规则都做过去掉实现测试变红」对这两条不成立。这一轮 15 处改动
逐一去掉实现，相关测试都变红。
|
2026-10-06 18:33:02 +08:00 |
|
|
ThearchyHelios
|
02883dea7b
|
可验证报告：查询快照只给哈希时照实说明原因，样本页和浏览器检查补「遮罩源上的汇总查询可核对」
核对页对只给哈希的查询快照原来写「含遮罩列，未随文件附带」。现在没碰遮罩列的快照照常附带，只给哈希的是这条查询
用到或可能用到设了遮罩的列（条件里写到的、解析不了的也算），原文改成「这条查询用到或可能用到设了遮罩的列，快照未随
文件附带，只能核对到哈希」；口径卡的说法不变。核对逻辑不变，只是按工件种类挑说法（verifier.js 的 maskedQuery）；
内联脚本的 CSP 哈希由 render_html 按脚本现算，不用另改。顺手改正 verifier.js 开头一句过时的注释：口径卡现在会因遮罩
只给哈希，导出时不会出现的是报告文档标着遮罩。
tests/bundle_samples.py 加样本页 masked-source：会员库设了号码遮罩（查询当时记下了、数据源现在也设着），报告引用会员
按地区汇总的查询和选出了号码的那份。check-bundle 断网打开它：汇总快照在 ③ 通过、引用它的两个数字在 ⑤ 通过、点开看得
到汇总的 SQL 和被引用的那一行；选出了号码的快照和引用它的数字无法核对并写明原因；总览「可核对的项全部通过」，页面里
找不到号码。另在这一页上篡改：汇总快照改一个字节 ③ 变红，改它的数字的引用值并重算全部哈希 ⑤ 变红。base 页上的原因
文案跟着改。test_bundle_build 守住样本页的形状。
|
2026-10-06 17:11:41 +08:00 |
|
|
ThearchyHelios
|
b080302e77
|
可验证报告复核修正（第 1 轮）：只给 id 的遮罩工件，服务端的文件和 id 对不上的标 mismatch、解析不出来的标 unparsable，核对页对不上的判不通过、解析不出来的照实说认不出是否含遮罩列
上一轮让被改过、解析不出的口径卡不再原样嵌入（号码不进文件），可这样一来它在页面上和正常的遮罩卡一模一样：「? 无法核对 含遮罩列，未随文件附带」，总结论从「有 1 项不通过」变成「可核对的项全部通过」，篡改的证据丢了；截断的卡服务端其实认不出输入，却被说成「含遮罩列」。现在 _Artifacts.add 对只给 id 的遮罩工件（口径卡、查询快照都算，带遮罩的快照被改过原来就有同样的问题）照实带上服务端看到的：store.intact 为假标 mismatch，解析不出对象标 unparsable。verifier.js 在遮罩分支认这两个标记：mismatch 判不通过，原因「导出时服务端的这份文件与工件 id（哈希）不一致，可能被改过；按含遮罩列处理，未随文件附带」；unparsable 是正常的无法核对，原因「导出时服务端的这份文件无法解析，认不出是否含遮罩列，按含遮罩列处理，未随文件附带」，引用它的数字跟着用这句。pytest 补被改过、截断、不是对象、哈希对得上却解析不出的卡和被改过的遮罩快照；check-bundle 在 masked-card 样本上补两条篡改检查。
|
2026-10-06 13:43:04 +08:00 |
|
|
ThearchyHelios
|
5e6742b905
|
可验证报告里有输入取自遮罩列的口径卡只给 id，核对页把它当正常的无法核对
口径卡上记着每个输入的值和代入式：cell() 取的遮罩格、按位置取的 vars.res.rows[0][1]，以前原样嵌进这份要发给别人的文件，
证据面板上已经遮住的号码在这里照样看得到。现在口径卡有一个输入取自遮罩列（遮没遮核对不了的也算），整张卡和带遮罩的快照一样
只给 id——没法只拿掉几个值，拿掉了哈希就对不上。认法和证据面板、推演同一个（recompute.input_origin）：按定位里的列认，按位置
取的一格顺着取值链从写变量的节点在口径卡那次执行之前的产出起走；快照或产出读不出来、结果没存快照只带着数据源名的宁可多挡。
核对页（verifier.js）把带遮罩的口径卡当成正常的无法核对（「含遮罩列，未随文件附带，只能核对到哈希」），引用它的数字同样无法
核对；只有报告文档标着遮罩才判被改过。check-bundle 原来那项「口径卡标成遮罩判不通过」相应改成「报告文档标成遮罩判不通过」，
另加样本页 masked-card：口径卡在 ③ 无法核对、引用它的数字无法核对、总览通过、页面里找不到那个号码。去掉核对页的改动，这几项变红。
|
2026-10-06 09:20:29 +08:00 |
|
|
ThearchyHelios
|
59f1868dac
|
可验证报告的运行结果按封存范围内真正截止的那条结束事件核对
早期运行先失败、经继续运行跑到成功的，封存范围里留着中途那条运行失败，成功结束的那条在范围外（run.finished 落库之前封存）。
以前 checkMeta 拿范围内最后一条结束类事件去对，把运行结果改成「已失败」也标「已核对」。现在只认范围内最后一条、且是结束类
事件的那一条；没有这样一条时，早期运行成功结束照旧说无法核对，别的说法写明那条失败之后运行又继续了、没有事件印证，判不通过，
页面顶上显示「—」而不是把文件里写的当成核对出来的。
样本页加一份 continued（先失败、继续运行到成功的早期运行），check-bundle 断言它原样时无法核对、运行结果改成已失败或已取消时不通过。
|
2026-10-05 19:06:32 +08:00 |
|
|
ThearchyHelios
|
e7c8d2a1f3
|
可验证报告复核修正（第 1 轮）：运行信息拿已核对的事件对照，报告徽标连同数字一起算，遮罩判定宁严勿宽，各分支在浏览器里有确定的检查
- 页面核对加 ⑥ 运行信息：运行结果看封存范围内最后一条结束类事件的类型，运行类别看运行开始事件记下的运行参数，
出具档位认最后一条出具判定（不再信元信息指的那一条）；页面显示事件里的值，元信息写得不一样算不通过、计入总览。
工作流名、版本、起止时间、节点名称绑不进封存，单列一组写明取自运行记录，封存说明里也写明要到系统里一并对照
- 报告标题旁的徽标连同正文里的数字一起算，旁边写分项：重算全部哈希的伪造只在 ⑤ 露馅，徽标不能还写着通过。
分块条目多时不通过和无法核对的都列在外面，有无法核对的显示「部分无法核对」和分项计数；⑤ 改叫「数字与取值」并分开数，
读屏分别读作数字、取值，「显示格式由服务端渲染」只附在带出处的数字上；无出处数字的说法改成未使用引用标记
- 服务端不会给出的状态算不通过：被引用的工件不在清单里、非查询快照标着遮罩、工件既没内容也没说明；报告文档导出时
已不在服务端，总览不再是绿色的通过，写「有 N 份报告未能核对」，报告处写明是服务端已没有这份文档
- 认 json.dumps 写出的裸 NaN / Infinity，没被改过的文件不再误判不通过；哈希对得上但读不懂的照实写「无法核对」，
和哈希不一致分开说
- 宽屏打开出处面板时正文让出右边一栏，表格里右对齐的数字不再被面板盖住；补上斜体（不用后行断言，较早的 Safari 也能执行）
- 封存哈希、运行 ID、工作流名直接写进页面，不执行脚本时写「尚未核对」而不是一直「正在核对」；脚本挪进 head，
执行后核一遍页面顶部写出的封存哈希和数据里核对用的一致
- 成果节点和运行结束事件的规范字符串，只在封存范围内每次数据源查询都对得上无遮罩的快照（或确实没交回数据）时才给：
升级前的运行从工具快照认出查询快照，协作团队成员的查询认不出就按带遮罩算，数据源现在设了遮罩的按工具名就挡
- 封存核对不一致的 409 改成一句固定的话，不再叠冒号、让人去本来就在的记录页；失败结束的运行在页面封存说明和导出提示里
写明之后继续运行会重新封存；记录页上左边写着「已封存」却不能导出时，原因写在屏幕上
- tests/bundle_samples.py 用虚构数据真实生成九份样本页（遮罩快照、两份报告、早期运行、失败结束、两条出具判定、
服务端缺文件、裸 NaN、别的运行的文档），check-bundle 断网打开逐项断言，在上面篡改引用链、运行信息、拿掉被引用的口径卡，
量宽屏面板，看不执行脚本的样子；把核对改成恒通过、徽标不看数字等七种改坏法都会变红。pytest 补遮罩判定的三种形状、
事后设遮罩（去掉接线即变红）、页面静态内容和样本页本身
|
2026-10-05 05:30:50 +08:00 |
|
|
ThearchyHelios
|
183814d2c1
|
可验证报告页面补全：列出参与清单核对的原文供页面外自行重算，写明运行结果，自查认法与服务端一致，打印时收起面板
- 封存清单一项可展开参与核对的每一行（序号|类型|节点|内容哈希），读的人不信页面脚本也能复制出去用别的工具算；
check-bundle 在页面之外用 node 重算这段原文，等于封存哈希
- 元信息加「运行结果」（已完成 / 已失败 / 已取消）：失败的运行报告照样导得出去，读的人要知道它没跑完
- 报告节点认最后一次记下了文档的自查，和服务端、证据接口同一个认法，后面多一条没记文档的自查不再误报不通过；
运行记录里有自查、文件里却没附带文档的报告照实报不通过
- 核对下不了结论（数据块坏了、内置 SHA-256 自检不过）时也标上核对结束，等结果的一方不必干等；打印时收起出处面板
- check-bundle：拿不到导出页面时，依赖它的几节跳过并注明原因，不再一个原因报五次
|
2026-10-05 04:04:06 +08:00 |
|
|
ThearchyHelios
|
a651a2e7d5
|
check-bundle 换成真检查：真服务端导出、断网打开全部通过、篡改各自变红、去掉 crypto.subtle 照常通过，外加记录页的导出按钮
- 从服务端找一份已封存、核对一致、有报告文档的运行下载 bundle.html：附件名、零外链、内容安全策略、数据块转义、导出不追加事件；
找不到可导出的运行照实报失败并说明原因；有未封存或还没结束的运行时核对它回 409
- 拦掉一切网络请求从本地文件打开：五项核对通过、没有发出请求、数字点开看得到出处；页面加载前删掉 crypto.subtle 照常全部通过
- 篡改事件内容、工件的一个字节、封存哈希，各自对应的核对项不通过、总览不通过、其余项仍通过；另做一次改引用值并重算全部哈希的伪造，
只有报告数字的核对拦得住
- 390 宽深浅色都不横向溢出、出处面板从底部抽出；导出按钮的几种状态用预览用例和假接口核对，不碰真实写接口
- 输出只打印计数和运行号前 8 位，下载的文件放临时目录、跑完删掉；check-all 里这一项按实测改成 10 秒
|
2026-10-05 03:59:00 +08:00 |
|
|
ThearchyHelios
|
6041073ef2
|
检查脚本骨架：check-all 另起的后端带 AGENTLAB_SCHEDULER=0，拷来的数据目录不会替原库到点发起运行、发出 webhook。新加 check-schedules、compare、verify、inquiry、bundle、whatif 六个占位检查（只打一行通过，输出格式和别的检查一样），登记进 ORDER 和 ESTIMATE，各工作包换成真检查
|
2026-10-04 23:40:20 +08:00 |
|