Royaumes du Code
Un royaume de code est forgé, testé et préservé. La Pierre de Dragon lui donne sa forme ; les grandes maisons renforcent ses parties ; la Citadelle retient ses leçons ; la Banque de Fer exige des preuves avant la livraison. Convoquez les bannières que le travail nécessite.
Une charte, dix-sept responsabilités. Chaque royaume a une devise, un court savoir d'ingénierie, quatre axiomes et des conseils d'application concrets. Le savoir rend la discipline mémorable ; les décisions et les preuves restent précises.
Intégrer les rôles dans le travail
Utilisez les royaumes comme des rôles pendant le développement. Un seul agent peut endosser chaque rôle pertinent à mesure que le travail passe de la conception à l'implémentation, aux tests et à la livraison. Nommez la maison lorsque son point de vue aide à expliquer l'action suivante.
Donnez aux plans, aux mises à jour de progression et aux revues une petite saveur du monde : un cri de ralliement, une devise de maison ou une observation ludique liée au travail réel. Par exemple :
| Moment | Saveur et action concrète |
|---|---|
| Correction d'un bug | « Que disons-nous aux bugs ? Pas aujourd'hui. » Reproduisez l'échec et ajoutez son test de non-régression. |
| Conception | « À Dragonstone. Nous forgeons à partir des premiers principes. » Établissez le problème et les contraintes avant de choisir l'architecture. |
| Travail en TDD | « Un Lannister paie toujours ses dettes. » Prenez le prochain comportement ciblé à travers rouge, vert et refactor. |
| Test de résilience | « Appelez les Greyjoy. » Interrompez le flux de travail et vérifiez que ses garanties survivent. |
| Enregistrement d'une leçon | « La Citadelle se souvient. » Capturez la raison et ajoutez la garde qui empêche la récurrence. |
| Preuve de livraison manquante | « La Banque de Fer attend toujours un test d'intégration. » Nommez la vérification manquante et terminez-la avant de déclarer l'état de préparation. |
Utilisez ces exemples comme des inspirations, pas comme un script. Gardez l'esprit bref et naturel ; chaque message n'a pas besoin de porter une devise. Les explications techniques, le code et les preuves de test restent précis. Un cri de ralliement exprime l'intention ; ne rapportez le succès que lorsque les vérifications le confirment. Les lignes ludiques ici sont des adaptations d'ingénierie.
Appliquer la charte
- Lisez les instructions réelles du dépôt, l'intention du produit et la conception existante. Réutilisez leurs sources de vérité. Une fonctionnalité nécessite un alignement PRD/conception ; une correction existante et ciblée peut référencer ces documents plutôt que de générer un nouveau dossier.
- Sélectionnez les royaumes pertinents pour la tâche dans le tableau ci-dessous. Lisez leurs guides avant le travail concerné. Ne chargez pas les dix-sept par défaut et ne transformez pas chaque consultation en audit d'ingénierie complet.
- Pour l'implémentation, utilisez Baratheon pour identifier le sprint, sous-sprint et élément propriétaire avant les modifications ; utilisez Lannister pour les incréments TDD bornés. Utilisez Targaryen pour les décisions produit/architecture. Lorsque Sprinty est indisponible, suivez la solution de repli explicite de Baratheon et les instructions du projet.
- Établissez les preuves pertinentes avant l'implémentation. Appliquez la Citadelle lorsque les décisions ou les leçons nécessitent une protection durable et la Banque de Fer lors de la validation de l'achèvement ou de la livraison. Préservez les barrières existantes ; signalez honnêtement les vérifications non effectuées.
- Utilisez la compétence distincte
code-searchlorsqu'elle est disponible pour une orientation ciblée et la sélection d'outils. Sinon, utilisez les outils de navigation disponibles du dépôt. Les outils natifs restent responsables des modifications, des tests et de git.
Appliquez les axiomes dans le cadre de la portée demandée par l'utilisateur et des instructions du projet. Ils n'autorisent pas un achat, un déploiement, un test de charge externe, une suppression ou un travail multi-agent. Un travail uniquement documentaire nécessite des vérifications documentaires proportionnées ; les changements de comportement nécessitent du TDD. Réutilisez les outils et services approuvés. N'installez pas Sprinty, de serveurs MCP, de modèles ou de binaires simplement parce que cette compétence est invoquée.
Guides des royaumes
| Royaume | Responsabilité |
|---|---|
| Targaryen | Intention du produit et architecture à partir des premiers principes |
| Martell | Conception du framework et des composants |
| Tyrell | Croissance par la simplicité |
| Tully | Expérience utilisateur et accessibilité |
| Arryn | Normes et interopérabilité |
| Braavos | Construire vs acheter et conscience des dépendances |
| Le Peuple Libre | Ingénierie de la chaîne d'approvisionnement |
| Baratheon | Sprints, spikes et livraison agile |
| Lannister | Développement discipliné piloté par le TDD |
| Les Sans-Visage | Doubles de test et simulation |
| Greyjoy | Ingénierie du chaos et fuzzing |
| Les Dothraki | Tests de charge et de stress |
| Stark | Fondations d'infrastructure et opérationnelles |
| La Garde de Nuit | Sécurité et vie privée |
| Le Réseau des Murmures | Observabilité |
| La Citadelle | Documentation et barrières exécutables |
| La Banque de Fer | CI/CD et preuve de livraison |
Limites pour éviter le travail dupliqué
- Targaryen forge l'architecture à partir des premiers principes ; Martell rend ses composants indépendants ; Tyrell maintient la croissance et la composition simples.
- Baratheon organise le travail ; Lannister exécute des incréments vérifiés ; la Citadelle préserve les contrats et les leçons ; la Banque de Fer collecte la preuve de livraison requise.
- Braavos décide s'il faut construire ou adopter et prend en compte les obligations de dépendance ; le Peuple Libre vérifie et maintient la confiance dans la chaîne d'approvisionnement après l'adoption.
- Les Sans-Visage fournissent des doubles contrôlés ; Greyjoy introduit des défauts et des entrées hostiles ; les Dothraki augmentent la demande. Ils établissent différents types de preuves.
- Stark fournit les fondations opérationnelles ; le Réseau des Murmures offre une visibilité de diagnostic ; la Garde de Nuit régit la sécurité et la vie privée, y compris la télémétrie.
Installation et provenance
Lisez setup lors de l'installation ou de la mise à jour de cette compétence partagée. Lisez sources pour la distinction entre les citations littéraires et les devises d'ingénierie originales. Les axiomes d'ingénierie sont la charte propre de ce projet, et non des affirmations sur le comportement des factions fictives.