# GardenArena — Challenge IA GardenScript 0.5 : Bamboo Hazard Gauntlet v0.6

Copiez l'intégralité de ce document dans Grok, Claude, Codex, ChatGPT, Gemini
ou un modèle local. Votre IA doit rendre une seule stratégie GardenScript
compilable. GardenArena ne lui demandera plus rien pendant la simulation : le
programme sera compilé puis rejoué localement par le Living Systems Kernel.

---

## Repère de marque et contrat technique

**Living Systems Kernel (LSK), noyau déterministe écrit en Rust**, est le nom
public du socle qui compile, arbitre et rejoue cette arène. Cette marque ne
modifie aucun identifiant normatif : `garden-script-compiler-v0.5`,
`garden-bamboo-v0.6`, les hashes, les artefacts et les routes API conservent
exactement leur nom technique.

## Mission donnée à l'IA

Tu participes au challenge public **GardenArena Bamboo Hazard Gauntlet**.

Écris une politique originale de gestion d'un bambou traçant sur 365 jours en
**GardenScript 0.5**, domaine `bamboo`, ruleset `bamboo.v1`. La politique doit
surveiller les rhizomes, contenir les évasions détectées, entretenir les joints
de la barrière, gérer les cannes et irriguer sans épuiser les ressources. La
même colonie subit quatre stress synthétiques publiés : sécheresse, inondation,
tempête et déplacement d'un joint de barrière.

Le même scénario, les mêmes hypothèses, les mêmes budgets et le même moteur
Rust sont appliqués à chaque concurrent. Il n'y a aucun appel à un LLM, aucune
météo distante et aucun hasard pendant un run. La première branche `when` vraie
de chaque canal gagne ; si aucune ne l'est, `otherwise` est appliqué.

Optimise dans l'ordre lexicographique exact suivant — **il n'existe aucun score
composite** :

1. rester classable (`rankable`, vrai avant faux) ;
2. minimiser les apex actifs échappés à la fin ;
3. minimiser le nombre de jours non contenus ;
4. maximiser la proportion de segments contenus ;
5. maximiser la vitalité minimale atteinte pendant l'épreuve ;
6. maximiser le nombre final de cannes vivantes ;
7. maximiser la vitalité finale ;
8. minimiser le travail consommé ;
9. minimiser l'eau consommée ;
10. l'identifiant d'entrant ne sert qu'à départager une égalité parfaite.

Une économie de travail ou d'eau ne compense donc jamais une dégradation d'un
critère placé avant elle. Raisonne silencieusement sur les priorités, les
ressources et l'ordre des actions, puis rends uniquement le programme demandé.

## Contrat syntaxique normatif

Le compilateur Rust `garden-script-compiler-v0.5` est l'unique source de
vérité. L'enveloppe commence exactement ainsi, sans ligne vide :

```text
garden "Nom ASCII unique" version 0.5
domain bamboo
ruleset: bamboo.v1
```

Contraintes impératives :

- le nom contient de 1 à 64 caractères ASCII imprimables, sans guillemet ;
- la source fait au plus 16 Kio et utilise uniquement des fins de ligne LF ;
- aucune ligne vide, aucun commentaire, aucun `setup:` et aucun contenu final
  supplémentaire ne sont admis ;
- les cinq blocs sont obligatoires, uniques et dans cet ordre exact :
  `monitoring`, `containment`, `barrier`, `canopy`, `irrigation` ;
- chaque bloc contient entre 1 et 10 lignes `when`, puis exactement une ligne
  `otherwise` ;
- une branche contient de 1 à 8 prédicats reliés uniquement par ` and ` ;
- un prédicat est exactement `CAPTEUR OPERATEUR VALEUR`, avec un seul espace
  entre ses trois éléments ;
- les seuls opérateurs sont `<`, `<=`, `>`, `>=`, `==` ;
- la forme exacte d'une branche est
  `  when CONDITION => ACTION` et celle du repli
  `  otherwise => ACTION` — les deux espaces initiaux sont obligatoires ;
- une valeur est un nombre décimal fini en base 10, avec au plus trois
  décimales, immédiatement suivi de son unité : `35%`, `10day`, `25cm`,
  `90min`, jamais `35 %` ;
- le budget statique vaut
  `nombre_de_when + nombre_de_predicats + 5` et doit rester inférieur ou égal
  à 512 unités ; le budget VM est également de 512 unités ;
- il n'existe ni boucle, ni récursion, ni variable mutable, ni fonction, ni
  import, ni fichier, ni processus, ni environnement, ni horloge réelle, ni
  hasard, ni entrée/sortie, ni réseau.

Le programme doit donc avoir exactement cette ossature, complétée avec des
branches réelles :

```text
garden "Nom ASCII unique" version 0.5
domain bamboo
ruleset: bamboo.v1
decide monitoring:
  when CONDITION => ACTION_MONITORING
  otherwise => ACTION_MONITORING
decide containment:
  when CONDITION => ACTION_CONTAINMENT
  otherwise => ACTION_CONTAINMENT
decide barrier:
  when CONDITION => ACTION_BARRIER
  otherwise => ACTION_BARRIER
decide canopy:
  when CONDITION => ACTION_CANOPY
  otherwise => ACTION_CANOPY
decide irrigation:
  when CONDITION => QUANTITE_MM
  otherwise => QUANTITE_MM
```

Les mots `CONDITION`, `ACTION_*` et `QUANTITE_MM` ci-dessus sont seulement des
emplacements explicatifs : ils ne sont pas des éléments du langage.

## Les cinq canaux et leurs seules sorties

| Canal | Sorties autorisées |
|---|---|
| `monitoring` | `surface_scan`, `barrier_probe`, `full_perimeter` |
| `containment` | `observe`, `cut_detected_tip`, `excavate_detected_sector` |
| `barrier` | `none`, `inspect_joints`, `repair_worst_joint` |
| `canopy` | `keep`, `thin_old_canes`, `harvest_mature_canes` |
| `irrigation` | une quantité comprise entre `0mm` et `20mm` inclus |

Le compilateur accepte jusqu'à trois décimales pour l'irrigation, mais ce
runner consomme des millimètres entiers et tronque la fraction positive. Pour
une intention non ambiguë, utilise des quantités entières.

## Les 24 capteurs autorisés

Chaque seuil doit employer l'unité exacte et rester dans la borne DSL indiquée.
Aucun autre capteur n'existe.

| Capteur | Unité | Borne inclusive |
|---|---:|---:|
| `clock.day` | `day` | 0–366 |
| `calendar.season_progress_pct` | `%` | 0–100 |
| `weather.rain_7d_mm` | `mm` | 0–2 000 |
| `soil.water_pct` | `%` | 0–100 |
| `colony.vitality_pct` | `%` | 0–100 |
| `rhizome.active_tips_count` | `count` | 0–1 000 |
| `rhizome.segment_count` | `count` | 0–100 000 |
| `rhizome.max_spread_cm` | `cm` | 0–10 000 |
| `rhizome.max_depth_cm` | `cm` | 0–500 |
| `rhizome.nearest_barrier_cm` | `cm` | 0–10 000 |
| `rhizome.barrier_contacts_30d_count` | `count` | 0–1 000 |
| `rhizome.outside_active_tips_count` | `count` | 0–1 000 |
| `rhizome.detected_outside_tips_count` | `count` | 0–1 000 |
| `barrier.min_depth_cm` | `cm` | 0–500 |
| `barrier.exposed_lip_cm` | `cm` | 0–100 |
| `barrier.joint_integrity_pct` | `%` | 0–100 |
| `cane.shoots_count` | `count` | 0–1 000 |
| `cane.living_count` | `count` | 0–1 000 |
| `cane.mature_count` | `count` | 0–1 000 |
| `history.days_since_monitoring_day` | `day` | 0–366 |
| `history.days_since_cut_day` | `day` | 0–366 |
| `resource.water_left_mm` | `mm` | 0–2 000 |
| `resource.labor_left_min` | `min` | 0–100 000 |
| `resource.patch_left_count` | `count` | 0–1 000 |

À chaque évaluation, le moteur fournit exactement ces 24 observations. Les
distances exposées en `cm` proviennent de l'état entier en millimètres ; le
script ne voit jamais directement les identifiants ou la géométrie complète
des segments.

## Scénario officiel `bamboo-underground-365d-v1` — schéma 1.1

### Terrain et colonie initiale

- durée : 365 jours ;
- taxon sélectionné : Moso, *Phyllostachys edulis*, architecture leptomorphe ;
- origine de la colonie : `x = 0mm`, profondeur `220mm`, avec deux apex initiaux
  partant à gauche et à droite ;
- zone gérée : de `-1500mm` à `+1500mm` ;
- limite d'exclusion : de `-5000mm` à `+5000mm` ;
- eau du sol initiale : 52 % ; vitalité initiale : 90 % ;
- quatre cannes initiales : âges 1 460, 900, 420 et 180 jours ; hauteurs 18 m,
  17 m, 16,5 m et 15 m ;
- barrière verticale : profondeur nominale `760mm`, lèvre visible `150mm`,
  épaisseur nominale `2mm` ;
- deux joints à `x = -1500mm` et `x = +1500mm`, profondeur `300mm`, tolérance
  géométrique `100mm`, intégrité initiale 65 %.

### Budgets identiques pour chaque concurrent

- eau totale : `600mm` ;
- travail total : `2500min` ;
- réparations disponibles : `6count` patches.

Les soldes ne peuvent jamais devenir négatifs. Une intention trop coûteuse est
remplacée par le repli sûr du canal et le replay conserve l'intention demandée,
l'intention acceptée et la raison du refus.

### Calendrier sans météo distante

| Jours | Phase | Facteur rhizome | `rain_7d_mm` | Évaporation/jour | Pousses permises |
|---:|---|---:|---:|---:|---|
| 1–60 | `dormancy` | 0 % | `35mm` | `1mm` | non |
| 61–120 | `shoot_emergence` | 25 % | `28mm` | `2mm` | oui |
| 121–240 | `rhizome_expansion` | 100 % | `18mm` | `3mm` | non |
| 241–300 | `culm_hardening` | 45 % | `24mm` | `2mm` | non |
| 301–365 | `maintenance` | 10 % | `30mm` | `1mm` | non |

`calendar.season_progress_pct` repart de zéro dans chaque phase. Hors stress,
le moteur utilise `rain_7d_mm / 7` en division entière pour l'apport quotidien.
Pendant l'épreuve, `weather.rain_7d_mm` expose la somme des sept apports
journaliers effectivement forcés, jour courant inclus, et non le libellé brut
de la fenêtre saisonnière.

### Épreuve des quatre stress — contrat public partagé

Le scénario porte `stress_schedule.contract: synthetic_shared_stress.v1`. Le
noyau construit une seule table de forçage de 365 jours avant d'exécuter les
entrants. Chaque stratégie reçoit donc les mêmes jours, la même pluie, la même
évaporation, la même rafale et la même dégradation de barrière. Il n'existe ni
seed cachée, ni tirage, ni météo distante, ni stress adapté au concurrent.

| Stress synthétique | Jours | Forçage déterministe |
|---|---:|---|
| sécheresse d'été `summer-drought-01` | 130–165 | pluie quotidienne ×100/1000, puis division entière ; évaporation +`3mm/jour` |
| crue éclair `flash-flood-01` | 220–224 | pluie +`35mm/jour` ; drainage ×250/1000 ; perte de vitalité de 8/1000 par jour si l'engorgement atteint 600/1000 |
| tempête `windstorm-01` | 252–253 | rafale `105km/h`, seuil `90km/h`, fraction de dommage 10/1000 par km/h excédentaire sur les cannes d'au moins `5000mm` |
| déplacement de joint `joint-shift-01` | 254 | perte de 220/1000 sur `right-joint-1`, après les interventions du jour et avant la croissance des rhizomes |

La tempête trie les cannes éligibles par hauteur décroissante, âge décroissant,
puis identifiant croissant. Elle désactive chaque jour
`ceil(nombre_eligible × 150/1000)` cannes et retire 6/1000 de vitalité par
canne touchée. L'engorgement est un réservoir borné séparé de l'eau du sol ;
son drainage de base est 30/1000 par jour avant le multiplicateur de crue.

Ces valeurs sont des **mécaniques de tournoi**, toutes déclarées
`model_assumption` avec une confiance faible. Les études citées bornent la
direction de certains effets de sécheresse ; elles ne valident ni le calendrier
choisi, ni les coefficients de crue, de vent ou de déplacement du joint.

GardenScript reste strictement en version 0.5 et conserve ses 24 capteurs : il
n'existe pas de capteur secret `wind`, `waterlogging` ou `stress_id`. Une
politique peut anticiper le calendrier avec `clock.day`, observer la pluie
effective via `weather.rain_7d_mm`, puis constater les effets publics dans le
replay et, au jour suivant, dans les capteurs existants.

### Coefficients Moso de ce scénario

Ces coefficients sont publiés pour que tous les concurrents jouent le même
modèle ; ils ne sont pas des constantes botaniques universelles :

- extension de base : `45mm` par jour actif avant modificateurs ;
- biais horizontal : 970/1000 ; biais vertical : 80/1000 ;
- profondeur préférée : 120–300 mm ;
- tentative de branchement tous les 30 nœuds/jours actifs ;
- tentative de pousse tous les 24 nœuds/jours actifs pendant la fenêtre
  autorisée ;
- hauteur finale atteinte en 50 jours, puis gelée par invariant ;
- maturité de récolte : 1 095 jours ; plafond de hauteur du scénario : 20 m.

L'extension entière d'un apex actif est :

```text
growth_mm = 45
          × facteur_saisonnier_en_milliemes
          × vitalite_en_milliemes
          × max(eau_du_sol_en_milliemes, 100)
          / 1000³
```

Le moteur limite le modèle à 32 apex actifs ; arrivé à cette valeur, il ne
crée plus de branche supplémentaire. Atteindre la garde de 12 000 segments
rend la stratégie non classable.

### Eau, vitalité et foule

- cible hydrique : 55 % ; seuil de sécheresse : 30 % ;
- sous 30 %, la vitalité perd 0,4 point par jour ; à partir de 55 %, elle
  récupère 0,1 point par jour ;
- au-delà de 28 cannes vivantes, la vitalité perd 0,1 point par jour ;
- efficacité pluie + irrigation : 800/1000 dans l'équation simplifiée ;
- drainage de base de l'engorgement synthétique : 30/1000 par jour ;
- plancher de classabilité de la vitalité : 35 %.

### Perception, actions et coûts

Les cinq intentions du jour sont calculées sur un même instantané. Le noyau les
applique ensuite dans l'ordre `monitoring` → `containment` → `barrier` →
`canopy` → `irrigation`. Une détection du matin peut donc permettre une coupe
ou une excavation le même jour.

| Action | Effet borné | Coût |
|---|---|---:|
| `surface_scan` | détecte uniquement les apex actifs déjà extérieurs et à une profondeur ≤100 mm | 1 min |
| `barrier_probe` | détecte tout apex extérieur, ou un apex à ≤250 mm d'un panneau et à une profondeur ≤450 mm | 8 min |
| `full_perimeter` | détecte tous les apex actifs extérieurs | 20 min |
| `observe` | aucune contention | 0 |
| `cut_detected_tip` | désactive le premier apex actif détecté ; jamais un apex invisible | 25 min et −0,8 point de vitalité |
| `excavate_detected_sector` | désactive tous les apex actifs détectés et marque leurs segments extérieurs comme excavés | 90 min et −2,5 points de vitalité |
| `none` | aucune action sur la barrière | 0 |
| `inspect_joints` | inscrit l'intégrité de chaque joint dans le replay | 18 min |
| `repair_worst_joint` | ajoute 30 points, au maximum 100 %, au joint le moins intègre | 55 min et 1 patch |
| `keep` | conserve les cannes | 0 |
| `thin_old_canes` | retire au plus les deux plus vieilles cannes vivantes | 35 min |
| `harvest_mature_canes` | récolte au plus trois cannes vivantes âgées d'au moins 1 095 jours | 45 min |
| irrigation positive | ajoute l'eau entière acceptée au réservoir simplifié | quantité demandée + 2 min |

Une coupe ou une excavation sans cible détectée est refusée. Une récolte ne
peut jamais prendre une canne immature. La réparation vise toujours le joint
le plus faible. Les coûts de canopée et d'inspection peuvent être engagés même
si aucune modification utile n'en résulte : ne les déclenche pas gratuitement.

### Barrière et risques de brèche

- chaque contact situé près d'un joint lui retire 3 points d'intégrité ;
- sous 60 % d'intégrité après le contact, le segment traverse le joint ;
- sinon, un panneau intact dévie l'apex de `45mm` vers la surface ;
- une trajectoire peut aussi passer sous la profondeur nominale ou au-dessus
  de la lèvre ;
- le moteur est une coupe 2D : il ne simule ni contournement des extrémités en
  3D, ni perforation, ni tassement, ni soulèvement, ni vieillissement réel du
  matériau.

Le `barrier.joint_integrity_pct` observé est l'intégrité du pire joint avant
les actions du jour. Les contacts sont ensuite produits par la croissance du
même jour, après les éventuelles réparations.

### Causes de non-classabilité

Une stratégie devient définitivement non classable si :

- un apex encore actif dépasse `5000mm` de l'origine ;
- la vitalité passe sous 35 % ;
- le moteur atteint sa garde de 12 000 segments ;
- l'invariant qui interdit à une canne de grandir après sa date de hauteur
  finale est violé.

## Vérité scientifique et limites

Cet exercice est une **simulation déterministe pilotée par des hypothèses**, et
non une observation de terrain. Le scénario déclare
`data_origin: synthetic_hypothesis_scenario` et sa liste
`provenance.observed_inputs` est vide.

Il sépare explicitement :

- `literature_bound` : bornes rapprochées de sources publiées, par exemple la
  barrière et la fenêtre de hauteur du Moso ;
- `model_assumption` : vitesse de rhizome, usure des joints, déviation,
  hydrologie et autres coefficients inventés pour cette arène ;
- `observed_input` : mesure réelle, catégorie absente de ce scénario.

Le moteur ne localise pas un rhizome réel, ne prévoit pas sa vitesse annuelle,
ne garantit pas une barrière, ne prescrit pas de travaux et ne remplace pas une
inspection du site. La croissance rapide d'une pousse aérienne ne doit jamais
être confondue avec une vitesse de rhizome. Tous les états, contacts, brèches,
interventions et résultats du replay sont simulés.

Ancrages documentaires déclarés par le scénario : recommandations de
[l'University of Maryland Extension](https://extension.umd.edu/resource/containing-and-removing-bamboo)
et de la [Royal Horticultural Society](https://www.rhs.org.uk/plants/types/grasses/bamboo-control)
pour les ordres de grandeur de barrière ; étude publiée sur la
[croissance en hauteur du Moso](https://pmc.ncbi.nlm.nih.gov/articles/PMC5430563/)
pour la fenêtre taxon- et site-spécifique ; synthèse morphologique sur les
[rhizomes pachymorphes et leptomorphes](https://pmc.ncbi.nlm.nih.gov/articles/PMC8208805/) ;
études de la réponse du Moso à une
[sécheresse éclair](https://pmc.ncbi.nlm.nih.gov/articles/PMC6616449/) et à une
[sécheresse estivale](https://www.frontiersin.org/journals/plant-science/articles/10.3389/fpls.2023.1252862/full).
Ces sources bornent certains paramètres ; elles ne valident pas les résultats
du simulateur ni les coefficients marqués `model_assumption`.

Ordre journalier exact : forçage public du jour → observation → VM GardenScript
→ noyau de sûreté et interventions → eau et vitalité → cannes → effets des
stress → géométrie des rhizomes → contraintes dures → snapshot.

Chaque frame du replay recopie `forcing` (`active_stress_ids`, pluie du jour,
pluie effective sur sept jours, évaporation, rafale et multiplicateur de
drainage). Les débuts/fins de stress, pertes d'engorgement, cannes touchées et
dommages du joint sont des événements explicites. Le résumé publie les jours
de sécheresse, crue, engorgement et tempête, l'engorgement maximal, les cannes
touchées et les événements de dommage de barrière.

## Protocole d'évaluation et provenance obligatoire

Deux modes sont publics et ne doivent jamais être mélangés :

- **ONE-SHOT / AVEUGLE — classable** : la session de génération reçoit ce
  document figé, produit une seule réponse et n'accède ni au dépôt, ni au code
  du moteur, ni au scénario JSON, ni à un runner, ni à un résultat de combat.
  L'organisateur peut compiler cette réponse, mais ne redemande aucune
  correction au modèle et ne lui fournit aucun feedback d'exécution ;
- **OPEN-BOOK / ITÉRATIF — exhibition, hors classement** : toute lecture du
  moteur ou du dépôt, utilisation d'outils locaux, simulation, comparaison à
  une baseline, feedback de compilation, retouche ou nouvelle génération place
  définitivement la stratégie dans cette catégorie. Elle peut servir de
  « boss de laboratoire », jamais gagner le classement one-shot.

Pour chaque entrée, l'organisateur déclare au minimum le mode, le fournisseur,
le modèle et la version annoncés, la date, ainsi que, s'ils sont disponibles,
les SHA-256 du prompt exact et du transcript. Cette provenance est une
**déclaration de l'organisateur, non une certification du fournisseur**. Une
stratégie sans provenance suffisante peut rester classable comme politique
communautaire sous le badge **PROTOCOLE NON VÉRIFIÉ**, mais ne doit jamais être
présentée comme la preuve d'un duel IA aveugle. Toute lecture du moteur ou
itération locale connue impose en revanche le mode `OPEN-BOOK / ITÉRATIF`, donc
l'exhibition hors classement.

## Validation, API et MCP

Avant toute soumission, valide les octets exacts du programme.

### Compilateur Rust local

Depuis la racine du dépôt GardenArena :

```bash
cargo run --quiet --manifest-path rust_engine/Cargo.toml \
  --bin garden-script -- validate strategie-bambou.garden
```

Une validation réussie renvoie notamment `valid: true`, aucun diagnostic,
`compiler_version: garden-script-compiler-v0.5`, `source_sha256`,
`program_sha256` et l'IR canonique.

### API GardenArena

Ressources publiques en lecture :

- `https://gardenarena.io/api/gardenscript/spec/bamboo-v0.5`
- `https://gardenarena.io/api/gardenscript/examples/bamboo-containment-v0.5.garden`
- `https://gardenarena.io/api/bamboo/hazard-gauntlet`
- `https://gardenarena.io/api/bamboo/scenarios/featured`
- `https://gardenarena.io/api/bamboo/replays/featured`

Validation publique dédiée à la Forge bambou :
`POST https://gardenarena.io/api/bamboo/validate` avec le JSON strict
`{"source":"SOURCE EXACTE"}` et l'en-tête `Content-Type: application/json`.
Le champ `source` doit conserver exactement les LF et les espaces ; sa valeur
UTF-8 reste limitée à 16 Kio. L'enveloppe JSON possède une limite de transport
distincte afin d'accepter les caractères échappés. La réponse place le résultat
du compilateur dans `validation` et confirme `source_stored: false`,
`simulation_started: false`, `outbound_llm_calls: 0` et
`external_network_calls: 0`. Cette route compile seulement : elle ne lance
jamais les 365 jours.

La route générique authentifiée
`POST https://gardenarena.io/api/gardenscript/validate` reste disponible aux
comptes GardenArena. Ne donne jamais un cookie, un jeton ou un secret à une IA ;
le client humain ou l'application transporte sa propre session.

### Serveur MCP

Endpoint streamable HTTP : `https://gardenarena.io/mcp`.

1. lire la ressource `gardenarena://gardenscript/v0.5` ;
2. éventuellement lire
   `gardenarena://gardenscript/v0.5/examples/bamboo-containment` ;
3. appeler l'outil `validate_gardenscript` avec la source exacte ;
4. exiger `validation.valid == true` et `validation.diagnostics == []`.

Le MCP et l'API appellent le même compilateur Rust ; ils ne réimplémentent pas
la grammaire et effectuent zéro appel LLM. Ne demande pas à l'outil
`submit_garden_strategy` d'écrire quoi que ce soit sauf instruction explicite
de l'utilisateur ; l'écriture MCP est désactivée par défaut.

## Scellement et provenance

- `source_sha256` est le SHA-256 des octets UTF-8 exacts remis par l'auteur ;
- `program_sha256` est le SHA-256 de l'IR JSON canonique produit par Rust ;
- `scenario_sha256` scelle le scénario sémantique ;
- `ruleset_sha256` scelle le ruleset, les hypothèses du modèle, le calendrier
  de stress, la barrière et les budgets ;
- `arena_sha256` lie la version du moteur, les deux hashes précédents et la
  liste triée `[entrant_id, program_sha256]` ; il change quand l'ensemble des
  concurrents change ;
- `roster_seal_sha256`, publié au scellement de la saison, engage le manifeste
  canonique complet du registre : hashes source/programme/IR/validation,
  attribution, mode d'évaluation, statut et scénario. Le flag `OPEN-BOOK` y
  est donc lié et les lignes SQLite correspondantes deviennent immuables ;
- le fichier de replay publié possède en plus son propre SHA-256 de transport.

Empreintes stables de l'exhibition Hazard Gauntlet v0.6 actuellement
versionnée :

```text
engine_version          garden-bamboo-v0.6
engine_binary_sha256    f4110dfbe04678e93e06e28f7e93560ab233763cddad86357eb17f2b020ea9b3
scenario_sha256         45f60bca9e50f8d128a2571b570a6fc683f8799e9cfc3580c77c947ce3d9d275
ruleset_sha256          20decb6799bb1eaf61012b37d0ac78d23d3168e3197cf9281263a44a68c85ce3
arena_sha256            b49eefc65d3f4d5b83600a15704f7f2ef030d30f0171cfa9111f741ea65af8bd
replay_transport_sha256 869b40a82177a7b000f5bd20e94f51ae759fb3464301e484efb079920531893e
```

Cet `arena_sha256` engage uniquement les deux entrants
`underground_sentinel` et `measured_patience` du replay maison. Il ne sera pas
celui de la future saison publique : le roster scellé changera nécessairement
l'identité de l'arène, même si scénario, ruleset et binaire restent identiques.

Les empreintes v0.5 ci-dessous restent celles du replay historique publié le
14 juillet 2026. Elles ne décrivent pas le Hazard Gauntlet v0.6 :

```text
engine_version  garden-bamboo-v0.5
scenario_sha256 49dce1fa6d624557d5bb9517ea6866fb5e701afbb63791fac19e31e6ee08f9e1
ruleset_sha256  f4a87c536a14ba633a9e375371b0ae60fa866686ce65a1edd3fe00844645a73e
arena_sha256    c2dd95714778ae8290b33162154950f5b82f4a80c8c755dac5fbb605ad50af92
artifact_sha256 7a080e39c26da82001f362d69f697c3a36bc29d7ce6a7f4aa507453c82966a1f
```

L'`arena_sha256` v0.5 ci-dessus concerne seulement les deux entrants de ce
replay historique. Il ne doit pas être recopié comme hash d'une nouvelle arène.

Pour une attribution honnête, l'organisateur conserve séparément le fournisseur,
le nom et la version déclarés du modèle, ainsi que, si disponibles, les hashes
SHA-256 du prompt et du transcript. Une attribution déclarée n'est pas une
attestation du fournisseur.

## Format de réponse obligatoire

Réponds avec **une seule source GardenScript 0.5 complète et originale**.

N'ajoute aucun préambule, aucune explication, aucun diagnostic, aucun hash,
aucune citation et aucune clôture. N'utilise pas de bloc Markdown ni de lignes
avec trois accents graves. La première ligne de ta réponse doit commencer par
`garden "` et la dernière doit être la ligne `otherwise` du canal
`irrigation`.

**Réponse attendue : le code GardenScript brut, et rien d'autre.**