Aller au contenu principal
REALIZED.DEV
Réserver un atelier

Architecture de la plateforme · Le harness d'ingénierie · Exécution déterministe

Ne devinez plus ce que votre IA construit.
Spécifiez l'architecture.

Les assistants de programmation IA classiques fonctionnent comme des boîtes noires : ils injectent du code non vérifié et accumulent une lourde dette de contexte. La plateforme Realized.Dev remplace ce chaos par un harness d'ingénierie déterministe à plusieurs agents.

Réserver une revue d'architecture Lire la note de sécurité

v1.0 — Le moteur déterministe

Spécification
La spec fait loi

Consignée dans Git et l'historique des pull requests

TDD
Red → Green

Un test qui échoue avant le code

Comment ça marche

Trois couches. Un contrat applicable.

Nous retirons l'autonomie à la couche d'exécution pour la confier à la spécification. Les règles du harness exigent une spécification acceptée et un test qui échoue avant toute implémentation. Le harness inclut des hooks qui vérifient les actions des agents, et nous les renforçons pour les exécutions cloud.

  1. L1

    Le harness

    Contraintes en lecture seule

    • Modes plan en lecture seule
    • Plans d'exécution explicites
    • Aucune mutation du dépôt
  2. L2

    Le Manager

    Gestion du backlog

    • File de travail locale
    • Audits de spec en lecture seule, à la demande
    • Plans prêts à exécuter
  3. L3

    La Main-d'œuvre

    Exécution parallèle

    • Vagues de sous-agents parallèles
    • Une branche par élément
    • Contrôle d'intake des PR cloud. Une personne approuve chaque fusion.

Le harness d'ingénierie

Exécution déterministe.

3 / 3

HARNESS 01

L'orchestrateur TDD

Délègue le travail à des sous-agents isolés pour les étapes red, green et refactor, avec les tests en premier dès la conception.

HARNESS 02

Contrôles qualité automatisés

Des contrôles QA automatisés vérifient que le code livré passe les tests avant toute opération de gestion de versions.

HARNESS 03

Pare-feu de fusion

Le harness inclut des hooks qui vérifient les actions des agents, et nous les renforçons pour les exécutions cloud. /intake vérifie les pull requests cloud dans un worktree isolé. Les agents ouvrent des pull requests en brouillon. Une personne approuve chaque fusion.

Philosophie centrale · La spec fait loi

La spécification est votre unique référence, consignée dans Git et l'historique des pull requests.

Le répertoire des spécifications, et non l'historique du chat, détermine ce qui est terminé. Les modifications sont vérifiées au regard de ces spécifications avant d'atteindre votre branche principale.

Pratiques courantes du secteur

  • Exécution en boîte noire→ vérifié
  • Corrections après génération→ vérifié
  • Frais d'API par token→ vérifié
  • Injection de code non vérifié→ vérifié

Plateforme Realized.Dev

  • Boucles TDD strictes→ vérifié
  • Tests de base de données uniquement en local→ vérifié
  • Critères d'acceptation conditionnés par la spec→ vérifié

Le harness

  • Modes plan en lecture seule→ vérifié
  • Contrôles QA automatisés→ vérifié
  • Vérifications de traçabilité→ vérifié
  • PR en brouillon ; une personne approuve chaque fusion→ vérifié

La limite

  • Aucune transmission en continu à des tiers→ vérifié

Étape suivante

Parcourez le harness avec notre équipe d'architecture.

90 minutes. Vos responsables ingénierie et sécurité. À l'issue, un pipeline candidat cadré pour la Phase 01 — pas une démonstration sur diapositives.

Découvrir le harness Realized.dev— Une publication du harness est à l'étudeGuide d'architecture
Réserver une revue d'architecture Matrice de conformité