Grace

Roadmap

D'où ça vient, où on en est, ce qui reste.

La réunion fondatrice (19/06/2026)

Grace V2 a été relancé « from scratch » comme talent manager. Décisions actées : talent = documentation indexée (pas des prompts) ; structure atomique → composite → persona ; graphe de connaissances entre talents ; model-agnostic ; config locale .grace/ + catalogue global.

Tensions identifiées (qui ont guidé ce POC) :

  1. Le graphe ne doit pas « gater » l'accès → il sert l'assemblage et la cohérence.
  2. Le framing « package manager / semver » est un piège de scope → ne pas bâtir npm avant 3 talents.
  3. « Model-agnostic » est vrai au format, faux au runtime : la résolution dynamique exige un adaptateur par harness (hook, MCP…).
  4. Risque de recréer le « gros CLAUDE.md » → le levier est l'altitude.
  5. La validation est le vrai sujet dur → remonter les prompt-tests tôt.
  6. « Grace remplace la CI » mélange deux produits → séparer builder vs validator.

Où on en est

Ce dépôt est le POC plateforme qui matérialise plusieurs recos via la voie MCP :

  • POC complet (7 étapes) : monorepo + docker-compose → DB Postgres → backend NestJS → serveur MCP → dashboard multi-projets → boucle de bout en bout + enregistrement dans Claude Code.

  • Rapprochement moteur ↔ schéma (Lots 1-3) : le moteur consomme la quasi-totalité du schéma de talent (rôles, priorité, activation, altitudes, recommends, validation typée + sévérités, personas, runner de prompt-tests).

  • Pertinence sémantique, tracing & personas custom : filtrage du resolve par embeddings (GRACE_RELEVANCE), journal d'activité (trace_events) et CRUD de personas depuis le dashboard.

Catalogue : 17 talents (4 architecture, 8 ddd, 3 testing, 1 product, 1 refactoring)

  • persona Software Craftsman. Le graphe de dépendances est complet : tous les prérequis référencés par requires/includes existent au catalogue (le doctor ne signale plus de manquant).

Ce qui manque

Les 9 prérequis atomiques historiquement manquants ont tous été écrits (architecture.dependency-rule, architecture.port-adapter, ddd.ubiquitous-language, ddd.entity, ddd.aggregate, ddd.domain-event, ddd.repository, ddd.domain-service, product.acceptance-criteria).

Au-delà du POC, la registry hoppr-talents a un backlog de ~53 talents sur 5 profils (craft / devops / front / infra / platform), dont 7 en P0.

Prochaines étapes possibles

  • Étoffer le catalogue au-delà des 17 talents (le graphe est complet ; viser la profondeur). La liste priorisée des talents à développer est sur Roadmap des talents.
  • Cleanup du schéma : graph.yml et prompts/ supprimés (non lus) ; reste à trancher outputs.
  • Exécuter les prompt-tests en CI (le runner existe, requiert une clé API).
  • Auth multitenant par organisation livrée (Better Auth : e-mail/mot de passe, Google, SSO OIDC/SAML par organisation ; approbation admin pour l'accès MCP ; multi-org / multi-session ; migration TypeORM → Drizzle). Reste le déploiement VPS réel et le durcissement continu (audit, notifications).
  • Voie fichiers en parallèle : export multi-cible (grace buildCLAUDE.md / AGENTS.md).

On this page