TMPA Implementation and Case Report
S0.4 Reference Reader, FCoP, CodeFlowMu, and the C01–C14 Rerun
Document Version: Draft I0.4
Status: Author-Produced Implementation and Case Report
Normative Target: TMPA Core S0.4
Historical Evidence Baseline: I0.3 / S0.3 corpus
Report and Execution Date: 2026-08-03
Conformance Corpus:tmpa-s0.4-fcop-codeflowmu-20260803
Authority Boundary: This report is evidentiary and non-normative. TMPA Core requirements are defined only by the GitHub Core Specification.
Abstract
This report advances the implementation case from an unavailable S0.3-era archive to a public, executable S0.4 corpus. It adds a read-only Reference Reader, deterministic C01–C14 fixtures, executable manifests, canonical result envelopes, product-evidence assertions, file digests, and a one-command runner. It also preserves the engineering lineage through FCoP, CodeFlowMu, and selected XiaoDian AI evidence.
FCoP realizes a project-visible coordination profile in which routed textual artifacts, lifecycle paths, atomic rename, append-only transition evidence, role bindings, reviews, issues, alerts, and inspection reports remain available outside transient sessions. CodeFlowMu adopts FCoP for persistent work identities, task/report flows, review gates, dependency waiting, recovery, and archival history. XiaoDian AI contributes pre-specification field evidence from a governed NL2SQL pipeline, including retained pass and rejection paths.
The S0.4 Reference Reader reports 14 PASS against its author-produced synthetic fixture suite. The separately evaluated FCoP–CodeFlowMu product baseline reports 1 PASS, 9 PARTIAL, 4 NOT RUN, and 0 FAIL, with aggregate verdict PARTIAL. FCoP 3.2.4 at commit da79dfefd99f597c9e422ce9edec22157f915a21 was retrieved and rerun directly: 1,137 tests passed, 2 skipped, and none failed. CodeFlowMu V1.2.3 commit 8f342d028eb66e77d135bea58fdbc7f2d0627e3b was not present in the public CodeFlowMu-open history, so its preserved I0.3 evidence was re-adjudicated but no fresh product execution is claimed.
1. Scope and Evidence Boundary
This report asks what the new S0.4 Reference Reader implements, what the fixed product evidence demonstrates, and which product requirements remain unexecuted. It is evidentiary and nonnormative; the TMPA Core Specification S0.4 alone defines requirements and canonical test meanings, while the Architecture Paper A0.5 explains the theory.
Evidence classes remain specified, implemented, demonstrated, and independently adopted. The Reference Reader is implemented and author-demonstrated. The product baseline contains mixed implemented/demonstrated evidence and remains PARTIAL. Fixture success is not converted into FCoP or CodeFlowMu product conformance, and no independent-adoption or independent-validation claim is made.
2. Engineering Lineage and Component Boundaries
CURRENT CONCEPTUAL LAYERING
TMPA architecture → reusable FCoP protocol profile → CodeFlowMu and other applications
HISTORICAL LINEAGE
XiaoDian AI practice → original TMPA → FCoP extraction and maturation
→ CodeFlowMu application → current TMPA formalizationFCoP realizes a defined file-based subset of TMPA. CodeFlowMu adopts FCoP as coordination and governance infrastructure. FCoP does not exhaust TMPA; CodeFlowMu does not define FCoP; XiaoDian AI is lineage and field evidence rather than a product-level TMPA reader.
Terminology follows Section 2 of the Core Specification. In particular, governance object is a semantic unit, source artifact is a physical observation, governance reader is the deterministic reconstruction stage, and valid / invalid / undetermined are the only semantic governance judgments. This report does not introduce alternative meanings.
FCoP uses ordinary filesystem artifacts and operating-system operations as a project-visible coordination surface. CodeFlowMu combines FCoP operations with agent sessions, runtime scheduling, role interfaces, business workflows, approval paths, recovery controls, and user-facing views. XiaoDian AI contributes permission, validation, NL2SQL, policy-gate, rejection, and audit evidence.
3. FCoP Engineering Realization
3.1 Durable Textual Message and State Surface
FCoP treats the project filesystem as a durable textual message and state surface: files carry protocol, paths address state, and events replay transitions. A routed TASK-* artifact serves as a stable work anchor; reports, reviews, issues, alerts, and decisions are separate linked artifacts; filenames carry routing metadata; lifecycle directories expose current state; atomic rename performs lifecycle movement; transition evidence records how state was reached; and artifacts remain inspectable after the originating session ends.
3.2 Agent-Visible Role Binding
Governed participation begins with an explicit role binding visible to the agent. It identifies active role, collaboration context, scope, permitted/prohibited actions, and independent review or escalation roles. This is operational protocol identity, not cryptographic or legal identity.
3.3 Lifecycle
inbox → active → review → done → archive → history
↑ |
└─ reject┘| Action | Source | Target | Typical authority |
|---|---|---|---|
create_task | — | inbox | task creator |
claim_task | inbox | active | assigned executor |
submit_task | active | review | responsible executor |
approve_task | review | done | reviewer or approver |
reject_task | review | active | reviewer |
finish_task | active | done | profile-authorized role |
archive_task | done | archive | archival authority |
archive_to_history | archive | history/... | archival authority |
Path represents current state under the profile; transition evidence records history. Inconsistency is an issue, not silently repaired state.
3.4 Routing, Atomic Publication, and Recovery
A reference filename is {TYPE}-{YYYYMMDD}-{NNN}-{SENDER}-to-{RECIPIENT}(-slug).md. Filename is transport envelope; body and schema carry complete meaning. Atomic publication uses write-to-temporary and rename where supported. Recovery reconstructs task identity, current lifecycle, responsibility, linked evidence, unresolved dependencies, and issues from persistent artifacts rather than hidden session context.
4. CodeFlowMu as a Persistent-Work Environment
CodeFlowMu explores a persistent AI work role—sometimes called a digital employee—as an engineering identity that accepts delegated work, uses tools, and submits evidence across sessions. The term does not imply legal employment, personhood, consciousness, human intention, or replacement of the accountable human or organization.
Model and session instances may change while governed work identity continues through role bindings, task/thread identifiers, reports and reviews, approval/rejection records, lifecycle transitions, unresolved issues/dependencies, recovery, and archival evidence.
One observed session illustrates the distinction between protocol initialization and participant identity. FCoP was initialized, but the session had not been assigned a role. The agent requested explicit role binding before establishing the development plan. After receiving a PM/co-reviewer binding it acknowledged the role and created governed planning work. The observation establishes operational role visibility, not cryptographic authentication.
Observed and tested CodeFlowMu paths include ADMIN/PM delegation, executor claim and execution, separate report submission, QA/governance review, approval/rejection/human-attention states, dependency waiting and release, ISSUE creation, restart recovery, archival history, lifecycle authority, fact gates, state history, and operation approval.
The implementation can block release when required evidence is missing, stale, or incomplete. Current local findings are not yet normalized into one TMPA canonical issue set and evidence graph. CodeFlowMu maintains session, task, report, lifecycle, and ledger evidence sufficient to demonstrate selected restart and recovery behaviors, but no single product reader currently reconstructs responsibility, lifecycle, unresolved dependencies, conflicts, and issues into one canonical output. This is why C13 remains PARTIAL.
5. XiaoDian AI NL2SQL Worked Case
A public TMPA-oriented browser demonstration is available at https://demo.chedian.cc/. The data-producing private development system and public repository are not asserted to be one directly reproducible build; the public view is an observable deployment snapshot, not a complete reproduction package.
A 2026-07-29 snapshot displayed 330 Profile, 16,129 Event, 924 Message, 1,220 Index/Export, 44 Knowledge, and 352 Audit records. These counts describe one captured state and are not performance benchmarks.
The visible NL2SQL chain included authorization, intent normalization, schema retrieval, DDL-context loading, model-based SQL generation, read-only validation, write blocking, table whitelisting, tenant isolation, field/join/enumeration validation, and result-reasonableness checking.
Two captured chains were reported: a vehicle-violation query passed in 26,344 ms; a vehicle-expense summary query was rejected after 131,994 ms. The evidence value is the retained divergence between accepted and rejected paths. The sample is too small and selected to support rates or representative performance claims.
The rejected chain preserves request identity, validation stages, explicit outcome, elapsed time, evidence beyond the session, and separation between governance evidence and generated SQL. It demonstrates that a real application can persist governance-related records, reconstruct a multi-stage chain, retain rejection as a first-class outcome, and display policy gates. It does not establish full TMPA Core conformance, representative SME performance, independent adoption, cryptographic non-repudiation, or factual correctness of every record.
6. Public S0.4 C01–C14 Corpus
I0.3 described a local tmpa-conformance.zip, but that archive, its runner, and its fixtures were not present in the GitHub single source of truth. I0.4 replaces that unavailable delivery claim with the public repository corpus research/conformance/tmpa-core-s0.4, corpus ID tmpa-s0.4-fcop-codeflowmu-20260803.
The corpus has two deliberately separate evidence tracks:
- S0.4 Reference Reader track. A read-only implementation consumes synthetic fixtures, validates the public S0.4 schemas and executable profile, reconstructs canonical nodes, edges, issues, judgments, and views, then checks C01–C14 assertions.
- Pinned product-baseline track. Machine-readable assertions re-adjudicate the available FCoP, CodeFlowMu, and XiaoDian evidence against the stricter S0.4 criteria. A fixture PASS is never promoted into a product PASS.
The repository command is npm run tmpa:s0.4:conformance. It regenerates criterion records, reference and product results, an execution log, a summary, and a SHA-256 file manifest without modifying product repositories. The runner uses strict JSON Schema validation for the S0.4 object and reader-result envelopes and validates the executable lifecycle/type/role/relation profile before evaluation.
Status semantics are strict: PASS means all mandatory assertions for that track executed and matched; PARTIAL means genuine product evidence exists but at least one S0.4-required observation or output is missing; NOT RUN means the required product execution path was unavailable; FAIL means an executed mandatory assertion did not match. The product aggregate is PASS only if all C01–C14 product verdicts are PASS.
The FCoP 3.2.4 commit da79dfefd99f597c9e422ce9edec22157f915a21 was retrieved directly and rerun on Python 3.12.13: 1,137 passed, 2 skipped, 0 failed. The pinned CodeFlowMu V1.2.3 commit 8f342d028eb66e77d135bea58fdbc7f2d0627e3b was not retrievable from the public CodeFlowMu-open history, so I0.4 records the new CodeFlowMu run as NOT RUN and uses preserved I0.3 assertions only for bounded re-adjudication.
| Evidence track | PASS | PARTIAL | NOT RUN | FAIL | Aggregate | Claim level |
|---|---|---|---|---|---|---|
| S0.4 Reference Reader fixtures | 14 | 0 | 0 | 0 | PASS | Implemented and author-demonstrated |
| FCoP–CodeFlowMu product baseline | 1 | 9 | 4 | 0 | PARTIAL | Mixed product evidence |
The Reference Reader result demonstrates that the published interpretation is executable. It does not establish that FCoP, CodeFlowMu, or XiaoDian fully conforms to S0.4, and it does not establish independent adoption.
7. Criterion-Level Results
The test names and meanings below are direct references to Core Specification Section 10.2; this report records only product evidence and remaining gaps.
| ID | Canonical test name | Verdict | Product evidence and remaining gap |
|---|---|---|---|
| C01 | Schema validation | PARTIAL | FCoP and CodeFlowMu provide schemas and validation paths, but complete TMPA canonical-object coverage and all negative format cases are not yet exposed through one Core validator. |
| C02 | Primary-carrier and single-writer immutability | PARTIAL | Separate artifacts and correction evidence exist; stricter immutable-object and one-primary-carrier observation remains incomplete. |
| C03 | Duplicate object identity | PARTIAL | Duplicate and conflict mechanisms exist locally, but a canonical same-ID/different-content quarantine view is not exposed end to end. |
| C04 | Serial-stream continuity and asynchronous progress | PARTIAL | Local ordering, dependency waiting, and asynchronous progress are implemented; one canonical partial-order graph and stream-gap issue set are not yet emitted. |
| C05 | Role authority | PARTIAL | Role, capability, and operation gates exist; all failures are not yet normalized into one authoritative TMPA issue model. |
| C06 | Lifecycle legality | PARTIAL | Direct lifecycle tests cover illegal and unauthorized transitions, but the product evidence does not yet emit both required canonical outputs: ILLEGAL_TRANSITION/invalid and LIFECYCLE_UNDETERMINED/undetermined. |
| C07 | Separation of duties | PARTIAL | Separate reports and reviews plus review gates exist, but complete identity-level separation and exception-object handling are not fully demonstrated. |
| C08 | Integrity tampering | NOT RUN | Fixture oracle exists; product covered-content digest verification and canonical tamper reader were not executed. |
| C09 | Missing reference | PARTIAL | Missing dependencies can block work, but the complete undetermined/partial graph propagation and canonical issue output remain incomplete. |
| C10 | Prohibited cycle | NOT RUN | Prohibited-cycle fixture exists; product graph reader capable of quarantining only the affected subgraph was not available. |
| C11 | Aggregation and reconstruction determinism | NOT RUN | The fixture oracle produced byte-equivalent output across 24 permutations; no product-level canonical graph-plus-issue serializer was available. |
| C12 | Conflict preservation | NOT RUN | Conflict-preservation fixture exists; product-level deterministic disputed/undetermined view and authorized resolution path were not executed as one criterion. |
| C13 | Recovery | PARTIAL | Restart and recovery mechanisms exist, but no unified fresh reader reconstructs all responsibility, lifecycle, dependency, and issue state. |
| C14 | Terminal-history preservation | PASS | Direct archive/history tests preserve terminal state, transitions, prior reports, reviews, and task evidence. |
The separate S0.4 Reference Reader track passes all 14 synthetic fixture assertions. Those results validate the executable interpretation and deterministic runner, not the products listed in the table.
8. Product Projection Gap
The publication repository now contains a generic S0.4 read-only Reference Reader. The dominant product gap is therefore narrower and more concrete: neither pinned product has a maintained projection adapter that converts its native artifacts into the S0.4 source-object surface consumed by that reader.
source artifacts
↓
source candidates with retained provenance
↓
canonical candidate set
↓
partial-order process and responsibility graph
↓
canonical issue set
↓
valid / invalid / undetermined judgment
↓
authoritative / quarantined / partial / disputed / pending_human viewFCoP and CodeFlowMu already provide substantial write-side and local-control mechanisms: separate artifacts, atomic publication, role checks, lifecycle gates, dependency blocking, archive preservation, and restart recovery. Product-specific projection would directly improve C03, C05, C09, and C13, provide infrastructure for C04/C07, and create the product execution path required by C10–C12. C01 still has schema-coverage gaps; C02 has a stricter immutability gap; C06 lacks the complete canonical three-valued output pair; C08 requires covered-content digest evidence. CodeFlowMu additionally needs a publicly retrievable pinned source or reproduction package.
9. Three-Valued Governance in the Worked Flow
TMPA distinguishes semantic judgment from view classification:
| Semantic judgment | View classification | Meaning |
|---|---|---|
valid | authoritative | required evidence and rules establish the conclusion |
invalid | quarantined or rejected | a deterministic violation excludes the affected evidence or action |
undetermined | partial | required evidence is missing or incomplete |
undetermined | disputed | valid evidence conflicts and no authorized resolution exists |
undetermined | pending_human | the applicable profile requires a human decision |
A representative review flow is:
TASK → REPORT → QA REVIEW(needs_human)
↓
judgment: undetermined
view: pending_human
lifecycle: blocked_pending_resolution
↓
ADMIN DECISION
↙ ↘
approve reject
↓ ↓
valid invalidThe needs_human state remains present in the graph and queryable. It is not prematurely represented as done, approved, failed, or rejected. Any downstream object that depends on the unresolved review remains undetermined until an authorized decision object is added.
The S0.4 Reference Reader demonstrates this three-valued flow on synthetic fixtures. Current CodeFlowMu behavior includes human-attention and waiting states, but product normalization into the Core judgment/view model remains an implementation target rather than a fully demonstrated product claim.
10. Reproducibility and Limitations
The S0.4 corpus is now public at a stable repository path and includes one-command execution, schemas, profile, fixtures, assertions, outputs, logs, and SHA-256 manifests. Repeated local executions with the fixed execution timestamp produce byte-identical artifacts. The FCoP commit was independently retrieved within this maintenance run and its selected test suites reran successfully; the CodeFlowMu commit was unavailable from the public repository. No third party has rerun or independently validated the corpus.
The baseline does not establish representative SME performance, comparative deployment cost, broad fault tolerance, independent adoption, factual truth of participant claims, authenticated identity, protected storage, or Byzantine resilience. Product and case evidence remain author-produced. The public demonstration and private data-producing system are not asserted to be one reproducible public build.
Required next measurements include installation dependencies and time, first-team startup, CPU/memory/storage growth, reconstruction under delayed and permuted evidence, controlled interruption and restart, conflict and missing-reference injection, human inspectability, adoption burden, and comparison against chat/shared-folder/simple-workflow baselines.
11. Engineering Roadmap
- Implement maintained FCoP and CodeFlowMu projection adapters without changing existing write behavior.
- Publish or otherwise make the pinned CodeFlowMu source and reproduction package retrievable.
- Execute product-level C08, C10, C11, and C12.
- Emit the missing canonical outputs for C01–C07, C09, and C13, including both C06 three-valued branches.
- Measure low-resource deployment, restart, and incremental reconstruction.
- Obtain an independent rerun and record all differences.
12. Evidence Statement
This report provides versioned engineering evidence, not independent validation. Its strongest results are bounded: the public S0.4 Reference Reader passes 14 of 14 synthetic criteria; the pinned product baseline has C14 PASS, nine PARTIAL verdicts, four NOT RUN verdicts, and no observed FAIL. Zero FAIL does not mean complete conformance because four product criteria were not executed and nine remain incomplete. Stronger claims require product projection, CodeFlowMu reproducibility, broader experiments, and independent reproduction.
13. Engineering Conclusion
The public S0.4 corpus converts broad engineering history into a testable, repository-resident baseline. Its Reference Reader passes all 14 synthetic criteria. Against the pinned products, only C14 passes, nine criteria have partial evidence, and four were not run at product-reader level. The result is stronger than an unversioned demonstration but remains weaker than complete or independent conformance.
The products already contain many write-side and local-control mechanisms. The new generic reader establishes a deterministic read-side reference, while maintained product projection adapters remain the largest shared gap. Product execution of C08, C10, C11, and C12, completion of the other partial outputs, quantified SME deployment cost, and independent reproduction remain separate empirical requirements.
Artifact Availability
The author-produced S0.4 corpus is public at research/conformance/tmpa-core-s0.4. It contains the Reference Reader, executable profile, fixtures, product-evidence assertions, external-run records, criterion results, summaries, logs, and SHA-256 manifest. There is no separate tmpa-conformance.zip; Git history is the version history.
Data Availability
The public demonstration exposes selected governance views. Private business data, credentials, and sensitive operational records are not included. The corpus uses selected test paths, hash inventories, and compact fixtures rather than exporting private production data.
Competing Interests and Provenance
The author is the originator or principal developer of TMPA, FCoP, and CodeFlowMu and is involved in the XiaoDian AI lineage. All baseline results are author-produced. This relationship increases the need for fixed versions, preserved failures, and independent reproduction.
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/.
Appendix A. FCoP End-to-End Artifact Example
A TASK is created by PM, claimed and executed by DEV, followed by a separate DEV REPORT and an independent QA REVIEW. The QA review may return needs_human when technical verification passes but production activation changes an authorization boundary.
The reader reconstructs:
TASK created by PM
├─ claimed and executed by DEV
├─ REPORT submitted by DEV
├─ REVIEW issued by QA: needs_human
├─ judgment: undetermined
├─ view: pending_human
├─ authorized human approval or rejection evidence
└─ final judgment: valid or invalidThe needs_human node remains in the graph and is queryable. Downstream objects depending on it remain undetermined until an authorized decision object resolves the state. The authoritative record is the source set and transitions, not the rendered view. Reordering input files must not change the reconstructed graph or issue set.
I0.4 Theory-to-Implementation Alignment
FCoP is evaluated as a protocol realization of TMPA concepts; CodeFlowMu is evaluated as an engineering system combining protocol roles with Skills, tools, runtime execution, recovery, and interfaces. The report distinguishes probabilistic agent execution evidence from deterministic validation mechanisms, and demonstrated behavior from full Core conformance.