250 Commits

Author	SHA1	Message	Date
ThearchyHelios	45c1ede402	评测前端：顶级导航「评测」、题集与加题、发起评测、评测详情、口径命中与重复度、目录快照；定时页选目标种类；记录页评测来源；设置里评测一组 ... 为什么：前三波评测只有接口，这一波是收口——每样能力都要有界面、能走通（细案 01 第 18 项、第 15 项定时的前端部分，评测-D8）。 界面层不放逻辑：比率、结论、趋势、分档、能不能做都由服务端给（上一次提交在 api/evals.py 补的 latest、trend、actions、 preview、signals、逐题花费），界面只显示。 - 导航：「评测」排在设置前面、⌥0，搭建者以上可见（使用者的页面表在 visiblePages 里收窄，手输地址被送回应用首页）。导航从 9 项 变 10 项，在 600、520、480 像素高的窗口里重新量过：≤520px 那档的导航项从 32px 收到 30px（17px 图标 + 2px + 11px 字）， 不然 480 高时遥测点超出视口 12px；App.tsx 的说明跟着改。 - 评测页 pages/evals/*（类型 typesEval.ts、接口 api/evals.ts、文案 lib/termsEval.ts 的 EVAL_TEXT）：题集列表（最近一次、同一 变体的趋势、定时，没有定时给「设定时」带着题集去新建）；新建、导入（先预览）、导出、归档、删除、题集设置（时区、默认变体—— 定时评测按它评、预算只填要改的项）；题目表（启用、试算、编辑、删除），口径升版待处置的顶部提示和三选一处置（叫法由服务端给， 没有缺省）；加题四种方式：写 SQL 定期望（选数据源、写 SQL、预览、点选格 / 列 / 配对列、按维度找行、试算，遮罩列拒收的原话 落在 SQL 下面）、选口径（工作流｜口径卡｜指标，不能复用的照列写原因，口径的输入按那一版的入口字段填）、从问数据运行认定 （选运行、选查询、选取哪一列，用到遮罩列的查询不给认定）、期望没有数据或期望反问；可另加文字要点。数值期望不许人填：只点选 取哪一格。 - 发起评测：评一次 / A/B 对照（两到三臂）/ 目录贡献对照（预设，可加「只用已核实和已确认的项」），变体有助手、写作模型、结论 裁判、目录（当前 / 只用已核实的 / 关 / 快照）、重复次数；估算和发起是同一份请求体，项数、按上一次估的花费、生效的预算、今天 已花照服务端写；可点名和哪一次比。 - 评测详情 /evals/runs/:id：进度和每题正在做什么、停止、只重试没做完的、按新规则重评、设为基线（按钮照服务端的 actions 摆）； 总览卡片（准确率和可追溯准确率带区间、花费、逐题 E1）和各项分布（结论、作答路径、出具档位、复核、结论裁判、引用率、查看、 耗时、按角色的用量）；逐题表（结论、期望和答案里的数、弱匹配、SQL 差在哪、查看、耗时、花费，展开看原因、去运行详情； ?case= 定位那道题）；和上一次比（换基准、指纹差异、转移和归因）；A/B 配对表（都对 / 只 A 对 / 只 B 对 / 都错、p 值）。 - 「口径命中与重复度」页签：E1、E3 这一窗口的值和档位、参考线、往前几个窗口的趋势（GET /api/evals/signals），明细直接调口径 账本的 GET /api/ledger/stats（总方案 X2）；成员不少于 3 的问题类能加入题集（带着问法去加题）、提取模板（从最近一次的运行提取， 去画布）。目录快照页签：拍当前目录、影子起草（先估算再开始，能停）。 - 定时页：新建时先选定时什么（工作流 / 评测题集；数据源维护在数据源页建），评测题集的表单（pages/schedules/TargetEditor.tsx：名称、题集、 FreqPicker、补发宽限，建题集目标用 ScheduleTargetCreate），评测题集的定时在详情里能改名称、频率、时区、补发宽限（SchedulePatch， 只交改了的、带版本）；数据源维护的定时只读、链到数据源页，第 3 波「只能查看，不能修改」那句改成说清在数据源页设置；触发历史里 的评测链到评测详情。纯函数 targetFormOf / targetCreateBody / targetPatchBody / targetProblems 放 model.ts。 - 记录页：评测运行旁的「评测」标记写是哪一步（作答、算期望……），点了回到评测里那道题；运行详情页头有键盘到得了的链接 （pages/runs/EvalSource.tsx）。 - 设置：偏好设置里「评测」一节（pages/EvalSettings.tsx，SettingsPage 里加一行）：四项预算缺省、保留几次、缺省开不开结论裁判、 今天已花；自己存、只交 eval 一组，取值范围只在服务端判。 - 问数据用量（评测-D14 的界面一半）：复核慢过问数据页的等待上限时，答案照原样先交出去，复核那一次的用量晚到了照记进这一轮、 再落一次库（以前直接丢掉）；开发期 window.__chatReviewWait 让检查脚本把上限调短。 检查：check-evals.mjs 换成真检查（假接口加夹具，写请求在浏览器层拦下并断言请求体，98 项）；check-shell 导航十项、⌥0、三种窗口高； check-schedules 目标种类（纯函数和页面）；check-chat 用量那一段加复核晚到。	2026-10-16 20:38:07 +08:00
ThearchyHelios	56ca53ad35	问数据建图用量不再是下限；评测通知链到评测详情；评测接口补界面要的几样 ... 用量（第 1 波遗留）：查清楚了，丢的不是浏览器那边——问数据页一直读到 SSE 结束、usage 那一条收得到——而是服务端生成过程 （api/copilot_gen._iter_ops）读到 done、look、ask 那一行就关掉模型的流，流末尾那一段才报的用量（Anthropic 的输出 token、 OpenAI 兼容系的 stream_usage）一次都拿不到，每次建图都记成「估不出」，这一轮的花费多半是下限。改成交出那一行之后先把流读完 再关（_drain，内容丢掉）：照约定那一行就是最后一行，读完只多收用量那一段；模型在那一行之后还往下写超过 DRAIN_CHARS 字闲话的 当场关流、照实记成没报全（不为闲话付钱，也不当成报全了）。评测的作答（app/eval/answer.Driver）走同一个 answer_ops， 用量跟着报全，和问数据页同一个口径。test_usage_meter：原先断言「输出 token 为 0、记成估不出」的那条改成报全；另加 look 后、 闲话超限、评测和问数据页收到同一份用量三条；去掉修复回跑，三条都抓得住。providers/usage.py 的说明跟着改。 通知：notify_eval 的链接从定时任务的触发历史改成这次评测的详情页 /evals/runs/{id}（评测页这一波上线）；测试设上对外访问地址、 断言链接（原来的断言在没设地址时对空列表恒真）。 评测接口（只加不改，app/api/evals.py）：题集列表和详情带 latest（最近一次评测）、trend（同一变体最近几次评完的准确率，旧的 在前，换了模型、目录的不连成一条线）、schedules（目标是它的定时任务）；评测详情带 actions（停止、只重试没做完的、重新评分、 钉住 / 取消基线能不能做，和接口拒收的条件同一份）和没做完的项数；POST /suites/{id}/cases/preview 写 SQL 定期望的预览 （同期望的 SQL 探针，交回列和前 50 行，遮罩列照保存时那一道拒收、没过守卫的指明是哪一格，都不回 422）；GET /signals 「口径命中与重复度」的判据和分档、窗口趋势（数只出自 ledger/stats.compute_stats）、成员不少于 3 的问题类（只出自 chat/questions，评测运行不进）。为什么放服务端：界面层不放逻辑，统计、能不能做都由服务端给。tests/test_evals_ui_api.py。	2026-10-16 19:41:57 +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	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	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	e65ac3e619	助手的节点手册：子工作流补上 workflow_version（口径账本做法 4 ⑤） ... 为什么：手册里子工作流只写了 {workflow_id, input}，模型不知道能固定版本。补上写法，并说明问数据里不要拿子工作流去拼已发布的口径——子工作流里的数报告引用不到，组合口径走 use_caliber 的内联实例化。	2026-10-16 17:18:37 +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	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	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
ThearchyHelios	545babc541	访问密钥收尾：服务账号进授权不进岗位的测试、关停时写请求记录的测试，几处整理 ... - 补测试：应用授权收服务账号、岗位绑定的检查把它算成错；改派给服务账号 422；调度循环停下时把攒着的请求记录写进库 （去掉对应的代码回跑，测试抓得住） - 门禁里只给拥有者的运行统一按 auth/access.PRIVATE_ORIGINS 认，不再各写一份字面量 - 幂等的 once 只把普通异常记成被拒：请求被取消时记录停在处理中，过了时限同一个键能重新认领（同钩子） - 新建密钥的弹窗等服务账号取回来再说「还不能建」，不先闪一下	2026-10-16 14:15:51 +08:00
ThearchyHelios	0b825f40ee	设置里的「访问密钥」与钩子的收件记录（下一轮第 2 波 W2-d 前端，细案 04 A1、A6、A7） ... - 设置 → 访问密钥：管理员看个人访问密钥的开关、服务账号（建、停用前确认）和全部密钥；别人只看自己的个人访问密钥，管理员 打开开关之后才有这一页（认人接口多给一项 personal_keys：关着时建不了、已有的也不生效，给一页空的没有用）。新建时缺省只勾读 的权限，服务账号勾不了回复待办，有效期必填最长 365 天；明文只显示这一次，点「我已保存」就没了；轮换、撤销先确认；关登录时 照实说访问密钥不生效、不给建的入口 - 「最近的请求」做成共用组件（components/RecentRequests.tsx）：每把密钥的请求记录、钩子的收件记录都用它，接口写路由模板， 成功、被拒、处理中分开上色 - 接口说明：照服务端门禁那张表列出方法、路径、权限、说明、错误码，标出要幂等键的 - 应用编辑 → 钩子：生成过密钥的钩子能展开收件记录（状态、原因、发起的实例），写明近 1 小时验签失败几次 - 名录里的服务账号：选人控件缺省不收（岗位绑定、改派不能派给它），应用授权照收；身份页那一行标出服务账号，不给角色和密码的 控件；审计按「访问密钥」筛 - 检查：新建 check-access-keys（不叫 check-tokens，那个名字查的是设计令牌），check-app-editor 的钩子一段加收件记录；登记进 check-all	2026-10-16 14:11:30 +08:00
ThearchyHelios	7f14313416	评测题目的几处收紧：口径题只能固定已发布未退役的版本、处置升版后按新版本再核一遍、试算前结束读事务、影子起草分开记只写出一部分的表 ... - cases.resolve_case：口径题钉的版本没发布过或已退役的，保存时照实拒收（422，field=gold.version）；以前要等试算跑到 升版判断才说得出。 - 处置升版（recompute / incomparable）改钉新版本之前，按新版本再过一遍 resolve_case（入口字段、指标），说得清是哪一项不行。 - 接口里的试算要等一次运行跑完（最多两分钟）：先结束这个请求的读事务再等，不一直开着它（导入时同样）。 - 影子起草：只写出一部分的表另记（tables_partial），快照照出、状态 partial；一张都没起草出来才算失败、不出快照。以前 只写出一部分的表算成没起草出来，几张表都只写出一部分时整次记失败、写好的部分也丢了。 - 题集里推起草哪些表时，期望 SQL 按题集的时区渲染。	2026-10-16 14:05:22 +08:00
ThearchyHelios	5b4bd91476	口径账本内核：运行封存后在后台比对已发布口径、逐个数标口径、按运行读的账本接口、来源链和导出留痕、统计 E1–E4 ... 为什么：问数据的答案要和已治理口径接起来（next-round 02 做法 2、3、9、10；总方案 X1、X2、X3、X12，拍板 L2、L4、L8）。 - 比对（ledger/match.py）：探索运行（chat、canvas、trial、personal_app）成功结束、封存完、有查询快照时，在 runner 封存之后和 notify_run 同一个位置放到后台；候选口径是每个工作流最新的已发布未退役版本里查库的调用工具节点（受管、已发布都算），按数据源 和表预筛；逐个用 match_template 比，schema 用查询当时冻结的表结构、列名取同一份快照里冻结的数据目录。每次运行限时 8 秒、在 线程里、同时最多 2 个；超时、快照被改过或读不出、SQL 解析不了照实记 skipped。启动时（run_manager.setup，和调度循环同一个开关） 补比最近 7 天封存了却没比过的运行，只读工件和版本表。 - 记法（ledger/store.py，拍板 L8）：内容寻址工件 kind=caliber_match（agentlab.caliber_match/1）+ run_append 的 sealed 方式追加 ledger.matched（core/events.py 登记）；工件里不放时间和工作流名，同一份封存再比一次哈希一样；meta 记 calibers / related / counts。 - 标签（ledger/labels.py）：单元格按查询的比对状态；指标要每个输入都等价于同一份口径同一版、绑定一致，式子按「哪个取数节点、 第几行、哪一列」换完和口径卡上的一字不差。caliber（how：independent 等价已证明；composed 助手选用留给第 3 波）/ related / reasoning / unknown；整题判断附还缺的入口字段。 - 读（ledger/view.py）：GET /api/runs/{id}/ledger（ledger_api.runs_router，和证据同一道门），没比对过、能比的按需排上；证据 片段接口加 ledger 键（没比对过的运行没有这个键，返回一字不差）；报告导出的面板最上面多「口径」一步并写明「封存后比对，不在 封存范围内」。遮罩按读的那一刻重滤：绑定的值是这次运行查到过的遮罩值时不给值，差异条目和逐行对照走 _Shown。 - 来源链：POST /api/runs 加 origin_ref（只在 origin=chat 时收，服务端核对对话访问权和轮次归属，写进 Run.origin 和封存的 run.origin）；WorkflowIn 加 origin（run_id、conversation_id、turn_id，核对规则同 from-run）；报告导出和可验证报告下载各记一条 审计 report.exported。可验证报告列封存后追加的事件时给 ledger.matched 一句只有条数的说明。 - 统计（ledger/stats.py）：E1–E4 从工件、运行、查询快照、审计现算，GET /api/ledger/stats（搭建者）；E3 用 app/chat/questions 的聚类加按（数据源、normalize_sql 文本）的确定性重复；评测直接调 compute_stats（可点名 run_ids）。对账反馈、认证转化、按发布 的召回在后面几波，照实写没有数据。 测试：test_ledger_match.py（真跑探索运行：等价、相关、没有相关口径、写死的码值、非探索运行、超时、快照被改、解析失败、预筛、 指标两种、级别、只认最新版、补比）、test_ledger_api.py（账本接口、按需比、遮罩、证据片段、导出、审计、统计）、 test_run_origin_ref.py（origin_ref 与画布来源的核对）。	2026-10-16 14:02:55 +08:00
ThearchyHelios	a7e91b16a1	评测接口与题集导出导入、零售样例题集（第 2 波 W2-c） ... - api/evals.py（骨架已登记、只给搭建者）：题集、题目的增删改查（改要带读到的 version，对不上 409；有评测记录的题集不能删， 只能归档）。保存题目时试算一次（细案 01 做法 8）：没过只读守卫、用到遮罩列、取不到值、运行失败、超时、口径升版待处置的， 照实回 422（带机器码和 field）、不保存；只改标签、启用的不重新试算。另有只试算不保存、试算已有的题。 - 从运行认定：GET /runs/{id}/queries 列出那次运行的查询（只给 SQL、列名、行数，不给格），POST …/cases/from-run 拷出一条 查询的 SQL 建题，记确认人、时间、出自哪次运行；客户端不能自己写 from_run，要改 SQL 就改成 SQL 题。 - 口径：GET /calibers 和蓝图助手同一份口径清单（能不能复用、为什么）；GET/POST …/upgrade 看、处置口径升版， recompute / dual / incomparable 三选一、没有缺省；不可比的旧题归档、按新版本另建新题。 - 目录快照：当前目录（当场写好）、影子起草的计划和估算、后台影子起草（202）、查看、停止。 - app/eval/transfer.py：题集导出成 JSON（数据源、工作流按名字；不含期望值、答案、运行，从运行认定只带确认人和时间），导入 按名字对上、逐题过同一套校验和同一道试算关，对不上、没过的跳过并写原因，一道都导不进来就不建题集。 - tests/fixtures/eval/retail_suite.json：零售样例题集，配 tests/fixtures/acceptance/retail.py（数据源名 retail_demo， retail.SOURCE_NAME）：支付日归属、退款、取消、华南高于华东，一道「华中区」期望没有数据，一道问法含糊期望反问。测试在 按今天生成的零售库上导入，六道题都试算通过、期望和直接查库一样、陷阱按口径算。	2026-10-16 13:58:36 +08:00
ThearchyHelios	19329c873e	访问密钥与服务账号的后端（下一轮第 2 波 W2-d，细案 04 A1–A6、总方案 X8） ... 外部系统（门户、OA、BI）和个人脚本要用一个身份调接口，以前只能拿个人会话 cookie 去模拟。这次加访问密钥： - 签发（A1）：users.kind 区分人和服务账号（svc- 开头、没有口令、不能登录、角色固定使用者，管理员建）；access_keys 只存 sha256 和开头一截，明文 agl_ 加 32 字节随机串只显示一次；到期必填（最长 365 天、缺省 90 天）、可撤销、可轮换（新钥 + 旧钥 24 小时后到期）；个人访问密钥由管理员开关 auth.personal_keys 管，缺省关，关掉时已有的个人密钥一并不认 - 认人与门禁（A2）：Principal 加 via / key_id / key_name / scopes / app_ids（全部带默认值）；中间件认 Bearer agl_…，不看 cookie、不查 CSRF、不看 X-Actor，认不出的各回 401 带各自的 code、绝不退回匿名；WebSocket 带密钥一律拒；关登录时 409 keys_need_login。KEY_ROUTES（方法 + 路由模板 → scope）一张表，FastAPI(dependencies=[Depends(key_gate)]) 挂一次；不在表里的 403 key_route_forbidden，缺 scope、限定应用、个人应用和试运行各有各的 403；每把密钥每分钟 120 次（429 + Retry-After） - 封顶（A3）：按密钥认出来的一律是使用者（拥有者现在的组），现有的使用者规则和遮罩全部自动生效，管理员的密钥也一样 - 写操作（A4）：发起入口、刷新视图必须带 Idempotency-Key，api_receipts 按（拥有者, 键）去重，轮换后照样认得出；状态机从 process/hooks.py 抽到 process/receipts.py，钩子和密钥共用（钩子现有测试原样通过），另按请求指纹拒掉同一个键办另一件事； 有文件控件的入口 422；回复待办只给个人密钥、只限审批 / 补充输入 / 编辑稿件；run.origin、task.responded 记 via=key、哪把密钥 - 视图数据（A5）：GET /api/apps/{id}/views/{view}/data（agentlab.viewdata/1），印章、清单哈希、口径卡指标原值和渲染文字， 遮罩的 value 为 null（和页面同一个判断），按需视图只读缓存、不发起运行，只给正式运行 - 留痕（A6）：建 / 撤销 / 轮换密钥、建 / 停用服务账号、开关个人密钥写审计；请求记录进程内缓冲、调度循环一拍里批量写、 保留 90 天；last_used_at 至少隔 1 分钟写一次；钩子收件记录接口（manage），验签失败只在进程内按钩子计数 - 名录与派单：服务账号在名录里标出，岗位绑定、选人候选、提交审核、改派里排除，应用授权照收；服务账号发起的实例里派给发起人 的待办交给任何人 - 接口说明（A7）：GET /api/access-keys/reference 从 KEY_ROUTES 生成（要登录） 测试：签发与各种 401、门禁合约（遍历全站路由）、CSRF 与身份来源、封顶（管理员密钥取工件也是遮过的）、幂等（含轮换后、 半路杀进程）、留痕、待办种类、视图数据（真跑的遮罩会员库）、限流、钩子收件记录。	2026-10-16 13:48:09 +08:00
ThearchyHelios	898e95a3ef	下一轮第 2 波的契约骨架：用户加 kind（服务账号）、剖析任务加上传表格的快照 id、工件按种类的索引；新模型文件 models_sources、models_eval（整模块导入）；评测、访问密钥的路由模块和口径账本按运行读的路由先登记好权限（评测只给搭建者，访问密钥登录即可，账本按运行读的和证据同一道门）	2026-10-16 13:07:40 +08:00
ThearchyHelios	3f5cf79b26	合入 W1-d 集成底座：安全响应头（frame-ancestors 缺省 self、白名单、script-src 先只上报）；对外访问地址只留一个设置（环境变量优先）；开登录时收起 /docs；集成接口的错误一律带机读码	2026-10-16 12:51:43 +08:00
ThearchyHelios	696cd17a4a	合入 W1-b 已知遗留：人工驳回记成已取消 + end_reason=rejected（不重试、不被出错时继续吞掉），各处照实写「被驳回」；个人渠道「我发起的实例完成 / 失败」生效；导入清单如实记「是否认证」；使用者选人按候选池、开登录时服务端核对；自由形蓝图按导入的图列「谁来做」；tick 按 id 断言	2026-10-16 12:51:43 +08:00
ThearchyHelios	e96b0180d9	可验证报告、报告导出写「被驳回」：元信息带 end_reason，核对仍按运行取消 ... 为什么：被驳回的运行导出后，可验证报告的运行结果写「已取消」，报告导出的运行状态也写「已取消」，和系统里「被驳回」两种 说法。封存里被驳回和手动停止是同一种结束事件（运行取消），分开它们的原因在那条事件的内容里，而运行取消的内容不随文件 附带（里面有驳回人和备注）——光看封存分不出来。 做了什么： - 两种导出的元信息都带 end_reason（bundle/build、report_export/build、对应的接口）。 - verifier.js：运行结果按运行记录写「被驳回」，核对的仍是「最后一条结束类事件是运行取消」，旁边写「已核对运行取消，被驳回 取自运行记录」，原因里写明这一半要去系统里对照；手动停止、老运行照旧「已取消」；文件里写被驳回、事件却是运行结束的照旧 不通过。runtime.js 的运行状态照 end_reason 写「被驳回」。 - 样本页加一份 rejected（check-bundle 样本数 17 → 18），断言写被驳回、写明取自运行记录、不提重新封存。 测试：test_bundle_rejected 用 node 载入 verifier.js 核运行信息（被驳回、手动停止、老运行、伪造）；test_bundle_build 核 元信息和样本页；test_bundle_api 核两种导出接口都带 end_reason。把实现退回去回跑，被驳回、伪造两条和元信息、样本页、 接口的断言都失败（手动停止、老运行两条守的是原样，照旧通过）；改完通过。	2026-10-16 12:46:48 +08:00
ThearchyHelios	b6cb5816db	问数据：被驳回的那次尝试不写「已手动停止」，会话列表标「被驳回」 ... 为什么：一轮的运行被审批人驳回之后点「重新运行本轮」，「之前的尝试」那一行写「已手动停止」，用户其实没有停过它。会话 列表的 last_status 把被驳回的一轮归成 cancelled，左栏不标——在等审批的那一问被驳回之后，看起来像是答完了（以前驳回 记成失败，左栏标的是「失败」）。 做了什么： - store/chat 的 attemptOf：被驳回的那次记 outcome=rejected，摘要写「被驳回：张工 驳回了「查数」：…」；老留档里记成 cancelled 的不改写。ChatPage 的尝试徽标认 rejected。 - api/conversations 的 last_status：前端落库时 meta 里记着 rejected 的、页面关掉没落库而运行是 cancelled + end_reason=rejected 的，都记 rejected；手动停止照旧 cancelled。types 的 last_status 加上 rejected。 - 左栏：打开过的看最后一轮（相位 cancelled 且带着驳回），没打开过的看 last_status，都标「被驳回」（不画异常色）。 测试：test_conversation_status 加一条（两种认法的被驳回、两种手动停止），改之前失败；check-chat 加一节被驳回（刷新后 认得出、补救区的话、左栏两种、重新运行之后的尝试记录），把前端改动退回去回跑，那一节 4 项不通过，改完通过。	2026-10-16 12:46:36 +08:00
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	3293ac0b58	自由形蓝图（后端）：按导入的图列出「谁来做」，只定由谁做；没绑时 bp.people_unbound 指向那张卡片 ... 为什么：自由形的骨架就是导入的图，图里派给岗位的人工节点、没登记查询的写入在应用里都要绑人，可蓝图上没有「谁来做」卡片。 第一次发布挡在 app.slot_unbound / app.reconciler_unbound 上，白话叫人「在「谁来做」里给这一步选人」，卡片却不存在；这时 应用还没建，也没法去应用编辑器绑，只能绕开蓝图（05-已知遗留 (d)）。 做了什么： - freeform 的 cards 加 people（「可选：只定每一步由谁做；会签、时限、超时在画布上改」）。freeform.people_rows 按 tree.slot_refs 列岗位行（同一个岗位用在几处合成一行，label 用节点标题拼、detail 写全每一处用途，path 是 /people/<i>/who）；写入能力没登记 查询时加一行「写入结果不明时谁去核实」（path /writeback/reconciler）；发起人、表达式、外部系统回调的步骤列成只读行。 blueprint_out 给出 derived_people，界面照这一份画。 - 存储复用现有路径：岗位绑定存在 spec.people[]（id 就是岗位名、只写 who），_common.slot_of / bindings_of 原样生效；核实人存在 /writeback/reconciler。needs_reconciler 对自由形按图里的写入算（with_graph 把蓝图存的图带给模板函数）。 - bp_set 对自由形的 people 只收 who（只收人和组，只由用户定），改会签、时限、超时、加减步骤报 bp.template_mismatch「在画布上 改」。apply_bp_op / blueprint_issues 新增 graph 参数，卡片接口、蓝图检查、试运行、实例化、蓝图助手都把蓝图存的图传下去。 - 检查：派生岗位、核实人没绑报 bp.people_unbound（试运行 warning、发布 error），路径就是那一行，带 slot；图里已经没有的岗位、 卡片上还留着的绑定报 warning，不静默删除。发布单照核实人的办法，去掉同一件事的 app.slot_unbound（slots.<slot>）和 app.reconciler_unbound。 偏离：岗位行不让助手代填（同「结果不明时谁去核实」，派活给谁是人的决定）。 测试：test_publish_plan 新增「财务审批（岗位）+ 写回（没登记查询）」建自由形蓝图一条（两行、不选人时只有 bp.people_unbound、 改会签被拒、选好人后绑到 finance 和核实岗位、发布单不再挡）；老的两条按新说法改；test_blueprint_templates 新增 people_rows 的合并、升级岗位、只读行、残留绑定提醒。	2026-10-16 10:34:18 +08:00
ThearchyHelios	d14fc97da7	应用入口、按需视图的表单没通过校验也带 code（form_invalid），和待办回复、入站钩子同一个码 ... api/apps.py 里这两处直接回 JSONResponse（detail + errors），上一次补错误码时只查了 HTTPException，漏了它们：外部系统发起 实例时表单不对，仍然只能按中文句子认。detail 和 errors 不变。 tests/test_integration_errors.py 的静态检查跟着扩：这几个模块里直接回的 JSONResponse 错误，内容里也要有 code（改之前 这条检查报出了这两处）。	2026-10-16 10:33:41 +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	a59409cc85	使用者选人（后端）：按用途给候选池，开登录时入口表单、待办表单的选人控件按同一个池核对 ... 为什么：使用者在选人控件里没有候选（名录只给搭建者），服务端也不核对。填错的名字原样派下去，待办给了一个不存在的人， 没人能处理、也不报错（05-已知遗留 (b)）。名录又不能整份放开给使用者（只读与最小可见）。 做了什么： - auth/directory 新增候选池：form 用途缺省是「能用这个应用的人」——使用及以上的授权（人；组列出组本身并展开成员）， 加上管理它的人（管理员、建应用的人）；应用授权给了所有人时池是全部启用的人（open），不带前缀 q 不列（needs_query）。 字段可以声明 x-principal: {pool: app | group:<组> | slot:<岗位>}（slot 按这次用到的应用版本的 bindings 展开）。 review 用途是启用的搭建者和管理员（同 personal._review_targets）。停用的人一律不列。 - GET /api/directory/candidates（任何登录的人；main.py 路由清单只加一行）：purpose=form 带 app_id+entry 或 task_id、field， 调用的人不能用这个应用 403；只回 {users:[{username, display_name}], groups, truncated, needs_query?}，不给停用、角色、 邮箱、组成员；q 按用户名或显示名开头筛，limit 最多 50。/api/directory 仍只给搭建者。 - 开了登录时 start_entry 和待办表单提交按同一个池核对，不在池里 422，errors 的 code=principal（FORM_ERROR_CODES 加一项）， 话写成「「x」不在可选的人里，请从候选中选择」（单点登录另说要先登录一次才进名录）。直接生效（遗留-Q4 按推荐）。 关登录照旧手填、不核对；不属于应用的待办（试运行、画布）没有池，不核对。 - apps/forms：x-principal 进 _FIELD_KEYS，validate_form_schema 查写法（只能写在选人控件上、只能是三种池）。 搭建者没有授权时按 apps/access 只能「查看全部实例」，不算池里的人——池按「能用」算，这一点写进了 app_pool 的说明。 测试：test_directory_candidates（只给名字、停用的不列、前缀筛、没使用权 403、名录仍 403；授权给所有人要前缀、截断；review 只出搭建者和管理员；入口表单不在池 422、停用的 422、组名和池里的人放行；待办表单同一个池；声明 group:<组> 收窄；关登录 任何名字照收；x-principal 写法校验）。	2026-10-16 10:24:22 +08:00
ThearchyHelios	e82d7fa55d	集成接口补齐错误码，开登录时收起 /docs、/redoc、/openapi.json（要搭建者登录） ... 外部系统只能按中文句子认是哪种错，文案一改就悄悄失灵；开了登录，接口说明仍然不用登录就能读，全部接口的结构对匿名的人 敞开（中间件只拦 /api/ 开头的路径）。 错误码（detail 文字一字不改，老前端照常显示；码都登记在 api/coded.py）： - api/apps.py 13 处：应用不存在（app_not_found，同入口发起时的码；没有授权的人也回它）、版本、实例不存在，钩子没声明、 没生成密钥，岗位绑定、个人应用草稿、授权、页面参数不合规；派生时工作流、版本不存在（apps/derive.py 的 DeriveRefused 带上码）；视图、入口、补算的拒绝原样带码，只有引擎不发起运行（LaunchRefused）没带码的几种补上 run_launch_refused - api/tasks.py 3 处：待办不存在、查看全部要搭建者（role_required）；服务层没带码的拒绝按状态补上同一类的码 （404 task_not_found、403 task_forbidden、409 task_closed、422 task_invalid），没改 process/tasks.py - api/artifacts.py 5 处：没有权限、这类原文只给搭建者、不存在、内容和哈希对不上 - api/deps.py 的 _forbidden（run_forbidden）、运行和证据接口的角色拒绝（role_required）、个人运行只给拥有者 （run_private）、问数据（chat_forbidden）；ensure_role / 路由级依赖走 auth.require，抽出 auth.refusal 一处判断， 没登录 401 auth_required、角色不够 403 role_required /docs：开登录时中间件把 /docs（含子路径）、/redoc、/openapi.json 当成 /api 一样拦，和路由级依赖用同一个 auth.refusal： 匿名 401，不到搭建者 403。关登录照旧（test_provenance_contract.py 的断言不受影响）。 测试 tests/test_integration_errors.py：这五个模块里不许再直接抛 HTTPException（静态检查）；应用、待办、工件、角色、运行 拒绝逐类核对 code 和原 detail；/docs 关登录照旧 200，开登录匿名 401、使用者 403、搭建者 200。去掉中间件的改动回跑， 开登录时匿名打开 /docs 是 200，测试失败。	2026-10-16 10:19:50 +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	d8034ca71a	对外访问地址只留一个：core/public_url.py 的 public_base_url()，通知、Webhook 链接、OIDC 回调、来源核对都改用它 ... 以前有两个「对外地址」：环境变量 AGENTLAB_PUBLIC_URL 只管 OIDC 回调和 Origin 核对，设置里 notify.public_base_url 只管 通知里的链接。只配了环境变量的部署，通知里不带链接；只在设置里填了的，回调又按请求的 Host 拼——违背「一种说法」。 - 新增 core/public_url.py：环境变量优先，其次设置（沿用 notify.public_base_url 这个键），都没有是 None。设置的值缓存在 进程里（中间件按请求核对来源，不能每次查库）：启动时 refresh 一次，PUT /api/settings 写完库就 remember，不用重启； 通知、定时任务 Webhook 手里本来就有会话，用 refresh 取，顺手按库里的值对齐缓存 - 地址的形状检查和规范化只有一份（url_problem / normalize），设置接口的中文报错和环境变量的启动校验都用它；环境变量 写错了（没有 http:// 或 https://、带 ? 或 #）启动时就报错，不再拼出坏的回调地址 - GET /api/settings 另给只读的 public_url 一组 {value, env_locked}，设置页据此显示「由环境变量指定」；环境变量设了时 PUT 把这一项改成别的值回 409（public_url_env_locked，field 指到这一项），原样写回不算改；public_url 一组写不进库 - notify/service 取地址的那一处、scheduler/webhook 链接里的地址、api/auth 的 OIDC 回调、auth/middleware 的 Origin 核对 都改走 public_base_url；deploy/agentlab.env 把这个变量的说法改成全站唯一的对外访问地址 测试 tests/test_public_url.py：先后顺序（环境变量 > 设置 > 无）、规范化、启动校验、PUT 刷新缓存、环境变量锁定（409、 不挡原样写回）、只配环境变量时通知带链接、OIDC 回调和 Origin 核对认设置里的地址。去掉修复回跑，只配环境变量的通知 链接、按设置核对 Origin 两条都会失败。设置页把它挪到「通用」在后面的前端提交里。	2026-10-16 10:18:12 +08:00
ThearchyHelios	ec5d9398b5	导入清单、累积快照清单、作废记录、清除原件记录如实写「是否认证」 ... 为什么：这四处的 signed_by.verified / signed_by_verified 写死 False。开了登录时署名就是登录的人，封存证据里却记着 「未认证」，和审计表、待办派单、run.origin 的 verified 口径对不上——留痕记错了事实（05-已知遗留 (c)）。 做了什么：api/deps 新增 signer_verified()（开了登录、这次请求的身份认证过时为真；关登录、不在请求里为假），和 signer_of 配对。表格导入提交、按期移除 / 作废接受、清除原件三个写接口在请求那一刻算好，和 signed_by 一起往下传到 recipe_imports._manifest、source_versions.manifest_doc / _revoked_record、table_versions.purge_import_raw；没有署名的 （退回暂存区上记的那个）照实记未认证。新参数都带默认值 False：运行里按配方导入一期（files/imports.py，署名取动作确认人 或发起人）没有请求身份，照旧记未认证。已封存的旧清单不改写，读取复验照旧。 测试：test_signer_verified（signer_verified 跟请求身份走；作废记录照给的写；开登录首次导入的清单 verified=True、清除原件 记录 signed_by 是登录的人且 verified=True，请求体里填的名字不看）。关登录的老断言（False）照旧通过。	2026-10-16 10:14:43 +08:00
ThearchyHelios	845809486a	驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段 ... 为什么：动作确认、工具 / 代码审批、审批驳回即终止、填写 / 编辑被驳回、双盲裁决的驳回以前抛普通 NodeError，运行记成 failed。 通知推「实例失败」，定时推「运行失败」，发布单把驳回过的试运行说成「试运行失败了」并挡住发布，记录页还给「继续运行」 （接着跑只会读到同一个驳回答复、再停一次）。人的决定被说成故障，每个消费方各写一份映射，已经漏了四处（05-已知遗留 (a)、总方案 X9）。 做了什么： - engine/context 新增 NodeRejected(NodeError)，带 node_id、kind、decision（reject / expired_reject）、actor、note；六处驳回改抛它， 原话一字不变。待办超时驳回的答复带 expired，Decision.expired 据此记成 expired_reject。 - runner._drive 在通用 except 之前单独接住：status=cancelled、end_reason=rejected、error 写原话、error_node 写那一步， run.cancelled 带 reason/node_id/label/kind/decision/actor/note；关审批、回收沙箱、关流、封存走取消的那一套。手动停止 （执行中取消、放弃断点上的运行）写 end_reason=stopped，run.cancelled 带 reason=stopped。 - 继续运行：被驳回的 409 code=run_rejected「被驳回的运行不能接着跑：改好内容后重新发起」；存量 failed+驳回（失败那一步上 最近一条处理完的待办是驳回，和实例页同一份判断 resolve.legacy_rejected）也拒。RunOut 带 end_reason。 - apps/resolve.instance_state：cancelled+rejected 和存量 failed+驳回说同一句（「「付款」未确认（被驳回）」「「x」被驳回」）。 - notify_run：状态那一句取自 instance_state，被驳回的走「实例结束」、ok=False，走到「已退回」成果的不再写「已完成」； 手动停止照旧不推。顺带修 04-对外集成与触达 B1：发起人是认证身份（run.origin.actor_verified）时 users 传 [started_by]， 个人渠道订阅了实例完成 / 失败终于收得到；自报署名不算。 - 定时 webhook：cancelled+rejected 按「运行结束」推「未出具（被驳回）」、写驳回的那一步，不写备注和原话、不画成功色； 手动停止仍不推。 - 发布单：试运行被驳回不算 plan.trial_failed，记 warning plan.trial_rejected「最近一次试运行在「x」被驳回、没有走完」（带白话）。 - (h) 重启时排队中的运行改成 failed 时补发 run.failed（同一句原因），时间线里有了失败原因这一行；不写结束时间、不封存，同以前。 - (f) tasks.tick / actions.tick 交回这一拍处理过的 id 列表（调度循环只记条数），测试改成只断言自己造的待办；先加了预置 一条无关到期待办的 fixture，旧的按条数断言当场失败（3 == 1），改完通过。 已封存的老运行不改写。测试：新增 test_run_rejected（五种关卡参数化、超时驳回、继续运行拒绝含存量、手动停止、补发 run.failed、 instance_state 新老形状同一句）、test_notify_run（驳回走实例结束、手动停止不推、已退回不写已完成、个人渠道 B1 两条）； webhook、发布单、动作确认、双盲、审批的老断言跟上。去掉 runner 里接 NodeRejected 的分支回跑，新测试 8 条失败。	2026-10-16 10:14:27 +08:00