ziqingchuan/landingPageSkill

Composer une page d'atterrissage

Convertit un fichier de configuration user_config_info.json en une page d'atterrissage éducative mono-fichier HTML, correcte sur le plan métier, visuellement unique et directement exécutable dans un navigateur. Le processus est autonome et ne dépend d'aucun système externe.

Version du contrat de configuration 3.0. Point clé : conversionFlow est la seule source de vérité pour le processus de conversion.

Entrées

Fichier	Rôle
user_config_info.json	Configuration réelle du projet (fournie par l'utilisateur)
references/user-config-spec.md	Spécification des champs : signification, type, valeurs autorisées, valeurs par défaut
references/business-rules.md	Règles métier : invariants de comportement pour la conversion, la réservation, plusieurs enfants/matières, etc.
references/frontend-design.md	Direction visuelle : thème, typographie, mise en page, anti-modèles
references/engineering-conventions.md	Contraintes techniques : adaptation CJK, mode de rendu i18n, isolation des noms, chargement initial
references/question-bank.json	Banque de questions standard : texte des questions, options, mappage des catégories de matières

Les fichiers de référence sont intégrés. L'utilisateur fournit uniquement user_config_info.json.

Priorités

Configuration valide → Invariants métier → Demandes explicites de l'utilisateur → Conventions techniques → Direction esthétique

La configuration est un fait en lecture seule : elle n'est pas générée, complétée ou validée. L'ordre des phases et des nœuds dans conversionFlow ne peut pas être modifié. En cas de conflit, indiquer le champ et la règle spécifiques, sans deviner silencieusement.

Workflow

Étape 1 : Obtenir la configuration

Lire user_config_info.json. Si non fourni, s'arrêter ; si l'analyse échoue, indiquer l'emplacement de l'erreur. Si project.notes n'est pas vide, le considérer comme une préférence supplémentaire de l'utilisateur concernant la structure, le ton et le style visuel, influençant directement l'étape 5 (direction esthétique), mais sans remplacer les champs structurés ni les commutateurs fonctionnels.

Étape 2 : Lire la spécification des champs

Lire intégralement user-config-spec.md pour comprendre la sémantique de chaque champ. Accorder une attention particulière à l'ordre à deux niveaux de conversionFlow (ordre des phases + ordre des nœuds) et aux 5 types d'éléments (field / question / verification / booking / calendarSync). N'effectuer aucune validation de schéma.

Étape 3 : Établir le modèle métier en lecture seule

Basé sur la configuration et la spécification des champs, extraire dans la réflexion le modèle métier du projet actuel :

• Matières : matière d'entrée (project.subject) + matières supplémentaires (extraSubjects)
• Processus de conversion : ordre des phases et des nœuds de conversionFlow, l'emplacement du code de vérification étant la phase où se trouve le nœud verification
• Champs : ceux activés, obligatoires, leur appartenance (parent/enfant), champs conditionnels par matière
• Commutateurs : booking / multiChild / multiSubject / syncCalendar / contactMode / flowMode
• Unité de prérequis : tous les nœuds de type field et question dans la phase lead (dans l'ordre des éléments)
• Correspondance des questions : l'questionId des nœuds kind=question correspond à question-bank.json, sélectionner le texte en chinois ou anglais selon project.language, utiliser optionId pour les données soumises

Étape 4 : Lire les règles métier

Lire intégralement business-rules.md pour extraire les invariants métier à respecter. Les règles métier sont des contraintes de résultat, pas une liste de modules — l'IA détermine l'architecture de l'information de manière autonome en fonction de ces contraintes.

Étape 5 : Définir la direction esthétique

Lire intégralement frontend-design.md et, selon ses instructions, effectuer une conception en deux phases :

1. Brainstorm : Couleur (4-6 hex), Typographie (2+ rôles de police), Mise en page (une phrase + schéma en ASCII), Signature (un élément unique)
2. Critique : S'autocritiquer par rapport à project.theme, project.adScene, project.notes — si une partie semble générique par défaut, la modifier ; ne coder qu'après avoir confirmé l'unicité.

Étape 6 : Générer le code de la page

Lire d'abord engineering-conventions.md pour comprendre les contraintes techniques déclenchées par la configuration actuelle (unités CJK, mode de rendu i18n, isolation des noms, chargement initial). Ce sont des garde-fous de qualité du code, sans modifier les résultats métier.

Produire un HTML mono-fichier complet :

• <head> avec meta, titre, inclusion CDN Google Fonts, <style> en ligne ; <body> avec <script> en ligne
• Aucune dépendance à un outil de build externe, package npm ou fichier local
• CSS en ligne, en faisant attention à la spécificité des sélecteurs ; JS en ligne, implémentant l'ensemble du processus métier requis par la configuration
• Toutes les interactions exécutables dans le navigateur (la soumission de formulaire peut être simulée, mais doit être clairement indiquée)
• Les éléments décoratifs privilégient les SVG en ligne ; les photos utilisent des CDN gratuits avec contrainte de taille
• Responsive jusqu'au mobile, focus clavier visible, respect de prefers-reduced-motion

Comportement métier implémenté selon les sections 5 à 11 de business-rules.md, avec exigences supplémentaires au niveau du code :

• Le conteneur de code de vérification utilise data-verification-stage pour marquer la phase
• Pour les données de créneaux non réelles, utiliser des données de prototype clairement indiquées, sans simuler d'inventaire
• Les champs cachés, fonctions non activées et données des branches non sélectionnées ne sont pas inclus dans le résultat de la soumission

Étape 7 : Auto-vérification

Avant la livraison, s'autovérifier par rapport à la liste de contrôle :

• Correction métier : vérifier chaque élément de la liste d'acceptation de business-rules.md
• Qualité du design : le plan passe par l'autocritique, les polices et couleurs dérivées du plan, la signature unique, le responsive, le focus clavier, prefers-reduced-motion, les sélecteurs CSS sans annulation
• Stabilité technique : vérifier chaque élément de la liste d'auto-vérification de engineering-conventions.md (unités CJK, mode de rendu i18n, préfixe de nom, isolation de portée, chargement initial)
• Exécutabilité du code : le fichier unique s'ouvre et s'exécute directement, sans dépendance externe, polices via CDN

Étape 8 : Livraison

Enregistrer le fichier dans le répertoire de travail de l'utilisateur, nommé d'après project.name. Expliquer en langage naturel concis : sur quelle configuration il est basé, quelles capacités principales sont implémentées, l'élément signature, et quelles données sont des prototypes à remplacer.

Modes d'échec

Situation	Traitement
user_config_info.json non fourni	S'arrêter, indiquer que le fichier de configuration est requis
Échec de l'analyse JSON	Indiquer l'emplacement de l'erreur, ne pas deviner de correction
Conflit entre configuration et règles métier	Indiquer le champ et la règle spécifiques, demander confirmation à l'utilisateur
Type inconnu dans conversionFlow	Indiquer le nœud spécifique, ne pas passer silencieusement
Données réelles nécessaires mais absentes	Utiliser des données de prototype clairement indiquées, sans simuler de données réelles
Conflit entre demande utilisateur et configuration	Traiter selon la chaîne de priorité et informer l'utilisateur