# Nachbau-Dokumentation Batch b_45

Bilder: 20 | Substanz: 18 | NOISE: 2

---

## Gruppe A — Google Actions Center: Availability Checker Dashboard
**Beteiligte Dateien:** `Bildschirmfoto 2026-06-17 um 01.42.31.png`

### Screen/Feature-Name
**Availability Checker** — Unterseite des Dashboards im Google Actions Center (GAC)

**URL:** `actionscenter.google.com/dashboards/availabilitychecker?a=44061221&activeTab=feeds&services_page=20&env=production&pli=1&returnNav=resolved`

**Datum/Uhrzeit:** 2026-06-17, 01:42 Uhr

### Navigation/Struktur
Linke Sidebar (Google Actions Center):
- Home
- Configuration
- Feeds
- Inventory (expandierbar)
- **Dashboards** (aktiv, expandiert):
  - Booking Server
  - Real Time Updates
  - Inventory Summary
  - Inventory Details
  - **Availability Checker** (aktiv, blau hervorgehoben)
  - Onboarding Health
  - Live Merchants
- Help & Support
  - Resources
  - Cases
- Terms of Service
- Send Feedback (Footer, links unten)

**Tabs oben:** `Production` (aktiv, grüner Haken) | `Sandbox`

Oben rechts: Suchfeld „Search for features and documentation", X-Button; Nutzer-Avatar (KADiCon), Name „KADiCon"

### Hauptinhalt — Tabelle (oberer Bereich, sichtbarer Ausschnitt)
Tabelle mit Feeds/Services (Spaltenheader nicht vollständig sichtbar, aber Spalten erkennbar: ID/Hash, zwei Zahlenspalten, eine Wert-Spalte mit 0.00):

| Zeile (Datum + Hash, unklar) | Wert 1 | Wert 2 | Wert 3 |
|---|---|---|---|
| 20003224 + Hash | 0 | 6434 | 0.00 |
| 20003224 + Hash | 0 | 7609 | 0.00 |
| 20003224 + Hash | 0 | 5546 | 0.00 |
| 20003224 + Hash | 0 | 7060 | 0.00 |
| 20003224 + Hash | 0 | 7146 | 0.00 |
| 20003224 + Hash | 0 | 2656 | 0.00 |
| 20003224 + Hash | 0 | 1135 | 0.00 |
| 20003224 + Hash | 0 | 6376 | 0.00 |

Paginierung: `services_page=20` in der URL.

### Chart 1: „Request Rate by Source and Day"
- **Typ:** Liniendiagramm (mehrzeilig)
- **X-Achse:** Datum, sichtbar: 2026-06-09, 2026-06-11, 2026-06-12, 2026-06-13, 2026-06-14, 2026-06-15, 2026-06-16
- **Y-Achse:** Zahlenwerte; Ticks bei ca. 60000, 120000, 180000, 240000
- **Legende (3 Linien):**
  - `Rpc Count User` (blaue Linie, gestrichelt)
  - `Rpc Count Slot Display` (graue Linie)
  - `Rpc Count Availability Checker` (weitere Linie)
- Werte: Peak ca. 200000+ bei Rpc Count User, andere Linien deutlich niedriger

### Chart 2: „Error Rate by Hour"
- **Typ:** Liniendiagramm
- **X-Achse:** Datum + Uhrzeit (Fr. Jun 13, Sa. Jun 14, So. Jun 16 sichtbar)
- **Y-Achse:** Prozent: 0.00%, 33.00%, 66.00%, 100.00%
- **Legende (2 Linien):**
  - `Unavailable Rate Total` (rote Linie)
  - `RPC Failure Rate Total` (weitere Linie)
- Auffälligkeit: Peak der roten Linie bei Fr. Jun 13 fast auf 100% (ca. 160%+ = Skalierung unklar), dann abfallend; weiterer Peak bei Sa. Jun 14

---

## Gruppe B — Google Actions Center: Onboarding Health (4 Frames)
**Beteiligte Dateien:** `Bildschirmfoto 2026-06-17 um 01.42.46.png`, `01.42.56.png`, `01.44.03.png`, `01.44.26.png`, `01.44.46.png`

### Screen/Feature-Name
**Onboarding Health** — Unterseite im GAC-Dashboard

**URL:** `actionscenter.google.com/dashboards/onboardinghealth?a=44061221&activeTab=feeds&services_page=20&env=production&pli=1&returnNav=resolved`

### Tabs
`Production` (aktiv) | `Sandbox`

### Seite 1 — Frame 01.42.46.png: Oberer Bereich (Merchant/Service/Availability/Food Data Feed-Übersicht + Onboarding-Checks)

**Infobannel oben (gelb):** „Previous changes to your contract with Google. In early 2024 Google sent you a notice waiving so-called 'Most Favoured Nation' clauses in your contract with Google Maps. Click Learn More for details." — Buttons: `Dismiss` | `Learn More`

**Button:** `Add filter` (links oben im Content-Bereich)

#### Feed-Status-Karten (4 Karten horizontal nebeneinander):

**Karte 1: Merchant Feed**
- Status-Balken mit 5 Spalten (Spaltenbezeichnungen unklar, Schema: Deals/nicht session + Google-link time + Feed format/content + Feed processing status + Merchant-mode)
- Zeile: Grüner Text (oben) + roter Text „FAIL": „Congratulations! You have published qualifying merchant feeds for the last 7 days. Make sure to keep it up."
- Weitere Zeile „FAIL"

**Karte 2: Service Feed**
- Ähnliche Spalten-Struktur
- Status: „Congratulations! You have published qualifying service feeds for the last 7 days. Make sure to keep it up." (grün)
- FAIL-Zelle(n) vorhanden

**Karte 3: Availability Feed**
- Spalten: „Feed has no feeds", „Feed has enough feeds", „Content processing status", „Consistent uploads"
- Status: „FAIL" (rot, links oben), Text: „Congratulations! We have checked your feed availability feeds for the last 7 days. Make sure to keep it up."
- FAIL in erster Spalte

**Karte 4: Food Data Quality** (nur Titel sichtbar)
- Drei Spalten: „Missing Service Seam", „Missing Price Seam", „Missing Availability Seam"
- Wert: „N/A" (grau)

#### Onboarding-Checks (6 Prüfblöcke horizontal):

**Block 1: Booking Server: Batch Availability Lookup, Check Availability &...**
- Status: FAIL (rot)
- Text: „It looks like when you sent 20 requests need to have a success rate of at least 90%. Your success rate is 100% and you have made 1 request."

**Block 2: Booking Server: Create Booking / Create Order**
- Status: FAIL (rot)
- Text: „It looks like when you sent 1 you need 1 request to have a success rate of at least 90%. Your success rate is 41% and you have made 4 requests."

**Block 3: Booking Server: UpdateBooking**
- Status: FAIL (rot)
- Text (ähnlich): „It looks like when you sent 5 requests need to have a success rate of at least 90%..."

**Block 4: Inventory Update Score**
- Status: FAIL (rot)
- Text: „It looks like when you sent 1 request need to have a success rate of at least 90%..."

**Block 5: Booking Notification / Order Notification Score**
- Status: FAIL (rot)
- Text: ähnliche Struktur

---

### Seite 2 — Frame 01.42.56.png: Weitere Onboarding-Checks (Scroll-Fortsetzung)

**Availability Feed-Karte (weiter unten):**
- Spalten: Feed has no feeds / Feed has enough feeds / Content processing status / Consistent uploads
- Status: „FAIL" (rot)
- Rechts daneben Hinweis-Panel: Aufzählungsliste, u.a.:
  - „Being marked (PROCESS_INCOMPLETE) for the last three days from the current feed person (unklar)"
  - „Having no validation errors or warnings"
  - „Having the correct schema of feeds that have fewer [...]"
  - „The content in your uploaded content matches it that you have made consistent uploads"

**Food Data Quality:**
- Missing Service Seam | Missing Price Seam | Missing Availability Seam (alle N/A)
- Hinweis-Panel rechts: Richtlinien zum Feed-Format

**Booking Server: Batch Availability Lookup, Check Availability &...**
- FAIL (rot), mit Punktliste zu Anforderungen

**Booking Server: Create Booking / Create Order**
- FAIL (rot)

**UpdateBooking / Inventory Update Score / Booking Notification:**
- FAIL (rot)
- Text zum „Inventory Update Score":
  - „In order to pass the Booking server test, your type of update frequency system and booking notification and tracking confirmation must meet the following requirements:"
  - Inventory updates: Start from [...], at least 10 requests per type and at least 3 out of 5 must hit 100%
  - Routing: [...] booking update must be at least 5 attempts, Of the most recent 5 attempts, 75% of them must check to 100%

---

### Seite 3 — Frame 01.44.03.png: E2E Onboarding Plan

**Feature-Name:** „E2E Onboarding Plan" — 42% complete (Fortschrittsbalken oben)

**URL:** `actionscenter.google.com/home?a=44061221&activeTab=feeds&services_page=20&env=production&pli=1&returnNav=resolved`

**Button oben rechts:** „Fetch latest data"
**Info-Banner (blau):** „Data shown may be up to a couple of hours stale."

#### Checkliste (8 Einträge):

| Nr. | Schritt | Status | Fortschritts-Punkte | Aktion |
|---|---|---|---|---|
| 1 | Setup | Complete | ●●●● (grün, 4 Punkte) | View |
| 2 | Feeds ready in Sandbox | Complete | ●●●● (grün, 4 Punkte) | View |
| 3 | Booking server is ready in Sandbox | Needs attention ⚠ | ●●● (orange, 3 Punkte) | View |
| 4 | Real-time updates are ready in Sandbox | Needs attention ⚠ | ● (1 Punkt) | View |
| 5 | Feeds ready in Production | Complete | ●●●● (grün, 4 Punkte) | View |
| 6 | Booking server is ready in Production | Needs attention ⚠ | ●●● (3 Punkte) | View |
| 7 | Real-time updates are ready in Production | Needs attention ⚠ | ● (1 Punkt) | View |
| 8 | Integration Testing and Google Review | Needs attention ⚠ | ● (1 Punkt) | View |

Jede Zeile hat:
- Nummerierter Kreis (grün = complete, orange/rot = needs attention)
- Titel des Schritts
- Status-Text: „Complete" oder „Needs attention" mit Warn-Dreieck
- Fortschritts-Punkte (●-Reihe)
- „View"-Link (blau, rechts)

---

### Seite 4 — Frame 01.44.26.png: Booking Server — Sandbox-Details (Expand)

Aufgeklappt: Schritt 3 „Booking server is ready in Sandbox" — Status: Needs attention ⚠

**Linke Seite — Beschreibungstext:**
„The [Implement the Booking Server Guide] gives an overview of the process. For your integration you will only be implementing the standard implementation and you can safely ignore all references to the other implementations."

**Rechte Seite — Sub-Checks (3 Karten):**

**BatchAvailabilityLookup ready in Sandbox**
- Status: ⚠ 1 unresolved errors
- Bullet: „You sent 1 out of 20 required requests in the past 14 days"
- Link: „View issue details"

**CreateBooking ready in Sandbox**
- Status: ⚠ 1 unresolved errors
- Bullet: „You only sent 0 out of 10 required requests in the past 14 days"
- Link: „View issue details"

**UpdateBooking ready in Sandbox**
- Status: ⚠ 1 unresolved errors
- Bullet: „You only sent 0 out of 10 required requests in the past 14 days"
- Link: „View issue details"

**Darunter — Schritt 4: Real-time updates are ready in Sandbox** (auch aufgeklappt):
Text: „Details can be found in the [Required Real-time update APIs] guide. You will call this endpoint when a booking made through Reserve with Google is changed in your system. Please note: we require you to only implement a notification real-time update. This is the only real-time update you will implement, and you do not need to implement any other real-time update endpoints."

**Sub-Check:**
**Booking RTU ready in Sandbox**
- Status: ⚠ 1 unresolved errors
- Bullet: „You only sent 0 out of 10 required requests in the past 14 days"

---

### Seite 5 — Frame 01.44.46.png: Production-Details + Integration Testing

**Schritt 5: Feeds ready in Production** — Complete (kein Expand-Inhalt sichtbar, nur Statuszeile)

**Schritt 6: Booking server is ready in Production** — Needs attention ⚠ (aufgeklappt)
Linker Text: „Receive and respond without errors to at least 90% of the recent BatchAvailabilityLookup, CreateBooking and UpdateBooking requests"

Sub-Checks rechts:
- **BatchAvailabilityLookup ready in Production:** ✓ Complete
- **CreateBooking ready in Production:** ⚠ 1 unresolved errors — „You only sent 2 out of 3 required requests in the past 14 days"
- **UpdateBooking ready in Production:** ⚠ 1 unresolved errors — „You only sent 0 out of 3 required requests in the past 14 days"

**Schritt 7: Real-time updates are ready in Production** — Needs attention ⚠ (aufgeklappt)
Linker Text: „Send the required number of RTUs and with a 90% success rate"

Sub-Check:
- **Booking RTU ready in Production:** ⚠ 1 unresolved errors — „You only sent 0 out of 3 required requests in the past 14 days"

**Schritt 8: Integration Testing and Google Review** — Needs attention ⚠ (aufgeklappt)
Linker Text: „Testing and Google review of integration. Read more about end-to-end [in the developer documentation]. Once you have completed testing and all checks have passed fillout the [launch readiness checklist]"

Sub-Check:
- **Integration testing and review:** ⚠ 1 unresolved errors — „Testing has not yet completed. Ensure your previous milestones are complete and check for any open support cases."

---

### Seite 6 — Frame 01.42.46.png (rechtes Panel-Overlay): Erklärungstext

Das rechte Panel (sichtbar als Textblock) erklärt Anforderungen je Feed/Check-Kategorie:
- Merchant Feed: Anforderungen für valid feed (mind. 3 Tage, keine Validation-Errors, correct Schema, Format-Compliance)
- Service Feed: ähnlich
- Availability Feed: Erwähnung von PROCESS_INCOMPLETE, 3-Tage-Fenster
- Booking Checks: Beschreibung der 90%-Success-Rate-Logik
- Inventory/Booking Notification Scores: schrittweise Aufzählung der Mindest-Requests

---

## ### Bildschirmfoto 2026-06-17 um 17.54.27.png — NOISE: E-Mail (intern BMW)

Internes BMW-E-Mail, kein App-/Tool-Screen. Absender: Salim Zabiullah (BMW). Inhalt: persönliche Korrespondenz zu „Wasserspender im Gebäude 4.0". Kein relevanter App-Screen.

---

## Gruppe C — Kadi-v2 Systemarchitektur (2 Frames)
**Beteiligte Dateien:** `Bildschirmfoto 2026-06-18 um 11.07.03.png`, `Bildschirmfoto 2026-06-18 um 11.10.11.png`

### Screen/Feature-Name
**System Overview — Kadi-v2 Architekturdiagramm** (zwei Darstellungen: informell + AWS-formal)

---

### Frame 11.07.03.png — Informelles Flussdiagramm „1. System Overview"

**Typ:** Gerichteter Abhängigkeitsgraph (Flowchart), schwarz-weiß / Text-basiert

**Knoten und Verbindungen (von links nach rechts):**

```
user
  → web-shell
    → api-gateway
      → control-plane-service
        → OIDC Provider
        → feature-flag-service
        → file-service
          → Malware Scanner
          → Object Storage
        → reporting-service
          → Power BI / OData
        → PostgreSQL (direkt)
      → domain-service
        → [Cache] → Redis (Session, Rate Limit)
        → Job Queue → Integration-worker → Teams / SharePoint / Graph
        → Job Queue → time-worker
        → PostgreSQL
```

**Redis:** Session, Rate Limit (via domain-service)
**PostgreSQL:** zentrale DB, mehrere Services verbunden

**Fußnotentext (unten im Bild):**
„Der aktuelle Fokus ist das Fundament E01-E04 (Security, Platform, Auth, Multi-Tenant) und anschließend E08 als M1-Fachfunktion. Die lokale Entwicklung läuft zuerst via Docker Compose. Zielbetrieb läuft in AWS in EU-Regionen mit Rightflow als internem IdP. Der Produktivbetrieb bleibt mandantenneural; BMW-spezifische Integrationen laufen über Adapter/Profiles."

---

### Frame 11.10.11.png — AWS-Infrastruktur-Diagramm (formal, mit Icons)

**Titel:** „BMW Corporate Network (Intranet)" (oben links)
**Rahmen:** „Default cloud (with only connections to the BMW Corporate Network for now)"
**Outer Container:** VPC (lila Cloud-Icon)

**Subnets:**
- Grüner Bereich (links): `subnet: intranet-0`, `subnet: intranet-1`
- Orange/gelber Bereich (rechts): `subnet: private-0`, `subnet: private-1`

**Komponenten und Verbindungsfluss:**

```
User
  → HTTPS:443
    → Route 53 (lila Shield-Icon)
      → HTTPS → internal ALB (Load-Balancer-Icon)
        ← TLS certificate (Certificate Manager, unten, gestrichelter Pfeil)
        → HTTPS → web-shell (Container-Icon, orange)
          → HTTP → api-gateway (Container-Icon, orange)
            → domain-service (Container-Icon, orange)
              → Session, Rate Limit → ElastiCache for Redis (R-Icon)
              → cache → ElastiCache for Redis
            → control-plane-service (Container-Icon, orange)
              → RDS PostgreSQL (Datenbank-Icon, lila)
```

**Unten rechts (3 Service-Icons):**
- Secrets Manager (roter Schloss-Icon)
- CloudWatch (lila Lupe-Icon)
- Elastic Container Registry (orange Box-Icon)

**Farbkodierung:**
- User-Pfad / Netzwerk: grau/schwarz
- Session/Rate Limit Linien: rosa/magenta
- Cache-Linie: türkis
- DB-Verbindungen: lila

---

## Gruppe D — KI-Präsentation: „Agents Working With LLMs" (7 Slides)
**Beteiligte Dateien:** `13.24.03.png`, `13.24.28.png`, `13.29.22.png`, `13.30.09.png`, `13.32.02.png`, `13.35.37.png`, `13.36.51.png`, `13.39.43.png`, `13.43.05.png`, `13.43.41.png`, `13.47.01.png`

**Thema:** Slide-Deck über LLM-Agenten-Optimierung, vermutlich ein Workshop/Talk
**Design:** Dunkler Hintergrund (schwarz/sehr dunkes Grün), weißer/heller Text, grüne Akzentfarben (grüne Überschriften für Kategorie-Labels, grüne Checkmarks, grüner Pfeil). Code-ähnliche Schrift für Labels.

---

### Slide 1 — „Context Window & Tokens" (Frame 13.24.03.png)

**Obertitel (grün, Monospace):** `AGENTS WORKING WITH LLMS`
**Haupttitel (weiß, groß):** `Context Window & Tokens`

**Diagramm: 2 horizontale Token-Balken**

**1st LOOP (obere Zeile):**
- Section „INPUT TOKENS" (links): `SYSTEM PROMPT & TOOLS` (dunkelgrün) | `PROMPT` (lila) | `FILE` (gelb/gold)
- Section „OUTPUT TOKENS" (rechts): `RESPONSE` (blaugrau)
- Rechts aussen: Label „LLM SPECIFIC LIMIT"

**2nd LOOP (untere Zeile):**
- Section „CACHE INPUT TOKENS (NOT GUARANTEED)": `SYSTEM PROMPT` (grau) | `PROMPT` (grau) | `FILE` (grau) | `RESPONSE` (grau) — alle ausgegraut
- Section „INPUT TOKENS": `PROMPT` (lila) | `FILE` (gelb/gold)
- Section „OUTPUT TOKENS": `RESPONSE` (blaugrau)

**Logik:** Im 2nd Loop werden vorherige Tokens (System Prompt, Prompt, File, Response) möglicherweise gecacht (nicht garantiert). Neue Input-Tokens sind nur noch Prompt + File. Output ist wieder Response.

---

### Slide 2 — „Context Rot" (Frame 13.24.28.png)

**Haupttitel:** `Context Rot`
**Untertitel links:** „Just because you can fill the context window, doesn't mean you should."
**Referenz:** `https://www.producttalk.org/context-rot/`

**Zwei Konzept-Karten nebeneinander:**

**Karte 1 — „Lost in the Middle" (WHEN <50% TOKENS):**
- Diagramm: Horizontale Zeile mit Labels `Beginning tokens` / `Middle tokens` / `End tokens`; Mittlerer Bereich markiert mit „DECAY" (unklar, Pfeil nach oben in Mitte)
- Text: „Models do bias tokens at the beginning and end of the context."

**Karte 2 — „Recency Bias" (WHEN .50% TOKENS — vermutlich ≥50%):**
- Diagramm: Vertikale Zeile mit `Latest Tokens (Newest)` oben, `Earliest Tokens (Oldest)` unten; X-Achse: `Time / Context Filling`; Markierung: `Context Window > 50% Full`
- Text: „Models bias tokens from the end of the context."

---

### Slide 3 — AI Engineer Evolution (Frame 13.29.22.png)

**Hauptinhalt:** Zwei-Spalten-Kontrast mit grünem Pfeil dazwischen

**Links (grüner Label):** `AI ASSISTED ENGINEER`
**Haupttitel links:** „Works with one agent, mostly sync"

**Pfeil:** Grüner Gradient-Pfeil nach rechts → `EFFECT OF OPTIMIZATIONS` (Beschriftung mittig unter Pfeil)

**Rechts (grüner Label):** `AI ENGINEER`
**Haupttitel rechts:** „Orchestrator of multiple, async agents"

---

### Slide 4 — „The two biggest levers for optimizing quality & tokens" (Frames 13.30.09.png + 13.32.02.png — identisch, exaktes Duplikat)

### ### Bildschirmfoto 2026-06-18 um 13.32.02.png — NOISE: exaktes Duplikat von 13.30.09.png

**Slide-Inhalt (einmalig dokumentiert):**

**Haupttitel (weiß, groß):** „The two biggest levers for **optimizing quality & tokens**" (Partial-Farbmarkierung grün auf dem letzten Teil)
**Icon rechts:** 3D-Block-Icon (grün)

**Linke Spalte — „Model choice & auto mode":**
- Terminal-Icon links oben
- Reasoning models (Opus, GPT-5.5) — for sync tasks like planning, architecture, debugging.
- Mid-tier models (Sonnet, GPT5.4) — for async implementation.
- Low-tier (Haiku, GPT-mini) — for small refactorings, repetitive tasks, doc updates.
- Auto Mode as the lazy default.

**Rechte Spalte — „Provide only relevant context":**
- Terminal-Icon links oben
- As much as required, as little as necessary.
- Context Engineering as your guidance and upskill potential.
- Compacting sessions can be helpful — but they can also lead to valuable information being lost. Used it cautiously.
- Use `/clear` often, for each new task.

---

### Slide 5 — „Your Prompt" (Frame 13.35.37.png)

**Kategorie-Label (grün, Monospace):** `GUIDING THE AGENT`
**Haupttitel (weiß, groß):** `Your Prompt`

**3-Spalten-Tabelle mit grüner Trennlinie oben:**

| Spalte 1 | Spalte 2 | Spalte 3 |
|---|---|---|
| ✓ (grüner Checkmark-Kreis) | ✓ | ✓ |
| **Be precise.** | **Add stop signals.** | **Add known context beforehand.** |
| Add description. | "Stop if X." | Files, Folders, Websites, etc. |

**Unten im Bild (Token-Balken-Miniaturgrafik):**
- Label: `ALWAYS ON` (über grünem Block)
- Block 1: grün — `SYSTEM & TOOLS`
- Block 2: lila — `PROMPT`
- (INSTRUCTIONS nicht sichtbar in diesem Slide)

---

### Slide 6 — „Research → Plan → Implement" (Frame 13.36.51.png)

**Kategorie-Label (grün):** `DIVIDE AND CONQUER YOUR WORK`
**Haupttitel:** `Research → Plan → Implement`

**Beispiel-Prompt oben (gelbe Sprechblase):** `"I WANT TO CHANGE X. WHAT FILES ARE RELEVANT?"`

**3 horizontale Schichten (Agent-Rollen):**

**Schicht 1 — `/RESEARCH` (Gemini 2.5 Pro):**
Token-Balken: `SYSTEM PROMPT` (grau) | `PROMPT` (lila) | `FILE` (X — rot) | `FILE` (✓) | `FILE` (✓) | `FILE` (✓) | `FILE` (✓) | `FILE` (✓) | → `PLAN INPUT` (grüner Block)

**Schicht 2 — `/PLAN` (Opus 4.7):**
Token-Balken: `SYSTEM PROMPT` | `PROMPT` | `PLAN INPUT` | `FILE` | `FILE` | `REASONING` | → `PRECISE SPEC` (grüner Block)

**Schicht 3 — `/FLEET` (GPT 5.4):**
Token-Balken: `SYSTEM PROMPT` | `PROMPT` | `PRECISE SPEC` | `FILE` | `FILE` | → `CHANGE CALLS`

**Verbindungen:** Pfeile zwischen Schichten (PLAN INPUT von Research → PLAN; PRECISE SPEC von PLAN → FLEET)

---

### Slide 7 — „Deterministic Controls" (Frame 13.39.43.png)

**Kategorie-Label:** `AVOID COMPOUNDING ERRORS EARLY`
**Haupttitel:** `Deterministic Controls`

**3 Zeilen-Szenarien:**

**Zeile 1 — WITH UNIT TESTS:**
Token-Balken: `SYSTEM & TOOLS` (dunkel) | `PROMPT` (lila) | `BUGGY CHANGE` (rot) | `FAILING TESTS` (rot) | `CORRECTION CHANGE` (grün) | `CHANGE 2` (grün) | `SUCCEEDING TESTS` (grün)

**Zeile 2 — WITHOUT UNIT TESTS:**
Token-Balken: `SYSTEM & TOOLS` | `PROMPT` | `BUGGY CHANGE` (rot) | `BUGGY CHANGE 2` (rot) | `BUGGY CHANGE 3` (rot) | `BUGGY CHANGE 4` (rot)
→ darunter `INCIDENT` (kleines Dreieck): „WASTED CI/CD MINUTES, COPILOT REVIEW CYCLES, HUMAN TIME ETC."

**Zeile 3 — DEBUGGING SESSION:**
Token-Balken: `SYSTEM & TOOLS` | `PROMPT` | `BUGGY RESEARCH` | `BUG FIX`

---

### Slide 8 — „Agent Configs" (Frame 13.43.05.png)

**Haupttitel:** `Agent Configs`

**Liste mit 8 Einträgen (alle mit grünem Checkmark-Kreis):**

1. **Persistent instructions** — `COPILOT-INSTRUCTIONS.MD`
2. **Custom Agents.** — `./GITHUB/AGENTS/*.AGENT.MD`
3. **Skills** — `./GITHUB/SKILLS/*/SKILL.MD`
4. **MCP**
5. **Subagents**
6. **Scoped instructions.** — `./GITHUB/INSTRUCTIONS/*.INSTRUCTIONS.MD`
7. **Prompt Files** — `./.GITHUB/PROMPTS/*.PROMPT.MD`
8. **Copilot Memory**

Layout: Einspaltige Liste, schwarzer Hintergrund, weiße Schrift, grüne Checkmarks links, Datei-Pfade in grünem Monospace-Font rechts neben den Titeln.

---

### Slide 9 — „Persistent Instructions" (Frame 13.43.41.png)

**Kategorie-Label (grün):** `YOUR ALWAYS ON AGENT GUIDANCE`
**Haupttitel:** `Persistent Instructions`

**Zwei Datei-Pfade (dunkelgrau Boxen mit Schloss-Icon):**
- `./.GITHUB/COPILOT-INSTRUCTIONS.MD`
- `./AGENT.MD`

**Rechte Seite (4 Checkmark-Punkte):**
- ✓ Put in:
  - the non-negotiables of your projects
  - log reoccurring agent misses
  - Statements to trim output ("be concise")
- ✓ Keep them very small.
- ✓ Don't use AI to generate them.
- ✓ Iterate, maintain and even recreate them often.

**Unten links: Token-Balken-Miniatur:**
- Block 1: dunkelgrün — `SYSTEM & TOOLS` (Label: ALWAYS ON)
- Block 2: lila — `INSTRUCTIONS` (Label: ALWAYS ON)

---

### Slide 10 — „Custom Agents" (Frame 13.47.01.png)

**Kategorie-Label (grün):** `DESIGN WORKFLOWS & BEHAVIORS`
**Haupttitel:** `Custom Agents`

**Diagramm (Flowchart):**

```
USER: "/TDD-RED ADD API ENDPOINT"
  → CUSTOM AGENT → PROMPT
                     ↓
              HARNESS: RETRIEVES THE AGENT FILE
                     ↓
  ┌─────────────────────────────────────────┐
  │ HARNESS: ADJUSTS AVAILABLE TOOLS         │
  │ HARNESS: PUTS CUSTOM AGENT DEFINITION IN │
  │ HARNESS: APPENDS PROMPT                  │
  └─────────────────────────────────────────┘
       ↓            ↓           ↓
  SYSTEM & TOOLS  INSTRUCTIONS  CUSTOM AGENT  PROMPT
```

**Rechtes Panel (gelbe Sprechblase / Code-Snippet):**
```
name: tdd-red
description: Writes failing tests from user requirements,
defaulting to one test unless full coverage is needed.
argument-hint: Feature request, failing test target, or TDD plan
(optional)
Configure tools.
tools: ['read', 'edit', 'search', 'execute', 'agent',
'github-events/issue_read']

You are the RED phase agent in Test-Driven Development.

Your SOLE responsibility is writing FAILING tests based on the
feature request and available specifications.

<user_principles>
RED Phase Rules:
1. Write tests that WILL FAIL because implementation doesn't
exist yet
2. Tests must be well-structured and follow existing conventions
3. Tests must clearly specify expected behavior
```

**Verbindungspfeile:** User → Custom Agent; Custom Agent → Harness retrieves; Harness → adjusts/puts/appends → final Token-Sequence