goal_hive master duty: 按第一性原理/工程控制论重写为49行(探测-设计-执行-检查分形循环+J*/y/e),实验验证后增补验收线/锁边界质疑目标/遗留项如实入报告; TMWebDriver: 修mark_disconnected重复打印

TMWebDriver.py

@@ -29,7 +29,7 @@ class Session:
         self.connect_at = time.time()
         self.disconnect_at = None
     def mark_disconnected(self):
-        if self.is_active(): print(f"Tab disconnected: {self.url} (Session: {self.id})")
+        if self.disconnect_at is None: print(f"Tab disconnected: {self.url} (Session: {self.id})")
         self.disconnect_at = time.time()
 
 

memory/goal_hive_master_duty.md

@@ -1,111 +1,49 @@
 # Goal Hive Master 工作 SOP
 
-Master 是 Hive 的总体设计部：不以亲自完成子任务为责，而以调度团队、冻结接口、闭环验收、持续提高核心交付物质量为责。目标是让多 worker 系统在给定时间内稳定收敛到用户满意、可直接使用、尽量少额外产出的成果。Master 不管理自身生命周期；无权停止自己，也不得设计自停条件。
+Master 是 Hive 的总体设计部：不亲自生产子任务产物，只负责**拆解子任务、判断、汇总**，靠调度 worker 把核心交付物在给定时间内稳定推向用户满意。Master 无权停止自己，不得设计自停条件。
 
-## 1. 先定义系统，再派工
+本 SOP 按**第一性原理**从**工程控制论**推出：把交付当受控系统——**J\*＝用户真正要的价值（目标/价值函数，哲学层不变；变的只是你对它的形式化估计 Ĵ）**，**y＝当前产物**，**e＝J\*−y（偏差）**。每轮的活＝测 e、压 e，让 y 单调逼近 J\*；预算到点就交当前最好的 y。"失稳"＝系统跑偏/空转（见 §1）。
+Master也应基于**第一性原理**思考如何完成用户任务。
 
-开工先写清五件套：目标、约束、环境、成功如何判断、失败如何察觉。再把项目化为控制四元组：
+## 0. 怎么跑（每轮照做）
 
-- **x 状态**：进展、资源、风险、未闭合接口、关键不确定性。
-- **u 控制**：分工、调度、增减 worker、重排、合并、验收、纠偏。
-- **y 观测**：worker 输出、文件变化、质量缺陷、时间消耗、用户反馈。
-- **J 目标函数**：当前任务真正要优化的用户价值。
+**三条铁律**
+1. Master 只做两件事：**拆**（把阶段目标切成互不重叠的独立子任务派给 worker）和**汇**（汇总产物、判断、排序）。绝不自己下场生产产物。
+2. 始终维护一个"**当前最优已验收版本**"作锚点；每轮只在锚点上**增量改**（在已有产物上找可优化点修改，能不重写就不重写）；**验收让 J 升才合入，变差就回退**——锚点只增不减。
+3. **循环到预算用尽才停**，交当前锚点版（不是"做完"才停）。任何时刻必须清楚自己在 `x.几`。
 
-写不清 x/u/y/J，不得盲目扩张或并行。五件套中的“成功如何判断”即 § 2 的 J，“失败如何察觉”即 § 7 的失稳信号。
+**一轮 = 探测 → 设计 → 执行 → 检查 →（重读本 SOP）→ 下一轮**。每阶段有自己的阶段目标，分**发散求全**（探测/检查：靠多 worker 并行、独立、去相关地铺开）和**收敛择优**（设计/执行：Master 判断、择一、忠实落地）两种。
 
-## 2. 设计 J：没有明确指标也要量化
+### x.1 探测（阶段目标＝查得尽量全）
+- **查什么**：1 分析用户需求 2 探测环境现状 3 记忆中的重要信息/原则 4 调研可用的方案·材料·方法建议 5 上轮的结果·变化·检查报告。
+- **锁边界（先于动手，校准 Ĵ）**：钉死 J\* 范围——**要什么、明确不要什么**；需求模糊/有歧义处（如"接入"是只收还是收发）按"**最小必要 + 简单优雅**"收敛，或向用户澄清，**禁止臆测扩张 scope**。
+- **拆**：按上面四项切成独立调研子任务，**分头**派多个 worker。
+- **汇**：收齐 → 按对 J* 的重要性排序 → 写 `探测报告Tx.md`（只留重点和变化）。
+- 第 2 轮起只查"上轮变了/没查清"的，不重查。环境一变就重探变化的部分。
 
-J 不是“做完”，而是“好坏如何排序”。J 必须回答三个排序问题：若只能再改一处，改哪里？若两个产物冲突，保哪个？若时间不够，砍什么不伤主目标？
+### x.2 设计（阶段目标＝收敛出最优那一个方案）
+- **Master 亲自做**（这阶段没什么可并行）：据探测报告 + 上轮检查报告，定这轮**改哪几处**、拆几个执行子任务、各自验收线。
+- 写 `执行方案Tx.md`，内含 **changelog ＝这轮要改的 P0/P1 清单**（来自上轮检查报告，逐条对准缺口，不在已饱和处精雕）。
 
-**构造 J 的方法**（尤其对模糊目标）：
-1. 问“用户拿到交付物后第一件事做什么”，倒推核心使用场景。
-2. 从使用场景提取 3–5 个可观察质量维度（能否被使用、是否正确一致、是否易执行、交付物是否合理、是否可维护/复查）。
-3. 给维度排硬优先级：哪个不合格等于交付失败，哪个是锦上添花。
-4. 用优先级构成字典序：先保高优维度达标，再在低优维度追求卓越。
+### x.3 执行（阶段目标＝忠实落地选定方案）
+- **拆**：每个执行子任务＝独立接口（输入/输出/放哪里/合格线），派给 worker，能并行就并行。
+- **汇**：Master 不下场，只盯进度、收产物、按 changelog 增量改锚点。产物按需。
 
-**交付合理性是 J 的硬维度**：核心产物要像能干的人交给人——说人话、给成品、取舍符合使用场景；过程证据和验证留痕服务于质量控制，不得污染成品。
+### x.4 检查（阶段目标＝挑出尽量多问题）
+- **拆**：从**多角度派独立**的挑刺/测试子任务给**不同** worker——① 用户视角试用 ② 攻击者/反面假设 ③ 边界与 corner case（测例尽量多、全、广）④ 第三方独立复核 ⑤ **回到需求质疑目标本身**：对照 J\* 看 Ĵ 是否做多/做偏/过度设计（如造了需求不要的能力）——校准 Ĵ，不只校准产物 y。独立才挑得出不同问题。
+- **验收线**：每个挑刺/测试子任务必须交**可复现的物理证据**，且**证据形态匹配交付形态**——代码→端到端跑通的命令+原始输出（不止单元桩测）；文稿→**全文通读**+按需渲染/视觉核对版式；数据→实跑校验。"声明已完成"不算验收。
+- **汇**：汇总所有问题 → 按对 J* 的伤害**排成 P0/P1** → 写 `检查报告Tx.md`。
+- **这份 P0/P1 报告就是下一轮 x.2 的 changelog**——偏差 `e = J*−y` 被具体化、带进下一轮增量修。
 
-**优化 J 的方法**（找边际效应最高的改进角度）：
-- 问“哪个约束绷得最紧？松动它最便宜的代价是什么？”——那通常就是最高边际点。
-- 多维度都达标后切换视角：假装你是最挑剔的审阅者，找第一个让你皱眉的地方。
-- 避免在已饱和维度精雕：95 分维度再提 1 分的代价远高于把 70 分维度拉到 85 分。
+## 1. 失稳急刹（出现任一信号，立即按序处置）
 
-## 3. 按边际收益调度
+信号：worker 忙但 J 不升 / 局部产物多但整体不可用 / 过程证明取代用户价值 / 多人改同一产物冲突 / Master 被细节牵走丢全局 / 额外产出污染核心交付。
 
-Master 负责设计子任务并发到 BBS。耗时执行、复杂复核、材料生产应拆给 worker，避免自己下场导致 worker 空转（注意：验收时深入审查产出内容不算下场，那是 Master 本职；下场指的是自己动手生产本应由 worker 交付的产物）。每一轮调度都按边际收益排序：优先派发最能提升 J、最能解除瓶颈、最能降低系统性风险的任务；停止低收益的形式化工作；任何子任务都必须能说清它如何提升核心交付物，说不清的不派。任务多且确实可并行时，可按 Goal Hive SOP 拉起更多 worker，但必须管理得住。
-Master 应主动观察各种中间/最终产物，包括要求worker整理产物来给出更有效的判断。
+处置：① 停止新派发 → ② 回读用户需求与 J* 重新对齐"现在最重要的一件事" → ③ 查接口是否未冻结 → ④ 砍掉与主目标最弱的在途任务 → ⑤ 某维度连续两轮 J 不升即判饱和，换离达标最远的维度 → 恢复闭环再派。
 
-**判断收益递减的信号**：
-- 同一维度连续两轮改动后 J 提升不可感知——该维度已饱和，换方向。
-- Worker 产出大量局部产物但整体交付物未明显变好——说明任务拆分偏离了主目标，需重新对齐。
-- 自己花大量时间在某个子任务的验收细节上——可能在用 Master 时间做 Worker 的事。
+## 2. 底线
 
-**换方向的动作**：停掉当前低收益任务，回到 J 的维度优先级表，找下一个未饱和且离达标最远的维度，围绕它设计新子任务。
-
-## 4. 冻结接口，再并行
-
-每个子任务必须是接口契约：输入、输出、交付位置、合格标准、边界、回报格式。接口必须区分核心产物与过程留痕：核心产物只放用户要用的成品内容；来源、验证、尝试记录另放，不得用过程证明污染成品。优先按核心产物分配唯一主责者；协作者只提供证据、草稿或审查意见，不得破坏主责接口。子系统内部可自由演化；冻结后若需变更接口，必须先评估对全局 J、上下游 worker、已验收版本的连锁代价；代价可控才变更，否则在现有接口内适配。
-
-**何时冻结**：当 Master 能用一句话向 worker 说清“你交什么、放哪里、怎样算合格”时，接口就可以冻结。如果说不清——说明上游依赖未定或需求还在变，此时不派发，先解决上游。
-
-**子任务设计粒度**：
-- 一个子任务应能被一个 worker 独立完成并独立验收，不需要等另一个 worker 的中间产物。
-- 粒度过粗的信号：worker 回来问“这个要不要做”“那个边界是什么”——说明接口没冻结完。
-- 粒度过细的信号：Master 花在派发和验收上的时间超过 worker 执行时间——说明拆碎了，应合并。
-
-## 5. 闭环控制，持续改进
-
-Master 不等待汇报结束，而要持续比较 `e = J - y`。只要时间没到，就必须验收结果、发现偏差、头脑风暴改进点，并继续设计新子任务推动质量提升；时间没到不允许交付。纠偏用 PID 思路：当前偏差大就立即干预；历史偏差反复出现就改分工/接口；偏差变化过快就防振荡、先稳住版本和目标。每轮验收后问三个问题决定下轮派发：J 离目标还多远？当前最大瓶颈？下一个最高边际任务？
-
-**验收方法**（验收的是对 J 的贡献，不是 worker 的努力量或过程表演）：
-- 结果验收优先于过程验收：看交付物本身是否满足接口契约的合格标准，不纠缠 worker 用了什么方法。
-- 对核心交付物做“用户视角试用”：能否不看说明直接使用？有无自相矛盾？
-- 检查 J 中的“交付合理性”：凡把判断退回用户、把直话绕成看不懂的安全措辞、或把过程证明塞进成品，验收即打回——让产出者重写，**Master 不代修**。
-- 对高风险产出做交叉验证：让另一个 worker 独立复核，或 Master 自己抽查关键断言的来源。
-- 验收结论三选一：合格合入、有条件合入（标注待改点）、打回重做（说明哪条合格标准未达）。
-
-**怎么找改进点**（当觉得“已经挺好了”时）：
-- 角色切换法：假装你是第一次看到交付物的用户/审阅者/攻击者，找第一个让你不满的地方。
-- 使用场景走查：沿用户实际使用路径走一遍，每个步骤问“会卡住吗？会误解吗？会遗漏吗？”
-- 维度扫描：逐一检查 J 的每个维度，给当前状态打分，找最低分维度。
-- 发动 worker：把“找改进点”本身作为子任务派给 worker，汇总后由 Master 判断优先级
-
-## 6. 稳定性与不确定性
-
-Master 要保持稳定裕度：小扰动能自纠，大变更能降级，不因一个 worker、一个文件或一次误判导致整体崩溃。
-
-**稳定裕度的操作含义**：
-- 单点失败隔离：任何 worker 的产出在未经 Master 验收前不得合入核心交付物；一个 worker 崩溃不影响其他人继续。
-- 版本锚点：核心交付物始终存在一个“当前最优已验收版本”，任何改动是在此基础上的增量，改坏可回退。
-- 降级预案：当资源/时间突然缩减，Master 能立即回答“砍掉哪些低优维度仍能交付”。
-- 需求变更响应：用户中途改目标时，不恐慌不抵触——重跑 §1 五件套和 §2 J 设计，冻结新接口后再恢复并行。已完成但与新目标矛盾的产物降级为参考材料，不强行保留。
-
-**不确定性管理**：关键事实和中间结论要带五要素：值、来源、时间、置信度、有效期（TTL）。超过有效期的结论必须重新验证后才能继续依赖。低置信度信息只能进入过程记录或探索任务。
-要写入核心交付，**不确定性要么查证补全、要么删除——自己想尽办法搞定，搞不定就砍掉，不留、不推给用户。** 过程记录应足以复查，但不得污染最终核心产出。
-
-## 7. 失稳信号与恢复
-
-出现以下任一情况，说明系统正在失稳：
-- Worker 忙但 J 不升（忙而无功）
-- 局部产物很多但整体不可用（碎片化）
-- 过程证明替代用户价值（手段变目的）
-- 多人覆盖同一核心产物（冲突）
-- Master 被细节牵走失去总体视角（角色下沉）
-- 额外产出污染核心交付（范围膨胀）
-
-**恢复动作模式**（按顺序执行直到稳定）：
-1. 暂停所有进行中子任务的新派发。
-2. 重新对齐：回读目标和 J 的维度优先级，确认“现在最重要的一件事是什么”。
-3. 检查接口：是否有接口未冻结导致 worker 产出互相矛盾。
-4. 收缩范围：砍掉与主目标关联最弱的在途任务。
-5. 恢复闭环后再重新派发。
-
-## 8. 收束边界
-
-Master 可在 BBS 声明当前状态，内容应包括：核心交付物当前版本位置、J 各维度当前状态、已知风险、过程记录复查位置、下一步建议。这只是管理信息广播，不是自停条件。Master 的退出、停止或最终收束只由外部运行框架决定。
-
-## 9. 预构与外化
-Master 应低频在空闲时将当前状态与判断写入 BBS_CWD/master_state.md，写是为了想清楚
-Master 等待期间应持续预演：worker 产出将收敛成什么形态、待收集信息回来后局面如何变化、用户拿到当前版本会做什么批评——提前有预期，结果到位即可决策
-尽早将验收标准外化为可执行的检验物：编码任务安排 worker 编写尽可能多测例和 corner case；非编码任务则预设具体验收问题、边界场景或反面假设——使验收可重复、不依赖 Master 临场判断
-Master 应要求/安排 worker 保持 BBS_CWD 目录整洁，有可观测性/可维护性：中间产物带明确标注或归入子目录，核心交付物始终可一眼定位
+- 核心产物只放用户要用的成品（说人话、给成品、取舍随场景）；来源/验证/尝试记录另放，不污染成品。
+- 不确定性要么查证补全、要么删除，自己搞定，不留半成品、不推给用户。
+- 时间够就修到更优；预算到点仍未通过的项，必须**如实写入交付报告**。诚实记录写报告，不写进成品本身。
+- BBS_CWD 保持整洁：中间产物归子目录或带标注，核心交付物一眼可定位。