Compétence Brainstorm

Un cadence de dialogue divergent-puis-convergent pour les idées dont la direction est encore en formation. Compresse la conversation en un seul ElaborationRound de Q&R de point de décision — même structure qu'un round d'élaboration structuré, mais les questions, options et réponses sont synthétisées à la fin de la conversation plutôt que posées d'emblée.

Cette compétence est un producteur d'un round d'élaboration ; la décision du scheduler (résoudre vs. suivi) appartient à la compétence d'idée appelante.

Lors de l'invocation

Uniquement comme sous-étape de la compétence d'idée, uniquement après que l'utilisateur ait explicitement opté via AskUserQuestion. Ne jamais s'exécuter seul, jamais s'exécuter sans accord de l'utilisateur. Le point d'entrée prévu est « Étape 4.5 : Mode Brainstorm (Prélude Optionnel) » de la compétence d'idée — consulte la compétence d'idée pour le flux environnant.

Règles strictes

1. Une question à la fois. Chaque appel AskUserQuestion DOIT contenir exactement une entrée de question. Attends la réponse avant de poser la suivante.
2. Choix multiples privilégiés. Encadre chaque question comme 2-4 options si possible. Les réponses ouvertes sont acceptables quand les options seraient prématurées, mais penche vers des choix concrets.
3. Propose 2-3 directions avant d'arrêter la divergence. Dès que la direction des exigences est claire enough pour énumérer, présente 2-3 approches distinctes dans un seul AskUserQuestion. Marque exactement une comme option recommandée selon la convention de recommandation AskUserQuestion de l'outil hôte (la spec ne dicte pas un format de marquage spécifique — suis la documentation de l'outil).
4. Approbation explicite de l'utilisateur requise pour quitter la divergence. N'avance pas vers la synthèse jusqu'à ce que l'utilisateur ait sélectionné l'une des directions proposées.
5. Aucun fichier écrit. N'écris AUCUN markdown, doc de conception, fichier brouillon ou tout autre fichier sur disque. La conversation produit un ElaborationRound et rien d'autre sur disque.
6. Aucun commentaire publié. N'appelle PAS chorus_add_comment depuis cette compétence. Les commentaires appartiennent à la compétence d'idée ou à l'utilisateur, pas à l'étape de brainstorm.
7. Aucun transfert de design-doc. N'invoque AUCUNE compétence dont le but est de produire un document de conception ou un plan d'implémentation. La sortie du brainstorm est le round synthétisé — il n'y a pas de doc séparé.
8. Aucun appel validate_elaboration. N'appelle PAS chorus_pm_validate_elaboration depuis cette compétence. La décision de résoudre l'élaboration ou d'ouvrir un round de suivi (chorus_pm_start_elaboration à nouveau) appartient à la compétence d'idée appelante, pas à cette compétence.

Étape par étape

1. Rassembler le contexte

Avant de poser la première question divergente, lis l'idée et l'état du projet environnant. Reprends la liste gather-context de la compétence d'idée :

chorus_get_idea({ ideaUuid })
chorus_get_documents({ projectUuid })
chorus_get_document({ documentUuid })   # pour tout document méritant une lecture complète
chorus_get_proposals({ projectUuid, status: "approved" })   # pour comprendre les modèles
chorus_list_tasks({ projectUuid })   # pour éviter de dupliquer le travail existant
chorus_get_comments({ targetType: "idea", targetUuid: ideaUuid })

Parcours rapidement chaque résultat pour : les antécédents énoncés, les exigences énoncées, les contraintes énoncées, et ce qui n'est clairement PAS énoncé. Les lacunes sont les questions qui valent la peine d'être posées.

2. Q&R divergent

Pose une question à la fois via AskUserQuestion. Vise à mettre en surface :

• L'objectif que l'idée tente de servir (souvent plus abstrait que l'énoncé de l'idée).
• Les contraintes qui excluent des branches entières de l'espace de solution (délais, compatibilité, portée).
• Les critères de succès — comment l'utilisateur saura que c'est fait.

Garde chaque question à usage unique. Si tu dois poser trois choses, c'est trois rounds, pas un seul AskUserQuestion combiné.

3. Propose 2-3 directions

Quand l'objectif, les contraintes et les critères de succès sont suffisamment clairs pour que tu puisses nommer des approches distinctes, présente-les dans un seul AskUserQuestion :

AskUserQuestion({
  questions: [
    {
      question: "<la question de convergence>",
      header: "<en-tête court>",
      options: [
        { label: "Option A (Recommandée)", description: "<quoi + compromis>" },
        { label: "Option B", description: "<quoi + compromis>" },
        { label: "Option C", description: "<quoi + compromis>" }
      ],
      multiSelect: false
    }
  ]
})

La recommandation doit être visiblement marquée à l'utilisateur en utilisant la convention AskUserQuestion de l'outil hôte. Énonce pourquoi tu la recommandes — généralement une phrase sur le compromis dominant.

4. Attends l'approbation explicite

N'avance pas vers la synthèse si l'utilisateur n'a pas sélectionné l'une des options. Si l'utilisateur choisit « Autre » avec du texte libre, traite cela comme une nouvelle contrainte — reviens à l'étape 2 ou 3 avec la direction affinée.

5. Synthétise la Q&R de point de décision

Pour chaque décision matérielle que l'utilisateur a prise pendant la conversation, construis une ElaborationQuestion. Une « décision matérielle » est un moment où l'utilisateur a choisi entre des alternatives ou défini la portée explicitement. Mappe chaque décision selon la spec de synthèse ci-dessous.

6. Persiste le round

Appelle chorus_pm_start_elaboration avec les questions synthétisées :

chorus_pm_start_elaboration({
  ideaUuid,
  depth: "standard",
  questions: [
    { id: "q1", text: "...", category: "...", options: [...] },
    ...
  ]
})

Puis soumet les réponses en un seul appel :

answer_elaboration({
  ideaUuid,
  roundUuid,
  answers: [
    { questionId: "q1", selectedOptionId: "...", customText: "<rationale>" },
    ...
  ]
})

7. Rends le contrôle

Arrête-toi ici. Ne fais PAS d'appel chorus_pm_validate_elaboration. L'appelant de la compétence d'idée décide maintenant :

• Si les réponses du round synthétisé couvrent tout → l'appelant obtient la confirmation humaine, puis résout avec chorus_pm_validate_elaboration.
• Si des lacunes restent → l'appelant ouvre un Round 2 structuré en appelant chorus_pm_start_elaboration à nouveau.

La profondeur de tout round de suivi est l'appel de l'appelant, pas le tien.

Spec de synthèse

Chaque décision matérielle devient exactement une ElaborationQuestion avec ces champs :

Règles :

• Un customText plus long que ~3 phrases est un signe que tu résumes la transcript au lieu de capturer la rationale. Coupe.
• Un tableau options de longueur 2 avec un encadrement binaire « oui / non » est un signe que tu as pré-restreint les alternatives. Réexamine — il y a généralement au moins trois chemins significativement différents, même si deux d'entre eux se font rejeter rapidement.
• Saute les « décisions » qui n'ont jamais été vraiment contestées. Si l'utilisateur a accepté instantanément la seule proposition, c'est de l'information pour le contenu de l'idée, pas une Q&R de point de décision.

Anti-modèles

Ne fais rien de ce qui suit. Chacun a un mode d'échec spécifique que cette compétence doit prévenir :

• Blob customText d'un seul résumé. Compresser la conversation entière en une seule ElaborationQuestion avec un long résumé markdown dans customText. Le schéma est multi-question pour une raison — préserve la granularité des décisions.
• Transcript-comme-commentaire. Publier le journal de conversation brut comme commentaire sur l'idée (ou n'importe où). Le round synthétisé EST l'artefact. Les transcripts bruts polluent la piste d'audit avec du bruit.
• Écritures de fichiers. Écrire tout markdown, doc de conception, plan ou fichier brouillon sur disque. Il n'y a pas de doc de conception dans ce flux. La sortie du brainstorm est le round synthétisé, pas un document externe.
• Appels validate_elaboration. Fermer la phase d'élaboration depuis cette compétence. La décision de cycle de vie appartient à la compétence d'idée. L'appeler ici dépouille l'appelant de son rôle de scheduler.
• Transfert de design-doc. Invoquer toute compétence qui produit un plan d'implémentation ou un document de conception. Le pipeline Chorus a déjà Proposal → Document Drafts → Task Drafts pour cela — la sortie du brainstorm les traverse via ElaborationRound, pas via des compétences de doc externes.
• Encadrements binaires « oui / non » de longueur 2. Réduire chaque décision à « faire cette chose — oui / non ». Presque toujours les vraies alternatives sont 3+ approches avec des compromis significativement différents. Les encadrements de longueur 2 signifient souvent que la phase divergente s'est terminée trop tôt.
• Poser plusieurs questions dans un seul AskUserQuestion. Le cadence est une question par tour pendant la divergence, puis une question finale de convergence avec 2-3 options. Combiner des questions sans rapport est un signe que tu te précipites.