Entscheidungen

Die offenen Punkte aus den beiden Proposals, die ein Agent nicht selbst entscheiden darf, weil sie Specs berühren und für alle ZVV-Apps gelten. Eine Frage pro Block, daneben Herkunft, Empfehlung und Folge. Antworten bleiben im Browser; unten entsteht daraus ein Markdown-Block zum Kopieren.

Die 19 Fragen sind nicht auf dieser Seite entstanden. Jede stammt aus einem der beiden Papiere und nennt ihre Fundstelle — docs/proposals/ungedeckte-luecken.md und docs/proposals/meta-views.md. Wo ein Papier eine Empfehlung ausspricht, steht sie als Vorauswahl da und ist als Empfehlung markiert: Der Leser soll bestätigen oder abweichen, nicht bei null anfangen. Wo ein Papier ausdrücklich keine Empfehlung gibt, steht auch keine Vorauswahl — diese Fragen tragen die Marke «ohne Empfehlung».

Eine Vorauswahl zählt nicht als Antwort. Der Fortschritt oben zählt nur, was jemand angefasst hat; wer dem Papier folgt, bestätigt alle Empfehlungen mit einem Klick. Die Fragen selbst stehen in example/lib/atlas/entscheidungen.ts — dieselbe Quelle wie die Belege auf /techstack, damit keine zweite Wahrheit entsteht.

0 von 19 beantwortet

Wer entscheidet, und wann

Beides steht bei jeder Entscheidung im erzeugten Block. Ohne Namen fehlt später der Verantwortliche — genau der Fehler, den L03 anprangert.

Wer (Name oder Kürzel)

Wann

Aus «Die neun ungedeckten Lücken entscheiden»

docs/proposals/ungedeckte-luecken.md · Entscheidungsvorlage · 5. August 2026 · entschieden am 6. August 2026 · 16 Fragen

01L02 · Playwright / E2E

Bleibt Playwright ein verbindlicher Atlas-Default für E2E-Tests — oder wird der Default aus Kapitel 07 gestrichen, bis die erste ZVV-App mit echtem Anmeldeweg E2E baut?

A Einführen: Konfiguration, Browser-Toolchain in der CI, Auth-Mock und mindestens ein tragender Test im Referenz-Repo

B Streichen: Kapitel 07 führt E2E nicht mehr als Atlas-Default; die Ablage tests/e2e/<feature>.spec.ts gilt nur noch für Apps, die E2E freiwillig bauen Empfehlung des Papiers

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

02L03 · Migration-Guides für v0.2

Was geschieht mit der Zusage «v0.2 liefert Migration-Guides», die mit dem Bump auf 0.2.0 fällig geworden ist?

A Guides jetzt schreiben

B Zusage auf v0.3 verschieben

C Zusage streichen und durch den einen benannten Bedarf ersetzen (Tailwind 3.4 → 4, drei Apps); der Guide entsteht aus dem ersten realen Migrations-PR Empfehlung des Papiers

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

03L04 · Baseline-CSP

Liefert Atlas eine kopierbare Baseline-Sicherheitsrichtlinie fürs Web (CSP mit Skript-, Stil- und Verbindungsquellen) — oder sagt Kapitel 10 ausdrücklich, dass jede App ihre Richtlinie selbst schreibt?

A Baseline schreiben und im Referenz-Repo umsetzen — zuerst nur meldend (Report-Only), erst nach einem vollen Release-Zyklus ohne Verstösse durchsetzend Empfehlung des Papiers

B Ausdrücklich keine Baseline: Kapitel 10 sagt, dass jede App ihre Richtlinie selbst schreibt

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Herkunft

docs/proposals/ungedeckte-luecken.md § 5 «L04 · Baseline-CSP»

Empfehlung

A — Baseline schreiben, im Referenz-Repo umsetzen, zuerst als Report-Only (§ 5)

Folge

Der Hebel ist der grösste der neun Lücken: CSP ist der einzige Befund, bei dem die Lücke direkt Sicherheitsqualität kostet statt Zeit, und docs/10 ist Spec-Kapitel — was dort fehlt, fehlt verbindlich in acht Apps. Die Maschinerie steht bereits (example/next.config.ts:6-18 SECURITY_HEADERS, :29-36 pfadgenaue Ausnahme). Der übertragbare Teil für die App-Repos ist die Zweistufigkeit (erst melden, dann durchsetzen), nicht die Direktiven selbst. Risiko bei A: Eine falsche Richtlinie bricht die Seite in Produktion, oft still — genau deshalb die Reihenfolge. Bei B erraten acht Apps weiterhin einzeln einen Sicherheits-Header.

Befund L04 aus dem Tech-Stack-Vertrag

Die Baseline steht (entschieden MRA, 6. August 2026): docs/10 §7.1 führt die kopierbare Richtlinie — Nonces aus der Proxy-Middleware, strict-dynamic, die style-src-Ausnahme benannt — und example/proxy.ts setzt sie als Referenz um. Halb offen bleibt die Lücke bewusst: Der Header läuft in Stufe 1 als Content-Security-Policy-Report-Only. Durchsetzend wird er erst nach einem vollen Release-Zyklus ohne Verstösse; bis dahin ist Report-Only der korrekte Zustand, kein Versäumnis.

Beleg: docs/10-security.md:265·example/proxy.ts:46·example/next.config.ts:29-31

04L04 · Nonce oder strict-dynamicohne Empfehlung

Verlangt die Baseline-Richtlinie pro Aufruf erzeugte Einmalwerte aus der Middleware (Nonces) — oder den einfacheren Weg über 'strict-dynamic' mit Hash?

nonce Nonces aus der Middleware — strikt, aufwendiger

strict-dynamic 'strict-dynamic' mit Hash — einfacher, schwächer

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Herkunft

docs/proposals/ungedeckte-luecken.md § 5 (letzter Absatz) und § 12 «Was dieses Papier nicht entscheidet»

Empfehlung

Keine. Das Papier nimmt diese eine Sache ausdrücklich nicht vorweg: «Das ist eine Sicherheitsentscheidung, keine Redaktionsentscheidung.»

Folge

Nonces zwingen jede App zu einer Middleware, die pro Anfrage einen Wert erzeugt und bis in die Seite durchreicht — nötig, weil Next im App Router eigene Inline-Skripte einfügt. 'strict-dynamic' kommt ohne diese Mechanik aus, lässt nachgeladene Skripte aber weiter zu. Was hier entschieden wird, kopieren acht Apps.

Befund L04 aus dem Tech-Stack-Vertrag

Beleg: docs/10-security.md:265·example/proxy.ts:46·example/next.config.ts:29-31

05L05 · Rollen-Modell

Werden Rollen-Namen ZVV-weit kanonisiert — oder bleiben sie app-spezifisch, und die normative RLS-Vorlage in Kapitel 10 wird von den FZDB-Namen befreit?

A ZVV-weite Rollenliste erstellen

B App-spezifisch bestätigen: docs/10:111 bleibt, die Namen zvv_finance/zvv_admin verschwinden aus dem normativen Pattern (:203, :214) und werden zu Platzhaltern, die Beispiele in § 4.1 werden als FZDB markiert Empfehlung des Papiers

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Herkunft

docs/proposals/ungedeckte-luecken.md § 6 «L05 · Kanonische Rollen-Namen»

Empfehlung

B — app-spezifisch bestätigen und die Vorlage säubern (§ 6)

Folge

Dies ist der einzige der neun Befunde ohne maschinellen Wächter — die Entscheidung muss so fallen, dass die verbleibende Aussage auch in einem Jahr noch stimmt, ohne dass jemand erinnert wird. Bei B ist der Edit von der Atlas-Wartung allein ausführbar; L05 bleibt in reduzierter Fassung in LUECKEN stehen («eine ZVV-weite Liste gibt es nicht») und wird ausdrücklich als per Sichtprüfung gepflegt markiert. Einziger automatischer Schutz: die bestehende Ankerprüfung auf docs/10-security.md:203 wird rot, wenn der Beleg nicht mit umgehängt wird. Bei A bleibt der Widerspruch bis zum Ende einer Abstimmung über mehrere App-Teams bestehen — realistisch Monate; für Apps mit fremder Fachdomäne wäre eine gemeinsame Liste zudem schlicht falsch.

Befund L05 aus dem Tech-Stack-Vertrag

Eine ZVV-weite Rollenliste gibt es nicht, und das ist entschieden so (MRA, 6. August 2026): Rollen bleiben pro App definiert, das normative RLS-Pattern in 10 §5 führt Platzhalter statt der FZDB-Namen, die §4.1-Beispiele sind ausdrücklich als FZDB markiert, und die Namenskonvention steht in 10 §5.1 — das Präfix zvv_ ist Rollen mit ZVV-weiter Bedeutung vorbehalten. Dieser Eintrag bleibt bewusst stehen und wird per Sichtprüfung gepflegt: L05 ist die einzige Lücke ohne maschinellen Wächter; nur die Ankerprüfung der Belege warnt, wenn die Fundstellen wandern.

Beleg: docs/10-security.md:111·docs/10-security.md:203·docs/10-security.md:221

06L05 · Namenskonvention zvv_

Gilt künftig: Das Präfix zvv_ ist ausschliesslich Rollen mit ZVV-weiter Bedeutung vorbehalten, app-lokale Rollen tragen es nicht?

ja Ja — Konvention so festlegen Empfehlung des Papiers

nein Nein — keine Konvention festlegen

abweichend Abweichende Konvention festlegen (bitte im Feld unten benennen) — verlangt eine Angabe im Feld unten

Abweichende Konvention beziehungsweise Begründung

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Herkunft

docs/proposals/ungedeckte-luecken.md § 6, Absatz «Die Namenskonvention ist der Teil, der heute entschieden werden kann und muss»

Empfehlung

Ja — das Papier nennt sie den Teil, der heute allein und ohne Dritte entschieden werden kann und muss (§ 6).

Folge

Mit der Konvention entsteht eine spätere kanonische Rollenliste additiv statt als Umbenennungswelle über acht Apps. Ohne sie definiert die nächste App zvv_admin anders als die vorige — genau der Konflikt, den die Konvention verhindert. Dass die Wirkung real ist, zeigt example/lib/mock/personas.ts:12: dort stehen die drei FZDB-Namen bereits als einziges Rollen-Vorbild im Repo. Die Konvention gehört nach docs/10 und wird im reduzierten L05-Eintrag zitiert; abgesichert ist sie nur durch Sichtprüfung.

Befund L05 aus dem Tech-Stack-Vertrag

Beleg: docs/10-security.md:111·docs/10-security.md:203·docs/10-security.md:221

07L06 · Verbindlichkeit von Limit und TTL

Werden Anfragebegrenzung und Gültigkeitsdauer des Magic-Links in den Spec-Kapiteln beziffert — oder ausdrücklich zu Betriebsparametern ausserhalb von Atlas erklärt?

A Beide beziffern, aber als getrennte Lücken führen: L06a Rate-Limit (wartet auf Betriebsentscheid), L06b Gültigkeitsdauer (sofort erledigbar) Empfehlung des Papiers

B Beide als Betriebsparameter ausserhalb von Atlas erklären

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

08L06a · Grenze pro Empfängeradresseohne Empfehlung

Welche Obergrenze gilt für Magic-Link-Anfragen pro Empfängeradresse und Zeitfenster?

benennen Zahl und Zeitfenster jetzt benennen (im Feld unten) — verlangt eine Angabe im Feld unten

offen Noch offen — der Betriebsentscheid steht aus

Zahl und Zeitfenster beziehungsweise Begründung

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

09L06a · Grenze pro Quell-IPohne Empfehlung

Welche Obergrenze gilt für Magic-Link-Anfragen pro Quell-IP?

benennen Zahl und Zeitfenster jetzt benennen (im Feld unten) — verlangt eine Angabe im Feld unten

offen Noch offen — der Betriebsentscheid steht aus

Zahl und Zeitfenster beziehungsweise Begründung

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

10L06a · Antwort bei Überschreitungohne Empfehlung

Was antwortet der Anmeldeweg bei Überschreitung — und darf diese Antwort verraten, dass es die angefragte Adresse überhaupt gibt?

neutral Neutrale Antwort — dieselbe Rückmeldung, ob die Adresse existiert oder nicht

offenlegend Ausdrückliche Überschreitungs-Meldung, die die Existenz der Adresse offenlegt

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

11L06a · Durchsetzungsortohne Empfehlung

Wo wird die Begrenzung technisch durchgesetzt?

server-action In der Server-Action

middleware In der Middleware

supabase Supabase-seitig

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

12L07 · /signup

Zeigt der CTA «Konto beantragen» künftig auf ein Ziel, das existiert — oder wird zuerst die Route /signup vollständig spezifiziert?

A Route /signup spezifizieren (Formular, Datenmodell, Freigabeprozess, wer den Antrag sieht)

B CTA auf ein existierendes, erreichbares Ziel richten — ein Edit an vier Fundstellen; die Frage nach dem Antragsweg bleibt offen, aber unter eigenem Namen Empfehlung des Papiers

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

13L07 · Adresse des CTA-Zielsohne Empfehlung

Welche Adresse ist das erreichbare Ziel des CTA — welche Stelle legt heute tatsächlich Konten an?

benennen Ziel jetzt benennen (im Feld unten) — verlangt eine Angabe im Feld unten

zurueckstellen Zurückstellen, bis die Betriebsstelle geantwortet hat

Adresse beziehungsweise Begründung

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

14L08 · Referenz-Repo in der Drift-Tabelle

Bekommt die Drift-Tabelle in Kapitel 07 eine Zeile für das Referenz-Repo samt Legende — oder wird sie durch die maschinenlesbare Selbstauskunft /api/meta ersetzt?

A Zeile für das Referenz-Repo plus Legende ergänzen, die Zeile als generiert kennzeichnen und auf KURZANTWORT verweisen Empfehlung des Papiers

B Tabelle durch den Endpunkt /api/meta ersetzen: jede App liefert ihren Stand als JSON, die Übersicht wird eingesammelt statt abgeschrieben

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Herkunft

docs/proposals/ungedeckte-luecken.md § 9 «L08 · Das Referenz-Repo fehlt in der Drift-Tabelle» (Bezug auf meta-views.md § 4.2)

Empfehlung

A jetzt, B als deklariertes Ziel im selben Edit (§ 9)

Folge

Die eigene Zeile ist billig und heute schon berechnet — example/lib/atlas/techstack.ts:145-192 (KURZANTWORT) ermittelt den Ist-Stand aus example/package.json und deckt dieselben Achsen ab; die Tabelle wiederholt von Hand, was der Code kennt. Die Legende ist zwei Zeilen (16.2 = exakt diese Minor · 5.x = Major bindend, Minor egal · 5 = Major genügt) und macht die Tabelle erst lesbar. Reines B hängt an einer Entscheidung, die im anderen Papier liegt und mehrere App-Teams betrifft. Mitzuentscheiden: Der Befundtext wird auf das Prüfbare zurückgeschnitten — es gibt keine Zeile, gegen die man den Ist-Stand des Vorbilds vergleichen könnte (statt einer Behauptung über Leserverhalten).

15L09 · Monorepo und Workspaces

Ist packages/atlas ein echter Workspace mit eigener deklarierter Toolchain — und bleibt example/ ein zweiter, eigener Install-Root?

A packages/atlas bekommt devDependencies, die CI läuft über npm ci an der Wurzel und npm test -w packages/atlas; example/ bleibt zweiter Install-Root, wird aber in Kapitel 07 §5 begründet statt geduldet Empfehlung des Papiers

B example/ in die Workspaces holen

C Zustand lassen und nur dokumentieren

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Herkunft

docs/proposals/ungedeckte-luecken.md § 10 «L09 · Monorepo- und Workspace-Konventionen»

Empfehlung

A — Toolchain deklarieren; example/ bleibt zweiter Install-Root, wird aber dokumentiert (§ 10)

Folge

Der unpinnte Install in .github/workflows/atlas-ci.yml:43-50 ist die schärfste Einzelstelle der neun Befunde: Sechzehn Pakete ohne Versionsangabe bedeuten, dass zwei Prüfungen desselben Commits mit verschiedenen Werkzeugen laufen können — in einem Repo, dessen Zweck Belegbarkeit ist, der Defekt mit der grössten Fallhöhe. Bei A entfallen beide CI-Workarounds ersatzlos. B nimmt dem Showcase die Eigenschaft, als eigenständiges Projekt kopierbar zu sein — das ist sein Zweck. C lässt den Reproduzierbarkeits-Defekt ausgerechnet im standardsetzenden Repo bestehen. Beachten: Solange L09 offen ist, darf der Prettier-Gate aus L01 nicht über example/ hinaus auf packages/atlas ausgedehnt werden.

16Reihenfolge der Bearbeitung

Wird die Bearbeitungsreihenfolge aus Abschnitt 11 so übernommen — Anfrage an den Betrieb zuerst, danach Kapitel 07 in einem Zug, dann Login-Strecke, dann Security, zuletzt Infrastruktur?

uebernehmen Reihenfolge wie in § 11 übernehmen (Stufe 0 L06a · 1 L01, L02 · 2 L03, L08 · 3 L07, L06b, L06a · 4 L05, L04 · 5 L09) Empfehlung des Papiers

abweichend Abweichende Reihenfolge festlegen (Abweichung im Feld unten benennen) — verlangt eine Angabe im Feld unten

Abweichende Reihenfolge beziehungsweise Begründung

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Aus «Meta-Views für den ZVV-App-Stack»

docs/proposals/meta-views.md · Entwurf zur Diskussion · 3. August 2026 · 3 Fragen

17MV · Verbindlichkeit der drei Meta-Routen

Werden die drei Meta-Routen so verbindlich, wie das Papier sie vorschlägt — /info Pflicht für jede ZVV-App, /changelog Pflicht sobald versioniert ausgeliefert wird, /docs nur wo es Fachinhalt gibt?

pflicht Wie in § 4.1: /info Pflicht für jede App, /changelog Pflicht ab versionierter Auslieferung, /docs optional Empfehlung des Papiers

guideline Als Guideline führen — starke Empfehlung statt Pflicht

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

18MV · Versionierungs-Doktrin

Wird die Versionierungs-Doktrin «version + commit + build time + environment» als Spec in ein Atlas-Kapitel aufgenommen — oder als Guideline?

spec Als Spec — verbindlich für jede ZVV-App Empfehlung des Papiers

guideline Als Guideline — starke Empfehlung mit dokumentiertem Spielraum

Begründung oder abweichende Antwort

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

19MV · Kundenradar-Deck auf /infoohne Empfehlung

Zieht die Präsentationsseite des Kundenradars von /info auf /story um — oder ist genau dieses Deck die künftige Pflichtseite /info und bleibt, wo es ist?

umzug Umzug nach /story wie im offenen Punkt vorgeschlagen

kein-umzug Kein Umzug — das Kundenradar-Deck ist die Vorlage der Pflichtseite und bleibt unter /info

anderer Anderer Zielname (bitte im Feld unten benennen) — verlangt eine Angabe im Feld unten

Zielname beziehungsweise Begründung

Freiwillig. Ohne Begründung steht im Block ein Gedankenstrich.

Ergebnis als Markdown

Passt unverändert unter docs/proposals/ungedeckte-luecken.md oder in ein GitHub-Issue. Je Entscheidung: wer, wann, was — und die Begründung, dazu Herkunft und die Empfehlung des Papiers, damit später nachvollziehbar bleibt, wovon abgewichen wurde.

31 Zeilen bereit.

Entscheidungsblockmarkdown

## Entscheidungen ((Name fehlt), 19. August 2026)

<!-- Erzeugt auf /entscheidungen im Referenz-Repo.
     Quelle der Fragen: example/lib/atlas/entscheidungen.ts, das seinerseits auf
     docs/proposals/ungedeckte-luecken.md und docs/proposals/meta-views.md verweist.
     Nicht von Hand fortschreiben — Frage ändern heisst Modul ändern. -->

**Stand:** 0 von 19 offenen Fragen entschieden. Insgesamt 19 Fragen.

### Offen geblieben

- **L02 · Playwright / E2E** — Bleibt Playwright ein verbindlicher Atlas-Default für E2E-Tests — oder wird der Default aus Kapitel 07 gestrichen, bis die erste ZVV-App mit echtem Anmeldeweg E2E baut?
- **L03 · Migration-Guides für v0.2** — Was geschieht mit der Zusage «v0.2 liefert Migration-Guides», die mit dem Bump auf 0.2.0 fällig geworden ist?
- **L04 · Baseline-CSP** — Liefert Atlas eine kopierbare Baseline-Sicherheitsrichtlinie fürs Web (CSP mit Skript-, Stil- und Verbindungsquellen) — oder sagt Kapitel 10 ausdrücklich, dass jede App ihre Richtlinie selbst schreibt?
- **L04 · Nonce oder strict-dynamic** — Verlangt die Baseline-Richtlinie pro Aufruf erzeugte Einmalwerte aus der Middleware (Nonces) — oder den einfacheren Weg über 'strict-dynamic' mit Hash?
- **L05 · Rollen-Modell** — Werden Rollen-Namen ZVV-weit kanonisiert — oder bleiben sie app-spezifisch, und die normative RLS-Vorlage in Kapitel 10 wird von den FZDB-Namen befreit?
- **L05 · Namenskonvention zvv_** — Gilt künftig: Das Präfix zvv_ ist ausschliesslich Rollen mit ZVV-weiter Bedeutung vorbehalten, app-lokale Rollen tragen es nicht?
- **L06 · Verbindlichkeit von Limit und TTL** — Werden Anfragebegrenzung und Gültigkeitsdauer des Magic-Links in den Spec-Kapiteln beziffert — oder ausdrücklich zu Betriebsparametern ausserhalb von Atlas erklärt?
- **L06a · Grenze pro Empfängeradresse** — Welche Obergrenze gilt für Magic-Link-Anfragen pro Empfängeradresse und Zeitfenster?
- **L06a · Grenze pro Quell-IP** — Welche Obergrenze gilt für Magic-Link-Anfragen pro Quell-IP?
- **L06a · Antwort bei Überschreitung** — Was antwortet der Anmeldeweg bei Überschreitung — und darf diese Antwort verraten, dass es die angefragte Adresse überhaupt gibt?
- **L06a · Durchsetzungsort** — Wo wird die Begrenzung technisch durchgesetzt?
- **L07 · /signup** — Zeigt der CTA «Konto beantragen» künftig auf ein Ziel, das existiert — oder wird zuerst die Route /signup vollständig spezifiziert?
- **L07 · Adresse des CTA-Ziels** — Welche Adresse ist das erreichbare Ziel des CTA — welche Stelle legt heute tatsächlich Konten an?
- **L08 · Referenz-Repo in der Drift-Tabelle** — Bekommt die Drift-Tabelle in Kapitel 07 eine Zeile für das Referenz-Repo samt Legende — oder wird sie durch die maschinenlesbare Selbstauskunft /api/meta ersetzt?
- **L09 · Monorepo und Workspaces** — Ist packages/atlas ein echter Workspace mit eigener deklarierter Toolchain — und bleibt example/ ein zweiter, eigener Install-Root?
- **Reihenfolge der Bearbeitung** — Wird die Bearbeitungsreihenfolge aus Abschnitt 11 so übernommen — Anfrage an den Betrieb zuerst, danach Kapitel 07 in einem Zug, dann Login-Strecke, dann Security, zuletzt Infrastruktur?
- **MV · Verbindlichkeit der drei Meta-Routen** — Werden die drei Meta-Routen so verbindlich, wie das Papier sie vorschlägt — /info Pflicht für jede ZVV-App, /changelog Pflicht sobald versioniert ausgeliefert wird, /docs nur wo es Fachinhalt gibt?
- **MV · Versionierungs-Doktrin** — Wird die Versionierungs-Doktrin «version + commit + build time + environment» als Spec in ein Atlas-Kapitel aufgenommen — oder als Guideline?
- **MV · Kundenradar-Deck auf /info** — Zieht die Präsentationsseite des Kundenradars von /info auf /story um — oder ist genau dieses Deck die künftige Pflichtseite /info und bleibt, wo es ist?

Was hier bewusst nicht gefragt wird

Die Auslassung ist eine Aussage. Wer eine dieser Fragen vermisst, findet hier den Grund, statt eine Lücke in der Lücken-Seite zu vermuten.

L01 · Prettier: Im Papier mit «EMPFEHLUNG: A — einführen» entschieden (§ 2) und inzwischen umgesetzt: Prettier 3.9.6 ist gepinnt, das Format-Gate läuft in der CI über example/, und L01 ist aus den LUECKEN entfernt. Eine Frage danach wäre eine Scheinfrage.
Die vier Prettier-Ausführungsschritte aus § 2: Arbeit, keine Entscheidung — die Werte stehen vollständig in docs/07-tech-stack.md:141.
L06b · Magic-Link-Gültigkeitsdauer: Das Papier sagt es selbst: «Die TTL ist keine Entscheidung, sondern eine Recherche.» Der Wert ist ein Supabase-Projekt-Setting mit konkretem Default; Kapitel 06 trägt nur nach, welchen Wert ZVV fährt und wo er eingestellt ist.
Das Zieldatum für die kanonische ZVV-Rollenliste (L05 Option A): § 12 schliesst es ausdrücklich aus: Es hängt an einer Abstimmung über mehrere App-Teams und wäre heute nur eine weitere Datumszusage ohne Verantwortlichen — genau der Fehler aus L03. Die Grundsatzfrage steht als L05-modell in der Liste.
Ob die App-Repos /signup gebaut haben: § 12: aus diesem Repo nicht prüfbar. Recherche in acht Repos, keine Entscheidung.
Wächter-Anpassungen und das Nachziehen der Belegzeilen: Folgearbeit jeder einzelnen Entscheidung (§ 11, Schlussabsatz) und durch die CI erzwungen — nicht selbst entscheidbar.
Die drei Entscheidungen im Block «Entscheidungen (MRA, 3. August 2026)»: /info und /api/meta sind öffentlich, CHANGELOG.md ist die eine Changelog-Quelle, die Fachdoku-Route heisst /docs. Bereits entschieden und datiert.
Die Deck-Spec in meta-views.md § 4.1a und die Package-Exports in § 4.2: Umsetzungsumfang beziehungsweise im Papier bereits als bewährt oder ausdrücklich als optional markiert. appMeta() existiert im Referenz-Repo schon (example/lib/atlas/app-meta.ts).

Wie diese Seite zu lesen ist

Wer entscheidet, und wann

Aus «Die neun ungedeckten Lücken entscheiden»

Aus «Meta-Views für den ZVV-App-Stack»

Ergebnis als Markdown

Was hier bewusst nicht gefragt wird