Blueprint et Programme Genesis
Le Blueprint et le Programme sont des explications maintenues, et non une preuve, une propriété ou un modèle sémantique exhaustif.
Blueprint
genesis/blueprint.md est une description courte, cohérente et non technique de ce que le produit devrait faire. Privilégiez l'intention explicite de l'utilisateur. Ne mentionnez pas les frameworks, packages, orthographes de routes, schémas, fichiers sources, plans d'implémentation, tests ou architecture privée.
Mettez à jour le Blueprint après l'implémentation uniquement lorsque le changement ajoute, supprime ou modifie intentionnellement le comportement observable du produit. Ne faites jamais d'un accident, d'un bug, d'un choix de conception privé ou d'une ambiguïté une intention du produit.
Programme
Organisez le Programme dans des répertoires lisibles ; l'appartenance est déclarée uniquement dans genesis/subsystems.md, indépendamment des noms de répertoires :
genesis/program/billing/invoices.md
genesis/program/authentication/sessions.md
Créez un module pour chaque opération publique significative fournie par un sous-système, indépendamment du langage ou de la disposition des sources. Les opérations publiques incluent les fonctions ou méthodes exportées, les actions d'API, les commandes, les opérations d'interface utilisateur et autres points d'entrée observables. Ne reflétez pas les fichiers sources et ne documentez pas chaque assistant.
Chaque module contient :
# Nom de frontière lisible par l'humain
Une courte explication de pourquoi la frontière existe.
## Sources
- Principale : `chemin/exact/auteur/source/principale`
- `chemin/exact/auteur/source/support`
## Contrat public
Entrées, sorties, effets, échecs et garanties significatifs.
Chaque module nécessite exactement une puce - Principale : source. Choisissez la source principale explicitement comme l'endroit où commencer la lecture de l'implémentation ; elle n'a pas besoin d'être un point d'entrée exécutable. Elle doit appartenir au sous-système propriétaire du module, en respectant les propriétaires de répertoires imbriqués plus spécifiques. Les autres sources peuvent citer des bibliothèques partagées dans d'autres sous-systèmes. Ne déduisez jamais le fichier principal de l'ordre de la liste des sources, des imports ou des noms de fichiers. Lors de la réconciliation de modules plus anciens, inspectez la source et marquez l'ancre explicitement ; l'indexation ne vous en attribue pas une.
Une section ## Carte d'implémentation facultative peut nommer uniquement les assistants privés ou les coutures qui aident matériellement un futur agent à modifier, tracer ou déboguer l'opération. Elle est informative, et non une garantie publique. Les tests sont des preuves et jamais des Sources d'implémentation.
Préférez moins de modules, plus clairs. Supprimez les explications obsolètes et redondantes. Une source peut prendre en charge plusieurs opérations ; les fichiers d'assistance et de colle peuvent n'apparaître dans aucun module du Programme.
Limites de la tâche
L'appelant détermine s'il s'agit d'une description initiale, d'une actualisation complète du Programme, d'une réconciliation post-changement ciblée, d'un travail uniquement sur le Blueprint, ou d'une révision en lecture seule. Respectez la limite d'édition de l'appelant. Signalez l'ambiguïté plutôt que d'inventer une intention.
Sous-systèmes
Maintenez genesis/subsystems.md parallèlement au Programme lors des travaux de description et d'actualisation. Le travail uniquement sur le Blueprint ne modifie pas la carte ; la révision reste en lecture seule. La carte est l'autorité d'association rédigée, mais les responsabilités et les références de table restent des explications faillibles du code source et du schéma de l'application.
Utilisez cette grammaire exacte de version zéro :
# Sous-systèmes
## `forms` Forms
Possède le rendu de formulaires réutilisables, la validation et la capture de soumission.
### Source
- Répertoire `packages/forms`
### Programme
- `genesis/program/forms/render.md`
### Données possédées
- Table `database` `default` `form_definitions`
### Données utilisées
- Rien.
Utilisez un identifiant stable en minuscules avec trait d'union et un titre lisible par l'humain par sous-système. Chaque entrée nécessite un texte de responsabilité et les sections Programme, Données possédées et Données utilisées. Le texte de responsabilité est l'explication complète du sous-système, pas une légende de carte. Expliquez son objectif, sa portée, ses parties importantes et sa collaboration avec d'autres propriétaires. Préservez les descriptions existantes substantielles ; ne les remplacez pas par des étiquettes d'une ligne pour convenir à une visualisation. Un consommateur peut raccourcir l'aperçu affiché. Les répertoires de support simples peuvent nécessiter seulement une courte explication.
La section Source requise contient exactement une entrée - Répertoire avec un chemin entre backticks : un répertoire canonique relatif au projet, . étant autorisé pour la racine du projet. Chaque sous-système a une racine de répertoire ; ne déclarez jamais de racines dispersées ou multiples. Les règles de répertoire parent empilé découvrent les racines de sous-système par défaut mais ne sont pas exhaustives. Un agent peut reconnaître et déclarer une autre racine ailleurs à partir de la responsabilité réelle et des preuves source. La déclaration rédigée persiste lors de l'indexation ordinaire. La carte rédigée est la liste des propriétaires canonique une fois prête ; les racines Stack sont des indices d'adoption et ne créent jamais de propriétaires supplémentaires ni ne divisent une frontière rédigée. Couvrez chaque source indexée, en utilisant un propriétaire racine du projet pour les fichiers de support restants si nécessaire. Les composants d'interface utilisateur et le code Engine peuvent partager une racine ; la projection UI ne change pas la propriété. Les sections vides disent - Rien. ; une nouvelle carte vide contient uniquement # Sous-systèmes et - Rien.. Chaque module du Programme appartient exactement à un sous-système. Les noms de répertoires du Programme n'attribuent pas de propriété. Les sources peuvent citer les bibliothèques d'un autre sous-système sans donner à l'opération ou à l'implémentation deux propriétaires. N'utilisez pas de globs, d'opérations en double ou de propriétaires de table en double.
Lors de la régénération ou du fractionnement délibéré de la carte, réconciliez les explications avec les nouveaux propriétaires de répertoires. Transférez ensemble le texte de responsabilité applicable et les affectations explicites du Programme, en préservant les identifiants stables lorsque la frontière est inchangée. Revérifiez la source principale requise de chaque Programme par rapport à son propriétaire actuel, y compris les propriétaires imbriqués ; les références de bibliothèque conservent leur propre propriété. Utilisez les déclarations actuelles plutôt que les noms codés en dur, la disposition des répertoires ou la liste en cache d'un consommateur antérieur. Inspectez les sous-systèmes et le Programme et résolvez les adhésions manquantes/dupliquées et les ancres principales invalides avant de prétendre à l'achèvement.
Une identité de table est constituée de trois valeurs exactes séparées par des backticks : l'identifiant de ressource Stack déclaré, le schéma et la table. default signifie le schéma par défaut de la ressource ; utilisez un schéma explicite le cas échéant. N'enregistrez jamais de nom de base de données hôte, de credential, d'expression SQL ou de valeur d'environnement. Les données utilisées font référence à une table possédée par un autre sous-système déclaré. Un sous-système peut posséder des données sans opérations Programme, ou des opérations sans données. Lisez le schéma/les migrations réels avant d'attribuer la propriété ; signalez l'incertitude au lieu d'inventer des associations.
Maintenez genesis/subsystems.md dans le même tour d'implémentation lorsqu'un changement ajoute, supprime ou modifie une responsabilité de sous-système, une adhésion au Programme ou une propriété/utilisation de données. Lisez la carte avant de modifier le code associé. Réutilisez les sous-systèmes existants à moins qu'une responsabilité distincte ne soit mise en évidence. Déclarez chaque module du Programme exactement une fois ; les dossiers ne déterminent pas l'adhésion. Maintenez les références de table ancrées dans le schéma/les migrations ; Genesis n'inspecte pas les bases de données. Les modifications d'assistants privés ne nécessitent aucune modification de la carte lorsque ces associations restent inchangées.
Si genesis/subsystems.md est manquant, ou est vide dans une application existante expliquée, créez-le à partir de la source réelle, du schéma et du Programme existant avant l'implémentation. Il s'agit d'une adoption explicative ordinaire, pas d'un blocage ou d'une raison de demander à nouveau la permission. Préservez le Programme et la source existants ; inspectez les responsabilités pertinentes et complétez la carte la plus petite et véridique. L'initialisation peut créer le fichier vide, mais seul l'agent en rédige le sens.