Les filtres ne marchent pas sur le dashboard
Les filtres sont cassés sur la page dashboard. Impossible de sélectionner « 30 derniers jours ». Testé sur Chrome.
Meridian Flow reproduit, valide et contextualise automatiquement les rapports de bugs avant que l'engineering ne les prenne en charge — transformant des tickets vagues en incidents avec un spec qui échoue, un verdict et les traces pour les corriger.
Salut l'équipe — quand j'ajoute le code SUMMER25 à la fin, la page se fige et je peux plus payer. Ça arrive sur mon MacBook dans Chrome. Pas sûr de comment reproduire, désolé. Urgent pour la campagne.
La plupart des rapports manquent d'étapes, ciblent le mauvais environnement, ou s'appuient sur du contexte enterré dans trois threads Slack. Les ingénieurs passent leur matinée à reproduire des tickets, pas à les corriger.
Les filtres sont cassés sur la page dashboard. Impossible de sélectionner « 30 derniers jours ». Testé sur Chrome.
Un client a signalé un total décalé d'un centime dans le PDF. Capture jointe (basse résolution).
Plusieurs utilisateurs rapportent un login lent. Parfois 5s, parfois nickel. Mobile et desktop.
Meridian Flow exécute cinq étapes déterministes entre le ticket et le développeur. Chaque étape produit un artefact que la suivante — ou un humain — peut exploiter.
Rapport en langage naturel depuis Jira, Linear ou GitHub. Aucun format spécifique requis.
Chaque ticket atterrit chez l'engineering avec la même forme — pour que n'importe qui dans l'équipe puisse agir sans avoir à relire le thread Jira d'origine.
{
"ticket": "PROD-2814",
"status": "reproduced",
"category": "race_condition",
"severity": 3,
"component": "checkout/PromoCodeInput.tsx",
"reproduction": {
"deterministic": true,
"runs": 12,
"failure_rate": 1.0,
"env": "staging-eu"
},
"ruled_out": ["browser", "network", "promo_data"],
"suspected_cause": "unawaited debounce on apply→pay",
"blast_radius": "~12% of code-applied checkouts",
"artefacts": ["spec.ts", "trace.zip", "frames/"]
}Le runner de reproduction vit dans votre infrastructure. Seuls les artefacts que vous choisissez — verdicts, traces, captures expurgées — atteignent notre control plane.
Les traces et verdicts quittent votre réseau. Les chemins de fichiers sont conservés ; le contenu des lignes ne l'est pas.
Les stack traces sont nettoyées de leurs identifiants avant l'envoi. Les verdicts ne contiennent que des chemins de fichiers.
Le runner remonte les verdicts dans votre propre Jira ; rien ne quitte le périmètre.
Meridian Flow ne cherche pas à être un agent IA générique. Il sait précisément qui il aide et avec quoi il s'intègre — c'est la seule façon pour le pretriage d'être fiable.
Nous lisons les tickets et y postons des verdicts structurés en commentaire. Linear et GitHub Issues sont aussi supportés ; Jira est celui autour duquel nous calibrons les heuristiques.
Chaque verdict est accompagné d'un spec Playwright qui échoue, que votre équipe peut exécuter, modifier et commiter à côté de vos tests e2e existants.
Nous tournons contre du vrai staging — pas un mock. Apportez un environnement, pointez le runner dessus, donnez-lui des identifiants de test. On travaille avec la forme que vous avez déjà.
React, Vue, Svelte, Remix, Next, SPA, MPA, tout ce que Playwright peut piloter. Le web mobile fonctionne ; le natif mobile n'est pas dans le périmètre.
Chaque trimestre, nous accueillons un petit nombre d'équipes personnellement. Nous calibrons le runner sur votre stack, configurons le workflow Jira avec vous, et restons dans votre Slack jusqu'à ce que vos dix premiers tickets atterrissent confirmés.