统一错误事件同步留痕到 AppData 应用日志 #453

Merged

k88936 merged 8 commits from feat/log-the-dianosis into master 2026-09-22 10:54:42 +08:00

Conversation 1 Commits 8 Files Changed 5

+214 -1

8 Commits

Author	SHA1	Message	Date
k88936	a3586bc995	Merge remote-tracking branch 'refs/remotes/origin/master' into feat/log-the-dianosis ... # Conflicts: # docs/project-memory/shared-memory/decision-log.md # docs/project-memory/shared-memory/pitfalls.md	2026-09-22 10:26:13 +08:00
k88936	74e6ac90a7	把摘要移出应用日志身份行，避免整行脱敏吃掉事件定位 ... - 身份行只留程序生成或调用方常量字段（eventId / source / stage / code / retryable / clientTurnId / elapsedMs / detailRef），去掉了 summary - summary 移到详情行（hint / summary / detail / metadata），自由文本全部只出现在详情行 - 原因：sanitize_diagnostic_message 命中凭据标记时替换整行，且裸词标记（如 credential rotation failed）脱敏消不掉，summary 留在身份行会连 eventId、detailRef 一起被替换 - 用例补一条裸标记词场景：详情行被整体替换时身份行仍能按 eventId 与 code 定位 - 同步【技术方案】AGC错误报告与诊断上传、【技术方案】AI游戏创作智能体App实施计划、决策记录与踩坑记录的两行字段口径 - 验证：cargo test -- runtime_error direct_tool_bridge（41 passed）、cargo fmt --check、git diff --check	2026-09-22 10:22:28 +08:00
k88936	cc980267fe	用例改为按生产口径传入已脱敏 detail ... - 原用例直接传带 token=secret 的原文，与函数「detail 已是 sidecar 脱敏文本」的前置条件不符，测的不是真实数据流 - 改为先按 8 KiB 口径 redact 出 safe_detail 再传入，metadata 仍按生产原样传未脱敏 JSON，保留脱敏覆盖 - 验证：cargo test runtime_error（7 passed）	2026-09-21 22:45:06 +08:00
k88936	4bdf9e2cd4	写明应用日志投影为什么对已脱敏 detail 再过一遍 ... - 原注释写「只再按应用日志预算截一次」，实现却是完整脱敏流水线，合同与实现不一致 - 采纳方式是把合同写实：detail/metadata/summary 都在这里脱敏；已脱敏的 detail 也走同一遍，理由是截断会切开脱敏标记，且这是 pub(crate) 边界不假设调用方先脱敏 - 未采纳「去掉再脱敏改为只截断」：该建议会把安全性绑定在调用方自觉上，收益只是一次可忽略的 canonicalize - 验证：rustfmt（注释改动，无行为变化）	2026-09-21 22:42:56 +08:00
k88936	5847505020	用例按逐行口径核验应用日志落盘边界 ... - 生产是把两行分别交给 append_application_log_line 脱敏截断，原用例先 join(" ") 再 sanitize，测不到逐行截断与「只该脱敏其中一行」的情况 - 改为逐行 sanitize，并分别断言身份行（eventId/code/detailRef/summary）与详情行（detail 脱敏、metadata 无凭据） - 验证：cargo test runtime_error（7 passed）	2026-09-21 22:20:25 +08:00
k88936	c49ee8d157	详情行的 metadata 补上单行压平 ... - metadata 之前直接以 {metadata} 插值进日志行，只靠 Value::to_string() 的转义保证单行，和函数「每个字段都先压平」的约定不一致 - 改为与其他字段一样走 single_line_log_field，日志行完整性不再依赖序列化器的转义行为 - 验证：cargo test runtime_error（7 passed）	2026-09-21 22:16:05 +08:00
k88936	852f5de886	修复应用日志身份行的摘要只压行未脱敏 ... - 身份行的 summary 由调用方给，direct_tool_bridge 传的是工具错误原文，而 app_log! 会把整行写 stderr，那里没有 sanitize_diagnostic_message 兜底 - 新增 AGENT_RUNTIME_ERROR_APP_LOG_SUMMARY_CHARS（320 字符，与 sidecar 摘要预算同口径），summary 落日志前先脱敏再截断 - 函数合同写明 detail/metadata/summary 三类外来文本都在这里脱敏，不再只是压平换行 - 同步【技术方案】AGC错误报告与诊断上传与共享记忆 decision-log 的预算口径 - 验证：cargo test runtime_error（7 passed）	2026-09-21 22:12:41 +08:00
k88936	8b2d0cb9df	统一错误事件同步留痕到 AppData 应用日志 ... - 新增 agent_runtime_error_app_log_lines，把统一错误事件的同一份已脱敏诊断投影成应用日志两行：agent.runtime.error 身份行与 agent.runtime.error.detail 详情行 - 身份行含 eventId/source/stage/code/retryable/clientTurnId/elapsedMs/detailRef/summary，详情行含 hint/detail/metadata；detail 与 metadata 各按 1200/200 字符预算先脱敏再截断，字段仍只来自 sidecar 那份 diagnosis - 拆两行的原因：整行命中凭据标记会被 sanitize_diagnostic_message 整体替换成脱敏占位，详情行被吃掉时身份行仍能定位 eventId 与 detailRef - app_log! 先于 sidecar 写入，sidecar 写失败也留下可提交的诊断；各字段先压平换行，保证应用日志逐行读取且 stderr 输出不拆行 - 新增用例覆盖身份字段、凭据脱敏、单行口径与实际 sanitize_diagnostic_message 落盘边界（含超长诊断） - 同步文件【技术方案】AGC错误报告与诊断上传与【技术方案】AI游戏创作智能体App实施计划，共享记忆 decision-log 与 pitfalls 明确项目内 .agent/runtime/errors sidecar 与进程内错误报告事件池是两套东西，本次只写日志行 - 验证：cargo test runtime_error（7 passed）、cargo fmt --check、npm run check:encoding、git diff --check	2026-09-21 21:34:45 +08:00