Create whitepaper.md

whitepaper.md

@@ -0,0 +1,799 @@
+# Bürgerabstimmung — Whitepaper
+
+**Digitale Bürgerbeteiligung mit dem Personalausweis. Themen einbringen, abstimmen, gemeinsam prüfen.**
+
+| | |
+|---|---|
+| Arbeitstitel / Marke | **Bürgerabstimmung** |
+| Domain (vorgeschlagen) | **buergerabstimmung.de** (Alternativen: buergerabstimmung.eu, abstimmungsportal.de) |
+| Status | Konzept & technischer Prototyp (Testbetrieb, keine offizielle Seite einer Behörde) |
+| Sprachen | Deutsch (Standard), Englisch |
+| Version | 1.0 · August 2026 |
+
+> **Wichtiger Hinweis:** Bürgerabstimmung ist ein privates Konzept- und Demonstrationsprojekt.
+> Es ist **keine offizielle Seite der Bundesregierung oder einer Behörde** und erhebt
+> nicht den Anspruch, staatliche Verfahren rechtlich zu ersetzen. Der Prototyp zeigt,
+> wie eine solche Plattform funktionieren könnte. Solange der Testbetrieb läuft, zeigt
+> die Seite dauerhaft ein entsprechendes Hinweisbanner an (im Code über die
+> Konfigurationsvariable `show_test_banner = true` gesteuert). Eine frische
+> Installation startet im **Testmodus**; er wird über die Oberfläche beendet und
+> löscht dabei alle bis dahin entstandenen Testdaten (Kapitel 5.3b).
+
+---
+
+## 1. Zusammenfassung
+
+Bürgerabstimmung ist eine Plattform für direkte, fortlaufende Bürgerbeteiligung. Jede Person
+mit deutschem Personalausweis kann:
+
+- **Themen einbringen** — maximal eines pro Tag, mit Ziel, Begründung, Kategorie und
+  räumlicher Ebene (Landkreis/kreisfreie Stadt, Bundesland, Deutschland; die
+  Gemeindeebene folgt in der Ausbaustufe),
+- **abstimmen** — dafür oder dagegen; wer sich enthält, stimmt schlicht nicht ab,
+- **rechtswidrige Inhalte melden** — geprüft nicht von einer Redaktion, sondern von
+  einer zufällig ausgelosten **Bürger-Jury** (1 % aller aktiven Ausweis-Pseudonyme),
+- **seine Gesamtansicht abrufen** — durch Auflegen des Ausweises (NFC) erscheinen alle
+  eigenen Themen, Stimmen und Favoriten.
+
+Die Identität wird ausschließlich über die **eID-Funktion des Personalausweises**
+nachgewiesen: Der Chip beweist kryptographisch die Echtheit der Karte (privater
+Schlüssel im Chip). Die Plattform kennt als Identität nur den **öffentlichen
+Schlüssel** — keinen Namen, keine Adresse, kein Geburtsdatum, kein abgeleitetes
+Pseudonym. Eine Karte = ein Konto. Das persönliche Profil wird an diesen
+öffentlichen Schlüssel **verschlüsselt** und vom Server **signiert**
+(manipulationssicher); die Stimmen werden **unverkettbar** gespeichert, sodass
+niemand rückschließen kann, wer wie gestimmt hat.
+
+Die Plattform ist bewusst **schlicht und amtlich-neutral** gestaltet, funktioniert
+gleichwertig auf Smartphone und PC, passt sich hellem und dunklem Systemdesign an und
+ist auch an öffentlichen Geräten (z. B. in Gemeindebüros oder Bibliotheken) nutzbar —
+für Menschen ohne eigenes Gerät.
+
+---
+
+## 2. Marke, Domain, Gestaltung
+
+### 2.1 Name
+
+**Bürgerabstimmung** — bewusst **kein Kunstwort und keine Marke**, sondern die
+schlichte Sachbezeichnung: Bürgerinnen und Bürger stimmen ab. So würde eine
+Verwaltung die Sache benennen, und genau das ist der Zweck des Namens — er
+verspricht nichts, was er nicht ist.
+
+Bewusst **nicht** gewählt wurden „Wahl…“ und „Bürgerentscheid“: Beides sind
+rechtlich belegte Begriffe für verbindliche Verfahren nach Wahl- und
+Gemeinderecht. Diese Plattform ist ein Meinungsbildungs-Kanal **ohne
+Rechtsverbindlichkeit**; ein Name aus dem Wahlrecht würde eine Wirkung
+suggerieren, die sie nicht hat.
+
+Zugleich ist der Name **nicht mit staatlichen Kennzeichen verwechselbar**: kein
+Bundesadler, keine Bundesfarben-Imitation, kein „bund.de“-Look. Vor einem echten
+Betrieb sind Marken- und Domainrecherche erforderlich — die reine
+Sachbezeichnung ist als Wortmarke voraussichtlich nicht schutzfähig, was für
+diesen Zweck kein Nachteil ist.
+
+### 2.2 Domain
+
+Vorschlag: **buergerabstimmung.de** (Sachbezeichnung, aussprechbar, .de passt
+zum Zweck). Ausweichoptionen: buergerabstimmung.eu, buerger-abstimmung.de,
+abstimmungsportal.de. Im Auslieferungszustand ist in der Konfiguration **keine
+Domain eingetragen** — sie wird erst beim Aufsetzen gesetzt.
+
+### 2.3 Gestaltungsprinzipien
+
+1. **Schlicht wie eine App:** ruhige graue Fläche, weiße Karten mit weichen
+   Ecken, Haarlinien statt Rahmen, Systemschrift, **ein** blauer Akzent —
+   die Formensprache verbreiteter Messenger-/Systemoberflächen (iOS, Signal).
+   Keine Verläufe, keine Deko-Effekte, keine „KI-Regenbogen“-Ästhetik; Rot
+   bleibt destruktiven Aktionen (Löschen) vorbehalten, Gelb allein dem
+   Testbetrieb-Banner.
+2. **Keine KI-Hinweistexte** auf der Seite. Die Seite spricht als Produkt, nüchtern
+   und in Sie-Form. Es steht nur Text da, der eine Entscheidung trägt:
+   Erklärsätze unter selbsterklärenden Überschriften, Wiederholungen von Zahlen
+   und Beschriftungen wie „Eingebracht am“ entfallen.
+3. **Hell/Dunkel automatisch:** Das Design folgt ausschließlich der
+   Systemeinstellung (`prefers-color-scheme`) — es wird bewusst nichts im
+   Browser gespeichert, auch keine Design-Präferenz.
+4. **Symbolhafter Einstieg:** Beim Sitzungsbeginn nur der Schriftzug und die
+   Sprachwahl — **Deutsch/English als Knöpfe mit Flagge**, ohne Bildmarke; die
+   Anmeldung führt ein Ausweis-Piktogramm mit NFC-Wellen an, Text bleibt
+   minimal. Die Kopfzeile der Seite trägt weder Wortmarke noch Anmeldestatus,
+   sondern nur die nötigen Bedienelemente; die Fußzeile nur Impressum und
+   Datenschutz. Das Impressum trägt im Prototyp bewusst nur einen Platzhalter
+   (ein `*` als Überschrift und als Text) — es ist vor einem echten Betrieb mit
+   den Pflichtangaben des Betreibers zu füllen, die Datenschutzerklärung ist an
+   den tatsächlichen Betrieb anzupassen.
+
+   **Bildmarke (Tab-/App-Icon):** ein **Häkchen im Feld** — scharfe Kanten,
+   keine abgerundeten Ecken, keine Farbe. Als SVG folgt es der
+   Systemeinstellung (schwarze Fläche mit weißem Kreuz im Hellmodus, weiße
+   Fläche mit schwarzem Kreuz im Dunkelmodus); PNG und ICO für Safari/iOS
+   liefern dieselbe Marke als geschlossene dunkle Kachel.
+5. **Responsiv:** eine Codebasis für Smartphone, Tablet, PC und Terminals. Die
+   **tragenden** Funktionen — anmelden, Thema einbringen, abstimmen, melden,
+   Jury — laufen ohne JavaScript; alle Fenster sind `:target`-Dialoge, alle
+   Eingaben normale Formulare. JavaScript ergänzt: Countdown, NFC-Auslösung,
+   die stufige Geltungsbereichs-Auswahl, die Live-Zahlen und den Hinweis auf
+   ähnliche Themen. **Eine Ausnahme:** die `profil.yaml` wird ausschließlich per
+   `fetch` geladen — ohne JavaScript gibt es keine Selbstauskunft. Das ist vor
+   einem Echtbetrieb zu ergänzen.
+6. **Testbetrieb-Banner:** Solange die Konfigurationsvariable
+   `show_test_banner` auf `true` steht (Auslieferungszustand), zeigt jede Seite oben
+   ein deutliches Banner: *„Testbetrieb — keine offizielle Seite der
+   Bundesregierung oder einer Behörde.“* Der **Testmodus** selbst ist keine
+   Variable, sondern ein Zustand der Installation (Kapitel 5.3b).
+7. **Barrierearmut:** semantisches HTML, Tastaturbedienung, ausreichende Kontraste.
+   Die Abstimmungsbalken nutzen **Akzentblau gegen Neutralgrau** — auf
+   Farbfehlsichtigkeit geprüft (CVD-Abstand ΔE 18,3 hell / 16,6 dunkel) — und
+   tragen immer Beschriftung samt Prozentwert; Bedeutung hängt nie an Farbe
+   allein. Vollständige BITV-Konformität ist Ziel der Ausbaustufe.
+
+---
+
+## 3. Leitidee und Einordnung
+
+Bürgerabstimmung versteht sich als **ständiger Meinungsbildungs-Kanal**: Statt alle vier
+Jahre ein Kreuz zu machen, können Bürgerinnen und Bürger laufend Anliegen einbringen
+und gewichten — von der Radweg-Frage in der Gemeinde bis zur bundespolitischen
+Grundsatzfrage. Die Ergebnisse sind ein präzises, manipulationsarmes Stimmungsbild,
+das Politik auf allen Ebenen nutzen kann.
+
+Bewusste Abgrenzung:
+
+- Bürgerabstimmung **ersetzt keine rechtlich bindenden Verfahren** (Wahlen, Volksentscheide).
+  Ergebnisse sind Meinungsbilder; eine rechtliche Bindung wäre ein politischer
+  Folgeschritt, kein technischer.
+- Die Plattform ist **strikt neutral**: Zum Start existieren ausschließlich
+  Kategorien über das gesamte politische Spektrum, keine vorbefüllten Themen
+  (siehe 6.3); die Moderation erfolgt durch geloste Jurys nach
+  strafrechtlichen — nicht politischen — Kriterien.
+
+---
+
+## 4. Zugänge und Zielgruppen
+
+- **Smartphone:** Ausweis per NFC ans Gerät halten, PIN in der eID-App eingeben,
+  fertig. Der Browser selbst berührt die Karte nie.
+- **PC:** eID-Client (z. B. AusweisApp) mit USB-Kartenleser oder gekoppeltem
+  Smartphone als Leser.
+- **Öffentliche Geräte:** Gemeinden, Bürgerbüros und Bibliotheken können Terminals
+  bereitstellen. Dafür ausgelegt: kurze Sitzungen, automatische Abmeldung nach
+  Inaktivität, keine lokalen Datenspuren, prominenter Abmelden-Knopf.
+- **Fremde Geräte:** Da die Anmeldung nur mit physischer Karte + PIN funktioniert und
+  keine Passwörter existieren, kann bedenkenlos das Gerät einer anderen Person
+  genutzt werden.
+
+Sprachen: **Deutsch und Englisch**. Die Wahl erfolgt beim Sitzungsbeginn,
+gilt für die Sitzung und wird **nirgends gespeichert** — weder im Browser noch
+am Konto. Ohne aufgelegten Ausweis ist die Seite nicht sichtbar (nur Anmeldung
+und Rechtliches sind offen).
+
+---
+
+## 5. Identität: die eID des Personalausweises
+
+### 5.1 Prinzip
+
+Jeder deutsche Personalausweis (seit 2010) enthält einen Chip mit
+Online-Ausweisfunktion (eID). Die Echtheit beweist der Chip kryptographisch: Er
+besitzt **private Schlüssel, die das Chipmaterial nie verlassen**, und die Gegenseite
+prüft die zugehörigen Zertifikate gegen die **staatliche Zertifikatskette** (Country
+Verifying CA / Document Verifier, BSI-Standards TR-03110, TR-03130). Kopierte oder
+gefälschte Karten fallen bei dieser Prüfung durch.
+
+Für Bürgerabstimmung entscheidend ist die Funktion **„dienstespezifisches Kennzeichen“
+(Restricted Identification)**: Der Chip errechnet pro Dienst ein stabiles Pseudonym.
+
+- Dasselbe Pseudonym bei jedem Anhalten derselben Karte bei Bürgerabstimmung → **ein
+  Konto pro Karte**, Wiedererkennung ohne Klarnamen.
+- Ein anderes Pseudonym bei jedem anderen Dienst → **keine Verkettbarkeit** über
+  Dienste hinweg.
+- Bürgerabstimmung fragt **keine** Klardaten ab (kein Name, keine Anschrift, kein
+  Geburtsdatum). Es wird auch **kein eigenes Pseudonym erzeugt oder
+  zugeordnet**: Identität ist unmittelbar der öffentliche Schlüssel („on
+  the go“); Stimmen werden auf dem Server direkt für diesen Schlüssel
+  eingetragen.
+
+### 5.2 Ablauf (Produktion)
+
+1. Nutzer wählt „Ausweis auflegen“. Die Plattform startet über den eID-Client
+   (AusweisApp, Schnittstelle nach TR-03124) eine Authentisierung beim zugelassenen
+   **eID-Server** (TR-03130).
+2. Nutzer hält die Karte an das NFC-Smartphone bzw. den Kartenleser und gibt die
+   sechsstellige **Ausweis-PIN** ein.
+3. Chip und eID-Server authentisieren sich gegenseitig (PACE, Terminal- und
+   Chip-Authentisierung); der eID-Server prüft Echtheit und Sperrliste und übermittelt
+   Bürgerabstimmung **nur das Pseudonym**.
+4. Bürgerabstimmung nimmt den geprüften öffentlichen Schlüssel unmittelbar als Kennung und meldet die Sitzung an.
+
+Voraussetzung für den Echtbetrieb ist ein **Berechtigungszertifikat** der
+Vergabestelle für Berechtigungszertifikate (Bundesverwaltungsamt) mit dem
+Berechtigungsumfang „pseudonymer Zugang“ sowie ein zertifizierter eID-Server
+(eigenbetrieben oder als Dienstleistung).
+
+### 5.3 Prototyp (dieses Repository)
+
+Der Prototyp bildet das Verfahren originalgetreu nach: Eine simulierte
+Testkarte im Browser übernimmt die Rolle des Chips und hält ein echtes
+Ed25519-Schlüsselpaar (libsodium). Beim „Ausweis auflegen“ signiert der
+private Schlüssel eine Zufallsnachricht; der Server prüft die Signatur
+gegen den öffentlichen Schlüssel und leitet daraus das Pseudonym ab.
+**Zwei getrennte Vorgänge:**
+
+1. **Profil laden (initiales Anhalten):** Die statische Challenge ist der
+   öffentliche Schlüssel selbst, zeitgebunden versiegelt. Der Server öffnet
+   den Nachweis mit dem öffentlichen Schlüssel und liefert die
+   **profil.yaml** (alle eigenen Stimmen, Themen, Favoriten, Jury-Status)
+   in den Browser; der Abmelde-Knopf löscht sie dort wieder. Der Nachweis
+   ist **TOTP-artig zeitbegrenzt** (5-Minuten-Fenster, Anmeldung gilt
+   höchstens zwei Fenster) — danach ist erneutes Anhalten nötig.
+2. **Stimmabgabe und jede andere Änderung (unabhängig davon):** Die Karte
+   erstellt je Vorgang einen **versiegelten Umschlag** (kombinierte
+   Signatur über Aktion + Zeitfenster + Zufallswert); der Server
+   **öffnet ihn mit dem öffentlichen Schlüssel** und trägt die Stimme für
+   genau diesen Schlüssel ein. Derselbe Vorgang ergibt zu anderer Zeit
+   einen anderen Umschlag; alte Umschläge verfallen.
+
+Zusätzlich trägt jedes Formular ein **Einmal-Token** (beim Einlösen
+verbraucht — Wiederholungen laufen ins Leere), und im Browser liegt außer
+der Sitzungs-ID nur die bewusst geladene profil.yaml. Am Smartphone ist
+der NFC-Leser auf der Anmeldeseite automatisch scharf: Das Auflegen des
+(echten) Personalausweises löst die Anmeldung direkt aus (Web NFC; der
+Knopf bleibt Rückfall und Berechtigungsgeste).
+
+### 5.3b Testmodus als Zustand, nicht als Variable
+
+Eine frische Installation startet **im Testmodus**. Er ist kein Schalter in
+der Konfigurationsdatei, sondern ein Zustand in der Datenbank
+(`schema_info.test_mode`), damit eine Vorführung ohne Codeänderung möglich
+ist und der Übergang in den Echtbetrieb protokolliert wird.
+
+- **Im Testmodus** zeigt die Anmeldeseite **genau einen Knopf**. Er erzeugt
+  eine zufällige, als gültig behandelte Sitzung; Ausweis-Aufforderungen bei
+  Änderungen entfallen. Das Banner bleibt unabhängig davon sichtbar.
+- **Beendet wird er über die Oberfläche**: Der Chip „Testmodus“ in der
+  Kopfzeile führt auf die Seite **„Echtbetrieb einrichten“** (Kapitel 5.3c).
+  Dort wird der Zugang für den Echtbetrieb festgelegt, geprüft und
+  umgeschaltet. Das Umschalten **löscht alle im Testbetrieb entstandenen
+  Daten** — Themen, Stimmen, Merkzettel, Meldungen, Jury-Sitze, Konten und die
+  im Testmodus erzeugten Ausweis-Schlüssel. Kategorien, System-Konto und eine
+  echte Freigabeliste bleiben. Der Schritt ist bewusst nicht umkehrbar.
+- **Danach** existiert kein Weg mehr in die Anwendung, der ohne Ausweis
+  auskommt: Die Anmeldeseite bietet nur noch die Ausweis-Apps an, und die
+  Einrichtungsseite ist geschlossen.
+
+### 5.3c Einrichtung des Echtbetriebs aus der Anwendung heraus
+
+Der Übergang vom Testbetrieb zum Echtbetrieb ist kein Eingriff in den
+Quelltext, sondern ein geführter Schritt in der Oberfläche. Die Seite
+„Echtbetrieb einrichten“ leistet dreierlei:
+
+1. **Voraussetzungen prüfen.** Sie zeigt, ob das Datenverzeichnis beschreibbar
+   ist, HTTPS anliegt, die Kryptographie-Erweiterung vorhanden ist, der
+   Zugriffsschutz greift und wie viele Ausweis-Schlüssel freigegeben sind.
+2. **Zugang festlegen.** Zur Wahl stehen der **eigene eID-Server** (Anmeldung
+   über die Ausweis-App; setzt Berechtigungszertifikat und einen Server nach
+   TR-03130 voraus) und die **eigene Trust-Liste** (Anmeldung nur mit
+   Schlüsseln aus der Freigabeliste, befüllt über eine Abgleich-Adresse oder
+   `issue-card`). Erfasst werden SOAP-Adresse, Client-Zertifikat und
+   -Schlüssel, die Aktivierungsadresse der Ausweis-App, die Abgleich-Adresse
+   der Freigabeliste und die Startadresse von Nect. Ein Knopf **prüft die
+   Verbindung** zum eID-Server, bevor irgendetwas verändert wird.
+3. **Umschalten.** Erst wenn die Eingaben gültig sind, der eID-Server
+   antwortet und der **Einrichtungsschlüssel** stimmt, werden die Einstellungen
+   nach `data/config.yaml` (Rechte 0600, vom Web nicht erreichbar)
+   geschrieben, die Testdaten gelöscht und der Echtbetrieb dauerhaft
+   aktiviert.
+
+Der **Einrichtungsschlüssel** steht in `data/setup.token` und ist nur über
+Dateizugriff oder `php index.php setup-token` lesbar. Damit kann das
+Umschalten nur, wer den Server betreibt — nicht jeder, der sich im Testbetrieb
+per Knopfdruck eine Sitzung erzeugen kann. Nach dem Umschalten wird die Datei
+gelöscht.
+
+Die Einstellungen aus `config.yaml` überlagern beim Start die Vorgaben im
+Quelltext; übernommen wird ausschließlich eine feste Liste erlaubter
+Schlüssel. `php index.php config` zeigt den wirksamen Stand.
+
+Der Wechsel auf einen echten eID-Server ersetzt nur den Karten-Block; Regeln
+und Abläufe bleiben identisch.
+
+### 5.3d Anbindung der AusweisApp (TR-03124/TR-03130)
+
+Die Anmeldung mit der AusweisApp ist direkt eingebaut und braucht auf der
+Serverseite nichts als den Webserver und diese Datei:
+
+1. Der Knopf „Mit AusweisApp anmelden“ leitet den Browser auf die
+   **Aktivierungsadresse des eID-Clients** nach TR-03124:
+   `http://127.0.0.1:24727/eID-Client?tcTokenURL=…`. Die AusweisApp — am PC wie
+   am Smartphone — fängt diese Adresse ab.
+2. Die App holt das **tcToken** unter `/eid/tctoken` ab. Sie tut das als
+   eigener HTTP-Client **ohne Browser-Cookie**; deshalb trägt die tcTokenURL
+   einen **Einmal-Nonce** (10 Minuten gültig), der Browsersitzung und
+   Ausweis-Vorgang verbindet.
+3. Mit hinterlegtem **eID-Server** (TR-03130, `eid_server_url`) fordert der
+   Server dort per `useID` eine Sitzung an und liefert der App ServerAddress,
+   SessionIdentifier und RefreshAddress. Die App liest den Chip PIN-geschützt
+   aus und schickt den Browser zurück auf `/eid/callback`.
+4. **Ohne** eID-Server liefert das tcToken bewusst nur eine
+   `CommunicationErrorAddress`. Die AusweisApp bricht sauber ab, der Browser
+   kehrt zurück — **angemeldet wird niemand**. Das ist die ehrliche Grenze:
+   Einen eID-Server darf nur betreiben, wer ein **Berechtigungszertifikat des
+   BVA** besitzt (Kapitel 5.3e).
+
+### 5.3e Autorisierte Schlüssel (Freigabeliste) und ehrliche Grenzen der eID
+
+Anmelden kann sich ausschließlich, wessen **öffentlicher Schlüssel in einer
+serverseitigen Allowlist** steht (`data/authorized_keys.yaml`) und wer den
+passenden **privaten Schlüssel** besitzt (zeitgebundene Signatur-Challenge).
+Damit ist ausgeschlossen, dass ein Knopfdruck ohne Ausweis oder mit einem
+fremden/gefälschten Schlüssel Zugang gewährt (fail-closed).
+
+Ehrliche Einordnung zur oft gewünschten „Liste aller Ausweis-Schlüssel“:
+Eine solche staatliche Liste **existiert nicht** und wäre auch nicht
+wünschenswert (sie wäre ein Register der kryptographischen Identität aller
+Bürgerinnen und Bürger). Der Personalausweis weist sich stattdessen über die
+**BSI-Zertifikatskette** (TR-03110: Chip-Authentisierung gegen CVCA/DV) aus,
+geprüft durch einen zertifizierten **eID-Server** (TR-03130); das Auslesen des
+Chips erfolgt PIN-geschützt ausschließlich über die **AusweisApp** (ein Browser
+kann den Chip nicht lesen). Im Prototyp ist die Allowlist deshalb der
+Platzhalter für genau diese Vertrauensprüfung: Der Modus `eid` übergibt an den
+eID-Server/die AusweisApp; der Modus `demo` nutzt per `issue-card` ausgegebene,
+autorisierte Test-Ausweise. Die Funktion `sync-keys` ist der Anschlusspunkt für
+eine eigene Trust-Liste bzw. eID-Server-Anbindung – kein Zugriff auf ein
+Behördenregister.
+
+### 5.4 Grenzen und Missbrauchsszenarien
+
+- **Karte ≠ Person am Gerät:** Wie bei jeder eID-Nutzung kann eine Person freiwillig
+  ihre Karte + PIN einer anderen überlassen. Das ist rechtswidrig, skaliert aber
+  schlecht (physische Karte nötig) — genau dadurch werden Bot-Netze und
+  Massen-Manipulation wirksam verhindert.
+- **Verlorene/gesperrte Ausweise** fallen über die Sperrlistenprüfung des eID-Servers
+  heraus.
+- **Alters-/Staatsangehörigkeitsfragen:** Die eID steht auch Unions­bürgern (eAT,
+  eID-Karte) offen; ob deren Teilnahme gewünscht ist, ist eine politische
+  Konfigurationsentscheidung (Berechtigungszertifikat kann die Kartentypen
+  einschränken). Der Prototyp behandelt alle Karten gleich.
+
+---
+
+## 6. Funktionen im Einzelnen
+
+### 6.1 Themen einbringen — „1 Thema pro Tag“
+
+- Jedes Pseudonym kann **ein Thema pro Kalendertag** (Zeitzone Europe/Berlin)
+  erstellen; um **00:00 Uhr** beginnt der nächste Tag. Die Regel ist zusätzlich zur
+  Anwendungslogik als **Datenbank-Constraint** verankert (UNIQUE über Autor +
+  Erstelldatum) — sie kann also auch durch Programmierfehler nicht umgangen werden.
+- Pflichtfelder beim Erstellen:
+  - **Titel** (kurz, prägnant),
+  - **Ziel** — was soll konkret erreicht werden?
+  - **Begründung** — warum?
+  - **Kategorie** (siehe 6.3),
+  - **Geltungsbereich** — eine hierarchische **Auswahl statt Freitext**,
+    wie auf Behördenseiten: Deutschland → Bundesland → Landkreis/kreisfreie
+    Stadt (eingebaute Gebietsliste mit allen 16 Ländern und rund 400
+    Kreisen; die Gemeindeebene folgt in der Ausbaustufe über das amtliche
+    Gemeindeverzeichnis, ARS/Destatis).
+- **Themen sind nach Veröffentlichung unveränderlich.** Es gibt keinen
+  Bearbeiten-Weg — weder in der Oberfläche noch als Route. Damit ist die stille
+  Umdeutung einer laufenden Abstimmung ausgeschlossen: Woran abgestimmt wurde,
+  steht fest. Wer sich vertan hat, archiviert das Thema (solange noch keine
+  Stimme abgegeben ist) und bringt es neu ein. Eine spätere Ausbaustufe könnte
+  Korrekturen mit sichtbarer Versionsanzeige erlauben.
+
+### 6.2 Abstimmen
+
+- Pro Thema und Ausweis genau eine Stimme: **dafür** oder **dagegen**.
+- **Neutral = nicht abstimmen.** Enthaltung wird nicht als eigene Stimmart gezählt.
+- Die eigene Stimme ist **24 Stunden lang** änderbar oder zurückziehbar; danach
+  ist sie fest (auf der Hauptseite als eigene Gruppe „kürzlich abgestimmt,
+  noch änderbar“ sichtbar).
+- **Stimmen sind unverkettbar gespeichert:** In der Datenbank steht kein
+  Ausweis-Bezug, sondern nur ein HMAC aus Thema + öffentlichem Schlüssel mit
+  serverseitigem Geheimnis. Doppelstimmen sind ausgeschlossen, doch ohne das
+  Geheimnis lässt sich nicht rückschließen, welcher Ausweis wie gestimmt hat.
+- **Abstimmungsende je Thema — Datum, Zielwert oder beides:** Beim Einbringen
+  sind zwei Bedingungen ankreuzbar: ein **Enddatum** und ein **Zielwert**
+  (Einheit „X Stimmen“ für eine feste Zahl oder „% Stimmen“ für einen Anteil
+  der registrierten Ausweise).
+  Gesetzt werden darf eine von beiden **oder beide zugleich** — dann endet die
+  Abstimmung, **was zuerst eintritt**. Prozentangaben werden beim Anlegen in
+  eine absolute Zahl umgerechnet, damit das Ziel im Verlauf nicht mit der
+  Nutzerzahl wandert. Für **jeden** Zielwert gilt zusätzlich eine Untergrenze
+  von 10 Stimmen — auch ein ausdrücklich kleinerer Wert wird stillschweigend
+  darauf angehoben. Danach ist das Thema beendet.
+- **Themen werden nie gelöscht.** Es gibt keinen Löschweg für Verfasser. Ein
+  Thema, zu dem **noch niemand abgestimmt** hat, lässt sich **archivieren**:
+  Es verschwindet aus Listen, Suche und Ähnlichkeitsabgleich, ist nicht mehr
+  wählbar und nicht mehr meldbar, bleibt aber unter
+  seiner Adresse erhalten und trägt dort die Kennzeichnung „Archiviert“.
+- **Abgestimmte Themen bleiben unverändert bestehen.** Sobald die erste Stimme
+  abgegeben ist, entfällt auch das Archivieren — der Knopf ist dann schlicht
+  nicht mehr da. Damit bleibt jedes Thema, über das abgestimmt wurde, dauerhaft
+  nachvollziehbar. (Davon unberührt ist die Entfernung durch eine Bürger-Jury
+  nach festgestelltem Gesetzesverstoß, Kapitel 7.)
+- **Gleiche Titel sind erlaubt, aber sichtbar.** Beim Einbringen zeigt das
+  Formular schon während des Tippens, ob es bereits ähnliche Themen gibt, und
+  verlinkt sie; einbringen lässt sich das Thema trotzdem. Auf der Themenseite
+  steht dieselbe Liste unter „Ähnliche Themen“. Der Abgleich vergleicht die
+  bedeutungstragenden Wörter des Titels, nicht die Zeichenkette.
+- **Ergebnisse aktualisieren sich ohne Neuladen.** Ein schlanker JSON-Endpunkt
+  liefert Stimmenstände; Liste und Themenseite schreiben Balken, Zahlen und
+  Anteile im Hintergrund fort (alle zwölf Sekunden und beim Zurückkehren auf
+  den Tab). Ohne JavaScript bleibt der beim Aufruf gerenderte Stand stehen —
+  die Seite funktioniert weiterhin vollständig.
+- Die Darstellung ist überall dieselbe und bewusst knapp: ein Balken, darunter
+  „Dafür n / x %“ und „Dagegen n / y %“ — in der Liste als Haarlinie, auf der
+  Themenseite kräftiger.
+- **Drei Symbole oben rechts am Thema**, auf einer Höhe mit den Schildern für
+  Kategorie und Gebiet: ein **Lesezeichen** zum Merken (Thema, Kategorie,
+  Gebiet), eine **Archivbox** für den Verfasser eines Themas ohne Stimmen und
+  eine **rote Flagge** zum Melden. Die Flagge fehlt beim eigenen Thema und bei
+  beendeten Abstimmungen; läuft bereits eine Meldung, steht sie unterlegt und
+  ohne Funktion da. Beschriftungen tragen die Symbole nur als `title` und
+  `aria-label`.
+- **Auf der Themenseite steht der eigene Stand in den Knöpfen, nicht in einem
+  Satz.** Dort gibt es keinen erklärenden Text zur eigenen Stimme; ihr Zustand
+  ist an den beiden Knöpfen ablesbar: beide grau, solange nicht gewählt wurde; die gewählte Seite
+  blau, solange sie sich noch ändern lässt; nach Ablauf der 24 Stunden und bei
+  beendeter Abstimmung die gewählte Seite blass-blau, die andere abgedunkelt,
+  beide nicht mehr bedienbar. Serverseitig wird eine dann noch abgesetzte
+  Stimme unabhängig davon abgewiesen. In der **Themenliste** und in der Gruppe
+  „kürzlich abgestimmt“ steht die eigene Stimme dagegen weiterhin als Text
+  („Ihre Stimme: Dafür“, dort mit Frist) — Knöpfe, an denen man sie ablesen
+  könnte, gibt es dort nicht.
+
+### 6.3 Kategorien — Neutralität durch Breite, keine vorbefüllten Themen
+
+Damit die Plattform von Beginn an nicht als politisch gefärbt wahrgenommen wird,
+gilt das **Breitenprinzip auf Kategorien-Ebene**: Zum Start existieren
+ausschließlich die Kategorien — bewusst viele, quer über das gesamte politische
+Spektrum. **Themen werden nicht vorbefüllt**; jeder einzelne Inhalt der
+Plattform stammt aus der Bürgerschaft. So kann keine Startauswahl als
+redaktionelle oder politische Setzung gelesen werden.
+
+Kategorien (Start-Satz, erweiterbar):
+
+Umwelt & Klima · Energie · Wirtschaft & Mittelstand · Arbeit & Soziales · Rente &
+Alterssicherung · Gesundheit & Pflege · Bildung & Forschung · Familie & Jugend ·
+Migration & Integration · Innere Sicherheit · Justiz & Bürgerrechte · Digitales &
+Verwaltung · Verkehr & Infrastruktur · Wohnen & Mieten · Landwirtschaft & Ernährung ·
+Finanzen & Steuern · Europa & Außenpolitik · Verteidigung · Kultur, Medien & Sport ·
+Verbraucherschutz · Kommunales & Ehrenamt · Demokratie & Beteiligung
+
+### 6.4 Merkzettel und eigener Stand
+
+- **Einzelne Themen, Kategorien und Gebiete lassen sich merken**: Am Thema
+  steht dafür ein **Lesezeichen-Symbol**, das ein kleines Auswahlfeld mit drei
+  Einträgen öffnet — dieses Thema, seine Kategorie, sein Gebiet. Gemerktes ist
+  im Feld hervorgehoben und wird durch erneutes Antippen wieder entfernt.
+  Gemerkte Themen führen direkt zurück zum Thema, gemerkte Kategorien und
+  Gebiete filtern die Themenliste; alles ist am Schlüssel gespeichert und steht
+  auf jedem Gerät bereit.
+- **Alles auf einer Seite.** Es gibt keine getrennte Unterseite „Meine
+  Übersicht“ mehr; `/me` und `/topics` führen auf dieselbe Hauptseite. Dort
+  stehen übereinander: Merkzettel-Chips, die Gruppe „kürzlich abgestimmt (noch
+  änderbar)“ mit der eigenen Stimme und der Frist, und die Themenliste. Eine
+  anstehende Jury-Aufgabe wird über einen Hinweis in der Kopfzeile und eine
+  Weiterleitung auf `/jury` erzwungen.
+- Der vollständige eigene Stand — Stimmen, eingebrachte Themen, Merkzettel,
+  Meldungen, Jury-Zuteilungen — wird zusätzlich als **profil.yaml** ausgeliefert
+  (Kapitel 5.3), verschlüsselt an den eigenen Ausweis-Schlüssel.
+
+### 6.5 Sprache
+
+Deutsch ist Standard; Englisch vollwertig verfügbar. Die Wahl wird in der Sitzung
+und — bei angemeldeten Nutzern — **am Pseudonym** gespeichert.
+
+---
+
+## 7. Meldung rechtswidriger Inhalte und Bürger-Jury
+
+### 7.1 Grundsatz: Recht statt Richtung
+
+Gemeldet werden können **mutmaßlich rechtswidrige Inhalte** — nicht politische
+Meinungen. Zur Einordnung, weil danach oft gefragt wird: Auch extreme politische
+Auffassungen sind in Deutschland **nicht als solche strafbar**; die
+Meinungsfreiheit (Art. 5 GG) schützt auch scharfe und radikale Positionen. Strafbar
+sind konkrete Delikte — und nur an diesen wird gemessen.
+
+Eine Meldung besteht deshalb aus genau **einem Grund: dem Verstoß gegen ein
+Gesetz**. Es gibt **keinen Auffangtatbestand** und **keinen Freitext** — es
+wird ausschließlich am zitierten Gesetz bewertet. Beim Melden führt ein Suchfeld
+(Schlagwort oder Paragraphennummer) zum eingebauten Register; der gewählte
+Paragraph wird **wortgleich (1:1) zitiert** und der Jury unverändert vorgelegt.
+
+Das Register umfasst im Prototyp **neun Tatbestände** des Strafgesetzbuchs:
+
+| Norm | Tatbestand |
+|---|---|
+| § 130 Abs. 1 StGB | Volksverhetzung |
+| § 86a Abs. 1 StGB | Verwenden von Kennzeichen verfassungswidriger und terroristischer Organisationen |
+| § 111 Abs. 1 StGB | Öffentliche Aufforderung zu Straftaten |
+| § 185 StGB | Beleidigung |
+| § 186 StGB | Üble Nachrede |
+| § 187 StGB | Verleumdung |
+| § 240 Abs. 1 StGB | Nötigung |
+| § 241 Abs. 1 StGB | Bedrohung |
+| § 126a Abs. 1 StGB | Gefährdendes Verbreiten personenbezogener Daten |
+
+Das Register ist erweiterbar; die hinterlegten Volltexte sind vor einem
+Echtbetrieb wortgleich gegen gesetze-im-internet.de abzugleichen.
+
+### 7.2 Bürger-Jury statt Redaktionsmoderation
+
+Über die Meldung entscheidet keine Redaktion, sondern eine **zufällig geloste Jury
+aus der Nutzerschaft** — das Losverfahren (wie beim Schöffenamt) macht gezielte
+Beeinflussung praktisch unmöglich.
+
+**Auswahl:**
+
+- **1 % aller bereits auf der Plattform verwendeten Ausweis-Pseudonyme** wird per
+  kryptographisch sicherem Zufall (CSPRNG) gezogen. Die Mindestgröße
+  (Standard: 5) ist ein **Zielwert, keine Untergrenze**: Sind weniger geeignete
+  Personen verfügbar, besteht die Jury eben aus weniger — notfalls aus zweien.
+  Ebenso kann das Quorum unter den Standardwert 3 fallen, weil es auf die
+  tatsächliche Jurygröße gedeckelt wird. Bei kleiner Nutzerschaft entscheiden
+  also sehr wenige; das ist eine bewusste Abwägung zugunsten der
+  Funktionsfähigkeit und vor einem Echtbetrieb zu überdenken.
+- **Ausgeschlossen** sind: Pseudonyme, die bereits einer **laufenden** Meldung als
+  Jury zugeteilt sind; die meldende Person; die Autorin/der Autor des gemeldeten
+  Themas; sowie Pseudonyme in der **Karenzzeit** — wer eine abgeschlossene
+  Jury-Runde hinter sich hat, ist erst **nach 3 Tagen** wieder losbar.
+
+**Ablauf und Fristen (alle Zeiten Europe/Berlin):**
+
+1. Meldung wird erstellt → Jury wird sofort gelost, die Abstimmung **startet zur
+   nächsten Mitternacht (00:00)**.
+2. Ab Start läuft die reguläre Abstimmungsfrist von **24 Stunden**.
+3. Nach Ablauf der 24 Stunden wird entschieden, **sofern mindestens 0,5 %** (bezogen
+   auf die Nutzerschaft, d. h. die Hälfte der Jury; Mindestquorum konfigurierbar)
+   ihre Stimme abgegeben haben.
+4. Ist das Quorum nicht erreicht, **läuft die Meldung weiter**, bis es erreicht ist;
+   dann wird unmittelbar entschieden.
+
+**Stimmoptionen der Jury:** *bestätigen* (Inhalt verstößt), *ablehnen* (kein
+Verstoß), *Enthaltung* (zählt für das Quorum, nicht für die Mehrheit).
+**Entscheidung:** einfache Mehrheit bestätigen > ablehnen → Inhalt wird entfernt
+(Platzhalterseite „nach Gemeinschaftsprüfung entfernt“); sonst bleibt er stehen.
+Bei Gleichstand bleibt der Inhalt stehen (im Zweifel für die Meinungsfreiheit).
+
+**Mitwirkungspflicht:** Wer ausgelost wurde und noch nicht abgestimmt hat, wird beim
+**nächsten Anhalten des Ausweises** (Sitzungsbeginn) zuerst zur Jury-Entscheidung
+geführt und kann die übrigen Funktionen erst danach nutzen — oder wartet, bis die
+Meldung abgeschlossen ist. Enthaltung ist ausdrücklich zulässig; niemand wird zu
+einem inhaltlichen Urteil gezwungen.
+
+**Schutz vor Melde-Missbrauch:** je Pseudonym maximal 3 Meldungen pro Tag; je Thema
+höchstens **eine offene** Meldung (weitere Meldungen desselben Themas werden auf die
+laufende Prüfung verwiesen); dasselbe Pseudonym kann dasselbe Thema nur einmal
+melden. Alle Grenzwerte sind serverseitig durchgesetzt.
+
+### 7.3 Grenzen des Verfahrens
+
+Die Bürger-Jury ist eine **Plattform-Moderation**, kein Strafverfahren. Offenkundig
+strafbare Inhalte können unabhängig vom Juryergebnis zusätzlich den
+Strafverfolgungsbehörden gemeldet werden; gesetzliche Melde- und Löschpflichten
+(insb. **Digital Services Act**, ggf. NetzDG-Nachfolgeregeln) gelten neben dem
+Juryverfahren und erfordern im Echtbetrieb einen benannten Zustellungsbevollmächtigten
+und Melde­wege für Behörden. Das ist im Betriebskonzept der Ausbaustufe zu verankern.
+
+---
+
+## 8. Sicherheitsarchitektur
+
+Bürgerabstimmung wäre im Echtbetrieb ein **hochwertiges Angriffsziel** (politische
+Stimmungsbilder, staatsnahe Wahrnehmung). Der Prototyp ist deshalb von Grund auf
+konservativ gebaut: wenig Code, wenig Abhängigkeiten, restriktive Standardwerte.
+
+### 8.1 Prinzipien
+
+- **Datenminimierung als Verteidigung:** Was nicht gespeichert ist, kann nicht
+  gestohlen werden. Keine Namen, keine E-Mail-Adressen, keine Passwörter, keine
+  Klar-IP-Adressen in der Datenbank.
+- **Keine fremden Laufzeit-Abhängigkeiten:** Der Prototyp nutzt ausschließlich
+  PHP-Bordmittel (kein Framework, kein Composer-Paket, kein CDN, keine externen
+  Fonts/Skripte). Das eliminiert Lieferketten-Risiken und macht den gesamten Code
+  in einem Durchgang auditierbar.
+- **Sichere Standardwerte:** Testbanner an, Mock-eID nur explizit, restriktivste
+  HTTP-Header, alle Grenzwerte serverseitig.
+- **Tiefenstaffelung:** Kernregeln (1 Thema/Tag, eine Stimme pro Thema, eine offene
+  Meldung pro Thema, ein Juror nur einmal je Meldung) sind zusätzlich zur
+  Anwendungslogik als **Datenbank-Constraints** erzwungen.
+
+### 8.2 Maßnahmen im Code (Prototyp)
+
+| Bereich | Maßnahme |
+|---|---|
+| SQL | Ausschließlich PDO-**Prepared Statements**, kein String-SQL mit Nutzerdaten |
+| XSS | Konsequentes Output-Escaping (`htmlspecialchars`, ENT_QUOTES) in allen Templates; CSS und JavaScript werden als eigene Routen ausgeliefert. Ausnahmen ohne CSP-Bezug: das Icon-SVG trägt einen eigenen `<style>`-Block, die beiden Notfallseiten vor dem Start nutzen Inline-Styles |
+| CSP | `default-src 'none'` + explizite Freigaben nur für eigene Skripte/Styles/Bilder; `frame-ancestors 'none'`, `base-uri 'none'`, `form-action 'self'` |
+| Clickjacking | `X-Frame-Options: DENY` + CSP frame-ancestors |
+| Weitere Header | `X-Content-Type-Options: nosniff`, `Referrer-Policy: no-referrer`, restriktive `Permissions-Policy`, COOP/CORP; HSTS im HTTPS-Betrieb |
+| CSRF/Replay | **Einmal-Token** auf jedem POST-Formular: beim Einlösen verbraucht — jede Aktion ist genau einmal gültig |
+| Sessions | HttpOnly, SameSite, Secure (bei HTTPS), ID-Rotation bei An-/Abmeldung, Inaktivitäts- (30 min) und absolutes Timeout (8 h) — wichtig für öffentliche Terminals |
+| Identität | Der öffentliche Ausweis-Schlüssel selbst ist die Kennung — kein abgeleitetes Pseudonym. Das Server-Geheimnis (`data/secret.key`, 0600) wird beim ersten Start erzeugt und nur für die Stimmen-Marker und die Ratenbegrenzung verwendet |
+| Zufall | Jury-Losverfahren mit CSPRNG (`random_int`, Fisher-Yates), nicht mit SQL-`RANDOM()` |
+| Rate-Limits | Serverseitig je Pseudonym bzw. gehashter IP: Anmeldeversuche, Stimmen, Meldungen, Formular-POSTs |
+| Eingaben | Whitelist-Validierung (Enums, Längen, UTF-8-Prüfung, Kontrollzeichen-Filter); keine Datei-Uploads |
+| Fehlerbilder | Keine Stacktraces oder Pfade nach außen; generische Fehlerseiten; Sicherheitsereignisse werden ohne personenbezogene Daten protokolliert |
+| Struktur | Eine Datei im Webroot; Datenbank, Geheimnisse und Logs liegen in `data/` **innerhalb** des Webroots und sind über eine eigene `.htaccess` sowie eine 404-Regel in der Anwendung gesperrt. Ein Verzeichnis außerhalb des Webroots wäre stärker und ist für den Echtbetrieb zu empfehlen |
+| Betrieb | Selbsttest (`php index.php selftest`, 122 Prüfungen) deckt die Kernregeln automatisiert ab: Tagesgrenze, Abstimmungsende, Jury-Ausschlüsse, Quorum, Fristen, Karenz, Freigabeliste, Dauerhaftigkeit abgestimmter Themen, Archivierung, Ähnlichkeitssuche, Einrichtung des Echtbetriebs, Sprachtabellen |
+
+### 8.3 Bedrohungsmodell (Auszug)
+
+| Bedrohung | Antwort |
+|---|---|
+| Bot-/Sockenpuppen-Armeen | eID: eine physische Karte = ein Konto; ohne Karte keine Stimme |
+| Stimmenkauf/-zwang im großen Stil | Physische Karte + PIN nötig; skaliert schlecht; rechtlich sanktioniert |
+| Manipulation der Jury-Auswahl | CSPRNG-Losung serverseitig; Ausschlusslisten; keine Selbstmeldung zur Jury möglich |
+| Melde-Spam zur Zensur | Tageslimit, eine offene Meldung je Thema, Quorum + Mehrheit nötig, Gleichstand erhält Inhalt |
+| SQL-Injection / XSS / CSRF | Siehe 8.2 — durchgängig parametrisiert, escaped, tokenisiert |
+| Session-Diebstahl am Terminal | Kurze Timeouts, Abmelde-Knopf, HttpOnly-Cookies. Im Browser liegt außer dem Sitzungs-Cookie nur die `profil.yaml` im `sessionStorage`; „Abmelden“ löscht sie |
+| Datenbank-Diebstahl | Enthält öffentliche Ausweis-Schlüssel, Themen und Stimmen — keine Klaridentitäten. Die Stimmen sind ohne das Server-Geheimnis nicht zuordenbar; wer Datenbank **und** `secret.key` erbeutet, kann die Zuordnung berechnen |
+| Lieferkette (Pakete/CDN) | Keine externen Abhängigkeiten im Prototyp |
+| DDoS / Lastspitzen | Ausbaustufe: CDN/Anycast vor statischen Assets, horizontale Skalierung, siehe 10.3 |
+
+### 8.4 Echtbetrieb zusätzlich (Pflichtprogramm)
+
+TLS ausschließlich (HSTS + Preload), getrennte Umgebungen, Härtung nach
+BSI-IT-Grundschutz, externe Penetrationstests **vor** Start, laufendes
+Schwachstellen-Management + Bug-Bounty, signierte Deployments, Backups mit
+Wiederanlaufübungen, 24/7-Monitoring, DDoS-Schutz, und ein unabhängiges
+Sicherheits-Audit des Jury-Losverfahrens (nachvollziehbare, aber nicht
+vorhersagbare Ziehung — z. B. via veröffentlichtem Ziehungs-Commitment).
+
+---
+
+## 9. Datenschutz (DSGVO)
+
+- **Datenminimierung:** gespeichert werden nur: der öffentliche Ausweis-Schlüssel
+  als Kennung, Zeitstempel, eigene Themen, Merkzettel, Meldungen und
+  Jury-Zuteilungen. Stimmen liegen **ohne Bezug zum Ausweis** (HMAC-Marker).
+  Die gewählte **Sprache wird nicht gespeichert** — sie gilt nur für die
+  laufende Sitzung; die Spalte in der Kontozeile trägt lediglich den Standardwert
+  aus der Anlage. Keine Klaridentität, keine IP-Adressen im Klartext (nur
+  kurzlebige Hashes für Rate-Limits), keine Tracker, keine Cookies außer dem
+  Sitzungs-Cookie.
+- **Rechtsgrundlage** (Echtbetrieb): Art. 6 Abs. 1 lit. a/e DSGVO je nach
+  Trägerschaft; eID-Nutzung nach eIDAS/PAuswG mit Berechtigungszertifikat.
+- **Betroffenenrechte — Stand im Prototyp, ehrlich:** Die *Auskunft* ist
+  umgesetzt: die **profil.yaml** enthält den vollständigen eigenen Stand, an den
+  eigenen Ausweis-Schlüssel verschlüsselt. Sie wird allerdings **nur per
+  JavaScript** abgerufen — ohne JavaScript gibt es keine Selbstauskunft.
+  Die *Löschung* ist als Routine vorhanden und automatisiert geprüft
+  (`account_delete` löscht die Kontozeile, wodurch Merkzettel, Meldungen und
+  Jury-Sitze per Fremdschlüssel mit entfernt werden, und hängt eingebrachte
+  Themen an ein System-Konto um; **abgegebene Stimmen bleiben erhalten**, weil
+  sie keinen Bezug zum Ausweis tragen und nach dem Löschen niemandem mehr
+  zuzuordnen sind). Sie hat in dieser Fassung **keine Schaltfläche** in der
+  Oberfläche — der Löschbereich wurde entfernt. **Vor einem Echtbetrieb ist
+  dafür zwingend ein Weg in der Oberfläche zu ergänzen**, sonst ist Art. 17
+  DSGVO nicht erfüllt.
+- **Speicherbegrenzung:** Rate-Limit-Einträge verfallen automatisch;
+  Sicherheitslogs ohne Personenbezug.
+- Für den Echtbetrieb: Datenschutz-Folgenabschätzung (Art. 35 DSGVO) zwingend,
+  benannte(r) DSB, Verzeichnis von Verarbeitungstätigkeiten.
+
+---
+
+## 10. Technik
+
+### 10.1 Prototyp-Stack
+
+- **PHP ≥ 8.0** (strict types, harte Versionssperre beim Start), keine externen Pakete.
+- **SQLite** (WAL-Modus) als Prototyp-Datenbank — eine Datei, einfach zu prüfen;
+  die Datenzugriffsschicht ist so geschrieben, dass PostgreSQL in der Ausbaustufe
+  ein Austausch der Verbindung ist.
+- **Server-gerendertes HTML**, genau eine CSS- und eine JS-Datei, dazu das
+  Icon — alles aus derselben Datei ausgeliefert. Hell/Dunkel ist reines CSS,
+  dafür gibt es kein Skript.
+- Betrieb hinter Apache/nginx mit gesperrtem `data/` oder für Demos mit
+  dem eingebauten PHP-Server.
+
+### 10.2 Hintergrundläufe
+
+Zustandswechsel (Meldung „wartet“ → „läuft“ um 00:00, Entscheidung nach 24 h +
+Quorum, Karenzzeiten) verarbeitet ein idempotenter **Maintenance-Tick**: er läuft
+per Cron (`php index.php cron`) **und** zusätzlich beiläufig bei Seitenaufrufen (auf 30 Sekunden gedrosselt),
+sodass der Prototyp auch ohne Cron korrekt bleibt.
+
+### 10.3 Skalierungspfad
+
+PostgreSQL + Read-Replicas → zustandslose PHP-Knoten hinter Load-Balancer →
+CDN für Assets → Warteschlange für Jury-Benachrichtigungen → mandantenfähige
+Gebietsdaten (amtliche Gemeindeschlüssel AGS/ARS statt Freitext-Gebieten).
+
+---
+
+## 11. Parameter (konfigurierbar)
+
+| Parameter | Standard | Bedeutung |
+|---|---|---|
+| `show_test_banner` | **true** | Testbetrieb-Banner auf jeder Seite |
+| `eid_mode` | `demo` | `demo` (ausgegebene Test-Ausweise) oder `eid` (nur Ausweis-Apps) |
+| `eid_client_url` | `http://127.0.0.1:24727/eID-Client` | Aktivierungsadresse des eID-Clients (TR-03124) |
+| `eid_server_url` | leer | SOAP-Endpunkt des eigenen eID-Servers (TR-03130); leer = fail-closed |
+| `data/config.yaml` | fehlt | von der Einrichtungsseite geschriebene Überlagerung der Vorgaben |
+| `default_lang` | `de` | Standardsprache |
+| `jury_share` | 1 % | Anteil der Nutzerschaft je Jury |
+| `jury_min` | 5 | Mindest-Jurygröße |
+| `quorum_share` | 0,5 % | Quorum als Anteil der Nutzerschaft |
+| `quorum_min` | 3 | Mindest-Quorum |
+| `report_vote_hours` | 24 | Reguläre Jury-Abstimmungsdauer |
+| `jury_cooldown_days` | 3 | Karenz nach abgeschlossener Jury-Runde |
+| `reports_per_day` | 3 | Meldungen je Pseudonym und Tag |
+| `timezone` | Europe/Berlin | Bezugszeitzone aller Tagesgrenzen |
+
+---
+
+## 12. Roadmap
+
+1. **Prototyp (dieses Repository):** vollständige Fachlogik mit Mock-eID,
+   Zwei-Sprachen-UI, Jury-Verfahren, Selbsttests.
+2. **Pilot:** Anbindung echter eID-Server (Berechtigungszertifikat, AusweisApp-Flow),
+   externes Sicherheits-Audit + Pentest, DSFA, Barrierefreiheit nach BITV,
+   PostgreSQL.
+3. **Kommunal-Pilotgemeinden:** Terminals in Bürgerbüros, amtliche Gebietsschlüssel,
+   Auswertungs-Exporte für Räte und Verwaltungen.
+4. **Ausbau:** Delegations-/Sachverständigen-Funktionen, strukturierte
+   Ergebnisberichte an Parlamente, offene Schnittstellen (Open Data) mit
+   Differential-Privacy-Schutz kleiner Gebiete.
+
+---
+
+## 13. Offene Punkte
+
+- Marken-/Domainrecherche „Bürgerabstimmung“ und finale Namensentscheidung.
+- Trägerschaft und Finanzierung (Verein/Stiftung empfohlen: neutralitätssichernd).
+- Rechtsgutachten: eID-Berechtigungsumfang, DSA-Pflichtenkatalog, Jugendliche
+  (Ausweispflicht ab 16 — Teilnahmealter ist Konfigurationsfrage).
+- Verifizierbare Jury-Ziehung (öffentliches Commitment-Verfahren) — Konzept in 8.4
+  skizziert, Umsetzung in der Pilotphase.
+
+---
+
+## Anhang: Installation und Betrieb
+
+Der technische Prototyp ist **eine einzige Datei**. Es genügt ein Webserver
+mit PHP — kein Framework, kein Paketmanager, keine externen Dienste.
+
+1. `index.php` in das Webverzeichnis legen (Hauptverzeichnis oder Unterordner;
+   der Basispfad wird erkannt).
+2. PHP **8.0 oder neuer** mit `pdo_sqlite`, `mbstring` und `sodium` — alle drei
+   gehören zur Standardausstattung.
+3. Seite aufrufen. Beim ersten Aufruf legt die Datei selbst an: `data/`
+   (SQLite-Datenbank, Server-Geheimnis, Protokolle, Zugriffssperre),
+   `.htaccess` (saubere Adressen und Schutz interner Dateien) und `robots.txt`.
+
+Meldet die Seite „Fast geschafft“, fehlen dem Verzeichnis Schreibrechte
+(755/775 setzen, neu laden). Ohne `.htaccess`-Unterstützung — etwa unter nginx —
+arbeitet die Anwendung über automatisch erzeugte `/index.php/…`-Adressen
+weiter; eine gleichwertige `try_files`-Regel stellt die sauberen Adressen her.
+Dort ist zusätzlich `/data/` zu sperren — die Anwendung selbst beantwortet
+jede Anfrage auf diesen Pfad mit 404, ausgeliefert würde sie sonst am
+PHP-Prozess vorbei.
+
+Der Auslieferungszustand ist der **Testmodus** (Kapitel 5.3b): ein Knopf meldet
+ohne Ausweis an, damit sich die Plattform vorführen lässt. Über den Chip
+„Testmodus“ führt die Seite **„Echtbetrieb einrichten“** (Kapitel 5.3c) durch
+Prüfung, Zugangswahl und Umschaltung; sie schreibt die Einstellungen nach
+`data/config.yaml`, löscht alle Testdaten und aktiviert dauerhaft die strenge
+Ausweisprüfung. Der dafür nötige Einrichtungsschlüssel steht in
+`data/setup.token`.
+
+Wartung und Prüfung laufen über dieselbe Datei auf der Kommandozeile:
+
+| Aufruf | Zweck |
+|---|---|
+| `php index.php selftest` | 122 automatisierte Prüfungen der Fachregeln |
+| `php index.php cron` | Wartungslauf (sonst beiläufig bei Seitenaufrufen) |
+| `php index.php seed 400` | Demo-Stimmen, anonym wie im Echtbetrieb |
+| `php index.php jurysim` | Demo-Jury stimmt in laufenden Prüfungen ab |
+| `php index.php issue-card 3` | autorisierte Demo-Ausweise samt Abhol-Verweis |
+| `php index.php sync-keys` | Freigabeliste aus der konfigurierten Trust-Liste |
+| `php index.php setup-token` | Einrichtungsschlüssel für die Umschaltung anzeigen |
+| `php index.php config` | wirksame Einstellungen aus `data/config.yaml` anzeigen |
+| `php -S 127.0.0.1:8080 index.php` | lokale Vorführung ohne Webserver |