TMPA 实施与案例报告
S0.4 Reference Reader、FCoP、CodeFlowMu 与 C01–C14 重跑
文档版本： Draft I0.4
状态： 作者生成的实施与案例报告
规范目标： TMPA Core S0.4
历史证据基线： I0.3 / S0.3 语料库
报告与执行日期： 2026-08-03
一致性语料库：tmpa-s0.4-fcop-codeflowmu-20260803
权威边界： 本报告只提供工程证据，不具有规范性；TMPA Core 要求仅由 GitHub Core Specification 定义。
摘要
本报告把 Implementation Case 从一个未进入 GitHub 的 S0.3 时代本地归档，推进为公开、可执行的 S0.4 语料库。新增内容包括只读 Reference Reader、确定性 C01–C14 Fixture、可执行 Manifest、规范结果 Envelope、产品证据断言、文件 Digest 与单命令 Runner；同时保留 FCoP、CodeFlowMu 与小典 AI 的工程谱系。
FCoP 实现项目可见的协调 Profile：路由文本工件、生命周期路径、原子 Rename、只增迁移证据、角色绑定、复核、ISSUE、告警和检查报告都保存在临时模型 Session 之外。CodeFlowMu 把 FCoP 用作持久工作身份、任务—报告流、复核门禁、依赖等待、恢复和归档历史的协调与治理基础设施。小典 AI 提供来自受治理 NL2SQL Pipeline 的前规范现场证据，包括被保留的通过路径和拒绝路径。
S0.4 Reference Reader 针对作者生成的合成 Fixture 套件得到 14 PASS。单独求值的 FCoP–CodeFlowMu 产品基线得到 1 PASS、9 PARTIAL、4 NOT RUN、0 FAIL，聚合裁决为 PARTIAL。FCoP 3.2.4 锁定提交 da79dfefd99f597c9e422ce9edec22157f915a21 已直接取回重跑：1,137 项通过、2 项跳过、0 项失败。CodeFlowMu V1.2.3 锁定提交 8f342d028eb66e77d135bea58fdbc7f2d0627e3b 不存在于公开 CodeFlowMu-open 历史，因此只重新裁决 I0.3 已保存证据，不声称完成新的产品执行。
1. 范围与证据边界
本报告回答：新的 S0.4 Reference Reader 实现了什么；锁定产品证据实际演示了什么；哪些产品要求仍未执行。本报告只提供工程证据且不具有规范性；要求与规范测试名称只由 TMPA Core Specification S0.4 定义，理论由 Architecture Paper A0.5 解释。
证据仍分为 specified、implemented、demonstrated 与 independently adopted。Reference Reader 已实现并由作者演示；产品基线包含混合的 implemented/demonstrated 证据，聚合仍为 PARTIAL。Fixture 成功不得转换为 FCoP 或 CodeFlowMu 产品一致性，也不建立独立采用或独立验证。
2. 工程谱系与组件边界
当前概念分层
TMPA 架构 → 可复用 FCoP 协议 Profile → CodeFlowMu 与其他下游应用
历史谱系
小典 AI 实践 → 原始 TMPA → FCoP 抽取与成熟
→ CodeFlowMu 应用 → 当前 TMPA 形式化FCoP 实现 TMPA 中一个已定义的文件型子集；CodeFlowMu 把 FCoP 作为协调与治理基础设施采用。FCoP 不穷尽 TMPA；CodeFlowMu 不定义 FCoP；小典 AI 是谱系和现场证据，不是产品级 TMPA Reader。
术语遵循 Core Specification 第 2 节：治理对象是语义单元，来源工件是物理观测，治理 Reader是确定性重建阶段，valid / invalid / undetermined 是仅有的三个治理语义判断。本报告不引入替代含义。
3. FCoP 工程实现
3.1 持久文本消息与状态表面
FCoP 把项目文件系统作为持久文本消息与状态表面：文件承载协议，路径表达状态，事件回放迁移。 TASK-* 工件作为稳定工作锚点；报告、复核、ISSUE、告警与决策保持独立；文件名携带路由；生命周期目录暴露状态；原子 Rename 执行迁移；迁移证据说明状态如何到达；工件在 Session 结束后仍可检查。
3.2 Agent 可见角色绑定
受治理参与从 Agent 可见的显式角色绑定开始。绑定规定角色、协作上下文、任务范围、允许/禁止动作以及独立复核或升级角色。它是运行协议身份，不是密码学或法律身份。
3.3 生命周期
参考生命周期为：
inbox → active → review → done → archive → history
↑ |
└─ reject┘| 动作 | 来源状态 | 目标状态 | 典型权限 |
|---|---|---|---|
create_task | — | inbox | 任务创建者 |
claim_task | inbox | active | 被分配的执行者 |
submit_task | active | review | 责任执行者 |
approve_task | review | done | 复核者或批准者 |
reject_task | review | active | 复核者 |
finish_task | active | done | Profile 授权角色 |
archive_task | done | archive | 归档权限 |
archive_to_history | archive | history/... | 归档权限 |
路径表示当前 Profile 状态，迁移证据记录过程历史。路径与证据不一致时必须形成 ISSUE，而不是静默修复。
3.4 路由、原子发布与恢复
参考文件名为 {TYPE}-{YYYYMMDD}-{NNN}-{SENDER}-to-{RECIPIENT}(-slug).md。文件名是传输封装；正文与 Schema 承载完整含义。在支持的平台上，原子发布通过先写临时文件再 Rename 实现。恢复从持久工件重建任务身份、当前生命周期、责任、关联证据、未解决依赖与问题，不依赖隐藏 Session 上下文。
4. CodeFlowMu 持久工作环境
CodeFlowMu 研究跨 Session 持续存在的 AI 工作角色。模型和 Session 可以变化，但工作身份通过角色绑定、任务/Thread ID、报告和复核、批准/拒绝记录、生命周期迁移、未解决 ISSUE/依赖、恢复和归档证据继续存在。
这里的“数字员工”只表示能够接受委托工作、使用工具并跨 Session 提交证据的工程身份，不表示法律雇佣、人格、意识、人类意图，也不表示替代承担责任的人类或组织。
一项已观察 Session 展示了协议初始化与参与者身份的区别：FCoP 已初始化，但 Session 尚未分配角色；Agent 在制定开发计划前请求显式角色绑定，在获得 PM/共同复核者绑定后才确认角色并创建受治理规划工作。该观察只建立运行角色可见性，不建立密码学认证。
观察与测试路径包括 ADMIN/PM 委托、执行者 Claim 与执行、独立报告提交、QA/治理复核、批准/拒绝/等待人工状态、依赖等待与释放、ISSUE 创建、重启恢复和归档历史。当前限制是这些局部发现尚未被统一规范化为 TMPA 证据图与问题集合，因此 C13 仍为 PARTIAL。
当必需证据缺失、过期或不完整时，实现可以阻止 Release。CodeFlowMu 已保存足以证明部分重启与恢复行为的 Session、任务、报告、生命周期和 Ledger 证据，但尚无单一产品 Reader 把责任、生命周期、未解决依赖、冲突与问题重建为一个规范输出。
5. 小典 AI NL2SQL 案例
公开演示位于 https://demo.chedian.cc/。产生数据的私有开发系统与公开仓库不被声称为同一个可直接复现构建。2026-07-29 快照显示 330 Profile、16,129 Event、924 Message、1,220 Index/Export、44 Knowledge 和 352 Audit 记录；这些是单次系统状态，不是性能基准。
NL2SQL 链覆盖授权、意图规范化、Schema/DDL 上下文、SQL 生成、只读验证、写入阻断、表白名单、租户隔离、字段/Join/枚举验证和结果合理性检查。一个车辆违法查询在 26,344 ms 后通过；一个车辆费用汇总查询在 131,994 ms 后被拒绝。价值在于保留通过与拒绝路径的分歧，而不是计算代表性通过率。
被拒绝链保留请求身份、验证阶段、明确结果、耗时、跨 Session 证据以及治理证据与生成 SQL 的分离。它演示真实应用能够保存治理相关记录、重建多阶段链、把拒绝保留为一等结果并展示策略门禁；它不证明完整 TMPA Core 一致性、代表性 SME 性能、独立采用、密码学不可抵赖性或每条记录的事实正确性。
6. 公开 S0.4 C01–C14 语料库
I0.3 曾描述本地 tmpa-conformance.zip，但该归档、Runner 与 Fixture 并未进入 GitHub 唯一事实源。I0.4 以公开仓库语料库 research/conformance/tmpa-core-s0.4 取代不可用的交付声明；语料库 ID 为 tmpa-s0.4-fcop-codeflowmu-20260803。
语料库刻意分成两条证据轨道：
- S0.4 Reference Reader 轨道。 只读实现消费合成 Fixture，验证公开 S0.4 Schema 与可执行 Profile，重建规范节点、边、问题、判断和视图，再核验 C01–C14 断言。
- 锁定产品基线轨道。 机器可读断言把可取得的 FCoP、CodeFlowMu 与小典证据按更严格的 S0.4 标准重新裁决。Fixture PASS 绝不提升为产品 PASS。
仓库命令为 npm run tmpa:s0.4:conformance。它在不修改产品仓库的前提下重新生成标准记录、Reference 与 Product 结果、执行日志、汇总和 SHA-256 文件 Manifest。Runner 对 S0.4 对象与 Reader Result Envelope 进行严格 JSON Schema 验证，并在求值前验证可执行的 Lifecycle/Type/Role/Relation Profile。
状态语义固定为：PASS 表示该轨道全部强制断言都已执行并匹配；PARTIAL 表示存在真实产品证据，但至少缺少一项 S0.4 必需观察或输出；NOT RUN 表示所需产品执行路径不可用；FAIL 表示已执行的强制断言不匹配。只有产品 C01–C14 全部 PASS 时，产品聚合结果才是 PASS。
FCoP 3.2.4 Commit da79dfefd99f597c9e422ce9edec22157f915a21 已直接取回，并在 Python 3.12.13 上重跑：1,137 项通过、2 项跳过、0 项失败。CodeFlowMu V1.2.3 锁定 Commit 8f342d028eb66e77d135bea58fdbc7f2d0627e3b 无法从公开 CodeFlowMu-open 历史取回，因此 I0.4 将新的 CodeFlowMu 执行记录为 NOT RUN，只把 I0.3 保存的断言用于有边界的重新裁决。
| 证据轨道 | PASS | PARTIAL | NOT RUN | FAIL | 聚合 | 声明级别 |
|---|---|---|---|---|---|---|
| S0.4 Reference Reader Fixture | 14 | 0 | 0 | 0 | PASS | Implemented 且由作者 Demonstrated |
| FCoP–CodeFlowMu 产品基线 | 1 | 9 | 4 | 0 | PARTIAL | 混合产品证据 |
Reference Reader 结果表明已发布的解释可以执行。它不建立 FCoP、CodeFlowMu 或小典对 S0.4 的完整一致性，也不建立独立采用。
7. 标准级结果
下表中的测试名称与含义直接引用 Core Specification 第 10.2 节；本报告只记录产品证据与剩余缺口。
| ID | 规范测试名称 | 裁决 | 产品证据与剩余缺口 |
|---|---|---|---|
| C01 | Schema 验证 | PARTIAL | FCoP 与 CodeFlowMu 已有 Schema 和验证路径，但完整 TMPA 规范对象覆盖及全部负向格式案例尚未由一个 Core Validator 暴露。 |
| C02 | 主载体与单写者不可变性 | PARTIAL | 独立工件与更正证据已存在；更严格的不可变对象与一任务一主载体观察仍不完整。 |
| C03 | 重复对象 ID | PARTIAL | 局部重复与冲突机制已存在，但相同 ID、不同内容的规范隔离视图尚未端到端暴露。 |
| C04 | 串行流连续性与异步推进 | PARTIAL | 局部排序、依赖等待与异步推进已实现；尚未输出统一规范偏序图与流缺口问题集合。 |
| C05 | 角色权限 | PARTIAL | 角色、Capability 与操作门禁已存在；全部失败尚未规范化为统一权威 TMPA 问题模型。 |
| C06 | 生命周期合法性 | PARTIAL | 直接生命周期测试覆盖非法与未授权迁移，但产品证据尚未同时输出 S0.4 要求的 ILLEGAL_TRANSITION/invalid 与 LIFECYCLE_UNDETERMINED/undetermined 两类规范结果。 |
| C07 | 职责分离 | PARTIAL | 独立报告、复核与 Review Gate 已存在，但身份级分离和例外对象处理尚未完整演示。 |
| C08 | 完整性篡改 | NOT RUN | Fixture Oracle 已存在；产品级被覆盖内容 Digest 验证与规范篡改 Reader 未执行。 |
| C09 | 缺失引用 | PARTIAL | 缺失依赖可以阻塞工作，但完整 undetermined/partial 图传播与规范问题输出仍不完整。 |
| C10 | 禁止环 | NOT RUN | 禁止环 Fixture 已存在；能够只隔离受影响子图的产品图 Reader 不可用。 |
| C11 | 聚合与重建确定性 | NOT RUN | Fixture Oracle 在 24 种排列下产生字节等价输出；产品级规范图与问题序列化器不可用。 |
| C12 | 冲突保留 | NOT RUN | 冲突保留 Fixture 已存在；产品级确定性 disputed/undetermined 视图与授权解决路径未作为一项标准执行。 |
| C13 | 恢复 | PARTIAL | 重启与恢复机制已存在，但没有统一的全新 Reader 重建全部责任、生命周期、依赖与问题状态。 |
| C14 | 终态历史保留 | PASS | 直接 Archive/History 测试保留终态、迁移、先前报告、复核与任务证据。 |
独立的 S0.4 Reference Reader 轨道通过全部 14 项合成 Fixture 断言。这些结果验证可执行解释与确定性 Runner，不验证表中产品。
8. 产品投影缺口
Publication 仓库现已包含通用 S0.4 只读 Reference Reader。主要产品缺口因此更具体：两个锁定产品都没有受维护的投影适配器，把各自原生工件转换为该 Reader 消费的 S0.4 来源对象表面。
来源工件
↓
保留来源追踪的来源候选
↓
规范候选集合
↓
偏序流程与责任图
↓
规范问题集合
↓
valid / invalid / undetermined 判断
↓
authoritative / quarantined / partial / disputed / pending_human 视图FCoP 与 CodeFlowMu 已具备独立工件、原子发布、角色检查、生命周期门禁、依赖阻塞、Archive 保留和重启恢复等写入侧与局部控制机制。产品专用投影将直接改善 C03、C05、C09、C13，为 C04/C07 提供基础设施，并建立 C10–C12 所需的产品执行路径。C01 仍有 Schema 覆盖缺口；C02 仍有更严格不可变性缺口；C06 缺少完整的规范三值输出对；C08 需要被覆盖内容的 Digest 证据。CodeFlowMu 还需要可公开取回的锁定源码或复现包。
9. Worked Flow 中的三值治理
TMPA 区分语义判断与视图分类：
| 语义判断 | 视图分类 | 含义 |
|---|---|---|
valid | authoritative | 必需证据与规则建立结论 |
invalid | quarantined 或 rejected | 确定性违规排除受影响证据或动作 |
undetermined | partial | 必需证据缺失或不完整 |
undetermined | disputed | 有效证据冲突且没有授权解决 |
undetermined | pending_human | 适用 Profile 要求人工决定 |
代表性复核流程为：
TASK → REPORT → QA REVIEW(needs_human)
↓
judgment: undetermined
view: pending_human
lifecycle: blocked_pending_resolution
↓
ADMIN DECISION
↙ ↘
approve reject
↓ ↓
valid invalidneeds_human 状态保持在图中并可查询，不得被提前表示为 done、approved、failed 或 rejected。依赖该未解决复核的下游对象保持 undetermined，直至增加授权决定对象。
S0.4 Reference Reader 已在合成 Fixture 上演示该三值流程。当前 CodeFlowMu 已有等待人工和注意状态，但产品级 Core 判断/视图规范化仍是实现目标，不是已经完整演示的产品声明。
10. 可复现性与局限
S0.4 语料库现已位于稳定的公开仓库路径，包含单命令执行、Schema、Profile、Fixture、断言、输出、日志与 SHA-256 Manifest。在固定执行时间戳下重复本地运行可产生字节完全一致的工件。本次维护直接取回 FCoP Commit 并成功重跑选定测试套件；CodeFlowMu Commit 无法从公开仓库取得。尚无第三方重跑或独立验证该语料库。
基线不建立代表性 SME 性能、比较部署成本、广泛容错、独立采用、参与者声明的事实真实性、认证身份、受保护存储或拜占庭韧性。产品与案例证据均由作者产生。公开演示与私有数据生成系统不被声称为同一个可复现公共构建。
下一阶段需要测量安装依赖与耗时、首个团队启动、CPU/内存/存储增长、延迟与乱序证据下的重建、受控中断与重启、冲突和缺失引用注入、人类可检查性、采用负担，以及相对于聊天、共享目录与简单工作流的基线。
11. 工程路线
- 实现受维护的 FCoP 与 CodeFlowMu 投影适配器，同时不改变现有写入行为；
- 发布或以其他方式提供可取回的 CodeFlowMu 锁定源码与复现包；
- 执行产品级 C08、C10、C11、C12；
- 补齐 C01–C07、C09、C13 的规范输出，包括 C06 两个三值分支；
- 测量低资源部署、重启与增量重建；
- 获得独立重跑并记录全部差异。
12. 证据声明
本报告提供带版本的工程证据，不提供独立验证。最强结论有明确边界：公开 S0.4 Reference Reader 通过 14/14 项合成标准；锁定产品基线为 C14 PASS、9 项 PARTIAL、4 项 NOT RUN，未观察到 FAIL。零 FAIL 不等于完整一致性，因为 4 项产品标准未执行，9 项仍不完整。更强声明需要产品投影、CodeFlowMu 可复现性、更广泛实验与独立复现。
13. 工程结论
公开 S0.4 语料库把宽泛工程历史转化为仓库内可测试基线。Reference Reader 通过全部 14 项合成标准；对锁定产品而言，仅 C14 PASS，9 项具有部分证据，4 项未在产品 Reader 层运行。该结果强于无版本演示，但仍弱于完整或独立一致性。
产品已经包含许多写入侧和局部控制机制。新的通用 Reader 建立确定性读取侧参考，而受维护的产品投影适配器仍是最大的共同缺口。C08、C10、C11、C12 的产品执行、其他 PARTIAL 输出的补齐、量化 SME 部署成本与独立复现，仍是分开的经验要求。
工件可用性
作者生成的 S0.4 语料库公开位于 research/conformance/tmpa-core-s0.4，包含 Reference Reader、可执行 Profile、Fixture、产品证据断言、外部运行记录、标准结果、汇总、日志和 SHA-256 Manifest。不再存在单独的 tmpa-conformance.zip；Git History 即版本历史。
数据可用性
公开演示暴露选定治理视图。私有业务数据、凭证与敏感运行记录不公开。语料库使用选定测试路径、Hash Inventory 与紧凑 Fixture，而不是导出私有生产数据。
利益冲突与来源
作者是 TMPA、FCoP、CodeFlowMu 的发起者或主要开发者，并参与小典 AI 谱系。全部基线结果均由作者产生，因此更需要锁定版本、保留失败并进行独立复现。
References
[1] FCoP Project. “FCoP — File-based Coordination Protocol,” repository README and architecture stack. GitHub, 2026. https://github.com/joinwell52-AI/FCoP.
[2] FCoP Project. “FCoP Runtime Specification · Single-Page Complete Edition,” 1.2.x specification line, 2026.
[3] FCoP Project. “FCoP IPC Envelope” and related machine-readable JSON Schemas, spec/schemas/, 2026.
[4] Python Package Index. fcop and fcop-mcp distributions, 2026.
[5] Official MCP Registry. io.github.joinwell52-AI/fcop, fcop-mcp server entry, 2026.
[6] FCoP Project. “ADR-0031: Governance Alert Layer (GAL).” Accepted 2026-05-11.
[7] FCoP Project. “ADR-0032: fcop_audit() — Protocol-to-Inspection Compiler.” Accepted 2026-05-12.
[8] CodeFlowMu. “TMPA Browser” public demonstration. https://demo.chedian.cc/. Snapshot observed 2026-07-29.
[9] TMPA Project. “TMPA Core S0.4 C01–C14 Conformance Corpus.” Corpus ID tmpa-s0.4-fcop-codeflowmu-20260803, executed 2026-08-03. research/conformance/tmpa-core-s0.4/.
附录 A：FCoP 端到端工件示例
PM 创建 TASK，DEV Claim 并执行，随后提交独立 DEV REPORT，再由 QA 发布独立 REVIEW。当技术验证通过但生产激活会改变授权边界时，QA 可以返回 needs_human。
Reader 重建：
PM 创建 TASK
├─ DEV Claim 并执行
├─ DEV 提交 REPORT
├─ QA 发布 REVIEW：needs_human
├─ judgment: undetermined
├─ view: pending_human
├─ 授权人工批准或拒绝证据
└─ 最终判断：valid 或 invalidneeds_human 节点保持在图中并可查询。依赖它的下游对象保持 undetermined，直至授权决定对象解决状态。权威记录是来源集合与迁移，不是渲染视图；重新排列输入文件不得改变重建图或问题集合。
I0.4 理论—实现对齐
FCoP 作为 TMPA 概念的协议实现接受评估；CodeFlowMu 作为结合协议角色、Skill、工具、Runtime 执行、恢复与界面的工程系统接受评估。本报告区分概率型 Agent 执行证据与确定性验证机制，也区分 demonstrated 行为与完整 Core Conformance。