Skip to content
reflow reflow docs

Application collections

An application collection groups the tests, repository association and plugin selection for one application in your current team. It can contain tests stored in Reflow and tests stored in Git.

Create collection

Section titled “Create collection”

After reflow login, run these commands from the application Git checkout:

Terminal window
reflow collections list --json
reflow collections create --repo . --json
reflow init --collection <returned-collection-id>
reflow target http://localhost:3000 --group my-app --collection <returned-collection-id>

The create command infers the display name from the checkout directory and the canonical GitHub owner/repo from its origin remote. Override with --name "My app" or --repository-id owner/repo. Credentials embedded in a remote URL are never saved. A checkout without a supported GitHub origin receives a local:<id> association. No checkout files, tests, Git commits or runs are created by this command.

The response includes collection_id, the current test_storage default and revision, and preference_changed: false. Creation accepts the existing team default. New teams default to keeping tests in Reflow. It does not require a separate confirmation in the browser or change the team’s preference. Changing that preference remains an owner/admin action in Team settings.

Creation requires a current team membership and author/run scope, like other application authoring. It does not grant execution approval to a closed-beta team. Duplicate names or GitHub repository associations are refused. List and select the existing collection.

List and select

Section titled “List and select”
Terminal window
reflow collections list --json
reflow collections select <collection-id>
reflow config get test-storage --json

Create and select remember the application in the private Reflow profile, scoped to the current API, team and user. Selection is validated against live team membership; it never silently switches teams. Pass --collection to override it. An existing execution target takes precedence over the remembered selection until you explicitly run reflow target --collection <id> again. Selection does not reset test data or execute anything.

MCP onboarding

Section titled “MCP onboarding”

Call get_reflow_context. When no collection is selected, next_action points at manage_collections:

  • action: "list" returns the current team’s collections.
  • action: "create", repository: "/absolute/path/to/app" infers local checkout metadata. Optional name and repository_id override it.
  • action: "select", collection_id: "..." validates and remembers the local selection. Pass repository to validate the checkout association too.

Use the returned ID for init_plugins and manage_execution. Application code and services remain on the author device. No browser extension is needed to create or select the collection.

Hosted HTTP MCP exposes the same tool but cannot inspect a local checkout. Supply name and optional repository_id: "owner/repo" for create. Hosted selection is request-scoped: pass collection_id on subsequent tools. Continue plugin installation and local execution on the author device.

Uncertain responses

Section titled “Uncertain responses”

Retain the returned new_collection_id and any operation/session IDs. Inspect get_reflow_context with that collection_id, or reflow collections list, before retrying. Local authoring retains its operation receipt; inspect it with reflow flows operation --operation-id <id> --operation-session <id>. Do not blindly repeat create after a timeout. A rejected duplicate is not permission to rename or rebind an existing application.

An older team whose storage associations are not activated receives an explicit administrator action instead of instructions to create more collections. Creation never bypasses that migration guard.