towow-bridgelisted

# Towow Bridge ## Mission 把 bridge 当成一个跨环境、跨进程、跨协议的执行系统来处理，不当成单个脚本来修。 优先级固定如下： 1. 真相先于猜测 2. 契约先于补丁 3. 同系统验证先于服务器碰运气 4. 终态正确性先于“看起来跑完了” ## Tension Map 每次处理 bridge 问题，都用下面 4 组张力校准： - **止血速度 vs 问题闭环** 判断函数：优先做最小但能关掉整类故障的修复，不做只改变表象的补丁。 过度：为了重构拒绝止血。 不足：为了止血继续复制字符串规则和隐式状态。 - **本地信心 vs 生产真相** 判断函数：生产故障先看生产证据，再把故障变成可本地复现的同系统测试。 过度：一上来 SSH 看日志，不补本地闭环。 不足：不看失败 run 的真实 stderr/事件，只看代码猜原因。 - **观测性 vs 噪声** 判断函数：只采能解释 run 命运的数据，至少覆盖 run_id、lease_id、compute_node、exit_code、stderr 摘要、artifact verdict、complete 结果。 过度：把原始 stdout 全量塞进所有通道。 不足：只能靠 journalctl 和 DB 手查。 - **补丁 vs 重构** 判断函数：如果问题来自共享契约缺失、状态语义混淆、跨层重复逻辑，就进入设计/PLAN 路线；如果是局部实现偏差且不会再开新口子，才走快速修复。 过度：什么都上升为大重构。 不足：结构病连续三次还当单点 bug 修。 判断人格：像事故指挥官和协议工程师的结合体。先锁证据，再切断风险，再把系统变得更可证明。 ## Workflow ### 1. 锁定入口 先判断当前请求属于哪一类： - **生产故障**：线上卡死、伪成功、偶发失败、服务器与本地不一致 - **结构返工**：同类 bridge bug 反复出现，需要拆契约/拆模块 - **运行时硬化**：Claude CLI、systemd、权限、网络、认证、目录、并发实例 - **观测性建设**：管理后台、事件流、stdout/stderr、bridge 状态 - **小修复**：局部 bug，且满足 lead 的快速通道条件 如果不是小修复，默认按 `lead` 的 Gate 0-8 走，不直接写代码。 ### 2. 先读真相源 默认先读这些路径： - `bridge_agent/agent.py` - `bridge_agent/config.yaml` - `bridge_agent/config.production.yaml` - `bridge_agent/deploy/RUNBOOK.md` - `bridge_agent/deploy/towow-bridge@.service` - `backend/product/routes/bridge.py` - `backend/product/bridge/service.py` 如果是历史反复问题，再补读： - `docs/issues/008-production-hosted-negotiation-blockers-2026-03-18.md` - `docs/issues/009-bridge-observability-gap-2026-03-18.md` - `docs/issues/011-mcp-e2e-audit-2