ClaudeandClaude Opus 5.5 4cf9fe192d feat(editor): Community-Logos unten rechts mit Herzen und Sortierung
Task 8: der Bereich „Logo unten rechts“ in der Optionsspalte des Editors (Spec § 3 und § 5).

- logos/logo-picker.ts (neu): createLogoPicker baut Kopf (Überschrift, Plakette „Community“, „+ Hochladen“, Satz zur Community), den
  Umschalter „Beliebt“/„Neu“ (Admins zusätzlich „Gemeldet“/„Ausgeblendet“, je eine Ansicht mit sort und filter) und das Raster:
  erste Kachel „Kein Logo“, je Logo eine Kachel mit Bild, Name, „von <Anzeigename>“ bzw. „von Anonym“ und einem eigenen Herz-Knopf
  neben dem Auswahlknopf. „Mehr laden“ hängt die nächste Seite an (Duplikate nur einmal), Leer-Text und Ladefehler mit „Nochmal
  versuchen“ (wiederholt genau den gescheiterten Schritt); nur die jüngste Antwort einer Ansicht zählt. Die Auswahl gehört dem
  Editor: ein Klick meldet onSelect, markiert wird über select(); ein Logo außerhalb der Liste wird nach dem Laden der ersten Seite
  per getLogo geholt und als zweite Kachel angeheftet (steht es in der Liste, gibt es keine Anfrage). selected() liefert die Zeile
  für die Infozeile in Task 9. Herzen: optimistisch mit Rücksprung und Fehlertext (role="alert"); solange eine Anfrage für ein
  Logo läuft, bleiben weitere Klicks auf sein Herz wirkungslos; Gäste öffnen erst den Login (abgebrochen: nichts passiert, kein
  Fehlertext); die Herzen einer Seite kommen mit genau deren IDs, beim Anmelden für alle gezeigten Logos, beim Abmelden aus; eine
  späte Antwort überschreibt kein inzwischen selbst geschaltetes Herz. „Hochladen“ meldet Gäste zuerst an, öffnet den Dialog (mit
  Signal, das beim Verlassen der Seite schließt), setzt das neue Logo als erste Kachel, ruft rememberLogo und onSelect(id).
- logos/logo-image.ts (neu): das PNG einer Kachel laden, auf die Pixelgrenze prüfen (MAX_LOGO_PIXELS, so wie checkGalleryImage die
  Galerie-Bilder prüft; darüber, nicht lesbar oder Ladefehler: neutraler Platzhalter statt Absturz) und zeigen: mehrfarbig als <img>,
  einfarbig als weiße Maske, immer auf dem dunklen Kartengrund. Die Object-URL gibt die zurückgegebene Funktion frei; eine Datei, die
  erst danach eintrifft, wird nicht mehr angezeigt.
- logos/logo-asset.ts: MAX_LOGO_PIXELS wird exportiert (eine Quelle für Renderer und Kacheln).
- logos/logos.css: Kopf, Umschalter, Raster (ab 1024 px zwei Spalten, sonst auto-fill ab 140 px), Kacheln mit Bildfläche auf #1B2738,
  Herz (gefüllt, wenn gedrückt), Leer- und Fehlerzeilen; Bild und Maske teilen sich die Regeln mit der Dialog-Vorschau.
- editor/editor-page.ts: der Picker sitzt in options.logoSlot, die Wahl setzt config.logo, sync ruft picker.select(config.logo), das
  Verlassen der Seite ruft dispose. Übernommen aus dem Review von Task 5: failedKey blockiert ein Logo nicht mehr für immer, eine
  andere Wahl (Logo, Details, Marke) hebt die Sperre auf; derselbe Schlüssel wird weiter nicht im Kreis neu versucht.
- editor/dom.ts: Symbole heart und plus. i18n/en.ts: englische Texte zu allen neuen Beschriftungen.
- Tests: logo-picker.test.ts (Aufbau, Sortierung, Mehr laden, Auswahl und angeheftetes Logo, Herzen mit Rennen und Login, Leer und
  Ladefehler, Hochladen, Kachelbilder, dispose, Englisch), logo-image.test.ts, editor-page.test.ts (Verdrahtung, Regressionstest zu
  failedKey). Vitest 51 Dateien, 1666 Tests grün, tsc und Build sauber.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 22:40:37 +00:00

AirCard-IOS

Inoffizielles Hobbyprojekt, mit dem man eigene Kartenmotive für Apple Wallet unter https://aircard-ios.org gestalten kann. Bilder hochladen, Vorlage und Netzwerk-Logo wählen, herunterladen – oder mit Konto speichern. Keine Verbindung zu Apple, Visa, Mastercard, UnionPay, American Express, JCB oder Discover.

Aufbau

web/ – Vite + TypeScript ohne Framework. Frontend-Module in src/:

  • card/ – Geometrie, Zuschnitt, Canvas-Rendering (keine DOM-Abhängigkeiten, einzeln testbar)
  • editor/ – UI (Vorlagen, Vorschau, Download, Speichern)
  • account/ – Appwrite-Client, Auth, Kartenverwaltung
  • pages/ – Routen (/, /karten, /passwort-neu via History-API)

deploy/ – Webhook-Router (Port 8087), Build-Skript (deploy.sh), nginx-Config, Traefik-Route für Appwrite.

docs/ – Spec, Plan, Appwrite-Konfiguration.

Lokal entwickeln

cd web
npm ci
npm run dev          # Entwicklungsserver http://localhost:5173

Login und Speichern brauchen die Appwrite-API. Ohne Einstellung gilt als Endpoint ${location.origin}/v1 (der Entwicklungsserver hat keinen Proxy dafür, es würde also der Vite-Server selbst gefragt). Für die lokale Entwicklung deshalb in web/.env.local (steht über .env* in .gitignore) den Endpoint setzen:

VITE_APPWRITE_ENDPOINT=https://appwrite.webklar.com/v1

Die Projekt-ID ist als Standard im Code hinterlegt (6ac2130a00289343d6d5, VITE_APPWRITE_PROJECT_ID überschreibt sie). Damit Appwrite den lokalen Host akzeptiert, muss die Web-Plattform localhost in der Appwrite-Console eingetragen sein (Projekt → Overview → Integrations → Platforms). Der Produktions-Build bekommt VITE_APPWRITE_ENDPOINT=https://aircard-ios.org/v1 aus der Container-Umgebung (deploy/compose-snippet.yml).

Tests

Im Frontend (web/):

cd web
npx vitest run               # Unit-Tests (card/*, editor/*, account/*, pages/*)
npx tsc --noEmit             # TypeScript-Prüfung

Im Repo-Wurzelverzeichnis:

node --test deploy/webhook-server.test.js        # Webhook-Server (deploy.sh wird dort durch einen Stub ersetzt)
node --test deploy/deploy.test.js                # deploy.sh (echtes Skript, lokaler git-Remote, npm-Stub)
node --test web/scripts/appwrite-setup.test.mjs  # Appwrite-Schema-Skript

Deploy

Automatisch: Push auf main → Gitea-Webhook → Container webklar-aircard-build führt npm ci und vite build aus → Ergebnis nach out/ → nginx webklar-aircard liefert.

Manuell:

docker exec webklar-aircard-build sh /deploy.sh

Starten nur mit:

docker compose up -d aircard-build aircard aircard-api

aircard-api ist der kleine API-Dienst der Community-Galerie (deploy/api/, Route aircard-ios.org/api, siehe deploy/api/README.md).

Die Appwrite-API wird über /home/webklar/apps/traefik/dynamic/aircard.yml geroutet (Vorlage: deploy/traefik/aircard.yml): Requests auf aircard-ios.org/v1 mit Header X-Appwrite-Project: 6ac2130a00289343d6d5 gehen an den Appwrite-Container. Ohne diesen Header antwortet der nginx der Seite mit 404.

Appwrite

Projekt „AirCard“ auf appwrite.webklar.com:

  • Projekt-ID (öffentlich, von Appwrite generiert): 6ac2130a00289343d6d5. Sie steht in deploy/traefik/aircard.yml, in /home/webklar/apps/.env (AIRCARD_APPWRITE_PROJECT_ID) und als Standard in web/src/account/appwrite.ts.
  • Datenbank: aircard, Tabelle: cards, Bucket: card-images (das Skript unten legt sie an und prüft sie)
  • Console-Einstellungen laut docs/appwrite-console.md (Soll-Stand, nicht maschinell geprüft; --check prüft nur das Schema): Auth mit E-Mail + Passwort, Sitzungsdauer 30 Tage, max. 5 Sitzungen pro Nutzer, Nutzerlimit 2000, Web-Plattformen aircard-ios.org und localhost. Schritte 3 und 4 dort (Auth-Härtung, Dienste abschalten) sind optional und am Live-Projekt unbestätigt.

Schema prüfen:

node --env-file=/home/webklar/apps/.env web/scripts/appwrite-setup.mjs --check

Schema erstmalig anlegen:

node --env-file=/home/webklar/apps/.env web/scripts/appwrite-setup.mjs

Umgebungsvariablen (in /home/webklar/apps/.env):

  • AIRCARD_APPWRITE_PROJECT_ID – Projekt-ID (idempotent im Skript lesbar)
  • AIRCARD_APPWRITE_API_KEY – API-Key aircard-provision (nur für Setup)

Hinweis

Inoffizielles Hobbyprojekt. Alle Marken gehören ihren Inhabern.

S
Description
No description provided
Readme
1.9 MiB
0 Stars 1 Watchers 0 Forks
Languages
TypeScript 74.9%
JavaScript 21.8%
CSS 2.8%
Shell 0.4%
HTML 0.1%