FCoP Grew a Project Tree

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 ,