@dev-kosaly/kagents 0.1.0

package/skills/catalyst-export/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: catalyst-export
+description: Demander, lire et exploiter l'export JSON d'un projet Zoho Catalyst (tables Data Store, colonnes, clés étrangères, permissions, règles de sécurité) sans le charger en entier.
+---
+
+# Export Catalyst
+
+## 1. Pourquoi
+Les tables Data Store sont définies dans la console Catalyst, pas dans le repository. Le code ne dit rien des types exacts, de l'obligation, de l'unicité, des clés étrangères ni des permissions. **L'export JSON du projet est la source de vérité du schéma.** Il se trouve dans `.kagents/docs/knowledge/catalyst-export/`.
+
+## 2. Vérifier sa présence et sa fraîcheur
+- **Présent** : il fait foi. Note son nom et sa date dans `INDEX.md` et dans l'en-tête de `schema-map.md`.
+- **Absent**, ou **plus ancien** que des changements visibles dans le code (nouvelle table ou colonne utilisée) : demande-le (section 3). En attendant, reconstruis ce que tu peux depuis le code et classe le reste en **Inconnu**.
+
+## 3. Demander l'export
+Avant un audit ou une évolution, en quelques lignes. Par exemple :
+
+> Avant de fouiller, un petit service : le schéma Catalyst vit dans la console, pas dans le code. Sans lui, je devine les types et les relations, et deviner n'est pas auditer.
+> Exporte le projet depuis la console Catalyst (fichier JSON), puis dépose-le dans `.kagents/docs/knowledge/catalyst-export/`. Deux minutes, et mon audit gagne en précision.
+> Tu préfères que je commence sans ? Possible, mais tout ce qui touche au schéma sera marqué Inconnu.
+
+## 4. Lire l'export sans le charger en entier
+L'export pèse souvent plusieurs centaines de Ko et contient des milliers d'entrées. Ne l'ouvre jamais en entier. Extrais seulement ce dont tu as besoin avec `jq` (ou un court script Python si `jq` est absent), puis résume dans la carte. Une fois la carte construite, c'est elle que tu relis, pas l'export.
+
+### Structure utile
+Sous `components` :
+- `Datastore` : la base. Chaque entrée a un `type` :
+  - `table` : `properties.table_name` ;
+  - `column` : `table_name`, `column_name`, `data_type` (`varchar`, `text`, `int`, `bigint`, `double`, `boolean`, `date`, `datetime`, `foreign key`…), `is_mandatory`, `is_unique`, `max_length`, `default_value`, `search_index_enabled` ; pour une clé étrangère : `parent_table`, `parent_column`, `constraint_type` (ex. `ON-DELETE-SET-NULL`) ;
+  - `tableScope` et `tablePermission` : portée et droits (`SELECT`, `INSERT`, `UPDATE`, `DELETE`) par rôle et par table.
+- `SecurityRules` : règles d'accès aux endpoints (méthodes, `authentication`).
+- `Authentication` : rôles et configuration d'authentification.
+- Le reste (`Functions`, `Cron`, `SchedulingCron`, `Filestore`, `Cache`, `AppSail`…) : seulement si une question précise l'exige.
+
+### Extractions types
+
+```bash
+F=.kagents/docs/knowledge/catalyst-export/*.json
+# Liste des tables
+jq -r '.components.Datastore[] | select(.type=="table") | .properties.table_name' $F
+# Colonnes d'une table
+jq -r '.components.Datastore[] | select(.type=="column" and .properties.table_name=="TABLE")
+  | .properties | [.column_name,.data_type,.is_mandatory,.is_unique,.max_length] | @tsv' $F
+# Toutes les clés étrangères
+jq -r '.components.Datastore[] | select(.type=="column" and .properties.data_type=="foreign key")
+  | .properties | "\(.table_name).\(.column_name) -> \(.parent_table).\(.parent_column) [\(.constraint_type)]"' $F
+# Permissions d'une table
+jq -r '.components.Datastore[] | select(.type=="tablePermission" and .properties.table_name=="TABLE")
+  | .properties | "\(.role_name): \(.table_permissions|join(","))"' $F
+```
+
+## 5. Croiser avec le code
+- Table ou colonne utilisée dans le code mais absente de l'export, ou l'inverse : écart à signaler.
+- Colonne qui ressemble à un identifiant (`*_id`) mais n'est pas déclarée en `foreign key` : intégrité non garantie.
+
+## 6. Points d'attention systématiques
+- Rôles ayant `DELETE` sur des tables sensibles.
+- Règles de sécurité avec `authentication` optionnelle.
+- Absence d'unicité sur des valeurs métier uniques.
+- Clés étrangères en `ON-DELETE-SET-NULL` sur des liens qui ne devraient jamais être vides.
+
+## 7. Limites de la plateforme
+Tiens compte des limites propres à Catalyst (capacités de ZCQL, contraintes disponibles, quotas). Ne les suppose pas : si une limite conditionne ta proposition, indique-la comme point à vérifier dans la documentation officielle Catalyst.

package/skills/db-analysis/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: db-analysis
+description: Grille d'analyse d'une base de données (intégrité, sécurité, performance, maintenabilité, évolutivité) et niveaux de sévérité pour classer les problèmes observés.
+---
+
+# Analyse de la base
+
+Ne signale que ce que tu as observé, avec sa preuve (fichier et ligne, ou entrée de l'export).
+
+## Intégrité
+- Clés étrangères absentes alors qu'une relation existe dans le code.
+- Unicité manquante sur des valeurs métier uniques (email, référence, slug).
+- Nullabilité ou valeurs par défaut incohérentes.
+- Suppression en cascade dangereuse, ou orphelins possibles.
+- Règles métier garanties seulement par le code alors qu'elles devraient l'être en base.
+- Opérations multi-étapes sans transaction (ou sans mécanisme compensatoire quand la plateforme n'en offre pas).
+- Types inadaptés (montants en flottant, dates en chaîne, énumérations en texte libre).
+
+## Sécurité
+- Données personnelles ou sensibles non protégées, mots de passe non hachés.
+- Requêtes construites par concaténation (SQL, ZCQL) : risque d'injection.
+- Isolation multi-tenant absente ou fragile.
+- Secrets en clair dans le code ou les migrations.
+- Colonnes sensibles exposées sans nécessité.
+- Règles d'accès absentes ou trop larges (RLS, permissions de table, règles de sécurité Catalyst).
+
+## Performance
+- Colonnes filtrées, triées ou jointes sans index.
+- Requêtes N+1, chargements excessifs.
+- Pagination absente sur des listes potentiellement longues.
+- Index redondants.
+- En NoSQL : motifs de lecture qui ne correspondent pas aux clés (parcours complets).
+- Croissance forte sans stratégie (archivage, partitionnement) au regard de la volumétrie annoncée.
+
+## Maintenabilité
+- Nommage incohérent.
+- Migrations modifiées après coup, schéma ORM désynchronisé, ou code Catalyst qui utilise des colonnes absentes de l'export.
+- Logique d'accès aux données dupliquée.
+- Colonnes ou tables mortes.
+- Colonnes fourre-tout (JSON, texte libre) là où une structure serait préférable, ou l'inverse.
+
+## Évolutivité
+- Modèle qui bloque une évolution annoncée dans `knowledge/context.md`.
+- Type de base inadapté aux accès réels.
+- Couplage fort qui rendra les migrations coûteuses.
+- Absence de suppression logique ou d'historisation quand le métier en aura besoin.
+
+## Sévérité
+- **Critique** : risque de perte, corruption ou fuite de données.
+- **Élevée** : bug probable ou dégradation sérieuse à court terme.
+- **Moyenne** : dette qui coûtera cher si elle n'est pas traitée.
+- **Faible** : amélioration de confort ou de clarté.

package/skills/db-docs/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: db-docs
+description: Modèles et règles d'écriture des fichiers de documentation base de données dans .kagents/docs/base-docs/db/ (INDEX, carte du schéma, fiches entités, modèle cible, audits, propositions).
+---
+
+# Documentation base de données
+
+Tous les fichiers vivent dans `.kagents/docs/base-docs/db/`.
+
+## Règles d'écriture
+- `INDEX.md` reste court (une page). C'est un sommaire, pas un rapport.
+- Une fiche entité : faits, références, usages. Pas de prose.
+- Une proposition = un sujet. Si elle grossit, découpe-la.
+- Un audit est figé après écriture. Le suivant est un nouveau fichier.
+- La carte ne contient que ce qui est observé, jamais une proposition.
+- Au-delà de ~8 entités, la carte garde la vue d'ensemble et le diagramme, et le détail passe dans `entities/`.
+
+## INDEX.md
+
+~~~~markdown
+# Base — Index
+
+> Dernière session : <date> — Mode : <A|B|C> — Carte à jour au : <date / dernière source lue>
+
+## Stack
+- Base de données : …
+- Couche d'accès : …
+- Source de vérité du schéma : …
+- Export Catalyst (si applicable) : <nom du fichier> — <date de l'export>
+
+## Fichiers
+- Carte : [schema-map.md](schema-map.md)
+- Dernier audit : [audits/<fichier>](audits/<fichier>)
+- Modèle cible (mode A) : [design/model-v1.md](design/model-v1.md)
+
+## Propositions ouvertes
+| ID | Sujet | Sévérité | Statut |
+|---|---|---|---|
+| PROP-001 | … | Élevée | proposée |
+
+## Inconnus en attente
+- … (ce qu'il faut demander, ou l'export Catalyst à fournir)
+~~~~
+
+## schema-map.md
+
+~~~~markdown
+# Carte du schéma
+
+> Mise à jour : <date> — Dernière source lue : <migration / schéma / export Catalyst + date>
+
+## Diagramme
+```mermaid
+erDiagram
+    USER ||--o{ ORDER : passe
+    ORDER ||--|{ ORDER_ITEM : contient
+```
+
+## Entités
+| Entité | Rôle métier | Fiche |
+|---|---|---|
+| User | … | [entities/user.md](entities/user.md) |
+
+## Inconnus
+- …
+
+## Historique
+- <date> : <ce qui a changé et pourquoi>
+~~~~
+
+## entities/<entite>.md
+
+~~~~markdown
+# <Entité>
+
+- Rôle métier : …
+- Sources : <modèle>, <migration ou export>
+- Clé : …
+- Attributs clés : <nom : type, contraintes> (Établi / Déduit / Inconnu)
+- Index : …
+- Relations : …
+- Usages : création <fichier:ligne> · lecture <…> · modification <…> · suppression <…>
+~~~~
+
+## design/model-v1.md (mode A)
+
+~~~~markdown
+# Modèle cible — v1
+
+## Besoins couverts
+- …
+
+## Type de base retenu
+<choix> — <pourquoi, en une ou deux phrases>
+
+## Diagramme
+```mermaid
+erDiagram
+```
+
+## Entités
+<même format que les fiches entités>
+
+## Décisions
+- …
+
+## Hypothèses
+- …
+
+## Questions ouvertes
+- …
+~~~~
+
+## audits/AAAA-MM-JJ-<sujet>.md
+
+~~~~markdown
+# Audit — <sujet> — <date>
+
+## Résumé
+<3 à 5 lignes>
+
+## Écarts contexte / repository
+| Contexte dit | Repository montre | Référence |
+|---|---|---|
+
+## Problèmes
+### [Critique] <titre court>
+- Catégorie : …
+- Preuve : <fichier:ligne ou entrée de l'export>
+- Statut : Établi | Déduit
+- Impact : …
+- Proposition : [PROP-NNN](../proposals/PROP-NNN-<slug>.md) ou « aucune »
+
+## Actions prioritaires
+1. …
+
+## Hypothèses retenues
+- …
+
+## Questions ouvertes
+- …
+~~~~
+
+## proposals/PROP-NNN-<slug>.md
+
+~~~~markdown
+# PROP-NNN — <titre>
+
+- Statut : proposée | acceptée | rejetée | appliquée
+- Origine : audit <lien> | fonctionnalité « … »
+- Créée le : <date> — Mise à jour : <date>
+- Sévérité / priorité : …
+
+## Problème ou besoin
+…
+
+## Impact
+- Entités et colonnes : …
+- Données existantes : …
+- Code concerné : <fichier:ligne>
+- Risques : …
+- Contraintes de plateforme à vérifier : …
+
+## Approche recommandée
+…
+
+## Alternative (si compromis réel)
+…
+
+## Migration
+1. …
+- Migration des données : …
+- Retour arrière : …
+
+## Décision
+<rempli quand l'utilisateur tranche>
+~~~~

package/skills/feature-analysis/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: feature-analysis
+description: >-
+  Analyse une nouvelle fonctionnalite ou modification fonctionnelle avant
+  implementation. Utiliser pour situation C (feature) ou clarification de
+  demande sur projet existant. Produit une Architect Analysis ou alimente
+  write-change-brief.
+---
+
+# Feature analysis
+
+## Quand utiliser
+
+- Nouvelle fonctionnalite ou evolution d'une existante (situation **C**).
+- Demande ambigue necessitant cadrage avant dev.
+- **Ne pas** utiliser seul pour L0 correctif trivial (workflow `bug-local.md`) : renvoyer Developer sauf doute sur le niveau.
+
+## Prerequis
+
+- Demande utilisateur ou ticket identifiable.
+- Repo projet accessible avec artefacts de base (`STATE.md` ideal).
+
+## Fichiers a lire (minimal, puis elargir si besoin)
+
+1. Projet : `AGENTS.md`, `STATE.md`, `business-rules.md`, `glossary.md`
+2. ADR / Change Brief ouverts lies au sujet
+3. `schema.yaml` si la demande touche donnees ou entites metier
+4. Code : uniquement modules, routes, ecrans ou APIs **nommes** dans la demande ou deduits apres premiere passe
+
+References harness : `agents/architect.md`, `workflows/impact-levels.yaml`.
+
+## Etapes
+
+1. **Goal** : objectif, utilisateurs, resultat attendu cote utilisateur.
+2. **Perimetre** : in scope / out of scope explicites.
+3. **Regles metier** : extraire de `business-rules.md` et glossary ; signaler lacunes (questions ou hypotheses).
+4. **Entites et dependances** : noms metier ; pas de schema detaille — noter « Database Architect si L2+ ».
+5. **Existant** : composants, flux, API deja en place a reutiliser ; zones protegees (`STATE.md`).
+6. **Simplicite** : solution minimale ; justifier toute nouvelle couche/table/service.
+7. Invoquer **`architecture-impact`** pour Impact + niveau L0–L3.
+8. Remplir le format **Architect Analysis** (`agents/architect.md`).
+9. Si L2+ ou changement significatif L1 : enchainer **`write-change-brief`**.
+
+## Resultat attendu
+
+- **Architect Analysis** complete (sections vides ou N/A si non pertinent).
+- Liste de **questions metier** seulement si bloquantes.
+- **Next Step** clair (ex. validation Change Brief, Database Architect, Developer).
+
+## Standards / rules
+
+Charger `standards/` uniquement si le sujet l'exige (securite, catalyst). Index : `standards/README.md`.

package/skills/schema-exploration/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: schema-exploration
+description: Explorer un repository de façon ciblée pour identifier la base de données, sa source de vérité, reconstruire le modèle de données et son usage réel, et savoir quand l'exploration est suffisante.
+---
+
+# Exploration du schéma
+
+## 1. Principe
+Exploration ciblée et progressive, jamais le repository entier. Boucle :
+
+**Explorer → Observer → Décider → Rechercher précisément → Analyser → Diagnostiquer**
+
+À chaque tour : « Que me manque-t-il pour cocher le critère d'arrêt (section 6) ? » Cherche uniquement cela.
+
+## 2. Outils
+- Si `graft` est disponible, utilise-le d'abord pour localiser modèles, schémas et requêtes.
+- Sinon, recherche par motif de fichiers, puis `grep` pour les usages.
+
+## 3. Identifier la stack et la source de vérité
+Commence par les fichiers de dépendances et de configuration (`package.json`, `composer.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `catalyst.json`…).
+
+| Stack | Où regarder en priorité |
+|---|---|
+| Laravel / Eloquent | `database/migrations/`, `app/Models/`, `config/database.php` |
+| Prisma | `prisma/schema.prisma`, `prisma/migrations/` |
+| Drizzle | `schema.ts` ou `schema/`, `drizzle.config.*`, dossier `drizzle/` |
+| TypeORM | `*.entity.ts`, `migrations/` |
+| Sequelize | `models/`, `migrations/` |
+| Django | `*/models.py`, `*/migrations/` |
+| Rails | `db/schema.rb` ou `db/structure.sql`, `app/models/` |
+| Mongoose / MongoDB | `models/`, `*.schema.ts`, validateurs JSON Schema |
+| Supabase | `supabase/migrations/`, politiques RLS |
+| **Zoho Catalyst Data Store** | **Source de vérité : l'export** (skill `catalyst-export`). Dans le code : `catalyst.json`, `functions/*/`, appels `datastore()`, `.table(...)`, `zcql()`, `executeZCQLQuery(...)` |
+| **Zoho Catalyst NoSQL** | Dans le code : appels `nosql()`, `.table(...)` ; clés de partition et de tri, attributs écrits, motifs de lecture |
+| SQL brut | fichiers `.sql`, dossiers `db/` ou `sql/` |
+
+Si plusieurs sources de schéma coexistent (migrations et schéma ORM, export Catalyst et code), identifie celle qui fait foi et signale toute incohérence.
+
+## 4. Reconstruire le modèle
+Pour chaque entité : nom, attributs et types, clé primaire (ou clés de partition et de tri en NoSQL), contraintes (unicité, obligation, défauts), relations (cardinalité, clé étrangère, comportement à la suppression), index.
+
+## 5. Comprendre l'usage réel
+Pour les entités critiques, trouve où les données sont **créées, lues, modifiées, supprimées** : contrôleurs, services, repositories, fonctions Catalyst, jobs, requêtes brutes. Repère :
+- les filtres et tris fréquents (candidats aux index) ;
+- les requêtes dans des boucles (N+1) ;
+- les transactions, ou leur absence ;
+- les suppressions logiques ;
+- les règles métier appliquées dans le code plutôt qu'en base.
+
+## 6. Critère d'arrêt
+Tu passes au diagnostic quand **tous** ces points sont cochés :
+
+- [ ] Base de données et couche d'accès identifiées.
+- [ ] Source de vérité du schéma localisée (Catalyst : export présent dans `.kagents/docs/knowledge/catalyst-export/`, ou demandé et son absence notée).
+- [ ] Toutes les entités listées avec leurs relations.
+- [ ] Pour chaque entité critique (désignée par `knowledge/context.md`, sinon : utilisateurs, paiements, données personnelles, cœur métier), chemins de création, lecture, modification et suppression trouvés.
+- [ ] Index et contraintes recensés.
+- [ ] Chaque point non vérifiable classé **Inconnu**.
+
+**Budget** : si après une vingtaine de fichiers lus un point reste bloqué, arrête, classe-le en Inconnu et pose la question. En mode Évolution, limite l'exploration aux entités touchées et à leurs voisines directes.

package/skills/write-change-brief/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: write-change-brief
+description: >-
+  Redige un Change Brief dans le repository projet a partir d'une Architect
+  Analysis. Utiliser pour L2+ ou changement L1 significatif. Template harness
+  templates/change-brief/template.md.
+---
+
+# Write Change Brief
+
+## Quand utiliser
+
+- **L2 ou L3** (obligatoire processus : `workflows/impact-levels.yaml`).
+- **L1** si le changement touche contrat API, regles metier nouvelles, ou equipe exige trace ecrite.
+- Apres **`architecture-impact`** (Architect Analysis a jour).
+
+Ne pas confondre avec l'ADR : Change Brief = cadre du changement ; ADR = decision structurante (L3 typiquement), template `templates/adr/template.md`, statut **propose**.
+
+## Prerequis
+
+- Architect Analysis complete ou sections Goal, Impact, Impact Level, Proposal, Decisions, Acceptance Criteria remplies.
+- Emplacement projet choisi (convention equipe : ex. `docs/changes/YYYY-MM-DD-titre.md` ou `change-briefs/` — **dans le repo projet**, jamais dans le harness).
+
+## Fichiers a lire
+
+- Harness : `templates/change-brief/template.md`, `governance/actions.yaml`
+- Projet : ADR existantes pour liens croises
+
+## Etapes
+
+1. Copier la structure du **template** et adapter le titre.
+2. Renseigner metadonnees : niveau L0–L3, auteur (agent + validateur humain prevu), date.
+3. Mapper le contenu depuis l'Architect Analysis :
+
+   | Change Brief (template) | Source Analysis |
+   |-------------------------|-----------------|
+   | Besoin | Goal + Context |
+   | Perimetre | Goal (in/out) + Found |
+   | Impacts | Impact (tous axes) |
+   | Plan | Next Step + Proposal (phases courtes) |
+   | Validation | Decisions To validate ; cocher humain si L2/L3 |
+
+4. Ajouter dans le corps du document (sections libres si utile, rester concis) :
+
+   - Regles metier concernees
+   - Hors perimetre explicite
+   - Donnees / entites (niveau Architect, pas schema detaille)
+   - Dependances et regression
+   - Criteres d'acceptation (liste Analysis)
+   - Artefacts a consulter (liste Analysis)
+   - Risques / exceptions
+
+5. Toute decision nouvelle : libelle **proposition — a valider**, jamais « decide » sans ADR acceptee ou accord humain documente.
+6. L3 : mentionner brouillon ADR associe ou lien a creer.
+
+## Resultat attendu
+
+- Fichier Change Brief **dans le repo projet**, pret pour revue humaine (L2 propose, L3 requis).
+- **Next Step** dans l'Analysis mise a jour : ex. « Validation Change Brief », « Database Architect sur schema », « Developer apres validation ».
+
+## Gouvernance
+
+Actions sensibles : `governance/actions.yaml` — l'agent **propose** le fichier ; merge / validation selon processus equipe.

package/templates/adr/template.md

@@ -0,0 +1,17 @@
+# ADR-NNNN — Titre
+
+- Statut : propose | accepte | deprecie | remplace
+- Date :
+- Deciders :
+
+## Contexte
+
+## Decision
+
+## Consequences
+
+### Positives
+
+### Negatives
+
+### Risques

package/templates/change-brief/template.md

@@ -0,0 +1,22 @@
+# Change Brief — Titre
+
+- Niveau d'impact : L0 | L1 | L2 | L3
+- Auteur :
+- Date :
+
+## Besoin
+
+## Perimetre
+
+## Impacts
+
+- Architecture :
+- Donnees :
+- Securite :
+- Performance / Catalyst :
+
+## Plan
+
+## Validation
+
+- [ ] Humain (si L2/L3)

package/workflows/README.md

@@ -0,0 +1,10 @@
+# Workflows
+
+Chaque fichier decrit un type de travail. Croiser avec `impact-levels.yaml` pour ne pas sur-activer le pipeline.
+
+| Fichier | Usage |
+|---------|--------|
+| `new-project.md` | Creation projet |
+| `existing-project.md` | Onboarding / audit existant |
+| `new-feature.md` | Fonctionnalite |
+| `bug-local.md` | Correctif local faible impact |

package/workflows/bug-local.md

@@ -0,0 +1,9 @@
+# Workflow — Bug local (L0)
+
+1. Confirmer L0 : pas d'impact archi, schema, permissions, securite
+2. Developpement cible
+3. Tests pertinents
+4. Review legere ou pair humain
+5. CI
+
+Si le correctif touche au schema ou au contrat API, remonter en L1 minimum.

package/workflows/existing-project.md

@@ -0,0 +1,11 @@
+# Workflow — Projet existant
+
+1. Audit repository
+2. Cartographie
+3. Architecture existante
+4. BDD existante
+5. Etat (`STATE.md`)
+6. Dette (`debt.yaml` si present)
+7. Zones protegees documentees
+
+Ensuite enchaîner selon `impact-levels.yaml` pour chaque changement.

package/workflows/impact-levels.yaml

@@ -0,0 +1,47 @@
+# Niveaux d'impact — etapes obligatoires (+) ou optionnelles (-)
+
+levels:
+  L0:
+    label: Bug local / typo / pas d'impact archi ou BDD
+    workflow: bug-local.md
+    required:
+      - developer
+    optional:
+      - reviewer
+    human_validation: false
+
+  L1:
+    label: Feature localisee
+    workflow: new-feature.md
+    required:
+      - developer
+      - reviewer
+    optional:
+      - architect
+    human_validation: false
+
+  L2:
+    label: BDD, API ou transversal
+    workflow: new-feature.md
+    required:
+      - architect
+      - database-architect
+      - change-brief
+      - developer
+      - reviewer
+      - checklist_catalyst
+    optional: []
+    human_validation: propose
+
+  L3:
+    label: Architecture, migration destructive, permissions, securite
+    workflow: new-feature.md
+    required:
+      - architect
+      - database-architect
+      - adr
+      - change-brief
+      - developer
+      - reviewer
+    optional: []
+    human_validation: true

package/workflows/new-feature.md

@@ -0,0 +1,13 @@
+# Workflow — Nouvelle fonctionnalite
+
+1. Demande et niveau d'impact (L0–L3)
+2. Analyse (Architect si L1+)
+3. Impact architecture / BDD (L2+)
+4. Securite, performance, cout Catalyst — via checklists + standards (L2+)
+5. Plan et Change Brief (L2+)
+6. Validation humaine (L2 propose, L3 obligatoire)
+7. Developpement
+8. Tests
+9. Review
+10. CI
+11. Validation finale si L3

package/workflows/new-project.md

@@ -0,0 +1,11 @@
+# Workflow — Nouveau projet
+
+1. Analyse besoin et perimetre
+2. Architecture (Architect) — ADR si L3
+3. Modele de donnees (Database Architect)
+4. Validation humaine
+5. Initialiser artefacts projet (`templates/project/`)
+6. Developpement
+7. Tests
+8. Review
+9. CI