RFC: Amend ADR-0028 to record the multi-user direction

[znerol2]

RFC: Amend ADR-0028 to record the multi-user direction

Summary

ADR-0028 defers the multi-user model and assumes a single operator. That
assumption now conflicts with the v0.2 outcome. This RFC proposes a short
amendment that records the direction and changes no contract. The
multi-user design itself lands later, as its own ADR.

Why now

• On 2026-09-16 the operator ruled that the post-freeze goal includes
  robust user management through Authentik with high compatibility with
  external identity providers, that we do not need to unravel all of it
  now, and that "for now we only have the one engineer role user, but
  there will be more."
• On 2026-10-21, on dmf-cms: GET /api/operations/{id} returns full operation detail to any authenticated user — the scoped-disclosure guard is never applied #541, the operator ruled that a
  tenant is an intra-organisation scope that isolates special cases, for
  example a vendor in a live production with access to one device,
  network or service and nothing else, and that every operation needs a
  recorded scope at dispatch.
• The v0.2 milestone outcome is "a team shares one console", which a
  single-operator assumption cannot support.

Proposed amendment

Add this block to ADR-0028, after the binding contract (C1–C5) in the
Decision section:

Direction (amendment 2026-10-21). This block records where identity
goes next. It adds direction and changes none of C1–C5.

• The multi-user model is in scope for v0.2, whose outcome is "a team
  shares one console".
• Authentik stays the human identity authority (C1). Compatibility with
  external identity providers is a requirement of the multi-user model.
• A tenant is an intra-organisation scope that isolates a special
  case. For example, a vendor in a live production gets access to one
  device, network or service and nothing else. Every operation records
  its scope at dispatch.
• The single-operator assumption in Consequences expires with v0.2. The
  multi-user design lands as its own ADR.

Add this line to the Status section, below "Accepted":

Amended 2026-10-21: forward direction recorded; the multi-user design lands as its own ADR.

The attached diff applies both changes to the ADR as it reads after the
pending reshape PR.

What stays unchanged

• Contract statements C1 to C5, including C3.1.
• The sanctioned exception list (three entries).
• The Enforcement bullets.
• The Status value, which stays "Accepted".
• No identity inventory or role-minimisation pass is proposed.

What this does not decide

• The concrete role model.
• Group mapping between Authentik and the platform.
• External-IdP mechanics.
• The mechanism that records scope at dispatch.

How this gets decided

Discussion here decides the wording of the amendment. When the v0.2
identity design exists, a new ADR records the multi-user model, and
this amendment points to it.

Questions for discussion

1. Does the direction block belong in the Decision section, or is a
   Consequences note enough?
2. Is "expires with v0.2" the right trigger, or should it expire when
   the new ADR is Accepted?
3. Should the tenant definition live in the architecture doc as well,
   so the two do not drift?