Périmètre

Ce qu’est la v1, ce qui a été retiré du précédent plan de couche d’exécution, et pourquoi.

Runic n’a pas toujours été un cache. Les premiers plans (archivés sous _deprecated/ dans le dépôt, ainsi que dans ALPHA.md/ROADMAP.md pour le contexte historique) décrivaient un runtime d’exécution : intercepter les appels d’outils, appliquer les autorisations, isoler l’accès au système de fichiers/réseau et contrôler un budget strict. Cette page explique pourquoi ce plan a été retiré, et non étendu.

Inclus dans le périmètre de la v1

• Mettre en cache le résultat d’une décision, indexé par une signature normalisée à correspondance exacte — { intent, params }, jamais le texte brut de la tâche, jamais une trace de raisonnement.
• Journaliser les tokens dépensés (signalés par l’agent) par rapport aux tokens économisés lors d’un accès au cache.
• Périmètre par session. Le partage entre sessions/agents constitue une phase ultérieure, une fois qu’il sera prouvé que la réutilisation par session compte en pratique.

Explicitement hors périmètre

• Exécution de toute sorte. Runic n’appelle jamais de capacité, ne déploie rien et n’exécute aucun code. L’ancien packages/runtime est abandonné.
• Autorisations ou isolation. Il n’y a rien à vérifier si rien ne s’exécute. Les anciens packages/permissions et packages/sandbox sont abandonnés.
• Correspondance sémantique ou approximative des tâches. Ceci est volontairement restreint — correspondance exacte uniquement. C’est une contrainte de conception destinée à le rester, et non un raccourci de v1 à élargir plus tard sans rouvrir la question de savoir si un accès au cache correspond réellement à la même décision.

Pourquoi il s’agit d’un pivot, et non d’un ajout

La plus grande partie de l’ancien plan de couche d’exécution — application des autorisations, isolation, exécution de capacités — s’est révélée dupliquer ce que MCP standardise déjà pour les appels d’outils. Construire un système parallèle d’autorisations/exécution par-dessus n’est pas, à lui seul, un créneau défendable ; c’est une infrastructure redondante qui concurrence une norme déjà existante.

L’idée de cache et de registre a survécu à cette suppression parce qu’elle répond à une question à laquelle MCP ne répond pas : cette décision exacte a-t-elle déjà été résolue, et quel en a été le coût ? C’est une promesse plus étroite et plus honnête que « Runic gère l’exécution de votre agent » — et c’est celle que ce dépôt tient réellement, avec de vrais chiffres de benchmark à l’appui plutôt qu’un diagramme d’architecture.

Si vous cherchez le plan de couche d’exécution

Il est conservé pour l’historique dans ALPHA.md et ROADMAP.md à la racine du dépôt, et le code lui-même est archivé sous _deprecated/. Aucun des deux n’est maintenu, et aucun ne reflète ce que Runic livre aujourd’hui — lisez Introduction pour cela.