Auf der Seite Arbeitsweise stehen vier Review-Gates als Karten: Aufgabe eingegrenzt, Test vor Implementierung, Review durch einen Menschen, Freigabe mit Namen. Als Text ist das richtig und ein wenig abstrakt. Hier läuft dasselbe als Fließband.
Planung 3
Aufgabe eingegrenzt, Ziel prüfbar.
Test 1
Erst der Test, dann der Code.
Bau 1
Die KI baut — in Menge.
Review 1
Ein Mensch liest jede Zeile.
Freigabe 2
Freigabe mit Namen.
Die Roboter bauen, die Hogs prüfen. Jedes Werkstück fährt durch ein Tor, wenn es eine Station verlässt, und das Tor leuchtet auf. Jedes vierte fällt an der Kontrolle durch: Der Hog hebt die Hand, das Tor sperrt, das Stück nimmt den Rücklauf zurück in die Montage. Daneben, auf schmalen Schirmen darunter, steht dasselbe als Kanban-Board. Ein Klick auf eine Karte lässt die Kamera dem Werkstück folgen, mit der Maus lässt sich die Halle ein Stück drehen.
Vier Tore, nicht fünf
Das Band hat fünf Stationen, aber nur vier Tore. Hinter der Montage steht keins. Dort arbeiten zwei Roboter allein, und das ist die Aussage: Die Menge macht die KI, ohne dass ein Mensch jede Schraube anschaut. Geprüft wird davor (steht die Aufgabe, steht der Test) und danach (liest jemand jede Zeile, unterschreibt jemand).
An allen anderen Stationen stehen Roboter und Hog nebeneinander. Ein Roboter allein an einem Tor wäre falsch, er würde die KI zum Kollegen mit Prüfbefugnis machen. Die Figuren sind KI-generiert, wie die übrigen Motive der Site, und als Strichzeichnung erkennbar keine Fotografie.
Die Tore gab es in der ersten Fassung nicht. Da standen an jeder Station zwei Pfosten mit einem Querbalken, gedacht als Markierung. Aus der Kamerahöhe sahen sie aus wie Glasscheiben zwischen Roboter und Hog, und die erste Frage beim Sichttest war, was diese Rechtecke bedeuten sollen. Sie bedeuteten nichts. Jetzt stehen sie quer über dem Band und haben einen Zustand: ruhend, leuchtend beim Durchlass, gesperrt bei Rückweisung.
Ein Takt, eine Wahrheit
Unter der Szene liegt kein Physikmodell, sondern ein Taktmodell, wie an einem echten Fließband. Alle 2,6 Sekunden rückt jedes Werkstück höchstens eine Station weiter, ausgewertet von hinten nach vorn, damit ein frei werdender Platz im selben Takt nachbesetzt werden kann. Die einzige Sonderregel betrifft den Rücklauf:
const s2 = an(2);
if (s2 && frei(3)) setze(s2, 3);
// Erst im Takt nach der Rückweisung zurück an die Montage
const rl = an('ruecklauf');
if (rl && rl.vorher === 'ruecklauf' && frei(2)) setze(rl, 2);
const s1 = an(1);
if (s1 && frei(2)) setze(s1, 2);
Das zurückgewiesene Stück hat an der Montage Vorrang, und davor staut es einen Takt. Das kostet Durchsatz: Statt eines Werkstücks pro Takt kommen vier in fünf Takten heraus. Nacharbeit ist nicht gratis, auch nicht in einer Animation.
Das Modell kennt weder three.js noch Svelte. Es ist deterministisch, jeder
Besucher sieht dieselbe Folge, und deshalb lässt es sich ohne Browser
prüfen. Ein Skript lässt 500 Takte laufen und verlangt unter anderem, dass
kein Platz doppelt belegt ist, dass genau die Werkstücke mit id % 4 === 2
einmal zurückgehen und dass sich das Belegungsmuster wiederholt, statt zu
driften. Szene, Board und Tore lesen nur aus diesem Zustand. Sie können
nicht auseinanderlaufen, weil keins von ihnen selbst etwas weiß.
Ein Fehler kam trotzdem erst im Board heraus. Es gab sieben Karten, und auf dem Band, in der Planung und in der Freigabe sind bis zu zehn Werkstücke gleichzeitig zu sehen. Dieselbe Aufgabe stand also zweimal im Board. Jetzt sind es elf, und der Prüflauf verlangt eindeutige Titel.
Linien, die man sieht
Die Halle besteht aus Kantenlinien, hell auf dem Blauschwarz der Site, wie
die Strichzeichnungen auf den anderen Seiten. Klassische WebGL-Linien haben
einen Haken: Sie sind immer genau ein Gerätepixel breit, egal was man
einstellt. Auf einem Retina-Schirm ist das ein halber CSS-Pixel und wirkt
wie Haarstrich. Die Szene nutzt deshalb LineSegments2 aus den
three.js-Addons, das Linien als Dreiecke zeichnet und echte Breiten in
Pixeln kann. Das Band bekommt 1,6 Pixel, Werkstücke 1,8, ein leuchtendes
Tor bis zu 3.
Hog und Roboter sind keine 3D-Modelle, sondern Strichzeichnungen auf Sprites, die sich immer zur Kamera drehen. In der ersten Fassung war jede Figur ein einzelnes Bild, das bei der Arbeit leicht hüpfte. In Szenengröße war davon wenig zu erkennen: Die feinen Linien schrumpften auf einen Bruchteil und verschwammen zu Grau. Jetzt hat jede Figur einen kurzen Film. Aus jeder Pose erzeugt ein Video-Modell fünf Sekunden Bewegung, mit demselben Bild als Anfang und Ende, damit die Schleife schließt. Ein Skript zerlegt das Video in 16 Bilder, schneidet alle gleich zu, verbreitert den Strich, bevor er verkleinert wird, und legt sie als Raster in eine Textur. Die Szene schiebt pro Bild nur den Ausschnitt weiter. Der Film läuft genau dann einmal durch, wenn vor der Figur ein Werkstück liegt.
Das hält die Figuren im Stil der übrigen Motive, hat aber eine Grenze: Von der Seite wären sie Pappe. Die Kamera lässt sich deshalb nur um 35 Grad nach links und rechts drehen, zoomen geht gar nicht. Das Mausrad soll die Seite scrollen, nicht in die Halle fahren. Auf Touch-Geräten ist das Drehen ganz aus, sonst würde ein Finger auf der Szene die Kamera drehen statt die Seite zu scrollen.
Beim Sperrkreuz am Kontroll-Tor ging das Prinzip „steht im Raum, wo es hingehört” schief. Das Tor steht quer zum Band, die Kamera schaut fast genau auf seine Kante, und ein Kreuz in der Torebene war von vorn ein einzelner Strich. Es hängt jetzt als Schild im Tor, zur Kamera gedreht.
Ohne WebGL, ohne JavaScript
Das Board ist kein Canvas, sondern HTML, gerendert schon auf dem Server.
Ohne JavaScript steht es vollständig da, nur eben still. Wo die Szene
wäre, liegt dann ein Standbild, und das ist nicht gemalt: Ein Skript öffnet
den Beitrag mit ?fabrik=standbild in einem Headless-Chrome, spult das
Modell bis zu einer Rückweisung vor und fotografiert die eigene Szene.
Ändert sich die Halle, wird das Bild neu gerendert statt nachgezeichnet.
Wer prefers-reduced-motion gesetzt hat, bekommt keine Endlosschleife,
sondern einen Knopf „Nächster Schritt”. Die Kamera springt dann zum
Werkstück, statt hinzufahren.
Eine Sekunde für nichts
Die erste Lighthouse-Messung der Beitragsseite ergab 81 Punkte für Performance, mit 740 Millisekunden Total Blocking Time. Das Profil zeigte die teuerste Funktion an einer unerwarteten Stelle: nicht three.js, nicht die Szene, sondern die Vorprüfung, ob der Browser überhaupt WebGL kann. Sie legte dafür einen Wegwerf-Kontext an. Unter Software-Rendering kostet das rund eine Sekunde, und gleich danach legt three.js seinen eigenen, zweiten Kontext an.
export function webglVerfuegbar(): boolean {
if (fabrikModus() === 'ohne-webgl') return false;
return typeof WebGLRenderingContext !== 'undefined';
}
Die Vorprüfung schaut jetzt nur noch, ob es die Schnittstelle gibt. Scheitert der Renderer trotzdem, fängt die Island den Fehler und zeigt das Standbild. Ergebnis: 99 Punkte, 30 Millisekunden. three.js selbst wiegt komprimiert 145 Kilobyte und wird nur auf dieser Seite geladen, erst wenn die Fabrik ins Bild scrollt.