205 Commits

Author	SHA1	Message	Date
ThearchyHelios	479cec0af7	通知事件一次登记（总方案 X6、5.1）：六个新事件进 notify/service.EVENTS，推给哪几条路也登记在那一处 ... 复核指出 X6 漏做：第 2、3 波的数据源变化、口径召回、评测、触达四块都要往 EVENTS、EVENT_LABEL 和前端设置页的事件列表里 加东西，正是 X6 要避免的同一处多方冲突；消息里能放什么也没有一处先定好。 做了什么： - EVENTS 改成登记表：每个事件一行，叫法 + 推给哪几条路（scopes：global 全局渠道自己订阅、user 相关的人自己的个人渠道、 app 应用版本 spec.notify 的订阅）。本轮新登记 source.changed、ledger.recall、eval.regressed、eval.failed、task.digest、 key.expiring，scopes 都是空的——登记了、还没有推送。实现推送的那一块只改自己那一行的 scopes（各行之间隔着说明行，几块并行 改也不会挨着冲突），前端叫法表不用再动。EVENT_LABEL 从登记表派生，老的 import 不变。 - 模块说明写清消息结构：标题、状态、条数、链接，加编号和搭建时起的名字；不放报告和答案里的数、表名、列名、取值、SQL、 按运行数据渲染出来的句子。 - _channels 只走事件登记了的路；没登记的事件直接报错（推送之前先登记）。现有五个事件登记的路照现在的做法，行为不变。 - 接口：订阅按登记核对（subscribe_problem）：没推送的「还没有推送，暂时不能订阅」，范围不对的「不推给范围是「应用」的 渠道」。只核对这次新勾的：以前存下的照旧，开关、改名不会因此 422。GET /api/notify/events 多给 scopes（空的照实给）。 - 前端：terms.ts 的 eventLabel 和 EVENTS 一一对应、逐字一致，六个新事件先有叫法；设置页的渠道编辑框、应用的通知改按 GET /api/notify/events 列（这种范围收得到的才列，已经勾着的照样列出来能取消；取不到时照实说）。 顺带修掉的（就在要改的那张列表上）：设置页以前按前端叫法表的键列事件，里面有五个服务端从来不认的（待办升级、待办超时、 待办处理完、动作失败、动作已生效），一勾保存就 422；改派、升级、催办只在投递记录里出现，另起 deliveryEventLabel（加上测试 消息），记录里照实写是哪一种。服务端 EVENT_LABEL 的四句老叫法（有待办派给我、实例完成、实例失败、写入结果未知）改成和界面 同一句，界面上看到的字不变。 验证：新增 test_notify_events（登记表、前后端逐字对照、接口拒收、只走登记了的路），去掉 _channels 的按路过滤或「只核对新勾 的」回跑各有一项失败；check-capabilities 加一段「可订阅的事件照服务端登记列」，把列表改回按叫法表的键列，四项失败。	2026-10-16 12:12:14 +08:00
ThearchyHelios	ee6e07959b	问数据一轮的「决定」下沉到后端 chat/turn.py，问数据页照后端给的走（细案 01 做法 1，总方案 2.1）；这一轮的花费 = 助手 + 运行 + 复核 ... - chat/turn.py：next_step（有 error 级问题时自查过就判失败、没自查过的老服务端才重来一次；autorun=false 只建不跑；reply、只有反问直接收尾；其余运行）、fill_input（规则同 chat.ts 的 fillInput）、retry_after_review（retry、broken、这一轮还没试满）、retry_instruction（两种措辞原样搬过来） - answer_ops 的 final（含只问不改那条）带 next（run | ready | fail）；/copilot/review 的结果带 retry_instruction（ReviewIn.attempt 按这一轮试过几次判，要重来是那句话，不重来是 null） - 前端 store/chat.ts：final 照 next 走，复核照 retry_instruction 走（原样交回给助手），launch / watch / settle 把 attempt 带到复核；老后端没有这两个字段时退回原来的规则（常量和措辞留在 retryInstruction 里，和后端逐字对照） - 这一轮的用量：usage 操作累加进 copilot，复核结果的 usage 累加进 review，自动重来和用户点重试换下来的运行并进 earlier，当前运行的抄进 run，一起随 meta.usage 落库；问数据页轮次头部写这一轮的花费（runCostText：估不出的写「≥」或「金额无法估算」），悬停分得清助手建图、运行、复核，文案在 lib/terms.ts 的 TURN_COST_TEXT；ReviewResult 类型补 retry_instruction、usage - 新增 tests/test_chat_turn_policy.py（各条决定的分支；前后端对照 MAX_ATTEMPTS、认问题字段的正则、两种重来措辞——改一个字回跑会失败；复核按 attempt 给不给 retry_instruction）；test_copilot_answer_ops 的基线比对改成「final 只多一个 next」 - check-chat 补一段「新服务端」：照 next=ready 不发起、照 retry_instruction 原样重来、第二次复核带 attempt=1、meta.usage 四份都记下、头部写 $0.067 且悬停分得清三部分	2026-10-16 10:59:15 +08:00
ThearchyHelios	ba28dee1f0	生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报 ... - api/copilot.py：event_stream 原样搬成 async generator answer_ops(payload, *, catalog_view=None)，交出的 op dict 不变；开流前的准备（数据源、目录检查器、助手模型、历史、查看服务）用自己的短会话，在第一条操作之前做完。SSE 路由只包一层：先取第一条，开流前的拒绝（模型没配好、限定的数据源都不在）照旧是 HTTP 错误 - catalog_view 一路传给查看服务和自查的 SQL 检查器（目录视图接缝的「生成过程从参数读」） - providers/usage.py：Meter 是一个 LangChain 回调，和 get_usage_metadata_callback 同一个机制（登记过的上下文变量），按模型累计 tokens、次数，金额按价格目录；估不出的记 unpriced_calls。没直接用 get_usage_metadata_callback：with 块跨 yield 会把变量留在调用方上下文里，调用方随后发起的运行会继承它、被重复计一遍；metered 只在每一步 __anext__ 期间挂上，嵌套时并进外层 - 生成过程读到 done / look / ask 就关模型的流（后面的闲话不要），流末尾才报的用量拿不到：这一次照样计次数和已报的 token，记成估不出，不悄悄少算（遗留：真实接入上建图那几次多半是下限） - providers/budget.py：BudgetFallback.astream 用 aclosing 包住里面那条流——以前调用方关流时里面那条要等垃圾回收才关，模型那次调用的收尾（用量回调）落在算完账之后；测试去掉它回跑会少计一次 - answer_ops 末尾多一条 {op: usage, by_model, input_tokens, output_tokens, calls, cost_usd, unpriced_calls}；/copilot/review 拆出 review_of_run（问数据页、评测共用），结果带 usage（没调模型时全 0）和 retry_instruction（要不要带着原图重来、说什么，按 chat/turn.py 的决定算；ReviewIn 多一个 attempt） - 新增 app/chat/turn.py（问数据一轮的决定，复核这边先用上；final.next、对照测试、前端照做在下一个提交）；新增 tests/test_copilot_answer_ops.py（八种结局的 SSE 输出和抽出来之前录下的 fixtures/copilot_answer_ops_baseline.json 逐条相同，末尾多一条 usage；直接迭代和 SSE 同一串；开流前的拒绝仍是 HTTP 错误）、tests/test_usage_meter.py；读 SSE 的十一个测试文件的收流帮手跳过末尾那条 usage	2026-10-16 10:45:45 +08:00
ThearchyHelios	4c0e83bc80	目录视图接缝 data/catalog_view.py（细案 01 做法 5，总方案 X7）：读目录的四处统一经它，「开目录 / 关目录 / 只用已核实的项 / 目录快照」的对照才做得了 ... - CatalogView{mode: live | snapshot | off, statuses: all | reviewed, snapshot}：缺省 live + all，行为和以前一样；reviewed 只留已核实、已确认的项（驳回的项原样留着交给各处，照旧经 visible_notes 去掉，冻结快照和 SQL 检查靠驳回的关系编号认出不该现推的关系——为此在 catalog.py 加 restrict_notes，没给 visible_notes 加参数） - 视图从哪来：运行从 Run.options['catalog_view'] 读（catalog_view.of_run：RunContext.extra 里的发起快照，审批恢复、续跑沿用），ToolContext 多一个 catalog_view，节点（调用工具、llm/agent、多 agent）构造时带上；生成过程从参数读（下一个提交接 answer_ops） - 四处消费一律经它：运行时 db_schema / db_query（tools/datasource._catalog_of，冻结进表结构快照的也是这一份）、look 表详情（TableKind.load、copilot_context.look_service 收 catalog_view）、自查的 SQL 检查器（sqlcheck.load_checkers 收 catalog_view，改用 catalog.read_catalogs 一次读出）、双盲复算（_Sources 带视图，交给盲算的目录和比较 SQL 用的中文名都按它；核查 agent、反方审稿的 db_schema 也按这次运行的视图） - 冻结快照：不是缺省视图的在引用 meta 里记下 catalog_view（不进内容哈希，缺省视图不记，快照和以前一字不差），证据面板据此写得出「本次运行目录：关」 - snapshot 模式只定读法（kind=eval_catalog_snapshot 的工件，{sources: {源 id: {tables: {表: {version, notes}}}}}），内容由第 2 波的题集包写；快照不在了照实报错（CatalogSnapshotMissing），不悄悄退回当前目录 - 新增 tests/test_catalog_view.py：四种视图在四处给的是同一份、缺省等于当前目录、运行从 options 读且冻结 meta 记下、lint（消费模块不许直接 read_catalog / read_entry / 查 CatalogNote）；去掉 _catalog_of 里的视图回跑两项失败	2026-10-16 10:28:01 +08:00
ThearchyHelios	dd00234622	系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高 ... - engine/origin.py：SYSTEM_ORIGINS = (eval, reconcile, recall) 和 counted_runs()（写法同 hidden_runs，coalesce 防 NULL：来源为空的老运行、外连接没对上运行的行照常计入）；ledger_issue 是替用户正式出具，照常计入 - 取问题、聚类全站只留一份：新增 app/chat/questions.py（recent_questions / cluster_questions）。只取问题原文、不取整份输入（以前把含 history 的 input JSON 拿去聚，同一段对话里的不同问题会聚成一类）；问数据按轮次一轮一条（conversation_turns.question），同一轮里的自动重来只是换了挂着的运行，不多算；别的探索运行取 input.question；排除系统运行和别人的私有运行。/governance/exploratory-clusters 改用它，多给 turn_ids 和 embedder（本地哈希向量的结果只是下限） - 工具白名单衰减、目录的使用次数和「被哪些运行用过」、审阅队列的使用权重（都走 catalog.query_snapshot_tables）只算 counted_runs 圈进来的运行 - 记录页：没按来源筛时默认不列这三类，按来源点名就列；新增 GET /api/runs/unlisted（同一份筛选，_filtered 和列表共用）照实给出没列出几次、各是哪种来源。界面在列表底下（空列表时也写）写「另有 N 次系统运行未列出（评测 2 次、口径对账 1 次）」，来源下拉的「全部」改说「全部来源（不含系统运行）」；文案进 lib/terms.ts 的 SYSTEM_RUNS_TEXT；check-runs 补一段 - test_personal_apps 里代表「别的探索运行」的两条运行改成画布试跑：问数据的问题按轮次取，没挂在任何一轮上的问数据运行不单独算 - 新增 tests/test_eval_origin.py（去掉 counted_runs 的过滤回跑，5 项都会失败）	2026-10-16 10:18:12 +08:00
ThearchyHelios	e3d0fe618c	定时目标的底座（总方案 X4，细案 01 做法 15）：定时只有一套，目标种类在 scheduler/service 里一处封装 ... - service.target_of / target_columns：读写目标只经这里。workflow 目标 target_id 同 workflow_id；非工作流目标 workflow_id 存空串（老表的非空约束，只加不改的迁移放宽不了），这条规矩不散到别处 - fire_once 按目标种类分派：工作流那段原样搬进 _fire_workflow（重叠跳过、渲染输入、记触发、发起一字不变）；这一波别的种类照实记「未能发起」并写明是哪类目标，不发起运行、不把空串当工作流去跑 - 建任务、PATCH 改工作流经 target_columns 一起写两列；存量任务（target_id 为空）照旧按 workflow_id 发起 - 接口和界面这一波不暴露新种类（第 3 波开放），返回的形状不变 - 新增 tests/test_schedule_target.py	2026-10-16 10:07:15 +08:00
ThearchyHelios	4c4fa8e4e9	「需要剖析」多认一种：上次剖析之后多出了码值、日期检查（new_checks）；停止排队任务时不再读过期的 job（起草、剖析两处） ... - 以前只认从没剖析过、上次没做完、又冒出了待核实关系三种：上次剖析时没有可剖析的项（指定了表、记为跳过），后来有人把一列 记成状态类，或者日期列变了，「需要剖析的表」永远漏掉它。现在按当前要做的检查对上次剖析的检查项（kind、target），多出了 码值、日期检查就要剖析，原因 new_checks；上次是空表而跳过的仍不算（不发查询不知道有没有数据），界面和 409 的说法写明。 due_reason 改收 plan_checks 列出的检查，没人用的 profile_checks 去掉。 - 停止一个排队中的任务时，排队那一步没停成（刚被后台认领）要回滚，回滚让读到的 job 属性全部过期，再读 job.id 就在异步会话里 同步加载（MissingGreenlet），接口 500。起草的 cancel 在 main 上就是这样写的，剖析照抄了；两处都先把 id、状态取出来。 新测试在旧代码上复现了这个 500。	2026-10-15 19:28:17 +08:00
ThearchyHelios	4f0b60df03	导入、同步起草撞上剖析、起草任务时，说法按这次要做的事说下一步 ... 复核 R3。导入目录、同步起草撞上剖析任务回 409 profile_busy 时，原话来自 busy_message，结尾固定是「请等这次剖析结束 （或先停止它）再开始新的剖析」；使用者这时是在导入、起草，不是要开始新的剖析，导入对话框原样显示这句。导入撞上起草 任务时同样说「再开始新的起草」（这是改造前就有的，同一类问题一起改了）。 - catalog_profile_jobs.busy_message / ensure_free 加 then（缺省 THEN_PROFILE「再开始新的剖析」，建剖析任务、重试照旧）。 - catalog_jobs.busy_message / sync_busy_message / ensure_draft_free 同样加 then（缺省 THEN_DRAFT「再开始新的起草」）； ensure_idle 和 _lane_busy 按这次要做的事（kind）选：导入撞上什么都是「再导入」；同步起草撞上剖析是「再起草」，撞上 起草仍是「再开始新的起草」（和建起草任务同一句话，test_catalog_draft_jobs 钉着这一点，没动那个文件）。 - 导入接口的说明补上撞上剖析任务回 profile_busy。 测试：剖析时导入、同步起草、再建剖析任务三句结尾各自对得上；队被剖析占着时（任务刚好在收尾）同样按这次要做的事说。	2026-10-15 19:12:48 +08:00
ThearchyHelios	6b3c737fb8	数据剖析改成逐表的后台任务：引擎改编排、剖析任务、接口、设置换新键 ... 以前剖析是一次同步长请求，预算按整次算（max_queries 60、max_total_s 120），选 50 张表只做得完前两三张，其余整张记「查询次数用完」；不能停，关掉页面报告就没了，对业务库查了什么无从查。 - data/catalog_profile.py：检查逻辑和 _apply 并入规则原样保留，只换编排。公开的逐表入口 profile_table：先列全检查项（plan_checks，纯函数，范围的 profile_checks、建任务时列的检查项、执行用同一份；遮罩、多列、不在表结构里、指向视图的关系在这里就列成按规则跳过），第一条查询估行数（确知空表整张表跳过），逐项执行、进度回调，整张表结束写目录并和回调在同一次库操作里；停止时做完的项照常写、没做的记 cancelled 保留旧结论。_Runner 拆成整个任务一个的 SourceRunner（只读守卫、单条时限、任务级止损：连续 3 条失败、最近 10 条 7 条超时；最近 6 条 4 条超时提醒；每条查询留痕，SQL 经 normalize_sql 去掉字面量）和每张表一个的 TableBudget（用完只停这张表）。删掉同步的 profile_catalog、挑表前批量估行数（_skip_empty、PROFILE_DEFAULT_TABLES、PROFILE_PROBE_TABLES）和进程内 _RUNNING。设置换成 table_max_queries（1–200，缺省 40）、table_max_s（10–600，缺省 60），旧键 max_queries、max_total_s 启动时从库里删掉（migrate_settings，不折算：旧值按整次算，含义不同），保存时只摘掉不报错（without_legacy）。表助手的 run_query 和起草时核对有效记录条件改走单条查询入口 run_single_query，行为不变。 - data/catalog_profile_jobs.py：剖析任务的建（selected / needed / all 三种范围，排序同前：有待核实关系的在前、使用次数、表结构顺序；挑出 0 张 ProfileNothing）、排队（和同源起草按建立先后串行，waiting_for）、执行（每张表开始前重读数据源：停用或关掉剖析就停下；遮罩按最新设置）、停止、重试、启动标中断不续跑、保留最近 50 个结束的任务（某张表最近一次剖析所在的不删）、last_profile / profile_due 的查询、任务和逐表的接口形状。 - api/catalog.py：加 /profile-jobs（建、active、latest、{job_id}、tasks/{seq}、cancel、retry），登记在 /{table} 前面；删掉 POST /catalog/profile；清单每行加 last_profile、profile_due、profile_due_reason、profile_checks，顶层加 active_profile_job；单表加 last_profile；导入目录、同步起草遇到剖析任务 409 profile_busy。api/coded.py 加 profile_nothing、catalog_profile_finished；api/datasources.py 保存时摘掉旧键；main.py 启动时标中断加设置迁移，关停时停掉进行中的剖析。 - 测试：test_catalog_profile.py、test_catalog_profile_units.py、test_catalog_semantics.py 里打同步接口和旧设置键的改走任务和新键，检查逻辑的断言保留；同步接口的整次总量上限一条改成逐表次数、逐表时长两条。	2026-10-15 18:30:48 +08:00
ThearchyHelios	1e58862bf0	抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备 ... data/catalog_job_runtime.py 从 catalog_jobs.py 抽出进程内任务的执行与停止（JobManager：start / stop(grace) / wait / running / shutdown；JobRun 把进队、等轮到自己、执行、按停止原因收尾、出队写一次）、同一任务的库写入一条一条来并 shield（SerialWriter）、启动时标中断（interrupt_on_startup、close_job）、状态词常量，以及每个源一条先来先到的队（SourceLanes：任务阻塞地占，同步写操作不阻塞地试占）。剖析和起草是同一类问题（关页面就没了、不能停、不留痕），生命周期各写一份迟早一边修了另一边没修；共用的是生命周期代码，表各建各的。 起草的行为不变（test_catalog_draft_jobs.py 一条不改全过），只是：ensure_idle 拆成「同种任务互斥」（ensure_draft_free，建起草任务、重试用，剖析任务不挡起草，起草任务排在它后面）和「同步写操作要求源空闲」（ensure_idle，同步起草、导入用，剖析任务也算）；同步起草、导入目录执行期间占着这个源的队，期间新建的任务排在后面；任务和清单顶上的进度带 waiting_for（起草排在剖析后面时为 profile）；排队中被停止的任务连同在队里等着的后台执行一起停掉、出队。 db/models.py 加 CatalogProfileJob、CatalogProfileTask 两张表（create_all 建，同源排队或进行中的部分唯一索引照起草的写法）；catalog_profile_jobs.py 先放剖析任务的忙碌判定，下一步补全。	2026-10-15 18:10:50 +08:00
ThearchyHelios	d2b398563b	写回卡片加「结果不明时谁去核实」：写回的目标能力没登记查询时，结果不明（请求发出去了、没拿到答复）平台查不了、也不自动重发，要有人去目标系统里核实；以前发布单报「写入结果不明时没人核实」「有一步还没指定谁来做」却在卡片上找不到地方改。 ... - 蓝图格式：写回卡片多一项 reconciler（一组人或组），旧蓝图没有这一项照旧可读；只收用户的操作（同「谁能看」），助手整张换写回卡片时留着用户选好的人 - 是否需要（templates/_common.needs_reconciler，和应用骨架加核实岗位同一个判断）：模板用到写回卡片、选了目标能力、能力没登记查询；交给前端的蓝图带 reconciler_needed，界面不自己判 - 蓝图检查 bp.reconciler_unbound：试运行只提醒（待办派给试运行的人自己），发布挡住；发布单上应用检查说同一件事的 app.reconciler_unbound 和核实岗位的 app.slot_unbound 不再重复列 - 岗位绑定：选了的人绑到应用的核实岗位；能力补登了查询就不再要、也不再绑，卡片上留着的人照样摆出来、写明用不上 - 卡片：需要时摆这一项，标「缺」、写明为什么要人核实，选人控件只能选人或组；「缺」只挡发布；蓝图助手的提示词写明这一项由用户定 - 示例蓝图（核对写回）补上核实人，审批、核对写回的卡片说明写上这一项；测试和检查脚本跟上	2026-10-15 17:31:20 +08:00
ThearchyHelios	7fc3488b55	取数 SQL 不再把数据源名写成库名，试运行失败的蓝图不能发布：填关节的说明以前把表写成「数据源名.表名」，模型照抄进 SQL，数据库把数据源名当成库名（MySQL 报 Unknown database），应用每次出数都失败；说明改成只写数据源里的表名，并写明不要加数据源名。助手自查加 sql_source_prefix：表名前面写了数据源名就交回模型改（认列的检查找表时去掉前缀，拦不住它；数据源名恰好是库名、schema 的不报）。发布单遇到最近一次试运行失败改为挡住（plan.trial_failed，带出错的那一句），不再只是「还没有成功的试运行」的提醒	2026-10-15 17:31:20 +08:00
ThearchyHelios	fcbf711941	按需求挑选不再总是「没挑出来，已把表目录交给助手」：挑选以为能关掉思考、只给 1024 的输出额度，可经 OpenAI 兼容接入的推理模型（DeepSeek、GLM、Kimi 这一类）收不到 thinking=off，想完就没额度写结果，回复是空的或 JSON 只写了一半，又被报成「不是约定的格式」。额度改成和证据裁判、核查同一档 16384，服务方嫌大时退回 4096（按接入和模型记在进程里、互相认），时限 20 秒放宽到 45 秒；结构化输出带原始回复，正文、工具调用参数里的 JSON 也认，<think> 里的草稿不算，正文里顺手写的 [1] 不算空结果；没成的原因照实分开说：被截断（带额度）、回复是空的、写了字却不是约定的格式，认不出的回复开头记进日志	2026-10-15 14:59:40 +08:00
ThearchyHelios	be845bb823	蓝图「看哪些数」对到的数据源和表要真的存在：卡片上照实说是哪一项、怎么改（bp.data_source_unknown / bp.data_table_unknown，带白话），挡住试运行和发布单，助手自查也拿得到；填报登记里本应用的记录表写 @records、表名固定，提示词和模板说明写明这个约定；「对到的表」改成从已接入的数据源和表里选，填报登记多一项「本应用的记录表」，卡片上照白话显示（以前要到试运行才报「绑定的工具不存在」，用户找不到在哪改）	2026-10-15 14:32:25 +08:00
ThearchyHelios	7739340607	普通用户建应用集成收尾： ... - 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点，只读和遮罩在这条路径上生效；被治理成写入的工具在只读运行里直接拒；知识库范围在工具层固定（图级默认值、参数名纠错、Agent 都改不了） - 个人应用的刷新和个人蓝图的试运行只有拥有者能读：运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧；个人蓝图的试运行不论谁发起都按个人应用约束 - 共享蓝图只给拥有者、对应应用的管理者、管理员，看不到的一律 404；审核副本归审核人；管理员看别人的个人应用只有元数据、可以归档 - 记录表跨版本汇总（只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位，缺的版本照实写进印章）；停用前发起的运行可以继续写旧版本；更正沿用原提交人、更正人记审计 - 约定收口：待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置；前端类型一次补齐、去掉临时的局部类型；审核待办卡不再给打不开的链接；读附件事件有中文说法；检查脚本补断言	2026-10-15 13:55:19 +08:00
ThearchyHelios	277982ead3	普通用户建应用（后端）： ... - 蓝图：bp_* 操作和逐卡白名单、蓝图检查、留痕、按蓝图判权限；五个场景模板加自由形（骨架、关节、应用骨架、定时任务），实例化与骨架比对；BlueprintApplier / TemplateApplier（只收模板声明过的关节）与自查；look 新类别口径卡；蓝图对话和填关节两个流式接口，不同组的关节并行填、出错的组串行重试；模板列表 - 试运行与发布单：四种起点（对话、模板、问数据的一轮、已发布版本）；试运行是探索运行，草稿应用按这次运行解析、印章写试运行，流程类派给自己、不触发升级；发布单九步、预检只读、每步留痕、停下后接着做、核对卡片指纹和应用管理权、启动时整理中断的单；白话层覆盖全部问题编号 - 记录表与文件：平台托管只追加的记录表、按高水位固定数据、连接上的临时视图做行级可见、写入走动作（records_append）、表版本在发布时切换、草稿不影响线上、记录列表遮敏感列；文件按哈希存、两步上传、提交时绑定运行、下载按读权限、清理、file_text、按配方导入一期（table_import_period） - 个人应用：存成个人应用（问数据的约束）、刷新（遮罩、只读、每日上限）、只有拥有者看得见、提交审核与共享副本、开关下发到认人接口；页面编辑的候选；隐藏组件不下发；三条新检查	2026-10-15 12:09:29 +08:00
ThearchyHelios	7088f4557e	普通用户建应用的契约骨架（docs/design/normal-user-apps.md 第五部分）：蓝图、蓝图留痕、发布单、文件、记录表的模型和迁移，应用的 scope / owner / blueprint_id；运行来源加 trial、personal_app；应用描述的固定版本可以没有版本号（试运行派生的草稿）或改钉蓝图（个人应用），视图来源加 exploratory，组件加 hidden，表单加文件控件；agentlab.blueprint/1 与 bp_* 操作、agentlab.template/1 与关节类型的定义；实例化、试运行、发布单、个人应用、记录表、文件、白话层的接口签名；蓝图、模板、文件、个人应用、蓝图助手的路由桩（501）；前端约定 typesBlueprint.ts、接口桩、新建应用与蓝图页的占位路由、termsBlueprint.ts	2026-10-15 09:49:45 +08:00
ThearchyHelios	e182c2d214	复测收尾：账号密码登录时应用检查和授权接口核对名录（没有的、已停用的报错或拒收，单点登录只提醒），名录口径收成 auth/directory 一处；受管发布版在页头、版本历史、选择器、发布前检查里按发布级别写，草稿和发布版内容相同时照实说；写入能力在工具库写「只演练」；印章的「截至」只写一次；走驳回出口到达的结局不用成功样式；停着等人时说在等哪一步，同页已有会签进度时待办状态不再画一遍，名单写显示名；应用编辑器可以归档（写清后果），已归档的应用拒收草稿修改和发布；受管发布成功的提示写明受管；权限测试按 id 取应用，不撞别的测试留下的同名应用	2026-10-15 08:35:28 +08:00
ThearchyHelios	941723b17c	端到端验收修复与指标出具： ... - 身份与工具：登录页建第一个管理员（认人接口的 401 说明能不能建）；搭建者有只读的人和组名录，选人给候选并核对名字；授权三行带标题；端点请求头名校验（空名、非法名存不进、发不出时说清原因）；写入能力在工具页试运行一律演练、不发送，HTTP 状态照实说成败；写记忆不算只读、查询能力只能选同一端点上的只读能力；审批与遮罩的说法和实际规则一致；开登录时不要署名、导入和发布记登录的人；使用者不显示推演等只给搭建者的操作，403 按是否开登录说话；登录页只认一次人 - 流程与实例：图里用到的岗位（派给谁、超时升级给谁、发送确认派给谁）全部派生、没绑人的发布时报错；写外部系统的参数按能力声明的类型收拢后再算哈希和发送，收不成就不发；发起人的实例页只看这一步的状态，处理人才给待办卡；会签进度带登录核实和时间，升级后照实写规则；实例状态写流程的结论（已退回、未确认、等待核实写入结果），核实生效后不再挂失败原因；流程应用首页不派生最近封存运行的结果块，看板没数据时是安静的空态；样例⑩的金额带类型和下限、待办标题带金额，表单上下限前后端一起生效 - 看板与证据：定时任务模板加 ISO 周、上一 ISO 周、本月、上月；出处链穿过原样解析查询结果的整形节点，追不到原始数据的照实说停在哪里，样例⑨改用 cell()；应用首页和版本历史都能做成应用；指标块单位不重复；版本列表带退役说明；定时任务页头跟着刷新；删视图要确认、新视图能起名；编辑器属性用中文名、术语带解释 - 指标出具（用户 2026-10-15 拍板）：契约只写「指标来自」、上游没有报告撰写节点、成果里没有模型写的话时按指标出具——必需指标齐、指标输入追到原始数据、成果字段里的数回指得上才完整出具；受管级要求每个指标静态地追到原始数据（governed.metric_untraced）；出具横幅和应用印章写明按指标 - 受管工作流降为已发布只给管理员（Q8 顺延，服务端同样拦）；工作流接口带当前发布版的级别，画布上改过之后也认得出受管工作流	2026-10-15 07:15:37 +08:00
ThearchyHelios	bb85fbc3ce	应用检查：静态文字里的数和固定版本里节点配置写着的数（审批金额线、时限、会签人数这类流程规则）对得上算有出处，对不上的列出是哪几个数、说明数据要绑定、规则要先写进工作流；应用润色助手的提示词同步：规则在固定的版本里没有就不照写，在说明里告诉用户（真实模型验收发现）	2026-10-14 23:58:12 +08:00
ThearchyHelios	bff3062a97	集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮	2026-10-14 22:08:33 +08:00
ThearchyHelios	d67349562a	应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	acb9ae1774	应用平台集成（后端访问面）：开登录后使用者的问数据只能是探索运行、节点与工具白名单、查询结果在工具边界遮罩且数据源强制只读、记忆与知识库范围不能自选，运行流按运行判读权限；对话按建立人隔离（应用助手对话要 manage）；能力字段语义的审阅队列与批量审阅；按需视图每日上限登记为设置项；通用设置接口不再读写登录设置；运行带来源、按来源筛选，审批带待办 id（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	0f32b8335e	应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	acdc9677a8	应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	00bd51b9a5	应用平台 BE-3 应用：「已发布且未退役」的唯一判定与版本退役，正式运行接受固定的已发布版本并核对 expect_hash（F1），口径升版只看已发布版本（F3），有应用固定或生效记录时拒绝删除工作流（F4）；表达式的根名字与禁止算术参数，表单子集校验与输入节点字段转换，应用对象、发布、版本、授权、页面解析与视图模型（三种来源、缓存、印章、证据指针、遮罩）、入口发起实例、应用操作、app.* 检查、确定性派生、账本只读接口、指标证据链接口（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	5dba66c2b6	应用平台 BE-1 治理底座：身份三种模式（off 默认 / local / oidc）、会话与 CSRF、中间件写入身份、角色与组与审计、按权限矩阵挂路由级依赖、运行与工件的读权限和 user 角色遮罩、reset-admin 找回；能力登记（同步、治理与乐观锁、发起快照、发布版本、作证判定）、登记的端点与平台执行器（分环境、演练、幂等头、身份断言、端点快照作证）、密钥加密与掩码、MCP 的 SSRF 与认证头、写入能力只进调用工具节点、正式运行里只读免审批的能力直接执行、四条 action.* 发布检查（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	220fd0e365	应用平台契约骨架：新表（身份、能力与端点、应用、待办与生效记录、通知）与迁移（补列、多列索引），运行来源与新事件类型，「人」的唯一入口 api/deps.py（关登录时行为不变），应用描述与表单的形状、受信组件目录 v1，各包跨包函数的签名桩，新路由登记，发布门禁的扩展钩子 EXTRA_LINTS；前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页	2026-10-14 17:53:40 +08:00
ThearchyHelios	49f00c589a	目录修改提案的依据改存成目录项单独的字段 reason（界面上叫「确认时的依据」，最多 500 字，超了截成 499 字加「…」），不再拼进备注：拼进 note 之后，带依据保存的关联关系再剖析时测量的说法换不了新、和覆盖率那一栏对不上；改了值的关联关系旧依据叠在新依据后面、越存越长；值不变、保存即确认的项撤销审阅回到推断后「依据：使用者说……」还挂着，看起来像使用者确认过一条推断项。去留：值改了（关联关系也一样）换成这次的依据，没写就去掉旧的；值不变的确认换成这次的，不叠；单项确认、驳回留着，撤销审阅去掉；整份提交改了值的、状态改回推断的、双盲复算改写的去掉；剖析刷新关联关系的测量只动备注。校验认 reason（文字、最多 500 字），起草、剖析的合并不碰人工确认的项，导出导入时已确认、已驳回的项连依据一起带，推断、有确证的项不带。表助手背景里已有的依据写成「以前确认时的依据：……」，系统提示词和 propose_changes 的说明写清那不是这次对话里使用者说的话、引用时写「以前确认时的依据写着：……」，遮罩列的项不给。表详情里依据和说明分开写：表级的项在值下面另起一行，列的一格、关联关系另一个悬停图标（读屏念「确认时的依据：……」），状态弹层里也写，驳回的项只在弹层里写；check-catalog-loop 的假服务端照服务端记下依据，补依据和说明分开、弹层、驳回项的检查；README 表助手一行写上依据另存	2026-10-14 15:38:15 +08:00
ThearchyHelios	20bef14520	保存目录修改提案时依据随项保存：表助手、助手流里「建议更新数据目录」的提案经 /catalog/{table}/patch 保存，写了依据的项备注记成「依据：……」（超出目录文字项的上限 500 字截断），没写依据的照旧；值不变、保存即确认的项和沿用了测量备注的关联关系，依据写在原来的备注前面（关联关系的剖析备注再剖析时整段换掉，放在前面才留得住）。表详情里人工确认的项有备注时也看得到：表级的项写在值下面（同有效记录条件的说明），列的一格、关联关系悬停看；check-catalog-loop 的假服务端照服务端记下依据，补保存后看得到依据、人工确认项的说明两处检查	2026-10-14 14:07:14 +08:00
ThearchyHelios	6baebe821a	合入数据目录闭环第一步（后端 B）：表助手（表详情页对话，流式返回，成批提出经校验的修改提案，只在开了剖析的源上经只读守卫跑查询、结果先遮）；审阅队列（按使用次数、风险、来源排序，批量确认驳回逐表乐观锁，表被哪些运行用过，审阅进度）；数据目录导出导入（先预览，确认和驳回的照带、冲突保留目标、推断只填空缺、对不上的跳过并写原因）；一次修改上限提到 200 项	2026-10-14 10:16:53 +08:00
ThearchyHelios	813522ec7b	表助手：待保存的修改不设上限、有效记录条件按起草的规矩核对。宽表上逐列补中文名、含义，几轮下来待保存的修改常常超过一次保存的 200 项，以前请求里超过 200 项就 422、对话用不了；现在交多少都收，背景里只列最近的 200 项（界面上新的提案接在后面）并写明另有几项，码值照全部待保存的修改合并。模型提的有效记录条件是 SQL：按 sqlcheck.valid_filter_problem 核对（一个条件、只用这张表的列、不能有子查询、聚合、窗口、分号，只能用几个函数），sqlcheck 里还没有这条规矩时至少核对用到的列都是这张表的、都在表结构里、没有子查询，不过的不交给界面、原因交回模型；系统提示里先写明这几条写法	2026-10-14 09:52:37 +08:00
ThearchyHelios	7c3484adba	数据目录闭环第一步（后端 A）：起草遗留——宽表逐段落盘、按比例止损、块进度、停止后的说法、同步起草与任务互斥 ... - 宽表逐段落盘：每写出一段（表级那段、每个列分段）就把这张表到这时拿到的内容并入目录（catalog_jobs.write_part，这一次合并不删任何东西）；整张表写完（ok、partial 都一样）再按完整覆盖的规则收尾一次，只删已经不在表结构里的列的模型项（write_draft 对 partial 也照删）。停止、服务重启时已经写进去的段留着；写过段的表照旧记 cancelled，model_error 写「已停止：已写进目录 N 段，剩下 M 段没起草」（中断写「已中断：…」）。新增、更新、删除的计数是各次写入的合计 - CatalogDraftTask 加 parts_written（已写进目录的段数）、chunks_total / chunks_done（这张表实际分成的块数和已结束的块数，段被缩小的上限分开、拆成两半后会变多；不用模型时为 null），升级时补列 - 止损按比例：这次起草最近 10 次调用有 7 次以上没写出来时，之后的段不再拆小、每块只问一次（不补问漏掉的列、截断后不再补剩下的、空壳不再原样再问，拆出来还没问的块也不再问），直到比例降下去；去掉会被偶尔一次成功清零的「连续 2 段」「接连超时」两条。结构化输出只给空壳的，这次起草还没换纯文本问过的照旧问一次；额度被拒、结构化输出不支持、网络错误这些通信上的重来照旧 - 同一张表接连 3 个原始段都一项没写出来：剩下没开始的段跳过不问，原因写「这张表接连 3 段都没写出来，剩下的 N 段已跳过，可以换一个起草模型后只重试这张表」 - 原因里「已拆小重试仍没写出」只跟在真拆过的那几段后面说：说到的段只有一部分拆过时写「其中第 3 段已拆小重试仍没写出」 - 目录清单的 last_draft 加 blank_columns_from（最近一次结束于 ok / partial 的用模型起草记下的留空列数；之后有起草写进了新内容时为 null）和 parts_written - 同步起草和后台任务双向互斥：同步起草进行期间同一个源建任务、重试、导入（ensure_idle）、再开一次同步起草都 409 catalog_draft_busy（进程内登记）	2026-10-14 08:31:35 +08:00
ThearchyHelios	a5d9ee0a16	表助手：表详情页里和使用者对话完善一张表的数据目录（POST /catalog/{table}/assistant，SSE：正文增量、只读查询、修改提案、完成、出错）；交给模型表结构、目录现状（每项的来源和状态）、关联关系（含别的表指过来的）、剖析结论、起草要求、使用次数、最近一次起草留空的列和界面上待保存的修改，遮罩列只给列名；提案按 plan_patch 核对（公式不收、列名必须在表结构里、遮罩列不给码值、已确认的同值不提），待保存修改里的码值并进新提的码值，只交给界面不写目录；只读查询只在开了数据剖析的源上给，经剖析的只读守卫和单条时限、每次请求最多 5 条、50 行交给模型，结果和报错先遮再交；模型取法、说法同起草（用不了 409），保留思考、额度 32768 可退回 8192、单次时限同起草，还没输出时网络错误和 429、5xx 重试，等待时发 SSE 注释保活，停止时正在进行的调用跟着停；PATCH 一次最多 200 项（预览和保存）	2026-10-14 08:20:02 +08:00
ThearchyHelios	2298cf848a	数据目录导出导入：导出为「<数据源名>-数据目录.json」附件（全部状态的项、起草要求）；导入先预览再写入，表名、列名按表结构的写法再忽略大小写对（带 schema 前缀的去掉前缀再对），关联关系两端换成目标的写法并重算编号；已确认、已驳回的项照带（来源、状态不变），目标里已确认、已驳回而不一样的保留目标的并记冲突，推断、有确证的只填空缺；表结构里没有的列、两端对不上的关系、目标遮罩列的码值、不合规的项跳过并写原因；逐表乐观锁、一张表写不进去不影响别的；有起草任务时 409，文件格式不对 422，没有表结构 409；起草要求只在勾选且目标还没有时写入	2026-10-14 08:06:45 +08:00
ThearchyHelios	adc56da6cf	数据目录审阅队列：推断的项按「使用次数权重 × 风险权重 × 来源权重」排好（有效记录条件、去重规则、业务日期、关联关系最高，模型起草、命名推断比库注释优先），带排在这里的理由，可按影响数字的项 / 名称和说明、按表筛选和分页；批量确认、驳回、撤销审阅逐表按版本乐观锁，同一张表的几条一次写入，一张表冲突不影响别的表；表被哪些运行用过（新的在前，取法同使用次数，抽出 query_snapshot_tables 共用）；审阅进度（常用 20 张表、全部、影响数字的项）	2026-10-14 07:59:51 +08:00
ThearchyHelios	afc98d1318	旧的同步起草 POST /catalog/draft：同一个源有排队或进行中的后台起草任务时回 409 catalog_draft_busy（和建任务同一句话），不再两边同时写同一个源的目录、抢模型名额	2026-10-13 20:30:02 +08:00
ThearchyHelios	975dde1146	起草引擎按验收修正：列分段均分、超时拆小、段大小随模型减半、每段 8 次封顶、提醒、超时与没写出来的计数、模型留空的列、不插队、原因写清哪几段哪几列 ... - 均分：超过 40 列的表，列分段数是列数除以 40 向上取整，各段列数平均（相差不超过 1），不再留下 2 到 8 列的尾段（实测 会思考的模型常对这种小段只给空壳）；表级那段、窄表拼段、parts_total 不变。 - 拆不开的段（不到 10 列）只给空壳：再问一次，结构化输出换纯文本，已经走纯文本的原样再问，仍是空壳才记没写出来。 - 超时当作这一段太大：不再原样重试同样大小的段，按额度用完的办法拆小再问；网络错误、429、5xx 仍原样退避重试。 - 段大小随模型调整：一次起草里额度用完或超时累计 2 次，之后新开始的段列数上限减半（40 → 20 → 10，最低 10），新开始 的段超过上限就先按上限均分开（多表的段按表重新拼）；任务记当前的上限 part_columns。 - 封顶：一段（连同它拆出来的、补问的、重试的）最多调用 8 次，到了次数还没写完的记没写出来、原因写清。止损照旧。 - 提醒：最近 6 次调用有 4 次以上没写出来（额度用完、超时、空壳、出错），任务的 notice 写一句提醒（次数、原因，建议在 「设置 → 偏好设置」的「起草模型」换一个模型、减少表或停止）；之后最近 6 次里少于 2 次就清掉。 - 用量：进度回调 usage 换成 call_done（CallReport：用量、没写出来的原因种类、当前的提醒和列数上限），任务的用量加 timeouts、failed_calls；超时的调用 token 照实记 0。 - 留空的列：请模型写了、模型也列出了，中文名和含义却都没给（或者给的都没通过校验）的列记在 ModelOutcome.blank，逐表 记 blank_columns 和最多 5 个列名 blank_sample，任务上是合计，目录清单的 last_draft 也带列数；表的状态不因此变。已确认 的、库注释已经说清的列不算。补问时把漏的列列出来、字段却留空的，算留空，不再记成「漏了这些列」。 - 公平排队：宽表的表级那段写完，它的列分段排到已经排着的段后面（先来先服务），不再插到队首让窄表一直等。 - 原因：几段因为同一个原因没写出来时说「这几段」，同一段拆出来的几块仍是「这一段」；只有真拆小过才补「已拆小重试仍 没写出」（截断后只补剩下的不算）；每段写上列的范围，例如「第 5 段（列名 到 列名，共 33 列）」，窄表写出是哪几列。 - 库：catalog_draft_jobs 加 timeouts、failed_calls、part_columns、notice，catalog_draft_tasks 加 blank_columns、 blank_sample，旧库启动时补列（存量回填 0 和空）。假模型加 hang（头几次调用一直不回，用来模拟超时）。	2026-10-13 20:30:02 +08:00
ThearchyHelios	38d6f47e67	PUT /catalog/guidance 的请求没写 guidance、或者不是一段文字时回 422 带一句中文说明（同超长时的写法），不再是 pydantic 的英文校验结果；表名恰好叫 guidance 的整份提交照旧	2026-10-13 16:48:46 +08:00
ThearchyHelios	c1a70ecf38	数据目录起草改成后台任务：新表 catalog_draft_jobs、catalog_draft_tasks 存任务和逐表状态，同一个源同时只有一个排队或进行中的任务（接口先查、部分唯一索引兜底）；POST /catalog/draft-jobs 建任务（202），GET /draft-jobs/active、/latest、/{id} 读任务，/cancel 停止（排队的直接停，进行中的停掉正在进行的模型调用，已写进目录的不回滚），/retry 只重试失败、只写出一部分、停止了的表；同源 409 catalog_draft_busy、起草模型用不了 409 catalog_draft_model_unavailable、已结束 409 catalog_draft_finished；每张表一结束就并入目录，进度、计数、用量随时落库；服务启动时把没做完的任务标成中断、不自动续跑，关停时同样；目录清单每行加 last_draft，顶层加 guidance、active_job；数据源级的起草要求存在 options 里，经 PUT /catalog/guidance 维护（最多 2000 字，表名恰好叫 guidance 的整份提交照旧），数据源接口不显示、整份回写 options 时留着，拼连接串时摘掉；本次说明最多 1000 字，任务记下起草要求和本次说明的快照，同步起草也带上数据源的起草要求	2026-10-13 15:33:00 +08:00
ThearchyHelios	b940b27e24	起草模型设置：新增设置组 catalog_draft（接入、模型），点名的接入不存在或已停用时保存回 422；数据目录起草和按配方导入的 AI 起草共用一处取模型（起草模型 > 助手的模型 > 默认接入），取自起草模型时报错照实说起草模型那一项；数据目录起草不再关思考，额度 32768，服务方嫌大时退回 8192（之后都用小额度），单次调用时限 420 秒交给 SDK；配方 AI 起草的额度、思考设置不动	2026-10-13 15:00:38 +08:00
ThearchyHelios	1e95f41a10	报告导出成 HTML 时，升级前写的老文档里取自遮罩列的指标写「已遮罩」：正文引用了、证据目录里却还带着原值的那几个，按可验证报告认老文档的同一个判断（certain_masks + bundle/build.py 的 withheld_metric_aliases，只认确定取自遮罩列的）照现在的报告撰写节点的写法改写，正文、按钮提示和出处链里都不出现原值；普通指标照常，现在写的文档本来就是「已遮罩」	2026-10-13 10:04:30 +08:00
ThearchyHelios	06b2c2b8ae	合入报告导出为自包含 HTML（数字点得开口径、来源、计算方式）与可验证报告数字详情里的口径卡一节；和可验证报告的遮罩改造合并：口径卡只给 id 的规则（有指标的值取自遮罩列、文档里写成「已遮罩」的）照旧，随文件附带的卡才附上它的输入指向的查询快照；数字详情保留显示文字核对和超过 2^53 的数照 JSON 原文显示，口径卡一节里输入的值同样照原文；样本页从 16 份变成 17 份	2026-10-13 10:03:24 +08:00
ThearchyHelios	7589c350bd	期 5 验收修复 N1 第 4 轮：转抄上游口径卡按整张卡、每一次执行认（保守规则）；显示文字白名单收紧复核点名的几类，软换行和金额符号不再误伤 ... 复核第 3 轮（91aa34d）找到三处 major、两处 minor：循环里卡转抄自己上一轮、更早一轮取过号码（SQL 带模板）时，写作目录只看 运行状态里最后一次的产出，号码进了报告正文和成果，自查通过、正式运行成功，封存之后的面板才写「已遮罩」；整张卡、清单文字、 下标不是字面量的转抄只按值认，由遮罩格算出来的年薪（月薪 × 12）在写作目录、报告、成果、证据面板、可验证报告里照给；显示 文字的白名单里还收着易混字（’ 当千分位、刂 当竖线、×10⁴ / T / bn / m 改量级、en dash 当负号），伪造页总览照样是绿色的 「全部通过」；先起别名再套没起别名的表达式、+phone 这类 SQL 写法认不出遮罩列；段内软换行紧挨着数字、数字前的 ￥ ¥ 被判 无法核对，原样导出的正常报告总览变成中性。 转抄的保守规则（recompute.masked_closure 的 CopyEdge.card；写作目录、报告自查、证据面板、推演、可验证报告同一个判断） - 卡上的输入转抄上游口径卡（字面量下标、下标不是字面量、整张卡、清单文字、整份指标列表都算），只要那张卡在这次运行的任何 一次执行里有一个指标不给，转抄出来的就不给（masked，整张卡转抄不再降成 table 按值认）；那张卡一个不给的指标都没有时照常， 没设遮罩的工作流、循环里累加自己上一轮的卡照给（第 3 轮修好的那条不回退）。最小不动点上按卡汇总：每张卡「有指标不给」 只从无到有、遮罩列只增不减，变一次只重认转抄它的那几个，工作量仍和边数成正比 - 每一次执行的指标集按台账认：写作目录（withheld_metrics）把运行状态里台账的 metric_set 条目交给 _CopyGraph（_executions， 连同它们的输入先在线程里读好），封存之后按封存范围内的台账；可验证报告（_Store._executions）按 node.finished 的台账条目 - 转抄的是哪张卡按读到的产出上记着的指标集认（经数据整形赋给变量的也认得出是哪张卡），认不出的按取值链上的节点 - 推演（recompute._copied）、证据面板（_copied_held）随之去掉整张卡转抄的 table 一档 - 行为变化：转抄了带遮罩指标的卡的普通指标（客户数、数指标个数、清单字数）也写「已遮罩」、推演不让改，正式运行引用它判 失败；那张卡自己的普通指标照给。test_report_masked_card_copies、test_report_masked_copy_closure 里按老规则写的期望相应改了 显示文字核对（verifier.js） - 弯撇号（U+2018、U+2019）移出常见写法的名单；偏旁形的汉字（刂冫氵亻阝扌忄犭礻衤讠钅饣纟丬）、康熙部首、部首补充、扩展 B 区以后的字不算常见写法：紧挨着数字判无法核对 - 数字后面紧接 ×、*、^ 再接数字判无法核对（新原因「后面紧接着乘号或乘方和数字」），后面那个数本身也核对过的（两个数相乘） 不算 - 数字后面紧接着、或隔着空白和左括号的英文量级写法（T、G、m、b，bn、mn、tn，thousand、million、billion、trillion）按整串 字母认，判无法核对；ms、GB 这类别的单位不算 - en dash 归入像负号的短横：紧挨在数字前面判无法核对（不判不通过），前面是数字、字母的区间照常 - 段内的换行（页面上显示成一个空格）、金额前面的「￥」「¥」收进名单 - 「（单位：万元）」、x10 这类隔着几个字或换了写法的认不出：名单只是兜底，bundle/build.py 的模块说明写明真伪以封存哈希为准 已知局限不再加规则：api/evidence.py、bundle/build.py 的模块说明写明遮罩只减少暴露、不是安全边界，列出认不出的 SQL 写法 （先起别名再套没起别名的表达式、+phone、Postgres 给没起别名的表达式起的列名、视图、自己建的函数、数据整形取出来的号码）。 验证 - 新增 tests/test_report_masked_copy_any_run.py（20 项）：纯函数上的边规则（四种写法、循环三轮、之前认好的指标、读到的产出 读不出来）；循环里转抄更早一轮的号码（护栏写法、只按字面量下标两种）写作目录写「已遮罩」、正式运行判失败，标注时文档、 成果、面板、可验证报告都没有号码；循环之后的卡转抄最后一轮，写作目录、面板、推演、可验证报告同一个判断，可验证报告自己 （没有报告的运行、老文档）也认；经数据整形转抄的按卡本身认；年薪的五种转抄写法写作目录都写「已遮罩」，标注时文件里没有 年薪；没碰号码列的循环、卡上没有遮罩指标的照常 - test_bundle_shown：复核点名的几类各自判无法核对、写明原因、总览中性；软换行、￥ ¥、两个核对过的数相乘、en dash 区间、 ms / GB 照常通过；PROSE 样本去掉 en dash，加上软换行和 ￥ ¥，17 处全部通过 - check-bundle 补弯撇号、刂、扩展 B 区、×10⁴、bn、billion、en dash 七种篡改（各自判无法核对、点名、总览中性），prose 样本 17 处全绿 - 复核者探针：test_probe_r3a、test_probe_r3c 的写法都拦住；test_probe_n1c（没设遮罩的循环自引用）照常；layout_probe 的 108 种写法里点名的几类都判无法核对，￥ ¥ 照常通过；Chrome 断网打开 forge3、forge4 的伪造页，点名的几类都不是绿的、提示 都显示 - 开发数据 39 份报告 1591 处、验收数据 58 份 1695 处引用按新规则扫过，判不通过和无法核对都是 0 - 每处改动都做了「去掉实现、测试变红」：17 个定点变异（不看整张卡、不读每一次执行、写作目录不交台账、可验证报告不读每一次 执行、整张卡退回按值认、推演不认、按取值链上的节点认卡两处；弯撇号、偏旁、扩展 B 区、乘号乘方、英文量级、en dash、软换行、 ￥ ¥、两数相乘豁免）全部变红	2026-10-12 23:01:09 +08:00
ThearchyHelios	91aa34d014	期 5 验收修复 N1 第 3 轮：转抄上游口径卡的遮罩改在指标依赖图上一次算出最小不动点；显示文字核对紧挨着的字改成白名单 ... 复核第 2 轮（ce71f7d）找到两处 major、两处 minor：转抄的识别逐个往上递归、追够八层（CARD_DEPTH）就按遮罩算——没设任何遮罩 的工作流里，循环里累加自己上一轮产出的口径卡在写作目录里指回自己，一直追到八层，写成「已遮罩」，正式运行判失败、报错说 「取自设置了遮罩的列」；每个指标的护栏 nodes.acc 选中整张卡的全部指标，递归次数约为（指标数 + 1）的八次方，四个指标四十秒、 卡住事件循环；封存之后循环超过八轮的，证据面板写「已遮罩」，可验证报告把文档整份只给哈希。紧挨着改字仍是黑名单：西里尔、 希腊的 I、O、M、K，汉字「丨」，换行、制表、各种宽度的空格后接「万」，「（万元）」，负号前面放一个别的文字系统里长得像撇号的 字母，都还是绿色的「全部通过」、提示也不显示。另有：* 展开派生表、WITH 里没起别名的 UPPER(phone) 认不出是确定取自遮罩列， 号码进了写作目录和文档；上游卡的节点产出读不出来时转抄当作认不出出处，号码随卡 2 的节点完成事件出去了。 转抄的遮罩在指标依赖图上一次认（recompute.masked_closure，写作目录、证据面板、推演、可验证报告共用） - 先按转抄以外的输入认每个指标（写作目录、可验证报告认老文档只按确定取自遮罩列的 sure；证据面板、推演宁可多遮），再沿转抄的 边（nodes.<卡>.metrics[i].value、vars.<assign_to>.metrics[i]、整张卡 / 清单文字 / 整份指标列表 / 下标不是字面量的连到那张卡 的全部指标）往下游传，直到不再变化。从「都照给」起往上收：环（循环里抄自己上一轮、几张卡互相转抄）本身不带来遮罩，环上有 一个指标别的输入取自遮罩格，整个环都不给。每个指标的结论只往严里变，工作量和边数成正比；删掉 CARD_DEPTH、CARD_TOO_DEEP 和逐层递归（_InputMasks._copied、_Store._copied_kind），可验证报告的缓存不再按 (卡, 指标) 混着深度记 - api/evidence.py 的 _CopyGraph（按请求记在 _Masks 上，键是 (指标集工件, 指标在卡上的位置)）：写作目录只有最后一次的产出， 抄自己上一轮的卡是一个环；封存之后按每次执行认（_card_outputs，同一次执行只找一次），一次一次往回连到第一轮。bundle/build.py 的 _Store.metric_word 按同样的键各认法一张图 - 推演（api/whatif.py → copied_inputs）的转抄输入按证据面板同一张图认：转抄的是不给的指标就不给值、不能改（原因「转抄的口径卡 指标取自设置了遮罩的列」），核对不了的不给、不推演。以前只按值认，转抄来的三位数余数照给、还能改 - 上游卡当时的产出读不出来（文件不在、与哈希不一致）、卡上又记着这个输入出自口径卡、转抄来了值的，转抄核对不了（同按位置取的 一格取值链上的产出读不出来），可验证报告里卡 2 只给哈希；第一轮还没有上一轮（转抄来的是空值）的不算 - 可验证报告附带口径卡另看卡上记着的转抄值（_copies_masked）：转抄的是不给、核对不了的指标，或者整张卡、清单文字转抄来的值里 写着号码（len(nodes.card.text) 的输入就是整段清单文字），卡只给 id。指标的值照给时以前照常附带 - 确定取自遮罩列（_sure）在整份算的快照里另按列名认（_named_from_masks）：SQLite、MySQL 拿没起别名的表达式原文当列名，* 展开 派生表、WITH、UNION 一支时原样带出；按列名拼一条只选这一项的 SQL 交给同一套认，COUNT(phone)、FILTER、分档标签照旧不算。 单元格引用的自查、收遮罩值、裁判摘录跟着收紧 显示文字核对（verifier.js）：紧挨着数字头尾的那一个字改成白名单（COMMON） - 名单：汉字（含「一」，去掉丨、丶、丿这类笔画字）、中文标点、半角和全角空格、ASCII 字母、常用半角标点和 = + / ~ * # < > 等 算式符号、× ÷ ≈ ≤ ≥、上一轮放行的破折号写法（——、—、–、―、﹘、ー、─、〜、〰）；逗号、句点、连字符看上下文（句点在数字头 前面只认 NO. 这种字母缩写）。名单以外的（别的文字系统的字母、制表换行和各种宽度的空格、零宽字符、全角拉丁字母、表情）判 无法核对，原因「紧挨着这个数的字不在常见写法里，无法确认读者看到的数」，总览随之不是绿的、显示去系统里核对的提示 - 像数字的字母另收 o、竖线一类（|、｜、丨、竖排破折号、制表符竖线、拉丁 / 西里尔 / 希腊里长得像 l、I 的）和圆圈一类（西里尔、 希腊的 O、空心圆）；量级单位另收十、拾、佰、仟和当「万」用的 w、W，前面隔着的改成任何空白和左括号、左引号（「（万元）」） - 负号前面的「编号」例外只认 ASCII 字母数字；后面接 e 和数字（科学记数法）同紧挨着数字，判不通过 - 开发数据 39 份报告 1591 处、验收数据 58 份报告 1695 处引用按新规则扫过，没有一处判不通过或无法核对；prose、formats 样本原样 导出全绿，别的样本页总览和第 2 轮一字不差；复核者的 42 种伪造写法（forge.py、forge2.py）全部不是绿色、提示都显示 测试 - 新增 tests/test_report_masked_copy_closure.py：没设遮罩的循环自引用照常显示、正式运行成功（复核者的探针）；循环三轮、十轮的 老文档照常附带；两张卡互相转抄照给；环上一个输入取自号码列整个环都不给、同循环里不相干的卡照给；上游产出读不出来三种转抄 写法都不漏号码；卡上记着转抄清单文字的卡不附带；推演按同一张图认转抄输入；* 展开里没起别名的号码表达式八种写法算确定取自 遮罩列、只数个数和分档标签的不算；纯函数的环、整张卡转抄、读不出来、两千个指标线性；写作目录和可验证报告在三张卡各 8 个 指标、循环十轮时各一秒以内（写作目录每个指标只认一次），另有真跑两张卡各 8 个指标十轮的计时 - test_report_masked_card_copies：认转抄补读不出来的几种；「追不到头按遮罩」改成环上认（没别的输入照给、有号码输入整个环不给） - test_bundle_shown：名单以外的字、像数字的字母、隔着各种空白和左括号的量级单位、别的文字系统字母后的负号、科学记数法各自判 无法核对或不通过、总览不是绿的；常见半角标点、算式符号照常通过；表情紧挨着数字改判无法核对（隔一个空格照常通过） - check-bundle 补长得像 I、M 的西里尔字母、汉字「丨」、数学粗体 l、隔着细空格的一位数、开尔文符号、隔着换行和 em 空格的「万」、 「（万元）」判无法核对，撇号字母后的负号、e3 判不通过，各自点名、总览不是绿的 - 每处改动都做了「去掉实现、测试变红」：整套退回第 2 轮（27 项红、写作目录计时十秒没认完、可验证报告长循环把文档只给哈希）； 环按遮罩算、不沿边往下游传、读不出来当认不出出处、不看卡上的转抄值、不按列名认、推演不用依赖图、每个指标各建一张图；名单 不判、名单去掉等号、不去笔画字、像数字的字母不扩、量级单位前只隔空格、负号例外按文字区、科学记数法不算、单位不收十和 w、 句点不看前面是不是字母	2026-10-12 21:12:57 +08:00
ThearchyHelios	ce71f7d5c1	期 5 验收修复 N1 第 2 轮：取自遮罩格的指标只按确定取自遮罩列的认、转抄上游口径卡的也认；显示文字核对不误判正常写法，总览有一项无法核对就不给绿色的通过 ... 复核第 1 轮（abb2707）找到四处：写作目录按证据面板宁可多遮的那一套认指标出处，SQL 认不准时没碰号码列的销售额也成了 「已遮罩」，正式运行引用它就判失败（相对基线回退）；「紧挨着负号」连破折号「——」「—」和汉字「一」都算，「运费统一10元」 「合计——7,036.50元」原样导出变红（相对基线回退）；紧挨着改字只堵住了数字、负号、小数点，接「万」、画删除线、从右往左 书写的字母、l / I / O 照样全绿，根子在总览把无法核对的项也给绿色；第二张口径卡转抄遮罩指标（nodes.<卡>.metrics[0].value、 vars.<assign_to>.metrics[0].value、nodes.<卡>.text）时号码照样进写作目录、文档证据目录和可验证报告。 取自遮罩格的指标只按确定的那一套认（写作目录、报告自查、可验证报告同一个判断） - 写作目录（api/evidence.py 的 withheld_metrics）认指标出处时遮罩列只认确定取自遮罩列的（_InputMasks 的 sure：读得出来的 快照按单元格引用自查的 _cited_masks，读不出来的按数据源现在设的列名），和 [[v:…]] 引用同一格的自查同一个口径：WITH 写了 列名表、VALUES 当表、子查询里有没起别名的号码表达式、只装着分档标签的列，指标照常显示、照常引用；改了名字、套了函数的 号码列照旧「已遮罩」。证据面板、推演照旧宁可多遮。报告自查按目录里记的 masked 认，跟着同一个判断 - 可验证报告认老文档（证据目录里还写着原值，整份只给哈希）按同一个判断：api/bundle.py 先按证据面板的那一套认好每份查询 快照里确定取自遮罩列的列和这次运行查到过的遮罩值（certain_masks），交给 build_bundle（sure_columns、sure_secrets）， _Store.metric_word 的 sure 按它们认。认口径卡能不能随文件附带照旧宁可多遮（卡上记着输入的值），SQL 认不准的卡同基线只给 id 转抄上游口径卡的指标按上游那个指标认 - recompute.card_input 认出输入转抄了哪张卡的哪几个指标：nodes.<卡>.metrics[i].value、vars.<卡的 assign_to>.metrics[i]、 整个指标、输入、渲染算转抄那个指标；整张卡、清单文字、整份指标列表、下标不是字面量的同整份查询结果（值里有遮罩值才不给， 数指标个数的照给）；只取名称、单位、口径名的不算 - 证据面板 / 写作目录（_InputMasks._copied）、可验证报告（_Store._copied_kind）都用同一个 _metric_masks / metric_word 往上追， 上游取自遮罩格，转抄的也不给；追了 CARD_DEPTH（8）张还没追到头（循环里抄自己上一轮的产出）的宁可多遮 - 写作目录读快照前把运行状态里每张口径卡的输入一并读好，不在事件循环里读盘 显示文字核对（verifier.js） - 判不通过只剩紧挨着的数字、小数点，和真当负号用的三个（半角连字符减号、数学减号、全角减号）紧挨着数字开头、前面又不是 字母数字时（「SKU-12」「A-3」的连字符是编号的一部分）。破折号（——、—、–、―，小号的、竖排的）、波浪线、汉字「一」、 假名长音、制表符横线这些易混字当普通的字。连字符、不断行连字符、上下标负号、粗减号这类平时不当负号用的短横紧挨着数字 开头判无法核对（以前判不通过；基线也是无法核对） - 判无法核对（带原因）：后面接着量级单位（万、亿、千、百、兆、萬、億、%、‰、‱、k、K、M、B 及全角，中间隔着空格也算； 核对过的字以「万」「亿」结尾再接一个也算），核对过的字画着删除线或紧挨着画了删除线的字，紧挨着长得像数字的字母和数字 符号（l、I、O、上下标数字、圈码、罗马数字、汉字〇），从右往左书写的字母和方向控制字符（照旧） - 总览（overallOf）：一项无法核对都没有、每份报告都核对上才是绿色的「全部通过」；有无法核对的写中性的「可核对的项全部通过， 另有 N 项无法核对」，下面醒目地写明这个文件判断不了真伪，要在系统中核对封存（运行 ID、GET /api/runs/<id>/verify、定时任务 通知里的清单哈希前 12 位）。以前无法核对的项照样给绿色，伪造者只要让读者看到的那个数落进无法核对就行 - 交出 layoutOf 给 node 里逐条核排法；开发数据 39 份报告 1591 处、验收数据 58 份报告 1695 处引用按新规则扫过，没有一处判 不通过或无法核对 测试 - 新增 tests/test_report_masked_metric_sure.py（四种 SQL 认不准的销售额、分档标签照给照引、确定取自号码列的照旧遮、老文档 照常附带、写作目录和可验证报告逐个指标同一个判断）、tests/test_report_masked_card_copies.py（三种转抄写法在写作目录、文档、 自查、证据面板、可验证报告里都不给号码，没有报告的运行、老文档，转抄普通指标照给，认转抄的各种写法，追不到头的宁可多遮）、 tests/test_bundle_prose_export.py（「统一」「——」「—」「SKU-」「共…家」「–」真跑报告撰写节点、从接口导出，全部通过、总览绿） - test_bundle_shown：负号只认三个、前面是汉字的照判不通过；像负号的短横、量级单位、删除线、长得像数字的字母各自判无法核对、 总览中性；正常写法原样导出全绿；总览只在一项无法核对都没有时是绿的 - 样本页新增 prose（写作者自己写在引用旁边的普通文字，原样导出全绿）；check-bundle 补数学减号、紧挨着汉字加负号判不通过， 接万（隔空格）、接亿元、接 %、接 k、订单号接万、画删除线另写一个数、前面加小写 L、后面接大写 O、长得像负号的连字符判无法 核对，各自点名原因、总览中性并写明去系统里核对；有无法核对项的样本页（base、legacy、continued、missing-card、masked-card、 masked-source、nan）总览改断言中性，从右往左书写的字母那条不再断言总览是绿的 - 每处改动都做了「去掉实现、测试变红」：写作目录不用 sure、老文档不用 sure、sure 列不用、转抄认不出（三处各自）、追不到头 按核对不了、负号的字母数字例外、负号恢复成 \p{Pd} 全部、数学减号全角减号不算、量级单位、隔空格、以万结尾、删除线、像数字 的字母、像负号的短横、总览有无法核对照样绿	2026-10-12 19:09:50 +08:00
ThearchyHelios	abb2707904	期 5 验收修复 N1：取自遮罩格的口径卡指标不进报告文档和可验证报告；显示文字核对堵住紧挨着改字的绕过 ... 验收第二轮发现：口径卡 phone_raw = cell(q_cust, 0, 'phone') 被 [[m:phone_raw]] 引用时自查不拦，号码写进正文；写作目录、 文档的证据目录收着上游口径卡的全部指标和原值；可验证报告里口径卡的节点完成事件（预览逐条写着「指标（名称）= 值」）一律 附规范串，没有报告的运行也照样带出号码；另外只改紧挨着被引用数字的普通正文（前面补一位数、加负号、后面接「0 万」）、重算 全部哈希，读者看到的是另一个数，核对页只标无法核对，总览仍是绿的。 报告撰写节点 - 写作之前按证据面板指标步骤的那一套认出值取自遮罩格的指标（api/evidence.py 的 withheld_metrics → _metric_masks， recompute.withheld_value）：cell() 取的遮罩格、改了名字的遮罩列、按位置取的一格一行、整份结果里带着遮罩值的。写作 目录、存进文档的证据目录里这些指标的值、渲染、标签都写「已遮罩」并记 masked（evidence.withhold_metrics，没被引用的 也一样），写作目录另说不要引用 - 只按出处认（by_value=False）：认不出出处、值碰巧等于遮罩列某一格的普通指标（写死的目标 20000）不算，不然它在报告里 成了「已遮罩」、引用它的正式运行判失败、写作者也改不掉（自查第 3 轮去掉按值认是同一个道理）；证据面板展示上照旧多遮 - 引用这类指标照样解析、正文写「已遮罩」（换算不再算），自查记 masked_cell（evidence.masked_metrics），和引用遮罩格同一 套处置：交回重写，仍不改按「违规处置」办；缺口、日志、判失败的下一步说「指标」 - 写成「已遮罩」的别名记进节点产出（masked_metrics），出口契约复核按同一份重建目录（report_catalog），正文里的「已遮罩」 对得上，不说文档被改过；写作时按上游状态建目录，循环里重跑不沿用上一次记下的那份 - 证据面板点开这一处：值、渲染都是「已遮罩」，按文档写的比渲染，不报渲染不一致 可验证报告（bundle/build.py、verifier.js） - 口径卡的节点完成事件：卡只给 id（有输入取自遮罩列，或者有指标的值不给）的只给哈希，和报告引不引用无关；没有台账的 老运行按预览里的 artifact、节点产出工件认，都读不出来的按运行里有没有带遮罩的快照 - 卡只给 id 的判断另按指标认（_Store.metric_word，和写作目录同一个判断）：整行、下标不是字面量的一格、整份结果转成的 文字，以前只认字面量下标的一格，卡原样嵌了进去 - 证据目录里还写着这类原值的老文档（升级前生成的，或者生成之后数据源才设的遮罩）整份只给哈希、不附带它引用的工件， 报告节点的完成事件也只给哈希；快照读不出来时按它的数据源现在设的遮罩认，卡读不出来时按这次运行查到过的遮罩值认。 核对页照实说明原因（中性色），这份报告算未能核对，总览不是绿的；文档里写成「已遮罩」的指标所在的卡一律只给 id - 被引用的数字紧挨着（中间没有空白、标点）数字、负号、小数点判不通过，点名「正文里紧挨着这个数的字改变了读者看到的 数」；排在看不见、改变方向的字前面判，同一句里再放一个这种字也降不成无法核对。服务端组装的文档两个数之间补了空格， 原样导出照旧全绿（开发数据里 39 份报告、505 处引用，没有一处紧挨着） 测试 - 新增 tests/test_report_masked_metrics.py（目录、自查、重写、标注 / 失败、出口契约、证据面板、循环）、 tests/test_bundle_masked_metrics.py（没有报告的运行、新文档、老文档连同核对页、普通卡、和写作目录同一个判断、手搭的 几条分支）；样本页 masked-card 改成现在的报告撰写节点写的文档，新增 masked-old-doc；check-bundle 补数字前加数字、加 负号、后面接「0 万」三种篡改，各自变红、点名，原有的紧挨着补位、连字符两条改成不通过，报告文档标成遮罩那条改成总览 不是绿的 - test_report_masked_values 的 [[m:phone_raw]] 改成按出处拦、写死的热线号码照常引用；几处按旧的报告正文（「13位」 「11位」「26位」）找片段的测试改成按引用找（test_evidence_metric_masks、test_evidence_masked_aliases、 test_whatif_masked_values），断言照新的正文写	2026-10-12 17:23:27 +08:00
ThearchyHelios	d177289a53	合入 M2 与 K3b 之后的整合修正：报告自查、裁判摘录、收遮罩值认「确定取自遮罩列」时直接用 masking._derived_masks 交回的 whole / collect，不再在结果后面垫一列去探测整份算——K3b 把「没有 * 的一支、列数和结果对不上」也判整份之后，垫过的每条 SQL 都成了整份算，没起别名的 UPPER(phone) 一个值都收不到、裁判摘录里照给号码、引用它的报告照常出具；UNION 后一支是 * 的写法也一并认对	2026-10-12 14:19:41 +08:00
ThearchyHelios	7cec3079f0	合入期 5 验收修复 M2：证据面板与推演按 SQL 认出改了名字的遮罩列；推演里取自遮罩格的指标不露原值；报告自查拦下引用遮罩列的格子（按列名对整个数据源生效，和证据面板同一个口径）；结论句裁判的摘录按快照逐份遮确定取自遮罩列的列；片段接口在没开结论句裁判时照实说；遮罩分析按快照工件 id 缓存	2026-10-12 14:17:45 +08:00
ThearchyHelios	1cfa5a524d	M2 复核第 4 轮：报告自查认遮罩列和证据面板同一个口径，哪张表（含视图）里叫这个名字的列都算；结论句裁判的摘录按快照逐份遮确定取自遮罩列的列；没起别名、盖住全部结果列的表达式算确定取自遮罩列，值照收 ... 第 3 轮的「遮罩表」推断和退回的裁判摘录各开了一个口子，收值时又把按位置认得出的列丢了： - 报告自查去掉「遮罩表」推断（_mask_owners）。数据源的 mask_columns 只认列名、不支持写成「表.列」，按列名在整个数据源上 生效：引用的那一格按 SQL 认出取自任何一张表里叫这个名字的列就记 masked_cell，视图（customer_spend.name）、没有第二个 遮罩列的表（employees.name）、门店名（stores.name）都算，和证据面板的遮法一致。以前经视图引用客户姓名、引用店员姓名， 正式运行照常成功，姓名写进了报告。SQL 血缘只用来点名出处，和排除值确实取自普通表别的列的（SELECT region AS phone FROM stores）；视图、表结构里没有的表、写了别的库名的表、没标 is_view 的老表结构、没有冻结表结构的快照看不出列的出处， 照算（_frozen_schema 只把 is_view 明写为 false 的表当普通表）。违规说明照实写取自哪张表的哪一列：「列「store」按 SQL 认出取自 stores.name，数据源对列名「name」设置了遮罩（按列名对所有表生效）」 - 交给结论句裁判的摘录按快照逐份遮（api/evidence.py 的 _judge_loader）：每份快照里确定取自遮罩列的列（_mask_sets 的 sure）并进交给 judge.prepare 的那一份快照的 mask_columns（工件本身不动），裁判照它自己的办法遮掉，judge.py 不用改。 c.phone AS tel 的号码不再进摘录；不按数据源名合并（另一份快照里同名、取自门店热线的列照给），不用宁可多遮的 hidden （整份遮的快照、只数个数的列照给）。按需裁判和报告撰写节点里当场裁判同一个函数。摘录变了的句子复用键随之变，此前 判过的会重判一次 - 收「这次运行查到过的遮罩值」：_sure 以前凡是要遮的列盖住了全部结果列、名字又对不上，就当认不准、整份算， SELECT UPPER(phone) FROM customers 一个值都收不到，证据面板之后照原样显示 SQL 里写着的号码。现在结果后面垫一列再认一遍 （_whole），垫的那一列也算进来的才是整份算的；按位置认得出的照收，整份遮的照旧只遮显示、不收值 测试：test_report_masked_owners.py 改名 test_report_masked_any_table.py 并按新口径改写（经视图改名 / 不改名、店员、门店名、 客户名真跑判失败且成果里没有值；* 展开、WITH、UNION、视图里改成遮罩列名字的列、没有表结构、没标 is_view、表结构里没有的 表、写了库名的表）；新增 test_judge_excerpt_masks.py（按需、当场两条路的摘录都不给改了名字的号码列，同名的门店热线照给； 没起别名的 UPPER(phone) 摘录也不给）；test_evidence_mask_memo.py 加没起别名的表达式照收值；违规说明的断言跟着改	2026-10-12 13:50:31 +08:00