Fund beim Lesen der CI-Läufe nach #402/#403 (2026-10-11).
Befund
Check 66f von e2e 66 ist in beiden CI-Läufen seit #402 rot, im Job suite auf melektaus-atx:
Task 645 (d48f174) FAIL a sprite wearing the clip plays only its stretch, round and round – ["#cc00f4"]
Task 647 (ce933a4) FAIL a sprite wearing the clip plays only its stretch, round and round – ["#cc00f4"]
Der Check liest 14-mal im Abstand von 120 ms das Pixel in der Mitte des Sprites. Erwartet sind Grün und Blau aus dem Clip 0,6–1,4 s. Gesehen wurde 14-mal dasselbe Lila #cc00f4, das es weder im Testvideo noch im Code gibt.
Alle anderen Checks von e2e 66 sind grün, auch der direkt danach: Der Player läuft (time 0,67, ready: true, muted: true).
Mit dem neuen Range-Router (c815d2c) sind die 3 anderen roten Checks aus Task 645 grün. Dieser eine ist geblieben. Die Smokes sind in beiden Läufen nicht gelaufen, im Log steht kein Eintrag dazu.
Was es nicht ist
Nicht die GPU: Meine Entwicklerläufe mit tmp/atx-e2e.sh 34,66 laufen auf derselben Karte (ANGLE … D3D12 (NVIDIA GeForce RTX 4070)), dort sah derselbe Check ["#00ff01","#0000ff"] und war grün (Logs 2026-10-11 12:29 und 12:40).
Vermutung (nicht gemessen)
In CI laufen vorher alle anderen Module. Ein konstantes Lila passt zu einem Objekt, das ein früheres Modul im Fixture-Projekt an der Stelle (0, 0) liegen lassen hat und das über dem Video-Sprite liegt. Das Sprite wird mit scene.objects.push angelegt, die Kamera sieht mit lookAt(0, 0) genau dorthin.
Plan
Lokal tmp/atx-e2e.sh all bis einschließlich 66 laufen lassen und den Screenshot 66-video-sprite ansehen, oder vor 66f per Hook auflisten, was an (0, 0) liegt.
Ist es ein Rest eines anderen Moduls: diesen Rest aufräumen. Zusätzlich legt 66f sein Sprite an eine eigene, freie Stelle bzw. ganz nach vorne, damit es nicht von Resten abhängt.
Ist es doch das Bild selbst (falsch hochgeladenes Videobild): neuer Befund, eigener Plan.
Fund beim Lesen der CI-Läufe nach #402/#403 (2026-10-11).
## Befund
Check 66f von e2e 66 ist in **beiden** CI-Läufen seit #402 rot, im Job `suite` auf `melektaus-atx`:
```
Task 645 (d48f174) FAIL a sprite wearing the clip plays only its stretch, round and round – ["#cc00f4"]
Task 647 (ce933a4) FAIL a sprite wearing the clip plays only its stretch, round and round – ["#cc00f4"]
```
- Der Check liest 14-mal im Abstand von 120 ms das Pixel in der Mitte des Sprites. Erwartet sind Grün und Blau aus dem Clip 0,6–1,4 s. Gesehen wurde **14-mal dasselbe Lila `#cc00f4`**, das es weder im Testvideo noch im Code gibt.
- Alle anderen Checks von e2e 66 sind grün, auch der direkt danach: Der Player läuft (`time` 0,67, `ready: true`, `muted: true`).
- Mit dem neuen Range-Router (c815d2c) sind die 3 anderen roten Checks aus Task 645 grün. Dieser eine ist geblieben. Die Smokes sind in beiden Läufen nicht gelaufen, im Log steht kein Eintrag dazu.
## Was es nicht ist
- **Nicht die GPU:** Meine Entwicklerläufe mit `tmp/atx-e2e.sh 34,66` laufen auf derselben Karte (`ANGLE … D3D12 (NVIDIA GeForce RTX 4070)`), dort sah derselbe Check `["#00ff01","#0000ff"]` und war grün (Logs 2026-10-11 12:29 und 12:40).
## Vermutung (nicht gemessen)
In CI laufen vorher alle anderen Module. Ein konstantes Lila passt zu einem Objekt, das ein früheres Modul im Fixture-Projekt an der Stelle (0, 0) liegen lassen hat und das über dem Video-Sprite liegt. Das Sprite wird mit `scene.objects.push` angelegt, die Kamera sieht mit `lookAt(0, 0)` genau dorthin.
## Plan
1. Lokal `tmp/atx-e2e.sh all` bis einschließlich 66 laufen lassen und den Screenshot `66-video-sprite` ansehen, oder vor 66f per Hook auflisten, was an (0, 0) liegt.
2. Ist es ein Rest eines anderen Moduls: diesen Rest aufräumen. Zusätzlich legt 66f sein Sprite an eine eigene, freie Stelle bzw. ganz nach vorne, damit es nicht von Resten abhängt.
3. Ist es doch das Bild selbst (falsch hochgeladenes Videobild): neuer Befund, eigener Plan.
Ursache: Der Fehler lag im Testmodul selbst, nicht am Video-Code. e2e 66 hat sein Video-Sprite auf (0, 0) gesetzt. Genau dort lassen frühere Module in der vollen Suite absichtlich Objekte liegen, die spätere Module noch brauchen:
otext und filler1–filler40 aus e2e 10/11 (z 5)
otex aus e2e 12 (z 900)
Deshalb hat jedes andere Modul eine eigene Lane mit eigenem Y (LANES in tools/e2e/lib/scaffold.mjs). Nur 66 hatte keine. Allein gestartet fehlen diese Objekte, deshalb war das Modul bei mir grün.
Beleg: Ich habe in einem vollen Lauf auf melektaus-atx eine Diagnose eingebaut. Unter dem Mittelpunkt des Sprites lagen o3, otex und filler40…filler1, erst danach vd66-object. Daneben, wo nichts davor lag, zeigte das Sprite korrekt Grün #00ff01. Das Lila #cc00f4 ist die Textur von otex in dem Zustand, den spätere Module hinterlassen. Mit dem Springen im Video hat es nichts zu tun: Task 645 sah dieselbe Farbe, als das Springen noch kaputt war.
Fix:
tools/e2e/lib/scaffold.mjs: neue Lane video: -7000.
tools/e2e/66-video.mjs: Sprite und lookAt nutzen diese Lane. Beim Aufräumen springt der Blick wieder auf (0, 0), wie bei den anderen Lane-Modulen.
Tests (melektaus-atx):
e2e 10-12 + 66, alter Stand → 66f FAIL (otex davor) ← Gegenprobe
e2e 10-12 + 66, mit Fix → ALL PASSED, 81 Checks, 66f sieht #00ff01 + #0000ff
Prettier, eslint → sauber
Der Fehler lässt sich mit 10-12,66 in unter einer Minute nachstellen, dafür braucht es nicht die volle Suite.
Nicht abgewartet: Den CI-Lauf zu a62d1d0 habe ich wie gewünscht nicht abgewartet. Ich lese ihn vor dem nächsten Commit.
## Erledigt mit `a62d1d0`
**Ursache:** Der Fehler lag im Testmodul selbst, nicht am Video-Code. e2e 66 hat sein Video-Sprite auf (0, 0) gesetzt. Genau dort lassen frühere Module in der vollen Suite absichtlich Objekte liegen, die spätere Module noch brauchen:
- `otext` und `filler1`–`filler40` aus e2e 10/11 (z 5)
- `otex` aus e2e 12 (z 900)
Deshalb hat jedes andere Modul eine eigene Lane mit eigenem Y (`LANES` in `tools/e2e/lib/scaffold.mjs`). Nur 66 hatte keine. Allein gestartet fehlen diese Objekte, deshalb war das Modul bei mir grün.
**Beleg:** Ich habe in einem vollen Lauf auf `melektaus-atx` eine Diagnose eingebaut. Unter dem Mittelpunkt des Sprites lagen `o3`, `otex` und `filler40`…`filler1`, erst danach `vd66-object`. Daneben, wo nichts davor lag, zeigte das Sprite korrekt Grün `#00ff01`. Das Lila `#cc00f4` ist die Textur von `otex` in dem Zustand, den spätere Module hinterlassen. Mit dem Springen im Video hat es nichts zu tun: Task 645 sah dieselbe Farbe, als das Springen noch kaputt war.
**Fix:**
- `tools/e2e/lib/scaffold.mjs`: neue Lane `video: -7000`.
- `tools/e2e/66-video.mjs`: Sprite und `lookAt` nutzen diese Lane. Beim Aufräumen springt der Blick wieder auf (0, 0), wie bei den anderen Lane-Modulen.
**Tests (`melektaus-atx`):**
```
e2e 10-12 + 66, alter Stand → 66f FAIL (otex davor) ← Gegenprobe
e2e 10-12 + 66, mit Fix → ALL PASSED, 81 Checks, 66f sieht #00ff01 + #0000ff
Prettier, eslint → sauber
```
Der Fehler lässt sich mit `10-12,66` in unter einer Minute nachstellen, dafür braucht es nicht die volle Suite.
**Nicht abgewartet:** Den CI-Lauf zu `a62d1d0` habe ich wie gewünscht nicht abgewartet. Ich lese ihn vor dem nächsten Commit.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fund beim Lesen der CI-Läufe nach #402/#403 (2026-10-11).
Befund
Check 66f von e2e 66 ist in beiden CI-Läufen seit #402 rot, im Job
suiteaufmelektaus-atx:#cc00f4, das es weder im Testvideo noch im Code gibt.time0,67,ready: true,muted: true).c815d2c) sind die 3 anderen roten Checks aus Task 645 grün. Dieser eine ist geblieben. Die Smokes sind in beiden Läufen nicht gelaufen, im Log steht kein Eintrag dazu.Was es nicht ist
tmp/atx-e2e.sh 34,66laufen auf derselben Karte (ANGLE … D3D12 (NVIDIA GeForce RTX 4070)), dort sah derselbe Check["#00ff01","#0000ff"]und war grün (Logs 2026-10-11 12:29 und 12:40).Vermutung (nicht gemessen)
In CI laufen vorher alle anderen Module. Ein konstantes Lila passt zu einem Objekt, das ein früheres Modul im Fixture-Projekt an der Stelle (0, 0) liegen lassen hat und das über dem Video-Sprite liegt. Das Sprite wird mit
scene.objects.pushangelegt, die Kamera sieht mitlookAt(0, 0)genau dorthin.Plan
tmp/atx-e2e.sh allbis einschließlich 66 laufen lassen und den Screenshot66-video-spriteansehen, oder vor 66f per Hook auflisten, was an (0, 0) liegt.Erledigt mit
a62d1d0Ursache: Der Fehler lag im Testmodul selbst, nicht am Video-Code. e2e 66 hat sein Video-Sprite auf (0, 0) gesetzt. Genau dort lassen frühere Module in der vollen Suite absichtlich Objekte liegen, die spätere Module noch brauchen:
otextundfiller1–filler40aus e2e 10/11 (z 5)otexaus e2e 12 (z 900)Deshalb hat jedes andere Modul eine eigene Lane mit eigenem Y (
LANESintools/e2e/lib/scaffold.mjs). Nur 66 hatte keine. Allein gestartet fehlen diese Objekte, deshalb war das Modul bei mir grün.Beleg: Ich habe in einem vollen Lauf auf
melektaus-atxeine Diagnose eingebaut. Unter dem Mittelpunkt des Sprites lageno3,otexundfiller40…filler1, erst danachvd66-object. Daneben, wo nichts davor lag, zeigte das Sprite korrekt Grün#00ff01. Das Lila#cc00f4ist die Textur vonotexin dem Zustand, den spätere Module hinterlassen. Mit dem Springen im Video hat es nichts zu tun: Task 645 sah dieselbe Farbe, als das Springen noch kaputt war.Fix:
tools/e2e/lib/scaffold.mjs: neue Lanevideo: -7000.tools/e2e/66-video.mjs: Sprite undlookAtnutzen diese Lane. Beim Aufräumen springt der Blick wieder auf (0, 0), wie bei den anderen Lane-Modulen.Tests (
melektaus-atx):Der Fehler lässt sich mit
10-12,66in unter einer Minute nachstellen, dafür braucht es nicht die volle Suite.Nicht abgewartet: Den CI-Lauf zu
a62d1d0habe ich wie gewünscht nicht abgewartet. Ich lese ihn vor dem nächsten Commit.