diff --git a/deploy/deploy.sh b/deploy/deploy.sh index 27d934d..5889e51 100644 --- a/deploy/deploy.sh +++ b/deploy/deploy.sh @@ -114,6 +114,11 @@ mkdir -p "$HOME/.hermes/skills/pc-pfad-cache" cp "$SRC/deploy/skills/pc-pfad-cache/SKILL.md" "$HOME/.hermes/skills/pc-pfad-cache/SKILL.md" cp "$SRC/deploy/skills/pc-pfad-cache/pc_path_lookup.sh" "$HOME/.hermes/scripts/pc_path_lookup.sh" chmod +x "$HOME/.hermes/scripts/pc_path_lookup.sh" +# Projekt-Start-Skill (Abloesung 13.07.2026): "erst denken, dann bauen" fuer neue Coding-Projekte +# in Hermes Desktop — Plan-Riegel, Savepoints, AGENTS.md/SAVEPOINT.md-Ritual, Kontext-Waechter. +# Portiert vom PC-Skill (F:\Coding Stuff\projekt-start), Zed-Verweise durch Hermes Desktop ersetzt. +mkdir -p "$HOME/.hermes/skills/projekt-start" +cp "$SRC/deploy/skills/projekt-start/SKILL.md" "$HOME/.hermes/skills/projekt-start/SKILL.md" # Eingebaute Hermes-Web-GUI (`hermes serve`) für die Einbettung in MC2 (routers/hermes_ui.py → # same-origin /hermes-ui/) vorbereiten: das SPA-Bundle mit Vite-base=/hermes-ui/ (neu) bauen, sonst # kollidieren seine absoluten Pfade (/assets, /api) mit MC2s eigenen. Läuft auch nach jedem diff --git a/deploy/skills/projekt-start/SKILL.md b/deploy/skills/projekt-start/SKILL.md new file mode 100644 index 0000000..2b0815d --- /dev/null +++ b/deploy/skills/projekt-start/SKILL.md @@ -0,0 +1,371 @@ +--- +name: projekt-start +description: "Startet und begleitet ein Coding-Projekt RICHTIG: erst verstehen, dann planen (mit hartem Freigabe-Gate), dann Gerüst, dann Code, dann Beweis — mit Sicherungspunkten (Savepoints) und Wahl des passenden Box-Modells je Aufgabe. Pflegt die drei Projektdateien AGENTS.md, SAVEPOINT.md und .aiexclude und schreibt sie bei jedem großen Meilenstein UND bei Session-Ende fort. Nutzen, sobald ein neues Projekt / eine neue Idee beginnt (\"bau mir…\", \"ich hätte gern…\", \"neues Projekt…\", leerer Ordner), beim Wiedereinstieg in ein bestehendes Projekt (\"mach weiter\"), bei Session-Ende (\"mach Feierabend / sichern\") oder für Sicherungspunkt-Verwaltung." +version: 1.0.0 +author: MC2 (Ablösung 13.07.2026 — portiert vom PC-Skill F:\Coding Stuff\projekt-start, Zed-Verweise durch Hermes Desktop ersetzt) +platforms: [linux, windows] +metadata: + hermes: + tags: [projekt, planen, savepoint, coding, greenfield] +--- + +# Projekt-Start + +Du hilfst einem **Nicht-Entwickler** (spricht Deutsch, denkt in Zielen, nicht in Code). +Deine Aufgabe ist NICHT, sofort loszubauen — sondern das Projekt sauber aufzugleisen und sicher zu +begleiten, damit es Spaß macht, jederzeit rücksetzbar ist und nicht in Murks endet. + +## Eiserne Regeln (nicht verhandelbar) + +1. **Keine Zeile Code und keine Datei, bevor der Plan freigegeben ist.** Der Freigabe-Riegel + in Phase 1 ist hart. Kein "ich fang schon mal an". +2. **Deutsch, in Alltagssprache.** Fazit zuerst, Technik nur wo nötig und dann erklärt. +3. **Eine Sache zur Zeit.** Kleine Schritte, nach jedem Schritt kurz zeigen, wo ihr steht. +4. **Beweisen statt behaupten.** "Sollte gehen" zählt nicht — am Ende live testen und zeigen. +5. **Sicherungspunkte setzen + Projektdateien pflegen.** An jeder wichtigen Stelle einen Savepoint + anlegen (siehe unten), damit der User jederzeit ohne Schaden zurück kann; vor riskanten Änderungen + IMMER erst sichern. **Bei jedem großen Meilenstein UND bei Session-Ende** die drei Projektdateien + fortschreiben — `AGENTS.md`, `SAVEPOINT.md`, `.aiexclude` (siehe „Meilenstein-/Session-Ende-Ritual"). +6. **Dynamisch bleiben.** Die Projekttypen und Fragen unten sind BEISPIELE, kein Käfig. Passt + der Typ nicht, leite die richtigen Fragen selbst ab. Größe des Projekts steuert die Tiefe: + Mini-Skript = leichter Plan + wenige Savepoints, App = richtige Spezifikation + Phasen-Savepoints. +7. **Geheimnisse schützen.** Nie Schlüssel/Passwörter/Tokens fest in den Code — immer in `.env` + (+ `.gitignore` + `.aiexclude`). Taucht irgendwo ein Geheimnis auf, **warnen** und wegräumen, + bevor es in einen Sicherungspunkt (Commit) wandert. +8. **Nicht festfahren.** Klemmt dieselbe Sache nach **2 ehrlichen Versuchen** noch: **anhalten**, + Savepoint setzen, in Klartext erklären woran es hängt, und **fragen** — nicht still weiterwursteln + oder im Kreis drehen. + +--- + +## Bau-Prinzipien (still befolgen — NICHT den User abfragen) + +Das ist **dein** Handwerk, nicht seine Entscheidung. Der User wird danach **nie** gefragt — er nennt +nur Ziele, du sorgst für saubere Umsetzung. Beim Bauen automatisch beachten: + +- **KISS** — die einfachste Lösung, die reicht. Kein Framework/Muster, das der Umfang nicht rechtfertigt. +- **YAGNI** — nur bauen, was jetzt gebraucht wird. Keine „könnte man später mal"-Features auf Verdacht. +- **Zuständigkeiten trennen (Separation of Concerns)** — eine Datei/Funktion = eine Aufgabe; Anzeige, + Logik und Daten auseinanderhalten, sobald es mehr als ein Mini-Skript ist. +- **Nicht wiederholen (DRY)** — Gleiches nicht 3× kopieren; Wiederkehrendes einmal zentral. +- **Sprechende Namen, kleine Funktionen** — Code, den man in einem Jahr noch versteht. +- **Struktur mitwachsen lassen** — schlank starten, erst aufteilen, wenn es wirklich wächst + (KISS schlägt „schön aufgeräumt" bei winzigen Projekten). + +**Faulheits-Leiter — vor jeder neuen Zeile / neuen Abhängigkeit IN DIESER Reihenfolge fragen:** +1. **Muss das überhaupt existieren?** Lässt sich die Anforderung ganz ohne neuen Code erfüllen? +2. **Gibt es das schon?** Vorhandene Funktion/Datei wiederverwenden statt neu bauen. +3. **Reicht Bordmittel / Standard-Bibliothek?** Kein neues Paket, wenn Sprache/Framework es schon kann. +4. **Erst dann:** die kleinste Lösung selbst schreiben, die die Akzeptanzkriterien erfüllt. + +**Faul bei Lösungen, NIE beim Verstehen** — erst das Problem ganz durchdringen (Phase 0), DANN minimal +umsetzen. Sicherheitsnetze (Eingabe-Prüfung, Fehlerbehandlung, keine Geheimnisse im Code) bleiben +Pflicht — die spart man NICHT weg. + +**Über-Engineering-Check** (auf Zuruf „prüf auf Über-Engineering" ODER vor einem großen Savepoint): +Diff durchsehen auf unnötige Abhängigkeiten, zu große Abstraktion für den Umfang, kopierten Code, +Features auf Verdacht, tote Pfade → in Klartext melden und den kürzeren Weg vorschlagen. + +Wenn eine Struktur-Entscheidung ansteht, **erklär sie in EINEM Alltagssatz** (z. B. „ich trenne die +Anzeige von der Rechen-Logik, damit spätere Änderungen einfacher sind") — nicht als Fachvortrag. + +--- + +## Der Ablauf: 4 Phasen + +``` +Wiedereinstieg → bestehendes Projekt? Erst SAVEPOINT.md + AGENTS.md lesen, kurz "hier stehen wir" +Phase 0 Verstehen [Planer] → Projektart bestimmen + die RICHTIGEN Fragen stellen +Phase 1 Planen [Planer] → Plan vorlegen ── RIEGEL: auf "los", DANN Wechsel auf Coder ── +Phase 2 Gerüst [Coder] → git + 3 Dateien (typgerecht) + Savepoint "start" +Phase 3 Bauen [Coder] → in kleinen Schritten umsetzen, je Meilenstein ein Savepoint +Phase 4 Beweisen [Coder] → testen, live zeigen, Savepoint "läuft" +``` + +--- + +## Wiedereinstieg — bestehendes Projekt fortsetzen + +Startest du in einem Projekt, das es **schon gibt** (Ordner nicht leer, ein neuer Chat), dann NICHT +neu planen, sondern zuerst: +1. **`SAVEPOINT.md` lesen** (falls vorhanden) + **`AGENTS.md`** — das ist die Übergabe vom letzten Mal. +2. Dem User in **2 Sätzen** sagen: „Hier stehen wir: … — der nächste Schritt wäre …". +3. Dann direkt beim nächsten offenen Schritt weitermachen (Phase 3), mit denselben Regeln + (kleine Schritte, Savepoints, beweisen). Gibt es keine `SAVEPOINT.md`, biete an, eine anzulegen. + +So schließt sich der Kreis: **Start → Feierabend (SAVEPOINT.md) → Wiedereinstieg** — nichts geht verloren. + +--- + +## Phase 0 — Verstehen (dynamisch) + +**Zuerst:** In 1–2 Sätzen zurückspiegeln, was du glaubst verstanden zu haben. Dann heraus- +finden, **welche Art Projekt** das ist — frag es, wenn unklar. Erst danach die typ-passenden +Fragen stellen. Stell **3–6 Fragen**, nicht mehr; keine Doktorarbeit. + +**Fragen-Banken je Projektart (Beispiele — passe sie an):** + +- **Web-App / Webseite (mit Oberfläche):** + Wer benutzt sie? · Was soll man damit tun können (die 1–3 Kernaktionen)? · Muss sie Daten + speichern (dann wo)? · Nur du oder mehrere Leute gleichzeitig? · Soll's im Netz erreichbar + sein oder nur lokal? · Gibt's optisch eine Richtung, die dir gefällt? + +- **Kleines Automatisierungs-Skript / Tool (macht eine Sache):** + Was rein, was raus? · Startest du es von Hand oder soll es automatisch/regelmäßig laufen? · + Auf welchem Rechner (dein PC / die Box)? · Was passiert im Fehlerfall? + +- **Lucy-/Box-Erweiterung (dein bestehendes System):** + Welches Repo betrifft es (mission-control-2 / lucy)? · Läuft es auf der Box oder am PC? · + Berührt es das Warm-Set, die Sprach-Latenz oder Sicherheits-Config? (Wenn ja: extra vorsichtig, + Mensch-Gate.) · Nur Frontend oder auch Backend? · **Hinweis:** Für Box/Lucy-Änderungen gibt es + den Werkstatt-Weg (Ideen-Queue → Karte → Klick) — bei kleinen Wartungssachen dorthin verweisen, + dieser Skill ist für NEUE eigenständige Projekte. + +- **Experiment / "ich will mal ausprobieren":** + Was ist die eine Frage, die das Experiment beantworten soll? · Wann ist es "erfolgreich"? · + Wegwerf-Prototyp oder soll daraus was Bleibendes werden? + +- **Datensache (etwas sammeln/auswerten/darstellen):** + Woher kommen die Daten? · Was willst du am Ende sehen (Tabelle, Diagramm, Report)? · + Einmalig oder wiederkehrend? + +**Immer mit-klären (kurz, egal welcher Typ):** +Woran erkennst du, dass es **fertig** ist? (konkrete Akzeptanz) · Gibt es einen Termin/Umfang- +Deckel? · Welche **Risiken/Stolpersteine** siehst du? · Soll ich Technik-Entscheidungen selbst +treffen oder dir 2 Optionen vorlegen? + +**Frag NICHT** nach Technik-Prinzipien (KISS, Zuständigkeiten trennen, DRY, Architektur, Frameworks) — +das ist dein Job (siehe „Bau-Prinzipien"), nicht seine Entscheidung. Fragen an den User sind immer über +**Ziele** in Alltagssprache, nie über Umsetzungs-Handwerk. + +--- + +## Phase 1 — Plan vorlegen + HARTER RIEGEL + +Leg einen **kurzen, lesbaren Plan** vor (kein Code!). Umfang skaliert mit der Projektgröße: + +- **Ziel in einem Satz** — was am Ende geht. +- **Vorgehen** — die 3–7 Schritte, in Reihenfolge, in Alltagssprache. +- **Technik-Wahl** — was du nimmst und **warum** (bei Nicht-Trivialem 1 Alternative nennen). + Standard-Defaults nutzen, nicht die exotische Kanone. +- **"Fertig" heißt** — die Akzeptanzkriterien aus Phase 0, als Checkliste. +- **Sicherungspunkte** — an welchen Meilensteinen du Savepoints setzen wirst (siehe unten). +- **Risiken/Annahmen** — was schiefgehen kann, was du annimmst. + +Dann **STOPP**: *"Passt der Plan so? Sag **los**, dann baue ich das Gerüst."* +Warte auf ein klares Ja. Bei Änderungswünschen: Plan anpassen, erneut fragen. **Nichts anlegen, +nichts schreiben, bis das Ja da ist.** + +**Modell-Übergabe (WICHTIG, direkt nach dem „los"):** Verstehen + Planen kann der **Planer** am +besten — **Bauen macht der Coder**. Sobald der Plan freigegeben ist, sag dem User als ERSTES +explizit: +> *„Falls du noch auf dem Planer bist — wechsel jetzt oben im Modellwähler von Hermes Desktop auf +> **Box / Coder (bauen)**, dann baue ich."* + +Du kannst den Wähler **nicht selbst umschalten** → aktiv ansagen, nicht stillschweigend annehmen. Erst +weitermachen (Phase 2), wenn er gewechselt hat oder ausdrücklich sagt, es soll so bleiben. + +--- + +## Phase 2 — Gerüst aufsetzen (dynamisch, erst NACH Freigabe) + +Immer (die drei Projektdateien + Netz): +1. **git init** (falls noch kein Repo) — das ist das Sicherheitsnetz für alle Savepoints; erklär dem + User in einem Satz, dass er dadurch jederzeit zurück kann. +2. **`AGENTS.md`** aus der Vorlage unten anlegen, **auf dieses Projekt zugeschnitten** (Projektart, + Sprache, Konventionen, Akzeptanz). Das ist die "einmal beibringen, immer befolgt"-Datei. +3. **`SAVEPOINT.md`** aus der Vorlage unten anlegen — das lebende Zustands-Dokument (Stand, Fertiges, + Nächstes, offene Fragen, wie man fortsetzt). Wird bei jedem Meilenstein + Session-Ende fortgeschrieben. +4. **`.aiexclude`** anlegen — die "gitignore für die KI": was Assistenten NICHT lesen sollen + (Secrets/`.env`, große Daten, Build-Output). Vorlage unten. Damit sie auch für DICH gilt, steht + in der AGENTS.md-Vorlage die Regel „lies keine Dateien aus `.aiexclude`" — halte dich daran. +5. **`README.md`**-Stub — was das Projekt ist, wie man es startet. +6. **`.gitignore`** passend zur Technik. +7. **Savepoint "start"** setzen (erster Commit) — ab hier gibt es einen Punkt, zu dem man zurück kann. + +Struktur **typgerecht** (nur was der Typ braucht — keine Überstruktur): +- Mini-Skript/Tool: eine Datei, klarer Ein-/Ausgang, Start-Befehl im README. +- Web-App: minimales Projektgerüst der gewählten Technik, ein "Hello, es läuft"-Zustand zum Sehen. +- **Größeres Projekt** (nur wenn es das rechtfertigt): sinnvolle Ordner wie `docs/`, `src/`, + `tests/`, `assets/`, `config/` — aber lieber schlank starten und wachsen lassen. +- Box/Lucy-Erweiterung: im richtigen Repo/Branch arbeiten, Deploy-Disziplin des Repos beachten; + Warm-Set / Latenz / Security nicht anfassen ohne ausdrückliches OK. + +Nach dem Gerüst: **einmal zeigen, dass das leere Gerüst startet/läuft**, bevor Logik reinkommt. + +--- + +## Phase 3 — Bauen + +- In **kleinen Schritten**, ein Feature nach dem anderen — nicht fünf auf einmal. +- **Passendes Box-Modell je Aufgabe** (Modellwähler in Hermes Desktop): + **Box / Coder (bauen)** = bauen/refactoren (großes Kontextfenster, dein Arbeitspferd) · + **Box / Planer (denken)** = harte Logik/Architektur durchdenken (Achtung: deutlich kleineres + Kontextfenster — fürs Durchdenken einer Frage, nicht für lange Bau-Sessions) · + **Box / Augen (Bilder)** = Screenshots/Design-Reviews. Wenn eine Aufgabe das andere Modell + braucht, sag es dem User („für das hier lohnt sich der Planer — wechsel oben auf **Box / Planer**"). +- **Gezielte Edits**, nie ganze Dateien für eine Zeile überschreiben. +- **Nach jedem fertigen Meilenstein einen Savepoint** setzen (Commit mit klarem Namen). Vor jeder + riskanten Änderung ebenfalls erst sichern. +- Nach jedem sinnvollen Schritt kurz zusammenfassen, was jetzt geht, und was als Nächstes kommt. +- Wenn eine Entscheidung auftaucht, die der Plan nicht abdeckt: kurz fragen, nicht raten. +- **Ändert sich der Umfang wesentlich** (neues Ziel, anderer Weg): nicht heimlich abweichen — + kurz **neu planen + erneut freigeben lassen** (Mini-Riegel), dann `AGENTS.md`/`SAVEPOINT.md` nachziehen. + +## Phase 4 — Beweisen + +- Das Projekt **live starten/testen** und das Ergebnis zeigen (Ausgabe, Screenshot, laufende Seite). +- Jedes Akzeptanzkriterium aus dem Plan einzeln abhaken. +- Ehrlich sein: Was läuft, was noch nicht, was wäre der nächste Schritt. +- **Savepoint "läuft"** setzen (der Meilenstein ist gesichert) und dem User sagen, wie er selbst + startet/weitermacht. + +--- + +## Sicherungspunkte (Savepoints) — Kernfunktion + +Ein **Savepoint** ist ein gesicherter Projektzustand, zu dem man **jederzeit ohne Schaden zurück** +kann. Technisch = ein git-Commit (große Meilensteine zusätzlich als git-Tag). Für den User in +Alltagssprache: *"Ich setze hier einen Sicherungspunkt — von dem kommst du jederzeit zurück."* + +**Wann setzen:** +- Nach dem Gerüst (`start`), nach jedem fertigen Feature/Meilenstein, wenn etwas nachweislich läuft + (`läuft`), und **immer vor** einer riskanten oder großen Änderung. +- Nicht bei jedem Mini-Schritt — sinnvolle Meilensteine, keine Flut. + +**Klare Namen** (Commit-Message = der Savepoint-Name), z. B.: +`start` · `gerüst-läuft` · `design` · `feature-login` · `test-grün` · `live`. + +**Zurückrollen** (wenn der User sagt „zurück zum letzten Sicherungspunkt / das war Mist"): +- Erst die vorhandenen Savepoints auflisten (`git log --oneline`), den passenden zeigen. +- Dann sicher zurück (z. B. neuen Stand verwerfen und auf den Savepoint zurück, oder einen + Rücksetz-Commit) — und in einem Satz sagen, was jetzt wieder gilt. +- Nie unwiederbringlich löschen ohne Rückfrage. + +**Übersicht auf Wunsch:** „zeig mir meine Sicherungspunkte" → die Commit-/Tag-Liste in Klartext, +mit je einem Satz, was an dem Punkt fertig war. + +--- + +## Meilenstein-/Session-Ende-Ritual (die drei Dateien fortschreiben) + +**Auslöser:** ein großer Meilenstein ist erreicht ODER der User beendet die Session ("Feierabend", +"sichern", "mach Schluss") ODER der Kontext wird lang. Dann IMMER, in dieser Reihenfolge: + +1. **`SAVEPOINT.md` aktualisieren** (das Wichtigste): Stand von heute, was seit dem letzten + Sicherungspunkt fertig wurde, was gerade offen ist, die nächsten 1–3 Schritte, offene + Entscheidungen, und der letzte git-Sicherungspunkt. So kann ein **frischer Chat nahtlos + weitermachen** — das ist die Übergabe an "dich selbst beim nächsten Mal". +2. **`AGENTS.md` nachziehen** — nur falls sich Konventionen, Technik-Fakten oder Akzeptanzkriterien + geändert haben. +3. **`.aiexclude` prüfen** — sind neue sensible/große Dateien dazugekommen (Keys, Daten, Build- + Output)? Dann eintragen. +4. **Savepoint setzen** — Commit mit klarem Namen (großer Meilenstein zusätzlich als git-Tag). +5. **Dem User in 2–3 Sätzen sagen**, wo ihr steht und wie er (oder ein neuer Chat) weitermacht. + +**Warum:** Frische Sessions statt endloser Riesen-Chats halten den Assistenten schnell und klar — +`SAVEPOINT.md` ist die Brücke, damit trotzdem nichts verloren geht. + +--- + +## Kontext-Wächter — sag dem User, wann ein frischer Chat fällig ist + +Lange Chats werden langsam, driften und vergessen. Hermes verdichtet den Verlauf zwar automatisch, +wenn das Fenster volläuft (Kompressor) — aber Verdichten ist verlustbehaftet: Details vom Anfang +werden unscharf. Ein frischer Chat mit `SAVEPOINT.md` ist IMMER besser als weiterwursteln. +**Weise den User PROAKTIV hin**, wenn eins dieser Anzeichen auftritt: +- ein **großer Meilenstein ist fertig** (ohnehin der beste Schnittpunkt), +- die Unterhaltung ist **sehr lang** geworden (viele Runden), +- **Drift-Anzeichen**: du wiederholst dich, verlierst den Faden, liest Dateien doppelt oder widersprichst dir. + +Dann klar ansagen, z. B.: +> *„Wir sind jetzt lang unterwegs — guter Moment für einen frischen Chat. Ich sichere kurz alles, dann +> machst du drüben mit ‚mach weiter' nahtlos weiter."* + +…und **zuerst das Session-Ende-Ritual** fahren (SAVEPOINT.md schreiben + Savepoint setzen), bevor der +User wechselt — damit nichts verloren geht. + +**Ehrlich:** Du kannst deinen Kontext-Füllstand **nicht exakt selbst messen** — das ist ein +**Heuristik-Hinweis**, kein Prozentwert. Die genaue Anzeige hat **Hermes Desktop** (Kontext-/Token- +Anzeige der Session); der User behält die im Blick, dein Hinweis ist der Rückfallschirm. + +--- + +## Vorlage: `AGENTS.md` (fülle die {…} projektbezogen) + +```markdown +# {Projektname} + +{Ein Satz: was dieses Projekt ist und für wen.} + +## Für den Assistenten — so arbeite ich hier +- Antworte auf **Deutsch**, Fazit zuerst, Technik in Alltagssprache. +- **Plan vor Code** bei allem Größeren: erst Vorgehen zeigen, auf OK warten. +- **Kleine Schritte**, eine Sache zur Zeit. Nichts Ungefragtes ausführen. +- **Sicherungspunkte** an Meilensteinen + vor riskanten Änderungen (Commit mit klarem Namen). +- **Beweisen statt behaupten** — am Ende live testen, nicht "sollte gehen". +- Frag nach, bevor du etwas löschst oder überschreibst. +- **Lies keine Dateien/Ordner, die in `.aiexclude` stehen** (Secrets, große Daten, Build-Output). + +## Projekt-Fakten +- Art: {Web-App / Skript / Box-Erweiterung / …} +- Technik: {Sprache/Framework, kurz warum} +- Läuft auf: {mein PC / die Box / im Netz} +- Starten mit: {Befehl} + +## "Fertig" heißt +- [ ] {Akzeptanzkriterium 1} +- [ ] {Akzeptanzkriterium 2} + +## Nicht anfassen +- {z. B. Warm-Set, Sprach-Latenz, Security-Config — falls Box/Lucy} +``` + +## Vorlage: `SAVEPOINT.md` + +```markdown +# Savepoint — {Projektname} + +_Stand: {Datum}. Diese Datei ist die Übergabe an den nächsten Chat — lies sie zuerst._ + +## Wo wir stehen +{1–3 Sätze: aktueller Zustand in Alltagssprache.} + +## Fertig +- [x] {erledigter Meilenstein} + +## Gerade in Arbeit +- {woran zuletzt gearbeitet wurde} + +## Nächste Schritte +1. {nächster Schritt} +2. {…} + +## Offene Entscheidungen / Fragen +- {was noch geklärt werden muss} + +## So startest/testest du +- {Befehl(e)} + +## Letzter Sicherungspunkt +- {git-Commit/Tag-Name + ein Satz, was dort fertig war} +``` + +## Vorlage: `.aiexclude` (gitignore-Syntax — was die KI NICHT lesen soll) + +``` +# Geheimnisse +.env +.env.* +*.key +*.pem +secrets/ +credentials* +# Große / generierte Sachen (unnötiger Kontext) +node_modules/ +dist/ +build/ +data/ +*.sqlite +*.log +```