EaiLab/pj0235-eai_agentplatform
11
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
51 Commits 1 Branch 0 Tags
e9c0c4007cf3e96117ba8eb6946f83ebc5ab673e
Commit Graph
5 Commits
Author SHA1 Message Date
eaiadminandClaude Code e9c0c4007c fix(task): 删任务级联清掉 run 与产物，不再留孤儿逐字稿 
DELETE /api/my/tasks/:id 原先只删 task_record。实测：删前 1/7/6，
删后 0/7/6 —— 运行记录与产物原样留着。任务列表里再也看不到，
也没有任何接口能按 task_id 找回，等于永久留在库里。而产物正文常常是
完整逐字稿（一次 26 分钟会议的录音内容），于是「删掉任务」并不等于
「删掉录音内容」；交付前按 DELIVERY.md 手工清单 C 项清测试数据时，
会留下一批谁也删不掉的逐字稿。

补上 TaskRunDAO.DeleteByTask + TaskArtifactDAO.DeleteByTask —— 两个 DAO
早就有了，weixin_public_account 的工作流重置一直在配对使用，缺的只是
这里没调。先子后父：中途失败任务还在，重试一次就干净；反过来先删父
再失败，子记录就再没人能找到了。task_id 外键只有这两张表，即完整级联。

验证（internal/api/my_task_delete_test.go，真实路由 + 真实鉴权中间件）：
先 stash 掉 my_task.go 跑，孤儿断言如期红；改回全绿。另有越权用例钉住
「404 且一条都不许少」，以及旁观任务证明不误伤。条数用 3/2 而非 1，
计数走模型而非表名字符串（拼错表名 Count 为 0，而 0 正是期望值）。
详见 bugs_and_errors.md E15。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-27 00:16:39 +08:00
eaiadminandClaude Code 81366ca273 fix(audio): 断连后能接着跑完 —— 失败消息上的重试 + 步骤编号统一 
用户报「卡在步骤 3」，实际断在第 5 步 structure：请求发出 46ms 后浏览器
连接断开，Gin 的 Request.Context() 被取消，上游回 499，后端包成 400。
服务端与前端应用层都没有任何主动取消（全仓 grep cancel/AbortController
零命中），是一次客户端断连。

断连本身无法在代码里杜绝，但它暴露了三个真 bug：

1. 报错文案说「第 1 步」，右栏说第 5 步 —— 尾部两步按自己这一轮从 1 数。
   新增 STEP_NUMBERS，报错与右栏共用同一份编号（这就是「步骤 3」这个
   说法的来源：用户看到的第一个数字就对不上）。
2. 断连后界面上没有任何续跑入口，任务永远停在 4/6（右栏六步是只读的）。
   失败的那条助手消息上挂「🔁 重试」。
3. 无脑重跑会在同一任务里留第二份「结构化纪要」，两份差别用户看不出来。
   resumeAudioSkill 收 skipSteps，按 task_run.action_key 判「跑过没有」
   —— 不用产物类型判，document/checklist 别的技能也在用。

另修：待确认那条消息改用 reactive()。messages 是 ref([])，push 进去的对象
模板读时才被代理，而代码改的是那个变量，改普通对象不触发重渲染，
用户会一直看到「正在继续整理...」。

验证（临时任务 100，已删，先备份 db）：CDP setBlockedURLs 掐掉 structure
复现同形断连 → 消息挂出重试按钮，文案与右栏同为第 5 步；后端补跑一次
structure（模拟响应丢失但已落库）→ 点重试只跑 minutes，落库 document 1 份、
checklist 1 份。反证：再手工跑一次 structure，同名产物立刻变 2 份。
详见 bugs_and_errors.md E14。

E15（未修，记录在案）：DeleteMyTask 只删 task_record，run 与 artifact 全成
孤儿，产物 content_text 是完整逐字稿。删除语义务必先定硬删还是软删。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-27 00:04:19 +08:00
eaiadminandClaude Code b4c8ea38d1 feat(asr): 降级兜底——分离路由全挂时退到无分离路由，只交付逐字稿 
回退链从「一条主路由 + 一串替补」改成两级：先把同能力（有说话人分离）的路由
试完，全挂才降级到不分离的路由。降级是**本次事实**而不是配置事实，写进第 2 步
产物（capability_degraded / capability_zh），第 3 步与第 5/6 步据此判为不可用。

- transcribe.go：Result 加 CapabilityDegraded，判据 chain[0] 能分离而实际这条
  不能；与 HasSpeakers 分开记（后者可能是「配了却没输出」那种异常）
- audio_handlers.go：闸门从「读路由声明的能力」改成「读稿子里实际有没有标签」
  （audioTranscriptSpeakerKeys），与第 3 步共用同一句 SpeakerKeysOf；本次没分离
  → 哨兵错误 errAudioSpeakersUnavailableThisRun，不再放行去写一份看不出残缺的纪要
- 闸门**不看** capability_degraded：改动前落库的老产物没有这个字段，看它就 fail-open
- 第 1 步「转写要求」提前把降级的后果说清；第 2 步产物带完整措辞与「⚠」日志
- 前端两处（SpecialistPanel.vue / audioSkill.js）判断顺序改为先读实际结果
  has_speakers、再退回声明 speakers —— 顺序反了会在降级那一次照旧显示第 3 步
- ai_config.json：补 3 条云端无分离路由与各自的回退链

验证：三处变异（产物 key 拼错、标记写死 true、闸门 fail-closed）都验过会红；
新增两个用例文件走真实 gin 路由 + 真实鉴权中间件，断言拦下来的**理由**而不只是
「拦下来了」；go test ./... 全绿、gofmt 干净、前端构建通过。

同期把本地 ASR 装成 systemd 常驻服务（deploy/install_asr_local.sh 七步全过，
开机自启，实测 26.7 分钟录音 → 3.1 分钟）。装的过程挖出两个只在服务化时才暴露的坑：

- E12 转写堵住事件循环 → 探活超时 → 本地被判不健康 → auto 静默退云端、音频出网，
  全程没有任何报错。修法 run_in_threadpool（deploy/asr/serve.py）
- E13 服务账号的 ~ 不可写，pyannote 写不了 ~/.pyannote/database.yml，每次转写 500。
  修法 asr.env 加 HOME=<cache 目录>（该目录在 unit 的 ReadWritePaths 里）

顺带收口一处交付缺口：服务源码原先只有 ~/asr-poc 一份，而 DELIVERY.md 的清理计划
要 rm -rf 它 —— 那会让唯一副本变成 /opt 下 root 所有、不在任何版本库里的文件。
现在 deploy/asr/ 是唯一事实源，装机脚本与文档同步改。

已知偏离 / 未做（记在案）：
- 界面那句「本次没有说话人分离，后续步骤不可用」只验到后端接口层，没有造出真实
  降级场景渲染出来看过
- deploy/asr/ 的引入改变了装机来源：原型目录 $SRC_DIR 从此只提供 venv 与模型，
  服务代码一律从仓库取

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-26 23:36:00 +08:00
eaiadminandClaude Code bc30bfce28 docs(rules): 记录「dev 早期一包提交」——G14.5 例外 + E09 复盘 
上一条提交（c1af86c）刻意混合了多条并行线，本提交把这次的教训沉淀下来：

- G14.5 增补例外条款：dev 早期直接 `git add -A` 一包提交，不为粒度打断节奏、
  不反问用户提交范围；同时保留「如实披露混合内容」的硬要求，并给出可操作判据
  「为了让提交能编译而不得不先测依赖锥 ⇒ 本来就是一个单元」。
  原文一字未删，例外写在原文之下；头部版本 V1.3 → V1.5。
- bugs_and_errors.md 新增 E09：症状（一句「提交一下」被做成依赖锥测量 +
  hunk 挑拣工具 + 5 轮索引导出编译 + 最后反问用户范围）、根因（把 G14
  「git 是后台事务」读成了「提交粒度值得花成本」）、修法、以及实测出的依赖锥
  （ASR / LLM 调用层 / 编排 Agent / 联网搜索 是一个编译单元）。

E09 记的是我自己的工作方式错误，不是环境坑。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-26 22:22:34 +08:00
eaiadminandClaude Code c1af86c934 feat(asr): 本地语音转写接入为一级路由 + 并行工作流合并提交 
按用户指示做**一包提交**，不按工作流拆分。本提交刻意混合了多条并行线：

  · 本地 ASR 接管：audio 成为与 chat/embed/image/video 同等的路由类别
    （IsLocalRoute 单一判据、audio 健康探测、default_audio_route、
    auto 占位、GET /api/ai/routes/audio、回退云端时界面明示「音频已出网」）
  · LLM 调用层：ctx 贯穿、ToolCall/ToolSchema、EmptyCompletionError /
    TransientUpstreamError（按错误类型而非文案判重试）
  · 编排 Agent：general_assistant orchestrate/persistence/spec_driver
  · 联网搜索：internal/search（playwright）
  · 网盘：backend + 前端
  · 前端 UI：导航/路由/工作台若干页
  · 交付文档：DELIVERY.md / AR04 / 部署文档的「无 Python」表述据实改写，
    新增 eai_agentplatform-asr.service、asr.env、clonezilla-cleanup 清 ~/asr-poc

不分拆的原因：dev 早期，粒度不该打断工作节奏。且实测过——这些改动
**在编译上是同一个单元**（llm.go 的 ctx 签名变更牵动 12 个调用点，
chat_message.go 的 ctx 改动又与编排重写同处一个 hunk），拆出来的中间态编不过。
详见 TOP_CODING_RULES.md G14.5 与 bugs_and_errors.md E09。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-26 22:21:39 +08:00