Mise à jour produit KENSAI : la publication proof-first et la discipline de soumission resserrent la surface same-day

KENSAI a durci les opérations du 16 avril avec une estimation des chances d’acceptation, une preuve vidéo obligatoire pour les soumissions et des index de blog séparés par langue afin de garder la publication du jour alignée dans toutes les langues requises.

Ce qui a été livré aujourd’hui

Le travail du jour a resserré deux systèmes à la fois : la manière dont KENSAI déclare une soumission bug bounty prête, et la manière dont le blog public prouve qu’une journée est réellement publiée. Résultat, moins de théâtre. Une découverte n’est pas vraiment prête sans estimation claire des chances d’acceptation et sans preuve vidéo, et un article quotidien n’est pas vraiment publié tant que le HTML localisé, le JSON localisé et les pages overview ne racontent pas la même vérité.

Cela peut paraître strict, mais c’est le bon standard. Des conseils faibles gaspillent des cycles de soumission, et une publication partielle crée une dérive silencieuse qui n’apparaît qu’au moment où des utilisateurs ou des robots tombent sur des surfaces obsolètes.

1) Les conseils de soumission commencent désormais par les chances d’acceptation et un non-envoi si nécessaire

Les recommandations de soumission doivent maintenant commencer par le point difficile. Si les chances d’acceptation semblent faibles, si l’histoire de scope est fragile ou si le résultat le plus probable est informatif ou hors périmètre, la recommandation doit dire clairement de ne pas envoyer. C’est préférable à polir un rapport qui ne devrait probablement jamais quitter la file.

La file devient ainsi plus honnête. Les preuves et la probabilité d’acceptation passent avant l’optimisme, exactement comme un workflow sécurité devrait fonctionner quand le temps et la crédibilité sont limités.

2) La preuve vidéo fait désormais partie de la définition de prêt

Le second resserrement concerne la preuve. Un texte seul ne suffit plus pour qualifier un finding de submission-ready. Si le chemin d’exploitation compte, le package doit contenir une vidéo qui montre clairement le comportement et résiste au scepticisme du reviewer.

Cela pousse l’équipe vers une preuve reproductible plutôt que vers une narration gonflée. Cela crée aussi une frontière plus nette entre signal intéressant et rapport réellement prêt à être envoyé.

3) La publication same-day ne reste honnête que si le HTML localisé, le JSON localisé et les pages overview avancent ensemble

Côté publication, la même règle s’applique : la preuve publique l’emporte sur l’intention interne. Chaque langue ne doit exister que dans son propre index JSON, l’anglais ne doit jamais absorber des entrées non anglaises, et les pages overview doivent être régénérées après l’arrivée des fichiers localisés.

C’est ce qui maintient une surface same-day honnête. Une journée ne compte comme publiée que lorsque le HTML rendu existe, que les bons fichiers JSON par langue pointent vers ces articles et que chaque overview linguistique affiche exactement le même set du 16 avril que l’anglais.

Pourquoi c’est important

Voilà le comportement produit qui mérite d’être protégé. Un système gagne la confiance lorsqu’il rend les affirmations fortes plus difficiles à simuler. La readiness de soumission doit signifier preuve, et la publication doit signifier parité visible sur la surface publique.

C’est une meilleure boucle d’exploitation que d’espérer que l’état interne finisse un jour par ressembler à ce que les utilisateurs voient réellement.