mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-08-28 19:20:41 +08:00
Emmanuel Atsé
cede485217
* feat(docs): add sidebar order validator
Adds tools/validate-sidebar-order.js to validate sidebar.order values
in YAML frontmatter across English and translated docs.
Checks for duplicate orders, gaps in sequence, and missing order fields.
For translations, also warns on order drift from English counterparts.
Wired into the quality script as docs:validate-sidebar.
* fix(validate-sidebar): tighten language detection and drift guard, add docstrings
* fix(validate-sidebar): replace subdirectory heuristic with locale pattern matching
detectLanguageDirs() previously classified any top-level docs/ directory
containing subdirectories as a translation language. This was too broad —
if an English section ever gained nested subfolders it would be silently
excluded from validation.
Replaced with a BCP 47 locale-code regex (/^[a-z]{2}(?:-[a-zA-Z]{2})?$/)
that matches known patterns (cs, fr, vi-vn, zh-cn) and won't falsely
classify content sections like explanation/ or reference/.
* fix(validate-sidebar): guard drift check against undefined order values
extractSidebarOrder() returns { hasSidebar: false } when no sidebar block
exists, leaving order as undefined rather than null. The drift check only
guarded against null, allowing undefined values to emit noisy warnings
like "Order drift: ... order undefined".
Changed the guard to typeof === 'number' which correctly excludes both
undefined and null without relying on a specific sentinel value.
* chore(validate-sidebar): add JSDoc docstrings to all functions
Adds @param and @returns annotations to extractSidebarOrder,
detectLanguageDirs, getEnglishSections, checkDirectory,
checkTranslationDrift, and relativePath.
* fix(validate-sidebar): add to pre-commit hook
* refactor(validate-sidebar): harden parsing and edge-case handling
Refactor to main() wrapper with pure return-based APIs, single directory
scan, and shared reporting. Harden frontmatter parsing (anchored delimiter,
direct-child-only order extraction, flow mapping support) and validation
(Infinity/zero guard, gap flood cap, multi-segment locales, graceful ENOENT).
* docs: fix sidebar.order duplicates and gaps across all locales
Resolves all validator errors flagged by the new
tools/validate-sidebar-order.js check.
English (docs/{explanation,how-to,reference}/):
- Renumbered to remove duplicates; established reading order
for new explanation pages added since orders were last set.
Translations (cs, fr, vi-vn, zh-cn):
- Mirrored English structural ordering where files exist, then
compacted to 1..N within each directory to eliminate gaps
caused by missing translation files.
Non-blocking drift warnings remain where translation directories
have fewer files than English; these are expected per the
validator's design.
---------
Co-authored-by: Brian Madison <bmadcode@gmail.com>
65 lines
3.5 KiB
Markdown
65 lines
3.5 KiB
Markdown
---
|
|
title: "Party Mode"
|
|
description: Collaboration multi-agents - regroupez tous vos agents IA dans une seule conversation
|
|
sidebar:
|
|
order: 10
|
|
---
|
|
|
|
Regroupez tous vos agents IA dans une seule conversation.
|
|
|
|
## Qu'est-ce que le Party Mode ?
|
|
|
|
Lancez `bmad-party-mode` et vous avez toute votre équipe IA dans une même pièce - PM, Architecte, Développeur, Designer UX, selon vos besoins. BMad Master orchestre, en sélectionnant les agents pertinents à chaque message. Les agents répondent en personnage, sont en accord ou désaccord, et construisent sur les idées des autres.
|
|
|
|
La conversation continue aussi longtemps que vous le souhaitez. Posez des questions de suivi, remettez en question les réponses, redirigez la discussion - c'est un véritable échange avec vos agents jusqu'à ce que vous ayez terminé.
|
|
|
|
**Idéal pour :**
|
|
|
|
- Les grandes décisions avec des compromis
|
|
- Les sessions de brainstorming
|
|
- Les rétrospectives post-incident quand les choses tournent mal
|
|
- Les rétrospectives de sprint et la planification
|
|
|
|
## Exemples
|
|
|
|
### Remettre en question une mauvaise architecture
|
|
|
|
**Vous :** « Ok l'équipe, notre dernier sprint a été un désastre. Le service d'authentification est tombé trois fois. Qui a cafouillé ? »
|
|
|
|
**Architecte :** « Le design était solide - authentification distribuée avec des fallbacks appropriés. Si l'implémentation a dévié des specs... »
|
|
|
|
**Développeur :** « J'ai suivi le document d'architecture à la lettre. Les specs ne prenaient pas en compte les race conditions lors de l'invalidation de sessions concurrentes. »
|
|
|
|
**PM :** « Vous avez tous les deux raté le vrai problème - nous n'avons pas validé les exigences de gestion des sessions dans le PRD. C'est de ma faute de ne pas l'avoir repéré. »
|
|
|
|
**TEA :** « Et j'aurais dû le repérer dans les tests d'intégration. Les scénarios de test ne couvraient pas l'invalidation concurrente. »
|
|
|
|
### Brainstorming créatif
|
|
|
|
**Vous :** « Comment rendre l'onboarding magique au lieu d'ennuyeux ? »
|
|
|
|
**Designer UX :** « Commençons par la divulgation progressive - révélons les fonctionnalités au fur et à mesure que les utilisateurs en ont besoin, pas d'un coup dans un tutoriel. »
|
|
|
|
**Storyteller :** « Et si l'onboarding était une histoire ? Chaque étape révèle le parcours d'un personnage - l'utilisateur EST le héros. »
|
|
|
|
**Game Designer :** « En partant de là - et si la première "quête" consistait à résoudre un vrai problème utilisateur ? Ils apprennent en faisant quelque chose d'utile. »
|
|
|
|
### Décision technique
|
|
|
|
**Vous :** « Monolithe ou microservices pour le MVP[^1] ? »
|
|
|
|
**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n'avez pas besoin à 1000 utilisateurs. »
|
|
|
|
**PM :** « D'accord. Le time-to-market[^2] compte plus que la scalabilité théorique. »
|
|
|
|
**Développeur :** « Monolithe avec des frontières de modules claires. On pourra extraire des services plus tard si nécessaire. »
|
|
|
|
:::tip[Meilleures décisions]
|
|
De meilleures décisions grâce à des perspectives diverses. Bienvenue dans le party mode.
|
|
:::
|
|
|
|
## Glossaire
|
|
|
|
[^1]: MVP (Minimum Viable Product) : version minimale d'un produit contenant juste assez de fonctionnalités pour être utilisée par des utilisateurs précoces et valider les hypothèses de marché avant d'investir dans un développement plus complet.
|
|
[^2]: Time-to-market : délai nécessaire pour concevoir, développer et lancer un produit sur le marché. Plus ce délai est court, plus l'entreprise peut prendre de l'avance sur ses concurrents.
|