Attrape les issues avant qu'elles n'atteignent la production. Chaque pull request relue face à ce qui tourne, pas seulement au diff.
Rejoindre la liste d'attenteL'avertissement arrive avant la fusion. Le mécanisme, les preuves et le correctif : là où tu relis.
Add trigram index for order search #482
main from order-search-trgm 
Merging this pull request may degrade production (high impact).
Merging this blocks every write to orders while the index builds. migrations/0114_order_search_trgm.sql:3 adds CREATE INDEX … USING gin (search_text gin_trgm_ops) without CONCURRENTLY, and a plain CREATE INDEX takes a full write lock on orders for the whole build. Checkout sustains ~38 writes/s on that table; each one queues behind the lock until the build finishes.
To make this safe: build the index with CREATE INDEX CONCURRENTLY outside the transactional migration.
Polylane analysed de91b47 for production impact.
Il améliore le code, il ne fait pas que le filtrer. L'instrumentation manquante est ajoutée directement sur ta branche.
Key queries
31 active · 2 telemetry gapsGenerated from your telemetry and your connected code, judged on observed data: every candidate ran against a day of real data before it was kept.
Et il continue de surveiller après la fusion. Ce qui passe entre les mailles est attrapé en production.
Critical latency degradation in checkout-edge worker
checkout-edge › Cloudflare Worker Critical latency degradation detected in checkout-edge worker: 18x+ P99 latency spikes sustained for 12 minutes
edge-gateway Cloudflare Worker ··· checkout-edge Cloudflare Worker ··· 
hd-prod Hyperdrive ··· 
payments-db PlanetScale ··· cart-svc Cloudflare Worker ···
Deploy 9f3c2a1 shrank the Hyperdrive pool
hd-prod from 50 connections to 5. Under checkout load,
requests queue on connection checkout and P99 rises 18× against the 30-minute baseline. Restoring the pool size restores latency.
Comment Polylane fonctionne. Il apprend ton système, le surveille, enquête et agit.
-
Il apprend d'abord ton système
Le graphe de contexte cartographie chaque ressource et chaque dépendance à travers tes clouds, tes dépôts et tes fournisseurs d'observabilité. Les agents raisonnent sur une topologie réelle, pas sur des suppositions.
-
Détection sans seuils
Des vérifications intégrées pour chaque fournisseur, plus des vérifications générées à partir de tes propres requêtes enregistrées et de tes dashboards. Une passe statistique et un agent décident ensemble, et une amélioration ne lève jamais d'issue.
-
Des enquêtes qui montrent leurs preuves
Chaque affirmation renvoie à la requête, à la ligne de log ou à l'enregistrement de changement qui la fonde. Un verdict sans preuves retombe sur non concluant.
-
Les écritures se méritent, jamais présumées
Les comptes se connectent en lecture seule. Les rollbacks sont désactivés par défaut, limités en fréquence et consignés. Les changements de code passent par ta revue habituelle.
-
Il s'affûte chaque semaine
Mémoires, notes quotidiennes et requêtes de supervision reconfirmées contre des données réelles : l'enquête de juillet apprend de celle de juin.
Il se branche sur ce que tu fais déjà tourner. Connecte en lecture seule et commence.
Questions.
Comment fonctionne la revue de pull requests par IA ?
Polylane se connecte à GitHub comme app et relit chaque pull request face à l'infrastructure réelle sur laquelle elle se déploie : le graphe de contexte, la télémétrie actuelle et les changements récents. Le verdict arrive sous forme de commentaire plus une vérification « Polylane production impact ».
Va-t-il bloquer mes fusions ?
Seulement si tu le veux. Rends la vérification « Polylane production impact » obligatoire via la protection de branche et les fusions risquées sont bloquées ; laisse-la facultative et le verdict est consultatif.
Est-ce destiné au code généré par IA ?
C'est pour tout le code. Ça compte simplement davantage quand personne n'a lu le changement de près : le filet de sécurité pour le code généré par IA est la même revue qui attrape l'erreur écrite à la main.
En quoi est-ce différent de la CI ?
La CI exécute tes tests contre le code. Polylane relit le changement face à la production : la config, la capacité et les dépendances sur lesquelles il atterrit, et la télémétrie qu'elles émettent en ce moment. Il apparaît comme une vérification dans la même liste, en répondant à une autre question.
Va-t-il un jour fusionner ou déployer tout seul ?
Non. Les changements n'atteignent ta branche par défaut que par ta revue, et les rollbacks vers un deploy précédent connu comme sain restent désactivés tant que tu ne les actives pas.