Zum Inhalt springen
AetherOS und die zehn Apps werden noch gebaut. Zu haben sind bisher nur Schriften, Emojis und Farben – Apps geplant für Sommer 2027. Was noch kommt
So arbeiten wir

Das ganze Regelwerk

Aerona wird nach aufgeschriebenen Regeln gebaut. Ein Thema, eine Datei – wer eine Regel ändert, ändert sie an einer Stelle. Hier stehen alle, jede mit ihrem Kern. Zusammengeführt wurde das Regelwerk am 25. Juli 2026, und seither wird daran weitergeschrieben: Zuletzt kamen die Regeln 32 zur Designsprache und 33 zur Bewegung dazu, beide gültig für jedes Aerona-Produkt. Vollständig nachlesen lässt sich jede Regel unter Die Regeln einzeln.

Auf einen Blick

42

Dateien im Regelwerk

300

Zeilen höchstens je Datei

1

Thema je Datei

Die zwanzig Grundsätze

Über den einzelnen Dateien stehen zwanzig Grundsätze. Jeder nennt die Regel, in der er ausführlich steht. Sie stehen ganz oben im Inhaltsverzeichnis des Regelwerks, noch vor der Liste der Dateien. Wer einen genauer wissen will, folgt der Nummer in der letzten Spalte.

Nr.GrundsatzWorum es gehtRegel
11000-%-PrinzipPremium-Niveau, keine drittklassige Software.00 Anspruch
2Alles-VereinerWie Windows, aber mit dem Besten aller Systeme.00 Vision
3300-Zeilen-RegelKeine Quelldatei darf mehr als 300 Zeilen haben.02, zerlegt wird nach 03
4Immer DeutschAntworten und Kommentare deutsch, Code englisch.04
5Voller CodeNiemals „// Rest bleibt gleich“.02
6Git ist PflichtVor jedem Umbau eine Sicherung.05
7Nichts geht verlorenArchiv statt Löschen, Beweis vor dem Löschen.06
8Erst denken, dann codenDie Ursache suchen, nicht das Symptom.01 und 07
9Engine ≠ ContentEngine und Inhalt sind strikt getrennt, damit die Engine aktualisierbar bleibt.00 Anspruch
10Charme in den MomentenKalt ist genauso durchgefallen wie billig.21
11Local FirstWas auf dem Rechner bleiben kann, verlässt ihn nicht.27
12DatenhaltbarkeitWas Aerona schreibt, kann Aerona in zehn Jahren noch lesen.28
13Nicht raten, messenJede Behauptung braucht eine Quelle.31
14Eine eigene WeltAlles selbst gemacht, nichts Standard, immer die neueste eigene Fassung.34
15Selbstständig, aber belegtSelbst entscheiden und weiterbauen; Unumkehrbares ist gesperrt, jede Behauptung hat einen Beleg.35
16Aeri wirbt immer mitJedes Werbemotiv aus eigenem Code, ehrlich, auf Englisch, mit Aeri.36
17Für jeden, auf jedem GerätVom alten Handy bis zum großen Bildschirm; eine Maschine misst jede Seite.37
18Scharf bis 8KAlles, was man sieht, ist auf 8K gestochen scharf; nichts wird hochgerechnet.38
19Takt und QualitätSchnell arbeiten ohne Abstriche; fertig ist erst, was gebaut und geprüft ist.39
20Lange AbläufeMinuten statt Stunden: nur Neues rechnen, gleichzeitig, fortsetzbar – ohne eine Prüfung wegzulassen.40

„Bei Unsicherheit gilt immer: lieber nachfragen als raten.“

Aus dem Inhaltsverzeichnis der Regeln

Alle Regeln

Nr.RegelDer Kern
00Anspruch, Architektur und Design-PhilosophieGearbeitet wird auf höchstem Niveau – das 1000-Prozent-Prinzip.
00Die VisionAlles, was jedes Betriebssystem der Welt hat. AetherOS bedient sich so vertraut wie Windows.
01Zusammenarbeit mit KI-AssistentenDie KI arbeitet wie eine erfahrene Entwicklerin und antwortet immer auf Deutsch.
02Architektur und CodeKeine Quelldatei darf mehr als 300 Zeilen haben.
03Zerlegen nach der 300-Zeilen-RegelWie jede Art von Datei richtig zerlegt wird – und wann man es besser lässt.
04Code-Sprache, Kommentare und DokumentationCode englisch, alles Erklärende deutsch.
05Git und VersionierungJedes Projekt ist ein Git-Repository, ohne Ausnahme.
06Aufräumen ohne VerlustNichts Sichtbares oder Funktionierendes darf verschwinden. Archiv statt Löschen.
07Sicherheit, Qualität und FehlersucheDie Ursache heilen, nicht das Symptom flicken.
08Das BautagebuchJeder Bauschritt wird mitgeschrieben, fertig für die Webseite.
09Ordnerstruktur und PfadeNummerierte Themenbereiche, keine festen Laufwerkspfade.
10Oberfläche, Design und FrontendWas nur funktioniert, aber billig aussieht, ist durchgefallen.
11CSS-ArchitekturEinfaches CSS in Modulen, jede Datei unter 300 Zeilen.
12App Engine und ReactDie App Engine läuft auf React, alles andere auf HTML, CSS und JavaScript.
13Übersetzungen: das 85-Sprachen-SystemKein sichtbarer Text steht direkt im Code.
14Zustand und Browser-SpeicherAlle gespeicherten Schlüssel beginnen mit „aerona_“.
15Simulator und EntwicklerwerkzeugeDer Simulator zeigt die Oberfläche auf echten Geräten.
16Auslieferung, Electron und VeröffentlichungenAerona läuft als Windows-Anwendung über Electron.
17Markenidentität und TonfallHochwertige Software, gefertigt in Deutschland.
18UpdatetexteDie verbindliche Vorgabe für Änderungsberichte – ihre Quelle ist das Bautagebuch.
19Das App-Format .aeroEin eigenes App-Format als offizieller Weg.
20Sparsam arbeitenKI-Kontingente sind begrenzt – also sparsam arbeiten.
21Charme, Verspieltheit und BelohnungDurchgefallen ist auch, was sich nach niemandem anfühlt.
22Leistung und LadezeitZeit sparen beim Benutzen – belegt mit gemessenen Zahlen.
23Bildsprache: Emojis, Symbole, Illustrationen3.979 eigene Emojis im aktuellen Satz, in 50 Kategorien.
24Prüfen und MessenWie geprüft wird – und wie man eine Prüfung erkennt, die nichts prüft.
25Barrierefreiheit„Aerona ist exklusiv im Look und inklusiv in der Nutzbarkeit.“
26Erster Start und EinführungDer erste Start lässt sich nicht wiederholen.
27Datenschutz und Local FirstDie Daten der Nutzer bleiben geschützt – und zuerst auf dem eigenen Gerät.
28Datenhaltbarkeit und MigrationWas Aerona schreibt, muss es in zehn Jahren noch öffnen können.
29Fremdcode und AbhängigkeitenFremdpakete wie React oder Electron sind in Ordnung – mit Bedacht.
30Wenn es beim Nutzer brichtOhne Telemetrie erfahren wir Fehler nur, wenn Nutzer sie melden.
31Nicht raten, sondern messenJede Behauptung braucht eine Quelle.
32Die DesignspracheWas in jedem Aerona-Produkt gleich ist.
33BewegungKeine Bewegung ist Standard.
34Eine eigene WeltAlles, was man sieht, hört oder anfasst, ist selbst gemacht.
35Selbstständig weiterbauen – aber belegtSelbst entscheiden über eine Leiter; was sich nicht zurückholen lässt, ist gesperrt.
36Marketing und WerbungWerbung aus eigenem Code, auf Englisch, mit Aeri und jeder Zahl nachgezählt.
37Für jeden, auf jedem GerätJedes eigene Teil hat einen Rückfall, gemessen auf fünf Geräten.
38Scharf bis 8KCode und Vektor zuerst, Bilder nur in ihrer 8K-Größe.
39Takt und QualitätNie leer warten, bündeln, gezielt prüfen – ohne eine andere Regel zu lockern.
40Lange AbläufeNur Neues rechnen, gleichzeitig, fortsetzbar – ohne eine Prüfung wegzulassen.

Der Kern steht so am Anfang jeder Regeldatei. Die Tafel ist vom 15. September 2026, die Zeilen für 32 und 33 kamen am 25. September dazu, die für 34 bis 40 am 5. Oktober. Es sind 42 Zeilen für 43 Dateien, weil die dreiundvierzigste das Inhaltsverzeichnis selbst ist. Die Kurzfassung mit den neun wichtigsten Regeln steht auf So arbeiten wir.

Zwei Teile

Das Regelwerk ist in zwei Teile gegliedert. Der erste gilt immer, der zweite nur für bestimmte Aufgaben. Welche Regeln aus dem zweiten Teil man liest, hängt davon ab, woran man arbeitet – das steht weiter unten unter „In welcher Reihenfolge man sie liest“.

24

Regeln in Teil A – sie gelten immer, in jedem Projekt

17

Regeln in Teil B – je nach Aufgabenbereich

Teil A

Dazu gehören Vision und Anspruch, Code und Git, Aufräumen, Sicherheit, das Bautagebuch, Leistung, Prüfen, Datenschutz, Datenhaltbarkeit und Fremdcode – außerdem die Zusammenarbeit mit KI, Ordner und Pfade, sparsames Arbeiten, was geschieht, wenn es beim Nutzer bricht, und die Regel, nicht zu raten. Sie gelten in jedem Projekt, egal woran man gerade arbeitet.

Teil B

Dazu gehören Oberfläche und CSS, Übersetzungen, die Marke, Charme, Bildsprache, Barrierefreiheit und der erste Start, dazu App Engine und React, Browser-Speicher, Simulator, Auslieferung, Updatetexte und das App-Format. Seit September stehen hier auch die Designsprache und die Bewegung; diese beiden gelten für jedes Produkt, das ein Mensch zu Gesicht bekommt.

Zusammengeführt wurde das Regelwerk am 25. Juli 2026. Die drei früheren Fassungen aus Januar, Februar und Juli 2026 liegen unverändert im Archiv. Nachschlagen darf man sie – als Regel gelten sie nicht mehr. Ebenfalls dort liegen alte Anleitungen für Server, die ein Backend beschreiben, das nicht mehr zu Aerona gehört.

Die Regeln, die am häufigsten zählen

300 Zeilen

Keine Quelldatei darf mehr als 300 Zeilen haben. Kein Vorschlag, eine Grenze. Nähert sich eine Datei ihr, ab etwa 250 Zeilen, wird sie vorher zerlegt. Im Betriebssystem gibt es seit dem 13. September 2026 keine Ausnahme mehr.

Archiv statt Löschen

Vor dem Löschen braucht es den Beweis, dass etwas tot ist. Sonst kommt es ins Archiv. Das Regelwerk selbst ist ein Beispiel: Seine drei früheren Fassungen gelten nicht mehr, liegen aber unverändert dort.

Das Bautagebuch

Jeder sichtbare Bauschritt wird aufgeschrieben – daraus entstehen die Änderungsberichte. Jeder Eintrag ist so geschrieben, dass er ohne Umschreiben auf die Webseite kann; ausgenommen sind nur Übersetzungen und Aufräumarbeit ohne sichtbare Wirkung. Nachlesen kann man es unter Das Bautagebuch.

Nicht raten, sondern messen

Jede Zahl auf dieser Webseite soll gezählt sein. Was sich nicht belegen lässt, kommt raus. Deshalb nennen Zahlen hier ihren Tag, und wo eine Zählung falsch war, steht auch das – unter Aerona in Zahlen.

In welcher Reihenfolge man sie liest

Wer neu dazukommt, ob Mensch oder KI-Werkzeug, liest zuerst neun Regeln in fester Reihenfolge. Davor kommt noch ein Blick auf den Stand: Ein Werkzeug zeigt in Sekunden, was es gibt und welche Dateien zu lang sind, statt dass man sich durch Ordner liest.

  1. 20 · Sparsam arbeiten – erst messen, dann lesen.
  2. 31 · Nicht raten, sondern messen – warum hier nichts geraten wird.
  3. 00 · Die Vision – wohin AetherOS soll.
  4. 00 · Anspruch, Architektur und Design-Philosophie – das Arbeitsniveau.
  5. 02 · Architektur und Code – der Code-Stil.
  6. 04 · Code-Sprache, Kommentare und Dokumentation – Code englisch, Erklärungen deutsch.
  7. 05 · Git und Versionierung – vor jedem Umbau eine Sicherung.
  8. 06 · Aufräumen ohne Verlust – Archiv statt Löschen.
  9. 24 · Prüfen und Messen – warum eine grüne Prüfung noch nichts beweist.

An der Webseite

Dazu die Regeln 10, 11, 13 und 18: Oberfläche, CSS, Übersetzungen und Updatetexte.

Am Betriebssystem

Dazu die Regeln 03, 19 und 16: Zerlegen, das App-Format und die Auslieferung.

An einer Oberfläche für Menschen

Zusätzlich die Regeln 32 und 33 – die Designsprache gilt in jedem Produkt gleich – sowie 21, 25 und 26: Charme, Barrierefreiheit und der erste Start.

Etwas schneller machen

Dazu Regel 22. Dort stehen auch die Sackgassen, die schon jemand abgelaufen ist.

Ein Format, das beim Nutzer landet

Dazu Regel 28 – und zwar bevor die erste Zeile geändert wird.

Wie eine Regel entsteht

Viele Regeln wurden nicht am Schreibtisch erdacht, sondern haben einen Anlass: etwas, das schiefging, und die Frage, warum. Vier Beispiele aus einer einzigen Regel – der über die Oberfläche –, so wie sie dort stehen.

RegelWas passiert istWas seitdem gilt
10.12 · Ring oder Fläche
erweitert am 07.09.2026
Ein durchsichtiger Hinweisknopf bekam einen Ring aus Punkten und zusätzlich eine Fläche aus Punkten – heraus kam ein graues Raster. Kevin: „das mit den Punkten gibt es nur bei Kästen, die in Aerona-Farben sind, weil man da den Rahmen nicht sehen würde.“Ring oder Fläche, der Grund entscheidet – nie beides gleichzeitig.
10.15 · Die Grenze der Unschärfe
Hauswert seit 13.09.2026
Durch zwei Glasscheiben im Design-Schaukasten sah man nichts. Nachgemessen lag es am Radius: vierzehn Pixel Unschärfe auf elf Pixel Linienabstand.Der Radius wird gerechnet, nicht geschätzt. Für die ganze Webseite gilt ein Wert: vier Pixel.
10.16 · Was ein Kasten wegschneidet
gemeldet am 07.09.2026
„jetzt kommt nichts mehr“ – dabei war der Ring an allen sechs gemessenen Bauteilen da. Vier davon schnitten ihn mit ihrem eigenen Rand weg.Wer einen Ring anhängt, prüft zuerst, ob der Kasten schneidet.
10.17 · Antworten statt Ausweichen
Glas starr seit 13.09.2026
An den Kacheln des Verzeichnisses kam der Ring – aber die Kachel hob sich daneben um drei Pixel, und man sah nur das.Glaskästen bleiben beim Zeigen stehen. Antworten darf nur, was sich im Kasten regt.

„Die Regel war also da — sie stand nur nirgends. Deshalb konnte man sie nicht nachlesen, sondern nur verletzen.“

Regel 10 · Oberfläche, Design und Frontend

Was eine Maschine prüft

Regeln, die niemand nachprüft, sind Papier. Einen Teil davon prüfen deshalb Werkzeuge, den Rest ein Mensch. Welche Regel wie geprüft wird, steht im Inhaltsverzeichnis des Regelwerks – samt dem Hinweis, dass auch diese Angabe eine Behauptung ist, die nachgezogen werden muss.

Das Regel-Werkzeug

Es macht dreizehn Prüfungen zu neun Regeln: 09, 10, 11, 16, 22, 25, 27, 29 und 34. Nachgezählt am 6. Oktober 2026. Kommt eine Prüfung dazu oder fällt eine weg, ändert sich die Zahl – deshalb steht das Datum dabei.

Die 300-Zeilen-Grenze

Ein zweites Werkzeug misst sie für den ganzen Bestand. Es gehört zum ersten Blick auf den Stand, noch vor jeder Arbeit – so fällt eine zu lange Datei auf, bevor sich jemand an sie gewöhnt.

Bewusst nicht geprüft

Eine Prüfung, die hunderte richtige Zeilen meldet, wird ignoriert. Was ausgelassen wird, ist deshalb am ganzen Bestand gemessen und begründet. Die Gründe stehen im Kopf des Werkzeugs selbst.

Der Rest

Alle übrigen Regeln brauchen weiter einen Menschen, der hinsieht. Dazu gehören etwa Tonfall, Charme und Bildsprache – Regeln, bei denen es auf ein Urteil ankommt.

Weiter

Version 9.0.0

Die Webseite wiegt die Hälfte, das Menü auf dem Telefon ist eine Liste geworden, das Glas ist überall dasselbe — und ein Kasten auf der Startseite sagt, warum hier eine Weile nichts passiert.