# App-Bauplan: Gemeinsame Auftragsübersicht
Beispiel-App-Bauplan · fiktiver Betrieb. Anforderungen und Projektbezeichnungen bilden einen durchgängigen Planungsfall; Ressourcen sind zur Einrichtung vorgesehen.
## 1. Auftrag, Ziel und Nutzen
Ihr Servicebetrieb mit zwölf Mitarbeitenden koordiniert Aufträge in Excel. Die Planung erfasst den Auftrag, vereinbart einen Termin und weist eine Person zu. Rückmeldungen kommen telefonisch; Kopien der Tabelle und nachträgliche Korrekturen erschweren die Übersicht.
Wir ersetzen diesen Ablauf durch eine kleine Webanwendung mit einer gemeinsamen Datenbank. Der Pilot umfasst zwei Personen in der Planung und zwei Servicetechniker, bei rund zwanzig neuen Aufträgen pro Woche. Eine interne Person übernimmt die Weiterentwicklung; eine Vertretung erhält ebenfalls Zugang zu Code und Betriebsanleitung.
**Projektverantwortung:** Nina führt die Planung und interne Umsetzung. Tobias übernimmt die Vertretung und prüft Freigaben mit. Mara und Leon nutzen die Anwendung in der Servicetechnik. Nina und Tobias erhalten die beiden Entwicklungszugänge.
**Nach der Umsetzung können Sie einen Auftrag erfassen, zuweisen, ausführen und abschliessen, ohne dafür mehrere Listen abzugleichen.** Die Planung und die zugewiesene Person arbeiten am selben Datensatz. Ihr Team kann anschliessend eine kleine Verbesserung mit KI-Unterstützung selbst durchführen, prüfen und veröffentlichen.
| Nutzen im Alltag | Woran Sie die Verbesserung erkennen |
| --- | --- |
| Ein gemeinsamer Stand | Die Planung findet Zuständigkeit, Termin und Status in einer Übersicht |
| Weniger Rückfragen zum Auftragsstand | Techniker melden den Abschluss in der Anwendung; die Planung sieht ihn nach dem Aktualisieren |
| Klare Zugriffe | Techniker sehen ihre eigenen Aufträge; die Planung überblickt den gesamten Pilot |
| Wissen im Betrieb | Hauptverantwortliche und Vertretung können Projekt, Konten und nächsten Änderungsschritt erklären |
Erfassen Sie vor dem Pilot eine Woche lang Rückfragen und doppelte Übertragungen. Vergleichen Sie dieselben Grössen nach zwei Pilotwochen. Dieser Abgleich zeigt den tatsächlichen Nutzen; eine feste Zeit- oder Geldersparnis ist nicht vorausgesetzt.
Der Bauplan beschreibt das zu bauende Ergebnis und den Weg dorthin. Die Anwendung und ihre Abnahmetests entstehen bei der Umsetzung.
## 2. Erste Ausbaustufe und Geschäftsregeln
1. Die Planung erfasst Auftragsnummer, Kunde und Beschreibung. Der Auftrag ist zunächst «Neu».
2. Sie weist eine aktive Person und einen Termin zu. Erst dann darf der Status «Geplant» gesetzt werden.
3. Die zugewiesene Person öffnet ihre Aufträge im persönlichen Konto.
4. Nach der Arbeit setzt sie ihren geplanten Auftrag auf «Erledigt».
5. Die Planung sieht den aktualisierten Stand und kann bei Bedarf nach Status oder zuständiger Person filtern.
Die Planung darf einen erledigten Auftrag wieder öffnen, sofern Termin und Zuständigkeit gesetzt sind. Techniker ändern keine Kunden, Auftragsnummern oder Zuweisungen. Löschen ist im Pilot nicht vorgesehen; Fehlaufträge korrigiert die Planung. «Erledigt» ist eine Arbeitsrückmeldung und löst keine Rechnung aus.
**Ausserhalb der ersten Stufe:** Rechnungen, Arbeitszeiterfassung, Materiallager, Tourenplanung, Offline-Betrieb, Anhänge, Kalenderintegration und das vollständige alte Auftragsarchiv. Der erste Import übernimmt nur freigegebene offene Aufträge. Die Oberfläche soll auf dem Smartphone bedienbar sein; eine eigene mobile App ist nicht erforderlich.
## 3. Oberfläche und Bedienung
[Skizze vergrössert öffnen](https://appreif.com/beispiele/auftragsuebersicht-skizze.svg).
| Bereich | Verhalten |
| --- | --- |
| Filter | «Alle», «Neu», «Geplant», «Erledigt» sowie die zuständige Person wählen; «Alle» setzt den jeweiligen Filter zurück |
| Neuer Auftrag | Pflichtangaben erklären; doppelte Auftragsnummer zurückweisen; Erfolg erst nach bestätigtem Speichern anzeigen |
| Übersicht | Auftragsnummer, Kunde, Termin, Zuständigkeit und Status anzeigen; nach Speichern den Stand neu laden |
| Details | Planung bearbeitet erlaubte Angaben; Technik erhält nur die Aktion zum Abschliessen eines eigenen geplanten Auftrags |
| Fehler und gleichzeitige Änderungen | Ungültige Eingaben verständlich melden. Wurde der Auftrag inzwischen geändert, neu laden statt die andere Änderung still zu überschreiben |
## 4. Datenmodell und Berechtigungen
### Datenstruktur
| Tabelle | Wesentliche Felder | Regeln |
| --- | --- | --- |
| Kunden | `id`, `firmenname` | Stabile interne Kennung; ein Kunde kann mehrere Aufträge haben |
| Teammitglieder | `user_id`, `anzeigename`, `rolle`, `aktiv` | Verbindung zum persönlichen Anmeldekonto; Rolle «Planung» oder «Technik»; nur Kontoverantwortliche verwalten Rollen |
| Aufträge | `id`, `auftragsnummer`, `kunde_id`, `beschreibung`, `termin`, `zustaendig_id`, `status`, `version`, `geaendert_am`, `geaendert_von` | Nummer eindeutig; Kunde erforderlich; Status auf drei Werte begrenzt; «Geplant» braucht Termin und aktive Zuständigkeit; Versionsnummer erkennt zwischenzeitliche Änderungen |
Firmen- und Personennamen dienen der Anzeige. Verknüpft wird über Kennungen, damit Umbenennungen die Zuordnung nicht verändern. `version` und die Änderungsangaben werden beim Speichern serverseitig gesetzt. Eine vollständige Änderungshistorie gehört noch nicht zur ersten Stufe.
### Wer darf was?
| Aktion | Planung | Technik |
| --- | --- | --- |
| Aufträge lesen | Alle Aufträge des Betriebs | Eigene zugewiesene Aufträge |
| Kundendaten lesen | Kundenliste | Nur Kunde eines eigenen Auftrags |
| Auftrag anlegen und zuweisen | Ja | Nein |
| Beschreibung, Termin, Kunde oder Nummer ändern | Ja, gemäss Geschäftsregeln | Nein |
| Eigenen geplanten Auftrag abschliessen | Ja | Ja |
| Erledigten Auftrag wieder öffnen | Ja | Nein |
| Aufträge löschen | Nein | Nein |
| Rollen und Konten administrieren | Separater administrativer Zugang | Nein |
Nicht angemeldete und deaktivierte Personen erhalten keinen Datenzugriff. Ein technisches Administrationskonto ist etwas anderes als die Geschäftsrolle «Planung».
**Technische Umsetzung:** Lesezugriffe werden durch Datenbankregeln mit Row Level Security begrenzt. Schreiben erfolgt über eng begrenzte Datenbankfunktionen für «erfassen», «zuweisen», «abschliessen» und «wieder öffnen». Direkte Schreibrechte auf den Tabellen werden den App-Konten entzogen. Jede Funktion prüft angemeldete Person, aktive Rolle, Zuständigkeit, erlaubte Felder und erwartete Versionsnummer. Rollen stammen aus der geschützten Teamtabelle, nicht aus frei änderbaren Profildaten.
Diese Funktionen brauchen ausdrücklich begrenzte Aufrufrechte und eine sorgfältige Prüfung erhöhter Rechte. Auch direkte Datenabrufe und Funktionsaufrufe gehören in die Tests. [Supabase: Zugriffsregeln](https://supabase.com/docs/guides/database/postgres/row-level-security) und [Datenbankfunktionen](https://supabase.com/docs/guides/database/functions).
Zum Nachschlagen: [Daten, Zugänge und Sicherungen](https://appreif.com/wissen/daten-zugriffe-und-sicherungen/).
## 5. Empfohlene Werkzeuge und Datenstandort
**Empfehlung:** React mit TypeScript und Vite für die Oberfläche, Supabase Pro für PostgreSQL und Anmeldung, Cloudflare Workers Static Assets für die ausgelieferten Oberflächendateien. Verwenden Sie für beide Supabase-Projekte ausdrücklich die Region **Zürich, `eu-central-2`**. Wählen Sie nicht nur die allgemeine Region «Europe». Die aktuelle [Supabase-Regionenliste](https://supabase.com/docs/guides/platform/regions) führt Zürich als konkreten Standort auf.
| Baustein | Auswahl und Zweck |
| --- | --- |
| Oberfläche | React/TypeScript: überschaubare Auftragsansichten; Vite erzeugt die auslieferbaren Dateien im Ordner `dist` |
| Daten und Anmeldung | Supabase: PostgreSQL, persönliche Anmeldung und kontrollierte Datenzugriffe in einem Dienst |
| Code und Änderungen | Privates GitHub-Repository in der Organisation des Betriebs; GitHub Desktop für die täglichen Git-Schritte |
| Editor und KI | VS Code mit Codex; zwei persönliche Zugänge für Hauptverantwortliche und Vertretung über ChatGPT Business |
| Hosting | Zwei getrennte statische Anwendungen: Vorschau und Betrieb. Geschäftsdaten werden direkt zwischen Browser und Supabase übertragen |
| E-Mail | Eigener SMTP-Versand für Einladungen und Passwortzurücksetzungen; zunächst vorhandenen Firmen-Maildienst prüfen |
Die Kombination hält Serververwaltung klein und passt zum vorhandenen Einstieg in Webentwicklung. Die App benötigt keine KI im laufenden Auftragsbetrieb. Das KI-Abo dient der Entwicklung; eine KI-API in der Anwendung ist nicht eingeplant.
Beide Supabase-Projekte dienen ausschliesslich Ihrem Betrieb. Anwendungskonten für die vier Pilotpersonen sind von den administrativen Anbieterzugängen getrennt.
**Datenstandort und Anbieter unterscheiden:** Zürich legt den primären Datenbankstandort fest. Supabase ist damit kein Schweizer Betreiber, und GitHub, KI-Werkzeug, E-Mail und die globale Auslieferung der Oberfläche sind eigene Dienste. Falls die Vorgabe auch Betreiber, Supportzugriffe, Sicherungen, Protokolle und sämtliche Verarbeitung in der Schweiz umfasst, muss die weiter unten beschriebene Schweizer Variante vor der Einrichtung gewählt und dafür bestätigt werden. Echte Auftragsdaten und Zugangsdaten werden nicht an das KI-Werkzeug übergeben.
### Sinnvolle Alternativen
| Voraussetzung | Alternative | Was sich ändert |
| --- | --- | --- |
| Nur ein KI-Arbeitsplatz wird neu benötigt | VS Code mit GitHub Copilot Business statt eines neuen ChatGPT-Business-Arbeitsbereichs | Andere KI-Oberfläche und Nutzungsabrechnung; derzeit USD 19 je zugewiesenem Platz/Monat. Freigabe und Zusatznutzung im Firmenkonto einstellen. [Tarif](https://docs.github.com/en/copilot/get-started/plans) |
| Schweizer Betreiber für App und Datenbank ist erforderlich | Nine Deploio mit verwaltetem PostgreSQL in Zürich | Ein serverseitiger Teil übernimmt Anmeldung und Datenzugriff; Supabase Auth, dessen HTTP-Schnittstelle und Berechtigungsfunktionen werden nicht durch das Austauschen einer Datenbankadresse ersetzt |
| Bereits eigene Schweizer Cloud-Infrastruktur und Betriebswissen vorhanden | Exoscale PostgreSQL DBaaS in einer [Schweizer Zone](https://www.exoscale.com/datacenters/) | Verwaltete Datenbank, aber zusätzlich eigene App/API und Anmeldung; Ressourcen, Backups und Gesamtpreis vor Bestellung im [Preisrechner](https://www.exoscale.com/pricing/) festlegen |
| Supabase muss vollständig selbst betrieben werden | Selbst gehostetes Supabase auf Schweizer Infrastruktur | Updates, Betrieb, Überwachung und Wiederherstellung gehen an den Betrieb oder seinen IT-Partner. Für den Einstieg ohne benannte Betriebsperson nicht empfohlen |
Bei Nine ist für diesen kleinen Pilot eine geteilte PostgreSQL-Economy-Datenbank eine mögliche Einstiegslösung. Sie hat begrenzte Ressourcen und kann bei Wartung kurz unterbrochen werden. Eine dedizierte Business-Datenbank ist die Alternative bei höheren Anforderungen. Die [Standorte und Betriebsgrenzen](https://docs.nine.ch/de/docs/on-demand-services/postgresql/economy) sowie die [App-Plattform](https://nine.ch/de/produkte/deploio/) sind dokumentiert. Der Wechsel auf diese Variante erfordert einen angepassten Bauplan für Backend, Anmeldung und Veröffentlichung.
Diese Variante verlegt App-Server und Datenbank zu einem Schweizer Anbieter. Entwicklungswerkzeuge wie GitHub und KI bleiben separat freizugebende Dienste.
## 6. Laufende Kosten und Budget
Preisstand: 4. November 2026. Beträge in der Anbieterwährung, vor Steuern und möglichen Wechselkurs-/Kartenkosten. Die folgenden Summen sind eine Startkalkulation innerhalb der genannten Tarifgrenzen. Interne Arbeitszeit und die Umsetzung sind separat zu budgetieren.
### Empfohlene Variante: Supabase in Zürich
| Position | Ansatz pro Monat | Grundlage |
| --- | --- | --- |
| Supabase Pro mit produktivem Micro-Projekt | USD 25 | Organisationsabo einschliesslich Compute-Guthaben für einen Micro-Server |
| Zweites Micro-Projekt für Test/Vorschau | ca. USD 10 | Eigene Datenbank und eigener Anmeldedienst, stundenbasiert abgerechnet |
| Statische Oberfläche auf Cloudflare | USD 0 zum Start | Reine statische Auslieferung; keine eigene Worker-API oder serverseitige Darstellung geplant |
| GitHub Free, GitHub Desktop und VS Code | USD 0 zum Start | Private Versionsverwaltung und lokale Werkzeuge; erweiterte Teamkontrollen separat prüfen |
| ChatGPT Business für zwei Personen | USD 50 | Zwei Plätze à USD 25 bei monatlicher Zahlung; Nutzungslimits und Zusatzguthaben beachten |
| E-Mail-Versand | USD 0 bei passendem bestehendem Dienst oder Resend Free | Resend Free: bis 3'000 Nachrichten/Monat, höchstens 100/Tag; Pro derzeit USD 20/Monat |
| Unabhängige verschlüsselte Sicherung | Vorhandener freigegebener Speicher oder CHF 5–10 Reserve | Planungsreserve für zusätzlichen Speicher, kein eingeholter Anbietertarif; Einrichtung und Wiederherstellung sind eigene Aufgaben |
| Domain | Bestehende Firmen-Subdomain: kein zusätzlicher Domainkauf | Eine neue Domain wird nur bei Bedarf separat bestellt |
**Basis: rund USD 85 pro Monat plus gegebenenfalls CHF 5–10 Sicherungsspeicher.** Davon sind USD 35 App-Infrastruktur und USD 50 Entwicklungswerkzeug. Mit Resend Pro statt kostenfreiem Versand wären es rund USD 105. Bereits vorhandene freigegebene KI-Plätze können die zusätzlichen Kosten reduzieren. Ein neuer Business-Arbeitsbereich benötigt mindestens zwei Plätze; USD 25 ist daher nicht sein gesamter Monatspreis.
Grundlagen: [Supabase-Tarife](https://supabase.com/pricing), [Compute-Abrechnung](https://supabase.com/docs/guides/platform/manage-your-usage/compute), [Cloudflare Static Assets](https://developers.cloudflare.com/workers/static-assets/billing-and-limitations/), [GitHub Free](https://docs.github.com/en/get-started/learning-about-github/githubs-plans), [Codex/Business-Tarif](https://learn.chatgpt.com/docs/pricing), [Resend-Tarife](https://resend.com/pricing).
Zusätzliche Projekte, grössere Server, mehr Speicher, Datenverkehr oder KI-Zusatznutzung können die Rechnung erhöhen. Supabase-Compute ist nicht durch den allgemeinen Spend Cap begrenzt. Aktivieren Sie verfügbare Budgetmeldungen, erlauben Sie KI-Zusatzkäufe nur nach Freigabe und kontrollieren Sie im ersten Monat wöchentlich die tatsächlichen Kosten. Der kostenlose Supabase-Tarif ist für Übungen geeignet; für den Betrieb sind hier tägliche Sicherungen und ein bezahltes Projekt eingeplant.
### Schweizer Betreiber: Kalkulation für Nine
| Position | Kleiner Pilot | Mit dedizierter produktiver Datenbank |
| --- | --- | --- |
| Produktive App, Deploio Standard-1 | CHF 35 | CHF 35 |
| Produktive PostgreSQL-Datenbank | Economy S: CHF 5.50 | Business XS: CHF 68.20 |
| Test-App, Micro | CHF 8.75 | CHF 8.75 |
| Test-Datenbank, Economy S | CHF 5.50 | CHF 5.50 |
| **Infrastruktur pro Monat** | **CHF 54.75** | **CHF 117.45** |
Diese Kalkulation umfasst jeweils eine App-Instanz pro Umgebung und kleine Datenbanken. E-Mail, zusätzlicher Sicherungsspeicher, KI-Werkzeuge und Umsetzungs-/Pflegearbeit kommen hinzu. Economy S umfasst bis 1 GB; bei Wachstum kann die Datenbank automatisch in ein teureres Paket wechseln. Ein höherer Verfügbarkeitsbedarf oder weitere App-Replikate verändern den Ansatz. [Deploio-Preise](https://docs.nine.ch/de/docs/deplo-io/) und [Datenbankpreise, exkl. MWST](https://docs.nine.ch/de/docs/on-demand-services/).
## 7. Konten, Projekt und Arbeitsumgebung einrichten
Die Geschäftsleitung gibt Kosten, Anbieter und Standort frei. Die interne Projektverantwortliche richtet die Ressourcen in Konten des Betriebs ein; die Vertretung erhält passende persönliche Zugänge. Administratorrechte und Wiederherstellungscodes gehören in den Firmen-Passwortmanager.
Aktivieren Sie die Mehrfaktor-Anmeldung für die administrativen Anbieterzugänge. Verwenden Sie persönliche Konten mit passenden Rechten und hinterlegen Sie den Wiederherstellungsweg für die Vertretung.
### Schritt 1: Werkzeuge installieren
1. [Node.js 24 LTS](https://nodejs.org/en/about/previous-releases) mit npm installieren. VS Code, GitHub Desktop und Git nach den [GitHub-Einrichtungsschritten](https://appreif.com/wissen/github-einrichten/) einrichten.
2. In einem neuen Terminal `node --version`, `npm --version` und `git --version` prüfen. Node muss mit `v24.` beginnen. Versionen im Projektblatt festhalten.
3. Den Ordner `C:\Projekte` anlegen. Unter macOS einen eigenen Projekteordner verwenden. Alle folgenden App-Befehle werden im neu anzulegenden Projekt ausgeführt, nicht im Ordner einer bestehenden Anwendung.
Hintergrund: [Git und Versionsverwaltung](https://appreif.com/wissen/git-und-versionsverwaltung/).
### Schritt 2: Das App-Grundgerüst anlegen
Im Terminal zuerst den eigenen Projekteordner öffnen. Der Unterordner `auftragsuebersicht` darf noch nicht existieren. Dann:
```sh
npm create vite@9.3.3 auftragsuebersicht -- --template react-ts --no-interactive
cd auftragsuebersicht
npm install
npm run build
npm run dev
```
Die ersten Befehle erzeugen das React-/TypeScript-Grundgerüst und installieren dessen Pakete. Der Build soll ohne Fehler durchlaufen; `npm run dev` zeigt die lokale Adresse der Startseite. Mit `Ctrl+C` beenden Sie den lokalen Entwicklungsserver. Diese Startseite ist zunächst das Grundgerüst, noch nicht die Auftragsverwaltung. [Vite-Einrichtung](https://vite.dev/guide/).
Öffnen Sie **diesen selben Ordner** in VS Code. Übernehmen Sie `package-lock.json` in Git und notieren Sie die erzeugten Paketversionen. Weitere Arbeitsplätze installieren anschliessend mit `npm ci` genau diesen Paketstand. Ein neues Grundgerüst wird dafür nicht nochmals erstellt.
### Schritt 3: Privates Repository verbinden
In GitHub Desktop den vorhandenen lokalen Ordner hinzufügen und dort bei Bedarf ein Git-Repository erstellen. Vor dem ersten Commit `.gitignore` prüfen; insbesondere `.env.local` und Sicherungsdateien ausschliessen. Anschliessend in der **Firmenorganisation** als privates Repository `auftragsuebersicht` veröffentlichen. Kein zweites, getrennt initialisiertes Remote-Repository daneben anlegen.
Hauptbranch ist `main`; neue Aufgaben beginnen auf einem Arbeitsbranch wie `aufgabe/statusfilter`. Die Vertretung klont dasselbe Repository. Prüfen Sie im Browser, ob der Commit im privaten Firmenprojekt sichtbar ist. Konkrete Adresse und Zugriffsrollen in `docs/projektblatt.md` eintragen. [Vorhandenes lokales Projekt verbinden](https://appreif.com/wissen/github-einrichten/#vorhandenes-projekt).
### Schritt 4: KI und Projektwissen vorbereiten
Codex über die [Einrichtungsanleitung](https://appreif.com/wissen/ki-werkzeuge-einrichten/) in VS Code installieren und mit dem freigegebenen Business-Zugang anmelden. Lassen Sie die KI zuerst den Projektordner und vorhandene Start-/Build-Befehle erklären, ohne Dateien zu ändern. Hauptverantwortliche und Vertretung üben danach [eine kleine README-Änderung](https://appreif.com/wissen/erste-aenderung-mit-ki/) mit Prüfung und Commit.
Legen Sie `README.md`, `AGENTS.md`, `docs/projektblatt.md`, `docs/app-bauplan.md` und `docs/betrieb.md` an. Verwenden Sie die [Dokumentvorlagen](https://appreif.com/wissen/projektwissen-und-vorlagen/) und füllen Sie sie für diese Auftragsverwaltung aus. Die KI-Regeln enthalten: nur Testdaten verwenden, kleine Aufgaben bearbeiten, Rollenregeln erhalten, Änderungen erklären und Prüfungen nennen. Produktionszugänge und Datenexporte bleiben ausserhalb des KI-Kontexts.
### Schritt 5: Supabase-Projekte anlegen
1. In der Supabase-Organisation des Betriebs den Pro-Tarif wählen. Zwei Micro-Projekte anlegen: `auftraege-test` und `auftraege-prod`. Für beide **Zürich `eu-central-2`** auswählen. Ist die Region bei der Einrichtung nicht verfügbar, Standortfrage klären, bevor Daten importiert werden.
2. Unterschiedliche starke Datenbankpasswörter erzeugen und im Firmen-Passwortmanager speichern. Projektkennungen, Region und Zuständigkeiten im Projektblatt notieren, die Passwörter selbst nicht.
3. Zunächst ausschliesslich das Testprojekt mit der lokalen App verbinden. Im App-Ordner `npm install @supabase/supabase-js` ausführen.
4. `.env.local` anlegen und die beiden folgenden Werte aus dem Verbindungsdialog des **Testprojekts** eintragen:
```text
VITE_SUPABASE_URL=PROJEKT_URL_AUS_DEM_TESTPROJEKT
VITE_SUPABASE_PUBLISHABLE_KEY=PUBLISHABLE_KEY_AUS_DEM_TESTPROJEKT
```
Diese Variablennamen sind im Code genauso zu verwenden. Der Publishable Key ist für die Browser-App bestimmt und schützt keine Daten ohne passende Zugriffsregeln. Datenbankpasswort, Secret Key oder `service_role`-Schlüssel dürfen niemals in einer `VITE_`-Variable stehen. Nach Änderungen an der lokalen Umgebungsdatei den Entwicklungsserver neu starten. [React-Verbindung mit Supabase](https://supabase.com/docs/guides/auth/quickstarts/react).
### Schritt 6: Datenbankänderungen nachvollziehbar vorbereiten
Die Tabellen und Berechtigungen werden als SQL-Migrationsdateien im Repository abgelegt. Im App-Ordner:
```sh
npm install --save-dev --save-exact supabase@3.0.0
npx supabase --version
npx supabase init
```
Damit entsteht die lokale Projektkonfiguration; eine Cloud-Datenbank wird dadurch nicht angelegt. Die gewählte CLI-Version im Projektblatt festhalten. Die aktuelle CLI-v3-Dokumentation verwendet `--remote` für gehostete Ziele. Prüfen Sie vor weiteren Befehlen die installierte Hilfe und verwenden Sie den dazu passenden [Migrationsablauf](https://supabase.com/docs/guides/local-development/cli-workflows).
Die erste SQL-Datei legt Datenmodell, Lese- und Aufrufrechte sowie die begrenzten Schreibfunktionen aus Abschnitt 4 an. Erst prüfen, dann auf **`auftraege-test`** anwenden. Vor jedem Datenbanklauf Projektkennung und Ziel prüfen; produktive Daten werden nicht zum Ausprobieren zurückgesetzt. Der vollständige lokale Supabase-Server ist eine spätere Option mit zusätzlicher Laufzeitumgebung; für diesen Start arbeiten wir mit der getrennten gehosteten Testdatenbank. [CLI installieren und initialisieren](https://supabase.com/docs/guides/local-development/cli/getting-started).
Mit der installierten CLI 3 werden Anmeldung, Test-Verbindung und eine leere Migrationsdatei so vorbereitet. `PROJEKTKENNUNG_TEST` durch die Kennung von **`auftraege-test`** ersetzen:
```sh
npx supabase login
npx supabase link --project-ref PROJEKTKENNUNG_TEST
npx supabase migration new auftragsmodell
```
Die Migration im Ordner `supabase/migrations` ausarbeiten und prüfen. Danach zuerst die Vorschau der geplanten Änderungen ansehen und nur auf das bestätigte Testprojekt anwenden:
```sh
npx supabase db push --dry-run --remote
npx supabase db push --remote
```
Der zweite Befehl verändert die verknüpfte Datenbank. Eine Vorschau der SQL-Dateien ist noch kein Funktionstest; anschliessend die Zugriffs- und Datenprüfungen aus Paket 1 ausführen.
### Schritt 7: Anmeldung und E-Mail vervollständigen
Offene Selbstregistrierung deaktivieren und die vier Pilotpersonen gezielt einladen. Die Geschäftsrollen anschliessend über den geschützten administrativen Weg zuweisen. Für Einladungen und Passwortzurücksetzungen eigenen SMTP-Versand konfigurieren; Supabases Standardversand ist für den Produktivbetrieb nicht vorgesehen. Bestehenden Firmenversand zuerst auf Nutzbarkeit prüfen, andernfalls Resend nach Freigabe der Datenverarbeitung einsetzen.
Absenderadresse und Domain bestätigen, SMTP-Zugang nur bei Supabase hinterlegen und Zustellung an alle Pilotpersonen testen. Für Test und Betrieb die jeweils passende Website- und Rücksprungadresse hinterlegen; die Vorschau darf nach der Anmeldung nicht in den produktiven Betrieb wechseln. [Supabase SMTP](https://supabase.com/docs/guides/auth/auth-smtp).
## 8. Umsetzung in sechs kleinen Paketen
Bearbeiten Sie ein Paket nach dem anderen. Ein Paket endet mit sichtbarem Ergebnis, Prüfnachweis und Commit. Prüffälle sind hier Abnahmekriterien für die Umsetzung, keine bereits bestandenen Tests.
| Paket | Konkrete Aufgabe | Erfolgskontrolle |
| --- | --- | --- |
| 1 — Daten und Regeln | Migration für Kunden, Teammitglieder und Aufträge; drei künstliche Testaufträge; Lese- und Schreibregeln | Doppelte Nummer und ungültiger Status scheitern; unangemeldet keine Daten; Techniker A liest auch direkt keinen Auftrag von B |
| 2 — Anmeldung und Rollen | Einladungen, Anmeldung, Abmeldung, Passwortzurücksetzung und geschützte Rollenzuweisung | Alle vier Konten gelangen in ihre richtige Ansicht; deaktiviertes Konto erhält auch mit alter Sitzung keinen Datenzugriff |
| 3 — Planung | Übersicht, Filter, Auftragserfassung und Zuweisung | Neuer Auftrag wird gespeichert und wiedergefunden; «Geplant» ohne Termin/Zuständigkeit scheitert; zwei gleichzeitige Bearbeitungen erzeugen keinen stillen Datenverlust |
| 4 — Technikrückmeldung | Eigene geplante Aufträge anzeigen und abschliessen | Abschluss erscheint nach Aktualisieren in der Planung; fremder Auftrag und Änderungen an Kunde, Nummer oder Zuweisung scheitern auch bei direktem Aufruf |
| 5 — Excel-Übernahme | Freigegebene offene Aufträge bereinigen und zunächst in Test importieren | Anzahl, Nummern, Kunde, Zuständigkeit und Status stimmen mit der freigegebenen Quelle überein; Konflikte werden gemeldet |
| 6 — Veröffentlichung und Übergabe | Getrennte Vorschau/Betrieb, Sicherungen, Rücknahmeweg und erste eigenständige Verbesserung | Pilotaufgaben und Zugriffsprüfungen bestehen; Wiederherstellung wird erprobt; interne Person setzt eine kleine Änderung nach Anleitung um |
### Erste KI-Aufgabe
> Lies `docs/app-bauplan.md`. Entwirf die erste SQL-Migration für Kunden, Teammitglieder und Aufträge sowie die vorgesehenen Lese- und Schreibzugriffe. Erkläre zuerst Tabellen, Beziehungen, erlaubte Aktionen und Prüffälle. Verwende nur künstliche Daten. Techniker dürfen ausschliesslich eigene geplante Aufträge abschliessen; direkte Änderungen an anderen Feldern und Rollen sind nicht erlaubt. Beschreibe Rechte erhöhter Datenbankfunktionen ausdrücklich. Ändere keine gehostete Datenbank. Warte nach dem Entwurf auf die Prüfung.
Beim Einsatz von Funktionen mit erhöhten Rechten müssen insbesondere Aufruferprüfung, Berechtigungsvergabe und ein festgelegter `search_path` geprüft werden. Eine funktionierende Oberfläche allein bestätigt diese Regeln nicht.
Zum Grundgerüst gehören Start-, Lint- und Build-Prüfungen. Automatisierte fachliche und Berechtigungstests werden mit Paket 1 eingerichtet; ihre tatsächlichen Befehle kommen danach in die README. `npm run build` ersetzt diese Tests nicht. Die Umsetzungsperson muss jeden Test ausserhalb des KI-Chats selbst wiederholen können.
### Erste eigenständige Verbesserung
Sobald der Grundablauf funktioniert, ergänzt Nina mit KI-Hilfe den Filter «Überfällig»; Tobias wiederholt Prüfung und Veröffentlichung anhand der Anleitung. Der Filter zeigt geplante Aufträge mit einem Termin vor dem heutigen Datum in der Zeitzone des Betriebs. Prüffälle: geplanter Auftrag von gestern sichtbar, Auftrag von morgen verborgen, erledigter Auftrag von gestern verborgen. Diese kleine Erweiterung braucht zunächst keine neuen Datenfelder und macht den Änderungsablauf praktisch nachvollziehbar.
## 9. Excel-Daten übernehmen und umschalten
| Excel-Angabe | Übernahme und Prüfung |
| --- | --- |
| Auftragsnummer | Eindeutige Nummer; fehlende oder doppelte Nummern vor Import klären |
| Kunde | Einmalige Zuordnung zu einer Kundenkennung; unterschiedliche Schreibweisen bereinigen |
| Tätigkeit | Pflichtbeschreibung; unnötige vertrauliche Angaben entfernen |
| Termin | Eindeutiges Datum; keine automatische Interpretation mehrdeutiger Werte |
| Verantwortlich | Zuordnung zu aktivem persönlichen Konto |
| Status | Bestätigte Zuordnung zu «Neu», «Geplant» oder «Erledigt» |
Bei zwei Zeilen «A-102» mit unterschiedlicher Zuständigkeit entscheidet die Planung über den gültigen Datensatz. Der Import darf nicht still die letzte Zeile gewinnen lassen. Importfehler werden in einer geschützten Liste gesammelt, nicht in öffentlichen Protokollen.
Nach dem erfolgreichen Probelauf vereinbart die Planung einen Umschalttermin. Dann Originaldatei sichern, Bearbeitung kurz unterbrechen, freigegebenen Bestand übernehmen und Anzahl sowie Zuordnungen abgleichen. Anschliessend wird die alte Liste schreibgeschützt; zwei beschreibbare Hauptlisten würden den Versionskonflikt fortsetzen. Bei abgebrochenem Import vor Umschaltung bleibt Excel führend. Nach Umschaltung müssen neue App-Aufträge vor einem Rückwechsel zuerst abgeglichen werden.
## 10. Vorschau, Veröffentlichung und Rücknahme
Zunächst die Vorschau einrichten. Im Cloudflare-Dashboard unter «Workers & Pages» eine Anwendung erstellen und das private Firmen-Repository importieren. Nur dieses Repository freigeben. Die statische Bereitstellung mit Build-Befehl `npm run build` und Ausgabeordner `dist` konfigurieren. Als erste Adresse die zugeteilte Testadresse verwenden. Eine zweite Bereitstellung bildet den Betrieb unter der vorgesehenen Firmen-Subdomain. [Repository im Dashboard verbinden](https://developers.cloudflare.com/workers/get-started/dashboard/).
In der Build-Konfiguration der Vorschau `VITE_SUPABASE_URL` und `VITE_SUPABASE_PUBLISHABLE_KEY` aus **`auftraege-test`** eintragen; in der Build-Konfiguration des Betriebs die Werte aus **`auftraege-prod`**. Beide bekommen eigene Werte **beim Build**, denn Vite baut sie in die Oberflächendateien ein. Eine blosse Änderung späterer Laufzeitvariablen ersetzt keinen neuen Build. Für den produktiven Build die beiden Werte und die Projektkennung vor Veröffentlichung im Vieraugenprinzip prüfen.
Die Oberfläche ruft direkt Supabase auf. In der Cloudflare-Konfiguration wird für Unterseiten die SPA-Rückgabe auf `index.html` festgelegt. Auch nach direktem Öffnen oder Neuladen einer Detailadresse muss die richtige Ansicht erreichbar sein. [Statische Apps und Routing](https://developers.cloudflare.com/workers/static-assets/routing/single-page-application/) und [Vite-Umgebungsvariablen](https://vite.dev/guide/env-and-mode).
Vor Veröffentlichung des Betriebs:
- dieselben geprüften Migrationen auf das bestätigte Produktionsprojekt anwenden;
- ausschliesslich freigegebene Daten und echte Pilotkonten übernehmen;
- erlaubte und verbotene Aktionen nochmals gegen den Betrieb prüfen;
- Datum, Commit, verwendete Konfiguration und durchgeführte Prüfungen im Betriebsblatt festhalten.
Bei einem Fehler den zuvor freigegebenen Oberflächenstand wieder veröffentlichen. Datenbankänderungen brauchen einen eigenen Rücknahme- oder Korrekturplan; beschädigte Daten werden damit nicht automatisch wiederhergestellt. Die Anleitung dazu steht in `docs/betrieb.md`. [Prüfen, veröffentlichen und zurücksetzen](https://appreif.com/wissen/testen-veroeffentlichen-zuruecksetzen/).
## 11. Sicherungen, Pflege und Verantwortung
Für das Pro-Projekt sind tägliche Datenbanksicherungen mit sieben Tagen Aufbewahrung vorgesehen. Ergänzen Sie wöchentlich einen verschlüsselten, unabhängig aufbewahrten Export nach der offiziellen Wiederherstellungsanleitung. Der Export bleibt in freigegebenem Speicher des Betriebs, ausserhalb von Git und KI-Werkzeugen. Das Betriebsblatt benennt Inhalt, Aufbewahrung, Speicherort und zuständige Person. [Supabase-Sicherungen](https://supabase.com/docs/guides/platform/backups).
**Wiederherstellungsziele für den Pilot:** Bei einem Datenfehler, solange die Anbietersicherung verfügbar ist, höchstens ein Tag Datenverlust. Beim vollständigen Verlust des Anbieterprojekts kann die wöchentliche unabhängige Kopie bis zu sieben Tage alt sein. Diese zweite Grenze ist vor Freigabe bewusst zu bestätigen; ist sie zu gross, müssen häufigere unabhängige Exporte eingerichtet werden. Wiederanlaufziel ist ein Arbeitstag. Das sind Anforderungen, die in einer Wiederherstellungsübung nachzuweisen sind.
Die Übung erfolgt in einer getrennten Wiederherstellungsumgebung: Daten und benötigte Kontenzuordnung wiederherstellen, Einloggen und Zuordnungen prüfen, einen Auftrag bearbeiten und das Resultat protokollieren. Zusätzliche temporäre Infrastruktur kann Kosten verursachen. Solange dies nicht funktioniert, erfolgt keine Freigabe für den echten Betrieb. Spätere Anhänge benötigen zusätzlich eine passende Dateisicherung.
| Aufgabe | Verantwortung und Rhythmus |
| --- | --- |
| Kosten und Fehlermeldungen prüfen | Interne Hauptverantwortliche; im ersten Monat wöchentlich, danach monatlich |
| Unabhängige Sicherung kontrollieren | Hauptverantwortliche oder Vertretung; wöchentlich, mit festem Termin |
| Konten und Rollen pflegen | Kontoverantwortliche; sofort bei Ein-/Austritt oder Rollenwechsel |
| Abhängigkeiten aktualisieren | Umsetzungsperson; monatlich in Test, mit anschliessenden Prüfungen |
| Wiederherstellung üben | Hauptverantwortliche und Vertretung; vor Start, danach vierteljährlich |
| Störung bearbeiten | Interne Ansprechperson sammelt Fehlerzeit, betroffene Funktion und letzte Änderung; bei Bedarf den vereinbarten IT-Partner hinzuziehen |
Planen Sie zunächst **zwei bis vier interne Stunden pro Monat** für Routinekontrollen und kleine Wartungsarbeiten ein; das ist eine Arbeitsannahme, keine enthaltene Betreuungsleistung oder garantierte Obergrenze. Grössere Änderungen und Störungen brauchen zusätzliche Zeit. Verwaltete Infrastruktur übernimmt nicht die fachliche Pflege Ihrer Anwendung.
## 12. Nächste Schritte und Freigabe
1. **Geschäftsleitung:** Standort-/Betreibervorgabe und monatliches Budget bestätigen; Hauptverantwortliche und Vertretung benennen.
2. **Planung:** Datenfelder, Statusregeln und die Liste der Pilotpersonen freigeben; fünf bereinigte Testzeilen bereitstellen.
3. **Interne Umsetzungsperson:** Schritte aus Abschnitt 7 durchführen und das Projektblatt mit tatsächlichen Adressen, Versionen und Prüfergebnissen füllen.
4. **Planung und Umsetzungsperson:** Pakete einzeln prüfen; Import, Wiederherstellung und Umschalttermin vor Betrieb gemeinsam freigeben.
5. **Vertretung:** Repository öffnen und eine kleine KI-unterstützte Änderung samt Prüfung und Veröffentlichung selbst durchführen.
Im Projektblatt werden noch die tatsächliche Firmenorganisation, Kontoverantwortlichen, Ressourcenkennungen, Subdomains, Mailkonfiguration und Sicherungsablage eingetragen. Diese Werte entstehen bei der Einrichtung. Der Bauplan legt Auswahl, Reihenfolge und Prüfkriterien fest; ein vorhandenes Konto oder erfolgreiches Prüfergebnis wird erst nach Ausführung eingetragen.
**Freigabe des Piloten:** Die Planung kann einen Auftrag bis zum Abschluss durchlaufen; Technik kann weder fremde Aufträge lesen noch unzulässige Änderungen speichern; die Datenübernahme ist abgeglichen; Sicherung und Wiederanlauf sind erprobt; die interne Weiterentwicklungsübung ist dokumentiert. Offene Kriterien bleiben in einer Aufgabenliste mit Verantwortlichen und Termin.
## Nachschlagen während der Umsetzung
| Thema | Anleitung |
| --- | --- |
| Überblick über das Gesamtsystem | [Wie die Werkzeuge zusammenspielen](https://appreif.com/wissen/werkzeuge-und-zusammenspiel/) |
| Code und Änderungen nachvollziehbar halten | [Git und Versionsverwaltung](https://appreif.com/wissen/git-und-versionsverwaltung/) |
| Repository und Arbeitsplatz verbinden | [GitHub einrichten](https://appreif.com/wissen/github-einrichten/) |
| KI-Werkzeug vorbereiten und Alternativen einordnen | [KI-Coding-Werkzeuge](https://appreif.com/wissen/ki-werkzeuge-einrichten/) |
| Rechte, Zugangsdaten und Wiederherstellung | [Daten, Zugänge und Sicherungen](https://appreif.com/wissen/daten-zugriffe-und-sicherungen/) |
| Entscheidungen und Befehle dokumentieren | [Projektwissen und Vorlagen](https://appreif.com/wissen/projektwissen-und-vorlagen/) |
| Änderungsablauf üben | [Erste Änderung mit KI](https://appreif.com/wissen/erste-aenderung-mit-ki/) |
| Kontrolliert veröffentlichen | [Prüfen, veröffentlichen und zurücksetzen](https://appreif.com/wissen/testen-veroeffentlichen-zuruecksetzen/) |