SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

user_id

INTEGER

op_type

INTEGER

act_user_id

INTEGER

repo_id

INTEGER

comment_id

INTEGER

is_deleted

INTEGER NOT NULL (default 0

ref_name

TEXT

is_private

INTEGER NOT NULL (default 0

content

{"Commits":[{"Sha1":"fb6c5ad390153c534787dc66d90284ff257d28d1","Message":"docs(governance): 治理入口新增业务主干导航行\n\nCLAUDE.md「使用入口」表加一行，把「搞清业务从头到尾怎么跑 / 新人上手」\n路由到 docs/domain/business-flow-overview.md。\n\n为什么要有这一行：跨域主干导航文档已经落在 docs/domain/ 下，但治理入口表\n不指向它——一份没有入口的资产下轮就没人读、也没人维护，随后静默漂移\n（C25 同族：文档指向的东西运行时到不了，反过来也一样成立）。\n\n该行同时写明它是**派生非真源**、据它下判断前必须回到 contracts / blueprint\n复核，避免入口表把导航文档抬成第二份状态机口径（P1）。\n\nAGENTS.md 为符号链接自动跟随；pnpm check exit 0（含 check:governance-docs）。\n作用域：本地工作区 dirty（并发会话有 approval-inbox 切片二在途），本提交\n只含 CLAUDE.md 一个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T19:58:50-07:00"},{"Sha1":"9e6f5674f9279f43dd8bd6b4acbcfbe5d7af29b6","Message":"test(e2e): 待办审批中心转报价的浏览器级用例——堵住两个 bug 的共同逃逸路径\n\n## 为什么补这一条\n\n审批中心 9 类待办里，「客户已选档·待转报价」是**唯一没被 E2E 打过**的一类。\n两个 bug 正是从这个缺口同时逃逸，且叠在一起：\n1. 前端把端点拼成 /api/solutions/:id/quotation，真实路由是 /create-quotation → 404；\n2. 动作必填 optionId，而 ApprovalTask 投影里没有这个字段 → 400。\n路径修对了也只是把 404 换成 400，这个按钮**从落地起就没成功执行过**。\n\n同轮已补两道静态门禁（check:api-routes / check:approval-payload），但它们各自\n只覆盖一半：前者只校验路径不看请求体，后者只校验入参不看路由。本用例是第三层，\n一次性覆盖两者，且打的是真实浏览器链路。\n\n## 用例设计\n\n前置数据用 API 铺（方案要走完设计→双审核→发布→客户选档才会进待办）——本用例的\n验证目标是**中心内的执行动作**，那条设计链路早已被第 4 条用例覆盖。铺数据序列先在\n真实后端上逐步试通，撞到四个真实约束，均已写进用例：\n- 无 body 的动作要传 {}，否则 Fastify 回 FST_ERR_CTP_EMPTY_JSON_BODY；\n- design 必须三档齐全（经济/推荐/旗舰）；\n- targetSegment 必须**建时就给**：APPROVED 后禁改输入，而对客发布闸门要求它非空；\n- 客户联系人字段是 primaryContact；档案无联系人时选档一律拒绝（审计 S3 fail-closed）。\n\n断言锚到 [data-testid=\"approval-task-row\"][data-approval-kind=\"...\"]，不用全页\ngetByText——页面含实时事件流面板会污染宽断言（C16）。成功判据不看 toast，看\n**服务端读回** QUOTATION_CREATED + quotationId：路径 404 或 optionId 缺失都会\n让这里读不到，且条目不会消失。\n\n自带客户与联系人常量（INBOX_*），不复用 CUSTOMER_NAME/CONTACT_NAME，避免这条链路\n把早期用例的客户档案推进到 QUOTATION_CREATED 而影响它们的断言。\n\n## 证据\n\n- 正向：pnpm check:ui 10 用例 0 失败（PG:55432/juhai_quotation_ui_final_20260801 +\n  Redis:6382，UI_WEB_PORT=3132/UI_API_PORT=3232）。\n- 负向：移除 NestJS 聚合的 optionId 后重跑，**恰好第 10 条判红、其余 9 条全绿**，\n  失败点正是 approval-blocked-reason 出现（UI 如设计般禁用按钮而非发必然 400 的请求）；\n  现场已恢复。\n- ⚠️ 负向那次会把 ui-acceptance.latest.json 覆盖成 status=failed/9 passed——那是负向\n  测试的产物不能当证据，故重跑正向后才提交（本提交内报告为 passed/10）。\n- baseline uiTestsPassed 9→10；CLAUDE.md 证据新鲜度行与 ui-acceptance 基线行同步回灌。\n- pnpm check 全绿 exit=0（18 项，自检 5 组）。本轮未跑 check:runtime（没动写链逻辑）。\n\n工作区 dirty：并发会话在途的报价域改动未包含在本提交内。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T09:52:10-07:00"},{"Sha1":"80fbe00d13bcdf8c4bf8ed64dca1c18cccbab449","Message":"feat(gate): 审批中心入参完整性门禁——从 Zod schema 反推必填字段，契约层与实现层各查一遍\n\n## 背景：一个从落地起就没成功执行过的按钮\n\n待办审批第 9 类「客户已选档·待转报价」的动作接口必填 optionId，而 ApprovalTask\n投影里根本没有这个字段，前端 buildPayload 返回 {}。同轮还有一个路径拼错的 bug\n盖在前面，路径修对了也只是把 404 换成 400 optionId Required。\n\n四道防线同时失效：\n- check:api-routes（同轮新建）只校验路径存在，不看请求体；\n- typecheck 抓不到——`optionId?: string` 是**可选**字段，后端不返回照样编译通过；\n- 9 类待办里恰好只有这一类没被 E2E 打过；\n- descriptor 里的 requiresVersionNo 是**手写布尔标记**，作者当初意识到「有些类\n  需要额外字段」却把它硬编码成单个布尔，新增 optionId 时没有对应标记。\n\n## 判据\n\n对每个 kind 从 Zod schema **反推**必填集合（不依赖任何手写标记），逐字段两层校验：\n1. 契约层：不在中心表单可输入白名单（comment/note/internalComment）的必填字段，\n   必须出现在 ApprovalTask 投影里；\n2. 实现层：**两个后端的聚合都真的产出了它**。第二层是关键——可选字段漏返回\n   不会被 typecheck 抓到，本次 bug 正是这么活下来的。\n\n某域给自己的 schema 加一个必填字段，中心立刻红，而不是等用户点按钮才发现。\n\n## 过程中修正了自己的一次误报\n\n初版用「kind 字面量 ±600 字符」文本窗口，一跑报 4 条红。先判责再改代码：方案两类\n共用 solutionReviews() 一个方法，两个 kind 字面量在方法开头推查询条件，而 versionNo\n在 25 行后的统一 map() 里，超窗即被判「没产出」。**字段产出点与 kind 声明点不在\n同一处是正常写法，门禁不该逼代码迁就它**——改按方法体切块。该坑已写成专门的自检\n用例钉死，防止以后被「优化」回窗口法而静默回潮。\n\n## 已知边界（不得外推）\n\n只校验必填不校验可选；不校验字段类型；USER_INPUT_FIELDS 白名单人工维护，\n往里加字段等于宣称中心表单能收集它，加之前必须确认 UI 真渲染了对应控件。\n\n## 证据\n\n- 真实源码两层负向测试：删 ApprovalTask.optionId → 契约层红；删 NestJS 聚合的\n  optionId → 实现层红并点名 NestJS；现场均已恢复。\n- 自检 14 项（scripts/lib/approval-payload-contract.test.mjs），含 1 条基线绿 +\n  3 条端到端红，断言 exit **恰好为 1**（崩溃同样非 0，会让「期望红」以错误理由通过）。\n- 接线：pnpm check / governance-report 棘轮 / baseline（新增 0 地板，\n  gateSelftests 4→5）/ CLAUDE.md 基线表。\n- 本地工作区 pnpm check 全绿 exit=0（18 项，自检 5 组）；工作区 dirty\n  （含并发会话在途的报价域改动，未包含在本提交内）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T09:14:36-07:00"}],"HeadCommit":{"Sha1":"fb6c5ad390153c534787dc66d90284ff257d28d1","Message":"docs(governance): 治理入口新增业务主干导航行\n\nCLAUDE.md「使用入口」表加一行，把「搞清业务从头到尾怎么跑 / 新人上手」\n路由到 docs/domain/business-flow-overview.md。\n\n为什么要有这一行：跨域主干导航文档已经落在 docs/domain/ 下，但治理入口表\n不指向它——一份没有入口的资产下轮就没人读、也没人维护，随后静默漂移\n（C25 同族：文档指向的东西运行时到不了，反过来也一样成立）。\n\n该行同时写明它是**派生非真源**、据它下判断前必须回到 contracts / blueprint\n复核，避免入口表把导航文档抬成第二份状态机口径（P1）。\n\nAGENTS.md 为符号链接自动跟随；pnpm check exit 0（含 check:governance-docs）。\n作用域：本地工作区 dirty（并发会话有 approval-inbox 切片二在途），本提交\n只含 CLAUDE.md 一个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T19:58:50-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/47ce4c6146a13c443db38c5816749d0591339e46...fb6c5ad390153c534787dc66d90284ff257d28d1","Len":3}

TEXT

created_unix

INTEGER

Update row 20286 in action