Richard/Deploymentcenter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
53 Commits 1 Branch 0 Tags
087f4392a946c7e95a99c7f6eb5fcf1bd76cb352
Commit Graph
5 Commits
Author SHA1 Message Date
Deploymentcenter BotandClaude Opus 5 0e93345ab8 fix(2.8.1): Sechs Befunde, eine Bauart - die Voreinstellung, die einsprang 
Drei Agenten haben von aussen gemeldet, und fast jeder Befund hat dieselbe
Form: Irgendwo sprang ein Vorgabewert ein, obwohl die richtige Antwort
bekannt war - meist das Projekt, an das der Aufrufer ohnehin gebunden ist.

#351  manage?action=next antwortete durchgaengig mit HTTP 500. In
      BugRepo::buildFilter() stand :project_scope zweimal in derselben
      Anweisung; mit ATTR_EMULATE_PREPARES=false bindet PDO jeden Namen
      genau einmal - zwei Marker, ein Wert, SQLSTATE[HY093]. Getroffen war
      nur "next", weil nur dort der Rueckkanal-Filter gesetzt wird. Damit
      gab es keine exklusive Uebernahme. Es ist der VIERTE Fall dieser
      Bauart, deshalb prueft scripts/pruefe_platzhalter.py das jetzt
      mechanisch vor jedem Ausliefern.

#382  Meldungen ohne project_slug landeten im Scheinprojekt "default" -
#387  ohne dc_projects-Zeile, also project_id NULL. Die Antwort sah wie ein
#397  Erfolg aus, und danach sperrte dieselbe Token-Bindung den Zugriff
      (403 project_forbidden). Der Rueckfall aufs Heimatprojekt war an
      !isWorkbench gebunden; ein Werkbank-Token ohne Slug bekam gar keinen
      Vorgabewert. Jetzt: genannter Slug, sonst Heimatprojekt, sonst 400.
      Ein unbekanntes Projekt wird abgewiesen statt still angelegt.

#364  Ohne project_slug lieferten list, stats und die Roadmap ALLE
#176  Projekte statt des eigenen, weil die Vorgabe auf "all" stand und ein
      Werkbank-Token beim Lesen absichtlich nicht unter die Schranke faellt.
      Gemessen: 393 Items, davon 28 eigene. Ausgerechnet der erste Aufruf
      jeder Sitzung. Die Roadmap antwortet ausserdem schmal - 55 Felder je
      Eintrag waren 628.392 Zeichen und fuellten das Kontextfenster.

#404  Watchdog-Monitore bekamen nie ein Projekt: upsertHeartbeat() wurde
      keines uebergeben, obwohl authorizeSource() die Token-Bindung liest.
      Befunde erbten dadurch "default" - dc_findings(project_slug=...) war
      fuer eine laufende, meldende Instanz leer.

#131  Wo der Leseweg richtig verengte, sagte er es nicht: HTTP 200 mit dem
      umgeschriebenen Filter sieht aus wie eine Auskunft ueber das
      angefragte Projekt. Ein Agent, der vor dem Melden dc_search fragt,
      legt so das Duplikat an. Jetzt scoped_to und scope_note im Umschlag -
      nur bei tatsaechlicher Verengung.

#354  dc-testkit 1.1.0 wurde zweimal mit verschiedenem Inhalt ausgeliefert
      (1898 und 1930 Zeilen), 1.0.0 davor ebenso. Der Absatz ueber
      DC_TESTKIT_VERSION stand die ganze Zeit im Skript und hat nicht
      getragen. Jetzt 1.1.1 plus ein Riegel in deploy.py, der abbricht,
      wenn sich der Inhalt aendert und die Nummer nicht.

Warum die Testsuite all das nicht sah: Ihr Master-Token ist an kein Projekt
gebunden und nimmt deshalb ueberall den anderen Zweig. Es gab sogar einen
Testfall fuer action=next - er lief gruen, waehrend der Aufruf in der Praxis
ausnahmslos scheiterte. Die neuen Faelle benutzen ausdruecklich
projektgebundene Token; testctl kann dafuer jetzt owner_type und scopes
waehlen.

Ausserdem: Die Agentenvorlage nennt fuer die SDK-Fassung dc_link_project
statt einer abgeschriebenen Zahl - "SDK 2.5.1" stand dort als Beispiel und
wurde als Wert uebernommen.

Nicht enthalten: die 20 Altlasten in "default". Sie sind ueber die API nicht
erreichbar; sql/wartung/2026-08-31_default-projekt-aufraeumen.sql liegt dafuer
bereit (alle 20 haben einen titelgleichen Zwilling im richtigen Projekt).

156 e2e-Faelle gruen, davon 9 neue.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-31 20:43:23 +02:00
Deploymentcenter BotandClaude Opus 5 1d5ac92051 feat(2.7.0): Roadmap im DC, Testinstanz mit Testtor, Supervisor und MCP 
Sammelcommit fuer den ueber mehrere Sitzungen gewachsenen, bisher nicht
eingecheckten Stand. Getrennte Commits waeren ehrlicher gewesen, sind es
nachtraeglich aber nicht mehr: BugRepo, changelog.json und die Doku tragen
Aenderungen aus allen Straengen gleichzeitig, und keine Zwischenstufe waere
lauffaehig.

ROADMAP IM DEPLOYMENTCENTER (2.7.0)

Planungsstand, Reihenfolge und Zustaendigkeit lagen in handgepflegten
Markdown-Dateien neben einem Bugtracker, der genau diese drei Dinge bereits
fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war eine Frage der Zeit.

Ab jetzt: Zustand im DC, Begruendung in der Datei. Kein Feld hat zwei Pfleger.

  - Migration 016: epic, roadmap_rank, target_build, defer_trigger,
    doc_anchor, Status "deferred", Tabelle roadmap_epics.
    KEINE Roadmap-Tabelle - ein Eintrag ist ein bugtracker_item.
  - Zugehoerigkeit ist ein Feld: Ein Item steht auf der Roadmap, wenn es ein
    epic hat. Ein zweites Kennzeichen daneben koennte auseinanderlaufen.
  - Kennung ist die Item-ID. Handvergebene Kuerzel ("A12") erzeugen die
    schlimmste Fehlerart: Beide Seiten stimmig, Verschiedenes gemeint, weil
    die Kennung nach einer Loeschung neu vergeben wurde.
  - Zurueckstellen verlangt defer_trigger. Ohne benannten Anlass ist ein
    Vorhaben nicht zurueckgestellt, sondern vergessen. Die Regel sitzt im
    Repository, damit sie auf allen drei Schreibwegen gleich greift.
  - Modules/Bugtracker/Roadmap.php, /api/bugtracker/v1/roadmap.php,
    WebUI-Modul mit Filtern, cli/roadmap.php --write/--check,
    dc_roadmap und dc_roadmap_set im MCP-Adapter.
  - cli/roadmap.php --write ERZEUGT den Zustandsteil der Markdown-Datei;
    --check prueft nur die Prosa. Was erzeugt wird, kann nicht driften.
  - docs/ROADMAP_MIGRATION.md: Uebernahme fuer die anderen Projekte.

TESTINSTANZ UND TESTTOR

  - dc-dev.mhdf.de: zweite Installation, eigene DB, eigene Schluessel,
    Basic-Auth davor, Rocket.Chat aus.
  - 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen, Sperre.
  - scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf
    die Testinstanz und laesst dann den Testlauf laufen. Erst bei
    Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test als Notausgang).
    Andersherum prueft der Lauf aelteren Code als den, der gleich hochgeht.
  - tests/ ist aus dem Produktiv-Deploy ausgeschlossen; testctl.php kann
    nicht versehentlich auf dc.mhdf.de landen.
  - Ein Lauf mit mehr uebersprungenen als geprueften Faellen endet mit
    Rueckgabewert 2 statt 0. Nichts ist kaputt, geprueft wurde es aber auch
    nicht - der Unterschied darf nicht am Rueckgabewert verschwinden.

SUPERVISOR, PROJEKTLANDSCHAFT, NACHPRUEFUNG (2.6.0/2.6.1)

  - Migration 013: projektuebergreifend melden (dev_agent, evidence,
    triage_external, affects).
  - Migration 014: supervisor_findings, Katalog, fuenf serverseitige
    Detektoren im Tick.
  - Migration 015: Nachpruefung als Arbeitsschlange statt Benachrichtigung.
  - DEV-Lizenzschluessel zur Selbstbedienung, dc-testkit fuer die Test-VM.
  - MCP-Adapter: 15 Werkzeuge, ohne Fremdabhaengigkeiten, mit Abgrenzung
    von Fremddaten gegen Prompt-Injektion.

BEHOBEN

  - observe und status im Supervisor legten den Zustand des Befundes als
    "status" in die Antwort. Http::ok() merged ['status' => 'success']
    darunter, also gewann der Befundzustand - eine angenommene Meldung kam
    als status="open" an. Heisst jetzt finding_status. War Item #59.

Migrationen 013-016 sind auf dem Produktivserver noch NICHT ausgefuehrt.
Ohne sie bricht das WebUI, weil die Roadmap-Ansicht bei jedem Seitenaufruf
gegen bugtracker_items.epic abfragt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-29 21:59:20 +02:00
Deploymentcenter BotandClaude Opus 5 e7fbc85db4 fix(security, core): Auth-Pflicht für Ingest-APIs, 500er-Ursachen beheben, Agenten-Workflow 
Sicherheit
- install_db.php war ohne Authentifizierung erreichbar und setzte bei jedem
  Aufruf das Admin-Passwort auf einen fest im Code stehenden Wert zurück.
  Jetzt Auth-Pflicht; ein Konto wird nur bei leerer Benutzertabelle angelegt.
- Stored XSS im Bugtracker-Detail-Modal: Titel, Beschreibung, Fehlermeldung,
  Stacktrace und Kommentare gingen ungefiltert durch innerHTML.
- report.php, projects.php und das Veröffentlichen von Releases verlangen jetzt
  zwingend ein Token. Publish war zuvor völlig ungeschützt.
- CSRF-Token in allen Formularen, Session-Regenerierung nach Login,
  Drosselung fehlgeschlagener Anmeldeversuche.
- Zugangsdaten aus der Versionskontrolle entfernt (Serverdaten.txt,
  config.php, .htpasswd, deploy_config.json). Historie enthält sie weiterhin,
  Rotation erforderlich (siehe docs/UPGRADE.md).
- Token-Validierung nur noch über SHA-256-Hash; expires_at wird ausgewertet.

Behobene 500er
- Audit::log() war in index.php weder eingebunden noch importiert. Jeder
  Klick auf "Aktivierung freigeben" endete in einem Fatal Error.
- Derselbe benannte PDO-Platzhalter mehrfach je Statement (:id in
  revokeToken/deleteToken, :q siebenfach in der Volltextsuche). Bei
  EMULATE_PREPARES=false ist das nicht zulässig und warf HY093.
- Migration 005 nutzte dynamisches SQL, dessen Semikolons in String-Literalen
  vom alten explode(';')-Installer als Statement-Ende gelesen wurden. Sie
  schlug still fehl, wodurch push_id/target_agent/tags dauerhaft fehlten.
- Monitor-Umbenennung ohne Transaktion, verschachtelte Transaktionen im
  RateLimiter.

Funktionale Korrekturen
- Der Watchdog-Evaluator fehlte vollständig: Monitor-Zustände änderten sich nur
  beim Eintreffen eines Heartbeats, ein ausgefallenes System blieb dauerhaft
  "up". Erster Lauf auf dem Produktivsystem: 7 von 10 Monitoren waren
  tatsächlich seit über einem Tag nicht erreichbar.
- Das Feld "os" fehlte im Monitor-Dialog, wurde aber gespeichert und löschte
  damit bei jedem Speichern das Betriebssystem.
- Der Resolve-Dialog existierte im HTML nicht; der Button war funktionslos.
- Versionsvergleich erfolgte lexikografisch, wodurch 1.9.0 als neuer galt
  als 1.10.0.
- Schreiboperationen meldeten Erfolg auch für nicht existierende IDs.
- Post/Redirect/Get gegen doppelte Einträge beim Neuladen.

Neue Struktur
- src/bootstrap.php mit PSR-4-Autoloader ersetzt die require-Ketten.
- Core: Config, Http, Csrf, ApiAuth, Logger, Migrator, ErrorReporter.
- Migrator mit zeichenweisem SQL-Parser, dc_migrations und Baseline-Verfahren,
  damit bestehende Installationen keine Beispieldaten zurückbekommen.

Agenten-Workflow
- Claim/Lease: Items werden exklusiv übernommen, damit nicht zwei Agenten am
  selben Problem arbeiten. action=next holt und reserviert in einem Zug.
- Idempotenz über client_ref, Deduplizierung auch für Feature Requests,
  Erkennung von Regressionen, automatische Eskalation des Schweregrads.
- Strukturierter Code-Kontext (repo_url, commit_sha, file_path, line_no).
- Delta-Abfragen über updated_since, Pagination, Bulk-Update.
- Beim Veröffentlichen eines Releases schließen sich Items mit passendem
  resolved_in_build selbst.
- Ausgehende Webhooks mit HMAC-Signatur, /api/health, /api/openapi.json.
- Unbehandelte Fehler meldet die Plattform in ihren eigenen Bugtracker.

WebUI
- Serverseitige Filterung mit Pagination statt Rendern aller Datensätze.
- Migrations-Schranke, Evaluator-Warnung, Übersicht aktiver Agenten.

Zeitstempel liegen in der Datenbank durchgängig in UTC und werden für die
Anzeige in die App-Zeitzone umgerechnet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 16:17:36 +02:00
Deploymentcenter Bot c437bdee6f feat(bugtracker, tokens): Add project search, push_id, target_agent, tags, edit modal, extended severities (idea, wishlist), token actions (copy/toggle/delete), and agent integration guide 2026-08-06 21:53:30 +02:00
Deploymentcenter Bot d71f90cdfc feat: integrate Bugtracker module, UpdateService enhancements & Token hierarchy 2026-08-06 12:45:58 +02:00