Garden Intake

Ein Skript aus der Python-Standardbibliothek. Es liest die Anfrage, gleicht sie gegen die Checkliste ab und schreibt einen Report als Markdown-Datei. Keine Installation, keine Abhängigkeiten.

Projektanfrage – Neugestaltung Privatgarten
Grundstücksgröße: ca. 650 m²
Wunsch: Neugestaltung des Gartens rund um einen
Neubau, Fertigstellung Haus voraussichtlich
Frühjahr nächstes Jahr.

Ausgangslage:
Das Grundstück ist derzeit Baustelle, Erdaushub
liegt noch teilweise auf der Fläche.
Der Garten ist nach Süden ausgerichtet, angrenzend
an ein Nachbargrundstück mit hoher Thujenhecke.
Ein alter Walnussbaum soll erhalten bleiben.

Wünsche der Familie:
- Terrasse direkt am Wohnzimmer, ca. 25-30 m²
- Rasenfläche zum Spielen für zwei Kinder
- Sichtschutz zur Straße
- Wenig Pflegeaufwand
- Wassersparend, falls möglich

Sonstiges:
Ein erstes Konzept mit grober Kostenschätzung
wäre hilfreich.

## Vorhanden

- **Grundstücksgröße/-lage** – gefunden
  (Stichwörter: m², grundstück)
- **Bestand: Vegetation/Bäume** – gefunden
  (Stichwörter: baum, hecke, walnuss)
- **Exposition/Lichtverhältnisse** – gefunden
  (Stichwörter: süden, osten, ausgerichtet)
- **Nutzungswünsche** – gefunden
  (Stichwörter: terrasse, rasen, spielen, …)
- **Budget/Kostenrahmen** – gefunden
  (Stichwörter: kostenschätzung, kosten)
- **Zeitrahmen/Termine** – gefunden
  (Stichwörter: frühjahr, fertigstellung)
- **Pflegeaufwand/Wasserbedarf** – gefunden
  (Stichwörter: pflegeaufwand, wassersparend)

## Fehlt – kritisch für die weitere Planung

- **Bodenbeschaffenheit**
- **Unterirdische Infrastruktur (Leitungen)**
- **Rechtliche Rahmenbedingungen**

# Checkliste: Kategorie -> (Keywords zur Erkennung, kritisch?)
# Die Stichwörter sind bewusst eng gehalten. Ein zu breites Wort (z. B. "garten"
# für die Grundstücksgröße) würde fast jede Anfrage als vollständig ausweisen und
# damit echte Lücken verdecken.
CHECKLIST = {
    "Grundstücksgröße/-lage": (["m²", "grundstück"], True),
    "Bestand: Vegetation/Bäume": (["baum", "bäume", "hecke", "walnuss", "gehölz"], True),
    # "erdaushub" wurde bewusst entfernt: Aushub auf der Fläche sagt nichts über
    # die Bodenbeschaffenheit aus. Der Treffer hätte eine offene Frage verdeckt.
    "Bodenbeschaffenheit": (["boden", "lehm", "sand", "durchlässig"], True),
    "Exposition/Lichtverhältnisse": (["süden", "norden", "osten", "westen", "ausgerichtet", "sonnig", "schatten"], True),
    "Unterirdische Infrastruktur (Leitungen)": (["leitung", "kanal", "wasserleitung", "stromleitung", "drainage"], True),
    "Nutzungswünsche/Funktionsprogramm": (["terrasse", "rasen", "spielen", "gemüsebeet", "sichtschutz"], False),
    "Budget/Kostenrahmen": (["budget", "kostenschätzung", "€", "euro", "kosten"], True),
    "Zeitrahmen/Termine": (["frühjahr", "termin", "fertigstellung", "woche", "monat"], False),
    "Rechtliche Rahmenbedingungen (Bebauungsplan etc.)": (["bebauungsplan", "widmung", "baubehörde", "auflage"], True),
    "Pflegeaufwand/Wasserbedarf": (["pflegeaufwand", "pflegeleicht", "wassersparend", "bewässerung"], False),
}


def check_intake(text: str) -> dict:
    text_lower = text.lower()
    results = {}
    for category, (keywords, critical) in CHECKLIST.items():
        found_terms = [kw for kw in keywords if kw in text_lower]
        results[category] = {
            "gefunden": bool(found_terms),
            "treffer": found_terms,
            "kritisch": critical,
        }
    return results

Die Kernlogik ist durch acht kleine Tests abgesichert (python3 intake_checker.py --selftest), die ohne zusätzliche Abhängigkeiten laufen. Dieselben Regeln laufen als JavaScript-Portierung im Browser – dort gegen 14 Testfälle, die Sie selbst ausführen können.

Demo öffnen →

Die Auswertung ohne Terminal. Diese Oberfläche ist gebaut und bedienbar: Das Regelwerk wurde nach JavaScript portiert und läuft im Browser des Besuchers – die gezeigten Werte werden dort berechnet, nicht eingetragen. Für dieselbe Anfrage liefert sie dasselbe Ergebnis wie das Python-Skript oben.

Demo öffnen →

Standbild der laufenden Oberfläche, Auszug aus 10 geprüften Themen. Die Spalte „Beleg im Text“ ist bewusst fester Bestandteil: Ohne sie wäre nicht prüfbar, warum ein Thema als erkannt gilt.

Die Regeln finden die Lücke. Das Sprachmodell formuliert daraus die Frage, die im Erstgespräch tatsächlich gestellt wird – und nennt dazu, aus welcher Lücke sie stammt.

Diese Stufe ist einmal echt gelaufen: Das Modell hat nicht den Anfragetext bekommen, sondern nur die Liste der offenen Themen aus der Regelprüfung. Die Antwort wurde gegen die Vorgabe validiert und gespeichert. In der Demo steht sie mit Modellname, Datum und Token-Verbrauch daneben, dazu der Prompt und die Validierung im Klartext. Live geschaltet wird sie über eine Serverless-Funktion, in der der API-Schlüssel serverseitig liegt.

Aufgezeichnete Antwort in der Demo ansehen →

Entwurf der Oberfläche, nicht bedienbar. Die Zeile „Grundlage“ unter jeder Frage ist der Kern: Man sieht, aus welcher Regel die Frage entstanden ist – nicht nur, dass ein Modell sie erzeugt hat.