Der Wunsch: "jeder Scout, Manager oder DogFather muss mit seinen
Creatorn die PDFs durchgehen, und beide druecken dann auf verifiziert,
so dass wir den Beweis haben -- und das ist danach auch nicht mehr zu
aendern."
Das ist kein Haekchen, das ist ein NACHWEIS. Wer so etwas baut, muss
drei Fragen beantworten, sonst ist er wertlos:
WER hat bestaetigt? Beide Seiten getrennt, mit Name, Zeitpunkt und IP.
Eine einzelne Bestaetigung reicht nicht -- "ich habe es ihm gezeigt" und
"er hat es mir gezeigt" sind zwei verschiedene Aussagen, und erst
zusammen ergeben sie einen Beweis. Bestaetigt nur einer, steht die
Unterweisung sichtbar als HALB da, in einer eigenen warnenden Farbe.
Diese Zwischenstufe sichtbar zu machen ist der Punkt: Ein Nachweis, bei
dem nur einer unterschrieben hat, sieht sonst aus wie fertig -- und man
merkt es erst, wenn jemand danach fragt.
WORAUF genau? Nicht auf "die Regeln", sondern auf eine bestimmte Datei.
Beim Bestaetigen wird der SHA-256 der PDF-Datei mitgespeichert. Tauscht
spaeter jemand die Datei aus, passt der Fingerabdruck nicht mehr, und
die Seite sagt das auch ("Das Dokument wurde seit der Bestaetigung
ausgetauscht"). Ohne diesen Wert waere die Bestaetigung ein Zettel ohne
Bezug.
IST ES UNVERAENDERT? Eine abgeschlossene Bestaetigung laesst sich nicht
mehr aendern und nicht loeschen -- und zwar nicht, weil der Code es
nicht anbietet, sondern weil die DATENBANK es ablehnt. Zwei Trigger mit
RAISE(ABORT). Ein Schutz, der nur im Code steht, ist beim naechsten
neuen Weg zur Datenbank wieder weg.
DER VOLLZUG WURDE DURCHGESPIELT. Aus RunOne stammt die Lehre, dass ein
Weg, den man nicht rueckgaengig machen kann, tagelang live sein und NIE
gelaufen sein kann. Die Pruefung bestaetigt deshalb wirklich, schliesst
ab, und versucht dann eine Aenderung -- ueber die Schnittstelle UND
direkt auf der Datenbank. Beide werden abgelehnt.
Und die GEGENPROBE dazu: Der Trigger wird entfernt, dieselbe Aenderung
versucht -- sie geht durch -- und der Trigger wieder gesetzt. Eine
Sperre, die man nicht hat scheitern sehen, ist keine Sperre.
Der Server entscheidet anhand der ROLLE, welche Seite gesetzt wird --
nicht der Absender. Sonst koennte ein Creator die Bestaetigung seines
Betreuers eintragen, und der ganze Nachweis waere wertlos. Eine bereits
gesetzte Seite wird nie ueberschrieben; ein Datum laesst sich also auch
nicht nachtraeglich verschieben.
Die Dokumente kommen aus der Wissens-Bibliothek, es gibt keinen zweiten
Upload-Weg. Sonst gaebe es Dateien, die nur hier existieren -- und
niemand wuesste, welche Fassung die richtige ist. Eine Unterweisung wird
nie geloescht, nur abgeschaltet: Die Nachweise haengen daran.
EIN EIGENER FEHLER, VON DER BROWSERPRUEFUNG GEFUNDEN: Der Aufruf der
Zusatzbloecke stand NACH einem return. laden() steigt frueh aus, wenn
die Liste leer ist -- und dann wurden Vorlagen und Unterweisungen nie
gebaut. Also ausgerechnet auf der leeren Seite, fuer die sie gedacht
sind. Jetzt stehen sie in einem finally.
Co-Authored-By: Claude Opus 5 <[email protected]>
108 lines
4.4 KiB
HTML
108 lines
4.4 KiB
HTML
<!doctype html>
|
||
<html lang="de">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
|
||
<title>Dogfather Universe · Creator Workspace</title>
|
||
<meta name="robots" content="noindex, nofollow" />
|
||
<meta name="theme-color" content="#05070d" />
|
||
<link rel="icon" href="assets/img/favicon.png" />
|
||
<link rel="stylesheet" href="assets/css/gate.css?v=202609011635" />
|
||
<link rel="stylesheet" href="assets/css/start.css?v=202609011635" />
|
||
</head>
|
||
|
||
<body class="start">
|
||
|
||
<!-- Der Schleier ueber der Buehne (Casper und HasiDog in den unteren
|
||
Ecken, siehe start.css). Ein eigenes Element statt eines dritten
|
||
Pseudo-Elements -- body hat nur ::before und ::after. -->
|
||
<div class="schleier" aria-hidden="true"></div>
|
||
|
||
<header class="kopfleiste">
|
||
<p class="marke"><span class="marke__text">Dogfather Universe · Creator Workspace</span></p>
|
||
<div class="kopfleiste__rechts">
|
||
<span class="wer" id="wer">…</span>
|
||
<button type="button" class="abmelden" id="abmelden">Abmelden</button>
|
||
</div>
|
||
</header>
|
||
|
||
<!-- Volle Breite: Bei 880 px waren drei Kacheln je 285 px breit, und in
|
||
den groesseren Schriften brach der Text ab. Mehr Breite ist hier die
|
||
ehrlichere Loesung als kleinere Schrift. -->
|
||
<main class="inhalt inhalt--breit">
|
||
<!-- Die Begrüßung sagt jetzt etwas. "Angemeldet" stand vorher da, obwohl
|
||
man das oben rechts ohnehin sieht – die Zeile war verschenkt. An
|
||
ihrer Stelle steht der Tag, die Kalenderwoche und, wenn der Tag
|
||
einen Charakter hat, ein kurzes Wort dazu (neue Woche, Endspurt,
|
||
Wochenende). Darunter die Lage in einem Satz. -->
|
||
<section class="willkommen">
|
||
<p class="marke willkommen__datum">
|
||
<span id="datum">…</span>
|
||
<span class="willkommen__marker" id="tagesmarker" hidden></span>
|
||
</p>
|
||
<div class="willkommen__reihe">
|
||
<span class="willkommen__plakette" id="plakette" aria-hidden="true"></span>
|
||
<div class="willkommen__text">
|
||
<h1 class="titel" id="gruss">Willkommen</h1>
|
||
<p class="unterzeile">
|
||
<span id="rollentext">…</span>
|
||
<span class="willkommen__lage" id="lage" hidden></span>
|
||
</p>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Was ist dran? Steht VOR den Zahlen, weil es der Unterschied
|
||
zwischen "wie viel liegt an" und "was muss ich jetzt tun" ist.
|
||
Bleibt komplett weg, wenn nichts anliegt. -->
|
||
<section class="dran" id="dran-block" hidden>
|
||
<div class="klapp-kopf">
|
||
<p class="feldschild">Was ist dran</p>
|
||
<button type="button" class="knopf-still" id="dran-schalter"
|
||
aria-expanded="false" aria-controls="dran" hidden>
|
||
<span id="dran-schalter-text">Alle zeigen</span>
|
||
<svg class="klapp-pfeil" viewBox="0 0 24 24" aria-hidden="true">
|
||
<path d="m6 9.5 6 6 6-6" />
|
||
</svg>
|
||
</button>
|
||
</div>
|
||
<ul class="dran__liste" id="dran" data-klapp="zu"></ul>
|
||
</section>
|
||
|
||
<!-- Zahlen zuerst: Das Konzept will "Prioritäten statt Datenfriedhof".
|
||
Sind alle sechs null, steht dort ein Satz statt sechs Nullen. -->
|
||
<section class="zahlen-block" id="zahlen-block">
|
||
<p class="feldschild">Deine Aufgaben</p>
|
||
<ul class="zahlen" id="zahlen"></ul>
|
||
<!-- Kein Grau-in-Grau, wenn alles erledigt ist: Ein leerer Posteingang
|
||
ist eine gute Nachricht und darf auch so aussehen. -->
|
||
<div class="zahlen-leer" id="zahlen-leer" hidden>
|
||
<span class="zahlen-leer__haken" aria-hidden="true">
|
||
<svg viewBox="0 0 24 24"><path d="m5 12.6 4.4 4.4L19 7.4" /></svg>
|
||
</span>
|
||
<span>
|
||
<strong>Nichts offen.</strong>
|
||
<span class="zahlen-leer__still">Alles abgearbeitet – gönn dir was.</span>
|
||
</span>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Die Bereiche, in drei Gruppen: was man täglich braucht, was zu
|
||
einem Creator gehört, was den Laden am Laufen hält. Aufgebaut von
|
||
start.js – dort steht auch, warum. -->
|
||
<div id="bereiche"></div>
|
||
|
||
<p class="fuss">
|
||
„Was ist dran" führt keine eigene Liste, sondern zeigt, was in den Bereichen
|
||
schon liegt – ein Punkt verschwindet von selbst, sobald die Sache erledigt ist.
|
||
Angezeigt wird nur, was du ohnehin sehen darfst.
|
||
</p>
|
||
</main>
|
||
|
||
<script src="assets/js/wahl.js?v=202609011635" defer></script>
|
||
<script src="assets/js/bereiche.js?v=202609011635" defer></script>
|
||
<script src="assets/js/kopf.js?v=202609011635" defer></script>
|
||
<script src="assets/js/start.js?v=202609011635" defer></script>
|
||
</body>
|
||
</html>
|