mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 13:31:43 +02:00
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:
@@ -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.
|
||||
@@ -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 +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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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: <target> / Pourquoi: <reason> / Proposition: <content>"</action>
|
||||
<action if="nothing worth capitalizing">Output explicitly: "Rien à capitaliser pour cette review." — do NOT skip silently</action>
|
||||
@@ -1 +0,0 @@
|
||||
- [ ] Capitalisation Lead_tech outputted — proposals written to `95_a_capitaliser.md` OR explicit "Rien à capitaliser" stated
|
||||
@@ -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>
|
||||
@@ -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: <target> / Pourquoi: <reason> / Proposition: <content>"</action>
|
||||
<action if="nothing worth capitalizing">Output explicitly: "Rien à capitaliser pour cette story." — do NOT skip silently</action>
|
||||
@@ -1 +0,0 @@
|
||||
- [ ] **Capitalisation Lead_tech:** Section "🧠 Capitalisation Lead_tech" outputted — proposals written to `95_a_capitaliser.md` OR explicit "Rien à capitaliser" stated
|
||||
@@ -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>
|
||||
@@ -1,3 +0,0 @@
|
||||
Parallel-safe: false
|
||||
Depends-on: ~
|
||||
Can-run-with: ~
|
||||
Reference in New Issue
Block a user