- Aufheben darf der Reservierende selbst (per Token-Link) und der
Betreiber. Ein offener release-Endpunkt wäre die naheliegende, aber
falsche Variante: dann löscht jeder Besucher fremde Reservierungen, und
weil reserved_by mitgeht, bleibt nicht mal nachvollziehbar, dass jemand
reserviert hatte. Token wird beim Aufheben und beim Erledigen gelöscht,
Vergleich mit compare_digest.
- Die Galerie bleibt frei zugänglich, ohne Zugangscode. Damit wird das
Rate-Limit zur einzigen Bremse vor dem Reservieren-Endpunkt, und zwei
Dinge gehören zwingend dazu: reserved_by erscheint öffentlich nur als
"reserviert", und noindex/robots.txt verhindern, dass Fotos und Texte
dauerhaft im Suchindex landen.
projekt.md bei /release entsprechend präzisiert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GR4bNaj9GtRu57J4Niii8o
Fehlte in Phase 4: das Image soll wie bei der Kantone-App über einen
Versions-Tag gebaut, vor dem Veröffentlichen getestet und in die Gitea-
Registry gestellt werden.
Der Plan hält dazu die Punkte fest, die dort nachträglich korrigiert werden
mussten - vor allem, Werte aus ${{ ... }} nicht direkt in die Shell zu
schreiben, weil Tag-Namen Sonderzeichen enthalten dürfen und der Job ein
Registry-Token hält.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GR4bNaj9GtRu57J4Niii8o
projekt.md beschreibt die Kinderkleider-Börse (FastAPI, SQLite, Bild-Upload
mit WebP-Konvertierung). Plan.md ergänzt die dort offenen Entscheidungen:
Frontend-Variante A (Jinja2 + HTMX, kein Node.js), Erfassen hinter Passwort,
Reservieren ohne Anmeldung, erreichbar aus dem Internet.
Aus dieser Kombination folgt der Schwerpunkt des Plans - ein offener,
zustandsändernder Endpunkt im Internet und ein Bild-Upload sind die beiden
Angriffsflächen, die den Ausschlag geben.
Noch kein Code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GR4bNaj9GtRu57J4Niii8o
StefanandClaude Opus 5