@Arjen Stet I ran Cassini on my own comp #9 - the brief editor. It walk all of the six phases, gates and all. It left a great map and it found a couple of things my own repo missed. Great Job!

@Marcelo Michelsohn whoop whoop !!

Tks @Leonard Dauksza great video, summarize perfectly my state of mind !

Busy building a Travel company ! I can finally build what I have had as an idea for 15 years !! Whoop whoop !

Finally !!

@Jake Van Clief , late to this, but I want to push on section 5.2, the "where this does not work" list. After running something super similar to ICM for a while now, I don't think the three limitations (real-time multi-agent collaboration, high-concurrency pipelines, AI-driven mid-pipeline branching) are limits of the methodology. They're limits of the unversioned filesystem. You already mention git, but use it as the coordination substrate itself rather than as a backup layer, and all three go away. What I run is basically ICM-of-ICMs: a "company as vaults" federation. Each department is its own self-contained ICM workspace with its own map file, its own router, its own reference-vs-working split, its own queue. Above them sits a control-plane workspace that only routes and aggregates, never does department work. The part that matters here is how the workspaces coordinate: all messag are passing over git. A cross-workspace delivery is a file written into the receiving workspace's inbox folder via worktree → PR → merge, and it counts as delivered only once it's merged on the receiver's main. The merge is the delivery receipt. Against the three limitations: 1. Multi-agent collaboration. The paper says file-based handoffs are too slow for agents responding to each other. That's true if we look at a chat speed and is irrelevant at company speed. Commits are the messages, watchers tick on a cron every few minutes and drain the inboxes, and agents in different workspaces work together (request, deliver, ack), at the same speed as a company - might be too slow for some but it works. 2. High concurrency. The paper says scaling would require "queueing, state isolation, deployment infrastructure." Git solve already that: a worktree per writer is state isolation, push/pull with rebase reconciliation is the queue, branch protection is the permission layer. 3. AI-driven branching. Our rule is that the AI may branch, but only by writing an artifact a human could have written. A router agent triages the inbox and writes a task file with a lane tag into the queue folder; it never invokes the next agent directly. So the branching decision becomes a plain file that anyone can inspect, edit, or revert before anything picks it up. Keeps the segregation of duty that you worried about.