Lunisist Zeit
ENTWICKLUNGSBILANZ / 21.09.2026
Quellen ↗
Bau-Kapazität & Konzepte · Kapitel 03

Schnell sichtbar.
Nicht automatisch fertig.

Ein guter One-Shot erzeugt überprüfbare Substanz: eine Oberfläche, ein Konzept oder einen abgegrenzten Implementierungsstand. Vollständigkeit muss danach bewiesen werden.

4 / 24

Historische Pakete mit strengem verify-PASS. Keine allgemeine Erfolgsquote für beliebige Aufgaben.

Was ein One-Shot wirklich leisten kann.

Die gezeigten Dateien machen Varianten, Interaktionen und Fachideen greifbar. Die Grenze zum fertigen Produkt bleibt sichtbar.

01Demo

Bedienwege konkretisieren

Aus einer Beschreibung kann eine klickbare Oberfläche entstehen: Navigation, Formulare, Zustände und Datenfluss werden diskutierbar. Das verringert Unklarheit, ersetzt aber keinen Fachtest.

02Konzept

Domänen räumlich zeigen

CAD-Konzepte können Korpus, Bauteile, Stücklisten und Kalkulationsansichten zusammenbringen. Ein Browser-Rendering belegt keinen produktiven CAD-/CAM-Export.

03Nachweis erforderlich

Implementierung eingrenzen

Ein präziser Auftrag kann Code, Tests und Belege für einen klaren Teilumfang erzeugen. Erst ein wiederholbarer Test und eine überprüfte Abnahme schließen den Auftrag.

Quelle: S01 · S02 · S11

CAD-Konzepte im Arbeitsmaßstab.

Eigene Clean-room-Demooberflächen. Keine Hersteller-Software, keine Gleichwertigkeitsbehauptung und kein Nachweis einer CNC-fähigen Produktionskette.

MasswerkVorhandenes CAD-Konzept · anonymisierte Berichtsadaption
Herkunft oneshot-input/demo-mockup-bericht/mockups/Masswerk.html · Originalquelle auf GitHub
Vorhandene, lokal bedienbare Masswerk-Konzeptoberfläche. Beispieldaten anonymisiert, Farben für die Berichtsumgebung angepasst. Darstellung und lokale Berechnungen sind keine Produktions-, Statik- oder Maschinenfreigabe.
Quelle: S02 · S11

Marke als bearbeitbares System.

Das Brand-Studio zeigt, dass nicht nur Programmlogik, sondern auch Marken- und Inhaltsarbeit in einen interaktiven Arbeitsraum übersetzt wurde.

Lunis · Brand-StudioVorhandene HTML-Demo · aktuelle Berichtsadaption
Herkunft varianten/html-demos/lunis-brand-studio-live-canvas.html · Originalquelle auf GitHub
Die vorhandene Brand-Studio-Datei wurde für den Bericht anonymisiert und auf Kachel, Navy und aktuelles Rot reduziert. Historische Markenvarianten sind nicht der verbindliche Markenstand. Alle Beispiele bleiben lokale Demoartefakte.
Quelle: S11 · S12

Auftrag ist nicht Erfolg.

Die historische Registersicht enthält unterschiedliche Zählobjekte. Der Bericht vermischt Pakete, Bridge-IDs, Proben und Zeitintervalle nicht.

24 historische Schusspakete

Quellenstand 20.09.
24Auftragspakete
4Strenges verify-PASS
7Marke ohne PASS-Beleg
13Unvollständig / offen
Quelle: S01
Was die vier PASS bezeichnen

S05b · S06b · S07b · S09

Diese historischen Pakete sind in der Quelle mit strengem verify-PASS geführt. Daraus folgt keine Übertragbarkeit auf sämtliche Anforderungen und keine Kundenabnahme.

22 Bridge-Intervalle / IDs stehen in einer anderen Registersicht; drei sind ausdrücklich Proben. Das ist weder dieselbe Zahl wie die 24 Pakete noch eine Zählung fertiger Produkte.

Später vorbereitete Aufträge A–F werden nicht rückwirkend als Erfolge gezählt. Blockierte oder nicht gesendete Aufträge bleiben außerhalb dieser Lieferung.

Quelle: S01

Sechs Phasen, nicht sechs Produkte.

Erster bis letzter beobachteter Aufruf je Phase. Die lange letzte Spanne enthält eine dokumentierte Bridge-Pause; sie darf nicht als ununterbrochene Arbeit verkauft werden.

Historischer Tagesverlauf

20.09.2026 · UTC
02:0005:0008:0011:0014:0017:0020:00Wave 0Wave 1IntegrationWave 2 / FixWave 3aProben / Wave 4Bridge-Pause 13:49–19:20
Beobachtetes FensterSpätere Build-WelleEnthaltene Pause

Wave 2/Fix enthält zusätzlich einen überlappenden Teilbereich 07:11–07:33 UTC. Die Grafik stellt das äußere Fenster dar. Sie zeigt keine CPU-/GPU-Auslastung.

Quelle: S01
Intervallsumme
38,0 h
Überlappungen und Pausen enthalten
Vereinigungsmenge
16,4 h
Überlappungen nur einmal, weiterhin Pausen
Historischer Parallel-Peak
6 Jobs
Beobachtung, keine Betriebszusage
Aktive Rechenzeit
Unbekannt
Kein belastbares CPU-/GPU-Stundenmaß

Schneller bauen heißt genauer prüfen.

Die sinnvolle Beschleunigung liegt in frühen, überprüfbaren Artefakten — nicht im Überspringen der Freigabe.

01

Präziser Auftrag

Fachziel, erlaubte Dateien, Belegregeln und Erfolgskriterien vorab festhalten.

02

Sichtbares Artefakt

Oberfläche oder Code als konkret prüfbare Lieferung statt nur als Beschreibung erzeugen.

03

Gegenprobe

Fehlerfälle, Quellen, Datenschutz, Datenintegrität und Zielumgebung prüfen.

04

Abgegrenzte Freigabe

Nur den tatsächlich belegten Umfang akzeptieren; Rest sichtbar offenhalten.

Kein „40-Stunden-Wunder“ als pauschaler BenchmarkDie 40 Stunden sind ein über mehrere Zeiträume zugeordneter Leistungsrahmen. Die Konzeptdateien und Agentenläufe haben eigene Herkunft und Grenzen. Eine rechnerische „Beschleunigung um Faktor X“ ist aus diesem Material nicht belastbar ableitbar.
Quelle: S01 · S02