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":"06c1676e4e8d18d0a3797df1323ed4d768d3bee8","Message":"fix(rma): complete 契约错位收口——resolution 真落库、completed_at 从死写复活\n\n前端 rmaApi.complete 发送 resolution/refundAmount/returnShippingNo/\nreturnShippingCarrier 四字段，而后端 completeRmaSchema 只收 returnedItem——\n全部被 Zod 静默剥离；且 completeRma 的 updateMany 从不写 completed_at，\n详情 timeline 依赖 completed_at 生成的「完成」节点永不出现（死节点）。\n\n修复（接线 + 契约收敛双向）：\n- 后端：completeRmaSchema 补 resolution（max 2000，可选）；completeRma 写入\n  completed_at + 将 resolution 并入 logistics_json（与 diagnose 的 diagnosis\n  键同构，保留既有 JSON 键）；controller 透传。\n- 前端 api：complete 签名收敛为 { resolution, returnedItem? }——删除后端无\n  写链的 refundAmount/returnShippingNo/returnShippingCarrier 死字段（退款\n  金额属财务域真源，不在 RMA JSON 记第二份）。\n- 前端 Detail（视图驱动闭环）：完成确认框升级为受控 Modal 真收集处理结论\n  （默认「已完成处理」，与既有拒绝原因 Modal 同构）；Descriptions 新增\n  「诊断结论」「处理结论」两行读 logisticsJson.diagnosis/resolution，\n  写入的信息在详情页真正查得回。\n\n真实端到端验证（运行中后端 + 真实 DB）：\n- created→receive→process→complete 带 resolution：status=completed、\n  completedAt 落库（timeline 完成节点复活）、logisticsJson.resolution\n  API 读回与 DB 直证一致。\n- 顺带补验上一提交的 diagnose 对齐链：receive→diagnose 带 diagnosisResult，\n  DB 直证 logistics_json.diagnosis 落库。\n\n新增回归锁定单测：断言 updateMany 写 completed_at + logistics_json 合并\nresolution 且保留既有 diagnosis 键。rma.service.test.ts 34/34 通过；\n前后端 type-check 全绿。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-03T03:16:05-07:00"}],"HeadCommit":{"Sha1":"06c1676e4e8d18d0a3797df1323ed4d768d3bee8","Message":"fix(rma): complete 契约错位收口——resolution 真落库、completed_at 从死写复活\n\n前端 rmaApi.complete 发送 resolution/refundAmount/returnShippingNo/\nreturnShippingCarrier 四字段，而后端 completeRmaSchema 只收 returnedItem——\n全部被 Zod 静默剥离；且 completeRma 的 updateMany 从不写 completed_at，\n详情 timeline 依赖 completed_at 生成的「完成」节点永不出现（死节点）。\n\n修复（接线 + 契约收敛双向）：\n- 后端：completeRmaSchema 补 resolution（max 2000，可选）；completeRma 写入\n  completed_at + 将 resolution 并入 logistics_json（与 diagnose 的 diagnosis\n  键同构，保留既有 JSON 键）；controller 透传。\n- 前端 api：complete 签名收敛为 { resolution, returnedItem? }——删除后端无\n  写链的 refundAmount/returnShippingNo/returnShippingCarrier 死字段（退款\n  金额属财务域真源，不在 RMA JSON 记第二份）。\n- 前端 Detail（视图驱动闭环）：完成确认框升级为受控 Modal 真收集处理结论\n  （默认「已完成处理」，与既有拒绝原因 Modal 同构）；Descriptions 新增\n  「诊断结论」「处理结论」两行读 logisticsJson.diagnosis/resolution，\n  写入的信息在详情页真正查得回。\n\n真实端到端验证（运行中后端 + 真实 DB）：\n- created→receive→process→complete 带 resolution：status=completed、\n  completedAt 落库（timeline 完成节点复活）、logisticsJson.resolution\n  API 读回与 DB 直证一致。\n- 顺带补验上一提交的 diagnose 对齐链：receive→diagnose 带 diagnosisResult，\n  DB 直证 logistics_json.diagnosis 落库。\n\n新增回归锁定单测：断言 updateMany 写 completed_at + logistics_json 合并\nresolution 且保留既有 diagnosis 键。rma.service.test.ts 34/34 通过；\n前后端 type-check 全绿。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-03T03:16:05-07:00"},"CompareURL":"luoanwu/juhi-omni-knowledge-hub/compare/c4a1b8ebcc54d4a222aa030b845818ad365b950d...06c1676e4e8d18d0a3797df1323ed4d768d3bee8","Len":1}

TEXT

created_unix

INTEGER

Update row 15971 in action