# Proposition — Atelier narratif pour BIG EGG

Analyse du 29 septembre 2026. **Document de discussion, sans implémentation.**

## 1. Recommandation

**Construire un atelier visuel inspiré de Taskmaster3000, qui lit les vraies données de Big Egg et sauvegarde la planification dans son propre fichier.**

On pourrait y voir les histoires déjà implémentées, sélectionner les vrais personnages, salles, objets et conditions, puis ajouter librement des scènes et des branches encore imaginaires. Déplacer un nœud, proposer une récompense ou dessiner une suite ne modifierait pas le jeu.

C'est un chantier réaliste : Big Egg possède déjà une grande partie des mécanismes nécessaires. Le travail principal serait de rendre leurs relations visibles et compréhensibles. L'écriture directe dans le jeu constituerait une extension distincte, à envisager après avoir utilisé la première version.

Un arbre totalement indépendant serait utile pour réfléchir, mais il abandonnerait un avantage déjà accessible : retrouver automatiquement les éléments existants et comprendre comment ils se répondent. **La lecture des données avec une planification séparée offre ici le meilleur compromis.**

Le terme « graphe » décrit mieux l'outil qu'« arbre » : une histoire peut avoir plusieurs entrées, des chemins qui se rejoignent, des événements répétables et des boucles.

## 2. Ce qui a été examiné

L'analyse porte sur :

- Les variantes du visualisateur narratif retrouvées sous `chrono island`, dont les copies de `BACKUP TASKMASTER`.
- Le code PHP et JavaScript de `Taskmaster3000/narrative`, son API centrale, les fiches de segments et son fichier maître.
- Le maître publié et le brouillon de **`big-egg-3d`**, schéma 91 au moment de la lecture.
- Le gestionnaire de données, le registre d'adresses, les conditions, les quêtes, les dialogues, les déclencheurs et les éléments de salle.
- La quête existante de Bob, comme exemple concret de récit réparti entre plusieurs collections.

Il s'agit d'une inspection statique des fichiers. Les interfaces Taskmaster n'ont pas été lancées, leurs anciens endpoints n'ont pas été appelés et aucune partie n'a été simulée. Les fonctions présentes dans le code ne sont donc pas toutes garanties opérationnelles à l'écran. Certains README sont en retard sur le code ; les constats ci-dessous privilégient celui-ci.

## 3. Quelle version de Taskmaster reprendre ?

Le dossier proposé est bien **la version la plus avancée retrouvée** :

```text
E:\GDRIVE\SERVEUR ET PRODUCTION WEB\2025\REBIRTH\chrono island\GODOT\chrono-island\Taskmaster3000
```

Six exemplaires de `narrative/js/narrative.js` ont été retrouvés. Les cinq copies sous `BACKUP TASKMASTER` partagent exactement le même contenu pour ce fichier ; l'exemplaire principal est différent et plus récent.

| Indice vérifié | Copies de sauvegarde | Dossier principal |
|---|---|---|
| `narrative.js` | 143 150 octets, 11 décembre 2025 | 162 501 octets, 23 décembre 2025 |
| Barre latérale V2 | Absente des variantes comparées | Présente, activable par préférence du navigateur |
| Fiche `pages/segments.php` de la branche 1 | 26 631 octets | 90 520 octets |
| `connections.js` | Même contenu | Même contenu que les sauvegardes |

La taille seule ne prouve pas la qualité. Elle est corroborée ici par les fonctionnalités et les différences de code : catalogue central, références par identifiants, sélecteurs de personnages et de faits, fiches plus complètes. La recherche des fichiers PHP/HTML hors sauvegardes et composants tiers n'a pas retrouvé d'autre outil web concurrent dans ce dossier Chrono Island.

Le maître Taskmaster contient actuellement **175 segments, 38 acteurs, 13 intrigues, 57 lieux et 437 faits**. C'est une base utilisée pour une histoire conséquente, pas seulement une maquette vide.

### Ce qui mérite d'être repris

- Cartes narratives déplaçables et redimensionnables.
- Zoom, déplacement de la vue, sélection et recherche.
- Couleurs d'intrigue et filtrage.
- Connexions SVG et mise en évidence des relations.
- Panneau latéral de propriétés et sélection dans des catalogues.
- Principes d'annulation, duplication, sauvegarde et export.
- Séparation entre résumé lisible et texte détaillé.

### Ce qui demande une adaptation réelle

**Les relations.** Le maître possède des liens par identifiants, et la fiche de segments les utilise. Mais le visualisateur conserve aussi des liens hérités fondés sur les titres. Dans `connections.js`, les rapprochements automatiques entre conditions et conséquences reposent encore sur des comparaisons de chaînes avec `includes`. Cela ne suffit pas pour affirmer qu'un événement du jeu en débloque un autre.

**La sauvegarde.** Le chargement et l'autosauvegarde du visualisateur passent par le maître central Taskmaster. Les commandes d'import/export de `narrative.js` appellent encore l'API historique, qui travaille dans `narrative/data/narrative.json`. Cette divergence est visible dans le code ; il faut la supprimer dans l'adaptation, puis éprouver l'aller-retour import/export.

**La coexistence des formats.** Le maître contient des champs anciens et nouveaux en parallèle : `title`/`titre`, informations narratives imbriquées et propriétés à plat, références historiques et références par ID. Big Egg n'a pas besoin d'hériter de toutes ces conversions.

**La barre latérale V2.** Elle apporte des sélecteurs utiles, mais sa transformation de la section des connexions contient encore un TODO. « Plus moderne » ne signifie donc pas « entièrement finalisée ».

**La temporalité.** Chrono Island manipule notamment des heures de début/fin et des états de scheduler. Pour Big Egg, les repères utiles sont surtout la quête, sa progression, le lieu, la plongée, la dimension et la répétition. Une frise en secondes ne doit pas devenir la structure principale de l'histoire.

Proposition : reprendre l'ergonomie et les parties visuelles utiles, en remplaçant la couche de données et les règles de connexion. Il serait prématuré de chiffrer un pourcentage de code directement réutilisable sans prototype.

## 4. Ce que Big Egg possède déjà

Inventaire du **maître publié** au moment de l'analyse :

| Élément | Quantité | Utilité dans l'atelier |
|---|---:|---|
| Quêtes | 1 | Identité, journal, étapes, portée |
| Personnages narratifs | 1 | Identité narrative et sélection des dialogues |
| Déclencheurs narratifs | 9 | Conditions, lieu, répétition, scène et effets |
| Scènes narratives | 20 | Textes, acteurs de scène, événements et changements de valeurs |
| Faits | 12 | États narratifs et compteurs déclarés |
| Objets de quête | 1 | Objets remis, consommés ou conservés |
| Salles | 111 | Lieux, variantes, vagues, accès, sorties et événements |
| Éléments de salle | 17 | PNJ et autres objets interactifs |
| Récompenses de plongée | 8 | Cartes de bonus et effets associés |
| Recettes | 50 | Objectifs culinaires et déblocages |
| Créatures | 49 | Combats, incarnations et compteurs |
| Employés | 11 | Recrutement et conditions de disponibilité |

Les armes, ingrédients, upgrades, statistiques et profils clients complètent ces catalogues.

Trois mécanismes rendent la lecture connectée particulièrement intéressante :

1. **Un langage d'adresses commun.** Par exemple `quests.bob_hungry_horse.state`, `fact.bob_angry`, `rooms.bob_crater_hideout.current` ou `weapons.egg_launcher.owned`.
2. **Des conditions structurées.** Elles déclarent une adresse, un opérateur et une valeur ; l'outil peut afficher une phrase lisible tout en conservant la référence exacte.
3. **Des effets déclarés.** Une scène ou un événement peut modifier une valeur, faire progresser une quête, remettre un objet ou débloquer quelque chose.

Le gestionnaire possède déjà des éditeurs pour les personnages, quêtes, scènes, objets de quête et déclencheurs, ainsi que des sélecteurs d'adresses et de conditions. Le visualisateur devrait compléter ces formulaires et réutiliser leurs règles, sans devenir un second gestionnaire général.

**Attention : les étapes d'une quête sont actuellement les étapes du journal.** Leur ordre dans la fiche ne définit pas à lui seul les transitions du récit. Ce sont les scènes, effets et autres règles qui écrivent `state` et `stage`. Relier automatiquement « étape 0 → étape 1 » comme une transition exécutable serait trompeur.

## 5. Où doivent vivre les conditions : salle, PNJ, ou les deux ?

**Elles doivent vivre sur le mécanisme qu'elles contrôlent.** Le visualisateur peut les rassembler autour d'un même segment pour l'auteur, tout en indiquant leur emplacement réel.

| Question d'auteur | Emplacement pertinent dans le jeu actuel |
|---|---|
| Cette salle est-elle accessible ou cette variante admissible ? | `rooms[].conditions` |
| Où cette variante peut-elle apparaître, et avec quelle chance ? | `rooms[].replaces`, plus les règles de tirage |
| Ce personnage apparaît-il comme client ? | Conditions de son `customer_profile` |
| Ce PNJ doit-il disparaître ? | `room_elements[].vanish_conditions` |
| Que répond ce personnage ? | Conditions des entrées de `characters[].dialogues` |
| Quand lancer automatiquement une scène ? | `story_triggers[].conditions` et `place` |
| Quand faire arriver une vague endormie ? | `rooms[].waves[].conditions` |
| Quand débloquer un plat, une arme ou un employé ? | Conditions de la fiche concernée |
| Que se passe-t-il après une action ou une scène ? | Effets des événements `on_*` ou événements de scène `set_value` |

Ce tableau décrit des responsabilités existantes, pas des champs à ajouter partout. Par exemple, le PNJ de salle étudié a une condition de disparition ; il ne faut pas lui inventer un champ universel de présence simplement pour uniformiser le visualisateur.

Exemple : « Bob est dans sa planque quand sa quête est en cours, il accepte le plat si on l'a, sinon il se fâche. »

- La salle règle son admissibilité pendant la quête et sa chance d'apparition.
- Sa liste d'éléments place le PNJ de Bob.
- Le personnage choisit son dialogue selon l'état de quête et l'objet possédé.
- Le dialogue de colère pose `fact.bob_angry`.
- Ce fait fait disparaître le PNJ et réveille la vague de combat.

L'auteur pourrait voir tout cela dans une carte « Rencontre dans la planque », puis déplier les responsabilités. Il n'aurait pas besoin de recopier les mêmes conditions à plusieurs endroits.

### Deux règles à rendre visibles

**Toutes les conditions d'une liste générique Big Egg sont combinées par ET.** `GameState.conditions_met()` ne prend pas en charge un langage général de groupes ET/OU imbriqués. Le sélecteur ET/OU de Taskmaster n'est donc pas directement transposable. Des branches alternatives peuvent être dessinées dans le plan ; les rendre exécutables demanderait une traduction précise vers les mécanismes existants ou une évolution du moteur. Le `any/all` des vagues concerne un mécanisme particulier, pas toutes les conditions du jeu.

**Les dialogues sont prioritaires.** Le personnage joue la première entrée de dialogue dont les conditions sont satisfaites. Une réponse sans condition placée avant une réponse spécifique peut la masquer. Cet ordre doit être affiché, pas transformé en choix aléatoire.

Les déclencheurs automatiques ont aussi une temporalité : ils réagissent au passage de faux à vrai, lieu compris. Leurs effets sont appliqués au déclenchement ; la scène attend ensuite que le jeu puisse l'afficher. Une flèche « scène terminée → récompense » ne décrirait donc pas nécessairement la donnée réelle.

## 6. Acteurs : une identité, plusieurs incarnations

Dans Big Egg, « acteur » recouvre plusieurs notions :

- Le personnage narratif : `characters.bob`.
- Son incarnation en client : `customer_profiles.bob_guest`.
- Son incarnation en PNJ : `room_elements.bob_npc`.
- Son incarnation en combattant : `enemies.bob_the_horse`.
- Son incarnation en employé : `employees.bob_the_horse`.
- L'acteur local à une scène narrative, qui peut avoir sa propre source visuelle.

L'atelier devrait proposer une fiche « Bob » avec ses incarnations. Certains liens sont explicites dans les données, notamment le champ `character` du client et du PNJ. D'autres associations devront être confirmées par l'auteur et enregistrées dans le plan.

Il ne faut pas fusionner des fiches uniquement parce que leur nom ou leur identifiant se ressemblent. Des variantes et des copies existent déjà.

Pour écrire une future histoire, le bouton « Nouvel acteur » pourrait créer une **idée de personnage**, utilisable immédiatement dans le plan. Un indicateur signalerait qu'elle n'a pas encore de fiche dans le jeu. Plus tard, l'auteur pourrait la rattacher à une vraie fiche sans perdre ses segments.

## 7. Récompenses : une liste existe, mais elle ne couvre pas tout

La collection `rewards` existe déjà, avec huit cartes de bonus de plongée. Elle ne représente pas toutes les récompenses narratives possibles.

Pour l'auteur, une récompense peut être :

| Intention | Mécanisme ou distinction à présenter |
|---|---|
| Donner des pièces | Effet vers `player.coins` |
| Donner un ingrédient | Effet vers `ingredients.<id>.owned` |
| Remettre un objet de quête | Effet vers `key_items.<id>.owned`, avec plafond et portée |
| Donner une arme | Possession `weapons.<id>.owned`, déjà utilisée pour le Lance-œufs |
| Débloquer une recette | Condition de la recette devenue satisfaite |
| Rendre Bob recrutable | Condition de l'employé satisfaite ; cela ne l'embauche pas automatiquement |
| Ouvrir une salle ou un dialogue | Changement d'état lu par les conditions correspondantes |
| Donner un bonus temporaire | Mécanisme de modificateurs ; les cartes de plongée sont un cas existant |

**« Disponible », « offert », « choisi », « possédé » et « équipé » ne sont pas synonymes.** Une interface qui les confondrait produirait des plans difficiles à implémenter correctement.

Je propose un sélecteur de récompense par catégorie, avec recherche dans les vrais catalogues, quantité ou valeur si pertinente, moment d'attribution et durée. Les intentions non couvertes par le moteur resteraient signalées « à implémenter ».

On pourrait aussi nommer un ensemble, par exemple « Récompense de Bob », qui regroupe plusieurs intentions. Dans la première version, cet ensemble vivrait seulement dans le plan. Il n'est pas nécessaire d'ajouter immédiatement une nouvelle collection de récompenses de quête au schéma du jeu.

La même fiche doit accueillir les **autres conséquences** : consommation d'un objet, colère d'un personnage, fermeture d'un chemin ou échec de quête. Toutes les conséquences ne sont pas des récompenses.

## 8. Les trois niveaux possibles

| Option | Ce qu'elle permet | Travail et limites |
|---|---|---|
| A — Tableau indépendant | Nœuds, liens, texte, acteurs et lieux saisis à la main | Le plus petit chantier, mais double saisie et divergence avec le jeu |
| **B — Atelier connecté en lecture** | Catalogues réels, inspection de l'existant, segments libres, liens et propositions séparés | Travail intermédiaire ; apporte une utilité immédiate sans modifier les règles |
| C — Éditeur narratif publiable | Création et modification de données exécutables depuis le graphe | Chantier important : schémas, validation, synchronisation et essais en jeu |

**Je recommande B.** La lecture de fichiers JSON et l'affichage de sélecteurs ne sont pas les difficultés principales. Les deux travaux exigeants sont la reconstruction fidèle des relations et une interface qui reste lisible.

L'option C est faisable techniquement. Elle implique cependant de décider comment un segment d'auteur se répartit entre une quête, plusieurs déclencheurs, un dialogue, une salle et des effets. Un simple bouton « exporter en JSON » ne résout pas cette traduction.

L'observation d'une partie en cours constitue encore une autre fonction. Lire le catalogue publié ne révèle ni l'inventaire du joueur, ni les valeurs calculées, ni les conditions actuellement vraies. Une connexion de diagnostic au jeu ou une simulation explicite serait nécessaire pour cela.

## 9. Proposition d'interface

Une entrée **Narrative** depuis le gestionnaire, ouvrant une page dédiée du même outil PHP local. Cela évite une seconde installation et laisse toute la place au graphe. Les composants visuels seraient isolés du gros script des formulaires.

### Trois zones principales

**À gauche : bibliothèque.** Quêtes et intrigues, personnages, salles, scènes, objets et récompenses. Recherche par nom lisible, avec identifiant disponible dans le détail. Possibilité de glisser une référence dans le plan ou d'ajouter une idée neuve.

**Au centre : graphe.** Segments, branches, regroupements et notes. Vue centrée sur une quête ou un personnage ; les objets techniques restent repliés jusqu'à ce qu'on les demande. Une vue globale chargée de toutes les salles et de tous les objets ne serait pas un bon écran de départ.

**À droite : inspecteur du segment.** Titre, résumé, acteurs, lieux, conditions, déclenchement, conséquences, récompenses, suite et provenance. Bouton pour retrouver la fiche source dans le gestionnaire ; le lien précis vers une fiche est à vérifier ou à ajouter lors de l'implémentation.

### Informations utiles au-delà des quatre listes initiales

| Information | Pourquoi elle compte |
|---|---|
| Quête ou intrigue | Regrouper plusieurs événements dans une histoire |
| Objectif du joueur | Distinguer ce que raconte la scène de ce que le joueur doit faire |
| Déclenchement | Parler, entrer, servir, tuer, posséder ou constater un état |
| Choix et branches | Représenter plusieurs chemins et leurs points de rencontre |
| Conséquences | Décrire ce qui change, y compris les pertes et échecs |
| Portée | Ce qui dure une plongée, une dimension ou toute la progression |
| Répétition | Une fois, répétable, conditions de réarmement |
| Priorité | Ordre des réponses possibles et cas masqués |
| Probabilité | Distinguer un événement admissible d'un événement garanti |
| État de réalisation | Idée, à préciser, relié à des données, vérifié en jeu |
| Provenance | Fiche exacte, champ exact, publié ou brouillon |

« Relié aux données » ne voudrait jamais dire automatiquement « vérifié en jeu ».

### Des liens dont le sens est explicite

- **Référence réelle** : ce PNJ utilise ce personnage, ce déclencheur joue cette scène.
- **Dépendance de valeur** : cette scène écrit un fait que cette autre règle lit.
- **Suite proposée** : lien dessiné par l'auteur pour une future histoire.

Ces relations doivent avoir des libellés et des styles distincts, pas seulement des couleurs. Pour une dépendance calculée, le détail doit expliquer « écrit `fact.bob_angry = true` / lit `fact.bob_angry` ».

Partager une adresse ne suffit pas à prouver une succession : une écriture à `false` peut désactiver une condition, une addition peut ne pas atteindre un seuil, et plusieurs autres conditions peuvent rester fausses. La première version peut indiquer « influence cette condition » ; elle ne doit pas promettre une causalité complète.

## 10. Exemple concret : la quête de Bob

La quête publiée est un excellent premier cas d'essai, parce qu'elle traverse restaurant, donjon, dialogues, objets, combat et recrutement.

Le schéma suivant est une **synthèse narrative des données**, pas un ordre d'exécution exhaustif. Le détail technique devrait rester accessible sous chaque carte.

```mermaid
flowchart TD
    A[Rencontre dans la salle d'El Tuna<br/>sans Lance-œufs, quête inconnue] --> B[Quête en cours]
    B --> C[Bob client arrive et s'assoit]
    C --> D[Étape 1 du journal<br/>recette de Bob accessible]
    D --> E[Servir Bob au restaurant]
    D --> F[Mettre le plat de côté<br/>objet de quête à emporter]
    D --> G[Planque admissible<br/>remplacement de la salle 3 à 50 %]
    F --> H[Parler à Bob avec le plat]
    G --> H
    G --> I[Sans le plat : colère]
    I --> J[Le PNJ disparaît<br/>une vague de combat se réveille]
    J --> K[Excuses après le combat<br/>la quête peut continuer]
    E --> L[Quête réussie]
    H --> L
    L --> M[Lance-œufs donné par un déclencheur]
    M -. Chemin narratif attendu .-> N[El Tuna vaincu]
    N --> O[Défi de Bob admissible<br/>remplacement de la salle 4 à 25 %]
    O --> P[Premier duel gagné<br/>Bob devient recrutable]
    P --> Q[Variante de duel récurrente]
```

Ce que le graphe révélerait mieux qu'une simple fiche de quête :

- La réussite peut venir du service au restaurant ou de la remise de l'objet dans la planque.
- Le Lance-œufs est donné par `story_triggers.bob_reward.on_fired`, pas par une liste « récompenses » directement dans la quête.
- Les conditions de dialogue déterminent quelle scène Bob choisit ; toutes ses scènes ne sont pas des branches équiprobables.
- Le combat dans la planque et le duel ultérieur sont deux situations différentes.
- La quête ne regroupe pas explicitement toutes les données concernées par un même `quest_id`. Il faut suivre les références et compléter le regroupement d'auteur si nécessaire.
- Les taux de 50 % et 25 % sont les chances déclarées pour les variantes. Ils doivent être interprétés avec l'arbitrage des autres salles admissibles ; une salle ne devient pas garantie parce que sa condition est vraie.
- La quête et `bob_joined` sont de portée `meta`, tandis que l'emploi de Bob est de portée `dimension`. Le compteur de victoires sur El Tuna est aussi remis à zéro au changement de dimension. Afficher ces durées aide à vérifier l'intention sans supposer qu'il s'agit d'erreurs.

L'association entre les différentes incarnations de Bob et le regroupement de cette suite dans une intrigue sont partiellement éditoriaux. Ils ne doivent pas être présentés comme des liens tous explicitement stockés par le jeu.

## 11. Architecture proposée pour la lecture seule

```mermaid
flowchart LR
    M[Maître publié] --> R[Lecture et index de références]
    D[Brouillon du gestionnaire] --> R
    R --> V[Vue des données réelles]
    P[Fichier de planification séparé] <--> A[Atelier narratif]
    V --> A
    A --> F[Consultation des fiches du gestionnaire]
```

Les fichiers existants restent les sources des règles :

- `data/game_data_master.json` pour le publié.
- `tools/game-data-manager/data/draft.json` pour le brouillon sauvegardé.

Le plan pourrait vivre dans `tools/game-data-manager/data/narrative_plan.json` — **nom proposé, fichier non créé**. Il stockerait uniquement : intrigues d'auteur, segments libres, associations confirmées, notes, positions, liens manuels et intentions de conditions/récompenses.

### Sélection de la source

Le gestionnaire expose déjà des lectures `load` — brouillon si présent, sinon maître — et `load_master`. Il existe donc un point de départ concret pour lire les données sans écrire.

L'atelier afficherait un choix explicite **Publié / Brouillon**, avec date de lecture. Par défaut, « Publié » répond à « qu'est-ce qui est prévu dans le jeu publié ? ». Le brouillon permet de préparer le travail en cours. Les modifications encore seulement présentes dans un autre onglet de navigateur ne peuvent pas être lues avant leur sauvegarde.

Lors de cette analyse, les deux fichiers différaient effectivement dans **`quests`, `localization` et `metadata`**. Cette distinction est donc nécessaire dès la première version.

### Références durables

Une référence doit enregistrer la collection et l'ID, jamais seulement le nom affiché. Une référence à un champ ajoute son chemin ; un nom mémorisé peut servir d'aide si la source disparaît, mais ne devient pas la vérité.

Les événements de scène ont des identifiants locaux. D'autres sous-éléments, comme les étapes du journal, sont repérés par position. Une insertion peut donc déplacer leur sens. Pour ces cas, conserver aussi une empreinte de contenu et demander une réconciliation en cas de changement ; ne pas rattacher silencieusement une note au mauvais élément.

### Actualisation et séparation des écritures

Actualiser le catalogue doit préserver les positions, les notes et les idées du plan. Une référence supprimée devient un avertissement visible ; elle n'entraîne pas la suppression des idées qui l'utilisent.

Le service d'enregistrement du plan ne doit pouvoir écrire que son fichier, avec gestion des versions concurrentes et remplacement atomique. L'autosauvegarde de Taskmaster, qui réécrit un maître complet, ne doit pas être réutilisée telle quelle.

Déplacer une carte réelle modifie sa présentation dans le plan. Pour réécrire son contenu, l'auteur crée une proposition liée ou passe par sa fiche dans le gestionnaire. Les données réelles et le texte proposé restent identifiables.

La première version n'aurait pas de bouton « Publier dans le jeu ». Elle enregistrerait et exporterait le plan. Un export Markdown fournirait ensuite une fiche d'implémentation lisible, en plus de l'export JSON réimportable.

## 12. Périmètre de la première version et progression

### Étape 1 — Une tranche complète autour de Bob

Lire les catalogues, représenter les principales relations de Bob, afficher les conditions et conséquences avec leur provenance, déplacer les cartes et enregistrer leurs positions séparément.

Cette étape doit répondre à trois questions pratiques : comprend-on mieux la quête ? Retrouve-t-on rapidement la règle qui nous intéresse ? Le graphe reste-t-il agréable à manipuler ?

### Étape 2 — L'atelier d'écriture utilisable

Ajouter les segments libres, les intrigues, les acteurs et lieux provisoires, les sélecteurs réels, les liens manuels, la duplication, l'annulation, la recherche, les filtres, l'export et l'import du plan.

Les champs libres restent possibles : il faut pouvoir écrire une idée avant d'avoir décidé sa condition exacte. L'outil signale simplement si cette intention est structurée et compatible avec le jeu ou encore à définir.

### Étape 3 — Inspection plus large et diagnostics

Étendre l'index des références aux mécanismes pertinents : événements de scènes, dialogues, déclencheurs, recettes, clients, éléments de salle, vagues, armes et recrutement. Ajouter la comparaison publié/brouillon et les avertissements ciblés.

Un diagnostic doit annoncer ses limites. « Aucun producteur déclaré trouvé » est utile ; « cet événement ne peut jamais arriver » serait excessif si une valeur peut être écrite par le moteur. De même, un cycle n'est pas forcément une erreur : les événements répétables en créent volontairement.

### Étape 4 éventuelle — Écriture ciblée vers le brouillon

Seulement si l'atelier est devenu utile au quotidien : préparer une modification limitée, montrer les fiches et champs concernés, valider avec le contrat du gestionnaire, puis appliquer au brouillon avec contrôle de version. La publication resterait dans le circuit existant.

Cette étape nécessiterait des essais spécifiques sur les sauvegardes, les localisations, les priorités de dialogues, les portées, les champs calculés et les déclenchements répétés. Un graphe général ne doit jamais écrire directement dans une statistique calculée ou contourner les mécanismes existants.

### Ce qui ne fait pas partie de la première version

Simulation complète de Godot, contrôle d'une partie en cours, génération automatique de tout le code d'une quête, nouveau langage de conditions ET/OU, éditeur de mise en scène 3D ou remplacement des formulaires existants.

Il n'est pas nécessaire de résoudre ces sujets pour obtenir un outil d'écriture déjà utile.

## 13. Critères pour considérer la première version réussie

1. L'auteur retrouve une salle, un personnage ou une récompense par son nom et l'associe à un segment sans recopier son identifiant.
2. La quête de Bob peut être comprise à partir d'une vue synthétique, puis inspectée jusqu'au champ réel qui porte la règle.
3. Une nouvelle intrigue entièrement imaginaire peut être écrite avec des acteurs et objets provisoires.
4. Les idées, relations réelles et dépendances déduites restent distinguables.
5. Un rafraîchissement du catalogue préserve le travail de composition et signale les références disparues.
6. Les données affichées sont clairement identifiées comme publiées ou issues du brouillon.
7. La sauvegarde, l'import/export et l'annulation du plan ne modifient ni le maître, ni le brouillon, ni une sauvegarde de joueur.

La validation devra notamment comparer les empreintes des fichiers du jeu avant/après les manipulations de l'atelier et tester un aller-retour réel sauvegarde → rechargement → export → import. Des contrôles ciblés de l'index vérifieront les relations de Bob, l'ordre des dialogues et la distinction entre dépendance et causalité.

Pour cette analyse documentaire, aucun test du jeu n'a été lancé.

## 14. Décisions à discuter

La proposition peut démarrer avec les choix suivants :

| Sujet | Choix proposé |
|---|---|
| Intégration | Page Narrative dédiée, accessible depuis le gestionnaire PHP |
| Données | Lecture du publié ou du brouillon, choix explicite |
| Enregistrement | Plan séparé, aucune publication depuis l'atelier en V1 |
| Point de départ | Quête de Bob, puis création libre d'une deuxième intrigue |
| Style visuel | Cartes et connexions de Taskmaster, adaptées aux lieux et à la progression de Big Egg |
| Récompenses | Sélecteur par catégorie ; ensembles nommés seulement dans le plan au départ |
| Conditions | Affichage du lieu réel de la règle ; intentions libres possibles |
| Évolution | Écriture ciblée vers le brouillon étudiée après usage réel |

La question de conception la plus utile pour la suite est : **préfères-tu commencer par voir et comprendre ce qui existe déjà, ou par écrire immédiatement une nouvelle intrigue ?** Les deux usages partagent le même socle ; la réponse détermine surtout le premier écran et l'ordre des étapes.

## 15. Références de l'analyse

Chemins Big Egg relatifs à ce document :

- [Maître publié](../data/game_data_master.json) et [brouillon du gestionnaire](../tools/game-data-manager/data/draft.json).
- [GameState](../autoload/game_state.gd) : `character_dialogue_scene`, `set_quest_value`, `conditions_met`, persistance des compteurs.
- [Catalogue d'adresses](../scripts/core/address_catalog.gd) : champs stockés/calculés et événements disponibles.
- [Registre](../scripts/core/registry.gd) : lecture, écriture et effets.
- [Déclencheurs narratifs](../scripts/core/story_triggers.gd) : front montant, répétition, application des effets et mise en attente des scènes.
- [Éléments de salle](../scripts/combat/room_element.gd) et [progression des salles](../scripts/core/dive_map.gd).
- [Interface du gestionnaire](../tools/game-data-manager/assets/app.js) : `questEditor`, `storyTriggerEditor`, sélecteurs d'adresses, conditions et effets.
- [API du gestionnaire](../tools/game-data-manager/api.php) : lectures `load` et `load_master`, sauvegarde du brouillon et publication.
- [Validation PHP](../tools/game-data-manager/config.php) : contrats des quêtes, personnages, déclencheurs et salles.

Sous le dossier Taskmaster principal indiqué en section 3 :

- `narrative/js/narrative.js` : `loadData`, `autoSave`, conversions, import/export.
- `narrative/js/canvas.js` et `narrative/js/connections.js` : cartes et connexions.
- `narrative/js/narrative-sidebar-v2.js` : sélecteurs et limites de la V2.
- `narrative/index.php` : activation de la V2 par préférence navigateur.
- `pages/segments.php`, `core/api.php`, `shared/js/api_client.js` et `core/data/master.json` : modèle central et relations par ID.
- `narrative/api.php` : ancien stockage autonome encore utilisé par l'import/export du visualisateur.

Les quantités et différences citées décrivent les fichiers observés le 29 septembre 2026. Elles évolueront avec le travail d'auteur. Ce document propose une architecture ; il ne constitue ni une validation fonctionnelle de Taskmaster, ni une autorisation de modifier le moteur.