Eine Quittung ist kein Beweis
Szene 7 von 13
Ein Zugangscode für die App-Prüfung musste angeglichen werden. Die Meldung „Konfiguration geändert“ war nicht dasselbe wie „Anmeldung funktioniert“.
Erklärung
Hier liegt die wichtigste Unterscheidung dieser Vorlesung. Eine Konfigurationsänderung erzeugt eine Quittung: Datei geändert, Dienst neu gestartet, Zeitstempel notiert — ohne den Wert selbst preiszugeben. Das beweist, dass etwas geschah. Es beweist nicht, dass der eigentliche Ablauf jetzt funktioniert. Deshalb folgte auf die Quittung ein zweiter, unabhängiger Schritt: von außen, mit einem eigenen Werkzeug, wurde die komplette Anmeldesequenz nachgestellt — Vorab-Anfrage, Code-Anfrage, Code-Bestätigung, Profil-Abruf — und jeder Schritt einzeln protokolliert, ohne den Code selbst je auszugeben. Erst als alle Schritte grün waren, galt die Reparatur als bewiesen, nicht als vermutet. Achtet auf die getrennten Beobachter: die Änderung kam von einer Stelle, der Beweis von einer anderen — dieselbe Instanz bestätigt niemals ihre eigene Änderung.
Quittung und Beweis sind getrennt
- Konfigurationsquittung
- „Ich habe X geändert“ — eine Behauptung über eine Handlung.
- Ausführungsbeweis
- „Ich habe Y beobachtet, nachdem X geändert wurde“ — eine Beobachtung.
- Getrennte Beobachter
- Die Änderung von einer Stelle, der Beweis von einer anderen.
git log --oneline -- docs/lernbegleiter/engineering/app-review-reconciled-handoff-2026-09-23_08-34-54.mdDenkpause
Der Controller meldet „Zugangscode angeglichen, Dienst neu gestartet“. Reicht das, um „Anmeldung funktioniert“ zu formulieren?
Ja, die Meldung eines vertrauenswürdigen Controllers genügt.
Eine Meldung über eine eigene Handlung ist kein unabhängiger Beweis.
Nein — erst der von außen beobachtete, vollständige Anmeldeablauf zählt als Beweis.
Richtig. Erst der unabhängig beobachtete, vollständige Ablauf zählt.
Nein, gar keine Änderung kann je als funktionierend gelten.
Übertrieben; ein beobachteter Erfolg zählt, sobald er unabhängig beobachtet wurde.
Belege
Konfigurationsquittung · angefordert · docs(ios): reviewer-code alignment — controller lacks ASC access; exact owner action recorded
2026-09-23 · docs/lernbegleiter/engineering/app-review-reconciled-handoff-2026-09-23_08-34-54.md · 1e18520471a7bf9290a6f6a65eae40e4b695b16c
| Authorization relayed to the controller (`msg_3280ea9a6b20`, 08:29): align `STUDY_REVIEW_OTP_CODE` on study-dev with the ASC Sign-In Password value, reload only the service, nothing else | sent | | Controller answer (checkpoint 08:30/08:35) | **Controller cannot read the ASC value** — it holds no ASC credential; secure access to the ASC field is unavailable to the controller and this session will not carry the value. → exact owner action below | | Configuration-change receipt (host/file/service/timestamp/operator, **no values**) | **pending owner action** | | End-to-end execution proof (this session, from outside: `/auth/otp/request` → `/auth/otp/verify` → `/auth/profile` 200) | **pending** — will be run only after the receipt; last known result 08:29: verify 400 (mismatch) | | Independent audit confirmation (`auth.review_otp_bypass` row: timestamp + account only) | **pending** |
Ausführungsbeweis · unabhängig beobachtet · docs(ios): handoff checklist — alignment done, sign-in proven, audit + driver review in flight, rights blocked
2026-09-23 · docs/lernbegleiter/engineering/app-review-reconciled-handoff-2026-09-23_08-34-54.md · b4871d13b5932a4f352ca873645abe1860ee93b2
| C2 | Reviewer sign-in executed end to end (separate from C1) | **DONE 09:02:46 and 09:03:12** | this session | native sequence from this Mac: `/auth/preauth` 200 → `/auth/otp/request` 200 → `/auth/otp/verify` 200 (session cookie) → `/auth/profile` 200, user "App Review", role student; code held in memory only, nothing printed or stored |
Mit meinem Konto im Hörsaal öffnen →