Tableau de bord OCE Shift Status
Collecte des données provenant de plusieurs serveurs MCP en parallèle et présente un tableau de bord consolidé du statut des équipes. Au mieux — les résultats partiels sont toujours affichés.
Procédure
Étape 0 : Confirmation auprès de l'utilisateur
Avant de collecter des données, utilisez l'outil ask_user :
Question : « Souhaitez-vous que je génère un tableau de bord du statut des équipes ? Cela interrogera IcM, ADO, Kusto, Teams et WorkIQ et peut déclencher des invites d'authentification. Assurez-vous d'être connecté au VPN en premier — c'est obligatoire pour Kusto et autres services internes. »
Choix : « Oui », « Oui, et l'écrire dans un fichier », « Non »
- Si Non : répondez « Pas de problème — comment puis-je vous aider ? » et arrêtez-vous.
- Si Oui : passez à l'étape 1. Présentez le tableau de bord dans la console.
- Si Oui, et l'écrire dans un fichier : passez à l'étape 1. Écrivez le tableau de bord dans
oce-dashboard-<YYYYMMDD-HHmmss>.mddans le répertoire de travail actuel au lieu de l'afficher dans la console. Confirmez simplement le nom du fichier une fois terminé.
Étape 1 : Lancer 6 agents en arrière-plan en parallèle
Utilisez l'outil task avec mode: "background" pour chacun. Instruisez chaque agent à toujours se terminer — soit retourner ses résultats, soit répondre par « FAILED: \<reason> » si l'appel d'outil échoue ou si l'authentification échoue. Les agents ne doivent jamais rester bloqués ou se réessayer indéfiniment.
CRITIQUE : Les agents en arrière-plan n'héritent pas du contexte de l'invite de l'agent. Chaque sous-invite d'agent doit être autonome avec tous les ID, paramètres et détails d'appel d'outil dont elle a besoin. Utilisez les modèles ci-dessous — ne construisez pas les invites de mémoire.
Agent 1 — Incidents IcM
Appelez icm-search_incidents_by_owning_team_id pour chaque équipe : 98481 (FF Hot), 149377 (Fluid Framework Client), 98313 (Azure Fluid Relay Client). N'incluez que les incidents Active et Mitigated — excluez Resolved. Rapportez ID, Sev, Title, Status, Team, date de création.
Agent 2 — Santé des pipelines ADO
Appelez ado-pipelines_get_builds pour chaque définition de pipeline (12 = Build, 56 = E2E, 63 = Stress) avec project: "internal", branchName: "refs/heads/main", statusFilter: "Completed", top: 3, queryOrder: "FinishTimeDescending". Codes de résultat : 2 = ✅, 4 = ⚠️, 8 = ❌. Rapportez l'ID de build, le résultat, l'heure d'achèvement et la tendance générale.
Agent 3 — Pipeline d'intégration Loop-FF
Appelez ado-office-pipelines_get_builds avec project: "OC", definitions: [29163], top: 5, queryOrder: "FinishTimeDescending". Important : Utilisez les outils du serveur MCP ado-office (PAS les outils ado par défaut) — ce pipeline se trouve dans l'org ADO office, pas fluidframework. Codes de résultat : 2 = ✅, 4 = ⚠️, 8 = ❌. Rapportez l'ID de build, le résultat, l'heure d'achèvement, la branche et le numéro de build. Signalez tous les échecs — un pipeline d'intégration défaillant signifie que la prochaine mise à jour FF vers Loop sera cassée.
Agent 4 — Taux d'erreurs Kusto
Ne chargez pas la skill ff-oce-kusto. Appelez kusto-kusto_query avec cluster_uri: "https://kusto.aria.microsoft.com", database: "6a8929bcfc6d44e9b13fee392ada9cf0", et cette requête :
Office_Fluid_FluidRuntime_Error
| where Event_Time > ago(1h)
| summarize ErrorCount = count() by AppName = tostring(App_Name)
| order by ErrorCount desc
| take 15Si cela échoue, réessayez avec un simple summarize ErrorCount = count() (sans clause by). Rapportez sous forme de tableau : Partner, Error Count.
Agent 5 — Alertes de pipeline Teams
Appelez teams-ListChannelMessages avec teamId 9ce27575-2f82-4689-abdb-bcff07e8063b, channelId 19:25dabf309c5c42a7abe4647c7c1b7990@thread.skype, top 50, et expand: "replies" pour récupérer les réponses en thread en ligne. Le paramètre expand est obligatoire — sans lui, replies sera null et le statut d'accusé de réception ne peut pas être déterminé. Filtrez les messages d'Azure DevOps (vérifiez que from.displayName contient « Azure DevOps ») au cours des 2 dernières semaines. Classifiez chacun comme Acknowledged (a une réponse textuelle ou réaction ✅/☑️/👍/👀), Resolved (réponse confirmant le correctif), ou Unacknowledged (pas de réponses, pas de réactions significatives). Rapportez : Date, Description, Status, Action Needed.
Agent 6 — WorkIQ
Appelez workiq-ask_work_iq : « Ai-je des e-mails en attente, des éléments d'action ou des suivis de réunion liés à Fluid Framework, FF Client, FF Hot ou Fluid Relay de la semaine dernière ? » Résumez les éléments exploitables.
Étape 2 : Collecte des résultats avec un délai d'attente de 90 secondes
Utilisez read_agent avec wait: true, timeout: 90 pour chaque agent, tous en parallèle.
Arrêt définitif : Après cette seule série d'appels read_agent, vous avez fini de collecter des données. N'appelez pas read_agent à nouveau. N'attendez pas les agents qui sont encore en cours d'exécution. Si le statut d'un agent est autre que « completed » avec des résultats, marquez cette section ⚠️ unavailable — timed out et passez immédiatement à l'étape 3. Les agents restants en cours d'exécution peuvent être ignorés — ils se nettoieront d'eux-mêmes.
Étape 3 : Présenter le tableau de bord
## 🖥️ Tableau de bord OCE Shift Status
Généré : <timestamp>
### 🚨 Incidents IcM actifs
| ID | Sev | Title | Status | Team | Age |
| --- | --- | --- | --- | --- | --- |
### 🔧 Santé des pipelines (main, 3 derniers exécutions)
| Pipeline | Exécution 1 | Exécution 2 | Exécution 3 | Tendance |
| --- | --- | --- | --- | --- |
### 🔗 Pipeline d'intégration Loop-FF (5 derniers builds)
| Build ID | Branch | Result | Finished | Build Number | Notes |
| --- | --- | --- | --- | --- | --- |
### 📊 Taux d'erreurs (dernière 1h)
| Partner | Error Count | Notes |
| --- | --- | --- |
### 🔔 Alertes de pipeline d'intégration (canal FF Client OCE, 2 dernières semaines)
| Date | Description | Status | Action Needed |
| --- | --- | --- | --- |
### 📋 WorkIQ
(résumé)Pour toute section sans données, affichez « ✅ Aucun ». Pour les services défaillants, affichez « ⚠️ [Service] unavailable — reason ».