#Ownership with mfeflow.app.json

This page explains the small file that every app has and what mfeflow does with it. The file answers a question that gets harder as teams multiply: who owns this?

#Why does ownership need a file?

When a remote breaks in production, someone must be paged. With ten remotes, nobody remembers who owns the cart. A name in a wiki goes stale.

mfeflow.app.json sits in the app's folder and is reviewed with its code. It also holds the claims other tools can check, such as which URL paths the remote handles.

#What is in it?

The generated file has five fields:

{
  "name": "cart",
  "owner": "team-cart",
  "shells": ["shell"],
  "routes": ["/cart"],
  "exposes": ["./App"]
}

Optional fields add a contact, the events the remote publishes and consumes, analytics event names, a budgets section and platform ranges. See the field reference.

#What does mfeflow check?

mfeflow validate and doctor read every mfeflow.app.json and fail on these problems:

• A file that is missing, invalid, or whose name does not match mfeflow.json (E113, E116)
• Two remotes that claim overlapping routes (E116)
• A registry entry missing for an environment (E114)

Overlap is checked by pattern, not by text. Comparison ignores case and a trailing slash. These pairs overlap:

/checkout/*   and  /checkout/pay
/shop/:id     and  /shop/new

#How does it help in an incident?

The owner also appears in the registry entry and in the registry index. A tool or a person reading the index knows who owns each remote without opening the repository. Future tools can route alerts using it.

#An example of a caught mistake

Suppose the cart team adds a route that the checkout team already claims:

{
  "name": "cart",
  "owner": "team-cart",
  "shells": ["shell"],
  "routes": ["/cart", "/checkout/*"],
  "exposes": ["./App"]
}

Run the check:

pnpm mfeflow validate

You should see an E116 error that names both remotes and both routes. The fix is to give each remote its own path before merging.

#What ownership does not give you

mfeflow.app.json does not enforce who may edit a folder. Use your repository's code owners for that. It also does not stop a remote from importing another remote's code. Keep remotes independent and talk through events, as described in the event-bus feature.

#Related

• Where the file lives: Project structure.
• Run the check in CI: CI and budgets.