Blomios
5955ea37a2
Met à jour les carnets/issues existants et ajoute les tickets #108, #109, #111, #112 créés durant le cycle. État runtime sans rapport avec le lot de code #82, isolé dans son propre commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1.7 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||
|---|---|---|---|---|---|
| #96 | 4 |
|
1785271075243 |
Décision (2026-07-24) : différée — documentée, non codée
Sur instruction utilisateur (#96 mis en pause pour se concentrer sur #95) : on documente le constat et la décision de fond reste ouverte pour plus tard. Aucun code ajouté.
Constat confirmé dans les sources
crates/infrastructure/src/assistant/mod.rs::TicketAssistantEnvironmentPreparer::materialise_mcp passe eff: None à opencode_config_json / opencode_provider_config_json (lignes ~253 et ~262). Le commentaire local (l. 246-251) le documente déjà : aucun PermissionStore/EffectivePermissions n'est résolu sur ce chemin, pour aucun adaptateur. Conséquence : les assistants de ticket tournent toujours avec le comportement natif d'OpenCode (prompting à chaque action), indépendamment des permissions IdeA configurées.
Pourquoi c'est différé (la vraie question produit)
Les assistants de ticket sont lancés depuis un profil (pas depuis un agent avec une politique par-agent). Il n'y a donc pas de source naturelle d'EffectivePermissions sur ce chemin. Câbler nécessite d'abord de trancher : les permissions viennent-elles du profil ? d'un fallback projet ? d'une posture dédiée aux assistants ? Tant que ce choix produit n'est pas posé, eff: None (= prompting natif) reste le défaut sûr — ce n'est pas une régression, c'est le comportement historique préservé.
Suivi
Non bloquant, priorité basse. À reprendre quand un besoin produit le justifie : définir la source d'autorités pour un assistant de ticket, puis la résoudre ici (comme pour les agents normaux dans application::agent::lifecycle).