Robot NXT Control MCP

Lokaler MCP-Server für kompatible, programmierbare Brick-Hardware, die per USB/WinUSB mit Windows 11 verbunden ist.

Kompatibilität und Marken

Dieses unabhängige Projekt ist weder mit der LEGO Group verbunden, noch wird es von ihr gesponsert oder befürwortet. LEGO, MINDSTORMS und NXT sind Marken der LEGO Group. Sie werden in dieser Dokumentation ausschließlich verwendet, um kompatible Hardware, Software, Protokolle und Drittanbieterabhängigkeiten zu kennzeichnen; sie sind nicht Teil des Namens, der Serverkennung oder der Plugin-Kennung dieses Projekts.

Migration von früheren Versionen

Die alte Plugin- und MCP-Server-Kennung wurde durch robot-nxt-control ersetzt, und die ausführbaren Dateien heißen jetzt robot-nxt-control-mcp, robot-nxt-control-mcp-stdio und robot-nxt-control-mcp-http. Installieren Sie das editierbare Paket nach dem Übernehmen dieser Änderung neu und ersetzen Sie frühere MCP-Konfigurationseinträge durch die untenstehenden Beispiele.

Related MCP server: KentraBOT MCP Server

Installation in Claude Desktop oder Codex desktop (Windows)

Schließen Sie zuerst die Windows-Installation ab. Diese Desktop-Apps starten den MCP-Server selbst; führen Sie robot-nxt-control-mcp-stdio.exe daher nicht manuell aus. Die Beispiele gehen davon aus, dass sich dieses Repository unter C:\Users\lukas\workspace\NXT-MCP befindet; ersetzen Sie diesen Teil in jedem Pfad, wenn Ihr Checkout woanders liegt.

Claude Desktop

1. Beenden Sie Claude Desktop vollständig (einschließlich des Tray-Symbols).

2. Öffnen Sie %APPDATA%\Claude\claude_desktop_config.json. Erstellen Sie die Datei, falls sie nicht vorhanden ist. Wenn sie bereits ein mcpServers-Objekt enthält, fügen Sie nur den untenstehenden Eintrag robot-nxt-control hinzu.

3. Speichern Sie die Datei und starten Sie Claude Desktop erneut. Der Server sollte unter Einstellungen → Entwickler → MCP-Server erscheinen.

{
  "mcpServers": {
    "robot-nxt-control": {
      "command": "C:\\Users\\lukas\\workspace\\NXT-MCP\\.venv\\Scripts\\robot-nxt-control-mcp-stdio.exe",
      "cwd": "C:\\Users\\lukas\\workspace\\NXT-MCP"
    }
  }
}

Dieselbe kopierfertige Konfiguration finden Sie in packaging/claude-desktop/mcp.json.

Codex desktop

Der Host von Codex desktop und die Codex-CLI verwenden die gemeinsame MCP-Konfiguration in %USERPROFILE%\.codex\config.toml. Fügen Sie diesen Block hinzu (oder führen Sie den entsprechenden Befehl codex mcp add unten aus) und starten Sie dann die Codex-App neu:

[mcp_servers.robot-nxt-control]
command = "C:\\Users\\lukas\\workspace\\NXT-MCP\\.venv\\Scripts\\robot-nxt-control-mcp-stdio.exe"
cwd = "C:\\Users\\lukas\\workspace\\NXT-MCP"
startup_timeout_sec = 10
tool_timeout_sec = 120

PowerShell-Alternative:

codex mcp add robot-nxt-control -- C:\Users\lukas\workspace\NXT-MCP\.venv\Scripts\robot-nxt-control-mcp-stdio.exe
codex mcp list

Für die ChatGPT-Desktop-MCP-Benutzeroberfläche: Einstellungen → MCP-Server → Server hinzufügen, wählen Sie STDIO, geben Sie robot-nxt-control ein, verwenden Sie dieselbe ausführbare Datei wie beim Befehl, speichern Sie und starten Sie dann die App neu. Lokale Codex-Clients unterstützen sowohl STDIO als auch Streamable HTTP und verwenden diese MCP-Konfiguration gemeinsam. Offizielle OpenAI-MCP-Dokumentation

Erste Prüfung

Öffnen Sie einen neuen Chat und fragen Sie nach nxt_info. Wenn keine Verbindung hergestellt werden kann, prüfen Sie zuerst mit ./.venv/Scripts/nxt-test.exe --log-level=debug, ob der Roboter funktioniert; stellen Sie dann sicher, dass jeder konfigurierte Pfad existiert und der NXT eingeschaltet ist. Bewegungswerkzeuge steuern echte Hardware: Beginnen Sie mit nxt_info oder query_all_state und verwenden Sie dann niedrige Leistung und begrenzte Bewegungsbefehle.

MCP-Transports, Hosts und Verifikation

Dieselbe create_server()-Factory unterstützt beide Transports. robot-nxt-control-mcp-stdio ist der lokale Prozess-Transport für Claude Desktop, Claude Code, Codex CLI, Codex desktop und lokale Codex-Plugins. Er schreibt Protokollverkehr nur nach stdout.

Verwenden Sie das mitgelieferte JSON als Ausgangskonfiguration und ersetzen Sie den absoluten Arbeitsbereichspfad, nachdem Sie den Checkout verschoben haben:

• Claude Desktop: packaging/claude-desktop/mcp.json

• Claude Code plugin: packaging/claude-code/

• Codex local plugin: C:\Users\lukas\plugins\robot-nxt-control (erstellt im persönlichen Marketplace)

Für Protokolltests starten Sie Streamable HTTP auf Loopback:

.\.venv\Scripts\robot-nxt-control-mcp-http.exe --port 8000
npx @modelcontextprotocol/inspector --cli http://127.0.0.1:8000/mcp --method tools/list
npx @modelcontextprotocol/conformance server --url http://127.0.0.1:8000/mcp --suite active

Führen Sie die Repository-Prüfungen mit .\.venv\Scripts\python.exe -m pytest aus. Sie umfassen eine prozessinterne MCP-Aushandlung, einen tools/list-, Annotations- und tools/call-Test sowie Controller- und Verhaltenstests. conformance-baseline.yml erfasst nur generische Szenarien, die optionale MCP-Funktionen erfordern, die dieser fokussierte Hardware-Server nicht bewirbt; jeder Eintrag ist eine Burn-down-Assertion, sodass der Runner veraltete Einträge markiert.

robot-nxt-control-mcp-http bindet standardmäßig an 127.0.0.1 und verweigert die Bindung an Nicht-Loopback-Adressen, sofern nicht NXT_MCP_ALLOW_REMOTE=true ausdrücklich gesetzt ist. Ein Cloud-Client kann einen USB-NXT nicht direkt erreichen: Führen Sie diesen Server neben dem Roboter aus und platzieren Sie einen Produktions-HTTPS-Reverse-Proxy mit OAuth-/Token-Validierung, Autorisierung, Audit-Logs und Netzwerkbeschränkungen vor dem Streamable-HTTP-Endpunkt. Machen Sie den USB-Steuer-Endpunkt niemals nur mit der Umgebungsüberschreibung öffentlich.

Siehe ARCHITECTURE.md für das Moduldesign, die MCP- und Verhaltensausführungsabläufe, den USB-Stack, das Sicherheitsmodell und die Mermaid-Diagramme.

Installation unter Windows 11

Verwenden Sie Python 3.11 x64. In PowerShell:

py -3.11 -m venv .venv
.\.venv\Scripts\python.exe -m pip install --upgrade pip
.\.venv\Scripts\python.exe -m pip install -e ".[test]"

1. NXT-Gerätetreiber mit Zadig installieren

Schalten Sie den NXT ein und verbinden Sie ihn per USB. Bestätigen Sie in PowerShell, dass Windows das Gerät im Normalmodus erkennt:

Get-PnpDevice -PresentOnly |
  Where-Object InstanceId -match 'VID_0694&PID_0002' |
  Format-List Status,FriendlyName,InstanceId,Problem

Die Hardware-ID muss USB\VID_0694&PID_0002 enthalten. Wenn Problem den Wert CM_PROB_FAILED_INSTALL hat oder der Geräte-Manager Code 28 anzeigt, fehlt der Treiber.

1. Laden Sie Zadig nur von https://zadig.akeo.ie/ herunter.

2. Führen Sie Zadig als Administrator aus.

3. Wählen Sie Optionen > Alle Geräte auflisten.

4. Wählen Sie den Eintrag, dessen USB-ID exakt 0694:0002 ist. Verwenden Sie die ID, nicht nur den angezeigten Gerätenamen.

5. Wählen Sie WinUSB im Treiberauswahlfeld.

6. Klicken Sie auf Treiber installieren oder Treiber ersetzen.

7. Trennen Sie den NXT und verbinden Sie ihn wieder, während er eingeschaltet bleibt.

Wählen Sie nicht 03EB:6124; das ist der NXT-Bootloader-/Firmware-Update-Modus. Ersetzen Sie keine Treiber für ein nicht zugehöriges USB-Gerät. Die Installation von WinUSB kann verhindern, dass die alte LEGO-NXT-G-Software mit dem Brick kommuniziert, bis ihr LEGO-/Fantom-Treiber wiederhergestellt ist.

2. Die x64-libusb-Laufzeit für PyUSB installieren

WinUSB ist der Windows-Gerätetreiber. PyUSB benötigt zusätzlich die libusb-1.0.dll im Benutzerraum. Das Repository enthält ein Hilfsprogramm, das das offizielle libusb-1.0.30-Archiv herunterlädt, dessen SHA-256 prüft und die VS2022-x64-DLL neben der python.exe dieser Umgebung installiert:

.\scripts\install-libusb-runtime.ps1

Das Hilfsprogramm benötigt 7z.exe im PATH. Für die manuelle Installation laden Sie libusb-1.0.30.7z aus dem offiziellen libusb-GitHub-Release herunter, extrahieren Sie VS2022\MS64\dll\libusb-1.0.dll und kopieren Sie diese nach .venv\Scripts\libusb-1.0.dll. Verwenden Sie keine MS32-DLL mit 64-Bit-Python.

Überprüfen Sie die Laufzeit unabhängig:

$env:PATH = "$PWD\.venv\Scripts;$env:PATH"
.\.venv\Scripts\python.exe -c "import usb.backend.libusb1 as b; assert b.get_backend() is not None; print('libusb OK')"

Der MCP-Server fügt eine DLL, die neben dem Python seiner virtuellen Umgebung installiert ist, automatisch zu seinem eigenen Suchpfad hinzu. nxt-test.exe ist ein externer NXT-Python-Befehl; führen Sie daher entweder zuerst die $env:PATH-Zeile oben aus oder aktivieren Sie die virtuelle Umgebung, bevor Sie ihn verwenden.

3. Den Brick testen

Überprüfen Sie die Hardware vor der MCP-Verwendung:

.\.venv\Scripts\nxt-test.exe --log-level=debug

Ein erfolgreicher Test gibt den Brick-Namen, den Batteriestand, die Protokollversion und die Firmwareversion aus. Wenn weiterhin kein Brick gemeldet wird, überprüfen Sie das Gerät 0694:0002 erneut im Geräte-Manager und bestätigen Sie, dass sein Treiber WinUSB ist.

Firmware

Keine Firmware-Installation oder -Aktualisierung ist erforderlich, wenn der NXT normal startet und Windows VID 0694 / PID 0002 anzeigt. Der MCP-Server verwendet standardmäßige NXT-Direktbefehle und meldet die installierte Firmware- und Protokollversion über nxt_info.

Führen Sie eine Firmware-Wiederherstellung nur durch, wenn der Brick nicht normal starten kann und Windows stattdessen VID 03EB / PID 6124 anzeigt, den Atmel-SAM-BA-Firmware-Update-Modus. Die Wiederherstellung löscht und überschreibt die Brick-Firmware und liegt außerhalb des normalen MCP-Setups:

1. Installieren Sie die normale NXT-WinUSB-Regel nicht für 03EB:6124.

2. Stellen Sie den Firmware-Update-Treiber wieder her bzw. verwenden Sie ihn, den die originale LEGO-MINDSTORMS-NXT-Software benötigt.

3. Verwenden Sie in dieser Software Extras > NXT-Firmware aktualisieren mit einem offiziellen NXT-Firmware-Image.

4. Schalten Sie den Brick nach der Wiederherstellung aus und wieder ein. Er muss als 0694:0002 zurückkehren; installieren Sie dann bei Bedarf WinUSB für dieses Gerät im Normalmodus erneut.

NXT-Python bietet bewusst kein Firmware-Flashen an. Ruf en Sie den Firmware-Bootmodus nicht auf und versuchen Sie keine Aktualisierung, nur um NoBackendError, Code 28 oder einen MCP-Verbindungsfehler zu beheben.

Öffnen Sie dann den MCP Inspector:

.\.venv\Scripts\mcp.exe dev src\nxt_mcp\server.py

Konfigurieren Sie für einen lokalen MCP-Host einen Stdio-Server mit dem Befehl .venv\Scripts\robot-nxt-control-mcp.exe und dem Repository als Arbeitsverzeichnis.

Deklarieren Sie die am Brick angeschlossenen Sensoren, bevor Sie den Server starten, damit der Snapshot des gesamten Bricks sofort typisierte Messwerte zurückgeben kann:

$env:NXT_SENSOR_MAP = "1:touch,2:light,4:ultrasonic"
.\.venv\Scripts\robot-nxt-control-mcp.exe

Auch der Aufruf von read_sensor oder eines sensorgesteuerten Motorbefehls merkt sich den Typ dieses Ports für spätere Snapshots.

High-Level-Werkzeuge

• move_motor_relative(port="C", power=40, degrees=2000) bewegt C um 2000 Encoder-Grad nach vorn. Verwenden Sie negative Leistung für die entgegengesetzte Richtung. Der Adapter verwendet eine enge USB-Encoder-Schleife, da die standardmäßige turn()-Schleife von NXT-Python für kleine Bewegungen zu langsam abfragt. Verwenden Sie für Bewegungen um 45 Grad eine niedrigere Leistung, z. B. 20.

• zero_motor_position(port="C") definiert die aktuelle C-Encoderposition als absoluten Nullpunkt 0. move_motor_absolute(port="C", target_degrees=-90, power=20) bewegt sich dann auf -90. Bei absoluten Bewegungen wird die Richtung aus dem Ziel abgeleitet; power ist ein positiver Betrag.

• motor_position(port="C") meldet die absolute/programmrelative Encoderposition und die rohen Tacho-Zähler.

• run_motor(port="C", power=-30) läuft kontinuierlich in negativer Richtung, bis ein Stoppbefehl oder ein begrenztes Verhalten ihn stoppt. Mit regulated=true ist power die geregelte NXT-Geschwindigkeitseinstellung, kein kalibrierter Wert in Grad pro Sekunde.

• run_motors(ports=["B", "C"], powers=[30, -30]) startet eine Motorgruppe in einem einzigen MCP-Aufruf. stop_motors, move_motors_relative und move_motors_absolute arbeiten auf dieselbe Weise mit Gruppen. Listen sind positionsbezogen: Jeder Leistungs-/Gradwert gehört zu dem Port am selben Index.

• run_motor_until_sensor(port="B", power=40, sensor_port=1, sensor_type="touch", condition="pressed") lässt B laufen, bis der Tastsensor S1 gedrückt ist.

• run_motors_until_sensor(ports=["B", "C"], powers=[40, 40], sensor_port=4, sensor_type="ultrasonic", condition="lte", threshold=20) fährt beide Motoren, bis ein Hindernis höchstens 20 cm entfernt ist, und stoppt dann die gesamte Gruppe.

• run_motor_until_sensor(port="B", power=40, sensor_port=4, sensor_type="ultrasonic", condition="lte", threshold=20) lässt B laufen, bis ein Hindernis höchstens 20 cm entfernt ist.

• query_all_state(format="text") gibt einen kompakten Text-Snapshot des Bricks, aller Motorports und aller Sensorports zurück. Verwenden Sie format="json" für strukturierte Daten.

• cycle_motor_on_touch(port="C", touch_port=1, cycles=5) fährt vorwärts, bis S1 gedrückt wird, fährt rückwärts, bis es losgelassen wird, wiederholt das fünfmal und piept nach Erfolg. Jede Druck- und Loslassphase hat ihr eigenes Zeitlimit und eine eigene Encoderweg-Obergrenze.

Jede sensorgesteuerte Bewegung hat ein Zeitlimit und eine Encoderweg-Grenze. Wird eine der beiden Grenzen erreicht, stoppt der Motor und gibt ok: false mit dem Grund zurück. Der Motor wird auch gestoppt, wenn ein Sensor- oder USB-Lesevorgang fehlschlägt.

Erweiterte Diagnose, Speicher und Telemetrie

• motor_state(port) meldet Regelungsmodus, Betriebszustand, Tachowerte und den konfigurierten Ausgangszustand. drive_sync(left_port, right_port, power, turn_ratio=0) verwendet die Sync-Regelung der NXT-Firmware für ein Paar mit Differenzialantrieb; wait_motors(...) hat ein Zeitlimit und stoppt bei Zeitüberschreitung seine Ports.

• read_sensor_raw(port, sensor_type?), wait_sensor(...) und sensor_stream(...) stellen begrenzte Diagnosen, entprellte Sensorwartevorgänge und endliche Stichproben bereit.

• Rufen Sie für Licht-, Farb- und Ultraschallsensoren zero_sensor_reference(port, sensor_type) und dann read_sensor_relative(port, sensor_type) auf. Der Rückgabewert ist die Änderung gegenüber dem erfassten Nullpunkt plus der absolute Wert. Bei Farbe wird die Intensität des reflektierten Lichts verwendet (nicht das diskrete Rot/Blau/usw.-Label), damit die Subtraktion sinnvoll ist.

• log_start, log_status, log_stop und log_export stellen begrenzte hostseitige CSV-Telemetrie bereit. Gültige Kanäle sind battery_mv, motor:A bis motor:C und sensor:1:touch (oder ein anderer unterstützter Sensortyp/Port).

• list_files, read_file, write_file und delete_file verwalten begrenzte NXT-Benutzerdateien. Schreibvorgänge sind auf .txt, .csv, .dat und .rso beschränkt; die Tonwiedergabe verwendet play_sound_file(name) und stop_sound().

• mailbox_send / mailbox_receive unterstützen Nachrichten bis zu 58 UTF-8-Bytes; i2c_transaction ist eine optional aktivierbare langsame Operation, die auf 16-Byte-Anfrage- und Antwortnutzdaten begrenzt ist. set_brick_name und keep_alive sind die unterstützten administrativen Direktbefehle.

Das Standard-NXT-Direktbefehlsprotokoll kann nicht auf das NXT-LCD zeichnen oder dessen Tasten lesen. Diese NXT-G/ROBOTC-Funktionen erfordern ein separat installiertes, auf dem NXT laufendes Brückenprogramm; sie werden von diesem Server bewusst nicht bereitgestellt.

Semantik der Motorpositionierung

NXT-Encoderzählwerte sind Grad an der Motorwelle, nicht Grad der Roboterausrichtung oder lineare Millimeter. Übersetzungsverhältnisse, Radumfang und Radschlupf müssen von einem Roboter-Verhalten berücksichtigt werden, wenn physikalische Einheiten benötigt werden.

Der absolute Nullpunkt wird vom programmrelativen Rotationszähler der NXT-Firmware gehalten. Er ist kein Referenzsensor und nicht persistent: Das Aus- und Einschalten des NXT-Steins oder das Starten/Stoppen eines .rxe-Programms macht die Referenz ungültig. Referenzieren Sie gegen einen Tastsensor und rufen Sie zero_motor_position erneut auf, bevor Sie sich auf absolute Zielpositionen verlassen.

Gruppenbefehle starten Motoren mithilfe aufeinanderfolgender USB-Pakete innerhalb einer einzigen Controller-Sperre. Sie vermeiden den MCP/LLM-Roundtrip-Versatz und überwachen alle Encoder gemeinsam, sind aber nicht hart echtzeitfähig oder mechanisch phasenverriegelt. Für einen Zweirad-Roboter ist dies für normales Fahren geeignet; für eine präzise Synchronisation ist möglicherweise ein auf dem NXT laufendes Steuerprogramm erforderlich.

Einschränkung der Hardwaremeldung

Die NXT-Firmware meldet den konfigurierten Zustand jedes Ports, kann aber nicht sicher feststellen, ob ein nicht angesteuerter Motor physisch angeschlossen ist. Die Abfrage des gesamten NXT-Steins meldet daher alle A/B/C-Firmwarezustände, statt das Vorhandensein von Motoren zu behaupten. Sensorports, die bereits durch read_sensor oder einen sensorgesteuerten Befehl konfiguriert wurden, zeigen typisierte Werte; andere Sensorports zeigen ihren rohen Firmwarezustand. Das Abfragen des Rohzustands konfiguriert Ports nicht neu und bestromt Hardware nicht kurzzeitig.

Verwenden Sie keine direkten MCP-Motorbefehle, während ein .rxe-Programm dieselben Ports steuert.

PC-seitige Python-Verhaltensweisen über MCP

Der Standard-NXT führt kein Python aus. Dieser Server kann stattdessen eingeschränkte Python-Verhaltensweisen auf dem PC speichern und ausführen; jeder Robotervorgang überschreitet weiterhin die Controller-Nahtstelle, sodass Skripte kein USB öffnen, keine NXT-Python-Sensoren instanziieren und keine eigenen Polling-Schleifen implementieren.

Beispielverhalten:

def run(robot):
    robot.configure_sensor(1, "touch")

    for _ in range(5):
        robot.motor_until("C", 20, 1, "pressed")
        robot.motor_until("C", -20, 1, "released")

    robot.play_tone(440, 500)
    return "completed 5 touch cycles"

Dasselbe Beispiel ist als behaviors/touch_cycle.py enthalten. Verwenden Sie diese MCP-Werkzeuge:

validate_behavior(source)
submit_behavior(name, source)
list_behaviors()
get_behavior(name)
run_behavior(name, timeout_seconds=120)

Die für Skripte sichtbare robot-Schnittstelle enthält:

configure_sensor(port, sensor_type)
read_sensor(port, sensor_type)
read_sensor_raw(port, sensor_type=None)
zero_sensor_reference(port, sensor_type)
read_sensor_relative(port, sensor_type)
wait_sensor(port, sensor_type, condition, ...)
sensor_stream(port, sensor_type, ...)
log_start(channels, interval_ms=100, duration_seconds=10)
log_status(job_id)
log_stop(job_id)
log_export(job_id)
motor_until(port, power, sensor_port, condition, sensor_type="touch", ...)
motor_for_ticks(port, power, ticks, ...)
motor_position(port)
zero_motor_position(port)
motor_to(port, target_degrees, power=20, ...)
run_motor(port, power, regulated=True)
drive_sync(left_port, right_port, power, turn_ratio=0)
wait_motors(ports, ...)
stop_motor(port, brake=False)
run_motors(ports, powers, regulated=True)
stop_motors(ports, brake=False)
motors_relative(ports, powers, degrees, ...)
motors_absolute(ports, powers, target_degrees, ...)
motors_until(ports, powers, sensor_port, condition, ...)
state(format="text")
play_tone(frequency_hz=440, duration_ms=500)
play_sound_file(name, loop=False)
stop_sound()
sleep(seconds)

Importe, Klassen, Ausnahmebehandlung, Zugriff auf private Attribute und Aufrufe außerhalb der dokumentierten Roboter-Methoden und der grundlegenden eingebauten Funktionen werden abgelehnt. Skripte sind auf 64 KiB begrenzt, es kann jeweils nur eines laufen, und run_behavior akzeptiert ein Zeitlimit von 1–300 Sekunden. Alle Motoren werden gestoppt, wenn ein Skript endet oder eine Ausnahme auslöst.

Diese Validierung soll versehentlichen Zugriff außerhalb der Roboter-Schnittstelle verhindern; sie ist keine Sicherheits-Sandbox für bösartigen Code. Gewähren Sie MCP-Zugriff nur vertrauenswürdigen lokalen Benutzern. Setzen Sie NXT_BEHAVIOR_DIR vor dem Start des Servers, um Verhaltensweisen an einem anderen Ort als dem Standardverzeichnis behaviors im Arbeitsverzeichnis des Servers zu speichern.

Für eine Befehlszeilen-Demonstration, die weiterhin MCP stdio verwendet, statt den Controller direkt zu importieren:

.\.venv\Scripts\python.exe scripts\mcp-behavior-client.py list
.\.venv\Scripts\python.exe scripts\mcp-behavior-client.py submit touch_cycle behaviors\touch_cycle.py
.\.venv\Scripts\python.exe scripts\mcp-behavior-client.py run touch_cycle --timeout 120

Der letzte Befehl führt eine physische Bewegung aus. Der Client ruft nur MCP-Werkzeuge auf; der MCP-Server lädt das Verhalten und besitzt die gesamte NXT-Kommunikation.

Test ohne NXT-Stein

$env:PYTHONPATH = "src"
py -3.11 -m pytest