.

AGENTS.md

@@ -1,88 +1,58 @@
-# AGENTS.md
-
-## Ziel der Datei
-Dieses Dokument beschreibt, welche Informationen ich als Agent für `p:\netwatch` erwarten würde: Projektziel, Setup, Regeln, Skills, bekannte Issues, Kontext & Einschränkungen.
+# AGENTS.md
 
 ## Ziel
-Codex soll bei der Pflege von `NEXT_STEPS.md` immer die zugehörigen Gitea-Issues berücksichtigen und erledigte Aufgaben über Commit-Messages schließen.
+Codex arbeitet pragmatisch bei Aufgaben aus `NEXT.md` und User-Requests.
+Ein Gitea-Issue ist optional.
 
-## Projektüberblick
-- Name: **netwatch** – ein Netzwerk-Dokumentations- und Verkabelungsverwaltungs-Tool (Alpha v0.2, Core-Module funktionsfähig, Stand: 13. Februar 2026).
-- Features: Dashboard, Gerätetypen-/Geräteverwaltung, Racks/Floors mit SVG-Planung, Verbindungen inkl. VLANs, Module, grafische Ansichten (Rack, Netzwerkgraph, Stockwerke/Räume).
-- Datenmodell: zentrales SQL-Schema (`locations`, `device_types`, `devices`, `connections` etc.) mit JSON-Erweiterungsmöglichkeiten.
-- Projektphasen (Phase 1–4) sind im README gelistet, siehe letzte Abschnitte.
+## Kernregeln
 
-## Schneller Projektstart
-```powershell
-docker-compose up -d --build
-# danach: http://localhost
-```
-Das Docker-Setup (Compose + Portainer) liegt in `docker-compose.yml` und `docker-portainer.yml`, ergänzende Infos in `Dockerfile`.
+1. Ein Issue ist **nicht erforderlich**, um eine Aufgabe umzusetzen.
+2. Skills duerfen jederzeit verwendet werden (z. B. `gitea-issues`).
+3. Ein `NEXT.md`-Punkt darf erst auf erledigt (`[x]`) gesetzt werden, wenn die Umsetzung im Code erfolgt ist.
+4. Nur wenn ein Gitea-Issue konkret referenziert ist **und** durch die Aenderung abgeschlossen wird, muss die Commit-Message `closes #<id>` enthalten.
+5. Jede `closes`-Referenz steht in einer **eigenen Zeile**.
+6. Kein `closes #<id>`, wenn das Issue nicht tatsaechlich abgeschlossen ist.
+7. `git push` nur auf explizite Aufforderung; standardmaessig nur committen.
 
-## Verbindliche Regeln
-1. Vor jeder Änderung an `NEXT_STEPS.md` müssen offene Issues geladen werden.
-2. Jeder umsetzbare Punkt in `NEXT_STEPS.md` muss eine Issue-Referenz im Format `[#<id>]` enthalten.
-3. Ein Punkt darf nur als erledigt markiert werden, wenn:
-   - die Umsetzung im Code erfolgt ist, und
-   - ein Commit mit `closes #<id>` erstellt wird.
-4. Kein „done“ ohne Issue-ID und kein Commit ohne passende `closes #<id>`-Referenz.
-5. Wenn mehrere Issues betroffen sind, alle in der Commit-Message aufführen (z. B. `closes #12, closes #18`).
-6. Beim Erstellen neuer NEXT_STEPS-Punkte sollen möglichst bestehende offene Issues verlinkt statt Duplikate erzeugt werden.
+## Verbindlicher Ablauf
 
-## Workflow für Codex
-1. Offene Issues abrufen (Skill `gitea-issues`):
+1. Aufgabe umsetzen (aus `NEXT.md` oder User-Anfrage).
+2. Optional Issues laden, wenn Kontext/Zuordnung noetig ist:
    - `python C:/Users/s.titz/.codex/skills/gitea-issues/scripts/list_issues.py <owner> <repo> --state open --limit 100 --json`
-2. `NEXT_STEPS.md` aktualisieren:
-   - Punkte mit `[#<id>]` ergänzen oder korrigieren.
-3. Umsetzung durchführen.
-4. Commit mit Schließ-Referenz erstellen:
-   - `git commit -m "Kurzbeschreibung der Änderung; closes #<id>"`
-5. Prüfen, dass jede als erledigt markierte Aufgabe eine geschlossene Issue-Referenz hat.
+3. `NEXT.md` bei Bedarf aktualisieren (mit oder ohne `[#<id>]`).
+4. Commit erstellen.
+5. Wenn Issue abgeschlossen wird, Commit-Message mit eigener `closes`-Zeile schreiben.
 
-## Formatvorgabe für NEXT_STEPS.md
-- Beispiel offen:
-  - `- [ ] [#42] Backup-Runbook erstellen`
-- Beispiel erledigt:
+## Commit-Format bei Issue-Abschluss
+
+Beispiel mit einem Issue:
+
+```text
+Kurzbeschreibung der Aenderung
+
+closes #42
+```
+
+Beispiel mit mehreren Issues:
+
+```text
+Kurzbeschreibung der Aenderung
+
+closes #12
+closes #18
+```
+
+## Format fuer NEXT.md
+
+- Offen ohne Issue:
+  - `- [ ] //TODO Backup-Runbook erstellen`
+- Offen mit Issue:
+  - `- [ ] [#42] //TODO Backup-Runbook erstellen`
+- Erledigt mit Issue:
   - `- [x] [#42] Backup-Runbook erstellen`
+- Erledigt ohne Issue:
+  - `- [x] Backup-Runbook erstellen`
 
-## Annahmen
-- Gitea ist so konfiguriert, dass `closes #<id>` in Commit-Messages das Issue schließt.
-- `GITEA_TOKEN` ist gesetzt, damit Issue-Abfragen funktionieren.
+## Annahme
 
-## Skills & Nutzungshinweise
-- **skill-creator** – Anleitung zum Erstellen bzw. Erweitern eigener Skills. Pfad: `C:/Users/s.titz/.codex/skills/.system/skill-creator/SKILL.md`.
-- **skill-installer** – Anleitung zum Installieren zusätzlicher Skills aus Kurationslisten oder GitHub. Pfad: `C:/Users/s.titz/.codex/skills/.system/skill-installer/SKILL.md`.
-
-Wenn ein Skill genannt wird (z. B. `$skill-creator`) oder die Aufgabe exakt zur Beschreibung passt, muss dieser Skill in dem Turn verwendet werden. Skills immer erst öffnen (`SKILL.md`), nur nötige Teile lesen, relative Pfade innerhalb des Skill-Verzeichnisses auflösen. Bei mehreren Skills: minimaler Satz in sinnvoller Reihenfolge, kurz ankündigen, warum welche Skills genutzt wurden.
-
-## Lokale Arbeitsregeln
-- Arbeitsumgebung: Windows, Pfad `P:\netwatch`, Shell `powershell`. Schreibzugriff für mich hier ist verboten; Änderungen müssen vom Nutzer übernommen werden.
-- Suche: Nutze `rg`/`rg --files` statt `grep`/`find` für Geschwindigkeit.
-- Codeänderungen: Nur ASCII-Zeichen einführen (außer bestehende Dateien nutzen Unicode); Formate ohne `apply_patch` nur wenn nötig; bevorzuge `apply_patch`.
-- Keine destruktiven Git-Befehle ohne ausdrückliche Aufforderung (z. B. keinen `reset --hard`).
-- Tests/Builds: Wenn nötig, nenne passende Tests/Prüfmethoden als nächsten Schritt.
-- Kommunikation: Verwende beim Antworten absolute Datumsangaben (z. B. „13. Februar 2026“), wenn sich jemand auf „heute/morgen“ bezieht, um Missverständnisse zu vermeiden.
-
-## Bekannte Bugs (aus `BUGS.md`)
-- Gerät löschen funktioniert nicht (Status unklar).
-- Gerätetypen SVG-Modul: Malfunktion.
-- Ports Drag & Drop (Funktion unklar).
-- Beim Erstellen von Gerätetypen soll ein voreingestelltes Rechteck basierend auf 19-Zoll & HE-Größe erzeugt werden, das als Grundgerüst dient.
-- Device-Typ-Erstellung: Klick auf Objekt-Typ-Button, dann Drag-Drop für Diagonale und Loslassen fixiert Position.
-
-## Weitere Ressourcen
-- `NEXT_STEPS.md` (aktuelles ToDo/Roadmap).
-- `IMPLEMENTATION_STATUS.md` (Status-Tracking).
-- `README.md` (Feature- und Architekturübersicht).
-
-## Besonderheiten / Kommunikation
-- Aktuelles Datum: Freitag, 13. Februar 2026 (nicht überschreiben).
-- Keine Netzwerkanfragen möglich; Referenzen nur lokal nutzen.
-- Wenn ein Agent spezielle Instruktionen benötigt (z. B. Skill-Anwendung), immer darauf hinweisen und ggf. den Nutzer nach Bestätigung fragen.
-
-## Einschränkungen
-- Sandbox ist lesend; bitte selbst `AGENTS.md` anlegen.
-- Jegliche Ausgaben/Antworten sollten den Developer-Guidelines folgen (kurz, teamorientiert, klare nächste Schritte).
-
-## Wichtig
-- Nutze UTF-8, wenn nicht anders angegeben.
+- Gitea ist so konfiguriert, dass `closes #<id>` in Commit-Messages das Issue schliesst.

BUGS.md

@@ -1,3 +0,0 @@
-# gefundene bugs
-- [ ] device löschen geht nicht
-- [ ] TODO Design vereinheitlichen

TODO.md

@@ -1,36 +0,0 @@
-# TODO
-
-Bereinigte und aktuelle TODO-Liste (Stand: 18. Februar 2026).
-Quelle: vorhandene `TODO`-Marker im Repository plus offene Architekturpunkte.
-
-## Erledigt (bereits umgesetzt)
-
-- [x] API-Basis umgesetzt (`app/api/connections.php`, `app/api/device_type_ports.php`, `app/api/upload.php`).
-- [x] Bootstrap/Auth/Config/Routing-Grundlagen umgesetzt (`app/config.php`, `app/bootstrap.php`, `app/lib/_sql.php`, `app/lib/auth.php`, `app/index.php`).
-- [x] Frontend-Grundlagen aktualisiert (`app/assets/js/app.js`, `app/assets/js/dashboard.js`, `app/assets/js/svg-editor.js`, `app/assets/js/network-view.js`).
-- [x] Delete-Flow fuer zentrale Module umgesetzt (`buildings`, `floors`, `racks`, `device_types`, `floor_infrastructure`).
-- [x] Legacy-Mock in `app/modules/device_types/ports.php` ersetzt.
-- [x] Veraltete Sammel-TODO-Liste (nicht mehr im Code vorhanden) entfernt.
-
-## Offen (direkt im Code markiert)
-
-- [x] `app/modules/dashboard/list.php`: zoombare/verschiebbare SVG-Wand mit klickbaren Punkten und Overlay-Drilldown umgesetzt.
-- [x] `app/modules/connections/list.php`: Detailbereich fuer ausgewaehlte Verbindung inkl. Bearbeiten/Loeschen im UI umgesetzt.
-- [x] `app/lib/helpers.php`: konkrete allgemeine Helper ergaenzt (`formatDateTime`, `formatBytes`, `generateUuidV4`, `normalizeSvgCoordinate`).
-
-## Offen (Bugs / Doku / Statusdateien)
-
-- [ ] `BUGS.md`: Design vereinheitlichen.
-- [x] `IMPLEMENTATION_STATUS.md`: Delete-Funktionen-Status aktualisiert.
-- [x] `IMPLEMENTATION_STATUS.md`: Auth-Status aktualisiert.
-- [x] `README.md`: Patchpanel-Infrastruktur-Status nachgezogen.
-- [x] `README.md`: SVG-Editor-Status fuer Floor-Infrastruktur nachgezogen.
-- [x] `doc/DATABASE.md`: Statusabschnitt fuer Patchpanel/Floorplan finalisiert.
-- [x] `init.sql`: Port-Konfigurationsregeln konkretisiert.
-
-## Topologie-Backlog (ausstehend)
-
-- [x] `connections.port_a_type` / `connections.port_b_type` um `patchpanel` erweitert und auf `floor_patchpanel_ports.id` nutzbar gemacht.
-- [ ] Validierungsregeln fuer Topologie fest verdrahten (Patchpanel-Port nur mit Patchpanel-Port oder Netzwerkbuchsen-Port).
-- [x] Port-CRUD fuer Patchpanels: `floor_patchpanel_ports` wird aus `port_count` erzeugt/synchronisiert.
-- [x] Port-CRUD fuer Netzwerkbuchsen: `network_outlet_ports` wird gepflegt (mindestens ein Port je Buchse) und ist in Verbindungen nutzbar.