Files
admin c1b5e4d966 chore(工作区): 全量入库 + 补齐 .gitignore(以工作区为准)
- 变更规模:新增 514 / 修改 62 / 重命名 155 / 删除 4(归档重组与文档轮次)
- .gitignore 修:`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级(归档/db-cwd归一-…),
  目录搬进 归档/配置与备份/ 后**静默失效**,43 MB 的 DB 备份又变成未跟踪
- .gitignore 补:嵌套 git 内部数据(归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/)
- .gitignore 补:运行态与部署副本(.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*)
- .gitignore 补:备份件(*.bak-*)
- 未跟踪文件从 2190 降到 890(其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件,按口径入库)
2026-10-10 23:13:22 +08:00

92 lines
5.7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 目标执行状态
> 🔴 **本文件=检查会话判断目标状态的唯一依据**(用户 2026-10-03 10:5x 要求逐字:
> 「目标执行情况也要有文档,这样检查会话**直接根据文档判断目标状态**,避免检查会话到处找信息」)。
> ⛔ 检查会话**不许再去工作区里翻文件**找目标状态 —— 读本文件 + `tasks.json` 就够了。
- **目标标题**:检查会话协作是否运行正常 + 协作机制问题排查与修复
- **目标简称**:本机协作
- **目标生命周期**:**进行中**
- **本文件由谁更新**:**目标检查会话**(`[协作]-[目标检查]-…`)在核对完成后改「目标生命周期」并更新本文档
- **最后实测时间**:2026-10-03 10:52(所有读数均为**现测**,⛔ 不是转述)
## 一、怎么用这份文档(检查会话照此判断,别自己另立口径)
1. 先读 `tmp/supervise-inbox/tasks.json`(队列四态台账)—— 那是「活干完了吗」。
2. 再读**本文档** —— 那是「目标达成了吗」。
3. **⛔ 两者都不许跳**。三路取并集,**任一路"没完"就是没完**:
- 台账里有 `pending`/`running`/`blocked` 的件;
- 任务图(`交付物/任务图-会话协作自检.json`)里还有 `status != done` 的节点;
- **本文档第二节里还有任何一条判据没过**。
4. 全部满足 ⇒ 才可把目标生命周期改成「已完成」,并在本文档把「结论」那一行更新掉。
## 二、验收判据(逐条,⛔ 判据值是中文写法:`过|…`/`🔴 不过|…`)
### V1 协作程序常驻一直运行
- **结论:过**
- **实测**:`supervise-heartbeat.json` → `pid=38988`、`round` 持续上涨(10 s/轮)、`ts_h=2026-10-03 10:35:21`。
- **判据**:pid 活 **∧** 心跳新鲜(<90 s)—— 与 `selftest.py::t_supervise_ensure` 同一口径。
### V2 队列与检查会话链路
- **结论:过**
- **实测**:`tasks.json` 读数 `S5=done(带 artifact)`、`S12=done(带 artifact)`;
`queue_pending()=0`(真源 `tasks.json` 四态口径);闸②`_all_sessions_idle()=True`、闸④`ws_pending_schedules()=[]`、闸③ 走 `queue-empty`。
- ⚠️ **旧判据「跟进会话链接得住(零条活着 / 今日投递成功 0 次)」已作废** —— 唤醒/跟进/队列投递
**整套退役**(用户 2026-10-03 定案),那条判据**永远不可能满足**。⇒ 本条改为校验**现行链路**。
### V3 协作会话在台账里留有产物文档
- **结论:过**
- **实测**:`S5.artifact` 指向 `references/architecture.md §2.3.0f`;`S12.artifact` 指向 `机制排查与修复/S12_清理报告_20261002.md`。
- **判据**:每条 `done` **必须**有 `artifact`。⇒ 机制侧已加硬约束:`--report --state done` **缺 `--artifact` 直接拒收(rc=3)**。
### V4 看板可服务
- **结论:过**
- **实测**:`netstat` → `127.0.0.1:8788` **LISTENING**(pid 41764);`/board.json` → HTTP 200、`ts=2026-10-03 10:52:35`。
- **判据**:能起得来 + 回环 HTTP 200(⛔ 不看页面像不像,看接口读数)。
### V5 机制自测全绿
- **结论:过**
- **实测**:`selftest.py` → **PASS 55 / FAIL 0**。
- ⚠️ **基线是 FAIL 1**(`技能侧零项目串` 那条,已于 2026-10-03 上午修掉:域键锚点词表三处对齐 + 结构性豁免)。
⇒ 判据写成「**FAIL 0**」,⛔ 不写「与基线持平」—— 那种写法会让真红也通过。
### V6 协作程序格能显示"检查程序在运行"
- **结论:过**
- **实测**:`/board.json` → `runtime.check = {"n":0,"label":"无检查在跑"}`。
**端到端验过**:临时把一条检查会话置 `working` ⇒ 线上 `runtime.check.n=1`、`label=有结果检查在运行`;还原后回 `n=0`。
- **判据**:`runtime.check` 字段在位 + 与真库 `working` 检查会话数**一致**(不许恒绿)。
- ⚠️ **旧判据「跟进会话角色落地(名册 11 条)」已作废** —— 跟进会话整套退役。
### V7 检查会话按规范命名、能被看板认出
- **结论:过**
- **实测**:排期名=`[协作]-[结果检查]-<工作区>-第N棒`(**两级方括号前缀**);
`parse_session_name()` ⇒ `role=worker / topic=结果检查 / ok=True`;
线上 `/board.json` 里 `44b547d4` 的 `role=协作会话`(改前是「主会话」)。
- **判据**:`role=worker` + `topic` 非空 + **两侧解析零漂移**。
- ⚠️ **旧判据「开工建齐三类(唤醒/协作/跟进)」已作废** —— 会话**只剩两类**(主会话/协作会话)。
## 三、结论
- **7 条判据全部通过** ⇒ 目标「检查会话协作是否运行正常」这一部分**已经达成**。
- ⚠️ **但整体目标未完成** —— 标题里还有「**协作机制问题排查与修复**」那半句,
而任务图(`交付物/任务图-会话协作自检.json`)里仍有 `status != done` 的节点。
⇒ **目标生命周期维持「进行中」**,⛔ 不得改成「已完成」。
## 四、旧判据的作废清单(⛔ 别再拿它们判)
| 旧判据 | 作废原因 |
|---|---|
| V2-跟进会话链接得住(零条活着/今日投递成功 0 次) | 唤醒/跟进/队列投递**整套退役**,永远不可能满足 |
| V6-跟进会话角色落地(名册 11 条) | 同上 |
| V7-开工建齐三类会话(唤醒/协作/跟进) | 会话**只剩两类**(主会话/协作会话) |
⚠️ 本清单**不是为了好看** —— 留着它们,目标状态就**永远判不出来**(同族红线:
「一条判据都没有 ⇒ 判不出来,⛔ 不许当成已完成」的反面:**有一条永远红的 ⇒ 也不许当成未完成**)。