feat: carcasse BMAD centralisée avec symlinks + nettoyage post-install

- Ajout de 80_bmad/base/ : carcasse BMAD centralisée (agents, workflows, skills)
- bmad-init-project.sh : symlinke core/bmm/cis/tea/_config/.agents/.claude, copie _memory localement, crée _bmad-output/
- BMAD_BASE résolu via SCRIPT_DIR (compatible Mac/NUC sans chemin hardcodé)
- Suppression de post-bmad-install.sh et ses templates (obsolètes avec la carcasse centralisée)
- Nettoyage aliases.sh : suppression post-bmad-install et bmad-install
This commit is contained in:
MaksTinyWorkshop
2026-03-11 11:28:19 +01:00
parent 863d4927d4
commit 72958b4335
20 changed files with 0 additions and 451 deletions

View File

@@ -1,30 +0,0 @@
---
# Capitalisation vers Lead_tech
Quand un apprentissage émerge (bug difficile, pattern réutilisable, anti-pattern, décision d'archi),
l'écrire dans la zone tampon Lead_tech :
```
~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md
```
Sur le NUC : `/srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md`
Format :
```
DATE — __PROJECT_NAME__
FILE_UPDATE_PROPOSAL
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Pourquoi :
<raison en 1-2 phrases>
Proposition :
<contenu suggéré>
```
Règle : écrire dans `95_a_capitaliser.md` uniquement. Jamais directement dans les fichiers Lead_tech validés.

View File

@@ -1,11 +0,0 @@
bmm-dev dev_implementation
bmm-architect architect
bmm-sm sm
bmm-qa qa
bmm-quick-flow-solo-dev dev_implementation
bmm-analyst analyst
bmm-pm pm
bmm-tech-writer tech_writer
bmm-ux-designer ux_designer
tea-tea qa
core-bmad-master core_bmad_master
1 bmm-dev dev_implementation
2 bmm-architect architect
3 bmm-sm sm
4 bmm-qa qa
5 bmm-quick-flow-solo-dev dev_implementation
6 bmm-analyst analyst
7 bmm-pm pm
8 bmm-tech-writer tech_writer
9 bmm-ux-designer ux_designer
10 tea-tea qa
11 core-bmad-master core_bmad_master

View File

@@ -1 +0,0 @@
When a reusable analysis pattern, requirements anti-pattern, or domain insight emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <10_product_patterns_valides.md | 10_backend_patterns_valides.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during architecture or technical design, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <40_decisions_et_archi.md | 10_backend_patterns_valides.md | 10_backend_risques_et_vigilance.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
As the orchestrating agent, when any cross-cutting pattern, process improvement, recurring friction, or architectural decision emerges across the project, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_product_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a product decision, prioritization pattern, or recurring friction is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <10_product_patterns_valides.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a reusable test pattern, tricky bug, or quality anti-pattern is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a process improvement, recurring friction, or architecture decision emerges during sprint work, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a reusable documentation pattern, writing convention, or recurring documentation friction emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <10_conventions_redaction.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1 +0,0 @@
When a reusable UX/UI pattern, interaction anti-pattern, or UX decision emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: <10_ux_patterns_valides.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files.

View File

@@ -1,8 +0,0 @@
<!-- Capitalisation Lead_tech -->
<critical>You MUST output this section — do NOT skip it silently</critical>
<output>## 🧠 Capitalisation Lead_tech
Review all findings for: anti-patterns found, recurring issues, architecture decisions confirmed or invalidated during this review.
</output>
<action>For EACH candidate (aim for 1-3): write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ONLY — NEVER inside the project repo. FORMAT = "DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: &lt;target&gt; / Pourquoi: &lt;reason&gt; / Proposition: &lt;content&gt;"</action>
<action if="nothing worth capitalizing">Output explicitly: "Rien à capitaliser pour cette review." — do NOT skip silently</action>

View File

@@ -1 +0,0 @@
- [ ] Capitalisation Lead_tech outputted — proposals written to `95_a_capitaliser.md` OR explicit "Rien à capitaliser" stated

View File

@@ -1,6 +0,0 @@
<!-- Story parallelization metadata -->
<critical>Every created story must explicitly define its parallelization metadata.</critical>
<action>Set `Parallel-safe`, `Depends-on`, and `Can-run-with` in the story header based on real technical dependencies, not optimism.</action>
<action>If the story depends on non-merged code from another story, set `Parallel-safe: false` and fill `Depends-on` explicitly.</action>
<action>Use `Can-run-with` only for stories that can be developed in parallel without merge or logic conflicts.</action>
<action>If multiple stories are technically linked, keep them on the same branch until they are independently testable, reviewable, and mergeable.</action>

View File

@@ -1,8 +0,0 @@
<!-- Capitalisation Lead_tech -->
<critical>You MUST output this section — do NOT skip it silently</critical>
<output>## 🧠 Capitalisation Lead_tech
Review the full implementation for: reusable patterns, difficult bug fixes, anti-patterns, architecture decisions, or subtle nuances discovered during this story.
</output>
<action>For EACH candidate (aim for 1-3): write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ONLY — NEVER inside the project repo. FORMAT = "DATE — __PROJECT_NAME__ / FILE_UPDATE_PROPOSAL / Fichier cible: &lt;target&gt; / Pourquoi: &lt;reason&gt; / Proposition: &lt;content&gt;"</action>
<action if="nothing worth capitalizing">Output explicitly: "Rien à capitaliser pour cette story." — do NOT skip silently</action>

View File

@@ -1 +0,0 @@
- [ ] **Capitalisation Lead_tech:** Section "🧠 Capitalisation Lead_tech" outputted — proposals written to `95_a_capitaliser.md` OR explicit "Rien à capitaliser" stated

View File

@@ -1,3 +0,0 @@
<!-- Story parallelization check -->
<action>Before implementation, read `Parallel-safe`, `Depends-on`, and `Can-run-with` from the story file.</action>
<action>If metadata conflicts with the actual code state or branch reality, stop and reconcile the story before coding.</action>

View File

@@ -1,3 +0,0 @@
Parallel-safe: false
Depends-on: ~
Can-run-with: ~