Trouver les feature flags récemment supprimés

Cette skill produit une liste des feature flags qui ont été soft-deletés dans le projet actif au cours d'une fenêtre temporelle spécifiée par l'utilisateur, ainsi que qui les a supprimés et quand.

Quand utiliser cette skill

L'utilisateur demande « quels flags ont été supprimés la semaine dernière / au cours des N derniers jours ? »
L'utilisateur veut un audit des suppressions récentes de flags (qui, quand, ce qui a été supprimé)
L'utilisateur veut savoir quand un flag spécifique a été supprimé, ou par qui
Tout framing de type « feature flags récemment supprimés »

Ne l'utilisez pas pour le nettoyage actif de flags obsolètes — c'est cleaning-up-stale-feature-flags. Cette skill concerne les flags qui ont déjà été supprimés.

Le piège qui rend cela non trivial

system.feature_flags expose deleted comme booléen mais n'expose pas deleted_at, updated_at, ou last_modified_at. Il n'existe aucun moyen de filtrer les flags soft-deletés par heure de suppression dans une seule requête SQL — la tentative d'utilisation de ces colonnes retournera Unable to resolve field.

L'horodatage réel de la suppression vit dans le journal d'activité par flag, accessible uniquement via posthog:feature-flags-activity-retrieve (un appel par id de flag). Il n'existe pas d'endpoint d'activité en masse.

Le workflow se fait donc en deux étapes : SQL pour énumérer les candidats, puis des recherches parallèles de logs d'activité pour trouver chaque événement de suppression.

Workflow

1. Clarifier la fenêtre si ambiguë

« La semaine dernière » est ambiguë — cela peut signifier les 7 derniers jours depuis maintenant, ou la semaine civile précédente (lun–dim). Si l'utilisateur n'a pas été explicite, demandez, ou présentez les deux interprétations dans le rapport final.

Calculez toujours le seuil en UTC et gardez l'interprétation locale de l'utilisateur à l'esprit séparément.

2. Énumérer les flags soft-deletés via SQL

Interrogez system.feature_flags pour deleted = true dans le projet actif, ordonnés par created_at DESC :

SELECT id, key, created_at
FROM system.feature_flags
WHERE team_id = <team_id> AND deleted = true
ORDER BY created_at DESC
LIMIT 100

Ordonnez par created_at DESC car les suppressions se regroupent empiriquement près de la création — la plupart des flags sont supprimés quelques jours après leur création — donc parcourir les candidats les plus récemment créés d'abord trouve les suppressions récentes plus vite. Mais cela reste une heuristique, pas une garantie : un flag ancien supprimé récemment ne sera pas en haut de cette liste. Soyez explicite sur cette limitation quand vous rapportez.

team_id est par défaut le projet actif, mais incluez-le explicitement pour clarté.

3. Lancer les recherches de logs d'activité en parallèle

Pour chaque id candidat, appelez posthog:feature-flags-activity-retrieve avec limit: 5, page: 1. Lancez tous les appels dans un seul message pour qu'ils s'exécutent concurremment — les appels séquentiels sont dramatiquement plus lents.

call feature-flags-activity-retrieve {"id": <flag_id>, "limit": 5, "page": 1}

Tailles de batch raisonnables :

« 7 derniers jours » → top 20–25 candidats
« 30 derniers jours » → top 50
« 90 derniers jours » → parcourir les ~100 complets

Si vous échantillonnez moins que l'ensemble complet, dites-le dans le rapport et proposez de parcourir le reste en suivi.

4. Extraire l'événement de suppression de chaque réponse

Dans chaque réponse, trouvez l'entrée où activity == "deleted". Le created_at de cette entrée est l'heure réelle de suppression, et user.email / user.first_name identifient qui a supprimé.

Le tableau detail.changes de l'événement de suppression contient généralement :

{field: "deleted", before: false, after: true} — la suppression réelle
{field: "key", before: "<original>", after: "<original>:deleted:<id>"} — Django renomme la clé lors de la suppression pour libérer la contrainte d'unicité
{field: "name", ...} — le nom est parfois réinitialisé

Pour la plupart des flags il existe exactement un événement de suppression. Si un flag a été supprimé et restauré plusieurs fois, prenez l'événement activity: deleted le plus récent dans la fenêtre.

5. Filtrer et rapporter

Filtrez les événements de suppression collectés à ceux dont le created_at se situe dans la fenêtre demandée. Présentez sous forme de tableau :

Énoncez votre méthodologie dans le rapport (combien de candidats vous avez parcourus vs. combien de flags soft-deletés existent au total), afin que l'utilisateur sache ce qui a et n'a pas été vérifié.

Mises en garde

Cas limites : si une suppression est à environ 1 heure du seuil de la fenêtre, présentez-la comme douteuse plutôt que de la supprimer silencieusement.
Ne faites pas confiance à created_at comme proxy pour l'heure de suppression : un flag créé en 2024 peut encore avoir été supprimé la semaine dernière. Le journal d'activité est la seule autorité.
Les clés renommées sont normales : un flag avec la clé foo:deleted:12345 était le flag originellement cléifié foo. La clé/nom original apparaît dans le tableau detail.changes de l'événement de suppression — présentez cela à l'utilisateur, pas la forme renommée.
Parcourir tous les candidats est possible mais lent : ~100 appels parallèles au log d'activité est faisable. Proposez-le en suivi plutôt que par défaut pour les courtes fenêtres.

Exemple d'interaction

Utilisateur : « quels flags ont été supprimés la semaine dernière ? »

Clarifiez si nécessaire, ou notez les deux interprétations : « 7 derniers jours glissants jusqu'à maintenant (UTC), dans le projet actif »
Lancez l'énumération SQL pour obtenir jusqu'à 100 candidats soft-deletés ordonnés par created_at DESC
Lancez les recherches de logs d'activité en parallèle sur les ~25 meilleurs candidats
Extrayez les entrées activity: deleted ; filtrez à celles dont created_at >= now - 7 days

Rapportez :

2 feature flags trouvés supprimés au cours des 7 derniers jours (glissants, fin 2026-05-22 19:04 UTC) :

| Flag ID | Clé                                       | Supprimé à (UTC)     | Supprimé par  |
|---------|-------------------------------------------|----------------------|---------------|
| 687432  | high_frequency_alerts                     | 2026-05-22 17:23     | Matt P.       |
| 676665  | tasks-sendblue-prewarmed-sandbox-pool     | 2026-05-15 13:45     | Alessandro    |

Méthodologie : parcours du log d'activité pour les 25 flags soft-deletés les plus
récemment créés. L'équipe 2 a ~100 flags soft-deletés au total ; les ~75 restants
ont été créés avant mi-mars 2026 et n'ont pas été vérifiés. Vous voulez que je
parcoure le reste ?

Outils connexes

posthog:execute-sql : Utilisé à l'étape 2 pour énumérer les candidats soft-deletés contre system.feature_flags
posthog:feature-flags-activity-retrieve : Utilisé à l'étape 3 pour trouver l'événement de suppression réel pour chaque candidat
posthog:feature-flag-get-definition : Utile si l'utilisateur veut ensuite inspecter l'apparence du flag supprimé

finding-deleted-feature-flags