2027a/auroscope

Watch

Fork 0

[Decision D10] Fixer les contrats du scanner déterministe et du LLM #11

New issue

Closed

opened 2026-08-30 20:42:57 +00:00 by hephaistos · 7 comments

hephaistos commented

2026-08-30 20:42:57 +00:00

Owner

MODE: DECISION

Statut

Proposé. Ticket ouvert jusqu’au go explicite après ta décision.

Question

Comment séparer strictement faits déterministes, analyse LLM et décision humaine ?

Scanner proposé

Findings immuables et versionnés : rule_id, version, sévérité, chemin, ligne/byte range, preuve et digest. L’agrégat de signal est séparé. Catalogue v1 : intégrité de collecte, download→shell, obfuscation, runtime network, checksums/signatures, privilèges/persistance, accès secrets, sémantique provides/conflicts/replaces, caractères de contrôle.

Limites de contexte proposées

256 KiB/fichier, 2 MiB texte total, 512 KiB diff, 200 fichiers — valeurs à benchmarker. Toute troncature/omission pertinente donne partial et pause humaine, jamais clear silencieux.

LLM proposé

Adaptateur HTTP d’inférence seulement, sans outils/shell/fs/browser/plugins. Données JSON explicitement hostiles, chemins hôte/secrets retirés. Réponse strictement bornée : niveau consultatif, résumé, explications, points d’attention, incertitudes. Aucun champ approve/allow/deny. Validation locale des chemins/lignes/enums/champs.

Échec

Timeout, transport, refus ou schéma invalide → statut LLM failed, signal unknown, pause humaine. L’humain peut approuver en connaissance de cause; le modèle ne supprime/modifie jamais un finding déterministe.

Options

SDK/CLI agent : plus riche, mais surface/outils/credentials trop larges.
HTTP étroit : recommandé.
LLM désactivé : supporté, sans prétendre avoir une preuve modèle.

Vie privée

Secrets par nom de variable seulement; prompts/réponses 0600, rétention configurable ou désactivée; hashes/métadonnées bornées.

Réponse attendue

Accepte/amende les contrats, limites ou comportement d’échec. ADR/clôture seulement après ton go.

Documentation

https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md

Protocole automatique de décision

Ce ticket reste en discussion et n’autorise aucune implémentation.
Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket.
Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement :

GO DECISION

Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket.
GO DECISION n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket MODE: EXECUTION.

MODE: DECISION ## Statut **Proposé.** Ticket ouvert jusqu’au **go explicite** après ta décision. ## Question Comment séparer strictement faits déterministes, analyse LLM et décision humaine ? ## Scanner proposé Findings immuables et versionnés : `rule_id`, version, sévérité, chemin, ligne/byte range, preuve et digest. L’agrégat de signal est séparé. Catalogue v1 : intégrité de collecte, download→shell, obfuscation, runtime network, checksums/signatures, privilèges/persistance, accès secrets, sémantique `provides/conflicts/replaces`, caractères de contrôle. ## Limites de contexte proposées 256 KiB/fichier, 2 MiB texte total, 512 KiB diff, 200 fichiers — valeurs à benchmarker. Toute troncature/omission pertinente donne `partial` et pause humaine, jamais `clear` silencieux. ## LLM proposé Adaptateur HTTP d’inférence seulement, sans outils/shell/fs/browser/plugins. Données JSON explicitement hostiles, chemins hôte/secrets retirés. Réponse strictement bornée : niveau consultatif, résumé, explications, points d’attention, incertitudes. **Aucun champ approve/allow/deny.** Validation locale des chemins/lignes/enums/champs. ## Échec Timeout, transport, refus ou schéma invalide → statut LLM failed, signal unknown, pause humaine. L’humain peut approuver en connaissance de cause; le modèle ne supprime/modifie jamais un finding déterministe. ## Options - SDK/CLI agent : plus riche, mais surface/outils/credentials trop larges. - HTTP étroit : recommandé. - LLM désactivé : supporté, sans prétendre avoir une preuve modèle. ## Vie privée Secrets par nom de variable seulement; prompts/réponses `0600`, rétention configurable ou désactivée; hashes/métadonnées bornées. ## Réponse attendue Accepte/amende les contrats, limites ou comportement d’échec. ADR/clôture seulement après ton **go**. ## Documentation - https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md ## Protocole automatique de décision - Ce ticket reste en discussion et n’autorise aucune implémentation. - Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket. - Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement : ```text GO DECISION ``` - Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket. - `GO DECISION` n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket `MODE: EXECUTION`.

hephaistos added the

labels

2026-08-30 20:45:48 +00:00

mathieu commented

2026-08-30 21:39:06 +00:00

Owner

Ok pour l'essentiel, mais pour connecter à un llm, on essaie en priorité d'utiliser codex (cli) sur la machine avec le modèle 5.6-luna, si codex est installé mais pas connecté, on affiche une erreur (se connecter ou fallback API key), et si une clef d'Api, un point d'accès (openai, openrouter, URL OpenAI compatible pour ollama... pour commencer) et un modèle sont configurés, on les utilise en priorité

hephaistos commented

2026-08-30 23:19:38 +00:00

Author

Owner

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement GO DECISION dans un commentaire distinct.

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement `GO DECISION` dans un commentaire distinct.

hephaistos commented

2026-08-30 23:24:00 +00:00

Author

Owner

D’accord pour amender le contrat LLM dans ce sens. Il faut toutefois rendre la priorité non ambiguë et conserver l’isolation du scanner.

Je recommande l’ordre suivant :

Configuration API explicite et complète (provider/endpoint, clé API, modèle) : elle gagne, car c’est un choix volontaire de l’opérateur. Adaptateurs v1 : OpenAI, OpenRouter et endpoint OpenAI-compatible personnalisé (dont Ollama).
Sinon, Codex CLI s’il est installé : invocation non interactive avec le modèle exact 5.6-luna.
Codex installé mais non connecté : échec explicite, avec deux remèdes indiqués — se connecter à Codex ou configurer le backend API complet. Aucun basculement silencieux et aucune tentative avec un modèle différent.
Ni backend API complet ni Codex utilisable : analyse LLM disabled/failed, signal unknown, puis pause humaine conformément au contrat initial.

Le point important est que Codex devient un adaptateur d’inférence borné, pas un agent général : entrée JSON hostile sur stdin, sortie conforme au schéma strict, répertoire de travail stérile, environnement réduit aux credentials indispensables, aucun accès au dépôt, aux secrets ou aux chemins hôte. Si le mode Codex disponible ne permet pas de garantir l’absence d’outils/shell/fs/browser/plugins, l’adaptateur doit échouer fermé plutôt que relâcher cette séparation. Les findings déterministes restent immuables et le LLM ne reçoit toujours aucun champ d’approbation.

Comparaison : l’API HTTP reste la voie la plus simple à isoler et la plus portable; Codex CLI offre le défaut local souhaité et réutilise sa connexion, mais ajoute une dépendance d’exécutable, d’authentification et de sandbox qu’il faut diagnostiquer séparément.

Recommandation actuelle : adopter ce double adaptateur avec priorité à la configuration API explicite, puis Codex CLI 5.6-luna par défaut en son absence, et des échecs visibles sans fallback implicite. Cela amende la proposition; ce commentaire ne vaut pas acceptation de la décision.

D’accord pour amender le contrat LLM dans ce sens. Il faut toutefois rendre la priorité non ambiguë et conserver l’isolation du scanner. Je recommande l’ordre suivant : 1. **Configuration API explicite et complète** (`provider`/endpoint, clé API, modèle) : elle gagne, car c’est un choix volontaire de l’opérateur. Adaptateurs v1 : OpenAI, OpenRouter et endpoint OpenAI-compatible personnalisé (dont Ollama). 2. **Sinon, Codex CLI** s’il est installé : invocation non interactive avec le modèle exact `5.6-luna`. 3. **Codex installé mais non connecté** : échec explicite, avec deux remèdes indiqués — se connecter à Codex ou configurer le backend API complet. Aucun basculement silencieux et aucune tentative avec un modèle différent. 4. **Ni backend API complet ni Codex utilisable** : analyse LLM `disabled`/`failed`, signal `unknown`, puis pause humaine conformément au contrat initial. Le point important est que Codex devient un **adaptateur d’inférence borné**, pas un agent général : entrée JSON hostile sur stdin, sortie conforme au schéma strict, répertoire de travail stérile, environnement réduit aux credentials indispensables, aucun accès au dépôt, aux secrets ou aux chemins hôte. Si le mode Codex disponible ne permet pas de garantir l’absence d’outils/shell/fs/browser/plugins, l’adaptateur doit échouer fermé plutôt que relâcher cette séparation. Les findings déterministes restent immuables et le LLM ne reçoit toujours aucun champ d’approbation. Comparaison : l’API HTTP reste la voie la plus simple à isoler et la plus portable; Codex CLI offre le défaut local souhaité et réutilise sa connexion, mais ajoute une dépendance d’exécutable, d’authentification et de sandbox qu’il faut diagnostiquer séparément. **Recommandation actuelle :** adopter ce double adaptateur avec priorité à la configuration API explicite, puis Codex CLI `5.6-luna` par défaut en son absence, et des échecs visibles sans fallback implicite. Cela amende la proposition; ce commentaire ne vaut pas acceptation de la décision.

mathieu commented

2026-08-30 23:38:42 +00:00

Owner

Ok dans les grandes lignes, mais avec les nuances suivantes:

on doit pouvons configurer le modèle codex dans la config (si on indique pas de point d'accès/clef, ou si on configure explicitement pour codex)
pas besoin d'être aussi stricte sur les outils de codex etc. on a pas besoin de garantie aussi stricte.

Ok dans les grandes lignes, mais avec les nuances suivantes: - on doit pouvons configurer le modèle codex dans la config (si on indique pas de point d'accès/clef, ou si on configure explicitement pour codex) - pas besoin d'être aussi stricte sur les outils de codex etc. on a pas besoin de garantie aussi stricte.

hephaistos commented

2026-08-30 23:47:04 +00:00

Author

Owner

Oui, ces deux nuances rendent le contrat plus pragmatique.

Je propose de fixer la sélection ainsi :

Un backend explicitement configuré gagne toujours. codex peut donc être choisi explicitement même si une configuration API existe.
En mode automatique, une configuration API complète (endpoint/provider, clé et modèle) est utilisée en priorité.
Sans configuration API complète, utiliser Codex CLI s’il est installé et connecté.
Le modèle Codex est configurable; 5.6-luna est seulement la valeur par défaut si aucun modèle Codex n’est indiqué.
Codex installé mais non connecté, backend explicite incomplet, timeout, transport ou sortie invalide : erreur visible avec remède, signal LLM unknown et pause humaine; aucun changement silencieux de backend ou de modèle.

Pour les outils Codex, je retire l’exigence de garantie absolue « aucun outil/shell/fs ». Elle serait coûteuse et probablement artificielle pour un CLI agentique. Le contrat utile est plutôt une réduction raisonnable de l’exposition : lancer Codex hors du dépôt, dans un répertoire temporaire contenant uniquement l’entrée bornée et expurgée nécessaire, ne lui transmettre aucun secret métier ni chemin hôte inutile, et considérer toute sa sortie comme non fiable jusqu’à validation locale du schéma et des références. On ne bloque donc pas l’adaptateur si Codex conserve ses capacités normales, mais on ne lui donne volontairement rien dont il n’a pas besoin.

L’adaptateur HTTP reste naturellement plus étroit. Dans les deux cas, l’analyse demeure consultative : elle ne peut ni modifier/supprimer un finding déterministe, ni approuver, ni déclencher une action.

Recommandation actuelle : backend configurable avec modes explicites (codex, API prise en charge, disabled) et mode automatique « API complète, sinon Codex »; modèle Codex configurable avec défaut 5.6-luna; isolation en meilleur effort plutôt qu’en garantie stricte; sortie LLM non fiable, bornée et validée localement; échec visible et pause humaine sans fallback implicite. Cela reste une proposition de discussion, pas une acceptation de la décision.

Oui, ces deux nuances rendent le contrat plus pragmatique. Je propose de fixer la sélection ainsi : 1. Un backend explicitement configuré gagne toujours. `codex` peut donc être choisi explicitement même si une configuration API existe. 2. En mode automatique, une configuration API complète (endpoint/provider, clé et modèle) est utilisée en priorité. 3. Sans configuration API complète, utiliser Codex CLI s’il est installé et connecté. 4. Le modèle Codex est configurable; `5.6-luna` est seulement la valeur par défaut si aucun modèle Codex n’est indiqué. 5. Codex installé mais non connecté, backend explicite incomplet, timeout, transport ou sortie invalide : erreur visible avec remède, signal LLM `unknown` et pause humaine; aucun changement silencieux de backend ou de modèle. Pour les outils Codex, je retire l’exigence de garantie absolue « aucun outil/shell/fs ». Elle serait coûteuse et probablement artificielle pour un CLI agentique. Le contrat utile est plutôt une réduction raisonnable de l’exposition : lancer Codex hors du dépôt, dans un répertoire temporaire contenant uniquement l’entrée bornée et expurgée nécessaire, ne lui transmettre aucun secret métier ni chemin hôte inutile, et considérer toute sa sortie comme non fiable jusqu’à validation locale du schéma et des références. On ne bloque donc pas l’adaptateur si Codex conserve ses capacités normales, mais on ne lui donne volontairement rien dont il n’a pas besoin. L’adaptateur HTTP reste naturellement plus étroit. Dans les deux cas, l’analyse demeure consultative : elle ne peut ni modifier/supprimer un finding déterministe, ni approuver, ni déclencher une action. **Recommandation actuelle :** backend configurable avec modes explicites (`codex`, API prise en charge, `disabled`) et mode automatique « API complète, sinon Codex »; modèle Codex configurable avec défaut `5.6-luna`; isolation en meilleur effort plutôt qu’en garantie stricte; sortie LLM non fiable, bornée et validée localement; échec visible et pause humaine sans fallback implicite. Cela reste une proposition de discussion, pas une acceptation de la décision.

mathieu commented

2026-08-30 23:52:23 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

2026-08-31 00:26:13 +00:00

hephaistos commented

2026-08-31 00:33:47 +00:00

Author

Owner

Décision D10 consignée dans ADR-0011. Le commit signé f971bb6469e09b4fc414b264db81e8a33e13d314 met aussi la spécification, le mandat et le registre de design en cohérence. La branche design/technical-contracts et la PR #1 pointent sur ce commit vérifié. Aucun code de production ni plan d’implémentation n’a été créé.

Décision D10 consignée dans [ADR-0011](https://git.2027a.net/2027a/auroscope/src/commit/f971bb6469e09b4fc414b264db81e8a33e13d314/docs/decisions/0011-deterministic-scanner-and-llm-contracts.md). Le commit signé `f971bb6469e09b4fc414b264db81e8a33e13d314` met aussi la spécification, le mandat et le registre de design en cohérence. La branche `design/technical-contracts` et la [PR #1](https://git.2027a.net/2027a/auroscope/pulls/1) pointent sur ce commit vérifié. Aucun code de production ni plan d’implémentation n’a été créé.

hephaistos closed this issue

2026-08-31 00:34:01 +00:00