603 Commits

Author	SHA1	Message	Date
ThearchyHelios	b3dcddb52e	召回复核修正（后端）：人工节点不再挡召回、读不出召回卡记失败、旧版不再接着算、团队渠道一次召回只推一条、目录核对按数据源合并排队；账本接口带上召回标记，对账结果可以反馈 ... - W4R-01：召回只查新版图里会不会写外部系统（apps/backfill 抽出 graph_external_write，graph_side_effect 复用它）。召回图只有两版 的取数和口径卡，图里别处的人工节点、按流程使用的问题碰不到它；口径卡上游的人工节点 derive 本来就认作数据部分不能复用。 「按新版重新出具」走完整的正式运行，仍按 graph_side_effect 全套拒绝。原来带审批的口径升版后一组都不召回，L6 对它们失效。 - W4R-09：收尾时召回卡读不出、或缺了某个比较的旧值 / 新值，照实记重算失败（读不出召回卡），原答案一个不动。原来两边都是空， 按渲染比被当成「没变」，给每个原答案永久盖上「已核对，不影响」，收过尾之后再也不核对。 - W4R-12：这一版已经不是当前发布版（之后又发布了更新的版本）时不再发起召回、不给接着算，批次里写 continue_reason，接着算的 接口 409 带同一句。同启动时接着做只认当前发布版：新版本的召回覆盖更早的所有版本，再按旧版开「口径升到 vN」的待办只是添乱。 - W4R-13：开登录时一组答案几个主人就几条待办，全局渠道却按这一批（recall.batch_of_key：同一次召回、同一个来由）只在最早开的 那条上推一次，答案、待办按这一批汇总，几条的链到待办箱；别的几条连 task.opened 也不再推全局渠道。个人渠道照旧每人一条。 - W4R-11：目录审阅之后的核对按数据源排队、批量审阅的几张表合成一遍（catalog_pass，同一数据源一把锁）；查询快照按数据源在库里 筛、按运行结束时间分页、每张表凑够 BASIS_MAX_RUNS 次运行就停；冻结的表结构快照这一遍里按工件 id 只读一次。原来批量审阅 几十张表就同时起几十个后台任务，每个都全表扫查询快照、反复读同一份几 MB 的表结构快照。 - W4R-03（本包那一半）：GET /api/runs/{id}/ledger 加 recall：checked（已按 vN 核对，不影响）、basis（依据有变：哪一种、几项、 新出现几条错误级问题）、tasks（看的这个人手上说的是这个答案、还没处理的 recall 待办）。不放数、不放表名。几种状态都带。 - W4R-10（本包那一半）：新事件 ledger.feedback（对账运行上的封存后事件），POST /api/ledger/answers/{run}/reconcile/{rid}/feedback {verdict: useful | unclear} 记反馈，同一个人改主意只算最后一次（app/ledger/feedback.py）；账本接口的 reconciled 每一项带 feedback {mine, useful, unclear}；统计 E2 的 feedback 数到它，去掉「第 4 波接上」的占位说法。离线核对页、封存后事件摘要 都认得这个事件。 测试：test_ledger_recall 新增七个用例、改了人工节点那一个（召回照算、重新出具照实拒绝）；新增 test_ledger_feedback； test_ledger_api 的 E2 断言跟上。每个修复都先写失败的测试、去掉修复回跑确认抓得住。后端全量 14237 通过。	2026-10-16 22:16:58 +08:00
ThearchyHelios	bbf6ebb79d	召回收尾：启动时只接着做当前发布版的自动批次、补测重启后从已有召回运行重算计划；时间线认不出的依据种类不猜 ... - ledger/recall.resume：最近发布、之后又发布了更新版本的不再接着做（新版本的召回本来就覆盖更早的所有版本） - 测试：重启前只发起了一组、也没收尾，重启后接着发完自动那一批、补上收尾照样开待办，再重启一次不再发起 - run/decode：ledger.basis_changed 认不出种类时写「答案的依据有变」，不当成目录事实变了；batches 的说明照实写参数原样给搭建者	2026-10-16 20:11:46 +08:00
ThearchyHelios	77fc0efa10	口径召回后端（W4-a）：发布新版本后反查用过旧版的答案、按参数分组在同一份数据上重算两版之差，数真变了才开 recall 待办 ... 为什么：口径升版是被迫处置的事件（02 做法 7、拍板 L6），已交付的答案以前没人追；目录事实被驳回、表结构变了也没有地方标。 - ledger/uses.py（新）：反查旧版本被谁用过——比对工件里等价已证明的问数回答（含轮次、对话主人）、W 的正式运行（定时任务、 应用各取最近 4 期）、固定了它的工作流版本发起的正式运行、固定这一版的应用、导出审计（导出人也是主人）；预告、召回、 版本用量共用这一份 - ledger/recall.py（新）：计划按（旧版本、新版本、input_key）去重成组，从已有召回运行重算（幂等、不建任务表）；每组一次 召回运行（origin_kind=recall，探索运行），派生图经 derive.recall_graph（新旧两版取数和口径卡带前缀、召回卡里算两版之差）； 不能重算照实记原因（数据部分不能复用、新版没这张卡、入口参数不齐、图里有人工节点或写入）；每次发布最多 recall_limit 组， 超出的手动接着算；收尾时按渲染的旧值新值判数变没变：变了开 recall 待办（开登录按主人各一条、关登录派给任何人）、推 ledger.recall，没变在原答案上记 ledger.recalled；待办「按新版重新出具」走 issue.check_target 同一套判法、「知道了」 - 目录事实被驳回或修改（审阅、人工编辑、保存提案、批量审阅之后）：冻结目录里看得到这一项的探索运行记 ledger.basis_changed， 按新目录多出错误级 SQL 检查问题的才开待办；表结构变动消费 source_changes（游标、处理时改了目录的当场交过去），标依据的 表结构已变，受影响的口径试算一次，算不出来才通知发布人 - 发布钩子在 commit_publish 提交之后排队（自动的几样和调度循环同一个开关），GET /api/workflows/{id}/recall-preview 给发布 弹窗预告；GET/POST /api/ledger/recall/{wf}/{v}[/continue] 给版本历史看批次、接着算；版本用量加问数回答、导出、召回 - ledger.recall 打开订阅（全局、个人渠道），同一渠道只推一次，消息不放数；新事件 ledger.recalled、ledger.basis_changed 登记为封存后追加的事件，可验证报告离线核对页认得；E4 每次发布召回了几组、数变了的比例 - runner 收尾时召回运行在后台收尾，启动时接着做没发完的批次	2026-10-16 19:52:03 +08:00
ThearchyHelios	45fab21072	第 4 波契约骨架：频率选择抽成公共组件 components/FreqPicker.tsx（频率与时区的纯函数搬到 lib/freq.ts，pages/schedules/model.ts 原样再导出），定时维护和定时任务共用；前端类型加 ScheduleTargetCreate（建评测题集、数据源维护这两种非工作流目标），api.schedules.create 收它；设置 ledger 一组加 recall_limit（口径升版后每次最多重算几组，缺省 50，0 表示不自动重算）；test_notify_events 的 PUSHED_THIS_ROUND 拆成一项一行、给 source.changed、ledger.recall 各留一个位置；check-all 预登记 catalog-changes、evals、ledger 三项检查（先放占位）	2026-10-16 19:09:47 +08:00
ThearchyHelios	eb6e3c7ab7	合入 W3-d 邮件、待办汇总、分享链接：邮件渠道（SMTP 可选、口令加密、退信不追踪）；每天的待办汇总与访问密钥到期提醒；分享链接（只存哈希、必设到期、只显示定时出数的视图、/s 页不进外壳、下载报告）；「最近一次封存」按来源白名单认；使用者拿不到邮件渠道的收件地址；同站门户嵌整站的配置说明	2026-10-16 18:48:07 +08:00
ThearchyHelios	1c8ca4c3d7	合入 W3-c 评测执行：后台评测与无头作答、六种期望五种结论的评分、重评、结论裁判记评测账、统计（Wilson 区间、按角色用量）、对比与 A/B（McNemar）、目录贡献预设、预算与止损、清理；定时任务接题集目标，定时评测有退步 / 没有评完推全局渠道；定时页照实显示非工作流目标	2026-10-16 18:46:44 +08:00
ThearchyHelios	defdb28e3f	合入 W3-b 口径账本闭环：caliber_from.nodes 改名映射；问数据的助手 use_caliber 选用已发布口径（服务端确定性内联实例化）；按口径正式出具（自动只给问数据的答案）与口径对账；认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证转化；使用者的原始运行记录只给问数据的运行	2026-10-16 18:45:45 +08:00
ThearchyHelios	695f63f7ba	W3-a 可验证报告离线核对页认 schema.drift：事件清单写「表结构变化」 ... 复核 L4：schema.drift 写在正式运行的封存范围里（和 catalog.drift 一样在发起时追加），可验证报告离线核对页的 EVENT_LABEL 里却没有它，事件清单直接显示原文「schema.drift」。照总方案 X10 的叫法（结构变化，和「数据目录变化」 分开）补上「表结构变化」。 复核顺带提的 ledger.matched 没加：它追加在封存之后、不在封存范围内，导出只带 seq ≤ manifest_seq 的事件 （bundle/build.py），离线核对页上不会出现它。 测试：test_schema_changes 加一条静态检查，读 verifier.js 的 EVENT_LABEL，catalog.drift、schema.drift 都有中文说法。	2026-10-16 18:37:51 +08:00
ThearchyHelios	c08b2d0d52	W3-a 取值观察写库出错不再拖垮剖析：每条观察、每条覆盖率下降各占一个保存点 ... 复核 L1：catalog_profile_observe.save 和 record_coverage_drops 与这张表的剖析结果、写进目录的结论共用一个事务， 只靠 try/except 记日志。flush 一出错（序列化不了的值、约束冲突）SQLAlchemy 就把整个事务回滚了，异常被吞掉， 外层 catalog_profile._record 提交时抛 PendingRollbackError，整个剖析任务记成「剖析任务出错」，剖析写的目录跟着 丢掉，和模块说明「辅助步骤失败不挡剖析」不符。复现：给一条观察带上序列化不了的值跑 maintenance，任务 failed。 改法： - save：先把剖析这张表自己的写入 flush 下去（那里出错是剖析的事，照常往外抛）；读目录一个保存点；每条观察 （落库、修剪、比较、撤销已列全、记变化）挪进 _save_one，各占一个保存点。一条出错只回滚它自己，连同它撤销的 已列全一起回滚，不会只撤了已列全却没有那条变化；别的观察和剖析结果照常提交。 - record_coverage_drops：每条覆盖率下降一个保存点。sc.record 原本只给插入包了保存点，更新已有那一条的改动要到 外层提交时才 flush，出错照样拖垮整个事务。 - _revoke_complete：从库里重读目录（populate_existing）再写，去掉同一事务里撞了重试的循环。catalog.write_entry 乐观锁对不上时回滚的是整个会话、保存点挡不住；会话里握着保存点回滚前的目录对象时（只 refresh 过的干净对象， 保存点回滚不让它过期），拿它的版本去写正好撞上这一条。重读之后别人提交不了新版本：这张表的结果在同一事务里 已经写过，事务拿着 SQLite 的写锁。 测试（test_catalog_observe 新增四条，去掉修复都会失败）：观察 flush 报错时剖析结果、目录照常提交、别的观察照常 落库；前一条观察记变化出错时它的撤销一起回滚、后一条照常撤销；覆盖率下降更新出错只回滚它自己；会话握着旧目录 对象时撤销按库里的版本写。	2026-10-16 18:37:51 +08:00
ThearchyHelios	38d9082994	使用者的原始运行记录只给问数据的运行，对账运行经证据接口读（复核 M3） ... 复核发现：使用者（开登录后的 user 角色）发起的口径对账运行带 MASK_RESULTS、记在本人名下，run_events_readable 只看这两条， 于是他能经 /api/runs/{id}、/events、/graph 读到对账运行的原始图和事件，里面原样是口径取数节点的 SQL 模板。这一波正是以 「口径的 SQL 可能写着遮罩值」为由不让使用者在问数据里看口径、use_caliber，这条读法绕开了证据面板按遮罩换 SQL 的那一层。 做法：api/deps.run_events_readable 给 user 角色再加一条 origin_kind == "chat"——原始记录、事件、运行时的图、实时流只给他 自己的、查询结果在工具边界遮过的问数据运行（原来的说明里就写着「实际上满足的就是它自己的问数据运行」，这次照实收紧）。 对账运行他仍然能经账本和证据接口读（can_read_run 不变，那里展示的 SQL 按遮罩换过），对账的发起也不变。改了 api/deps.py 的这一个函数（没分给哪个包）和 ledger/reconcile 的模块说明。 测试：开账号密码登录，使用者对自己的问数据答案经接口发起对账，对账运行的 /api/runs/{id}、/events、/graph 都回 403，证据 接口 200；他自己的问数据运行这三样照旧 200。去掉这一条回跑，新用例失败；test_auth_access、test_personal_apps 照旧过。	2026-10-16 18:25:43 +08:00
ThearchyHelios	37d0f0abf1	自动按口径出具只给问数据的答案（复核 M2） ... 复核发现：自动出具对所有参与比对的探索来源都生效（问数据、画布试运行、蓝图试运行、个人应用刷新），而拍板 L1 和细案 做法 5 说的是「问数据的答案」。画布上反复试跑一份和受管口径等价的草图，每次都是新的来源运行，去重按来源运行算，于是每 试一次就自动发起一次正式运行（含报告撰写的模型费用），直到每日上限；个人应用刷新、蓝图试运行同样。 做法：plan_issue 算 auto_reason 时，设置开着之后先看来源，不是 chat 的写 AUTO_NOT_CHAT（「这次是画布试运行，不是问数据 的答案：自动出具只给问数据的答案，这里只给一键出具」），只给一键，一键照常发起。条件链改成逐条 if/elif，好读。 测试：equivalent_run 缺省改成问数据（origin_kind=chat），原来的自动出具用例照旧过；新加「画布试运行不自动、写明原因、 一键照常」。去掉来源这一条回跑，新用例失败。	2026-10-16 18:25:33 +08:00
ThearchyHelios	9e33c0f801	评测的两个通知事件照实叫「定时评测有退步」「定时评测没有评完」（复核 L3） ... eval.regressed、eval.failed 只在定时发起的评测收尾时推（runner._conclude 只认 trigger == "schedule"），手动发起的那次人自己 在看、不推，这和细案 01 做法 15 把这两个事件放在定时一节里一致。可订阅时的叫法却是「评测有退步」「评测失败」，没写「定时」： 有人给全局渠道勾上「评测失败」、再手动发起一次评测并止损停下，渠道里收不到任何消息，界面上也没处说为什么。 - notify/service.EVENTS 和前端 NOTIFY_TEXT.eventLabel 同一句改成「定时评测有退步」「定时评测没有评完」（test_notify_events 逐字对照两边）。eval.failed 不只是失败：到了上限、止损停下（partial）同样推，所以叫「没有评完」，和消息标题本来的说法一致。 - notify_eval 的消息标题也带上「定时」：定时评测「题集名」有退步 / 没有评完。 - 新测试：两个事件的叫法带「定时」；手动发起的评测止损停下，订阅了这两个事件的全局渠道收不到任何消息（去掉 trigger 的判断 这一条就失败）。 - 模块说明、接口说明里引用旧叫法的几处一并改。	2026-10-16 18:23:03 +08:00
ThearchyHelios	e5003a1d46	W3-d 复核 L2：使用者列通知渠道时拿不到全局、应用邮件渠道的收件地址 ... 复核发现：GET /api/notify/channels 对使用者照样列全局、应用渠道（应用的通知里要挑渠道，只用名字和 id），而邮件渠道的 mail_to 给的是全部收件地址原文；channel_out 的说明却写着「搭建者以上才看得到」。Webhook 渠道只给主机名，邮件渠道多露了 一层：任何使用者都能拿到内部的收件名单。 做法：channel_out 加 recipients 参数，list_channels 按 _can_edit 的同一条规矩判（关登录时谁都能改，开了登录要搭建者 以上）：改得了的照原样给 mail_to（改地址要整份重填），改不了的只给条数 mail_count。个人渠道照旧写发到自己的账号邮箱。 建、改渠道的返回本来就只给能改的人，照旧。说明同步改；前端 typesApp 的 NotifyChannelRow 加 mail_count（设置页的 通知只给使用者列个人渠道，界面上用不上，不加入口）。 测试（tests/test_notify_mail.py）：开登录，使用者列渠道时全局、应用的邮件渠道照样在、没有 mail_to、只有条数，自己的个人 渠道照常；搭建者看得到地址。去掉修复回跑，这一项失败。	2026-10-16 18:20:52 +08:00
ThearchyHelios	36c8f581cc	W3-d 复核 H1：「最近一次封存」按来源白名单认，问数据按口径出具的正式运行不再顶替看板的数 ... 复核发现：问数据的答案按已治理口径正式出具的运行（origin_kind=ledger_issue，W3-b 加的自动出具缺省开）参数是从某人的 提问里绑出来的，而 apps/resolve.sealed_runs 只排除了补算（app_backfill）。于是 from=formal 的 latest_sealed 视图、 趋势、分享链接（latest，以及建 fixed 分享时取的那次）、视图数据接口、补算判断「新版本算过没有」都会换成那组参数的数， 而且没有任何提示。 做法：sealed_runs 的来源从黑名单改成白名单 SEALED_ORIGINS（定时、手动正式运行、应用入口和按需视图、入站钩子、直接调 接口，外加没有来源列之前的老运行）；不算的列在 NOT_SEALED_ORIGINS，逐条写明原因。上面这几处都经 sealed_runs，改一处都 跟上。按白名单认是为了以后再加来源时默认不算、要算得先登记，不会再悄悄漏进看板。 测试（tests/test_shares.py）： - 先跑一次正常的正式运行，再跑一次更新的 ledger_issue 正式运行：应用页、趋势、视图数据接口、latest 和 fixed 两种分享 都还是正常那次，分享的下载报告也不认出具的那次。去掉修复回跑，这一项失败； - ORIGIN_KINDS 每种来源都要归进 SEALED_ORIGINS 或 NOT_SEALED_ORIGINS 之一，以后新加的来源没归类先失败。	2026-10-16 18:20:52 +08:00
ThearchyHelios	7e8d3a9c49	口径比对的 drain（测试用）只等还没做完的任务，做完还留在登记里的顺手去掉 ... 为什么：并行跑全量测试时偶发过 drain 原地空转（faulthandler 抓到主线程一直在 drain 里，每轮 gather 都立刻返回），四次全量里挂了两次。这一波起整题等价的探索运行比完会接着自动出具，后台任务的进出更密。改成只 gather 没做完的、把做完的从登记里去掉之后，连跑两次全量都没再出现。drain 只给测试用，服务里不调它；没能在单进程里复现出根因，照实记进遗留。	2026-10-16 17:46:20 +08:00
ThearchyHelios	b1c585daf4	W3-a 结构变化的影响面：一批（一次刷新）只读一次目录 ... 后台探查每批读完、刷新对象索引发现真删除的表时，各张表的影响面以前每张都重读一遍整个源的目录（structure_impact 不给 notes_by_table 时自己读）。一批几十张表、几千张表的库删了一批表时，这一读就重复几十次。改成一批（一次刷新）读一次、 各表共用；已发布模板的图本来就按任务缓存。行为不变，test_schema_changes、test_introspect_jobs、test_source_changes 照过。	2026-10-16 17:29:00 +08:00
ThearchyHelios	ed72ee68d6	W3-a 关联覆盖率下降、清理目录跨表、扩容器集成测试到对象索引和取值观察 ... - 剖析核对关联关系时，覆盖率从够有确证的线（95%）掉到线以下的记一条 coverage_drop（取值变化，warning）：剖析本身照旧 按规则降回推断（人工确认的只补上新的覆盖率），这里只把「覆盖率下降」留进变化记录。人点的剖析也记（变化记录全站一份）。 关系的发现里多带 previous_coverage。 - 处理动作「清理目录」逐表清：这张表上说到被删的列的项，加上别的表指向它的关联关系（表删了时尤其如此）；记这张表的 目录版本，别的表也动了的另记 catalog_versions。 - 剖析任务的逐表进度多一类 observe（取值观察的四类合成一组），前端「取值观察 N/M」用它。 - 定时维护补一条测试：AGENTLAB_SCHEDULER 关着时调度循环不起，到点的维护不触发、不建任务。 - scripts/dialect-it.sh / dialect_it.py 扩到第 2 波的对象索引字典查询（走字典查询不退回 Inspector、类型、表注释、行数 估算、Oracle 小写名的 quote）和这一波的取值观察（经剖析引擎只观察：行数、小表码值整表、大表 PG / Oracle 块采样、MySQL 前 N 行、最新业务日期排除无效日期，max_date_sql 直接跑）。夹具的订单表加了表注释。本机跑了一次四种库的容器 （postgres:16、mysql:8.4、mariadb:11、gvenzl/oracle-free:23-slim）：121 项全过、0 项不通过，跑完容器已删、镜像留着。 验证：后端全量 14046 通过（11 跳过、8 预期失败）。	2026-10-16 17:28:07 +08:00
ThearchyHelios	e65ac3e619	助手的节点手册：子工作流补上 workflow_version（口径账本做法 4 ⑤） ... 为什么：手册里子工作流只写了 {workflow_id, input}，模型不知道能固定版本。补上写法，并说明问数据里不要拿子工作流去拼已发布的口径——子工作流里的数报告引用不到，组合口径走 use_caliber 的内联实例化。	2026-10-16 17:18:37 +08:00
ThearchyHelios	ced7234180	按口径出具也按 SQL 里参数的位置校验绑定值；去掉 certify 没用到的导入 ... 为什么：出具用的参数来自比对时的绑定，运行时要渲染进口径的 SQL 模板。写在引号里的值带着引号、裸写的值不是数，渲染出来就不是那一版口径的 SQL 了。组合时校验助手给的参数用的是同一个判断（ledger/compose.slot_contexts / value_problem），这里共用；那张图里别的节点引用运行时变量的不归出具管，跳过不报。宁可少出具，照实说为什么不代填。	2026-10-16 17:17:48 +08:00
ThearchyHelios	fd1ec6f75d	测试：开登录时自动按口径出具按提问人的权限判 ... 为什么：自动出具在后台跑，没有请求里的身份，要按这次运行的发起人取（ledger/issue._starter）。补一条用例：使用者没有应用授权时不自动出具，应用固定了这一版、授给他使用之后才出具，正式运行记在他名下、origin 标自动。	2026-10-16 17:15:50 +08:00
ThearchyHelios	40daf37107	评测发起后立刻交给后台再读回；补「复核要重来」的测试 ... 为什么：发起评测时提交之后、交给后台之前还 await 了几次读回，这中间别的请求读到「排队中、却没在这个进程里跑」会把它 当成服务重启留下的、标中断。改成提交之后立刻交给后台，再读回。 - test_eval_runner：复核给了 retry_instruction 时带着这次运行的图、照那句话重来一次，第二次复核（attempt=1）不再要重来， 两次作答运行都记在这一题名下	2026-10-16 17:15:17 +08:00
ThearchyHelios	5e9413e080	账本：按来源运行找出具过的正式运行、对过的账改在 SQL 里按 origin.source_run 筛 ... 为什么：GET 账本每次都要列这两样，原来把全部 ledger_issue / reconcile 运行读出来在 Python 里筛，出具多了就是整表扫。改成 origin_kind（有索引）加 json_extract(origin, "$.source_run")，写法同 auth/keys 认幂等键。	2026-10-16 17:11:55 +08:00
ThearchyHelios	fc9b31ecfe	W3-d 收尾：关登录时不发汇总和到期提醒、分享页不下发入口表单、邮件标题去换行；测试互不干扰 ... - notify/digest：关登录时「派给我的」认不出是谁、访问密钥也不生效，待办汇总和密钥到期提醒一概不发，也不认领当天 - resolve_page 的分享旁路不下发入口的表单（分享链接里不能发起） - 邮件标题里的换行合成空格：应用名、节点名是人起的，邮件头里有换行就是头注入 - 邮件、汇总的测试前后各清一遍渠道、投递记录和 notify 一组，对外访问地址的缓存跟着清；汇总测试只删自己建的待办。 全量并行跑时不再被同一进程里别的测试留下的行带偏	2026-10-16 17:11:54 +08:00
ThearchyHelios	a0cdb16617	重评时把评分规则版本记进指纹；去掉几处没用的导入 ... 为什么：按新规则重评之后，和别的评测比时「评分规则」那一项要照实标出变了；总表上另记重评的时间。	2026-10-16 17:11:09 +08:00
ThearchyHelios	88e219eabc	评测总表照实列出没开评的题、按评完的题估每题花费；对比测试单独成文件，补超时止损的测试 ... 为什么：总表里「没开评、停下、出错」的题以前只体现在计数里，准确率旁边看不出来；下一次开跑前的估算按每题平均花费算， 把没开评的题也摊进去会估低。 - stats.summarize 加 not_run；per_case_cost_usd 只按评完了的题平均 - test_eval_compare.py：逐题转移与归因、指纹差异、A/B 配对表、选基准（从 test_eval_stats 拆出来，对上细案的测试清单） - test_eval_runner：最近 10 题里 7 题超时就止损	2026-10-16 17:08:29 +08:00
ThearchyHelios	538799e70d	沉淀：认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证队列的转化（口径账本做法 8、10，拍板 L9） ... 为什么：同一类问题被反复问、Agent 反复写出同一个形状的 SQL，就该沉淀成一份口径；以前 from-run 保留 Agent，沉淀出的模板没有固定 SQL，以后永远比对不上。第 2 波的统计在 E2 反馈、E3 认证队列上照实写了「目前没有数据」，这一波补上能补的。 做了什么（新增 ledger/certify.py）： - GET /api/ledger/certify-queue（搭建者）：确定性重复（问数据运行里被报告引用、没对上口径的查询，按数据源 + normalize_sql 文本分组，≥3 次运行且来自 ≥2 段对话；跨运行变化的字面量是参数候选，展示的形状不带取值）、问题聚类（app/chat/questions 全站唯一的那份）、被反复用的答案（导出 ≥2 次用第 2 波的 report.exported 审计、做成过应用看蓝图来源、在画布里打开或提取过看工作流 origin）。每项给代表问题、轮次、相关口径、是否已固化。 - POST /api/ledger/certify-queue/dismiss：「不是口径」写审计 ledger.certify.dismiss，之后不再进队。 - 固化成口径草稿（from-run 加 freeze、peers 后转调 certify.freeze）：报告引用的查询变成固定 SQL 的取数节点，跨轮变化的字面量换成 '{{ input.pN }}'（缺省值取代表运行的），单行结果的数值列成口径卡指标，报告核对规则按受管要求写、契约 report_from + metrics_from + required（多行加 cells）；过 validate_graph 和受管门禁。新工作流 origin.sources 记来源问题。 - 发布之后补比：api/workflows.commit_publish 提交后调 certify.after_publish，来源运行按新口径补比一次（新的 trigger=certified，界面写「按之后发布的口径回看」，时间线和账本接口同一句）。 - 统计：E2 加对过账的答案数、参数经人核对的、指标由人选的次数（反馈照实写第 4 波）；E3 认证队列的转化（固化、发布、不是口径）。 测试：tests/test_ledger_certify.py（参数推断与模板、三种信号进队、门槛、不是口径、固化草稿过受管门禁、发布后来源运行补比成等价已证明并出队、再问标等价已证明、统计）。	2026-10-16 17:06:41 +08:00
ThearchyHelios	df6c3ce10d	定时页照实显示非工作流目标；评测停止时几臂一起收尾；工作流题的测试 ... 为什么：这一波后端开始接受评测题集、数据源维护这两种定时目标（总方案 X4），定时页要能把它们照实列出来、点进去 不报错；界面上不能有点了没用的入口。 - 定时页列表：非工作流目标写种类（评测题集 / 数据源维护）和目标名，不标运行类别，「编辑」写成「查看」 - 详情：非工作流目标的设置只读地列出名称、目标、频率、时区、补发宽限，不出工作流那张表单（选工作流、输入模板、 Webhook 对它们不适用）；页头的启用、立即运行、删除和触发历史照常 - 立即运行发起的是一次评测时说「已发起一次评测」（以前会落到「未能发起运行」）；触发历史写评测的编号 - types.ts：Schedule 加 target_kind / target_id / target_label / target_name / target_exists，触发记录加 eval_run_id； 文案进 SCHEDULE_TEXT - check-schedules 加一段「目标不是工作流的定时任务」 - runner：还没准备好就被停下、出错时，按 pair_id 找全几臂一起收尾 - 测试：工作流题按钉住版本跑探索运行（不发正式运行、不建图）；钉住基线的接口 - 后端几句给人看的话按文案规范改（不用「跑」「钉」）	2026-10-16 17:04:05 +08:00
ThearchyHelios	906ec072ce	按口径正式出具与口径对账（口径账本做法 5、6，拍板 L1、L5） ... 为什么：问数据的答案整题等价于已发布口径时，要能按那一版发起一次完整走过门禁的正式运行（路径一、二a）；只是相关、不等价时，要能看「差多少」（路径二b）。两条路都不能让客户端冒充来源、自己传参数，也不能在 Python 里算差值。 正式出具（新增 ledger/issue.py）： - POST /api/ledger/answers/{run_id}/issue {workflow_id, version}：参数只从比对工件的绑定取，补入口缺省值再过 apps/forms 校验；经 launch_run 发起正式运行，来源 ledger_issue，origin 记 source_run、conversation_id、turn_id、binding_hash、口径和认法、是否自动；按 expect_hash 钉 graph_hash。 - 不能出具照实写原因：整题不等价、点名别的口径、版本退役或没发布、图里有人工节点或写入（apps/backfill._side_effect 抽成共用的 graph_side_effect）、缺入口字段、超过每日上限、权限（L5：使用者只能按他有权使用的应用固定着的版本出具，复用应用授权，origin 记 granted_by_app；别的写「请搭建者出具」）。 - 自动出具（L1）：比对完（只在运行一封存就比的那一次）整题独立等价、版本受管、设置开着、当天没超上限才自动；助手选用的只给一键。不自动的原因写进 actions 的 auto_reason。 - 同一运行、同一口径、同一组参数只发起一次（input_key 去重），进程内按（运行、工作流、版本）串行。 - 设置加 ledger 一组：自动出具开关、每日上限、比对时限（ledger/match 读它）。 口径对账（新增 ledger/reconcile.py，derive 扩 reconcile_graph / ours_block / assemble 的出口契约）： - POST /api/ledger/answers/{run_id}/reconcile：按那一版确定性派生只读图（这次的取数 ours_q1 → 口径的取数 → 口径卡 → 对账卡，出口契约 metrics_from，不加报告、不调模型），来源 reconcile 的探索运行；对账卡算这次、口径、差值、相对差。 - 参数是启发得来的、不全、含遮罩值时先让人核对（needs_check，没核对的 409）；指标式不是取数一格、差异有兜底时要人选对照哪个指标，选择记进 origin。 - 多行结果：被引用的行按维度列经合并查询 LEFT JOIN 对齐、按引用先后排，最多 10 行；维度是遮罩列、合并键不唯一照实拒绝。使用者发起带 MASK_RESULTS / READ_ONLY，搭建者也带 READ_ONLY。 - GET /api/runs/{id}/ledger 的 actions 补上出具、对账两类，issued、reconciled 列出发起过的运行。 测试：tests/test_ledger_issue.py（自动出具、只给一键的几种、拒绝原因、使用者的应用授权、并发只发一次、设置）、tests/test_ledger_reconcile.py（核对参数、派生图确定与契约、差值和相对差、出处链、要人选列、多行对齐、遮罩维度和重复键拒绝、使用者只读遮罩）；第 2 波 test_ledger_api 的 actions 断言按这一波改。	2026-10-16 16:55:06 +08:00
ThearchyHelios	e29adf80d0	评测执行的测试：执行、评分、统计与对比、清理、定时与通知 ... 为什么：照细案 01 的测试清单把这一波的行为钉住，顺带修了跑测试时撞出来的两处。 - test_eval_runner：后台排队、并发不超过 max_parallel 也不超过全局并发的四分之一、同一题集同时只能一次、停止后只重做 没做完的（评完的不动）、重启标中断不续跑、单次金额上限触顶不再开新题、评测每日账单独记（不占裁判、核查的额度）、 连续 3 题助手调用失败止损、每题超时取消正在跑的运行、停在审批上的作答取消掉（评测不代批）、接口的估算与进度、设置里 eval 一组和 /settings/eval/spend - test_eval_score：五种结论、写出精度和百分数、维度配对与弱匹配、多行 / 名单 / 没有数据 / 反问、路径和期望先于数字、 dual 两版、允许的相对误差和双盲复算是同一个函数；读封存的答案、逐题 E1 用账本的比对函数；重评只读封存、不调模型 - test_eval_stats：Wilson、精确 McNemar、P50/P90 和手算对照；总表的各项；转移与四种归因；指纹差异；配对表；选基准 - test_eval_cleanup：保留规则；forget 只删一条引用都不剩的文件；清理后总表还在、结果和底下的运行删掉、共用的工件留着 - test_eval_schedule：定时接口收题集（拒工作流、输入模板、Webhook）、到点建一次评测并写 eval_run_id、重叠跳过、错过的按 宽限补；有退步推「评测有退步」、没评完推「评测失败」，消息里没有期望值和答案里的数 - test_eval_e2e 补：开评拍目录快照、记表结构前后；打开裁判时结论裁判走按需裁判那条路、花费记在评测账上，文字要点单列 - 修：期望反问的题在建图、运行失败（含超时）时把原因写全；改非工作流目标的定时任务时提交后不再读过期对象	2026-10-16 16:49:47 +08:00
ThearchyHelios	f5c94cf12d	W3-a 变化记录的接口与处理、定时维护（next-round 03 B3、B4） ... 变化没有统一的记录：进不了审阅，发不了通知，口径账本的召回也没有可以订阅的接口；目录只能手动探查、手动剖析。现在： - api/source_changes.py（骨架已在 datasources 通配之前登记，搭建者可用，访问密钥不放）：GET /api/datasources/{id}/changes （缺省开着的和知道了的，按「使用次数权重 × 严重程度」排，带各级别计数）、GET /changes/{change_id}、POST /changes/{change_id}/resolve。处理动作落到目录已有的写入接口：清理目录里说到被删的列的项（整份写、乐观锁）、加入码值 （apply_patch 配 _merge_codes，含义待填写，依据写变化编号）、重新起草这张表（模型用不了时只按表结构起草）、重新剖析、 知道了、误报（必须写理由）；每个动作写 resolution，动了目录的记目录版本，建了任务的记任务编号。 - data/source_changes.py 给召回：list_changes（按 seq 游标拉）、affecting（按源和表反查）、resolve、triggers_recall（只认 结构类、处理时改了目录的、触及有效记录条件的新码值）。 - 通知 source.changed 的发送函数 notify/service.notify_source_changed：只推还要人看的「要处理」级变化，按源汇总，消息里 只有源名、各级别条数和链接（D9）；探查、剖析任务结束时有新的要处理变化就调。这一行的订阅范围第 4 波有了界面才打开， 现在推不出去（照实）。 - 定时维护（data/source_maintenance.py，X4：就是一条 target_kind=source_maintenance 的定时，不另建表）：fire 按顺序建 探查任务 → 剖析任务（范围 needed / observe / maintenance 按选的步骤），任务上记 trigger=schedule、fire_at、schedule_id； 剖析等探查进了同源队才建，靠 SourceLanes 串行；剖析没开、数据源停用 / 不存在 / 是上传表格时照实记没执行，同源还有 探查或剖析在做时记跳过；触发记录的 inputs 写明建了哪几个任务、哪几步没执行。check_target 核对目标。维护步骤存在 options.catalog_maintenance，经 GET / PUT /api/datasources/{id}/maintenance 改，数据源表单不显示它（api/datasources.py 的 _MANAGED_OPTIONS 加了这一个键）。 测试：test_source_changes（列表与计数、误报要理由、处理过的 409、清理目录与加入码值记目录版本、剖析没开照实 422、 去重、游标拉取与反查、召回触发、通知只有源名条数链接）、test_source_maintenance（按顺序串行、trigger 与 fire_at、 剖析没开记未执行、停用 / 不存在 / 忙、调度循环只补最近一次且积压只记一条、步骤接口与核对目标）。	2026-10-16 16:48:40 +08:00
ThearchyHelios	f887cdc30a	W3-d 邮件、待办汇总、分享链接的界面 ... - 设置 → 通知：渠道多一种格式「邮件」，邮件服务没启用时不列；个人邮件渠道不填地址，写「发到账号邮箱 …」（账号没有邮箱照实写 发不出去），全局、应用的填收件地址；投递记录里邮件成功写「已交给邮件服务器」、悬停说明退信不追踪；新增「邮件服务」一节 （管理员改、搭建者只看：口令留空不改、可清除，发测试邮件要先保存）和「每天的待办汇总」的发送时间 - 设置 → 偏好设置的「应用」一节：「允许建分享链接」开关（缺省关，写明关掉时已有的一并打不开） - 应用编辑 → 岗位与授权：分享链接的管理（选页面、始终最新 / 固定这一期、有效期 1–90 天、允许嵌入；链接只显示这一次； 列出状态、到期、打开次数，撤销先确认）；开关关着时不给新建，已有的照列能撤销；个人应用写明不能分享 - /s 分享页：不进外壳（App 在 /s 上整个跳过认人、取目录、心跳、读主题，请求层在 /s 上也不送去登录页），key 从 # 后面读、 放进请求头；同一个 ViewRenderer 渲染、操作全禁用；印章常显（「数据的来历」逐个列视图的印章）；点数字说明出处在下载的 报告里；页脚「只读 · 由 X 于 … 分享 · … 到期」；撤销、到期、关了开关、链接不完整按服务端的话写明；没允许嵌入的分享在别的 页面的 iframe 里不显示内容、给「在新窗口打开」 - ViewRenderer 加 onEvidence：点数字交给调用方（分享页），不开在线证据面板 - check-copy 加「快照链接」一条（总方案 X10：写「分享链接」），带自检	2026-10-16 16:44:06 +08:00
ThearchyHelios	c95e5b4e84	W3-a 取值观察：剖析引擎的四类观察检查、比较器、撤销「已列全」（next-round 03 B2） ... 码值出现新取值、比例剧变、业务日期断档、某天没数据，以前都看不到：确认过的码值列不再取分布，大表只看物理顺序最老的 前 10 万行，「已列全」过期以后 SQL 检查还照它提示。现在： - 剖析引擎加四类观察检查（data/catalog_profile_observe.py）：rows（行数，用剖析开头那条估行数的结果）、codes_observe （所有码值列，包括人工确认过、标了已列全的）、freshness（已确认或已验证的业务日期的最新日期）、daily_volume（最近 35 天按天计数）。计入每张表的预算、止损和留痕，每条观察记口径 basis 和它出自哪几条查询；遮罩列不进任何观察查询。 - 大表口径照目录-D7：有确认的业务日期且该列打头有索引看 35 天窗口；PG / Oracle 没有就块采样（比例按表的大小取一档， 不跨档比）；MySQL / SQLite 没有就按存储顺序的前 N 行，照实写口径。最新业务日期、按日行数在大表上只在有索引时才查。 SqlDialect 加 max_date_sql（有效区间里的最大日期），方言金样跟着加了两条。 - data/value_drift.py 纯函数比较器：新码值（已列全的任何新值、没列全的要占 0.5% 以上且有历史）、PSI 剧变（≥0.25 warning、0.1–0.25 info，两次都要 1,000 行）、断档（超过 max(2×中位间隔, 3 天)）、缺天（以前的窗口没有过）、量跌 （不到前 28 天中位数的 30%）、行数跌 30% / 涨 3 倍（估算值要连续两次）。只和同口径的历史比。 - 观察记进 table_observations（每张表每种观察留最近 26 条），比出的取值变化进 source_changes，和这张表的剖析结果、目录在 同一个事务里。机器唯一写进目录的事：数据证明码值表不再列全时撤销「已列全」（目录版本 +1，署名「取值观察」，值、含义、 状态都不动），SQL 检查随之不再按旧码值表提示 unknown_code。 - 剖析任务的范围加 observe（观察到期的有目录的表，只观察）和 maintenance（定时维护：需要剖析的 + 观察到期的）；人点的 「需要剖析 / 全部 / 指定的表」照旧不观察。只观察的那一项不算「上次剖析」（不顶掉表清单的上次剖析和给助手的剖析事实）。 任务的设置快照里记 trigger / fire_at / schedule_id（剖析任务表没有这几列）。 - 观察结论（最新业务日期、更新的行数）经 last_facts → schema_view.profile_lines 和剖析事实同一节进 look、db_schema、 /schema、表助手（X7），遮罩在渲染那一刻再核。 测试：test_value_drift（阈值两侧、口径不同不比）、test_catalog_observe（四类观察与口径、撤销已列全与 SQL 检查、去重、 遮罩不进查询、大表窗口与前 N 行、PG / Oracle 采样 SQL、观察不算上次剖析、进表详情）。	2026-10-16 16:40:41 +08:00
ThearchyHelios	2371e75f17	评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段） ... 为什么：第 2 波只有题集和期望答案的来源，评测本身跑不起来。这一段把细案 01 做法 9–12、16、17 的后端接上， 量的是用户在问数据页拿到的同一轮，而不是另抄一份编排。 - eval/answer.py：无头作答，串起 answer_ops → chat/turn 的决定 → launch_run(origin=eval，带目录视图、只读、遮罩) → 等终态（停在审批的取消、记「评测不代批」；驳回记路径「被驳回」）→ review_of_run → 按同一规则重来一次； 工作流题按钉住版本的图跑探索运行（不发正式运行，免得被 pick_base 和应用视图取到）。用量按角色记 - eval/runner.py：用 core/job_runtime，一次评测一个任务，题 × 重复 × 臂一项；A/B 几臂共用期望、同一题同时开跑； 开评拍目录快照、记上传表格版本和表结构哈希的前后；并发不超过 max_parallel 和全局并发的四分之一；每题时限； 评测单独一本账（开跑前估算、每题预留后找补、触顶不再开新题）；止损；能停、只重试没做完的、重启标中断不续跑 - eval/score.py：六种期望、五种结论（量纲不同单列）、维度配对与弱匹配、路径不对直接不通过、口径 dual 两版都报； 逐题 E1 用口径账本的 compare_queries（总方案 X2，不另写 signals）；SCORER_VERSION 可重评（eval/rescore.py，只读封存） - eval/judging.py：结论裁判走按需裁判同一条路（evidence._judge_now），文字要点由裁判判、单列不计准确率；花费经 judge.charged_to 记在评测那本账上（engine/judge.py 只加了一个上下文变量和取账本的一处） - eval/stats.py、eval/compare.py：准确率与可追溯准确率 + Wilson 区间、各项分布、P50/P90、按角色成本、引用率、逐题 E1； 选基准、逐题转移与归因、指纹差异、A/B 配对表与精确 McNemar；「目录贡献」预设对照（当前 vs 关，可加只用已核实） - eval/cleanup.py + core/artifact_store.forget：保留最近 N 次 + 钉住的基线 + A/B 另几臂，删结果、明细工件、底下的运行和 引用行，工件文件一条引用都不剩才删；总表永久保留 - engine/tolerance.py：双盲复算的 _agree / _delta_pct 原样搬来共用（dual_check 改 import，行为不变） - 设置加 eval 一组（builder 读、admin 写）和 GET /api/settings/eval/spend；题集预算在全站缺省上覆盖，每日上限只能往下收 - api/evals.py：发起（单臂 / A/B / 目录贡献预设）、估算、进度、逐题、停止、重试、重评、钉基线、和上一次比、配对表、清理 - main.py 的 lifespan：影子起草和评测的启动整理、关停（评测先于运行停，停时取消自己发起的运行） - 测试：test_eval_e2e（dual_check_shop + 剧本模型：按支付日 330 通过且 SQL 等价，按下单日 310 不通过、差在 time； 目录对照 1:0；和上一次比找到退步、归因做法变）；通知事件、定时接口形状的老测试按新事件和新字段更新	2026-10-16 16:38:09 +08:00
ThearchyHelios	4f4ad48ad7	组合式问数：问数据的助手可以 use_caliber 选用已发布口径，服务端确定性内联实例化（口径账本做法 4，拍板 L3） ... 为什么：问数据以前看不到口径，也没有组合机制；子图做骨架的路走不通（子图证据不交回父图、使用者用不了子工作流）。改成助手只选口径、填参数，取数节点由服务端按固定版本照抄，证据照常封存、比对照常复证。 做了什么： - 问数据的查看对象加 caliber（look/calibers 的 compose 模式）：另给每张卡的入口字段（类型、必填、可选值、格式、缺省值）和「能不能组合」（ledger/derive.load_pinned 同一个认法），能组合的写出 use_caliber 的写法；仍不给 SQL。只给搭建者及以上：使用者的图里看得到拷进来的取数 SQL。 - 新增 ledger/compose.py：use_caliber {id, workflow_id, version, card, metrics, inputs} 经 derive.caliber_block（扩了 card_id、inputs 两项）实例化——取数节点照抄、id 加前缀、模板按参数渲染成字面 SQL，口径卡 id 就是操作 id、caliber_from 带改名映射。参数按入口字段过 apps/forms 校验，写进 SQL 引号里的不能带引号、裸写的只能是数；只能选这一轮看到的那一版、能组合的卡、卡上的指标；不合规拒收。 - GraphApplier 落地 use_caliber：节点、连线记进 seen（兜底重放照样在），入口连到第一个取数节点；转给界面的只有那一条操作带 result；拒收的原因经自查交回模型（GraphChecker.issues）。 - 提示：协议多一段 USE_CALIBER_PROMPT；LOOK_WHEN 里问数据那一条按细案改写（只在能选用口径时换）。运行时写 SQL 的 Agent 不看口径（L2）。 - 比对器认出助手选用的查询（从封存的图里读 caliber_from.nodes）：证明了的标 composed「助手选用」，没能证明的照常是相关口径并说明；标签 how=composed，指标标签记取自哪几条查询；比对算法版本升到 2。 - 前端：问数据过程里 use_caliber 照实显示一行（选用了哪一版、生成几个节点；拒收写原因），节点数算进「新增几个步骤」；文案进 LEDGER_TEXT.use；check-decode 加一节。 测试：tests/test_ledger_compose.py（实例化确定性、各种拒收、查看文字不带 SQL、提示切换、落地与接线、拒收交回模型、剧本模型走一遍生成再真跑出 composed 标签、使用者不给口径）。	2026-10-16 16:35:28 +08:00
ThearchyHelios	f759c5c82d	W3-d 分享链接（后端）：只读、不用登录、必设到期、只显示定时出数的视图 ... 为什么做（04 细案 C2，集成-I6）：会话 cookie 是 SameSite=Lax，跨站的 iframe 里带不上，想把看板放进别的门户只能每人开账号且 必须同站；分享链接是跨站嵌入唯一走得通的办法。它把数据交出了授权范围，所以每一步往窄处取： - view_shares（db/models_apps.ViewShare）：只存 key 的 sha256 和开头 6 位；latest 跟着最近一次封存走，fixed 存建分享那一刻 每个视图的运行 id、按建分享时的应用版本解析；到期必填；打开只计数 - POST / GET / DELETE /api/apps/{id}/shares：要应用的 manage，建要管理员开了 apps.share_links（缺省关）；个人应用、没发布、 归档的不能分享；这一页没有最近封存的视图不收；到期最长 90 天；key 只在建的时候交回一次（/s#<key>）；建、撤销写审计 - GET /api/shares/page、/api/shares/report.html 是公开路由（中间件把 /api/shares/ 当公开前缀），只认请求头 X-AgentLab-Share，地址里带的 key 不认；撤销、到期回 410 写明；开关关掉时已有的一并 403；应用归档、页面没了 410 - apps/resolve.resolve_page 加 share 旁路：只解析 latest_sealed 视图（fixed 用存下的运行，趋势也停在那一期），按需、实例、 探索视图写明原因、从不发起运行（auto 的也不）；流程组件和报告换成写明原因的说明块；页面缓存键另加分享的标识；out 另给 各视图取到的运行和可下载的报告 - 下载报告只认这条分享此刻解析出来的运行，内部就是 export_report_html（同样遮过、照常记导出审计，导出人记成不冒充任何人的 分享身份） - 分享接口都不放给访问密钥（不在 KEY_ROUTES，门禁 403） 安全头：/s 用 AGENTLAB_EMBED_ORIGINS 和 no-referrer（第 1 波 web_security 预留的规则，这次在真实页面托管下测）。C3 同站门户 嵌整站只做配置和文档：写进 web_security 的模块说明和 deploy/agentlab.env 的「嵌入」一节，「分享链接还没有上线」那句改掉。	2026-10-16 16:30:42 +08:00
ThearchyHelios	8d59ca1581	W3-a 表结构变化：前后差异、影响面、结构版本与 schema.drift（next-round 03 B1） ... 以前重新探查是整份替换表结构、不比前后：删了一列，那一列上人工确认过的目录项、写死这一列的已发布模板都收不到提醒， 正式运行要到查询那一步才报错。现在： - data/schema_diff.py：纯函数，同一张表前后两次的结构比出变化（加列、删列、类型、可空、注释、主键与唯一约束、外键）； 疑似改名（类型相同、夹在同样两列之间、只有一对）只说「可能」；读不到唯一约束、外键的一边不比；升级后第一次读到 （结构版本 0）只建基线，不把通用写法换成方言完整写法说成类型变了。 - 后台探查顺带记变化（data/introspect_jobs.py）：刷新对象索引记新出现的表、真删除的表（第一次建索引只建基线）；开始 执行时记离开范围的有目录的表、范围规则和上一次不同；逐批读完拿上一次的结构比，读不到结构的记 table_reflect_failed。 离开范围、读不到结构不算删除。记变化出错只记日志，不挡探查。 - 变化记录 source_changes（db/models_sources.py 的 SourceChange，格式 agentlab-change/1，seq 自增不复用、按指纹去重）， 记录与读取在 data/source_changes.py；取值观察的表 TableObservation 同文件建好。 - 影响面（data/catalog_impact.structure_impact）：目录里说到被删、被改的列的项（列级项、业务主键、业务日期、有效记录条件 按 parse_valid_filter 取列、两端的关联关系）带状态，人工确认过的升为要处理；已发布模板写死的 SQL 换上新结构再跑 sql_unknown_columns，说得出「这条 SQL 现在会报列不存在」。sql_unknown_columns 从 api/copilot.py 挪到 data/sqlcheck_columns.py 共用，copilot 那边只改 import。 - 发布时记 WorkflowVersion.schema_versions（只记直接引用、结构版本大于 0 的表）；正式运行发起时比对，变了写 schema.drift （core/events.py 登记，只提醒、不拦）；版本详情给出 schema_versions、schema_changes；发布前检查把这一版直接引用的表上 还没处理的结构变化列成警告（schema.change_open），不拦发布。 测试：test_schema_diff（纯函数）、test_schema_changes（SQLite 夹具 ALTER 前后、影响面、去重、真删除与离开范围、 schema.drift、发布前检查、升级后基线）。	2026-10-16 16:26:11 +08:00
ThearchyHelios	86d2840e41	W3-d 邮件渠道、待办汇总、访问密钥到期提醒（后端） ... 邮件（04 细案 B2，集成-I4 / I5，改写应用平台 Q6）： - notify/mail.py：标准库 smtplib 放进 asyncio.to_thread，单次超时 10 秒；4xx 和连不上按 1/2/4 秒重试，5xx 不重试； 报错只写主机名和服务器回话，口令一律抹掉；纯文本 + 转义过的 HTML，带 List-Unsubscribe 和 Auto-Submitted；测试可换假的 SMTP 工厂。模块说明写清改写 Q6 的理由：SMTP 是可选配置、退信不追踪照实说「已交给邮件服务器」 - 通知渠道多一种格式「邮件」（core.CHANNEL_FORMATS；定时任务的 Webhook 只会发 HTTP，FORMATS 不加，免得定时任务能选 邮件）：个人邮件渠道不收地址，只发到名录里的账号邮箱，没有邮箱记一条失败投递并写明去「设置 → 身份」填；全局、应用的填 固定地址，最多 20 个；邮件服务没启用时不收新的邮件渠道；渠道列表另给 mail（启没启用、本人的账号邮箱），投递记录带格式 - 设置的 mail 一组（只有管理员能改）：口令用 core/crypto 加密，读的时候只说配没配；启用时要配全；发件人名称、主机不许 换行；「发测试邮件」只发到管理员自己的账号邮箱，关登录、没有邮箱时 422 说清怎么办 - mail.default_for_assignees（缺省关）：开了之后第一次派到待办的人自动有一个个人邮件渠道（订阅待办打开、动作结果未知、 审核有结果），本人删了不再建回来；关登录时不建 待办汇总与密钥到期（04 细案 B3）： - notify/digest.py 接进调度循环的步骤列表：每天到 notify.digest_at（缺省 09:00，服务端时区）给订阅了 task.digest 的 个人渠道发汇总（条数、最早时限、最多 5 条节点名、去待办箱的链接，没有待办不发）；按日期在 settings 表里插一行认领， 重启不重发；认领行和自动建邮件渠道的名单是通知自己记的账，设置接口不列不收 - key.expiring：到期前 7 天、1 天各推一次，个人密钥推本人的个人渠道、服务账号的推全局渠道，推之前记审计、按审计去重； 轮换下来的旧密钥、撤销了的、建的时候就在这一档里的不推 - 两个事件推送实现了，才在 notify/service.EVENTS 打开它们的订阅范围 设置的 notify 一组加 digest_at；只给一部分时补上存着的另几项；环境变量锁住对外访问地址时只核对那一项，汇总时间照常能改。 apps 一组加 share_links（分享链接的开关，缺省关，下一个提交用）。测试：假 SMTP 工厂下的收件人、失败投递、重试、口令、 设置与权限、自动建渠道；汇总按时、只发一次、重启不重发；密钥两档、谁收、不该推的几种。	2026-10-16 16:21:41 +08:00
ThearchyHelios	1f8250699c	口径卡来源支持节点改名映射 caliber_from.nodes（口径账本做法 4 ③） ... 为什么：组合式问数、对账、召回要把一份口径的取数节点拷进另一张图，同一张图里放两份口径时节点 id 会撞，拷过来的取数节点得改名（c1_fetch）。以前 caliber_from 只认同名的取数节点，改了名口径卡就取不到输入。 做了什么： - metrics._pinned_caliber 认 caliber_from.nodes {原 id: 新 id}：按语法树把式子里 nodes.<原 id>（含 cell(nodes.X, …) 的第一个参数、nodes['X']）的根换成新 id 再算，字符串字面量里的字不动；指标集的 source 照记映射。映射形状不对节点失败并说清哪一处。 - 画布校验 _caliber_from_issues：映射的形状和运行时同一个判断（rename_problem），改名后的节点要在图里、在口径卡上游。 - 升版检查照常挡、照常记事件，事件带上 caliber_nodes；证据的 _caliber_source / _caliber_upgrade 照带映射。 - 运行对比按映射把式子换回那一版里的写法再比：同一份口径换了节点名不算口径变了。推演按卡上记的改名后的式子原样重算。 - 没写 nodes 的老图一字不差：式子不经 unparse、来源只有三项、升版事件没有新键（单独测）。 测试：tests/test_caliber_from_nodes.py（改写规则、运行时取值、证据链、推演、校验、升版检查、对比、老图不变）。	2026-10-16 16:20:25 +08:00
ThearchyHelios	91cc150f17	下一轮第 3 波的契约骨架：工作流版本加表的结构版本；定时的非工作流目标按种类交给各自的模块（评测题集 app/eval/scheduled、数据源维护 app/data/source_maintenance，先放照实记「还不能发起」的占位）、record_fire 共用；分享链接、数据源变化记录、口径账本按答案出具与对账的路由先登记好权限	2026-10-16 15:51:33 +08:00
ThearchyHelios	ee8c0317a2	合入 W2-d 访问密钥与服务账号：服务账号（管理员建、不能登录）与个人访问密钥（管理员开关，缺省关）；只存哈希、必设到期、轮换与撤销；按路由白名单放行、封顶在使用者边界（看到的都遮过）；发起入口和刷新视图必须带幂等键；视图数据接口 agentlab.viewdata/1；审计、请求记录、钩子收件记录；接口说明；设置里的访问密钥页	2026-10-16 15:38:33 +08:00
ThearchyHelios	9e687114f7	合入 W2-c 评测题集与期望答案：题集、题目、评测、结果的数据模型；三种期望来源（SQL、口径、从运行认定），每次以评测来源的探索运行重算，遮罩列拒收；口径升版的三种处置；全站唯一的派生图生成器 ledger/derive.py；目录快照与影子起草（不碰线上目录、不查业务库）；题集导出导入；零售样例题集	2026-10-16 15:38:11 +08:00
ThearchyHelios	64ed51c95d	合入 W2-b 口径账本内核：sql_semantics 的参数绑定与等价证明（绑定只当启发，等价只由 explain_sql_diff 判，执行守门进语料）；探索运行封存后在后台比对口径，结果存 caliber_match 工件并追加封存后事件 ledger.matched，启动补比；逐个数的口径标签与整题判断（GET /api/runs/{id}/ledger、证据片段、报告导出的「口径」一步）；运行与问数据轮次、画布来源的封存链接；报告导出留审计；E1–E4 统计	2026-10-16 15:38:11 +08:00
ThearchyHelios	298e52bd69	按复核意见修后台探查的三处退化（A-1、A-2、A-3） ... A-1 升级后第一次后台探查中途停下，表结构缩成已读完的那几批： schema_cache 只从对象索引物化，老缓存（升级前同步探查写的，没有 scope 摘要）里的表结构却从没进过对象索引。 于是第一次探查只要停止、连接断开、服务重启，或者排队时有人按需加入、探查失败要记一笔，物化出来的就只剩已读完的表， 老缓存里还没重读的表静默消失，skipped 里也没有。先在探查范围面板刷新过对象索引、再探查却连不上时更糟：表结构清成空的。 现在这个 schema 的对象索引第一次建起来时（refresh_index 的 legacy，source_objects.legacy_seed），把老缓存里的表结构 接进对应的行：在范围里、算规则命中，带老结构和它的指纹，结构版本记 0（第一次真读到记 1，不把反射格式的差异当成 结构变化）；老缓存里读不到结构的照样记成读不到。缓存的 schema 和配置对不上的不接，对象索引里没有的不接。第一次 任务开始时照规则重圈，没重读到的沿用老结构，和以后每次探查中途停下一样。 A-2 schema 填错、一个对象都没有时不再给候选 schema： PostgreSQL、Oracle 的 schema 写错时字典查询只回 0 行，不抛错，新路径就只物化出 tables={} 并盖上同步时间， available_schemas 没了：卡片上「该服务器上还有……」、助手摘要里「数据可能在这些 schema」都给不出。现在 prepare 拿到 0 个对象时照旧用 list_schemas 拿候选，记在任务的 scope 里，物化时由 rebuild_schema_cache 写进 available_schemas （不置 failed：这不是一次失败）；有了对象再探查就不再挂着。 A-3 排队中「加入范围」的表在任务开始时被移出： _apply 只保留建任务时圈好的表和所有 on_demand 的行，目录页显式加入（explicit）的表被当成离开范围、清掉结构。 现在保留 added_at 不早于建任务时刻的行（按需加入、显式加入都算），原因按 pinned > 显式 > 规则 > 按需取高的； 建任务之前就按需加入、又被显式移出的不再一律留着，照规则移出（以前「留着所有 on_demand」会让显式移出不生效）。 测试（tests/test_introspect_jobs.py）：60 张表的老缓存，第一批读完后停止 / 第二批连接出错 / 重启标中断 / dry_run 后探查失败，表数都不减少，再探查一次结构版本全是 1；别的 schema 的老缓存不接；空库和替身模拟的 0 对象 schema 带上 候选、DataSourceOut 和助手摘要都看得到；排队中显式加入、按需加入的表任务跑完仍在范围里。去掉三处修复各自回跑， 对应的测试都失败。	2026-10-16 15:36:21 +08:00
ThearchyHelios	9cd45ca047	评测题目返回给界面的说明改成合规文案：check-copy 三项规则恢复全过 ... check-copy 也扫后端交给界面的报错文案，nr2/c 交付时没跑这一道，有三项没过（复核 C-1）： - 口语补语：期望 SQL 行数不够时写的「取不到值」「取不到第 N 行」，改成「没有可用的值」「没有第 N 行」； 同一处 where 匹配到多行的「取不准是哪一行」一并改成「无法确定是哪一行」。 - 禁用词「钉住」「改钉」：升版处置的叫法（UPGRADE_LABEL）和 DisposeRefused、升版状态的说明，按全站 「固定版本」的说法改成「固定的…」「改为固定新版本」，和应用、子工作流的升版说明一致。 - 半角标点和英文引号：题目 where 写错时的报错例子原来是一段 JSON，改成全角的「地区：华南」，并写明取值只能是 文字或数字（校验本来就只收这两种）。 只改文案，判断和机读码都不变。代码注释和模块说明里的「钉」不上界面，照全仓库的写法保留。	2026-10-16 15:23:44 +08:00
ThearchyHelios	f9f5338ec6	数据源不可用时的 db_schema 替身也收 keyword；重读范围内读不到结构的表不记成按需加入；起草、剖析排在探查后面的测试 ... - tools/datasource._unavailable_tool：db_schema__ 多了可选的 keyword，固定的版本不在了时的替身也要收这个参数（调用工具节点按 参数模型的全部字段传参，不收就报「不接受名为 keyword 的参数」，全量测试里 test_run_data_versions 抓到的）。 - source_objects.add_to_scope：本来就在范围里、只是上次没读到结构的表（pinned、规则命中的）这次重读一遍，不改原因、不记留痕， 不算进「每次运行最多按需加入 8 张」，也不出现在面板的「按需加入的表」里。 - tests/test_introspect_jobs.py：起草、剖析任务排在同源的探查任务后面时 waiting_for 是 introspect。	2026-10-16 14:53:41 +08:00
ThearchyHelios	64ca6cb75b	look：交回给模型点名的预筛目录只对这一次查看的需求有效，每次查看开始时清掉 ... 为什么：挑选模型拿不到时（没有可用的模型）pick 不会重建预筛目录，index() 会交回上一次查看、另一个需求的那份。	2026-10-16 14:50:26 +08:00
ThearchyHelios	f4755056e6	前端跟上后台探查：数据源卡片上的进度、停止、结果，探查范围面板；目录清单的几种「不在」、分批显示、搜索范围外的表并加入范围 ... 为什么：探查改成了后台任务（POST /introspect 回 202 和任务），界面不能再等同步结果；几千张表的库要能设范围、看命中数， 目录清单要说清表为什么不在，范围外的表要找得到、加得进来。这一波直接进 main，不能有半截的功能。 - 数据源卡片：「探查结构」开始后台任务，进行中每秒取一次进度（进度条、正在读哪张、排在谁后面），「停止」停在当前一批之后； 结束时换上任务带回的数据源、说一句结果；最近一次没做完（部分读不到、停止、中断、失败）常驻一行，读不到的表可展开。 规则命中超过上限时照实说命中数并给「调整探查范围」；已有任务时跟上那一个；对象清单拿不到时重取卡片显示原因。 有范围外的表时写「探查范围 400 / 3,000」。换 schema 后的重新探查、按配置重新探查、新建后的探查都走任务。 - 探查范围面板（IntrospectScopeDialog）：全部对象 / 按规则，包含、排除（排除优先）、显式列出、显式移出、包含视图、上限； 边改边数命中（停手 400 毫秒问服务端，不连库），超上限写明会被拒绝、「保存并探查」点不了；一律在范围内的表说明和举例； 按需加入的留痕；没有对象索引时「刷新对象索引」（dry_run）。界面不算命中，规则只在服务端一处。 - 数据目录：表清单一次画 200 行、「显示更多」；表结构里没有的按 absent_reason 分开说（只有真删除说「表已不在」），老服务端 不给原因时照旧；有范围外的表时搜索词同时在对象索引里找，命中列在清单下面、「加入范围」后清单重取；顶部说明按探查范围写 （老缓存照旧说只探查了前 N 张、请重新探查）；表详情按原因说；起草、剖析排在探查后面时写明。 - 运行面板的查看记录读 added_to_scope，展开区写「按需加入探查范围」。 - 类型、接口、文案各写各的块（types.ts / typesApp.ts 末尾、client.ts 的 datasources 和 dataCatalog、terms.ts 的 INTROSPECT_TEXT / INTROSPECT_SCOPE_TEXT / CATALOG_ABSENT_TEXT / CATALOG_SCOPE_TEXT），SCHEMA_PARTIAL_TEXT 改成按探查范围说。 - 检查：check-manage 的假探查改回 202 和任务、加「数据 · 后台探查与探查范围」一节（超上限、刷新对象索引、边改边数、 保存并探查、进度、停止、结果）；check-catalog 的「只探查了一部分表」改成老缓存的说法，加「探查范围：三种不在、分批显示、 加入范围」一节。两项检查 1,135 项全过。 - introspect_jobs 的一句报错不用「连不上」（check-copy）。	2026-10-16 14:46:58 +08:00
ThearchyHelios	4ba4a21b2c	大库的 look 预筛与按需加入、剖析事实四处一致、有效记录条件按 quote_name 加引号的测试；对象索引批量更新改走按表的 executemany ... 为什么：A2 和遗留 e 的行为要有脚本化的验收，且能证明测试抓得住回归（去掉遮罩重滤、去掉 quote_name 强制引号后对应用例都失败， 已回跑确认）。 - tests/test_look_large.py：3,000 张表的合成库，探查范围 300 张 + 5 张有目录的表，其余只在对象索引里（注释写进索引，模拟 MySQL / PG 的表注释）。10 条脚本化需求挑中 ≥ 9 条、挑选提示词 < 20,000 字（挑选用按字面重合打分的假模型，只看得到交给它的 那份目录）；挑中范围外的表按需加入、记 added_to_scope 和留痕；点名的每次查看最多 4 张、超了照实说；db_schema__ 的 keyword、 只列前 50 张、每次运行最多 8 张；查询照实列「未按目录检查的表」；目录搜索和「加入范围」；剖析的关系指向范围外时不说 「表结构里没有」。 - tests/test_profile_facts.py：look、运行时 db_schema、/schema、表助手四处同一段剖析事实和固定提示；剖析之后加遮罩，那一列 的范围不出现；没有剖析结果时表详情一字不差；上传表格快照不一致（含没记快照的）不给；剖析任务开始一张表时记下快照； 「上次剖析」取真正开始过的那一次。 - tests/test_valid_filter_quote.py：存进目录的写法和剖析核对查询都按 quote_name 给 Oracle 小写列加引号。 - source_objects.refresh_index：注释、类型、行数估算有变的行改用按表的 executemany（ORM 的按主键批量更新要求参数里写主键 列名，3,000 张表的库第二次刷新索引时报错）。 - db_schema__ 不传 table 时说清没列出的里有几张在探查范围外。	2026-10-16 14:26:04 +08:00
ThearchyHelios	0a3c45eb97	口径账本：合并查询的格照实写为什么没比对；账本测试按用例各用一个数据源隔开 ... - ledger/match.py：合并查询的快照不和口径比（它的数来自各个输入的查询），引用了它的格以前标成「没有比对记录」，现在写明 「合并查询的格不和口径比对」；它不进工件的 queries，统计不数它。 - 测试：账本的用例以前在开头把别的用例发布的版本一律退役，好让候选口径只剩自己的——并行时会碰到同一个进程里别的测试模块的 数据。改成每个用例一个名字不同的数据源（候选口径本来就按数据源预筛），不动别人的数据。补启动补比随调度开关起后台任务的用例。	2026-10-16 14:23:41 +08:00
ThearchyHelios	1a6082f033	大库的对象索引、探查范围和后台探查（next-round 03 A1），schema_view 预筛与按需加入、剖析事实的后端（A2、遗留 e 的底座） ... 为什么：几千张表的库以前用不了——探查每个源最多取 200 个对象、按数据库列出的顺序截断，同步请求、整份替换、不排队； 落在窗口外的表在目录、look、剖析里被说成「表已不在」。 做了什么： - db/models_sources.py：source_objects（对象索引一行一个对象：范围、原因、结构指纹与 struct_version、first_seen / last_seen / removed_at、reflected_at、按需加入的留痕）、introspect_jobs / introspect_tasks（后台探查任务与逐表状态）。 - data/source_objects.py：每种方言一条字典查询建对象索引（失败退回 Inspector，上限 5 万，截断时不判删除）；探查范围规则 （options.introspect_scope：通配、按 name_key、排除优先、显式列出 / 移出；有目录的表、已发布模板写死 SQL 用到的表 pinned； 命中超上限拒绝并说出命中数）；唯一的 rebuild_schema_cache 从范围内已反射的行物化 schema_cache（形状不变，另加 scope 摘要）； 三种「不在」分开说（removed / missing / out_of_scope / reflect_failed）；按需加入（当场只读反射、落盘、留痕、进程内按源加锁）。 - data/introspect_jobs.py：探查改成后台任务（core/job_runtime，lane kind introspect，和同源起草、剖析串行；按批反射、逐表记状态、 可停止、读完的照样物化；重启标中断不续跑）。 - api/datasources.py：POST /introspect 返回 202 和任务，dry_run 同步只刷新索引、返回命中数；/introspect-jobs 读任务、停止； /introspect-scope 读、预览、保存规则；/schema?table= 带剖析事实、说清三种「不在」；DataSourceOut 加 schema_scope、introspect_job。 - schema_view：search_tables（BM25 倒排，遮罩列只用列名，范围外只按名字和注释、权重低一档）、profile_lines（剖析事实一节， 附「只供写查询参考」，遮罩按渲染那一刻重滤，上传表格快照不一致时不给）、absent_detail。 - look：候选超过 PREFILTER_LIMIT 时只给预筛结果 + 已用到的表 + 一跳关联；点名或挑中范围外的表按需加入（每次查看最多 4 张）， look 记录加 added_to_scope、prefiltered；表详情带剖析事实。 - tools/datasource：db_schema__ 加 keyword、不传 table 时只列前 50 张；点名范围外的表按需加入（每次运行最多 8 张）；查询结果 照实列「未按目录检查的表」（unchecked_tables，不新增检查规则）；建工具时读剖析事实。 - 剖析：_relation_ends 分清「范围外，可以加入」和「表结构里没有」；任务记上传表格的 snapshot_id；last_facts。表助手、/schema 用同一段剖析事实。 - 目录接口：清单只列范围内，absent_reason 分开说；GET /catalog/search 查对象索引，POST /catalog/scope/add 加入范围。 - 第 1 波留下的一处：check_valid_filter 和 stored_valid_filter 拼有效记录条件时按 quote_name 强制加引号。 - 工具参数纠错：空着的可选参数不止一个时，只认拼写明显接近的那一个（db_schema 多了 keyword 以后 tabel 仍能纠成 table）。 - 测试：3,000 张表的合成库（对象索引、缺省范围超上限拒绝、规则圈 400 张后台读完、停止、重启标中断、和剖析排队、同步起草 409）、删除与结构版本、Inspector 回退、截断不判删除、范围规则、pinned、方言金样；改了同步探查的老测试改为等任务做完。	2026-10-16 14:17:06 +08:00