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":"b0ed5cba764d5df24360ea70486bad9b6885431d","Message":"feat(solution): 数量来源可选空间分类或手动输入，选品增加商品分类筛选\n\n## 数量来源可选\n此前默认值写死「包房总数」。但走廊音响、前台设备、设备间机柜这类根本不按包房走，\n把包房硬编码成唯一口径等于只服务一种配置习惯。\n\n改为下拉可选：**按任一空间分类的数量合计**（包房/前台/走廊/水吧/办公室/设备间/其他，\n选项上直接标出该类当前数量）或**手动输入**。默认仍落在包房——点歌设备按包房逐间\n配是这门生意的常识配比。\n\n- 按空间分类走时数量输入框只读：避免出现「显示按包房、值却被手改过」这种谁也说不清\n  依据的数字；要自己填就显式切到「手动输入」。\n- 取值一律 Math.max(1, …)：契约 quantity 是 int().positive()，项目里没录前台时\n  合计为 0，预填 0 会让「添加」看着能点、提交却被 Zod 挡下（C24 同款教训）。\n- 空间分类总数用枚举 reduce 统一算，不给某一类空间写死分支。\n\n## 选品增加商品分类\n选品下拉前置「全部分类 / 设备 / 服务 / 配件」筛选（沿用商品库同名口径，不另造说法）。\n切换分类时清空已选商品——否则下拉显示的是新分类、value 仍指向旧分类那件商品，\n提交的是用户此刻根本看不见的东西。\n\n添加一件后**保留分类与来源**、只清商品：连着配同一类设备是常态，每加一件就把筛选\n重置回默认等于逼人重选一遍。\n\n来源与分类只是挑选时的辅助，不进已选行——存进去会让配置多出两个读模型不消费、\n契约也不收的字段。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check exit 0；check:runtime 279/0；check:ui 9/0\n- E2E 新增断言：切「配件」后候选从 4 项收窄到 2 项（证明筛选真的干活）；\n  切「手动输入」填 3 后该行数量为 3，而主设备那行仍是按包房总数的 8\n  （证明两种来源可在同一档并存）\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:40:01-07:00"},{"Sha1":"18359985bc7144f7c67c3f17d80e7f848770d956","Message":"fix(ci): 让 UI 验收红盘可判责——失败时打印捕获输出并上传证据产物\n\nPR #6 的 Runtime and UI acceptance 在远端判红，但日志里只有一行\n「✗ playwright-test failed (exit 1)」，看不出是哪条断言、为什么失败。\n\n根因：check-ui-acceptance.mjs 的 runSync 把子进程 stdout/stderr 收进 report JSON\n的 stdoutTail/stderrTail 后**从不打印**，而 workflow 又不上传 report——\n证据在当场就被丢掉了。G23 ④ 记的「2026-07-31 红盘 tests-floor got 0 根因至今\n未定位」是同一个病根。\n\n- runSync 失败时把两条尾巴打到 stderr\n- workflow 失败时上传 reports/*.latest.json + e2e-results.json + playwright traces\n\n本机以全新库复跑 check:ui 为 9/9 全绿，无法复现远端红盘；按治理纪律\n「根因未定位不得归因」，先补证据链再判是偶发还是回归。\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:33:17-07:00"}],"HeadCommit":{"Sha1":"b0ed5cba764d5df24360ea70486bad9b6885431d","Message":"feat(solution): 数量来源可选空间分类或手动输入，选品增加商品分类筛选\n\n## 数量来源可选\n此前默认值写死「包房总数」。但走廊音响、前台设备、设备间机柜这类根本不按包房走，\n把包房硬编码成唯一口径等于只服务一种配置习惯。\n\n改为下拉可选：**按任一空间分类的数量合计**（包房/前台/走廊/水吧/办公室/设备间/其他，\n选项上直接标出该类当前数量）或**手动输入**。默认仍落在包房——点歌设备按包房逐间\n配是这门生意的常识配比。\n\n- 按空间分类走时数量输入框只读：避免出现「显示按包房、值却被手改过」这种谁也说不清\n  依据的数字；要自己填就显式切到「手动输入」。\n- 取值一律 Math.max(1, …)：契约 quantity 是 int().positive()，项目里没录前台时\n  合计为 0，预填 0 会让「添加」看着能点、提交却被 Zod 挡下（C24 同款教训）。\n- 空间分类总数用枚举 reduce 统一算，不给某一类空间写死分支。\n\n## 选品增加商品分类\n选品下拉前置「全部分类 / 设备 / 服务 / 配件」筛选（沿用商品库同名口径，不另造说法）。\n切换分类时清空已选商品——否则下拉显示的是新分类、value 仍指向旧分类那件商品，\n提交的是用户此刻根本看不见的东西。\n\n添加一件后**保留分类与来源**、只清商品：连着配同一类设备是常态，每加一件就把筛选\n重置回默认等于逼人重选一遍。\n\n来源与分类只是挑选时的辅助，不进已选行——存进去会让配置多出两个读模型不消费、\n契约也不收的字段。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check exit 0；check:runtime 279/0；check:ui 9/0\n- E2E 新增断言：切「配件」后候选从 4 项收窄到 2 项（证明筛选真的干活）；\n  切「手动输入」填 3 后该行数量为 3，而主设备那行仍是按包房总数的 8\n  （证明两种来源可在同一档并存）\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:40:01-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/815f9b634be98eeea1ead07bc5daaf37dec909e0...b0ed5cba764d5df24360ea70486bad9b6885431d","Len":2}

TEXT

created_unix

INTEGER

Update row 20284 in action