Build DSH Plugin

Que fait Build DSH Plugin ?

Utilisez ce workflow pour transformer une idée de plugin DSH en un bundle standard sans modifier ni ombrager le Harness lui-même.

Normaliser le brief utilisateur

Lisez intake.md pour chaque nouvelle demande de plugin. Acceptez soit le langage ordinaire, soit le bref chinois minimal, soit le modèle JSON structuré à plugin-brief.template.json.

Exigez uniquement trois faits sémantiques avant la génération du code source :

1. le problème actuel de l'utilisateur ;
2. le résultat attendu par l'utilisateur ;
3. au moins un critère d'acceptation observable.

Inférez les noms, les identifiants de package, les architectures candidates, la classe de risque, la structure du projet, les tests et les valeurs par défaut sûres. Ne demandez pas à l'utilisateur de concevoir des API Host, des entrées Cordis, des schémas, des outils de construction ou une stratégie de test, sauf s'il a une préférence.

Lorsque des champs facultatifs sont absents, par défaut : génération de code source uniquement, bundle DSH standard, comportement en lecture seule, aucune mutation réelle du profil, aucun redémarrage, aucun réseau/processus/compte/périphérique externe, aucune information d'identification, exposition locale uniquement, aucune publication et acceptation jetable E3. Construisez des bundles DSH réutilisables avec une structure de package compatible avec le marché par défaut, mais n'inférez pas l'autorisation de soumettre ou de modifier le DSH STORE. Indiquez chaque valeur par défaut comme une hypothèse. Aucune publication est une valeur par défaut d'autorisation, pas une interdiction permanente : une version fixe, correctement autorisée, correctement licenciée et cohérente en interne peut être distribuée depuis un site Web ou proposée à un marché.

Ne posez que des questions dont les réponses modifient matériellement le résultat du produit ou les limites de risque. L'absence de problème, de résultat ou d'acceptation bloque la génération. L'absence de profil cible, de périmètre de mutation, de propriétaire d'identifiants, de sécurité LAN/Internet ou de périphérique/compte réel ne bloque que l'opération réelle correspondante ; cela ne bloque pas un échafaudage source sûr lorsque les interfaces peuvent rester abstraites.

Exécutez le normalisateur déterministe lorsqu'un brief JSON est disponible :

node scripts/normalize-brief.mjs /chemin/absolu/vers/plugin-brief.json
node scripts/normalize-brief.mjs /chemin/absolu/vers/plugin-brief.json --json

Si le statut normalisé est READY ou READY_WITH_ASSUMPTIONS et que le mode demandé est build-source, passez par les phases 0–6 sans autre tour de clarification large. Arrêtez-vous avant la publication, la mutation réelle du profil, le redémarrage, les identifiants, le périphérique ou l'exposition publique, sauf autorisation séparée et spécification complète.

Établir le contrat

Commencez en lecture seule. Inspectez les instructions du dépôt, la version cible de DSH, la documentation officielle des plugins, le profil actif seulement lorsque pertinent, et un exemple de plugin standard actuel. Ne supposez pas qu'une API ou un contrat de package d'un projet plus ancien s'applique.

Appliquez toujours ces règles :

• Construisez un bundle DSH, pas une application de bureau ni un fork de DSH.
• Ne modifiez jamais l'arborescence source de DSH ni aucun package @deepseek-ai/*.
• Ne désactivez, ne remplacez et n'ombragez jamais l'inventaire officiel des plugins.
• N'appelez jamais les API de mutation Loader/Fiber. Utilisez les services Host publics et la composition de bundles.
• Utilisez la CLI officielle de DSH pour les modifications de packages. Passez des tableaux d'arguments fixes ; ne construisez jamais de chaînes de commandes shell.
• Conservez les tests dans des répertoires de base/profils jetables. N'écrivez jamais de tests contre le vrai ~/.dsh.
• N'exposez pas les identifiants, les fichiers utilisateur complets, le contexte système/plugin injecté, le raisonnement du modèle ou les chemins privés via des journaux ou des clients.
• Maintenez la planification, la complétion du code, la publication du package, l'installation du profil, l'acceptation d'exécution et l'acceptation externe/périphérique comme des états séparés.
• Maintenez la préparation du plugin, la préparation en tant que candidat au catalogue, la PR/CI du registre, le catalogue fusionné, la visibilité sur le marché public et l'installation du profil comme des états séparés.
• Maintenez la sortie canonique de l'outil, le rendu côté modèle, l'intention de carte neutre vis-à-vis du fournisseur et le rendu client personnalisé optionnel comme des contrats séparés.

Lisez boundaries.md avant l'implémentation ou l'installation. Les bloqueurs stricts dans ce fichier remplacent toute note. Lisez card-contract.md avant d'implémenter un outil de modèle, presentCall, presentResult, presentationMeta ou une carte d'outil personnalisée.

Expliquer chaque décision conséquente

N'émettez pas une liste de règles sans sa logique de décision. Pour chaque décision d'architecture, de permission, de mutation, de publication ou d'acceptation, enregistrez :

1. Objectif : l'échec ou le résultat que la décision contrôle.
2. Raisonnement : pourquoi les mécanismes de DSH ou le modèle de menace actuel l'exigent.
3. Avantages : ce qui devient plus sûr, plus simple, plus compatible ou plus facile à vérifier.
4. Coûts : charge d'implémentation, friction UX, coût de performance, perte de capacité ou délai opérationnel.
5. Applicabilité : les conditions dans lesquelles la décision est appropriée.
6. Alternatives : options viables, pourquoi elles ont été rejetées et quand les reconsidérer.
7. Procédure : étapes concrètes, responsable, entrées, sorties et comportement de restauration.
8. Porte de preuve : la preuve observable requise pour avancer et la condition qui arrête le travail.

Lisez decision-guide.md lors de la planification, de la révision ou de l'explication d'un plugin. Utilisez ses fiches de décision plutôt que de copier un modèle préféré sans analyse.

Exécuter le workflow

Suivez workflow.md pour le processus complet par étapes et les artefacts requis. Ne sautez pas une étape simplement parce qu'un plugin similaire l'a déjà passée ; les versions de DSH, la composition du profil, les dépendances et les services externes peuvent dériver.

1. Prouver l'adéquation du host

Identifiez le host cible, la couture d'extension, le résultat utilisateur demandé, les mutations d'état, les dépendances externes et la surface d'acceptation.

Arrêtez-vous et signalez une inadéquation du host lorsque le projet cible Obsidian, VS Code, une extension de navigateur, MCP uniquement, ou un autre environnement d'exécution sans contrat de bundle DSH prouvé. Proposez le host compatible ou un adaptateur délibérément cadré. Ne vous détournez pas vers un projet adjacent.

Produisez un enregistrement de contrat de host et une comparaison d'architecture. Porte : compatible, adapter-required ou incompatible ; ne laissez jamais cela comme une prose implicite.

2. Classifier le risque

Attribuez une classe parmi scorecard.md :

• R0 : métadonnées/UI en lecture seule.
• R1 : outils/services du host ou état du plugin appartenant à l'utilisateur, aucune écriture dans le cycle de vie du profil.
• R2 : processus externe, réseau, identifiants ou pont de périphérique.
• R3 : cycle de vie du profil, redémarrage, contrôle à distance ou gestion large.

Utilisez la classe supérieure en cas d'incertitude. Enregistrez les non-objectifs et les surfaces interdites avant le codage.

Produisez un registre des risques qui nomme les actifs, les acteurs, les limites de confiance, les surfaces d'écriture, l'impact des défaillances, le niveau de preuve minimum et la raison du choix de la classe.

3. Sélectionner le modèle standard

• Bundle host uniquement : exposez un service/outil Cordis public et contribuez une ou plusieurs lignes de patch uniques.
• Host + Client : gardez le code du navigateur séparé ; enregistrez-vous avec window.__ModuleLoader__.load() et les slots. Le code du navigateur ne doit pas importer de modules Host/Node.
• Route Web optionnelle : retarde l'enregistrement avec ctx.inject(['webServer'], ...) ; les profils headless/sans Web doivent toujours démarrer.
• Adaptateur de compétence : montez des fichiers de compétence isolés ; n'installez pas silencieusement l'environnement d'exécution, l'extension ou les identifiants externes.
• Pont ApiProxy : adaptez la surface distante publique étroite avec une liste d'autorisation, une révocation, une authentification, une analyse bornée et une sécurité de transport fermée en cas d'échec.
• Gestionnaire de cycle de vie : traitez chaque modification de profil comme une transaction R3 et utilisez le protocole de mutation ci-dessous.
• Contrat de carte d'outil : préférez les intentions de rendu presentCall/presentResult neutres vis-à-vis du fournisseur ; utilisez une carte de slot client personnalisée uniquement pour un outil appartenant au plugin lorsque le vocabulaire intégré inspecté ne peut pas exprimer le résultat.

Créez un manifeste de bundle avec dsh.bundle.patch, un cordis.patch.yml résoluble par package, des ID d'entrée uniques, des fichiers explicites, une version, une licence et un contrat de construction. N'oubliez pas que les couches de patch ultérieures remplacent la config complète d'une ligne ; elles ne font pas de fusion profonde.

Comparez au moins deux modèles plausibles lorsque le choix affecte les permissions, les limites de processus, le comportement d'installation ou l'expérience utilisateur. Enregistrez les avantages et les coûts ; ne sélectionnez pas une architecture simplement parce qu'un projet antérieur l'a utilisée.

4. Implémenter le moindre privilège

Utilisez les services publics déjà fournis par la version inspectée de DSH. Si la couture requise est absente, arrêtez-vous et proposez un adaptateur ou une modification en amont au lieu de patcher le noyau.

Préférez les API de découverte en lecture seule et de simulation/prévisualisation. Activez les fonctionnalités d'écriture séparément. Validez les schémas et les limites de taille avant la logique métier. Rejetez les profils malformés, les chemins ambigus, les composants officiels inconnus, l'état obsolète, la relecture, les modifications concurrentes et les preuves manquantes.

Pour chaque outil de modèle, enregistrez la sortie canonique, le rendu côté modèle, la carte en attente, la carte terminée, les métadonnées de présentation durables, les limites/révocations, le recours générique et les preuves en direct/relecture. Les présentateurs doivent être déterministes et n'effectuer aucune E/S, accès à l'horloge/aléatoire, lecture de session ou travail supplémentaire porteur de permission. Ne mettez jamais d'identifiants, de fichiers privés complets, de raisonnement du modèle ou d'arguments illimités dans une carte.

Pour les modèles de défaillance récurrents, lisez problem-playbook.md.

Produisez une matrice de permissions avec chaque source de données/action, côté propriétaire, appelant autorisé, révocation, limite de taille/taux, mode de défaillance et test. Toute permission sans résultat utilisateur et sans test est supprimée.

5. Appliquer le protocole de mutation

Pour les mutations de profil/package/redémarrage, créez un nouveau plan typé pour exactement une opération contenant :

1. l'opération et le profil cible ;
2. l'identité immuable du package/source ;
3. le périmètre exact du fichier et les hachages de précondition attendus ;
4. les arguments de commande et le répertoire de travail ;
5. l'emplacement de sauvegarde et la procédure de restauration ;
6. la postcondition et les contrôles de santé ;
7. une phrase de confirmation exacte ;
8. l'expiration et l'identité à usage unique.

Affichez le plan et attendez la confirmation exacte par opération. Invalidez-le en cas de non-concordance, d'expiration, de modification concurrente ou d'utilisation antérieure. Sauvegardez avant d'écrire, validez atomiquement, exécutez les contrôles de santé de configuration et d'exécution, et restaurez en cas d'échec. Une publication de dépôt n'autorise jamais une mise à jour locale du profil.

Considérez la friction de confirmation et la machinerie de transaction comme des coûts explicites. Acceptez ces coûts pour R3 car l'alternative est une corruption silencieuse et difficile à récupérer de l'état utilisateur. N'imposez pas le protocole de mutation sur les lectures R0 pures.

6. Monter l'échelle de preuve

Avancez uniquement avec des preuves actuelles :

• E0 : idée ou plan.
• E1 : structure statique / révision du code source.
• E2 : tests automatisés unitaires / de contrat / de défaillance.
• E3 : installation de profil jetable, --dump-config, démarrage et test de fumée API.
• E4 : version de profil réel confirmée séparément, processus/port, inventaire/API officiel et relecture UI visible.
• E5 : acceptation externe/publique/périphérique plus preuve de récupération après échec ou de restauration.

N'inférez jamais un niveau supérieur à partir d'un niveau inférieur. Les captures d'écran de l'interface utilisateur ne prouvent pas la restauration ; HTTP 200 ne prouve pas une interface utilisateur visible ; le succès de l'installation ne prouve pas la santé du redémarrage ; la sortie du simulateur ne prouve pas un périphérique réel.

Pour les cartes d'outil, E2 inclut les tests de présentateur déterministe, de relecture malformée, de révocation, de limite, de troncature et de recours générique. E3 inclut la parité de relecture en direct et persistée dans un environnement d'exécution DSH isolé. Le comportement visible de la carte dans le profil de l'utilisateur reste E4.

Produisez une matrice de preuve par capacité. Incluez les preuves négatives et de récupération, pas seulement le chemin heureux. Un score classe la préparation ; il n'accorde jamais d'autorité ni ne remplace une porte dure.

7. Publier et installer séparément

Avant la publication du dépôt, synchronisez la version du package, le README, l'entrée du catalogue, l'ancre d'installation immuable, les tests et les métadonnées sources fixes. Pour les sources Git, soit livrez les artefacts construits, soit déclarez un script prepare autonome et divulguez allowBuilds de pnpm ; épinglez un SHA de commit complet.

Exécutez les vérifications du dépôt, la vérification de la source et une simulation de packaging. Vérifiez le commit distant et les actifs publics après la fusion. Ensuite, arrêtez-vous. Mettez à jour un profil réel uniquement sous un nouveau plan de mutation confirmé, redémarrez-le via le mécanisme approuvé, et relisez la version résolue et l'état d'exécution.

Produisez deux rapports séparés : les preuves de publication du dépôt et les preuves d'acceptation du profil/de l'environnement d'exécution. Lorsque le deuxième rapport est absent, indiquez Profil inchangé ou Profil non vérifié.

8. Rendre les plugins réutilisables prêts pour le DSH STORE

Lisez marketplace.md chaque fois que vous construisez un plugin tiers réutilisable DSH, que vous évaluez un dépôt existant pour le DSH STORE, ou que vous préparez une entrée de catalogue.

N'attendez pas la soumission pour découvrir une incompatibilité de liste. Dès le premier échafaudage, réservez des ID de package/catalogue/entrée uniques ; déclarez le dépôt, la version, la licence, un dsh.bundle.patch sûr, un patch relatif au package, des fichiers d'exécution/construction, des scripts de cycle de vie, des permissions, des dépendances et des preuves de compatibilité. Au début de chaque évaluation STORE, exécutez node scripts/official-dsh-releases.mjs et utilisez sa fenêtre officielle des trois dernières versions ; ne réutilisez pas une fenêtre mémorisée. Le résolveur suit le canal latest/alpha/beta/rc npm le plus élevé et actif, exclut les versions next uniquement et dépréciées, et échoue en cas d'autorité invalide. La fenêtre observée au 2026-09-02 est 0.1.2-alpha.2, 0.1.2-alpha.3 et 0.1.2-alpha.4, mais il s'agit d'une preuve plutôt que d'une constante permanente. Conservez des enregistrements exacts de compatibility.dshReleases et les compatibility.dshOperations correspondants pour l'installation, le démarrage, la désinstallation et la restauration sur chaque version de la fenêtre résolue. Les clés historiques peuvent rester, mais les métadonnées inconnues restent inconnues au lieu d'être devinées.

Gardez la découverte STORE et l'installation de confiance physiquement et logiquement séparées. Un enregistrement dans registry/candidates.json est uniquement destiné à la découverte, ne porte aucun contrat de package/installation/permission, et doit se normaliser à installable: false sans actions autorisées. Il ne peut passer à registry/catalog.json qu'après une révision séparée de la source fixe, du bundle, de la licence, de la permission, de la compatibilité et des preuves. La promotion, la recommandation, le parrainage, les étoiles ou le score n'autorisent jamais la découverte seule à servir d'installation. Ne sautez pas la porte du catalogue.

...

[truncated for translation]