先把“谁在说话、谁在做事、谁能验收”彻底分开。
这份方案针对截图中“用户已要求停止，但监督消息仍继续出现”以及“旺财曾用其他员工 App 代发”的问题，重新定义集团协作的事实源、调度、身份和验收边界。
一句话结论
不再继续把一个看板修成同时负责数据库、调度器、Worker 生命周期、通知、交接和验收的“大一统系统”。
继续修 Kanban 主流程
一周内已出现错误 done、旧候选覆盖新候选、重复阻塞、通知门禁缺失等问题。继续堆补丁，实际上是在重写工作流引擎。
群聊 / 多维表格单独承载
群聊没有原子状态和依赖；表格适合人工协作但不适合租约、幂等和崩溃恢复。它们不能独自承担事实源。
版本化项目文件 + 轻执行器
把计划、交接、QA、终验都变成有版本、有负责人、有证据的文件；把运行和展示从事实源中分离。
目标架构：四层分工
聊天入口和项目控制是两条不同链路，互相引用事实，但不互相冒充。
中央 Webhook + transient Worker
解决“员工不需要常驻”的原始目标。Worker 只能使用自己的 Profile/App，不能替其他员工发言。
Kanban 历史
导出 tasks、runs、events、comments 后只读归档；不再新建、派发、自动解阻或作为完成事实。
轻量执行器
只检查项目文件依赖、创建租约、启动 Worker、收集 PID/心跳；不写 QA 或终验结论。
一条任务如何走完
任何阶段都不能靠“机器人回复了一句”直接跳过下一阶段。
总监规划
确定范围、负责人、QA、验收标准
执行领取
执行器预检通过后签发租约
员工交付
写入候选、测试、风险和摘要
独立 QA
只读拉取交付物，重放并判定
总监终验
PASS 后才允许下一阶段或上线
| 状态 | 谁可以写 | 含义 | 禁止误读 |
|---|---|---|---|
| planned | 总监 | 计划已冻结，等待执行条件 | 不是已分派、不是已开工 |
| assigned | 控制面 | 已明确负责人和交付合同 | 不是 Worker 已启动 |
| running | 执行器 | 预检通过、租约有效、Worker 存活 | 不是候选通过 |
| delivered | 执行人 | 候选和证据已提交，等待独立 QA | 不是最终完成 |
| qa_passed | 独立 QA | QA 按合同重放通过 | 不是生产上线 |
| accepted | 总监 | 总监核对证据并批准阶段交付 | 高风险动作仍需用户批准 |
解决“谁发的”与越权代发
内容生成、发送 Profile、App 身份必须能在审计记录中一一对应。
一个 Profile 只能代表自己
旺财只能用 default App；张启明只能用 supervisor App；林知夏只能用 muyang-secretary App。任何跨 Profile 的发送请求默认拒绝，不能用“帮忙汇报”绕过。
每条消息绑定五个字段
生成会话 Profile、发送 Profile、App ID、入站消息引用、远端 message_id。发送 Profile 与目标员工不一致时，系统必须 fail closed。
message = {
"author_profile": "supervisor", # 谁生成内容
"sender_profile": "supervisor", # 谁调用发送器
"app_id": "app-bound-to-supervisor", # 与 Profile 一对一
"reply_to": "inbound-message-ref",
"remote_message_id": "required-before-ack"
}
# invariant: author_profile == sender_profile == target_profile
# mismatch => reject, audit, alert; never silently reroute to another App项目文件如何交接
文件是可审计事实，不是让所有员工随意改写的共享便签。
project_id: control-v1
owner: supervisor
status: planned
revision: 1
stages:
- id: implementation
assignee: be-lead
reviewer: qa
depends_on: []
exit: delivered + evidence
- id: acceptance
assignee: supervisor
depends_on: [implementation.qa_passed]
exit: accepted
approval:
production_canary: user_required实现路线：先做一条最小纵向链
不一次迁移 31 名员工，不一次开启 Bot-to-Bot，也不再自动滚代。
停止旧调度源与旧通知任务
导出 Kanban 全部历史；停止自动 dispatch、监督和重复重跑；建立“计划源登记表”，任何新定时任务必须登记 job_id、owner、stop_key 和退出条件。
建立 Project Control Files v1
固定 PROJECT、Task、Handoff、QA、Acceptance 五种文件格式；定义状态、revision、依赖、负责人、证据哈希和审批边界。
实现轻量执行器
读取项目文件 → 预检 → 发租约 → 启动单个 transient Worker → 收集心跳与结果。执行器不写 QA、不写终验、不跨 App 发消息。
接入本人 App 出站护栏
为每个回复绑定作者 Profile 与发送 Profile；不一致直接拒绝。先用一个员工做 DM 文本 Canary，不碰群 Bot-to-Bot。
一条真实业务链
张启明规划 → 张承业执行 → 张谨言独立 QA → 张启明终验。失败自动停在当前阶段，不自动开启下一代。
| 角色 | 可以做 | 不能做 |
|---|---|---|
| 旺财 / 总入口 | 接收用户目标、解释方案、汇总事实、请求批准 | 不代替张启明思考，不调用张启明 App 发送旺财内容 |
| 张启明 / 总监 | 规划、拆解、指定执行人/QA、终验 | 不写实施代码、不自审、不自签通过 |
| 专业员工 | 执行合同、提交候选、写交接证据 | 不自行改 QA/终验状态，不代其他员工发消息 |
| 张谨言 / QA | 只读获取候选并独立重放，PASS/FAIL | 不改候选、不部署、不替总监终验 |
| 控制面 | 预检、租约、启动、回收、记录遥测 | 不替任何员工生成业务结论，不自动批准生产变更 |
停止命令只停了一个任务，不停调度源
修复为：所有周期任务必须从统一 Schedule Registry 创建；停止命令写入带版本的 revoke record；执行器每次发送前检查 revoke；被撤销的任务不能再次创建同类子任务。
停止后不会再出现下一条汇报
启动一个 30 秒测试任务 → 用户发送停止 → 观察任务源、运行 Worker、出站队列和重启后的状态；要求 0 条晚到消息、0 个新子任务、0 个隐藏副本。
任务状态与业务事实混淆
“Worker 退出”只代表执行进程结束；“QA PASS”和“总监接受”必须是独立文件事件，不能由进程退出自动推断。
任何阶段都可恢复且不跳阶段
进程中断后只能回到同一 revision；没有新的合同、证据和授权，不得自动向 QA 或生产推进。
通过标准与止损线
没有真实证据就写“未验证”，不把进程存在或页面显示当成业务成功。
| 测试 | 必须观察到 | 失败时动作 |
|---|---|---|
| 身份隔离 | PASS 生成 Profile、发送 Profile、App 身份一致；错配请求被拒绝并审计 | STOP 禁止任何正式员工群聊/任务推进 |
| 计划停止 | PASS revoke 后没有晚到消息、重复子任务或隐藏调度源 | STOP 冻结调度器，保留日志 |
| 租约恢复 | PASS Worker 崩溃可回收；同一任务不会被两个 Worker 同时执行 | STOP 不允许自动重试，人工定位 |
| 独立验收 | PASS 执行人不能写 QA/终验；QA 能从固定 revision 重放 | STOP 候选退回，不得部署 |
| 真实飞书 E2E | PASS 入站 → 本人 Worker → 本人 App → remote ID → ACK → 回收 | STOP 单 App 回滚，不影响旺财 |
| 成本止损 | PASS 单阶段固定模型调用上限、超时和重试上限 | STOP 禁止连续滚代，转人工评审 |
唯一下一步
这份页面是设计交付，尚未代表服务器已经切换。
先冻结旧调度，再做一个低风险文件任务 Canary
不改 31 个机器人、不开放 Bot-to-Bot、不部署生产。先证明“项目文件 → 单 Worker → 交付 → 独立 QA → 总监终验”这一条链真正成立；通过后再接多维表格投影和更多员工。