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":"04eb1a9023e244277b620d25d83ab7fe3e1e7c3e","Message":"fix: 修复采购拒收/提成备注/供应商表单/选址提交时间 4 处前后端契约断链\n\n- Rejections.tsx：前端类型/表单/列表全面对齐后端真实契约\n  （reasonType/reasonDetail/handlingStatus/handlingResult，purchaseOrder/\n  supplier/rejector 改嵌套对象）；POST /rejections、/rejections/:id/handle\n  补上此前完全缺失的 Zod 校验；listRejections 的 supplierId 筛选此前被\n  静默忽略，现通过 purchase_orders 关联真正实现；handlingStatus 命名对齐。\n- commission_records/commission_settlements：前端 remark 字段统一改为\n  notes 对齐后端真实列；顺带把\"生成结算单\"备注功能真正打通\n  （generateSettlementSchema 此前没有该字段，前端填了会被 Zod 直接丢弃）。\n- supplier_applications/supplier_contracts：移除一批被 Zod 校验通过却\n  从未写入数据库的死字段（city/province/companyProfile/bankAccountName/\n  applyReason/subCategory/confidentialityClause/productScope/deliveryTerms/\n  penaltyClause/territory）——这批列已在 schema 清理中被物理删除，\n  修复方向是去掉前后端\"填了也存不进去\"的死字段，而非把列加回来。\n- location_assessments.submitted_at：该列物理上一直存在（建表迁移即有），\n  只是 Prisma schema 未声明；补上字段声明后 submit() 真正写入该列，\n  前端已有的渲染逻辑无需改动即可生效，prisma migrate status 确认无 drift。\n\ntype-check 全绿（前端+后端），受影响 6 个模块 219 个单测通过（新增 7 个\n拒收记录测试锁定 supplierId 过滤、字段写入行为）。\n\nCo-Authored-By: Claude Sonnet 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-01T03:40:54-07:00"},{"Sha1":"0dda7b57e47411ea4a044d5966c888a9336242a7","Message":"chore(schema): 388 项破坏性 schema 变更全文级复核，清理本地库 243 项确认孤儿对象\n\n背景：dual-tenant-risk-ledger R-P0-2 记录的 388/375 项 dropTable+dropColumn\n迁移序列外破坏性变更，此前 0 owner 签字、无法追溯裁定依据。\n\n本轮工作：\n1. 产出结构化清单（schema-destructive-changes-inventory-2026-07-01.md），\n   对 375 项逐条做全文级代码引用复核（非邻近窗口字符串初筛）。\n2. 279 项收敛为\"确认可安全清理\"，其中 25 项 supplier 域列被证实是\"改名复用\"\n   （如 risk_name→title、contract_name→title），从候选中排除避免真删数据；\n   58 项（supplier_jbps/supplier_scorecards）候选列名与当前 schema 完全不匹配，\n   标记为\"清单来源存疑\"暂不裁定。\n3. 对确认安全的 279 项先跑数据存在性预检，36 列有非空计数（抽查证实均为\n   DEFAULT 值噪声，非真实业务数据）保守排除，最终 243 项（30 张表 CASCADE +\n   213 列）已在本地开发库执行验证，过程中发现并安全清理了 service_tickets\n   上两条指向废弃工单工作流表的死外键。\n\nscripts/audit-same-tenant-references.ts 同步移除已删除的 ticket-operations.service.ts\n引用。type-check 全绿，受影响 6 个模块 215 个单测通过。staging/生产未触碰，\n需 owner 签字后按文档流程重新执行数据预检再放行。\n\nCo-Authored-By: Claude Sonnet 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-01T03:40:19-07:00"},{"Sha1":"4d854c3be9851ddb8af27e9bea5cb231c33a7a03","Message":"fix(tickets): 补齐状态机死守卫，删除零引用的死代码平行实现\n\ncanStart/canResolve 守卫补线：未指派处理人的工单不能开始处理或标记已解决\n（此前状态机拓扑允许 new/in_progress 直接流转，未指派工单可静默进入处理中）。\n\n删除 ticket-operations.service.ts：其导出的 12 个函数\n（startTicket/resolveTicket/pauseTicket 等）在全仓库只被自己的测试文件引用，\ncontroller/路由层实际走的是 TicketService 类方法，是完全未接线的死代码平行实现。\n测试文件中对应的 7 个 describe 块改写为测试真实类方法，过程中一并修正了\nmock 调用次数（updateInTx 内部还有一次存在性校验 findFirst）和\ncanTransitionTicket 全局 mock 恒 true 导致拓扑拒绝路径测不到的问题。\n\n43/43 单测通过。\n\nCo-Authored-By: Claude Sonnet 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-01T03:39:23-07:00"},{"Sha1":"33a3248f092a239094ad920d12fb0c5dc0c730ca","Message":"fix(governance): 补录 53 个孤儿模块到 modules.ts 登记表\n\n后端 281 个模块目录里有 53 个已挂载路由但从未在 MODULE_REGISTRY 登记，\n权限码从各模块真实 requirePermission 调用中提取补录（非编造）；system\n模块补充为聚合门面条目（无独立路由，见 system.routes.ts 注释）。\nai-manifest-registry 确认是 Phase 0 基础设施桩代码而非业务模块，未强行注册。\n\naudit:modules 复核无回归。\n\nCo-Authored-By: Claude Sonnet 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-01T03:38:57-07:00"},{"Sha1":"e2cacfb34e40fb700f3c2b03039deb9db20fd603","Message":"fix(rls): 修复分区子表 RLS 绕过并把运行态扫描接入棘轮门禁\n\naudit_logs/event_logs/im_messages 的 81 张月度分区子表此前 relrowsecurity=false，\n父表 RLS policy 不被子表继承，无租户上下文直查子分区可读到全租户数据（本地实测\naudit_logs_2026_05 泄露 21375 行）。新增迁移给存量子表 backfill RLS+policy，\n并把 create_monthly_partitions() 改成新分区随建随启 RLS，已在本地库验证泄露归零、\n合法访问不受影响。\n\n同时补上审计盲区：generate-rls-policies.ts 新增运行态扫描（直连 pg_inherits/\npg_class），不再只看 Prisma model 静态清单；harness report.ts 把分区子表缺口计入\ndashboard HIGH；CLAUDE.md 新增两条棘轮断言并通过 baseline-reconcile 校验。\n\nCo-Authored-By: Claude Sonnet 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-01T03:38:15-07:00"}],"HeadCommit":{"Sha1":"04eb1a9023e244277b620d25d83ab7fe3e1e7c3e","Message":"fix: 修复采购拒收/提成备注/供应商表单/选址提交时间 4 处前后端契约断链\n\n- Rejections.tsx：前端类型/表单/列表全面对齐后端真实契约\n  （reasonType/reasonDetail/handlingStatus/handlingResult，purchaseOrder/\n  supplier/rejector 改嵌套对象）；POST /rejections、/rejections/:id/handle\n  补上此前完全缺失的 Zod 校验；listRejections 的 supplierId 筛选此前被\n  静默忽略，现通过 purchase_orders 关联真正实现；handlingStatus 命名对齐。\n- commission_records/commission_settlements：前端 remark 字段统一改为\n  notes 对齐后端真实列；顺带把\"生成结算单\"备注功能真正打通\n  （generateSettlementSchema 此前没有该字段，前端填了会被 Zod 直接丢弃）。\n- supplier_applications/supplier_contracts：移除一批被 Zod 校验通过却\n  从未写入数据库的死字段（city/province/companyProfile/bankAccountName/\n  applyReason/subCategory/confidentialityClause/productScope/deliveryTerms/\n  penaltyClause/territory）——这批列已在 schema 清理中被物理删除，\n  修复方向是去掉前后端\"填了也存不进去\"的死字段，而非把列加回来。\n- location_assessments.submitted_at：该列物理上一直存在（建表迁移即有），\n  只是 Prisma schema 未声明；补上字段声明后 submit() 真正写入该列，\n  前端已有的渲染逻辑无需改动即可生效，prisma migrate status 确认无 drift。\n\ntype-check 全绿（前端+后端），受影响 6 个模块 219 个单测通过（新增 7 个\n拒收记录测试锁定 supplierId 过滤、字段写入行为）。\n\nCo-Authored-By: Claude Sonnet 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-01T03:40:54-07:00"},"CompareURL":"luoanwu/juhi-omni-knowledge-hub/compare/989e54a1f18193e7e19b620bf93c71c29508f2f9...04eb1a9023e244277b620d25d83ab7fe3e1e7c3e","Len":6}

TEXT

created_unix

INTEGER

Update row 15249 in action