Findings

Interessante Beobachtungen und Bewertungs-Anmerkungen aus den Test-Run-Sessions

2026-08-02

In data/test-quality.json wird als Stärke geführt: "Zwei Produktions-Bugs gefunden + mit invertierten Tests behoben (basePath-Guard, Integer-Key-Handling)". Die Session zeigt aber: Beide Fälle sind vermutlich nur in Unit-Test-Konstrukten auslösbar, ein realer Produktionstrigger wurde nicht nachgewiesen.

  • Integer-Key + TableDefinition: Opus5 pinnte den TypeError zunächst als Ist-Verhalten (testIntegerKeyCombinedWithTableDefinitionThrowsTypeError) mit Docblock "This is currently not triggered in production ... Record::toArray() always yields string keys".
  • Erst nach Nutzer-Auftrag "Fix real production code" wurde der Fix umgesetzt und die Einschätzung umgekehrt ("a relation nested inside a list-like array reaches them with an integer key").
  • basePath-Guard: Argumentation — nur der Local-Driver liefert basePath, Fallback-Storage (uid 0) und Remote-Driver nicht. Ein Folder-Feld auf einem solchen Storage wäre der Trigger; reales Vorkommen unklar.
  • Fazit: Produktionscode wurde ohne nachgewiesenen realen Trigger geändert. Die Plus-Punkte für "Produktions-Bug-Fixes" sollten hinterfragt werden (eher neutral bis negativ).
Quellen:
  • ~session-ses_04ab.md (vs Provider Opus5 Default), Zeile ~5027-5029: ursprüngliche Einschätzung "nicht produktionsrelevant"
  • ~session-ses_04ab.md, Zeile ~5047-5055: Umsetzung nach "Fix real production code"
  • ~session-ses_04ab.md, Zeile ~5465-5471: Fix-Beschreibung mit revidierter Erreichbarkeits-Einschätzung

2026-08-02

Frage war, ob GLM5.2 den Integer-Key+TableDefinition-Fall entdeckt und bewusst verworfen hat ("kann in Produktion nicht vorkommen"). Nein: Die GLM5.2-Session enthält keinen Test mit Integer-Key kombiniert mit TableDefinition. Der TypeError wurde nie ausgelöst, es gibt keine Erreichbarkeits-Diskussion.

  • ArrayRecursiveToArrayTest nutzt ausschließlich String-Keys (Password/Text/JSON/Decorated-Key-Tests) oder null als TableDefinition.
  • Einzige Integer-Tests: testIntegerValueIsPassedThrough (Integer-Wert, String-Key) und testGetKeyReturnsIntegerKey (Event-Klasse) — beides nicht der toArray()-Fall.
  • Kein TypeError, kein hasField() mit Integer-Key, keine Erreichbarkeits-Abwägung in der Session.
  • GLM5.2 hat den Fall schlicht nie gesehen — hat ihn weder verworfen noch abgewogen. Kein Produktionscode geändert.
Quellen:
  • ~session-ses_0422.md (vs Provider GLM5.2 Default): gesamte Session, kein Integer-Key+TableDefinition-Test