PRD — Meta KG Applications

Problème

Nexus sait déjà construire un Knowledge Graph documentaire autour des sources, documents, requêtes, citations et jobs d’ingestion. En revanche, les applications développées autour de Nexus ou indexées dans Nexus ne sont pas encore représentées comme des systèmes techniques traversables.

Un agent codeur ou un développeur doit encore explorer manuellement les fichiers, endpoints, tables, collections Qdrant, composants frontend, tests, migrations et documents d’architecture.

Objectif produit

Créer dans Nexus un Meta KG Applications capable de représenter la structure technique d’une application, notamment son codebase GitHub, ses données Postgres, ses collections Qdrant, ses services runtime et ses liens avec la documentation Nexus.

Utilisateurs

Cas d’usage prioritaires

1. Analyser l’impact d’une modification d’endpoint.
2. Trouver les fichiers backend/frontend liés à une fonctionnalité.
3. Relier une table Postgres aux fonctions qui la lisent ou l’écrivent.
4. Relier un payload Qdrant aux tables Postgres et aux filtres de recherche.
5. Produire un context pack court pour Codex.
6. Visualiser les dépendances principales d’un repo.
7. Détecter les tests à lancer après modification.
8. Relier les documents d’architecture aux fichiers, endpoints et tables décrits.

Non-objectifs V0

• Ne pas stocker tout le code brut dans Nexus comme corpus documentaire.
• Ne pas remplacer le KG documentaire existant.
• Ne pas créer de routeur d’intention rigide.
• Ne pas faire du MCP le canal principal.
• Ne pas inférer des liens critiques sans preuve.
• Ne pas gérer l’analyse variable-level exhaustive.

Organisation fonctionnelle

source_app = developpement
workspace = application / produit
project = domaine technique ou fonctionnel

Exemple :

source_app: developpement
workspace: Aurora Nexus
project: backend | frontend | ingestion | data | vector | infra | docs

Données de dimensionnement connues

Audit réalisé sur /home/ubuntu/apps/Aurora_rag_public :

Répartition principale par extension :

Conclusion opérationnelle : aucun agent ne doit recevoir le repo complet en prompt. Le système doit produire des context packs courts, fondés sur un graphe dérivé et des preuves.

Critères de succès V0

• Un repo peut être scanné et inventorié.
• Les nœuds principaux code/data/vector sont créés.
• Les relations critiques sont générées avec evidence.
• Un endpoint context-pack retourne un contexte exploitable.
• Une CLI locale peut produire le même context pack.
• Codex peut réduire le nombre de fichiers lus pour une tâche donnée.
• Les permissions Nexus ne sont pas contournées.