diff --git a/Zukunft-f%C3%BCr-das-Projekt.md b/Zukunft-f%C3%BCr-das-Projekt.md
new file mode 100644
index 0000000..5a6e99a
--- /dev/null
+++ b/Zukunft-f%C3%BCr-das-Projekt.md
@@ -0,0 +1,43 @@
+Um aus dem BMC TPL Code All-Around Plugin ein echtes, professionelles IDE-Tool zu machen, ist die zukünftige Entwicklung in drei klare Phasen unterteilt.
+
+Bevor neue Features implementiert werden, fokussiert sich das Projekt zunächst auf eine saubere, wartbare Architektur.
+
+🛠️ Phase 1: Architektur & Refactoring (Aufräumen)
+
+Die aktuelle Codebasis muss strukturiert werden, um zukünftiges Wachstum ohne "Spaghetti-Code" zu ermöglichen.
+
+[ ] Ordnerstruktur etablieren: Zerlegen der Hauptdateien in logische Module (z. B. src/providers/, src/linter/, src/utils/, src/core/).
+
+[ ] Linter modularisieren: Die monolithische validateTplDocument-Funktion in eigene, testbare Teilfunktionen splitten (z. B. checkSyntax.ts, checkBlocks.ts, checkAssignments.ts).
+
+[ ] Daten-Trennung: Auslagern der statischen Snippets und BMC-Funktionen in eigene Konfigurations- oder Daten-Ordner.
+
+[ ] Kontext-Kategorisierung: Snippets und Hilfsfunktionen nach Gültigkeitsbereich trennen (Allgemein, Pattern, Syncmapping).
+
+🧠 Phase 2: Kontextsensitive Intelligenz (UX-Verbesserung)
+
+Die Autovervollständigung und Hover-Informationen sollen verstehen, wo sich der Nutzer gerade im Code befindet.
+
+[ ] Kontext-Awareness: Die Autovervollständigung bietet nur noch logisch sinnvolle Snippets an (z. B. kein metadata-Vorschlag mitten in einem body-Block, kein tpl_skeleton, wenn bereits eine Modul-Definition existiert).
+
+[ ] Hover-Kategorisierung: Optische Unterscheidung im Tooltip zwischen lokalen (define), extern importierten und nativen BMC-Funktionen (z. B. durch kleine Badges oder Labels im Markdown).
+
+[ ] Smart Semicolons: Snippets für Funktionsaufrufe generieren das abschließende Semikolon automatisch mit, falls der Kontext dies erfordert.
+
+[ ] Dynamische Trigger: Autovervollständigung bei spezifischen Blöcken wie Triggern und Bedingungen optimieren.
+
+🔍 Phase 3: Deep Code Analysis (Smarter Linter)
+
+Erweiterung des Linters von einem reinen Syntax-Checker zu einem intelligenten Code-Reviewer (Refactoring-Hilfen).
+
+[ ] DRY-Erkennung (Don't Repeat Yourself): Ein Algorithmus, der identische oder fast identische Code-Blöcke erkennt und als "Info" markiert (Vorschlag: "Dieser Code wiederholt sich, erwäge eine define-Funktion").
+
+[ ] Log-Konsolidierung: Erkennen von mehreren aufeinanderfolgenden log.*-Zeilen des gleichen Typs mit einem Quick Fix, um diese zu einer Zeile/Liste zusammenzufassen.
+
+[ ] Feinmaschige Syntax-Checks:
+
+[ ] Prüfung auf fehlende Kommas in Listen und Tabellen.
+
+[ ] Erkennung fehlender Keywords wie then nach einem if.
+
+[ ] Validierung von Operator-Kombinationen.
\ No newline at end of file