№ · HANDOFF 杂项 CH.07.05
主页 · 🤝 Handoff 杂项 · Thread Hygiene

Thread Hygiene

📅 2026-07-05 · 📦 14.7 KB · 🤝 Handoff 杂项 · 📝 MD 文档 🆕 14d 🏷️ Owner🏷️ Year1
  • 当前执行面默认只保留两类线程：docs/handoff/index.md Canonical Threads 里的基础控制线程，以及当前 In-Flight Business Cards 明确绑定的 owner threadId；其余旧主管 / PM / 长工 / 发布线程在完成替换、收口或失效后，应转为历史线程。
  • canonical 线程默认应固定在侧栏顶层；若主管主线程、PM 主线程、日版本监督长工或固定发布长工被取消固定或被埋到普通线程堆里，监督线程应优先恢复 pin，保持执行面可见。
  • 巡检线程列表时，只把 cwd=E:\同福客栈挂机游戏 且被当前 docs/handoff/** canonical 映射或当前 In-Flight Business Cards owner threadId 引用的线程视为本项目当前执行面；其它仓库里即使标题相同、模块名相同，也只按外部历史线程或无关线程处理。
  • 线程列表工具的 query=\"cwd:...\" 过滤结果当前不稳定；若按 cwd:\"E:\\同福客栈挂机游戏\" 查询返回空列表，不得直接据此判断“没有同福线程”。应退回使用更稳的交叉判断：docs/handoff/index.md 的 canonical 映射 + 线程 id 直查 + 标题关键词（如 同福客栈、[大管家]、[PM]#、[长工]#、[短工]#）+ read_thread 复核。
  • 同理，list_threads 直接以 thread id 作为 query 也可能返回空结果；这不代表对应线程不存在、已失效，或不再属于当前执行面。thread id 精确核查应优先用 read_thread，而不是把 list_threads(query=<thread-id>) 的空结果当成负证据。
  • 不只 query=\"cwd:...\"，任何单一线程 query（包括 长工、短工、[长工]#、[短工]# 等标题关键词或带特殊符号查询）返回空，都不得单独当成“没有对应线程 / 没有对应漂移”的证据；这类查询最多只算辅助信号，仍需回到 docs/handoff/index.md 的 canonical 映射、线程 id 直查、标题关键词交叉判断与 read_thread 复核。
  • 同理，query=\"同福客栈\" 这类仓库名 / 项目名关键词也不可靠；同仓库 worker 标题可能只写模块名与身份前缀，不带“同福客栈”字样，例如 [短工]#闯荡阻塞修复@v0.4。因此 query=\"同福客栈\" 返回结果不全时，不得据此判断“当前只有 canonical 线程”或“没有新短工”。应改用更宽的最近线程列表，再按 cwd=E:\同福客栈挂机游戏、canonical 映射、标题关键词交叉判断与 read_thread 复核。
  • 同理，任何单一线程 query 一次命中多条结果时，也不得按原始命中数直接吸收为当前执行面；结果里可能混入其它仓库、其它项目、其它 supervisor 的同名角色线程。只有 cwd=E:\同福客栈挂机游戏 且被当前 docs/handoff/** canonical 映射或当前 In-Flight Business Cards owner threadId 引用的线程，才可进入当前执行面判断。
  • docs/handoff/** 里声明为 canonical 的主管主线程 / PM / 长工 / 发布线程，以及当前 active owner task 明确绑定的 owner 长工，都是 E:\同福客栈挂机游戏 专用执行面；其它仓库、其它项目、其它 supervisor 不得借用这些线程继续派活、同步状态或吸收回包。
  • 若 canonical 线程或当前 active owner task 绑定的 owner 长工线程收到来自非 E:\同福客栈挂机游戏 项目的派发、同步或发布相关消息，监督应把它视为“跨项目借用风险”，按线程污染 / 误用信号处理，而不是把该消息继续吸收为同福当前状态。
  • 若 canonical 线程存在未读监督 / 派发 / 自限回合，先清最近一条未读回合并吸收规则，再继续做派发、监督、发布资格判断或巡检结论；不要带着未读状态继续外推当前执行面。
  • 侧栏 hasUnreadTurn / 未读徽标只能当风险信号，不单独等同于“线程尚未吸收规则”；是否已吸收，以该线程最近一条监督 / 派发 / 自限消息是否已得到对应 final reply 为准。
  • 若已通过 read_thread 确认该未读仅是规则同步后的元数据残留，监督线程不要为了清 UI 未读徽标而再次打扰该线程；保持当前判断即可。
  • 若 canonical 线程的侧栏 preview 仍停留在更早的历史启动词、旧派发文本或旧监督消息，但 read_thread 已确认最近一条相关回合是 final reply，且没有新的 truth source、没有新的线程 updatedAt 跳变，则把它视为侧栏历史预览残留，而不是当前执行口径漂移；不要为了“刷新 preview”反复发送新的待命同步、规则同步或催办消息。
  • 对固定发布长工这类已知“污染只读线程”，若 read_thread 已确认最新监督 / 自限回合是无敏感信息的 final reply，但侧栏 preview 仍停留在更早的历史敏感回合，则把它视为侧栏历史预览残留，而不是当前执行口径漂移；不要为了“刷新 preview”反复发送新的待命同步。此时继续以 docs/handoff/index.md、docs/handoff/release-rule.md 与该线程最近已确认 final reply 为准，并保留“需轮换”的结论。
  • 若监督结论、summary package、线程巡检回包或后续派发 gate 需要提及该固定发布长工，只允许使用线程 id、线程标题与“污染只读发布线程 / 只读待轮换”这类脱敏状态描述；不得复制、转述、改写或概括其侧栏 preview / 历史中的敏感残留内容。
  • 侧栏 status: notLoaded / 线程未加载只表示客户端当前未把线程内容载入，不单独等同于线程有新动作、需要催办，或当前执行面发生漂移。
  • 若 canonical 线程显示 status: notLoaded，但 updatedAt 未变化，且 read_thread 已确认最近一条相关回合就是 final reply，则把它视为加载态残留，不单独升级为漂移证据。
  • 对这类加载态残留，监督线程不要为了“唤醒 / 加载线程”而再次发送无业务意义的提醒、自检或催办消息；保持当前判断即可。
  • 同理，历史短工线程若在线程列表里仍显示 status: active、activeFlags: waitingOnApproval 或同类运行态，也不得单独当成“仍在执行 / 待回包 / 可继续派发”的证据。只要当前 docs/handoff/index.md、docs/handoff/current-dispatch-shortlist.md 或对应历史 session 已把它收成 summarized、verified、stalled / blocker-evidence，或已被 canonical replacement lane 吸收，就继续按历史线程 / 漂移噪音处理，不恢复任何 live 执行权。
  • 若向 canonical 线程发送最小监督/纠偏消息时返回运输层错误，例如 no active turn to steer，监督线程不要围绕同一条消息反复重试；应立即退回当前 truth source（docs/handoff/index.md、当前 daily plan、当前 task/session 卡、最近已确认 final reply）完成判断。是否把该线程长期降级为“可 read、暂不可 steer”，以当前 docs/handoff/index.md 的显式状态为准；单次错误本身只算一次性失败信号，不自动外推成长期状态。
  • 未被 docs/handoff/** 当前卡面引用的同福线程默认不要 pin；避免旧业务线程或旁路线程继续伪装成当前执行面。
  • 历史线程处理顺序固定为：先改名加 [历史] 前缀，再归档；避免它们继续在侧栏中冒充当前角色。
  • 已 summarized / verified 且不再挂在 In-Flight Business Cards 的短工线程，也应转历史并归档；不要继续留在当天执行面。
  • 若历史短工线程已经满足以上条件，且在线程列表 / docs/handoff/index.md / 当前 canonical 执行面里都已不再表现为当前执行面，但 set_thread_archived 对该 inactive 线程返回未持久生效，则把它视为归档工具限制，而不是当前执行面漂移；不要围绕同一条 inactive 历史短工反复重试归档。
  • 当 docs/handoff/index.md 已显示 loop state: summarized、dispatch state: standby 且 In-Flight Business Cards 为空时，监督进入稳定待命巡检态：默认只低频检查 4 类漂移信号，不再重复做全量线程回放或全仓文档复扫。
  • 在上述稳定待命巡检态下，默认读取顺序应进一步收紧为：先读 docs/handoff/index.md，再按 canonical 线程 id 直读最近相关回合；只有当需要判断“是否混入了新的同福线程 / 旧线程重新冒充当前执行面”时，才升级到宽范围线程列表扫描。不要把宽列表扫描当成每轮默认动作，以减少噪音、降低 token 消耗，并避免把已知污染发布线程的历史 preview 残留反复带入监督上下文。
  • 若上一轮监督已经确认 docs/handoff/index.md、最新 business task/session 时间戳、以及 canonical PM / 长工线程的 updatedAt 都未变化，则本轮默认可以直接复用“稳定待命、无新漂移”的判断，不再重复展开对应线程正文；只有当这三类时间戳/状态中任一项发生变化，或命中 4 类漂移信号时，才重新读取线程正文做增量复核。
  • 但对 canonical 线程本身，不要把顶层 thread.updatedAt 当成唯一变化信号；某些线程即使已有新的相关 final reply，顶层 updatedAt 仍可能滞后或不敏感。更稳的增量判定应优先比较“最近一条相关 turn 的 id / completedAt 是否变化”；只有当最近 turn 标识不变时，才可把该线程视为无新监督变化。
  • 对长工的最小专向巡检也保持低频：默认只检查两条 canonical 长工是否仍与 docs/handoff/index.md 一致，即 019ef251-8479-7091-b73e-2662c3606261（日版本监督长工）与 019f09d6-687c-78b0-8443-d04787fe850b（固定发布长工）。若 docs/handoff/index.md 仍为 loop state: summarized / dispatch state: standby、In-Flight Business Cards 为空，且这两条线程最近相关回合仍是已确认 final reply，则继续按待命长工处理，不额外打扰；只有当 truth source 变化、线程 updatedAt 变化、或命中 4 类漂移信号时，才升级长工深查。
  • 这 4 类漂移信号固定为：
    1. 同福仓库内出现未授权新的主管 / PM / 长工 / 发布线程，或旧线程重新冒充当前执行面。
    1. 短工被误升成长工，或外部仓库线程被误判为同福当前执行面。
    1. backlog-only / 候选模块被提前写入 docs/handoff/**、docs/daily-plans/**、docs/plans/**、建卡或进入派发面。
    1. 污染只读发布线程被误当成真实发布线程，或发布规则 truth source 再次发生口径漂移。
  • 共享工作区里的实现改动、调试脚本、截图、预览产物、备份文件与本地工具输出，只能先当“工作树漂移信号”处理；若当前 docs/handoff/index.md、daily plan 或 task/session 卡没有明确吸收它们，不得据此单独判定“已有新在途 lane”“已有新 truth source”或“应直接派发新 worker”。
  • 同理，若某条 live owner 只是预锁了 child gate，而其文件边界里已经存在未跟踪目录、历史实物、半成品实现或只完成一半的文档证据，也不得据此外推“这条 gate 已经启动 / 已经完成”。只有当该 gate 的真实短工线程、正式 callback、或被当前 control-plane 吸收的新 task/session 同时出现时，才可升级成当前执行态。
  • sibling gate 必须分别判定：一条 gate 的历史实物或旧 callback，不得单独证明另一条 sibling gate 已闭环。例如 Day 4 R3 有历史联机骨架实物，并不等于 R6 字段净化已完成；必须逐条看当前 owner 卡、当前 callback 与对应文件证据。
  • closeout / 收口模板若仍保留“模板”“占位”“真填待补”等明示占位文本，只能按半份证据或漂移信号处理，不得把它直接当成“本轮已收口”或“已满足下一轮派发前提”的证明。
  • 同理，若 docs/handoff/tasks/ 里提前出现来自 future-dated 日计划 / 周计划 / 5 日计划的预写 task 卡，但 docs/handoff/index.md 尚未吸收，且该卡仍为 current state: pending + next action: wait for direct truth source（或同义等待态），则它只算合法占位，不算当前执行面，也不构成 PM 派发授权。只有当主会话明确拍板且对应 lane 正式吸收到 docs/handoff/index.md 后，才允许进入派发判断。
  • 同理，若 docs/handoff/tasks/ 里保留的是更早一轮的历史 prep/owner 卡（例如 2026-07-04-*owner 这类周末 prep 卡），且其正文已明确写成 current state: summarized / verified，next action: none，或已声明“只保留为历史证据 / 不再作为 live owner board 或 today-dispatch 依据”，则它即使仍放在 tasks/ 目录、文件名仍带 owner、或本地 mtime 较新，也只按历史 prep 证据处理；目录位置、命名样式与较新的时间戳都不单独构成当前执行面或派发授权。
  • 同理，若 docs/handoff/tasks/ 里放的是短工 input spec、人工清单、说明稿或其它 supporting note，而不是标准 task card（例如缺少 kind: task / id: / current state: / next action: 这一组最小卡面字段，或正文显式自称 Input Spec、TL;DR、quick checklist 等），则它只按 supporting spec 处理，不按 task card 解析，也不构成 today-dispatch 入口。即使它位于 tasks/ 目录、被旧计划 / 收口文档引用、或文件名看起来像 lane 名称，也不得单独升级成当前执行面。
  • 同理，docs/handoff/thread-hygiene.md、docs/handoff/startup-prompt.md、docs/handoff/roles/*.md 这类控制面文件的更新时间晚于 docs/handoff/index.md，默认只表示控制规则、启动词或角色边界被细化；除非这些更新同时伴随新的 docs/handoff/index.md 变化、或新的业务 task/session 被吸收到当前执行面，否则不得仅凭这类控制文件较新就外推“执行面已变化”或“应恢复派发”。
  • 当前仓库已确认的高噪音样例包括：docs/uirefactor/** 历史设计稿、docs/art/** 美术清单/预览、public/assets/ui/** 本地 UI 资产、tools/剧情编辑器/** 与 story-video/** 本地工具/媒体目录、以及 args-*.json、tmp-*、preview/、outputs/、*.bak 这类探针/预览/备份辅助产物。若没有新的 truth source 明确吸收，它们一律只按漂移信号处理，不进入当前执行面。
  • 巡检线程列表时，若线程未被 docs/handoff/** 当前卡面引用，且职责已被 canonical 线程替代，不再把它视为可继续派活对象。
  • 上一条规则不适用于 docs/handoff/index.md 已声明的 canonical 主管主线程 / PM / 日版本监督长工 / 固定发布长工，以及当前仍挂在 In-Flight Business Cards 的 active owner task 所绑定的 owner 长工；它们在对应 truth source 仍有效时，仍属于当前执行面。