Comment ça fonctionne
Décrivez le changement. RefineBrief analyse le code et prépare les tickets Jira.
Vous indiquez le problème et choisissez où mener l’analyse. RefineBrief parcourt les dépôts Java connectés, identifie les classes, méthodes, flux et dépendances probablement concernés, sépare les preuves des inférences et prépare un brief technique avec un ou plusieurs tickets. Votre équipe révise tout avant la création dans Jira.
Git en lecture seule · Aucun changement de code · Création dans Jira uniquement après approbation
Configuration initiale
Connectez une fois. Analysez toujours avec le contexte à jour.
Lors de la configuration, votre équipe connecte les dépôts Git en lecture seule et définit le projet et le modèle de ticket Jira. RefineBrief crée une représentation technique dérivée et la maintient à jour lorsque les dépôts évoluent.
- Connecter les dépôts Git
- Connecter Jira
- Choisir le projet
- Configurer le modèle de ticket
- Décrire le problème
- Choisir certains ou tous les dépôts
- Analyser l’impact probable
- Réviser le brief technique
- Créer les tickets approuvés
Flux principal
De la demande à Jira.
- 01
Décrire le changement
Saisissez un bug, une fonctionnalité, une tâche ou une question technique, même si la description est encore incomplète.
- 02
Choisir où analyser
Sélectionnez les dépôts probablement concernés ou laissez RefineBrief analyser tous les dépôts connectés.
- 03
Réviser l’impact probable
Consultez le comportement actuel, les classes, méthodes, services, flux, dépendances, risques et décisions manquantes.
- 04
Ajuster le résultat
Modifiez le brief, répondez aux questions et fusionnez, divisez ou supprimez les tickets suggérés.
- 05
Créer dans Jira
Les tickets approuvés utilisent le projet et le modèle de ticket Jira configurés par votre équipe.
Le résultat
Ce que votre équipe reçoit avant le refinement.
RefineBrief transforme la demande initiale en un brief technique révisable.
Le brief comprend la demande initiale, le comportement actuel trouvé dans le code, les classes et services probablement concernés, les flux HTTP et Kafka, les preuves liées, l’impact probable entre dépôts, le périmètre, les dépendances, les risques, les questions ouvertes et un ou plusieurs tickets suggérés.
RefineBriefPRÊT À ÊTRE RÉVISÉ« Ajouter la gestion des nouvelles tentatives au traitement des notifications client. »
Le producteur envoie les événements vers customer.events. Le consommateur traite les erreurs temporaires et permanentes du fournisseur dans le même flux.
- notification-service
- email-consumer
- Observability
- Tests d’intégration
- NotificationController.java:84
- NotificationService.java:136
- EmailConsumer.java:112
- Combien de tentatives doivent être effectuées ?
- Les échecs permanents doivent-ils aller vers un dead-letter topic ?
- Le consommateur doit-il garantir l’idempotence ?
- Qui est alerté lorsque toutes les tentatives échouent ?
- Mettre à jour la politique de nouvelle tentative
- Ajouter l’idempotence au consommateur
- Surveiller les échecs permanents
- Couvrir les livraisons en double dans les tests d’intégration
Impact probable entre dépôts
Suivez le changement au-delà du premier dépôt.
RefineBrief suit les appels HTTP, les événements Kafka et les dépendances partagées pour montrer où un changement peut se propager. Chaque relation reste liée aux preuves trouvées et peut être révisée par l’équipe.
Preuve, inférence et décision
Ce qui a été trouvé ne se mélange pas avec ce que l’équipe doit encore décider.
EmailConsumer.java traite les erreurs temporaires et permanentes du fournisseur dans la même branche.
La politique de nouvelle tentative peut nécessiter des changements dans plusieurs services.
Les événements en échec permanent doivent-ils aller dans un topic dead-letter ?
Une demande, un ou plusieurs tickets
Révisez la répartition suggérée avant tout envoi vers Jira.
Lorsque l’investigation identifie des travaux indépendants dans les services, consommateurs, l’observabilité ou les tests, RefineBrief suggère une division. Votre équipe peut fusionner, séparer, modifier ou supprimer tout ticket.
Mettre à jour la politique de nouvelle tentative du producteur de notifications
notification-service
Ajouter l’idempotence au consommateur Kafka
email-consumer
Ajouter la surveillance des événements en échec
observability
Étendre la couverture d’intégration des livraisons en double
integration-tests
Division suggérée · Fusionner, séparer, modifier ou supprimer avant la création dans Jira
RefineBrief suggère la division
L’équipe révise et modifie
Le modèle de ticket Jira est appliqué
Seuls les tickets approuvés sont créés
Périmètre actuel
Centré sur les systèmes Java modernes.
RefineBrief prend actuellement en charge Java 17 à Java 25, les monolithes et microservices, plusieurs dépôts Git, les classes, méthodes et dépendances, les contrats HTTP, les producteurs et consommateurs Kafka, ainsi que la sélection de certains ou de tous les dépôts connectés.
- Java 17 à Java 25
- Monolithes et microservices
- Plusieurs dépôts Git
- Classes, méthodes et dépendances
- Appels et contrats HTTP
- Producteurs et consommateurs Kafka
- Certains ou tous les dépôts connectés
Analyse du code frontend
Détails techniques de l’investigation
Cartographie des symboles basée sur SCIP
Relations de graphe
Recherche lexicale et sémantique
Utilisez une demande réelle
Utilisez une demande réelle de votre équipe pendant la démo.
Découvrez comment RefineBrief analyse le contexte technique, expose les décisions manquantes et prépare les tickets Jira avant le refinement.