ThearchyHelios
|
d4e68bd1a9
|
合入 W4-d 目录前端:数据目录的「变化」视图与处理动作、数据源角标、表详情「结构与取值变化」一节、数据源的定时维护(一条目标为数据源的定时任务)、后台任务条(探查、起草、剖析按服务端排队顺序);打开 source.changed 订阅;指名数据源卡片统一用 #source-<id>
|
2026-10-16 22:30:09 +08:00 |
|
ThearchyHelios
|
d17a08bafb
|
合入 W4-c 账本前端:证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询;被驳回的那一步 node.failed 带 reason=rejected,画布、航迹、时间线、问数据过程都画「被驳回」
|
2026-10-16 22:29:02 +08:00 |
|
ThearchyHelios
|
13bd021219
|
合入 W4-b 评测前端:顶级导航「评测」(搭建者以上、⌥0)、题集与四种加题、发起评测与预估花费、评测详情与逐题结果、对比与 A/B、口径命中与重复度、目录快照;定时页选目标种类、认得数据源维护的触发记录;记录页的评测来源;设置里的评测一组;问数据建图用量不再是下限(读完模型的流再关);问题聚类的向量只取一次
|
2026-10-16 22:28:35 +08:00 |
|
ThearchyHelios
|
1195c4abcb
|
账本前端补两样:答案身上的召回标记写到问数据的轮次和证据面板「口径」一步;对账结果卡上问「说明有用 / 看不懂」
复核 W4R-03(a×c):召回在原答案的运行上追加 ledger.recalled、ledger.basis_changed,以前只在运行时间线(decode)里,问数据的
轮次底部、证据面板「口径」一步、账本接口都不带——使用者被标了「依据有变」、或者口径升版后「已按 v2 核对,不影响」,重开对话
什么也看不到,得点开「过程」才翻得出来,而使用者进不了记录页。W4-a 已在账本接口加上 recall(ledger/recall.answer_marks:
checked / basis / tasks,几种 state 都带),这边照它画:
- typesLedger:RunLedger.recall(LedgerRecallMarks)
- run/LedgerStep 新增 RecallMarks(问数据的轮次和「口径」一步共用):「已按口径「X」vN 核对,不影响」(同一份口径核对过
几次只写最近那一版,数变了的不在这里写);依据有变按两类各一行——数据目录(catalog / values / catalog_edit)和表结构
(structure),认不出的种类只说「答案的依据有变」不猜,项数相加,按新目录新出现错误级问题的写几条;看的人手上有说的是
这个答案的召回待办时写一句(口径升到 vN、数变了 / 依据有变检查出新问题)并链到 /apps/inbox/{待办}
- LedgerTurn:比对过的卡里写在摘要下面;没比对、不比对的答案(state 不是 matched)只要带着标记就单独写一张小卡
- LedgerPart(证据面板「口径」一步):有标签的写在脚注前;没标签但答案带着标记的,这一步只写标记
复核 W4R-10(多包):细案 02 做法 10 的 E2「说明有用 / 看不懂」以前没有入口。W4-a 已加 POST /ledger/answers/{run}/reconcile/
{对账运行}/feedback({verdict: useful | unclear},记成对账运行上的封存后事件、统计 E2 数它),账本接口的 reconciled 每一项
带 feedback {mine, useful, unclear}。这边:
- api.caliberLedger.feedback;typesLedger 加 LedgerFeedback、LedgerFeedbackOut
- run/LedgerReconcile 的对账卡:做完的卡问一句「「差在哪」的说明有帮助吗?」,两个按钮,看的人选过的按下(aria-pressed),
写各几个人(服务端给的数),可以改主意;交回来的反馈先画上,账本再取一次让别处挂着的同一张卡跟着变;回收站里只看不反馈;
没做完的卡不问
- 问数据的轮次里卡片上方没有「差在哪」,卡里补写一份(showWhere),反馈问的就是它;证据面板里它本来就在卡片上方,不重复
检查(写请求都在浏览器层拦下):
- check-evidence 新一段 ledger-recall:比对过的答案「口径」一步写核对过(只写最近那一版)、依据有变(项数相加、新问题条数)、
链到待办;不比对的答案这一步只写依据有变
- check-chat 新一段 recall:轮次底部同上,另核对做完的对账卡写「差在哪」和反馈人数;不比对的答案单独一张小卡写表结构有变
- check-ledger 对账一段:没做完不问;点「看不懂」请求体只有 verdict、按下、写各几个人;改点「说明有用」再记一条、按下的换过来
- 共用夹具 ledger-fixtures 加 RECALL
把这几个文件的改动拿掉回跑:check-chat recall 6 项、check-evidence ledger-recall 4 项、check-ledger 对账反馈 2 项都不过;
放回去全过
|
2026-10-16 22:21:11 +08:00 |
|
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
|
35583ba1d8
|
口径召回前端(W4-a):版本用量加问数回答和召回、发布弹窗预告召回规模、版本历史看召回批次、recall 待办卡、时间线认两个新事件
为什么:前三波召回只有接口;这一波收口,口径升版之后谁的答案受影响、重算了几组、数变没变、怎么处置都要在界面上走得通。
- canvas/versionUsage:使用情况那一行加问数回答、导出、定时任务、召回(老服务端不给就不写)
- canvas/RecallPanel(新):发布弹窗「召回」一行——旧版本被谁用过、按参数去重几组、发布后自动重算几组、超出上限几组(可在
版本历史接着算)、上限为 0 时只列不算、不能重算的原因;版本历史展开一版——每组结论(数变了 / 没变 / 无法重算:原因 /
重算失败 / 正在重算 / 未重算)、变了的指标、开了几条待办、召回运行链接,「另有 M 组未重算」+ 接着算
- run/RecallTask(新)+ TaskCard:recall 待办卡——旧口径、新口径、两版之差一行一个指标,每个数点得开召回卡的指标链;每个答案
当时的值点得开(正式运行的口径卡、问数回答的查询快照),问数回答链回对话;「按新版重新出具」(不能时停用并写服务端给的
原因)、「知道了」;遮罩值写已遮罩、点不开;目录有变、表结构变了两种只有「知道了」
- run/decode:ledger.recalled(已按 vN 核对,不影响;召回核对数变没变;试算结果)、ledger.basis_changed(依据有变、依据的
表结构已变);缺字段不猜
- 文案进 lib/termsRecall.ts;接口 api/recall.ts、形状 typesRecall.ts;TaskKind 加 recall
- 检查:check-inbox 加 recall 卡两段,check-publish 加召回预告和召回批次两段(版本历史、发布弹窗都在这里测;check-versions
测的是上传表格的版本页,和召回无关),check-decode 加两个新事件的夹具,check-capabilities 的可订阅事件跟上 ledger.recall
|
2026-10-16 20:05:24 +08:00 |
|
ThearchyHelios
|
b24aabefcf
|
账本前端:证据「口径」一步、数字上的小标记、问数据轮次摘要与出具 / 对账、可沉淀的问题、设置里的口径账本一组
第 2、3 波只有接口,这一波接上界面(docs/design/next-round/02-口径账本.md 做法 3–6、8 的界面、做法 11;总方案 X3、X10)。
界面层不放逻辑:标签、整题判断、能不能出具、能不能自动、不能的原因、要不要先核对参数都照 GET /api/runs/{id}/ledger 给的画。
- 比对结果不靠实时流(第 2 波遗留):ledger.matched 在封存之后追加、事件总线已经关了,打开着的页面收不到。store/ledger
按退避轮询(1、2、3、5、8、13 秒,之后每 15 秒),服务端答 pending 时写「正在比对口径」,等满 2 分钟还没结论照实说、
给「再取一次」;要自动出具的再等出具的那一次出现,出具、对账的运行没结束的等它们结束。只在有组件看着时轮询,同一次
运行的正文、面板、轮次摘要共用一份
- 证据正文(EvidenceDoc):来自口径的数字后面挂一个小标记,写明受管 / 已发布,悬停写是哪一份口径、怎么认的;相关口径的
数不加标记
- 证据面板出处链最上面加「口径」一步(run/LedgerStep):来自口径——「X」v3(受管)· 参数 · 等价已证明 / 助手选用 ·
按口径正式出具;相关口径——差在哪 + 看差多少;这次的推理——没有相关的已发布口径;没比对的写原因;脚注写「封存后比对,
不在封存范围内」,事后补比的写按哪种口径回看
- 口径对账(run/LedgerReconcile):核对参数(照动作里的入口字段画,推断的参数要先核对,遮罩值不回填)→ 发起(认不出列
怎么配时照 409 带回的选项选对照的指标)→ 结果卡片:每组按你的问法、按口径、差值(附相对差)各自点得开出处链
(apps/EvidenceDrawer,同应用页点数)
- 问数据轮次底部(run/LedgerTurn):一行摘要(几个数来自口径「X」vN、几个是这次的推理、几个没有比对)、整题等价时按口径
正式出具(能自动的写正在自动出具;不能的照写原因,使用者没有应用授权写「请搭建者出具」)、有相关口径时对账;出具过的
正式运行挂在下面,档位写完整出具 / 降档出具 / 不予出具,搭建者点开去运行;回收站里的对话只看不发起
- 可沉淀的问题(pages/ledger/CertifyQueue):工作流列表弹窗里的抽屉,确定性重复、问题聚类、被反复用的答案分开写;
「固化成口径草稿」走 /copilot/from-run 的 freeze 并打开画布,聚类没有共同的 SQL、按人挑的那一轮固化;「不是口径」
要写理由
- 设置(pages/settings/LedgerSettings,照 VerifySettings):自动按口径正式出具、每日上限、比对时限、升版后每次最多重算几组,
和其余偏好共用保存条、整组写 ledger
- 类型 typesLedger.ts、接口 api/caliberLedger.ts(挂 api.caliberLedger)、文案 lib/termsLedger.ts;types.ts 的证据片段
答复加 ledger、rendered 两个键
|
2026-10-16 20:02:08 +08:00 |
|
ThearchyHelios
|
aa3bd65cfc
|
W4-d 前端:数据目录页的「变化」视图、表详情「结构与取值变化」一节、后台任务条、数据源的角标和定时维护
第 3 波的结构变化、取值观察、变化记录、定时维护都只有接口,这一提交给它们界面,能走通(收口):
- 数据目录页左栏加第三个视图「变化」(view=changes):按要处理 / 提醒 / 说明分组(组内照服务端排好的先后),能按开着的 /
处理过的、结构变化 / 取值变化筛,筛选和打开的那一条记在地址里;视图标签上写几条要处理。点开一条,右栏写服务端的一句说法、
依据(谁、经什么测到的;取值变化写观察口径,结构变化写比对的两版结构)、前后各是什么、影响面(说到这些列的目录项和它们
现在的状态、写死了这张表的已发布模板、「这条 SQL 现在会报列不存在」、有效记录条件)、能做的处理。动作和做不了的原因都照
服务端给的 actions 画;清理目录项先确认,加入码值可以先填含义,误报必须写理由(写之前按钮不能点,服务端也会拒)。处理完
照实写结果:谁、什么时候、目录第几版、建了的任务(点得进起草、剖析的进度)。
- 表详情加「结构与取值变化」一节:这张表的变化(点「去处理」到「变化」视图里那一条)、撤销过的「已列全」、最近几次取值观察
(行数、码值分布、最新业务日期、按日行数)和各自的口径,口径换过的说一句不互相比较;按日行数的小柱图只给眼睛看,数字写在
字里和读屏名称里。
- 后台任务条(05 (g)):页头的「起草」「数据剖析」改回纯入口(进行中转圈、排队中时钟,读屏名称写状态、不写数字);DraftStrip
换成 JobStrip,按服务端给的同源队先后列出探查、起草、剖析,每项一行加进度条和提醒(剖析的「最近查询多数超时」也挪到这里,
窄屏、触屏看得见全文),「查看」打开对应的对话框,探查的到数据源卡片上(#source-<id> 滚过去)。
- 数据源卡片:要处理的变化条数的角标(读屏写全,点开到「变化」视图);「定时维护」对话框(和「探查范围」一样是卡片上的
独立对话框,不塞进编辑表单:两个保存混在一起出错时说不清哪一样没存上):开关缺省关、开启时提示选低峰时段,选步骤(PUT
/maintenance),频率用 components/FreqPicker,保存成一条 target_kind=source_maintenance 的定时任务(新建 ScheduleTargetCreate,
改频率、开关 SchedulePatch 带版本);照实写下一次什么时候、最近一次建了哪些任务、哪几步没执行和原因(触发记录的 inputs),
剖析没开、调度没开时说到点会怎样。上传表格、记录表不给这一节。开着的维护在卡片上带一个标签写频率。
- 地址里带 pjob / djob 时打开那个剖析、起草任务的进度(定时维护的「最近一次」从数据源页链过来)。
新文件:typesSource.ts(接口约定)、api/sourceChanges.ts、lib/termsSource.ts(terms.ts 末尾转出)、pages/catalog/changes.ts、
ChangesQueue.tsx、ChangeDetail.tsx、TableChanges.tsx、JobStrip.tsx、pages/SourceMaintenanceDialog.tsx。变化的叫法和服务端逐字
一致,tests/test_source_change_terms.py 守着(维护步骤的叫法同样)。观察的按日行数服务端补上窗口里没数据的日子(不然小柱图
看不出断档)。
|
2026-10-16 19:46:14 +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
|
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
|
ee8c0317a2
|
合入 W2-d 访问密钥与服务账号:服务账号(管理员建、不能登录)与个人访问密钥(管理员开关,缺省关);只存哈希、必设到期、轮换与撤销;按路由白名单放行、封顶在使用者边界(看到的都遮过);发起入口和刷新视图必须带幂等键;视图数据接口 agentlab.viewdata/1;审计、请求记录、钩子收件记录;接口说明;设置里的访问密钥页
|
2026-10-16 15:38:33 +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
|
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
|
7576fa6ce9
|
前端跟上口径账本内核:时间线认得 ledger.matched;问数据的运行带上属于哪段对话、哪一轮;「在画布里打开」带来源
为什么:这一波合入就进 main,后端新加的封存后事件、来源链要在界面上接得住,不能有订阅了收不到、点了没用的地方
(next-round 02 做法 2、9)。账本的标签、证据面板的「口径」一步、对账在第 4 波接界面,这一波只有接口。
- run/decode.ts:ledger.matched 解读成时间线上一行「比对已发布口径:1 条查询等价已证明,2 条有相关口径」,副标题写明「封存后比对,
不在封存范围内」,事后补比、按需比的另写「按现在的口径回看」;有没比完的标成提醒;不改相位。文案进 lib/terms.ts 的 LEDGER_TEXT
(连同 X10 的叫法:来自口径 / 相关口径 / 这次的推理 / 没有比对,等价已证明 / 助手选用,受管 / 已发布)。
- store/chat.ts:发起运行时带 origin_ref {conversation_id, turn_id}(等开轮请求拿到服务端的轮次 id);服务端核对不过
(origin_ref_invalid:对话刚被删)时不带来源照常发起——来源只是留痕,不挡这一轮的回答。
- pages/ChatPage.tsx:「在画布里打开」带 origin {run_id, conversation_id, turn_id}(这一轮跑过才有);核对不过时不带来源照常新建。
run/AssistantStream.tsx 的 onOpenGraph 多给一个轮次 id(只加参数,别处不受影响)。
- api/client.ts:runs.start 的 origin_ref、workflows.create 的 origin。
- 检查脚本:check-decode 加「口径账本」一节;check-chat 断言发起时带上 origin_ref、「在画布里打开」带上来源;check-report-export
加「口径一步」:没比对过的运行没有这一步,数据块里放一份编的标签断网打开,面板最上面是「口径」、写明封存后比对、遮罩的参数写
「已遮罩」(只打印这一节,不打印真数据)。
验证:tsc、check-copy;check-all --stacks 1 decode chat report-export 全过(1485 项)。
|
2026-10-16 14:15:22 +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
|
696cd17a4a
|
合入 W1-b 已知遗留:人工驳回记成已取消 + end_reason=rejected(不重试、不被出错时继续吞掉),各处照实写「被驳回」;个人渠道「我发起的实例完成 / 失败」生效;导入清单如实记「是否认证」;使用者选人按候选池、开登录时服务端核对;自由形蓝图按导入的图列「谁来做」;tick 按 id 断言
|
2026-10-16 12:51:43 +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
|
fbb671a96b
|
使用者选人(前端):选人控件按池边输入边取候选;个人渠道的实例事件改叫「我发起的实例完成 / 失败」
为什么:使用者读不到名录,选人控件只能凭记忆手填用户名,填错了服务端以前也照收(05-已知遗留 (b))。服务端已按用途给候选池、
开登录时按同一个池核对(上上个提交),前端要把候选给到人手上。另外个人渠道勾「实例完成 / 失败」以前永远收不到,服务端修好之后
(驳回那个提交里的 notify_run),名字要照实写成只推自己发起的实例(04-对外集成与触达 B1)。
做了什么:
- PrincipalPicker 加 source(CandidateSource:form 带 app_id+entry 或 task_id 和 field,review)。搭建者及以上照旧用整份名录;
使用者开了登录、给了 source 时边输入边按开头取候选(250 毫秒防抖),列表里显示显示名、标签悬停给用户名;加的时候按同一个池
问一次服务端,不在池里的当场说「「x」不在可选的人里」(问不到就先收下,提交时由服务端判);池要先输开头才列、列不全时照实提示。
- SchemaForm 按表单用在哪(入口、待办,同上传文件的上下文)给选人控件 source;个人应用提交审核用 purpose=review。
- typesApp:CandidateSource、Candidates、FormField 的 x-principal、FormError 的 principal 码(和服务端 FORM_ERROR_CODES 同序)。
- api.identity.candidates。termsApp 的 PRINCIPAL_TEXT 加三句。
- 设置 → 通知:范围是「仅自己」的渠道,run.finished / run.failed 写「我发起的实例完成 / 失败」(termsApp.NOTIFY_PERSONAL_EVENT_LABEL)。
- 服务端 x-principal 写法不对时的说法改成不带半角冒号接中文的写法(check-copy)。
|
2026-10-16 10:54:30 +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
|
6c728aaacd
|
数据剖析按复核意见修三处:没来得及收尾的表照实说、停止中的说法、展开的进行中一行不跟着查询数重取
- 服务重启的说明不再一律说「做完的项已写进数据目录」(R1 前端这一侧)。目录只在一张表结束时和它的结果一起写:停止、关停
服务时正在剖析的那张来得及收尾,做完的项照常写进去(服务端记部分完成,原因写「已做完的 N 项照常写进了数据目录」);进程
被杀、下次启动时才标中断的那张没来得及收尾,这次的结论一项都没写进去,服务端把它记成已停止、查完的项改记跳过。界面按逐表
的状态认出这样的表(已停止却有开始时刻:正常收尾的表不会是已停止,没开始的表没有开始时刻),服务重启、停止的说明里点名它
「剖析到一半服务就停了,没来得及收尾,这次的结论没有写进目录,保留原来的结论」,有别的表收了尾才说「其余做完的项已写进数据
目录」;逐表一行用服务端给这张表的原话(查完的几项没写进目录),一项都还没查完、原因就是任务那一句时写「没来得及收尾」。
不说「做完的项没写进去」:被杀时它可能一项都还没查完。
- 「正在停止」不再说等正在执行的那条查询结束(R4)。停止时服务端不等这条查询(它在发过的查询里记失败),库那边按单条时限截止
它,收尾写完停止就答;单条时限设得长时,旧说法会让人以为要等满时限。改成「正在执行的那条查询不再等待,由数据库按单条时限
截止;已做完的项照常写进目录…」,和服务端的说法一致;接口、停止逻辑的注释同步改。
- 展开进行中的那一行,只在一项检查开始、结束时重取这张表的完整结果(R5)。服务端只在这两个时刻写检查清单、正在做哪一项和发过
的查询,其间每发一条查询只加查询数和用时;以前重取的依据带着查询数,进行中几乎每次轮询(1.5 秒)都多取一份没变的结果,
一张 40 条查询的表约多 40 次。依据改成状态、结束的项数和正在做哪一项。
检查脚本 check-catalog-profile:伪造的停止照服务端分「来得及收尾」(正在剖析的那张记部分完成、原因写做完的已写进目录)和
「没来得及收尾」(记已停止、查完的项改记跳过、说法照服务端)两种;停止那一节跟着改(正在剖析的那张是部分完成,汇总
「完成 1,部分完成 1,已停止 3」),「正在停止」的说法改查新句子;服务重启一节加关停时收了尾、进程被杀(查完一项、一项都
没查完)三种;表详情一节加剖析到一半进程被杀;进行中一节加一条:展开进行中的一行后只多发查询时不再请求 tasks/{seq},一项
结束、换下一项时重取一次。先在改动前的代码上跑过,这几条照复核说的那样不通过(展开后多取了 2~3 次、停止中还是旧说法、
服务重启一律说已写进),改完通过。
|
2026-10-15 19:18:17 +08:00 |
|
ThearchyHelios
|
03a9684a18
|
数据剖析前端改成逐表的后台任务:对话框看得到每张表的进度,可以停止、重试没做完的表
以前剖析是一次同步长请求,进行中只有一条已用时长的横条、停不下来,关掉页面报告就没了;预算按整次剖析算,几十张表
往往只做完前两三张。服务端改成逐表的后台任务(profile-jobs)后,界面照起草任务的做法重做:
- types、api:按接口约定加剖析任务、逐表行、逐表详情(检查清单、发现、发过的查询)、清单行上的最近一次剖析和
profile_due / profile_checks、目录顶上的 active_profile_job,起草任务加 waiting_for;删掉同步接口 profile() 和只给它用的
类型;设置换成每张表最多查询数、每张表时长上限两项新键
- profileJob.ts(新):useProfileJob,进行中每 1.5 秒取一次,状态只往前走,关掉对话框照常进行,结束时右下角提示
- ProfileDialog 重做:开始前四种范围和个数、按表写的预算和这次最多约几条查询、只读一条一条发可随时停止的说明,同源有
起草任务时「排队剖析」;进行中逐表一行(状态、各类检查进度、查询数、用时、正在做哪一项),点开看检查清单、发现和发过的
查询;结束后汇总、止损和停止的原因照实写、按有发现 / 有跳过 / 失败筛、重试没做完的表;409 六种情况各有说法和下一步
- 目录页头部起草、剖析各一个进度入口;表清单加「剖析」一格和「需要剖析」开关(地址里记 profile=due);表详情加
「数据剖析」一节和「剖析这张表」
- 起草排在剖析后面时写「排在剖析任务后面,剖析结束后自动开始」
- 文案:去掉「剖析无法中途停止」「总时长上限」等已不成立的说法,补上新的跳过原因和任务状态的叫法
|
2026-10-15 18:14:14 +08:00 |
|
ThearchyHelios
|
7739340607
|
普通用户建应用集成收尾:
- 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点,只读和遮罩在这条路径上生效;被治理成写入的工具在只读运行里直接拒;知识库范围在工具层固定(图级默认值、参数名纠错、Agent 都改不了)
- 个人应用的刷新和个人蓝图的试运行只有拥有者能读:运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧;个人蓝图的试运行不论谁发起都按个人应用约束
- 共享蓝图只给拥有者、对应应用的管理者、管理员,看不到的一律 404;审核副本归审核人;管理员看别人的个人应用只有元数据、可以归档
- 记录表跨版本汇总(只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位,缺的版本照实写进印章);停用前发起的运行可以继续写旧版本;更正沿用原提交人、更正人记审计
- 约定收口:待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置;前端类型一次补齐、去掉临时的局部类型;审核待办卡不再给打不开的链接;读附件事件有中文说法;检查脚本补断言
|
2026-10-15 13:55:19 +08:00 |
|
ThearchyHelios
|
a702a5c14b
|
普通用户建应用(前端):新建应用的三个起点(说需求、场景模板、从已有的开始);蓝图页(对话加卡片、反问选项、关节逐组进度、试运行、发布摘要按你来定 / 助手可以修 / 要找管理员分栏、逐步打勾、接着做);问数据「做成应用」改走蓝图;问数据和画布的反问收尾;页面上直接改(选中、改字、隐藏、挪动、删除、加数据卡片、自动存草稿);文件控件;我的记录列表;个人应用的界面(我的应用、刷新与剩余次数、提交审核、审核待办卡);设置页的个人应用开关;四个新检查脚本并加进完整关口
|
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
|
941723b17c
|
端到端验收修复与指标出具:
- 身份与工具:登录页建第一个管理员(认人接口的 401 说明能不能建);搭建者有只读的人和组名录,选人给候选并核对名字;授权三行带标题;端点请求头名校验(空名、非法名存不进、发不出时说清原因);写入能力在工具页试运行一律演练、不发送,HTTP 状态照实说成败;写记忆不算只读、查询能力只能选同一端点上的只读能力;审批与遮罩的说法和实际规则一致;开登录时不要署名、导入和发布记登录的人;使用者不显示推演等只给搭建者的操作,403 按是否开登录说话;登录页只认一次人
- 流程与实例:图里用到的岗位(派给谁、超时升级给谁、发送确认派给谁)全部派生、没绑人的发布时报错;写外部系统的参数按能力声明的类型收拢后再算哈希和发送,收不成就不发;发起人的实例页只看这一步的状态,处理人才给待办卡;会签进度带登录核实和时间,升级后照实写规则;实例状态写流程的结论(已退回、未确认、等待核实写入结果),核实生效后不再挂失败原因;流程应用首页不派生最近封存运行的结果块,看板没数据时是安静的空态;样例⑩的金额带类型和下限、待办标题带金额,表单上下限前后端一起生效
- 看板与证据:定时任务模板加 ISO 周、上一 ISO 周、本月、上月;出处链穿过原样解析查询结果的整形节点,追不到原始数据的照实说停在哪里,样例⑨改用 cell();应用首页和版本历史都能做成应用;指标块单位不重复;版本列表带退役说明;定时任务页头跟着刷新;删视图要确认、新视图能起名;编辑器属性用中文名、术语带解释
- 指标出具(用户 2026-10-15 拍板):契约只写「指标来自」、上游没有报告撰写节点、成果里没有模型写的话时按指标出具——必需指标齐、指标输入追到原始数据、成果字段里的数回指得上才完整出具;受管级要求每个指标静态地追到原始数据(governed.metric_untraced);出具横幅和应用印章写明按指标
- 受管工作流降为已发布只给管理员(Q8 顺延,服务端同样拦);工作流接口带当前发布版的级别,画布上改过之后也认得出受管工作流
|
2026-10-15 07:15:37 +08:00 |
|
ThearchyHelios
|
bff3062a97
|
集成收尾:前端约定写入后端实际返回的形状(应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅),去掉多种字段名都认的兼容解析;钩子按(应用, 名字)、应用助手对话按(应用, 建立人)加唯一索引,迁移前去重,插入改在保存点里、撞上就改用已有的那一行;口径卡固定的版本也须已发布且未退役,记级别之前有正式运行凭据的老版本启动时补记为已发布;证据面板和应用视图按列名遮端点快照(同一个函数),不再整张表遮掉;待办计数带上最新一条的时间,新待办通知不再漏;非管理员的搭建者不出模型接入的改动按钮
|
2026-10-14 22:08:33 +08:00 |
|
ThearchyHelios
|
1dd4f93579
|
应用平台集成(前端):钩子按名字管理并只显示一次密钥、按新口径补算、应用助手对话历史、设置页按角色收起与身份设置补管理员用户名、按需视图每日上限、界面偏好按角色只存本地、使用者问数据用数据源名单并在运行流连不上时改轮询、能力字段待审阅、记录页按来源筛选与待办 id、编辑器的入口 / 表单 / 待办外观 JSON 分区、画布 ?publish=1、工具页绑定端点与 MCP 认证头掩码编辑、派给自己的新待办系统通知、样例与检查脚本改走待办接口(含统一复核后的修复)
|
2026-10-14 21:55:51 +08:00 |
|
ThearchyHelios
|
e341beb1cb
|
应用平台 FE-6 搭建面:应用编辑器(固定版本、派生、页面树与属性面板、预览、检查、发布时选处置、岗位与授权、钩子、通知、助手面板),人工节点新字段与写入动作说明,发布弹窗与版本页的退役和使用情况,记录页的来源、待办与动作事件、生效记录,发起表单换成表单渲染器并带来源,问数据「做成应用」,look 的界面与 meta.looks,工具页的能力与端点,设置页的身份、通知、审计;检查脚本的更新与新增(含统一复核后的修复)
|
2026-10-14 20:05:23 +08:00 |
|
ThearchyHelios
|
22021e76c3
|
应用平台 FE-5 使用面:表单渲染器与子集校验、待办卡(会签进度、动作确认哈希卡、核实选项)、视图渲染与组件目录 v1 的渲染器(印章、指标点开出处、趋势与图表、表格、报告)、应用首页 / 应用页 / 发起 / 实例 / 待办 / 登录页、导航加「应用」与徽标按来源分开、按角色收起导航、401 跳登录与请求头;新检查脚本 check-apps、check-inbox、check-auth(含统一复核后的修复)
|
2026-10-14 20:05:23 +08:00 |
|
ThearchyHelios
|
c38c0043a4
|
契约骨架补充:运行路径上的能力登记函数给出和今天一致的默认实现(并行开发互不卡住),build_tools 加 allow_write 参数;前端补 ViewRenderer、PrincipalPicker 的接口桩和按草稿预览的参数
|
2026-10-14 17:56:54 +08:00 |
|
ThearchyHelios
|
220fd0e365
|
应用平台契约骨架:新表(身份、能力与端点、应用、待办与生效记录、通知)与迁移(补列、多列索引),运行来源与新事件类型,「人」的唯一入口 api/deps.py(关登录时行为不变),应用描述与表单的形状、受信组件目录 v1,各包跨包函数的签名桩,新路由登记,发布门禁的扩展钩子 EXTRA_LINTS;前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页
|
2026-10-14 17:53:40 +08:00 |
|
ThearchyHelios
|
a9ffbcfa86
|
数据目录闭环(前端):类型、接口、文案和纯函数——起草任务的逐段落盘、块进度字段和清单的 blank_columns_from;审阅队列、成批审阅、审阅进度、用过这张表的运行;导出导入(下载文件、预览、导入);表助手的事件流(按行读 data: <JSON>,开流前被拒带状态码和机读码,能停止);表助手的对话怎么截(最多 40 条、每条 4000 字、从用户的话开始)、待保存的修改怎么累积(同一路径以最后一次提案为准、保存带最早那条提案的版本、409 后按预览重算);审阅视图的地址参数、成批结果和表详情改过之后的状态同步;文案进 lib/terms.ts
|
2026-10-14 08:44:14 +08:00 |
|
ThearchyHelios
|
f57c6e284b
|
数据目录起草的几处说法照服务端的实际做法改:点停止后写「正在停止:取消进行中的模型调用,正在写入目录的表写完后停止…」(服务端马上停掉进行中的调用、只等手上那张表写完,不是等当前这次调用结束);任务整体出错时原因照服务端的原话在「起草失败」下面写一次(服务端的原因有的自带「起草任务出错:」开头,界面不再套一层),服务端给没结束的表记的同一句不再逐表重复(服务重启中断同样),各有原因的照写;「只重试失败的表」没建成和开始时同一个说法——起草模型用不了(服务端重试也回 409 catalog_draft_model_unavailable)照原样写那句话、长句不再拆成「标题:原因」,别的写「未能开始起草」;提示里原因为空时不留冒号。check-catalog 先补会失败的检查:停止的说法、重试时起草模型用不了、任务整体出错(原因只写一次、逐表不重复、都能重试),服务重启中断的逐表不再重复原因;假服务端的中断任务照后端记上同一句原因
|
2026-10-13 16:34:29 +08:00 |
|
ThearchyHelios
|
90a560d07e
|
数据目录起草改成后台任务(前端):对话框选范围、写起草要求和本次补充说明后建任务,之后显示任务的进度和结果——总进度、新增 / 更新 / 删除合计、逐表状态、宽表的段进度、没写全的原因;可以停止、在后台继续,关掉对话框任务照常进行,目录页上方显示一条进度,点开回到对话框,结束时提示并可查看结果;结果里只列没写全的表,「只重试失败的表」新建只含失败、部分完成、已停止的表的任务;服务重启中断的任务写明原因、同样能重试;已有任务(409)转去显示进行中的那一个,起草模型用不了(409)留在设置阶段写明原因;起草要求改过先存再建任务,写明用的是哪个起草模型、数据源说明也一并交给模型;清单上标出上次起草失败、部分完成的表并写原因,表详情里给「重新起草这张表」;进行中每 1.5 秒取一次,取回的状态只往前走。check-catalog 用假的任务接口覆盖这些(任务怎么往前走由检查自己推),旧的同步起草检查换掉
|
2026-10-13 15:24:57 +08:00 |
|
ThearchyHelios
|
265ba0c91d
|
报告导出为自包含 HTML(数字点得开口径、来源、计算方式);可验证报告的数字详情补齐口径卡一节
两件事,一条心:把「网页上点数字看得到的效果」带出系统外。
① 报告导出:新增 GET /api/runs/{run_id}/report.html(app/report_export:build + 模板 + 浏览器端脚本)。
正文由服务端按报告文档的块、句、片段渲染成 HTML——不执行脚本也读得到整份报告(附件预览常常不执行脚本);
执行脚本后,带出处的数字、无证据的数字、可疑的表名字段名都点得开,面板是网页上证据面板同一个拼法的
出处链(api/evidence._chain):指标步骤带口径卡名与版本、原式、代入式、每个输入取自哪次查询的哪一格、
复算、双盲复算;查询步骤带 SQL 和被引用的行;数据源遮罩列照网页上的规矩写「已遮罩」。封存状态逐项标明;
没封存的运行照常导出(和网页上读报告一个道理)。同样的引用共用一条链,长报告不把整份快照抄几十遍。
入口在问数据答案和运行详情成果上的「导出」(带证据的报告给 HTML,Markdown 留一个小的;旧运行照旧只有
Markdown)——api.reportExport + AssistantStream 的 AnswerActions。
② 可验证报告(bundle)的数字详情补齐:点开数字原来只有出处和值,现在多一节口径卡——指标(名 + id)、
单位、原式、代入式、输入(取值 ← 路径、取自哪次查询的哪一行哪一列)、复算;输入指向的查询快照也随文件
附带(遮罩规则同嵌入那一套,build._card_input_queries),④ 引用链按「已核对的口径卡的输入」认它们
(哈希对不上的卡不认,免得替被改过的卡圆)。收件人不连服务也能看到每个数怎么算出来的。
测试:后端 tests/test_report_export.py(真跑运行导出,正文、出处链、遮罩、只读、404/409、共用链);
bundle_samples 的口径卡换成带原式/代入式/输入/复算的真实形状,另加 metric-only 样本页(只引用指标的
报告,快照从口径卡的输入这一条路附带);check-bundle 断言数字详情和这条引用链,加上篡改;新增
scripts/check-report-export.mjs(真导出断网点开、不执行脚本也读得到、成果上的导出按钮、旧答案没有
HTML 按钮、409 提示),挂进 check-all。README 补「导出两份」一节。全量 pytest 通过;check-bundle、
check-report-export、check-stream、check-evidence、check-chat 全部通过(check-runs 5 项失败为基线
上就有的沙箱数据形态问题,与本次无关)。
|
2026-10-10 12:59:21 +08:00 |
|
ThearchyHelios
|
b4edcadc88
|
合入期 5 前置修复 L3:记录页的工件列表把双盲复算对照、反方审稿记录、质询回答归到「核查记录」一组,窄屏下说明换到第二行、序号不被截掉;运行对比的默认基准接口带上 previous,运行详情的对比入口在基准不是紧挨着的上一次时写明「与上一次成功的运行对比」,和触发历史一致
|
2026-10-06 22:19:25 +08:00 |
|
ThearchyHelios
|
db84e576c0
|
模型接入报错收尾(第 1 轮复核,前端):反方审稿的模型一栏不再多出一句相反的说明;检查器读工作流默认设置里的模型;助手栏保存失败时退回原样并说明、「当前」只写在跟随默认上、原因的去向写「上方」;接入「启用」的说明另起一行;落到演示模型的修复候选加醒目标签
- 检查器:模型一栏的留空说明(modelDefault)只用于节点定义里的模型栏。反方审稿的「反方模型」自己画、只读节点自己的
配置、留空跟随设置,以前全图默认点名了接入时也被套上「留空则使用接入「X」的默认模型」,和它自己的说明相反;工作流
默认设置写了模型时,空选项和说明写「使用工作流默认设置的模型「X」」(后端执行时取的就是它,也不报「没有指定模型」),
不再说成某个接入的默认模型;
- 助手栏「助手使用的模型」:重新选择时保存失败,下拉、原因、齿轮上的红点退回选之前的样子(服务端存着的没变),下面写
「保存失败,助手使用的模型未更改」,收起再展开后不再留着;只认最后一次选择的回包;选了具体模型时「跟随默认」不写
「当前」(那时服务端给的 effective_model 是选的那个模型);下拉下面的原因用服务端的 panel_error;
- 设置页接入编辑框:停用的后果另起一行写在复选框下面(aria-describedby 接上,读屏名只是「启用」),不再和「启用」并排
放在 label 里把它挤成上下两个字;说法收紧为「停用后,该接入的模型不再出现在下拉列表中,指定它或其模型的节点和设置也
无法调用」——调不了以后怎样(报错、转人工审批、记未裁判、记缺口)由各组自己那句说,不笼统写「运行时报错」;
- 发布前检查:候选带 demo 标记时,选项名旁加提醒色的「演示模型」标签,说明里那半句照旧(normalizeFix 留下这个标记)。
types.ts 的 PublishFix 选项加可选的 demo 字段。
检查:check-studio 那一节加反方审稿不套说明(全图默认点名接入、写了模型两种)、工作流默认设置带模型时的空选项和说明、
保存失败退回原样与收起再展开、选具体模型不写「当前」、原因写「上方」;check-manage 量「启用」只占一行(1440、390)、
说明不在 label 里、读屏名只是「启用」、说明在弹窗里;check-publish 的伪造门禁跟上「无法改用其他接入:」与 demo 标记,
加一节演示标签(两个候选各一个、提醒色而非淡色、和选项名同一行、390 宽在弹窗里)。新加的检查项对着改动前的界面跑过,
都会不通过。
|
2026-10-06 19:43:44 +08:00 |
|
ThearchyHelios
|
c8800d75e3
|
模型接入报错的说法与修复候选收尾(前端):助手栏照实显示存着的模型设定、能重新选「跟随默认」清掉失效的接入;检查器模型一栏说清留空用哪个接入;停用接入的后果写全;问题只认自己那一处的修复
- 助手栏「助手使用的模型」:读 GET /api/copilot/model 的 error,照实写在下拉下面,齿轮上加红点(收着时也看得出来)。存着的
设定下拉里列不出来(点名了接入,或模型不在可选列表中)时列成一项并选中,不再停在「跟随默认」——以前看着一切正常、
发出一句话才报错,而且再选「跟随默认」不算改动、清不掉存着的接入,报错又指到改不了它的设置页。这时发出的请求不带
模型,服务端按存着的整组取,和下拉上显示的一致;
- 检查器模型一栏:节点(没写就是全图默认)点名了接入时,空选项和说明写「使用接入「X」的默认模型」;X 不存在、已停用时
空选项说状态、不写说明,不再和检查器顶上接入那条问题矛盾(同后端去掉「没有指定模型」那一条);
- 设置页:接入编辑框「启用」旁、卡片上「已停用」的悬停说明写全停用的后果(指定它或它的模型的节点和设置运行时报错),
不只说下拉里看不到;门控、裁判、核查三格存着的接入名恰好是某个启用接入的模型时,补一句在这一组哪一栏用它,和服务端
保存时 422 的那句一致;
- 发布前检查:点名的模型接入只认节点、字段都对得上的修复,没有就是这一处没有修复,不再退到同节点、同编号别处的修复
(同后端 annotate)——以前给不出修复的那一行下面会画着另一处的选项;
- 说法收进 terms.ts(PROVIDER_REF_TEXT、ASSISTANT_MODEL_TEXT),getModel / setModel 的返回补上类型(CopilotModel)。
检查:check-studio 加一节(检查器空选项与说明、助手栏的错误与重新选择、发出的请求不带模型、390 宽不多撑出横向溢出),
check-manage 加一节(停用后果、接入名恰好是模型名)并跟上 422 的新说法,check-publish 的伪造门禁照后端「没有修复时
不指到发布前检查」,加一节给不出修复的那一行不借同节点别处的修复。
|
2026-10-06 17:51:26 +08:00 |
|
ThearchyHelios
|
6514db6118
|
运行详情「更多」里的对比入口按默认基准是不是紧挨着的上一次定叫法:上一次失败、取消、还没结束时写「与上一次成功的运行对比」,和定时任务触发历史里的同名链接一字不差、点进去是同一个基准
拿到能对比的运行(已封存、属于已保存的工作流、不在运行中)就预先问一次 compare/base,按答复里的 previous 定叫法;按运行 id 加清单哈希记,失败后接着运行完重新封存了会再问。问到之前这一项只写「正在查找上一次成功的运行…」、不给点:菜单开着时不会先写一个叫法、问到了再换成另一个,也点不到说错了的入口。预先问出错、找不到默认基准都不提示,叫法退回「与上一次对比」,点了照常再问一次、照实说。点了总是再问一次、按那一次的答复跳:详情页可能开了很久,预先问到的基准不一定还是现在的。
类型 RunCompareBase 加 previous(老服务端不给,按 true 算,同 ScheduleFireCompare);两种叫法放在 RUN_COMPARE_TEXT(menu、menuLastOk),SCHEDULE_TEXT 的 compareLinkLastOk 和 compareLink 一样改成取它的 getter,过时的说明一并改掉。check-compare:夹具里本次的默认基准带 previous: false(和触发历史那一行同一个假定);上一次失败了、上一次就是成功的两种,运行详情和触发历史两个入口叫法一致、打开同一对运行;预先问的那一次压住时菜单项只写正在查找、问到后直接是最终叫法(记下菜单开着时出现过的每一种状态核对);预先问出错、找不到基准时不提示、点了照常再问;点了之后对比页不再自己找一遍
|
2026-10-06 16:52:30 +08:00 |
|
ThearchyHelios
|
23cdc986fc
|
审批质询(前端)第一步:质询的类型与接口、时间线解读 approval.inquiry
- types.ts 末尾按前后端约定加 Inquiry、InquiryRequest/Response、查询与快照的类型,字段名一个不改
- api/inquiry.ts:提问(POST,不设超时,服务端自有时长上限)、列出问答、取质询引用过的查询快照(外层包不包一层都交给界面认)
- decode.ts:approval.inquiry 不再落进「未识别的事件」,解读成顶层一行「审批人质询」:标题带问题前 40 字,副标题说回答完成 / 不完整(写明哪个上限)/ 未能回答、查了几次,封存之后问的写明封存后追加;缺字段、类型不对的照实少说,不拿 0 顶查询次数
- check-decode 断言上述说法与缺字段的兜底;check-trace 加「运行停在审批时来了一条质询,相位仍是等待」:等待段不被收掉、执行时长不涨、恢复后照常跑完、每个前缀上 trace 与 decodePhase 一致
|
2026-10-05 18:46:03 +08:00 |
|
ThearchyHelios
|
8ed74bbe97
|
合入期 2 变化三分法(前端):运行对比页(摘要、指标表、效应拆分、维度归因、查询与模板差异),运行详情加「与上一次对比」
# Conflicts:
# frontend/src/types.ts
# scripts/check-all.mjs
|
2026-10-05 12:50:04 +08:00 |
|
ThearchyHelios
|
4deffd62f7
|
定时任务前端底座:接口约定的类型、api.schedules、页面用的纯函数和文案
types.ts 末尾一段写定时任务的接口约定(Schedule、Fire、预览、变量、立即运行、触发历史、Webhook 测试),字段名和形状照前后端共用的约定,不各自发挥;运行列表的 schedule_id 用同名接口合并补在这一段,不去改上面 Run 的定义。
api/schedules.ts 挂上全部接口:列表、详情、新建、修改(只带改了的字段和读到的版本)、删除、预览(可取消,丢掉过时的请求)、变量、立即运行、触发历史分页、发送测试消息。
pages/schedules/model.ts 是不碰 React 的纯函数:
- 频率预设和 cron 互转:每天 / 每周(连着三天以上写区间)/ 每月 / 每隔几小时(只给 24 的约数,*/5 在跨天处会断)/ 自定义;填得不完整时返回空串,不拿猜出来的频率顶上;认不出的 cron 一律算自定义、原文照放
- 按定时任务自己的时区写时间(Intl 取各段再拼中文,周几、偏移照算),本机时区另给;距下次运行先取整再判档
- 表单和请求体互转:修改时和打开时的表单比,只交改了的字段(cron 写法不同但人没动不算改);Webhook 按约定地址省略即不改、空串即删除,密钥省略即不改、空串即清除,交 Webhook 时格式和事件总是一起交
- 表单的问题按字段给出,写在对应的输入框下
terms.ts 的 SCHEDULE_TEXT 写全定时任务页的文案;占位页的两条先留着,换成真页面时删掉。「钉钉」是 Webhook 的产品名,会被「钉住」那条规则误报,在 copy-allow.json 里登记一条例外并写明理由。
|
2026-10-05 08:56:02 +08:00 |
|
ThearchyHelios
|
e6c77ea4ee
|
运行对比页(前端):两次运行的指标变化按数据、口径、模板与 SQL 拆开讲
- 运行详情「更多」加「与上一次对比」:先问 compare/base 找默认基准再跳到对比页;没封存、还在运行的不给点;
找不到基准时留在原页,提示服务端给的原因,并可去对比页手动选择基准
- 对比页(/runs/compare?target=…&base=…):顶部两次运行(名字、时间、类别与版本、定时来源、未封存标记,可点进
各自详情)、互换、换基准下拉(运行列表接口按工作流取,未封存的列出但不能选);摘要条八类的个数照服务端的
summary,点一类只看这一类;指标表用服务端渲染值,能严格拆分的并列口径效应和数据效应、画两截条形,并写明两者
之和等于总变化,不能拆的写服务端给的原因;展开看变化说明、输入对比、维度归因前 10 项(没有占比时写原因);
查询区标结构状态,只参数变列出字面量,结构变并排两条 SQL 逐词标出各自独有的部分;模板区写版本、变化的节点和
配置项;说明照实列出
- 加载、找基准、409(未封存或封存核对不一致)、422(不是同一工作流)、404、找不到基准、空对比都写清楚;请求按
「本次 + 基准」取,换基准、互换时丢掉过时的答复,开发模式的 StrictMode 下同一份对比也只请求一次
- 窄屏表格在自己的框里横向滚动(指标名一栏钉住,展开的明细按可见宽度排),深浅色下分类标签、差异高亮对比度都
在 4.5 以上
- check-compare.mjs 换成真检查:page.route 假接口覆盖入口、摘要、分类、拆分、归因、SQL 并排、换基准与互换、
过时答复、各类错误、窄屏和深浅色
|
2026-10-05 08:43:32 +08:00 |
|
ThearchyHelios
|
26595b70f7
|
合入期 1 数字推演沙盘:证据面板里改口径卡的输入、排除查询结果的行,即时看指标和报告引用处的新值;推演只读、不写运行记录,醒目标注推演非出具;口径卡的容器型输入此后另存完整值
# Conflicts:
# scripts/check-all.mjs
|
2026-10-05 07:53:42 +08:00 |
|
ThearchyHelios
|
633af950db
|
数字推演复核修正(第 1 轮,界面):整份结果在推演区里勾行,只让用到的行可勾,勾完结果就在手边,加载中和失败后不摆上一次的答复
- 整份结果、数组字段作输入时,输入下面给「勾选要排除的行(共 N 行)」,按页取整份快照来勾:证据链里没有它的查询步骤、
或者查询步骤只给前后 2 行时也勾得全
- 查询步骤里的勾行表格只让这个指标用到的行可勾(row_span),别的行禁用并说明没用到,勾了也不发请求
- 勾行表格底下带推演结果(旧值 → 新值或原因)和「回到推演结果」;勾完、答复回来后各把它带进视野一次(答复回来时上面
的内容会变高,把表格往下挤)
- 推演的请求和答复提到片段那一层,推演区和查询步骤共用一份;答复回来之前随改动变的部分变淡、标为忙,请求失败时结果、
排除标记、报告中会变的地方、下游口径卡都不显示,不拿上一次的答复充数
- 整个指标推演不了(口径卡没记输入)时只说原因,不再同时写「无可推演」和「无变化」,也不画勾选框
- 快照读不出来的输入写「查询快照无法核对,不显示原值」;没有能改的输入、也没有能勾的行时说一句为什么
- check-whatif 补对应检查:整份结果勾行、上下文行不能勾、勾完结果整个在视野里、封存核对未通过、加载中和失败后、整个
指标推演不了、窄屏里的勾行表格;ESTIMATE 按实测改成 28 秒
|
2026-10-05 05:43:17 +08:00 |
|
ThearchyHelios
|
cf038c95f5
|
证据面板加数字推演:指标步骤上「推演」,改输入、勾掉查询结果里的行,看这个数和报告怎么变
- run/WhatIf.tsx:推演区。顶上醒目横幅「推演,非出具:不会写进运行记录,也不会改动报告」,运行未封存另行提示;
旧值 → 新值和变化量(比率、百分数写「个百分点」)、推演代入式、输入(数值可改:停顿 450 毫秒或回车、失焦才提交,
写的不是数提示并保留上次的结果,Esc 退回)、不支持推演的输入和原因、报告中会变的地方(可定位)、可能受影响的
下游口径卡、恢复原值;加载、失败(可重试)、空态都有。新改动来了旧请求直接丢掉,答复按请求体缓存
- EvidencePanel.tsx:MetricPart 挂「推演」开关和推演区;QueryPart 只在推演时把结果窗口换成带勾选框的表(WhatIfRows),
勾掉的行划掉、遮罩列照旧写「已遮罩」。草稿按(运行、报告、口径卡、指标)认,同一个指标的几处引用之间来回切不清空
- 接口 api.whatif.run、推演相关类型(types.ts 末尾独立一段)、WHATIF_TEXT 文案
- 预览用例 ?syn=whatif / whatif-rail 和 check-whatif.mjs(54 项,用 page.route 假接口):请求体、防抖、回车、排除行、
恢复原值、收起、不支持的输入、遮罩列、加载 / 失败 / 未封存、390px 与 360px 右栏不横向溢出、深浅色横幅对比度
|
2026-10-05 04:04:30 +08:00 |
|
ThearchyHelios
|
d85b634f75
|
记录页封存凭证条加「导出可验证报告」:已结束且已封存的运行可下载,不可用时说明原因
- api.bundle.download 取文件和服务端给的文件名(优先 RFC 5987 的 filename*,没有再看 filename),下载照 EvidencePane 的写法
- 按钮只在运行结束且已封存时可用;运行中、等待审批、接着跑(留着旧封存)、没有封存清单时禁用,悬停和读屏都说明原因;
服务端回 409(封存核对不一致等)时提示原因
- 文案进 BUNDLE_TEXT;预览用例 dev/fixtures/bundle.tsx(已封存、运行中、等待审批、未封存、接着跑)给 check-bundle 用
|
2026-10-05 03:58:13 +08:00 |
|
ThearchyHelios
|
90dac0992b
|
复核套件骨架(前端):节点库加双盲复算、反方审稿(把关类,图标、配色、空配置,说明和卡片写明尚未生效,检查器照常打开)。路由加 /runs/compare(排在 /runs/:runId 前,标签页标题写「运行对比」)和 /schedules、/schedules/:id,都是页头加「功能开发中」的占位页;导航和命令面板在设置前加「定时任务」,快捷键 ⌥8,设置仍是 ⌥7;八个导航项在 480px 高的窗口里放不下,矮窗口的导航项从 40px 收到 36px。请求层从 api/client.ts 拆到 api/http.ts,client.ts 原样转出原有导出并加转请求函数;schedules、compare、bundle、inquiry、whatif 各一个空的命名空间文件,从 http.ts 取请求函数、挂到 api 上,不和 client.ts 互相导入。terms.ts 给各包占好文案块(RUN_COMPARE_TEXT 和配方对照的 COMPARE_TEXT 分开)。审批卡留两个插槽:payload.kind 为 dual_check 时的 DualCheckApproval,报告核对概况后面的 ChallengeSummary,都先返回 null。预览页自动收 dev/fixtures/*.tsx 导出的 cases,?syn= 先查这里再走原有用例。check-shell 跟着改导航项和快捷键的断言,check-copy 的 for_model 检查把 http.ts 和 client.ts 合起来看
|
2026-10-04 23:40:20 +08:00 |
|
ThearchyHelios
|
5b3839f787
|
数据目录 F2b:剖析的 409、剖析设置的 422 带机读码,界面不再从原话里认是哪一种——服务端用 api/coded.CodedHTTPException:剖析开始不了的五种情况带 code(profile_disabled、datasource_inactive、schema_missing、profile_busy、snapshot_tampered),保存数据源时剖析设置不合规带 code=profile_settings_invalid 和出错的那一项 field(max_queries……),给人看的那句不变;CodedHTTPException 多一个可选的 field;前端 profileBlockOf、profileFieldOfRejection 只认 code 和 field,没带机读码的旧响应按通用提示处理;补后端测试和检查脚本的断言(伪造的 409、422 都带 code)
|
2026-10-04 03:03:23 +08:00 |
|