Ein Meilenstein ist erst vollständig, wenn sein ganzer Gate ausgeführt wurde.
Version 0.8.0 schafft eine veröffentlichte Beta als Grundlage. Die nächsten Entscheidungen betreffen die Erweiterung unterstützter Sprach-, Beweis-, Rust-, Entwicklungs- und Laufzeitprofile, jeweils mit ausführbarer Abnahme und gemessenen Ergebnissen.
entity Semaprax
status beta
snapshot 615e501
authority github.com/wavect/semaprax| Repository-Snapshot | 615e501 · 2026-10-06. Das Tag v0.8.0 verweist auf den festgehaltenen Quellcommit. Die exakte Tag-CI war erfolgreich. Daraus folgt keine allgemeine Produktions- oder Sicherheitsgarantie. |
|---|---|
| Status des Gesamtprodukts | 55 Teilweise · 0 Implementiert · 0 Fehlend |
| Graph- und Projektvertrag | Kanonischer Quellcode, stabile IDs und geprüfte Compiler-Repräsentationen verbinden Regeln, semantische Abfragen, Änderungen und Ausführung. Die je nach Feature gewählten Graph- und Project-Schemas behalten ihre eigenen Vorgaben für Zulassung, Kompatibilität und Host-Berechtigungen. |
| Veröffentlichte Betaversion | v0.8.0 · Veröffentlicht am 6. Oktober 2026 um 07:37 UTC. Alle 82 Jobs für den exakten Release-Tag waren erfolgreich. Veröffentlicht wurden drei Toolchain-Archive, SHA256SUMS, Attestierungen für jedes Archiv und eine signierte gemeinsame Herkunftsdokumentation. Der Release-Job prüfte den signierten Satz vor der Veröffentlichung unabhängig. Die Archive sind nicht notarisiert; reproduzierbare Builds werden nicht zugesichert. Eine Offline-Prüfung bestätigt keinen aktuellen Widerrufsstatus. Exakte Tag-CI. |
| Paket- und API-Vorschau | Die Veröffentlichung enthält nutzbare Profile für die Sprache, Quellcode-Regeln, Entwicklungswerkzeuge und Host-Integrationen. Für generierte Rust/npm-Pakete, öffentliche generische ABIs und weitere Plattformen gelten weiterhin eigene Entscheidungen über Veröffentlichung und Unterstützung. |
Die zugesagten Eigenschaften von Quellcode und Archiven erhalten, Regel- und Rust-Profile erweitern, Werkzeugänderungen anhand echter Aufgabenqualität und Kosten qualifizieren und geprüftes Neuladen sowie Agent-Wiederherstellung auf mehr Hosts bringen. Öffentliche generische ABIs, Paketveröffentlichung und eine gepflegte Anwendungsplattform bleiben getrennte Meilensteine. Der maximale Katalognormalisierungsfall hat seine begrenzte Anwendungsprüfung über Interpreter, native Ausführung und Core Wasm bestanden. Er ist kein bislang unausgeführtes Ziel mehr. Ein Veröffentlichungstermin für v1.0 ist nicht angekündigt.
Quellcode-Identität, deterministische Prüfungen, Archivherkunft und Fehlerpfade während der Weiterentwicklung erhalten. Regelabdeckung und geschützte Reparaturen von Funktionskörpern mit aktuellen Beweis-, Quellcode- und Zielnachweisen erweitern. Eine frühere erfolgreiche Veröffentlichung validiert keine spätere Änderung.
Ausgewählte Rust-APIs, Callback-Captures und Future-Kompositionen erweitern und dabei jede Annahme über Fremdcode und jedes Ziel festhalten. Veröffentlichung und unterstützte Kompatibilität generierter Rust/npm-Pakete sowie öffentlicher generischer Schnittstellen gesondert entscheiden. PG-9 bleibt nicht unterstützt und unveröffentlicht.
Auf vorhandenen Records, Generics, Collections, unveränderlichen Listen, Ownership und begrenzten Closures aufbauen. Kompositionen von Lebensdauern und Nutzdaten gezielt erweitern und realistische Programme an Ressourcengrenzen und Backend-Verhalten messen.
Checkpoint-Wiederherstellung, Behandlung fehlgeschlagener Vorgänge und optionale Ausführungsziele für Stufen erweitern. Geprüften Hot Reload auf weitere Hosts bringen und Suche, Skills und Routing der Entwicklungswerkzeuge anhand akzeptierter Aufgaben und Kosten qualifizieren. Die dokumentierte kostenpflichtige Kampagne qualifizierte keine neue Standardeinstellung.
Host-Plattformen, Browser-Engines, Geräte und Paketökosysteme mit eigenen wiederholbaren Zusagen für Konformität, Lebenszyklus und Pflege ergänzen. Eine vollständige Anwendungsplattform und das abschließende Validierungsprodukt für 1.0 bleiben umfassendere Arbeiten. Daraus ergibt sich kein Liefertermin.
Drei Toolchain-Archive sind veröffentlicht, begrenzte Browser-/Mobile-/Desktop-Profile existieren. Eine vollständig unterstützte Anwendungsplattform über Browser, physische Geräte, Betriebssysteme und Installationsabläufe bleibt eine umfassendere Produktanforderung.
GitHub-RepositoryAllgemeine ownership-sichere Fremdschnittstellen, stabile Aggregate-/Ressourcen-/Component-/Generic-ABIs, gepflegte Paketveröffentlichung und breite Host-Sprachkompatibilität bleiben offen. Metadaten, generierter Code und private Host-Fixtures erfüllen diese Anforderung nicht.
GitHub-RepositoryGeprüft anhand des Tags v0.8.0 und seines festgehaltenen Quellcommits. Versionierte Spezifikationen definieren Zulassung und Befugnisse; ältere Release-Überschriften in Matrix und Roadmap sind historisch. GitHub-Repository.
Das Online-Handbuch ist die englische Anleitung aus main und kann Änderungen nach 0.8.0 behandeln. Nutze den fixierten Snapshot, um diese Veröffentlichung nachzuvollziehen.
Der aktuelle englische Lernpfad, veröffentlicht aus main.
Die Handbuchdateien am exakt geprüften Release-Commit.
Aktuelle englische Anleitung zu Rechner-Manifest, Prüfungen, Tests und Builds.
Aktuelle englische Einführung in Werte, Funktionen und Quellcodestruktur.
Aktuelle englische Anleitung zu semantischem Kontext und sicheren Änderungsabläufen.
Fixierte Befehlsformen und die Abgrenzung zwischen eigenständiger CLI und vollständiger Toolchain.
Fixierte Einrichtung, semantische Navigation, Review und Entwicklungssteuerung.
Fixierte Beispiele für Sprache, Projekte, Regeln, Agents und Host-Integrationen.
Geprüft anhand des Tags v0.8.0 und seines festgehaltenen Quellcommits. Versionierte Spezifikationen definieren Zulassung und Befugnisse; ältere Release-Überschriften in Matrix und Roadmap sind historisch.
Ein Termin für v1.0 ist nicht angekündigt. Version 0.8.0 wurde am 6. Oktober 2026 veröffentlicht. Die Roadmap beschreibt Arbeitsbereiche und Abnahmeprüfungen. Ältere nummerierte Überschriften sind keine verlässliche Liste noch ausstehender Releases.
Eine begrenzte Implementierung muss ihren maßgeblichen Vertrag sowie Erfolgs- und Fehlerprüfungen erfüllen. Breitere Unterstützung benötigt zusätzlich die benannten Hosts, Schnittstellen und den Pflegeumfang. Paketveröffentlichung und Änderungen der Werkzeugstandards sind getrennte Entscheidungen mit eigenen Release- beziehungsweise Qualitäts- und Kostennachweisen.