# ANO-01 — Les doubles de Steve

**Conception ajoutée le 15 septembre 2026. Non implémentée.** Les trois doubles
sont des anomalies de Sanctuary. Leurs comportements sont distincts : Herobrine
harcèle les explorateurs et disparaît lorsqu'il est vu ; le mineur fantôme
creuse des galeries ; le Steve bugué reste comme une preuve matérielle de
l'existence de Steve.

Branche de conception réservée : `codex/steve-anomalies-design`.
Ce dossier prolonge [BR-01](backrooms-implementation.md) et la
[cosmologie](cosmologie.md). Il prépare trois lots vérifiables ; il ne déclenche
pas leur implémentation et ne consomme pas de numéro `beta.xxx`.

## 1. Règles données par le créateur

| Double | Présence | Apparence et comportement retenus |
| --- | --- | --- |
| **Herobrine** | Caché dans les Backrooms | Frappe le joueur, place des blocs, l'enferme, avance vers lui ; peut se placer derrière lui et attendre qu'il se retourne. Disparaît au moment où le joueur le voit. |
| **Mineur fantôme** | **Overworld et Backrooms**, confirmé pendant la conception | Creuse des galeries surtout dans les chunks les moins marqués par Demeure. De face comme de dos, on voit l'arrière de sa tête. |
| **Steve bugué** | Apparition **extrêmement rare** ; lieux d'apparition à préciser | Steve en T-pose, avec des UV mal placés, donc des fragments de texture au mauvais endroit sur son corps. Une fois trouvé, il reste : on peut le mettre dans un bateau et le déplacer. Il constitue une preuve que Steve existe. |

La description du mineur retient la correction orale finale : arrière de la
tête visible de face et de dos. Elle ne demande pas deux visages frontaux.

Les trois anomalies sont liées à Steve dans la fiction. Leur origine exacte,
leurs relations entre elles et ce que Steve en sait restent à raconter ; ce
dossier ne leur attribue ni machine créatrice ni explication définitive.

## 2. Place dans les prochains développements

| Lot proposé | Résultat vérifiable | Dépendances | Branche prévue |
| --- | --- | --- | --- |
| **ANO-01A — Herobrine** | Une rencontre dans les Backrooms comporte une action physique puis une disparition lorsque l'apparition est vue. | BR-01 jouable, donc suivi du ballast livré auparavant ; contrat de modification des blocs. | `codex/herobrine-backrooms` |
| **ANO-01B — Mineur fantôme** | Le mineur choisit préférentiellement les zones peu demeurées et y laisse des galeries persistantes. | Demeure et contrat de creusement ; BR-01 pour la partie Backrooms. Un prototype Overworld peut être vérifié séparément. | `codex/ghost-miner` |
| **ANO-01C — Steve bugué** | Un individu rare est découvert, embarqué, déplacé puis retrouvé après redémarrage. | Entités persistantes, rendu et bateaux ; BR-01 seulement si les lieux d'apparition retenus l'exigent. | `codex/glitched-steve` |

BR-01 garde son résultat initial : générer les lieux et permettre l'aller-retour.
L'absence des doubles ne bloque pas la validation de ce socle. Leur activation
vient ensuite, avec leurs propres critères et notes de livraison.

## 3. ANO-01A — Herobrine dans les Backrooms

### Rencontre attendue

Herobrine peut se manifester à travers plusieurs gestes : frapper, avancer,
poser des blocs pour entraver ou enfermer, se tenir derrière un joueur et
attendre son regard. Chaque rencontre peut en employer un ou plusieurs ; tous
les gestes doivent pouvoir être éprouvés pendant le développement.

Exemple de mise en scène proposé : le joueur poursuit son exploration après un
coup ou découvre un passage récemment fermé ; Herobrine attend derrière lui.
Quand le joueur se retourne et le voit, l'apparition disparaît. Les dégâts et
les changements de blocs sont de vrais événements du monde.

### Contrat technique proposé

- Une machine d'états serveur décrit l'apparition, sa cible, son action, sa phase
  d'attente du regard et sa disparition. Les intervalles et budgets de rencontres
  sont réglables ; ils ne sont pas fixés arbitrairement dans cette conception.
- Définir « vu » par un observateur actif, une direction de vue et une ligne de
  visibilité non obstruée. Un regard à travers un mur ne déclenche pas la
  disparition. Vérifier le comportement avec les caméras et zooms pris en charge.
- En multijoueur, proposition de départ : le premier observateur admissible qui
  voit l'apparition déclenche sa disparition pour tous. Le client peut signaler
  une observation ; le serveur en valide les conditions et décide du résultat.
- La disparition interrompt les attaques et placements encore en attente. Une
  attaque déjà résolue n'est pas appliquée une seconde fois à la reprise.
- Les blocs placés et les effets accomplis suivent leur propre persistance.
  La disparition ne restaure pas automatiquement une ancienne copie du terrain.
- L'enfermement doit pouvoir se produire réellement. Fixer avant le code les
  blocs autorisés, leur provenance/drops, la quantité par rencontre et les moyens
  d'en sortir. Aucun écrasement de conteneur ou placement dans le corps d'un
  joueur n'est nécessaire pour obtenir cet effet.
- Proposer des rencontres hors du volume d'arrivée protégé des salles personnelles,
  en cohérence avec BR-01. La portée exacte de cette protection face à Herobrine
  doit être inscrite dans le contrat du lot avant son activation.

La cadence, les dégâts, le caractère éventuellement mortel, les sons, la
distance d'approche et la possibilité de combattre Herobrine restent à régler.
Le comportement retenu ne doit pas être réduit à un effet visuel sans coup
ni modification réelle de l'environnement.

### Critères d'acceptation futurs

- [ ] Démontrer chaque geste demandé : coup, marche/approche, placement,
  enfermement et attente derrière le joueur.
- [ ] Lors du retournement, l'apparition est perceptible puis disparaît dès
  l'observation reconnue, sans attaque différée après sa disparition.
- [ ] Observer derrière un mur n'a pas le même résultat qu'une vue dégagée ;
  deux clients partagent un résultat cohérent.
- [ ] Les blocs réellement placés survivent conformément au contrat, sans
  effacer des modifications ultérieures des joueurs lors de la fin de rencontre.
- [ ] Annulation, déconnexion, déchargement et redémarrage ne rejouent ni coup
  ni placement ; les limites de rencontres restent effectives.

## 4. ANO-01B — Le mineur fantôme

### Apparence et comportement

Le modèle montre l'arrière de la tête sur ses faces avant et arrière. Les côtés,
l'animation de creusement et les accessoires restent à concevoir. Ce défaut
visuel appartient au modèle et doit être cohérent pour deux observateurs placés
de part et d'autre ; il ne résulte pas d'une tête tournée artificiellement pour
chaque caméra.

Le mineur avance en creusant des galeries dans l'Overworld et les Backrooms.
Il laisse une transformation physique du terrain. L'apparition ne dépend pas
du fait qu'un joueur soit en train de regarder le creusement.

### Choisir les chunks les moins demeurés

Le mod autonome [Demeure](demeure-beta006.md) fournit déjà des influences par
dimension et chunk. Il conserve notamment des scores de joueurs, d'animaux,
de villageois, de monstres et de nature. Un pourcentage dominant ou l'étiquette
« abandonné » ne mesure pas à lui seul la quantité d'habitation humaine.

Proposition pour le premier prototype :

1. Lire les empreintes des chunks candidats dans un voisinage borné, déjà
   disponible ; ne pas parcourir ni charger toute la carte pour chercher un
   minimum mondial.
2. Comparer la **somme des scores effectifs des sujets joueurs**, à date commune,
   et favoriser les scores faibles. Conserver « surtout » comme une préférence
   pondérée, dont la force sera réglée pendant les essais.
3. Distinguer une zone sans empreinte enregistrée d'un service indisponible.
   Documenter la couverture historique et la politique des zones non relevées ;
   une panne ne vaut jamais un score nul. Un monde ancien sans suivi n'est pas
   réputé vierge par défaut.
4. Réévaluer le trajet aux limites de chunks et avant chaque courte séquence
   de creusement, pour tenir compte d'un secteur qui devient habité.
5. Garder la politique de ciblage dans Sanctuary. Demeure reste responsable de
   ses mesures et ne reçoit pas de règle propre au mineur.

### Creuser et conserver les traces

- Traiter le creusement comme l'action d'une entité dans le monde chargé,
  avec cadence, portée et volume bornés ; aucune régénération de chunk.
- Définir matériaux creusables, drops, traitement des minerais, eau/lave,
  conteneurs, constructions et protections avant activation. Les permissions
  explicites et les exclusions de terrain sont vérifiées indépendamment du score
  Demeure : une faible empreinte ne constitue pas un droit de démolition.
- Réserver des séquences courtes et reprendre depuis l'état sauvegardé. Recharger
  le mineur ne doit pas creuser de nouveau une ancienne séquence ni redonner ses
  éventuels drops. Aucun rattrapage de creusement hors ligne n'est proposé.
- Les galeries sont sauvegardées comme modifications normales du monde. Dans
  les Backrooms, le générateur ne les rebouche pas en rechargeant son ancien plan.
- Attribuer l'action au mineur. Ne pas créditer un joueur de minage, d'XP ou de
  Demeure à sa place. Si le ballast reçoit un événement, son origine « anomalie »
  et la règle de contribution doivent venir du contrat économique.

La fréquence d'apparition, la forme et la longueur des galeries, les interactions
avec le mineur et la persistance de l'entité elle-même restent à concevoir.
Ses galeries, une fois creusées, sont persistantes.

### Critères d'acceptation futurs

- [ ] Le rendu montre l'arrière de la tête de face et de dos, y compris pour
  deux joueurs simultanés et pendant le creusement.
- [ ] La sélection contrôlée favorise les scores humains faibles ; tester
  scores égaux, activité répartie entre plusieurs joueurs, influence animale,
  service indisponible et zones sans historique.
- [ ] Un parcours est vérifié dans l'Overworld puis dans les Backrooms. Un score
  associé à une dimension ne contamine pas le classement de l'autre.
- [ ] Les galeries existent réellement, respectent les contrats de terrain et
  subsistent après déchargement/redémarrage sans doublon de drops.
- [ ] Une nouvelle habitation influe sur les choix suivants. Le mineur ne crée
  pas d'activité personnelle artificielle et n'ouvre pas une boucle de ballast.

## 5. ANO-01C — Le Steve bugué, preuve transportable

### Identité visuelle et découverte

Le Steve bugué est **extrêmement rare**, en T-pose avec un placement volontairement
incorrect des UV : les UV indiquent quelle portion de texture couvre chaque
face du modèle. Cette mauvaise correspondance doit être visible et rester
identique après rechargement ; elle fait partie de l'apparence de l'individu.

Une fois découvert, il demeure dans le monde et peut être montré aux autres.
Le trouver ne se résout pas par sa disparition ou une récompense qui le remplace.
Il peut monter dans un bateau et être déplacé avec celui-ci. Son rôle narratif
est de fournir une preuve durable que Steve existe.

### Contrat proposé de persistance et de transport

- Donner à l'individu une identité persistante. Une fois découvert, le soustraire
  au despawn naturel lié à la distance, au temps ou au départ de son découvreur.
- Sauvegarder position, dimension, variante visuelle, état de découverte et lien
  de passager. Le changement de chunk, le déchargement du bateau et le redémarrage
  conservent le même individu, sans le réinvoquer à son ancien emplacement.
- Vérifier embarquement, déplacement et débarquement avec les bateaux du pack.
  Conserver la signature en T-pose une fois embarqué et adapter le placement pour
  un résultat lisible. Un bateau cassé libère l'individu sans le supprimer.
- Le départ ou le changement de nom du découvreur n'efface pas l'entité. Deux
  joueurs peuvent constater et déplacer le même individu selon les interactions
  de transport ordinaires, sans exclusivité de propriété ajoutée implicitement.
- Les tentatives d'apparition rare doivent avoir une identité et une fréquence
  maîtrisées : recharger un chunk ne relance pas une loterie illimitée et ne
  recopie pas un individu déjà découvert.

**Persistance ne signifie pas invulnérabilité.** Résistance aux dégâts, mort,
chute dans le vide, nombre d'individus possibles et éventuels passages entre
dimensions restent à fixer avant livraison. Les lieux d'apparition et la
probabilité exacte restent également ouverts ; seule l'extrême rareté est
décidée. Aucun chiffre ni dimension ne sont présentés ici comme approuvés.

### Critères d'acceptation futurs

- [ ] T-pose et UV déplacés sont identifiables et stables à pied et en bateau.
- [ ] Un individu découvert est encore présent après éloignement, départ de
  tous les joueurs, déchargement et redémarrage.
- [ ] Embarquement, transport sur plusieurs chunks, débarquement et destruction
  du bateau conservent l'identité et produisent exactement un individu.
- [ ] Deux clients constatent la même présence et le même déplacement ; changer
  de découvreur ou quitter le serveur ne provoque pas de disparition.
- [ ] Les essais démontrent le mécanisme de rareté et l'absence de nouveau tirage
  induit par une simple reconnexion ou un rechargement répété.

## 6. Terrain, sauvegardes et livraison

Les choix proposés sur les blocs, les dégâts et les protections complètent les
idées du créateur ; leurs valeurs doivent être établies dans chaque lot avant
le code qui les applique. Les coups, poses et creusements restent des actions
réelles. La conservation des secteurs de BR-01 interdit leur régénération
silencieuse, tout en permettant ces modifications de gameplay sauvegardées.

Développer d'abord sur des mondes neufs ignorés. Avant activation sur un monde
existant, documenter le contrat d'adoption : périmètre des mutations autorisées,
couverture Demeure, identités des anomalies, actions en cours et devenir des
entités lors d'une désactivation. Aucun monde personnel n'est modifié par ce
dossier. Le stockage autonome de Demeure reste sous sa responsabilité.

Pour chaque livraison de code :

- vérifier les API de la version Minecraft exacte, les identifiants
  `sanctuary:*` retenus et les modèles/textures effectivement utilisés ;
- ajouter les libellés FR/EN utiles et préserver l'absence de coordonnées des
  Backrooms dans les messages et interfaces ordinaires ;
- effectuer les tests serveur ciblés, des essais de rendu à deux clients et les
  reprises de sauvegarde ; archiver graines, positions opérateur et paramètres ;
- lancer `./gradlew check build`, puis `./gradlew assemblePack` si la distribution
  change ; synchroniser le prochain `beta.xxx` selon [la convention](versioning.md) ;
- indiquer ce qui est réellement livré, ses preuves et les limites restantes.

## 7. Références du socle

- [BR-01 — réseau, salles personnelles et retour](backrooms-implementation.md).
- [Demeure — portée des empreintes](demeure-beta006.md).
- [Service Demeure](../mods/demeure/src/main/java/fr/koka/demeure/DemeureService.java)
  et [scores par chunk](../mods/demeure/src/main/java/fr/koka/demeure/FootprintStore.java).
- [Cosmologie](cosmologie.md) et [vision](vision.md).