25/26 - 4ahitm - itp - Lecture Notes

‏ ‏ ‎ ‏ ‏ ‎

1. Testtermine

1. Dez. 2025
es wurden statt dem 2. Test schriftliche und mündliche Mitarbeitsüberprüfungen vereinbart

2. 2025-09-15

2.1. Projekte

Franklyn weiterarbeiten
ev. Seniorenheim

2.1.1. Themen

Gesundheit
Umwelt
Bildung
Beeinträchtigte Personen

3. 2025-09-16

3.1. Authentifizierung und Autorisierung

Statuscodes sind nicht korrekt
- 401 Unauthorized sollte unauthenticated heissen
- 403 Forbidden sollte unauthorized heissen

3.1.1. Ablauf einer HTTP Anfrage

Zugriff auf eine geschützte Ressource durch Request.
Server antwortet mit 401 Unauthorized und fordert Authentifizierung an. Der Client wird an den Keycloak weitergeleitet.
Client authentifiziert sich beim Keycloak (z.B. durch Login).
Keycloak sendet ein Token (z.B. JWT) an den Client zurück.
Client sendet das Token in der nächsten Anfrage an den Server.
Server überprüft das Token und gewährt Zugriff auf die Ressource, wenn das Token gültig ist.

3.1.2. Keycloak

Realm

User

Client

Role

Collection von Rechten

Group

Collection von Usern

4. 2025-09-22

4.1. Projektideen Stütz

Franklyn: Lehreraccounts, KI-Detektion, ev. weitere Funktionen wie aufzeigen
- Clemens, Jakob, Eldin, Gregor
LeoIoT Jonas, Daniel L, Paul, Elias, Stefan
- Sensoren in Klassen mit Dashboard
- Dashboard für PV-Anlage und Verbräuche der Schule
Trainingsplaner (Paul, Elias, Daniel L.)
HTL 3D für Elternsprechtag
MusicVoting
- Miriam, Simone, Marlies
Der sprechende Eisbär (Chatbot mit KI)
Dashboard mit Grafana und InfluxDB für eine Mineralölfirma
- Hanan
- Almin
FPV-Drohnen Assistent (David, Simon)

4.2. Projektideen Schüler

Brailleleiste
Lernplattform (Hanan) vgl. Code Academy
HÜ-Planer (Clemens, Jakob)
Whatsapp-Alternative (Miriam)
SOS-Taschenrechner (Daniel R.)

4.3. Aufgabenstellung

Erstellung einer Projektidee mit Projektkonzept
- User Stories
- Systemarchtitektur

5. 2025-09-23 Keycloak

IAM … Identity and Access Management

Keycloak ist ein Softwareprodukt zur Verwaltung von Identitäten und Zugriffsrechten in Anwendungen und Diensten. Es bietet Funktionen wie Single Sign-On (SSO), Benutzerverwaltung, Rollen- und Berechtigungsmanagement sowie Integration mit verschiedenen Authentifizierungsprotokollen wie OAuth2, OpenID Connect und SAML.

https://www.urldecoder.org/

Die Payload eines tokens ist nicht verschlüsselt jedoch fälschungssicher signiert.

Was ist Keycloak
- Keycloak ist eine Open-Source Identity- und Access-Management-Lösung (IAM), die Single Sign-On (SSO) für Anwendungen und Services bereitstellt. Es übernimmt zentrale Aufgaben im Bereich der Authentifizierung und Autorisierung, basierend auf modernen Sicherheitsstandards wie OAuth 2.0, OpenID Connect (OIDC) und SAML 2.0.

Keycloak Authenctication Flows

Securing Quarkus Backends with Keycloak

CORS (Cross-Origin-Ressource-Sharing)
- CORS (Cross-Origin Resource Sharing) ist ein Sicherheitsmechanismus in Webbrowsern, der den Zugriff von Webanwendungen auf Ressourcen über Domänengrenzen hinweg regelt.

Was ist Kubernetes?
- Kubernetes ist ein Container-Orchestrierungstool, welches dafür sorgt , dass Container automatisch gestartet, überwacht, skaliert und im Fehlerfall neu gestartet werden.

6. 2025-10-07

6.1. Pure Web

 npm create vite

Wir verwenden Vite als Build-Tool (Bundler)
- https://vitejs.dev/guide/
- Erstellt ein großes javascript file mit allen Abhängigkeiten.
- Unterstützt auch React, Vue, Svelte, …
- Einfacher zu konfigurieren als Webpack
- Vergleichbar mit webpack
package-lock.json zu .gitignore hinzufügen
Model erstellen

6.1.1. Proxy einrichten

https://vite.dev/config/server-options.html#server-proxy

https://vite.dev/config/server-options

6.1.2. Warum Typescript Module?

Auf einer herkömmlichen Website wird alles javascript direkt im globalen Scope ausgeführt. Eigener Code im globalen Scope kann leicht mit fremdem Code kollidieren (z.B. Bibliotheken) und ist daher unwartbar.
Deshalb werden Typescript Module verwendet. Diese haben ihren eigenen Scope und kollidieren nicht mit anderem Code.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules

6.1.3. Model

Das Model ist die Wahrheit, die reine Wahrheit und nichts als die Wahrhei → Single Source of truth
Das Aussehen des Bildschirms wird AUSSCHLIESSLICH durch das Model bestimmt. In der GUI werden keine Zustände gespeichert.

7. 2025-10-21

7.1. Trennung von Layout und Daten

7.1.1. MVC

7.1.2. MVVM

Ein Model ist immer notwendig. Ein Model ist die Wahrheit, die reine Wahrheit und nichts als die Wahrheit.

Problem: Wir sollten die Daten nicht in den Komponenten speichern.
Abhilfe: Die Daten sollten zentral gespeichert werden → store

8. 2025-11-04

9. 2025-11-10

9.1. Backlog mit User Stories

Jede Gruppe muss ein Backlog erstellen, in dem alle User Stories für das Projekt gesammelt werden. Dabei ist zu beachten, dass die User Stories klein genug sind, um in einem Sprint umgesetzt werden zu können. Auch sind nur wenige User Stories detailliert auszuarbeiten, die meisten sollten nur grob beschrieben werden, da diese erst späte im Projekt detailliert werden.

https://docs.github.com/de/issues

9.2. Systemarchitektur

Abgeleitet vom Backlog ist ein erster entwurf der Systemarchitektur zu erstellen. Dabei sind die wichtigsten Komponenten des Systems zu identifizieren und deren Zusammenspiel zu beschreiben. Auch sind die wichtigsten Technologien und Frameworks zu benennen, die im Projekt verwendet werden sollen.

10. 2025-12-02 [Hanan Mehic]

10.1. Kubernetes

YAML-Konfigurationsdatei für Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_PASSWORD
              value: "demo"
            - name: POSTGRES_USER
              value: "demo"
            - name: POSTGRES_DB
              value: "demo"
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: postgres-pvc

10.2. Port Forwarding

Port Forwarding ist eine Netzwerktechnik, die es ermöglicht, eingehende Datenpakete, die an einer bestimmten Adresse und einem externen Port ankommen, zu einem bestimmten Gerät und einem internen Port im privaten Netzwerk umzuleiten. Sie ist notwendig, da Geräte in deinem privaten Netzwerk standardmäßig durch eine Firewall verborgen sind.

11. 2025-12-22

11.1. Teststrategien

Vorgehen zum Auswählen von Testfällen
Äquivalenzklassen
Grenzwertanalyse

Testobjekte: * Black-Box-Tests * White-Box-Tests * Gray-Box-Tests

11.1.1. Testaufbau

Arrange - Act- Assert (AAA-Pattern)
Given - When - Then (GWT-Pattern)
Mock
- Mocking bedeutet täuschen oder vortäuschen
- Ein Mock-Objekt ist ein Objekt, das das Verhalten eines echten Objekts simuliert.
- Mocks werden verwendet, um Abhängigkeiten zu isolieren und kontrollierte Testumgebungen zu schaffen.
- Bibliotheken: Mockito, JMock, EasyMock
- Mock Objekte können auch Stubs oder Spies sein.
  - Ein Stub ist ein einfaches Mock-Objekt, das vordefinierte Antworten auf Methodenaufrufe zurückgibt.
  - Ein Spy ist ein Mock-Objekt, das das Verhalten eines echten Objekts überwacht und aufzeichnet.
Philipp Hauer’s Blog - Modern Best Practices for Testing in Java

12. 2026-01-12

12.1. Testen des Backends

Unit-Tests (assertj-core)
Integrationstests (assertj-db)

siehe im Ordner labs das Projekt testen.

13. 2026-01-20 [A. Mahmutovic]

13.1. API Testing mit httpyac

Um API-Endpunkte automatisiert und reproduzierbar zu testen, verwenden wir das Tool httpyac.

13.1.1. Installation und Setup

Die Installation erfolgt lokal im Projektverzeichnis (Ordner api), um globale Abhängigkeiten zu vermeiden.

# Initialisierung des API-Ordners
cd api
npm init -y

# Lokale Installation von httpyac
npm install httpyac

13.1.2. Erstellen von Requests

Requests werden in einer .http Datei definiert. Mit ?? werden Test-Assertions direkt unter dem Request eingefügt.

# @name clients
GET http://localhost:8080/clients
?? status == 200

13.1.3. Automatisierung (package.json)

Um die Tests einfach über die CLI zu starten, wird ein Script in der package.json hinterlegt:

"scripts": {
  "test": "httpyac --send --all --bail request.http"
}

Der Aufruf erfolgt dann mittels:

npm test

13.1.4. Konfiguration mit Variablen

Für unterschiedliche Umgebungen wird eine http-client.config.js erstellt. In der request.http kann dann die Variable {{host}} statt localhost:8080 verwendet werden.

13.2. Code Coverage mit JaCoCo

JaCoCo (Java Code Coverage) misst, wie viel Prozent des Codes durch Tests tatsächlich ausgeführt werden.

13.2.1. Konfiguration Quarkus

Die Integration erfolgt über die pom.xml und die application.properties.

<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-jacoco</artifactId>
  <scope>test</scope>
</dependency>

In den application.properties muss das Paket-Format umgestellt werden, um auch Integration-Tests korrekt zu erfassen:

quarkus.package.type=uber-jar

13.2.2. Ausführung

Die Reports werden beim Build-Prozess generiert:

mvn package
# Starten mit JaCoCo Agent (falls Integrationstests manuell geprüft werden)
java -jar target/*-runner.jar

Der fertige Report ist als interaktive Webseite unter target/jacoco-report/index.html verfügbar.

13.3. Test-Strategie (Prof. Aberger)

Code Coverage Ziel: Ein Abdeckungsgrad von ca. 80% wird angestrebt.
Sinn des Testens: Die Abdeckung ist der Hauptgrund für das Testing, um die Stabilität bei Refactorings zu gewährleisten.
Code Design: Verwendung von Expressions (z.B. Switch-Expression mit return) statt Statements erhöht die Testbarkeit und Übersichtlichkeit.
- Unnötige Getter und Setter sollten vermieden werden (Datenklassen/Records), da diese die Coverage-Statistik verfälschen (Boilerplate-Code ohne Logik).

// Effizientes Design: Expression statt Statement
public String resolve(int code) {
    return switch (code) {
        case 200 -> "OK";
        default -> "Error";
    };
}

13.4. Kubernetes

YAML-Konfigurationsdatei für Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_PASSWORD
              value: "demo"
            - name: POSTGRES_USER
              value: "demo"
            - name: POSTGRES_DB
              value: "demo"
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: postgres-pvc

13.5. Port Forwarding

Port Forwarding ist eine Netzwerktechnik, die es ermöglicht, eingehende Datenpakete, die an einer bestimmten Adresse und einem externen Port ankommen, zu einem bestimmten Gerät und einem internen Port im privaten Netzwerk umzuleiten. Sie ist notwendig, da Geräte in deinem privaten Netzwerk standardmäßig durch eine Firewall verborgen sind.

14. 2026-01-27

Image von Mr. Mehic

15. 2026-03-01 [Hanan Mehic] - What ist kubernetes (Nana)

15.1. Official Definition of Kubernetes

Open source container orchestration tool
Developed by Google
Manages containers (Docker or other technologies)
Helps manage containerized applications in different deployment environments:
- Physical
- Virtual
- Cloud

15.2. What Problems Does Kubernetes Solve?

Trend from Monolith to Microservices
Increased usage of containers
Demand for a proper way of managing hundreds of containers

15.3. What Features Do Orchestration Tools Offer?

High availability (no downtime)
Scalability and high performance
Disaster recovery (backup and restore)

15.4. Kubernetes Basic Architecture

A Kubernetes cluster consists of one Master Node connected to multiple Worker Nodes.

Each node has kubelet running on it.

Kubelet:

Kubernetes process
Enables the cluster to communicate with each node
Executes tasks like running application processes

Each Worker Node:

Runs Docker containers of different applications
Hosts the running application workloads

15.4.1. Master Node Components

Important Kubernetes processes run on the Master Node:

API Server
- Container
- Entry point to the Kubernetes cluster
- All communication goes through it
Controller Manager
- Keeps track of what is happening in the cluster
Scheduler
- Decides on which Worker Node a Pod should run
- Based on available resources
etcd
- Kubernetes backing store (key-value database)

15.4.2. Virtual Network

Enables nodes to communicate with each other
Creates a unified machine view across all nodes
Worker nodes are larger in number
Master Node is critical → requires backup
Best practice: multiple Master Nodes

15.5. Kubernetes Basic Concepts

15.5.1. Pod

Wrapper of a container
Multiple Pods can run on each Worker Node
A Pod can contain multiple containers
Usually one Pod per application
Each Pod is its own self-contained server
Manages containers running inside it
Communicates with other Pods via internal IP addresses

15.5.2. Virtual Network

Assigns each Pod an IP address
Services replace dynamic IP addresses
If a Pod dies and gets recreated, the Service remains stable
Ensures communication between Pods

15.5.3. Service

Permanent IP address
Load balancer

15.6. Kubernetes Configuration

All configuration in a Kubernetes cluster goes through the Master Node via the API Server.

Clients (UI or API) communicate with the API Server
Configuration requests are sent as:
- YAML
- JSON
Kubernetes configuration is declarative

16. 2026-03-09 [Clemens Zangenfeind]

16.1. Kriterien für ein gutes GUI

Ein gutes GUI soll feedback an den Nutzer zurückgeben.
- Bsp.: Ein Nutzer erstellt einen neuen Listeneintrag, ein pop-up sagt dem Nutzer, dass ein neuer Eintrag erstellt wurde.
Es soll Beschreibungen und Alle möglichen Interaktionen klar darstellen.
- Der Nutzer sieht direkt bei Aufruf der Website, wie er alle möglichen Filter auf Daten anwenden kann.
Der Nutzer soll wissen wo er anfangen soll.
Die wichtigsten Daten werden als erstes / am größten gezeigt (Informationshirarchie).
- Der Titel eines Kalendareintrags ist größer geschrieben und als erstes platziert, weitere Daten folgen danach

→ Das Design eines GUIs hängt von der Zielgruppe ab

UI ist das design (Aussehen), UX ist die Nutzererfahrung (Interaktionen)

17. 2026-02-23

18. 2026-03-09 - User Interface [Simone Sperrer]

18.1. Kriterien für eine gute GUI

Dashboard: Informationen auch ohne ausgeführter Aktion
Es ist ersichtlich, welche Aktionen möglich sind
Dem User alle Daten sichtbar machen, die ihn interessieren könnten
Startseite: Ein gesamter Überblick
Bei ausgeführten Aktionen: Feedback über Erfolg oder Fehler (User-Feedback)
Symbole Verwenden (z.B. Zahlungsoptionen)
Pflichtfelder markieren
Wichtige Informationen hervorheben (Farben, Schriftgröße, …)
Mann sollte nicht mehr wie zwei Schriftarten verwenden
Cookies mit einem Klick akzeptieren oder ablehnen können
Make your links look like links
Konsistente Gestaltung

18.2. User Interface Elemente

Buttons
Checkboxen
- Man kann mehrere Optionen auswählen
Radio Buttons
- Man kann nur eine Option auswählen
Comboboxen
- Eine Combobox ist ein Eingabefeld, in dem man tippen, suchen und oft aus einer Liste auswählen kann (ein- oder mehrfach).
Dropdown
- Ein Dropdown ist eine Liste, die sich öffnet und nur die Auswahl eines vordefinierten, einzelnen Wertes erlaubt.
Toggle Switch
- Man sieht sehr gut welche Optionen ausgewählt sind
Slider
- Man bekommt mit einem Blick ein gutes User-Feedback über den noch verfügbaren Spielraum
Date Picker
Popups
Menu Bars
Wizard
- unterteilt komplexe Prozesse in mehrere Schritte, um die Benutzer zu zeigen in welchem Schritt sie sich befindet

18.3. Was versteht man unter Informationshierarchie?

Informationshierarchie ist die strukturierte Anordnung und Priorisierung von Inhalten, um Nutzern das Verständnis und das schnelle Auffinden von Informationen zu erleichtern.

18.4. UI Vs. UX

UI (User Interface) bezieht sich auf die Gestaltung der Benutzeroberfläche, also wie die Elemente angeordnet sind, welche Farben verwendet werden, welche Schriftarten, …
UX (User Experience) bezieht sich auf die Gesamterfahrung des Nutzers, einschließlich der Benutzerfreundlichkeit, der Effizienz und der Zufriedenheit.

18.5. Serif Vs. Sans-serif

Serif-Schriften (mit Füßchen) sind ideal für gedruckte, lange Texte (Bücher, Zeitungen), da sie die Zeilenführung unterstützen und klassisch/seriös wirken.
Sans-Serif-Schriften (ohne Serifen) eignen sich besser für Bildschirme, kurze Texte, Überschriften und moderne, minimalistische Designs (Websites, Apps, Logos).

18.6. Deployment

Wohin kann man Applikationen deployen?
- Cloud-Provider: AWS, Azure, Google Cloud, … → k8s
- Docker:
  - vm
  - bare-metal
Grundregeln bei Docker-Containern/Images:
- Container sollten so klein wie möglich sein (Single Responsibility Principle)
- Nach Möglichkeit sollen keine eigenen Images mit Dockerfile erstellt werden, sondern offizielle Images konfiguriert werden (z.B. postgres, redis, …)
Grundregeln für Keycloak:
- Immer einen eigenen Realm erstellen und nicht den Master Realm verwenden.

19. 2026-03-16

3.LF Stoffumfang:

UML (CLD, OD, Deployment Diagramm, …)
IAM-Systeme
Deployment (Docker, Kubernetes, CI/CD, gh-action)
Agentisches Programmieren

20. 2026-03-17

Für jedes Teammitglied sind Zeitaufzeichnungen den Projekten zu führen:

zB in https://clockify.me/

21. 2026-03-24

Prof. Aberger demonstriert agentisches Programmieren mit Claude und Gemini
- Es wird eine Checklist erstellt, die durch das LLM abgearbeitet wird.
- openspec
- jsdoc
- Es wird angemerkt, dass Grundlagen des Programmierens tw. fehlen:
  - zB Java: Virtuelle Threads
  - zB JS: Shadow DOM, Custom Elements, …

22. 2026-04-13 [Hanan Mehic]

22.1. Grundprinzip von LLMs

Large Language Models (LLMs) arbeiten auf Basis von Tokenisierung und Vektorraummodellen.

Texte werden in Tokens zerlegt (Wörter / Wortteile)
Tokens werden in Vektoren umgewandelt
Bedeutung entsteht durch Ähnlichkeit im Vektorraum

22.1.1. Wichtige Konsequenzen

Rechtschreibfehler → andere Tokens → schlechtere Ergebnisse
Präzision im Prompt → bessere Vektor-Ausrichtung
Kontext bestimmt die Interpretation

22.2. Mathematische Intuition

22.2.1. Ähnlichkeit von Bedeutungen (Cosinus)

\$cos(\theta) = (a · b) / (|a| * |b|)\$

cos(θ) ~ 1 → gleiche Richtung → gleiche Bedeutung
cos(θ) ~ 0 → unabhängig
cos(θ) ~ -1 → gegensätzlich

Ziel beim Prompting: Prompt-Vektor ~ Ziel-Vektor

22.2.2. “Tal”-Metapher (LLM-Verhalten)

LLM verhält sich wie eine Landschaft (Loss Landscape)
Ziel = Minimum (Tal)
Antworten "rollen" Richtung sinnvollster Lösung

Gute Prompts = bessere Richtung ins Tal

22.2.3. Prompt als quadratische Funktion

Scheitelpunkt = optimale Antwort (Ziel)
Startpunkt = Prompt
Je präziser der Prompt → desto direkter zum Minimum

22.3. Prompt Engineering

22.3.1. Ziel

Maximale Alignment zwischen:

Prompt
gewünschtem Output

22.3.2. Prinzipien

Klarheit > Kreativität
Strukturierte Inputs (z. B. Markdown)
Kontext vollständig angeben
Keine unnötigen Informationen

22.3.3. Fehlerquellen

Rechtschreibfehler (Token-Verlust)
Unklare Anforderungen
Fehlender Kontext

22.4. Kontext (Context Engineering)

Kontext = alles, was das Modell über das Problem weiß

22.4.1. Beispiele

Projektstruktur
Anforderungen
bestehender Code
Zielbeschreibung

22.4.2. Wichtig

Kontext wird gewichtet interpretiert
Falsche Gewichtung → falsche Priorisierung

Tipp: Dinge als Kommentar markieren → weniger Gewicht (z. B. "nur Idee")

22.5. AI Spec-Driven Development

22.5.1. Grundidee

Entwicklung basiert auf Spezifikationen statt Code
LLM generiert Code aus Specs

22.5.2. OpenSpec

Definiert, wie Spezifikationen aufgebaut sind
Ziel: standardisierte Kommunikation mit LLMs

22.5.3. Change Requests

Wenn sich Anforderungen ändern:

Neue Fragen klären
Spezifikation anpassen
LLM erneut ausführen

Iterativer Prozess

22.6. Skills

Ein Skill = spezialisierter Prompt mit Bedingungen

22.6.1. Eigenschaften

Hat Header (wann wird er verwendet)
Wird nur ausgeführt, wenn Kontext passt
Kann enthalten:
- Prompts
- Shell-Skripte
- Anweisungen

Vorteile:

Wiederverwendbarkeit
Modularität

22.7. Projektkontexte

22.7.1. Brownfield

Bestehendes Projekt
Erweiterung / Anpassung

22.7.2. Greenfield

Neues Projekt
Keine Altlasten

Figure 1. source: https://www.cabotsolutions.com/blog/migrating-to-the-cloud-choosing-between-greenfield-and-brownfield

Wichtig für LLM: Kontext unterscheidet sich stark

22.8. Risiken

22.8.1. YOLO-Mods

Unsichere Änderungen
Kein Verständnis der Auswirkungen

23. 2024-04-14

23.1. Continuation Prompt

zB nach Erstellen einer GUI in stitch kann man "Give me a continuation prompt" eingeben.

Dieser Prompt wird im Verzeichnis continuation gespeichert und kann später wiederverwendet werden, um die GUI weiterzuentwickeln.

Mit /clear den Context löschen und ggf @continuation/gui.md wieder einlesen.

Man muss bei Änderungen zunächst einen change request nach openspec erstellen, damit die Änderungen in der Spezifikation dokumentiert sind. Danach kann man die Änderungen vornehmen und den Continuation Prompt ausführen, um die Änderungen umzusetzen.

24. 2026-05-12

24.1. openSpec

global installieren

24.2. Ablauf

Beginnen mit /opsx:explore
anschließend /opsx:propose: Hier kann er gut mit Spezifikationen umgehen.
Dann einen cold start
- create continuation prompt
- /clear
- read continuation prompt
/opsx:apply
commit (ev. auch push)
/opsx:sync
/opsx:archive

24.2.1. tmux

Ein Terminal, das nicht beendet wird, wenn man die ssh-session beendet. Mit "tmux attach" kann man sich wieder mit der Session verbinden.

24.3. Skills

24.3.1. Front Matter

Definieren, wann ein Skill ausgeführt wird

24.4. ZimaBlade

Wie Raspberry nur schneller

24.5. Firewall NFS Tables

Mit /copy wird der Output der KI

25. 2026-05-26

25.1. openSpec

zum Darstellen des Outputs der KI im Browser

mo

syncen vom Entwicklunsserver mit rsync

25.2. Continuation Prompt

zwischen 20% und 25% des Kontextes imm er einen continuation prompt erstellen.

create a continuation prompt in folder "continuations"

anschließend

update the continuation prompt

Für Background Tasks /bg

Skill erstellen, damit claude automatisch erkennt, welcher Task im Hintergrund auszuführen ist

25.3. Das `/bg`-Kommando

25.3.1. Was ist `/bg`?

Mit dem /bg-Kommando kann ein Agent in den Hintergrund geschickt werden, während er weiterarbeitet. Gleichzeitig lässt sich eine neue Session für eine andere Aufgabe starten. Es geht also um paralleles Arbeiten — man steuert, wo und wie viele Agenten laufen.

25.3.2. Agent View

Anthropic hat am 12. Mai 2026 das sogenannte Agent View in Claude Code eingeführt — eine einheitliche Ansicht im CLI, über die alle Claude-Code-Sessions verwaltet werden können.

Man kann:

neue Agenten starten,
sie in den Hintergrund schicken,
und nur dann eingreifen, wenn Claude eine Eingabe braucht.

Auf einen Blick sieht man, welche Agenten auf einen warten, welche noch arbeiten und welche fertig sind.

25.3.3. Verfügbarkeit

Das Feature ist derzeit als Research Preview verfügbar und nur für folgende Pläne zugänglich:

Pro
Max
Team
Enterprise
Claude API

Free-Plan-Nutzer haben keinen Zugang zu Background Agents oder dem claude agents-Kommando.

25.4. Das `/goal`-Kommando

25.4.1. Was ist `/goal`?

/goal setzt eine Abschlussbedingung, und Claude Code arbeitet selbstständig über mehrere Turns hinweg, bis ein separates Modell entscheidet, dass die Bedingung erfüllt ist.

Es ist die eingebaute Version der „keep-going"-Loops, die man sich bisher manuell zusammengebaut hat.

Das Kommando ändert die zentrale Frage:

Von „Was soll ich als nächstes tun?" zu „Welcher Endzustand gilt als erledigt?"

Das passt natürlich zu langen Aufgaben mit einem klaren Endpunkt — etwa „alle Tests müssen grün sein".

25.4.2. Mindestanforderung

/goal erfordert Claude Code v2.1.139 oder neuer.

25.5. Vergleich: `/bg` vs. `/goal`

/bg /goal

	`/bg`	`/goal`
Frage	Wo läuft es?	Wann ist es fertig?
Zweck	Parallel mehrere Sessions verwalten	Autonom bis zur Zielerreichung iterieren
Kontrolle	Man wechselt selbst zwischen Sessions	Claude iteriert selbstständig

Frage

Wo läuft es?

Wann ist es fertig?

Zweck

Parallel mehrere Sessions verwalten

Autonom bis zur Zielerreichung iterieren

Kontrolle

Man wechselt selbst zwischen Sessions

Claude iteriert selbstständig

25.6. Zusammenspiel und praktisches Beispiel

Die beiden Kommandos sind für unterschiedliche Dimensionen zuständig und ergänzen sich ideal:

/bg steuert wo der Agent läuft.
/goal definiert wann er fertig ist.

Für unbeaufsichtigte Läufe empfiehlt sich folgende Kombination:

Auto-Mode genehmigt Tool-Calls innerhalb eines Turns.
/goal startet den nächsten Turn automatisch.

25.6.1. Beispiel-Workflow

# 1. Ziel definieren
/goal "Migriere alle Auth-Komponenten auf das neue Design-System, alle Tests müssen grün sein"

# 2. Agenten in den Hintergrund schicken
/bg

# 3. Neue Session starten und parallel weiterarbeiten

Claude arbeitet nun im Hintergrund eigenständig — schreibt Code, führt Tests aus, debuggt — bis das definierte Ziel erreicht ist.