# Herkunft und Änderungen Nach GPL §5a: was aus welcher Quelle übertragen und wie es verändert wurde. Swift-Pfade relativ zu `filius-ipad/ios/FiliusPad/TopologyEditor/` (Stand `3b5ded0`, 27.08.2026), Tests relativ zu `filius-ipad/ios/FiliusPadTests/`. ## packages/core | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/ids.ts` | Swift-Sortierung nach `UUID.uuidString` | neu, bildet die Swift-Ordnung nach | | `src/model/node.ts` | `Model/TopologyNode.swift` | übertragen; Standard-Ports und -Namen wie Java; ein gegebener Name bleibt, auch leer (Java lässt Router unbenannt) | | `src/model/link.ts`, `src/model/graph.ts` | `Model/TopologyLink.swift`, `Model/TopologyGraph.swift` | übertragen, bisher nur die Daten (Abfragen folgen mit dem Editor) | | `src/model/documentation.ts` | `Model/TopologyDocumentation.swift` | übertragen; FNV-Kennung mit BigInt, gegen die IDs aus dem Swift-Import geprüft | | `src/model/documentation.ts` (Java-Regeln) | Java `JDocuElement` (Konstruktor, `fontColor`, `panelColor`, `showPopupMenu`, `mouseDragged`, `setColor`), `GUIDocumentationPanel.updateViewport` (gemessen mit `DocuRun`) | geändert (F4.8a): `isItalic` (Javas Stil 2, mit Fett 3; ging vorher beim Speichern verloren); ein Element behält Größe und Schriftgröße seiner Datei (Swift vergrößert auf 32 × 24, Schrift nur 8–72); fehlende Schrift Dialog 12; neue Elemente 100 × 50, Fläche grau (204), Text schwarz; Javas 15 Text- und 12 Flächenfarben, Schriftgrößen 12/18/24, Stile Normal/Kursiv/Fett; `resizedFrame` (Javas Ziehen am Rand, kleinste Größe Fläche 20 × 20, Text 88 × 20); `inJavaDrawingOrder` (Texte über Flächen, je Art das frühere oben) | | `src/runtime/config.ts` | `State/TopologyEditorState.swift` (Laufzeit-Konfigurationen, WLAN eines Rechners, DHCP, Portweiterleitung, Remote Link ohne LAN-Transport, Programme und ihre Konfiguration, Firewall, DNS-Einträge aus `State/TopologyDNSResolver.swift`, E-Mail-Konten und -Nachrichten aus `State/TopologyEmail.swift`); dazu Echo-Server- und Client-Konfiguration, die Swift nicht speichert | übertragen; Java-Beschriftungen der Oberfläche weggelassen | | `src/runtime/engine.ts` | `State/TopologyNetworkRuntimeEngine.swift` Z. ~313–3585, ~4472–5187 (UDP), ~4753–4850 | übertragen: Warteschlange, Uhr, Ethernet, Switch, ARP, IPv4, ICMP, Routing, Firewall, UDP-Sockets (binden, freie Ports nach Javas Zufall, senden samt Broadcast, zustellen, empfangen mit Wartezeit, schließen), TCP (Z. ~5187–5913: Server- und Client-Sockets, Handschlag mit Ergebnis, Segmente zu 1460 Byte bis zum PSH, höchstens drei Versuche, Abbau über alle Java-Zustände samt `TIME_WAIT`; seit F2.3c nach Javas `TCPSocket` an Java-Filius gemessen: je Versuch und für `TIME_WAIT` 3 RTT nach der Geschwindigkeit (8250 ms bei 90 %, Swift fest 7500 bzw. 2500 ms), der Zeitablauf zählt ab der Übergabe des Segments, vor ARP; ein Segment beendet `TIME_WAIT`; die Gegenseite schließt beim FIN von selbst; nicht bestätigte Daten schließen mit FIN statt sofort; der angenommene Socket hat die Startnummer des Listeners, der Listener eine neue. seit F2.3e wie Java: SYN+ACK und FIN gehen nie ein zweites Mal hinaus; der Server gibt einen Handschlag nach 3 RTT auf und schließt mit FIN; nach dem FIN wartet ein Socket höchstens fünfmal 3 RTT, jedes Segment beendet eine Wartezeit, dann CLOSED (Java lässt den Zustand stehen). Abweichend von Java: drei SYN statt einem, weil Javas Wiederholungsschleife nach dem ersten Zeitablauf abbricht, und ein wiederholtes SYN in `SYN_RCVD` bekommt das SYN+ACK noch einmal, statt den Socket zu schließen), DHCP (Z. ~5913–6694: Server mit festen Zuordnungen, Adressbereich, Angeboten, Leases und Sperrliste; Client seit F2.3b nach Javas `DHCPClient` neu gebaut und an Java-Filius gemessen: je Versuch eine Nachricht, eine Antwort, die nicht passt, wird gelesen und verworfen; die ARP-Prüfung wartet eine RTT, eine Antwort für die Adresse beendet sie sofort, dann DECLINE; nach einem Zeitablauf wiederholt der Zustand seine Nachricht, nach dem fünften nimmt der Client eine Link-Local-Adresse `169.254.1.x/16` (ARP-Probe, ARP-Reply an alle) und gibt keine alte Adresse zurück; Swift sendete doppelt, wartete nicht auf ARP und kehrte nach zehn Versuchen zur alten Adresse zurück. Abweichend von Java: Nach fünf belegten Link-Local-Adressen gibt der Client auf (Java sucht endlos), und ein ARP-Paket für eine andere Adresse beendet die Prüfung nicht. Seit F2.3d befördert ein Kabel einen Frame nach dem anderen wie Javas `SimplexVerbindung` (ein Frame wartet im Ausgangspuffer, bis der vorige angekommen ist, und erscheint im Protokoll, wenn er losgeht); Swift schickt alle zugleich, die Option `swiftCables` behält das für den Swift-Vergleich. Die RTT der DHCP-Zeiten (Warten, Angebote, Sperrliste) folgt wie in Java der Geschwindigkeit (50 Kabel, 2750 ms bei 90 %); Swift rechnet fest mit 2500 ms. ARP seit F2.4b nach Javas `holeARPTabellenEintrag`, an Java-Filius gemessen: eine Auflösung fragt, wartet eine RTT, fragt ein zweites Mal und gibt nach einer weiteren RTT auf; dann „Host unreachable" beim Absender selbst oder vom Router zurück (bei ICMP nur für Echo-Anfragen); ein wartender Absender wacht nach den übrigen Ereignissen desselben Zeitpunkts auf; der Ping wartet danach eine RTT auf die Antwort. Swift schickt in der Ereignisverarbeitung beide Anfragen zugleich und lässt das Paket ohne Ende warten, wenn die Adresse irgendwo im Netz vorkommt (Wissen, das kein Knoten hat), und blockiert direkte Aufrufe ohne Wartezeit; die Option `swiftArp` behält das für den Swift-Vergleich. Seit F2.4b-2 kehrt ein Senden wie in Java sofort zurück, die Frames reisen, während die Uhr läuft (Swift: der Aufruf kehrt erst zurück, wenn alle Frames angekommen sind; die Option `swiftSends` behält das für den Swift-Vergleich), und UDP und TCP senden über Javas Transport-Thread je Knoten und Protokoll: ein Segment nach dem anderen; solange IP auf ARP wartet, blockiert das nächste `senden`. Wartende Absender kommen in der Reihenfolge an die Reihe, in der sie kamen (Javas Sperre überlässt das dem Zufall). Seit F2.4b-3 geht jedes ankommende Paket wie in Java durch den IP-Thread (UDP, TCP) oder den ICMP-Thread (ICMP) seines Knotens: zustellen, Echo-Reply, weiterleiten, eins nach dem anderen; solange ARP wartet, warten die folgenden. Abweichend von Java weckt eine ARP-Antwort alle, die auf die Adresse warten (Javas `notify` weckt einen beliebigen). DNS seit F2.4a nach Javas `DNSServer`/`Resolver`, an Java-Filius gemessen: Server auf Port 53 mit Einträgen aus dem Modell (die Antwort wiederholt die Frage nicht, RCODE immer 0, ein Verweis mit NS und A im Antwortteil), iterativer Resolver mit 5 RTT je Anfrage, der nur die Server behält, an die er verwiesen wurde; seit F2.4c auf den Ereignissen statt blockierend und mit rekursivem Server nach `DNSServer.answerWithRemoteData` (Nameserver der Zone, dann der eigene DNS-Server, sonst Verweis), abweichend von Java fragt er sich nie selbst (Java endlos). Gateway-NAT seit F2.6 (Z. ~3585–3900) nach Javas `filius.software.nat`, an Java-Filius gemessen: die Übersetzung vor dem IP-Thread (wie Javas NAT-Threads zwischen Karte und Ethernet), ausgehend WAN-Adresse und der Port des Eintrags (ICMP behält die Kennung), eingehend nach Gegenstelle, Port und Protokoll, sonst nach der Portweiterleitung (legt einen dynamischen Eintrag an), ein Ping an die WAN-Adresse beantwortet der Heimrouter, Pakete von außen an das LAN verschwinden, beide Seiten durch die Firewall des Heimrouters, ausgehend TTL 1 bekommt „Zeit überschritten“; dynamische Einträge verfallen nach 300 s mal Javas Verzögerungsfaktor (Swift fest 300 s), aufgefrischt nur eingehend, seit 01.10.2026 genau in diesem Alter (Java findet sie erst bei seiner sekündlichen Prüfung, bis zu 1 s später; so auch der Switch: Javas `checkSAT` prüft jede Sekunde, der Kern verfällt genau zur Lernzeit); der Heimrouter leitet weiter wie ein Router. Abweichend von Java: ein LAN-Endpunkt bekommt für jede neue Gegenstelle einen Eintrag auf demselben WAN-Port (Java behält nur den für die erste, die Antworten weiterer bleiben am Heimrouter hängen). RIP seit F2.5a (Z. ~4700–5090) nach Javas `filius.software.rip`, seit F2.5b an Java-Filius gemessen (die Pause in Javas `float`-Rechnung): eine Route mit 0 Hops je eigenem Netz, die nie verfällt; der erste Beacon nach einer Sekunde, dann alle 25,2–35,2 s aus einem Zufall je Router (Java: ein ungesetzter `Random` je Router; der Kern setzt ihn aus Szenario und Router-ID, `ripSeed`; Swift: ein Zufall für alle); eine Nachricht je Schnittstelle ohne die Routen über sie (Split Horizon); eine neue Route oder mehr Hops vom selben Router senden sofort; eine gelernte Route wird genau nach ihren 75 s auf 16 gesetzt und sofort gemeldet (Java erst beim nächsten eigenen Beacon, bis zu gut 30 s später; Swift bei jedem Ereignis; seit 01.10.2026, vorher wie Java); Nachrichten von jedem Quellport (Swift: nur 521); ein RIP-Router leitet nur nach seiner Tabelle weiter, wenige Hops vor langer Maske. `receiveUdp` kehrt wie Javas `empfangen` zurück, sobald ein Datagramm da ist. Seit der Abnahme F2 nach Javas `ARPThread`: ein Eintrag entsteht nur aus einer Anfrage nach der eigenen Adresse oder aus einer Antwort (Swift: aus jedem Paket; `swiftArp` behält das), ein Paket von der Netzadresse wird verworfen; ein Rechner leitet weiter, wenn seine IP-Weiterleitung an ist (`ipForwardingByNodeId`). Seit F2.8b nach Javas Tabellen gemessen: eine ARP-Anfrage trägt als Ziel-MAC die Broadcast-Adresse (Swift: Nullen; `swiftArp` behält sie), eine ICMP-Fehlermeldung Identifier und Sequenznummer 0 (RFC 792, Java; Swift kopiert die des Echos, ein Ping erkennt die Meldung am eingebetteten Echo), und „Host nicht erreichbar“ vom Router trägt das Paket, wie er es weitergeleitet hat (TTL gesenkt). Die Broadcast-Adresse schreibt sie immer groß (Java in der Antwort an 0.0.0.0 klein). Den Mitschnitt je Karte (`capture.ts`) schreibt sie seit F2.8a dort, wo Java ihn schreibt: beim Abgang auf das Kabel und bei der Ankunft an der Karte. Seit F3.4a läuft die Befehlszeile mit (`terminal`, auf den Dateien des Knotens). Seit F3.4b nach Javas `ICMP`/`ICMPThread`, an Java-Filius gemessen: ein Echo im Programm-Thread (`icmpEchoSteps`: Warteschlange leeren, senden mit ARP-Wartezeit, eine RTT auf die erste ICMP-Nachricht warten, gleich welche), ein ICMP-Paket an den Broadcast eines eigenen Netzes geht mit TTL 1 an alle und wird von dort beantwortet, einer für ein fremdes Netz verworfen; Javas Routenwahl (`routeRow`), die ARP-Tabelle mit Javas Broadcast-Zeile (`arpTable`, `removeArpEntry`, `resetArpTable`), DNS im Programm-Thread mit Antwort- und Autoritätsteil (`resolveDnsSteps`), ein UDP-Socket weiß, dass er ohne Gegenstelle lauscht (`listening`); ein Rechner nimmt Pakete an 127.0.0.1 an. Eine ARP-Wartezeit endet wie Javas `wait` nach allem, was zur selben Zeit sonst geschieht (eine Antwort zur selben Millisekunde zählt noch). Seit F3.4c die Uhrzeit eines Frames (`wallTime`) für `tcpdump`. Seit F3.6a läuft das Gnutella-Programm mit (`gnutella`, Schnappschuss `gnutellaByNodeId`), mit eigener Zufallsquelle für die GUIDs (`drawGnutellaGuid`). Seit F3.5a schreibt der Mailserver seine Kontendatei `/mailserver/konten.txt` beim Start und bei jeder Änderung seiner Konten in die Dateien des Knotens (Java schreibt die Benachrichtigung an einen lokalen Absender erst beim nächsten Speichern hinein). Abweichend von Java: eine Echo-Antwort kommt von der gefragten Adresse (RFC 792; Java antwortet von 127.0.0.1, wenn die eigene Adresse gefragt war, und von der nahen Karte, wenn die ferne eines Routers gefragt war), und „Netz nicht erreichbar“ vom Router trägt wie „Host nicht erreichbar“ das Paket, wie er es weitergeleitet hätte, mit Absender (Java bettet ein halb gebautes ohne Absender ein). Seit F3.3b läuft das E-Mail-Programm mit (`emailClient`), seine gesendeten und abgeholten Mails stehen im Schnappschuss (`emailClientsByNodeId`); ein Programm-Thread kann MX nachschlagen (`resolveDnsMailServerSteps`). Seit F3.3a läuft der E-Mail-Server mit (`emailServer`); was er annimmt oder löscht, steht im Schnappschuss (`emailServersByNodeId`), aus dem es zurück ins Projekt geht; die Uhrzeit für seine Benachrichtigungen kommt aus der Option `wallClock`. Seit F3.2c ändert die Seite `konfig` der Router und Heimrouter die Firewall zur Laufzeit; die Änderung steht im Schnappschuss (`firewallConfiguration`), aus dem sie zurück ins Projekt geht. Seit F3.2b starten Router und Heimrouter ihren Webserver auf Port 80 mit Javas Seiten (Javas Server lauscht wegen eines Wettlaufs in `setAktiv` manchmal nie, der Kern immer; `swiftRouters` lässt ihn für den Swift-Vergleich weg), die Firewall führt ein Protokoll je Knoten (Regeltreffer bei TCP und UDP, verworfenes ICMP), das wie Javas Protokollseite einen Neustart überlebt, eine RIP-Route kennt die öffentliche Adresse des meldenden Routers (`hopPublicIp`), und TCP zählt Sequenznummern und Segmentgröße wie Java in Zeichen (UTF-16-Einheiten) statt in Bytes, ohne ein Zeichenpaar zu zerreißen; Bytes, die kein Text sind, zählen als Bytes. Seit F3.2a schließt ein Programm wie Javas `schliessen()` nur auf Bitte (`requestTcpClose`): Das FIN geht zur selben Zeit, nach dem, was der Programm-Thread noch tut. Seit F3.1 laufen Verbinden, Senden, Empfangen und Annehmen auch als Schritte eines Programm-Threads (`connectTcpSteps`, `sendTcpSteps`, `receiveTcpSteps`, `acceptTcpSteps`, `resolveHostSteps`); die blockierenden Aufrufe sind nur noch eine Hülle darum. Abweichend von Java: Ein Verbindungsaufbau ohne Route scheitert sofort (Javas Socket-Thread stirbt an der `RouteNotFoundException`, `verbinden` wartet ewig), eine Nachricht, die vor dem Schließen ankam, wird noch ausgegeben (Java verwirft sie), und Senden unterscheidet wie Java „nicht verbunden", „unterbrochen" und „Zeitüberschreitung". WLAN seit F2.7 an Java-Filius gemessen: zur Laufzeit ist ein Funkkabel ein Kabel wie jedes andere, und eine SSID verbindet nichts (nach ihr legt nur Javas Editor das Funkkabel, `JHostKonfiguration.updateWifiConnection`); Swifts Verbindung über die SSID zur Laufzeit, auch ohne Kabel (`wirelessAssociations`), nicht übernommen. Klasse statt Werttyp. Noch nicht übertragen (wirft `NotPortedError`): Remote Link | | `src/runtime/engine.ts` (ganze Millisekunden) | Java `System.currentTimeMillis` (long) | behoben (F4.6b): `start` und `advance` runden auf ganze Millisekunden ab, wie Javas Uhr zählt. Gefunden im Browser: der Raum gab `performance.now()` mit Bruchteilen weiter, und ein Ping blieb nach der ersten Zeitüberschreitung hängen; alle Tests liefen zuvor mit glatten Takten | | `src/runtime/engine.ts` (leere Nachricht), `test/apps.test.ts` | Java `TCPSocket.erstelleSegmente`, `TCPSocket.run` (gemessen mit `EchoWindowRun`) | behoben (F4.6g1): ein leeres Segment mit PSH an der erwarteten Stelle ist eine leere Nachricht und wird ausgeliefert (vorher galt es als Wiederholung, weil seine Nummer die nächste nicht weiterzählt; Javas Echo beantwortet sie). Java beendet eine Nachricht mit jedem PSH, auch dem eines wiederholten Segments (eine leere Nachricht mehr, wenn ein ACK verloren geht); hier nur mit einem neuen — ein wiederholtes leeres ist an seiner Nummer nicht von einem neuen zu unterscheiden (benannt) | | `src/runtime/apps/dnsServer.ts`, `src/runtime/dnsHosts.ts`, `src/runtime/engine.ts` (DNS-Server), `src/runtime/snapshot.ts` (`DnsServerSnapshot`), `test/dnsWindow.test.ts`, `test/dnsWindow.java.json` | Java `DNSServer` (`hinzuRecord`, `loescheResourceRecord`, `changeSingleEntry`, `leseRecordListe`, `schreibeRecordListe`), `ResourceRecord`, `GUIApplicationDNSServerWindow`, `DNSConfigTable` (gemessen mit `DnsWindowRun`) | neu (F4.6g2): der DNS-Server als Programm, das sein Fenster ändert — an und aus (sein Socket auf Port 53), rekursive Auflösung, und die Einträge, die `/dns/hosts` sind und bei jeder Anfrage gelesen werden wie in Java (ein anderes Programm, der Texteditor, ändert sie sofort); ohne Datei die der Einstellungen. Der Schnappschuss nimmt jetzt jeden installierten DNS-Server mit, ob er läuft (`isActive`). Der Leser von `/dns/hosts` zieht aus `packages/fls` hierher (`isHostsDomainName` statt `isDomainName`), dazu `newHostsRecord`, `dnsHostsText`, `hostsRecordsOf`. Gegen Javas Fenster geprüft, auch die Antworten des Resolvers. Abweichend von Java: ein hinzugefügter Eintrag behält, was ein anderes Programm inzwischen in die Datei schrieb (Java schreibt seine alte Liste zurück); eine Zelle ändert nur ihren Eintrag (Java auch die folgenden Einträge anderer Art); eine entfernte Zeile ist dieser Eintrag (Java der erste des Namens); ein Eintrag braucht einen Namen (Java nimmt den leeren) | | `src/runtime/apps/personalFirewall.ts`, `src/runtime/engine.ts` (`personalFirewall`, `addFirewallPortRule`, `removeFirewallRule`, Firewall-Protokoll mit Zeit), `src/runtime/apps/routerPages.ts` (`portRuleAdded`, `portRuleRemoved`), `test/firewallWindow.test.ts`, `test/firewallWindow.java.json`, `test/scenarios/firewall-pc.scenario.json` | Java `GUIApplicationFirewallWindow` (`hinzuRegel`, `loescheRegel`, `ruleToVector`), `Firewall` (`addRule`, `deleteRule`), `FirewallRule` (gemessen mit `FirewallWindowRun`) | neu (F4.6g3): die Firewall eines Rechners, wie ihr Fenster sie ändert — eine Portregel hinzugefügt (TCP, UDP oder beide; alle Absender oder nur die der eigenen Netze; akzeptieren, hinten angefügt), eine Regel entfernt; beides steht im Protokoll der Firewall (Java schreibt es nur ins Fenster). Das Protokoll trägt jetzt die Zeit jeder Zeile. Gegen Javas Fenster geprüft, mit Ping, TCP-Verbindung und DNS-Frage aus dem eigenen und einem fremden Netz nach jedem Schritt. Abweichend von Java: ein Port ist 1 bis 65535, Leerzeichen drumherum erlaubt (Java nimmt jede Zahl: −1 öffnet jeden Port beider Protokolle, 0 und 70000 ergeben Regeln, die nie greifen; ein Leerzeichen davor lehnt Java still ab) | | `src/runtime/apps/gnutella.ts` (`cancelSearch`, `setMaximumKnownPeers`, `fileRows`, `gnutellaResultRow`, `gnutellaPeerCountOfText`), `test/gnutellaWindow.test.ts`, `test/gnutellaWindow.java.json` | Java `PeerToPeerAnwendung` (`abbrechenSuche`, `setMaxTeilnehmerZahl`), `PeerToPeerClient`/`PeerToPeerClientMitarbeiter` (`beenden`), `GUIApplicationPeerToPeerAnwendungWindow` (`updateErgebnisTabelle`, `updateDateiTabelle`, `zahlPruefen`), gemessen mit `GnutellaWindowRun` | erweitert (F4.6g4): was Gnutellas Fenster vom Programm braucht — „Stopp!“ schließt jede Verbindung der eigenen Anfragen (Suchen, Beitreten, Herunterladen), die Treffer unterwegs sind verloren, weitergereichte fremde Anfragen bleiben; die Zahl der Teilnehmer gilt für die kommenden; die Dateien von `/peer2peer` (ohne Ordner) mit Typ; ein Ergebnis wie Javas Tabelle es zerlegt. Gegen Javas Fenster geprüft. Abweichend von Java: jede ganze Zahl ist eine Teilnehmerzahl (Javas Prüfung `musterNurZahl` nimmt nur eine Ziffer) | | `src/runtime/viewers.ts`, `src/runtime/captureRows.ts` (`javaFrameText`), `src/runtime/engine.ts` (`portNumber` der SAT, `clearDynamicNatEntries`), `src/runtime/capture.ts` (`clearDropped`), `test/viewers.test.ts`, `test/viewers-switch.java.json`, `test/viewers-nat.java.json` | Java `SwitchFirmware` (`holeSAT`, `loescheSAT`), `GatewayFirmware` (`holeNAT`, `createEintrag`, `loescheNAT`), `EthernetFrame.toString`, `Lauscher.getDroppedDataUnits`, `Verbindung.setDrop` (gemessen mit `ViewersRun`) | neu (F4.6g5): was die Anzeigen der laufenden Simulation zeigen — die Nummer des Switch-Anschlusses („Port 1“), die NAT-Tabelle in Javas Worten (ICMP „0 (Identifier: 1)“, die Portweiterleitung mit „*“ und ohne Zeit), „Tabelle zurücksetzen“ lässt die Portweiterleitung stehen, ein verworfener Frame in Javas Textform; die Liste der verworfenen Frames lässt sich leeren, ihre Nummern laufen weiter. Gegen Java geprüft. Abweichend von Java: die Switch-Tabelle ist nach Adressen geordnet (Javas nach seiner Hash-Tabelle) | | `src/runtime/captureWindow.ts`, `test/exchangeWindow.test.ts`, `test/exchangeWindow.java.json` | Java `AggregatedExchangeDialog`, `AggregatedExchangePanel`, `AggregatedMessageTable` (`update`, `writeToStream`, `prepareDataArrays`, `splitString`), `MessageDetailsPanel.update`, `Lauscher.reset` (gemessen mit `ExchangeWindowRun`) | neu (F4.7): das Datenaustausch-Fenster — je Frame die Zeile seiner höchsten Schicht (`exchangeRow`), seine Details wie Javas Baum (`captureDetailLines`: „Nr.: n / Zeit: t“, je Schicht Quelle, Ziel, Protokoll, Bemerkung, die der Anwendung mit ihrer Länge in „Bytes“, eine lange oder mehrzeilige darunter) und die Tabelle als Textdatei (`exchangeExportText`: Rahmen, Breiten 10/20/40, Bemerkung auf höchstens fünf Zeilen, „...“, CR LF). Gegen Javas Fenster geprüft, auch „Tabellen löschen“ (alle Karten leer, neu nummeriert). Abweichend von Java: eine leere Bemerkung wird leer exportiert (Java schreibt „null“) | | `src/runtime/engine.ts` (Installation), `src/runtime/apps/installation.ts`, `test/installation.test.ts` | Java `InternetKnotenBetriebssystem.installAndStartAppIfAvailable/entferneSoftware`, `WebServer.erzeugeStandardVerzeichnis`, `PeerToPeerAnwendung`/`EmailServer`/`DNSServer.setSystemSoftware/starten`, `tmpl/webserver_index_*`, `gfx/allgemein/splashscreen-mini.png` | neu (F4.6c): was ein Programm bei der Installation in die Dateien legt (Javas Startseite je Sprache, Bild, `/peer2peer`, `/mailserver/konten.txt`, `/dns/hosts`); `installProgram`/`removeProgram` im laufenden Betrieb — Einstellungen und fehlende Dateien aus dem Schnappschuss des Dokuments, Programm sofort gestartet; entfernt wird ein Server abgeschaltet, die Dateien bleiben. Die Programmerzeugung beim Start läuft über dieselbe `startProgram` in der bisherigen Reihenfolge | | `src/runtime/apps/web.ts` (F4.6d), `test/web.test.ts` | Java `WebBrowser.retrieveImages`, `GUIApplicationWebBrowserWindow.hyperLinkListener`, `WebServer.changeVHostTable/saveVHosts/setUseVHost` (gemessen mit `BrowserWindowRun`) | erweitert (F4.6d): die Zeile einer Seite nennt Host und Pfad, die eines Bildes trägt seine Daten (für das Fenster); `pageReference` und `linkTarget` — relative Bilder und Links zählen vom Ordner der Seite (Java vom Wurzelordner des Servers; für eine Seite im Wurzelordner sind die Anfragen Javas), eine Marke (`#…`) und andere Schemata führen nirgends hin; der Webserver schaltet seine virtuellen Hosts um und schreibt ihre Tabelle, nur mit vollständigen Zeilen (Java schreibt jede Zeile, und beim Lesen rückt eine Zelle einer unvollständigen in die Zeile davor) | | `src/runtime/apps/emailClient.ts`, `src/runtime/apps/emailServer.ts`, `src/runtime/emailAccountsFile.ts`, `src/runtime/engine.ts` (F4.6e) | Java `GUIApplicationEmailAnwendungWindow.kontoSpeichern/emailLoeschen`, `EmailAnwendung.setzeKonto/speichern/removeReceivedMail/removeSentMail`, `GUIApplicationEmailServerWindow`, `EmailServer.setMailDomain/benutzerHinzufuegen/kontoLoeschen` (gemessen mit `MailWindowRun`) | erweitert (F4.6e): das E-Mail-Programm setzt sein Konto (`accountOfForm` mit Javas Mustern für Ports und Benutzernamen, `splitName` wie Javas Dialog: letztes Wort Nachname) und schreibt es nach `/konten.txt` (`clientAccountFileText`, jetzt im Kern statt im Export), löscht eine Mail eines Ordners, prüft ein Formular wie Javas Fenster (`mailFormProblem`) und sendet mit dem Konto, mit dem die Mail geschrieben wurde; der Server setzt seine Domain (nicht leer, Javas Muster), legt ein Konto an (einen vorhandenen Namen in jeder Schreibweise nicht — Javas Fenster meldet es als angelegt) und entfernt eines, sein Startknopf schreibt die eigene Zeile des Fensters; die neue Domain steht sofort in Schnappschuss und Kontendatei (Java erst bei der nächsten Kontenänderung) | | `src/model/virtualFileSystem.ts` (`revision`) | — | erweitert (F4.6f1): ein Zähler, der sich mit jeder Änderung ändert (auch einem Löschen), damit der Raum ein Dateisystem nur zurückschreibt, wenn es sich geändert hat | | `src/runtime/threads.ts` | Javas Threads der Programme (`Anwendung extends Thread`, `ServerMitarbeiter`) | neu (F3.1): ein Programm-Thread als Generator, der liefert, worauf er wartet (Bedingung, Zeit oder beides); die Engine setzt nach jedem Ereignis fort, wessen Warten vorbei ist, in der Reihenfolge, in der die Threads begannen; nichts blockiert die Engine. Abweichend von Java: ein Thread wacht sofort, wenn seine Bedingung gilt (Java sieht oft nur alle 100 ms nach) | | `src/runtime/apps/program.ts` | Java `filius.software.Anwendung` | neu (F3.1): die Zeilen im Fenster eines Programms (strukturiert, damit der Editor sie übersetzt) und der Befehls-Thread (`ausfuehren`) | | `src/runtime/apps/server.ts` | Java `ServerAnwendung`, `ServerMitarbeiter` | neu (F3.2a, aus `echo.ts` herausgelöst): was jeder Server teilt — ein Thread nimmt Verbindungen an, solange er eingeschaltet ist, je Verbindung einer beantwortet jede Nachricht; ausgeschaltet schließt er Socket und Verbindungen; Port belegt → er schaltet sich aus; seit F3.3a kann ein Server das Gespräch einer Verbindung selbst führen (`converse`: Begrüßung, keine oder mehrere Antworten, Schließen) | | `src/runtime/apps/web.ts` | Java `filius.software.www` (`WebServer`, `WebServerMitarbeiter`, `WebBrowser`), die Adresszeile aus `GUIApplicationWebBrowserWindow.erzeugeURL` | neu nach Java (F3.2a): Webserver (Dateien unter `/webserver`, `index.html` für `/`, virtuelle Hosts aus `/www.conf/vhosts`, fünf Zeilen, ohne Rücksicht auf Groß- und Kleinschreibung, Inhaltsart nach dem Dateinamen, Bilder und Binärdateien in Javas Base64) und Browser (immer Port 80, Seite, dann ihre Bilder nacheinander über dieselbe Verbindung, dann schließen; Link ohne Host geht an den letzten). An Java-Filius gemessen. Abweichend von Java: nichts außerhalb von `/webserver` (Java löst `/../` auf und liefert jede Datei des Rechners), 400/501 statt eines stummen Abbruchs bei unlesbaren Anfragen, eine Anfrage ohne Version gilt als HTTP/1.1, der Browser zeigt „Server nicht erreichbar“, wenn keine Antwort kommt (Java nichts). Seit F3.2c wie Java: Eine Methode, die nicht genau `GET` oder `POST` heißt (`get`), wird gelesen und mit 501 beantwortet (vorher die Seite) | | `src/runtime/apps/routerPages.ts` | Java `VermittlungsrechnerBetriebssystem`, `GatewayFirmware`, `FirewallWebLog`, `VermittlungWeb`, `FirewallRule.toString`, Vorlagen `tmpl/vermittlung_index`, `gateway_index`, `routing` (de, en) | neu nach Java (F3.2b): die Seiten der Router und Heimrouter in der Sprache des Projekts — Index, `routes` (Weiterleitungs- oder RIP-Tabelle mit Javas Farben, Gültigkeit in ganzen Sekunden) und `log` (Firewall-Protokoll); die Vorlagen per Skript aus Javas Ressourcen übernommen (Zeilen wie Javas `readLine` mit `\n`). Abweichend von Java: `` statt Javas `` auf der deutschen Protokollseite | | `src/runtime/apps/firewallSettings.ts` | Java `FirewallWebKonfig`, Vorlage `tmpl/firewall_konfig_webseite` (de, en), `EingabenUeberpruefung` (`musterPort`, `isValidSubnetmask`) | neu nach Java (F3.2c): die Seite `konfig` der Router und Heimrouter — allgemeine Einstellungen, Standardaktion, Regeln verschieben, löschen, hinzufügen; Fehlerliste und wieder gefülltes Formular, wenn eine Regel nicht passt; Vorlagen per Skript aus Javas Ressourcen. An Java-Filius gemessen (`KonfigCases`, `RouterWebRun`). Abweichend von Java: ein Feld wird erst gegen die anderen geprüft, wenn alle gelesen sind (Java prüft die IP gegen die noch ungelesene Maske und umgekehrt und nimmt so keine Regel mit Adresse an); ein Fehler steht nur auf der Antwort auf das gescheiterte Hinzufügen (Java zeigt ihn auf jeder späteren Seite); bei mehreren Knöpfen kein Fehler ohne Hinzufügen (Java schreibt die nackte Liste); Text aus dem Formular wird maskiert (Java schreibt ihn roh, ein „$“ ließ die Seite scheitern); die Daten werden zerlegt, bevor sie dekodiert werden (Java dekodiert zuerst, ein getipptes „&“ zerriss das Formular), ein Feld ohne gültige URL-Kodierung gilt, wie es kam (Javas Dekodierer wirft, keine Seite kommt); Regel 0 nach unten tut nichts (Java wirft) | | `src/runtime/http.ts` | Java `HTTPNachricht`, Spring `UriUtils.encodePath`/`decode`, `java.net.URLDecoder` | neu nach Java (F3.2a): Anfragen und Antworten in Javas Textform, Javas Statustexte, Pfade kodiert wie `UriUtils`; seit F3.2c `javaUrlDecode` für Formulardaten wie `URLDecoder.decode` (UTF-8, `+` als Leerzeichen, scheitert, wo Java wirft) | | `src/util/javaBase64.ts` | Java `filius.rahmenprogramm.Base64` (iHarder) | aus `packages/fls` (`exportProject.ts`) in den Kern gezogen (F3.2a), dazu der Leser, der Leerraum überspringt | | `src/runtime/email.ts` | Java `filius.software.email.Email`, `AddressEntry`, `EmailUtils` | neu nach Java (F3.3a): Mails in Javas Textform (From, To, Cc, Subject, Date Received, Leerzeile, Text; kein Bcc), Adressen „Name “, Javas Größe einer Mail für POP3. Abweichend von Java: der Kopf endet an seiner Leerzeile, ein unbekanntes Feld wird übergangen (Java beendet dort den Kopf und liest die folgenden Felder als Text), eine Zeile ohne Feld beginnt den Text (Java verwirft sie) | | `src/runtime/emailAccountsFile.ts` | Java `EmailServer.listeBenutzerkontenZuString` | neu (F3.5a): die Kontendatei des Mailservers aus seinen Konten, aus `packages/fls` (Export) hierher verschoben, damit Export und Laufzeit dasselbe schreiben; Javas Fehler wie dort nicht übernommen | | `src/runtime/apps/emailServer.ts` | Java `EmailServer`, `SMTPServer`, `SMTPMitarbeiter`, `POP3Server`, `POP3Mitarbeiter`, `EmailKonto` | neu nach Java (F3.3a): Konten einer Domain, SMTP auf Port 25 speichert Mails an eigene Konten (wie Java neu gelesen) und schickt bei unbekannten Empfängern eine Benachrichtigung an einen Absender der Domain, POP3 auf Port 110 gibt Mails ab 0 nummeriert aus; beide zusammen ein- und ausgeschaltet, POP3 zuerst; SMTP-Antworten in der Sprache des Projekts; Fensterzeilen wie Java. An Java-Filius gemessen (`EmailRun`, `MailCases`). Abweichend von Java: nach einer Mail ist der Umschlag neu (Java antwortet dem nächsten Befehl 503 und behält Absender, Empfänger und Text); ein Befehl, den der Zustand nicht nimmt, bekommt 503 (Java schweigt), HELO beginnt neu; in DATA ist alles Text, auch `quit`; die Domain gilt in jeder Schreibweise; ein Empfänger ohne `@` ist unbekannt, ein leerer Absender bekommt keine Benachrichtigung (Java wirft), eine Benachrichtigung an eine Mail ohne From geht an den Absender des Umschlags (Java: `To: null`); POP3: eine Mail lässt sich mehrmals abrufen, eine fehlende Mail, `LIST` ohne Mails und falsche Argumente geben `-ERR` (Java: leere Mail, leere Antwort, Abbruch), `LIST n` listet die eine Mail, Nummern bleiben nach `DELE` (Javas `LIST` zählt neu), vor der Anmeldung `-ERR unknown command`, `QUIT` immer `+OK`. Seit F3.3b leitet der Server Mails an fremde Domains per MX weiter (in seinem eigenen Thread, je Weiterleitung ein neuer SMTP-Client) und schickt eine Benachrichtigung an einen fremden Absender mit leerem Absender an dessen Domain. Noch nicht: die Kontodatei `/mailserver/konten.txt` zur Laufzeit | | `src/runtime/apps/emailClient.ts` | Java `EmailAnwendung`, `SMTPClient`, `POP3Client`, das Senden aus `GUIApplicationEmailAnwendungWindow` | neu nach Java (F3.3b): das E-Mail-Programm sendet eine Mail an den SMTP-Server seines Kontos, eine Verbindung je Empfänger (An, Cc, Bcc), und holt die Mails seines Kontos vom POP3-Server (jede abgerufen, dann gelöscht); die Prüfungen des Fensters (kein Konto, Adresse, die Javas Muster nicht nimmt, kein Empfänger); Meldungen wie Javas Beobachter (Verbindung, versendet, getrennt, Ausnahmen); der SMTP-Client dient auch dem Server zum Weiterleiten. An Java-Filius gemessen (`EmailClientRun`). Abweichend von Java: der SMTP-Port des Kontos gilt (Java verbindet immer zu 25); drei SYN statt einem | | `src/runtime/apps/filePrograms.ts` | Java `FileExplorer`, `TextEditor`, `ImageViewer` und ihre Fenster, `config/filetypes.txt`, die Meldungen `sw_fileexplorer_msg1`–`3`, `fileexplorer_msg19` | neu nach Java (F3.5b): die Dateioperationen hinter den Knöpfen von Datei-Explorer (Ordnerliste, neuer Ordner, löschen, kopieren/ausschneiden/einfügen, umbenennen, importieren), Texteditor (speichern, speichern unter) und Bildbetrachter, auf den Dateien des Knotens; an Java-Filius gemessen (`FileCases`). Abweichend von Java: ein Ordnername, der zu keinem Namen wird, legt nichts an; Einfügen auf einen vorhandenen Namen wird abgelehnt (Java: zweiter Eintrag gleichen Namens); Umbenennen auf einen Namen mit `/` oder mit Leerzeichen am Rand wird abgelehnt, eine reine Änderung der Groß-/Kleinschreibung ausgeführt (Java lehnt sie ab); „Speichern unter“ und Import auf einen Ordnernamen werden abgelehnt (Java wirft); die Größe einer Textdatei sind ihre Zeichen | | `src/runtime/apps/filePrograms.ts` (F4.6f2), `test/filePrograms.test.ts` | Java `GUIApplicationTextEditorWindow.oeffnen/speichernUnter`, `Dateisystem.holeDatei/speicherDatei` (gemessen mit `TextEditorWindowRun`) | erweitert (F4.6f2): `openText` öffnet nach dem Ordner und Namen des Dialogs (der Name als Pfad, in jeder Schreibweise) und nur eine Textdatei (Java zeigt ein Bild als Base64-Text), ohne Fund `notFound` (Java vergisst die offene Datei); „Speichern unter“ nimmt `ordner/d.txt` als Datei d.txt in ordner (Java legt eine Datei mit `/` im Namen an) und lehnt einen leeren Namen und einen mit Leerzeichen am Rand ab (`invalidName`; Java legt solche Dateien an, das Dateisystem warf), einen fehlenden Ordner auch unterwegs (`folderMissing`) | | `src/runtime/apps/filePrograms.ts` (F4.6f3), `test/filePrograms.test.ts` | Java `GUIApplicationImageViewerWindow.oeffnen` (gemessen mit `FileExplorerWindowRun`) | erweitert (F4.6f3): `openImage` öffnet nach dem Ordner und Namen des Dialogs nur ein Bild (Java zeigt eine andere Datei als leeres Bild), ohne Fund `notFound` | | `src/runtime/apps/gnutella.ts` | Java `filius.software.dateiaustausch` (`PeerToPeerAnwendung`, `PeerToPeerServer`, `PeerToPeerServerMitarbeiter`, `PeerToPeerClient`, `PeerToPeerClientMitarbeiter`, `PingPaket`, `PongPaket`) | neu nach Java (F3.6a): Beitreten mit Ping und Pong in Javas Textformat über Port 6346, Weiterleiten an die eigenen Teilnehmer, Pongs auf dem Weg des Pings zurück, Höchstzahl der Teilnehmer, Zurücksetzen, Ordner `/peer2peer`; an Java-Filius gemessen (`GnutellaRun`). Die Swift-Fassung (`TopologyRuntimeGnutella.swift`, eigenes Protokoll) nicht übernommen. Seit F3.6b Suche mit Query und Treffern (weitergeleitet wie Pings, Treffer auf dem Weg der Query zurück), Ergebnisse, Download per HTTP über 6346 (`QueryPaket`, `QueryHitPaket`, `httpAnfrageVerarbeiten`, `herunterladenDatei`). Abweichend von Java: ein zweites Mal ankommender Ping bekommt keinen Pong, und seine Verbindung bleibt (Java wirft und schließt sie); wer Treffer geschickt hat, hält die Verbindung, damit auch die Treffer der weiter entfernten Teilnehmer zurückkommen (Java schließt sie, die gehen verloren); Größen in Treffer und Pong in Zeichen (Java: Base64-dekodiert) | | `src/runtime/apps/terminal.ts`, `src/runtime/apps/terminalTexts.ts` | Java `filius.software.lokal.Terminal`, die Eingabe aus `GUIApplicationTerminalWindow`, die Texte `sw_terminal_*` und `terminal_msg*` des Bündels | neu nach Java (F3.4a): die Befehlszeile mit Javas Zerlegung der Eingabe, Verteilung nach dem Befehlsnamen und den lokalen Befehlen `ls`/`dir`, `cd`, `pwd`, `mkdir`, `touch`, `cp`/`copy`, `mv`/`move`, `rm`/`del`, `cat`/`type`, `test`, `help`, `ipconfig`, `route`; Texte in der Sprache des Projekts, aus dem von Java geladenen Bündel erzeugt. An Java-Filius gemessen (`TerminalCases`). Abweichend von Java: die Größe einer Textdatei sind ihre Zeichen (Java dekodiert Base64); ein fehlender Ordner ist für `ls` „nicht vorhanden“, `ls /` nennt die Wurzel; `cd` auf eine Datei, `touch`/`mkdir` in fehlenden Ordnern und `cp` auf einen Ordnernamen scheitern; `..` bleibt an der Wurzel; `rm` und `mv` nehmen absolute Pfade absolut, die Wurzel ist nicht löschbar, nach dem Löschen des Arbeitsordners gilt der nächste verbliebene darüber; `mv` auf die Datei selbst benennt sie um. Seit F3.4b die Netzbefehle `ping` (Strg+C über `interrupt`), `host`, `nslookup`, `arp` und `netstat`, mit Javas Laufmarken; ein unbekannter Befehl wird wie bei Java sofort gemeldet, auch während ein anderer läuft; seit F3.4c `traceroute` und `tcpdump` (`arpsend` nicht gebaut, der Befehl ist unbekannt); an Java-Filius gemessen (`TerminalRun`). Abweichend von Java: `ping` nennt den Host, wo Java seinen ersten Parameter nennt (`-b` in der Statistik), und nimmt vor dem Host nur `-b` (Java nimmt jedes Wort und pingt einen Broadcast); `arp` und `netstat` listen in der Reihenfolge des Lernens bzw. Anlegens (Java: Reihenfolge einer `HashMap`); `netstat` zeigt von einem UDP-Server nur den lauschenden Socket (Java auch einen für jede je beantwortete Adresse, nie geschlossen); `traceroute` sagt sein Fazit vor der Endmarke (Java danach, wo sein Fenster keinen Text mehr zeigt) und nennt ein Ziel beim 20. Sprung erreicht (Java: nicht erreicht); `tcpdump` meldet jeden Frame sofort (Java schaut alle 100 ms); seit F4.6b `continueIn` — Javas Arbeitsverzeichnis überdauert Stopp und Start (`TerminalWindowRun`), das Fenster des Raums reicht es an das Programm des nächsten Starts weiter | | `src/runtime/apps/echo.ts` | Java `filius.software.clientserver` (`ServerBaustein`, `ServerBausteinMitarbeiter`, `ClientAnwendung`, `ClientBaustein`) | neu nach Java statt nach Swift (F3.1): Echo-Server (auf `server.ts`, sendet jede Nachricht zurück) und einfacher Client (verbinden über Adresse oder Namen, senden, empfangen, trennen), mit Javas Fensterzeilen. An Java-Filius gemessen. Abweichend von Java: Der Server merkt das Ausschalten, der Client die Verbindung sofort (Java alle 100 ms); ohne Route scheitert der Client sofort (Java wartet ewig ohne Meldung); ausgeschaltet bestätigt der Server noch das FIN seiner Verbindungen (Java gibt den Port frei, das FIN bleibt unbeantwortet) | | `src/runtime/dns.ts` | Java `filius.software.dns.DNSNachricht`, `Query`, `ResourceRecord` | neu nach Java statt nach Swift (Swift ersetzt Javas Textnachrichten durch `FILIUS-DNS-TYPED/1`): Kopfzeile `ID=… QR=… RCODE=… QDCOUNT=… …`, Frage- und Eintragszeilen, Suche nach Namen ohne Rücksicht auf Groß- und Kleinschreibung, NS der längsten Zone, sonst der Wurzel | | `src/runtime/ipv4.ts` | Engine `parseIPv4`/`sameSubnet` | übertragen | | `src/runtime/packets.ts` | Engine, Paketmodelle | übertragen; `Data` → `Uint8Array` | | `src/runtime/random.ts` | Engine, `TopologyJavaCompatibleRandom` | übertragen; BigInt für die 48-Bit-Arithmetik; dazu `nextDouble` (Javas `Math.random`, an OpenJDK 21 gemessen) | | `src/runtime/routeTable.ts` | `State/TopologyJavaRouteTable.swift` | übertragen ohne Tabellengeometrie (gehört in den Editor) | | `src/runtime/snapshot.ts` | Engine, `TopologyNetworkRuntimeTopologySnapshot` | übertragen, bisher mit den Feldern der übertragenen Schichten, seit der Abnahme F2 mit der IP-Weiterleitung, wo sie vom Standard der Art abweicht, seit F2.3 mit den DHCP-Einstellungen von Clients und Servern, seit F2.4a mit den eingeschalteten DNS-Servern, seit F3.1 mit den installierten Echo-Servern (Port, ein oder aus) und einfachen Clients, seit F3.2a mit den Webservern, Browsern und den Dateisystemen der Knoten, seit F3.2b mit der Sprache der Seiten, die Geräte selbst schreiben, seit F3.3a mit den E-Mail-Servern (Domain, Konten mit Postfächern, ein oder aus), seit F3.3b mit den E-Mail-Programmen (Konto, Ordner), seit F3.4a mit den Knoten, auf denen die Befehlszeile installiert ist; ohne Swifts WLAN-Einstellungen der Rechner (`hostWirelessConfigurationsByNodeID`), die zur Laufzeit nichts bewirken (F2.7) | | `src/runtime/speed.ts` | Engine, `TopologyNetworkRuntimeSpeed` | übertragen; dazu Javas RTT (`Verbindung.holeRTT`: 50 Kabel), die Swift nicht kennt | | `src/runtime/trace.ts` | Engine, Paketspur-Modell | übertragen | | `src/runtime/captureRows.ts` | Java `Lauscher.datenVorbereiten`, `classifyApplicationLayerProtocol`, die `toString` von `ArpPaket`, `IpPaket`, `IcmpPaket` | neu nach Java (F2.8b): die Tabelle des Mitschnitts, je Frame eine Zeile je Schicht (Ethernet; ARP, ICMP oder IP; TCP oder UDP; die Daten, wenn Javas `trim` etwas übrig lässt), in beiden Ansichten Javas (Ende als Adresse:Port samt Datenzeile, oder nur Ports und die Datenzeile ohne Enden); die Bemerkung bleibt strukturiert, `captureCommentText` sagt sie mit gegebenen Wörtern und Zahlenformat wie Java. An Javas eigenen Tabellen gemessen. Abweichend von Java: „ICMP Time Exceeded“ (Java: „Exeeded“) | | `src/runtime/capture.ts` | Java `filius.rahmenprogramm.nachrichten.Lauscher` | neu nach Java (Swift hat stattdessen die Paketspur je Schritt): der Mitschnitt je Netzwerkkarte, jeder gesendete und empfangene Frame einmal mit Zeit und Nummer, wie Java auch Frames an andere Karten und solche, die die Firewall verwirft; Switches ohne Liste; verlorene Frames getrennt; bleibt über Stopp und Neustart, geleert nur auf Wunsch. Abweichend von Java: je Port statt je MAC-Adresse (Java legt zwei Karten mit gleicher MAC zusammen) und höchstens 10.000 Frames je Karte, die ältesten 1.000 fallen auf einmal heraus, die Nummern bleiben (Java behält alles) | | `src/util/equal.ts` | — | neu (Ersatz für Swifts `Equatable`) | | `src/util/swiftString.ts` | — | neu: Swift-String-Verhalten, das der übertragene Code stillschweigend voraussetzt (Trimmen, Kleinschreibung je Skalar, kanonische Gleichheit, Sortierung nach Skalarwerten, Base64 wie Foundation); am Swift-Orakel gemessen, Leerraum und Steuerzeichen über ganz Unicode | | `src/model/virtualFileSystem.ts`, `src/model/defaultImages.ts` | `State/TopologyVirtualFileSystem.swift` | übertragen; Schlüssel in NFC statt Swifts kanonischer Wörterbuch-Gleichheit; Steuerzeichen nach Unicode Cc+Cf, ohne Foundations Tabellenfehler in Ebene 14; seit F3.4a die Einträge eines Ordners auch in der Reihenfolge ihres Entstehens, wie Javas Dateibaum (`entriesInCreationOrder`); seit F3.5b `renameInPlace`: ein Eintrag behält beim Umbenennen seine Stelle, auch bei reiner Änderung der Groß-/Kleinschreibung, wie Javas Knoten (`renameItem` bleibt Swifts Verschieben); seit F3.6b `javaFileTypeName` und `fileContentOfJavaType` (Javas Dateityp aus der Art und zurück), aus Export und Import von `packages/fls` hierher, damit auch der Gnutella-Download sie nutzt | | `test/virtualFileSystem.test.ts`, `test/vfs.*.json` | `TopologyProjectPersistenceTests.swift`, `TopologyEditorReducerTests.swift` (drei Dateisystem-Tests, als Fälle) | übertragen und erweitert: 11 Fälle, Ergebnis aus dem Swift-Kern | | `test/strings.test.ts`, `test/strings.*.json` | — | neu: Fälle und ganze Zeichenmengen, Ergebnis aus dem Swift-Kern | | `test/engine.test.ts` | `TopologyNetworkRuntimeEngineTests.swift` (21 von 72 Tests) | übertragen; `nextInt`- und `nextDouble`-Referenzwerte an OpenJDK 21 gemessen; die DHCP-Client-Tests seit F2.3b nach Javas Verhalten (neun, davon zwei benannte Java-Fehler, die der Kern nicht übernimmt); seit F2.8a sechs Tests für den Mitschnitt (über Neustart, Leeren, Obergrenze, verlorene Frames, Switches) | | `test/oracle.test.ts`, `test/scenarios/` | — | neu: 14 Szenarien (davon 2 UDP, 3 TCP, 4 DHCP), Ergebnis mit dem Swift-Kern abgeglichen (`tools/swift-oracle`); Schritte für UDP, TCP und DHCP; die vier DHCP-Szenarien folgen seit F2.3b Java, die drei TCP-Szenarien seit F2.3c; sie müssen von Swift abweichen; drei weitere (`firewall-and-loss`, `routed-two-networks`, `switch-lan`) folgen seit F2.4b ab der Spur, an der ARP scheitert oder ein Ping unbeantwortet bleibt, Java und stimmen bis dahin mit Swift | | `test/dhcpJava.test.ts`, `test/scenarios/*.java.json`, `test/scenario.ts`, `test/javaRun.ts` | — | neu: die DHCP-Szenarien gegen Java-Filius (`tools/java-oracle`, `DhcpRun`): je Client dieselben Frames in derselben Reihenfolge, Abstände auf 200 ms, dieselben Adressen am Ende | | `test/arpJava.test.ts`, `test/scenarios/arp-routed.scenario.json`, `test/scenarios/arp-java-*.java.json` | — | neu: vier ARP-Abläufe gegen Java-Filius (`ArpRun`): Frames, Abstände und wann jeder Aufruf zurückkehrt; die zwei Pings stimmen seit F2.4b-1, die zwei UDP-Abläufe seit F2.4b-2 (Javas Transport-Thread), drei Abläufe durch den Router seit F2.4b-3 (IP- und ICMP-Thread) | | `test/natJava.test.ts`, `test/scenarios/nat-home.scenario.json`, `test/scenarios/nat-java-*.java.json` | — | neu: sechs NAT-Abläufe gegen Java-Filius (`NatRun`): je Absenderkarte dieselben Frames in derselben Folge zur selben Zeit, dieselben Aufrufe, dieselbe NAT-Tabelle; freie Ports und TCP-Startnummern als Platzhalter; ein benannter Java-Fehler (`JAVA_BUGS`: die Antwort der zweiten Gegenstelle) | | `test/javaRun.ts` (`expectSameCaptures`) | — | seit F2.8a: der Mitschnitt jeder Karte gegen Javas Liste dieser Karte (dieselben Frames, dieselbe Folge, dieselbe Zeit), in den Vergleichen für ARP, WLAN, DNS, TCP, NAT, RIP und DHCP mit einem Client; seit F2.8b für jeden dieser Frames auch Javas Tabellenzeilen in beiden Ansichten (Wörter und Zahlen wie Javas deutsches Gebietsschema); seit der Abnahme F3 wahlweise Fluss für Fluss (`flow`): wo Frames verschiedener Verbindungen in beliebiger Folge kommen, je Fluss in Folge, mit Zeit und Tabellenzeilen; und nur ausgewählte Frames (`compared`) | | `test/echoJava.test.ts`, `test/scenarios/echo-java-*.java.json` | — | neu (F3.1): acht Abläufe mit Echo-Server und einfachem Client gegen Java-Filius (`EchoRun`): je Karte Frames, Zeiten und Tabellenzeilen, dazu die Fensterzeilen beider Programme auf Deutsch wie Java (Zeilen, die Java erst bei seinem 100-ms-Blick schreibt, dürfen dort bis zu 100 ms später kommen); drei benannte Java-Fehler (`JAVA_BUGS`: keine Route, nur ein SYN, das unbeantwortete FIN nach dem Ausschalten) | | `test/webJava.test.ts`, `test/scenarios/web-lan.scenario.json`, `test/scenarios/web-java-*.java.json`, `test/programLines.ts` | — | neu (F3.2a): elf Abläufe mit Webserver und Browser gegen Java-Filius (`WebRun`, mit den Dateien des Servers): je Karte Frames, Zeiten, Tabellen, die Fensterzeilen des Servers, Seiten und Bilder des Browsers (Fehlerseiten nach Status); Javas Threads hinken bei langen Übertragungen bis zu 130 ms nach, verglichen auf 200 ms; drei benannte Java-Fehler (`JAVA_BUGS`: `/../` liefert fremde Dateien, `HALLO` beendet die Verbindung stumm, nur ein SYN). `programLines.ts`: die Fensterzeilen der Programme auf Deutsch, geteilt mit `echoJava.test.ts` | | `test/routerWebJava.test.ts`, `test/scenarios/router-web.scenario.json`, `test/scenarios/routerweb-java-*.java.json` | — | neu (F3.2b): sechs Abläufe mit den Seiten der Router und Heimrouter gegen Java-Filius (`RouterWebRun`): Index, Routen (Weiterleitung und RIP), Protokoll nach verworfenem Ping und Regeltreffern, Heimrouter von innen und außen; seit F3.2c drei mit `konfig`: die Seite, „ICMP filtern“ aus und der Ping kommt durch, eine Regel angelegt und nach oben geschoben sperrt den Browser aus (benannter Java-Fehler: nur ein SYN); Startnummern ohne die Million (Javas Router-Server lauscht nicht immer), die Gültigkeit der RIP-Routen als Platzhalter (Javas versetzter Start); ein benannter Java-Fehler (``) | | `test/routerPages.test.ts` | — | neu (F3.2b): Farben und Hops der Routen-Seite, RIP bei 16 Hops und Sekunden, Index in beiden Sprachen, Regeltexte, UDP im Protokoll und das Protokoll über einen Neustart, Server beim Start und `swiftRouters`, öffentliche Adresse bei kürzerem Weg, TCP in Zeichen; seit F3.2c `konfig` über das Netz: Änderung in den Schnappschuss, eine Seite ohne Daten ändert nichts, Englisch, Heimrouter | | `test/firewallSettings.test.ts`, `test/firewall-settings.cases.txt`, `test/firewall-settings.{de,en}.java.json` | — | neu (F3.2c): 25 Fälle der Seite `konfig` gegen Java-Filius (`KonfigCases`), je Schritt Seite und Firewall, Deutsch und Englisch, darunter die Formulardaten, wie Javas Browserfenster (Swing) sie schickt; zehn benannte Java-Fehler (`JAVA_BUGS`), die erwartete Seite jeweils aus einem Java-Lauf mit demselben Zustand; dazu `javaUrlDecode` | | `test/web.test.ts` | — | neu (F3.2a): HTTP-Form, Pfadkodierung, Base64, Adresszeile, Bildersuche; am Server 400/501 (seit F3.2c auch für `get` und `Post`), Durchgriff, Ordner, Inhaltsarten, Binärdateien, virtuelle Hosts (fünf Zeilen, Schalter ohne Datei); am Browser Seite und Bilder, Link ohne Host, nur HTML sucht Bilder, keine Adresse, keine Antwort | | `test/emailServer.test.ts`, `test/email-server.cases.txt`, `test/email-server.{de,en}.java.json`, `test/mailAccounts.ts` | — | neu (F3.3a): 26 Fälle der SMTP- und POP3-Gespräche gegen Java-Filius (`MailCases`), je Nachricht Antworten, Fensterzeilen, Schließen und Konten, Deutsch und Englisch; 18 Fälle mit benannten Java-Fehlern (`JAVA_BUGS`); dazu Adressen, Mailtext und Größe, und im Kern: Ein- und Ausschalten, Postfächer im Schnappschuss und über einen Neustart, Datum der Benachrichtigung je Sprache | | `test/emailJava.test.ts`, `test/scenarios/mail-lan.scenario.json`, `test/scenarios/email-java-*.java.json` | — | neu (F3.3a): vier Abläufe mit dem E-Mail-Server gegen Java-Filius (`EmailRun`): SMTP, SMTP mit Fehlern und Benachrichtigung, POP3 zweimal angemeldet, POP3-Anmeldefehler; je Karte Frames, Zeiten, Tabellen, die Fensterzeilen von Server und Client und die Konten am Ende (das Datum der Benachrichtigung als Platzhalter); seit F3.5a auch die Kontendatei am Ende, wie Java die Konten schreibt (und wo Javas hinterlassene Datei hinterherhinkt) | | `test/emailClientJava.test.ts`, `test/scenarios/email-client-java-*.java.json` | — | neu (F3.3b): sechs Abläufe mit dem E-Mail-Programm und zwei Servern gegen Java-Filius (`EmailClientRun`): senden mit Weiterleitung, abholen, Server per Name und Benachrichtigungen von beiden Servern, falsches Passwort, kein Server, unbekannter Servername; je Karte Frames, Zeiten, Tabellen, die Meldungen von Programm und Servern, Posteingang, Gesendete und Konten am Ende; Javas 100-ms-Blick kostet je Verbindung (und je DNS-Antwort, auf die es so wartet) eine Periode Toleranz; ein benannter Java-Fehler (nur ein SYN); bei `byName` die Startnummern ohne die Million (Thread-Wettlauf in Java) | | `test/emailClient.test.ts` | — | neu (F3.3b): was das Fenster ablehnt, Bcc, der SMTP-Port des Kontos, eine ungültige Kontoadresse, eine Verbindung, die beim Warten endet, eine Mail ohne Absender aus dem Modell, die Ordner im Schnappschuss | | `test/filePrograms.test.ts`, `test/file-programs.cases.txt`, `test/file-programs.{de,en}.java.json` | — | neu (F3.5b): sechs Fälle der Dateiprogramme gegen Java-Filius (`FileCases`), je Schritt Rückgabe und alle Dateien, Deutsch und Englisch, benannte Java-Fehler (`JAVA_BUGS`); dazu Dateitypen, Ordnerliste, Bildbetrachter, leerer Ordnername | | `test/gnutellaJava.test.ts`, `test/gnutella.test.ts`, `test/scenarios/gnutella-java-*.java.json` | — | neu (F3.6a, F3.6b): sechs Abläufe des Beitretens und zwei der Suche mit Download gegen Java-Filius (`GnutellaRun`), Ergebnisse und Dateien am Ende, je Karte die Frames samt Tabellen (wo viele Verbindungen zugleich laufen: je Verbindung und Richtung mit ihren Daten), die Teilnehmer jedes Programms mit Zeit; Javas GUIDs ersetzen die gezogenen, damit Längen und Sequenznummern gleich bleiben; dazu Paketformat, doppelter Ping, Kopf ohne Paket, Lebensdauer, Dateien im Pong | | `test/terminal.test.ts`, `test/terminal.cases.txt`, `test/terminal.{de,en}.java.json` | — | neu (F3.4a): 16 Fälle der Befehlszeile gegen Java-Filius (`TerminalCases`), je Zeile die Handlung des Fensters, was das Programm sagt, Arbeitsordner und alle Dateien, Deutsch und Englisch; Javas Größe von Textdateien überall als Java-Fehler korrigiert, dazu acht Fälle mit benannten Java-Fehlern (`JAVA_BUGS`); ein Bild bleibt beim Kopieren ein Bild; jeder Text der Tabelle ist wörtlich Javas | | `test/terminalJava.test.ts`, `test/scenarios/terminal-net.scenario.json`, `test/scenarios/terminal-java-*.java.json` | — | neu (F3.4b): zwölf Abläufe der Netzbefehle gegen Java-Filius (`TerminalRun`) auf einem LAN mit DNS-Server, Router und Rechner dahinter: `ping` im LAN, über den Router, ins Leere, hinter dem Router unerreichbar, ohne Route am Router, Broadcast, eigene Adresse, Fehler, Strg+C; `host` und `nslookup`, auch ohne erreichbaren DNS-Server; `arp`; `netstat` mit TCP-Verbindung und DNS-Server; je Karte die Frames samt Javas Tabellen, je Rechner Texte und Laufmarken mit Zeit; benannte Java-Fehler (`JAVA_BUGS`); die Reihenfolge der Antworten auf einen Broadcast ist ein Wettlauf von Javas Threads (je Sekunde als Menge verglichen); seit F3.4c neun Abläufe mit `traceroute` (LAN, über den Router, unerreichbar, ohne Route, ins Leere, eigene Adresse, Fehler, Strg+C) und `tcpdump` auf zwei Rechnern; ein Wächter verwirft Aufnahmen, in denen Java sein Aufwecken verpasst hat; dazu zehn Einzelfälle (traceroute über 20 Sprünge, Strg+C vor dem Start, fremde Echo-Antworten, gerundeter Verlust, Broadcast bei anderer Maske, zufälliger Identifier und sein Weiterzählen, gleich lange Routen) | | `test/apps.test.ts` | — | neu (F3.1): wie Threads aufwachen (nach dem Ereignis, nach einer Pause hinter den anderen, ein Weckruf nur für sein Warten, Reihenfolge des Beginns, kein Warten auf schon Geltendes), und was die Java-Abläufe nicht zeigen: belegter Port, Name über DNS und ohne DNS, keine Route, unbestätigtes Senden, Neustart, eine Nachricht vor dem Schließen | | `test/captureRows.test.ts` | — | neu (F2.8b): die Regeln der Tabelle, die kein Java-Lauf zeigt (GNT, POP3, SMTP, HTTP, Javas `trim`, ICMP-Fehler mit eingebettetem ICMP, Ansicht ohne Enden) | | `test/wlanJava.test.ts`, `test/scenarios/wlan-lan.scenario.json`, `test/scenarios/wlan-java-*.java.json` | — | neu: vier Pings gegen Java-Filius (`WlanRun`): über Funkkabel, über ein Kabel und an ein Notebook mit der SSID des Switches, aber ohne Kabel (ARP scheitert in Java wie im Kern); Frames, Abstände, Ergebnis und Dauer | | `test/ripJava.test.ts`, `test/scenarios/rip-chain.scenario.json`, `test/scenarios/rip-java-*.java.json` | — | neu: zwei RIP-Abläufe gegen Java-Filius (`RipRun`, der Zufall jedes Routers auf `ripSeed` gesetzt): je Absenderkarte dieselben Nachrichten zur selben Zeit, jede Tabelle durch dieselben Zustände, derselbe Ping; die ersten 5 s (Javas gestaffelter Start) nur über den erreichten Zustand | | `test/dnsJava.test.ts`, `test/scenarios/dns-lan.scenario.json`, `test/scenarios/dns-java-*.java.json` | — | neu: fünf DNS-Abfragen gegen Java-Filius (`DnsRun`): Frames, Ergebnis und Dauer; seit F2.4b-1 alle wie Java; seit F2.4c dazu fünf mit rekursivem Server (`dns-recursive.scenario.json`, `dns-recursive-java-*.java.json`), einer nur bis zur Anfrage des Clients verglichen (`JAVA_UNTIL`: Javas Server fragt sich selbst ohne Ende) | | `test/tcpJava.test.ts`, `test/scenarios/tcp-java-*.java.json` | — | neu: sechs TCP-Abläufe gegen Java-Filius (`TcpRun`, drei davon mit genau einem verlorenen Frame, `loseFirst`): Frames mit Flags und Nummern, Socket-Zustände; benannte Java-Fehler (`JAVA_BUGS`: nur ein SYN, der Zustand bleibt nach dem Schließen stehen), `lostSynAck` nur bis zum zweiten SYN verglichen (`JAVA_UNTIL`) | | `test/routeTable.test.ts` | `TopologyJavaRouteTableTests.swift` (8 von 12 Tests) | übertragen; Geometrie- und Reducer-Tests folgen mit Editor und Dokument | ## packages/fls | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/zip.ts` | `Persistence/TopologyFLSArchive.swift` (Fehler, Grenzen, Pfadregeln, ZIP-Leser/-Schreiber, CRC-32) | übertragen; DEFLATE über `fflate`, mit Apples Abschneide-Verhalten nachgebildet; Pfadfaltung (NFC, Breite, volles Case-Folding) an 41 Paaren gegen das Swift-Orakel gemessen | | `src/archive.ts` | ebenda, Archiv-Teil von Import und Export | übertragen, ohne die XML-Ebene | | `src/javabeans.ts`, `src/javaDefaults.json` | — | neu: XMLEncoder-Leser nach den Regeln von `java.beans.XMLDecoder` (Swift liest elementweise und verliert geteilte Werte); Getter-Standardwerte und statische Konstanten mit `tools/java-oracle` gemessen; merkt sich den Java-Typ jedes Primitivs an Settern, Konstruktor- und Aufrufargumenten und welche Eigenschaften ein eigener Getter angelegt hat (für `beanCapture.ts`) | | `src/javaDefaults.json` (`#priority`) | Java `Thread.getPriority` (gemessen mit `GetterDefaults`) | nachgetragen (F4.6c): die Priorität der gespeicherten Thread-Klassen (5); Javas Datei kann eine Zahl über einen solchen Getter-Wert benennen (`idref`), unaufgelöst las der Import 0 | | `src/importProject.ts` | `Persistence/TopologyProjectStore.swift` (Knoten, Ports, Kabel, IP-Konfiguration, Switch/WLAN, Routen, RIP, Firewall, DHCP, Portweiterleitung, Modem, Dateisysteme, Programme, Doku-Elemente des Imports) | übertragen, Eingabe ist Javas Sicht: Name und Port-Anzahl wie Java, abgelehnte Adresse → Swift-Standard, Router-Standardgateway wie Java (Swift verliert es), jede Router-Firewall eingetragen, Konfigurationstexte wie in Swift getrimmt (`swiftTrim`), Rechner ohne Dateisystem leer wie in Java (Swift: Demo-Dateien), alle Programme bleiben (Swift verwirft sechs), Webserver-Dateien bleiben in `/webserver` (Swift: `/www`), keine versteckten Zustandsdateien im Dateisystem, DNS-Einträge so, wie Javas Server sie aus `/dns/hosts` beantwortet, WLAN eines Rechners eingeschaltet nach Javas Funk-Merkmal der Karte (auch ohne SSID; Swift: jede SSID); der Webserver behält Javas Schalter für virtuelle Hosts (Swift: aus); gegen Swifts importiertes Modell auf 13 Dateien geprüft; seit der Abnahme F2 die IP-Weiterleitung eines Knotens, wo sie vom Standard seiner Art abweicht (`ipForwardingByNodeId`; Java `ipForwardingEnabled`, übersehen bis das Firewall-Beispiel lief) | | `src/importProject.ts`, `src/exportProject.ts` (Dokumentation) | Java `JDocuElement.setColor(null)`, `Font` (gemessen mit `DocuRun`) | geändert (F4.8a): Kursiv gelesen und geschrieben (Stil = Fett 1 | Kursiv 2); ein Element ohne Farbe bekommt Javas Hellgrau (192) statt Schwarz bzw. Swifts Blassgelb; Java lädt das Geschriebene so (exported.java.json neu) | | `test/importProject.test.ts` | — | neu: Swifts importiertes Modell (13 Dateien, begründete Abweichungen; im Dateisystem ausgenommen nur Swifts versteckte Zustandsdateien), Vollständigkeit aller 23, Pings im Kern (über einen Router; über drei Router mit manuellen Routen und Router-Gateways; seit F2.7 über Funkkabel); seit der Abnahme F2 IP-Weiterleitung und eingeschaltete DNS-Server im Schnappschuss; seit F3.2c eine Firewall, über `konfig` im Lauf geändert, gespeichert und wieder geöffnet (`internetwork_komplett.fls`); seit F3.3a eine Mail, im Lauf per SMTP angenommen, gespeichert und wieder geöffnet (`email_komplett.fls`); seit F3.3b eine Mail vom Programm über den MX an die andere Domain, abgeholt, gespeichert und wieder geöffnet; seit F3.4a Ordner und Datei aus der Befehlszeile, gespeichert und wieder geöffnet | | `src/systemSoftware.ts` | Java `SwitchFirmware`, `Betriebssystem`, `VermittlungsrechnerBetriebssystem`, `GatewayFirmware`, `Weiterleitungstabelle`, `Firewall`, `FirewallRule`, `DHCPServer`, `ModemFirmware`, `Dateisystem`, `Datei` | neu nach Java: SSID, Lernzeit, RIP, manuelle Routen, Router-Firewall (an allen Stellen, an denen die Datei sie erreicht), DHCP (ein kaputter statischer Eintrag fällt allein weg, Java verliert alle folgenden), statische NAT, Modem, Dateisystem (bei Router und Heimrouter das, was die Datei zu den Vorlagen des Konstruktors hinzufügt, oder eine eigene Wurzel, die sie ersetzt), installierte Programme von Rechner und Notebook (eigene Anwendungen eines Projekts als erfasste Bean, `beanCapture.ts`); `Character.isWhitespace` am JDK gemessen; gegen Java geprüft; seit der Abnahme F2 `ipForwardingEnabled` jedes Knotens mit IP-Stapel, mit Javas Standard der Klasse (Router und Heimrouter an) | | `src/javaIp.ts` | Java `IP.inetAton`/`ipCheck` | neu nach Java; an 46 Fällen mit Java gemessen; seit F2.5a in `packages/core/src/util/javaIp.ts` (der Kern liest damit RIP-Nachrichten) | | `src/dnsHosts.ts` | Java `DNSServer.leseRecordListe`, `ResourceRecord`, `Dateisystem.holeDatei`; Swift `State/TopologyDNSResolver.swift` (`TopologyDNSHostsFileCodec`) als Vergleich | neu nach Java: Felder nur an einzelnen Leerzeichen, keine Kommentare, ungültige TTL → 3600, Doppelte bleiben; ins Modell kommt nur, was Java beantwortet (Typ A/MX/NS, Name nicht leer); Javas Fehler nicht übernommen: Label mit Ziffer vorn erlaubt, kein Backslash, letztes Label nicht rein numerisch (RFC 1123/3696), Typ in jeder Schreibung (RFC 4343), negative TTL ungültig (RFC 2181); an 76 Fällen mit Java und Swift gemessen | | `src/dnsHosts.ts` (F4.6g2) | — | umgezogen (F4.6g2): der Leser von `/dns/hosts` liegt jetzt im Kern, wo der DNS-Server der Engine die Datei bei jeder Anfrage liest; hier bleibt das Finden der Datei im Baum eines Projekts, `isDomainName` ist `isHostsDomainName` des Kerns | | `src/topology.ts` | Java `SzenarioVerwaltung.netzwerkLaden`, Konstruktoren und Setter der Geräte; Swift `Persistence/TopologyProjectStore.swift` (Parser) als Vergleich | neu nach Java statt Übertragung: Geräteart aus der Klasse statt aus der Beschriftung, Geräte ohne Koordinaten bei 0,0 statt verworfen, Werte durch Javas Setter, die Zeichen-Enden eines Kabels, die Funk-Eigenschaft einer Netzwerkkarte (`wireless`, bis 30.09.2026 übersehen) | | `test/javabeans.test.ts` | — | neu: je XMLDecoder-Regel ein Test; alle 23 Korpus-Dateien, Klasse und Position jedes Geräts wie Java | | `test/topology.test.ts` | — | neu: alle 23 Korpus-Dateien Feld für Feld wie Java (Geräte, Schnittstellen, Kabel, Doku-Elemente), dazu die Regeln, die der Korpus nicht berührt; Java lädt seit M8 über den vollständigen Ladeweg, eigene Anwendungen (`test/ownApplications.ts`) sind bis B2 ausgenommen | | `test/javaIp.test.ts`, `test/ip-check.*` | — | neu: `IP.ipCheck`-Fälle, Ergebnis aus Java | | `src/javaEmail.ts` | Java `EmailServer` (Konten-Bean, `kontenLaden`/`stringZuListeBenutzerkonten`), `EmailAnwendung` (Ordner, Adressbuch, `laden`), `EmailKonto`, `Email`, `AddressEntry`, `EmailUtils` | neu nach Java: E-Mail-Beans über ihre Setter, `/mailserver/konten.txt` und `/konten.txt` im Format von Javas Lesern, ohne ihre Fehler (leere Felder zählen, eine kurze Zeile fällt allein weg, Nachrichten mit leerem Text oder Betreff bleiben, `;` im Betreff bleibt, CRLF, beim Client die letzte vollständige Zeile); Empfänger älterer Dateien als Zeichenketten; gegen Java auf dem Korpus und an 43 Fällen geprüft (13 benannte Java-Fehler) | | `src/beanCapture.ts` | — | neu: eine decodierte Bean zurück in die Form des Schreibers, mit Javas Zahlentypen; der Verweis auf das Betriebssystem des Knotens als Marke; was das Format nicht sagen kann (Unaufgelöstes, `Field`, Fabrikmethode, ein anderswo per Getter erreichtes Objekt), wird abgelehnt, nicht geraten; Rundlauf-Tests in `test/beanCapture.test.ts` | | `src/javaBeansWriter.ts` | — | neu: Schreiber für das `XMLDecoder`-Format, Gegenstück zu `javabeans.ts`; ausdrücklich typisierte Eingabe, geteilte Objekte über `id`/`idref`, was XML nicht fassen kann (und CR) als ``; von Java selbst geprüft (`BeansDump`) | | `test/javaBeansWriter.test.ts`, `test/beans/` | — | neu: 11 Dateien des Schreibers, von Javas `XMLDecoder` gelesen und beschrieben; Erwartungen von Hand | | `src/projectSnapshot.ts` | Swift `TopologyNetworkRuntimeTopologySnapshot(editorState:)` | neu (Abnahme F2): das importierte Projekt als Schnappschuss des Kerns; nur die Kabel verbinden (Swifts Verbindung über die SSID nicht übernommen), nur eingeschaltete DNS-Server laufen; seit F3.1 jeder installierte Echo-Server (ein oder aus, er lässt sich zur Laufzeit schalten) und einfache Client; seit F3.2a jeder Webserver und Browser und die Dateisysteme; seit F3.2c der Rückweg `projectWithSimulationChanges`: die Firewalls aus dem Schnappschuss des Laufs ins Projekt, wie Java sie beim Speichern hat; seit F3.3a die installierten E-Mail-Server (ein oder aus) und auf dem Rückweg ihre Postfächer; seit F3.3b die installierten E-Mail-Programme und auf dem Rückweg ihre Ordner; seit F3.4a die Knoten mit der Befehlszeile (ihre Dateien sind die des Projekts) | | `src/projectSnapshot.ts` (`emailServerAfterRun`) | Java `EmailServer` (gespeichert nach einem Lauf, gemessen mit `SaveAfterRunRun`) | erweitert (F4.6f1): der Rückweg nimmt auch die Domain eines E-Mail-Servers mit; als eigene Funktion für den Rückweg des Raums ins Dokument | | `src/projectSnapshot.ts` (DNS-Server) | Java `DNSServer.setAktiv` (das Fenster schaltet im Lauf an und aus) | geändert (F4.6g2): jeder installierte DNS-Server kommt in den Schnappschuss, mit `isActive` (vorher nur die laufenden) | | `test/examplesJava.test.ts`, `test/examples/*.java.json` | — | neu (Abnahme F2): fünf Beispiele von Filius (`internetwork_komplett`, `einfaches_rechnernetz_komplett`, `dns_server`, `nat_with_mapped_port`, `Internet_Komplett_…_DE`) mit dem eigenen Leser eingelesen und im Kern gespielt, gegen Java-Filius (`ExampleRun`): je Karte Frames, Zeiten und Tabellenzeilen, die Aufrufe, die Adressen am Ende; gleichzeitig startende DHCP-Clients je Client; zwei benannte Java-Fehler (`JAVA_BUGS`: Ping ohne Gateway wirft eine `NullPointerException`; NAT-Eintrag nur für die erste Gegenstelle) | | `test/classicsJava.test.ts`, `test/exampleRun.ts`, `test/examples/{web,email,gnutella}.java.json` | — | neu (Abnahme F3): die Unterrichtsklassiker auf Beispielen von Filius gegen Java-Filius (`ExampleRun`): Webseite über ihren DNS-Namen (`internetwork_komplett`), E-Mail zwischen zwei Netzen durch NAT und Weitergabe von Server zu Server (`Internet_Komplett_…_DE`), Datei per Gnutella über einen Router finden und holen, Ping, Pong und Query weitergereicht (`zwei_rechnernetze_komplett`, Programme vom Test eingesetzt); je Karte Frames, Zeiten und Tabellenzeilen (ohne RIP), die Zeilen jedes Programms, Mails, Teilnehmer, Ergebnisse und Dateien am Ende; Javas Fehler aus F3.6b und `closedPort` benannt (`JAVA_BUGS`); gleich lange RIP-Wege nach Javas Wahl (`equalRipTies`). `exampleRun.ts`: was beide Beispiel-Tests teilen (Datei öffnen, Javas Namen, Karten nach MAC) | | `src/importProject.ts` (`modemPair`, `modemPort`) | — | zusammengelegt (F4.5a): das Modem-Paar eines Ports an einer Stelle, für Import, Export und das Geräte-Blatt | | `src/topology.ts`, `src/importProject.ts`, `src/exportProject.ts`, `src/topologyWriter.ts` (Wolke) | Java `Switch.cloud`, `JSwitchKonfiguration` | nachgetragen (F4.3): ein Switch, als Wolke gezeichnet, wird gelesen, im Modell gehalten (`SwitchConfiguration.showsAsCloud`) und wieder geschrieben — vorher ging die Eigenschaft beim Lesen verloren (`nat.fls`, `man-in-the-middle.fls`); `FlsOracle` schreibt sie, Korpus und Schreib-/Exportproben neu geprüft | | `src/topologyWriter.ts` | Java `SzenarioVerwaltung.netzwerkSpeichern`, Konstruktoren von `NetzwerkInterface`, `Port`, `GUIKabelItem` und der Systemsoftware | neu nach Java: `konfiguration.xml` aus Javas Sicht — Geräte, Schnittstellen (vom Konstruktor angelegte über Getter, weitere per `add`), Ports über Getter-Verweise, Kabel samt Zeichen-Enden (`kabelpanel`), Doku-Elemente; Systemsoftware über ihre Setter: SSID, Lernzeit, RIP, manuelle Routen, DHCP-Client und -Server, statische NAT, Modem, Router-Firewall (über das `konfig`-Plug-in des Webservers, wie XMLEncoder sie erreicht); eigene Anwendungen eines Projekts, wie die Datei sie hatte; Dateisysteme (an die Wurzel des Konstruktors angehängt wie bei XMLEncoder, beim Router hinter dessen Vorlagen); installierte Programme nach den Dateien (Webserver, Tauschbörse und E-Mail-Server legen ihre Ordner nur an, wo sie fehlen; der DNS-Server liest `/dns/hosts` beim Installieren), je unter ihrem Schlüssel mit der Systemsoftware wie `installApp`, samt Einstellungen und persönlicher Firewall; E-Mail: Domain und Bean-Konten des Servers samt Postfächern, Ordner und Adressbuch des Clients (sein Konto steht in `/konten.txt`, einer Datei); Javas Fehler nicht übernommen: ein Empfänger, den eine ältere Datei als Zeichenkette hält, wird als der `AddressEntry` geschrieben, den Javas `AddressEntry(String)` daraus macht (Java legt die Zeichenkette ungeprüft in die typisierte Liste, sein E-Mail-Fenster scheitert daran), ein `null`-Empfänger fällt weg; Kopf „Filius version: 2.14.0 (mdg-filius)“; seit der Abnahme F2 `ipForwardingEnabled`, wo es vom Standard der Klasse abweicht | | `test/topologyWriter.test.ts`, `test/written.java.json` | — | neu: alle 23 Korpus-Dateien gelesen und neu geschrieben, von Java geladen — Topologie, Systemsoftware, Dateisysteme und Programme samt E-Mail wie beim Original (bis auf die benannte Abweichung bei Empfängern als Zeichenkette, nur in `man-in-the-middle.fls`) (Java gegen Java); dazu eine künstliche Topologie mit dem, was der Korpus nicht hat (u. a. eingeschaltete Router-Firewall mit Regeln jedes Protokolls, alle Firewall-Schalter abseits der Vorgabe, Modem mit eigenem Port und Ziel, verschachtelter Dateibaum mit umbenannter Wurzel, namenlosem Ordner, Datei ohne Typ und Inhalt mit CR/CRLF und Zeichen jenseits der BMP, Heimrouter mit eigener Wurzel, jedes Filius-Programm mit Einstellungen abseits der Vorgabe samt persönlicher Firewall, von Java angelegte Ordner `/peer2peer` und `/mailserver`, E-Mail-Server und -Client mit Konto, Postfach, drei Ordnern, Adressbuch und Empfängern aller Formen) | | `src/exportProject.ts` | Gegenstück zu `importProject.ts`; `saveProjectArchive` schreibt eine ganze `.fls` samt der übrigen Archiveinträge (Gegenstück: `openProjectArchive` in `importProject.ts`, das sie in `archiveEntries` des Modells legt); Java `JHostKonfiguration.updateWifiConnection`, `InternetKnotenBetriebssystem.getStandardGateway`/`setStandardGateway` | neu: Editor-Modell → Javas Sicht für den Schreiber, Schritt X1 Topologie — Geräte, Schnittstellen (MAC wie in der Simulation: aus der Datei oder aus der Port-ID abgeleitet), Kabel samt Funk (Karte drahtlos und Switch, wie Java verbindet), Gateway und DNS an allen Schnittstellen wie Javas eigene Setter, Doku-Elemente; X2 Systemsoftware — SSIDs, Lernzeit, Routen, RIP, DHCP-Client und -Server, Portweiterleitung, Firewall (Namen des Kerns als Javas Zahlen), Modems aus den Paaren des Modells (Port aus dem Paarnamen, der erste eines Paars dient, Ziel `localhost`); X3 Dateien von Rechner und Notebook — Typ aus der Inhaltsart (Text nach Endung, sonst `text`; Bild und Binärdaten nach Medientyp), Bilder und Binärdaten in Base64 wie Filius' `Base64.encodeBytes` (Umbruch nach 76 Zeichen, an 19 Längen mit Java gemessen); X4a Programme — je Programm die Filius-Klasse unter ihrem Namen als Schlüssel, eingeschaltete Server, Ports, virtuelle Hosts, DNS-Rekursion, Ziel des Clients (leer als `null` wie Javas Konstruktor), Teilnehmerzahl, persönliche Firewall; X4b E-Mail — Beans des Servers (Domain, Konten, Postfächer) und des Clients (drei Ordner, Adressbuch), `/konten.txt` und `/mailserver/konten.txt` aus den Konten des Modells neu geschrieben im Format von Filius 2.14 (`EmailKonto.toString`, `listeBenutzerkontenZuString`), ohne Javas Fehler (leere Felder statt "null"); ein Zeichen, das ein Feld im Format nicht tragen kann, wird dort zum Leerzeichen, mit Warnung; seit der Abnahme F2 die IP-Weiterleitung aus dem Modell | | `test/exportProject.test.ts`, `test/exported.java.json` | — | neu: alle 23 Korpus-Dateien importiert, exportiert, geschrieben und von Java geladen — Topologie wie beim Original bis auf benannte Abweichungen (abgeleiteter MAC und abgeleitete Switch-SSID statt gewürfelter, Modem-Rollen nach Reihenfolge im Paar, Doku in Zeichenreihenfolge mit Text, Schrift und Mindestgröße des Modells, Dateien in der Ordnung und mit dem Typ des Modells, keine eigenen Dateien von Routern, Empfänger als Zeichenkette gelesen, Nachrichten des Gesendet-Ordners versendet, Konto-Dateien neu geschrieben wie Filius 2.14); die übrigen Archiveinträge (eigene Anwendungen unter `projekt/anwendungen`) kommen byte-gleich zurück; eigene Anwendungen auf Rechnern gehen als erfasste Bean durch das Modell (`ownApplicationsByNodeId`) und werden zurückgeschrieben; dazu ein künstliches Modell, das Java ebenfalls lädt | | `src/importEmail.ts` | `Persistence/TopologyProjectStore.swift` (`registerJavaEmailConfigurations`, `assignedJavaEmailMessages`) | übertragen, Eingabe ist Javas Sicht: Server-Konten aus `/mailserver/konten.txt`, ohne Datei aus der Bean-Liste (Java verlöre sie); Client-Konto aus `/konten.txt`, ohne Datei aus der älteren `kontoListe` (Filius 2.14 liest sie nicht mehr); Konten und Nachrichten bleiben, wo Swift verwirft, was seine Prüfung nicht besteht; Vor- und Nachname getrennt; Empfangszeit nur aus der Datei (Swift nummeriert); gegen Swifts Modell geprüft | | `test/importEmail.test.ts`, `test/email-*.swift.json` | `State/TopologyEmail.swift` (`decodeJavaServer`, `decodeJavaClient`) als Vergleich | neu: dieselben 43 Kontodateien mit Swifts Leser; wie Swift bis auf benannte Fälle, in denen Swift prüft und die ganze Datei verwirft, wo Java liest | | `src/javaFileSystem.ts`, `src/javaString.ts` | Java `Dateisystem.holeDatei`, `String.trim`/`split`/`equalsIgnoreCase` | neu nach Java; die Groß-/Kleinschreibung gegenüber ASCII am JDK über die ganze BMP gemessen | | `test/javaEmail.test.ts`, `test/email-*.cases.txt`, `test/email-*.java.json`, `test/javaEmailNames.ts`, `test/javaFileSystem.test.ts` | — | neu: Kontodateien von Server und Client, Ergebnis aus Java; Dateifund | | `test/dnsHosts.test.ts`, `test/dns-hosts.*` | — | neu: `/dns/hosts`-Fälle, wie Java bis auf 7 benannte Java-Fehler, das Modell wie Swift bis auf benannte Fälle mit Grund | | `test/zip.test.ts` | `TopologyProjectPersistenceTests.swift` (Archiv-Ablehnungstests, `makeMinimalZIP`, `makePayloadZIP`) | übertragen, ergänzt um DEFLATE-Grenzfälle | | `test/corpus.test.ts` | — | neu: 23 Korpus-Dateien, gegengeprüft mit `fflate.unzipSync` | | `test/pathFolding.test.ts`, `test/path-folding.*.json` | — | neu: welche Pfade dieselbe Datei meinen, Ergebnis aus dem Swift-Kern | ## packages/doc | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/projectDoc.ts` | Plan §5.2 (Schema 1); das Modell ist `ImportedProject` aus `packages/fls` | neu (F4.1): ein Projekt verlustfrei in ein `Y.Doc` und zurück — Geräte, Ports mit ihren Einstellungen, Einstellungen je Gerät, installierte und eingeschaltete Programme, Dateien (Text als `Y.Text`, je Ordner in der Reihenfolge des Anlegens), eigene Java-Anwendungen (als Text, `long` erhalten), Kabel, Doku-Elemente, Archiveinträge; Reihenfolge über `order`, Gleichstand nach Schlüssel; Dateien tolerant gelesen | | `src/values.ts` | — | neu (F4.1): Einstellungen als `Y.Map` je Feld und Listen als `Y.Array`, damit gleichzeitige Änderungen verschiedener Felder und Zeilen beide bleiben | | `src/janitor.ts` | Plan §5.3 | neu (F4.1): der Hausmeister, I1 (Kabel ins Leere), I2 (zwei Kabel an einem Port: kleinere Kennung bleibt), I4 (fehlender Ordner, ohne Rücksicht auf Groß-/Kleinschreibung); deterministisch, idempotent, Ursprung `janitor` | | `src/snapshot.ts` | — | neu (F4.1): Schnappschuss des Kerns und `.fls`-Export eines Dokuments, beide über das Projekt (`projectSnapshot`, `saveProjectArchive`) | | `src/view.ts` | Java `Host.holeAnzeigeName`; `exportProject.joinsWirelessly` | neu (F4.3): die Zeichensicht ohne Dateisysteme — Geräte mit Javas Beschriftung und Wolke, Kabel mit Funk-Kennung, Doku-Elemente in der Zeichenfolge des Modells | | `src/commands.ts` | Java `GUIContainer.neuerKnoten`, Konstruktoren der Geräte, `GUIEvents` (Kabel), `InternetKnoten/LokalerKnoten.holeFreienPort`, `Gateway` | neu (F4.4a): neues Gerät mit Javas Voreinstellungen (gegen `NewDeviceRun` gemessen), Verschieben auf ganze Pixel, Löschen samt Kabeln, Kabel nach Javas Regeln (erster freier Port, Heimrouter WAN/LAN, Funk nur an Switch, nur einmal verbunden) mit Javas Meldungen als Gründe, Rückgängig je Person (`Y.UndoManager`, nur der eigene Ursprung) | | `src/fields.ts` | Java `EingabenUeberpruefung` (`musterIpAdresse`, `musterSubNetz`, `musterServiceSetIdentifier`, `musterNurZahlen`, `musterPort`), `IP.ipCheck`, wie `JHostKonfiguration`, `JSwitchKonfiguration`, `JModemKonfiguration` sie nutzen | neu (F4.5a): die Regeln der Felder des Geräte-Blatts, gegen Javas Felder gemessen (`SheetRun`). Abweichend von Java: Markieren und Übernehmen sind eine Regel — Java übernimmt rot markierten Text („10..0.0.1“, „+10.0.0.1“, „-0.0.0.1“, arabisch-indische Ziffern, Haltezeit „-5“), verwirft schwarzen („.0.0.1“, eine Haltezeit jenseits von `long`) und nimmt als Modem-Port jede Zahl (0, 65536, -1); hier gilt Javas `musterPort`. Leerzeichen um Adressen und Zahlen fallen weg (Java verwirft „ 10.0.0.1“) | | `src/settings.ts` | Java `JHostKonfiguration.aenderungenAnnehmen/aendereAnzeigeName/updateWifiConnection`, `JSwitchKonfiguration.aenderungenAnnehmen/changeAppearance`, `JModemKonfiguration` | neu (F4.5a): Name, Anzeige als Adresse/MAC, Adresse, Maske, Gateway, DNS, IP-Weiterleitung (nur abweichend von der Art gespeichert), DHCP (hält den eigenen DHCP-Server an), LAN/WLAN mit SSID samt Funkverbindung, SSID (wirft die Funkgeräte ab), Haltezeit und Wolke eines Switches, Port eines Modems (als Paar); je Änderung eine Transaktion mit Ursprung. Abweichend von Java: Der Name bleibt, wenn die MAC-Adresse angezeigt und ein anderes Feld übernommen wird (Java überschreibt ihn mit der MAC-Adresse); ein Rechner tritt dem ersten Switch mit der SSID bei (Javas Suche hängt von unbeteiligten Geräten ab); ein voller Zugangspunkt meldet sich mit Javas Meldung (Java baut ein Kabel ohne Port) | | `src/sheet.ts` | Java `JHostKonfiguration.updateAttribute/updateSsid`, `JSwitchKonfiguration.updateAttribute`, `JModemKonfiguration.updateAttribute` | neu (F4.5a): was das Blatt zeigt — je Art die Felder des Java-Panels, die Netze der Switches je einmal, WLAN nur bei freiem Port oder schon drahtlos, Haltezeit in ganzen Sekunden | | `src/settings.ts`, `src/sheet.ts` (Router, Heimrouter) | Java `JVermittlungsrechnerKonfiguration`, `JGatewayConfiguration`, `JWeiterleitungsTabelle`, `Weiterleitungstabelle.holeTabelle/validate/addManuellenEintrag` | erweitert (F4.5b): Adresse und Maske je Karte (die erste gespiegelt in den Einstellungen des Geräts, wie das Projekt sie hält), Standard-Gateway, RIP, die manuellen Zeilen der Weiterleitungstabelle (neue Zeile erst mit vier gültigen Zellen, Zelle, Löschen), DHCP am Heimrouter (lässt seinen DHCP-Server laufen, wie Java); das Blatt liest Karten mit dem Gerät am anderen Kabelende und die ganze Tabelle über `routeTableRows` des Kerns (gegen fünf von Java gemessene Tabellen). Abweichend von Java: Eine Kartenadresse, die das Muster, aber nicht `IP.ipCheck` besteht („.0.0.1“), wird nicht `null` (Javas Router-Panel wirft danach); eine abgelehnte Tabellenzelle wird nicht als `null` gespeichert; ein leeres Gateway ist nicht rot (Javas Router-Panel prüft es mit `musterIpAdresse`, übernimmt es aber) | | `src/settings.ts`, `src/sheet.ts`, `src/fields.ts` (DHCP-Server, Portweiterleitung) | Java `JDHCPKonfiguration`, `DHCPServer.determineGatewayip/determineDnsserverip/addStaticAssignment`, `JPortForwardingDialog`, `GatewayFirmware.validateData`, `EingabenUeberpruefung.musterMacAddress` | erweitert (F4.5c): Grenzen, Gateway und DNS des DHCP-Servers (wie Javas Dialog nie leer), „Manuelle Einstellungen“ und „DHCP aktivieren“, feste Zuordnungen (MAC und Adresse, eine MAC nur einmal, ohne Rücksicht auf Groß-/Kleinschreibung), die Zeilen der Portweiterleitung (TCP oder UDP, Ports nach `musterPort`, LAN-Adresse); das Blatt zeigt, was der Server ausgibt, wie Java es bestimmt (eigene Einstellung, sonst Gateway und DNS des Geräts oder 0.0.0.0; beim Heimrouter die LAN-Adresse) und welche Zeile Javas Firmware weiterleitet (`parsePortForwardingRow` des Kerns, jetzt exportiert). Abweichend von Java: Grenzen in `IP.ipCheck`-Form statt wie getippt („.0.0.1“ nimmt Java), MAC-Adressen groß und nur aus Hexziffern (Javas Klasse `[0-9a-fA-f]` lässt „_“ durch), eine zweite Zuordnung derselben MAC wird mit Meldung abgelehnt statt still verworfen, ungültige Portweiterleitungen werden nicht gespeichert (Java speichert jede, leitet aber nur gültige weiter) | | `src/settings.ts`, `src/sheet.ts`, `src/fields.ts` (Firewall) | Java `JFirewallDialog`, `GatewayFirewallConfigTable.closeEditor`, `Firewall.addRule/moveUp/moveDown/deleteRule`, `FirewallRule.validateExistingAttributes`, `EingabenUeberpruefung.isValidSubnetmask` | erweitert (F4.5d): Firewall an/aus, ICMP filtern, nur SYN verwerfen, Standardaktion, Regeln (neu wie Javas: leer, TCP, alle Ports, verwerfen; Zelle, Protokoll, Aktion, rauf/runter, löschen); Quelle leer, Adresse oder Javas Marke „999.999.999.999“, Ziel leer oder Adresse, Masken leer oder durchgehende Einsen, Port leer (alle) oder `musterPort`. Abweichend von Java: Javas Tabelle schreibt eine Zelle vor der Prüfung in die Regel, sodass die Firewall „abc“, Maske „255.0.255.0“ oder Port 0 hält, während die Tabelle den alten Wert zeigt — hier wird nichts übernommen, was die Prüfung ablehnt; ein Port, der keine Zahl ist, wird nicht still zu „alle Ports“; „.0.0.1“ und „080“ gelten nicht | | `src/settings.ts`, `src/sheet.ts`, `src/commands.ts` (Verbindungen) | Java `JConnectionsDialog` (`swapConnection`, `removeConnection`, Knöpfe „+“/„-“), `Vermittlungsrechner.hinzuAnschluss/removeNic`, `NetzwerkInterface()`, `InternetKnotenBetriebssystem.setStandardGateway` | erweitert (F4.5e): eine Karte nach der letzten anfügen (192.168.0.10/24, eigene MAC aus der Port-Kennung, bis acht), die letzte samt Kabel entfernen, die Kabel zweier Karten tauschen oder eines umstecken (dieselben Kabel, dieselben Geräte; zwei freie Karten: nichts), Javas Klicklogik (`connectionsClick`: markieren, abwählen, tauschen); das Blatt nennt die Adresse der Gegenstelle (Rechner, Router; Switch und Modem ohne). Abweichend von Java: Java entfernt auch die letzte Karte — ein Router ohne Karte behält kein Gateway (Java legt es in die Karten, gemessen), und keine Datei könnte es halten; hier bleibt eine Karte (`ROUTER_INTERFACES.fewest`) | | `src/view.ts` (`nodeLabel`) | Java `Knoten.holeAnzeigeName` | herausgelöst (F4.5b): die Beschriftung eines Geräts, auch für „Verbunden mit …“ | | `src/view.ts` (`desktopView`) | Java `GUIDesktopWindow.updateTitle`, `GUIDesktopPanel.updateAppPane` | neu (F4.6a): was der Desktop eines Rechners vom Dokument braucht — Art, Beschriftung, ob sie die Adresse ist (Javas Titel lässt die Adresse dann weg), installierte Programme | | `src/view.ts` (`captureCards`, `cardAddress`) | Java `GUIEvents.kontextMenueAktionsmodus` (je Karte „Datenaustausch anzeigen (Adresse)“), `AggregatedExchangePanel.updateTabTitle` | neu (F4.7): die Karten eines Geräts in der Reihenfolge seiner Ports mit Adresse und dem Titel ihres Reiters — die Adresse, wo die Beschriftung sie ist, sonst Beschriftung, „ - “ und Adresse; Switch und Modem haben keine. `cardAddress` zog aus `sheet.ts` hierher | | `src/documentation.ts`, `src/projectDoc.ts` (`italic`), `src/view.ts` (`italic`, Zeichenreihenfolge), `test/documentation.test.ts`, `test/documentation.java.json`, `test/fixtures/documentation.fls` | Java `JDocuElement`, `GUIDocumentationPanel`, `SzenarioVerwaltung.speichern/laden` (gemessen mit `DocuRun`; die Fixture hat Java gespeichert) | neu (F4.8a): Befehle der Dokumentation — neues Element mit Javas Voreinstellungen ans Ende der Liste (je Art zuunterst), Rahmen in ganzen Pixeln, Farbe, Schriftgröße und -stil (ein Stil ersetzt den vorigen; eine Fläche nimmt keine Schrift), Löschen, der `Y.Text` eines Textes; die Zeichensicht in Javas Stapelung. Gegen Java geprüft: neue Elemente, Farblisten, Schriftfolge, kleinste Größen, Stapel, eine von Java gespeicherte Datei gelesen, im Dokument gehalten und wieder geschrieben | | `src/software.ts`, `test/install.test.ts`, `test/fixtures/installed-programs.fls` | Java `GUIInstallationsDialog.aenderungenSpeichern` (gemessen mit `InstallRun`), `config/Desktop_*.txt` | neu (F4.6c): `setSoftware` — installieren (aus, Javas Voreinstellungen, fehlende Dateien; DNS-Einträge, E-Mail-Konten und das Konto des E-Mail-Programms aus vorhandenen Dateien) und entfernen (mit Einstellungen, Dateien bleiben) in einem Schritt, in der Reihenfolge von Javas Liste der Sprache (`SOFTWARE_ORDER`). Gegen Javas gespeicherte Installation geprüft; benannt: Javas Gnutella würfelt 3–5 Teilnehmer, hier 3 wie in einer Datei ohne Angabe | | `src/simulation.ts` | Plan §6.1 (`origin: 'sim'`); Java `SzenarioVerwaltung.speichern` nach einem Lauf (gemessen mit `SaveAfterRunRun`) | neu (F4.6f1): `writeRunState` schreibt, was ein Lauf von jedem Knoten hinterlässt, und nur, was sich unterscheidet — Dateien (neue hinter die anderen, geänderte an ihrem Platz, ein Text nur an der geänderten Stelle, verschwundene entfernt), ob Programme laufen, Einstellungen, die der Knoten hat (Feldreihenfolge egal); zweimal geschrieben ändert es nichts; `SIM_ORIGIN` landet in keinem Rückgängig-Stapel | | `src/files.ts`, `src/simulation.ts`, `test/files.test.ts` | Plan §7.3 (Texteditor auf `Y.Text`) | neu (F4.6f2): die Dateien eines Geräts im Dokument — als Dateisystem des Kerns gelesen (`nodeFiles`), über die Operationen des Kerns geändert und nur mit dem Geänderten zurückgeschrieben (`changeFiles`), der `Y.Text` einer Textdatei in jeder Schreibweise (`fileText`), und die Dateien des Dokuments in das Dateisystem einer laufenden Engine, nur was sich unterscheidet, nach ihrer Schreibweise, und nach einem Wechsel zwischen Datei und Ordner alles neu in der Reihenfolge des Dokuments (`readFilesInto`, duldsam wie `fileSystemOf`); `writeFiles` und `replaceText` aus `simulation.ts` hierher gezogen | | `src/files.ts` (Reihenfolge), `test/files.test.ts` | Java `GUIApplicationFileExplorerWindow` (Umbenennen an Ort und Stelle) | erweitert (F4.6f3): `writeFiles` nummeriert die Einträge nach der Reihenfolge des Dateisystems neu, wenn sie davon abweicht — ein umbenannter Eintrag ist im Dokument ein neuer Schlüssel und rückte sonst ans Ende | | `test/sheet.test.ts`, `test/sheet.cases.txt`, `test/sheet.java.json` | — | neu (F4.5a): 77 in Javas Felder getippte Texte, jede Regel dagegen samt der benannten Abweichungen; die Befehle, die Funkverbindungen, Rückgängig je Änderung, alles über eine gespeicherte `.fls` | | `test/devices.test.ts`, `test/fixtures/new-devices.fls` | — | neu (F4.4a): neue Geräte jeder Art gegen Javas gespeicherte (Zufall maskiert), Kabelregeln, ein selbst gebautes Netz pingt im Kern, Rückgängig nur der eigenen Änderungen über zwei Replikate | | `test/projectDoc.test.ts` | — | neu (F4.1): alle 23 Korpusdateien → Dokument → Yjs-Update → Projekt: dasselbe Projekt, derselbe Schnappschuss, dieselbe `.fls`, dieselbe Reihenfolge je Ordner; Kennungen absichtlich gegen die Dateireihenfolge | | `test/collaboration.test.ts`, `test/values.test.ts` | — | neu (F4.1): zwei Replikate — zwei Felder eines Geräts, zwei neue Zeilen, gemeinsames Tippen; der Hausmeister nach einem Zusammenführen (I1, I2 auf beiden Replikaten gleich, I4 auch in anderer Schreibweise), idempotent ohne Aktualisierung; `long` einer eigenen Anwendung, Binärdateien | | `src/blobs.ts`, `src/projectDoc.ts` (`fileEntry`, `bytesOf`), `src/files.ts` (`holds`), `src/commands.ts`, `test/blobs.test.ts` | Plan §5.1 | neu (F5.5): große Binärdateien der Rechner außerhalb des Dokuments — ab 16 KB trägt der Eintrag eines Bilds oder einer Binärdatei `blob` (SHA-256 der Bytes, hex; `@noble/hashes`, MIT) und `size` statt `data`; Text bleibt `Y.Text`, kleinere Binärdateien bleiben im Eintrag; wo die Bytes sind, sagt die Blob-Seite des Dokuments (`attachBlobs`), ohne sie bleibt alles im Dokument wie bisher; ein Blob ohne Bytes liest sich als leer, wird so aber nie zurückgeschrieben (sonst wäre die Datei weg); `missingBlobs`, `onBlobsArrive`, `memoryBlobSide` | ## packages/protocol | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/sim.ts`, `src/host.ts` | Plan §6.4 | neu (F4.2): die Nachrichten zwischen Editor und Simulationsraum in einer Liste (Client: sub, unsub, start, stop, speed, input; Raum: state, activity, trace, app, ack, error), Prüfung jedes Felds mit benanntem Fehler statt stillem Verwerfen; `SimHost` | | `test/sim.test.ts` | — | neu (F4.2): jede Art gelesen, jede Ablehnung mit ihrem Grund | | `src/sim.ts` (`node`) | Java `NetworkInfoPanel.updateInfo`, `GUIDesktopWindow.updateTitle` | erweitert (F4.6a): Thema `node:` und Nachricht `node` — die erste Karte eines Geräts, wie die Simulation sie fährt (DHCP ändert sie), für Titel und Netzwerk-Info des Desktops | | `src/terminal.ts` | Java `GUIApplicationTerminalWindow` (gemessen mit `TerminalWindowRun`) | neu (F4.6b): die Zeilen eines Befehlszeilen-Fensters (Text, Eingabe nach ihrem Prompt, cls, Beschäftigt, Prompt, exit) und wie ein Client sie liest — Text ab dem letzten cls, Prompt, ob er sichtbar ist (verborgen, solange ein Befehl läuft), Verlauf; Javas Pfeiltasten (`commandHistoryPointer`) | | `src/web.ts`, `src/sim.ts` (`view`, `start.language`) | Java `GUIApplicationWebBrowserWindow`, `GUIApplicationWebServerWindow` (gemessen mit `BrowserWindowRun`) | neu (F4.6d): der Bildschirmstand eines Programmfensters (`view`, ganz, wenn er sich ändert) — der des Browsers (Adresszeile, Adresse des letzten Abrufs, Seite: Start, nicht erreichbar, Fehler mit Status, HTML mit den gekommenen Bildern, Text, Bild) und der des Webservers (Knopf, Kästchen, Tabelle); `browserTitle` wie Javas Fenster (Programmname, dann die Adresse, dann der Titel der Seite), `htmlTitle`; der Start nennt die Sprache, in der FILIUS für die startende Person läuft | | `src/mail.ts` | Java `GUIApplicationEmailAnwendungWindow` (`posteingangAktualisieren`, `gesendeteAktualisieren`, `replyLayout`), `GUIApplicationEmailServerWindow` (gemessen mit `MailWindowRun`) | neu (F4.6e): die Bildschirmstände von E-Mail-Programm (Konto, Posteingang, Gesendete) und E-Mail-Server (Knopf, Domain, Konten mit Zahl der Mails); die Zeilen der Ordner und die Antwort (an den Absender, „RE:“, zitierter Text) wie Javas Fenster | | `src/echo.ts` | Java `GUIApplicationServerBausteinWindow`, `GUIApplicationClientBausteinWindow` (gemessen mit `EchoWindowRun`) | neu (F4.6g1): die Bildschirmstände von Echo-Server (läuft, Port) und Einfachem Client (verbunden, Adresse, Port); `portOfText`: ein Port, wie ein Socket ihn haben kann (Javas `Integer.parseInt` nimmt jede Zahl und wirft bei anderem Text) | | `src/dns.ts`, `src/sim.ts` (`dnsServer`) | Java `GUIApplicationDNSServerWindow` (gemessen mit `DnsWindowRun`) | neu (F4.6g2): der Bildschirmstand des DNS-Servers — Knopf, Kästchen, die Zeilen der drei Tabellen, wie `/dns/hosts` sie hält | | `src/firewall.ts`, `src/sim.ts` (`firewall`) | Java `GUIApplicationFirewallWindow` (gemessen mit `FirewallWindowRun`) | neu (F4.6g3): der Bildschirmstand der Firewall eines Rechners — die drei Kästchen und die Regeln, wie die Tabelle sie zeigt (mit dem ganzen Text einer Regel, die das Fenster nicht machen kann); das Protokoll kommt als Zeilen des Fensters | | `src/gnutella.ts` | Java `GUIApplicationPeerToPeerAnwendungWindow` (gemessen mit `GnutellaWindowRun`) | neu (F4.6g4): der Bildschirmstand von Gnutella — die bekannten Teilnehmer, die Ergebnisse wie die Tabelle sie zeigt, die Dateien von `/peer2peer`, die Zahl der Teilnehmer | | `src/viewers.ts`, `src/sim.ts` (`sat`, `nat`, `drop`, `dropped`, `clock`) | Java `SatViewer`, `NatViewer`, `SimulationControl` (gemessen mit `ViewersRun`) | neu (F4.6g5): die Tabellen eines Switches und eines Heimrouters als Bildschirmstände; die Nachricht `drop` (Javas „Pakete verwerfen“ gedrückt oder losgelassen), das Thema `dropped` mit den verworfenen Frames; der Zustand trägt `clock`, die Uhrzeit, für die die Zeit 0 der Simulation steht | | `src/sim.ts` (`clearCapture`) | Java `AggregatedMessageTable` („Tabellen löschen“, `Lauscher.reset`) | neu (F4.7): die Nachricht `clearCapture` | | `src/sim.ts` (`startedBy`, `readOnly`, `frozen`, `WRITING_KINDS`), `src/sync.ts` (Schließcodes von `/sim`) | Plan §6.2, §6.4 | erweitert (F5.3a): der Zustand nennt, wer startete; was einen Raum ändert (Start, Stopp, Geschwindigkeit, Verwerfen, Tabellen löschen, Eingaben), nur mit Schreibstufe; ein eingefrorenes Projekt startet nicht; `/sim` sagt Absage und Trennung als Schließen des WebSockets (4403 mit dem Absagegrund, 4410 mit dem Trennungsgrund, 4500 wenn der Faden des Raums scheiterte) | | `src/sync.ts` | Plan §8.5 | neu (F5.2): was F einem Editor über seinen Platz im gemeinsamen Dokument sagt — warum eine Verbindung abgewiesen wird (`notAProject`, `notSignedIn`, `noAccess`, `unknownProject`), warum F sie schließt (`revoked`, `deleted`), und die Nachricht `access`, wenn sich der Zugang einer bleibenden Verbindung ändert (eingefroren, aufgetaut) | | `src/sim.ts` (`restart`, `WRITING_KINDS`), `test/sim.test.ts` | — | neu (10.10.2026, auf Wunsch des Nutzers): die Nachricht `restart` (mit Sprache wie `start`, schreibend) — die Simulation neu starten, alles geleert. Abweichend von Java: dort nur Stoppen und Starten, Datenaustausch und Fenster überdauern das | ## packages/sim | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/room.ts` | Plan §6.1–6.4; Javas Geschwindigkeit `Verbindung.verzoegerungsFaktor` | neu (F4.2): der Simulationsraum — eine Engine je Projekt, Schnappschuss des Dokuments beim Start, Uhr im Takt der Wanduhr (Geschwindigkeit = Kabelverzögerung wie Java, Nachholen höchstens 2 s), Mitschnitt und Uhr über Stopp und Start, Abonnements (Kabelaktivität bei Änderung, neue Rahmen je Karte in beiden Ansichten, neue Fensterzeilen je Programm), Befehlszeile als erste Aktion; ein Fehler des Kerns wird allen gemeldet (`engineFailed`) statt den Raum zu beenden | | `src/channel.ts`, `src/serveRoom.ts`, `src/localSimHost.ts`, `src/worker.ts` | Plan §6.1 | neu (F4.2): der Raum in einem Web Worker der Seite — Dokument-Updates in beide Richtungen ohne Echo, Nachrichten geprüft | | `test/room.test.ts`, `test/localSimHost.test.ts` | — | neu (F4.2): der Raum gegen die von Hand gesteuerte Engine (dieselben Rahmen, dieselben Zeilen), Abonnieren, Geschwindigkeit, Nachholen, Fehler; Host und Worker-Seite über einen `MessageChannel` | | `src/room.ts` (`node`) | Plan §6.4 | erweitert (F4.6a): der Raum schickt einem Abonnenten die Netzwerkwerte eines Geräts beim Abonnieren und wenn sie sich ändern, nichts vor dem ersten Start | | `src/room.ts` (Takt) | — | behoben (F4.6b): der Raum gibt der Engine ganze Millisekunden und trägt den Bruchteil der Wanduhr in den nächsten Takt; nach einem Sprung holt er höchstens zwei Sekunden nach, auch über die folgenden Takte nicht mehr | | `src/terminalWindow.ts`, `src/room.ts` (Befehlszeile), `test/terminalWindow.test.ts`, `test/terminalWindow.java.json` | Java `GUIApplicationTerminalWindow`, `Terminal.setSystemSoftware` | neu (F4.6b): das Fenster der Befehlszeile im Raum, eines je Rechner für alle — Startbildschirm, jede Eingabe nach ihrem Prompt, leere Zeile, cls, exit, danach die Zeilen des Programms in ihrer Reihenfolge; es überdauert Stopp und Start mit Text, Verlauf und Arbeitsverzeichnis wie Javas. Gegen Javas Fenster Taste für Taste geprüft; benannt: was ein Lauf in den Dateien anlegt, steht nach dem Neustart noch nicht im Dokument (F4.6f), ein dort angelegter Ordner fehlt dann | | `src/room.ts` (Installation) | Java `GUIInstallationsDialog` (Programme starten sofort) | erweitert (F4.6c): im laufenden Betrieb beobachtet der Raum die installierten Programme des Dokuments und installiert oder entfernt sie in der Engine; eine neue Befehlszeile bekommt ihr Fenster | | `src/browserWindow.ts`, `src/room.ts` (Browser, Webserver), `test/browserWindow.test.ts`, `test/browserWindow.java.json` | Java `GUIApplicationWebBrowserWindow`, `GUIApplicationWebServerWindow` (gemessen mit `BrowserWindowRun`) | neu (F4.6d): das Browserfenster im Raum, eines je Rechner für alle, über Stopps behalten — Adresse öffnen (keine Adresse: die Zeile zurück auf „http://“), Links und Formulare der gezeigten Seite folgen, was das Programm bekam, in den Bildschirmstand; der Raum schickt Bildschirmstände (Browser statt Zeilen, Webserver zu seinen Zeilen), nimmt die Aktionen `open`/`follow` und `setActive`/`useVirtualHosts`/`setVirtualHost` an und startet in der Sprache der Person. Gegen Javas Fenster geprüft; benannt: Javas Fehlerseite findet ihre Vorlage nie, Bilder und Links einer Seite im Ordner, eine Marke lädt in Java die Startseite, die Datei der virtuellen Hosts | | `src/room.ts` (E-Mail), `test/mailWindow.test.ts`, `test/mailWindow.java.json` | Java `GUIApplicationEmailAnwendungWindow`, `GUIApplicationEmailServerWindow` (gemessen mit `MailWindowRun`) | erweitert (F4.6e): der Raum schickt die Bildschirmstände von E-Mail-Programm und -Server zu ihren Zeilen und nimmt `setAccount`/`send`/`fetch`/`removeMail` und `setActive`/`setDomain` (nur bei angehaltenem Server)/`addAccount`/`removeAccount` an. Gegen Javas Fenster geprüft; benannt: ein vorhandener Benutzername, Löschen im falschen Ordner, die Domain in der Kontendatei | | `src/room.ts` (Rückweg), `test/writeBack.test.ts`, `test/fixtures/after-run-*.fls`, `test/terminalWindow.test.ts` | Java `GUIMainMenu.stopSimulation`, `SzenarioVerwaltung.speichern` (gemessen mit `SaveAfterRunRun`) | erweitert (F4.6f1): der Raum schreibt, was ein Lauf hinterlässt (Dateien, laufende Server, virtuelle Hosts, Domain und Konten der E-Mail-Server, Konto und Ordner der E-Mail-Programme, Firewalls, die Adresse eines DHCP-Clients), als `origin: 'sim'` ins Dokument: höchstens einmal je Sekunde (ab dem Start gezählt), nach jeder Aktion in einem Fenster und beim Stopp. Gegen Javas nach dem Lauf gespeichertes Projekt geprüft; die Befehlszeile geht nach einem Neustart im vorher angelegten Ordner weiter wie Javas (die benannte Abweichung aus F4.6b ist weg) | | `src/room.ts` (Dateien in beide Richtungen), `test/writeBack.test.ts` | Plan §7.3 | erweitert (F4.6f2): was eine Person ins Dokument schreibt (der Texteditor), geht im Lauf sofort in die Dateien der Engine; was die Engine an ihren Dateien ändert, geht im Takt der Änderung ins Dokument (nicht erst nach einer Sekunde), damit das Dokument jede Änderung der Engine hat, bevor die nächste einer Person kommt — so behält ein Text, den beide zugleich ändern, beides. Ein Rechner, dessen Programme keine Dateien benutzen, liest seine beim nächsten Start | | `src/room.ts` (Echo), `test/echoWindow.test.ts`, `test/echoWindow.java.json`, `test/fixtures/after-run-echo.fls`, `test/room.test.ts` | Java `GUIApplicationServerBausteinWindow`, `GUIApplicationClientBausteinWindow` (gemessen mit `EchoWindowRun`), `SaveAfterRunRun echo` | erweitert (F4.6g1): der Raum nimmt `setActive` mit Port beim Echo-Server und `connect`/`disconnect`/`send` beim Einfachen Client an, schickt ihre Bildschirmstände und schreibt nach dem Lauf Port und Ziel zurück, wie Javas Projekt sie behält. Gegen Javas Fenster und Javas gespeichertes Projekt geprüft; benannt: drei SYN statt einem (F2.3c) — ein Verbindungsversuch dauert länger | | `src/room.ts` (DNS-Server), `test/dnsWindow.test.ts` | Java `GUIApplicationDNSServerWindow`, `DNSConfigTable` | erweitert (F4.6g2): der Raum nimmt `setActive`, `setRecursive`, `addRecord`, `removeRecord`, `changeRecord` an, schickt den Bildschirmstand (ohne Zeilen; Javas Fenster hat keine) und schreibt nach dem Lauf zurück, ob der Server läuft, die rekursive Auflösung und die Einträge der Datei in seine Einstellungen | | `src/room.ts` (Firewall), `test/firewallWindow.test.ts` | Java `GUIApplicationFirewallWindow` | erweitert (F4.6g3): der Raum nimmt `setActive`, `setIcmpAllowed`, `setFilterUdp`, `addRule`, `removeRule` an, schickt den Bildschirmstand und das Protokoll der Firewall als Zeilen (über Stopps behalten, wie die Engine es hält); zurück ins Projekt geht die Firewall wie schon bei Routern | | `src/room.ts` (Gnutella), `test/gnutellaWindow.test.ts`, `test/room.test.ts` | Java `GUIApplicationPeerToPeerAnwendungWindow` | erweitert (F4.6g4): der Raum nimmt `join`, `leave`, `search`, `cancelSearch`, `clearResults`, `download`, `setMaximumPeers` an, schickt den Bildschirmstand (ohne Zeilen; Javas Fenster hat keine) und schreibt nach dem Lauf die Zahl der Teilnehmer zurück; eine heruntergeladene Datei steht sofort im Dokument. Der alte Raumtest nahm Gnutella als Programm ohne Aktionen und prüft dort jetzt ein nicht installiertes Programm | | `src/room.ts` (Anzeigen, „Pakete verwerfen“), `test/viewers.test.ts`, `test/room.test.ts` | Java `SatViewer`, `NatViewer`, `SimulationControl`, `Verbindung.setDrop` | erweitert (F4.6g5): der Raum schickt die Tabellen eines Switches und eines Heimrouters (ohne Zeilen) und nimmt ihr `reset`; jedes Kabel verwirft, solange irgendein Client „Pakete verwerfen“ hält (ein Client, der geht oder beim Stopp noch hält, zählt nicht mehr); die verworfenen Frames gehen an, wer sie beobachtet, mit jedem Start neu begonnen wie Javas Liste | | `src/room.ts` („Tabellen löschen“), `test/exchangeWindow.test.ts` | Java `Lauscher.reset`, `GUIContainer.closeDialogs/reopenDialogs` | erweitert (F4.7): `clearCapture` leert im Lauf die Listen aller Karten und die verworfenen Frames, jeder Beobachter bekommt sie neu (ab 1 nummeriert), das Kabel leuchtet schon mit dem ersten neuen Frame; im Entwurf `notRunning`. Der Mitschnitt bleibt über Stopp und Start, wie Javas | | `browser/m9.spec.ts`, `browser/traceDigest.ts`, `browser/*Entry.ts`, `/playwright.config.ts` | Plan §13 M9 | neu (F4.2): M9 in Chromium — 17 Beispiele, je 30 s mit Eingaben, ergeben Zeichen für Zeichen denselben Mitschnitt wie in Node; der Raum in einem echten Worker | | `src/room.ts` („gestartet von“), `test/room.test.ts` | Plan §6.2 | erweitert (F5.3a): ein Client trägt auf F einen Namen; wer die laufende Simulation gestartet hat, steht im Zustand (`startedBy`), bis sie hält oder der Kern scheitert; ein Raum der eigenen Seite nennt niemanden | | `src/room.ts` (`blobsArrived`) | — | erweitert (F5.5): kamen Bytes nach, liest die laufende Simulation die Dateien neu | | `src/room.ts` (`restart`), `test/room.test.ts` | — | neu (10.10.2026, auf Wunsch des Nutzers): der Raum startet neu — gestoppt wie bei `stop` (was die Geräte schrieben, bleibt im Dokument), dann Mitschnitt aller Karten, verworfene Rahmen, Befehlszeilen- und Browserfenster geleert, jedem Beobachter seine Fenster und Listen von vorn geschickt, gestartet wie bei `start`, benannt nach der Person, die neu startete. Aus dem Entwurf heraus: nur gestartet, ebenso geleert (anders als ein Start, der den letzten Lauf behält) | ## packages/editor | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/assets/hardware/*.png` | Java-Filius `src/main/resources/gfx/hardware/` (GPL) | unverändert kopiert: Javas Standardsymbole (`IconMode.DEFAULT`), damit Arbeitsblätter passen; seit F4.5e auch `rj45.png` für die Knöpfe der Verbindungen | | `src/canvas/viewport.ts` | Dashboard `frontend/src/apps/kanban/zoom.js` (Rechte bei uns, Plan §7.1) | kopiert und umgebaut (F4.3): Grenzen, Stufen, Einpassen, Fingerrechnung; statt Rollposition ein Ausschnitt aus Maßstab und Versatz | | `src/canvas/layout.ts` | Java `JSidebarButton.getWidth/getHeight`, `JCablePanel.updateBounds/paintComponent`, `IconMode`, `Host.holeAnzeigeName` | neu nach Java (F4.3): Knopfgröße, Symbol oben mittig, Kabel als Javas quadratische Kurve zwischen den Knopfmitten (ganzzahlig wie Java); Beschriftungsschrift nach den Maßen der Dateien ab Java 2.5 | | `src/canvas/Canvas.tsx`, `src/canvas/ZoomBar.tsx`, `src/canvas/icons.ts`, `src/Editor.tsx`, `src/main.tsx` | Plan §7.1, §7.2 | neu (F4.3): die Fläche (SVG) mit Geräten, Kabeln (Funk gestrichelt), Doku-Elementen; Verschieben (Zeiger erst bei Bewegung gefangen), Strg+Rad und Trackpad-Pinch, zwei Finger, Zoomleiste mit 44-px-Zielen; Entwicklungsseite mit Beispielen | | `src/i18n/*` | Java `MessagesBundle_de_DE`, `_en_GB` | neu (F4.3): Kataloge de/en mit englischen Schlüsseln, Javas Wörter für Geräte (M11) | | `src/theme/tokens.css` | Dashboard `frontend/src/index.css` (semantische Token) | neu (F4.3): dieselben Namen und Werte, hell und dunkel; dazu die Farben der Fläche nach Java (`JCablePanel`) | | `src/bridge/dashboardBridge.ts` | Dashboard `frontend/src/apps/scratch/lib/bridge.js` (Muster) | neu (F4.3): Version, Namen, Herkunftsprüfung; `setLocale`, `setTheme`, `ready` | | `test/*.test.ts`, `browser/canvas.spec.ts` | — | neu (F4.3): Rechnung von Ausschnitt und Java-Anordnung, Kataloge gegen Javas Bündel, Brücke; im Browser jedes Beispiel gegen die in der Datei gespeicherten Knopfmaße (ab Java 2.5), Gesten mit Maus, Rad und zwei Fingern (CDP), Sprache und Dunkel | | `src/design/Palette.tsx`, `src/assets/hardware/kabel.png` | Java `GUIDesignSidebar` (Reihenfolge, Kabel zuerst), Javas Symbol `kabel.png` | neu (F4.4b): die Palette — Gerät aufs Feld ziehen (Symbol mittig am Ablegepunkt, wie Javas Vorschau) oder antippen (Mitte der Ansicht), das Kabel als Werkzeug | | `src/design/ContextMenu.tsx`, `src/design/RouterDialog.tsx` | Java `GUIEvents.kontextMenueEntwurfsmodus` (`guievents_msg5`–`7`), `GUIContainer.neuerKnoten` (`guicontainer_msg1`/`2`) | neu (F4.4b): Menü eines Geräts oder Kabels (Langdruck oder Dreipunkt-Knopf), Wahl der Schnittstellenzahl eines neuen Vermittlungsrechners (2 bis 8, ohne Wahl 2); Javas Tippfehler „Vermittlungsrechnerns“ ausgebessert | | `src/Editor.tsx`, `src/canvas/Canvas.tsx` (Werkzeuge) | Java `GUIEvents` (Kabel ziehen, Heimrouter-Hälften, Meldungen `guievents_msg1/12/22–26`) | neu (F4.4b): Auswählen, Gerät ziehen, Langdruck, Kabel ziehen oder zweimal antippen mit Gummiband und WAN/LAN-Hinweis, Javas Meldungen, Entf-Taste, Rückgängig/Wiederholen per Knopf und Strg+Z/Strg+Y; jede Änderung mit dem eigenen Ursprung des Editors | | `browser/design.spec.ts`, `browser/editorPage.ts` | — | neu (F4.4b): die Werkzeuge in Chromium mit Maus und Berührung (CDP) | | `src/sheet/DeviceSheet.tsx`, `src/sheet/SheetField.tsx`, `src/sheet/sheet.css` | Java `JKonfiguration` und die Panels je Art (Reihenfolge und Wörter `jhostkonfiguration_msg1`–`16`, `jswitchkonfiguration_msg1`–`5`, `jmodemkonfiguration_msg4`) | neu (F4.5a): das Geräte-Blatt — öffnet mit dem gewählten Gerät wie Javas Panel, neben der Fläche (340 px) oder auf dem Handy darunter; ein Feld wird beim Verlassen oder mit Enter übernommen, abgelehnter Text bleibt rot stehen mit dem, was weiter gilt (Java setzt still den alten Wert zurück), Escape verwirft ihn; Adressfelder bei DHCP gesperrt; jede Änderung ein Schritt im Rückgängig. Vermittlungsrechner und Heimrouter vorerst nur mit Namen | | `browser/sheet.spec.ts` | — | neu (F4.5a): das Blatt in Chromium — Felder wie Java, Markieren und Behalten, Gerätewechsel, Rückgängig, WLAN, Handy mit Berührung, Englisch; seit F4.5b Router-Reiter, aktives Kabel, Weiterleitungstabelle, RIP, Heimrouter; seit F4.5c DHCP-Server und Portfreigaben; seit F4.5d Firewall; seit F4.5e Verbindungen (Tauschen, Umstecken, Karten bis acht und bis eine, Markierung nach Rückgängig) | | `src/sheet/FirewallPanel.tsx` | Java `JFirewallDialog` (`jfirewalldialog_msg21`–`43`, `jvermittlungsrechnerkonfiguration_msg4`) | neu (F4.5d): die Firewall als Seite des Blatts (bei Vermittlungsrechner und Heimrouter unter „Allgemein“): Reiter Allgemein mit den drei Schaltern und Javas Erklärungen, Reiter Firewall-Regeln mit Javas Einleitung, Standardaktion, Regeltabelle, rauf/runter (an den Enden gesperrt), Neue Regel, Regel löschen (die Nachfolgerin bleibt gewählt, wie bei Java). Javas erster Reiter heißt „Netzwerkschnittstellen“, enthält aber die allgemeinen Schalter — hier „Allgemein“; Javas „Aktion?“ ohne Fragezeichen, „über die Standard-Aktion“ groß | | `src/sheet/ConnectionsPanel.tsx`, `src/sheet/SheetField.tsx` (`SheetNote`), `src/theme/tokens.css` (`--connection-*`) | Java `JConnectionsDialog` (`jvermittlungsrechnerkonfiguration_msg19`, `22`–`25`) | neu (F4.5e): „Verbindungen verwalten“ als Seite des Vermittlungsrechners (unter „Allgemein“ nach „Firewall einrichten“, wie bei Java): je Karte Javas RJ45-Knopf links von „NIC n: Adresse“ in Javas Farben (grün belegt, rot frei, gelb markiert), darunter die Gegenstelle wie bei Java („A (10.0.0.2)“, ein Switch nur mit Namen); antippen markiert, dieselbe abwählen, eine andere tauscht; „+“ und „−“ mit Javas „Schnittstelle hinzufügen“ und „Maximal 8 Schnittstellen erlaubt!“; Javas Hinweis darunter wie im Dialog. Java zeichnet die Kabel zwischen zwei Spalten — im schmalen Blatt steht die Gegenstelle unter der Karte; der Reiter einer entfernten Karte fällt auf „Allgemein“ zurück | | `src/simulation/useSimulation.ts`, `src/simulation/ModeBar.tsx`, `src/assets/modes/*.png` | Java `GUIMainMenu.selectMode/updateLatency` (`guimainmemu_msg3`/`4`/`15`/`16`), Javas Modussymbole (`gfx/allgemein`) | neu (F4.6a): der Raum im Worker der Seite (`LocalSimHost` über `?worker`), Javas Moduswahl mit Javas Symbolen, im Aktionsmodus der Geschwindigkeitsregler mit Prozent (90 % zu Beginn wie Java); Javas Tasten Strg+D/Strg+R nicht, sie legen im Browser ein Lesezeichen an und laden neu | | `src/desktop/DesktopWindow.tsx`, `src/desktop/programs.ts`, `src/desktop/desktop.css`, `src/assets/desktop/*.png` | Java `GUIDesktopWindow`, `GUIDesktopPanel`, `GUIDesktopIcon`, `NetworkInfoPanel`, `config/Desktop_de_DE.txt`/`_en_GB.txt` (`desktoppanel_*`, `network_msg*`) | neu (F4.6a): der Desktop eines Rechners — Titel „Name - Adresse“ (nur die Beschriftung, wo sie die Adresse ist), Javas Hintergrund, Software-Installation zuerst, dann die Programme in der Reihenfolge der Java-Liste der Sprache, graue Taskleiste mit „Startbildschirm“ und dem Netzwerksymbol (leuchtet, solange das Kabel trägt), Netzwerk-Info mit den laufenden Werten; auf breiten Schirmen verschiebbar über der Fläche, mehrere gestapelt, auf dem Handy flächig unter den Modusknöpfen. Javas Taskleiste hat 30 px, hier 44 für Finger; Javas Knopf „Ändern“ unter schreibgeschützten Feldern fehlt. Die Programmfenster folgen ab F4.6b | | `src/desktop/TerminalPanel.tsx`, `src/desktop/ProgramFrame.tsx` | Java `GUIApplicationTerminalWindow`, `GUIApplicationWindow` | neu (F4.6b): ein Programmfenster über dem Desktop mit Javas dunkelgrauer Titelleiste (kein Schließknopf, „Startbildschirm“ führt zurück; das offene Programm überdauert den Entwurf wie bei Java) und die Befehlszeile — grau auf schwarz, Prompt vor der Eingabe (verborgen, solange ein Befehl läuft), Enter, Pfeiltasten, Strg+C (mit markiertem Text kopiert es); für Finger Befehle als Chips, Pfeile und Strg+C als Knöpfe; `exit` schließt das Fenster für alle, die es offen haben | | `src/desktop/InstallationPanel.tsx`, `src/assets/desktop/pfeil_*.png` | Java `GUIInstallationsDialog` (`installationsdialog_msg1`–`4`), Javas Pfeile | neu (F4.6c): die Software-Installation auf dem Desktop — „Installiert:“ und „Verfügbar:“ in der Reihenfolge von Javas Liste, Pfeile oder Doppelklick verschieben, ein Tippen wählt (ein zweites lässt los), „Änderungen annehmen“ wendet an und führt zurück; Javas Liste der installierten Programme kommt in der Reihenfolge einer HashMap, hier in der der Liste | | `src/desktop/BrowserPanel.tsx`, `src/desktop/browserPage.ts`, `src/assets/desktop/browser_waterwolf_logo.png` | Java `GUIApplicationWebBrowserWindow` (`webbrowser_msg2`, `sw_webbrowser_msg1`, `tmpl/http_fehler_*`), Javas Logo (`gfx/desktop`) | neu (F4.6d): der Webbrowser — Adresszeile mit „Start“, Javas Startseite mit Logo, die Seite in einem Rahmen mit Sandbox und Richtlinie (kein Skript, nichts lädt außer den gekommenen Bildern als Daten, kein Formular geht ab), Links und Formulare gehen an den Raum (ein Formular wie Javas Fenster: seine Felder in Reihenfolge samt Knopf), eine Marke springt in der Seite; der Titel des Fensters aus der Seite mit aufgelösten Entities (Java zeigt „&“), die Fehlerseite aus Javas Vorlage (Java findet sie nie und zeigt „Fehler“), Text als Text und ein Bild als Bild (Java zeigt beides als HTML) | | `src/desktop/WebServerPanel.tsx`, `src/desktop/serverLines.ts` | Java `GUIApplicationWebServerWindow` (`webserver_msg1`–`6`), `ServerAnwendung`/`ServerMitarbeiter`/`TCPSocket` (`sw_serveranwendung_msg1`–`6`, `sw_servermitarbeiter_msg1`/`2`, `sw_tcpsocket_msg6`–`8`) | neu (F4.6d): der Webserver — „Starten“/„Anhalten“, „Verwende virtuelle Hosts“ mit der Tabelle (eine Zelle wird beim Verlassen oder mit Enter geschrieben, Escape nimmt sie zurück), darunter die Zeilen des Servers in Javas Worten | | `src/desktop/EmailClientPanel.tsx`, `src/desktop/EmailServerPanel.tsx`, `src/desktop/mailLines.ts`, `src/assets/desktop/email_*.png` | Java `GUIApplicationEmailAnwendungWindow` (`emailanwendung_msg1`–`47`), `GUIApplicationEmailServerWindow` (`emailserver_msg1`–`29`), `SMTPMitarbeiter`/`SMTPClient` (`sw_smtpmitarbeiter_msg12`–`14`, `sw_smtpclient_msg1`–`4`), Javas Symbole (`gfx/desktop`, `img/email_icon.png`) | neu (F4.6e): das E-Mail-Programm — Abrufen, Verfassen, Antworten, Löschen, Konto einrichten, Posteingang und Gesendete, darunter die gewählte Mail (sonst Javas Willkommen), Verfassen und Konto als Fenster über dem Programm, Javas Dialoge als Hinweis mit OK, ein Fehler des Programms wie Javas Dialog; die gewählte Mail gehört zu ihrem Ordner (Java löschte die zuvor im anderen Ordner gewählte). Der E-Mail-Server — Starten/Anhalten, Maildomain (nur angehalten, rot, wo Javas Muster sie nicht nimmt), Neues Konto mit Namensfeld (Java hat das Etikett ohne Feld; ohne Namen Javas Platzhalter), Konten-Liste mit Javas Frage vor dem Entfernen, Log Fenster in Javas Worten | | `src/desktop/textEditor.ts`, `src/desktop/TextEditorPanel.tsx`, `src/desktop/FileDialog.tsx`, `src/desktop/textBinding.ts`, `src/assets/desktop/datei.png`, `src/assets/desktop/ordner.png` | Java `GUIApplicationTextEditorWindow` (`texteditor_msg3`–`6`), `DMTNFileChooser` (`dmtnfilechooser_msg1`–`11`), `OrdnerInhaltListRenderer` (Javas Symbole aus `gfx/desktop`), gemessen mit `TextEditorWindowRun` | neu (F4.6f2): der Texteditor — „Neu“, „Öffnen“, „Speichern“, „Speichern unter“ über Javas Dateidialog, der Titel mit dem Namen der offenen Datei, Javas Courier; der Text der offenen Datei ist ihr `Y.Text` im Dokument (Plan §7.3): Getipptes steht sofort in der Datei, für alle, die sie offen haben, und für die laufende Simulation (Java hält eine Kopie bis „Speichern“). Strg+Z/Strg+Y nehmen das eigene Getippte zurück. Besser als Java: „Speichern unter“ auf eine vorhandene Datei schreibt sie und bleibt in ihr (Java bleibt in einer Kopie, die kein Ordner hält, jedes spätere „Speichern“ ging verloren); eine gelöschte offene Datei lässt ihren Text als neuen Text, „Speichern“ fragt nach einem Namen (Javas ging verloren); was der Dialog nicht findet oder kein Text ist, sagt er, die offene Datei bleibt; der Dialog zeigt den Pfad des Ordners (Java nur den Namen, die Wurzel als „root“), ein Tippen öffnet einen Ordner oder nimmt einen Dateinamen (Java will einen Doppelklick) | | `src/desktop/fileExplorer.ts`, `src/desktop/windowState.ts`, `src/desktop/FileExplorerPanel.tsx`, `src/desktop/ImageViewerPanel.tsx` | Java `GUIApplicationFileExplorerWindow` (`fileexplorer_msg2`–`19`, `sw_fileexplorer_msg1`–`3`, `sw_fileimporter_msg3`), `GUIApplicationImageViewerWindow` (`imageviewer_msg2`), gemessen mit `FileExplorerWindowRun` | neu (F4.6f3): der Datei-Explorer — Baum aus Ordnern und Dateien, die Einträge des gewählten Ordners mit Javas Symbolen, Javas Menü per Rechtsklick (auf einem Eintrag Löschen, Ausschneiden, Kopieren, Umbenennen; auf der freien Fläche Neuer Ordner, Einfügen), Javas Fragen und das Importfenster; Kopiertes bleibt zum nächsten Einfügen, Ausgeschnittenes nicht. Der Bildbetrachter — „Öffnen“ über Javas Dateidialog, das Bild, sein Name als Titel. Die Dateien sind die des Dokuments, geändert über die Operationen des Kerns. Besser als Java: Baum und Liste folgen den Dateien sofort („Aktualisieren“ entfällt); die Aktionen des Menüs sind auch Knöpfe, ein Finger braucht keinen Rechtsklick; ein Ordner der Liste öffnet mit Doppelklick; eine im Baum gewählte Datei wird in ihrem Ordner gewählt (Java hält sie für einen Ordner, ein neuer Ordner landete unter ihr); was eine Aktion ablehnt, wird gesagt; der neue Name beginnt mit dem alten; der Bildbetrachter zeigt ein Bild statt alle übereinander und sagt, was kein Bild ist. `windowState.ts`: was die Fenster der lokalen Programme teilen (auch der Texteditor) | | `src/desktop/EchoPanels.tsx`, `src/desktop/serverLines.ts` (`simpleClientLine`) | Java `GUIApplicationServerBausteinWindow` (`serverbaustein_msg1`–`3`), `GUIApplicationClientBausteinWindow` (`clientbaustein_msg1`–`6`), `ClientBaustein` (`sw_clientbaustein_msg2`–`6`), `Socket`/`TCPSocket` (`sw_socket_msg1`, `sw_tcpsocket_msg2`, `3`, `9`) | neu (F4.6g1): Echo-Server — Starten/Anhalten mit Port (nur angehalten beschreibbar) und seine Zeilen; Einfacher Client — Server-Adresse und -Port (verbunden gesperrt, nach einer Änderung des Programms wieder dessen Werte), Verbinden/Trennen, Nachricht und Senden (nur verbunden, danach leer), seine Zeilen in Javas Worten. Besser als Java: ein Port, der keiner ist, wird rot markiert und nicht übergeben (Javas Knopf wirft und tut nichts) | | `src/desktop/DnsServerPanel.tsx`, `src/desktop/WebServerPanel.tsx` (Zelle) | Java `GUIApplicationDNSServerWindow` (`dnsserver_msg1`–`23`), gemessen mit `DnsWindowRun` | neu (F4.6g2): der DNS-Server — Starten/Beenden, das Kästchen der rekursiven Auflösung, drei Reiter mit je zwei Feldern (das Adressfeld beginnt mit der eigenen Adresse), rot, solange die Prüfung sie nicht nimmt, „Hinzufügen“ (sonst Javas gültiges Beispiel), „Auswahl entfernen“ und die Tabelle, deren Zellen beim Verlassen geschrieben werden. Besser als Java: eine Zelle, die die Prüfung nicht nimmt, wird markiert, bevor sie zurückgeht. **Behoben, auch im Webserver (F4.6d):** eine Zelle übernahm den neuen Wert des Raums, der kurz nach einem Enter kommt, auch über das inzwischen Getippte; jetzt nur, solange seit Enter, Escape oder Verlassen nichts getippt ist | | `src/desktop/PersonalFirewallPanel.tsx`, `src/desktop/serverLines.ts` (`firewallLine`), `src/desktop/DesktopWindow.tsx` | Java `GUIApplicationFirewallWindow` (`firewall_msg1`–`14`), `Firewall`/`FirewallThread` (`sw_firewall_msg5`, `msg7`, `msg8`, `firewallthread_msg1`), gemessen mit `FirewallWindowRun` | neu (F4.6g3): die Firewall eines Rechners — Reiter „Konfiguration“ und „Log“, die drei Kästchen (ICMP und UDP nur bei eingeschalteter Firewall), Port mit Protokoll und Absendern, „Hinzufügen“ (das Feld wird danach geleert), „Löschen“ der gewählten Zeile, die Tabelle; das Protokoll in Javas Worten. Besser als Java: ein Port, der keiner ist, wird rot markiert und nicht übergeben; Javas Erklärtext, den Java schreibt, aber nie zeigt, steht unter den Kästchen; eine Regel, die das Fenster nicht machen kann (aus einer Datei: verwerfend oder mit Adresse), zeigt in der Absenderspalte, was sie ist (Java zeigt sie als offenen Port für alle Absender); ins Protokoll kann man nicht tippen | | `src/desktop/GnutellaPanel.tsx`, `src/desktop/DesktopWindow.tsx`, `src/assets/desktop/peertopeer_*.png`, `src/main.tsx` (`filiusDev.writeFile`) | Java `GUIApplicationPeerToPeerAnwendungWindow` (`peertopeeranwendung_msg1`–`31`), Javas Symbole der Reiter, gemessen mit `GnutellaWindowRun` | neu (F4.6g4): Gnutella — vier Reiter mit Javas Symbolen: Netzwerk (Adresse, anfangs Javas 192.168.0.1, rot, solange sie keine ist; „Netz beitreten“, Tabelle der Nachbarn, „Netz verlassen“), Suche (Suchbegriff, „Suchen“, „Stopp!“, Ergebnistabelle mit Wahl, „Herunterladen“, „Liste leeren“), Dateien, Einstellungen (Zahl der Teilnehmer, „Speichern“). Besser als Java: die Tabellen zeigen sofort, was das Programm hält (Javas Ergebnisse zeigen nach einer neuen Suche die alten, bis ein Treffer kommt; seine Dateien nur, was beim letzten Bescheid des Programms da war); jede ganze Zahl wird genommen; was nicht genommen wird, steht unter dem Feld statt in einem Dialog; „Herunterladen“ nur mit gewähltem Ergebnis. Die Dev-Seite schreibt mit `writeFile` eine Datei wie eine andere Person | | `src/simulation/ViewerWindow.tsx`, `src/simulation/DropControl.tsx`, `src/simulation/timeOfDay.ts`, `src/simulation/useSimulation.ts` (`clock`, `dropped`, `drop`), `src/Editor.tsx`, `src/sheet/sheet.css` (`.editor-toolbar`) | Java `SatViewer`, `NatViewer` (`guievents_msg8`–`10`, `27`–`34`, `36`, `sw_switchfirmware_msg1`), `SimulationControl` (`simulation_control_drop_packets`), `GUIKnotenItem` (Klick im Aktionsmodus), gemessen mit `ViewersRun` | neu (F4.6g5): ein Tippen auf einen Switch zeigt seine Tabelle, auf einen Heimrouter seine NAT-Tabelle, in einem verschiebbaren Fenster mit Javas Spalten und Uhrzeiten; „Pakete verwerfen“ wird gehalten (Finger, Maus, Leertaste/Enter), daneben die Zahl und aufklappbar die Liste der verworfenen Frames mit Uhrzeit und Javas Text. Besser als Java: „Tabelle löschen“/„zurücksetzen“ ist ein Knopf (Java: Menü der rechten Maustaste), die Liste klappt weg; die Werkzeugleiste bricht auf schmalen Bildschirmen um | | `src/simulation/CaptureWindow.tsx`, `src/simulation/captureCells.ts`, `src/simulation/useSimulation.ts` (`traces`, `clearCapture`), `src/Editor.tsx`, `src/desktop/desktop.css`, `src/theme/tokens.css` (`--capture-*`), Kataloge (`capture.*`, `menu.showCapture`) | Java `AggregatedExchangeDialog` (`lauscherdialog_msg1`), `AggregatedExchangePanel` (`buttontabcomponent_msg1`), `AggregatedMessageTable` (`nachrichtentabelle_msg7`–`9`), `LauscherTableCellRenderer`, `LayerColorVar`, `Lauscher` (`rp_lauscher_msg1`–`14`), `GUIEvents` (`guievents_msg4`), gemessen mit `ExchangeWindowRun` | neu (F4.7): im Menü eines Geräts je Karte „Datenaustausch anzeigen (Adresse)“; ein Fenster mit einem Reiter je Karte, die Zeilen in Javas Schichtenfarben (dunkle Varianten im dunklen Thema), die gewählte weiß auf schwarz, darunter ihre Details, „Tabellen löschen“, „Als Textdatei exportieren“ (nach dem Reiter benannt), „Automatisches Scrollen“; Wahl und Scrollen je Reiter, behalten, solange das Fenster zu ist; das Fenster geht mit dem Entwurf und kommt mit dem nächsten Start; der Reiter einer entfernten Karte verschwindet. Besser als Java: die drei sind Knöpfe und ein Kästchen statt eines Menüs der rechten Maustaste; ein Frame wird nach seiner Nummer gewählt (Javas Details nehmen den Zeilenindex dafür) | | `src/design/DocumentationSidebar.tsx`, `src/design/DocumentationText.tsx`, `src/design/DocumentationMenu.tsx`, `src/canvas/documentationPaint.ts`, `src/canvas/Canvas.tsx` (Dokumentationsmodus), `src/simulation/ModeBar.tsx` (dritter Knopf), `src/Editor.tsx`, `src/assets/modes/dokumodus*.png`, `src/assets/documentation/*.png`, Kataloge (`mode.documentation`, `docu.*`) | Java `GUIMainMenu` (`btDokumodus`, `guimainmemu_msg14`, Reihenfolge der Knöpfe), `GUIDocumentationSidebar` (`docusidebar_msg1`, `3`), `GUIContainer` (Ablegen aus der Seitenleiste, Ebenen), `JDocuElement` (Fokus, Ziehen, Menü `guievents_msg13`–`21`, Zeichnen), `GUIDocumentationPanel` (Klick daneben), gemessen mit `DocuRun` | neu (F4.8b): der Dokumentationsmodus — Javas dritter Knopf vorn, er stoppt eine Simulation; die Seitenleiste „Text“/„Gliederungsfläche“ (gezogen landet ein Element mittig unter dem Zeiger, mit Fokus); die Elemente liegen über dem Netz und nehmen den Zeiger: Tippen gibt den Fokus, eine Fläche wird an ihrer Mitte gezogen, ein Text in seinem Fokusband, am Rand ändert sich die Größe nach Javas Regel; der Text wird in ein Feld über ihm getippt (auf `Y.Text`, Escape beendet, Strg+Entf löscht); das Menü mit Schriftgröße, Schriftstil, Javas Farben und Löschen; Entf löscht; Javas Zeichnung je Modus (halbtransparent im Dokumentationsmodus, sonst deckend aufgehellt, Rand, grauer Textrand nur im Dokumentationsmodus, Fokus blau). Besser als Java: Tippen auf die Seitenleiste legt ein Element in die Mitte der Ansicht (Java legt nichts ab); das Menü zeigt Größen, Stile und Farben auf einmal statt in Untermenüs; die Ränder lassen sich bei kleinem Zoom mit dem Finger greifen (mindestens 10 Bildschirmpunkte) | | `src/canvas/networkImage.ts`, `src/design/exportImage.ts`, `src/design/DocumentationSidebar.tsx` („Exportieren“), `src/Editor.tsx` (`projectName`), `src/download.ts`, `src/canvas/layout.ts` (`cableFrame`, `cableControl`), `src/main.tsx` (Dateiname), `src/assets/documentation/download_small.png`, Kataloge (`docu.export`, `docu.exportHint`, `docu.saveFailed`) | Java `GUIDocumentationSidebar` (`docusidebar_msg5`, `6`), `GUIContainer.exportAsImage/createNetworkImage`, `GUIPrintPanel`, `GUIFooterPanel`, `GUIMainArea` (Grenzen), `JCablePanel` (Grenzen, Farben), `guimainmemu_msg11`, gemessen mit `ExportRun` | neu (F4.8c): „Exportieren“ in der Seitenleiste des Dokumentationsmodus speichert die Fläche als PNG wie Java — Dokumentation wie im Entwurf gemalt unter dem Netz, Kabel, Geräte, nichts gewählt, Hintergrund durchsichtig; Javas Ausschnitt (10 Rand, die hellgraue Fußzeile 20 unter dem untersten Element, 20 Rand darunter); Dateiname nach dem Projekt; scheitert das Speichern, Javas „Fehler beim Speichern aufgetreten!“. Das Bild wird mit Canvas 2D gemalt, nicht aus der SVG gerastert (ein `foreignObject` sperrt die Leinwand unter WebKit). **Nicht übernommen:** ein leeres Projekt gibt bei Java ein leeres Bild 20 × 35 (die Fußzeile läuft über), hier die Fußzeile allein; Java schneidet an den Rändern seiner Fläche ab, der Editor hat keine. Die Fußzeile trägt den Projektnamen, nicht den Pfad (den kennt kein Browser). Javas englisches „Error occured!“ berichtigt. Der Download des Datenaustauschs nutzt denselben Helfer | | `src/report/reportWriter.ts`, `src/report/report.ts`, `src/report/reportPdf.ts`, `src/design/DocumentationSidebar.tsx` („Report“), `src/Editor.tsx` (Bericht), `src/simulation/useSimulation.ts` (`captures`), `src/simulation/captureCells.ts` (`reportRows`), `src/canvas/networkImage.ts` (`exportNames.report`), `src/assets/documentation/pdf_small.png`, Kataloge (`docu.report`, `docu.reportHint`, `report.*`), Abhängigkeit `pdf-lib` (MIT) | Java `GUIDocumentationSidebar` (`docusidebar_msg7`, `8`, `generateReport`), `ReportGenerator` (Aufbau, Schriften, Farben, Tabellen), iText 5 (Satz: Zeilenabstand, Umbruch, Tabellen, Seitenwechsel), `main_dlg_YES`/`NO`, gemessen mit `ReportRun` | neu (F4.8d): „Report“ speichert Javas Bericht als PDF — Titel und Projektname, „1. Übersicht“ mit dem exportierten Bild, „2. Komponenten“ je Gerät mit Karten (Basiskonfiguration, Netzwerkschnittstellen, Anwendungen, DNS-Einträge, Weiterleitungstabelle, Portweiterleitung), „3. Datenaustausch“ je Karte mit Rahmen; Satz nach iTexts Regeln, Helvetica ohne eingebettete Schrift, Breiten ohne Unterschneidung wie iText (pdf-libs `widthOfTextAtSize` unterschneidet). pdf-lib wird erst beim Klick geladen. Die Rahmen holt der Editor mit einem kurzen Abo aller Karten beim Raum (auch nach dem Stopp). **Nicht übernommen:** `true`/`false` bei DHCP (Javas eigenes „Ja“/„Nein“); Programme und Karten in Javas HashMap-Reihenfolge (hier Installation bzw. Geräte); ein Bild höher als die Seite läuft über den Rand (hier verkleinert); der Bericht schreibt Protokolle der Portweiterleitung ins Modell zurück; „tcp“ klein bleibt bei Java klein. Projektname statt Pfad unter dem Titel; ein Zeichen, das Helvetica nicht schreiben kann, wird „?“ | | `src/Editor.tsx`, `src/canvas/Canvas.tsx` (Aktionsmodus) | Java `GUIContainer.setActiveSite/showDesktop/closeDialogs/reopenDialogs`, `GUIKnotenItem` (Klick im Aktionsmodus), `GUIEvents.kontextMenueAktionsmodus` (`guievents_msg3`), `JCablePanel` (`farbeBlinken`) | erweitert (F4.6a): im Aktionsmodus ist der Entwurf gesperrt wie bei Java — keine Palette, kein Blatt, nichts bewegt sich, kein Rückgängig, kein Löschen —, Kabel mit Rahmen leuchten grün, ein Tipp auf einen Rechner öffnet seinen Desktop (Langdruck: „Desktop anzeigen“); offene Desktops überstehen den Entwurf und erscheinen beim nächsten Start wieder, die eines entfernten Rechners nicht | | `browser/simulation.spec.ts`, `test/programs.test.ts` | — | neu (F4.6a): Moduswechsel, Sperren, Geschwindigkeit, Kabelaktivität, Desktop mit Titel, Programmen, Netzwerk-Info, Verschieben und Stapeln, Handy, Englisch; die Programmliste gegen Javas `Desktop_*.txt`; seit F4.6b die Befehlszeile (Ping über drei Router, Verlauf, Chips, Strg+C, Behalten, exit) und der Fehlerfall des Raums; seit F4.6c die Software-Installation (sofort lauffähig, Doppelklick, Abwählen) | | `browser/web.spec.ts`, `browser/fixtures/web-pages.fls`, `test/webPagesFixture.test.ts`, `test/serverLines.test.ts`, `src/simulation/useSimulation.ts` (`views`), `src/Editor.tsx` (Sprache beim Start), `src/desktop/DesktopWindow.tsx` | — | neu (F4.6d): Browser und Webserver in Chromium auf einer eigenen Projektdatei (mit den Befehlen des Dokuments gebaut und bei jedem Lauf verglichen): Adresszeile, Titel, Sandbox, Bilder, Marke, Links im Ordner, beide Formulare bis in die Zeilen des Servers, Fehlerseite, nicht erreichbarer Server, Knopf, Kästchen und Tabelle, die Routerseiten auf Englisch; die Zeilen des Servers gegen Javas Fenster | | `browser/mail.spec.ts`, `test/mailLines.test.ts` | — | neu (F4.6e): E-Mail in Chromium auf Javas Beispiel `email_komplett` — Prüfungen und Dialoge, Senden, Abrufen, Antworten, Löschen im gewählten Ordner, Konto-Dialog, ein Fehler als Dialog; Konten anlegen und entfernen, Domain nur angehalten; die Zeilen des Server-Fensters gegen Javas Fenster | | `browser/simulation.spec.ts` (Rückweg) | — | erweitert (F4.6f1): ein in der Befehlszeile angelegter Ordner ist nach Entwurf und Neustart da, ein entfernter weg | | `browser/text.spec.ts`, `test/textEditor.test.ts`, `test/textBinding.test.ts`, `src/main.tsx` (`filiusDev.insertText`) | — | neu (F4.6f2): Javas Schritte am Fenster des Texteditors nachgespielt (gleich, wo Java recht hat, benannt, wo es irrt); in Chromium: im Lauf installiert, eine Seite über Javas Dialog in den Webserver gespeichert, vom anderen Rechner abgerufen, im Lauf geändert und wieder abgerufen, der Cursor bleibt, wo man tippt, Rückgängig, Ablehnungen im Dialog, eine von der Befehlszeile gelöschte offene Datei, „Neu“, Weitertippen nach einer fremden Änderung vor dem Cursor (die Entwicklungsseite schreibt dafür wie eine andere Person in eine Datei); wohin Cursor und Auswahl bei fremden Änderungen gehen | | `browser/files.spec.ts`, `test/fileExplorer.test.ts` | — | neu (F4.6f3): Javas Schritte an Explorer und Bildbetrachter nachgespielt (gleich, wo Java recht hat, benannt, wo es irrt); in Chromium: im Lauf installiert, Ordner angelegt, über Javas Rechtsklick-Menü kopiert und eingefügt, Javas Meldung beim Einfügen in sich selbst, per Knopf umbenannt und nach „Sicher?“ gelöscht, was die Befehlszeile anlegt sofort sichtbar, ein lokales Bild importiert und im Bildbetrachter gezeigt, eine Textdatei dort abgelehnt | | `browser/echo.spec.ts`, `test/serverLines.test.ts` (Echo) | — | neu (F4.6g1): Echo in Chromium — im Lauf installiert, ein Port, der keiner ist, markiert, Server gestartet, Client verbunden, Felder gesperrt, Nachricht gesendet und zurückbekommen, Trennen; die Zeilen beider Fenster gegen Javas | | `browser/dns.spec.ts` | — | neu (F4.6g2): der DNS-Server in Chromium auf `email_komplett` — Knopf, Reiter, eigene Adresse im Feld, Javas Beispiel bei Ungültigem, Eintrag hinzugefügt, Zelle geschrieben und eine abgelehnt, Zeile entfernt, MX, Kästchen, Beenden; die Befehlszeile des Web-Servers löst den neuen Namen auf | | `browser/firewall.spec.ts`, `test/serverLines.test.ts` (Firewall) | — | neu (F4.6g3): die Firewall in Chromium auf `email_komplett`, im Lauf auf dem Web-Server installiert — Javas Kästchen, ein Port abgelehnt und einer hinzugefügt, der Browser eines Notebooks durch die Regel gelassen, ICMP verboten und dessen Ping verworfen (beides im Protokoll), die Firewall aus (die Kästchen darunter gesperrt), die Regel gewählt und gelöscht; die Zeilen des Protokolls und der Tabelle Wort für Wort wie Javas | | `browser/gnutella.spec.ts` | — | neu (F4.6g4): Gnutella in Chromium auf `email_komplett`, im Lauf auf zwei Notebooks installiert — vier Reiter, eine Adresse mit Javas Worten abgelehnt, ein Nachbar beigetreten, eine Datei des anderen gefunden und heruntergeladen (der Reiter Dateien zeigt sie), „Liste leeren“ hebt die Wahl auf, die Zahl der Teilnehmer gespeichert (12, die Java ablehnt; was keine Zahl ist, mit Javas Worten abgelehnt), das Netz verlassen | | `browser/viewers.spec.ts`, `test/timeOfDay.test.ts` | — | neu (F4.6g5): auf `nat_with_mapped_port` die NAT-Tabelle (Portweiterleitung, dann ein Ping, zurückgesetzt), die Switch-Tabelle (gelernt, gelöscht), „Pakete verwerfen“ gehalten, während ein Ping läuft (Antworten verloren, Liste in Javas Worten); auf einem Handy bleibt „Pakete verwerfen“ erreichbar; die Uhrzeit wie Javas `HH:mm:ss(.SSS)` | | `browser/capture.spec.ts`, `test/captureCells.test.ts` | — | neu (F4.7): auf `web-pages.fls` Javas Menü, eine Seite geladen (Zeile je Frame, Javas Farben, Details, Textdatei mit Javas Kopf), die Karten eines Routers, „Tabellen löschen“, „Automatisches Scrollen“ aus, ein Reiter geschlossen, das Fenster über Entwurf und Start, der Reiter eines entfernten Rechners weg; auf einem Handy; die Zellen in beiden Sprachen und Zahlenformaten | | `browser/documentation.spec.ts`, `test/documentationPaint.test.ts` | — | neu (F4.8b): auf `nat_with_mapped_port` Javas Knopfreihenfolge, eine Fläche gezogen (mittig, grau, Deckkraft 200), verschoben, auf 20 × 20 verkleinert, Farbe aus Javas zwölf; ein Text getippt, groß und kursiv; Escape, Javas Textrand; im Entwurf deckend aufgehellt, nicht wählbar; Entf; Start der Simulation beendet den Modus; Handy; die Zeichenregeln gegen Javas gemessene Pixel | | `test/networkImage.test.ts`, `test/networkImage.java.json`, `browser/documentation.spec.ts` (Export) | — | neu (F4.8c): Ausschnitt und Fußzeile gegen Javas Druckpanel auf vier Projekten (aus Javas eigenen Grenzen, die von Javas Schrift abhängen), jedes Kabel Javas gegen `cableFrame`, Javas Farben (durchsichtig, Fußzeile 192, Fläche wie im Entwurf); Zeilenumbruch; Dateinamen; das Malen auf einem aufzeichnenden Kontext (Reihenfolge, Farben, gestrichelte Funkstrecke); im Browser der Download (Name, Größe aus den Rahmen der Fläche, Eckpixel, Flächenfarbe 215, Fußzeile hellgrau) und Javas Meldung, wenn `toBlob` nichts liefert | | `test/report.test.ts`, `test/report.java.json`, `test/report.ours.java.json`, `browser/report.spec.ts` | — | neu (F4.8d): jedes Textstück von Javas Bericht (Wort, Ort, Schrift, Größe, Farbe) gegen den eigenen Satz — alle Geräteseiten von `Internet_Komplett`, die erste Seite, ein langer Titel, ein Projekt ohne Geräte, ein leeres, der Datenaustausch von `einfaches_rechnernetz_komplett` über alle Seiten (Javas Zeilen aus Javas Seiten); Javas iText liest das eigene PDF und findet dieselben Stücke an denselben Orten (SHA-256 festgehalten); im Browser der Bericht nach einem kurzen Lauf mit DHCP: Dateiname, Titel, Bild, Geräte, Datenaustausch | | `browser/touch.spec.ts`, `browser/fingers.ts`, `playwright.config.ts` (Projekte `ipad-portrait`, `ipad-landscape`), `package.json` (Playwright fest auf 1.62.1) | — | neu (F4.9): der Editor nur mit dem Finger, in Chromium am Desktop und in WebKit als iPad hoch und quer — die Abnahme von F4 als Ablauf ("zwei Rechnernetze" neu gebaut, Adressen im Blatt, Kabel per Werkzeug, Befehlszeile installiert, Ping quer über den Router), Zwei-Finger-Zoom vergrößert die Fläche und nie die Seite (M7, ohne Rahmen), jede Aktion ohne Rechtsklick (langes Drücken, Dreipunkt-Knopf, Menü der Dokumentation), alle Ziele mindestens 44 px, nichts über den Rand. Echte Gesten: Chromium über CDP, WebKit über `Input.dispatchTouchEvent` seiner Seitensitzung, die Playwright nur über die Verbindung im selben Prozess hergibt (Naht im Inneren von Playwright, Version deshalb fest). Ein gezogener Finger hält vor dem Loslassen 150 ms still: sonst nimmt Chromium die Geste als Schwung, und das nächste Antippen stoppt nur den Schwung | | `src/sheet/ServicePanels.tsx`, `src/sheet/RowsEditor.tsx`, `src/sheet/SheetTabs.tsx`, `src/sheet/DeviceSheet.tsx` (Seiten) | Java `JDHCPKonfiguration` (`jdhcpkonfiguration_msg1`–`15`), `JPortForwardingDialog` (`jportforwarding_msg4`–`7`, `jgatewayconfiguration_msg19`) | neu (F4.5c): Javas Dialoge als Seiten des Blatts mit „Zurück“ — DHCP-Server (Grundeinstellungen, statische Adresszuweisung; beim Rechner, gesperrt während DHCP die Karte einrichtet, und auf dem LAN-Reiter des Heimrouters), Portfreigaben (Heimrouter); jedes Feld beim Verlassen übernommen statt mit Javas OK-Knopf. Die Zeilentabellen (Weiterleitung, Zuordnungen, Portfreigaben) teilen sich `RowsEditor`: eine neue Zeile, sobald alle Felder gültig sind, Zeile wählen, bearbeiten, löschen. Javas Tooltip zu „Manuelle Einstellungen“ als Text unter dem Kästchen (ein Finger hat kein Überfahren) | | `src/sheet/RouterSheets.tsx`, `src/sheet/NameField.tsx`, `src/canvas/Canvas.tsx` (`highlightedLink`), `src/theme/tokens.css` (`--canvas-cable-active`) | Java `JVermittlungsrechnerKonfiguration`, `JGatewayConfiguration`, `JWeiterleitungsTabelle` (Wörter `jvermittlungsrechnerkonfiguration_msg6`–`26`, `jweiterleitungstabelle_msg3`–`6`), `JCablePanel.farbeBlinken`, `Kabel.setAktiv` | neu (F4.5b): Blatt des Vermittlungsrechners — Reiter Allgemein (Name, Gateway, Automatisches Routing, IP-Weiterleitung nur angezeigt), je Karte (Reiter mit ihrer Adresse, „Verbunden mit …“, Adresse, Maske, MAC) und Weiterleitungstabelle (alle Einträge oder nur die manuellen, Javas Zeilen grau, eine neue Zeile, die mit vier gültigen Feldern übernommen wird, Zelle bearbeiten, Eintrag löschen; bei RIP gesperrt); Blatt des Heimrouters mit Allgemein, LAN, WAN (DHCP sperrt die WAN-Adresse). Das Kabel der offenen Karte leuchtet grün wie bei Java. Javas „Eintrag Löschen“ klein geschrieben | | `src/remote/remoteSimHost.ts`, `src/remote/sharedDoc.ts`, `src/remote/SharedProject.tsx`, `src/main.tsx` (`?project=`) | Plan §5, §6.1, §8.5; Hocuspocus' Provider 3.4.4 (MIT) | neu (F5.3b): der Editor auf einem Projekt von F — das gemeinsame Dokument über `/sync` (bereit mit Dokument, Lesestufe und ob eingefroren; abgewiesen; getrennt) und der Raum über `/sim` (`RemoteSimHost`: Nachrichten vor dem Öffnen warten, nach einem Verlust kommt der Socket wieder, mit doppelter Wartezeit bis 10 s und allen abonnierten Themen; Absage und Trennung von F beenden ihn); wer liest und wieder schreiben darf (aufgetaut), bekommt das Dokument neu; statt des Editors ein Wort, warum nicht | | `src/Editor.tsx`, `src/canvas/Canvas.tsx` (`locked`), `src/sheet/SheetLock.tsx`, `src/sheet/DeviceSheet.tsx`, `src/sheet/RouterSheets.tsx`, `src/sheet/FirewallPanel.tsx`, `src/sheet/ServicePanels.tsx`, `src/design/DocumentationSidebar.tsx`, `src/simulation/ModeBar.tsx`, `src/simulation/useSimulation.ts`, `src/i18n/*.json` | Plan §6.2, §6.4, §9.3 | geändert (F5.3b): wer nur liest, sieht alles und ändert nichts — keine Palette, kein Rückgängig, nichts bewegt sich oder hat ein Menü, die Felder des Blatts sind gesperrt (die Reiter bleiben), keine neuen Doku-Elemente, die Simulation wird von ihm weder gestartet noch angehalten; Desktops und Datenaustausch öffnen zum Zuschauen; ein „nein“ des Raums wird gesagt; „Simulation gestartet von …“ und „Nur ansehen“ bzw. „Eingefroren – nur ansehen“ neben den Modusknöpfen | | `src/remote/presence.ts`, `src/remote/usePresence.ts`, `src/remote/PresenceMarks.tsx`, `src/remote/sharedDoc.ts` (`you`, Awareness), `src/remote/SharedProject.tsx` (`onPeople`), `src/Editor.tsx`, `src/canvas/Canvas.tsx` (`chosenBy`), `src/desktop/DesktopWindow.tsx`, `src/simulation/ViewerWindow.tsx`, `src/simulation/CaptureWindow.tsx`, `src/bridge/dashboardBridge.ts` (`people`), `src/main.tsx`, `src/i18n/*.json` | Plan §7.4 | neu (F5.4): die anderen im Projekt über Yjs-Awareness — jeder Editor sagt, wer er ist (von F), welches Gerät er gewählt und welche Fenster er offen hat, und nichts sonst (kein Mauszeiger, nichts, das sich ohne Anlass ändert; gesendet nur bei einer Änderung); fremde Zustände werden geprüft gelesen; ein Rahmen in der Farbe der Person um ein Gerät, das sie gewählt hat, ein Punkt an einem Fenster, das sie auch offen hat, ein Kreis mit den Initialen je Person neben den Modusknöpfen (eine Person mit zwei Tabs einmal); eine Person ohne Farbe des Dashboards bekommt eine aus ihrer Kennung; die Brücke meldet dem Dashboard die Personen (`people`). Name und Farbe sagt der Editor selbst — wer seinen Editor verändert, könnte den anderen im Projekt einen anderen Namen zeigen | | `src/moving.ts`, `src/Editor.tsx` (Züge), `src/remote/presence.ts` (`moving`), `src/remote/usePresence.ts` (`MOVING_MILLISECONDS`), `src/canvas/Canvas.tsx` (Zugende), `src/main.tsx` (`filiusDev.updates`), `test/moving.test.ts` | Plan §7.4, M4 | neu (F5.6d): ein Zug — ein Gerät verschieben, ein Element der Dokumentation verschieben oder vergrößern — kommt erst beim Loslassen ins Dokument, als eine Änderung; solange er dauert, zeigt ihn der Editor selbst und sagt ihn den anderen über die Anwesenheit (`moving`, höchstens alle 50 ms die Lage dann, das Ende sofort). Gemessen (M4): vorher jede Mausbewegung eine Änderung, 59/s, je ~18 Byte bleibender Verlauf im Dokument. Ein Zug, den der Browser abbricht oder den ein zweiter Finger zur Geste macht, bleibt, wo er war (WebKit schickt beim zweiten Finger noch einmal `pointerdown` für den ersten); der Zug einer anderen Person wird geprüft gelesen, ein Editor ohne `moving` gilt als „zieht nichts“ | | `test/presence.test.ts` | — | neu (F5.4): Lesen fremder Zustände, die anderen ohne sich selbst, eine Person einmal, Rahmen und Punkte, Farben, Initialen, Senden nur bei Änderung | | `src/remote/remoteBlobs.ts`, `src/remote/SharedProject.tsx` (Blob-Seite), `src/desktop/fileExplorer.ts` (Bildbetrachter), `src/i18n/*.json` | Plan §5.1 | neu (F5.5): die Blob-Seite des Editors auf F — was das Dokument nennt, wird geholt (mit dem Keks; was F noch nicht hat, ein paar Mal im Abstand neu gefragt), was hier entsteht (eine importierte Datei), sofort gehalten und zu F gebracht (einmal wiederholt, dann gesagt); der Bildbetrachter zeichnet neu, wenn die Bytes kommen | | `test/remoteBlobs.test.ts` | — | neu (F5.5): Hochladen, Wiederholen, Scheitern (auch bei falschem Namen), Holen je Blob einmal, nachfragen bei 404, Netzverlust | | `test/remoteSimHost.test.ts`, `browser/shared.spec.ts`, `browser/serverF.ts` | — | neu (F5.3b), erweitert (F5.5: ein großes Bild, von Mia importiert, bei Ben im Bildbetrachter, in F's Speicher unter seinem SHA-256): `RemoteSimHost` auf nachgebauten Sockets mit gestellter Uhr; drei Personen in drei Browsern an einem echten F (aus dem Bündel gestartet): verschieben, nur lesen, eine Simulation für alle mit Namen, ein Ping in einer Befehlszeile bei der anderen, Eintippen als Leser abgewiesen, eingefroren und aufgetaut, Zugang beendet; Absagen ohne Sitzung und ohne Projekt | | `src/canvas/Canvas.tsx` (`hasMenu`), `src/Editor.tsx` (Aktionsmodus), `src/simulation/SimulationSheet.tsx`, `src/desktop/DesktopSheet.tsx` (vorher `DesktopWindow.tsx`), `src/simulation/ViewerSheet.tsx` (vorher `ViewerWindow.tsx`), `src/simulation/CaptureSheet.tsx` (vorher `CaptureWindow.tsx`), `src/desktop/desktop.css`, `src/i18n/*.json` (`menu.showSat`, `menu.showNat`, `sheet.seeThrough`), `browser/*.spec.ts` (`showFromMenu`, `showDesktop`), `tools/live/acceptance.ts` | Java `GUIEvents.kontextMenueAktionsmodus`, `GUIKnotenItem` (Klick im Aktionsmodus), `GUIDesktopWindow`, `SatViewer`, `NatViewer`, `AggregatedExchangeDialog` | geändert (F6.5, auf Wunsch des Nutzers): im Aktionsmodus wählt ein Tipp das Gerät nur aus, sein Dreipunkt-Knopf erscheint wie im Entwurf (nur wo das Menü etwas anbietet); geöffnet wird über das Menü — Desktop, „SAT Tabelle anzeigen“ am Switch, „NAT-Tabelle anzeigen“ am Heimrouter, Datenaustausch je Karte. Desktop, Tabellen und Datenaustausch sind keine Fenster im Fenster mehr, sondern das Blatt des Aktionsmodus nach dem Muster des Dashboard-Blatts (`AppSheet`): unter der Werkzeugleiste bis zum unteren Rand, Kopf mit Symbol, Titel, Anwesenden, „Durchsichtig“ und ×; eins zur Zeit (es deckt die Fläche, ein anderes öffnet man nach dem Schließen); ein Blatt, dessen Gerät entfernt wurde, schließt; es übersteht die Rückkehr in den Entwurf, ein Desktop behält sein offenes Programm. „Durchsichtig“ (Deckkraft 0,55, im Browser gemerkt) lässt das Netz durchscheinen. Das Geräteblatt bleibt im Aktionsmodus zu, die anderen sehen keinen Rahmen um ein dort gewähltes Gerät. Abweichend von Java: Java öffnet Desktop und Tabellen mit einem Klick aufs Gerät, als verschiebbare Fenster, mehrere zugleich, und sein Menü nur mit Rechtsklick | | `src/sheet/SheetTabs.tsx` (`variant="segmented"`), `src/sheet/sheet.css` (`.sheet-segments`), `src/sheet/ServicePanels.tsx` (DHCP-Server), `browser/sheet.spec.ts` | Java `JDHCPKonfiguration` (Reiter `jdhcpkonfiguration_msg10/11`) | geändert (10.10.2026, auf Wunsch des Nutzers): die beiden Seiten des DHCP-Servers („Grundeinstellungen“, „Statische Adresszuweisung“) als Segment-Control nach dem Muster des Dashboards — ein Rahmen, gleiche Anteile, das gewählte in der Akzentfarbe. Javas Wörter bleiben; gemessen: „Grundeinstellungen“ ist bei 14 px 138 px breit, eine Hälfte des 340-px-Blatts hält 139 (halbfett 157 px). Darum: Wörter brechen in ihrem Segment an Leerzeichen um, das gewählte ist nicht fett (die Breite spränge), und wo das längste Wort eines Segments samt Innenabstand nicht mehr in seinen Anteil passt (Handy, andere Systemschrift), stehen die Segmente untereinander, als ein Control — entschieden durch Messen der Wörter in der Schrift der Segmente (Canvas), nicht durch eine feste Breite. Abweichend von Java: dort Reiter (JTabbedPane) | | `src/design/SideBar.tsx` (neu), `src/design/Palette.tsx`, `src/design/DocumentationSidebar.tsx`, `src/Editor.tsx`, `src/sheet/sheet.css` (`.side-bar`), `src/i18n/*.json` (`design.foldBar`, `design.unfoldBar`), `browser/design.spec.ts`, `browser/documentation.spec.ts` | Java `GUIDesignSidebar`, `GUIDocumentationSidebar`; Dashboard `AppShell` („Leiste einklappen“) | erweitert (10.10.2026, auf Wunsch des Nutzers): die Leiste links (Palette, Dokumentationsleiste) klappt mit einem Knopf oben ein und aus — eingeklappt eine schmale Spalte (57 px statt 137) mit nur dem Knopf, nach dem Muster der Dashboard-Leiste; der Knopf steht in beiden Zuständen an derselben Stelle. Ein Zustand für beide Leisten, in diesem Browser gemerkt (`filius.barFolded`). Gemessen: die Fläche gewinnt 80 px (iPad hochkant mit Blatt 291 → 371 px, Handy 253 → 333 px). Abweichend von Java: dort ist die Leiste fest | | `src/sheet/sheet.css` (`.editor-root`, Handy), `src/Editor.tsx` (Wurzel), `browser/sheet.spec.ts` | — | geändert (10.10.2026, auf Wunsch des Nutzers): auf dem Handy (bis 639 px) nimmt das Geräte-Blatt den ganzen Editor ein, über der Leiste und den Modusknöpfen; eine Meldung bleibt darüber, Schließen gibt die Fläche zurück. Vorher stand es unter der Fläche (höchstens halb so hoch), neben einer Leiste von 137 px blieben ihm 253 von 390 px. Folge: die DHCP-Segmente stehen auf einem 390-px-Handy jetzt nebeneinander, untereinander erst unter etwa 335 px | | `src/simulation/PropertiesSheet.tsx` (neu), `src/simulation/DropHold.tsx` (vorher `DropControl.tsx`), `src/simulation/useSimulation.ts` (`restart`), `src/Editor.tsx`, `src/sheet/sheet.css`, `src/desktop/desktop.css`, `src/i18n/*.json` (`properties.*`; `drop.list` entfällt), `browser/viewers.spec.ts`, `browser/shared.spec.ts`, `browser/fromF.spec.ts`, `tools/live/acceptance.ts` | Java `SimulationControl` | geändert (10.10.2026, auf Wunsch des Nutzers): im Aktionsmodus ein eigener Inspector „Eigenschaften“ (Knopf über der Fläche, Blatt neben ihr wie die Geräte-Einstellungen, auf dem Handy über dem ganzen Editor) statt Hinweis und Knöpfen in der Werkzeugleiste: wer die Simulation gestartet hat, „Simulation neu starten“ (für alle, nach einer Rückfrage; die Tabellen des Datenaustauschs verlieren ihre Auswahl), „Pakete verwerfen“ und darunter die verworfenen Pakete samt Anzahl. Wer nur zusieht, sieht Starter und Liste, ohne Neustart und Verwerfen | | `src/canvas/handles.ts` (neu), `src/canvas/Canvas.tsx` (Griffe, Durchtippen, Platz von „⋯“), `src/sheet/sheet.css` (`.doc-handle`), `src/i18n/*.json` (`docu.resize`, `docu.move`), `test/handles.test.ts`, `browser/touch.spec.ts`, `browser/documentation.spec.ts` | Java `JDocuElement` (Rand von 7 zum Greifen) | erweitert (10.10.2026, auf Wunsch des Nutzers): im Dokumentationsmodus zeigt das fokussierte Element Griffe für den Finger — Trefferfläche 44 px, Punkt in Javas Fokusblau auf dem Fokusband: an den Ecken, ab drei Zielen Länge auch an den Kantenmitten; auf einem Element unter zwei Zielen nur rechts unten, außen an der Ecke, damit seine Mitte verschiebt und das Menü öffnet. Ein Text hat über seiner linken oberen Ecke einen Verschiebe-Griff (seine Mitte ist das Eingabefeld). „⋯“ steht über der rechten oberen Ecke; Griff und „⋯“ weichen am Rand der Fläche aus. Ein Tippen auf einen Griff gilt dem, was darunter liegt; langes Drücken öffnet das Menü. Gemessen: Javas Rand war 10–14 Bildschirm-Pixel breit und unsichtbar. WebKit gibt das Ende eines Tippens dem Griff statt der Fläche, die die Berührung gefangen hat; der Griff reicht seine Ereignisse deshalb weiter. Javas Rand für die Maus bleibt. Abweichend von Java: dort keine Griffe | ## packages/server | Datei | Quelle | Art der Übertragung | | --- | --- | --- | | `src/sync.ts`, `src/persistence.ts`, `src/store.ts`, `src/server.ts`, `src/log.ts`, `src/main.ts`, `src/index.ts` | Plan §5.3, §5.4, §8.2; Hocuspocus 3.4.4 (MIT), `ws` (MIT), `pg` (MIT) | neu (F5.1): Server F mit den gemeinsamen Dokumenten — Hocuspocus auf `/sync`, ein Projekt je Dokument, nur Projekte, die der Speicher kennt (Absage mit Grund `unknownProject` bzw. `notAProject`); jede Aktualisierung sofort in Postgres (`filius_doc_update`, der Reihe nach), verdichtet nach 500 Aktualisierungen, eine Minute nach der letzten Änderung und wenn die letzte Person geht (`filius_doc`, `FOR UPDATE` auf die beim Anlegen geschriebene Zeile); ein Projekt, das während des Bearbeitens verschwindet, wird nicht still neu geschrieben, sondern im Protokoll gemeldet; der Hausmeister läuft nur hier, beim Laden und 250 ms nach jeder fremden Änderung; Lesestufe kann nichts ändern; `/healthz`; Protokoll als JSON-Zeilen. Beim Schließen nimmt der Dienst niemanden mehr an und schließt auch die WebSockets (Hocuspocus' eigenes Schließen ist eine Nachricht, nach der sich ein Client auf demselben Socket wieder anmeldet). Hocuspocus 4 verlangt Node 22; 3.4.4 läuft auf Node 20 und 22 | | `src/ticket.ts` | itsdangerous 2.2.0 (BSD-3-Clause) `URLSafeTimedSerializer`, `TimestampSigner`, `Signer` (django-concat, HMAC-SHA1); Dashboard `backend/modules/scratch/src/ticket.py` | neu (F5.2): die Eintrittskarte des Dashboards in Node geprüft, wie itsdangerous sie prüft (zlib-gepackte Nutzlast mit „.“, Zeitstempel als kürzeste Bytes, Signatur zuerst, dann das Alter: über 60 s oder unter 0 abgelehnt); die Ansprüche Person, Login, Name, Farbe, Sprache, Projekt, Stufe — ohne Person, Login, Projekt oder gültige Stufe keine Karte. Strenger als Python: eine Signatur mit fremden Zeichen, die Pythons Base64 überliest, wird abgelehnt (itsdangerous erzeugt sie nie) | | `src/sessions.ts`, `src/auth.ts` | Scratch-Editor `dashboard_auth_routes.py`, `models/session.py` | neu (F5.2): `/__auth` tauscht die Karte gegen einen Keks (`filius_session`, HttpOnly, SameSite=Lax, über HTTPS `Secure`, 12 h) und schickt den Browser nach `next` — nur an einen Ort von F selbst, aufgelöst wie im Browser: `/\…` und `//…` führen nicht weg (Scratchs Prüfung lässt beide durch, Werkzeug reicht sie roh weiter, der Browser liest `//…` — gemessen), und weil F den aufgelösten Pfad weitergibt, auch nicht `/.//…`, das die Auflösung zu `//…` kürzt; F speichert nur den SHA-256 des Schlüssels; ein zweites Projekt im selben Browser hängt eine Berechtigung an die Sitzung, eine Karte einer anderen Person beendet die alte Sitzung; jede Karte verlängert, abgelaufene werden gelöscht | | `src/sync.ts` (Anmeldung), `src/server.ts` (Wege, Herkunft) | Plan §8.5 | geändert (F5.2): `/sync` entscheidet nach der Berechtigung der Sitzung, die der Keks nennt — keine, Lesen, Schreiben; ein eingefrorenes Projekt lesen alle; jede Absage mit Grund und im Protokoll; ein WebSocket von einer Seite fremder Herkunft wird abgewiesen (eine Seite anderswo unter derselben Domain brächte den Keks mit, SameSite trennt nur Sites); unerwartete Fehler eines Wegs werden 500 und stehen im Protokoll | | `src/service.ts`, `src/store.ts` (`freeze`, `remove`), `src/persistence.ts` (`discard`), `src/main.ts` | Dashboard `backend/modules/scratch/src/service.py`, Scratch-Editor `revoke`, `active_sessions` | neu (F5.2): `/svc/*` mit Dienstschlüssel (in konstanter Zeit verglichen): Projekt anlegen (leeres FILIUS-Projekt), löschen (erst nicht mehr gespeichert, dann weg, dann alle getrennt — wer wiederkommt, findet kein Projekt), einfrieren und auftauen (wer drin ist, liest bzw. schreibt wieder und erfährt es), Berechtigung einer Person an einem Projekt oder alle ihre Sitzungen beenden (wer verbunden ist, wird getrennt und beim Wiederkommen abgewiesen), die Sitzungen auflisten; ohne Geheimnisse startet der Dienst nicht | | `src/simRooms.ts`, `src/simWorker.ts`, `src/simChannel.ts`, `src/server.ts` (`/sim`), `src/service.ts` (Räume) | Plan §6.1–§6.4, §8.2 | neu (F5.3a): die Simulationsräume auf F — einer je Projekt für alle darin, gehalten von wenigen `worker_threads` (der mit den wenigsten Räumen nimmt den nächsten), jeder Raum mit einer Kopie des Dokuments: Hocuspocus' direkte Verbindung hält das Dokument offen, solange der Raum lebt, jede Änderung geht in den Raum, was der Raum schreibt, kommt als seine Änderung zurück; `/sim?project=…` meldet an wie `/sync` (Keks, Berechtigung, Herkunft), Nachrichten vor der Anmeldung werden gehalten; ändern nur mit Schreibstufe; nach dem Letzten bleibt der Raum 60 s und hält dann, schreibt zurück und endet; Einfrieren hält eine laufende Simulation an (ihr Stand kommt noch ins Projekt), Löschen beendet den Raum ohne Zurückschreiben, Widerruf trennt auch im Raum; ein scheiternder Faden beendet seine Räume; beim Herunterfahren halten alle Räume und schreiben zurück; ein Socket ohne Antwort auf Pings wird getrennt; Nachrichten höchstens 1 MiB; `/healthz` zählt die Räume; der Build bündelt den Faden als `dist/simWorker.mjs` | | `src/sync.ts` (Zugang gleich zu Beginn, stille Absage) | Plan §8.5 | geändert (F5.3b): jede Verbindung erfährt ihren Zugang sofort nach der Anmeldung (Nachricht `access`), damit der Editor weiß, ob er liest und warum; eine Absage trägt keinen Meldungstext — Hocuspocus schreibt sonst die Meldung eines gescheiterten Hooks auf die Konsole, außerhalb des JSON-Protokolls | | `src/sync.ts` (`you`), `protocol/src/sync.ts` (`AccessMessage.you`) | Plan §7.4 | erweitert (F5.4): die Zugangsnachricht beim Verbinden nennt die Person (Kennung, Name, Farbe aus der Karte), damit der Editor sich den anderen zeigen kann — der Keks ist für die Seite nicht lesbar | | `src/blobs.ts`, `src/blobRoutes.ts`, `src/simWorker.ts` (Blobs), `src/simRooms.ts` (Blobs), `src/simChannel.ts`, `src/server.ts` (`/blobs`), `src/main.ts`, `test/blobs.test.ts` | Plan §5.1 | neu (F5.5): die Blobs auf F, inhaltsadressiert (`filius_blob`, F rechnet den Namen selbst aus); `GET /blobs/?project=` mit Berechtigung am Projekt, `POST /blobs?project=` mit Schreibstufe, nicht eingefroren, nur von der Herkunft des Editors, höchstens 16 MiB; CORS für die Herkünfte des Editors; der Raumfaden fragt nach den Blobs seines Dokuments, ein Start wartet auf die gefragten, was F noch nicht hat, wird ein paar Mal neu gefragt und kommt in die laufende Simulation; ein Blob, den die Simulation macht, wird gespeichert, bevor die Änderung, die ihn nennt, angewandt wird. Noch nicht: Blobs vergessen, die kein Projekt mehr nennt | | `src/editorFiles.ts`, `src/precompress.ts`, `src/precompressMain.ts`, `src/server.ts` (Editor), `src/main.ts` (`FILIUS_EDITOR_DIR`), `test/editorFiles.test.ts`, `editor/browser/fromF.spec.ts` | Plan §8.2, §8.3 | neu (F5.6b): F liefert die Seite und das Bundle des Editors selbst aus (Ordner `editor/` neben `main.mjs`), damit der Editor von Fs Herkunft kommt und sie als seinen Server nimmt; nur GET und HEAD, nur Dateien im Ordner (jedes `..`, auch kodiert, wird aufgelöst und außerhalb abgewiesen); Fs eigene Wege gehen vor; `assets/` (Vite benennt nach dem Inhalt) ein Jahr im Cache, alles andere jedes Mal neu gefragt; der Build legt `.br` und `.gz` daneben, wo sie kleiner sind, F schickt die bessere, die der Browser nimmt (das Bundle 695 KB → 212 KB mit brotli). Ohne Ordner beantwortet F nur seine Wege und meldet es im Protokoll | | `src/ticket.ts` (`TICKET_AHEAD_SECONDS`), `test/ticket.test.ts`, `tools/ticket-oracle` (zwei Fälle) | itsdangerous 2.2.0 `TimestampSigner.unsign` | geändert (F5.6c): eine Karte darf bis zu 5 s vor Fs Uhr signiert sein — itsdangerous lehnt schon eine Sekunde ab. Gemessen auf test-filius: Fs Uhr 886 ms hinter der des Dashboard-Rechners wies fast neun von zehn Karten ab, mit NTP 8 ms noch eine von 125 (eine Karte trägt ganze Sekunden). Das Orakel hält fest, dass Python die Karten 1 s und 5 s voraus ablehnt und 6 s voraus wie F | | `src/transfer.ts`, `src/service.ts` (Beispiele, Import, Kopie, Export), `src/server.ts`, `src/main.ts` (`FILIUS_EXAMPLES_DIR`), `test/transfer.test.ts`, `test/bundle.test.ts`, `package.json` (Banner) | Plan §11, F6 | neu (F6.1): FILIUS-Dateien über den Dienstweg — `GET /svc/examples` (die Java-Beispiele liegen neben F im Image, GPL wie dieses Repo, nicht im Dashboard), `POST /svc/projects` mit `example`, `POST /svc/projects//import` (die `.fls` als Rumpf, höchstens 64 MiB), `POST /svc/projects//copy` (der Stand jetzt, auch während jemand arbeitet), `GET /svc/projects//export` (die `.fls`, Warnungen in `X-Filius-Warnings` als base64url-JSON); große Dateien gehen beim Import zuerst in den Blob-Speicher, der Export nimmt ihre Bytes von dort und wird ohne sie nicht gemacht. **Fehler vorher gefunden:** der Rumpf einer Anfrage ist in Node ein `Buffer`, die Dateien einer `.fls` wären Stücke davon, und Yjs nimmt keinen `Buffer` ins Dokument — jede `.fls` mit Binärdateien wäre gescheitert. **Und beim Bau des Image:** `fflate` (über `fls` jetzt im Bundle) importiert `createRequire` selbst, das Banner des Builds deklarierte es ein zweites Mal — F startete nicht; das Banner nennt es jetzt anders, ein Test baut und startet den Bundle | | `test/editorConnection.test.ts` | — | neu (F5.3b), erweitert (F5.4: Identität von F, die anderen über die Awareness, auch eine lesende Person, weg mit dem Schließen): `connectSharedDoc` des Editors gegen einen echten F — bereit mit Schreib- und Lesestufe, eingefroren und aufgetaut (neues Dokument, die verirrte Änderung ist weg, Schreiben geht wieder), eingefroren von Beginn an, Absage, Widerruf, Löschen, Loslassen | | `test/sim.test.ts`, `test/harness.ts` (Faden) | — | neu (F5.3a): echte Sockets, der echte Faden (esbuild bündelt ihn wie der Build), Beispiel internetwork_komplett: ein Start für alle mit Namen, Ping in einer Befehlszeile bei der anderen, Zurückschreiben ins Dokument und eine Datei aus dem Dokument im Raum, Lesestufe, Absagen, Nachlauf, Einfrieren, Löschen, Widerruf, Wahl des Fadens, scheiternder Faden, Herunterfahren, Ping | | `test/ticket.test.ts`, `test/tickets.ts`, `test/tickets.python.json` | `tools/ticket-oracle` | neu (F5.2): jede Karte des Python-Orakels liest Node wie Python (Nutzlast oder derselbe Grund der Ablehnung); in Node signierte Karten tragen dasselbe JSON zum selben Zeitpunkt (Nodes zlib packt anders, ungepackt byte-gleich); die Ansprüche | | `test/access.test.ts`, `test/harness.ts` | — | neu (F5.2): `/__auth` (Keks, `next`, schlechte Karten, unbekanntes Projekt, zweites Projekt, nächste Person, Verlängerung), Absagen an `/sync` mit Grund, Herkunft, Dienstweg (Schlüssel, Anlegen, Fehlerantworten, Löschen, Einfrieren, Widerruf einzeln und ganz, Sitzungsliste, 500) | | `test/sync.test.ts`, `test/database.ts` | — | neu (F5.1), seit F5.2 mit echter Anmeldung (Karte, Keks): echte Clients (Hocuspocus' Provider über WebSocket) gegen eine Wegwerf-Postgres in Docker: Wiederkehr nach Neustart, nie verdichtete Aktualisierungen nach hartem Halt, zwei Personen live, Verdichten (500, Ruhe, nichts ohne Änderung), Schließen mit Personen, die sofort wiederkommen, gelöschtes Projekt, doppeltes Anlegen, Hausmeister beim Laden und nach einer Zusammenführung, unbekanntes Projekt, Lesestufe, `/healthz`, Protokoll | | `src/simRooms.ts`, `src/simWorker.ts`, `test/sim.test.ts`, `test/blobs.test.ts` | Plan §6.4 | erweitert (10.10.2026): `restart` nur mit Schreibstufe, in einem eingefrorenen Projekt abgewiesen (`frozen`) wie `start`, im Log als `sim.restart`; ein Neustart wartet wie ein Start auf die Dateien, nach denen der Raum gefragt hat | ## tools/live Messen und Abnehmen an einem laufenden F (Standard `test-filius`), mit dessen Geheimnissen aus `/root/.filius-test.env`: `lib.ts` (Projekt über `/svc`, Beispiel über `/sync` hineingeschrieben, Anmelden mit Karte, Raum über `/sim`, jedes angelegte Projekt am Ende gelöscht), `m3.ts` (Räume in Stufen, Antwortzeit einer Sonde), `m4.ts` (Dokumentgröße, Aktualisierungen beim Ziehen), `acceptance.ts` (Abnahme F5 mit zwei Browsern), `clock.mjs` (Versatz von Fs Uhr) — neu (F5.6c). ## tools/ticket-oracle Schreibt Eintrittskarten mit itsdangerous 2.2.0 selbst (der Version des Dashboards) bei fester Uhr und hält fest, was itsdangerous beim Lesen antwortet: `packages/server/test/tickets.python.json`. ## tools/swift-oracle Baut den unveränderten Swift-Kern (Stand `3b5ded0`) unter Linux, nur zwei Ausdrücke sind für den Linux-Compiler aufgeteilt (`patches/`). Die Quellen selbst werden beim Bau geholt und nicht eingecheckt. ## deploy `Dockerfile`, `docker-compose.yml`, `test.env.example`, `production.env.example`, `proxy.conf`, dazu `.dockerignore` — neu (F5.6a/b): das Image von F (zwei Stufen, Node 24, ohne `node_modules`, nicht als root), ein Stack je Umgebung mit eigenem Namen, Volume, Image-Tag und Port (Test 8081, Produktion 8080) und der Eintrag für den externen OpenResty.