Les deux scopes d’écriture
vso.test_write — Coverage Builder
Alimente uniquement l’action de création du Coverage Builder. Création seule : jamais d’écrasement ni de suppression d’un plan ou d’une suite existante.
vso.work_write — test exploratoire
Alimente uniquement ce qu’une session exploratoire dépose à votre demande : un bug, un cas de test, la tâche de suivi de la session, et leurs pièces jointes. Tout est créé, jamais modifié — TestPulse relie un nouveau work item à votre exigence, il ne touche pas à l’exigence.
Une exception étroite : à la clôture d’une session, un dialogue facultatif peut poser l’état de la tâche que TestPulse vient de créer, dans le même geste. C’est la seule écriture postérieure à une création dans le produit, et elle ne s’applique jamais à quoi que ce soit d’antérieur.
Ajouter un scope d’écriture au manifeste est une action d’administrateur et déclenche une ré-approbation de l’extension pour l’organisation. Jusque-là, tout ce qui est en lecture continue de fonctionner — seule l’action de création correspondante est indisponible.
Permission ≠ scope
Un 403 à la création d’un plan est presque toujours une ACL d’area path — la permission Manage test plans se donne par area path — et non un scope manquant. Voir Créer le plan dans Azure DevOps.À suivre
Confidentialité & données
Où vivent les données.
Lecture seule par conception
La frontière lecture/écriture en détail.