Warum Agenten-Edits semantische Identität brauchen: SEMAPRAX in Rust

Ein Coding-Agent sollte eine Deklaration über ihre Identität und erwartete Bedeutung bearbeiten, nicht über eine womöglich veraltete Zeilennummer. In SEMAPRAX überleben persistente Deklarations-IDs gewöhnliche Quelltextverschiebungen, geprüfte HIR bündelt aufgelöste Bedeutung und revisionsgebundene Patches brechen geschlossen ab, wenn sich ihr Quellsnapshot geändert hat. Rust bildet diese Unterschiede explizit im Typsystem des Compilers ab.

Dieser Artikel erklärt das Design des Pre-Alpha-Forschungscompilers. Die Grenzen sind auch für Refactoring-Engines, Compiler-Services und Agentenwerkzeuge nützlich, die eine Absicht in eine überprüfbare Änderung übersetzen.

Warum sind Zeilen und Byte-Offsets schlechte Ziele?

Ein Text-Edit sagt meist „ersetze Bytes 418 bis 463“. Diese Adresse beschreibt einen Dateisnapshot, nicht die gemeinte Programmeinheit. Formatter, Kommentare oder parallele Edits verschieben sie. Namen helfen, bleiben wegen Scopes, Overloads und Umbenennungen aber kontextabhängig.

Der SEMAPRAX-Vertrag behandelt menschenlesbaren .spx-Quelltext als kanonische Git-Projektion und stellt einen versionierten semantischen Graphen als bevorzugtes Agenteninterface bereit. Öffentliche Deklarationen tragen persistente @id-Identitäten. Ausdrucksidentitäten sind revisionsgebunden, weil eine dauerhafte Identität jedes temporären Syntaxknotens ein zu starkes Versprechen wäre. Der Sprach- und Compilervertrag spezifiziert diese Trennung.

Wie bildet Rust die Identitätsgrenze ab?

Die HIR reicht nicht überall rohe Strings weiter. Sie definiert getrennte Newtypes:

pub struct DeclarationId(String);
pub struct ExpressionId(String);

pub struct ResolvedFunction {
    pub id: DeclarationId,
    // geprüfte Signatur, Body und Effekte
}

Das gekürzte Beispiel entspricht den Typen in src/hir.rs in der geprüften Revision. Eine Funktion, die ein persistentes Deklarationsziel erwartet, kann nicht versehentlich eine Ausdrucksadresse erhalten. Der Compiler verlangt eine explizite Umwandlung oder lehnt die Operation ab.

Dasselbe Modul speichert Deklarationsindizes in BTreeMap und Relationsmengen in BTreeSet. Geordnete Collections garantieren noch keine Deterministik, verhindern aber zufällige Hash-Iterationsreihenfolgen. Wo Reihenfolge Ausführung beeinflusst, muss die semantische Ordnung erhalten bleiben.

Warum einmal in geprüfte HIR auflösen?

Wenn Graph-Exporter, natives Backend und Wasm-Backend Bedeutung jeweils aus Syntax rekonstruieren, können sie Typen, Ownership oder Aufrufziele unterschiedlich interpretieren. SEMAPRAX löst zuerst auf und prüft, danach konsumieren Projektionen die geprüfte Repräsentation. Das veröffentlichte Architektur- und Trust-Boundary-Dokument beschreibt diese Pipeline und trennt implementierte Pfade von zukünftiger Authority.

1. Menschenlesbaren Quelltext parsen.
2. Namen und persistente Identitäten in HIR auflösen.
3. Die vom aktuellen Sprachsubset zugelassenen Typen, Effekte, Ownership-Regeln und Verträge prüfen.
4. Deterministisches Graph-JSON oder Zielartefakte aus geprüfter Semantik erzeugen.
5. Änderungen an Quellrevision und erwartetes semantisches Ziel binden.

Der Graph ist eine Compilerprojektion, keine zweite Source of Truth. Git überprüft weiterhin Quelltext, während der Agent strukturierten Kontext erhält.

Was macht einen semantischen Graphen deterministisch?

Determinismus ist eine Eigenschaft der ganzen Pipeline. Stabile Knoten-IDs helfen nicht, wenn Kanten bei jedem Lauf anders sortiert sind. SEMAPRAX nutzt in seiner Rust-Graphprojektion geordnete Indizes, explizite Serialisierung, begrenzte Traversierung und kanonische Ausgaberegeln.

Ausführungsvektoren dürfen nicht für schöneres JSON nachträglich sortiert werden. Auswertungs- und Cleanup-Reihenfolge sind semantisch. Kanonisches Sortieren gehört nur auf mathematisch ungeordnete Mengen.

Wie kann Evidenz einen Agenten-Patch begrenzen?

Eine Evidenzkapsel soll erklären, warum ein Patch zulässig ist, aber ihr Besitz darf keine Schreibberechtigung erteilen. SEMAPRAX trennt Beweisdaten von der Komponente mit Commit-Authority. Der Patch-Pfad nimmt den normalen Lock, spielt die exakte begrenzte Evidenz unabhängig nach, prüft den aktuellen Snapshot und staged erst dann den Kandidaten. Die Patch-Evidenz-Implementierung hält Replay und Anwendung sichtbar getrennt.

• Veraltete Absicht: Der Patch galt für eine ältere Revision.
• Falsches Ziel: Der Text passt noch, bezeichnet aber eine andere Deklaration.
• Vorgetäuschte Sicherheit: Ein plausibler Report wird präsentiert, ohne Checks zu reproduzieren.

Unabhängiges Replay beweist nicht, dass ein Feature klug ist. Es belegt enger, dass der begrenzte Vorschlag weiterhin die gebundenen Compilerprüfungen erfüllt.

Welche Muster sollten Rust-Compiler übernehmen?

1. Domain-Newtypes: Persistente Entitäten, revisionslokale Knoten, Digests und Capabilities typseitig trennen.
2. Ein geprüfter semantischer Kern: Graphen und Backends sollen aufgelöste Bedeutung konsumieren.
3. Expliziter Determinismus: Ordnung, Serialisierung, Diagnostik und Fehlerverhalten spezifizieren und Byte für Byte testen.
4. Snapshot-Bindung: Ein semantisches Ziel ohne Quelldigest kann driften.
5. Machtlose Evidenz: Evidenz innerhalb der Authority-Grenze vor jedem Staging nachspielen.
6. Grenzen veröffentlichen: Eine Completion Matrix verhindert, dass Evidenz für einen Pfad als Beleg für alle Ziele gilt.

SEMAPRAX setzt den letzten Punkt mit einer evidenzgebundenen Completion Matrix um.

Was beweist SEMAPRAX noch nicht?

SEMAPRAX v0.2 ist experimentelle Pre-Alpha-Forschung. Das Repository dokumentiert begrenzte Native-C11/Clang- und WebAssembly-Core-Pfade, deterministische Semantikwerkzeuge und ein wachsendes geprüftes Subset. Es behauptet weder Produktionsreife noch vollständige Memory Safety, alle Betriebssysteme, ein vollständiges Ownership-System, volle Ökosystem-Interoperabilität, eine öffentliche Component-Model-Runtime oder reale ökonomische Authority.

Bewerte das Projekt anhand von Quelltext und datierter Evidenz. Beginne mit dem SEMAPRAX-Architekturüberblick und vergleiche die Aussagen mit der fixierten Revision.

Wie lässt sich der Walkthrough reproduzieren?

git clone https://github.com/wavect/semaprax.git
cd semaprax
git checkout ca339feffcadf77a679abe2f159376287cf2e22c
cargo run -- graph examples/hello.spx

Der Befehl untersucht die Graphprojektion der exakt für diesen Artikel verwendeten Revision. Lokale Änderungen zählen erst nach den dokumentierten Quality Gates als Evidenz.

Redaktioneller Hinweis: OpenAI Codex unterstützte Entwurf und Übersetzung. Wavect prüfte technische Aussagen und Codeverweise gegen SEMAPRAX-Commit ca339fe. Der Artikel leitet keine Performance- oder Sicherheitsbehauptung aus Modellausgaben ab.