Ajouter le package sidekick - #12
Draft
JoeyBG wants to merge 1 commit into
Draft
Conversation
Équipe multi-modèles pour OpenCode basée sur le patron « sidekick » de
Devin Fusion : un agent principal qui planifie et révise mais dont
l'édition de fichiers est refusée au niveau de la couche de permissions,
déléguant chaque changement à un sidekick moins cher.
Adapté de mihneaptu/opencode-fusion (MIT) avec quatre écarts :
- Aucun `model:` dans les frontmatter — le routage appartient au
opencode.json de chaque personne, qui est justement ce que chacun veut
ajuster. Le frontmatter écraserait la config en silence.
- Plugins retirés. `fusion-audit` est couvert par `opencode stats
--models/--tools` (et l'attribution par agent découle du routage par
rôle). `fusion-claude` est écarté : dépendance externe par poste et APM
ne distribue pas les plugins OpenCode.
- `plan` allégé — référence `build` au lieu de redupliquer sa discipline.
Sa posture de permissions est un sous-ensemble strict de celle de build.
- Trappe de sortie `normal` distribuée. Sans elle, le `plan` natif
d'OpenCode survivrait avec `edit: ask` et contournerait le patron par
accident.
L'allowlist bash couvre pnpm, npm, make et mix pour les stacks Mirego.
Installation au scope utilisateur, pas par projet :
apm install -g mirego/agentic/sidekick --target opencode
Requiert OpenCode >= 1.18 : `subagent_depth` n'existe pas avant et 1.17
rejette le fichier de config au complet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexte
Équipe multi-modèles pour OpenCode basée sur le patron « sidekick » de Devin Fusion : un agent principal qui planifie, décide et révise, mais dont l'édition de fichiers est refusée au niveau de la couche de permissions. Son seul chemin vers le disque est de remettre une spec à un sidekick moins cher. L'intelligence coûteuse reste sur le jugement, un modèle bon marché fait le mécanique.
Adapté de mihneaptu/opencode-fusion (MIT), packagé pour APM.
Installation au scope utilisateur — c'est une config de poste, pas une dépendance de projet :
Chacun route ensuite ses propres modèles dans son
opencode.json. C'est justement la partie que tout le monde veut ajuster, donc aucun agent ne fixe de modèle.Contenu
buildedit/grep/glob/listrefusésplanbuild, sans accès au sidekick ni à git en écrituresidekicknormalresearch/reviewer/design/visionPlus la commande
/sidekick-status— vérification de santé en trois couches.Écarts avec l'upstream
model:dans les frontmatter. Le frontmatter écraseopencode.jsonen silence sur toute clé qu'il définit, donc un modèle codé en dur gagnerait contre la config de la personne.fusion-auditest couvert paropencode stats --models/--tools(et comme chaque rôle tourne sur son propre modèle,--modelsest l'attribution par agent). Son propre README admet que les hooks d'outils OpenCode n'exposent pas l'agent appelant, donc il ne répond pas à la question qu'un plugin d'audit existe pour répondre.fusion-claudeest écarté : dépendance externe par poste, statut incertain côté Anthropic, et APM ne distribue pas les plugins OpenCode.planallégé — référencebuildau lieu de redupliquer sa discipline (l'upstream duplique ~480 mots). Sa posture de permissions est un sous-ensemble strict de celle debuild: mesuré, zéro règle unique àplan, le seul écart réel est l'absence desidekicket de git en écriture.normaldistribuée. Sans elle, leplannatif d'OpenCode survivrait avecedit: ask: on aurait trois primaires dont deux contraints et un qui contourne le patron en silence. Une trappe étiquetée vaut mieux qu'un trou.pnpm,makeetmixen plus denpm/npx. C'est le seul endroit où une adaptation par projet a du sens — les patrons de permissions doivent nommer des commandes concrètes.Vérifié
Installé au scope utilisateur et permissions résolues lues via
opencode agent list:build:git addallow,commit/pushask,push --forcedeny,pnpm run lintallow,lint:fixdeny.Le
/sidekick-statusa été exécuté depuis une sessionbuildréellement chargée : les trois couches passent. La couche 1 est confirmée positivement — deux appels bash ont été bloqués et l'ensemble de règles retourné était l'allowlist du package mot pour mot, ce qui prouve que la config est chargée et appliquée.Prérequis
OpenCode >= 1.18. La clé
subagent_depthn'existe pas avant : sur 1.17 et antérieur, OpenCode rejette le fichier de config au complet et ne démarre pas. Vérifié en pratique pendant le développement.Notes de review
agent:des commandes OpenCode. L'install avertitfrontmatter keys not supported for opencode commands and were dropped: agent./sidekick-statusne peut donc pas s'épingler surbuild: le prompt détecte l'agent actif et rapporte la couche 1 en SKIP depuis un agent non restreint, puisqu'unnormalqui aeditne prouve rien.opencode agent listn'est pas dans l'allowlist debuild, donc la couche 3 de/sidekick-statusretombe toujours sur la lecture des fichiers — le check le plus faible, qui ne voit pas les règles de base fusionnées. Ajouter"opencode agent list*": allowréglerait ça. Volontairement laissé de côté pour ne pas élargir l'allowlist sans discussion.## Unreleased— les tags sont au niveau du repo, doncv1.3.0toucherait aussispec-workflow.