---
title: Périmètre
description: >-
  Ce qu’est la v1, ce qui a été retiré du précédent plan de couche d’exécution,
  et pourquoi.
sidebar:
  order: 8
---
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.