fix(gtm): Ultimate prompt syntax robustness, add versions to logs, update migration docs

BUILDER_APPS_MIGRATION.md

@@ -60,13 +60,7 @@ Multi-Line Prompts können in Docker-Umgebungen zu **sehr hartnäckigen Syntaxfe
     2.  **Nutze die `.format()` Methode** zur Variablen-Injektion. Dies trennt die String-Definition komplett von der Variablen-Interpolation und ist die robusteste Methode.
 
     ```python
-    # Schlecht (fehleranfällig, auch wenn es manchmal funktioniert):
-    # prompt = f"""
-    # 1. Mache dies: {var1}
-    # 2. Mache das: {var2}
-    # """
-    
-    # Gut (maximal robust):
+    # Beispiel: So ist es maximal robust (bevorzugte Methode)
     prompt_template = """
     1) Mache dies: {variable_1}
     2) Mache das: {variable_2}
@@ -76,6 +70,10 @@ Multi-Line Prompts können in Docker-Umgebungen zu **sehr hartnäckigen Syntaxfe
     full_prompt = sys_instr + "\n\n" + prompt
     ```
 
+*   **Versionierung für Debugging:** Um sicherzustellen, dass die korrekte Version des Codes läuft, füge Versionsnummern in die Start-Logs des Node.js Servers (`server.cjs`) und des Python Orchestrators (`gtm_architect_orchestrator.py`) ein.
+    *   `server.cjs`: `console.log(`... (Version: ${VERSION})`);`
+    *   `gtm_architect_orchestrator.py`: `print(f"DEBUG: Orchestrator v{__version__} loaded ...")`
+
 *   **Signaturen prüfen:** Shared Libraries (`helpers.py`) haben oft ältere Signaturen. Immer die tatsächliche Definition prüfen!
     *   Beispiel: `call_openai_chat` unterstützt oft kein `system_message` Argument. Stattdessen Prompt manuell zusammenbauen (`sys_instr + "\n\n" + prompt`).