DEV Community: joinwell52

Three Agents Returned Three Reports. Which Task Did They Actually Prove?

joinwell52 — Sat, 22 Aug 2026 07:16:30 +0000

Original research: English · 中文 · Research Center

Three Agents finish at nearly the same time. Each report says “tests passed.” The dashboard sees three successful files. Yet one report came from the wrong project root, one reused an older test log, and one belongs to a retry that had already been rejected.

Three green reports can still add up to a false delivery.

Acceptance needs three plain answers:

Who did the work? Runtime identity and immutable execution context.
What proves it? Machine-captured command, exit code, Git state, logs, and artifact hashes.
Which task owns it? A unique task contract plus the accepted execution attempt.

Matching filenames alone cannot answer all three.

The attribution chain

task dispatch
→ immutable context binding
→ tool execution
→ machine evidence capture
→ report envelope
→ attribution validation
→ independent QA
→ acceptance decision

The report is one link. It is not the whole proof.

Figure 1. Evidence is accepted only when identity, task binding, execution facts, and independent verification converge on the same task.

Do not let the model author the envelope

A common file protocol checks that the task number inferred from the filename equals frontmatter.task_id and the first referenced task. This catches many accidental mismatches.

But an LLM can copy an old template and put the same wrong task ID in all three places. The file is internally consistent and externally wrong.

The stronger design is Runtime packaging:

the Agent submits report content through a controlled tool;
the Runtime injects task_id, parent_id, project root, runtime instance, attempt ID, and evidence references from the active execution context;
the Agent cannot overwrite those envelope fields;
the validator compares the envelope with the dispatch record and current task contract.

Not every current submission path implements universal envelope injection and unified evidence capture. They are target architecture requirements. The article does not present them as already complete everywhere.

Evidence must come from the execution boundary

“I ran the tests” is a claim. Useful evidence includes:

exact command and normalized working directory;
process exit code;
captured stdout/stderr or a content hash and durable location;
Git commit/tree or changed-file hashes;
Runtime instance and execution attempt;
tool invocation identity;
test time and environment facts when they affect interpretation.

The model may summarize this evidence, but it should not fabricate the primary record. A Runtime or tool wrapper should capture it at the process boundary.

Use logical order, not filesystem time

File modification time is unreliable for causality. Git checkout, archive extraction, clock skew, and cross-device synchronization can rewrite or preserve timestamps in surprising ways.

Use a task revision and attempt sequence:

TASK-42 revision 6
  attempt 1 → rejected
  attempt 2 → accepted evidence candidate

If a late report from attempt 1 arrives after attempt 2, physical time does not make it current. The accepted task revision and attempt decision do.

Multiple reports need an explicit state machine

Never overwrite a report silently. Each submission should be immutable and identified by attempt or report sequence. The acceptance layer can then decide:

candidate: awaiting verification;
rejected: evidence or contract mismatch;
superseded: replaced by a later valid attempt;
accepted: bound to the current task decision.

History remains inspectable, while only one attempt may satisfy the task.

A practical attribution veto list

Reject or hold acceptance when:

Runtime instance, canonical root, task revision, or attempt conflicts;
a report refers to a task other than the active dispatch contract;
Git hash or artifact hash does not match the inspected workspace;
required machine evidence is missing or cannot be resolved;
the execution right expired on a path that implements a lease;
a rejected/superseded attempt submits a late report;
independent verification covers a different revision;
three metadata fields agree with one another but disagree with the Runtime dispatch record.

A veto is not automatically an accusation of fraud. The neutral verdict is stale, conflicting, or insufficient evidence unless there is independent evidence of deliberate deception.

What 44 tests establish

On the pinned CodeFlowMu implementation, 44/44 report ownership and aggregation gate tests passed. They validate the covered parser, ownership, and aggregation paths.

They do not prove report content is inherently truthful. They also do not cover the logical counterexample where all three model-authored fields consistently point to the same wrong task. That case remains a required next fault test and a reason to move envelope authority into the Runtime.

The durable rule is: a report counts only when identity, machine evidence, task contract, and an authorized acceptance decision agree.

The full fact matrix and implementation boundaries are in the canonical English article. A Chinese version is also available.

More bilingual Agent engineering research: JoinWell52 Research Center

Why Is the Agent Still Editing the Old Project?

joinwell52 — Sat, 22 Aug 2026 06:47:41 +0000

Original research: English · 中文 · Research Center

The UI says Project B. The next test runs in B. Yet an Agent terminal still writes into Project A, an old file watcher emits events from A, and the evidence report is saved under B.

This is the local-Agent equivalent of a construction crew moving sites: the supervisor changes the sign, the workers keep demolishing the old building, the tool truck arrives at the new one, and the inspector records everything in the new site diary. Every component can report success while the delivery is wrong.

The current project is not one path string. It is a distributed binding shared by an execution chain.

Seven consumers can hold seven different roots

Component	Plain role	How it becomes stale
Runtime	coordinator	Keeps the previous in-memory project binding
MCP Server	tool process	Was started with the old root or environment
file Watcher	site camera	Still subscribes to Project A
Agent / terminal `cwd`	worker location	A child process keeps its original working directory
task write root	work-order desk	New tasks go to B while execution stays in A
FCoP lifecycle root	delivery ledger	State files describe a different project
logs and evidence root	inspection diary	Evidence is attributed to the new root for old work

Changing the toolbar only updates one observer. Safe rebinding must move the whole group.

Figure 1. The old root becomes inactive before a new execution identity is allowed to produce effects.

A four-phase safe switch

1. Stop admitting new work

Freeze new dispatches before changing any root. Otherwise work can enter while half the system still points to A and half already points to B.

Existing sessions should enter graceful draining: block new tool calls, ask cooperative work to stop at a safe boundary, wait for a bounded grace period, and only then terminate remaining child processes. A forced kill must leave a visible dirty-state record; it must not be presented as a clean switch.

2. Quiesce old side effects

Stop watchers, MCP tool processes, terminals, build jobs, and other children that can still touch A. On Windows, process termination does not guarantee immediate handle release. A Git process, language server, or orphaned tool may retain a file or directory handle and cause EBUSY or EPERM errors.

Use bounded retry with evidence:

request cooperative stop
wait for child exit
probe old-root handles / operations
retry within a fixed deadline
if still busy: reject the switch and retain diagnostics

Silently continuing after a handle error creates a split workspace.

3. Persist one canonical new root

Normalize more than slash direction and letter case. Modern Node.js projects commonly use symlinks through package managers. Two different strings may reach the same physical directory, while one friendly-looking path may escape the intended root.

Resolve a real path (fs.realpathSync.native() on Node.js/Windows where appropriate), validate that it exists and is permitted, then persist the canonical form. Task context should become immutable: once one task starts, its project identity cannot change underneath it.

4. Rebuild and prove the binding

Restart the Runtime-facing components from the saved canonical root. Give the new execution chain a new identity or epoch. Before dispatch resumes, verify:

Runtime root equals the persisted root;
MCP/tool roots equal the Runtime root;
watcher subscriptions cover only the new root;
new child-process cwd equals the new root;
task, report, log, and evidence roots agree;
no old-epoch process may write.

The switch is complete only when these facts agree—not when the UI label changes.

Fail visibly on four classes of error

Invalid destination: missing, forbidden, or unresolved path. Keep A active or stop safely; do not half-switch.
Draining timeout: an in-flight model/tool call does not reach a safe boundary. Preserve its state and require an explicit recovery decision.
Windows handle retention: old processes still lock A. Retry within bounds, identify the owner when possible, then reject rather than guess.
Binding mismatch: any component reports a different canonical root or execution epoch. Block dispatch.

What 27 tests do—and do not—prove

The pinned CodeFlowMu implementation passed 27/27 related tests for the current Windows-local project switch path. They verify the tested order, conflicts, and binding behavior in that implementation.

They do not prove that graceful draining, orphan-handle discovery, symlink behavior on every filesystem, or every third-party MCP Server is already covered. Those are explicit engineering requirements and next validation targets, not retroactive claims about the current test suite.

The practical rule

Treat project switching like changing an execution identity:

stop old effects
→ persist one canonical new address
→ rebuild every root consumer
→ prove task and evidence share that address
→ reopen dispatch

If your system cannot enumerate every component that consumes the project root, it cannot yet claim to switch projects safely.

The complete source matrix and implementation boundaries are in the canonical English article. A Chinese version is also available.

More bilingual Agent engineering research: JoinWell52 Research Center

An AI Agent’s Skill Is Not Its Permission

joinwell52 — Sat, 22 Aug 2026 06:47:37 +0000

Original research: English · 中文 · Research Center

Suppose an AI Agent receives a deployment playbook. It now understands the build, test, and release sequence. The environment also exposes a terminal and file-writing tools. May it publish?

Many systems accidentally answer yes. They collapse four separate facts into one: the model knows a procedure, a tool exists, the role may call it, and this exact operation is authorized.

Think of a controlled office release. A Skill is the operating manual. A Tool is the machine that can change files or invoke an API. A role capability is the access badge. An operation policy is the work order that identifies the target and impact. Approval is the seal placed on one exact work order.

Knowing the manual, operating the machine, holding a badge, and receiving approval are different events.

Four gates, four different questions

Layer	Question	What it must not imply
Skill / playbook	How should this job be done?	That the job is permitted
Role capability	Which tools may this role call?	That every target is acceptable
Operation policy	What object and side effect are being requested?	That a human has approved it
Single-use approval	Is this exact operation allowed now?	That later or modified operations are allowed

A Tool is not permission and is not inherently safe. It is an effect-producing interface. If the gate or operating-system boundary is overprivileged, a perfectly deterministic tool can still do too much.

Figure 1. Approval grants one controlled execution attempt; it does not merge the four layers.

Why prompts cannot be the security boundary

A Skill lives in model context. It is useful for decomposing intent, choosing a workflow, and assembling parameters. But it is still probabilistic text exposed to instruction conflict and prompt injection.

Authorization must be enforced outside that context. In a Model Context Protocol (MCP) tool or local Runtime, a neutral gate should check at least:

caller identity
AND role-to-tool capability
AND canonical project root
AND target allowlist
AND operation policy
AND matching single-use approval
AND underlying OS / sandbox permission

The model may propose an operation. It must not be the component that decides whether its own proposal is authorized.

Bind approval to state, not only parameters

Parameter matching is necessary but insufficient. A reviewer may approve a patch against Git commit abc123; before execution, another process changes the branch. The command is unchanged, but the state it will affect is not.

The approval fingerprint should therefore bind the action to relevant preconditions, for example:

{
  "action": "publish_release",
  "project_root": "D:/work/app",
  "git_commit": "abc123",
  "artifact_hash": "sha256:...",
  "expires_at": "2026-08-22T14:10:00+08:00",
  "nonce": "approval-7f2..."
}

Immediately before the side effect, the Runtime recalculates the fingerprint. A state mismatch, expiry, or repeated nonce rejects execution. This closes a common time-of-check/time-of-use (TOCTOU) gap.

Network retry is not renewed authority. A retry may safely return the stored result for the same operation identifier; changing the target, parameters, or bound state requires a new approval.

Static parsing still needs a sandbox

Command and path parsing cannot prove every effect in advance. Shell expansion, symlinks, environment variables, child processes, and tool-specific behavior can escape a naive allowlist.

That is why policy gates must sit above hard controls:

run high-impact tools in a restricted process or container;
grant the process only the filesystem and network access it needs;
canonicalize paths and reject traversal outside the bound root;
record command, exit code, stdout/stderr location, and artifact hashes;
fail closed when identity, state, or approval evidence is missing.

What the implementation tests establish

In the public CodeFlowMu Runtime, the tested chain separates Skill context routing, role/tool capability, operation authorization, approval persistence, and one-time consumption. On the pinned implementation used by the research article, 22 focused gate tests plus 13 approval persistence/consumption tests passed: 35/35.

That result supports the tested paths. It is not a penetration test, a third-party security certification, or proof that every downstream tool has perfect target parsing. The remaining boundary matters as much as the green count.

An audit checklist you can use

For every high-impact Agent action, require a concrete answer:

Can the Skill directly invoke effects, or only propose a structured request?
Is role capability enforced in deterministic code?
Is the canonical project root part of the request?
Does policy inspect the real target and side effect?
Is approval bound to parameters and relevant state?
Does approval expire and resist replay?
Does the underlying process lack unnecessary filesystem/network rights?
Can a reviewer reconstruct who proposed, authorized, executed, and verified the action?

The architecture rule is simple: let Skills explain and propose; let deterministic software authorize and execute.

Full evidence matrix, source links, and implementation boundaries are preserved in the canonical English article. A Chinese version is also available.

More bilingual Agent engineering research: JoinWell52 Research Center

Don’t Trust an All-Green Demo: How Fault Injection Exposes an Unreliable AI Agent Dispatcher

joinwell52 — Thu, 20 Aug 2026 07:20:54 +0000

Original research article: English · 中文 · Research Center

Related reading: begin with the long-requirement work graph. This article asks what remains true after a fault; finish with local execution and mobile control.

In ten seconds

Organize reliability tests as one rule that must never break × one injected fault × one observable verdict. The article delivers six defensive rules, four fault families, and a 12-case checklist that can become a Runtime test plan.

The easiest multi-agent demo is a happy path: create a TASK, let an Agent claim it, write a REPORT, and show “done” in the UI.

One successful run says almost nothing about the harder system. What happens when a watcher emits the same file event twice? If the dispatch record is durable but the model session never starts, will restart launch duplicate work? If one task appears in both active/ and review/, which location wins? If a dependency prevents a test from running, does the dashboard still say PASS?

Reliability testing begins with facts that must survive every interleaving, not with buttons on a page.

Do not only ask whether the workflow completed. Ask which invariants remain true when failure lands on every commit boundary.

Start from protocol invariants without repeating the protocol tutorial

FCoP v3 defines TASK, REPORT, ISSUE, and REVIEW artifacts, plus the collaboration semantics in which location represents current state and events preserve transition history. The previous article, “Files, Paths, and Events: Implementing and Testing the FCoP Collaboration State Machine”, covers protocol transitions and atomic commit in full; here they are only inputs to Runtime testing. ADR-0038 narrows the boundary: the protocol externalizes and coordinates work; it does not execute tasks or own model sessions and global orchestration.

CodeFlowMu Runtime owns file observation, task parsing, dependency checks, agent selection, session startup, dispatch commit, and recovery. Testing therefore needs layers:

Layer	What it must establish	Typical failure
Protocol/artifact	Identity, provenance, legal state, history, authority	Duplicate identity, illegal transition, history gap
Storage commit	No partial canonical write; bounded recovery	Temp residue, rename failure, weak durability
Runtime observation	Repeated events and reconciliation do not duplicate effects	Watcher jitter, missed event, double scan
Dispatch/session	Dependencies, busy state, two-phase dispatch, crash recovery	Double dispatch, orphan session
Governance	A REPORT does not confer acceptance; failures remain visible	Self-approval, NOT RUN reported as PASS

A single end-to-end test collapses these layers. When it fails, “the workflow did not finish” cannot tell you whether the defect belongs to protocol semantics, storage, observation, or the session host.

Figure 1. TMPA defines what should hold, FCoP specifies how it is expressed, and CodeFlowMu implements how it runs. TMPA C01–C14 conformance evidence and this article's 12 product-fault scenarios cannot substitute for one another. Source: TMPA Core S1.0, FCoP v3, current CodeFlowMu code, and the 2026-08-19 experiment record.

Six defensive rules worth encoding first

Regardless of language or storage engine, start with six rules that a fault must never be allowed to break:

A task identity never means two jobs: duplicates are reported, not overwritten.
A task cannot have split-state personality: two current locations are preserved as a conflict, not resolved by traversal order.
History is an append-only ledger: rejection, failure, retry, and recovery remain visible.
Every model call is attributable: it maps to a task version, execution attempt, time-bounded claim, and host decision.
No permit, no start: unmet dependencies, a busy agent, or an unapproved gate prevents session startup.
Restart never guesses: persistent artifacts and explicit execution records decide retry, rework, continue, or stop.

TMPA Core S1.0 supplies the identity, state, conflict, history, and recovery baseline. CodeFlowMu adds product responsibilities for watchers, dependencies, dispatch attempts, sessions, and time-bounded claims. The combination produces the Runtime test coordinates; the product-specific half is not a Core requirement.

Core also requires a deterministic Reader to produce a byte-equivalent canonical result for the same final source set and fixed Profile. Determinism here does not mean every timeline is identical. It means directory traversal order cannot change the governance verdict when the evidence is the same.

Why file coordination still needs governance semantics

Putting Markdown files in directories is a storage technique, not a reliability model. A filesystem still permits duplicate sources, concurrent writers, torn updates, ambiguous locations, and evidence that disappears under an overwrite. The useful question is not “Can agents exchange files?” but “Which facts must remain true when those exchanges fail?”

TMPA Core supplies five constraints that give the file projection engineering meaning:

Stable identity and provenance. A governed object needs a stable identity, source relation, and accountable role. Two sources declaring the same task identity are a conflict to preserve, not an invitation to let the last writer win.
Lifecycle and acceptance stay separate. A task location may represent its current collaboration state, while a REPORT records an execution claim and an authorized decision records acceptance. One field called done cannot safely compress all three.
Published objects are immutable; history remains reconstructable. Rejection, failure, retry, and recovery append new evidence. They do not rewrite the past into a cleaner story.
Conflict is a result. When readers find two current locations or incompatible sources, they report the ambiguity and stop the affected transition. Traversal order, confidence, or a model guess must not silently manufacture consensus.
Recovery comes from durable evidence. A fresh reader must rebuild responsibility, lifecycle, unresolved dependencies, failures, and recovery relations without access to the previous agent's hidden reasoning.

FCoP projects part of those semantics into TASK, REPORT, ISSUE, REVIEW, lifecycle locations, and transition events. CodeFlowMu then assumes the product responsibilities that a protocol does not: observing files, checking dependencies, managing attempts and sessions, enforcing time-bounded authority, and choosing a recovery policy.

That hierarchy also limits what a test result proves. TMPA C01–C14 check conformance behavior for an exact Core bundle. The 12 scenarios later in this article target concrete CodeFlowMu storage, observation, dispatch, and test-oracle failures. Neither suite can stand in for the other, and the 12 scenarios are a test plan—not a claim that all twelve already pass.

Storage faults: atomic rename is a commit point, not a universal guarantee

A common file commit is: write a uniquely named temporary file, flush its contents, then replace/rename the destination. POSIX rename() provides atomic name replacement under its defined conditions, which makes it useful as an observable commit point.

Keep the boundary narrow:

Do not assume atomicity across mounts.
fsync(file) is not automatically durable directory metadata after power loss.
Windows sharing, antivirus scanning, or transient path disappearance can yield EPERM/ENOENT.
A successful rename does not make downstream business effects exactly-once.
A file lock does not automatically eliminate deadlock or every race.

On 2026-08-19, we ran the current CodeFlowMu atomic-write test file in the local working copy: 9 tests passed. That supports the limited claim that the tested temp-file, replacement, and bounded-retry branches passed in this environment. It does not support “safe on every filesystem” or “exactly-once execution.”

A useful harness places faults between storage steps:

// Illustrative interface, not a published CodeFlowMu API.
await scenario({ seed: 42017 })
  .given(taskIn("active", "TASK-001"))
  .inject("after-temp-write", error("EPERM"), { times: 2 })
  .inject("after-replace-before-source-unlink", crash())
  .restartRuntime()
  .expect(oneCanonicalLocation("TASK-001"))
  .expect(historyExplainsCurrentState("TASK-001"))
  .expect(noUnboundedRetry());

The API shape is unimportant. The seed, injection point, error count, restart, and final verdict must be reproducible.

Event faults: a watcher notification is not a business fact

Filesystem watchers may duplicate, merge, reorder, or miss transient notifications. A watcher event should therefore mean “re-read durable facts,” not “dispatch one task.”

Test duplicate observation paths together: emit two identical watcher events while periodic reconciliation finds the same TASK. Multiple observations are acceptable; only one constrained business commit is. The implementation may use a deduplication key, task revision, dispatch-intent record, or idempotent store. The test should specify the result rather than turn one lock design into a standard.

Also test a missed event: suppress the watcher completely and run reconciliation. The persistent task must still be discovered. Otherwise an optimization has quietly become the only fact-ingestion path.

Dispatch faults: test attempt and lease commit boundaries

CodeFlowMu's current DispatchAttemptStore persists offered, claimed, running, and terminal states, together with attempt, lease, session ID, and idempotency key. The existing TaskDispatcher.twoPhaseDispatch.test.ts mainly covers trusted and unknown routes, repeated holds, dependency blocking, explicit release, and session_started. It does not directly inject the two crash windows below.

The commit sequence that still needs fault injection is:

Persist an intent bound to task revision, target agent, and rationale.
Start the model session.
Commit the external session identity or a failure record.

The target contract is: after a crash following step 1, restart sees “attempt without session”; after session startup but before step 3, external session identity or an idempotency key prevents a blind second launch. These are test requirements in this article, not a claim that the current crash paths have already been verified.

This is still not exactly-once. For external APIs, Git pushes, payments, or other irreversible effects, a more realistic contract is at-least-once attempt, domain idempotency key, visible duplicates, and human-decidable recovery.

Busy agents and dependencies are fault inputs too. An unknown TASK source, a busy target agent, an incomplete parent, an unapproved gate, and simultaneous explicit wake plus automatic scan must all be tested instead of excluded by fixtures.

PASS, FAIL, and NOT RUN are different facts

Our current rerun produced a more useful record than an all-green screenshot. Exact commands, environment, exit codes, and raw output are preserved in the experiment run log:

Atomic-write tests: 9/9 passed.
LAN address tests: 5/5 passed.
Long-horizon planning tests did not load because yaml was missing.
Two-phase dispatch tests did not load because @cursor/sdk was missing.
The open-edition mobile-publication boundary test ran and failed because current permission semantics no longer match the older test contract. Exact identifiers and the raw assertion diff remain in the experiment log; the public engineering lesson is that implementation, user-facing permission language, and regression tests must move together.

Under Core S1.0, an environment or infrastructure failure that prevents the test body from running is NOT RUN, not PASS and not automatically a product FAIL. The PWA case is a genuine executed FAIL, but its semantic classification remains open: did the implementation intentionally migrate the contract and leave a stale test, or did it diverge from the approved contract? A test detects drift; it does not possess product authority to choose the contract.

A trustworthy test system must expose product defects, test-environment gaps, and stale tests as distinct conditions.

A minimum 12-case fault-injection set

#	Scenario	Minimum verdict
1	Two sources declare one TASK ID	Report conflict; do not overwrite
2	One TASK exists in two lifecycle directories	Preserve the dual-location conflict
3	Crash during temp write	Canonical file remains readable; temp can be cleaned
4	Repeated EPERM/ENOENT on replace	Bounded retry; final failure remains visible
5	Duplicate watcher event	Repeat observation, not business commit
6	Missed watcher event; reconciliation only	Durable task is eventually found
7	Target agent is busy	No double dispatch; record the block
8	Dependency or gate is unmet	Do not start a session
9	Crash after dispatch intent	Restart recognizes intent without session
10	Crash after session start, before commit	Avoid blind duplicate start through identity/idempotency
11	REPORT is replayed	Preserve history; do not upgrade acceptance
12	Test dependency is missing	Report NOT RUN with environment evidence

Twelve is not an official specification number or a certification suite. It is a minimum transition from demo testing to engineering testing. Performance, load, longevity, security, cross-platform, cross-filesystem, and real-process termination tests still remain.

The public FoundationDB testing material shows the mature version of the idea: deterministic simulation, fault injection, and reproducible seeds can turn rare interleavings into repeatable experiments. Its results do not transfer to CodeFlowMu. Its method does: random exploration can be broad, but failure reproduction must be narrow.

The purpose of testing a file-based multi-agent Runtime is not to prove that “files are reliable.” It is to prove that when files, events, processes, and agents can all fail, the system can still explain the current facts, incomplete actions, and the next authority allowed to decide.

Primary sources

Other language: 中文研究原文

More research and engineering records: JoinWell52 Research Center

How Do You Stay in Control of an AI Team After Leaving Your Computer? A Two-Plane Design for Local Execution and Mobile Control

joinwell52 — Thu, 20 Aug 2026 07:20:51 +0000

Original research article: English · 中文 · Research Center

Related reading: start with the long-requirement work graph, then use fault injection to test the execution boundary. This article covers remote observation and bounded human decisions after leaving the computer.

In ten seconds

The computer keeps execution and authoritative facts. The phone provides a constrained view and a small decision surface. Every mobile action returns to the latest server-side version for authority, version, and duplicate-request checks.

At 7 p.m., a refactor is still running on a computer at home. DEV has submitted changes, OPS is running integration tests, and QA has just found a failure. The human is on a train. What the phone needs is not a miniature IDE. It needs three answers: what happened, which decision requires me, and whether a weak connection can execute my action twice.

The most dangerous design is a second task database inside the phone app. PC and PWA quickly acquire separate truths: the local task is in review while the cached phone still says active; an offline approval targets an old revision and is later replayed against new work.

A cleaner boundary separates an execution plane from a control plane.

The PC Runtime owns execution and durable facts. The PWA observes those same facts and sends a small set of human decisions back with version, reason, and an idempotency key—a unique request number that prevents repeated taps from creating repeated decisions.

A PWA is not a second Runtime

The W3C Web App Manifest provides installation metadata, start URLs, and application scope. Service Workers provide event-driven network mediation and caching. Browsers may terminate a service worker and restart it when an event arrives. That is useful for an offline shell, caching, and notifications; it is not a reliable process for a model session that runs for hours.

The first system boundary should therefore be explicit:

PC / Execution & Fact Plane              Mobile / Bound Control Plane
┌───────────────────────────┐            ┌──────────────────────────┐
│ CodeFlowMu Runtime        │            │ PWA                      │
│ - Watch / dispatch        │            │ - Team status            │
│ - Model sessions          │<--API/SSE--│ - Task / report detail    │
│ - Tests / evidence        │            │ - Approval with reason    │
│ - FCoP work artifacts     │            │ - Device / link status    │
└─────────────┬─────────────┘            └────────────┬─────────────┘
              │ authoritative files                   │ no second task DB
              v                                       │
      TASK / REPORT / REVIEW / events <───────────────┘

FCoP remains a protocol in this design: it defines work artifacts, path-based state, and event history. CodeFlowMu is the engineering rail that runs agents, observes files, starts sessions, and exposes PC/PWA services. PWA behavior must not be advertised as a capability of the protocol.

What the phone minimally needs to show

A useful control plane is not measured by page count. A minimum product can have six surfaces:

Team status: which roles are idle, busy, blocked, or offline, with an observation time.
Task state and hierarchy: current task, parent/child relations, revision, location, and blocking reason.
Reports and evidence: who asserted what, whether tests are PASS/FAIL/NOT RUN, and where evidence lives.
Pending decisions: objects awaiting approve, reject, pause, or rework authority.
Activity: append-only meaningful events, rather than treating chat bubbles as a state machine.
Device status: bound devices, last seen, session expiry, and LAN/Gateway reachability.

Every surface must answer, “Which authoritative record produced this value?” If the list comes from a file reader, details from a separate database replica, and notifications from in-memory events, the three will eventually disagree about one task.

TMPA Architecture Paper A1.0 calls for a stable primary carrier for governed work. Multiple writers use separate asynchronous streams that a deterministic Reader aggregates. Applied to mobile control, this does not require “files as the only database.” It requires every cache and index to remain an explicitly derived view rather than quietly acquiring primary authority.

Binding is a device lifecycle, not a permanent QR code

The current CodeFlowMu binding store separates a short-lived pending binding from durable device identity. The durable device record stores a session-token hash. To return the same result for a repeated browser request, an in-process completion record retains the original session token while that record remains in memory. Eligibility to replay the first result ends after ten minutes; the expired record is removed lazily when that binding ID is accessed again, not by a timer at the ten-minute mark. That tradeoff belongs in the threat model; it must not be simplified to “the system only stores hashes.” The presence of code is not a security certification.

A stricter target binding contract should include the following. The current ten-minute idempotent replay window is an intentional compatibility policy, not strict single use:

The PC generates a short-lived, single-use entry.
Confirmation atomically consumes the pending token; a same-token network retry returns the same result only within a bounded window, while wrong, conflicting, or expired tokens are rejected.
The server issues an expiring, revocable device session.
The client stores only required credentials; logs, screenshots, and URLs do not echo them.
The PC can list, disable, and rotate devices.
High-risk actions may require fresh authentication rather than a browsing session.

Binding links, QR codes, session tokens, real task bodies, and chat messages do not belong in public screenshots, Git, or ordinary debug logs. “Do not leak this” in a prompt is not a security boundary; Core S1.0's separation of role authority applies to UI actions too.

A mobile approval is not a `status` edit

The dangerous request is simply “task 1 is approved.” A tunnel drops the connection, the phone retries three times, and meanwhile the task changes. The server now has repeated approval writes with no proof of which version the user saw.

A safer target protocol sends an object ID, observed version fingerprint, decision, non-empty reason, and unique request number. This is an architectural example, not a claim about a published CodeFlowMu API or an already connected mobile Planning Gate.

Suppose QA writes a failed report on the PC and the phone displays “rework decision required.” When an administrator taps approve-rework, the client should submit the object ID, observed revision, decision enum, non-empty reason, idempotency key, and client time. The server re-reads canonical state, validates authority and revision, appends the decision, and returns a new server version.

Weak networks require fail-closed behavior: when version, authority, or outcome is uncertain, the system does not proceed.

If the revision changed, reject the old decision and require a reread.
If an idempotency key is replayed, return the first result without appending another decision.
If the request times out, display “outcome unknown,” not success.
Approval means the Runtime may attempt work; it does not mean execution completed.
Execution still returns through REPORT, tests, and independent review evidence.

TMPA Core S1.0 separates execution claims, validation results, and acceptance decisions. Mobile UI transports human authority into the same governance chain; convenience does not permit those roles to collapse.

Figure 1. This is the target decision boundary, not a claim about the current mobile API. The phone remains an entry point; the authoritative service should recheck device session, role capability, target revision, and idempotency. FCoP REVIEW and Operation Approval remain separate planes. Source: TMPA Core S1.0, FCoP v3, and the verified boundaries of current CodeFlowMu device and operation-approval implementations.

LAN and Gateway are reachability paths, not fact sources

On the same network, a phone may connect directly to the PC service. Away from home, a constrained Gateway may relay requests and events. The paths change reachability. They must not change the authoritative source of TASK, REPORT, approval, and device state.

On 2026-08-19, we reran the current CodeFlowMu LAN-address test file: 5 tests passed. Exact commands, environment, exit codes, and raw output are preserved in the experiment run log. That supports a limited address-selection implementation claim. It does not establish public reachability, NAT behavior, TLS, Gateway longevity, or end-to-end mobile security.

The current open-edition implementation still keeps remote mobile publication read-only/external, but this run found that current permission semantics and an older regression test no longer agree. Exact error identifiers belong in the experiment record, not the article's main narrative. The general lesson is stronger: authority must align across backend enforcement, user-facing permission language, and regression tests, or the phone may display a capability that does not exist. A test detects drift; product authority must decide the contract and synchronize all three surfaces.

Weak networks and caches: stale views may be readable; stale decisions must not execute

A PWA may cache its shell and the most recent read-only snapshot, but the page must display data version, server time, and connection state. A practical policy is:

Offline users may read a task explicitly labeled “as of 19:02.”
The client does not cache an approval token that can be replayed unconditionally.
Reconnection performs version reconciliation before enabling write buttons.
Server events trigger incremental refresh, while full reconciliation repairs missed events.
An old client, incompatible schema, or uncertain authority forces read-only mode.

This direction is consistent with local-first research on local ownership, offline availability, and cross-device coordination. That paper does not validate our implementation. CodeFlowMu still needs end-to-end experiments for real weak networks, clock skew, cache corruption, device revocation, and Gateway failures.

A 15-point acceptance checklist

Facts and display

List and detail views resolve to the same canonical artifact and revision.
Cached views show observation time instead of impersonating real-time state.
REPORT, REVIEW, decision, and execution state are not compressed into one done value.
Full reconciliation repairs missed real-time events.

Binding and authority

The pending binding token expires and is consumed once; bounded idempotent replay returns only the same result, and the token cannot be recovered from logs.
Device sessions can expire, rotate, and be revoked.
The server rechecks roles for high-risk actions instead of trusting visible buttons.
A PWA screen does not confer external publication authority on the open edition.

Mobile writes

Every decision carries object ID, current revision, decision, reason, and idempotency key.
A changed revision makes the stale decision fail closed.
Timeout produces “unknown,” never client-declared success.
Approval and execution success are displayed separately.

Network and privacy

LAN and Gateway use the same fact and authority services.
Weak network, disconnect, repeated request, server restart, and device revocation have regression coverage.
Public screenshots, repositories, telemetry, and ordinary logs exclude QR codes, binding URLs, tokens, and real task text.

A cloud Runtime is another valid architecture. If tasks execute in a remote sandbox, the phone may directly control that cloud authority. This article addresses the failure and trust model of a local agent team; it does not argue that all agents must run on a PC.

For a local system, the best mobile client is not the one with the most features. It is the one that lets a human leave the desk, see the same facts, make a small number of authorized decisions, and refuse to manufacture a second truth when network and version are uncertain.

How TMPA, FCoP, CodeFlowMu, and Mobile divide responsibility

These names describe four layers, not four competing products.

TMPA Core defines governance semantics. It specifies stable work carriers, role responsibility, lifecycle state, independent acceptance, conflict preservation, and deterministic reconstruction. A stable primary carrier is the stable reference point for governed work; TMPA does not declare that every system must use a PC or local disk. Its crucial boundary here is that an execution report is a fact claim, while acceptance is a decision made by an authorized role.
FCoP projects collaboration into files. It defines TASK, REPORT, ISSUE, REVIEW, lifecycle locations, and transition events that people and tools can inspect. It does not choose a LAN address, issue device credentials, draw the mobile UI, or own an agent session.
CodeFlowMu is the running engineering system. In the local deployment discussed here, the project root, Runtime, and server-side readers form the authoritative execution plane. CodeFlowMu runs agents and tests, checks dependencies and permissions, manages devices, and distinguishes task review from operation approval. That local authority is a CodeFlowMu deployment choice, not a universal TMPA requirement.
CodeFlowMu Mobile PWA is a constrained remote surface. It displays server-derived facts and returns a small set of human requests to the same authority. It may cache a stale view, but it does not become a second Runtime or bypass server-side checks.

Under the target decision contract described in this article, tapping Approve would send the target, observed revision, reason, and idempotency key. The authoritative service would then recheck the device session, role capability, current revision, and prior use of the request key. Current public CodeFlowMu code proves narrower pieces: device-session checks and a separate Operation Approval service whose server creates an action ID for a digest-bound attempt. It does not prove that the existing mobile route already accepts and enforces this client-supplied revision/idempotency contract. A future task-review path may record a decision in the applicable REVIEW chain; a high-risk Git or external-write action remains a separate operation approval. Later REPORT and verification evidence still determine what actually happened.

In one line: TMPA defines the governance semantics, FCoP defines the collaboration artifacts, CodeFlowMu owns local execution and authority checks, and the phone remains a bounded remote entry point.

Primary sources

Other language: 中文研究原文

More research and engineering records: JoinWell52 Research Center

Why Multi-Agent Governance Can Start with Files

joinwell52 — Tue, 18 Aug 2026 14:39:21 +0000

Why Multi-Agent Governance Can Start with Files

Original research article: English · 中文 · Research Center

The first problem in multi-Agent collaboration is not how to open more sessions. It is how to turn one role's task, another role's delivery, and a third role's review into shared facts that every participant can inspect.

Which task version was authoritative?
Who changed the scope?
Which test report belongs to which implementation?
Did the rejection reason enter the rework request?

The missing component is not a smarter model. It is shared operational truth.

For a local-first, single-machine system with low or moderate concurrency, that truth can begin as files. Tasks, reports, issues and review decisions become explicit artifacts. Paths expose current lifecycle state. Ordered events preserve how state changed.

The protocol starts with one rule:

AI roles cannot coordinate only in their heads. The work must be written into files.

This is not an argument that files should replace databases, queues or workflow engines. It is an ordering principle: make the work visible before upgrading the control plane.

The useful Unix lesson is a common interface

Ritchie and Thompson’s The UNIX Time-Sharing System is often reduced to “everything is a file.” The more useful engineering lesson is that ordinary files, devices and inter-process I/O could be reached through compatible interfaces and hierarchical names.

That idea transfers to Agent governance in three ways:

A human can inspect a task in an editor, an Agent can parse it, a CLI can scan it, and a web view can index it without requiring one SDK.
Names and paths can carry stable meaning: inbox/, active/, review/ and done/ are a state surface both programs and people can understand.
Creation, validation, transition, review and archival can remain separate tools if they honor the same artifact contract.

Unix still needed processes, permissions, pipes and internal interlocks. Files do not automatically provide safe concurrent updates, distributed consistency or exactly-once execution. Here, “files first” means externalizing coordination facts through open artifacts where practical.

A directory becomes a work ledger only with contracts

The blackboard model describes multiple knowledge sources contributing intermediate results to a shared problem-solving surface. A directory can implement such a surface, but an unstructured folder is not governance.

It becomes useful only when:

every artifact has a defined identity;
current state has one authoritative location;
transitions leave ordered evidence;
roles have explicit responsibilities; and
completion depends on evidence rather than an Agent assertion.

A shared ledger coordinates work facts and evidence. It does not replace execution or distributed consistency.

Chat is organized by who spoke when. A work ledger is organized by the work object, current owner, evidence and decisions.

Separate four kinds of work facts

FCoP uses four IPC artifacts to keep different claims apart:

Artifact	Question it answers	Minimum useful content
`TASK`	Who is expected to deliver what?	sender, recipient, scope, priority, acceptance
`REPORT`	What did the worker actually do?	task reference, changes, tests, evidence, risks
`ISSUE`	What is blocking delivery?	symptom, impact, attempts, required decision
`REVIEW`	Who judged what evidence?	subject, reviewer, verdict, rationale, next action

Five lifecycle buckets: use location to answer “where is the task now?”

The five directories under _lifecycle/ form a minimal observable state machine. A TASK may occupy only one bucket at a time; moving the file is the state transition.

Lifecycle bucket	Question it answers	Typical action
`inbox/`	A new task exists. Who will claim it?	create, then wait for `claim`
`active/`	Who is executing or reworking it?	claim; rejected work returns here
`review/`	Delivery was submitted. Who will decide?	`submit`, then approve or reject
`done/`	Did the protocol lifecycle finish or receive approval?	`finish` or `approve`; this is not yet business acceptance
`archive/`	Has the work left the active collaboration surface?	archive after upstream acceptance

inbox --claim--> active --submit--> review --approve--> done --archive--> archive
                    |   ^                   |
                    |   +------reject-------+
                    +---------finish------->+

Four rules keep this model unambiguous:

One current location: the same TASK cannot exist in both active and done.
Move, do not relabel: state changes through controlled migration, not an Agent editing a mutable status field.
Separate now from history: the path answers “where is it now”; append-only transitions: records how it arrived there.
Separate state from credentials: REPORT, ISSUE and REVIEW are delivery, blocking and governance evidence, not current task state.

FCoP v2's tasks / reports / issues / shared / log were the old five buckets organized by artifact type. FCoP v3's _lifecycle/ buckets organize TASK files by work stage. They are different concepts.

Likewise, _lifecycle/review/ means a TASK awaits a decision, while reviews/REVIEW-*.md is an independent governance judgment.

For current lifecycle position, the path is the authoritative NOW fact. For business completion, the upstream role's acceptance of the REPORT and its evidence is decisive.

This distinction keeps a worker's completion claim, protocol approval, and upstream acceptance from collapsing into one ambiguous done label.

Inspectability improves rework

The FCoP repository contains a small Tetris dogfood evidence set. A task was underspecified, the implementer guessed instead of raising an ISSUE, and the defect appeared in the guessed area. Review rejected the result, and an administrator created a sharper rework task.

One example does not prove a production-scale defect reduction. It supports a narrower conclusion: when task, report, review and rework remain separate, failure does not collapse into a vague memory. A maintainer can locate where ambiguity entered and whether the rejection became an actionable next task.

The ledger does not eliminate mistakes. It makes them attributable and convertible into decisions.

When files are a sensible starting point

A file-backed ledger fits when:

work stays on one machine or in a bounded workspace;
human readability matters more than millisecond latency;
artifacts should fit Git, backups and ordinary tools;
people need to inspect and approve Agent work directly; and
the protocol is evolving faster than the control-plane implementation.

Pressure for stronger infrastructure appears when many machines compete for tasks, strict transactions or granular authorization are required, leases and throughput guarantees become central, network-filesystem semantics are insufficient, or directory scanning becomes a bottleneck.

The useful separation is between an artifact plane, which preserves readable evidence, and an execution plane, which owns scheduling, isolation, retries and scale.

A minimum ledger you can inspect today

project/
  fcop/
    fcop.json
    _lifecycle/
      inbox/
      active/
      review/
      done/
      archive/
    reports/
    issues/
    shared/
    reviews/
    history/
      YYYY-MM-DD/
  workspace/
    <slug>/

This structure contains three different planes:

_lifecycle/ is the current TASK state plane;
reports/, issues/, and reviews/ form the evidence and governance plane and do not move with TASK state;
history/ is the long-term history plane for closed tasks and paired reports.

Each TASK keeps append-only migration history in transitions:. A separate events/ directory would create another truth that could drift from the task file.

Then ask:

Does each task have a unique identity and recipient?
Can a human find the authoritative version in under a minute?
Does “done” link to tests, a diff or environmental evidence?
Is the worker report separate from the reviewer judgment?
Does rejection create a traceable next action?
Do transitions retain time, actor, source and destination?
Can a restarted runtime reconstruct what happened from disk?

If most answers are “no,” adding more Agents will usually increase ambiguity rather than throughput.

What “everything is a file” contributes to engineering

The point is not to replace databases, queues and workflow engines with Markdown. It is to establish an open protocol surface with five engineering properties:

Engineering property	How the ledger provides it
Addressable	stable task identity, sender, recipient and parent relationships
Observable	lifecycle buckets expose the current stage directly
Replayable	`transitions:` preserves time, source, destination, actor and tool
Verifiable	TASK, REPORT, ISSUE and REVIEW can be checked against each other
Composable and evolvable	editors, Git, CLIs and web views share the same artifacts, while stronger infrastructure can be added later

Stable identity + path state + transition history + delivery evidence = a governable shared work ledger.

The ledger does not solve contention, transactions, authorization, retries or scheduling by itself. It first answers more basic questions: was the work formally delegated, who owns it now, why was it rejected, and what evidence justified acceptance?

Starting with files is neither nostalgia nor a rejection of infrastructure. Its engineering value is to let humans, Agents and tools share the same inspectable facts, then upgrade the execution plane in response to real pressure.

FCoP is not an industry standard or a final answer. It offers a testable starting point: before expanding the control plane, make the collaboration visible, machine-readable and evidence-checkable.

The next implementation question is how to make path transitions testable without exposing partial artifacts. That is covered in Files, Paths, and Events: Implementing and Testing the FCoP State Machine.

Sources: UNIX paper · Blackboard model · FCoP v3 specification · FCoP boundary charter

More research notes: JoinWell52 Research Center

Completion Claim Accepted State: A Verification Contract for Agents

joinwell52 — Sun, 16 Aug 2026 15:25:25 +0000

Completion Claim ≠ Accepted State: A Verification Contract for Agents

Original research note: English · 中文 · Research Center

An Agent finishes its last action and says the task is complete. Should the runtime believe it?

In long-running Agent work, that is where a surprising number of failures begin. The final message may sound convincing even when a required action was skipped, the result was never read back, an external blocker stopped the workflow, or an unwanted side effect occurred.

The worker's statement is useful, but it is still only a completion claim.

Microsoft Research's Universal Verifier work makes this distinction concrete for computer-use Agents. Its architecture separates process quality from outcome attainment, distinguishes controllable from uncontrollable failures, and retrieves screenshot evidence against individual rubric criteria instead of trusting the last screen or the Agent's own summary.

The reusable engineering pattern is not “add one more judge model.” It is a separation of responsibilities:

worker action
→ completion claim
→ deterministic readback + claim-specific evidence
→ independent verification
→ acceptance authority
→ completion receipt

Three checks that should not be collapsed

1. Deterministic checks

These answer questions that should not require interpretation:

Does the database record exist?
Did the expected file change?
Did the test suite pass?
Was the commit created and pushed?
Is the external system actually in the requested state?

2. Learned verification

Some outcomes need interpretation. A verifier may inspect a trajectory, screenshots, intent alignment, failure responsibility, and side effects. This is useful, but it should produce a versioned judgment with evidence references—not an unquestionable truth value.

3. Human or policy acceptance

Irreversible, ambiguous, regulated, or high-impact work still needs an acceptance authority. That authority may accept, reject, escalate, or leave the claim undetermined.

The three checks can disagree. A worker may follow the correct process but be blocked by a CAPTCHA. A visible outcome may be achieved through an unexpected valid route. A task may look complete while producing an unrequested side effect. Preserving those disagreements is safer than forcing every run into completed or failed.

A minimal runtime state model

running
→ completion_claimed
→ verifying
→ accepted | rejected | escalated | undetermined

The Microsoft paper reports strong results, including a 1% false-positive rate on its internal split and 8% on the external Browserbase split. That is promising, but not a universal production guarantee. The benchmark is relatively small, the work focuses on web computer-use trajectories, and human labels are still judgments rather than an objective completion oracle.

The main lesson is architectural: the same component should not be both claimant and final acceptor.

How are you handling this in Agent systems?

Can the worker mark its own task complete?
Which evidence must exist before done is accepted?
Do you preserve undetermined and escalated as real states?

Sources: Microsoft Research paper · Universal Verifier implementation

More research notes: JoinWell52 Research Center

Trace Is Not Governance: From Work Facts to SaaW

joinwell52 — Thu, 13 Aug 2026 17:14:48 +0000

Trace Is Not Governance: From Work Facts to SaaW

An engineering lineage through TMPA, FCoP, CodeFlowMu, and Self-Morphing

Read the complete 23-section manifesto, From SaaS to SaaW

中文版

An Agent called tools, modified files, and finally returned completed.

What does that prove?

It proves only that an execution occurred.

It does not automatically prove that the task was legally completed, the tests were confirmed, the delivery was reviewed, conflicts were resolved, or any role had the authority to move the task into its next state.

This is the architectural boundary that long-running Agent systems most often overlook:

Trace is not Governance.

Figure 1. A trace records events. Governance reconstructs legal work state from durable facts, rules, responsibility, and authority.

1. Why an execution trace is not enough

A trace can answer which tool a model called, when an operation occurred, and what the tool returned.

Real work requires another set of answers:

Who authorized the task?
Who formally accepted responsibility?
Which artifact represents the official delivery?
Can the test result be independently verified?
Who performed the review?
Is the current lifecycle state legal?
Do unresolved conflicts, missing evidence, or dangling references remain?
Who continues after a process restart?

Adding more log lines does not solve these questions. Logs remain system events. Governance concerns work facts, responsibility, and the legal effect of decisions.

The first step toward a digital employee is therefore not giving an Agent more tools. It is making work facts independent of the Agent session.

2. TMPA: Making work facts reconstructable

TMPA (Textual Multi-Agent Process Architecture) is a text-message-based asynchronous multi-agent process architecture designed for SME-first, minimum-infrastructure environments.

It is not an Agent scheduler or a central runtime. TMPA addresses how tasks, responsibility, evidence, conflicts, and audit state become valid when Agents and humans collaborate asynchronously over time.

Its core consists of four connected rules:

Text carries durable messages and state; each writer maintains its own local serial stream; multiple serial streams advance asynchronously to form parallel collaboration; readers aggregate available evidence to reconstruct process, responsibility, lifecycle, conflicts, and audit state.

Figure 2. Each actor appends its own facts. Cross-stream references form a partial order. The Reader aggregates evidence without overwriting conflict.

The important point is not simply “using text instead of a database.” Two deeper principles matter.

First, responsibility needs a clear source. PM, DEV, QA, and human decision-makers preserve their own local fact streams instead of rewriting another actor's history.

Second, state is not merely the last value of a field. A Reader recalculates current state from objects such as Task, Acceptance, Report, Review, Decision, Issue, and Correction.

Models may change and processes may restart, but established work facts do not disappear with the session.

3. FCoP: Bringing governance semantics into project collaboration

Theory and specifications need an executable form of coordination.

FCoP (File-based Coordination Protocol) is a multi-agent behavioral-governance protocol that uses the filesystem as its sole synchronization primitive.

Its project-visible Profile can be summarized as follows:

Directory is state: inbox → active → review → done → archive.
Filename is routing: sender, recipient, object type, and sequence express identity.
Content is payload: Markdown and frontmatter carry tasks, reports, references, and evidence.
Atomic movement is synchronization: lifecycle transitions use os.rename().

Figure 3. Lifecycle change moves a project-visible work object instead of overwriting a central status field. Humans, Agents, Readers, and operations tools inspect the same fact plane.

FCoP is not merely a way to “send messages with files.” It makes handoffs, reports, reviews, decisions, issues, and recovery paths observable, referenceable, and auditable.

Its boundary is equally important: FCoP governs collaborative behavior. It does not provide model reasoning, process scheduling, identity authentication, or resource allocation, and it is not a complete Agent Runtime.

4. CodeFlowMu: Bringing roles, tools, and governance into real execution

If TMPA defines work facts and governance semantics, and FCoP provides a project-visible file-driven coordination protocol, then CodeFlowMu addresses how those semantics and protocols enter a real Agent runtime world.

Its engineering starting point is not a giant central Agent.

Reasoning remains in mature model ecosystems. Browsers, APIs, CLIs, MCP, and business systems perform actual operations. CodeFlowMu concentrates on role orchestration, responsibility boundaries, Skill routing, lifecycle, FCoP integration, reports, reviews, recovery, and human decisions.

Figure 4. Models reason and tools act. CodeFlowMu organizes work, FCoP carries facts, and TMPA guides governance semantics.

The three are therefore not three similar products:

Layer	Responsibility	Non-responsibility
TMPA	Defines which work facts can become valid and reconstructable	Does not schedule or execute work
FCoP	Brings those facts into project-visible collaboration	Is not a complete Agent Runtime
CodeFlowMu	Runs roles, tools, protocols, lifecycle, recovery, and governance	Does not use runtime events as a substitute for business decisions

Only with these boundaries can a system avoid treating “the Agent returned completed” as “the organization accepted the delivery.”

5. The Meta-Development Runtime: Development capability becomes production capability

The most important thing about CodeFlowMu is not only that multiple Agents can develop software together.

More importantly, that development capability can itself become production capability for the next generation of digital employees.

We call this form the Meta-Development Runtime.

Roles such as PM, DEV, QA, and OPS can build more than conventional software. They can combine job responsibilities, workflows, Skills, permissions, governance policies, validation rules, runtime configuration, recovery rules, and human decision gates into a:

Digital Employee Package: turning a digital employee into an engineered product.

A position capability can then be defined, developed, tested, versioned, deployed, upgraded, and rolled back like software.

6. Self-Morphing: “Developing itself” under governance

Self-Morphing does not mean allowing a running Agent to rewrite itself arbitrarily, nor does it mean an unlimited recursion of Agents creating Agents.

It describes a strictly isolated and recoverable improvement loop. Production work emits evidence. Evidence exposes a capability gap. The Meta-Development Runtime designs an improvement and produces a new Digital Employee Package. Only after isolated validation and explicit authorization may that version enter the next work cycle.

Figure 5. Evidence can enter meta-development, but meta-development cannot rewrite the live production runtime. Validation and authority control deployment, and a rollback path always remains available.

The complete loop is:

Work → Evidence → Gap → Improvement → Isolated Validation → Human or Governance Authorization → Deployment → New Work Cycle

If the source of a change is not traceable, tests are not reproducible, deployment is not authorized, the running version is not identifiable, or failure cannot be rolled back, then “self-evolution” is only unauditable automatic rewriting.

7. Humans do not disappear; they leave the operation layer

SaaW does not remove humans from the system.

Low-risk, reversible, in-policy work such as retrieval, organization, validation, reporting, and synchronization can increasingly be performed by digital employees. External publication, irreversible modification, money, credentials, privacy, and policy exceptions must stop at a human authority boundary.

Humans no longer need to perform every click and data transfer. Their responsibilities move toward:

defining objectives and authority boundaries;
handling conflict and exceptions;
reviewing consequential evidence;
approving, rejecting, or requesting rework;
taking final responsibility for high-impact outcomes.

In SaaS, humans usually remain in the software operation layer. In SaaW, humans increasingly move into governance and final authority.

8. SaaW: When software begins to carry work

SaaW (Software as an Agent Worker) is the higher-level name for this transition. Software stops being only a collection of capabilities operated by people and begins to carry work continuously under explicit job responsibilities, authority boundaries, and governance rules.

It is not a new chat window, and it is not created by simply adding an Agent. A real digital work subject needs a role, an environment, Skills, permissions, state, governance, evidence, recovery, and human authority boundaries.

Validated capability must remain separate from the research frontier.

The public engineering foundation available today includes the TMPA V1.0 architecture paper, core specification, and implementation case; the FCoP protocol and implementation; and the open CodeFlowMu engineering runtime environment. The implementation case pins CodeFlowMu v1.8.0 and records a 14/14 validation result against TMPA S1.0.

Standardized Digital Employee Packages, a standardized Agent PC, domain Work Runtimes, and broader Self-Morphing validation remain research and future engineering work.

Conclusion

The decisive change from Agent systems to digital employees is not that a model becomes more human-like. It is that work gains facts, responsibility, evidence, recovery, and authority structures that exist independently of the model session.

TMPA makes work facts valid. FCoP makes coordination facts visible. CodeFlowMu brings them into real execution. The Meta-Development Runtime then turns runtime evidence into Digital Employee Packages and improves them through governed Self-Morphing, ultimately pointing toward SaaW.

Software was once a tool.

Then it became a service.

Now, it is beginning to work.

From Software Market to Digital Labor Market.

Complete manifesto: From SaaS to SaaW: When a Codebase Starts “Developing Itself”
TMPA V1.0 DOI: 10.5281/zenodo.21888488
FCoP: GitHub Repository
CodeFlowMu: Open Engineering Runtime
Version status: V1.0 · Published
Research Center: Digital Employee Works

Durable Agent Runtime Is Becoming the Baseline

joinwell52 — Tue, 11 Aug 2026 17:22:18 +0000

Durable Agent Runtime Is Becoming the Baseline

Persistence, checkpoints, interruption, recovery, sandboxing, and structured runtime operations are becoming standard infrastructure.

Author: JoinWell52 Research Center · 2026-08-02

Originally published at JoinWell52 Research Center. Visit the Research Center home page for more research and articles. This cross-post uses the original English article as its canonical source.

Summary

One of the strongest open-source engineering signals is that agent systems are moving beyond short-lived model loops. The important runtime questions are now: where state is stored, where execution can pause, how work resumes after failure, how risky actions are reviewed, and where tools actually run.

LangGraph treats persistence, checkpoints, human interruption, and fault-tolerant resume as first-class runtime primitives. OpenHands separates agent logic from a sandboxed execution environment. CrewAI combines crews with persistent flows and operational deployment. AutoGen exposes save/load state, team control, termination, trace logging, and structured event logging.

The Research Center judgment is:

A production agent runtime is no longer defined by tool calling alone. Its minimum engineering contract includes persistent state, interruption, recovery, isolation, observability, and explicit completion control.

Source

The following official materials were selected because they describe concrete runtime mechanisms rather than general product positioning:

LangGraph persistence and human-in-the-loop documentation — checkpoints, threads, pending writes, fault recovery, approve/edit/reject decisions, and resume behavior.
OpenHands runtime and sandbox documentation — Docker isolation, process and remote sandboxes, runtime plugins, command execution, and service exposure.
CrewAI documentation — stateful flows, long-running workflow resume, guardrails, human-in-the-loop triggers, observability, and deployment.
AutoGen documentation — team state, save/load, termination, trace logging, structured event logging, and runtime-oriented team controls.

These sources document available mechanisms. They do not independently prove reliability under every production workload.

Key Observations

1. Persistence is moving into the runtime core

LangGraph saves graph state as checkpoints organized by thread. Checkpoints enable interruption, memory, time-travel debugging, and fault recovery. Pending writes reduce unnecessary re-execution when some nodes in a step succeed and another fails.

AutoGen separately supports saving and loading agents, teams, and termination conditions. CrewAI Flows describe state management, persistence, and resume for long-running workflows.

The common direction is clear: runtime state must survive beyond one model response or one process lifetime.

2. Human review is becoming an execution state

LangGraph human-in-the-loop middleware can pause before sensitive tool calls and resume after approve, edit, or reject decisions. This is not merely a UI confirmation; the graph state is persisted so the execution can stop safely and later continue from the same thread.

CrewAI also places human-in-the-loop triggers inside task and flow control. The engineering pattern is therefore:

Proposed action
      ↓
Policy evaluation
      ↓
Persisted interrupt
      ↓
Human decision
      ↓
Resume / modify / reject

Diagram: joinwell52 Research Center synthesis from official runtime documentation.

3. Isolation is becoming part of runtime correctness

OpenHands runs commands, edits files, and starts services inside a sandbox. Docker is the recommended isolated provider; process mode is faster but explicitly unsafe; remote sandboxes support managed and hosted execution.

This shows that tool capability and execution safety cannot be treated as separate afterthoughts. The runtime must know where an action executes and what isolation boundary applies.

4. Observability is splitting into trace and structured events

AutoGen distinguishes human-readable trace logs from structured events intended for machine consumption. CrewAI promotes observability for production flows. LangGraph connects checkpointed execution to tracing and debugging.

This distinction matters: operator logs help people understand a run, while structured events support automation, metrics, alerts, and governance.

Cross Analysis

Runtime capability matrix

Runtime capability	LangGraph	OpenHands	CrewAI	AutoGen
Persistent state	Thread checkpoints and state snapshots	Conversation and runtime state around sandbox execution	Flow state and persistence	Save/load agent and team state
Resume after interruption	Native command-based resume	Runtime/session restart depends on deployment path	Long-running flow resume	Reload saved team/application state
Human approval	Interrupt with approve/edit/reject	Operator interaction around task execution	Human-in-the-loop triggers	User proxy and team control patterns
Failure recovery	Checkpoint and pending-write recovery	Isolated runtime restart and environment recreation	Flow-level control and redeployment	External termination, reset, state restoration
Execution isolation	Not the primary abstraction	Docker/process/remote sandbox providers	Deployment environment dependent	Code executor and runtime dependent
Structured observability	State history and tracing integrations	Runtime logs and environment visibility	Built-in observability and managed monitoring	Separate trace and structured event loggers
Completion control	Graph end state and node transitions	Agent/task completion	Task/process/flow completion	Termination conditions and team result

Note: This matrix summarizes documented mechanisms. It is not a performance benchmark.

Minimum durable runtime contract

Work identity / thread
        ↓
Persistent state
        ↓
Executable step
        ↓
Checkpoint + event
        ↓
Policy / human interrupt
        ↓
Resume, retry, or recover
        ↓
Evidence-backed completion

A runtime that omits any of these layers may still demonstrate an agent, but it is difficult to operate as a long-running worker.

Architecture Judgment

Checkpointing is becoming the dividing line between demos and durable systems. A durable runtime must resume from recorded state rather than restart reasoning from scratch.
Human review must be modeled as a lifecycle state. Approval cannot remain an external chat convention.
Execution isolation belongs in the runtime contract. Tool permission without sandbox context is incomplete.
Structured events and human-readable logs serve different consumers. Both are required.
Completion needs an explicit state transition. A natural-language claim of success is not sufficient evidence.

Engineering Impact

TMPA

This report does not modify TMPA publications. As research input, it reinforces the importance of Event, Lifecycle, Authority, Integrity, and Reader reconstruction across interrupted and resumed execution.

Digital Employee

A Digital Employee runtime must persist work identity, current state, pending approvals, tool environment, recovery history, evidence, and completion authority across sessions.

CodeFlowMu

CodeFlowMu already contains FCoP lifecycle files, task state, recovery actions, runtime logs, and role-based completion gates. The next engineering step is to make checkpoint, interrupt, recovery, and completion events available through one stable runtime contract rather than separate operational conventions.

Further Research

Compare checkpoint granularity and replay semantics across runtimes.
Examine how secrets and credentials are bound to sandboxes and tools.
Compare structured event schemas and trace formats.
Test recovery behavior under partial multi-agent failure.

References

LangChain, LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview
LangChain, LangGraph persistence: https://docs.langchain.com/oss/python/langgraph/persistence
LangChain, Human-in-the-loop: https://docs.langchain.com/oss/python/langchain/human-in-the-loop
OpenHands, Runtime Architecture: https://docs.openhands.dev/openhands/usage/architecture/runtime
OpenHands, Sandbox overview: https://docs.openhands.dev/openhands/usage/sandboxes/overview
CrewAI, Documentation: https://docs.crewai.com/
CrewAI, CrewAI AMP: https://docs.crewai.com/enterprise/introduction
Microsoft AutoGen, Managing State: https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/tutorial/state.html
Microsoft AutoGen, Logging: https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/framework/logging.html

Research Center

Agent Capability Is Being Packaged as Skills, Plugins, and Contracts

joinwell52 — Tue, 11 Aug 2026 16:59:56 +0000

Agent Capability Is Being Packaged as Skills, Plugins, and Contracts

Reusable capability is moving out of hidden prompts and into explicit packages, interfaces, workflow nodes, and events.

Author: JoinWell52 Research Center · 2026-08-02

Originally published at JoinWell52 Research Center. Visit the Research Center home page for more research and articles. This cross-post uses the original English article as its canonical source.

Summary

A significant open-source engineering shift is changing how agent capability is represented. Early systems often embedded capability inside one long prompt plus an unrestricted tool list. Current systems increasingly package capability as explicit, inspectable components.

OpenHands uses skills, hooks, MCP configurations, specialized agents, commands, and plugins. CrewAI separates agents, tasks, tools, crews, flows, guardrails, memory, knowledge, and structured outputs. AutoGen separates AgentChat teams from the event-driven Core and requires application-defined message contracts. LangGraph treats nodes, state, edges, interrupts, and persistence as explicit orchestration components.

The Research Center judgment is:

Reusable agent capability is becoming a governed package with a name, scope, activation rule, interface, version, runtime dependency, event surface, and evidence trail. A prompt fragment alone is not a sufficient skill contract.

Source

The selected official sources cover four complementary engineering directions:

OpenHands Skills and Plugins — progressive disclosure through SKILL.md, always-on repository context, triggered skills, plugin packages, hooks, MCP servers, agents, and commands.
CrewAI Agents and Flows — role-oriented agents, tools, memory, knowledge, structured output, persistent flows, guardrails, callbacks, and observability.
AutoGen Teams and Core — team patterns, handoffs, event-driven runtime, message protocols, memory interfaces, state serialization, and structured logging.
LangGraph orchestration — explicit state, nodes, transitions, interrupts, persistence, and human decision points.

These sources reveal engineering patterns. They do not establish one universal standard for skill packaging.

Key Observations

1. Skills are moving from prompt text to loadable artifacts

OpenHands describes skills as specialized prompts with domain guidance and automated handling, but packages them as files with explicit loading behavior. Always-on context is separated from on-demand skills; keyword or agent-triggered activation supports progressive disclosure. Organization-, user-, and repository-level scopes are distinct.

This is more operationally useful than copying every instruction into every system prompt.

2. Plugins are becoming capability bundles

OpenHands plugins can combine skills, hooks, MCP configuration, specialized agents, and commands. The important engineering change is that a capability package can include both knowledge and runtime integration.

Capability package
  ├── Skill instructions
  ├── Tool / MCP bindings
  ├── Lifecycle hooks
  ├── Specialized agent definitions
  ├── Commands
  └── Versioned package metadata

Diagram: joinwell52 Research Center synthesis from OpenHands plugin documentation.

3. Workflow systems are separating capability from orchestration

CrewAI distinguishes agents and their tools from Flows that route, persist, and resume work. LangGraph similarly separates node behavior from state and graph transitions. AutoGen separates agents from team patterns and from the event-driven runtime.

This allows the same skill or tool to be reused in different workflows without redefining the entire worker.

4. Message and event contracts are becoming important

AutoGen’s application stack requires developers to define message types as a behavior contract. AutoGen also separates trace logs from structured events. This is a strong signal that agent interaction needs machine-readable interfaces, not only conversational text.

A capability is operationally incomplete when other components cannot determine:

what input it accepts;
what output it promises;
what events it emits;
what errors or holds it can return;
what authority it requires;
how it is versioned.

Cross Analysis

Capability representation matrix

Dimension	OpenHands	CrewAI	AutoGen	LangGraph
Primary capability unit	Skill / plugin / agent / command	Agent / tool / task / crew	Agent / team / message handler	Node / runnable / graph
Activation	Always-on, user-triggered, keyword or agent-selected	Task/process/flow invocation	Runtime messages, team selection, handoff	Edge, condition, interrupt, command
Tool integration	Plugin and MCP configuration	Agent tools and integration tools	Tool-capable agents and extensions	Tool nodes and application code
State	Conversation and workspace context	Flow and crew state	Agent/team state and memory protocol	Explicit graph state and checkpoints
Interface contract	Skill format and plugin structure	Structured task inputs/outputs and Pydantic models	Message protocol and event types	State schema and node transition contract
Observability	Runtime/plugin logs and hooks	Traces, callbacks, monitoring	Trace and structured event loggers	State history and tracing integration
Distribution	Registry/repository packages	Project packages and managed platform	Python components and distributed runtime	Libraries, deployment, and runtime services

Note: This comparison describes documented abstractions, not feature parity or quality.

Proposed minimum Skill Contract

skill:
  id:
  version:
  purpose:
  activation:
  input_contract:
  output_contract:
  allowed_tools:
  required_authority:
  runtime_dependencies:
  emitted_events:
  failure_states:
  evidence_requirements:
  owner:

This is a Research Center synthesis, not a frozen product schema.

Architecture Judgment

Skill should be an explicit artifact. Hidden prompt content cannot be reliably discovered, versioned, activated, or audited.
Capability and workflow should be separate. A skill describes what can be done; a workflow determines when and in what sequence it is used.
A plugin may bind knowledge to runtime infrastructure. This is powerful but expands the security and review boundary.
Message and event contracts are necessary for multi-agent composition. Free-form text alone is insufficient for dependable orchestration.
Activation state must be observable. Installed, loaded, selected, executed, and verified are different states.

Engineering Impact

TMPA

This report does not change TMPA publications. As research input, it supports explicit references among Role, Authority, Message, Event, Lifecycle, and Integrity for capability activation and execution.

Digital Employee

A Digital Employee should own a governed capability catalog. Each skill should have scope, version, owner, authority requirements, runtime bindings, evidence expectations, and evaluation history.

CodeFlowMu

CodeFlowMu currently loads skills and exposes tool usage, but the product should distinguish:

available
→ installed
→ activated
→ invoked
→ completed
→ verified

The Runtime should record which version of a skill was active for each WorkOrder and which structured events and evidence were produced.

Further Research

Compare AgentSkills, Claude Code plugins, MCP servers, and framework-specific tools.
Define a portable Skill Contract for CodeFlowMu.
Examine signature, trust, and permission models for third-party capability packages.
Test whether one skill can operate consistently across different Agent providers.

References

OpenHands, Skills overview: https://docs.openhands.dev/overview/skills
OpenHands, Organization and User Skills: https://docs.openhands.dev/overview/skills/org
OpenHands, Adding New Skills: https://docs.openhands.dev/overview/skills/adding
OpenHands, Plugins: https://docs.openhands.dev/sdk/guides/plugins
CrewAI, Documentation: https://docs.crewai.com/
CrewAI, CrewAI AMP: https://docs.crewai.com/enterprise/introduction
Microsoft AutoGen, Teams: https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/tutorial/teams.html
Microsoft AutoGen, Application Stack: https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/core-concepts/application-stack.html
Microsoft AutoGen, Memory and RAG: https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/memory.html
Microsoft AutoGen, Logging: https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/framework/logging.html
LangChain, LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview

Research Center

One Agent Said “Done.” Why Didn’t the Team Release It?

joinwell52 — Tue, 11 Aug 2026 15:20:52 +0000

One Agent Said “Done.” Why Didn’t the Team Release It?

A CodeFlowMu multi-agent fact-checking field case

Author: JoinWell52 Research Center · 2026-08-06

Originally published at JoinWell52 Research Center. Visit the Research Center home page for more research and articles. This cross-post uses the original article page as its canonical source.

This is not model-level hallucination detection. It is protocol-and-organization governance: FCoP, as Agent POSIX, externalizes facts; CodeFlowMu, as the application and Runtime, runs the roles; PM decides whether the evidence is sufficient to advance.

At 1:06 PM, a DEV subexecution returned completed.

Its summary looked polished. It described the implementation, the tests, the commit, and the remaining gaps. It looked like the kind of result a project manager could forward to QA without thinking twice.

But the same raw event contained three very different statements:

The shell command returned no exit status, so its result is unknown — do not assume it ran or succeeded.

Test results summary: Unconfirmed in this session.

Commit SHA: Not available here.

On one side: “done.”

On the other: no confirmed command result, no confirmed tests, and no commit SHA.

If PM had accepted the summary, QA would have received a delivery that did not yet exist. If QA had merely repeated DEV’s conclusion, the claim could have propagated into task status, reports, acceptance, and release.

That did not happen in WP-13.

PM did not release it.

Hallucination happens inside one agent. Failure happens when the team treats it as fact.

Most conversations about hallucination prevention focus on making the model smarter: a larger model, a stronger prompt, another reflection pass, or a second model that reviews the first one.

Those techniques help, but they still depend on the same basic idea: ask a language model to correct a language model.

CodeFlowMu takes a different approach. A multi-agent system is not several models taking turns writing, nor is it three models voting. It is a team with distinct jobs, fact sources, authority, and handoff boundaries:

DEV implements the task and may make mistakes;
PM decides whether delivery facts satisfy the task contract;
QA re-verifies the result as a separate role;
Runtime handles wake-up, scheduling, recovery, UI, and live activity streams, but does not replace PM’s business judgment.

The goal is not to make hallucination impossible.

The goal is to make sure that a hallucination produced by one role cannot automatically acquire system authority.

Agents may be wrong. The organization must not make them right by default.

The live scene: PM’s fact judgment above, the agent’s activity stream below

The image below is not a reconstructed flowchart. It is a screenshot from the CodeFlowMu operating interface during the incident.

The upper area shows the PM-facing task and fact-checking conversation. The lower area preserves the live agent activity stream and visible reasoning summaries. The most important sentence is not DEV’s self-report. It is PM’s judgment:

The sub-agent claimed completion, but the artifacts were incomplete -- do not treat it as complete.

This is not a caption added later. It is the business decision PM made after checking disk, Git, REPORT, and task state. It turns completed back from a persuasive language claim into an evidence-insufficient result that cannot be released.

Around 1:08 PM, PM could see that no formal DEV REPORT existed, Git HEAD still belonged to the previous work package, required test files were incomplete, Shell had returned no exit status multiple times, and the subexecution itself admitted that tests were unconfirmed and the SHA was unavailable.

PM’s decision was immediate:

Do not dispatch QA. Do not close the task. Do not create a duplicate replacement task. Continue the original task.

Five role actions turned “done” into a verifiable delivery

Act 1: DEV lost certainty at the tool boundary

Part of the implementation existed, but Edit, Shell, and Read calls repeatedly returned abnormal or incomplete status. The key problem was not merely that a tool failed. The tool could not provide a reliable exit status.

In engineering, there is a hard boundary between unknown and success. No exit status means a command cannot be assumed to have run. No output means tests cannot be assumed to have passed. No commit means the work has not become a traceable delivery.

Act 2: Subexecution produced a completion-like narrative

The subexecution was not malicious. It attempted to continue the work and produced a technically coherent plan.

But when tools could not confirm results, it still organized partial information into a narrative that sounded complete. That is one of the strongest capabilities of language models—and one of the most dangerous in an execution system:

they can turn incomplete and conflicting evidence into a coherent story.

Coherence is not closure.

Act 3: PM blocked the story from acquiring business authority

PM did not ask the same execution path, “Are you sure?” A second confirmation would still be another language claim.

The more important engineering question is how PM obtained the facts. Was PM merely prompted to behave this way, or did Runtime enforce a non-LLM gate before release?

The WP-13 evidence package supports the following actual chain:

Runtime recorded and surfaced the subexecution-ending event while preserving no exit status, unconfirmed tests, and unavailable SHA as separate facts;
Runtime preserved the original task identity and returned the task to PM’s workflow;
PM Agent, inside its own execution session, actively read the TASK, lifecycle location, REPORTs, disk files, Git state, and Runtime event evidence;
whether a file exists, where HEAD points, and whether an exit status is null are deterministic observations;
whether those observations satisfy the WP-13 completion contract—and whether to continue, rework, or dispatch QA—remained PM’s business judgment.

The article therefore should not describe WP-13 as “FCoP automatically detected a hallucination,” nor should it claim that a global hard-coded collect_evidence() gate rejected the task on PM’s behalf.

Runtime stores and exposes facts. PM checks them under a role and task contract. Business release authority remains with PM.

What PM checked, and how another engineer can reproduce it

The commands below are reproducible equivalents that show where each fact comes from. They are not a claim that PM executed the same literal command sequence character for character.

Fact to verify	Reproducible source or equivalent check	State around 1:08 PM
Current task state	Locate `TASK-20260805-019` under `fcop/_lifecycle/{inbox,active,review,done}/`	Still in `active`
Formal DEV handoff	Search `fcop/reports/REPORT-*-DEV-to-PM.md` and verify task references	No matching REPORT
Traceable WP-13 commit	`git rev-parse HEAD`, `git show --stat HEAD`, then inspect WP-13 paths	HEAD still belonged to the previous WP
Required files on disk	`stat/glob` the WP-13 files and test paths required by the TASK	Incomplete
Confirmed command and test evidence	Read the raw Runtime events, Shell exit statuses, and test output	At least one relevant Shell event had `exit_status = null`; the result remained `unknown`

task_bucket is not completion evidence by itself; it is a lifecycle-consistency constraint. For this pre-QA review, PM expected the task to remain in active. If it had already moved to review, done, or archive, that would itself be state drift and should block progression until reconciled.

Abstracted as pseudocode, the mechanism looks roughly like this:

on_subexecution_finished(event):
    runtime.append(event)
    # completed and exit_status=null remain two different facts
    runtime.surface_to_pm(event.task_id)

PM.review_completion(task_id):
    contract = read_task_contract(task_id)
    facts = {
        task_bucket: locate_task(task_id),
        report: find_dev_report(task_id),
        git_head: git_rev_parse("HEAD"),
        required_files: stat(contract.required_files),
        command_results: read_runtime_events(task_id)
    }

    unexpected_bucket = facts.task_bucket != "active"
    shell_events = [
        e for e in facts.command_results
        if e.kind == "shell"
    ]
    any_unresolved = any(
        e.exit_status is null
        for e in shell_events
    )

    if unexpected_bucket
       or facts.report.missing
       or not commit_matches(contract, facts.git_head)
       or not facts.required_files.complete
       or any_unresolved:
        PM.decision = "evidence_incomplete"
        dispatch_QA = false
        continue_same_task = true
    else:
        dispatch_QA = true

This pseudocode is an engineering abstraction of the observed mechanism. It is not a claim that the repository already contained a same-named hard gate. A stronger Runtime may later precompute deterministic diagnostics such as report_missing, commit_unreachable, and evidence_incomplete, while leaving continuation, rework, and acceptance to the role with the appropriate authority.

The following is a normalized evidence summary. Its fields come from the raw event and PM’s checks, but its formatting is not a verbatim copy of the Runtime JSONL:

13:06  subexecution.status = completed
       shell_events.any(exit_status = null) = true
       tests = unconfirmed
       commit_sha = unavailable

13:08  task.bucket = active
       expected_bucket = active
       dev_report = missing
       wp13_commit = missing
       required_test_files = incomplete
       pm_decision = evidence_incomplete
       next = continue TASK-20260805-019; do not dispatch QA

PM found that the completion contract did not close, withheld QA dispatch, and preserved the original task for continued work. No global truth classifier was required—only a role with a bounded responsibility making an explainable judgment from external facts.

Act 4: DEV completed the real delivery on the original task

After the tool channel recovered, DEV continued TASK-20260805-019 instead of creating a new task that would hide the failure history.

Real artifacts then appeared:

commit 609571ddb22d1fbb2bfb5e54692c07beeef4cf23;
12 WP-13 files;
1230 insertions / 452 deletions;
formal REPORT-20260805-037-DEV-to-PM.md;
observation tests: 3/3 PASS;
activity-buffer + project-graph tests: 10/10 PASS;
root-fault + log-center regression: 14/14 PASS;
runtime typecheck: exit 0;
production Active remained disabled;
no real TaskDispatcher delivery path was changed.

Only then did “done” stop depending on DEV’s wording.

Act 5: QA trusted neither DEV nor PM—it trusted re-execution

At 1:09 PM, after verifying the REPORT and commit, PM dispatched TASK-20260805-020 to QA.

QA reran the evidence checks in a separate role. At 1:11 PM, the live activity stream recorded the first completion statement backed by independent execution:

All tests passed, 27/27. DEV’s reported 3+10+14=27 matches the actual result.

The final QA evidence included:

27/27 tests passed;
typecheck exit 0;
git diff --check exit 0;
no TaskDispatcher changes in the commit;
production_active remained false.

This was role-separated QA verification, not an external third-party audit. But it broke the single-agent pattern of self-claim, self-approval, and self-closure.

FCoP is a protocol that lets an agent say no

Language models are not scarce in their ability to keep generating: add another explanation, offer another plan, or turn an incomplete process into a completion-shaped narrative. The scarce capability is to stop when the facts do not close and say no.

One of FCoP’s most important values is that it lets agents do more than say yes; it lets a role say no on the basis of shared facts.

Generating another answer is abundant. Refusing to promote incomplete evidence into “done” is a scarce agent capability.

This no is not a mood or cautious wording. It has operational consequences: do not dispatch QA, do not close the task, do not create a duplicate history, preserve the missing evidence, and continue the original task.

The core of WP-13 is not merely that one agent noticed another agent’s error. Protocol and organization together gave PM a scarce capability: to reject a polished answer before it became a completion fact.

Protocol and application boundary: FCoP is Agent POSIX; CodeFlowMu is the Runtime

This section gives the complete architectural explanation once. Later sections only refer back to it.

FCoP means Filesystem Coordination Protocol

“Filename as Protocol” is not the expansion of FCoP. It is the protocol’s core invariant.

The current formulation is:

Files carry protocol. Paths address state. Events replay transitions.

TASK externalizes what should be done. REPORT externalizes what an agent claims it did. REVIEW externalizes who judged what and on which basis. File location represents current state, while append-only transitions: preserve the past.

FCoP is a behavioral governance protocol layer, not a hallucination detector

FCoP does not understand the business goal of WP-13, run tests, or decide whether a natural-language sentence is true. It defines how agents report behavior, how results are reviewed, and how actions remain auditable inside capability boundaries.

FCoP is Agent POSIX, not Agent OS

FCoP is responsible for	FCoP is not responsible for
State semantics and legal transitions	LLM invocation and tool execution
TASK / REPORT / REVIEW file contracts	Waking agents and scheduling queues
Externalized event formats	Retry policy, heartbeat, and TTL
Audit and append-only history	Deciding which agent executes now
Capability declaration and review semantics	Concrete sandbox, process, and permission enforcement

CodeFlowMu is the application site for FCoP

CodeFlowMu runs PM, DEV, QA, OPS, and other roles; preserves task identity; performs wake-up and scheduling; records Runtime events; displays the live activity stream; and recovers the original task after anomalies.

The relationship can be compressed into:

CodeFlowMu: Application / Runtime / Scheduler / UI
FCoP: Identity + Location + Event + Behavior Governance

Or more plainly:

CodeFlowMu: makes work happen
FCoP: makes what happened reportable, reviewable, and auditable

WP-13 is therefore a CodeFlowMu application case and an FCoP field-evidence case. It is not a case of “FCoP automatically detecting and repairing hallucination.”

The real value of multi-agent systems is organizational veto power

Imagine adding a Reviewer Agent that receives DEV’s answer:

DEV: The task is complete.

Reviewer: Looks reasonable. Approved.

That is still not a team. It is two models evaluating the same narrative.

Real role separation requires at least three properties:

Different responsibilities — DEV delivers, PM judges, QA verifies;
Different fact sources — every role cannot rely on the same natural-language summary;
Different authority — DEV cannot approve itself, QA cannot redefine PM’s task goal, and Runtime cannot replace business judgment.

The key to hallucination containment is therefore not the number of agents. It is the organizational structure.

Without role boundaries, multi-agent means multiple answers. With roles, fact sources, and authority boundaries, it becomes a team.

Three meanings of “success” must remain separate

The most important boundary in this case is:

model-generated completion claim
        ≠
protocol completion state
        ≠
business acceptance

A tool call ending is not work completion

A tool returning completed proves at most that one invocation lifecycle ended. Without an exit status, the result remains unknown.

Work completion is not business acceptance

Code, commit, REPORT, and tests may establish a DEV delivery. Acceptance still requires PM and QA to judge the task contract.

Protocol state does not replace business judgment

In FCoP, path is the NOW truth and events preserve PAST transitions. But even done must not be casually reinterpreted as final business approval. Protocol semantics and business authority must remain precise and separate.

What should this case change? Improve the Runtime before expanding the protocol.

WP-13 first exposed CodeFlowMu Runtime problems:

preserve no exit status as unknown;
never visually collapse subexecution completion into business completion;
attach typed evidence contracts to tasks;
precompute diagnostics such as report_missing, commit_unreachable, and evidence_incomplete;
persist PM fact judgments as lightweight immutable records;
keep QA role-separated and require real reruns;
resume the original task after tool recovery;
add a regression case where a subexecution returns completed without exit status, commit, or REPORT.

Only when multiple independent runtimes demonstrate that the current file contract cannot express a necessary fact should FCoP be expanded. Otherwise every application problem becomes another field, state, or automated judgment, and Agent POSIX grows into another Agent OS.

Conclusion: a team allows an agent to be wrong without allowing the error to pass

WP-13 eventually passed 27 tests. But the more important moment happened before the tests: one agent had already said “done,” and the system did not convert that confidence into success.

PM checked the facts and said no: the sub-agent claimed completion, but the artifacts were incomplete, so the claim could not be treated as complete.

DEV returned to the original task and completed the real delivery. QA reran the evidence and only then returned PASS.

As explained above, FCoP owns the shared fact surface and CodeFlowMu runs the roles; the actual veto belonged to PM, the role with the relevant responsibility and authority.

A single agent tries to be right. A multi-agent team must remain reliable even when one agent is wrong.

Hallucination may be unavoidable, but it can remain a local error instead of becoming an incorrect delivery. That is the most practical and valuable form of multi-agent “hallucination prevention.”

Easter egg: after publication, Claude reproduced the same failure mode

After this article was published, I sent the link to Claude for another editorial pass. I applied its suggestions and published the revision. Claude then repeatedly concluded that the page had not updated. It called the same web_fetch path several times, saw old content, and promoted that observation into a confident explanation that the site or CDN was still serving the previous version.

The problem was not that the tool returned nothing. The problem was that Claude promoted “the tool call completed” into “the returned content is the latest truth,” then treated repeated calls through the same tool and the same information path as independent verification.

I opened the same page on two computers, saw the new version on both, and sent screenshots. Only then did Claude acknowledge:

I treated “the call completed” as “the result is the latest fact.”

Four screenshots: one tool kept validating itself until independent observations intervened

Screenshot 1 — repeated retrieval was mistaken for independent verification. Claude insists that every web_fetch call is a fresh, independent network request. Because six calls returned the same old page, it attributes the result to the site, server, or CDN rather than questioning the shared retrieval path.

Screenshot 2 — new evidence appears, but the explanation remains overconfident. After the user supplies a screenshot showing the revised article, Claude accepts that the new version exists, yet continues to explain its stale result as CDN edge-node inconsistency. That explanation is plausible, but it has not been independently established.

Screenshot 3 — the methodological error is recognized. Claude acknowledges that it kept using one tool and one information path to validate itself. It did not switch to an independent source in the way a PM or QA role would cross-check a disputed fact.

Screenshot 4 — two-device observation forces the claim back into review. Once the user confirms the revised page on two computers, Claude explicitly admits the core failure: it treated “the call completed” as “the result is the latest fact.” The screenshot also records the distinction between repeated use of one tool and genuinely independent verification.

The failure can be compressed into three boundaries:

web_fetch completed
        ≠
the returned page is the latest truth

six calls through the same tool
        ≠
six independent information sources

a plausible CDN explanation
        ≠
a demonstrated root cause

This is the same governance problem as the main WP-13 case. In the article, DEV’s completed could not override disk, Git, REPORT, and test evidence. In the easter egg, Claude’s repeated web_fetch results could not override the new page observed on two devices. The domain changed, but the failure structure did not: an agent may propose a conclusion, but that conclusion cannot promote itself into fact by repeatedly consulting the same tool chain.

Cross-checking on two computers was not an external third-party audit, but it introduced observations independent of Claude’s single retrieval path and was enough to force the original conclusion back into review.

This easter egg also keeps an evidence boundary. It does not prove that the stale result was caused by Claude’s local cache, the CDN, or a particular edge node. It proves only that, while the root cause remained unknown, Claude promoted stale content from one retrieval path into a confident conclusion and continued to use the same source to support itself.

The most dangerous part was not that a tool returned old content. It was that an agent gave that old content an overconfident explanation without independent evidence.

Download the complete evidence package

This article is not a story reconstructed from memory. The original TASKs, DEV and QA REPORTs, Runtime JSONL, session excerpts, test results, commit patch, screenshots, and integrity manifest have been packaged for offline review.

Download the WP-13 multi-agent fact-checking evidence package (ZIP)
View the attachment location on GitHub
SHA-256: 5b5eda3034c822f13421783244b1d0c76a9fa79950bfad0ce61bb8d2e404131c

The package supports review of the claims in this article, subject to the evidence boundary below: it demonstrates that DEV later produced a real delivery and received role-separated QA PASS. It does not establish external third-party certification, and it does not reinterpret the snapshot’s review / pending state as final business approval.

FCoP references

Evidence boundary

This article is based on the WP-13 publication evidence package. The case demonstrates that DEV later produced a real delivery and received role-separated QA PASS. At the evidence snapshot, TASK-019 and TASK-020 remained review / pending; this article does not claim final PM approval or terminal task closure. QA was role-separated verification, not external third-party certification.

FCoP Grew a Project Tree

joinwell52 — Mon, 15 Jun 2026 02:17:57 +0000

FCoP Grew a Project Tree

Subtitle: How a Mini-Game Task Revealed Product Evolution Inside a Multi-Agent Workflow

Author: FCoP Maintainer · 2026-06-14

Note: Some screenshots are from the Chinese CodeFlowMu console. They are included as workflow evidence; the key protocol signals are the task IDs, lifecycle states, and FCoP fields explained in the captions.

I originally wanted the PM in CodeFlowMu to coordinate DEV, OPS, and QA around a small local mini-game.

The game turned out not to be the important part.

The task tree was.

During one failed archive attempt, FCoP exposed something that had not yet been formally written into the protocol: a project tree.

This article is not really about the Grid Runner game itself. It is about a structural change that appeared while debugging a multi-agent workflow: FCoP was designed to manage task flow. In this run, it started to express product evolution.

1. Why Start with a Mini-Game?

FCoP is a multi-agent collaboration protocol. Its core idea is simple: agents should not only “talk” in chat. Their work must land as files. Tasks, reports, review records, and lifecycle transitions all live inside the project directory, so that anyone can later inspect what happened, who did what, and whether the work was actually closed.

CodeFlowMu is an AI collaboration workflow system built on top of FCoP. As ADMIN, I use a Web console to assign work to PM. PM then decomposes the work for DEV, OPS, and QA. The console makes the workflow easier to operate, but the real ledger still lives on disk: TASK-*.md, REPORT-*.md, and the lifecycle folders under fcop/_lifecycle/.

This test was not meant to build a large product. It was meant to check whether multiple roles could complete a full collaboration loop around a small target:

ADMIN creates task → PM decomposes → DEV/OPS/QA execute → REPORT → review → archive

So I chose a very small probe: Grid Runner.

Grid Runner is a local HTML / CSS / JavaScript mini-game. The player moves on a grid, collects coins, avoids monsters, and reaches an exit. The rules are simple, but the task is still rich enough for DEV to implement, OPS to verify the local runtime path, and QA to actually play and score it.

Figure 1. The small game used as the workflow probe. The game itself was intentionally simple; the real test was whether PM, DEV, OPS, and QA could complete the FCoP loop around it.

On June 13, I assigned the first task to PM through the console:

TASK-20260613-020
Grid Runner v0.1
thread_key: panel-task-020

PM followed the normal workflow and assigned work to DEV, OPS, and QA. After the reports came back, task 020 entered done.

At this point, everything looked ordinary. Nobody mentioned a “project tree.” Nobody mentioned “phase tasks.” It looked like a single completed task line.

2. Phase 2 Arrived, But I Had Not Yet Seen the Tree

After the first version was accepted, the product did not stop.

I assigned a second task to PM:

TASK-20260614-004
Grid Runner Phase 2: product upgrade
references:
  - TASK-20260613-020
thread_key: panel-task-020

The goal of 004 was to turn the demo into a more product-like lightweight game: a main menu, five levels, power-ups, local progress storage, a result screen, and visual effects.

PM then decomposed it:

005 DEV  Implement Phase 2
006 OPS  Verify file:// execution
007 QA   Playtest and accept
008 DEV  Fix the missing magnet tile in level 4
009 OPS  Re-check the fix

At the time, I only saw this as “the next segment on the same line.” Task 020 was already complete; task 004 was the follow-up upgrade. My mental model was still a single-task model: once 020 is done, it should be archivable.

In the console, under panel-task-020, the structure was already visible: ADMIN-to-PM tasks 020 and 004 above, and PM-to-team execution tasks below. The tree was already on screen. I just had not yet read it as a tree.

Figure 2. CodeFlowMu console view. The UI is in Chinese, but the important protocol markers are the task IDs, panel-task-020, report_missing, and lifecycle states.

3. The Archive Failed, and I Saw the Project Tree for the First Time

On the morning of June 14, I clicked “Archive” on task 020 in the CodeFlowMu console.

Task 020 was the initial Grid Runner version. DEV, OPS, and QA had all reported back. PM had already submitted a summary. The console showed it as completed. I expected it to move into _lifecycle/archive/.

But the archive did not go through.

The core message was: there were still open child tasks. At the protocol level, this was CHILD_TASKS_OPEN.

I asked PM in the ADMIN ↔ PM chat:

Do the child tasks of this one overlap with 004? Wasn’t 004 opened as a separate new task?

My confusion was concrete: 004 was clearly a later Phase 2 task. Why should it block the archive of 020?

PM answered: this was not an ID collision. It was a parent-child relationship. Task 020 still had Phase 2 task 004 underneath it. Task 004 had then produced 005, 006, and 007; the QA path further led to 008 and 009. The lower tasks had to be closed before 020 could be archived.

Then PM drew a text tree in the chat:

020  Grid Runner initial version
└── 004  Phase 2
    ├── 005–007  implementation, ops check, playtest
    └── 008–009  bug fix and re-check

Figure 3. PM explained the failed archive by drawing the task relation as a tree: 020 as the root, 004 as Phase 2, and 005–009 as execution / fix tasks.

That was the first moment I saw the “project tree.”

It did not come from a protocol spec. It did not come from a dedicated UI prompt. It came from PM trying to explain why 020 could not be archived, by drawing the relationship that already existed on disk.

Figure 4. The archive attempt was blocked because child tasks were still open. This is where the single-task view broke down and the project-tree view became necessary.

At that point, the meaning changed:

020 was no longer just the Grid Runner v0.1 task.
020 had become the project root of the Grid Runner product line.

004 was not an independent new project.
004 was Phase 2 under 020.

So CHILD_TASKS_OPEN was not wrong.

From a single-task view, 020 was complete. From a project-tree view, the Phase 2 branch below 020 had not yet closed. A phase can be complete while the whole project tree is not yet ready to archive.

4. This Was Not AI Inventing an Organization. It Was a Shape Produced by Protocol Composition.

This was not an AI agent inventing a new project management method.

What actually mattered were several rules that already existed:

thread_key       tracks the same collaboration thread
references       marks which delivery a task continues from
parent           expresses parent-child relation
REPORT           requires roles to write back results
CHILD_TASKS_OPEN prevents a parent from being archived while children are open

Add one ordinary behavior: after the first version was accepted, ADMIN assigned Phase 2, and PM decomposed it under the same collaboration thread.

Nobody had designed a “project tree” button. Nobody started by saying “we are building an Epic / Milestone hierarchy.” But those rules stacked together, and the disk began to express this structure:

Project Root → Phase → Execution Task → Fix Task → Archive

In the actual Grid Runner run, it looked like this:

TASK-20260613-020  Grid Runner v0.1 / project root
└── TASK-20260614-004  Phase 2 product upgrade
    ├── TASK-20260614-005  DEV implementation
    ├── TASK-20260614-006  OPS verification
    ├── TASK-20260614-007  QA playtest
    ├── TASK-20260614-008  DEV fix
    └── TASK-20260614-009  OPS re-check

This is what I call controlled emergence.

It is “emergence” because the project tree was not hard-coded in advance.

It is “controlled” because it was not random. It was constrained by the file protocol, task references, PM decomposition, and archive guards.

The rules were small. The original intention was narrow. But once a real project continued across versions, the structure appeared.

5. EVAL Also Read the Tree

After I recognized the tree in chat, I manually ran EVAL from the CodeFlowMu console.

This EVAL is not a formal audit, and it does not replace the FCoP ledger. It is an internal collaboration-state scan. It reads TASK files, REPORT files, and frontmatter under _lifecycle/, then writes suspected structures into GAP-*-panel-scan.md under fcop/internal/eval/.

The scan reported project_tree_emergence:

Root task: TASK-20260613-020
Phase task: TASK-20260614-004
Execution tasks: TASK-20260614-005, 006, 007, 008
Pattern: main task -> phase task -> execution task
Value: FCoP has emerged product-evolution tree and project-management capability from task-flow management

This means the tree was not only an explanation PM drew in chat. The file relationships themselves were readable by a program.

Still, EVAL should be treated as heuristic cross-checking. Sometimes it also identifies smaller local fix chains as subtrees, such as 004 → 007 → 008 or 004 → 008 → 009. Those local readings are useful, but they do not replace the canonical reading: 020 is the project root of the Grid Runner product line, and 004 is Phase 2 under it.

Figure 5. EVAL also detected local project-tree slices. This supported the observation, but the canonical reading remains 020 → 004 → 005/006/007/008.

So the external story should still be grounded in TASK / REPORT / archive paths. EVAL only shows that the human intuition and the programmatic scan aligned.

6. The Protocol Was Not Wrong. The Console Had Not Explained the Tree.

My confusion did not come from a protocol error.

The opposite is closer to the truth: the protocol was protecting consistency. Since open child tasks remained below the parent, the parent could not be archived.

The real issue was that the console still mainly presented the workflow as a flat task lifecycle. It had not yet exposed the Project / Phase / Execution layer.

As a result, the same screen could mix several states:

done              this delivery of 020 was completed
report_missing    some child path was still missing a report
CHILD_TASKS_OPEN  the root still had open children

Each state made sense on its own. But together, they looked contradictory to ADMIN: if the task is done, why can it not be archived?

Once the project-tree view appears, the contradiction disappears:

phase complete ≠ project tree closed
task done ≠ root node archivable

This is not protocol debt. It is product-expression debt.

CodeFlowMu should add three things next:

The console should display Project / Phase / Execution levels, not only a flat task list.
When PM creates a Phase, the edge type must be explicit: continue the current main line, or create an independent thread.
Archive blocking should explain the tree-shaped reason, not only show CHILD_TASKS_OPEN; it should list which Phase and which child task are still open.

7. The Real Value of This Emergence

ADMIN’s real intent was simple: 020 had been accepted; continue with a Phase 2 product upgrade.

But PM made a “project-manager-like” structural choice during execution: Phase 2 was kept inside the same panel-task-020 thread, and the disk formed a 020 → 004 product-evolution tree.

That is the emergence point. It was not simply that ADMIN phrased the request incorrectly, nor that PM wrote a wrong field. Product intent and lifecycle representation overlapped in the same collaboration thread, and the tree shape grew out of that overlap.

This was not a simple mistake. It was two layers of truth stacked together:

Layer	Judgment
Product semantics	✅ Reasonable. 004 really was Grid Runner Phase 2, continuing from 020.
Lifecycle semantics	⚠️ Risky. If 004 enters the same thread / parent relationship before 020 is fully archived, 020 can be blocked by `CHILD_TASKS_OPEN`.
Protocol capability	✅ Emergent. FCoP grew a structure from “task flow” into “project root → phase → execution line.”
Console expression	❌ Insufficient. The console still presented a single-task lifecycle, so users saw `done`, `report_missing`, and `child_open` mixed together.

Grid Runner itself was just a mini-game. The structure produced by the collaboration was more important than the game.

Originally, FCoP only had a task flow:

ADMIN → PM → DEV/OPS/QA → REPORT → REVIEW → DONE

But this Grid Runner run produced another shape:

Project Root → Phase → Execution Tasks → Fix Line → Final Close

The tree on disk looked like this, consistent with the ASCII tree PM drew in chat:

TASK-20260613-020  Grid Runner v0.1 / static-game milestone
└── TASK-20260614-004  Phase 2 product upgrade
    ├── 005 DEV
    ├── 006 OPS
    ├── 007 QA
    ├── 008 DEV fix
    └── 009 OPS fix

This matches the internal EVAL observation: it identified 020→004→005/006/007/008 as a “main task → phase task → execution task” project tree, and judged the value as: FCoP emerged product-evolution tree and project-management capability from task-flow management.

The final reading should be consistent across the article, archive behavior, and future spec:

020 is not a standalone completed project. 004 is Phase 2 under 020.
Their child tasks do not overlap, but the business line is continuous; the thread_key is the same, and references / parent relationships are valid.
Therefore, 020 entering done/ does not mean the whole tree can be archived. As long as 004 or 007 is still open, CHILD_TASKS_OPEN is reasonable. It is not a console bug. It is the protocol protecting tree consistency.

The valuable discoveries are:

FCoP naturally grew Project / Phase / Execution layers. From demo to product, from version one to later versions, from main line to phase, from execution to QA, from failure to fix, and from a single task’s done state to whole-tree archive, everything happened inside the same collaboration thread.
parent, thread_key, and references already carry project-tree semantics, not just task-reference semantics.
The console still treats lifecycle mostly as single-task lifecycle, so done, report_missing, and child_open can appear together and confuse the user. The tree exists in files; the UI has not caught up.
The protocol should absorb this capability. When PM creates a Phase, PM must choose: continue the current main line or create an independent thread. The system should not wait for an archive failure and then rely on chat to draw the tree.

In one sentence: this was controlled emergence. Grid Runner grew from a normal task flow into a product-iteration tree. 020 is the project root, and 004 is Phase 2, not a separate project. Nobody added a new button for this. Existing protocol rules, real execution, and archive constraints stacked together. The shape became readable, auditable, and blockable. That is the life of a protocol.

Conclusion

I will remember this Grid Runner two-line run as a case of controlled emergence in FCoP.

The core was not that AI invented project management.

It was this combination:

parent
thread_key
references
PM Phase planning
CHILD_TASKS_OPEN

Together, these rules naturally formed a project tree.

So FCoP should not avoid this phenomenon. It should absorb it.

In one sentence: FCoP grew a project tree; now the protocol needs to write it down.

Evidence Behind This Observation

This section keeps only links and key excerpts. The full source files are not pasted here, to avoid turning the article into a log dump. Primary TASK / EVAL originals from the CodeFlowMu dogfood run are catalogued in the evidence archive; figures in this essay live under essays/assets/.

Evidence	Reference	Why it matters
Original task	`TASK-20260613-020`	The original Grid Runner v0.1 task. It later became the project root. Key field: `thread_key: panel-task-020`.
Phase 2 task	`TASK-20260614-004`	The later Grid Runner Phase 2 task. Key field: `references: TASK-20260613-020`, same thread.
EVAL source report	`GAP-20260614-004-panel-scan`	The internal EVAL scan triggered from the console. It detected `project_tree_emergence`.

The key fields can be compressed into four lines:

TASK-20260613-020: thread_key = panel-task-020
TASK-20260614-004: references = TASK-20260613-020
EVAL: project_tree_emergence
Archive guard: CHILD_TASKS_OPEN

What EVAL Observed

The internal EVAL scan identified the Grid Runner line as a project tree:

TASK-20260613-020  Grid Runner v0.1 / project root
└── TASK-20260614-004  Phase 2 product upgrade
    ├── TASK-20260614-005  DEV execution
    ├── TASK-20260614-006  OPS verification
    ├── TASK-20260614-007  QA playtest
    └── TASK-20260614-008  DEV fix

Its canonical reading was:

020 → 004 → 005 / 006 / 007 / 008

In other words: main task → phase task → execution task.

EVAL also detected smaller local fix chains, such as:

004 → 007 → 008
004 → 008 → 009

Those local observations are useful, but they do not replace the main-line interpretation: 020 is the project root of the Grid Runner product line, and 004 is Phase 2 under 020.

Terminology

The table below explains the FCoP terms used in this article without requiring readers to know Chinese.

Term	Meaning in this article	Protocol marker
Collaboration thread	A continuous line of work that keeps related tasks together. In this case, Grid Runner stayed under the same thread.	`thread_key`, here `panel-task-020`
Continues from	A task explicitly builds on an earlier task or delivery. Phase 2 continued from the v0.1 task.	`references`
Parent task	A task that owns or contains lower-level tasks. A parent should not be archived while its children are still open.	`parent`
Open child tasks	Lower-level tasks are still not fully closed. This is why the archive attempt was blocked.	`CHILD_TASKS_OPEN`
Internal EVAL scan	A CodeFlowMu internal scan that reads TASK / REPORT files and detects possible workflow structures. It is supporting evidence, not the formal ledger.	`GAP-*-panel-scan.md`
Project-tree emergence	The observed pattern where FCoP task flow began to express a product structure: project root → phase → execution → fix.	`project_tree_emergence`

DEV Community: joinwell52

Three Agents Returned Three Reports. Which Task Did They Actually Prove?

The attribution chain

Do not let the model author the envelope

Evidence must come from the execution boundary

Use logical order, not filesystem time

Multiple reports need an explicit state machine

A practical attribution veto list

What 44 tests establish

Why Is the Agent Still Editing the Old Project?

Seven consumers can hold seven different roots

A four-phase safe switch

1. Stop admitting new work

2. Quiesce old side effects

3. Persist one canonical new root

4. Rebuild and prove the binding

Fail visibly on four classes of error

What 27 tests do—and do not—prove

The practical rule

An AI Agent’s Skill Is Not Its Permission

Four gates, four different questions

Why prompts cannot be the security boundary

Bind approval to state, not only parameters

Static parsing still needs a sandbox

What the implementation tests establish

An audit checklist you can use

Don’t Trust an All-Green Demo: How Fault Injection Exposes an Unreliable AI Agent Dispatcher

In ten seconds

Start from protocol invariants without repeating the protocol tutorial

Six defensive rules worth encoding first

Why file coordination still needs governance semantics

Storage faults: atomic rename is a commit point, not a universal guarantee

Event faults: a watcher notification is not a business fact

Dispatch faults: test attempt and lease commit boundaries

PASS, FAIL, and NOT RUN are different facts

A minimum 12-case fault-injection set

Primary sources

How Do You Stay in Control of an AI Team After Leaving Your Computer? A Two-Plane Design for Local Execution and Mobile Control

In ten seconds

A PWA is not a second Runtime

What the phone minimally needs to show

Binding is a device lifecycle, not a permanent QR code

A mobile approval is not a status edit

LAN and Gateway are reachability paths, not fact sources

Weak networks and caches: stale views may be readable; stale decisions must not execute

A 15-point acceptance checklist

How TMPA, FCoP, CodeFlowMu, and Mobile divide responsibility

Primary sources

Why Multi-Agent Governance Can Start with Files

Why Multi-Agent Governance Can Start with Files

The useful Unix lesson is a common interface

A directory becomes a work ledger only with contracts

Separate four kinds of work facts

Five lifecycle buckets: use location to answer “where is the task now?”

Inspectability improves rework

When files are a sensible starting point

A minimum ledger you can inspect today

What “everything is a file” contributes to engineering

Completion Claim Accepted State: A Verification Contract for Agents

Completion Claim ≠ Accepted State: A Verification Contract for Agents

Three checks that should not be collapsed

1. Deterministic checks

2. Learned verification

3. Human or policy acceptance

A minimal runtime state model

Trace Is Not Governance: From Work Facts to SaaW

Trace Is Not Governance: From Work Facts to SaaW

An engineering lineage through TMPA, FCoP, CodeFlowMu, and Self-Morphing

1. Why an execution trace is not enough

2. TMPA: Making work facts reconstructable

3. FCoP: Bringing governance semantics into project collaboration

4. CodeFlowMu: Bringing roles, tools, and governance into real execution

5. The Meta-Development Runtime: Development capability becomes production capability

6. Self-Morphing: “Developing itself” under governance

7. Humans do not disappear; they leave the operation layer

8. SaaW: When software begins to carry work

Conclusion

Durable Agent Runtime Is Becoming the Baseline

Durable Agent Runtime Is Becoming the Baseline

Summary

A mobile approval is not a `status` edit