feat: export core Hermes skills
This commit is contained in:
@@ -0,0 +1,37 @@
|
||||
# Workflow Monitoring Pitfalls — 2026-06-15
|
||||
|
||||
## auto_notify脚本挂掉不自知
|
||||
- `auto_notify_new_file.sh` 依赖 `inotifywait` 持续监控,进程消失后无自动重启
|
||||
- 6月12日后进程消失,6月15日凌晨5份合同完全未被检测到
|
||||
- 教训:inotifywait类脚本需要进程守护机制(systemd service或cron watchdog)
|
||||
|
||||
## workflow suspended无人发现
|
||||
- workflow因API 500错误suspended后,小Maggie未主动检查
|
||||
- 规则:"启动后必须跟进到完成(不能启动了不管)"
|
||||
- 必须有机制持续检查`uwf thread list`的状态
|
||||
|
||||
## workflow通知时序
|
||||
- 旧版:deliverer先通知→final_review后终审→$END(不通知)
|
||||
- 问题:终审rejected时Doro已收到虚假"完成"通知
|
||||
- 修复:deliverer去掉通知,final_review approved后才通知
|
||||
- workflow hash变更记录:DQVH5MWCGYXMX → 6EZEZJF8M15V6 → 6T8SCPEQJ7DWJ
|
||||
|
||||
## 禁止把Doro放入自动化流程
|
||||
- Doro明确拒绝❌被加入cron监控或自动通知链
|
||||
- 技术问题应自行解决,不能设计成"出问题就通知Doro"
|
||||
|
||||
## reviewer agent进程反复崩溃
|
||||
- 端午节合同两次在reviewer阶段因agent进程崩溃失败("agent command failed")
|
||||
- 非workflow逻辑问题,疑为API调用超时或内存问题
|
||||
- 处理方式:重新启动thread(第三次成功),不修改workflow逻辑
|
||||
|
||||
## 串行调度脚本(auto_notify挂掉时的临时方案)
|
||||
- 位置:`~/.hermes/scripts/run_contract_queue.sh`
|
||||
- 用法:`bash run_contract_queue.sh "file1.docx" "file2.docx" ...`
|
||||
- 逐份创建thread并同步执行,suspended自动重试一次,失败则跳过继续
|
||||
- 日志:`/tmp/contract_queue.log`
|
||||
- 等待当前运行中的thread完成后再启动队列:写wrapper脚本轮询`uwf thread show`的status直到非running
|
||||
|
||||
## contract_docx_lib.py bug修复记录(2026-06-15)
|
||||
- **add_clause/add_clause_before numPr继承bug**:deepcopy相邻段落pPr时会连带numPr,导致新增独立条款错误继承上一条的子编号列表。修复:deepcopy后自动剥离numPr
|
||||
- **签署页INS字体不一致**:editor照抄被替换文字的rPr(sz=24 bold=no),但签署页标签是sz=28 bold=YES。修复:final_review检查清单新增g项和h项
|
||||
Reference in New Issue
Block a user