Triage Frontend Issues

Archivez le bruit non actionable de la file d'attente sentry/javascript : archivez uniquement, toujours en mode untilEscalating, toujours avec une raison explicite. Les issues qui semblent actionables dans notre code, ou que vous ne pouvez pas classifier avec confiance, doivent être ignorées.

Hard Rules

Ces règles remplacent tout le reste. Ne les assouplissez pas.

1. Périmètre du projet. Opérez uniquement sur organizationSlug=sentry, slug du projet javascript. Si on vous demande de traiter un autre projet, arrêtez et demandez à l'utilisateur de confirmer.
2. Archive uniquement. La seule mutation de statut autorisée est status=ignored. Ne résolvez jamais, ne dérésolvez jamais, n'assignez jamais, ne supprimez jamais, ne mettez jamais à jour d'autres champs que le statut.
3. Toujours untilEscalating. Utilisez ignoreMode=untilEscalating. N'utilisez jamais forever, forDuration, untilOccurrenceCount, ou untilUserCount. Si l'utilisateur demande un mode différent, arrêtez et faites-lui archiver l'issue manuellement — ce skill n'effectue pas d'archives non-escaladantes.
4. Incluez toujours une reason. La reason doit être une phrase courte et factuelle nommant la catégorie depuis references/archive-criteria.md (ex: "Bruit de bibliothèque tierce — internals echarts; pas actionable dans notre code").
5. Ne touchez jamais aux issues en dehors de la file unresolved. Ignorez tout ce qui a un status de resolved, ignored, ou reprocessing.
6. N'archivez jamais sans confirmation. Construisez un plan complet, montrez-le à l'utilisateur, attendez l'approbation explicite avant d'appeler update_issue. Une seule approbation couvre le plan affiché uniquement; les nouveaux lots nécessitent une nouvelle approbation.
7. En cas de doute, ignorez. Si une issue pourrait plausiblement être un vrai bug dans notre code, ne l'archivez pas. Signalez-la comme needs-human dans le plan avec une note d'une ligne.

Prérequis

• Sentry MCP authentifié via mcp.sentry.dev. Outils requis: search_issues, get_sentry_resource, update_issue.
• Si update_issue n'est pas disponible, arrêtez et demandez à l'utilisateur d'authentifier le serveur Sentry MCP.

Entrées

$ARGUMENTS est l'une des options suivantes:

Si $ARGUMENTS est ambigu, demandez à l'utilisateur de clarifier avant de rechercher.

Workflow

1. Charger la file

Pour une entrée issue unique:

• Appelez get_sentry_resource(url=<issue-url>) ou get_sentry_resource(resourceType='issue', organizationSlug='sentry', resourceId=<shortId>).
• Confirmez que le Project est le projet frontend javascript. Sinon, arrêtez.

Pour une entrée query/défaut:

• Appelez search_issues(organizationSlug='sentry', projectSlugOrId='javascript', query=<query>, sort='new', limit=50).
• Puis appelez get_sentry_resource pour chaque résultat en parallèle pour obtenir le culprit, substatus, assignee, et les indices de stack-frame (la réponse de recherche omet certains champs).

Ignorez immédiatement si l'une de ces conditions est vraie sur une issue:

• status n'est pas unresolved (déjà archivée, résolue, ou en reprocessing).
• assignedTo est défini pour une personne (quelqu'un en est responsable).
• assignedTo est défini pour une équipe autre que frontend/issues et l'issue semble spécifique à l'équipe (laissez l'équipe propriétaire la traiter).

2. Classifier chaque issue

Lisez references/archive-criteria.md pour la taxonomie des catégories avec heuristiques de reconnaissance et exemples. Pour chaque issue candidate, produisez l'une des options suivantes:

Lors de l'évaluation, pondérez ces signaux (dans cet ordre):

1. Frame Sentry-SDK non-top. Si le frame in-app le plus haut est dans node_modules/, chrome-extension://, un hôte tiers, ou <unknown>, c'est un fort signal d'archive.
2. Motif de titre. Beaucoup d'archives sont reconnaissables uniquement par le titre (voir la référence des critères).
3. Le volume n'est pas un veto. Certaines issues à haut volume (10k+ événements, des milliers d'utilisateurs) sont toujours archive-worthy si le frame le plus haut est tiers. Le volume seul ne force jamais l'archive non plus.
4. Récence. Les issues à événement unique datant de plus de 30 jours sans réapparition sont généralement du bruit.
5. Propagation org client. Si les événements proviennent uniquement du sous-domaine d'un seul client (vérifiez la tag customerDomain.subdomain), c'est probablement du bruit environnemental client.

3. Construire le plan

Affichez un tableau Markdown à l'utilisateur, exactement dans cette forme:

## Plan de triage — sentry/javascript (<N> candidats)

| # | Issue | Titre | Volume | Décision | Catégorie | Raison |
|---|-------|-------|--------|----------|-----------|--------|
| 1 | [JAVASCRIPT-XXXX](url) | TypeError: ... | 12e/3u | archive | browser-api-noise | Permission clipboard navigateur refusée; pas actionable. |
| 2 | [JAVASCRIPT-YYYY](url) | <unknown> | 4945e/123u | needs-human | — | Volume élevé, pas de titre — veuillez examiner avant archivage. |
| 3 | [JAVASCRIPT-ZZZZ](url) | ZodError: ... | 360e/132u | skip | — | Validation de schéma échouée dans notre code; semble actionable. |

Puis résumez les comptages: N archive / M skip / K needs-human. Terminez par:

Répondez `apply` pour archiver les N issues marquées `archive`, `apply N,M,...` pour archiver un sous-ensemble, ou `cancel` pour ne rien faire.

4. Appliquer après approbation

Quand l'utilisateur répond apply (ou apply <subset>):

Pour chaque issue de l'ensemble approuvé, appelez:

update_issue(
  organizationSlug='sentry',
  issueId=<shortId>,
  status='ignored',
  ignoreMode='untilEscalating',
  reason=<raison marquée-catégorie depuis le plan>,
)

Exécutez-les séquentiellement (non en parallèle). Si un appel échoue, enregistrez l'échec, continuez avec les issues restantes, et signalez les IDs échoués à l'étape 5.

Si l'utilisateur répond cancel ou demande de modifier le plan, N'APPELEZ PAS update_issue. S'il répond avec des modifications ("change la ligne 2 en skip"), reconstruisez le plan et re-confirmez.

5. Rapport

Après application, affichez:

## Rapport de triage

- Archivées: N
- Ignorées: M
- Nécessite examen humain: K
- Échecs: F (avec IDs d'issues)

<details><summary>Issues archivées</summary>

- JAVASCRIPT-XXXX — <raison>
- ...

</details>

Récupération

• Si update_issue échoue sur un élément, enregistrez l'échec et continuez avec le reste. Signalez les IDs échoués à la fin.
• Si l'utilisateur remarque une archive incorrecte, il peut la dés-archiver lui-même dans Sentry. Le skill n'inverse jamais automatiquement ses propres actions.
• Si l'utilisateur demande "refaire le plan avec ces ajustements" en cours de flux, régénérez le plan de zéro — ne supposez pas que le plan précédent s'applique toujours.

Exemples de raisons (utilisez cette voix)

• Bruit de bibliothèque tierce — tooltip echarts; pas actionable dans notre code.
• Bruit de permission API navigateur — Clipboard writeText refusé par user agent.
• Interférence proxy environnement client — réponse 200 traitée comme erreur (corps HTML depuis proxy d'entreprise).
• Backend 5xx transient — InternalServerError sur /api/0/organizations/.../events-meta/; backend transient.
• Événement test/synthétique — smoke test ou probe de sécurité, pas trafic production.
• Mauvais projet — erreur Prisma/Python mal routée vers le projet frontend.
• Fluke événement unique — 1 événement, 1 utilisateur, pas de réapparition en 30+ jours.
• Bruit d'extension navigateur — ReferenceError pour global injecté par extension (DarkReader/WeixinJSBridge).