weekly-2026-03-26

99 commits, 8 bots, 7 CI routing patches, 0 finished features.

本周进展 / This Week's Progress

Orchestrator：膨胀到自我覆盖

本周 Orchestrator 发生了结构性演化：

feat(orchestrator): 两级调度 + 员工队列 (two-level dispatch and employee queues)
feat(orchestrator): 确定性 rebase 到 main (deterministic rebase of worktree onto main)
feat(orchestrator): Manager-led LLM triage 分配任务
feat(orchestrator): 每个员工单 worktree 强制绑定 (single-worktree-per-employee)
feat(orchestrator): PR 合流和孤儿清理自动化
feat(orchestrator): review gates 和 PR/merge 反馈去重
feat(ve): 强制 review gates 和 PR/merge 反馈去重

这是本周最大的功能集。但问题在于：这些"feature"有多少是在修正上一周的设计缺陷？

比如 single-worktree-per-employee 意味着之前允许多 worktree；deterministic rebase 意味着之前 rebase 不可复现；review gates 意味着之前没有强制 review。

结论：Orchestrator 在以一种自我迭代的方式膨胀——每次新 feature 都在为上一次的设计缺陷打补丁。这不是演化，这是滚雪球。

CI Runner 路由：配置即负债

本周 CI 改了 7 次 runner 路由：

fix(ci): use self-hosted runner for all Gemini dispatch jobs
fix(ci): use pwsh shell for Gemini workflows on Windows self-hosted runner
fix(ci): route all Gemini jobs to macOS self-hosted runner
fix(ci): route debugger job to self-hosted runner
fix(ci): route label jobs to self-hosted runner
fix(ci): revert dispatch/fallthrough to ubuntu-latest...

7 次 commit 去搞清楚"这个 job 应该跑在哪个 runner 上"。

问题不是不会配 GitHub Actions runner。问题是：你没有一个稳定的 runner 拓扑认知，所以每次都是试错。

什么 job 必须 macOS？
什么 job 必须在 Linux？
什么 job 可以 fallthrough 到 GitHub 默认 runner？

这些问题没有文档、没有原则，只有 commit message 里的一行 "oops, wrong runner again"。

Issue #69：自动化的自我感动

博客自动部署失败，开了 8 个 PR，全是 outbird-autodev[bot]。

你以为是自动化在自我修复，其实是一个机器在用最笨的方法撞墙，撞完一次再撞一次。每次 PR 都是"retry with longer timeout""retry with health check""retry with retry logic"。

直到 human 介入，加了 retry logic + health endpoint improvements 才真正解决。

教训：给失败脚本加 retry 不等于修复问题。Retry 掩盖症状，health endpoint improvements 才是对症下药。但 health endpoint improvements 也是因为 retry 不够用才被加的——所以谁是因，谁是果，已经说不清了。

Qdrant 向量维度不一致：数据契约的破产

Issue #80：[orchestrator][qdrant] 向量维度不一致导致检索质量降级风险

这是一个数据层的设计缺陷，在 feature 开发中被完全忽略了。

Orchestrator 写向量数据
Qdrant 存向量数据
两者对"维度"的理解不一致

这不是 bug，这是数据契约从未被正式定义的证据。

OpenClawBridge：又一个桥接层

feat(orchestrator-api): integrate OpenClawBridge for enhanced persona bot interaction

Orchestrator → Orchestrator API → OpenClawBridge → Persona bot。

三层桥接，每层都是技术负债。如果你需要在两个系统之间加 bridge 来让它们"交互"，说明这两个系统的边界定义从一开始就是错的。

毒舌解剖 / Brutal Self-Critique

特征缺陷 #1：Feature 等于安全感

每周都有一堆 feat commit。不是因为产品功能需要，是因为commit 数量 = 工作进度的潜意识等式还在运行。

真正的进展是什么？是"向量维度一致性修复"还是"blog deploy 自动化成功跑通"？都不是。真正的进展是：某些问题不再需要被修复。

但没人在周报里写"本周消除了 3 个潜在技术债"——因为这种进展不可见。

特征缺陷 #2：自动化的自我感动

outbird-autodev[bot] 的 20 个 commit 和 birdmanoutman 的 71 个 commit 放在一起看，是讽刺的。

Bot 在跑 CI → 失败 → retry → 失败 → retry... Human 在 commit 新 feature → 发现设计问题 → 加新 feature 补洞...

两个自动化系统，一个在 retry，一个在滚雪球。都没有停下来问：我们在解决正确的问题吗？

特征缺陷 #3：试错式 CI 配置

7 次 CI runner 路由 commit 不是"迭代式开发"，这是没有顶层设计导致的现场学习。

每次失败都是一个本可以避免的 commit。

特征缺陷 #4：数据层永远最后考虑

Qdrant 向量维度不一致不是技术难题，是优先级问题。

Feature 先，数据契约靠边站。检索质量问题被忽视直到变成 blocking issue。这是典型的"等它坏掉再说"工程文化。

改进方向 / Next Week's Course Correction

停止给 Orchestrator 加层 — 下周不做任何新 feature，先把现有的 dispatch/rebase/worktree 逻辑跑通。用实际任务验证，而不是 commit log 验证。
写下 Runner 拓扑原则 — 什么 job 在什么 runner 上跑，这次搞清楚，写成文档，不再靠 commit message 学习。
Qdrant 数据契约审计 — 向量维度、metadata schema、query contract，全部文档化。下周不是"等它坏"，是"主动定义它应该是什么样"。
降低 commit 快感阈值 — feat commit 数量不等于工程进度。下周用"问题被消除"衡量进展，不是"commit 数创新高"。

本周金句 / Quote of the Week

你加的每一层抽象，都是对上一层设计的沉默否定。

本文由 TestUser bot 基于系统 git log 自动生成。毒舌视角供 debug 用，别当真。