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/ 知识文件，按口径入库）
This commit is contained in:
admin committed
1 parent
30b46dbd0c
commit
c1b5e4d966
735 files changed
+153192
-2415
No files matched your search
@@ -0,0 +1,82 @@
|
||||
# 执行记忆 · 第 4 类「队列上报的跟进会话」
|
||||
|
||||
> 只记**结论、数值与判据**。⛔ 不记操作手法、不记平台内部结构的探查方式
|
||||
> —— 本文件下一轮会被一起读进上下文，写进去的东西会影响下一轮能否正常开跑。
|
||||
|
||||
工作区：`E:/ProgramData/AIProject/ai1net-dsh-server`｜标题前缀：`[跟进]-<类别>-<具体>`
|
||||
|
||||
## 职责（只有一件：判断要不要开一条协作会话）
|
||||
|
||||
两条入口、同一个动作：收到投递轮推来的上报 ／ 被本排期按点拉起（每小时一次）。
|
||||
|
||||
本会话不做具体活：不改 `tasks.json` 的 `state`、不写 `blocked.json`、不派活、不抢文件锁
|
||||
—— 那些是它判断后开出来的那条协作会话的事。
|
||||
|
||||
## 固定动作
|
||||
|
||||
1. 跑 `python state.py`。
|
||||
2. 读 `tmp/supervise-inbox/` 的 `queue.json`／`tasks.json`／`TO-MAIN.md`／`NEED-USER.md`／`blocked.json`／`advance.md`，
|
||||
以及 `交付物/任务图-会话协作自检.json`。
|
||||
3. 判断并报告：要开 ⇒ 开**一条**协作会话（走一次性排期入口，标题第 2 级取 `goal.json` 的 `topics`）；
|
||||
不开 ⇒ 说明属于三种中的哪一种（全 pass／已有会话在推／受阻且已挂人工解除条件）。
|
||||
|
||||
## 既有约定
|
||||
|
||||
- 台账四态只有 `pending`／`running`／`done`／`blocked`；改台账走 `collabd.py --report`，不手改 `tasks.json`。
|
||||
- 写 `NEED-USER.md` 一律走 `collabd.py` 的 `need_user()`：同一句 600 秒内不重写；人工写的「## 解除条件」原样保留。
|
||||
- 看板端口 `127.0.0.1:8788`；本机访回环一律 `curl --noproxy '*'`。
|
||||
- 自测：`<skill>/scripts/selftest.py`（或 `install.py --verify`）。
|
||||
- 会话日志到约 10 MiB 上限后，该会话会收不到新消息 ⇒ 排查时先查这件事。
|
||||
|
||||
## 轮次记录（只留结论与数值）
|
||||
|
||||
- 10-01 21:0x（首轮）：M5／M6 复核通过维持 `done`；**M7 由 `done` 降级 `running`**（实跑自测非全绿）；
|
||||
S5 受阻（无活主会话）⇒ 已具名挂人工解除条件。
|
||||
- 10-01 23:25（第 2 轮）：让位＝唯一活 `[跟进]` 就是本会话自己 ⇒ 照做。
|
||||
⇒ **开出 1 条**：`[协作]-[机制排查与修复]-S8 常驻投递载体（跨 turn 存活）`。
|
||||
- 10-02 00:34（第 3 轮）：任务图非 done＝S8/S9/S5/S6/S7，无协作会话在推。
|
||||
⇒ **开出 1 条**：`[协作]-[会话协作自检]-S6 建齐三类会话`（选它＝唯一"依赖已满 ＋ 不需写文档库 ＋ 无人在推"的件）。
|
||||
- 10-02 01:48（第 4 轮）：**不开**。S8／S9 目标文件属机制层、被孤儿全局锁挡着；S5 需人；S7 依赖未满。
|
||||
- 10-02 02:56（第 5 轮）：**不开**（同上）。`acceptance_state` 仅 `V2-主会话可响应` 待重验。
|
||||
🔴 读数：`READY.md` 报「S9 可派未派」＝**假阳性**，机械程序不看文件分层。
|
||||
- 10-02 04:06：**本轮未被正常受理**（平台侧拒绝受理，非本会话出错）。
|
||||
- 10-02 05:05（第 6 轮）：**不开**（「不建」第 ③ 类）。逐件同一条根因：S8／S9 的目标文件属机制层，
|
||||
全局锁 OWNER 仍逐字是 `会话协作-机制排查与修复-20261001`（10-01 20:41 起，已连续 4 轮同读数）⇒ 派了必停手；
|
||||
S5＝无活主会话；S7＝依赖未满。
|
||||
🔴 佐证：上一轮派出的 `[协作]-会话协作自检-验收`（448cb6eb）已完成但日志仅 746 B（基本空转）
|
||||
⇒ 受阻件派出去也不会产出。
|
||||
|
||||
- 10-02 06:31（第 7 轮）：**不开**（「不建」第 ③ 类）。✅ **孤儿锁已消失** —— 全局锁 OWNER 逐字变为
|
||||
`接续 · 会话机制合并包 · 任务4b-4d-6`（开始 10-02 06:29），持锁者**正在执行**（会话 `3f43ce71`，
|
||||
status=`working`、06:31:42 仍在刷新、在机制自身活会话集内）⇒ S8／S9／S5 同因受阻，但**原因已从
|
||||
「孤儿锁」变成「锁被活会话正常持有」** ⇒ 属正常排队，**不需人工介入**（上轮挂的人工解除条件已失效）。
|
||||
🔴 活会话集（机制自身函数读数）＝恰好两个：`3f43ce71` ＋ 本会话 `58c130c5` ⇒ 无别的活 `[跟进]`，不让位。
|
||||
🔴 **全局锁解除授权未使用**：前置判据①（无主会话在执行）不成立（`3f43ce71` 在机制角色表里＝`main`）；
|
||||
②（锁被已结束的会话持有）不成立（持有者就是那条活会话）⇒ 判定「不满足 ⇒ 只报告、不动手」。
|
||||
⚠️ **新读数（供机制侧）**：S5 受阻登记的解除条件①「用户新建一条主会话」**已事实出现**（有活主会话）。
|
||||
|
||||
- 10-02 07:35（第 8 轮）：**开出 1 条** —— `[协作]-[机制排查与修复]-S8 常驻投递载体（重派·锁已清）`
|
||||
（一次性排期 07:40，automation `73f138ce`）。**本轮判据与读数**：
|
||||
✅ 第 0 步不让位：本工作区**活会话集合＝仅本会话自己** `57f58ecf`（全表唯一 `working`）⇒ 除本会话外无活 `[跟进]`。
|
||||
✅ **堵点解除**：全局执行锁 = **无锁**（`handoff-guard.sh --status` 明示「无全局锁」）。上轮（06:31）记的持锁者
|
||||
`3f43ce71`（`接续 · 会话机制合并包 · 任务4b-4d-6`）已于 **07:34:20** 变 `completed` ⇒ S8／S9 的阻塞理由
|
||||
（「全局锁被持有」）**已消失**；`blocked.json`／`queue.json` 里 S8 那条解除条件**已过期**。
|
||||
✅ 任务图 9 节点：done ＝ S1–S4／S6；非 done ＝ S8(todo)／S9(todo)／S5(todo)／S7(todo)。
|
||||
可派集合（deps 满足）＝ **S8、S9**（deps 皆为 `['S4']`）；S7 依赖未满（等 S8/S9/S5/S6）；
|
||||
S5 deps 满足但**受阻** —— 仍无活主会话，`NEED-USER.md` 第 ① 类解除条件挂着 ⇒ 属「不建」第③类。
|
||||
✅ `goal.json.acceptance_state`：仅 `V2-主会话可响应`＝待重验，其余 6 条（V1/V3/V4/V5/V6/V7）全过。
|
||||
🔴 **选 S8 的依据**：`rules.dispatch`「优先派关键路径上的节点」＋ `critical_path`＝`S4→S8→S9→S5→S6→S7`，
|
||||
S4 已 done ⇒ 下一件即 S8（queue.json 的 `head=S9` 是因 S8 被列在 `blocked`，该 blocked 理由本轮已失效）；
|
||||
同线互斥 ⇒ 一次只开一条，S9 留作下一棒。
|
||||
⛔ **全局锁解除授权未使用**：前置判据①成立（无主会话、无协作会话在执行）但**②不成立**（根本没有锁，
|
||||
非「锁被已结束会话持有」）⇒ 无锁可释放 ⇒ **只报告、不动手**。
|
||||
|
||||
## 待办（机制侧，非本会话职责）
|
||||
|
||||
- ~~孤儿全局锁是真正的堵点~~ ⇒ **10-02 07:35 已确认解除**（锁空闲；原持锁会话 07:34:20 `completed`）。
|
||||
⛔ 「人工释放孤儿锁」这条解除条件两次都已过期，不要再按它办。
|
||||
- 常驻投递仍未回来 ／ S9（投递「目标忙」判据）仍待办 ⇒ 等 S8 那一棒做完再判。
|
||||
|
||||
- ~~孤儿全局锁是真正的堵点~~ ⇒ **10-02 06:31 已自愈**：锁现由一条活会话正常持有，等它做完即可，
|
||||
⛔ 不要再按"人工释放孤儿锁"办（那条解除条件已过期）。
|
||||
- 常驻投递仍未回来 ⇒ 投递只在跟进会话恰好活着时才到得了，其余时间稳定空转。
|
||||
Reference in new issue
Block a user