Flowline
Try the demo →
Reference

Release notes — team collaboration

For teammates

What changed

  • A project is stored as one file per card, scenario, suite, note and test record, so two people editing different things never touch the same file (Reference).
  • Flowline knows who you are. Flows, suites and scenarios can have an owner, and in a Drive or git workspace each card, scenario, suite and flow shows who changed it last (Working as a team).
  • Several testers run one suite cycle at once. A scenario has an assignee, and Take next tells the second tester that someone already took the scenario (Working as a team).
  • When teammates have a project open on the same Flowline server, their initials show in the editor header. A teammate's save reaches your open project as soon as their editor announces it (Working as a team).
  • A change to the same card by two people merges field by field. Where you both changed one field the later save wins, and the header names the field and the teammate (Working as a team).
  • Teammates on the same server see your edits before they are saved. Undo takes back only your own changes (Working as a team).
  • The live dot after the avatars shows the live channel. Its hover text says why it is off, for example when the server refuses the connection or you are signed out (Working as a team).
  • A closed tab leaves the avatars in about 2 seconds, a dropped connection within about 15 seconds, and a joining tab sees everyone in about 1 second. A tab that stays open saves a departed teammate's unsaved edits in about 4 seconds after a closed tab, and in up to about 15 seconds after a crash. These are numbers from a test harness; the checks in real browsers are listed in docs/browser-checklist.md.
  • The first save of an old project converts it and keeps the old files: in Drive's trash for 30 days, in .backup/schema-6 in a server or computer folder, in the history of a git folder. The save line names the place, except in git (Working as a team).
  • Deleting a card leaves the card before it with an unconnected branch until the card comes back. A restore brings the connection back everywhere.
  • The projects screen shows History only in a git workspace, the one kind with an Activity log (Working as a team).
  • When a branch switch fails after the old branch's save timed out, the editor no longer stays on "saving" and takes teammates' changes again (Working as a team).
  • Import on the projects screen refuses a .flowproj.zip that lacks a flow file its project.json lists, and names the missing files.
  • An error page from a proxy no longer reaches the editor as raw markup: the error shows the server's message or the HTTP status, and a 412 still offers Refresh (API-01).
  • The MCP list tools name people: list_bugs the reporter, list_runs the tester, list_suites and list_scenarios the owner, list_suite_runs who started and finished (MCP setup, API-02).

What to expect in a mixed team

The programme shipped in phases, and an older app is named by its phase: Phase 2 (people and owners), Phase 3 (parallel suite runs, no live channel), Phase 4/5 (avatars and save notices), Phase 6.0 (the first live-editing build). "Updated" is this release. src/state/simMatrix.test.ts runs frozen Phase 4/5 and Phase 6.0 apps beside updated ones in one room, and docs/superpowers/specs/2026-09-28-team-collaboration-design.md (section 4.3.1) states the rules.

  • Phase 3, 4/5 and 6.0 apps keep working beside an updated app. In the matrix test the 4/5 and 6.0 apps end on the same files as the updated apps, with no edit lost.
  • A Phase 3 app keeps the project's live key and shows no avatars. It sends no notices, so its saves reach updated teammates with the 15-second check.
  • A Phase 4/5 app shows updated teammates' avatars and gets their save notices. It reads no live edits, so a teammate's edit reaches it when it is saved. It sends none either: its edits reach teammates only through its own saves, and nobody saves for it after it closes.
  • A Phase 6.0 app sees live edits. Each kind of message it does not know costs it a gap, and an edit over 60 KB (OPS_FRAME_BYTES) travels in pieces of such a kind. A gap drops the app's waiting edits, which its next save carries, and costs one whole-project check. It loses nothing.
  • An older app never answers the check that removes departed teammates, so it stays visible for up to 30 seconds after it leaves (Working as a team).
  • When an older app edits a card whose connection to a deleted card is hidden, it writes the card without that connection. Restoring the deleted card later brings back every connection but that one.
  • A file a Phase 6.0 app creates on Drive has no reserved id. An updated app that saves it for a departed author creates it with no id too, so a twin file can appear, as it could before.
  • A Phase 2 app cannot open the runner of a cycle that has an assignee. Update every tester's app before you run suites together.
  • An app from before the file layout cannot save through the server, and on a shared Drive or git folder it writes the old layout back. See "Who updates first" below.

Known limitations

Each line says what you can see and what to do. The id points to docs/superpowers/plans/team-collab-cleanup-backlog.md.

  • If a roll call finds more silent peers than sockets that closed, a teammate who really left has their unsaved edits saved by the next 15-second check, not at once (HAND-2).
  • If you close a tab that holds a departed teammate's unsaved edit while a save notice has claimed more than its save held, the tab closes without a warning and the edit is lost. Read from code, not measured (HAND-3).
  • While a teammate types into a file this tab saves for them, an extra write or a version conflict can show. No edit is lost (HAND-7).
  • A departed teammate's edit waits for the 15-second check when the handoff's save writes nothing (HAND-10).
  • A latent defect in LiveSequence.took can lose a newer edit if it fires. No simulated run fires it now (HAND-1).
  • While one new file waits for its Drive id, this tab sends no live edits. If the id keeps failing, live co-editing stops for the tab with no message, and edits still travel with saves (REV4-9).
  • If Drive rejects one create id, every save of the project fails until you reload the tab (REV4-5).
  • On Drive, two writers in one upload window can leave twin files for a file that the upgrade, or an edit that wins over a teammate's delete, creates (REV4-3).
  • After a stale Drive listing, a flow's children can read as deleted by a teammate although they exist, or a twin file can appear (REV4-4).
  • On Drive, two saves of one file close together can leave the older value, and nobody is told. After a teammate saves the same card, check that your change is still there and make it again if not (backlog "Drive race", .planning/WINDOWS.md entry 6).
  • A flow a teammate edited live and then deleted can read "your unsaved changes to it were dropped" with nothing of your own lost (ROOM-03).
  • In a git workspace, a save after a checkout made elsewhere gets 412. The editor then offers only Updated — Refresh, not Overwrite with mine: your edits belong to the old branch. Refresh drops them, so copy them first (REV4-6).
  • A git pull or resolve waits for the workspace lock and has no git timeout. A stalled remote holds every save, delete and branch switch of that workspace until git gives up (REV4-7).
  • On Drive the upgrade moves project.json and each flow.json to the trash, and the trash is not an archive. Deleting a migrated flow or project later deletes the folder, and Drive removes what is inside; this is not yet checked on live Drive.
  • A project that a build before this release already upgraded on Drive has no trash copy.
  • An account that does not own the Drive files may be unable to upgrade a project. If so, its saves show an error until the owner opens the project. This is unconfirmed.
  • In a browser workspace the notice names .backup/schema-6 in browser storage, which you cannot open.
  • The presence and handoff timings come from a test harness. The checks in real browsers, and with two Drive accounts, are listed in docs/browser-checklist.md.
  • No visible effect: HAND-4, HAND-5, HAND-6, HAND-8, HAND-9, REV4-1, REV4-8, REV4-11 and three entries without an id: sendBudget, overlaps, grouped graph.edges. Each has a verdict in docs/superpowers/plans/team-collab-cleanup-backlog.md.

Not in this release

  • Teammates' pointers and selection outlines are not shown; presence is the avatars (CURS-01 to CURS-04, backlog Phase 999.3).
  • No message says that storage lacks a teammate's changes (ROOM-04, backlog Phase 999.3).
  • Edits made while the live channel connects, or while it is down, reach teammates only with a save (ROOM-05, backlog Phase 999.3).
  • Storage checks and large projects cost what they cost before: the 15-second check, no event-driven checks, no measured delivery time for live edits (LAT-02 to LAT-05, PERF-02 to PERF-05, PERF-07, backlog Phase 999.3).
  • The MCP check of the server's apiVersion (API-03), the GET /:id response of API-04 and the 400 → InvalidIdError mapping of API-01, backlog Phase 999.3.

For operators

Who updates first

  • The server serves the web app (Hosting it yourself). Update the server and every browser gets the new app on its next reload.
  • A tab still running the old app cannot save. The server answers 410 to a whole-project POST or PUT on /api/projects with This Flowline client is out of date — reload the page, or update flowline-mcp.
  • The web app refuses a flowline-mcp helper whose /api/health reports an apiVersion below 3 (API_VERSION), with Your flowline-mcp helper is out of date. Update the helper beside the server.
  • Every teammate updates before anyone edits a shared Drive or git folder. An older app writes the old single-file layout back, the newer editor shows Updated — Refresh, and after Refresh the older app's edit is lost (Working as a team).
  • On Drive, the owner of the folder opens each old-layout project first, since an account that does not own the files may be unable to upgrade it (see the limits above).
  • An agent's write over MCP upgrades an old-layout project the same way, and shows no notice.
  • MCP needs a restart after the relay is switched on (Hosting it yourself).
  • The 15-second storage check (CHANGE_POLL_MS) runs with the live channel on or off. The 5-second suite-run check (RUN_POLL_MS) runs only while the live channel is down. A leave waits at most 10 seconds for its save (LEAVE_SAVE_MS). Storage delays are unchanged in this release.

Pass the /api/live upgrade

The live channel is a WebSocket at /api/live, so a proxy must pass the upgrade (Hosting it yourself). If it does not, browsers keep retrying with up to 30 seconds between tries: the live dot stays amber, no avatars show, and teammates' saves arrive with the 15-second check.

Set APP_BASE_URL

Behind ngrok or a TLS proxy, APP_BASE_URL must be the public URL, or the server answers 403 to the upgrade (Hosting it yourself). Users then see what they see with no upgrade passed.