Why Muster is read-only, and why that is the point

The first version of Muster could open pull requests. It could file issues, move cards, and nudge a branch that had gone quiet. It demoed beautifully. We removed all of it two weeks before launch, and the product has been better ever since.

Write access changes what a tool is for

The moment a tool can act on your repository, every conversation about it turns into a conversation about trust. Which scopes does it hold. What happens if it misfires at 2am. Who reviews what it opened. That is a reasonable set of questions, and answering them well is a whole product in itself. It is just not the product we wanted to build.

We wanted the thing you open on Monday to tell you where you actually stand. That job is finished the moment the page renders. Adding a button that changes something turns a five-second glance into a decision, and decisions are exactly what a status page should be making easier, not heavier.

What read-only bought us

Onboarding collapsed to one screen. Most providers offer a read-only scope, so connecting Muster is a smaller ask than connecting almost anything else in your stack. Security review, when it happens, is short, because the honest answer to what can this thing break is nothing.

It also made the scoring honest. A tool that can fix a stale branch has an incentive to find stale branches. A tool that can only report has an incentive to be right.

The line we will not cross

We will keep adding signals, integrations, and ways to slice them. We will not add a button that writes to your code. If a score tells you something needs attention, the next click should take you to the provider, in the place you already trust, with the context already loaded.