Geltungsbereich

Was v1 ist, was aus dem früheren Plan für die Ausführungsebene gestrichen wurde und warum.

Runic war nicht immer ein Cache. Frühere Pläne (im Repository unter _deprecated/ archiviert sowie in ALPHA.md/ROADMAP.md als historischer Kontext) beschrieben eine Ausführungsumgebung: Tool-Aufrufe abfangen, Berechtigungen durchsetzen, Dateisystem-/Netzwerkzugriff sandboxen und ein festes Budget messen. Diese Seite erklärt, warum dieser Plan gestrichen und nicht erweitert wurde.

Im Umfang von v1

• Das Caching des Ergebnisses einer Entscheidung, basierend auf einer normalisierten Signatur mit exakter Übereinstimmung — { intent, params }, niemals roher Aufgabentext, niemals ein Reasoning-Trace.
• Das Protokollieren ausgegebener Tokens (vom Agenten gemeldet) im Vergleich zu bei einem Cache-Treffer eingesparten Tokens.
• Geltungsbereich pro Sitzung. Sitzungsübergreifendes bzw. agentenübergreifendes Teilen ist eine spätere Phase, sobald sich zeigt, dass Wiederverwendung pro Sitzung in der Praxis relevant ist.

Ausdrücklich nicht im Umfang

• Ausführung jeglicher Art. Runic ruft niemals eine Fähigkeit auf, stellt nichts bereit und führt keinen Code aus. Das alte packages/runtime ist tot.
• Berechtigungen oder Sandboxing. Es gibt nichts zu prüfen, wenn nichts ausgeführt wird. Die alten packages/permissions und packages/sandbox sind tot.
• Semantisches oder unscharfes Aufgaben-Matching. Das ist bewusst eng gefasst — nur exakte Übereinstimmung. Es ist eine Entwurfsbeschränkung, die eine Beschränkung bleiben soll, und keine v1-Abkürzung, die später ausgeweitet wird, ohne die Frage erneut zu stellen, ob ein Cache-Treffer tatsächlich dieselbe Entscheidung ist.

Warum dies ein Kurswechsel und keine Ergänzung ist

Der Großteil des alten Plans für die Ausführungsebene — Berechtigungsdurchsetzung, Sandboxing, Fähigkeitenausführung — erwies sich als Duplizierung dessen, was MCP bereits für Tool-Aufrufe standardisiert. Ein paralleles Berechtigungs-/Ausführungssystem darüber zu bauen, ist für sich genommen kein vertretbarer Ansatz; es ist redundante Infrastruktur, die mit einem bereits bestehenden Standard konkurriert.

Die Idee eines Caches mit Ledger überstand die Streichung, weil sie eine Frage beantwortet, die MCP nicht beantwortet: Wurde diese exakte Entscheidung bereits getroffen, und was hat sie gekostet? Das ist eine engere, ehrlichere Aussage als „Runic verwaltet die Ausführung deines Agenten“ — und sie ist es, die dieses Repository tatsächlich liefert, mit echten Benchmark-Zahlen als Beleg statt mit einem Architekturdiagramm.

Wenn du nach dem Plan für die Ausführungsebene suchst

Er ist zur historischen Dokumentation in ALPHA.md und ROADMAP.md im Stammverzeichnis des Repositorys erhalten, und der Code selbst ist unter _deprecated/ archiviert. Keines von beiden wird gepflegt, und keines spiegelt wider, was Runic heute ausliefert — lies dafür Einführung.