Architecture decision records

Each record captures one decision that shaped muster: the situation, the choice, the alternatives and the consequences. Records are numbered in the order they were made and are not rewritten when superseded; a later record says what replaced them.

Record	Decision
001	Packages communicate only through the internal/api service locator
002	Behaviour is specified by BDD scenarios against real muster instances
003	Definitions are YAML files locally and custom resources on Kubernetes, with one schema
004	muster logs a person in to remote MCP servers that run their own OAuth
005	muster protects its own endpoint as an OAuth 2.1 resource server in front of Dex
006	Tools of OAuth-protected servers are visible per session, after that session's login
007	The reconciler owns MCPServer status and the aggregator follows it
008	Authentication state is explicit: a server is authenticated, pending or not required
009	Single sign-on by forwarding the person's identity token to servers that trust the same issuer
010	The meta-tools live in the server; clients see only them
011	Downstream connections are pooled per session; authentication and capabilities are separate stores

Writing a record

A new record is the next number, named NNN-<slug>.md, with the sections Context, Decision, Alternatives considered and Consequences. It is proposed in the pull request that implements the decision and linked from this table.