Déclarez le système une seule fois. Les humains le relisent. Les agents l’opèrent.
Putnami est un modèle de workspace, des primitives de framework pour Go et TypeScript, et une couche de protocoles filaires en dessous. Votre build, votre CI, votre infrastructure et vos agents lisent tous les mêmes contrats — de votre poste jusqu’à la production.
Votre système est réel. Sa description ne l’est pas.
Le système n’existe qu’à l’exécution
De la configuration en cinq dialectes, l’infrastructure dans un autre dépôt, la CI dans le YAML d’un fournisseur. Rien dans git ne dit ce qu’est le système — seulement des fragments de la façon de le reconstruire, si vous la connaissez déjà.Chaque frontière est une convention
La CLI sait ce que le framework émet parce que la même personne a écrit les deux. Ajoutez un langage, un second consommateur ou un agent, et la convention ne vit plus que dans la tête de quelqu’un.La dérive n’est pas non corrigée. Elle est invisible.
Le local, la CI et la production divergent sans bruit, car rien dans le système ne les compare. Vous l’apprenez au pire moment.Les agents savent modifier. Pas opérer.
Un agent peut écrire du code dans votre dépôt. Opérer votre système — connaître le rayon d’impact, lire l’état, annuler une erreur — demande un contrat, et vous n’en avez aucun à lui confier.Une déclaration. Tout ce qui suit la lit.
Vous écrivez l’intention à côté du code qu’elle décrit. Putnami dérive le reste, de façon déterministe, et le publie comme un contrat que tout le monde peut analyser — y compris les outils que vous n’avez pas écrits.
| Vous déclarez | Putnami dérive | Qui le lit |
|---|---|---|
| putnami.json | le graphe du workspace | la CLI, chaque extension, chaque tâche |
| un handler HTTP | un inventaire des routes | votre edge, sous forme d’une liste d’autorisation générée qui refuse par défaut |
| un besoin d’infrastructure, à côté du code | un manifeste fusionné, avec sa provenance | votre cible de déploiement |
| putnami.ci.json | un graphe de jobs validé | tout plan d’exécution — il lit le document, il ne l’élargit jamais |
| une migration, un repository | l’empreinte d’un bundle | les adaptateurs Go et TypeScript, le provisionneur de tests |
| — rien. c’est dérivé | le contexte de l’agent | votre agent, à travers la CLI |
Votre branche est déjà un environnement. Git porte l’intention — ce qui a changé, par qui, par rapport à quoi — et chaque document ci-dessus en est dérivé : une seule structure de workspace, un seul jeu de commandes et un seul jeu de contrats tiennent de votre poste à la CI, jusqu’à ce qui l’exécute. Les prévisualisations et déploiements gérés par branche sont la suite ; rien dans la chaîne n’exige de compte.
Chaque ligne ci-dessus est un protocole filaire : un schéma publié, un corpus d’exemples valides et invalides, et un analyseur strict dans chaque langage qui l’implémente. Lire les protocoles →
Un agent n’a pas besoin qu’on lui explique votre dépôt.
Il lit les mêmes contrats que votre build.
putnami context pack
Un document d’orientation déterministe par projet : identité et graphe de dépendances, racines de composition, références de capacités et de contrats, plages de code représentatives, tests, documentation, provenance. Agrégé par référence — chemins, empreintes et plages, jamais le contenu des fichiers — derrière un contrôle de publication qui échoue fermé. Affiché en lecture seule par la CLI.--impacted
Le rayon d’impact d’un changement, avant que quoi que ce soit n’agisse. Un agent qui sait ce qu’il va toucher est un agent que vous pouvez laisser travailler.--output=json · jsonl
Codes de sortie, modes de sortie et documents machine forment un contrat versionné, pas un détail d’implémentation qui bouge sous un analyseur. Le même corpus valide la CLI Go et la CLI TypeScript.putnami doctor
Des constats de préparation à la production selon un profil de déploiement, une taxonomie figée des codes de contrôle, et une remédiation intégrée à chaque contrôle. « Qu’est-ce qui ne va pas et que dois-je faire » est une donnée, pas de la prose.Un flux d’événements JSONL par job : l’agent qui surveille un build et l’humain qui lit le journal analysent les mêmes lignes.
Un paquet par frontière. Aucune hypothèse partagée.
Les frameworks, l’outillage et la plateforme ne s’intègrent pas par du code partagé. Ils s’intègrent par des protocoles : un schéma publié, un corpus d’exemples valides et invalides, un analyseur strict dans chaque langage qui l’implémente, et au moins un vrai consommateur.
Un protocole sans consommateur est une spécification, pas un contrat.
Le dépôt publie une matrice de conformité — qui implémente ou consomme chaque contrat, et comment c’est vérifié. Elle a trois états, et celui du milieu est publié exprès : testé, aligné à la main (dérive possible), et non consommateur. Une matrice toujours au vert serait du marketing.
Des contraintes, pas des aspirations. Une violation est un bug.
Observable par construction. Chaque runtime émet des signaux structurés par défaut. Le local, la prévisualisation et la production exposent la même forme.
La performance est une contrainte. Les valeurs par défaut doivent tenir la charge de production. Les régressions sont détectables en CI. Les abstractions exposent leur coût.
Déterministe et relisible. Git définit l’intention du système. Les déploiements sont des fonctions pures d’un état versionné. La dérive est détectable.
La sécurité est fondamentale. Les valeurs par défaut sûres sont imposées. Le système échoue fermé. Les chemins dangereux exigent une acceptation explicite.
La propriété des données n’est pas négociable. Les données vivent dans des stockages que vous contrôlez. Les schémas sont versionnés, portables et font partie du contrat.
L’automatisation est un utilisateur de premier rang. La CLI est l’interface principale. Sa sortie est déterministe et lisible par une machine : humains et machines suivent les mêmes règles.
Trois surfaces. Une déclaration.
Putnami
La précision structurelle. Le modèle de workspace, les primitives de framework, la CLI et la couche de protocoles en dessous. Complet en local, sans compte. FSL-1.1-MIT.Putnami Cloud
La profondeur opérationnelle sur les mêmes documents : provenance des releases, corrélation à l’exécution, contexte d’incident, protection des déploiements. Il lit votre inventaire de routes pour construire une liste d’autorisation, votre manifeste d’infrastructure pour provisionner, votre document de CI pour exécuter. Il n’a droit à aucun dialecte privé.Putnami Intelligence
Ce qui est livré aujourd’hui : l’orientation des agents par la CLI, un index versionné du workspace, et le développement piloté par les spécifications — fonctionnalités, specs et architecture enregistrées à côté du code. La boucle de revue et d’audit, avec fraîcheur et preuves sur chaque constat, est la suite. Il fonctionne seul : utile sans les frameworks Putnami comme sans Putnami Cloud.Adopter putnami.dev affine ce qu’Intelligence sait de votre structure. Adopter Cloud approfondit ce qu’il sait de vos opérations. Aucun n’est un prérequis — et Cloud s’intègre par les mêmes contrats publiés que n’importe quel adaptateur tiers. Son avantage est une corrélation sans configuration, pas un canal privé.
L’outillage d’abord. La profondeur du langage quand vous en avez besoin.
Commencez par un workspace.
Tout ce qui précède tourne sur votre machine, sans compte. La plateforme est là quand l’opérer cesse d’être votre travail.