BridgePedia - Contributi dell'utente [it]

XYZ

2026-11-10T20:55:50Z

Lpala: XYZ: scenari 5 e 7 shape_constraints e esempio 2P non rialzo coerente

{{DEFAULTSORT:XYZ}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]

{{Convenzione
|nome=XYZ
|tipologia=Sviluppo
|scopo=Dopo certe sequenze di apertura e risposta a livello 1 con ridichiarazione dell'apertore, rendere artificiali e forzanti le ridichiarazioni 2{{fiori}} e 2{{quadri}} del rispondente, così da distinguere a basso livello le mani d'invito da quelle più forti. Secondo l'articolo di Danny Kleinman l'ideazione è attribuita a Joe Kivel.
|trigger=Dieci sequenze senza interventi iniziate da una mano non passata. Quattro "a tre colori" a livello 1: 1{{fiori}}-1{{quadri}};1{{cuori}}, 1{{fiori}}-1{{quadri}};1{{picche}}, 1{{fiori}}-1{{cuori}};1{{picche}}, 1{{quadri}}-1{{cuori}};1{{picche}}. Sei con apertura, risposta e 1SA dell'apertore: 1{{fiori}}-1{{quadri}}, 1{{fiori}}-1{{cuori}}, 1{{fiori}}-1{{picche}}, 1{{quadri}}-1{{cuori}}, 1{{quadri}}-1{{picche}}, 1{{cuori}}-1{{picche}}, tutte seguite da 1SA.
|risposte=Nelle quattro sequenze a tre colori: 2{{fiori}} del rispondente = "puppet" verso 2{{quadri}}: non mostra quadri, è artificiale e forzante e l'apertore deve dire 2{{quadri}} con qualunque mano (niente super-accettazioni a 3{{quadri}} né preferenze a salto). Il rispondente può passare 2{{quadri}} con mano debole, oppure dichiarare un colore naturale al giro successivo con mano d'invito (se non è a salto è un invito, da spiegare agli avversari). 2{{quadri}} del rispondente = artificiale e forzante a manche, poi si torna al naturale. 2{{cuori}} è naturale e scoraggiante; 2{{picche}} è naturale e scoraggiante solo se è un rialzo, mentre 2{{picche}} non rialzo e le dichiarazioni più alte sono forzanti e da slam. Dopo 1SA dell'apertore (sei sequenze) 2{{fiori}} e 2{{quadri}} funzionano come il New Minor Forcing.
|note=Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata. Costi indicati dall'autore: si perde la preferenza a 2{{fiori}} dopo 1{{fiori}}-1{{cuori}};1{{picche}}, si creano molte mani orfane, e dopo 1SA si perde il semplice ritiro a 2{{fiori}} (per esempio dopo 1{{fiori}}-1{{picche}};1SA e 1{{quadri}}-1{{picche}};1SA). Il range dell'1SA di ridichiarazione non è indicato nella fonte: negli scenari si usa 12-14 PO come ipotesi di lavoro. Negli scenari l'apertore ha sempre 12-14 PO (con 15-17 bilanciati aprirebbe 1SA, quindi non ha una mano da 1SA) e il rispondente ha mano debole (5-8 PO) oppure 11 o più PO; tutti gli intervalli di punti sono ipotesi nostre (non indicato nella fonte). Varianti sui check-back dopo 1SA citate dalla fonte: Second Round Stayman e Hi-Ro-Jerum. La preferenza dell'autore (non usare check-back) è una sua opinione.
|tag_cc=response_xyz
|tag_sistema=naturale
|shape_constraints=1D-1H;1S poi 2C puppet e passo dopo 2D (rispondente debole con 4 cuori e fit a quadri): pairhcp:17-22 opener D:4+ S:4 H:0-3 hcp:12-14; responder H:4+ D:3+ S:0-3 hcp:5-8; opp1 quiet; opp2 quiet // 1D-1H;1S 2C puppet poi invito a manche con colore naturale (11-12 PO): pairhcp:23-26 opener D:4+ S:4 H:0-3 hcp:12-14; responder S:4 H:5 hcp:11-12; opp1 quiet; opp2 quiet // 2D forzante a manche dopo 1C-1D;1H: pairhcp:24-29 opener C:3+ H:4 D:0-3 hcp:12-14; responder D:5+ H:3 hcp:12-15; opp1 quiet; opp2 quiet // 2H naturale scoraggiante dopo 1C-1H;1S: pairhcp:17-22 opener C:4+ S:4 H:0-2 hcp:12-14; responder H:6 S:3 hcp:5-8; opp1 quiet; opp2 quiet // 2S non rialzo forzante da slam dopo 1C-1D;1H: pairhcp:25-30 opener C:4+ H:4 hcp:12-14; responder S:5 D:5 hcp:13-16; opp1 quiet; opp2 quiet // new minor forcing dopo 1C-1S;1SA con 2D (1SA 12-14 ipotesi): pairhcp:24-29 opener shape:balanced S:2-3 hcp:12-14; responder S:5 hcp:12-15; opp1 quiet; opp2 quiet // costo dopo 1D-1S;1SA perso il ritiro a 2C naturale (1SA 12-14 ipotesi): pairhcp:17-22 opener shape:balanced S:0-3 hcp:12-14; responder S:4 C:5+ hcp:5-8; opp1 quiet; opp2 quiet // quadri lunghe e 2D artificiale forzante dopo 1C-1D;1S: pairhcp:25-31 opener C:3+ S:4 hcp:12-14; responder D:6+ S:0-3 hcp:13-17; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=XYZ: dopo 1m-1x;1y (tre colori a livello 1) e dopo 1SA dell'apertore, 2♣ = puppet verso 2♦, 2♦ = artificiale forzante a manche
|cc_text_response_xyz=XYZ: 2♣ puppet verso 2♦ (debole: passo; invito: colore naturale dopo 2♦), 2♦ artificiale GF; 2♥ naturale scoraggiante
}}

<div style="border:1px solid #c80; padding:6px;">'''Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata.'''</div>

La '''XYZ''' è una convenzione di sviluppo del rispondente che, secondo l'articolo di Danny Kleinman su Bridgebum.com, è attribuita a Joe Kivel. Si applica a dieci sequenze senza interventi e rende artificiali e forzanti le ridichiarazioni a 2{{fiori}} e 2{{quadri}}.

== Dominio ==
Le sequenze interessate (avversari sempre passati, apertura da mano non passata) sono dieci.
* Quattro sequenze "a tre colori" tutte a livello 1: 1{{fiori}} 1{{quadri}} 1{{cuori}}; 1{{fiori}} 1{{quadri}} 1{{picche}}; 1{{fiori}} 1{{cuori}} 1{{picche}}; 1{{quadri}} 1{{cuori}} 1{{picche}}.
* Sei sequenze con 1SA dell'apertore: 1{{fiori}} 1{{quadri}}, 1{{fiori}} 1{{cuori}}, 1{{fiori}} 1{{picche}}, 1{{quadri}} 1{{cuori}}, 1{{quadri}} 1{{picche}}, 1{{cuori}} 1{{picche}}, in ogni caso seguite da 1SA.

== Come si gioca senza XYZ ==
Per capire che cosa si sostituisce, l'articolo descrive prima il metodo naturale. Nelle sequenze a tre colori le ridichiarazioni a Senza del rispondente sono naturali (1SA circa 6-10 PO, 2SA 11-12, 3SA 13-17); i rialzi del nobile dell'apertore e la ripetizione del proprio nobile hanno range analoghi. Il quarto colore (forzante e spesso artificiale) serve a mantenere la dichiarazione aperta con mani forti. Nel naturale i salti a livello 3 nel quarto colore sono semplicemente invitanti.

== Le ridichiarazioni del rispondente con XYZ ==
=== 2{{fiori}}: il puppet ===
Il 2{{fiori}} somiglia a un transfer, ma non mostra quadri: l'apertore deve dire 2{{quadri}} qualunque mano abbia, senza super-accettazioni a 3{{quadri}} né preferenze a salto. Il 2{{fiori}} è artificiale e forzante (da spiegare agli avversari).
* Con mano debole il rispondente passa il 2{{quadri}} obbligato.
* Con mano d'invito a manche dichiara al giro successivo un colore naturale; se la dichiarazione non è a salto è un invito (da spiegare). Rispetto al metodo standard resta un livello di dichiarazione in più per un eventuale tentativo dell'apertore.

=== 2{{quadri}}: artificiale e forzante a manche ===
Il 2{{quadri}} è artificiale e forzante a manche; dopo di esso si torna alla dichiarazione naturale. Lascia spazio all'apertore, per esempio, per dichiarare 2SA e quindi giocare i Senza dalla mano giusta.

=== 2{{cuori}} e 2{{picche}} ===
2{{cuori}} è naturale e scoraggiante, come nel metodo standard. 2{{picche}} è naturale e scoraggiante quando è un rialzo; se non è un rialzo, e per tutte le dichiarazioni più alte, la mano è forzante e da slam.

== Dopo 1SA dell'apertore ==
Nelle sei sequenze con 1SA la XYZ funziona come il New Minor Forcing: le ridichiarazioni 2{{fiori}} e 2{{quadri}} diventano artificiali. Per la descrizione dettagliata dei check-back si rimanda alla fonte.

== Vantaggi ==
Secondo la fonte la XYZ distingue a basso costo le mani d'invito a manche da quelle più forti, sia nelle sequenze a tre colori sia in quelle con 1SA dell'apertore. L'autore la definisce un po' più semplice dei metodi naturali che sostituisce.

== Costi ==
Secondo la fonte:
* si perde la preferenza a 2{{fiori}} dopo 1{{fiori}} 1{{cuori}}; 1{{picche}} (non si può dichiarare 2{{fiori}} con una mano come <hand>K6.K1098.653.Q976</hand>);
* si creano molte "mani orfane", cioè mani che avevano una dichiarazione naturale ora sottratta;
* dopo 1SA dell'apertore si perde il semplice ritiro a 2{{fiori}} dopo 1{{fiori}} 1{{picche}}; 1SA (per esempio con <hand>KQ98.J76.42.Q972</hand>) e a 2{{fiori}} dopo 1{{quadri}} 1{{picche}}; 1SA o 1{{quadri}} 1{{cuori}}; 1SA;
* si perde l'opzione di chiedere una preferenza al proprio nobile dopo 1{{fiori}} 1{{cuori}} 1SA (con una 5-5 cuori-quadri e simili);
* il danno è un po' maggiore che con il solo NMF o con un check-back a 2{{fiori}}, perché diventano orfane due dichiarazioni naturali, 2{{fiori}} e 2{{quadri}}.

== Esempi ==
=== Puppet e passo ===
Rispondente debole con fit a quadri. Sud apre di 1{{quadri}}:

Sud: <hand>AQ73.82.KJ752.A4</hand>

Nord: <hand>K6.QJ98.Q1094.986</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P P P</bidding>

Il 2{{fiori}} di Nord è un puppet (non mostra quadri), Sud dice 2{{quadri}} obbligato e Nord passa.

=== Puppet e invito a manche ===
Nord ha 10 PO e una mano d'invito: dopo il puppet dichiara il colore in modo naturale, non a salto.

Sud: <hand>KJ74.K4.AQ752.83</hand>

Nord: <hand>QJ85.A10952.93.K4</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P 2S P 4S P P P</bidding>

Con la mano massima Sud accetta l'invito a 2{{picche}} e arriva a manche.

=== 2{{quadri}} forzante a manche ===
Nord ha 13 PO e quadri quinte: il 2{{quadri}} è artificiale e forzante a manche, lascia a Sud lo spazio per 2SA.

Sud: <hand>Q65.AK82.84.K1087</hand>

Nord: <hand>A8.QJ4.QJ1042.K104</hand>

<bidding dealer="S">1C P 1D P 1H P 2D P 2NT P 3NT P P P</bidding>

=== 2{{picche}} non rialzo (forzante, da slam) ===
Nord ha un bicolore 5-5 picche-quadri (14 PO). Dopo 1{{fiori}} 1{{quadri}} 1{{cuori}} il 2{{picche}} non è un rialzo e quindi è forzante con interesse di slam.

Sud: <hand>K4.AJ73.83.KQ962</hand>

Nord: <hand>AQJ85.6.AQJ85.74</hand>

<bidding dealer="S">1C P 1D P 1H P 2S P</bidding>

== Varianti ==
La fonte non propone varianti della XYZ in senso stretto: cita invece, come alternative ai check-back dopo 1SA dell'apertore, il '''Second Round Stayman''' (2{{fiori}} chiede prima un nobile quarto non dichiarato, poi tre carte nel nobile del rispondente; il solo orfano è un 2{{fiori}} naturale) e il ''Hi-Ro-Jerum'', che incorpora la "Spade Inversion". Non esistono pagine di varianti nel wiki.

== Opinione dell'autore ==
Kleinman osserva che la XYZ e i check-back dopo 1SA possono essere utili in alcune smazzate, ma che fanno più male che bene per via delle mani orfane che creano. Poiché preferisce rialzare liberamente le risposte di 1{{cuori}} e 1{{picche}}, dichiara di non averli mai usati. È una sua scelta personale, non una regola.

== Vedi anche ==
* [[Walsh]] — Nella lezione 05 del ''Corso Preagonistica 2026'' di Marina Causa la prosecuzione dopo la Walsh è chiamata "XY" ed è analoga nello schema (2{{fiori}} puppet verso 2{{quadri}}, 2{{quadri}} relé forzante a manche, 2SA transfer a 3{{fiori}}). Le due convenzioni hanno uno schema affine ma non sono la stessa: la XYZ è definita dall'articolo di Bridgebum sulle dieci sequenze sopra indicate.

== Fonti ==
* Danny Kleinman, "XYZ", Bridgebum.com, © Jeff Tang, https://www.bridgebum.com/xyz.php (ideazione attribuita a Joe Kivel secondo l'articolo). Sintesi e riscrittura in italiano; gli esempi sono rielaborati.

XYZ

2026-11-10T20:45:26Z

Lpala: shape_constraints: apertore 12-14 PO, rispondente debole o 11+; chiariti range ipotetici

{{DEFAULTSORT:XYZ}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]

{{Convenzione
|nome=XYZ
|tipologia=Sviluppo
|scopo=Dopo certe sequenze di apertura e risposta a livello 1 con ridichiarazione dell'apertore, rendere artificiali e forzanti le ridichiarazioni 2{{fiori}} e 2{{quadri}} del rispondente, così da distinguere a basso livello le mani d'invito da quelle più forti. Secondo l'articolo di Danny Kleinman l'ideazione è attribuita a Joe Kivel.
|trigger=Dieci sequenze senza interventi iniziate da una mano non passata. Quattro "a tre colori" a livello 1: 1{{fiori}}-1{{quadri}};1{{cuori}}, 1{{fiori}}-1{{quadri}};1{{picche}}, 1{{fiori}}-1{{cuori}};1{{picche}}, 1{{quadri}}-1{{cuori}};1{{picche}}. Sei con apertura, risposta e 1SA dell'apertore: 1{{fiori}}-1{{quadri}}, 1{{fiori}}-1{{cuori}}, 1{{fiori}}-1{{picche}}, 1{{quadri}}-1{{cuori}}, 1{{quadri}}-1{{picche}}, 1{{cuori}}-1{{picche}}, tutte seguite da 1SA.
|risposte=Nelle quattro sequenze a tre colori: 2{{fiori}} del rispondente = "puppet" verso 2{{quadri}}: non mostra quadri, è artificiale e forzante e l'apertore deve dire 2{{quadri}} con qualunque mano (niente super-accettazioni a 3{{quadri}} né preferenze a salto). Il rispondente può passare 2{{quadri}} con mano debole, oppure dichiarare un colore naturale al giro successivo con mano d'invito (se non è a salto è un invito, da spiegare agli avversari). 2{{quadri}} del rispondente = artificiale e forzante a manche, poi si torna al naturale. 2{{cuori}} è naturale e scoraggiante; 2{{picche}} è naturale e scoraggiante solo se è un rialzo, mentre 2{{picche}} non rialzo e le dichiarazioni più alte sono forzanti e da slam. Dopo 1SA dell'apertore (sei sequenze) 2{{fiori}} e 2{{quadri}} funzionano come il New Minor Forcing.
|note=Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata. Costi indicati dall'autore: si perde la preferenza a 2{{fiori}} dopo 1{{fiori}}-1{{cuori}};1{{picche}}, si creano molte mani orfane, e dopo 1SA si perde il semplice ritiro a 2{{fiori}} (per esempio dopo 1{{fiori}}-1{{picche}};1SA e 1{{quadri}}-1{{picche}};1SA). Il range dell'1SA di ridichiarazione non è indicato nella fonte: negli scenari si usa 12-14 PO come ipotesi di lavoro. Negli scenari l'apertore ha sempre 12-14 PO (con 15-17 bilanciati aprirebbe 1SA, quindi non ha una mano da 1SA) e il rispondente ha mano debole (5-8 PO) oppure 11 o più PO; tutti gli intervalli di punti sono ipotesi nostre (non indicato nella fonte). Varianti sui check-back dopo 1SA citate dalla fonte: Second Round Stayman e Hi-Ro-Jerum. La preferenza dell'autore (non usare check-back) è una sua opinione.
|tag_cc=response_xyz
|tag_sistema=naturale
|shape_constraints=1D-1H;1S poi 2C puppet e passo dopo 2D (rispondente debole con 4 cuori e fit a quadri): pairhcp:17-22 opener D:4+ S:4 H:0-3 hcp:12-14; responder H:4+ D:3+ S:0-3 hcp:5-8; opp1 quiet; opp2 quiet // 1D-1H;1S 2C puppet poi invito a manche con colore naturale (11-12 PO): pairhcp:23-26 opener D:4+ S:4 H:0-3 hcp:12-14; responder S:4 H:5 hcp:11-12; opp1 quiet; opp2 quiet // 2D forzante a manche dopo 1C-1D;1H: pairhcp:24-29 opener C:3+ H:4 D:0-3 hcp:12-14; responder D:5+ H:3 hcp:12-15; opp1 quiet; opp2 quiet // 2H naturale scoraggiante dopo 1C-1H;1S: pairhcp:17-22 opener C:4+ S:4 H:0-2 hcp:12-14; responder H:6 S:3 hcp:5-8; opp1 quiet; opp2 quiet // 2S non rialzo forzante da slam dopo 1C-1D;1H: pairhcp:27-32 opener C:4+ H:4 hcp:12-14; responder S:5 D:6+ hcp:15-18; opp1 quiet; opp2 quiet // new minor forcing dopo 1C-1S;1SA con 2D (1SA 12-14 ipotesi): pairhcp:24-29 opener shape:balanced S:2-3 hcp:12-14; responder S:5 hcp:12-15; opp1 quiet; opp2 quiet // costo dopo 1D-1S;1SA perso il ritiro a 2C naturale (1SA 12-14 ipotesi): pairhcp:17-22 opener shape:balanced hcp:12-14; responder S:4 C:5+ hcp:5-8; opp1 quiet; opp2 quiet // quadri lunghe e 2D artificiale forzante dopo 1C-1D;1S: pairhcp:25-31 opener C:3+ S:4 hcp:12-14; responder D:6+ S:0-3 hcp:13-17; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=XYZ: dopo 1m-1x;1y (tre colori a livello 1) e dopo 1SA dell'apertore, 2♣ = puppet verso 2♦, 2♦ = artificiale forzante a manche
|cc_text_response_xyz=XYZ: 2♣ puppet verso 2♦ (debole: passo; invito: colore naturale dopo 2♦), 2♦ artificiale GF; 2♥ naturale scoraggiante
}}

<div style="border:1px solid #c80; padding:6px;">'''Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata.'''</div>

La '''XYZ''' è una convenzione di sviluppo del rispondente che, secondo l'articolo di Danny Kleinman su Bridgebum.com, è attribuita a Joe Kivel. Si applica a dieci sequenze senza interventi e rende artificiali e forzanti le ridichiarazioni a 2{{fiori}} e 2{{quadri}}.

== Dominio ==
Le sequenze interessate (avversari sempre passati, apertura da mano non passata) sono dieci.
* Quattro sequenze "a tre colori" tutte a livello 1: 1{{fiori}} 1{{quadri}} 1{{cuori}}; 1{{fiori}} 1{{quadri}} 1{{picche}}; 1{{fiori}} 1{{cuori}} 1{{picche}}; 1{{quadri}} 1{{cuori}} 1{{picche}}.
* Sei sequenze con 1SA dell'apertore: 1{{fiori}} 1{{quadri}}, 1{{fiori}} 1{{cuori}}, 1{{fiori}} 1{{picche}}, 1{{quadri}} 1{{cuori}}, 1{{quadri}} 1{{picche}}, 1{{cuori}} 1{{picche}}, in ogni caso seguite da 1SA.

== Come si gioca senza XYZ ==
Per capire che cosa si sostituisce, l'articolo descrive prima il metodo naturale. Nelle sequenze a tre colori le ridichiarazioni a Senza del rispondente sono naturali (1SA circa 6-10 PO, 2SA 11-12, 3SA 13-17); i rialzi del nobile dell'apertore e la ripetizione del proprio nobile hanno range analoghi. Il quarto colore (forzante e spesso artificiale) serve a mantenere la dichiarazione aperta con mani forti. Nel naturale i salti a livello 3 nel quarto colore sono semplicemente invitanti.

== Le ridichiarazioni del rispondente con XYZ ==
=== 2{{fiori}}: il puppet ===
Il 2{{fiori}} somiglia a un transfer, ma non mostra quadri: l'apertore deve dire 2{{quadri}} qualunque mano abbia, senza super-accettazioni a 3{{quadri}} né preferenze a salto. Il 2{{fiori}} è artificiale e forzante (da spiegare agli avversari).
* Con mano debole il rispondente passa il 2{{quadri}} obbligato.
* Con mano d'invito a manche dichiara al giro successivo un colore naturale; se la dichiarazione non è a salto è un invito (da spiegare). Rispetto al metodo standard resta un livello di dichiarazione in più per un eventuale tentativo dell'apertore.

=== 2{{quadri}}: artificiale e forzante a manche ===
Il 2{{quadri}} è artificiale e forzante a manche; dopo di esso si torna alla dichiarazione naturale. Lascia spazio all'apertore, per esempio, per dichiarare 2SA e quindi giocare i Senza dalla mano giusta.

=== 2{{cuori}} e 2{{picche}} ===
2{{cuori}} è naturale e scoraggiante, come nel metodo standard. 2{{picche}} è naturale e scoraggiante quando è un rialzo; se non è un rialzo, e per tutte le dichiarazioni più alte, la mano è forzante e da slam.

== Dopo 1SA dell'apertore ==
Nelle sei sequenze con 1SA la XYZ funziona come il New Minor Forcing: le ridichiarazioni 2{{fiori}} e 2{{quadri}} diventano artificiali. Per la descrizione dettagliata dei check-back si rimanda alla fonte.

== Vantaggi ==
Secondo la fonte la XYZ distingue a basso costo le mani d'invito a manche da quelle più forti, sia nelle sequenze a tre colori sia in quelle con 1SA dell'apertore. L'autore la definisce un po' più semplice dei metodi naturali che sostituisce.

== Costi ==
Secondo la fonte:
* si perde la preferenza a 2{{fiori}} dopo 1{{fiori}} 1{{cuori}}; 1{{picche}} (non si può dichiarare 2{{fiori}} con una mano come <hand>K6.K1098.653.Q976</hand>);
* si creano molte "mani orfane", cioè mani che avevano una dichiarazione naturale ora sottratta;
* dopo 1SA dell'apertore si perde il semplice ritiro a 2{{fiori}} dopo 1{{fiori}} 1{{picche}}; 1SA (per esempio con <hand>KQ98.J76.42.Q972</hand>) e a 2{{fiori}} dopo 1{{quadri}} 1{{picche}}; 1SA o 1{{quadri}} 1{{cuori}}; 1SA;
* si perde l'opzione di chiedere una preferenza al proprio nobile dopo 1{{fiori}} 1{{cuori}} 1SA (con una 5-5 cuori-quadri e simili);
* il danno è un po' maggiore che con il solo NMF o con un check-back a 2{{fiori}}, perché diventano orfane due dichiarazioni naturali, 2{{fiori}} e 2{{quadri}}.

== Esempi ==
=== Puppet e passo ===
Rispondente debole con fit a quadri. Sud apre di 1{{quadri}}:

Sud: <hand>AQ73.82.KJ752.A4</hand>

Nord: <hand>K6.QJ98.Q1094.986</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P P P</bidding>

Il 2{{fiori}} di Nord è un puppet (non mostra quadri), Sud dice 2{{quadri}} obbligato e Nord passa.

=== Puppet e invito a manche ===
Nord ha 10 PO e una mano d'invito: dopo il puppet dichiara il colore in modo naturale, non a salto.

Sud: <hand>KJ74.K4.AQ752.83</hand>

Nord: <hand>QJ85.A10952.93.K4</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P 2S P 4S P P P</bidding>

Con la mano massima Sud accetta l'invito a 2{{picche}} e arriva a manche.

=== 2{{quadri}} forzante a manche ===
Nord ha 13 PO e quadri quinte: il 2{{quadri}} è artificiale e forzante a manche, lascia a Sud lo spazio per 2SA.

Sud: <hand>Q65.AK82.84.K1087</hand>

Nord: <hand>A8.QJ4.QJ1042.K104</hand>

<bidding dealer="S">1C P 1D P 1H P 2D P 2NT P 3NT P P P</bidding>

=== 2{{picche}} non rialzo (forzante, da slam) ===
Nord ha un bicolore forte picche-quadri. Dopo 1{{fiori}} 1{{quadri}} 1{{cuori}} il 2{{picche}} non è un rialzo e quindi è forzante con interesse di slam.

Sud: <hand>K4.AJ73.83.KQ962</hand>

Nord: <hand>AKQ85.6.KQJ1042.7</hand>

<bidding dealer="S">1C P 1D P 1H P 2S P</bidding>

== Varianti ==
La fonte non propone varianti della XYZ in senso stretto: cita invece, come alternative ai check-back dopo 1SA dell'apertore, il '''Second Round Stayman''' (2{{fiori}} chiede prima un nobile quarto non dichiarato, poi tre carte nel nobile del rispondente; il solo orfano è un 2{{fiori}} naturale) e il ''Hi-Ro-Jerum'', che incorpora la "Spade Inversion". Non esistono pagine di varianti nel wiki.

== Opinione dell'autore ==
Kleinman osserva che la XYZ e i check-back dopo 1SA possono essere utili in alcune smazzate, ma che fanno più male che bene per via delle mani orfane che creano. Poiché preferisce rialzare liberamente le risposte di 1{{cuori}} e 1{{picche}}, dichiara di non averli mai usati. È una sua scelta personale, non una regola.

== Vedi anche ==
* [[Walsh]] — Nella lezione 05 del ''Corso Preagonistica 2026'' di Marina Causa la prosecuzione dopo la Walsh è chiamata "XY" ed è analoga nello schema (2{{fiori}} puppet verso 2{{quadri}}, 2{{quadri}} relé forzante a manche, 2SA transfer a 3{{fiori}}). Le due convenzioni hanno uno schema affine ma non sono la stessa: la XYZ è definita dall'articolo di Bridgebum sulle dieci sequenze sopra indicate.

== Fonti ==
* Danny Kleinman, "XYZ", Bridgebum.com, © Jeff Tang, https://www.bridgebum.com/xyz.php (ideazione attribuita a Joe Kivel secondo l'articolo). Sintesi e riscrittura in italiano; gli esempi sono rielaborati.

Walsh

2026-11-03T06:11:11Z

Lpala: Vedi anche: XYZ

{{DEFAULTSORT:Walsh}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]
[[Categoria:Risposte a 1 fiori]]

{{Convenzione
|nome=Walsh
|tipologia=Sviluppo
|scopo=Su apertura di 1{{fiori}}, anticipare il maggiore a discapito delle quadri (anche se più lunghe) con tutte le mani da 4 a 11 punti, per mettere in pista un nobile scavalcando le quadri (utile nella competizione) e per nascondere all'attacco le eventuali quarte nobili dell'apertore bilanciato.
|trigger=Apertura di 1{{fiori}} del compagno. Il rispondente con 4+ carte in un nobile e 4-11 punti onori risponde direttamente 1{{cuori}} o 1{{picche}}, saltando le quadri. Con mano da manche (FM, 12+ PO) si segue la sequenza naturale: 1{{quadri}} (solo se quinte o più), poi il nobile.
|risposte=Da 4 a 11 PO con un nobile: 1{{cuori}}/1{{picche}} diretto, anche con quadri più lunghe. Mano FM (12+): 1{{quadri}} (solo con quadri quinte o più) e poi il nobile; con quadri solo quarte si risponde comunque 1{{cuori}}. Dopo 1{{fiori}} 1{{quadri}}, se l'apertore ridichiara un colore a livello 1 mostra una mano sbilanciata (fiori lunghi o tricolore); se ridichiara 1SA, dopo 1{{fiori}} 1{{quadri}} 1SA la ridichiarazione 2{{cuori}} del rispondente garantisce i cuori. Prosecuzione XY (dopo 1{{fiori}}-1{{quadri}}-1 e simili): 2{{fiori}} = transfer per 2{{quadri}} (parziale a quadri o tutte le mani di invito); 2{{quadri}} = relé forzante manche; 2SA = transfer per 3{{fiori}} (parziale a fiori o mani 5/5 di 15+ con almeno due onori maggiori in entrambi i colori).
|note=Contenuto trascritto da slide: revisione da parte di un esperto consigliata. Il range dell'1SA di ridichiarazione dell'apertore non è indicato nella fonte. Con l'XY: la ripetizione del nobile di risposta è da passare; la dichiarazione di 2{{cuori}} dopo risposta 1{{picche}} non è forzante (max 9/10); tutte le dichiarazioni a livello tre, tradizionalmente invitanti e quindi passabili, diventano forzanti manche (perché tutti gli inviti passano dal 2{{fiori}}).
|tag_cc=response_walsh
|tag_sistema=naturale,quinta_nobile
|shape_constraints=1H su 1C con 4 cuori e 4-11 PO, saltando le quadri: pairhcp:16-28 opener hcp:12-17; responder H:4+ hcp:4-11; opp1 quiet; opp2 quiet // 1H con quadri più lunghe (quadri saltate): pairhcp:16-28 opener hcp:12-17; responder H:4 D:5+ hcp:4-11; opp1 quiet; opp2 quiet // 1S su 1C con 4 picche e 4-11 PO, saltando le quadri: pairhcp:16-28 opener hcp:12-17; responder S:4+ hcp:4-11; opp1 quiet; opp2 quiet // 1S con quadri più lunghe (quadri saltate): pairhcp:16-28 opener hcp:12-17; responder S:4 D:5+ hcp:4-11; opp1 quiet; opp2 quiet // FM con quadri 5+ e cuori quarti 1D poi cuori: pairhcp:24-33 opener hcp:12-17; responder D:5+ H:4 hcp:12-16; opp1 quiet; opp2 quiet // FM con quadri 5+ e picche quarte 1D poi picche: pairhcp:24-33 opener hcp:12-17; responder D:5+ S:4 hcp:12-16; opp1 quiet; opp2 quiet // apertore bilanciato che ridichiara 1SA dopo 1D (range 1SA non indicato nella fonte): pairhcp:18-28 opener shape:balanced hcp:12-14; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // apertore sbilanciato con fiori lunghi che ridichiara a livello 1 dopo 1D: pairhcp:18-28 opener C:6+ S:4 hcp:12-17; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // apertore tricolore che ridichiara a livello 1 dopo 1D: pairhcp:18-28 opener shape:three_suiter S:4 hcp:12-17; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // transfer 2C per parziale a quadri dopo 1S 1SA: pairhcp:16-24 opener shape:balanced hcp:12-14; responder S:4 D:5 hcp:5-9; opp1 quiet; opp2 quiet // transfer 2C per invito a manche con 5 cuori dopo 1H 1SA: pairhcp:22-26 opener shape:balanced hcp:12-14; responder H:5 hcp:10-11; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore (1{{fiori}});responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=Walsh: su 1♣ si risponde 1♥/1♠ con 4+ nobili e 4-11 PO (salta le quadri); con 12+ 1♦ (quinte+) poi il nobile
|cc_text_response_walsh=Walsh: su 1♣ nobile diretto con 4-11 PO anche saltando le quadri; 12+ PO 1♦ poi nobile; 1♦ poi XY (2♣ transfer a 2♦, 2♦ relé FM, 2SA transfer a 3♣)
}}

<div style="border:1px solid #c80; padding:6px;">'''Contenuto trascritto da slide (Marina Causa, Corso Preagonistica 2026): revisione da parte di un esperto consigliata.'''</div>

La '''Walsh''' è un accordo per cui, '''su apertura di 1{{fiori}}''', si '''anticipa il maggiore a discapito delle quadri''' (anche se più lunghe) '''con tutte le mani da 4 a 11 punti'''. Se invece la mano è da manche (FM) si segue la sequenza naturale: quadri (solo se quinte o più), poi il nobile.

== Schema ==
* Su 1{{fiori}}, con 4+ carte nobili e 4-11 PO: si risponde direttamente '''1{{cuori}}''' o '''1{{picche}}''', saltando le quadri, anche se le quadri sono più lunghe.
* Con mano da manche (FM, 12+): sequenza naturale, '''1{{quadri}}''' (solo se quinte o più) e poi il nobile.

=== Esempi della fonte (apertura 1{{fiori}} del compagno) ===
{| class="wikitable"
! Mano !! Risposta !! Nota
|-
| <hand>J84.A984.Q982.J7</hand> || 1{{cuori}} || 4-11 PO: nobile diretto
|-
| <hand>K74.Q984.A9862.7</hand> || 1{{cuori}} || quadri più lunghe, ma si anticipa il nobile
|-
| <hand>J4.AQ84.K982.KQ7</hand> || 1{{cuori}} || mano FM, ma le quadri sono solo quarte
|-
| <hand>K74.AQ84.AKJ82.7</hand> || 1{{quadri}} || mano FM: poi si dichiarano le cuori
|}

== Vantaggi ==
=== 1) Un nobile in pista scavalcando le quadri ===
Mette in pista un nobile scavalcando le quadri (cosa che di solito l'apertore non ha quando apre 1{{fiori}}): dal punto di vista della strategia di competizione è una scelta vincente (la fonte aggiunge: persino se il compagno non sa che si sta giocando Walsh da soli).

Esempio della fonte (Sud apre):

Sud: <hand>Q63.A1065.KQ4.Q98</hand>

Nord: <hand>52.KQ74.A10962.63</hand>

<bidding dealer="S">1C P 1H 1S 2H P P P</bidding>

Nord-Sud si sono potuti assestare velocemente su un parziale di 8 atout. Secondo la fonte, forse E/O potevano insistere a picche, forse avevano un ottimo fit a fiori; di certo, se Nord avesse risposto 1{{quadri}}, su 1{{picche}} Sud sarebbe passato e a bocce ferme per E/O sarebbe stato più facile appropriarsi del parziale.

=== 2) L'apertore bilanciato nasconde le quarte nobili ===
Se l'apertore è bilanciato di diritto e la risposta è 1{{quadri}} in prima istanza, si comporta come se il compagno non avesse quarte nobili e dichiara comunque 1SA. Con questa replica può nascondere una quarta nobile, o anche tutte e due; se resta il contratto finale, l'attaccante sarà completamente alla cieca.

Esempio della fonte: dopo 1{{fiori}} 1{{quadri}} 1SA 3SA l'attaccante ha ''mano completata'' (la slide dà picche J10xx, cuori KJxx, quadri Jx, fiori Qxx):
<hand>J1085.KJ73.J2.Q64</hand>

Sa che il morto scenderà senza quarte nobili, ma il vivo potrebbe averle entrambe, o solo una, o nessuna: non sa praticamente niente della mano del giocante.

Smazzata della fonte (Sud apre):

Sud: <hand>KJ63.AJ65.Q4.Q95</hand>

Nord: <hand>852.104.KJ62.KJ63</hand>

<bidding dealer="S">1C P 1D P 1SA P P P</bidding>

=== Nessun rischio di perdere una manche nobile ===
La fonte nota che non c'è pericolo di perdere una manche nel nobile: se il rispondente ha almeno 12 punti dichiara 1{{quadri}} all'inizio e poi prosegue dichiarando il nobile, svelando la forza oltre alla bicolore almeno 5/4.

Sud: <hand>KJ63.AJ65.Q4.Q95</hand>

Nord: <hand>Q2.K1084.KJ962.A3</hand>

<bidding dealer="S">1C P 1D P 1SA P 2H P 3H P 4H P P P</bidding>

Nord si accontenta della manche perché ha 13 e sa di fronteggiare una bilanciata di diritto; con la stessa mano e visuale di slam potrebbe, su 3{{cuori}}, iniziare a dare i controlli. Il seguito (una volta chiarito che il rispondente ha 12+ con quadri lunghe e la quarta nobile che annuncia) è tutto naturale:

Sud: <hand>K9.AJ94.Q72.Q1096</hand>

Nord: <hand>Q1043.K8.AJ953.K5</hand>

<bidding dealer="S">1C P 1D P 1SA P 2S P 2SA P 3SA P P P</bidding>

== Conseguenze sulle ridichiarazioni ==
* '''Apertore sbilanciato''': quando, sulla risposta di 1{{quadri}}, l'apertore ridichiara un colore a livello 1, mostra automaticamente una mano sbilanciata, e quindi fiori lunghi o tricolore. Esempio della fonte (''mano completata'', la slide dà AKxx, x, Axx, Qxxxx): <hand>AK63.4.A52.Q9873</hand> <bidding dealer="S">1C P 1D P 1S</bidding>
* '''2{{cuori}} del rispondente dopo 1SA''': in un sistema standard la ridichiarazione di 2{{cuori}} mostrerebbe valori nel colore e non necessariamente quattro carte; giocando Walsh il colore di cuori è garantito, per il fatto che l'apertore potrebbe avere fit nel seme. Nord si presenterà quindi con carte tipo (slide: KJx, AJxx, KQxxx, x; ''mano completata''): <hand>KJ4.AJ73.KQ982.6</hand> <bidding dealer="S">1C P 1D P 1SA P 2H</bidding>
* La sequenza 1{{fiori}} 1{{quadri}} 1SA 2{{cuori}} va considerata '''forzante di manche''' perché, adottando anche la convenzione XY, ci sarà modo di raccontare le carte di Nord quando si trova con una 4/6 invitante.

=== Nota sulle sequenze con 2{{quadri}} dell'apertore ===
La fonte avverte che giocare Walsh è abbastanza facile e rilassante, purché si faccia l'orecchio ad alcune sequenze delicate; indica due situazioni a cui prestare attenzione. Per la prima mostra la sequenza 1{{fiori}} 1{{picche}} 2{{fiori}} 2{{quadri}} ("??" sulla slide) con la mano seguente (''mano completata'', la slide dà Ax, Kx, xxx, AQxxxx): <hand>A4.K5.763.AQ9842</hand> <bidding dealer="S">1C P 1S P 2C P 2D P</bidding> La fonte dice che questa, per nessun motivo, può essere considerata una sequenza Walsh; la ridichiarazione di 2{{quadri}} è indispensabile per indagare ancora. In queste situazioni il rispondente, se ha il corto-lungo Walsh, deve rassegnarsi e passare, sperando che l'apertore abbia sei carte di fiori. (La slide descrive solo una delle due situazioni annunciate.)

== Prosecuzione "XY" dopo 1{{fiori}}-1{{quadri}}-1... ==
Giocando XY non serve più il nuovo colore forzante (non nelle sequenze a livello 1), né il check back né altro. L'idea: tutto ruota su tre possibili repliche del rispondente.
* '''2{{fiori}}''': transfer per 2{{quadri}}. Con tutte le mani che vogliono giocare un parziale a quadri oppure tutte le mani con forza di invito, che si chiarirà dopo.
* '''2{{quadri}}''': relé FM, con tutte le mani con cui il rispondente vuole interrogare.
* '''2SA''': transfer per 3{{fiori}}. Con tutte le mani che vogliono giocare un parziale a fiori oppure tutte le mani 5/5 di 15+ con almeno due onori maggiori in entrambi i colori.

Inoltre, qualcosa cambia:
* La ripetizione del nobile di risposta è da passare.
* La dichiarazione di 2{{cuori}} dopo risposta 1{{picche}} è non forzante (max 9/10).
* Tutte le dichiarazioni a livello tre, tradizionalmente invitanti e quindi passabili, usando l'XY diventano FM (perché tutti gli inviti passano dal 2{{fiori}}).

=== 2{{fiori}}, il transfer per gli inviti a manche o per le quadri ===
Con qualsiasi mano invitante il rispondente ridichiara 2{{fiori}} (e l'apertore dovrà dire 2{{quadri}}). L'apertore, con 11/16, dovrà rispettare il transfer. Dopodiché si aprono due possibilità.

==== a) Intenzione di giocare un parziale a quadri ====
Secondo la fonte è più che possibile e, giocando Walsh, è un modo intelligente di recuperare una lunga ignorata al primo giro. Chissà, forse 1SA era un buon parziale e forse no, di certo 2{{quadri}} non dovrebbe essere una brutta scelta: se sfortunati si troveranno 2 carte, altrimenti 3.

Sud: <hand>Q2.A82.J54.AJ976</hand>

Nord: <hand>KJ104.43.KQ952.103</hand>

<bidding dealer="S">1C P 1S P 1SA P 2C P 2D P P P</bidding>

Lo "stop" a 2{{quadri}} non è automatico: poiché l'apertore ha ridichiarato a colore 1 su 1, potrebbe ancora avere una mano che sfiora il rever. Nel timore che Nord si volesse fermare a un parziale a quadri (sempre possibile: se ora arrivasse il 3{{quadri}} Sud si rassegnerebbe) Sud disobbedisce, descrivendosi ancora: la pennellata a 3{{fiori}} descrive proprio queste carte, e questa forza onori. Esempio della fonte, nella forma riportata dalla slide (apertura 1{{quadri}}; ''mano completata'', la slide dà KQJ7, 4, AK854, A92):

<hand>KQJ7.4.AK854.A92</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 3C</bidding>

La disobbedienza deve presentare ottimi motivi, anche se la mano non è particolarmente forte:

<hand>K10.AQ87.4.KQJ972</hand>

<bidding dealer="S">1C P 1D P 1H P 2C P 3C</bidding>

Se Nord ha una mano invitante a manche farà le sue deduzioni: questo 3{{fiori}} dice "sono certo che questo parziale sia meglio, se era nelle tue intenzioni proporre di giocare 2{{quadri}}: io avrei detto 2{{quadri}} e tu Passo... ma ti prevengo con una sesta solidissima e un punteggio non minimo".

==== b) Invito a manche ====
Se ha intenzione di formulare un invito a manche (quindi la forza onori sarà intorno ai 10/11 punti), invece di passare il rispondente formulerà, a livello di estrema sicurezza, l'invito che intende proporre.

'''Invito con 5 carte di cuori''' ("sono invitante a manche con 5 carte di cuori"): Sud giustamente declina, né si prende il mal di pancia, con 12, di correggere a 2SA.

Sud: <hand>AK52.102.K54.Q872</hand>

Nord: <hand>94.AQJ74.A93.643</hand>

<bidding dealer="S">1C P 1H P 1S P 2C P 2D P 2H P P P</bidding>

Se le carte di Nord fossero state <hand>94.AQ9854.A54.65</hand> avrebbe detto 2{{fiori}} e poi 3{{cuori}}: invitante, ma questa volta con almeno 6 carte.

'''Invito con fit a picche''' ("sono invitante a manche con fit a picche"): Sud è minimo e passa. La fonte nota come sia straordinario riuscire a formulare a livello due un invito che, in qualunque naturale, si dovrebbe spingere a livello 3; a volte si è già sotto, nonostante il fit di 8 carte e i 22/23 punti in linea.

Sud: <hand>A1052.82.AJ54.K72</hand>

Nord: <hand>KQJ4.AJ74.93.643</hand>

<bidding dealer="S">1C P 1H P 1S P 2C P 2D P 2S P P P</bidding>

'''Invito a 3SA''' ("sono invitante a 3SA"): rialza se sei massimo. Secondo la fonte nulla di speciale: anche nel naturale classico senza fronzoli Sud avrebbe detto 1SA, Nord avrebbe invitato con 2SA e il risultato sarebbe stato comunque 3SA. Attenzione: quando invita a Senza il rispondente nega di avere 5 carte nel nobile di risposta.

Sud: <hand>K105.Q2.A109.KJ1072</hand>

Nord: <hand>QJ84.KJ74.Q83.Q3</hand>

<bidding dealer="S">1C P 1H P 1SA P 2C P 2D P 2SA P 3SA P P P</bidding>

'''Invito 5-4 (picche e cuori)''': Nord risponde normalmente 1{{picche}}, poi trasferisce con il 2{{fiori}} e mostra infine una mano "invitante con 5 picche e 4 cuori"; Sud con 14 accetta e rialza a manche.

Sud: <hand>K5.QJ92.A105.A1092</hand>

Nord: <hand>A9842.K1074.KJ.83</hand>

<bidding dealer="S">1C P 1S P 1SA P 2C P 2D P 2H P 4H P P P</bidding>

Secondo la fonte, se Nord avesse detto le cuori direttamente su 1SA avrebbe mostrato una mano limite, da 6 fino al punteggio da invito; se di cuori ne avesse dette 3, dopo essere passato dal transfer, avrebbe mostrato una 5-5 invitante. Occorre ricordarsi che il 2{{fiori}} prelude sempre a una mano non più che invitante, quindi al massimo 11.

== Picche e poi cuori ==
La fonte osserva che la sequenza di risposta "picche e poi cuori" è sempre stata delicatissima nel naturale senza convenzioni: essendo un cambio di colore forzante, chiedeva all'apertore di rialzare a 3 cuori tutte le volte che, anche con 12, preferiva il secondo colore. Questo creava al rispondente crisi di coscienza imbarazzanti (esempio della slide con apertura 1{{quadri}}: picche KJxxx, cuori AJxx, quadri xx, fiori xx, dopo 1{{quadri}} 1{{picche}} 1SA). Il fatto che, con l'XY, la replica 2{{cuori}} sia passabile è un grande sollievo.

== Varianti ==
La fonte non indica varianti della convenzione. Non esistono pagine di varianti nel wiki.

== Vedi anche ==
* [[XYZ]]
* [[Stayman]]
* [[Fiori forte]]
* [[Precision]]
* [[Landy]]

== Fonti ==
* Marina Causa, ''Corso Preagonistica 2026'', lezione 05 — La convenzione WALSH (slide).
* Nota: il contenuto è trascritto da slide; revisione da parte di un esperto consigliata. Gli esempi con "x" sulla slide sono indicati come ''mano completata'' con carte basse plausibili.

XYZ

2026-11-03T06:11:05Z

Lpala: Correzione etichetta scenario 7

{{DEFAULTSORT:XYZ}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]

{{Convenzione
|nome=XYZ
|tipologia=Sviluppo
|scopo=Dopo certe sequenze di apertura e risposta a livello 1 con ridichiarazione dell'apertore, rendere artificiali e forzanti le ridichiarazioni 2{{fiori}} e 2{{quadri}} del rispondente, così da distinguere a basso livello le mani d'invito da quelle più forti. Secondo l'articolo di Danny Kleinman l'ideazione è attribuita a Joe Kivel.
|trigger=Dieci sequenze senza interventi iniziate da una mano non passata. Quattro "a tre colori" a livello 1: 1{{fiori}}-1{{quadri}};1{{cuori}}, 1{{fiori}}-1{{quadri}};1{{picche}}, 1{{fiori}}-1{{cuori}};1{{picche}}, 1{{quadri}}-1{{cuori}};1{{picche}}. Sei con apertura, risposta e 1SA dell'apertore: 1{{fiori}}-1{{quadri}}, 1{{fiori}}-1{{cuori}}, 1{{fiori}}-1{{picche}}, 1{{quadri}}-1{{cuori}}, 1{{quadri}}-1{{picche}}, 1{{cuori}}-1{{picche}}, tutte seguite da 1SA.
|risposte=Nelle quattro sequenze a tre colori: 2{{fiori}} del rispondente = "puppet" verso 2{{quadri}}: non mostra quadri, è artificiale e forzante e l'apertore deve dire 2{{quadri}} con qualunque mano (niente super-accettazioni a 3{{quadri}} né preferenze a salto). Il rispondente può passare 2{{quadri}} con mano debole, oppure dichiarare un colore naturale al giro successivo con mano d'invito (se non è a salto è un invito, da spiegare agli avversari). 2{{quadri}} del rispondente = artificiale e forzante a manche, poi si torna al naturale. 2{{cuori}} è naturale e scoraggiante; 2{{picche}} è naturale e scoraggiante solo se è un rialzo, mentre 2{{picche}} non rialzo e le dichiarazioni più alte sono forzanti e da slam. Dopo 1SA dell'apertore (sei sequenze) 2{{fiori}} e 2{{quadri}} funzionano come il New Minor Forcing.
|note=Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata. Costi indicati dall'autore: si perde la preferenza a 2{{fiori}} dopo 1{{fiori}}-1{{cuori}};1{{picche}}, si creano molte mani orfane, e dopo 1SA si perde il semplice ritiro a 2{{fiori}} (per esempio dopo 1{{fiori}}-1{{picche}};1SA e 1{{quadri}}-1{{picche}};1SA). Il range dell'1SA di ridichiarazione non è indicato nella fonte: negli scenari si usa 12-14 PO come ipotesi di lavoro. Varianti sui check-back dopo 1SA citate dalla fonte: Second Round Stayman e Hi-Ro-Jerum. La preferenza dell'autore (non usare check-back) è una sua opinione.
|tag_cc=response_xyz
|tag_sistema=naturale
|shape_constraints=1D-1H;1S poi 2C puppet e passo dopo 2D (rispondente debole con 4 cuori e fit a quadri): pairhcp:18-26 opener D:4+ S:4 H:0-3 hcp:12-17; responder H:4+ D:3+ S:0-3 hcp:6-9; opp1 quiet; opp2 quiet // 1D-1H;1S 2C puppet poi invito a manche con colore naturale (10-11 PO): pairhcp:22-28 opener D:4+ S:4 H:0-3 hcp:12-17; responder S:4 H:5 hcp:10-11; opp1 quiet; opp2 quiet // 2D forzante a manche dopo 1C-1D;1H: pairhcp:24-32 opener C:3+ H:4 D:0-3 hcp:12-17; responder D:5+ H:3 hcp:12-15; opp1 quiet; opp2 quiet // 2H naturale scoraggiante dopo 1C-1H;1S: pairhcp:17-26 opener C:4+ S:4 H:0-2 hcp:12-17; responder H:6 S:3 hcp:5-9; opp1 quiet; opp2 quiet // 2S non rialzo forzante da slam dopo 1C-1D;1H: pairhcp:27-36 opener C:4+ H:4 hcp:12-17; responder S:5 D:6+ hcp:15-19; opp1 quiet; opp2 quiet // new minor forcing dopo 1C-1S;1SA con 2D (1SA 12-14 ipotesi): pairhcp:24-29 opener shape:balanced S:2-3 hcp:12-14; responder S:5 hcp:12-15; opp1 quiet; opp2 quiet // costo dopo 1D-1S;1SA perso il ritiro a 2C naturale (1SA 12-14 ipotesi): pairhcp:18-23 opener shape:balanced hcp:12-14; responder S:4 C:5+ hcp:6-9; opp1 quiet; opp2 quiet // quadri lunghe e 2D artificiale forzante dopo 1C-1D;1S: pairhcp:25-34 opener C:3+ S:4 hcp:12-17; responder D:6+ S:0-3 hcp:13-17; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=XYZ: dopo 1m-1x;1y (tre colori a livello 1) e dopo 1SA dell'apertore, 2♣ = puppet verso 2♦, 2♦ = artificiale forzante a manche
|cc_text_response_xyz=XYZ: 2♣ puppet verso 2♦ (debole: passo; invito: colore naturale dopo 2♦), 2♦ artificiale GF; 2♥ naturale scoraggiante
}}

<div style="border:1px solid #c80; padding:6px;">'''Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata.'''</div>

La '''XYZ''' è una convenzione di sviluppo del rispondente che, secondo l'articolo di Danny Kleinman su Bridgebum.com, è attribuita a Joe Kivel. Si applica a dieci sequenze senza interventi e rende artificiali e forzanti le ridichiarazioni a 2{{fiori}} e 2{{quadri}}.

== Dominio ==
Le sequenze interessate (avversari sempre passati, apertura da mano non passata) sono dieci.
* Quattro sequenze "a tre colori" tutte a livello 1: 1{{fiori}} 1{{quadri}} 1{{cuori}}; 1{{fiori}} 1{{quadri}} 1{{picche}}; 1{{fiori}} 1{{cuori}} 1{{picche}}; 1{{quadri}} 1{{cuori}} 1{{picche}}.
* Sei sequenze con 1SA dell'apertore: 1{{fiori}} 1{{quadri}}, 1{{fiori}} 1{{cuori}}, 1{{fiori}} 1{{picche}}, 1{{quadri}} 1{{cuori}}, 1{{quadri}} 1{{picche}}, 1{{cuori}} 1{{picche}}, in ogni caso seguite da 1SA.

== Come si gioca senza XYZ ==
Per capire che cosa si sostituisce, l'articolo descrive prima il metodo naturale. Nelle sequenze a tre colori le ridichiarazioni a Senza del rispondente sono naturali (1SA circa 6-10 PO, 2SA 11-12, 3SA 13-17); i rialzi del nobile dell'apertore e la ripetizione del proprio nobile hanno range analoghi. Il quarto colore (forzante e spesso artificiale) serve a mantenere la dichiarazione aperta con mani forti. Nel naturale i salti a livello 3 nel quarto colore sono semplicemente invitanti.

== Le ridichiarazioni del rispondente con XYZ ==
=== 2{{fiori}}: il puppet ===
Il 2{{fiori}} somiglia a un transfer, ma non mostra quadri: l'apertore deve dire 2{{quadri}} qualunque mano abbia, senza super-accettazioni a 3{{quadri}} né preferenze a salto. Il 2{{fiori}} è artificiale e forzante (da spiegare agli avversari).
* Con mano debole il rispondente passa il 2{{quadri}} obbligato.
* Con mano d'invito a manche dichiara al giro successivo un colore naturale; se la dichiarazione non è a salto è un invito (da spiegare). Rispetto al metodo standard resta un livello di dichiarazione in più per un eventuale tentativo dell'apertore.

=== 2{{quadri}}: artificiale e forzante a manche ===
Il 2{{quadri}} è artificiale e forzante a manche; dopo di esso si torna alla dichiarazione naturale. Lascia spazio all'apertore, per esempio, per dichiarare 2SA e quindi giocare i Senza dalla mano giusta.

=== 2{{cuori}} e 2{{picche}} ===
2{{cuori}} è naturale e scoraggiante, come nel metodo standard. 2{{picche}} è naturale e scoraggiante quando è un rialzo; se non è un rialzo, e per tutte le dichiarazioni più alte, la mano è forzante e da slam.

== Dopo 1SA dell'apertore ==
Nelle sei sequenze con 1SA la XYZ funziona come il New Minor Forcing: le ridichiarazioni 2{{fiori}} e 2{{quadri}} diventano artificiali. Per la descrizione dettagliata dei check-back si rimanda alla fonte.

== Vantaggi ==
Secondo la fonte la XYZ distingue a basso costo le mani d'invito a manche da quelle più forti, sia nelle sequenze a tre colori sia in quelle con 1SA dell'apertore. L'autore la definisce un po' più semplice dei metodi naturali che sostituisce.

== Costi ==
Secondo la fonte:
* si perde la preferenza a 2{{fiori}} dopo 1{{fiori}} 1{{cuori}}; 1{{picche}} (non si può dichiarare 2{{fiori}} con una mano come <hand>K6.K1098.653.Q976</hand>);
* si creano molte "mani orfane", cioè mani che avevano una dichiarazione naturale ora sottratta;
* dopo 1SA dell'apertore si perde il semplice ritiro a 2{{fiori}} dopo 1{{fiori}} 1{{picche}}; 1SA (per esempio con <hand>KQ98.J76.42.Q972</hand>) e a 2{{fiori}} dopo 1{{quadri}} 1{{picche}}; 1SA o 1{{quadri}} 1{{cuori}}; 1SA;
* si perde l'opzione di chiedere una preferenza al proprio nobile dopo 1{{fiori}} 1{{cuori}} 1SA (con una 5-5 cuori-quadri e simili);
* il danno è un po' maggiore che con il solo NMF o con un check-back a 2{{fiori}}, perché diventano orfane due dichiarazioni naturali, 2{{fiori}} e 2{{quadri}}.

== Esempi ==
=== Puppet e passo ===
Rispondente debole con fit a quadri. Sud apre di 1{{quadri}}:

Sud: <hand>AQ73.82.KJ752.A4</hand>

Nord: <hand>K6.QJ98.Q1094.986</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P P P</bidding>

Il 2{{fiori}} di Nord è un puppet (non mostra quadri), Sud dice 2{{quadri}} obbligato e Nord passa.

=== Puppet e invito a manche ===
Nord ha 10 PO e una mano d'invito: dopo il puppet dichiara il colore in modo naturale, non a salto.

Sud: <hand>KJ74.K4.AQ752.83</hand>

Nord: <hand>QJ85.A10952.93.K4</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P 2S P 4S P P P</bidding>

Con la mano massima Sud accetta l'invito a 2{{picche}} e arriva a manche.

=== 2{{quadri}} forzante a manche ===
Nord ha 13 PO e quadri quinte: il 2{{quadri}} è artificiale e forzante a manche, lascia a Sud lo spazio per 2SA.

Sud: <hand>Q65.AK82.84.K1087</hand>

Nord: <hand>A8.QJ4.QJ1042.K104</hand>

<bidding dealer="S">1C P 1D P 1H P 2D P 2NT P 3NT P P P</bidding>

=== 2{{picche}} non rialzo (forzante, da slam) ===
Nord ha un bicolore forte picche-quadri. Dopo 1{{fiori}} 1{{quadri}} 1{{cuori}} il 2{{picche}} non è un rialzo e quindi è forzante con interesse di slam.

Sud: <hand>K4.AJ73.83.KQ962</hand>

Nord: <hand>AKQ85.6.KQJ1042.7</hand>

<bidding dealer="S">1C P 1D P 1H P 2S P</bidding>

== Varianti ==
La fonte non propone varianti della XYZ in senso stretto: cita invece, come alternative ai check-back dopo 1SA dell'apertore, il '''Second Round Stayman''' (2{{fiori}} chiede prima un nobile quarto non dichiarato, poi tre carte nel nobile del rispondente; il solo orfano è un 2{{fiori}} naturale) e il ''Hi-Ro-Jerum'', che incorpora la "Spade Inversion". Non esistono pagine di varianti nel wiki.

== Opinione dell'autore ==
Kleinman osserva che la XYZ e i check-back dopo 1SA possono essere utili in alcune smazzate, ma che fanno più male che bene per via delle mani orfane che creano. Poiché preferisce rialzare liberamente le risposte di 1{{cuori}} e 1{{picche}}, dichiara di non averli mai usati. È una sua scelta personale, non una regola.

== Vedi anche ==
* [[Walsh]] — Nella lezione 05 del ''Corso Preagonistica 2026'' di Marina Causa la prosecuzione dopo la Walsh è chiamata "XY" ed è analoga nello schema (2{{fiori}} puppet verso 2{{quadri}}, 2{{quadri}} relé forzante a manche, 2SA transfer a 3{{fiori}}). Le due convenzioni hanno uno schema affine ma non sono la stessa: la XYZ è definita dall'articolo di Bridgebum sulle dieci sequenze sopra indicate.

== Fonti ==
* Danny Kleinman, "XYZ", Bridgebum.com, © Jeff Tang, https://www.bridgebum.com/xyz.php (ideazione attribuita a Joe Kivel secondo l'articolo). Sintesi e riscrittura in italiano; gli esempi sono rielaborati.

XYZ

2026-11-03T06:10:59Z

Lpala: Correzione etichetta

{{DEFAULTSORT:XYZ}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]

{{Convenzione
|nome=XYZ
|tipologia=Sviluppo
|scopo=Dopo certe sequenze di apertura e risposta a livello 1 con ridichiarazione dell'apertore, rendere artificiali e forzanti le ridichiarazioni 2{{fiori}} e 2{{quadri}} del rispondente, così da distinguere a basso livello le mani d'invito da quelle più forti. Secondo l'articolo di Danny Kleinman l'ideazione è attribuita a Joe Kivel.
|trigger=Dieci sequenze senza interventi iniziate da una mano non passata. Quattro "a tre colori" a livello 1: 1{{fiori}}-1{{quadri}};1{{cuori}}, 1{{fiori}}-1{{quadri}};1{{picche}}, 1{{fiori}}-1{{cuori}};1{{picche}}, 1{{quadri}}-1{{cuori}};1{{picche}}. Sei con apertura, risposta e 1SA dell'apertore: 1{{fiori}}-1{{quadri}}, 1{{fiori}}-1{{cuori}}, 1{{fiori}}-1{{picche}}, 1{{quadri}}-1{{cuori}}, 1{{quadri}}-1{{picche}}, 1{{cuori}}-1{{picche}}, tutte seguite da 1SA.
|risposte=Nelle quattro sequenze a tre colori: 2{{fiori}} del rispondente = "puppet" verso 2{{quadri}}: non mostra quadri, è artificiale e forzante e l'apertore deve dire 2{{quadri}} con qualunque mano (niente super-accettazioni a 3{{quadri}} né preferenze a salto). Il rispondente può passare 2{{quadri}} con mano debole, oppure dichiarare un colore naturale al giro successivo con mano d'invito (se non è a salto è un invito, da spiegare agli avversari). 2{{quadri}} del rispondente = artificiale e forzante a manche, poi si torna al naturale. 2{{cuori}} è naturale e scoraggiante; 2{{picche}} è naturale e scoraggiante solo se è un rialzo, mentre 2{{picche}} non rialzo e le dichiarazioni più alte sono forzanti e da slam. Dopo 1SA dell'apertore (sei sequenze) 2{{fiori}} e 2{{quadri}} funzionano come il New Minor Forcing.
|note=Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata. Costi indicati dall'autore: si perde la preferenza a 2{{fiori}} dopo 1{{fiori}}-1{{cuori}};1{{picche}}, si creano molte mani orfane, e dopo 1SA si perde il semplice ritiro a 2{{fiori}} (per esempio dopo 1{{fiori}}-1{{picche}};1SA e 1{{quadri}}-1{{picche}};1SA). Il range dell'1SA di ridichiarazione non è indicato nella fonte: negli scenari si usa 12-14 PO come ipotesi di lavoro. Varianti sui check-back dopo 1SA citate dalla fonte: Second Round Stayman e Hi-Ro-Jerum. La preferenza dell'autore (non usare check-back) è una sua opinione.
|tag_cc=response_xyz
|tag_sistema=naturale
|shape_constraints=1D-1H;1S poi 2C puppet e passo dopo 2D (rispondente debole con 4 cuori e fit a quadri): pairhcp:18-26 opener D:4+ S:4 H:0-3 hcp:12-17; responder H:4+ D:3+ S:0-3 hcp:6-9; opp1 quiet; opp2 quiet // 1D-1H;1S 2C puppet poi invito a manche con colore naturale (10-11 PO): pairhcp:22-28 opener D:4+ S:4 H:0-3 hcp:12-17; responder S:4 H:5 hcp:10-11; opp1 quiet; opp2 quiet // 2D forzante a manche dopo 1C-1D;1H: pairhcp:24-32 opener C:3+ H:4 D:0-3 hcp:12-17; responder D:5+ H:3 hcp:12-15; opp1 quiet; opp2 quiet // 2H naturale scoraggiante dopo 1C-1H;1S: pairhcp:17-26 opener C:4+ S:4 H:0-2 hcp:12-17; responder H:6 S:3 hcp:5-9; opp1 quiet; opp2 quiet // 2S non rialzo forzante da slam dopo 1C-1D;1H: pairhcp:27-36 opener C:4+ H:4 hcp:12-17; responder S:5 D:6+ hcp:15-19; opp1 quiet; opp2 quiet // new minor forcing dopo 1C-1S;1SA con 2D (1SA 12-14 ipotesi): pairhcp:24-29 opener shape:balanced S:2-3 hcp:12-14; responder S:5 hcp:12-15; opp1 quiet; opp2 quiet // costo: dopo 1D-1S;1SA perso il ritiro a 2C naturale, 2C artificiale (1SA 12-14 ipotesi): pairhcp:18-23 opener shape:balanced hcp:12-14; responder S:4 C:5+ hcp:6-9; opp1 quiet; opp2 quiet // quadri lunghe e 2D artificiale forzante dopo 1C-1D;1S: pairhcp:25-34 opener C:3+ S:4 hcp:12-17; responder D:6+ S:0-3 hcp:13-17; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=XYZ: dopo 1m-1x;1y (tre colori a livello 1) e dopo 1SA dell'apertore, 2♣ = puppet verso 2♦, 2♦ = artificiale forzante a manche
|cc_text_response_xyz=XYZ: 2♣ puppet verso 2♦ (debole: passo; invito: colore naturale dopo 2♦), 2♦ artificiale GF; 2♥ naturale scoraggiante
}}

<div style="border:1px solid #c80; padding:6px;">'''Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata.'''</div>

La '''XYZ''' è una convenzione di sviluppo del rispondente che, secondo l'articolo di Danny Kleinman su Bridgebum.com, è attribuita a Joe Kivel. Si applica a dieci sequenze senza interventi e rende artificiali e forzanti le ridichiarazioni a 2{{fiori}} e 2{{quadri}}.

== Dominio ==
Le sequenze interessate (avversari sempre passati, apertura da mano non passata) sono dieci.
* Quattro sequenze "a tre colori" tutte a livello 1: 1{{fiori}} 1{{quadri}} 1{{cuori}}; 1{{fiori}} 1{{quadri}} 1{{picche}}; 1{{fiori}} 1{{cuori}} 1{{picche}}; 1{{quadri}} 1{{cuori}} 1{{picche}}.
* Sei sequenze con 1SA dell'apertore: 1{{fiori}} 1{{quadri}}, 1{{fiori}} 1{{cuori}}, 1{{fiori}} 1{{picche}}, 1{{quadri}} 1{{cuori}}, 1{{quadri}} 1{{picche}}, 1{{cuori}} 1{{picche}}, in ogni caso seguite da 1SA.

== Come si gioca senza XYZ ==
Per capire che cosa si sostituisce, l'articolo descrive prima il metodo naturale. Nelle sequenze a tre colori le ridichiarazioni a Senza del rispondente sono naturali (1SA circa 6-10 PO, 2SA 11-12, 3SA 13-17); i rialzi del nobile dell'apertore e la ripetizione del proprio nobile hanno range analoghi. Il quarto colore (forzante e spesso artificiale) serve a mantenere la dichiarazione aperta con mani forti. Nel naturale i salti a livello 3 nel quarto colore sono semplicemente invitanti.

== Le ridichiarazioni del rispondente con XYZ ==
=== 2{{fiori}}: il puppet ===
Il 2{{fiori}} somiglia a un transfer, ma non mostra quadri: l'apertore deve dire 2{{quadri}} qualunque mano abbia, senza super-accettazioni a 3{{quadri}} né preferenze a salto. Il 2{{fiori}} è artificiale e forzante (da spiegare agli avversari).
* Con mano debole il rispondente passa il 2{{quadri}} obbligato.
* Con mano d'invito a manche dichiara al giro successivo un colore naturale; se la dichiarazione non è a salto è un invito (da spiegare). Rispetto al metodo standard resta un livello di dichiarazione in più per un eventuale tentativo dell'apertore.

=== 2{{quadri}}: artificiale e forzante a manche ===
Il 2{{quadri}} è artificiale e forzante a manche; dopo di esso si torna alla dichiarazione naturale. Lascia spazio all'apertore, per esempio, per dichiarare 2SA e quindi giocare i Senza dalla mano giusta.

=== 2{{cuori}} e 2{{picche}} ===
2{{cuori}} è naturale e scoraggiante, come nel metodo standard. 2{{picche}} è naturale e scoraggiante quando è un rialzo; se non è un rialzo, e per tutte le dichiarazioni più alte, la mano è forzante e da slam.

== Dopo 1SA dell'apertore ==
Nelle sei sequenze con 1SA la XYZ funziona come il New Minor Forcing: le ridichiarazioni 2{{fiori}} e 2{{quadri}} diventano artificiali. Per la descrizione dettagliata dei check-back si rimanda alla fonte.

== Vantaggi ==
Secondo la fonte la XYZ distingue a basso costo le mani d'invito a manche da quelle più forti, sia nelle sequenze a tre colori sia in quelle con 1SA dell'apertore. L'autore la definisce un po' più semplice dei metodi naturali che sostituisce.

== Costi ==
Secondo la fonte:
* si perde la preferenza a 2{{fiori}} dopo 1{{fiori}} 1{{cuori}}; 1{{picche}} (non si può dichiarare 2{{fiori}} con una mano come <hand>K6.K1098.653.Q976</hand>);
* si creano molte "mani orfane", cioè mani che avevano una dichiarazione naturale ora sottratta;
* dopo 1SA dell'apertore si perde il semplice ritiro a 2{{fiori}} dopo 1{{fiori}} 1{{picche}}; 1SA (per esempio con <hand>KQ98.J76.42.Q972</hand>) e a 2{{fiori}} dopo 1{{quadri}} 1{{picche}}; 1SA o 1{{quadri}} 1{{cuori}}; 1SA;
* si perde l'opzione di chiedere una preferenza al proprio nobile dopo 1{{fiori}} 1{{cuori}} 1SA (con una 5-5 cuori-quadri e simili);
* il danno è un po' maggiore che con il solo NMF o con un check-back a 2{{fiori}}, perché diventano orfane due dichiarazioni naturali, 2{{fiori}} e 2{{quadri}}.

== Esempi ==
=== Puppet e passo ===
Rispondente debole con fit a quadri. Sud apre di 1{{quadri}}:

Sud: <hand>AQ73.82.KJ752.A4</hand>

Nord: <hand>K6.QJ98.Q1094.986</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P P P</bidding>

Il 2{{fiori}} di Nord è un puppet (non mostra quadri), Sud dice 2{{quadri}} obbligato e Nord passa.

=== Puppet e invito a manche ===
Nord ha 10 PO e una mano d'invito: dopo il puppet dichiara il colore in modo naturale, non a salto.

Sud: <hand>KJ74.K4.AQ752.83</hand>

Nord: <hand>QJ85.A10952.93.K4</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P 2S P 4S P P P</bidding>

Con la mano massima Sud accetta l'invito a 2{{picche}} e arriva a manche.

=== 2{{quadri}} forzante a manche ===
Nord ha 13 PO e quadri quinte: il 2{{quadri}} è artificiale e forzante a manche, lascia a Sud lo spazio per 2SA.

Sud: <hand>Q65.AK82.84.K1087</hand>

Nord: <hand>A8.QJ4.QJ1042.K104</hand>

<bidding dealer="S">1C P 1D P 1H P 2D P 2NT P 3NT P P P</bidding>

=== 2{{picche}} non rialzo (forzante, da slam) ===
Nord ha un bicolore forte picche-quadri. Dopo 1{{fiori}} 1{{quadri}} 1{{cuori}} il 2{{picche}} non è un rialzo e quindi è forzante con interesse di slam.

Sud: <hand>K4.AJ73.83.KQ962</hand>

Nord: <hand>AKQ85.6.KQJ1042.7</hand>

<bidding dealer="S">1C P 1D P 1H P 2S P</bidding>

== Varianti ==
La fonte non propone varianti della XYZ in senso stretto: cita invece, come alternative ai check-back dopo 1SA dell'apertore, il '''Second Round Stayman''' (2{{fiori}} chiede prima un nobile quarto non dichiarato, poi tre carte nel nobile del rispondente; il solo orfano è un 2{{fiori}} naturale) e il ''Hi-Ro-Jerum'', che incorpora la "Spade Inversion". Non esistono pagine di varianti nel wiki.

== Opinione dell'autore ==
Kleinman osserva che la XYZ e i check-back dopo 1SA possono essere utili in alcune smazzate, ma che fanno più male che bene per via delle mani orfane che creano. Poiché preferisce rialzare liberamente le risposte di 1{{cuori}} e 1{{picche}}, dichiara di non averli mai usati. È una sua scelta personale, non una regola.

== Vedi anche ==
* [[Walsh]] — Nella lezione 05 del ''Corso Preagonistica 2026'' di Marina Causa la prosecuzione dopo la Walsh è chiamata "XY" ed è analoga nello schema (2{{fiori}} puppet verso 2{{quadri}}, 2{{quadri}} relé forzante a manche, 2SA transfer a 3{{fiori}}). Le due convenzioni hanno uno schema affine ma non sono la stessa: la XYZ è definita dall'articolo di Bridgebum sulle dieci sequenze sopra indicate.

== Fonti ==
* Danny Kleinman, "XYZ", Bridgebum.com, © Jeff Tang, https://www.bridgebum.com/xyz.php (ideazione attribuita a Joe Kivel secondo l'articolo). Sintesi e riscrittura in italiano; gli esempi sono rielaborati.

XYZ

2026-11-03T06:10:51Z

Lpala: Correzioni etichette scenari e testo

{{DEFAULTSORT:XYZ}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]

{{Convenzione
|nome=XYZ
|tipologia=Sviluppo
|scopo=Dopo certe sequenze di apertura e risposta a livello 1 con ridichiarazione dell'apertore, rendere artificiali e forzanti le ridichiarazioni 2{{fiori}} e 2{{quadri}} del rispondente, così da distinguere a basso livello le mani d'invito da quelle più forti. Secondo l'articolo di Danny Kleinman l'ideazione è attribuita a Joe Kivel.
|trigger=Dieci sequenze senza interventi iniziate da una mano non passata. Quattro "a tre colori" a livello 1: 1{{fiori}}-1{{quadri}};1{{cuori}}, 1{{fiori}}-1{{quadri}};1{{picche}}, 1{{fiori}}-1{{cuori}};1{{picche}}, 1{{quadri}}-1{{cuori}};1{{picche}}. Sei con apertura, risposta e 1SA dell'apertore: 1{{fiori}}-1{{quadri}}, 1{{fiori}}-1{{cuori}}, 1{{fiori}}-1{{picche}}, 1{{quadri}}-1{{cuori}}, 1{{quadri}}-1{{picche}}, 1{{cuori}}-1{{picche}}, tutte seguite da 1SA.
|risposte=Nelle quattro sequenze a tre colori: 2{{fiori}} del rispondente = "puppet" verso 2{{quadri}}: non mostra quadri, è artificiale e forzante e l'apertore deve dire 2{{quadri}} con qualunque mano (niente super-accettazioni a 3{{quadri}} né preferenze a salto). Il rispondente può passare 2{{quadri}} con mano debole, oppure dichiarare un colore naturale al giro successivo con mano d'invito (se non è a salto è un invito, da spiegare agli avversari). 2{{quadri}} del rispondente = artificiale e forzante a manche, poi si torna al naturale. 2{{cuori}} è naturale e scoraggiante; 2{{picche}} è naturale e scoraggiante solo se è un rialzo, mentre 2{{picche}} non rialzo e le dichiarazioni più alte sono forzanti e da slam. Dopo 1SA dell'apertore (sei sequenze) 2{{fiori}} e 2{{quadri}} funzionano come il New Minor Forcing.
|note=Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata. Costi indicati dall'autore: si perde la preferenza a 2{{fiori}} dopo 1{{fiori}}-1{{cuori}};1{{picche}}, si creano molte mani orfane, e dopo 1SA si perde il semplice ritiro a 2{{fiori}} (per esempio dopo 1{{fiori}}-1{{picche}};1SA e 1{{quadri}}-1{{picche}};1SA). Il range dell'1SA di ridichiarazione non è indicato nella fonte: negli scenari si usa 12-14 PO come ipotesi di lavoro. Varianti sui check-back dopo 1SA citate dalla fonte: Second Round Stayman e Hi-Ro-Jerum. La preferenza dell'autore (non usare check-back) è una sua opinione.
|tag_cc=response_xyz
|tag_sistema=naturale
|shape_constraints=1D-1H;1S poi 2C puppet e passo dopo 2Q (rispondente debole con 4 cuori e fit a quadri): pairhcp:18-26 opener D:4+ S:4 H:0-3 hcp:12-17; responder H:4+ D:3+ S:0-3 hcp:6-9; opp1 quiet; opp2 quiet // 1D-1H;1S 2C puppet poi invito a manche con colore naturale (10-11 PO): pairhcp:22-28 opener D:4+ S:4 H:0-3 hcp:12-17; responder S:4 H:5 hcp:10-11; opp1 quiet; opp2 quiet // 2D forzante a manche dopo 1C-1D;1H: pairhcp:24-32 opener C:3+ H:4 D:0-3 hcp:12-17; responder D:5+ H:3 hcp:12-15; opp1 quiet; opp2 quiet // 2H naturale scoraggiante dopo 1C-1H;1S: pairhcp:17-26 opener C:4+ S:4 H:0-2 hcp:12-17; responder H:6 S:3 hcp:5-9; opp1 quiet; opp2 quiet // 2S non rialzo forzante da slam dopo 1C-1D;1H: pairhcp:27-36 opener C:4+ H:4 hcp:12-17; responder S:5 D:6+ hcp:15-19; opp1 quiet; opp2 quiet // new minor forcing dopo 1C-1S;1SA con 2D (1SA 12-14 ipotesi): pairhcp:24-29 opener shape:balanced S:2-3 hcp:12-14; responder S:5 hcp:12-15; opp1 quiet; opp2 quiet // costo: dopo 1D-1S;1SA perso il ritiro a 2C naturale, 2C artificiale (1SA 12-14 ipotesi): pairhcp:18-23 opener shape:balanced hcp:12-14; responder S:4 C:5+ hcp:6-9; opp1 quiet; opp2 quiet // quadri lunghe e 2D artificiale forzante dopo 1C-1D;1S: pairhcp:25-34 opener C:3+ S:4 hcp:12-17; responder D:6+ S:0-3 hcp:13-17; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=XYZ: dopo 1m-1x;1y (tre colori a livello 1) e dopo 1SA dell'apertore, 2♣ = puppet verso 2♦, 2♦ = artificiale forzante a manche
|cc_text_response_xyz=XYZ: 2♣ puppet verso 2♦ (debole: passo; invito: colore naturale dopo 2♦), 2♦ artificiale GF; 2♥ naturale scoraggiante
}}

<div style="border:1px solid #c80; padding:6px;">'''Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata.'''</div>

La '''XYZ''' è una convenzione di sviluppo del rispondente che, secondo l'articolo di Danny Kleinman su Bridgebum.com, è attribuita a Joe Kivel. Si applica a dieci sequenze senza interventi e rende artificiali e forzanti le ridichiarazioni a 2{{fiori}} e 2{{quadri}}.

== Dominio ==
Le sequenze interessate (avversari sempre passati, apertura da mano non passata) sono dieci.
* Quattro sequenze "a tre colori" tutte a livello 1: 1{{fiori}} 1{{quadri}} 1{{cuori}}; 1{{fiori}} 1{{quadri}} 1{{picche}}; 1{{fiori}} 1{{cuori}} 1{{picche}}; 1{{quadri}} 1{{cuori}} 1{{picche}}.
* Sei sequenze con 1SA dell'apertore: 1{{fiori}} 1{{quadri}}, 1{{fiori}} 1{{cuori}}, 1{{fiori}} 1{{picche}}, 1{{quadri}} 1{{cuori}}, 1{{quadri}} 1{{picche}}, 1{{cuori}} 1{{picche}}, in ogni caso seguite da 1SA.

== Come si gioca senza XYZ ==
Per capire che cosa si sostituisce, l'articolo descrive prima il metodo naturale. Nelle sequenze a tre colori le ridichiarazioni a Senza del rispondente sono naturali (1SA circa 6-10 PO, 2SA 11-12, 3SA 13-17); i rialzi del nobile dell'apertore e la ripetizione del proprio nobile hanno range analoghi. Il quarto colore (forzante e spesso artificiale) serve a mantenere la dichiarazione aperta con mani forti. Nel naturale i salti a livello 3 nel quarto colore sono semplicemente invitanti.

== Le ridichiarazioni del rispondente con XYZ ==
=== 2{{fiori}}: il puppet ===
Il 2{{fiori}} somiglia a un transfer, ma non mostra quadri: l'apertore deve dire 2{{quadri}} qualunque mano abbia, senza super-accettazioni a 3{{quadri}} né preferenze a salto. Il 2{{fiori}} è artificiale e forzante (da spiegare agli avversari).
* Con mano debole il rispondente passa il 2{{quadri}} obbligato.
* Con mano d'invito a manche dichiara al giro successivo un colore naturale; se la dichiarazione non è a salto è un invito (da spiegare). Rispetto al metodo standard resta un livello di dichiarazione in più per un eventuale tentativo dell'apertore.

=== 2{{quadri}}: artificiale e forzante a manche ===
Il 2{{quadri}} è artificiale e forzante a manche; dopo di esso si torna alla dichiarazione naturale. Lascia spazio all'apertore, per esempio, per dichiarare 2SA e quindi giocare i Senza dalla mano giusta.

=== 2{{cuori}} e 2{{picche}} ===
2{{cuori}} è naturale e scoraggiante, come nel metodo standard. 2{{picche}} è naturale e scoraggiante quando è un rialzo; se non è un rialzo, e per tutte le dichiarazioni più alte, la mano è forzante e da slam.

== Dopo 1SA dell'apertore ==
Nelle sei sequenze con 1SA la XYZ funziona come il New Minor Forcing: le ridichiarazioni 2{{fiori}} e 2{{quadri}} diventano artificiali. Per la descrizione dettagliata dei check-back si rimanda alla fonte.

== Vantaggi ==
Secondo la fonte la XYZ distingue a basso costo le mani d'invito a manche da quelle più forti, sia nelle sequenze a tre colori sia in quelle con 1SA dell'apertore. L'autore la definisce un po' più semplice dei metodi naturali che sostituisce.

== Costi ==
Secondo la fonte:
* si perde la preferenza a 2{{fiori}} dopo 1{{fiori}} 1{{cuori}}; 1{{picche}} (non si può dichiarare 2{{fiori}} con una mano come <hand>K6.K1098.653.Q976</hand>);
* si creano molte "mani orfane", cioè mani che avevano una dichiarazione naturale ora sottratta;
* dopo 1SA dell'apertore si perde il semplice ritiro a 2{{fiori}} dopo 1{{fiori}} 1{{picche}}; 1SA (per esempio con <hand>KQ98.J76.42.Q972</hand>) e a 2{{fiori}} dopo 1{{quadri}} 1{{picche}}; 1SA o 1{{quadri}} 1{{cuori}}; 1SA;
* si perde l'opzione di chiedere una preferenza al proprio nobile dopo 1{{fiori}} 1{{cuori}} 1SA (con una 5-5 cuori-quadri e simili);
* il danno è un po' maggiore che con il solo NMF o con un check-back a 2{{fiori}}, perché diventano orfane due dichiarazioni naturali, 2{{fiori}} e 2{{quadri}}.

== Esempi ==
=== Puppet e passo ===
Rispondente debole con fit a quadri. Sud apre di 1{{quadri}}:

Sud: <hand>AQ73.82.KJ752.A4</hand>

Nord: <hand>K6.QJ98.Q1094.986</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P P P</bidding>

Il 2{{fiori}} di Nord è un puppet (non mostra quadri), Sud dice 2{{quadri}} obbligato e Nord passa.

=== Puppet e invito a manche ===
Nord ha 10 PO e una mano d'invito: dopo il puppet dichiara il colore in modo naturale, non a salto.

Sud: <hand>KJ74.K4.AQ752.83</hand>

Nord: <hand>QJ85.A10952.93.K4</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P 2S P 4S P P P</bidding>

Con la mano massima Sud accetta l'invito a 2{{picche}} e arriva a manche.

=== 2{{quadri}} forzante a manche ===
Nord ha 13 PO e quadri quinte: il 2{{quadri}} è artificiale e forzante a manche, lascia a Sud lo spazio per 2SA.

Sud: <hand>Q65.AK82.84.K1087</hand>

Nord: <hand>A8.QJ4.QJ1042.K104</hand>

<bidding dealer="S">1C P 1D P 1H P 2D P 2NT P 3NT P P P</bidding>

=== 2{{picche}} non rialzo (forzante, da slam) ===
Nord ha un bicolore forte picche-quadri. Dopo 1{{fiori}} 1{{quadri}} 1{{cuori}} il 2{{picche}} non è un rialzo e quindi è forzante con interesse di slam.

Sud: <hand>K4.AJ73.83.KQ962</hand>

Nord: <hand>AKQ85.6.KQJ1042.7</hand>

<bidding dealer="S">1C P 1D P 1H P 2S P</bidding>

== Varianti ==
La fonte non propone varianti della XYZ in senso stretto: cita invece, come alternative ai check-back dopo 1SA dell'apertore, il '''Second Round Stayman''' (2{{fiori}} chiede prima un nobile quarto non dichiarato, poi tre carte nel nobile del rispondente; il solo orfano è un 2{{fiori}} naturale) e il ''Hi-Ro-Jerum'', che incorpora la "Spade Inversion". Non esistono pagine di varianti nel wiki.

== Opinione dell'autore ==
Kleinman osserva che la XYZ e i check-back dopo 1SA possono essere utili in alcune smazzate, ma che fanno più male che bene per via delle mani orfane che creano. Poiché preferisce rialzare liberamente le risposte di 1{{cuori}} e 1{{picche}}, dichiara di non averli mai usati. È una sua scelta personale, non una regola.

== Vedi anche ==
* [[Walsh]] — Nella lezione 05 del ''Corso Preagonistica 2026'' di Marina Causa la prosecuzione dopo la Walsh è chiamata "XY" ed è analoga nello schema (2{{fiori}} puppet verso 2{{quadri}}, 2{{quadri}} relé forzante a manche, 2SA transfer a 3{{fiori}}). Le due convenzioni hanno uno schema affine ma non sono la stessa: la XYZ è definita dall'articolo di Bridgebum sulle dieci sequenze sopra indicate.

== Fonti ==
* Danny Kleinman, "XYZ", Bridgebum.com, © Jeff Tang, https://www.bridgebum.com/xyz.php (ideazione attribuita a Joe Kivel secondo l'articolo). Sintesi e riscrittura in italiano; gli esempi sono rielaborati.

XYZ

2026-11-03T06:10:38Z

Lpala: Nuova pagina XYZ (sintesi da Bridgebum, Kleinman)

{{DEFAULTSORT:XYZ}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]

{{Convenzione
|nome=XYZ
|tipologia=Sviluppo
|scopo=Dopo certe sequenze di apertura e risposta a livello 1 con ridichiarazione dell'apertore, rendere artificiali e forzanti le ridichiarazioni 2{{fiori}} e 2{{quadri}} del rispondente, così da distinguere a basso livello le mani d'invito da quelle più forti. Secondo l'articolo di Danny Kleinman l'ideazione è attribuita a Joe Kivel.
|trigger=Dieci sequenze senza interventi iniziate da una mano non passata. Quattro "a tre colori" a livello 1: 1{{fiori}}-1{{quadri}};1{{cuori}}, 1{{fiori}}-1{{quadri}};1{{picche}}, 1{{fiori}}-1{{cuori}};1{{picche}}, 1{{quadri}}-1{{cuori}};1{{picche}}. Sei con apertura, risposta e 1SA dell'apertore: 1{{fiori}}-1{{quadri}}, 1{{fiori}}-1{{cuori}}, 1{{fiori}}-1{{picche}}, 1{{quadri}}-1{{cuori}}, 1{{quadri}}-1{{picche}}, 1{{cuori}}-1{{picche}}, tutte seguite da 1SA.
|risposte=Nelle quattro sequenze a tre colori: 2{{fiori}} del rispondente = "puppet" verso 2{{quadri}}: non mostra quadri, è artificiale e forzante e l'apertore deve dire 2{{quadri}} con qualunque mano (niente super-accettazioni a 3{{quadri}} né preferenze a salto). Il rispondente può passare 2{{quadri}} con mano debole, oppure dichiarare un colore naturale al giro successivo con mano d'invito (se non è a salto è un invito, da spiegare agli avversari). 2{{quadri}} del rispondente = artificiale e forzante a manche, poi si torna al naturale. 2{{cuori}} è naturale e scoraggiante; 2{{picche}} è naturale e scoraggiante solo se è un rialzo, mentre 2{{picche}} non rialzo e le dichiarazioni più alte sono forzanti e da slam. Dopo 1SA dell'apertore (sei sequenze) 2{{fiori}} e 2{{quadri}} funzionano come il New Minor Forcing.
|note=Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata. Costi indicati dall'autore: si perde la preferenza a 2{{fiori}} dopo 1{{fiori}}-1{{cuori}};1{{picche}}, si creano molte mani orfane, e dopo 1SA si perde il semplice ritiro a 2{{fiori}} (per esempio dopo 1{{fiori}}-1{{picche}};1SA e 1{{quadri}}-1{{picche}};1SA). Il range dell'1SA di ridichiarazione non è indicato nella fonte: negli scenari si usa 12-14 PO come ipotesi di lavoro. Varianti sui check-back dopo 1SA citate dalla fonte: Second Round Stayman e Hi-Ro-Jerum. La preferenza dell'autore (non usare check-back) è una sua opinione.
|tag_cc=response_xyz
|tag_sistema=naturale
|shape_constraints=1 1Q-1C;1P poi 2F puppet e passo dopo 2Q (rispondente debole con 4 cuori e fit a quadri): pairhcp:18-26 opener D:4+ S:4 H:0-3 hcp:12-17; responder H:4+ D:3+ S:0-3 hcp:6-9; opp1 quiet; opp2 quiet // 2 2F puppet poi invito a manche con colore naturale dopo 1Q-1C;1P: pairhcp:22-28 opener D:4+ S:4 H:0-3 hcp:12-17; responder S:4 H:5 hcp:10-11; opp1 quiet; opp2 quiet // 3 2Q forzante a manche dopo 1F-1Q;1C: pairhcp:24-32 opener C:3+ H:4 D:0-3 hcp:12-17; responder D:5+ H:3 hcp:12-15; opp1 quiet; opp2 quiet // 4 2C naturale scoraggiante dopo 1F-1C;1P: pairhcp:17-26 opener C:4+ S:4 H:0-2 hcp:12-17; responder H:6 S:3 hcp:5-9; opp1 quiet; opp2 quiet // 5 2P non rialzo forzante da slam dopo 1F-1Q;1C: pairhcp:27-36 opener C:4+ H:4 hcp:12-17; responder S:5 D:6+ hcp:15-19; opp1 quiet; opp2 quiet // 6 new minor forcing dopo 1F-1P;1SA con 2Q (1SA 12-14 ipotesi): pairhcp:24-29 opener shape:balanced S:2-3 hcp:12-14; responder S:5 hcp:12-15; opp1 quiet; opp2 quiet // 7 costo dopo 1Q-1P;1SA, perso il ritiro a 2F naturale (1SA 12-14 ipotesi): pairhcp:18-23 opener shape:balanced hcp:12-14; responder S:4 C:5+ hcp:6-9; opp1 quiet; opp2 quiet // 8 quadri lunghe e 2Q artificiale forzante dopo 1F-1Q;1P: pairhcp:25-34 opener C:3+ S:4 hcp:12-17; responder D:6+ S:0-3 hcp:13-17; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=XYZ: dopo 1m-1x;1y (tre colori a livello 1) e dopo 1SA dell'apertore, 2♣ = puppet verso 2♦, 2♦ = artificiale forzante a manche
|cc_text_response_xyz=XYZ: 2♣ puppet verso 2♦ (debole: passo; invito: colore naturale dopo 2♦), 2♦ artificiale GF; 2♥ naturale scoraggiante
}}

<div style="border:1px solid #c80; padding:6px;">'''Sintesi in italiano da fonte web (Bridgebum, Danny Kleinman): revisione da parte di un esperto consigliata.'''</div>

La '''XYZ''' è una convenzione di sviluppo del rispondente che, secondo l'articolo di Danny Kleinman su Bridgebum.com, è attribuita a Joe Kivel. Si applica a dieci sequenze senza interventi e rende artificiali e forzanti le ridichiarazioni a 2{{fiori}} e 2{{quadri}}.

== Dominio ==
Le sequenze interessate (avversari sempre passati, apertura da mano non passata) sono dieci.
* Quattro sequenze "a tre colori" tutte a livello 1: 1{{fiori}} 1{{quadri}} 1{{cuori}}; 1{{fiori}} 1{{quadri}} 1{{picche}}; 1{{fiori}} 1{{cuori}} 1{{picche}}; 1{{quadri}} 1{{cuori}} 1{{picche}}.
* Sei sequenze con 1SA dell'apertore: 1{{fiori}} 1{{quadri}}, 1{{fiori}} 1{{cuori}}, 1{{fiori}} 1{{picche}}, 1{{quadri}} 1{{cuori}}, 1{{quadri}} 1{{picche}}, 1{{cuori}} 1{{picche}}, in ogni caso seguite da 1SA.

== Come si gioca senza XYZ ==
Per capire che cosa si sostituisce, l'articolo descrive prima il metodo naturale. Nelle sequenze a tre colori le ridichiarazioni a Senza del rispondente sono naturali (1SA circa 6-10 PO, 2SA 11-12, 3SA 13-17); i rialzi del nobile dell'apertore e la ripetizione del proprio nobile hanno range analoghi. Il quarto colore (forzante e spesso artificiale) serve a mantenere la dichiarazione aperta con mani forti. Nel naturale i salti a livello 3 nel quarto colore sono semplicemente invitanti.

== Le ridichiarazioni del rispondente con XYZ ==
=== 2{{fiori}}: il puppet ===
Il 2{{fiori}} somiglia a un transfer, ma non mostra quadri: l'apertore deve dire 2{{quadri}} qualunque mano abbia, senza super-accettazioni a 3{{quadri}} né preferenze a salto. Il 2{{fiori}} è artificiale e forzante (da spiegare agli avversari).
* Con mano debole il rispondente passa il 2{{quadri}} obbligato.
* Con mano d'invito a manche dichiara al giro successivo un colore naturale; se la dichiarazione non è a salto è un invito (da spiegare). Rispetto al metodo standard resta un livello di dichiarazione in più per un eventuale tentativo dell'apertore.

=== 2{{quadri}}: artificiale e forzante a manche ===
Il 2{{quadri}} è artificiale e forzante a manche; dopo di esso si torna alla dichiarazione naturale. Lascia spazio all'apertore, per esempio, per dichiarare 2SA e quindi giocare i Senza dalla mano giusta.

=== 2{{cuori}} e 2{{picche}} ===
2{{cuori}} è naturale e scoraggiante, come nel metodo standard. 2{{picche}} è naturale e scoraggiante quando è un rialzo; se non è un rialzo, e per tutte le dichiarazioni più alte, la mano è forzante e da slam.

== Dopo 1SA dell'apertore ==
Nelle sei sequenze con 1SA la XYZ funziona come il New Minor Forcing: le ridichiarazioni 2{{fiori}} e 2{{quadri}} diventano artificiali. Per la descrizione dettagliata dei check-back si rimanda alla fonte.

== Vantaggi ==
Secondo la fonte la XYZ distingue a basso costo le mani d'invito a manche da quelle più forti, sia nelle sequenze a tre colori sia in quelle con 1SA dell'apertore. L'autore la definisce un po' più semplice dei metodi naturali che sostituisce.

== Costi ==
Secondo la fonte:
* si perde la preferenza a 2{{fiori}} dopo 1{{fiori}} 1{{cuori}}; 1{{picche}} (non si può dichiarare 2{{fiori}} con una mano come <hand>K6.K1098.653.Q976</hand>);
* si creano molte "mani orfane", cioè mani che avevano una dichiarazione naturale ora sottratta;
* dopo 1SA dell'apertore si perde il semplice ritiro a 2{{fiori}} dopo 1{{fiori}} 1{{picche}}; 1SA (per esempio con <hand>KQ98.J76.42.Q972</hand>) e a 2{{fiori}} dopo 1{{quadri}} 1{{picche}}; 1SA o 1{{quadri}} 1{{cuori}}; 1SA;
* si perde l'opzione di chiedere una preferenza al proprio nobile dopo 1{{fiori}} 1{{cuori}} 1SA (con 5-5 nei nobili e simili);
* il danno è un po' maggiore che con il solo NMF o con un check-back a 2{{fiori}}, perché diventano orfane due dichiarazioni naturali, 2{{fiori}} e 2{{quadri}}.

== Esempi ==
=== Puppet e passo ===
Rispondente debole con fit a quadri. Sud apre di 1{{quadri}}:

Sud: <hand>AQ73.82.KJ752.A4</hand>

Nord: <hand>K6.QJ98.Q1094.986</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P P P</bidding>

Il 2{{fiori}} di Nord è un puppet (non mostra quadri), Sud dice 2{{quadri}} obbligato e Nord passa.

=== Puppet e invito a manche ===
Nord ha 10 PO e una mano d'invito: dopo il puppet dichiara il colore in modo naturale, non a salto.

Sud: <hand>KJ74.K4.AQ752.83</hand>

Nord: <hand>QJ85.A10952.93.K4</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 2D P 2S P 4S P P P</bidding>

Con la mano massima Sud accetta l'invito a 2{{picche}} e arriva a manche.

=== 2{{quadri}} forzante a manche ===
Nord ha 13 PO e quadri quinte: il 2{{quadri}} è artificiale e forzante a manche, lascia a Sud lo spazio per 2SA.

Sud: <hand>Q65.AK82.84.K1087</hand>

Nord: <hand>A8.QJ4.QJ1042.K104</hand>

<bidding dealer="S">1C P 1D P 1H P 2D P 2NT P 3NT P P P</bidding>

=== 2{{picche}} non rialzo (forzante, da slam) ===
Nord ha un bicolore forte picche-quadri. Dopo 1{{fiori}} 1{{quadri}} 1{{cuori}} il 2{{picche}} non è un rialzo e quindi è forzante con interesse di slam.

Sud: <hand>K4.AJ73.83.KQ962</hand>

Nord: <hand>AKQ85.6.KQJ1042.7</hand>

<bidding dealer="S">1C P 1D P 1H P 2S P</bidding>

== Varianti ==
La fonte non propone varianti della XYZ in senso stretto: cita invece, come alternative ai check-back dopo 1SA dell'apertore, il '''Second Round Stayman''' (2{{fiori}} chiede prima un nobile quarto non dichiarato, poi tre carte nel nobile del rispondente; il solo orfano è un 2{{fiori}} naturale) e l'''Hi-Ro-Jerum'', che incorpora la "Spade Inversion". Non esistono pagine di varianti nel wiki.

== Opinione dell'autore ==
Kleinman osserva che la XYZ e i check-back dopo 1SA possono essere utili in alcune smazzate, ma che fanno più male che bene per via delle mani orfane che creano. Poiché preferisce rialzare liberamente le risposte di 1{{cuori}} e 1{{picche}}, dichiara di non averli mai usati. È una sua scelta personale, non una regola.

== Vedi anche ==
* [[Walsh]] — Nella lezione 05 del ''Corso Preagonistica 2026'' di Marina Causa la prosecuzione dopo la Walsh è chiamata "XY" ed è analoga nello schema (2{{fiori}} puppet verso 2{{quadri}}, 2{{quadri}} relé forzante a manche, 2SA transfer a 3{{fiori}}). Le due convenzioni hanno uno schema affine ma non sono la stessa: la XYZ è definita dall'articolo di Bridgebum sulle dieci sequenze sopra indicate.
* [[Due su uno Game Forcing]]

== Fonti ==
* Danny Kleinman, "XYZ", Bridgebum.com, © Jeff Tang, https://www.bridgebum.com/xyz.php (ideazione attribuita a Joe Kivel secondo l'articolo). Sintesi e riscrittura in italiano; gli esempi sono rielaborati.

Walsh

2026-11-03T05:44:24Z

Lpala: Walsh: correzione etichette scenari

{{DEFAULTSORT:Walsh}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]
[[Categoria:Risposte a 1 fiori]]

{{Convenzione
|nome=Walsh
|tipologia=Sviluppo
|scopo=Su apertura di 1{{fiori}}, anticipare il maggiore a discapito delle quadri (anche se più lunghe) con tutte le mani da 4 a 11 punti, per mettere in pista un nobile scavalcando le quadri (utile nella competizione) e per nascondere all'attacco le eventuali quarte nobili dell'apertore bilanciato.
|trigger=Apertura di 1{{fiori}} del compagno. Il rispondente con 4+ carte in un nobile e 4-11 punti onori risponde direttamente 1{{cuori}} o 1{{picche}}, saltando le quadri. Con mano da manche (FM, 12+ PO) si segue la sequenza naturale: 1{{quadri}} (solo se quinte o più), poi il nobile.
|risposte=Da 4 a 11 PO con un nobile: 1{{cuori}}/1{{picche}} diretto, anche con quadri più lunghe. Mano FM (12+): 1{{quadri}} (solo con quadri quinte o più) e poi il nobile; con quadri solo quarte si risponde comunque 1{{cuori}}. Dopo 1{{fiori}} 1{{quadri}}, se l'apertore ridichiara un colore a livello 1 mostra una mano sbilanciata (fiori lunghi o tricolore); se ridichiara 1SA, dopo 1{{fiori}} 1{{quadri}} 1SA la ridichiarazione 2{{cuori}} del rispondente garantisce i cuori. Prosecuzione XY (dopo 1{{fiori}}-1{{quadri}}-1 e simili): 2{{fiori}} = transfer per 2{{quadri}} (parziale a quadri o tutte le mani di invito); 2{{quadri}} = relé forzante manche; 2SA = transfer per 3{{fiori}} (parziale a fiori o mani 5/5 di 15+ con almeno due onori maggiori in entrambi i colori).
|note=Contenuto trascritto da slide: revisione da parte di un esperto consigliata. Il range dell'1SA di ridichiarazione dell'apertore non è indicato nella fonte. Con l'XY: la ripetizione del nobile di risposta è da passare; la dichiarazione di 2{{cuori}} dopo risposta 1{{picche}} non è forzante (max 9/10); tutte le dichiarazioni a livello tre, tradizionalmente invitanti e quindi passabili, diventano forzanti manche (perché tutti gli inviti passano dal 2{{fiori}}).
|tag_cc=response_walsh
|tag_sistema=naturale,quinta_nobile
|shape_constraints=1H su 1C con 4 cuori e 4-11 PO, saltando le quadri: pairhcp:16-28 opener hcp:12-17; responder H:4+ hcp:4-11; opp1 quiet; opp2 quiet // 1H con quadri più lunghe (quadri saltate): pairhcp:16-28 opener hcp:12-17; responder H:4 D:5+ hcp:4-11; opp1 quiet; opp2 quiet // 1S su 1C con 4 picche e 4-11 PO, saltando le quadri: pairhcp:16-28 opener hcp:12-17; responder S:4+ hcp:4-11; opp1 quiet; opp2 quiet // 1S con quadri più lunghe (quadri saltate): pairhcp:16-28 opener hcp:12-17; responder S:4 D:5+ hcp:4-11; opp1 quiet; opp2 quiet // FM con quadri 5+ e cuori quarti 1D poi cuori: pairhcp:24-33 opener hcp:12-17; responder D:5+ H:4 hcp:12-16; opp1 quiet; opp2 quiet // FM con quadri 5+ e picche quarte 1D poi picche: pairhcp:24-33 opener hcp:12-17; responder D:5+ S:4 hcp:12-16; opp1 quiet; opp2 quiet // apertore bilanciato che ridichiara 1SA dopo 1D (range 1SA non indicato nella fonte): pairhcp:18-28 opener shape:balanced hcp:12-14; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // apertore sbilanciato con fiori lunghi che ridichiara a livello 1 dopo 1D: pairhcp:18-28 opener C:6+ S:4 hcp:12-17; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // apertore tricolore che ridichiara a livello 1 dopo 1D: pairhcp:18-28 opener shape:three_suiter S:4 hcp:12-17; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // transfer 2C per parziale a quadri dopo 1S 1SA: pairhcp:16-24 opener shape:balanced hcp:12-14; responder S:4 D:5 hcp:5-9; opp1 quiet; opp2 quiet // transfer 2C per invito a manche con 5 cuori dopo 1H 1SA: pairhcp:22-26 opener shape:balanced hcp:12-14; responder H:5 hcp:10-11; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore (1{{fiori}});responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=Walsh: su 1♣ si risponde 1♥/1♠ con 4+ nobili e 4-11 PO (salta le quadri); con 12+ 1♦ (quinte+) poi il nobile
|cc_text_response_walsh=Walsh: su 1♣ nobile diretto con 4-11 PO anche saltando le quadri; 12+ PO 1♦ poi nobile; 1♦ poi XY (2♣ transfer a 2♦, 2♦ relé FM, 2SA transfer a 3♣)
}}

<div style="border:1px solid #c80; padding:6px;">'''Contenuto trascritto da slide (Marina Causa, Corso Preagonistica 2026): revisione da parte di un esperto consigliata.'''</div>

La '''Walsh''' è un accordo per cui, '''su apertura di 1{{fiori}}''', si '''anticipa il maggiore a discapito delle quadri''' (anche se più lunghe) '''con tutte le mani da 4 a 11 punti'''. Se invece la mano è da manche (FM) si segue la sequenza naturale: quadri (solo se quinte o più), poi il nobile.

== Schema ==
* Su 1{{fiori}}, con 4+ carte nobili e 4-11 PO: si risponde direttamente '''1{{cuori}}''' o '''1{{picche}}''', saltando le quadri, anche se le quadri sono più lunghe.
* Con mano da manche (FM, 12+): sequenza naturale, '''1{{quadri}}''' (solo se quinte o più) e poi il nobile.

=== Esempi della fonte (apertura 1{{fiori}} del compagno) ===
{| class="wikitable"
! Mano !! Risposta !! Nota
|-
| <hand>J84.A984.Q982.J7</hand> || 1{{cuori}} || 4-11 PO: nobile diretto
|-
| <hand>K74.Q984.A9862.7</hand> || 1{{cuori}} || quadri più lunghe, ma si anticipa il nobile
|-
| <hand>J4.AQ84.K982.KQ7</hand> || 1{{cuori}} || mano FM, ma le quadri sono solo quarte
|-
| <hand>K74.AQ84.AKJ82.7</hand> || 1{{quadri}} || mano FM: poi si dichiarano le cuori
|}

== Vantaggi ==
=== 1) Un nobile in pista scavalcando le quadri ===
Mette in pista un nobile scavalcando le quadri (cosa che di solito l'apertore non ha quando apre 1{{fiori}}): dal punto di vista della strategia di competizione è una scelta vincente (la fonte aggiunge: persino se il compagno non sa che si sta giocando Walsh da soli).

Esempio della fonte (Sud apre):

Sud: <hand>Q63.A1065.KQ4.Q98</hand>

Nord: <hand>52.KQ74.A10962.63</hand>

<bidding dealer="S">1C P 1H 1S 2H P P P</bidding>

Nord-Sud si sono potuti assestare velocemente su un parziale di 8 atout. Secondo la fonte, forse E/O potevano insistere a picche, forse avevano un ottimo fit a fiori; di certo, se Nord avesse risposto 1{{quadri}}, su 1{{picche}} Sud sarebbe passato e a bocce ferme per E/O sarebbe stato più facile appropriarsi del parziale.

=== 2) L'apertore bilanciato nasconde le quarte nobili ===
Se l'apertore è bilanciato di diritto e la risposta è 1{{quadri}} in prima istanza, si comporta come se il compagno non avesse quarte nobili e dichiara comunque 1SA. Con questa replica può nascondere una quarta nobile, o anche tutte e due; se resta il contratto finale, l'attaccante sarà completamente alla cieca.

Esempio della fonte: dopo 1{{fiori}} 1{{quadri}} 1SA 3SA l'attaccante ha ''mano completata'' (la slide dà picche J10xx, cuori KJxx, quadri Jx, fiori Qxx):
<hand>J1085.KJ73.J2.Q64</hand>

Sa che il morto scenderà senza quarte nobili, ma il vivo potrebbe averle entrambe, o solo una, o nessuna: non sa praticamente niente della mano del giocante.

Smazzata della fonte (Sud apre):

Sud: <hand>KJ63.AJ65.Q4.Q95</hand>

Nord: <hand>852.104.KJ62.KJ63</hand>

<bidding dealer="S">1C P 1D P 1SA P P P</bidding>

=== Nessun rischio di perdere una manche nobile ===
La fonte nota che non c'è pericolo di perdere una manche nel nobile: se il rispondente ha almeno 12 punti dichiara 1{{quadri}} all'inizio e poi prosegue dichiarando il nobile, svelando la forza oltre alla bicolore almeno 5/4.

Sud: <hand>KJ63.AJ65.Q4.Q95</hand>

Nord: <hand>Q2.K1084.KJ962.A3</hand>

<bidding dealer="S">1C P 1D P 1SA P 2H P 3H P 4H P P P</bidding>

Nord si accontenta della manche perché ha 13 e sa di fronteggiare una bilanciata di diritto; con la stessa mano e visuale di slam potrebbe, su 3{{cuori}}, iniziare a dare i controlli. Il seguito (una volta chiarito che il rispondente ha 12+ con quadri lunghe e la quarta nobile che annuncia) è tutto naturale:

Sud: <hand>K9.AJ94.Q72.Q1096</hand>

Nord: <hand>Q1043.K8.AJ953.K5</hand>

<bidding dealer="S">1C P 1D P 1SA P 2S P 2SA P 3SA P P P</bidding>

== Conseguenze sulle ridichiarazioni ==
* '''Apertore sbilanciato''': quando, sulla risposta di 1{{quadri}}, l'apertore ridichiara un colore a livello 1, mostra automaticamente una mano sbilanciata, e quindi fiori lunghi o tricolore. Esempio della fonte (''mano completata'', la slide dà AKxx, x, Axx, Qxxxx): <hand>AK63.4.A52.Q9873</hand> <bidding dealer="S">1C P 1D P 1S</bidding>
* '''2{{cuori}} del rispondente dopo 1SA''': in un sistema standard la ridichiarazione di 2{{cuori}} mostrerebbe valori nel colore e non necessariamente quattro carte; giocando Walsh il colore di cuori è garantito, per il fatto che l'apertore potrebbe avere fit nel seme. Nord si presenterà quindi con carte tipo (slide: KJx, AJxx, KQxxx, x; ''mano completata''): <hand>KJ4.AJ73.KQ982.6</hand> <bidding dealer="S">1C P 1D P 1SA P 2H</bidding>
* La sequenza 1{{fiori}} 1{{quadri}} 1SA 2{{cuori}} va considerata '''forzante di manche''' perché, adottando anche la convenzione XY, ci sarà modo di raccontare le carte di Nord quando si trova con una 4/6 invitante.

=== Nota sulle sequenze con 2{{quadri}} dell'apertore ===
La fonte avverte che giocare Walsh è abbastanza facile e rilassante, purché si faccia l'orecchio ad alcune sequenze delicate; indica due situazioni a cui prestare attenzione. Per la prima mostra la sequenza 1{{fiori}} 1{{picche}} 2{{fiori}} 2{{quadri}} ("??" sulla slide) con la mano seguente (''mano completata'', la slide dà Ax, Kx, xxx, AQxxxx): <hand>A4.K5.763.AQ9842</hand> <bidding dealer="S">1C P 1S P 2C P 2D P</bidding> La fonte dice che questa, per nessun motivo, può essere considerata una sequenza Walsh; la ridichiarazione di 2{{quadri}} è indispensabile per indagare ancora. In queste situazioni il rispondente, se ha il corto-lungo Walsh, deve rassegnarsi e passare, sperando che l'apertore abbia sei carte di fiori. (La slide descrive solo una delle due situazioni annunciate.)

== Prosecuzione "XY" dopo 1{{fiori}}-1{{quadri}}-1... ==
Giocando XY non serve più il nuovo colore forzante (non nelle sequenze a livello 1), né il check back né altro. L'idea: tutto ruota su tre possibili repliche del rispondente.
* '''2{{fiori}}''': transfer per 2{{quadri}}. Con tutte le mani che vogliono giocare un parziale a quadri oppure tutte le mani con forza di invito, che si chiarirà dopo.
* '''2{{quadri}}''': relé FM, con tutte le mani con cui il rispondente vuole interrogare.
* '''2SA''': transfer per 3{{fiori}}. Con tutte le mani che vogliono giocare un parziale a fiori oppure tutte le mani 5/5 di 15+ con almeno due onori maggiori in entrambi i colori.

Inoltre, qualcosa cambia:
* La ripetizione del nobile di risposta è da passare.
* La dichiarazione di 2{{cuori}} dopo risposta 1{{picche}} è non forzante (max 9/10).
* Tutte le dichiarazioni a livello tre, tradizionalmente invitanti e quindi passabili, usando l'XY diventano FM (perché tutti gli inviti passano dal 2{{fiori}}).

=== 2{{fiori}}, il transfer per gli inviti a manche o per le quadri ===
Con qualsiasi mano invitante il rispondente ridichiara 2{{fiori}} (e l'apertore dovrà dire 2{{quadri}}). L'apertore, con 11/16, dovrà rispettare il transfer. Dopodiché si aprono due possibilità.

==== a) Intenzione di giocare un parziale a quadri ====
Secondo la fonte è più che possibile e, giocando Walsh, è un modo intelligente di recuperare una lunga ignorata al primo giro. Chissà, forse 1SA era un buon parziale e forse no, di certo 2{{quadri}} non dovrebbe essere una brutta scelta: se sfortunati si troveranno 2 carte, altrimenti 3.

Sud: <hand>Q2.A82.J54.AJ976</hand>

Nord: <hand>KJ104.43.KQ952.103</hand>

<bidding dealer="S">1C P 1S P 1SA P 2C P 2D P P P</bidding>

Lo "stop" a 2{{quadri}} non è automatico: poiché l'apertore ha ridichiarato a colore 1 su 1, potrebbe ancora avere una mano che sfiora il rever. Nel timore che Nord si volesse fermare a un parziale a quadri (sempre possibile: se ora arrivasse il 3{{quadri}} Sud si rassegnerebbe) Sud disobbedisce, descrivendosi ancora: la pennellata a 3{{fiori}} descrive proprio queste carte, e questa forza onori. Esempio della fonte, nella forma riportata dalla slide (apertura 1{{quadri}}; ''mano completata'', la slide dà KQJ7, 4, AK854, A92):

<hand>KQJ7.4.AK854.A92</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 3C</bidding>

La disobbedienza deve presentare ottimi motivi, anche se la mano non è particolarmente forte:

<hand>K10.AQ87.4.KQJ972</hand>

<bidding dealer="S">1C P 1D P 1H P 2C P 3C</bidding>

Se Nord ha una mano invitante a manche farà le sue deduzioni: questo 3{{fiori}} dice "sono certo che questo parziale sia meglio, se era nelle tue intenzioni proporre di giocare 2{{quadri}}: io avrei detto 2{{quadri}} e tu Passo... ma ti prevengo con una sesta solidissima e un punteggio non minimo".

==== b) Invito a manche ====
Se ha intenzione di formulare un invito a manche (quindi la forza onori sarà intorno ai 10/11 punti), invece di passare il rispondente formulerà, a livello di estrema sicurezza, l'invito che intende proporre.

'''Invito con 5 carte di cuori''' ("sono invitante a manche con 5 carte di cuori"): Sud giustamente declina, né si prende il mal di pancia, con 12, di correggere a 2SA.

Sud: <hand>AK52.102.K54.Q872</hand>

Nord: <hand>94.AQJ74.A93.643</hand>

<bidding dealer="S">1C P 1H P 1S P 2C P 2D P 2H P P P</bidding>

Se le carte di Nord fossero state <hand>94.AQ9854.A54.65</hand> avrebbe detto 2{{fiori}} e poi 3{{cuori}}: invitante, ma questa volta con almeno 6 carte.

'''Invito con fit a picche''' ("sono invitante a manche con fit a picche"): Sud è minimo e passa. La fonte nota come sia straordinario riuscire a formulare a livello due un invito che, in qualunque naturale, si dovrebbe spingere a livello 3; a volte si è già sotto, nonostante il fit di 8 carte e i 22/23 punti in linea.

Sud: <hand>A1052.82.AJ54.K72</hand>

Nord: <hand>KQJ4.AJ74.93.643</hand>

<bidding dealer="S">1C P 1H P 1S P 2C P 2D P 2S P P P</bidding>

'''Invito a 3SA''' ("sono invitante a 3SA"): rialza se sei massimo. Secondo la fonte nulla di speciale: anche nel naturale classico senza fronzoli Sud avrebbe detto 1SA, Nord avrebbe invitato con 2SA e il risultato sarebbe stato comunque 3SA. Attenzione: quando invita a Senza il rispondente nega di avere 5 carte nel nobile di risposta.

Sud: <hand>K105.Q2.A109.KJ1072</hand>

Nord: <hand>QJ84.KJ74.Q83.Q3</hand>

<bidding dealer="S">1C P 1H P 1SA P 2C P 2D P 2SA P 3SA P P P</bidding>

'''Invito 5-4 (picche e cuori)''': Nord risponde normalmente 1{{picche}}, poi trasferisce con il 2{{fiori}} e mostra infine una mano "invitante con 5 picche e 4 cuori"; Sud con 14 accetta e rialza a manche.

Sud: <hand>K5.QJ92.A105.A1092</hand>

Nord: <hand>A9842.K1074.KJ.83</hand>

<bidding dealer="S">1C P 1S P 1SA P 2C P 2D P 2H P 4H P P P</bidding>

Secondo la fonte, se Nord avesse detto le cuori direttamente su 1SA avrebbe mostrato una mano limite, da 6 fino al punteggio da invito; se di cuori ne avesse dette 3, dopo essere passato dal transfer, avrebbe mostrato una 5-5 invitante. Occorre ricordarsi che il 2{{fiori}} prelude sempre a una mano non più che invitante, quindi al massimo 11.

== Picche e poi cuori ==
La fonte osserva che la sequenza di risposta "picche e poi cuori" è sempre stata delicatissima nel naturale senza convenzioni: essendo un cambio di colore forzante, chiedeva all'apertore di rialzare a 3 cuori tutte le volte che, anche con 12, preferiva il secondo colore. Questo creava al rispondente crisi di coscienza imbarazzanti (esempio della slide con apertura 1{{quadri}}: picche KJxxx, cuori AJxx, quadri xx, fiori xx, dopo 1{{quadri}} 1{{picche}} 1SA). Il fatto che, con l'XY, la replica 2{{cuori}} sia passabile è un grande sollievo.

== Varianti ==
La fonte non indica varianti della convenzione. Non esistono pagine di varianti nel wiki.

== Vedi anche ==
* [[Stayman]]
* [[Fiori forte]]
* [[Precision]]
* [[Landy]]

== Fonti ==
* Marina Causa, ''Corso Preagonistica 2026'', lezione 05 — La convenzione WALSH (slide).
* Nota: il contenuto è trascritto da slide; revisione da parte di un esperto consigliata. Gli esempi con "x" sulla slide sono indicati come ''mano completata'' con carte basse plausibili.

Walsh

2026-11-03T05:44:11Z

Lpala: Riscrittura completa da slide di Marina Causa (Corso Preagonistica 2026, lezione 05): schema corretto

{{DEFAULTSORT:Walsh}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]
[[Categoria:Risposte a 1 fiori]]

{{Convenzione
|nome=Walsh
|tipologia=Sviluppo
|scopo=Su apertura di 1{{fiori}}, anticipare il maggiore a discapito delle quadri (anche se più lunghe) con tutte le mani da 4 a 11 punti, per mettere in pista un nobile scavalcando le quadri (utile nella competizione) e per nascondere all'attacco le eventuali quarte nobili dell'apertore bilanciato.
|trigger=Apertura di 1{{fiori}} del compagno. Il rispondente con 4+ carte in un nobile e 4-11 punti onori risponde direttamente 1{{cuori}} o 1{{picche}}, saltando le quadri. Con mano da manche (FM, 12+ PO) si segue la sequenza naturale: 1{{quadri}} (solo se quinte o più), poi il nobile.
|risposte=Da 4 a 11 PO con un nobile: 1{{cuori}}/1{{picche}} diretto, anche con quadri più lunghe. Mano FM (12+): 1{{quadri}} (solo con quadri quinte o più) e poi il nobile; con quadri solo quarte si risponde comunque 1{{cuori}}. Dopo 1{{fiori}} 1{{quadri}}, se l'apertore ridichiara un colore a livello 1 mostra una mano sbilanciata (fiori lunghi o tricolore); se ridichiara 1SA, dopo 1{{fiori}} 1{{quadri}} 1SA la ridichiarazione 2{{cuori}} del rispondente garantisce i cuori. Prosecuzione XY (dopo 1{{fiori}}-1{{quadri}}-1 e simili): 2{{fiori}} = transfer per 2{{quadri}} (parziale a quadri o tutte le mani di invito); 2{{quadri}} = relé forzante manche; 2SA = transfer per 3{{fiori}} (parziale a fiori o mani 5/5 di 15+ con almeno due onori maggiori in entrambi i colori).
|note=Contenuto trascritto da slide: revisione da parte di un esperto consigliata. Il range dell'1SA di ridichiarazione dell'apertore non è indicato nella fonte. Con l'XY: la ripetizione del nobile di risposta è da passare; la dichiarazione di 2{{cuori}} dopo risposta 1{{picche}} non è forzante (max 9/10); tutte le dichiarazioni a livello tre, tradizionalmente invitanti e quindi passabili, diventano forzanti manche (perché tutti gli inviti passano dal 2{{fiori}}).
|tag_cc=response_walsh
|tag_sistema=naturale,quinta_nobile
|shape_constraints=1H su 1C con 4 cuori e 4-11 PO, saltando le quadri: pairhcp:16-28 opener hcp:12-17; responder H:4+ hcp:4-11; opp1 quiet; opp2 quiet // 1H con quadri più lunghe (quadri saltate): pairhcp:16-28 opener hcp:12-17; responder H:4 D:5+ hcp:4-11; opp1 quiet; opp2 quiet // 1S su 1C con 4 picche e 4-11 PO, saltando le quadri: pairhcp:16-28 opener hcp:12-17; responder S:4+ hcp:4-11; opp1 quiet; opp2 quiet // 1S con quadri più lunghe (quadri saltate): pairhcp:16-28 opener hcp:12-17; responder S:4 D:5+ hcp:4-11; opp1 quiet; opp2 quiet // FM con quadri 5+ e cuori quarti: 1D poi cuori: pairhcp:24-33 opener hcp:12-17; responder D:5+ H:4 hcp:12-16; opp1 quiet; opp2 quiet // FM con quadri 5+ e picche quarte: 1D poi picche: pairhcp:24-33 opener hcp:12-17; responder D:5+ S:4 hcp:12-16; opp1 quiet; opp2 quiet // apertore bilanciato che ridichiara 1SA dopo 1D (range 1SA non indicato nella fonte): pairhcp:18-28 opener shape:balanced hcp:12-14; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // apertore sbilanciato con fiori lunghi che ridichiara a livello 1 dopo 1D: pairhcp:18-28 opener C:6+ S:4 hcp:12-17; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // apertore tricolore che ridichiara a livello 1 dopo 1D: pairhcp:18-28 opener shape:three_suiter S:4 hcp:12-17; responder D:4+ H:0-3 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // transfer 2C per parziale a quadri dopo 1S 1SA: pairhcp:16-24 opener shape:balanced hcp:12-14; responder S:4 D:5 hcp:5-9; opp1 quiet; opp2 quiet // transfer 2C per invito a manche con 5 cuori dopo 1H 1SA: pairhcp:22-26 opener shape:balanced hcp:12-14; responder H:5 hcp:10-11; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore (1{{fiori}});responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=Walsh: su 1♣ si risponde 1♥/1♠ con 4+ nobili e 4-11 PO (salta le quadri); con 12+ 1♦ (quinte+) poi il nobile
|cc_text_response_walsh=Walsh: su 1♣ nobile diretto con 4-11 PO anche saltando le quadri; 12+ PO 1♦ poi nobile; 1♦ poi XY (2♣ transfer a 2♦, 2♦ relé FM, 2SA transfer a 3♣)
}}

<div style="border:1px solid #c80; padding:6px;">'''Contenuto trascritto da slide (Marina Causa, Corso Preagonistica 2026): revisione da parte di un esperto consigliata.'''</div>

La '''Walsh''' è un accordo per cui, '''su apertura di 1{{fiori}}''', si '''anticipa il maggiore a discapito delle quadri''' (anche se più lunghe) '''con tutte le mani da 4 a 11 punti'''. Se invece la mano è da manche (FM) si segue la sequenza naturale: quadri (solo se quinte o più), poi il nobile.

== Schema ==
* Su 1{{fiori}}, con 4+ carte nobili e 4-11 PO: si risponde direttamente '''1{{cuori}}''' o '''1{{picche}}''', saltando le quadri, anche se le quadri sono più lunghe.
* Con mano da manche (FM, 12+): sequenza naturale, '''1{{quadri}}''' (solo se quinte o più) e poi il nobile.

=== Esempi della fonte (apertura 1{{fiori}} del compagno) ===
{| class="wikitable"
! Mano !! Risposta !! Nota
|-
| <hand>J84.A984.Q982.J7</hand> || 1{{cuori}} || 4-11 PO: nobile diretto
|-
| <hand>K74.Q984.A9862.7</hand> || 1{{cuori}} || quadri più lunghe, ma si anticipa il nobile
|-
| <hand>J4.AQ84.K982.KQ7</hand> || 1{{cuori}} || mano FM, ma le quadri sono solo quarte
|-
| <hand>K74.AQ84.AKJ82.7</hand> || 1{{quadri}} || mano FM: poi si dichiarano le cuori
|}

== Vantaggi ==
=== 1) Un nobile in pista scavalcando le quadri ===
Mette in pista un nobile scavalcando le quadri (cosa che di solito l'apertore non ha quando apre 1{{fiori}}): dal punto di vista della strategia di competizione è una scelta vincente (la fonte aggiunge: persino se il compagno non sa che si sta giocando Walsh da soli).

Esempio della fonte (Sud apre):

Sud: <hand>Q63.A1065.KQ4.Q98</hand>

Nord: <hand>52.KQ74.A10962.63</hand>

<bidding dealer="S">1C P 1H 1S 2H P P P</bidding>

Nord-Sud si sono potuti assestare velocemente su un parziale di 8 atout. Secondo la fonte, forse E/O potevano insistere a picche, forse avevano un ottimo fit a fiori; di certo, se Nord avesse risposto 1{{quadri}}, su 1{{picche}} Sud sarebbe passato e a bocce ferme per E/O sarebbe stato più facile appropriarsi del parziale.

=== 2) L'apertore bilanciato nasconde le quarte nobili ===
Se l'apertore è bilanciato di diritto e la risposta è 1{{quadri}} in prima istanza, si comporta come se il compagno non avesse quarte nobili e dichiara comunque 1SA. Con questa replica può nascondere una quarta nobile, o anche tutte e due; se resta il contratto finale, l'attaccante sarà completamente alla cieca.

Esempio della fonte: dopo 1{{fiori}} 1{{quadri}} 1SA 3SA l'attaccante ha ''mano completata'' (la slide dà picche J10xx, cuori KJxx, quadri Jx, fiori Qxx):
<hand>J1085.KJ73.J2.Q64</hand>

Sa che il morto scenderà senza quarte nobili, ma il vivo potrebbe averle entrambe, o solo una, o nessuna: non sa praticamente niente della mano del giocante.

Smazzata della fonte (Sud apre):

Sud: <hand>KJ63.AJ65.Q4.Q95</hand>

Nord: <hand>852.104.KJ62.KJ63</hand>

<bidding dealer="S">1C P 1D P 1SA P P P</bidding>

=== Nessun rischio di perdere una manche nobile ===
La fonte nota che non c'è pericolo di perdere una manche nel nobile: se il rispondente ha almeno 12 punti dichiara 1{{quadri}} all'inizio e poi prosegue dichiarando il nobile, svelando la forza oltre alla bicolore almeno 5/4.

Sud: <hand>KJ63.AJ65.Q4.Q95</hand>

Nord: <hand>Q2.K1084.KJ962.A3</hand>

<bidding dealer="S">1C P 1D P 1SA P 2H P 3H P 4H P P P</bidding>

Nord si accontenta della manche perché ha 13 e sa di fronteggiare una bilanciata di diritto; con la stessa mano e visuale di slam potrebbe, su 3{{cuori}}, iniziare a dare i controlli. Il seguito (una volta chiarito che il rispondente ha 12+ con quadri lunghe e la quarta nobile che annuncia) è tutto naturale:

Sud: <hand>K9.AJ94.Q72.Q1096</hand>

Nord: <hand>Q1043.K8.AJ953.K5</hand>

<bidding dealer="S">1C P 1D P 1SA P 2S P 2SA P 3SA P P P</bidding>

== Conseguenze sulle ridichiarazioni ==
* '''Apertore sbilanciato''': quando, sulla risposta di 1{{quadri}}, l'apertore ridichiara un colore a livello 1, mostra automaticamente una mano sbilanciata, e quindi fiori lunghi o tricolore. Esempio della fonte (''mano completata'', la slide dà AKxx, x, Axx, Qxxxx): <hand>AK63.4.A52.Q9873</hand> <bidding dealer="S">1C P 1D P 1S</bidding>
* '''2{{cuori}} del rispondente dopo 1SA''': in un sistema standard la ridichiarazione di 2{{cuori}} mostrerebbe valori nel colore e non necessariamente quattro carte; giocando Walsh il colore di cuori è garantito, per il fatto che l'apertore potrebbe avere fit nel seme. Nord si presenterà quindi con carte tipo (slide: KJx, AJxx, KQxxx, x; ''mano completata''): <hand>KJ4.AJ73.KQ982.6</hand> <bidding dealer="S">1C P 1D P 1SA P 2H</bidding>
* La sequenza 1{{fiori}} 1{{quadri}} 1SA 2{{cuori}} va considerata '''forzante di manche''' perché, adottando anche la convenzione XY, ci sarà modo di raccontare le carte di Nord quando si trova con una 4/6 invitante.

=== Nota sulle sequenze con 2{{quadri}} dell'apertore ===
La fonte avverte che giocare Walsh è abbastanza facile e rilassante, purché si faccia l'orecchio ad alcune sequenze delicate; indica due situazioni a cui prestare attenzione. Per la prima mostra la sequenza 1{{fiori}} 1{{picche}} 2{{fiori}} 2{{quadri}} ("??" sulla slide) con la mano seguente (''mano completata'', la slide dà Ax, Kx, xxx, AQxxxx): <hand>A4.K5.763.AQ9842</hand> <bidding dealer="S">1C P 1S P 2C P 2D P</bidding> La fonte dice che questa, per nessun motivo, può essere considerata una sequenza Walsh; la ridichiarazione di 2{{quadri}} è indispensabile per indagare ancora. In queste situazioni il rispondente, se ha il corto-lungo Walsh, deve rassegnarsi e passare, sperando che l'apertore abbia sei carte di fiori. (La slide descrive solo una delle due situazioni annunciate.)

== Prosecuzione "XY" dopo 1{{fiori}}-1{{quadri}}-1... ==
Giocando XY non serve più il nuovo colore forzante (non nelle sequenze a livello 1), né il check back né altro. L'idea: tutto ruota su tre possibili repliche del rispondente.
* '''2{{fiori}}''': transfer per 2{{quadri}}. Con tutte le mani che vogliono giocare un parziale a quadri oppure tutte le mani con forza di invito, che si chiarirà dopo.
* '''2{{quadri}}''': relé FM, con tutte le mani con cui il rispondente vuole interrogare.
* '''2SA''': transfer per 3{{fiori}}. Con tutte le mani che vogliono giocare un parziale a fiori oppure tutte le mani 5/5 di 15+ con almeno due onori maggiori in entrambi i colori.

Inoltre, qualcosa cambia:
* La ripetizione del nobile di risposta è da passare.
* La dichiarazione di 2{{cuori}} dopo risposta 1{{picche}} è non forzante (max 9/10).
* Tutte le dichiarazioni a livello tre, tradizionalmente invitanti e quindi passabili, usando l'XY diventano FM (perché tutti gli inviti passano dal 2{{fiori}}).

=== 2{{fiori}}, il transfer per gli inviti a manche o per le quadri ===
Con qualsiasi mano invitante il rispondente ridichiara 2{{fiori}} (e l'apertore dovrà dire 2{{quadri}}). L'apertore, con 11/16, dovrà rispettare il transfer. Dopodiché si aprono due possibilità.

==== a) Intenzione di giocare un parziale a quadri ====
Secondo la fonte è più che possibile e, giocando Walsh, è un modo intelligente di recuperare una lunga ignorata al primo giro. Chissà, forse 1SA era un buon parziale e forse no, di certo 2{{quadri}} non dovrebbe essere una brutta scelta: se sfortunati si troveranno 2 carte, altrimenti 3.

Sud: <hand>Q2.A82.J54.AJ976</hand>

Nord: <hand>KJ104.43.KQ952.103</hand>

<bidding dealer="S">1C P 1S P 1SA P 2C P 2D P P P</bidding>

Lo "stop" a 2{{quadri}} non è automatico: poiché l'apertore ha ridichiarato a colore 1 su 1, potrebbe ancora avere una mano che sfiora il rever. Nel timore che Nord si volesse fermare a un parziale a quadri (sempre possibile: se ora arrivasse il 3{{quadri}} Sud si rassegnerebbe) Sud disobbedisce, descrivendosi ancora: la pennellata a 3{{fiori}} descrive proprio queste carte, e questa forza onori. Esempio della fonte, nella forma riportata dalla slide (apertura 1{{quadri}}; ''mano completata'', la slide dà KQJ7, 4, AK854, A92):

<hand>KQJ7.4.AK854.A92</hand>

<bidding dealer="S">1D P 1H P 1S P 2C P 3C</bidding>

La disobbedienza deve presentare ottimi motivi, anche se la mano non è particolarmente forte:

<hand>K10.AQ87.4.KQJ972</hand>

<bidding dealer="S">1C P 1D P 1H P 2C P 3C</bidding>

Se Nord ha una mano invitante a manche farà le sue deduzioni: questo 3{{fiori}} dice "sono certo che questo parziale sia meglio, se era nelle tue intenzioni proporre di giocare 2{{quadri}}: io avrei detto 2{{quadri}} e tu Passo... ma ti prevengo con una sesta solidissima e un punteggio non minimo".

==== b) Invito a manche ====
Se ha intenzione di formulare un invito a manche (quindi la forza onori sarà intorno ai 10/11 punti), invece di passare il rispondente formulerà, a livello di estrema sicurezza, l'invito che intende proporre.

'''Invito con 5 carte di cuori''' ("sono invitante a manche con 5 carte di cuori"): Sud giustamente declina, né si prende il mal di pancia, con 12, di correggere a 2SA.

Sud: <hand>AK52.102.K54.Q872</hand>

Nord: <hand>94.AQJ74.A93.643</hand>

<bidding dealer="S">1C P 1H P 1S P 2C P 2D P 2H P P P</bidding>

Se le carte di Nord fossero state <hand>94.AQ9854.A54.65</hand> avrebbe detto 2{{fiori}} e poi 3{{cuori}}: invitante, ma questa volta con almeno 6 carte.

'''Invito con fit a picche''' ("sono invitante a manche con fit a picche"): Sud è minimo e passa. La fonte nota come sia straordinario riuscire a formulare a livello due un invito che, in qualunque naturale, si dovrebbe spingere a livello 3; a volte si è già sotto, nonostante il fit di 8 carte e i 22/23 punti in linea.

Sud: <hand>A1052.82.AJ54.K72</hand>

Nord: <hand>KQJ4.AJ74.93.643</hand>

<bidding dealer="S">1C P 1H P 1S P 2C P 2D P 2S P P P</bidding>

'''Invito a 3SA''' ("sono invitante a 3SA"): rialza se sei massimo. Secondo la fonte nulla di speciale: anche nel naturale classico senza fronzoli Sud avrebbe detto 1SA, Nord avrebbe invitato con 2SA e il risultato sarebbe stato comunque 3SA. Attenzione: quando invita a Senza il rispondente nega di avere 5 carte nel nobile di risposta.

Sud: <hand>K105.Q2.A109.KJ1072</hand>

Nord: <hand>QJ84.KJ74.Q83.Q3</hand>

<bidding dealer="S">1C P 1H P 1SA P 2C P 2D P 2SA P 3SA P P P</bidding>

'''Invito 5-4 (picche e cuori)''': Nord risponde normalmente 1{{picche}}, poi trasferisce con il 2{{fiori}} e mostra infine una mano "invitante con 5 picche e 4 cuori"; Sud con 14 accetta e rialza a manche.

Sud: <hand>K5.QJ92.A105.A1092</hand>

Nord: <hand>A9842.K1074.KJ.83</hand>

<bidding dealer="S">1C P 1S P 1SA P 2C P 2D P 2H P 4H P P P</bidding>

Secondo la fonte, se Nord avesse detto le cuori direttamente su 1SA avrebbe mostrato una mano limite, da 6 fino al punteggio da invito; se di cuori ne avesse dette 3, dopo essere passato dal transfer, avrebbe mostrato una 5-5 invitante. Occorre ricordarsi che il 2{{fiori}} prelude sempre a una mano non più che invitante, quindi al massimo 11.

== Picche e poi cuori ==
La fonte osserva che la sequenza di risposta "picche e poi cuori" è sempre stata delicatissima nel naturale senza convenzioni: essendo un cambio di colore forzante, chiedeva all'apertore di rialzare a 3 cuori tutte le volte che, anche con 12, preferiva il secondo colore. Questo creava al rispondente crisi di coscienza imbarazzanti (esempio della slide con apertura 1{{quadri}}: picche KJxxx, cuori AJxx, quadri xx, fiori xx, dopo 1{{quadri}} 1{{picche}} 1SA). Il fatto che, con l'XY, la replica 2{{cuori}} sia passabile è un grande sollievo.

== Varianti ==
La fonte non indica varianti della convenzione. Non esistono pagine di varianti nel wiki.

== Vedi anche ==
* [[Stayman]]
* [[Fiori forte]]
* [[Precision]]
* [[Landy]]

== Fonti ==
* Marina Causa, ''Corso Preagonistica 2026'', lezione 05 — La convenzione WALSH (slide).
* Nota: il contenuto è trascritto da slide; revisione da parte di un esperto consigliata. Gli esempi con "x" sulla slide sono indicati come ''mano completata'' con carte basse plausibili.

Walsh

2026-11-02T19:48:47Z

Lpala: Nuova pagina Walsh (bozza IA da verificare)

{{DEFAULTSORT:Walsh}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di risposta]]
[[Categoria:Risposte a 1 fiori]]

{{Convenzione
|nome=Walsh
|tipologia=Sviluppo
|scopo=Dopo l'apertura di 1{{fiori}}, permettere al rispondente con un quarto nobile (senza quinta nobile) di rispondere 1{{quadri}} e lasciare all'apertore la dichiarazione del proprio quarto nobile, per trovare un fit 4-4 nei colori maggiori.
|trigger=Apertura di 1{{fiori}} del compagno (non forte e non artificiale); il rispondente ha circa 6+ punti onori, un quarto nobile e nessuna quinta nobile.
|risposte=Schema di riferimento (da verificare): 1{{quadri}} = quarto nobile, 6+ PO, nessuna quinta nobile; l'apertore dichiara per primo un proprio quarto nobile (1{{cuori}} o 1{{picche}}); con 4{{cuori}} 4{{picche}} nel rispondente si cerca il fit; senza nobile quarto l'apertore ridichiara 1SA se bilanciato (nello schema qui descritto 12-14 PO) o il proprio colore.
|note=Redatto da IA e da verificare dagli esperti: nessuna fonte primaria verificata (vedi Fonti). Le soglie di punti e il trattamento di 1{{quadri}} (solo con quarto nobile, oppure anche con quadri lunghi) variano tra gli autori e i sistemi: sono varianti, non regole consolidate. Compatibile con i sistemi naturali con 1{{fiori}} non forte.
|tag_cc=response_walsh
|tag_sistema=naturale,quinta_nobile
|shape_constraints=1D con 4 cuori: pairhcp:18-28 opener hcp:12-17; responder H:4 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // 1D con 4 picche: pairhcp:18-28 opener hcp:12-17; responder S:4 H:0-3 hcp:6-11; opp1 quiet; opp2 quiet // 1D con 4-4 nobili: pairhcp:18-28 opener hcp:12-17; responder S:4 H:4 hcp:6-11; opp1 quiet; opp2 quiet // rientro apertore con fit a cuori: pairhcp:18-28 opener H:4 hcp:12-17; responder H:4 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet // rientro apertore con fit a picche: pairhcp:18-28 opener S:4 H:0-3 hcp:12-17; responder S:4 H:0-3 hcp:6-11; opp1 quiet; opp2 quiet // 1SA bilanciato dell'apertore: pairhcp:18-26 opener shape:balanced hcp:12-14 H:0-3 S:0-3; responder H:4 S:0-3 hcp:6-11; opp1 quiet; opp2 quiet
|shape_roles=opener=Apertore;responder=Rispondente;opp1=Avversario;opp2=Avversario
|cc_text_default=Walsh (1♦ su 1♣ = quarto nobile, 6+ PO)
|cc_text_response_walsh=Walsh: 1♦ su 1♣ con quarto nobile, l'apertore dichiara il suo nobile
}}

<div style="border:1px solid #c80; padding:6px;">'''Bozza redatta da IA, da verificare dagli esperti finché non rivista.'''</div>

La '''Walsh''' è una convenzione di risposta all'apertura di '''1{{fiori}}''' naturale (non forte e non artificiale), in cui il rispondente con un '''quarto nobile''' e senza quinta nobile risponde '''1{{quadri}}''' invece di dichiarare il nobile, lasciando all'apertore la possibilità di dichiarare per primo un proprio quarto nobile.

''Nota di redazione'': le fonti consultabili per questa pagina non descrivono la convenzione (vedi [[#Fonti|Fonti]]). Quanto segue è uno schema di riferimento prudente; i punti che nelle fonti degli autori cambiano sono indicati come varianti.

== Idea ==
Con un quarto nobile non si vuole dichiarare il colore se il fit non è certo, e si preferisce che sia l'apertore, che può avere un quarto nobile, a dichiararlo per primo. Il rispondente con 1{{quadri}} indica una mano con almeno un quarto nobile e dà all'apertore la possibilità di rispondere nel suo nobile: se si trova un fit 4-4 lo si raggiunge e il contratto è giocato dalla mano più adatta.

== Apertura ==
L'apertura è '''1{{fiori}}''' naturale o ''contenitore'' (spesso con 3 carte in sistemi a quinta nobile), con punti normali. Non si applica ai sistemi a '''[[Fiori forte]]''' (dove 1{{fiori}} è artificiale e le risposte sono diverse; vedi anche [[Precision]]): in tali sistemi le risposte a 1{{fiori}} seguono lo schema del sistema.

== Risposta di 1{{quadri}} ==
Schema di riferimento:
* '''6+ punti onori''' circa;
* '''quarto nobile''' (cuori o picche) o entrambi;
* '''nessuna quinta''' in un nobile (con quinta si risponde nel colore lungo);
* senza una mano adatta a un'altra risposta più descrittiva.

=== Esempio 1: 1{{quadri}} con 4{{cuori}} ===
Mano del rispondente (Sud), 4{{cuori}} senza quinta nobile:
<hand>J32.KQ72.84.J983</hand>

<bidding>1C P 1D P 1H P 2H P P P</bidding>

L'apertore (Nord) con 4{{cuori}} ridichiara 1{{cuori}}, il rispondente appoggia a livello minimo con una mano minima: fit 4-4 raggiunto.

Mano dell'apertore:
<hand>A85.AJ96.KQ2.754</hand>

== Rientro dell'apertore ==
Dopo 1{{fiori}} P 1{{quadri}} P, l'apertore dichiara per primo il proprio '''quarto nobile''':
* con 4{{cuori}} dichiara 1{{cuori}}, con 4{{picche}} dichiara 1{{picche}}: indica il fit atteso se il rispondente ha lo stesso nobile;
* senza nobile quarto, se bilanciato, ridichiara '''1SA''' (nello schema qui descritto 12-14 PO) oppure il proprio colore: 2{{fiori}} con fiori lunghi o un colore minore.

=== Esempio 2: 1SA bilanciato dell'apertore ===
Mano dell'apertore (Nord), bilanciata 12-14 senza quarto nobile:
<hand>KQ4.J85.AJ73.Q52</hand>

Mano del rispondente (Sud):
<hand>85.KQ72.Q94.J1083</hand>

<bidding>1C P 1D P 1SA P 2H P P P</bidding>

L'apertore non ha un quarto nobile e ridichiara 1SA; il rispondente, con mano minima e 4{{cuori}}, può fermarsi in un contratto parziale secondo gli accordi di coppia (qui 2{{cuori}} è solo indicativo: dettaglio da verificare).

=== Esempio 3: 4-4 nei nobili ===
Mano del rispondente, 4{{picche}} 4{{cuori}}:
<hand>K942.A653.82.Q74</hand>

Mano dell'apertore, con 4{{picche}}:
<hand>AJ75.K2.KQ95.J63</hand>

<bidding>1C P 1D P 1S P 2S P P P</bidding>

L'apertore dichiara il proprio quarto nobile (1{{picche}}) e il rispondente appoggia: fit 4-4 a picche.

== Con 5-4 nei nobili ==
Con 5-4 nei nobili si risponde generalmente nel colore lungo (5 carte), non con 1{{quadri}}: è fuori dallo schema Walsh qui descritto.

== Varianti ==
La Walsh è citata in letteratura in più forme; nessuna pagina del wiki e nessuna fonte consultata fissa i dettagli. Punti da verificare:
* soglia minima di punti del rispondente (6+ nello schema qui riportato) e mani con quadri lunghi che passano comunque da 1{{quadri}};
* uso con 4-4 nobili: se rispondere in 1{{cuori}} (up-the-line) o in 1{{quadri}};
* punti dell'1SA di ridichiarazione dell'apertore (12-14 nello schema qui riportato);
* se il rispondente con mano da manche ha sviluppi diversi dalla risposta Walsh (spesso 2/1 o salto);
* nessuna pagina "Walsh (variante)" esiste: le varianti non sono sviluppate qui.

== Vantaggi e svantaggi ==
* Vantaggio: l'apertore non rischia di restare senza un fit nobile perché il rispondente non dichiara per primo; il fit 4-4 si trova a livello basso.
* Vantaggio: il rispondente con mano povera ha un'unica risposta naturale per le mani con quarto nobile.
* Svantaggio: 1{{quadri}} diventa ambiguo (può nascondere quadri o nobili), ed è meno descrittivo quando il rispondente ha una buona mano di manche.
* Svantaggio: se l'apertore ha fiori lunghi può preferire 2{{fiori}} e perdere il nobile.

== Rapporto con il resto del sistema ==
Compatibile con le risposte naturali a 1{{fiori}} nei sistemi a quinta nobile. Non si usa nei sistemi in cui 1{{fiori}} è artificiale (vedi [[Fiori forte]], [[Precision]]). Si può affiancare a convenzioni di ricerca del fit come lo [[Stayman]] (su 1SA) per le mani bilanciate.

== Vedi anche ==
* [[Stayman]]
* [[Fiori forte]]
* [[Precision]]
* [[Landy]]

== Fonti ==
* Fonte da completare: nessuna fonte primaria verificata al momento della redazione. L'attribuzione della convenzione a Richard Walsh non è supportata da fonti presenti nel wiki, e non è stata inserita qui.
* Nel wiki la Walsh compare solo come voce della scheda convenzionale BridgeCC (risposta 1{{quadri}} a 1{{fiori}}); non è una fonte sul contenuto.

Gioco di eliminazione

2026-10-28T07:36:01Z

Lpala: Scenari E2-E4: vincoli difensori/punti e nota di verifica aggiornata

{{Convenzione
|nome=Gioco di eliminazione
|tipologia=Tecnica di gioco
|scopo=Togliere alla difesa le uscite neutre nei colori laterali, in modo che un avversario messo in presa debba muovere un colore pericoloso o giocare in taglio e scarto, evitando di dipendere dalla posizione di una carta.
|trigger=Contratto a colore con atout lunghi in linea e colori laterali che si possono eliminare (incassando le vincenti e tagliando le perdenti), con un colore chiave in cui la difesa, costretta a giocare per prima, ci regala una presa.
|risposte=1) Contare le prese sicure e le perdenti; 2) battere le atout; 3) incassare e tagliare i colori laterali; 4) mettere in presa un avversario (messa in mano); 5) lasciare alla difesa solo il colore pericoloso o il taglio e scarto.
|note=Alternativa alla linea di impasse o expasse: l'eliminazione non dipende dalla posizione di una carta ma richiede che la difesa non abbia uscite neutre. Pagina di tecnica di gioco, non di licita: nessun tag BridgeCC applicabile.
|shape_constraints=E1 messa in mano a cuori: opener S:5 S=AKQJ H:2 H=x D:3 D=J C:3 C=AQ; responder S:4 S=x H:3 H=AQ D:4 D=Q C:2 C=K // E2 dama a picche evitata: opener S:2 S=AQ H:4 H=AKQ D:3 D=x C:4 C=KQJT; responder S:2 S=x H:4 H=x D:3 D=AKJ C:4 C=x; opp1 H:2-3; opp2 H:2-3 // E3 slam a quadri con atout 2-2: opener S:5 S=AKQ H:3 H=K D:4 D=AQ C:1 C=x; responder S:4 S=x H:3 H=A D:4 D=K C:2 C=A; opp1 S:2 hcp:4-7; opp2 S:2 hcp:4-7 // E4 taglio e scarto: opener S:5 S=KQT H:3 H=x D:2 D=K C:3 C=AQ; responder S:4 S=AJ9 H:2 H=T D:4 D=A C:3 C=x; opp1 S:2 H:4 H=AKQ D:4; opp2 S:2 hcp:4-8 // E5 sottoapertura a quadri: opener S:2 S=x H:3 H=K D:2 D=AQ C:6 C=AQT; responder S:4 S=AKQ H:4 H=Q D:2 D=x C:3 C=KJ; opp1 D:6 D=KJT H:3 H=A
|shape_roles=opener=Dichiarante;responder=Morto;opp1=Attaccante;opp2=Quarta mano
}}

Il '''gioco di eliminazione''' (in inglese ''elimination play'' o ''strip and throw-in'') è una tecnica del [[Gioco della carta (bridge)|gioco della carta]] con cui il dichiarante, in un contratto a colore, toglie uno dopo l'altro i colori laterali alla difesa e poi mette in presa un avversario, che si trova costretto a giocare un colore dove regala una presa oppure a muovere in taglio e scarto.

== Quando si usa ==
Si pensa all'eliminazione quando:
* il contratto è a colore e la linea in atout è tranquilla (tipicamente le atout si battono senza problemi);
* resta un solo colore da giocare con difficoltà, di solito con una perdente che dipende da un impasse o da una posizione di carte;
* i colori laterali si possono esaurire incassando le vincenti e tagliando le piccole, in mano o al morto;
* un avversario può essere messo in presa senza che gli rimanga una uscita neutra.

== Come si svolge ==
# '''Conta''': si contano le prese sicure e le perdenti e si individua il colore dove la difesa può fare danno.
# '''Atout''': di norma si battono le atout, per impedire alla difesa di tagliare e per mantenere il controllo.
# '''Eliminazione dei colori laterali''': si incassano le vincenti dei colori laterali e si tagliano le perdenti, finché la difesa non ha più carte in quei colori.
# '''Messa in mano''': si cede una presa a un avversario scelto, in modo che debba rigiocare.
# '''Scelta del colore''': la difesa può muovere solo il colore pericoloso, oppure giocare in taglio e scarto, che permette al dichiarante di scartare una perdente e tagliare nell'altra mano.

== Eliminazione e impasse a confronto ==
La linea di impasse o expasse dipende dalla posizione di una carta: se è sbagliata, la mano cade. L'eliminazione sposta il problema: invece di indovinare dove sta la carta, si costringe la difesa a muovere per prima nel colore dove si vuole che giochi. Funziona quando la difesa non ha uscite neutre, cioè colori dove può giocare senza regalare nulla. Quando le ha ancora, la messa in mano non produce l'effetto sperato e occorre ripiegare sulla linea di impasse.

== Errori tipici ==
* '''Incassare un giro di troppo''': togliere una carta che serviva come uscita al dichiarante o come ingresso, e lasciare alla difesa una uscita neutra.
* '''Togliere troppo presto un ingresso''': dopo aver eliminato i colori, al dichiarante manca il rientro in mano o al morto necessario a completare la tecnica.
* '''Non contare prima''': iniziare a incassare senza avere stabilito quale colore deve restare alla difesa.

== Esempio 1: messa in mano a cuori ==
Nord è dichiarante, nessuno in zona. Contratto 4{{picche}}, attacco Fante di fiori.

<deal dealer="N" vul="None" board="1">
N: AKQJ7.52.J74.AQ5
E: 86.J943.A106.J1097
S: T954.AQ6.Q852.K6
W: 32.K1087.K93.8432
</deal>

<bidding>1S P 2NT P 4S P P P</bidding>

Dopo aver battuto le atout, si incassano i fiori scartando una piccola di cuori dal morto e si incassano gli onori di cuori. La difesa, messa in presa, deve muovere quadri oppure giocare in taglio e scarto. La linea di impasse a cuori e di expasse a quadri riuscirebbe solo con certe posizioni (circa il 67 %); l'eliminazione realizza dieci prese qualunque sia la difesa (verificato a carte scoperte).

== Esempio 2: la dama di quadri e l'impasse a picche non servono ==
Ovest è dichiarante, Est-Ovest in zona. Contratto 4{{cuori}}, attacco 5 di fiori.

<deal dealer="W" vul="EW" board="2">
N: KJ7652.JT.8632.5
E: 98.6543.AJ5.7432
S: T43.972.Q97.A986
W: AQ.AKQ8.KT4.KQJT
</deal>

<bidding>2C P 2D P 2NT P 3C P 3H P 4H P P P</bidding>

Dopo aver battuto le atout e incassato i fiori, basta giocare Asso e Dama di picche (eliminazione) invece di indovinare la posizione della Dama di quadri o di tentare l'impasse a picche: la linea di eliminazione riesce nel 100 % dei casi contro circa il 75 % delle altre. Dieci prese verificate a carte scoperte.

== Regole di generazione ==
Questa pagina fornisce a Play le regole per generare smazzate di allenamento. Ogni scenario fissa la struttura del dichiarante e del morto: le lunghezze dei colori e gli onori del colore chiave; le carte basse e gli onori non nominati sono casuali e sui difensori i vincoli di punti sono solo quelli indicati negli scenari E3 e E4.
* '''E1 (messa in mano a cuori)''': dichiarante con cinque picche e AKQJ, morto con quattro picche; contratto da giocare 4{{picche}}.
* '''E2 (dama a picche evitata)''': dichiarante con AKQ di cuori e KQJT di fiori, morto con quattro cuori e Asso, Re e Fante di quadri; il Re di quadri è in mano al Morto (il Dichiarante ha 21 PO e il Morto 8) e i difensori hanno i cuori divisi 3-2; contratto da giocare 4{{cuori}}. Motivo: mani meno sbilanciate nei punti.
* '''E3 (slam a quadri con atout 2-2)''': slam a picche (contratto 6{{picche}}) con colore chiave a quadri e atout divisi 2-2 fra i difensori; ogni difensore ha 4-7 PO (mani meno sbilanciate nei punti).
* '''E4 (taglio e scarto)''': contratto 4{{picche}} con taglio e scarto: l'attaccante (opp1) ha Asso, Re e Dama di cuori quarte e quattro quadri, atout 2-2; il difensore Quarta mano (opp2) ha 4-8 PO (mani meno sbilanciate nei punti).
* '''E5 (sottoapertura a quadri)''': contratto 6{{fiori}} dopo una sottoapertura a quadri dell'attaccante: ha quadri sesti con K, J, 10 e l'Asso di cuori.
Gli scenari E2-E5 vincolano anche i difensori, perché la linea di eliminazione dipende da come sono divisi gli atout e da dove stanno gli onori.

'''Nota di verifica.''' Gli scenari sono stati controllati campionando mani e risolvendole a carte scoperte con la difesa migliore: il contratto si realizza in E1 10/10, E2 8/8 (con cuori dei difensori 2-3; senza quel vincolo 6/8: le mani fallivano con cuori 4-1 o vuoti), E3 7/8, E4 7 su 7 risolte tutte realizzate (1 non risolta nel tempo massimo), E5 8/8. I campioni sono piccoli, quindi sono indicazioni e non garanzie; il solutore è un double-dummy interno. Il contratto è sempre realizzabile solo con la linea di eliminazione nelle mani generate, salvo le eccezioni indicate.

== Vedi anche ==
* [[Gioco della carta (bridge)]]

== Fonti ==
* ProgettoBridge, ''Lezione 18 — Gioco di Eliminazione, Smazzate esplicative''.

Progetto:BridgeShape Editor e Laboratorio

2026-10-28T07:05:45Z

Lpala: Corretto grassetto

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]]

= BridgeShape — Editor avanzato e Laboratorio di test (brief per Play) =

Integra <code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code> §8.4 (editor) e §5.8 (statistiche). Origine: la scrittura degli scenari
di "Gioco di eliminazione" (E1–E5) ha mostrato che il DSL è espressivo ma '''non si vede come
vengono generate le mani''': gli scenari risultavano sbilanciati (es. apertore 24 PO, risponditore 5;
avversari a 0 PO che ricevono tutti i punti residui) e ce ne si accorge solo guardando mani a caso.

== 1. Il DSL è abbastanza generale? Lacune da colmare ==

Coperto bene: lunghezze, forma, PO totali/per seme, onori esatti (<code><nowiki>S=AKQJ</nowiki></code>, <code><nowiki>x</nowiki></code>), pattern, <code><nowiki>pairhcp</nowiki></code>,
fermate, controlli, carte chiave, LTC, <code><nowiki>any</nowiki></code>/<code><nowiki>not</nowiki></code>, variabili, macro, contesto (dealer, contratto, attacco).

Lacune (in ordine di priorità):

# '''Nessun controllo su come si distribuisce il resto.''' Le carte non vincolate vanno a caso alle mani libere. Servono:
#* <code><nowiki>default-opp: realistic</nowiki></code> (o <code><nowiki>quiet</nowiki></code> già esistente) con soglie ragionevoli per gli avversari;
#* <code><nowiki>hcp:</nowiki></code> e <code><nowiki>pairhcp:</nowiki></code> per ogni posizione '''anche come intervallo "tipico"''' (non solo filtro);
#* opzione <code><nowiki>spread: even</nowiki></code> che, dopo i vincoli, ripartisce gli onori residui senza concentrarli in una mano.
# '''Vincoli di esito (post-filtro double-dummy)''': <code><nowiki>makes: 4S by opener</nowiki></code>, <code><nowiki>tricks: 10-11</nowiki></code>, <code><nowiki>lead-fails</nowiki></code>. Fondamentali per le tecniche di gioco (eliminazione, messa in presa, squeeze). Opzionali, con budget di tempo; se il solver non c'è → <code><nowiki>requires: dd</nowiki></code> e <code><nowiki>unsupported_feature</nowiki></code>. Il solver va eseguito solo dopo i filtri economici.
# '''Vincoli di relazione fra mani''' (es. "i due avversari hanno insieme 8+ carte di ♥", "atout 3-2 / 4-1 fra i difensori"): oggi si ottengono solo fissando le lunghezze di entrambi.
# '''Vincoli "morbidi"/pesati''': preferenze (peso 0–1) invece di filtri duri, per mani più naturali senza far esplodere il tasso di rifiuto.
# '''Carte o vincoli fissati dall'utente nel test''' (<code><nowiki>fixed</nowiki></code>, già in §5.6) con override temporanei.

== 2. Editor "potentissimo" (estende §8.4) ==

* '''Pannello Mani''' con le 4 posizioni, per ciascuna: barre min-max di lunghezze per seme, PO, griglia onori (deve / non deve / indifferente / "uno fra"), sempre sincronizzato col DSL testuale.
* '''Indicatori in tempo reale di fattibilità''': mentre si modifica, calcolo esatto/rapido di: somma minimi vs 13 carte, somma minimi PO vs 40, onori richiesti in conflitto (stessa carta a due mani), stima del tasso di successo (campionamento rapido a 200 tentativi con barra di avanzamento).
* '''Avvisi di sbilanciamento''' (punto chiave): avvisa se la distribuzione implicita dei PO fra le mani è anomala (es. una mano ≥ 22 e il compagno ≤ 6; un avversario a 0 con l'altro a ≥ 12; coppia fuori da 23–33 senza motivo) e proponi la correzione.
* '''Validazione live''' con <code><nowiki>shapeaction=validate</nowiki></code> (errori, avvisi, descrizioni, <code><nowiki>requires</nowiki></code>).
* '''Cronologia e confronto''': versioni salvate, diff DSL + diff statistiche fra due versioni.
* '''Esportazione''': "Copia per BridgePedia" (riga <code><nowiki>shape_constraints</nowiki></code>), JSON, link con seed.
* '''Modelli''' dalle convenzioni del wiki e dalle ricette (<code><nowiki>Progetto:BridgeShape Ricette DSL</nowiki></code>).

== 3. Laboratorio di test: capire come vengono generate le mani ==

Pulsante "Prova" → modale "Laboratorio" su N mani (default 1000, fino a 10.000, in background con
progresso, seed fisso riproducibile). Output:

# '''Esito del campionamento''': tasso di successo, tentativi medi/p95, tempo medio/p95, mani generate/rifiutate.
# '''Vincolo colpevole''': per ogni vincolo la % di scarti che provoca (quale pezzo dello scenario rende lo scenario lento o raro).
# '''Istogrammi per posizione''' (apertore/compagno/avv. sx/avv. dx): PO (0–37), lunghezza per seme, forma (classi), numero di assi/re/controlli, LTC. Con '''linee dei limiti richiesti''', media, mediana, percentili 5/95.
# '''Confronto con la base''': stessi istogrammi su un mazzo non vincolato, per vedere di quanto lo scenario distorce (misura per seme: variazione rispetto al caso).
# '''Frequenza onori per mano''': matrice posizione × carta (A K Q J T) con % di presenza, per scoprire concentrazioni (es. "ogni volta l'avversario sx ha l'Asso di ♦").
# '''Coppia''': istogramma PO della coppia, distribuzione dei fit (lunghezza d'atout combinata), spaccature degli atout dei difensori (3-2, 4-1, 5-0).
# '''Test di equità''': verifica che il campionamento sia uniforme sullo spazio dei vincoli (confronto tra due seed e tra metodo a rifiuto e costruttivo; chi² sulle frequenze di carte/posizioni). Segnala bias (es. carte basse sempre nella stessa mano).
# '''Se disponibile il solver''': percentuale di mani in cui il contratto dichiarato si realizza, e distribuzione delle prese; elenco delle mani contro-esempio apribili con un clic.
# '''Galleria''': le prime 10 mani, un clic per aprirne il perché (§5.4) e per "fissa e rigenera".
# '''Report esportabile''' (JSON + testo) da inviare a BridgePedia (§8.5), così gli editor del wiki tarano i vincoli. Accettiamo un campo <code><nowiki>labReport</nowiki></code> nello scenario problematico.

== 4. API richieste (aggiunte a <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code>) ==

* <code><nowiki>POST /api/deals/lab</nowiki></code> <code><nowiki>{source, dsl, scenario, n, seed, solver?: bool}</nowiki></code> → <code><nowiki>jobId</nowiki></code>; <code><nowiki>GET /api/deals/lab/{jobId}</nowiki></code> → <code><nowiki>{status, progress, success, attempts, timing, rejectBy[], histograms{}, honors{}, balance{warnings[]}, fairness{}, dd?{}}</nowiki></code>.
* <code><nowiki>POST /api/deals/check</nowiki></code> (già in §5.5) per le mani contro-esempio.
* Tag <code><nowiki>requires</nowiki></code>: <code><nowiki>lab</nowiki></code>, <code><nowiki>dd</nowiki></code>, <code><nowiki>spread</nowiki></code>, <code><nowiki>relations</nowiki></code>, <code><nowiki>soft</nowiki></code>.

== 5. Criteri di accettazione ==

# Per ogni scenario del wiki il laboratorio parte in < 2 s e fornisce i 10 punti sopra per N=1000 entro 30 s.
# Gli avvisi di sbilanciamento segnalano E2 di "Gioco di eliminazione" (24/5 PO) prima della generazione.
# Due esecuzioni con stesso seed danno identici istogrammi.
# Test di equità: nessuno scarto > 3σ rispetto all'attesa sui vincoli non esplicitati.

----

== Vedi anche ==
* [[Progetto:BridgeShape Motore e frontend]]
* [[Progetto:BridgeShape API]]
* [[Progetto:BridgeShape Ricette DSL]]
* [[Gioco di eliminazione]]

== Fonti ==
* Esperienza di scrittura degli scenari di Gioco di eliminazione (ProgettoBridge, Lezione 18) e specifica interna BridgeShape

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape API

2026-10-28T07:05:34Z

Lpala: Link a Editor e Laboratorio

Documentazione BridgeShape: [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]] · [[Progetto:BridgeShape Editor e Laboratorio|Editor e Laboratorio]]

= BridgeShape — API per Generatori di Smazzate =

Documentazione tecnica per chi sviluppa un generatore di smazzate di test
che legge i vincoli di distribuzione (shape constraints) dalle convenzioni
di BridgePedia.

== Panoramica ==

Ogni pagina wiki di convenzione su BridgePedia può definire nel template
<code><nowiki>{{Convenzione}}</nowiki></code> un campo <code><nowiki>shape_constraints</nowiki></code> che descrive, in un formato
DSL compatto, i vincoli di distribuzione delle mani dei 4 giocatori al tavolo.

L'estensione '''BridgeShape''' espone un'API REST/JSON per leggere questi
vincoli in modo strutturato.

----

== API Endpoint ==

<syntaxhighlight lang="text">
GET /api.php?action=bridgeshape&shapeaction=ACTION&format=json
</syntaxhighlight>

=== Azioni disponibili ===

{| class="wikitable"
! Azione
! Descrizione
! Parametri
|-
| <code><nowiki>get</nowiki></code>
| Vincoli per una singola convenzione
| <code><nowiki>pageid</nowiki></code> oppure <code><nowiki>title</nowiki></code>
|-
| <code><nowiki>list</nowiki></code>
| Elenco convenzioni con vincoli definiti
| —
|-
| <code><nowiki>listall</nowiki></code>
| Elenco tutte le convenzioni (con/senza vincoli)
| —
|-
| <code><nowiki>validate</nowiki></code>
| Valida una stringa DSL senza bisogno di una pagina wiki
| <code><nowiki>dsl</nowiki></code>
|}

=== Esempi di chiamata ===

<syntaxhighlight lang="bash">
# Per titolo pagina
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&title=Splinter&format=json"

# Per page ID
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&pageid=42&format=json"

# Elenco pagine con vincoli
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=list&format=json"

# Validare una stringa DSL
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=validate&dsl=opener+H:5%2B+hcp:12-21&format=json"
</syntaxhighlight>

----

== Formato risposta JSON ==

=== <code><nowiki>shapeaction=get</nowiki></code> ===

<syntaxhighlight lang="json">
{
"shapeconstraints": {
"pageId": 42,
"raw": "1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 // ...",
"scenarios": [
{
"label": "1H-4C",
"positions": {
"opener": {
"suits": {
"H": { "min": 5, "max": null }
},
"hcp": { "min": 12, "max": 21 }
},
"responder": {
"suits": {
"H": { "min": 4, "max": null },
"C": { "min": 0, "max": 1 }
},
"suit_hcp": {
"C": { "min": 0, "max": 0 }
},
"hcp": { "min": 10, "max": 15 }
}
},
"fit": []
}
]
}
}
</syntaxhighlight>

'''Descrizioni leggibili.''' Insieme a <code><nowiki>scenarios</nowiki></code>, <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono
<code><nowiki>descriptions</nowiki></code> (stesso ordine): per ogni scenario <code><nowiki>label</nowiki></code>, <code><nowiki>positions</nowiki></code>
(per posizione, elenco di frasi già tradotte, es. <code><nowiki>"♠: ha K J 10 (e non A Q 9)"</nowiki></code>),
<code><nowiki>positionLabels</nowiki></code> (nome del ruolo, es. "Attaccante" se la pagina ha <code><nowiki>shape_roles</nowiki></code>;
altrimenti "Apertore (chi usa la convenzione)", "Compagno", ...) e <code><nowiki>fit</nowiki></code>.
Parametro opzionale <code><nowiki>lang</nowiki></code> (it, en, ...; default lingua dell'API, di solito <code><nowiki>it</nowiki></code>).
Serve a mostrare nell'interfaccia di Play '''perché''' la mano è fatta così.
Nella posizione compare anche <code><nowiki>quiet: 1</nowiki></code> se è stata usata la macro <code><nowiki>quiet</nowiki></code>.

=== <code><nowiki>shapeaction=list</nowiki></code> ===

<syntaxhighlight lang="json">
{
"pages": [
{
"pageId": 42,
"title": "Splinter",
"scenarioCount": 6,
"labels": ["1H-4C", "1H-4D", "1H-4S", "1S-4C", "1S-4D", "1S-4H"]
},
{
"pageId": 15,
"title": "Stayman",
"scenarioCount": 2,
"labels": ["fit a cuori", "fit a picche"]
}
]
}
</syntaxhighlight>

----

== Formato DSL ==

Il DSL (Domain Specific Language) è la stringa scritta nel campo
<code><nowiki>shape_constraints</nowiki></code> del template wiki.

=== Struttura ===

<syntaxhighlight lang="text">
etichetta: vincoli posizione; vincoli posizione // etichetta: vincoli // ...
</syntaxhighlight>

* '''<code><nowiki>//</nowiki></code>''' separa gli scenari (il generatore ne sceglie uno random o li presenta all'utente)
* '''<code><nowiki>;</nowiki></code>''' separa le posizioni dentro uno scenario
* Ogni scenario ha un''''etichetta''' opzionale seguita da <code><nowiki>:</nowiki></code>
* Ogni posizione inizia col nome del ruolo, seguito da vincoli separati da spazi

=== Posizioni ===

{| class="wikitable"
! Nome
! Ruolo
|-
| <code><nowiki>opener</nowiki></code>
| Chi apre o fa la prima licita convenzionale
|-
| <code><nowiki>responder</nowiki></code>
| Il compagno dell'opener
|-
| <code><nowiki>opp1</nowiki></code>
| Avversario a sinistra dell'opener
|-
| <code><nowiki>opp2</nowiki></code>
| Avversario a destra dell'opener (compagno di opp1)
|}

=== Vincoli ===

==== Lunghezza seme (specifico) ====

<syntaxhighlight lang="text">
S:5+ — almeno 5 picche
H:0-1 — 0 o 1 cuori
D:3 — esattamente 3 quadri
C:2-5 — da 2 a 5 fiori
</syntaxhighlight>

Semi: <code><nowiki>S</nowiki></code> = Spades/Picche, <code><nowiki>H</nowiki></code> = Hearts/Cuori, <code><nowiki>D</nowiki></code> = Diamonds/Quadri, <code><nowiki>C</nowiki></code> = Clubs/Fiori

==== Lunghezza seme (wildcard) ====

<syntaxhighlight lang="text">
x:0-1 — un seme qualsiasi (tra quelli non specificati) con 0-1 carte
x:6+ — un seme non specificato con almeno 6 carte
</syntaxhighlight>

Il generatore sceglie casualmente quale seme assegnare a <code><nowiki>x</nowiki></code> tra quelli
non già vincolati esplicitamente (S/H/D/C).

==== HCP totali ====

<syntaxhighlight lang="text">
hcp:15-17 — da 15 a 17 punti onore
hcp:12+ — almeno 12 punti
hcp:0-7 — da 0 a 7 punti
</syntaxhighlight>

==== HCP nel seme (specifico) ====

<syntaxhighlight lang="text">
Shcp:3+ — almeno 3 HCP a picche
Chcp:0 — 0 HCP a fiori (nessun onore)
Hhcp:0-2 — da 0 a 2 HCP a cuori
</syntaxhighlight>

==== HCP nel seme (wildcard) ====

<syntaxhighlight lang="text">
xhcp:0 — 0 HCP nel seme wildcard (x)
xhcp:0-1 — 0-1 HCP nel seme x
</syntaxhighlight>

==== Shape class ====

<syntaxhighlight lang="text">
shape:balanced — distribuzione bilanciata (4333, 4432, 5332)
shape:semi_balanced — semibilanciata (5422, 6322)
shape:one_suiter — monocolore
shape:two_suiter — bicolore
shape:three_suiter — tricolore
shape:any — qualsiasi (default)
</syntaxhighlight>

==== Onori esatti in un seme (<code><nowiki>S=KJT</nowiki></code>) ====

<syntaxhighlight lang="text">
S=KJT — in picche ha K, J e 10; NON ha A, Q, 9 (le carte basse 8-2 completano)
S=KT9 — sequenza interna: K, 10, 9; NON ha A, Q, J
H=Q — a cuori ha la Q come unico onore tra A K Q J 10
D=x — nessun onore a quadri (solo carte basse)
</syntaxhighlight>

Le lettere ammesse sono <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>). La regola è: '''le carte elencate sono possedute, le altre tra A K Q J 10 9 NON lo sono'''; le carte
dall'8 in giù sono libere e riempiono fino alla lunghezza del seme. Serve a
descrivere attacchi (sequenza interrotta <code><nowiki>KJT</nowiki></code>, interna <code><nowiki>KT</nowiki></code>, sotto onore <code><nowiki>K</nowiki></code> o
<code><nowiki>Q</nowiki></code>) e le carte del compagno. Si combina con la lunghezza (<code><nowiki>S:5 S=KJT</nowiki></code>).

Nel JSON compare <code><nowiki>suit_cards</nowiki></code> nella posizione, es. <code><nowiki>{"S": "KJT", "H": ""}</nowiki></code>
(stringa vuota = nessuna carta alta). Il generatore deve:
* assegnare esattamente quegli onori alla mano e '''escluderli''' dalle altre mani del seme; gli onori non nominati da nessuna posizione sono distribuiti a caso, ma mai a una posizione con <code><nowiki>suit_cards</nowiki></code> per quel seme che non li elenca;
* rispettare comunque <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code> (la validazione segnala le contraddizioni, es. <code><nowiki>S=KQ Shcp:0-2</nowiki></code> o lo stesso onore a due mani).

==== Pattern di mano in un seme (<code><nowiki>S~...</nowiki></code>, stile regex) ====

Descrive '''l'intera mano in quel seme''', dall'alto in basso, come una piccola
espressione regolare ancorata (inizio e fine):

<syntaxhighlight lang="text">
S~AKQ. — A, K, Q + una carta bassa (4 carte)
S~A... — A + tre carte basse (4 carte)
S~AJT9. — A, J, 10, 9 + una bassa
S~AKQ.|A... — alternative: una OPPURE l'altra
S~[KQ]x{2,3} — K o Q (come unico onore) + 2 o 3 carte basse
S~KJT.* — K, J, 10 + qualunque numero di basse (anche zero)
</syntaxhighlight>

Elementi:
* '''Carte alte''' <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>), '''sempre in ordine decrescente''', ciascuna posseduta; quelle non nominate tra A K Q J 10 9 NON sono possedute.
* '''Classe''' <code><nowiki>[KQ]</nowiki></code> = una carta tra quelle (si espande in alternative).
* '''Carta bassa''' <code><nowiki>.</nowiki></code> (o <code><nowiki>x</nowiki></code>) = una carta qualsiasi tra 8 e 2; compare solo in fondo. Quantificatori: <code><nowiki>?</nowiki></code> (0-1), <code><nowiki>*</nowiki></code> (0 o più), <code><nowiki>+</nowiki></code> (1 o più), <code><nowiki>{n}</nowiki></code>, <code><nowiki>{n,m}</nowiki></code>. Più punti si sommano (<code><nowiki>...</nowiki></code> = tre basse).
* '''Alternative''' <code><nowiki>|</nowiki></code>: il generatore ne sceglie una a caso per ogni mano.

È la forma più espressiva di <code><nowiki>S=KJT</nowiki></code> (che resta valida): il pattern fissa anche
la lunghezza (<code><nowiki>S~A...</nowiki></code> = 4 carte). Se c'è anche <code><nowiki>S:N</nowiki></code> i due vincoli devono
essere compatibili (la validazione API segnala le incompatibilità).

Nel JSON compare <code><nowiki>suit_patterns</nowiki></code> nella posizione, già '''normalizzato''' (classi
espanse, quantificatori risolti), così il generatore non deve interpretare la
regex:

<syntaxhighlight lang="json">
"suit_patterns": {
"S": [
{"cards": "AKQ", "low_min": 1, "low_max": 1},
{"cards": "A", "low_min": 3, "low_max": 3}
]
}
</syntaxhighlight>

<code><nowiki>cards</nowiki></code> = carte alte possedute (ordine A K Q J T 9); <code><nowiki>low_min</nowiki></code>/<code><nowiki>low_max</nowiki></code> =
numero di carte basse (2-8), <code><nowiki>low_max: null</nowiki></code> = nessun limite. La lunghezza del
seme è <code><nowiki>len(cards) + numero di basse</nowiki></code>. Il generatore sceglie una alternativa e
rispetta anche <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code>. Gli onori di <code><nowiki>cards</nowiki></code> vanno esclusi dalle altre
mani; quelli non nominati nella mano vanno ad altri a caso.

==== Avversari "quiet" (nessun intervento) ====

<syntaxhighlight lang="text">
opp1 quiet — solo per opp1/opp2
opp2 quiet:0-7 — come quiet, ma con HCP personalizzati
</syntaxhighlight>

<code><nowiki>quiet</nowiki></code> è una '''macro espansa dall'API''': nel JSON non compare mai la parola
<code><nowiki>quiet</nowiki></code>, ma i vincoli già risolti. Chi legge l'API (il generatore) non deve
implementare nulla di nuovo. Si espande in:

<syntaxhighlight lang="text">
S:0-4 H:0-4 D:0-5 C:0-5 hcp:0-9 Shcp:0-3 Hhcp:0-3 Dhcp:0-4 Chcp:0-4
(con quiet:0-7 → hcp:0-7)
</syntaxhighlight>

Significato: gli avversari possono avere colori lunghi (così le mani sono
varie), ma poveri di onori e con pochi punti: nessun colore da 6+ carte
(niente apertura di sbarramento), nessun contro informativo, nessun intervento
naturale credibile. Le distribuzioni ammesse sono quindi molte, ma con punti
ridotti: il generatore ha meno margine sugli HCP della coppia dichiarante
(40 punti totali: apertore+rispondente restano sopra ~22).
I token espliciti scritti sulla stessa posizione '''sostituiscono''' i default,
in qualsiasi ordine: <code><nowiki>opp1 quiet S:0-4</nowiki></code> lascia le picche 0-4 e tiene il resto.
Su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> la macro viene ignorata.

==== Fit (vincolo cross-posizione) ====

<syntaxhighlight lang="text">
fit:H8+ — almeno 8 cuori totali tra i compagni
fit:S9+ — almeno 9 picche totali tra i compagni
fit:M8+ — almeno 8 carte in un seme maggiore (H o S)
fit:m8+ — almeno 8 carte in un seme minore (D o C)
fit:8+ — almeno 8 carte in un seme qualsiasi
</syntaxhighlight>

Il fit si applica tra '''compagni''':
* Se appare su <code><nowiki>opener</nowiki></code> o <code><nowiki>responder</nowiki></code>, o a livello di scenario → coppia dichiarante
* Se appare su <code><nowiki>opp1</nowiki></code> o <code><nowiki>opp2</nowiki></code> → coppia difensiva

=== Formato range ===

{| class="wikitable"
! Sintassi
! Significato
|-
| <code><nowiki>5+</nowiki></code>
| Almeno 5 (min=5, max=null)
|-
| <code><nowiki>0-1</nowiki></code>
| Da 0 a 1 (min=0, max=1)
|-
| <code><nowiki>3</nowiki></code>
| Esattamente 3 (min=3, max=3)
|-
| <code><nowiki>12-21</nowiki></code>
| Da 12 a 21 (min=12, max=21)
|}

Nella risposta JSON, <code><nowiki>max: null</nowiki></code> significa "nessun limite superiore".

=== Semi non menzionati ===

I semi '''non vincolati''' e non coperti da <code><nowiki>x:</nowiki></code> sono distribuiti '''casualmente'''
dal generatore, rispettando il vincolo che il totale delle carte per mano sia 13.

----

== DSL versione 2 (<code><nowiki>dslVersion: 2</nowiki></code>) ==

Tutto ciò che sopra resta valido e '''invariato''': i campi v1 hanno lo stesso significato di prima.
La v2 aggiunge sintassi nuova; '''ogni scenario ha nel JSON il campo <code><nowiki>requires</nowiki></code>''' (elenco di tag,
vuoto se usa solo la v1; vedi sotto) così un motore parziale può rifiutare uno scenario con un
errore esplicito invece di generare mani sbagliate. <code><nowiki>descriptions[].context</nowiki></code> è sempre presente
(array, eventualmente vuoto).
Le definizioni normative (cosa è una fermata, i punti totali, le perdenti...) e
l'architettura del motore sono in '''<code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code>'''.

=== Macro di scrittura (<code><nowiki>@NOME=v1,v2</nowiki></code>) — risolte dal parser, il motore non le vede ===

<syntaxhighlight lang="text">
@M=H,S 1${M}: opener ${M}:5+ hcp:12-21; responder ${M}:3+
</syntaxhighlight>
Genera due scenari (<code><nowiki>1H</nowiki></code>, <code><nowiki>1S</nowiki></code>) sostituendo <code><nowiki>${M}</nowiki></code> ovunque, etichetta compresa.
Più prefissi fanno il prodotto cartesiano (max 64 scenari): <code><nowiki>@M=H,S @N=15-17,12-14</nowiki></code>.
I valori possono essere intervalli (<code><nowiki>hcp:${N}</nowiki></code>): servono anche come parametri del
sistema (SA 15-17 contro 14-16).

=== Semi variabili <code><nowiki>$a $b $c $d</nowiki></code> ===

Un seme "da scegliere" condiviso da più posizioni dello stesso scenario. Ogni
variabile è un seme diverso dalle altre. Dominio dichiarato a livello di scenario
(prima delle posizioni):

<syntaxhighlight lang="text">
Landy: $a=M $b=any opener hcp:12-21 ; opp1 $a:5+ $b:4+ ; responder $a:0-2
</syntaxhighlight>
<code><nowiki>$a=M</nowiki></code> nobili, <code><nowiki>$a=m</nowiki></code> minori, <code><nowiki>$a=any</nowiki></code> (default) qualunque, <code><nowiki>$a=SH</nowiki></code> insieme esplicito.
Una variabile non dichiarata vale <code><nowiki>any</nowiki></code> (tutti i semi). Si usano al posto di <code><nowiki>S H D C</nowiki></code> in: <code><nowiki>$a:5+</nowiki></code> (lunghezza), <code><nowiki>$ahcp:</nowiki></code>, <code><nowiki>$a=KQ</nowiki></code>, <code><nowiki>$a~...</nowiki></code>,
<code><nowiki>stop:$a</nowiki></code>, <code><nowiki>has:$aQ</nowiki></code>, <code><nowiki>kc:$a3</nowiki></code>, confronti (<code><nowiki>$a>$b</nowiki></code>), <code><nowiki>longest:$a</nowiki></code>.
Differisce da <code><nowiki>x:</nowiki></code> (che vale per una sola posizione).
JSON: lo stesso dizionario <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, ... ma con chiave <code><nowiki>"$a"</nowiki></code>;
a livello di scenario <code><nowiki>"vars": {"$a": ["S","H"]}</nowiki></code>.

=== Controlli, carte chiave, carte precise ===

{| class="wikitable"
! Token
! Significato
|-
| <code><nowiki>aces:2</nowiki></code> <code><nowiki>kings:1-2</nowiki></code> <code><nowiki>queens:0</nowiki></code>
| numero di assi / re / dame nella mano
|-
| <code><nowiki>controls:6+</nowiki></code>
| controlli (A=2, K=1)
|-
| <code><nowiki>kc:H3</nowiki></code> <code><nowiki>kc:H2-3</nowiki></code> <code><nowiki>kc:$a3</nowiki></code>
| carte chiave con atout H: i 4 assi + il Re di H (0-5)
|-
| <code><nowiki>has:HQ</nowiki></code> <code><nowiki>has:S10</nowiki></code>
| possiede quella carta precisa
|-
| <code><nowiki>lacks:HQ</nowiki></code>
| NON possiede quella carta
|-
| <code><nowiki>stop:S</nowiki></code> <code><nowiki>nostop:S</nowiki></code>
| ha / non ha una fermata nel seme (definizione in SPEC)
|}

JSON: <code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code> (Range); <code><nowiki>keycards: {"H": Range}</nowiki></code>;
<code><nowiki>cards_held: ["HQ"]</nowiki></code>, <code><nowiki>cards_not_held: ["SK"]</nowiki></code>; <code><nowiki>stoppers: {"S": 1, "H": 0}</nowiki></code>
(1 = deve averla, 0 = non deve averla).

=== Punti e perdenti ===

<code><nowiki>tp:</nowiki></code> punti totali (PO + 1 per ogni carta oltre la quarta in ogni seme),
<code><nowiki>dp:</nowiki></code> punti distribuzione (PO + 3 chicane + 2 singolo + 1 doubleton),
<code><nowiki>ltc:</nowiki></code> perdenti (Losing Trick Count). A livello di scenario: <code><nowiki>pairhcp:25+</nowiki></code>
(PO della coppia dichiarante), <code><nowiki>defhcp:0-14</nowiki></code> (coppia avversaria), <code><nowiki>pairtp:26+</nowiki></code>.
JSON: <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code> (Range) nella posizione; <code><nowiki>pair_hcp: {"declarer": R, "defense": R}</nowiki></code>,
<code><nowiki>pair_tp: {"declarer": R}</nowiki></code> nello scenario.

=== Confronti tra semi e forme precise ===

<syntaxhighlight lang="text">
H>S H>=S H<S H<=S H==S $a>$b — confronto di lunghezze nella stessa mano
longest:H — H è tra i semi più lunghi (pari merito ammesso)
shape:5-4-x-x shape:5422 shape:54xx — lunghezze ordinate in modo decrescente, x = qualsiasi
shape:semi_balanced — 5422 e 6322 (si aggiunge alle classi esistenti)
</syntaxhighlight>
JSON: <code><nowiki>compare: [{"left":"H","op":">=","right":"S"}]</nowiki></code>, <code><nowiki>longest: ["H"]</nowiki></code>,
<code><nowiki>shape_pattern: "54xx"</nowiki></code>.

=== Alternative e negazioni nella stessa mano: <code><nowiki>any(...)</nowiki></code> e <code><nowiki>not(...)</nowiki></code> ===

<syntaxhighlight lang="text">
opener any(S:4+ hcp:12+, H:4+) not(D:6+)
</syntaxhighlight>
<code><nowiki>any(A, B)</nowiki></code>: la mano soddisfa '''almeno una''' delle alternative (separate da virgola;
ogni alternativa è una congiunzione di token). <code><nowiki>not(A, B)</nowiki></code>: la mano non soddisfa
'''nessuna''' delle alternative. Si possono scrivere più gruppi (si combinano in AND);
niente annidamenti.
JSON: <code><nowiki>any: [[altA, altB], ...]</nowiki></code> (lista di gruppi; ogni alternativa è un oggetto
con gli stessi campi di una posizione), <code><nowiki>not: [altA, altB]</nowiki></code>.

=== Contesto dello scenario ===

Token prima delle posizioni: <code><nowiki>weight:3</nowiki></code> (frequenza relativa, 1-100, default 1),
<code><nowiki>dealer:opener</nowiki></code>, <code><nowiki>vul:none|us|them|both</nowiki></code> (<code><nowiki>us</nowiki></code> = apertore+rispondente),
<code><nowiki>auction:1SA,P,2C,P</nowiki></code> (licite, notazione BridgeCards; SA = NT), <code><nowiki>contract:4H</nowiki></code>,
<code><nowiki>declarer:responder</nowiki></code>, <code><nowiki>lead:SK</nowiki></code>.
JSON: <code><nowiki>weight</nowiki></code> (int) e <code><nowiki>context: {"dealer":..,"vul":..,"auction":[..],"contract":"4H","declarer":..,"lead":"SK"}</nowiki></code>.
Il motore deve usare <code><nowiki>dealer</nowiki></code>/<code><nowiki>vul</nowiki></code> quando li espone (per la numerazione del tavolo) e,
se c'è <code><nowiki>lead</nowiki></code>, la carta deve stare nella mano dell'attaccante (a sinistra del
dichiarante) e rispettare i vincoli di quella mano.

=== Tag <code><nowiki>requires</nowiki></code> ===

<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>vars</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>card_presence</nowiki></code> (has/lacks),
<code><nowiki>controls</nowiki></code> (aces/kings/queens/controls/kc), <code><nowiki>points</nowiki></code> (tp/dp/ltc), <code><nowiki>pair_points</nowiki></code>,
<code><nowiki>compare</nowiki></code> (confronti, longest), <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>any_not</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>weight</nowiki></code>.
Le macro <code><nowiki>@</nowiki></code> e <code><nowiki>quiet</nowiki></code> non compaiono: sono già espanse.

=== Avvisi di parsing (<code><nowiki>warnings</nowiki></code>) ===

<code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono <code><nowiki>warnings</nowiki></code> quando un frammento del DSL non è stato
capito e quindi '''scartato''': nome di posizione sbagliato, token sconosciuto o con valore
non valido (<code><nowiki>aces:5</nowiki></code>, <code><nowiki>S=Kx</nowiki></code>, <code><nowiki>shape:4-5-x-x</nowiki></code>), token di scenario dopo le posizioni, posizione
definita due volte, <code><nowiki>quiet</nowiki></code> su opener/responder, gruppo <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> con alternative non
valide (in tal caso '''l'intero gruppo è ignorato''', mai applicato a metà). <code><nowiki>validate.valid</nowiki></code> è 1
solo se non ci sono né <code><nowiki>errors</nowiki></code> né <code><nowiki>warnings</nowiki></code>. Un motore non deve generare se ci sono
<code><nowiki>warnings</nowiki></code> o <code><nowiki>errors</nowiki></code>.

Limiti (oltre i quali il parser avvisa e tronca): 60.000 caratteri di input, 200 scenari, 6
prefissi <code><nowiki>@</nowiki></code>, 64 valori per macro, 64 scenari per espansione, 8 gruppi <code><nowiki>any/not</nowiki></code> e 16 alternative
per posizione. Le etichette non possono contenere <code><nowiki>:</nowiki></code>.

----

== Struttura JSON di uno scenario ==

<syntaxhighlight lang="typescript">
interface Scenario {
label: string; // Etichetta (es. "1H-4C"), vuota se non specificata
positions: {
[posName: string]: Position; // "opener", "responder", "opp1", "opp2"
};
fit: FitConstraint[]; // Vincoli di fit (array, può essere vuoto)
}

interface Position {
suit_patterns?: { // Pattern regex-like normalizzati: {"S":[{"cards":"AKQ","low_min":1,"low_max":1}]}
[suit: string]: { cards: string; low_min: number; low_max: number | null }[];
};
suit_cards?: { [suit: string]: string }; // Onori esatti, es. {"S":"KJT"}; "" = nessuna carta alta
suits?: { // Vincoli lunghezza seme (solo semi esplicitati)
[suit: string]: Range; // "S", "H", "D", "C"
};
hcp?: Range; // HCP totali
suit_hcp?: { // HCP per seme specifico
[suit: string]: Range;
};
x?: Range; // Lunghezza seme wildcard
x_hcp?: Range; // HCP seme wildcard
shape?: string; // Shape class: "balanced", "one_suiter", etc.
}

interface Range {
min: number;
max: number | null; // null = nessun limite superiore
}

interface FitConstraint {
suit: string | null; // "S","H","D","C" o null
suit_class: string | null; // "major", "minor" o null
min: number; // Numero minimo di carte (es. 8)
pair: string; // "declarer" o "defense"
}
</syntaxhighlight>

----

== Logica per il generatore ==

=== Algoritmo base ===

Per ogni scenario:

# '''Scegli lo scenario''': random tra quelli disponibili, oppure lascia scegliere all'utente
# '''Risolvi wildcard''':
#* Se una posizione ha <code><nowiki>x:</nowiki></code>, scegli un seme casuale tra quelli non esplicitamente vincolati
#* <code><nowiki>xhcp:</nowiki></code> si applica allo stesso seme scelto per <code><nowiki>x:</nowiki></code>
# '''Risolvi fit''':
#* Se <code><nowiki>fit.suit</nowiki></code> è specificato, entrambi i compagni devono avere un totale >= <code><nowiki>fit.min</nowiki></code> in quel seme
#* Se <code><nowiki>fit.suit_class</nowiki></code> è "major", scegli tra H e S; se "minor", tra D e C
#* Se entrambi sono null, scegli un seme qualsiasi
#* <code><nowiki>fit.pair</nowiki></code> indica quale coppia: "declarer" (opener+responder) o "defense" (opp1+opp2)
# '''Genera le mani''':
#* Per ogni posizione, genera una mano che rispetti tutti i vincoli
#* I semi senza vincoli vengono riempiti casualmente
#* Il totale delle carte per mano deve essere esattamente 13
#* Il totale delle carte per seme (tutte e 4 le mani) deve essere esattamente 13
# '''Posizioni non menzionate''': se uno scenario non menziona <code><nowiki>opp1</nowiki></code>/<code><nowiki>opp2</nowiki></code>, distribuisci le carte rimanenti casualmente tra gli avversari

=== Priorità dei vincoli ===

# Vincoli di fit (cross-posizione) — determinano la distribuzione di base
# Vincoli di seme specifico (S:, H:, D:, C:) — limitano i singoli semi
# Vincoli wildcard (x:) — dopo aver fissato i semi specifici
# Vincoli HCP (hcp:, Shcp:, xhcp:) — filtro finale
# Shape class (shape:) — validazione della forma complessiva

=== Gestione di <code><nowiki>max: null</nowiki></code> ===

Quando <code><nowiki>max</nowiki></code> è <code><nowiki>null</nowiki></code>, non c'è limite superiore esplicito. I limiti fisici
del bridge si applicano comunque:
* Massimo 13 carte per seme (tutte e 4 le mani)
* Massimo 13 carte per mano
* Massimo 10 HCP per seme (A+K+Q+J = 4+3+2+1)
* Massimo 37 HCP per mano (raro ma teoricamente possibile con tutti gli onori)

----

== Esempi completi ==

=== Splinter (tutti gli scenari specifici) ===

DSL nel template wiki:
<syntaxhighlight lang="text">
1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 //
1H-4D: opener H:5+ hcp:12-21; responder H:4+ D:0-1 Dhcp:0 hcp:10-15 //
1H-4S: opener H:5+ hcp:12-21; responder H:4+ S:0-1 Shcp:0 hcp:10-15 //
1S-4C: opener S:5+ hcp:12-21; responder S:4+ C:0-1 Chcp:0 hcp:10-15 //
1S-4D: opener S:5+ hcp:12-21; responder S:4+ D:0-1 Dhcp:0 hcp:10-15 //
1S-4H: opener S:5+ hcp:12-21; responder S:4+ H:0-1 Hhcp:0 hcp:10-15
</syntaxhighlight>

=== Splinter (compatto con fit e wildcard) ===

<syntaxhighlight lang="text">
dopo 1H: fit:H8+ opener H:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15 //
dopo 1S: fit:S8+ opener S:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15
</syntaxhighlight>

=== Stayman ===

<syntaxhighlight lang="text">
fit a cuori: fit:H8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder H:4+ hcp:8+ //
fit a picche: fit:S8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder S:4+ hcp:8+
</syntaxhighlight>

=== Contro informativo ===

<syntaxhighlight lang="text">
base: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; responder hcp:0-8 //
con intervento: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; opp2 hcp:8+ x:5+
</syntaxhighlight>

=== Preempt 3-a-livello ===

<syntaxhighlight lang="text">
opener H:7+ x:0-1 hcp:5-10
</syntaxhighlight>

=== Overcall con fit avversari ===

<syntaxhighlight lang="text">
overcall semplice: opener hcp:12-21 x:5+; opp1 hcp:10+ x:5+; opp2 fit:8+ //
con barrage: opener hcp:12-21 x:5+; opp1 hcp:6-10 x:6+; opp2 fit:9+
</syntaxhighlight>

----

== Note implementative ==

* L'API è read-only, non richiede token CSRF
* L'accesso anonimo è abilitato di default (<code><nowiki>BridgeShapeAllowAnonymous: true</nowiki></code>) perché i dati sono pubblici e i tool esterni ne hanno bisogno
* Il campo <code><nowiki>raw</nowiki></code> nella risposta <code><nowiki>get</nowiki></code> contiene la stringa DSL originale, utile per debug
* L'azione <code><nowiki>validate</nowiki></code> permette di testare stringhe DSL senza creare pagine wiki
* I calcoli HCP usano la scala standard: A=4, K=3, Q=2, J=1

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Motore e frontend

2026-10-28T07:05:32Z

Lpala: Link a Editor e Laboratorio

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]] · [[Progetto:BridgeShape Editor e Laboratorio|Editor e Laboratorio]]

= BridgeShape — Specifica del motore di smazzate e del frontend (per Play) =

Destinatario: il team/sessione di '''Play''' (generatore di smazzate e relativo frontend).
Obiettivo: realizzare un '''motore completo''' che generi mani per ''qualsiasi'' scenario
descritto nelle pagine di BridgePedia, e un '''frontend''' per consultare gli scenari,
generare, creare e gestire smazzate.

Documenti collegati (leggere in quest'ordine):

# <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code> — riferimento della sintassi (DSL v1 + v2) e del JSON dell'API.
# '''questo file''' — semantica normativa, architettura del motore, test di conformità, specifica del frontend, piano di consegna.
# Wiki: <code><nowiki>Progetto:BridgeShape API</nowiki></code>; le pagine di convenzione con <code><nowiki>shape_constraints</nowiki></code> (elenco: <code><nowiki>GET /api.php?action=bridgeshape&shapeaction=list</nowiki></code>).

Fonte di verità del contratto: l'API <code><nowiki>action=bridgeshape</nowiki></code> di https://bridgepedia.it.
Se questo documento e l'API divergono vale l'API; segnalatelo a BridgePedia.

----

== 1. Contratto, versioni e compatibilità ==

{| class="wikitable"
! Elemento
! Dove
! Uso
|-
| <code><nowiki>dslVersion</nowiki></code>
| risposta di <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code>
| oggi <code><nowiki>2</nowiki></code>. Cambia solo con modifiche non retrocompatibili
|-
| <code><nowiki>scenarios[].requires</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| tag delle capacità richieste dallo scenario (§1.1)
|-
| <code><nowiki>errors</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| contraddizioni semantiche: '''non generare'''
|-
| <code><nowiki>warnings</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| frammenti del DSL scartati dal parser: '''non generare'''
|-
| <code><nowiki>descriptions</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| testo leggibile per scenario, tradotto (<code><nowiki>lang=it|en|...</nowiki></code>)
|-
| <code><nowiki>valid</nowiki></code>
| <code><nowiki>validate</nowiki></code>
| 1/0
|}

Regole di compatibilità:

* I campi nuovi compaiono '''solo se usati''': un motore v1 continua a funzionare sulle pagine v1.
* Campi sconosciuti: ignorarli '''non''' è permesso se compaiono in <code><nowiki>requires</nowiki></code>. Se il motore non supporta un tag di <code><nowiki>requires</nowiki></code>, deve rifiutare lo scenario con codice <code><nowiki>unsupported_feature</nowiki></code> (e nome del tag) e il frontend deve mostrarlo come "non ancora generabile", non nasconderlo.
* Il booleano nel JSON è sempre <code><nowiki>1</nowiki></code>/<code><nowiki>0</nowiki></code> (MediaWiki rimuove i <code><nowiki>false</nowiki></code>).
* Tutte le chiavi di seme sono <code><nowiki>S H D C</nowiki></code> oppure una variabile <code><nowiki>"$a".."$d"</nowiki></code>.

=== 1.1 Tag <code><nowiki>requires</nowiki></code> ===

{| class="wikitable"
! Tag
! Costrutti
! Impatto sul motore
|-
| <code><nowiki>suit_cards</nowiki></code>
| <code><nowiki>S=KJT</nowiki></code>
| assegnazione di onori precisi
|-
| <code><nowiki>suit_patterns</nowiki></code>
| <code><nowiki>S~AKQ.|A...</nowiki></code>
| alternative di mano nel seme
|-
| <code><nowiki>vars</nowiki></code>
| <code><nowiki>$a $b</nowiki></code>, <code><nowiki>vars</nowiki></code>
| seme scelto a runtime, condiviso tra posizioni
|-
| <code><nowiki>stoppers</nowiki></code>
| <code><nowiki>stop:S</nowiki></code>
| filtro/vincolo sulla mano
|-
| <code><nowiki>card_presence</nowiki></code>
| <code><nowiki>has:HQ</nowiki></code>, <code><nowiki>lacks:SK</nowiki></code>
| carte fisse
|-
| <code><nowiki>controls</nowiki></code>
| <code><nowiki>aces kings queens controls kc</nowiki></code>
| conteggi di onori
|-
| <code><nowiki>points</nowiki></code>
| <code><nowiki>tp dp ltc</nowiki></code>
| punteggi derivati
|-
| <code><nowiki>pair_points</nowiki></code>
| <code><nowiki>pairhcp pairtp defhcp</nowiki></code>
| vincolo sulla coppia
|-
| <code><nowiki>compare</nowiki></code>
| <code><nowiki>H>S</nowiki></code>, <code><nowiki>longest:</nowiki></code>
| relazioni tra lunghezze
|-
| <code><nowiki>shape_pattern</nowiki></code>
| <code><nowiki>shape:5-4-x-x</nowiki></code>
| forma ordinata
|-
| <code><nowiki>any_not</nowiki></code>
| <code><nowiki>any(...)</nowiki></code>, <code><nowiki>not(...)</nowiki></code>
| disgiunzioni e negazioni
|-
| <code><nowiki>context</nowiki></code>
| <code><nowiki>dealer vul auction contract declarer lead</nowiki></code>
| metadati e carta d'attacco
|-
| <code><nowiki>weight</nowiki></code>
| <code><nowiki>weight:N</nowiki></code>
| scelta ponderata dello scenario
|}

Le macro <code><nowiki>@M=H,S</nowiki></code> e <code><nowiki>quiet</nowiki></code> sono già espanse dal parser (non compaiono mai).

=== 1.2 Endpoint consigliati lato Play ===

Il motore deve esporre (nomi indicativi; l'importante è la semantica):

<syntaxhighlight lang="text">
POST /api/deals/generate
{
"source": { "page": "Splinter", "scenario": "1H-4C" } // oppure { "dsl": "..." }
| { "page": "Splinter" }, // scenario scelto per peso
"count": 10, // 1..100
"seed": 12345, // opzionale, riproducibilità
"fixed": { "opener": "SAK2.H.D.C", "responder": "..." }, // carte/mani già fissate (§5.6)
"lang": "it"
}
→ 200 { "seed":..., "deals":[ {
"scenario": "1H-4C", "index": 0,
"dealer": "opener", "vul": "none",
"hands": { "opener":"AK2.QJ53.K84.T65", "responder":"...", "opp1":"...", "opp2":"..." },
"bindings": { "$a": "H", "x:opener": "D" }, // come sono state risolte variabili e jolly
"pbn": "[Deal \"N:...\"]", "lin": "...",
"explanation": { "opener": ["♥: 5+ carte", ...], ... }, // dalle descriptions
"stats": { "attempts": 412, "ms": 38 }
} ] }
→ 422 { "code": "...", "reasons": [ {"code":"...", "position":"opp1", "detail":"..."} ] }
GET /api/deals/capabilities → { "dslVersion": 2, "supports": ["suit_cards", ...] }
</syntaxhighlight>

Posizioni → sedi: <code><nowiki>opener</nowiki></code> = Nord per default; il motore ruota in base a <code><nowiki>context.dealer</nowiki></code> solo
per la numerazione/PBN; i vincoli restano sempre in termini di ruoli (<code><nowiki>opener</nowiki></code>, <code><nowiki>responder</nowiki></code>,
<code><nowiki>opp1</nowiki></code> = a sinistra dell'apertore, <code><nowiki>opp2</nowiki></code> = a destra).

----

== 2. Definizioni normative ==

Il motore e il frontend devono usare '''esattamente''' queste definizioni (le descrizioni in
italiano dell'API le presuppongono).

* '''Carte''': A K Q J 10 9 8 7 6 5 4 3 2. Nei vincoli <code><nowiki>T</nowiki></code> = 10. "Carte basse" = 8..2.
* '''PO / HCP''': A=4, K=3, Q=2, J=1. <code><nowiki>Shcp</nowiki></code> ecc. = PO nel solo seme.
* '''Posizioni e coppie''': coppia dichiarante = <code><nowiki>opener</nowiki></code>+<code><nowiki>responder</nowiki></code>; difesa = <code><nowiki>opp1</nowiki></code>+<code><nowiki>opp2</nowiki></code>. Senso di gioco: opener → opp1 → responder → opp2 (orario). Lo stesso per l'attaccante: siede a sinistra del dichiarante (<code><nowiki>declarer</nowiki></code> = opener → attacca opp1; responder → opp2; opp1 → responder; opp2 → opener).
* '''Forma ordinata''': le 4 lunghezze in ordine decrescente (es. 5431).
* '''Classi di forma''' (possono sovrapporsi; le pagine oggi usano solo <code><nowiki>balanced</nowiki></code>):
** <code><nowiki>balanced</nowiki></code>: 4333, 4432, 5332.
** <code><nowiki>semi_balanced</nowiki></code>: 5422, 6322.
** <code><nowiki>one_suiter</nowiki></code>: seme più lungo ≥ 6 e secondo ≤ 3.
** <code><nowiki>two_suiter</nowiki></code>: i due semi più lunghi hanno entrambi ≥ 4 carte e insieme ≥ 9 (5-4, 6-4, 5-5, ...).
** <code><nowiki>three_suiter</nowiki></code>: tre semi ≥ 4 (4441, 5440, 4450...).
** <code><nowiki>any</nowiki></code>: nessun vincolo. Se la vostra implementazione attuale differisce, allineatela a questa o segnalate la differenza.
* '''<code><nowiki>shape_pattern</nowiki></code>''' (<code><nowiki>54xx</nowiki></code>): la forma ordinata deve corrispondere cifra per cifra; <code><nowiki>x</nowiki></code> = qualsiasi.
* '''<code><nowiki>longest:H</nowiki></code>''': la lunghezza di H è ≥ di ogni altro seme (pari merito ammesso).
* '''Confronti''' <code><nowiki>A op B</nowiki></code>: sulle lunghezze dei due semi nella stessa mano; <code><nowiki>==</nowiki></code> uguali.
* '''Controlli''': A=2, K=1 (le dame non contano). <code><nowiki>controls:6+</nowiki></code> somma sulla mano.
* '''Carte chiave per l'atout T''' (<code><nowiki>kc:T</nowiki></code>): numero di assi (0-4) + 1 se possiede il Re di T. Valori 0-5. La Dama di atout si esprime con <code><nowiki>has:TQ</nowiki></code>.
* '''Fermata''' nel seme X (<code><nowiki>stop:X</nowiki></code>): possiede almeno una tra: A; Kx (Re con ≥ 2 carte nel seme); Qxx (Dama con ≥ 3); Jxxx (Fante con ≥ 4). <code><nowiki>nostop:X</nowiki></code> = nessuna di queste.
* '''Punti totali <code><nowiki>tp</nowiki></code>''': PO + (per ogni seme, <code><nowiki>max(0, lunghezza − 4)</nowiki></code>).
* '''Punti distribuzione <code><nowiki>dp</nowiki></code>''': PO + 3 per ogni chicane + 2 per ogni singolo + 1 per ogni doubleton.
* '''Perdenti <code><nowiki>ltc</nowiki></code>''' (Losing Trick Count classico): per ogni seme con <code><nowiki>n</nowiki></code> carte, <code><nowiki>m = min(n,3)</nowiki></code>; perdenti del seme = <code><nowiki>m − [A] − [K e n≥2] − [Q e n≥3]</nowiki></code>; somma sui 4 semi (seme vuoto = 0). Tabella di controllo: x=1, A=0, K=1, Q=1; xx=2, Ax=1, Kx=1, Qx=2, AK=0, AQ=1, KQ=1; AKQ=0, AKx=1, AQx=1, KQx=1, Axx=2, Kxx=2, Qxx=2, xxx=3. (Correzione: la formula precedente <code><nowiki>m − #A,K,Q</nowiki></code> contava anche K e Q secchi o Q doppia.)
* '''<code><nowiki>S=KJT</nowiki></code>''' (<code><nowiki>suit_cards</nowiki></code>): tra A K Q J 10 9 possiede ''esattamente'' quelle elencate; 8..2 liberi. Stringa vuota = nessuna carta alta. Gli onori elencati sono esclusi dalle altre mani solo per quel che riguarda la proprietà: ogni carta ha un unico proprietario.
* '''<code><nowiki>S~...</nowiki></code>''' (<code><nowiki>suit_patterns</nowiki></code>): una sola alternativa (scelta a caso, uniformemente tra quelle compatibili con gli altri vincoli) descrive tutta la mano in quel seme: <code><nowiki>cards</nowiki></code> + tra <code><nowiki>low_min</nowiki></code> e <code><nowiki>low_max</nowiki></code> carte basse (<code><nowiki>low_max: null</nowiki></code> = illimitato, ma ≤ 13 − len(cards)).
* '''<code><nowiki>x:</nowiki></code>''' (jolly di posizione): un seme scelto a caso tra quelli ''non'' vincolati esplicitamente in quella posizione. Dentro una foglia di <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> il jolly vede '''solo i semi nominati nella foglia'''; un seme nominato soltanto in <code><nowiki>fit</nowiki></code>, confronti o <code><nowiki>longest:</nowiki></code> non è escluso da <code><nowiki>x</nowiki></code>; <code><nowiki>xhcp:</nowiki></code> si riferisce allo stesso seme. Il jolly '''non''' è condiviso con altre posizioni.
* '''Variabili <code><nowiki>$a..$d</nowiki></code>''': a inizio generazione ogni variabile usata riceve un seme dal proprio dominio (<code><nowiki>vars</nowiki></code>, default tutti e quattro). Variabili diverse hanno '''semi diversi'''; una variabile non dichiarata ha dominio completo. Una variabile può coincidere con un seme nominato esplicitamente (<code><nowiki>$a</nowiki></code> e <code><nowiki>H</nowiki></code>): se non è voluto, restringere il dominio (<code><nowiki>$a=SD</nowiki></code>). La scelta è uniforme tra le assegnazioni che rendono lo scenario soddisfacibile.
* '''<code><nowiki>fit</nowiki></code>''': somma delle lunghezze dei due compagni nel seme (o in qualunque seme del tipo <code><nowiki>major</nowiki></code>/ <code><nowiki>minor</nowiki></code>/<code><nowiki>any</nowiki></code>, a scelta del motore, uniformemente tra i semi che soddisfano il vincolo).
* '''<code><nowiki>any(A,B)</nowiki></code>''': la mano soddisfa almeno una alternativa. '''<code><nowiki>not(A,B)</nowiki></code>''': non ne soddisfa nessuna. Più gruppi → AND. Dentro <code><nowiki>A</nowiki></code>,<code><nowiki>B</nowiki></code> valgono gli stessi campi di una posizione (senza <code><nowiki>any/not/fit</nowiki></code>).
* '''<code><nowiki>pair_hcp.declarer</nowiki></code>''' = PO(opener)+PO(responder); <code><nowiki>defense</nowiki></code> = PO(opp1)+PO(opp2). <code><nowiki>pair_tp</nowiki></code>: somma <code><nowiki>tp</nowiki></code>.
* '''Posizioni non nominate''': ricevono le carte rimanenti a caso (nessun vincolo); non applicare <code><nowiki>quiet</nowiki></code> implicito.
* '''<code><nowiki>weight</nowiki></code>''': probabilità relativa di scelta dello scenario quando non è scelto dall'utente (default 1). Non influenza la generazione dentro lo scenario.
* '''<code><nowiki>context</nowiki></code>''': metadati. <code><nowiki>dealer</nowiki></code> e <code><nowiki>vul</nowiki></code> (<code><nowiki>us</nowiki></code> = coppia dichiarante) vanno riportati nell'output (PBN/LIN) e mostrati. <code><nowiki>auction</nowiki></code> è la sequenza da mostrare/verificare (notazione BridgeCards: <code><nowiki>P</nowiki></code>, <code><nowiki>X</nowiki></code>, <code><nowiki>XX</nowiki></code>, <code><nowiki>1NT</nowiki></code>...). <code><nowiki>contract</nowiki></code>/<code><nowiki>declarer</nowiki></code>/<code><nowiki>lead</nowiki></code>: vedi §5.7.

----

== 3. Architettura consigliata del motore ==

Pipeline per ogni mano richiesta:

<syntaxhighlight lang="text">
parse risposta API → controllo requires/errors/warnings
→ scelta scenario (utente | peso)
→ ASSEGNAZIONE SIMBOLICA : variabili $a.., jolly x:, fit, alternative any()/S~, pattern di forma
→ MATRICE DELLE LUNGHEZZE : 4 posizioni × 4 semi (somme 13 per riga e per colonna)
→ ASSEGNAZIONE DELLE CARTE : carte fissate/vincolate, poi resto casuale
→ RIPARAZIONE PUNTI : scambi mirati per entrare negli intervalli PO/tp/dp/ltc/controlli
→ VERIFICA FINALE : valutazione indipendente di TUTTI i vincoli sulla smazzata completa
→ output + spiegazione
</syntaxhighlight>

Punti chiave:

# '''Verifica finale indipendente''' (il "giudice"): una funzione pura <code><nowiki>satisfies(deal, scenario, bindings)</nowiki></code> che valuta ogni vincolo dalle definizioni di §2. Ogni smazzata emessa deve passarla. Questa funzione è anche la base dei test e del pulsante "verifica" del frontend.
# '''Costruzione, non solo scarto.''' Il rejection sampling puro non regge scenari stretti (es. Gran rever nel Multirever, <code><nowiki>quiet</nowiki></code> con coppia 25+ PO). Costruire prima la matrice delle lunghezze con propagazione dei vincoli (backtracking con limiti per riga/colonna), poi assegnare le carte onore per posizione secondo <code><nowiki>suit_cards</nowiki></code>/<code><nowiki>suit_patterns</nowiki></code>/<code><nowiki>has</nowiki></code>/<code><nowiki>lacks</nowiki></code>/<code><nowiki>aces</nowiki></code>..., infine le basse.
# '''Riparazione PO''': dopo l'assegnazione, se i PO (o <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, controlli, <code><nowiki>pair_*</nowiki></code>) sono fuori intervallo, scambiare due carte tra due mani preservando lunghezze e vincoli ''rigidi'' (carte fissate, pattern). Ricerca locale con budget; poi nuovo tentativo dall'inizio.
# '''Uniformità''': l'obiettivo è una distribuzione quasi uniforme tra le smazzate che soddisfano lo scenario. Le euristiche di costruzione introducono distorsioni: misuratele (§7.3) e non dichiarate "uniformi" se non lo sono.
# '''Budget e fallimenti''': limite di tempo (oggi 2,5 s CPU/mano), massimo tentativi, e diagnosi. Su fallimento restituire 422 con i <code><nowiki>reasons</nowiki></code> di §6, mai una smazzata che viola i vincoli.
# '''Riproducibilità''': stesso <code><nowiki>seed</nowiki></code> + stessa versione del DSL → stessa smazzata. Salvare nel record <code><nowiki>seed</nowiki></code>, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>source.page</nowiki></code>, <code><nowiki>revid</nowiki></code> della pagina se disponibile.
# '''Concorrenza e cache''': cache del JSON dell'API per pagina con TTL breve (60 s) e rivalidazione sulla <code><nowiki>list</nowiki></code>; mai servire DSL non validato.

=== 3.1 Ordine di risoluzione dei vincoli ===

# Variabili <code><nowiki>$a..</nowiki></code>, jolly <code><nowiki>x:</nowiki></code>, <code><nowiki>fit</nowiki></code> (decidono ''quali'' semi).
# Alternative: scegliere un ramo per ogni <code><nowiki>any()</nowiki></code> e ogni <code><nowiki>S~</nowiki></code> (escludendo i rami impossibili con i vincoli già noti); applicare <code><nowiki>not()</nowiki></code> come vincoli di esclusione.
# Lunghezze (<code><nowiki>suits</nowiki></code>, <code><nowiki>compare</nowiki></code>, <code><nowiki>longest</nowiki></code>, <code><nowiki>shape</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>fit</nowiki></code>).
# Carte precise (<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>cards_held/not_held</nowiki></code>, <code><nowiki>lead</nowiki></code>).
# Conteggi (<code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code>, <code><nowiki>keycards</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>).
# Punteggi derivati (<code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, <code><nowiki>pair_*</nowiki></code>) e <code><nowiki>stoppers</nowiki></code>.
# Verifica finale.

Un vincolo è "rigido" se riguarda carte/lunghezze fissate (1-4); "morbido" se si ripara per scambio (5-6).

----

== 4. Semantica delle combinazioni delicate ==

* <code><nowiki>quiet</nowiki></code> è già espanso in <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>: nessun trattamento speciale (il campo <code><nowiki>quiet: 1</nowiki></code> serve solo alla descrizione). Una difesa quiet '''riduce''' il margine PO per la coppia dichiarante: verificare la compatibilità prima di costruire (<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>...).
* <code><nowiki>S=...</nowiki></code> / <code><nowiki>S~...</nowiki></code> + <code><nowiki>S:N</nowiki></code> + <code><nowiki>Shcp</nowiki></code>: devono essere coerenti; l'API segnala le contraddizioni evidenti.
* Una carta (<code><nowiki>has:HQ</nowiki></code>) può comparire in una sola posizione; due posizioni con la stessa carta sono un errore di validazione, non un caso da risolvere a caso.
* <code><nowiki>any()</nowiki></code> dentro una posizione con variabili: le variabili si legano '''prima''', poi si sceglie il ramo.
* <code><nowiki>not()</nowiki></code> con <code><nowiki>S~</nowiki></code>: escludere dall'insieme di alternative, non solo filtrare a posteriori.
* <code><nowiki>longest:</nowiki></code> e <code><nowiki>compare</nowiki></code> valgono sulle lunghezze finali (dopo il bind delle variabili).
* <code><nowiki>context.lead</nowiki></code> (<code><nowiki>SK</nowiki></code>): la carta deve stare nella mano dell'attaccante (§2) e quella mano deve soddisfare i suoi vincoli (es. se ha <code><nowiki>S=KJT</nowiki></code>, <code><nowiki>lead:SJ</nowiki></code> è coerente, <code><nowiki>lead:SQ</nowiki></code> no).

=== Chiarimenti (concordati con Play) ===

* '''<code><nowiki>context.auction</nowiki></code>''': la sequenza parte dal '''mazziere''' (<code><nowiki>dealer</nowiki></code>); il primo token è la sua chiamata. Se <code><nowiki>dealer</nowiki></code> manca, l'asta è solo descrittiva e non si verifica nulla. Nella v2 l'asta e <code><nowiki>contract</nowiki></code> sono '''informativi''': il motore non deve ricavarne vincoli sulle mani.
* '''<code><nowiki>declarer</nowiki></code>''': non deve discendere dall'asta (non verificata). Serve a stabilire chi attacca (vedi §2) e quindi a validare <code><nowiki>lead</nowiki></code>.
* '''<code><nowiki>errors</nowiki></code>''': array di '''stringhe''' <code><nowiki>"<etichetta scenario o 'scenario #N'>: <messaggio in inglese>"</nowiki></code>, senza codici né struttura. Il motore li riporta così come sono (codice proprio <code><nowiki>dsl_errors</nowiki></code>, §6). Un formato strutturato (<code><nowiki>code</nowiki></code>, <code><nowiki>scenario</nowiki></code>, <code><nowiki>position</nowiki></code>) è una possibile evoluzione: lo si introdurrebbe come campo nuovo <code><nowiki>errorDetails</nowiki></code>, senza toccare <code><nowiki>errors</nowiki></code>.
* '''<code><nowiki>descriptions</nowiki></code>''': oggi un elemento per scenario con <code><nowiki>positions</nowiki></code> (testo per posizione) e <code><nowiki>context</nowiki></code>; '''non esiste un id per singolo vincolo'''. Se il frontend lo richiede, si aggiungerà un campo additivo (da concordare, §11).
* '''«Uniforme»''' (variabili, jolly, <code><nowiki>fit</nowiki></code>): tra le assegnazioni di semi che rendono lo scenario soddisfacibile, ciascuna ha uguale probabilità (a meno di tolleranza statistica nei test: ±5 % su 1000 estrazioni per due valori, vedi caso 3). Non implica uniformità sulle carte o sulle mani.

----

== 5. Funzionalità del motore (elenco completo da realizzare) ==

=== 5.1 Core (parità v1) — già in produzione, da conservare ===
Lunghezze, PO totali/per seme, <code><nowiki>x:</nowiki></code>, <code><nowiki>shape:</nowiki></code>, <code><nowiki>fit</nowiki></code>, <code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>quiet</nowiki></code>
(espanso), 422 con ragioni, tetto 2,5 s.

=== 5.2 Nuove funzioni DSL v2 ===
Tutte le righe di §1.1. Priorità di consegna in §9.

=== 5.3 Mani multiple e serie ===
<code><nowiki>count</nowiki></code> ≤ 100 per richiesta; opzione <code><nowiki>distinct: true</nowiki></code> (nessuna mano duplicata nella serie);
opzione <code><nowiki>balance: "round_robin" | "weighted"</nowiki></code> per distribuire gli scenari della stessa convenzione.

=== 5.4 Spiegazione per mano ===
Per ogni smazzata: per posizione, elenco dei vincoli con esito (✓) e valore effettivo
("♥: 5 carte, richiesto 5+"), e i '''binding''' (<code><nowiki>$a = ♥</nowiki></code>, <code><nowiki>x di opener = ♦</nowiki></code>). Serve al frontend.

=== 5.5 Verifica di una smazzata data ===
<code><nowiki>POST /api/deals/check</nowiki></code> con quattro mani e una <code><nowiki>source</nowiki></code> → elenco di vincoli soddisfatti/violati.
Usa lo stesso giudice del §3. Serve a: smazzate inserite a mano, correzione in aula, test.

=== 5.6 Mani parzialmente fissate (<code><nowiki>fixed</nowiki></code>) ===
Accettare mani complete o parziali (<code><nowiki>"opener": "SAK2."</nowiki></code>, o carte singole) e completare il resto
rispettando lo scenario. Se impossibile → 422 <code><nowiki>fixed_cards_conflict</nowiki></code>.

=== 5.7 Contesto di gioco della carta ===
<code><nowiki>contract</nowiki></code>, <code><nowiki>declarer</nowiki></code>, <code><nowiki>lead</nowiki></code>: il motore garantisce che la carta d'attacco sia nella mano giusta e
fornisce nel risultato <code><nowiki>play: { "contract":"4H", "declarer":"responder", "leader":"opp2", "lead":"SK" }</nowiki></code>.
(Il gioco successivo, oltre la prima carta, non è nel DSL: per Segnali e Attacchi la prima carta e le
mani bastano a mostrare la situazione.)

=== 5.8 Statistiche ===
Per scenario: tasso di successo, tentativi medi, p95 ms, codici di fallimento. Esposte in
<code><nowiki>GET /api/deals/stats</nowiki></code> e inviate a BridgePedia (§8.5) per tarare i vincoli.

----

== 6. Codici di errore (422 e simili) ==

Già in uso: <code><nowiki>exact_cards_always_conflict</nowiki></code>, <code><nowiki>generation_time_limit</nowiki></code>, <code><nowiki>suit_cards_below_hcp_min</nowiki></code>,
<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>, <code><nowiki>suit_cards_exceed_hcp_max</nowiki></code>. Da aggiungere:

{| class="wikitable"
! Codice
! Quando
|-
| <code><nowiki>unsupported_feature</nowiki></code>
| lo scenario richiede un tag non supportato (<code><nowiki>detail</nowiki></code>: il tag)
|-
| <code><nowiki>dsl_errors</nowiki></code>
| l'API ha restituito <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> (riportarli)
|-
| <code><nowiki>variable_unsatisfiable</nowiki></code>
| nessuna assegnazione dei semi variabili rende lo scenario possibile
|-
| <code><nowiki>fixed_cards_conflict</nowiki></code>
| <code><nowiki>fixed</nowiki></code> contraddice lo scenario o carte duplicate
|-
| <code><nowiki>pair_points_unreachable</nowiki></code>
| <code><nowiki>pairhcp/pairtp</nowiki></code> incompatibili con i limiti per posizione
|-
| <code><nowiki>lead_conflict</nowiki></code>
| <code><nowiki>lead</nowiki></code> incompatibile con la mano dell'attaccante
|-
| <code><nowiki>no_branch_left</nowiki></code>
| <code><nowiki>any()</nowiki></code>/<code><nowiki>S~</nowiki></code>/<code><nowiki>not()</nowiki></code> eliminano tutti i rami
|-
| <code><nowiki>shape_unreachable</nowiki></code>
| forma/lunghezze incompatibili con 13 carte per mano e per seme
|-
| <code><nowiki>invalid_request</nowiki></code>
| parametri non validi (count, seed...)
|}

Ogni 422 porta <code><nowiki>reasons: [{code, position?, detail}]</nowiki></code> leggibili dal frontend.

----

== 7. Test di conformità e qualità ==

=== 7.1 Invarianti (property test, ≥ 10.000 smazzate per scenario del wiki) ===
* 52 carte distinte; 13 per mano; nessun duplicato.
* <code><nowiki>satisfies()</nowiki></code> vero per ogni smazzata emessa (il giudice '''non''' deve condividere codice con il generatore).
* Stesso seed → stesso risultato.

=== 7.2 Casi minimi per costrutto (la DSL → cosa deve valere) ===

{| class="wikitable"
! #
! DSL
! Asserzione
|-
| 1
| <code><nowiki>opener S:5+ hcp:12-21</nowiki></code>
| ♠ ≥ 5, PO in intervallo
|-
| 2
| <code><nowiki>@M=H,S opener ${M}:5+</nowiki></code>
| due scenari generabili (<code><nowiki>H</nowiki></code>, <code><nowiki>S</nowiki></code>)
|-
| 3
| <code><nowiki>$a=M opener $a:5+; responder $a:3+</nowiki></code>
| in ogni mano: un nobile ≥5 in opener, lo stesso seme ≥3 in responder; entrambi i nobili compaiono su 1000 mani
|-
| 4
| <code><nowiki>$a=M $b=m opener $a:5+ $b:4+</nowiki></code>
| $a nobile, $b minore, mai lo stesso seme
|-
| 5
| <code><nowiki>opener stop:S</nowiki></code> su 1000 mani
| tutte le mani hanno A, Kx, Qxx o Jxxx a ♠
|-
| 6
| <code><nowiki>opener nostop:S S:3+</nowiki></code>
| nessuna mano con A, né Kx, Qxx o Jxxx a ♠ (con 3 carte: né A, né K, né Q)
|-
| 7
| <code><nowiki>opener aces:2 kc:H3</nowiki></code>
| 2 assi; assi + K♥ = 3 (<code><nowiki>kc:H4</nowiki></code> con <code><nowiki>aces:2</nowiki></code> è impossibile: max 2+1)
|-
| 8
| <code><nowiki>opener has:HQ lacks:SK</nowiki></code>
| Q♥ presente, K♠ assente
|-
| 9
| <code><nowiki>opener tp:20-22</nowiki></code>
| <code><nowiki>tp</nowiki></code> corretto con la definizione di §2
|-
| 10
| <code><nowiki>opener ltc:6-7</nowiki></code>
| LTC con la definizione di §2
|-
| 11
| <code><nowiki>opener H>S</nowiki></code> e <code><nowiki>opener H>=S longest:H</nowiki></code>
| confronti rispettati; <code><nowiki>longest</nowiki></code> con pari merito
|-
| 12
| <code><nowiki>opener shape:5-4-x-x</nowiki></code>
| 5 e 4 come due semi più lunghi in ordine; gli altri due sommano 4
|-
| 13
| <code><nowiki>opener shape:semi_balanced</nowiki></code>
| solo 5422 e 6322
|-
| 14
| <code><nowiki>opener any(S:5+, H:5+)</nowiki></code>
| almeno un nobile ≥ 5
|-
| 15
| <code><nowiki>opener not(S:4+, H:4+)</nowiki></code>
| nessun nobile ≥ 4
|-
| 16
| <code><nowiki>opener any(S:4+ hcp:12+, H:4+)</nowiki></code>
| rami composti
|-
| 17
| <code><nowiki>pairhcp:25+ ... opp1 quiet; opp2 quiet</nowiki></code>
| coppia ≥ 25, avversari entro i limiti quiet
|-
| 18
| <code><nowiki>weight:1 ... // weight:3 ...</nowiki></code>
| 1000 estrazioni ~ 25%/75% (± tolleranza)
|-
| 19
| <code><nowiki>dealer:opp1 vul:both</nowiki></code>
| output con dealer/vul corretti e PBN ruotato
|-
| 20
| <code><nowiki>declarer:responder lead:SJ opp2 S=KJT</nowiki></code>
| J♠ in opp2; con <code><nowiki>lead:SQ</nowiki></code> → 422 <code><nowiki>lead_conflict</nowiki></code>
|-
| 21
| <code><nowiki>fixed</nowiki></code> con Q♥ in opener
| opener ha Q♥ e rispetta lo scenario
|-
| 22
| scenario impossibile (<code><nowiki>S=AK Shcp:0-2</nowiki></code>)
| 422 con ragione
|-
| 23
| scenario con <code><nowiki>unsupported</nowiki></code> simulato
| 422 <code><nowiki>unsupported_feature</nowiki></code>
|}

Aggiungere come test di regressione '''tutti gli scenari reali''' delle pagine del wiki
(<code><nowiki>shapeaction=list</nowiki></code> → <code><nowiki>get</nowiki></code>): per ciascuno ≥ 1000 smazzate valide entro il budget, oppure una
diagnosi documentata. Gli scenari più duri oggi: ''Multirever'' (Gran rever, 20 scenari) e
''Segnale di Smith'' (20 scenari con <code><nowiki>suit_cards</nowiki></code>).

=== 7.3 Qualità statistica ===
Per ogni scenario del wiki misurare su 5000 mani: distribuzione delle lunghezze e dei PO nei limiti
consentiti, tasso di riuscita al primo tentativo, tempo p50/p95. Segnalare distorsioni evidenti
(es. la posizione A prende sempre i PO alti).

=== 7.4 Prestazioni ===
Obiettivo: p95 < 300 ms per mano sugli scenari comuni; < 2,5 s sul peggiore. Se non si rispetta,
non allargare i vincoli: segnalare lo scenario a BridgePedia (§8.5) che può rivederlo.

----

== 8. Frontend di Play ==

Il frontend deve permettere di '''consultare''', '''generare''', '''creare''' e '''gestire''' smazzate.
Lingua: italiano, con i18n predisposta (en, fr, es, de). Tutti i testi dei vincoli vengono
dall'API (<code><nowiki>descriptions</nowiki></code>, parametro <code><nowiki>lang</nowiki></code>): non riscriverli.

=== 8.1 Catalogo delle convenzioni ===
* Elenco da <code><nowiki>shapeaction=list</nowiki></code> (con vincoli) e <code><nowiki>listall</nowiki></code> (tutte, con <code><nowiki>hasShape</nowiki></code>).
* Per ogni voce: titolo, numero di scenari, link alla pagina del wiki, stato: ''generabile'', ''parzialmente generabile'' (alcuni scenari con <code><nowiki>requires</nowiki></code> non supportato), ''non generabile''.
* Ricerca testuale; filtri per tipologia/sistema se esposti; badge "da verificare" per le traduzioni non verificate.
* Le 27 convenzioni senza vincoli compaiono come "scenari in arrivo" con link al wiki.

=== 8.2 Visualizzatore di scenario ===
* Tabella a colonne per posizione (come la tabella del wiki): etichetta scenario, frasi di <code><nowiki>descriptions[i].positions</nowiki></code>, <code><nowiki>positionLabels</nowiki></code> (rispettare i ruoli personalizzati, es. "Attaccante"), <code><nowiki>fit</nowiki></code>, <code><nowiki>context</nowiki></code>.
* Semi ♥ ♦ in rosso. Mostrare <code><nowiki>requires</nowiki></code> come chip (tooltip con spiegazione).
* Pulsante "Mostra DSL" (testo <code><nowiki>raw</nowiki></code>) e "Apri la pagina nel wiki".

=== 8.3 Generatore ===
* Scelta convenzione → scenario (singolo, "a caso", "tutti a rotazione", pesato) → quantità (1-100) → opzioni (seed, mani distinte, nascondi avversari).
* Risultato: schede smazzata con 4 mani (formato BridgeCards: ♠♥♦♣, bordi, dealer, vulnerabilità), etichetta scenario, '''pannello "perché questa mano"''': per posizione le frasi di <code><nowiki>explanation</nowiki></code> con spunta, binding (<code><nowiki>$a = ♥</nowiki></code>), PO/lunghezze effettive.
* Azioni per smazzata: rigenera, "blocca questa mano e rigenera le altre" (usa <code><nowiki>fixed</nowiki></code>), copia link con seed, esporta PBN/LIN/immagine, aggiungi alla raccolta.
* Se la licita <code><nowiki>auction</nowiki></code> è presente: mostrarla con <code><nowiki><bidding></nowiki></code> (stile BridgeCards) o nascosta per esercizio ("indovina la risposta").
* Gestione 422: messaggio per codice (§6) con suggerimento ("lo scenario è impossibile perché..."). Per <code><nowiki>unsupported_feature</nowiki></code>: spiegare quale capacità manca.

=== 8.4 Editor / creazione di scenari ===
Due modalità sincronizzate:

# '''Modulo guidato''' per posizione (Apertore, Compagno, Avv. sinistro, Avv. destro):
#* lunghezze per seme (slider min-max), PO totali e per seme, forma (classi + schema <code><nowiki>5-4-x-x</nowiki></code>);
#* griglia carte per seme (A K Q J 10 9 + "basse") con stati ''deve avere / non deve avere / indifferente'' che produce <code><nowiki>S=...</nowiki></code>; costruttore di pattern per <code><nowiki>S~</nowiki></code> con anteprima;
#* interruttori: fermata (per seme), assi/re/dame/controlli, carte chiave con atout, <code><nowiki>tp/dp/ltc</nowiki></code>, confronti tra semi, <code><nowiki>any(...)</nowiki></code>/<code><nowiki>not(...)</nowiki></code> come gruppi aggiungibili;
#* variabili di seme <code><nowiki>$a..$d</nowiki></code> con dominio (nobili/minori/qualsiasi);
#* contesto: dealer, vulnerabilità, licita, contratto, attacco, peso;
#* avversari: pulsante '''quiet''' (e <code><nowiki>quiet:max</nowiki></code>);
#* macro: "ripeti per ogni nobile / minore / seme" genera <code><nowiki>@M=...</nowiki></code>.
# '''Editor testuale''' del DSL con evidenziazione, completamento e ''validazione live'': chiama <code><nowiki>shapeaction=validate</nowiki></code> (debounce 400 ms) e mostra <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>, <code><nowiki>descriptions</nowiki></code> e <code><nowiki>requires</nowiki></code> (con il supporto del motore). Le due modalità si convertono a vicenda (modulo → DSL è obbligatorio; DSL → modulo almeno per i costrutti elementari, il resto resta testuale).

* Pulsante "Prova": genera 5 mani di test dallo scenario in modifica e mostra tempi e tassi di riuscita.
* Salvataggio come '''bozza personale''' in Play (non scrive sul wiki). Pulsante "Copia per BridgePedia" produce la riga <code><nowiki>shape_constraints</nowiki></code> da incollare nella pagina (gli editor del wiki fanno il resto).
* Libreria di '''modelli''' presi dalle convenzioni del wiki ("parti da Landy").

=== 8.5 Retroazione verso BridgePedia ===
* Pulsante "Segnala scenario problematico" (lento / troppo raro / 422 / distribuzione strana) che invia: pagina, scenario, <code><nowiki>dslVersion</nowiki></code>, codice errore, statistiche (§5.8) al canale concordato (sessione/issue). Nessuna scrittura diretta sul wiki.
* Report periodico automatico delle statistiche di generazione per scenario.

=== 8.6 Smazzate manuali ===
* Compositore: assegnare le 52 carte alle quattro mani con trascinamento o digitazione (<code><nowiki>AK2.QJ5.K84.T65</nowiki></code>), controllo duplicati, completamento casuale delle carte mancanti (opzionalmente rispettando uno scenario: usa <code><nowiki>fixed</nowiki></code>).
* Pulsante "Verifica rispetto a uno scenario" (§5.5) con l'elenco dei vincoli soddisfatti e violati.
* Importa/esporta PBN, LIN, testo semplice.

=== 8.7 Gestione delle smazzate ===
* Raccolte ("mazzi di esercizio"): nome, descrizione, convenzione, tag; ordinamento; duplicati evitati.
* Ricerca per convenzione, scenario, tag, data; filtri per vulnerabilità, dealer.
* Metadati salvati: <code><nowiki>seed</nowiki></code>, <code><nowiki>source.page</nowiki></code>, scenario, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>revid</nowiki></code>, data, autore.
* Note personali per smazzata; stampa di una raccolta (fogli A4 con 4 o 6 smazzate per pagina, versione "solo mano dell'apertore" per esercizio).
* Condivisione: link con seed/raccolta, permessi (privato, gruppo, pubblico) secondo il modello utenti di Play. Esportazione in blocco (PBN).
* Modalità "esercizio di licita": mostra le mani di un lato, l'utente inserisce la licita, il frontend confronta con <code><nowiki>context.auction</nowiki></code> se presente.

=== 8.8 Requisiti trasversali ===
* Mobile first; tastiera accessibile; semi anche come lettere per daltonici.
* Nessuna dipendenza dal wiki per il rendering delle carte (usare componenti propri; stile coerente con BridgeCards).
* Tempi: la generazione deve mostrare avanzamento e poter essere annullata.
* Tracciare (analytics interni) tempi, errori e scenari più usati.
* Testo dei vincoli sempre da <code><nowiki>descriptions</nowiki></code> con <code><nowiki>lang</nowiki></code> coerente con la lingua dell'interfaccia.

----

== 9. Piano di consegna consigliato ==

{| class="wikitable"
! Fase
! Contenuto
! Esito atteso
|-
| '''P0 — compatibilità''' (subito)
| leggere <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>requires</nowiki></code>, <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>; esporre <code><nowiki>/capabilities</nowiki></code>; rifiutare con <code><nowiki>unsupported_feature</nowiki></code>; giudice <code><nowiki>satisfies()</nowiki></code> per v1
| nessuna smazzata errata con le pagine nuove
|-
| '''P1 — core v2'''
| macro (nessun lavoro, già espanse), <code><nowiki>weight</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, classi nuove, <code><nowiki>compare</nowiki></code>/<code><nowiki>longest</nowiki></code>, <code><nowiki>any/not</nowiki></code>, <code><nowiki>pair_*</nowiki></code>
| scenari per Landy/Cappelletti/DONT/Smolen con forme e alternative
|-
| '''P2 — variabili e carte'''
| <code><nowiki>vars</nowiki></code> condivise tra posizioni, <code><nowiki>has/lacks</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>aces/kings/queens/controls/kc</nowiki></code>
| Michaels, Sputnik, Lebensohl, Blackwood/RKCB, Exclusion
|-
| '''P3 — punteggi'''
| <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>
| sistemi a forza (Fiori forte, 2♣ forte, Gazzilli)
|-
| '''P4 — frontend lettura'''
| catalogo, visualizzatore, generatore con spiegazioni
| tutti possono provare le convenzioni
|-
| '''P5 — frontend creazione'''
| editor guidato + testuale con validazione live, "Prova", bozze
| gli editor creano e collaudano scenari senza il wiki
|-
| '''P6 — gestione'''
| raccolte, smazzate manuali, <code><nowiki>check</nowiki></code>, <code><nowiki>fixed</nowiki></code>, esportazioni, esercizi di licita
| uso didattico completo
|-
| '''P7 — qualità'''
| suite di conformità (§7), statistiche, report verso BridgePedia
| motore misurabile
|}

Ogni fase deve chiudersi con i test di §7 per i costrutti introdotti. BridgePedia estende le
pagine del wiki man mano che i tag diventano disponibili: '''comunicate a ogni fase la lista dei tag supportati''' (<code><nowiki>/capabilities</nowiki></code>) così il wiki passa dalle approssimazioni (pattern <code><nowiki>S~</nowiki></code>) ai
costrutti nativi solo quando il motore li regge.

----

== 10. Cosa fa BridgePedia (per non sovrapporsi) ==

* Mantiene il DSL, il parser, le descrizioni e l'API; aggiunge costrutti su richiesta motivata.
* Scrive e tiene aggiornati gli scenari nelle pagine delle convenzioni; le 27 mancanti saranno coperte via via con i costrutti v2.
* Fornisce il catalogo di ricette (come descrivere Landy, Blackwood, un attacco sotto onore...).
* Riceve da Play le segnalazioni di §8.5 e rivede i vincoli troppo duri.

== 11. Decisioni aperte (da concordare con Play) ==

# Definizione definitiva delle classi di forma (§2) rispetto a quanto già implementato.
# Formato di <code><nowiki>explanation</nowiki></code> (testo semplice vs struttura con esito per vincolo).
# Modello di persistenza e permessi delle raccolte (utenti Play).
# Canale per le segnalazioni verso BridgePedia (§8.5).
# Se <code><nowiki>fixed</nowiki></code> deve accettare anche vincoli aggiuntivi temporanei (override locali dello scenario).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Editor e Laboratorio

2026-10-28T07:05:31Z

Lpala: Nuova pagina: Editor avanzato e Laboratorio di test BridgeShape

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]]

= BridgeShape — Editor avanzato e Laboratorio di test (brief per Play) =

Integra <code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code> §8.4 (editor) e §5.8 (statistiche). Origine: la scrittura degli scenari
di "Gioco di eliminazione" (E1–E5) ha mostrato che il DSL è espressivo ma **non si vede come
vengono generate le mani**: gli scenari risultavano sbilanciati (es. apertore 24 PO, risponditore 5;
avversari a 0 PO che ricevono tutti i punti residui) e ce ne si accorge solo guardando mani a caso.

== 1. Il DSL è abbastanza generale? Lacune da colmare ==

Coperto bene: lunghezze, forma, PO totali/per seme, onori esatti (<code><nowiki>S=AKQJ</nowiki></code>, <code><nowiki>x</nowiki></code>), pattern, <code><nowiki>pairhcp</nowiki></code>,
fermate, controlli, carte chiave, LTC, <code><nowiki>any</nowiki></code>/<code><nowiki>not</nowiki></code>, variabili, macro, contesto (dealer, contratto, attacco).

Lacune (in ordine di priorità):

# '''Nessun controllo su come si distribuisce il resto.''' Le carte non vincolate vanno a caso alle mani libere. Servono:
#* <code><nowiki>default-opp: realistic</nowiki></code> (o <code><nowiki>quiet</nowiki></code> già esistente) con soglie ragionevoli per gli avversari;
#* <code><nowiki>hcp:</nowiki></code> e <code><nowiki>pairhcp:</nowiki></code> per ogni posizione '''anche come intervallo "tipico"''' (non solo filtro);
#* opzione <code><nowiki>spread: even</nowiki></code> che, dopo i vincoli, ripartisce gli onori residui senza concentrarli in una mano.
# '''Vincoli di esito (post-filtro double-dummy)''': <code><nowiki>makes: 4S by opener</nowiki></code>, <code><nowiki>tricks: 10-11</nowiki></code>, <code><nowiki>lead-fails</nowiki></code>. Fondamentali per le tecniche di gioco (eliminazione, messa in presa, squeeze). Opzionali, con budget di tempo; se il solver non c'è → <code><nowiki>requires: dd</nowiki></code> e <code><nowiki>unsupported_feature</nowiki></code>. Il solver va eseguito solo dopo i filtri economici.
# '''Vincoli di relazione fra mani''' (es. "i due avversari hanno insieme 8+ carte di ♥", "atout 3-2 / 4-1 fra i difensori"): oggi si ottengono solo fissando le lunghezze di entrambi.
# '''Vincoli "morbidi"/pesati''': preferenze (peso 0–1) invece di filtri duri, per mani più naturali senza far esplodere il tasso di rifiuto.
# '''Carte o vincoli fissati dall'utente nel test''' (<code><nowiki>fixed</nowiki></code>, già in §5.6) con override temporanei.

== 2. Editor "potentissimo" (estende §8.4) ==

* '''Pannello Mani''' con le 4 posizioni, per ciascuna: barre min-max di lunghezze per seme, PO, griglia onori (deve / non deve / indifferente / "uno fra"), sempre sincronizzato col DSL testuale.
* '''Indicatori in tempo reale di fattibilità''': mentre si modifica, calcolo esatto/rapido di: somma minimi vs 13 carte, somma minimi PO vs 40, onori richiesti in conflitto (stessa carta a due mani), stima del tasso di successo (campionamento rapido a 200 tentativi con barra di avanzamento).
* '''Avvisi di sbilanciamento''' (punto chiave): avvisa se la distribuzione implicita dei PO fra le mani è anomala (es. una mano ≥ 22 e il compagno ≤ 6; un avversario a 0 con l'altro a ≥ 12; coppia fuori da 23–33 senza motivo) e proponi la correzione.
* '''Validazione live''' con <code><nowiki>shapeaction=validate</nowiki></code> (errori, avvisi, descrizioni, <code><nowiki>requires</nowiki></code>).
* '''Cronologia e confronto''': versioni salvate, diff DSL + diff statistiche fra due versioni.
* '''Esportazione''': "Copia per BridgePedia" (riga <code><nowiki>shape_constraints</nowiki></code>), JSON, link con seed.
* '''Modelli''' dalle convenzioni del wiki e dalle ricette (<code><nowiki>Progetto:BridgeShape Ricette DSL</nowiki></code>).

== 3. Laboratorio di test: capire come vengono generate le mani ==

Pulsante "Prova" → modale "Laboratorio" su N mani (default 1000, fino a 10.000, in background con
progresso, seed fisso riproducibile). Output:

# '''Esito del campionamento''': tasso di successo, tentativi medi/p95, tempo medio/p95, mani generate/rifiutate.
# '''Vincolo colpevole''': per ogni vincolo la % di scarti che provoca (quale pezzo dello scenario rende lo scenario lento o raro).
# '''Istogrammi per posizione''' (apertore/compagno/avv. sx/avv. dx): PO (0–37), lunghezza per seme, forma (classi), numero di assi/re/controlli, LTC. Con '''linee dei limiti richiesti''', media, mediana, percentili 5/95.
# '''Confronto con la base''': stessi istogrammi su un mazzo non vincolato, per vedere di quanto lo scenario distorce (misura per seme: variazione rispetto al caso).
# '''Frequenza onori per mano''': matrice posizione × carta (A K Q J T) con % di presenza, per scoprire concentrazioni (es. "ogni volta l'avversario sx ha l'Asso di ♦").
# '''Coppia''': istogramma PO della coppia, distribuzione dei fit (lunghezza d'atout combinata), spaccature degli atout dei difensori (3-2, 4-1, 5-0).
# '''Test di equità''': verifica che il campionamento sia uniforme sullo spazio dei vincoli (confronto tra due seed e tra metodo a rifiuto e costruttivo; chi² sulle frequenze di carte/posizioni). Segnala bias (es. carte basse sempre nella stessa mano).
# '''Se disponibile il solver''': percentuale di mani in cui il contratto dichiarato si realizza, e distribuzione delle prese; elenco delle mani contro-esempio apribili con un clic.
# '''Galleria''': le prime 10 mani, un clic per aprirne il perché (§5.4) e per "fissa e rigenera".
# '''Report esportabile''' (JSON + testo) da inviare a BridgePedia (§8.5), così gli editor del wiki tarano i vincoli. Accettiamo un campo <code><nowiki>labReport</nowiki></code> nello scenario problematico.

== 4. API richieste (aggiunte a <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code>) ==

* <code><nowiki>POST /api/deals/lab</nowiki></code> <code><nowiki>{source, dsl, scenario, n, seed, solver?: bool}</nowiki></code> → <code><nowiki>jobId</nowiki></code>; <code><nowiki>GET /api/deals/lab/{jobId}</nowiki></code> → <code><nowiki>{status, progress, success, attempts, timing, rejectBy[], histograms{}, honors{}, balance{warnings[]}, fairness{}, dd?{}}</nowiki></code>.
* <code><nowiki>POST /api/deals/check</nowiki></code> (già in §5.5) per le mani contro-esempio.
* Tag <code><nowiki>requires</nowiki></code>: <code><nowiki>lab</nowiki></code>, <code><nowiki>dd</nowiki></code>, <code><nowiki>spread</nowiki></code>, <code><nowiki>relations</nowiki></code>, <code><nowiki>soft</nowiki></code>.

== 5. Criteri di accettazione ==

# Per ogni scenario del wiki il laboratorio parte in < 2 s e fornisce i 10 punti sopra per N=1000 entro 30 s.
# Gli avvisi di sbilanciamento segnalano E2 di "Gioco di eliminazione" (24/5 PO) prima della generazione.
# Due esecuzioni con stesso seed danno identici istogrammi.
# Test di equità: nessuno scarto > 3σ rispetto all'attesa sui vincoli non esplicitati.

----

== Vedi anche ==
* [[Progetto:BridgeShape Motore e frontend]]
* [[Progetto:BridgeShape API]]
* [[Progetto:BridgeShape Ricette DSL]]
* [[Gioco di eliminazione]]

== Fonti ==
* Esperienza di scrittura degli scenari di Gioco di eliminazione (ProgettoBridge, Lezione 18) e specifica interna BridgeShape

[[Categoria:Documentazione tecnica]]

Gioco di eliminazione

2026-10-27T22:02:03Z

Lpala: Aggiunti scenari E3-E5 e nota di verifica

{{Convenzione
|nome=Gioco di eliminazione
|tipologia=Tecnica di gioco
|scopo=Togliere alla difesa le uscite neutre nei colori laterali, in modo che un avversario messo in presa debba muovere un colore pericoloso o giocare in taglio e scarto, evitando di dipendere dalla posizione di una carta.
|trigger=Contratto a colore con atout lunghi in linea e colori laterali che si possono eliminare (incassando le vincenti e tagliando le perdenti), con un colore chiave in cui la difesa, costretta a giocare per prima, ci regala una presa.
|risposte=1) Contare le prese sicure e le perdenti; 2) battere le atout; 3) incassare e tagliare i colori laterali; 4) mettere in presa un avversario (messa in mano); 5) lasciare alla difesa solo il colore pericoloso o il taglio e scarto.
|note=Alternativa alla linea di impasse o expasse: l'eliminazione non dipende dalla posizione di una carta ma richiede che la difesa non abbia uscite neutre. Pagina di tecnica di gioco, non di licita: nessun tag BridgeCC applicabile.
|shape_constraints=E1 messa in mano a cuori: opener S:5 S=AKQJ H:2 H=x D:3 D=J C:3 C=AQ; responder S:4 S=x H:3 H=AQ D:4 D=Q C:2 C=K // E2 dama a picche evitata: opener S:2 S=AQ H:4 H=AKQ D:3 D=K C:4 C=KQJT; responder S:2 S=x H:4 H=x D:3 D=AJ C:4 C=x // E3 slam a quadri con atout 2-2: opener S:5 S=AKQ H:3 H=K D:4 D=AQ C:1 C=x; responder S:4 S=x H:3 H=A D:4 D=K C:2 C=A; opp1 S:2; opp2 S:2 // E4 taglio e scarto: opener S:5 S=KQT H:3 H=x D:2 D=K C:3 C=AQ; responder S:4 S=AJ9 H:2 H=T D:4 D=A C:3 C=x; opp1 S:2 H:4 H=AKQ D:4; opp2 S:2 // E5 sottoapertura a quadri: opener S:2 S=x H:3 H=K D:2 D=AQ C:6 C=AQT; responder S:4 S=AKQ H:4 H=Q D:2 D=x C:3 C=KJ; opp1 D:6 D=KJT H:3 H=A
|shape_roles=opener=Dichiarante;responder=Morto;opp1=Attaccante;opp2=Quarta mano
}}

Il '''gioco di eliminazione''' (in inglese ''elimination play'' o ''strip and throw-in'') è una tecnica del [[Gioco della carta (bridge)|gioco della carta]] con cui il dichiarante, in un contratto a colore, toglie uno dopo l'altro i colori laterali alla difesa e poi mette in presa un avversario, che si trova costretto a giocare un colore dove regala una presa oppure a muovere in taglio e scarto.

== Quando si usa ==
Si pensa all'eliminazione quando:
* il contratto è a colore e la linea in atout è tranquilla (tipicamente le atout si battono senza problemi);
* resta un solo colore da giocare con difficoltà, di solito con una perdente che dipende da un impasse o da una posizione di carte;
* i colori laterali si possono esaurire incassando le vincenti e tagliando le piccole, in mano o al morto;
* un avversario può essere messo in presa senza che gli rimanga una uscita neutra.

== Come si svolge ==
# '''Conta''': si contano le prese sicure e le perdenti e si individua il colore dove la difesa può fare danno.
# '''Atout''': di norma si battono le atout, per impedire alla difesa di tagliare e per mantenere il controllo.
# '''Eliminazione dei colori laterali''': si incassano le vincenti dei colori laterali e si tagliano le perdenti, finché la difesa non ha più carte in quei colori.
# '''Messa in mano''': si cede una presa a un avversario scelto, in modo che debba rigiocare.
# '''Scelta del colore''': la difesa può muovere solo il colore pericoloso, oppure giocare in taglio e scarto, che permette al dichiarante di scartare una perdente e tagliare nell'altra mano.

== Eliminazione e impasse a confronto ==
La linea di impasse o expasse dipende dalla posizione di una carta: se è sbagliata, la mano cade. L'eliminazione sposta il problema: invece di indovinare dove sta la carta, si costringe la difesa a muovere per prima nel colore dove si vuole che giochi. Funziona quando la difesa non ha uscite neutre, cioè colori dove può giocare senza regalare nulla. Quando le ha ancora, la messa in mano non produce l'effetto sperato e occorre ripiegare sulla linea di impasse.

== Errori tipici ==
* '''Incassare un giro di troppo''': togliere una carta che serviva come uscita al dichiarante o come ingresso, e lasciare alla difesa una uscita neutra.
* '''Togliere troppo presto un ingresso''': dopo aver eliminato i colori, al dichiarante manca il rientro in mano o al morto necessario a completare la tecnica.
* '''Non contare prima''': iniziare a incassare senza avere stabilito quale colore deve restare alla difesa.

== Esempio 1: messa in mano a cuori ==
Nord è dichiarante, nessuno in zona. Contratto 4{{picche}}, attacco Fante di fiori.

<deal dealer="N" vul="None" board="1">
N: AKQJ7.52.J74.AQ5
E: 86.J943.A106.J1097
S: T954.AQ6.Q852.K6
W: 32.K1087.K93.8432
</deal>

<bidding>1S P 2NT P 4S P P P</bidding>

Dopo aver battuto le atout, si incassano i fiori scartando una piccola di cuori dal morto e si incassano gli onori di cuori. La difesa, messa in presa, deve muovere quadri oppure giocare in taglio e scarto. La linea di impasse a cuori e di expasse a quadri riuscirebbe solo con certe posizioni (circa il 67 %); l'eliminazione realizza dieci prese qualunque sia la difesa (verificato a carte scoperte).

== Esempio 2: la dama di quadri e l'impasse a picche non servono ==
Ovest è dichiarante, Est-Ovest in zona. Contratto 4{{cuori}}, attacco 5 di fiori.

<deal dealer="W" vul="EW" board="2">
N: KJ7652.JT.8632.5
E: 98.6543.AJ5.7432
S: T43.972.Q97.A986
W: AQ.AKQ8.KT4.KQJT
</deal>

<bidding>2C P 2D P 2NT P 3C P 3H P 4H P P P</bidding>

Dopo aver battuto le atout e incassato i fiori, basta giocare Asso e Dama di picche (eliminazione) invece di indovinare la posizione della Dama di quadri o di tentare l'impasse a picche: la linea di eliminazione riesce nel 100 % dei casi contro circa il 75 % delle altre. Dieci prese verificate a carte scoperte.

== Regole di generazione ==
Questa pagina fornisce a Play le regole per generare smazzate di allenamento. Ogni scenario fissa la struttura del dichiarante e del morto: le lunghezze dei colori e gli onori del colore chiave; le carte basse e gli onori non nominati sono casuali e sui difensori non c'è alcun vincolo di punti.
* '''E1 (messa in mano a cuori)''': dichiarante con cinque picche e AKQJ, morto con quattro picche; contratto da giocare 4{{picche}}.
* '''E2 (dama a picche evitata)''': dichiarante con AKQ di cuori e KQJT di fiori, morto con quattro cuori; contratto da giocare 4{{cuori}}.
* '''E3 (slam a quadri con atout 2-2)''': slam a picche (contratto 6{{picche}}) con colore chiave a quadri e atout divisi 2-2 fra i difensori.
* '''E4 (taglio e scarto)''': contratto 4{{picche}} con taglio e scarto: l'attaccante (opp1) ha Asso, Re e Dama di cuori quarte e quattro quadri, atout 2-2.
* '''E5 (sottoapertura a quadri)''': contratto 6{{fiori}} dopo una sottoapertura a quadri dell'attaccante: ha quadri sesti con K, J, 10 e l'Asso di cuori.
Gli scenari E3-E5 vincolano anche i difensori, perché la linea di eliminazione dipende da come sono divisi gli atout e da dove stanno gli onori.

'''Nota di verifica.''' Gli scenari sono stati controllati campionando mani e risolvendole a carte scoperte con la difesa migliore: il contratto si realizza in E1 10/10, E2 9/10, E3 9/10, E4 5 mani risolte su 5 (altre 3 non risolte nel tempo massimo), E5 8/8. Il campione è piccolo, quindi sono indicazioni e non garanzie.

== Vedi anche ==
* [[Gioco della carta (bridge)]]

== Fonti ==
* ProgettoBridge, ''Lezione 18 — Gioco di Eliminazione, Smazzate esplicative''.

Gioco di eliminazione

2026-10-27T20:18:16Z

Lpala: Nuova pagina: gioco di eliminazione

{{Convenzione
|nome=Gioco di eliminazione
|tipologia=Tecnica di gioco
|scopo=Togliere alla difesa le uscite neutre nei colori laterali, in modo che un avversario messo in presa debba muovere un colore pericoloso o giocare in taglio e scarto, evitando di dipendere dalla posizione di una carta.
|trigger=Contratto a colore con atout lunghi in linea e colori laterali che si possono eliminare (incassando le vincenti e tagliando le perdenti), con un colore chiave in cui la difesa, costretta a giocare per prima, ci regala una presa.
|risposte=1) Contare le prese sicure e le perdenti; 2) battere le atout; 3) incassare e tagliare i colori laterali; 4) mettere in presa un avversario (messa in mano); 5) lasciare alla difesa solo il colore pericoloso o il taglio e scarto.
|note=Alternativa alla linea di impasse o expasse: l'eliminazione non dipende dalla posizione di una carta ma richiede che la difesa non abbia uscite neutre. Pagina di tecnica di gioco, non di licita: nessun tag BridgeCC applicabile.
|shape_constraints=E1 messa in mano a cuori: opener S:5 S=AKQJ H:2 H=x D:3 D=J C:3 C=AQ; responder S:4 S=x H:3 H=AQ D:4 D=Q C:2 C=K // E2 dama a picche evitata: opener S:2 S=AQ H:4 H=AKQ D:3 D=K C:4 C=KQJT; responder S:2 S=x H:4 H=x D:3 D=AJ C:4 C=x
|shape_roles=opener=Dichiarante;responder=Morto;opp1=Attaccante;opp2=Quarta mano
}}

Il '''gioco di eliminazione''' (in inglese ''elimination play'' o ''strip and throw-in'') è una tecnica del [[Gioco della carta (bridge)|gioco della carta]] con cui il dichiarante, in un contratto a colore, toglie uno dopo l'altro i colori laterali alla difesa e poi mette in presa un avversario, che si trova costretto a giocare un colore dove regala una presa oppure a muovere in taglio e scarto.

== Quando si usa ==
Si pensa all'eliminazione quando:
* il contratto è a colore e la linea in atout è tranquilla (tipicamente le atout si battono senza problemi);
* resta un solo colore da giocare con difficoltà, di solito con una perdente che dipende da un impasse o da una posizione di carte;
* i colori laterali si possono esaurire incassando le vincenti e tagliando le piccole, in mano o al morto;
* un avversario può essere messo in presa senza che gli rimanga una uscita neutra.

== Come si svolge ==
# '''Conta''': si contano le prese sicure e le perdenti e si individua il colore dove la difesa può fare danno.
# '''Atout''': di norma si battono le atout, per impedire alla difesa di tagliare e per mantenere il controllo.
# '''Eliminazione dei colori laterali''': si incassano le vincenti dei colori laterali e si tagliano le perdenti, finché la difesa non ha più carte in quei colori.
# '''Messa in mano''': si cede una presa a un avversario scelto, in modo che debba rigiocare.
# '''Scelta del colore''': la difesa può muovere solo il colore pericoloso, oppure giocare in taglio e scarto, che permette al dichiarante di scartare una perdente e tagliare nell'altra mano.

== Eliminazione e impasse a confronto ==
La linea di impasse o expasse dipende dalla posizione di una carta: se è sbagliata, la mano cade. L'eliminazione sposta il problema: invece di indovinare dove sta la carta, si costringe la difesa a muovere per prima nel colore dove si vuole che giochi. Funziona quando la difesa non ha uscite neutre, cioè colori dove può giocare senza regalare nulla. Quando le ha ancora, la messa in mano non produce l'effetto sperato e occorre ripiegare sulla linea di impasse.

== Errori tipici ==
* '''Incassare un giro di troppo''': togliere una carta che serviva come uscita al dichiarante o come ingresso, e lasciare alla difesa una uscita neutra.
* '''Togliere troppo presto un ingresso''': dopo aver eliminato i colori, al dichiarante manca il rientro in mano o al morto necessario a completare la tecnica.
* '''Non contare prima''': iniziare a incassare senza avere stabilito quale colore deve restare alla difesa.

== Esempio 1: messa in mano a cuori ==
Nord è dichiarante, nessuno in zona. Contratto 4{{picche}}, attacco Fante di fiori.

<deal dealer="N" vul="None" board="1">
N: AKQJ7.52.J74.AQ5
E: 86.J943.A106.J1097
S: T954.AQ6.Q852.K6
W: 32.K1087.K93.8432
</deal>

<bidding>1S P 2NT P 4S P P P</bidding>

Dopo aver battuto le atout, si incassano i fiori scartando una piccola di cuori dal morto e si incassano gli onori di cuori. La difesa, messa in presa, deve muovere quadri oppure giocare in taglio e scarto. La linea di impasse a cuori e di expasse a quadri riuscirebbe solo con certe posizioni (circa il 67 %); l'eliminazione realizza dieci prese qualunque sia la difesa (verificato a carte scoperte).

== Esempio 2: la dama di quadri e l'impasse a picche non servono ==
Ovest è dichiarante, Est-Ovest in zona. Contratto 4{{cuori}}, attacco 5 di fiori.

<deal dealer="W" vul="EW" board="2">
N: KJ7652.JT.8632.5
E: 98.6543.AJ5.7432
S: T43.972.Q97.A986
W: AQ.AKQ8.KT4.KQJT
</deal>

<bidding>2C P 2D P 2NT P 3C P 3H P 4H P P P</bidding>

Dopo aver battuto le atout e incassato i fiori, basta giocare Asso e Dama di picche (eliminazione) invece di indovinare la posizione della Dama di quadri o di tentare l'impasse a picche: la linea di eliminazione riesce nel 100 % dei casi contro circa il 75 % delle altre. Dieci prese verificate a carte scoperte.

== Regole di generazione ==
Questa pagina fornisce a Play le regole per generare smazzate di allenamento. Ogni scenario fissa la struttura del dichiarante e del morto: le lunghezze dei colori e gli onori del colore chiave; le carte basse e gli onori non nominati sono casuali e sui difensori non c'è alcun vincolo di punti.
* '''E1 (messa in mano a cuori)''': dichiarante con cinque picche e AKQJ, morto con quattro picche; contratto da giocare 4{{picche}}.
* '''E2 (dama a picche evitata)''': dichiarante con AKQ di cuori e KQJT di fiori, morto con quattro cuori; contratto da giocare 4{{cuori}}.
Altri scenari (slam, taglio e scarto, sottoapertura) saranno aggiunti dopo la verifica.

== Vedi anche ==
* [[Gioco della carta (bridge)]]

== Fonti ==
* ProgettoBridge, ''Lezione 18 — Gioco di Eliminazione, Smazzate esplicative''.

Progetto:BridgeShape Smazzate di gioco

2026-10-27T19:06:55Z

Lpala: Blocchi di codice in <pre> (SyntaxHighlight non caricata)

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — Regole per generare smazzate di gioco (eliminazione e messa in mano) =

Come descrivere con <code><nowiki>shape_constraints</nowiki></code> le smazzate didattiche sul '''gioco della carta''' (eliminazione,
messa in mano, expasse, sblocco, conteggio, carta falsa), per esempio quelle della lezione
"Gioco di Eliminazione" di ProgettoBridge. Gli scenari qui sotto sono '''archetipi scritti da BridgePedia''' (non copiano le mani né il testo della lezione). Ogni riga è verificata dal parser
(<code><nowiki>RecipesTest</nowiki></code>).

== 1. Cosa può fare la DSL e cosa no ==

La DSL descrive la '''struttura''' della smazzata: forma, punti, fit, colori lunghi, contesto
(contratto, attaccante, vulnerabilità). '''Non''' può dire "la mano si realizza solo con la messa in
mano": quella è una proprietà del ''gioco'', non della distribuzione. Quindi la generazione ha due
fasi:

# '''Generazione strutturale''' con gli scenari di questa pagina (il motore Play).
# '''Filtro tecnico''' (post-filtro), da realizzare in Play con un risolutore a carte scoperte (double dummy): si tiene la smazzata solo se supera i controlli del §3.

Senza il passo 2 la maggior parte delle mani generate non conterrebbe il tema voluto.

== 2. Archetipi (scenari) ==

Messa in mano dopo eliminazione, fit nobile 5-4, contratto di manche:
<pre>
Eliminazione base 4S: declarer:opener contract:4S opener S:5 hcp:16-19 ; responder S:4 hcp:8-11
Eliminazione base 4H: declarer:opener contract:4H opener H:5 hcp:16-19 ; responder H:4 hcp:8-11
</pre>

Colore laterale corto da eliminare (singolo o doubleton) con taglio e scarto possibile:
<pre>
Eliminazione colore corto: declarer:opener contract:4S opener S:5-6 hcp:15-19 $a:2-3 ; responder S:4 $a:2 hcp:8-12
</pre>

Slam con undici prese vincenti e un solo colore da giocare bene:
<pre>
Slam con colore chiave: declarer:opener contract:6S pairhcp:30-34 opener S:5+ hcp:17-21 ; responder S:3+ hcp:10-14
</pre>

Expasse e impasse nello stesso colore (stessa posizione di una carta):
<pre>
Impasse o expasse: declarer:opener contract:6D pairhcp:30-34 opener D:5+ hcp:14-18 ; responder D:4+ hcp:14+
</pre>

Gioco a senza atout con sblocco al primo giro:
<pre>
SA con sblocco: declarer:opener contract:3NT opener shape:balanced hcp:15-17 ; responder shape:balanced hcp:9-12 ; opp1 S:5+
SA con onore secondo in mano: declarer:opener contract:3NT opener H:2-3 hcp:15-17 ; responder H:4 hcp:10-12 ; opp1 S:5+
</pre>

Conteggio della mano di un avversario che ha aperto di barrage o sottoapertura:
<pre>
Conteggio dopo barrage: dealer:opp1 declarer:opener contract:4H opp1 S:7 hcp:5-9 ; opener H:5+ hcp:16-20 ; responder H:3+
Conteggio dopo sottoapertura: dealer:opp1 declarer:opener contract:6C opp1 D:6 hcp:5-9 ; opener C:6+ hcp:19+ ; responder C:2-4 hcp:12+
</pre>

Atout 2-2 favorevoli e doppio impasse:
<pre>
Quattro picche 2-2: declarer:opener contract:4S opener S:5 hcp:12-15 ; responder S:4 hcp:8-11 ; opp1 S:2 ; opp2 S:2
</pre>

Controgioco e attacco per la difesa (si impersona la difesa):
<pre>
Difesa contro 4 cuori: declarer:opener contract:4H lead:SQ opener H:5+ hcp:17+ ; opp1 S=QJ
Difesa contro 6 fiori: declarer:opener contract:6C opener C:6+ hcp:19+ ; opp1 H:4-5 hcp:6-10
</pre>

Contro informativo e risposta del compagno:
<pre>
Contro informativo e risposta: dealer:opener opener S:6 hcp:12-15 ; opp1 hcp:12+ H:4+ ; responder hcp:0-5 C:5+
</pre>

Mano troppo forte per l'appoggio barrage (fit quinto con 2NT Truscott):
<pre>
Fit quinto con mano forte: declarer:opener contract:4S pairhcp:25-30 opener S:5 hcp:15-18 ; responder S:5+ hcp:9-12
</pre>

== 3. Filtri tecnici (post-filtro con risolutore a carte scoperte) ==

Applicare dopo la generazione strutturale. Soglie indicative da tarare con esempi reali:

* '''Contratto realizzabile ma non banale''': il risolutore trova la linea vincente, e la prima linea "ovvia" (per esempio impasse a prima vista) fallisce nella maggior parte delle posizioni alternative.
* '''Esistenza di una linea ≥ 90 % più alta della naturale''': confrontare le probabilità delle linee; tenere la smazzata se la linea di eliminazione supera la naturale di almeno il 15 %.
* '''Eliminazione necessaria''': dopo aver tolto i colori laterali la difesa deve essere messa in presa e restare senza uscite neutre (verifica: il contratto cade se si salta l'eliminazione).
* '''Una sola linea vincente''' (o pochissime): scartare le mani risolvibili in molti modi.
* '''Coerenza con la licita''': licita ricostruita con le convenzioni del sistema scelto, mai incompatibile con le mani (usare il giudice <code><nowiki>satisfies()</nowiki></code> sulla smazzata finale).
* '''Carta falsa / radiografia''': nelle mani sul conteggio richiedere che le carte da dedurre siano una distribuzione plausibile (almeno due ipotesi alternative con probabilità diverse).

== 4. Come usarli nelle pagine ==

* Un archetipo per pagina di tecnica, come <code><nowiki>shape_constraints</nowiki></code> nel template <code><nowiki>{{Convenzione}}</nowiki></code> o nella pagina della tecnica, con <code><nowiki>shape_roles</nowiki></code> adatti (Dichiarante, Morto, Attaccante, Compagno).
* Le soglie PO nell'archetipo sono punti di partenza: nella pagina si citano quelle della fonte e le mani reali (con <code><nowiki><deal></nowiki></code>) dall'antologia di smazzate, con la fonte citata.
* Per smazzate per la '''difesa''' usare <code><nowiki>declarer:</nowiki></code> e <code><nowiki>lead:</nowiki></code> e descrivere la mano dell'attaccante.

== Fonti ==

* ProgettoBridge, ''Lezione 18 — Gioco di Eliminazione, smazzate esplicative'' (tecniche e temi trattati; gli archetipi qui sopra sono ricostruzioni originali di BridgePedia, non riproduzioni).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Ricette DSL

2026-10-27T19:06:26Z

Lpala: Aggiunto link a Smazzate di gioco

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]]

= BridgeShape — Ricette DSL v2 per gli editor =

Come descrivere con <code><nowiki>shape_constraints</nowiki></code> le situazioni tipiche. Ogni ricetta è verificata dal
parser (<code><nowiki>tests/phpunit/unit/RecipesTest.php</nowiki></code>). I punti sono esempi di partenza: '''le soglie vanno prese dalla fonte citata nella pagina''', non da qui.

Regole: scenari separati da <code><nowiki>//</nowiki></code>; posizioni da <code><nowiki>;</nowiki></code>; <code><nowiki>|</nowiki></code> dentro i template si scrive <code><nowiki>{{!}}</nowiki></code>.
Per ogni pagina con scenari aggiungere <code><nowiki>shape_roles</nowiki></code> se i nomi "Apertore/Compagno" non calzano.

== Apertura e risposta con fit variabile (macro) ==

Un solo testo per entrambi i nobili:
<syntaxhighlight lang="text">
@M=H,S 1${M}-fit: opener ${M}:5+ hcp:12-21; responder ${M}:3+ hcp:6+
</syntaxhighlight>

== Splinter con seme singolo variabile ==

<syntaxhighlight lang="text">
@M=H,S 1${M}: $a=SHDC opener ${M}:5+ hcp:12-21; responder ${M}:4+ $a:0-1 $ahcp:0 hcp:10-15
</syntaxhighlight>
(se <code><nowiki>$a</nowiki></code> deve essere diverso da <code><nowiki>${M}</nowiki></code>, restringere: <code><nowiki>$a=SDC</nowiki></code>.)

== Intervento bicolore su apertura (Landy, Michaels, Cappelletti) ==

Un nobile + un minore, seme dell'apertore escluso con <code><nowiki>not</nowiki></code>:
<syntaxhighlight lang="text">
Michaels nobile+minore: $a=M $b=m opener hcp:12-21 ; opp1 $a:5+ $b:5+ hcp:8-16 ; responder hcp:0-9
</syntaxhighlight>
Landy (5-4 nei nobili):
<syntaxhighlight lang="text">
Landy 5-4 picche: opener shape:balanced hcp:15-17; opp1 S:5 H:4 hcp:8+
Landy 4-5 cuori: opener shape:balanced hcp:15-17; opp1 S:4 H:5 hcp:8+
Landy 5-5: opener shape:balanced hcp:15-17; opp1 S:5+ H:5+ hcp:8+
</syntaxhighlight>

== Avversari che non possono intervenire ==
<syntaxhighlight lang="text">
Avversari quiet: opener hcp:12-21; responder hcp:6+; opp1 quiet; opp2 quiet
Avversari quiet stretti: opener hcp:12-21; responder hcp:6+; opp1 quiet:0-7; opp2 quiet:0-7
</syntaxhighlight>

== Fermate (Lebensohl, Michaels, SA dopo intervento) ==
<syntaxhighlight lang="text">
Lebensohl con fermata: opener shape:balanced hcp:15-17; opp1 S:5+ hcp:8-15; responder stop:S hcp:10+ H:0-3
Lebensohl senza fermata: opener shape:balanced hcp:15-17; opp1 S:5+ hcp:8-15; responder nostop:S hcp:10+
</syntaxhighlight>

== Blackwood / RKCB / richiesta della Dama ==
<syntaxhighlight lang="text">
@M=H,S RKCB-${M}-1o4: opener ${M}:5+ hcp:16+; responder ${M}:3+ kc:${M}1 has:${M}Q
@M=H,S RKCB-${M}-2senzaDama: opener ${M}:5+ hcp:16+; responder ${M}:3+ kc:${M}2 lacks:${M}Q
@M=H,S RKCB-${M}-3: opener ${M}:5+ hcp:16+; responder ${M}:3+ kc:${M}3
Blackwood-2-assi: opener hcp:18+; responder aces:2
</syntaxhighlight>
(<code><nowiki>kc:H1</nowiki></code> = un asso oppure il Re di cuori; l'atout viene dalla macro.)

== Forze con punteggi alternativi ==
<syntaxhighlight lang="text">
Apertura forte per punti totali: opener tp:23+ ; responder hcp:0-7
Aperture a perdenti: opener ltc:5-6 hcp:17+
</syntaxhighlight>

== Alternative di mano senza duplicare gli scenari ==
<syntaxhighlight lang="text">
Smolen: opener shape:balanced hcp:15-17 any(S:3+ H:2-3, H:3+ S:2-3); responder any(S:5 H:4, S:4 H:5) hcp:10+
Mano con almeno un nobile lungo: opener any(S:5+, H:5+) hcp:12-21
Nessun nobile 4+: opener not(S:4+, H:4+) shape:balanced
</syntaxhighlight>

== Confronti e forme ==
<syntaxhighlight lang="text">
Colore più lungo a cuori: opener H>S longest:H hcp:12-21
Bicolore 5-4 qualsiasi: opener shape:5-4-x-x hcp:12-21
Semibilanciata: opener shape:semi_balanced
</syntaxhighlight>

== Barrage / preempt per vulnerabilità e frequenza ==
<syntaxhighlight lang="text">
Preempt in zona sfavorevole: vul:us dealer:opener weight:2 opener H:7 hcp:5-10
</syntaxhighlight>

== Segnali e attacchi (contesto di gioco) ==
<syntaxhighlight lang="text">
Segnale di Smith: declarer:opener contract:4H lead:SK opener H:5+; opp1 S=KQT
Attacco sotto onore: declarer:opener contract:3NT lead:S4 opener hcp:15-17; opp1 S~K.{2,3}
</syntaxhighlight>
(L'attacco deve stare nella mano a sinistra del dichiarante: <code><nowiki>declarer:opener</nowiki></code> → <code><nowiki>opp1</nowiki></code>.)

== Coppia e forza totale ==
<syntaxhighlight lang="text">
Slam: pairhcp:33+ opener hcp:17+ ; responder hcp:14+
</syntaxhighlight>

== Cose da NON fare ==
* Non ripetere uno scenario per ogni nobile: usare <code><nowiki>@M=H,S</nowiki></code>.
* Non usare <code><nowiki>S~</nowiki></code> per esprimere "ha almeno 4 carte": usare <code><nowiki>S:4+</nowiki></code>.
* Non usare <code><nowiki>quiet</nowiki></code> su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> (viene ignorato).
* <code><nowiki>{{!}}</nowiki></code> e non <code><nowiki>|</nowiki></code> dentro i parametri dei template.
* Controllare sempre con <code><nowiki>shapeaction=validate</nowiki></code>: se compaiono <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> lo scenario va corretto.

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Motore e frontend

2026-10-27T19:06:25Z

Lpala: Aggiunto link a Smazzate di gioco

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]]

= BridgeShape — Specifica del motore di smazzate e del frontend (per Play) =

Destinatario: il team/sessione di '''Play''' (generatore di smazzate e relativo frontend).
Obiettivo: realizzare un '''motore completo''' che generi mani per ''qualsiasi'' scenario
descritto nelle pagine di BridgePedia, e un '''frontend''' per consultare gli scenari,
generare, creare e gestire smazzate.

Documenti collegati (leggere in quest'ordine):

# <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code> — riferimento della sintassi (DSL v1 + v2) e del JSON dell'API.
# '''questo file''' — semantica normativa, architettura del motore, test di conformità, specifica del frontend, piano di consegna.
# Wiki: <code><nowiki>Progetto:BridgeShape API</nowiki></code>; le pagine di convenzione con <code><nowiki>shape_constraints</nowiki></code> (elenco: <code><nowiki>GET /api.php?action=bridgeshape&shapeaction=list</nowiki></code>).

Fonte di verità del contratto: l'API <code><nowiki>action=bridgeshape</nowiki></code> di https://bridgepedia.it.
Se questo documento e l'API divergono vale l'API; segnalatelo a BridgePedia.

----

== 1. Contratto, versioni e compatibilità ==

{| class="wikitable"
! Elemento
! Dove
! Uso
|-
| <code><nowiki>dslVersion</nowiki></code>
| risposta di <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code>
| oggi <code><nowiki>2</nowiki></code>. Cambia solo con modifiche non retrocompatibili
|-
| <code><nowiki>scenarios[].requires</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| tag delle capacità richieste dallo scenario (§1.1)
|-
| <code><nowiki>errors</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| contraddizioni semantiche: '''non generare'''
|-
| <code><nowiki>warnings</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| frammenti del DSL scartati dal parser: '''non generare'''
|-
| <code><nowiki>descriptions</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| testo leggibile per scenario, tradotto (<code><nowiki>lang=it|en|...</nowiki></code>)
|-
| <code><nowiki>valid</nowiki></code>
| <code><nowiki>validate</nowiki></code>
| 1/0
|}

Regole di compatibilità:

* I campi nuovi compaiono '''solo se usati''': un motore v1 continua a funzionare sulle pagine v1.
* Campi sconosciuti: ignorarli '''non''' è permesso se compaiono in <code><nowiki>requires</nowiki></code>. Se il motore non supporta un tag di <code><nowiki>requires</nowiki></code>, deve rifiutare lo scenario con codice <code><nowiki>unsupported_feature</nowiki></code> (e nome del tag) e il frontend deve mostrarlo come "non ancora generabile", non nasconderlo.
* Il booleano nel JSON è sempre <code><nowiki>1</nowiki></code>/<code><nowiki>0</nowiki></code> (MediaWiki rimuove i <code><nowiki>false</nowiki></code>).
* Tutte le chiavi di seme sono <code><nowiki>S H D C</nowiki></code> oppure una variabile <code><nowiki>"$a".."$d"</nowiki></code>.

=== 1.1 Tag <code><nowiki>requires</nowiki></code> ===

{| class="wikitable"
! Tag
! Costrutti
! Impatto sul motore
|-
| <code><nowiki>suit_cards</nowiki></code>
| <code><nowiki>S=KJT</nowiki></code>
| assegnazione di onori precisi
|-
| <code><nowiki>suit_patterns</nowiki></code>
| <code><nowiki>S~AKQ.|A...</nowiki></code>
| alternative di mano nel seme
|-
| <code><nowiki>vars</nowiki></code>
| <code><nowiki>$a $b</nowiki></code>, <code><nowiki>vars</nowiki></code>
| seme scelto a runtime, condiviso tra posizioni
|-
| <code><nowiki>stoppers</nowiki></code>
| <code><nowiki>stop:S</nowiki></code>
| filtro/vincolo sulla mano
|-
| <code><nowiki>card_presence</nowiki></code>
| <code><nowiki>has:HQ</nowiki></code>, <code><nowiki>lacks:SK</nowiki></code>
| carte fisse
|-
| <code><nowiki>controls</nowiki></code>
| <code><nowiki>aces kings queens controls kc</nowiki></code>
| conteggi di onori
|-
| <code><nowiki>points</nowiki></code>
| <code><nowiki>tp dp ltc</nowiki></code>
| punteggi derivati
|-
| <code><nowiki>pair_points</nowiki></code>
| <code><nowiki>pairhcp pairtp defhcp</nowiki></code>
| vincolo sulla coppia
|-
| <code><nowiki>compare</nowiki></code>
| <code><nowiki>H>S</nowiki></code>, <code><nowiki>longest:</nowiki></code>
| relazioni tra lunghezze
|-
| <code><nowiki>shape_pattern</nowiki></code>
| <code><nowiki>shape:5-4-x-x</nowiki></code>
| forma ordinata
|-
| <code><nowiki>any_not</nowiki></code>
| <code><nowiki>any(...)</nowiki></code>, <code><nowiki>not(...)</nowiki></code>
| disgiunzioni e negazioni
|-
| <code><nowiki>context</nowiki></code>
| <code><nowiki>dealer vul auction contract declarer lead</nowiki></code>
| metadati e carta d'attacco
|-
| <code><nowiki>weight</nowiki></code>
| <code><nowiki>weight:N</nowiki></code>
| scelta ponderata dello scenario
|}

Le macro <code><nowiki>@M=H,S</nowiki></code> e <code><nowiki>quiet</nowiki></code> sono già espanse dal parser (non compaiono mai).

=== 1.2 Endpoint consigliati lato Play ===

Il motore deve esporre (nomi indicativi; l'importante è la semantica):

<syntaxhighlight lang="text">
POST /api/deals/generate
{
"source": { "page": "Splinter", "scenario": "1H-4C" } // oppure { "dsl": "..." }
| { "page": "Splinter" }, // scenario scelto per peso
"count": 10, // 1..100
"seed": 12345, // opzionale, riproducibilità
"fixed": { "opener": "SAK2.H.D.C", "responder": "..." }, // carte/mani già fissate (§5.6)
"lang": "it"
}
→ 200 { "seed":..., "deals":[ {
"scenario": "1H-4C", "index": 0,
"dealer": "opener", "vul": "none",
"hands": { "opener":"AK2.QJ53.K84.T65", "responder":"...", "opp1":"...", "opp2":"..." },
"bindings": { "$a": "H", "x:opener": "D" }, // come sono state risolte variabili e jolly
"pbn": "[Deal \"N:...\"]", "lin": "...",
"explanation": { "opener": ["♥: 5+ carte", ...], ... }, // dalle descriptions
"stats": { "attempts": 412, "ms": 38 }
} ] }
→ 422 { "code": "...", "reasons": [ {"code":"...", "position":"opp1", "detail":"..."} ] }
GET /api/deals/capabilities → { "dslVersion": 2, "supports": ["suit_cards", ...] }
</syntaxhighlight>

Posizioni → sedi: <code><nowiki>opener</nowiki></code> = Nord per default; il motore ruota in base a <code><nowiki>context.dealer</nowiki></code> solo
per la numerazione/PBN; i vincoli restano sempre in termini di ruoli (<code><nowiki>opener</nowiki></code>, <code><nowiki>responder</nowiki></code>,
<code><nowiki>opp1</nowiki></code> = a sinistra dell'apertore, <code><nowiki>opp2</nowiki></code> = a destra).

----

== 2. Definizioni normative ==

Il motore e il frontend devono usare '''esattamente''' queste definizioni (le descrizioni in
italiano dell'API le presuppongono).

* '''Carte''': A K Q J 10 9 8 7 6 5 4 3 2. Nei vincoli <code><nowiki>T</nowiki></code> = 10. "Carte basse" = 8..2.
* '''PO / HCP''': A=4, K=3, Q=2, J=1. <code><nowiki>Shcp</nowiki></code> ecc. = PO nel solo seme.
* '''Posizioni e coppie''': coppia dichiarante = <code><nowiki>opener</nowiki></code>+<code><nowiki>responder</nowiki></code>; difesa = <code><nowiki>opp1</nowiki></code>+<code><nowiki>opp2</nowiki></code>. Senso di gioco: opener → opp1 → responder → opp2 (orario). Lo stesso per l'attaccante: siede a sinistra del dichiarante (<code><nowiki>declarer</nowiki></code> = opener → attacca opp1; responder → opp2; opp1 → responder; opp2 → opener).
* '''Forma ordinata''': le 4 lunghezze in ordine decrescente (es. 5431).
* '''Classi di forma''' (possono sovrapporsi; le pagine oggi usano solo <code><nowiki>balanced</nowiki></code>):
** <code><nowiki>balanced</nowiki></code>: 4333, 4432, 5332.
** <code><nowiki>semi_balanced</nowiki></code>: 5422, 6322.
** <code><nowiki>one_suiter</nowiki></code>: seme più lungo ≥ 6 e secondo ≤ 3.
** <code><nowiki>two_suiter</nowiki></code>: i due semi più lunghi hanno entrambi ≥ 4 carte e insieme ≥ 9 (5-4, 6-4, 5-5, ...).
** <code><nowiki>three_suiter</nowiki></code>: tre semi ≥ 4 (4441, 5440, 4450...).
** <code><nowiki>any</nowiki></code>: nessun vincolo. Se la vostra implementazione attuale differisce, allineatela a questa o segnalate la differenza.
* '''<code><nowiki>shape_pattern</nowiki></code>''' (<code><nowiki>54xx</nowiki></code>): la forma ordinata deve corrispondere cifra per cifra; <code><nowiki>x</nowiki></code> = qualsiasi.
* '''<code><nowiki>longest:H</nowiki></code>''': la lunghezza di H è ≥ di ogni altro seme (pari merito ammesso).
* '''Confronti''' <code><nowiki>A op B</nowiki></code>: sulle lunghezze dei due semi nella stessa mano; <code><nowiki>==</nowiki></code> uguali.
* '''Controlli''': A=2, K=1 (le dame non contano). <code><nowiki>controls:6+</nowiki></code> somma sulla mano.
* '''Carte chiave per l'atout T''' (<code><nowiki>kc:T</nowiki></code>): numero di assi (0-4) + 1 se possiede il Re di T. Valori 0-5. La Dama di atout si esprime con <code><nowiki>has:TQ</nowiki></code>.
* '''Fermata''' nel seme X (<code><nowiki>stop:X</nowiki></code>): possiede almeno una tra: A; Kx (Re con ≥ 2 carte nel seme); Qxx (Dama con ≥ 3); Jxxx (Fante con ≥ 4). <code><nowiki>nostop:X</nowiki></code> = nessuna di queste.
* '''Punti totali <code><nowiki>tp</nowiki></code>''': PO + (per ogni seme, <code><nowiki>max(0, lunghezza − 4)</nowiki></code>).
* '''Punti distribuzione <code><nowiki>dp</nowiki></code>''': PO + 3 per ogni chicane + 2 per ogni singolo + 1 per ogni doubleton.
* '''Perdenti <code><nowiki>ltc</nowiki></code>''' (Losing Trick Count classico): per ogni seme con <code><nowiki>n</nowiki></code> carte, <code><nowiki>m = min(n,3)</nowiki></code>; perdenti del seme = <code><nowiki>m − [A] − [K e n≥2] − [Q e n≥3]</nowiki></code>; somma sui 4 semi (seme vuoto = 0). Tabella di controllo: x=1, A=0, K=1, Q=1; xx=2, Ax=1, Kx=1, Qx=2, AK=0, AQ=1, KQ=1; AKQ=0, AKx=1, AQx=1, KQx=1, Axx=2, Kxx=2, Qxx=2, xxx=3. (Correzione: la formula precedente <code><nowiki>m − #A,K,Q</nowiki></code> contava anche K e Q secchi o Q doppia.)
* '''<code><nowiki>S=KJT</nowiki></code>''' (<code><nowiki>suit_cards</nowiki></code>): tra A K Q J 10 9 possiede ''esattamente'' quelle elencate; 8..2 liberi. Stringa vuota = nessuna carta alta. Gli onori elencati sono esclusi dalle altre mani solo per quel che riguarda la proprietà: ogni carta ha un unico proprietario.
* '''<code><nowiki>S~...</nowiki></code>''' (<code><nowiki>suit_patterns</nowiki></code>): una sola alternativa (scelta a caso, uniformemente tra quelle compatibili con gli altri vincoli) descrive tutta la mano in quel seme: <code><nowiki>cards</nowiki></code> + tra <code><nowiki>low_min</nowiki></code> e <code><nowiki>low_max</nowiki></code> carte basse (<code><nowiki>low_max: null</nowiki></code> = illimitato, ma ≤ 13 − len(cards)).
* '''<code><nowiki>x:</nowiki></code>''' (jolly di posizione): un seme scelto a caso tra quelli ''non'' vincolati esplicitamente in quella posizione. Dentro una foglia di <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> il jolly vede '''solo i semi nominati nella foglia'''; un seme nominato soltanto in <code><nowiki>fit</nowiki></code>, confronti o <code><nowiki>longest:</nowiki></code> non è escluso da <code><nowiki>x</nowiki></code>; <code><nowiki>xhcp:</nowiki></code> si riferisce allo stesso seme. Il jolly '''non''' è condiviso con altre posizioni.
* '''Variabili <code><nowiki>$a..$d</nowiki></code>''': a inizio generazione ogni variabile usata riceve un seme dal proprio dominio (<code><nowiki>vars</nowiki></code>, default tutti e quattro). Variabili diverse hanno '''semi diversi'''; una variabile non dichiarata ha dominio completo. Una variabile può coincidere con un seme nominato esplicitamente (<code><nowiki>$a</nowiki></code> e <code><nowiki>H</nowiki></code>): se non è voluto, restringere il dominio (<code><nowiki>$a=SD</nowiki></code>). La scelta è uniforme tra le assegnazioni che rendono lo scenario soddisfacibile.
* '''<code><nowiki>fit</nowiki></code>''': somma delle lunghezze dei due compagni nel seme (o in qualunque seme del tipo <code><nowiki>major</nowiki></code>/ <code><nowiki>minor</nowiki></code>/<code><nowiki>any</nowiki></code>, a scelta del motore, uniformemente tra i semi che soddisfano il vincolo).
* '''<code><nowiki>any(A,B)</nowiki></code>''': la mano soddisfa almeno una alternativa. '''<code><nowiki>not(A,B)</nowiki></code>''': non ne soddisfa nessuna. Più gruppi → AND. Dentro <code><nowiki>A</nowiki></code>,<code><nowiki>B</nowiki></code> valgono gli stessi campi di una posizione (senza <code><nowiki>any/not/fit</nowiki></code>).
* '''<code><nowiki>pair_hcp.declarer</nowiki></code>''' = PO(opener)+PO(responder); <code><nowiki>defense</nowiki></code> = PO(opp1)+PO(opp2). <code><nowiki>pair_tp</nowiki></code>: somma <code><nowiki>tp</nowiki></code>.
* '''Posizioni non nominate''': ricevono le carte rimanenti a caso (nessun vincolo); non applicare <code><nowiki>quiet</nowiki></code> implicito.
* '''<code><nowiki>weight</nowiki></code>''': probabilità relativa di scelta dello scenario quando non è scelto dall'utente (default 1). Non influenza la generazione dentro lo scenario.
* '''<code><nowiki>context</nowiki></code>''': metadati. <code><nowiki>dealer</nowiki></code> e <code><nowiki>vul</nowiki></code> (<code><nowiki>us</nowiki></code> = coppia dichiarante) vanno riportati nell'output (PBN/LIN) e mostrati. <code><nowiki>auction</nowiki></code> è la sequenza da mostrare/verificare (notazione BridgeCards: <code><nowiki>P</nowiki></code>, <code><nowiki>X</nowiki></code>, <code><nowiki>XX</nowiki></code>, <code><nowiki>1NT</nowiki></code>...). <code><nowiki>contract</nowiki></code>/<code><nowiki>declarer</nowiki></code>/<code><nowiki>lead</nowiki></code>: vedi §5.7.

----

== 3. Architettura consigliata del motore ==

Pipeline per ogni mano richiesta:

<syntaxhighlight lang="text">
parse risposta API → controllo requires/errors/warnings
→ scelta scenario (utente | peso)
→ ASSEGNAZIONE SIMBOLICA : variabili $a.., jolly x:, fit, alternative any()/S~, pattern di forma
→ MATRICE DELLE LUNGHEZZE : 4 posizioni × 4 semi (somme 13 per riga e per colonna)
→ ASSEGNAZIONE DELLE CARTE : carte fissate/vincolate, poi resto casuale
→ RIPARAZIONE PUNTI : scambi mirati per entrare negli intervalli PO/tp/dp/ltc/controlli
→ VERIFICA FINALE : valutazione indipendente di TUTTI i vincoli sulla smazzata completa
→ output + spiegazione
</syntaxhighlight>

Punti chiave:

# '''Verifica finale indipendente''' (il "giudice"): una funzione pura <code><nowiki>satisfies(deal, scenario, bindings)</nowiki></code> che valuta ogni vincolo dalle definizioni di §2. Ogni smazzata emessa deve passarla. Questa funzione è anche la base dei test e del pulsante "verifica" del frontend.
# '''Costruzione, non solo scarto.''' Il rejection sampling puro non regge scenari stretti (es. Gran rever nel Multirever, <code><nowiki>quiet</nowiki></code> con coppia 25+ PO). Costruire prima la matrice delle lunghezze con propagazione dei vincoli (backtracking con limiti per riga/colonna), poi assegnare le carte onore per posizione secondo <code><nowiki>suit_cards</nowiki></code>/<code><nowiki>suit_patterns</nowiki></code>/<code><nowiki>has</nowiki></code>/<code><nowiki>lacks</nowiki></code>/<code><nowiki>aces</nowiki></code>..., infine le basse.
# '''Riparazione PO''': dopo l'assegnazione, se i PO (o <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, controlli, <code><nowiki>pair_*</nowiki></code>) sono fuori intervallo, scambiare due carte tra due mani preservando lunghezze e vincoli ''rigidi'' (carte fissate, pattern). Ricerca locale con budget; poi nuovo tentativo dall'inizio.
# '''Uniformità''': l'obiettivo è una distribuzione quasi uniforme tra le smazzate che soddisfano lo scenario. Le euristiche di costruzione introducono distorsioni: misuratele (§7.3) e non dichiarate "uniformi" se non lo sono.
# '''Budget e fallimenti''': limite di tempo (oggi 2,5 s CPU/mano), massimo tentativi, e diagnosi. Su fallimento restituire 422 con i <code><nowiki>reasons</nowiki></code> di §6, mai una smazzata che viola i vincoli.
# '''Riproducibilità''': stesso <code><nowiki>seed</nowiki></code> + stessa versione del DSL → stessa smazzata. Salvare nel record <code><nowiki>seed</nowiki></code>, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>source.page</nowiki></code>, <code><nowiki>revid</nowiki></code> della pagina se disponibile.
# '''Concorrenza e cache''': cache del JSON dell'API per pagina con TTL breve (60 s) e rivalidazione sulla <code><nowiki>list</nowiki></code>; mai servire DSL non validato.

=== 3.1 Ordine di risoluzione dei vincoli ===

# Variabili <code><nowiki>$a..</nowiki></code>, jolly <code><nowiki>x:</nowiki></code>, <code><nowiki>fit</nowiki></code> (decidono ''quali'' semi).
# Alternative: scegliere un ramo per ogni <code><nowiki>any()</nowiki></code> e ogni <code><nowiki>S~</nowiki></code> (escludendo i rami impossibili con i vincoli già noti); applicare <code><nowiki>not()</nowiki></code> come vincoli di esclusione.
# Lunghezze (<code><nowiki>suits</nowiki></code>, <code><nowiki>compare</nowiki></code>, <code><nowiki>longest</nowiki></code>, <code><nowiki>shape</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>fit</nowiki></code>).
# Carte precise (<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>cards_held/not_held</nowiki></code>, <code><nowiki>lead</nowiki></code>).
# Conteggi (<code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code>, <code><nowiki>keycards</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>).
# Punteggi derivati (<code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, <code><nowiki>pair_*</nowiki></code>) e <code><nowiki>stoppers</nowiki></code>.
# Verifica finale.

Un vincolo è "rigido" se riguarda carte/lunghezze fissate (1-4); "morbido" se si ripara per scambio (5-6).

----

== 4. Semantica delle combinazioni delicate ==

* <code><nowiki>quiet</nowiki></code> è già espanso in <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>: nessun trattamento speciale (il campo <code><nowiki>quiet: 1</nowiki></code> serve solo alla descrizione). Una difesa quiet '''riduce''' il margine PO per la coppia dichiarante: verificare la compatibilità prima di costruire (<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>...).
* <code><nowiki>S=...</nowiki></code> / <code><nowiki>S~...</nowiki></code> + <code><nowiki>S:N</nowiki></code> + <code><nowiki>Shcp</nowiki></code>: devono essere coerenti; l'API segnala le contraddizioni evidenti.
* Una carta (<code><nowiki>has:HQ</nowiki></code>) può comparire in una sola posizione; due posizioni con la stessa carta sono un errore di validazione, non un caso da risolvere a caso.
* <code><nowiki>any()</nowiki></code> dentro una posizione con variabili: le variabili si legano '''prima''', poi si sceglie il ramo.
* <code><nowiki>not()</nowiki></code> con <code><nowiki>S~</nowiki></code>: escludere dall'insieme di alternative, non solo filtrare a posteriori.
* <code><nowiki>longest:</nowiki></code> e <code><nowiki>compare</nowiki></code> valgono sulle lunghezze finali (dopo il bind delle variabili).
* <code><nowiki>context.lead</nowiki></code> (<code><nowiki>SK</nowiki></code>): la carta deve stare nella mano dell'attaccante (§2) e quella mano deve soddisfare i suoi vincoli (es. se ha <code><nowiki>S=KJT</nowiki></code>, <code><nowiki>lead:SJ</nowiki></code> è coerente, <code><nowiki>lead:SQ</nowiki></code> no).

=== Chiarimenti (concordati con Play) ===

* '''<code><nowiki>context.auction</nowiki></code>''': la sequenza parte dal '''mazziere''' (<code><nowiki>dealer</nowiki></code>); il primo token è la sua chiamata. Se <code><nowiki>dealer</nowiki></code> manca, l'asta è solo descrittiva e non si verifica nulla. Nella v2 l'asta e <code><nowiki>contract</nowiki></code> sono '''informativi''': il motore non deve ricavarne vincoli sulle mani.
* '''<code><nowiki>declarer</nowiki></code>''': non deve discendere dall'asta (non verificata). Serve a stabilire chi attacca (vedi §2) e quindi a validare <code><nowiki>lead</nowiki></code>.
* '''<code><nowiki>errors</nowiki></code>''': array di '''stringhe''' <code><nowiki>"<etichetta scenario o 'scenario #N'>: <messaggio in inglese>"</nowiki></code>, senza codici né struttura. Il motore li riporta così come sono (codice proprio <code><nowiki>dsl_errors</nowiki></code>, §6). Un formato strutturato (<code><nowiki>code</nowiki></code>, <code><nowiki>scenario</nowiki></code>, <code><nowiki>position</nowiki></code>) è una possibile evoluzione: lo si introdurrebbe come campo nuovo <code><nowiki>errorDetails</nowiki></code>, senza toccare <code><nowiki>errors</nowiki></code>.
* '''<code><nowiki>descriptions</nowiki></code>''': oggi un elemento per scenario con <code><nowiki>positions</nowiki></code> (testo per posizione) e <code><nowiki>context</nowiki></code>; '''non esiste un id per singolo vincolo'''. Se il frontend lo richiede, si aggiungerà un campo additivo (da concordare, §11).
* '''«Uniforme»''' (variabili, jolly, <code><nowiki>fit</nowiki></code>): tra le assegnazioni di semi che rendono lo scenario soddisfacibile, ciascuna ha uguale probabilità (a meno di tolleranza statistica nei test: ±5 % su 1000 estrazioni per due valori, vedi caso 3). Non implica uniformità sulle carte o sulle mani.

----

== 5. Funzionalità del motore (elenco completo da realizzare) ==

=== 5.1 Core (parità v1) — già in produzione, da conservare ===
Lunghezze, PO totali/per seme, <code><nowiki>x:</nowiki></code>, <code><nowiki>shape:</nowiki></code>, <code><nowiki>fit</nowiki></code>, <code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>quiet</nowiki></code>
(espanso), 422 con ragioni, tetto 2,5 s.

=== 5.2 Nuove funzioni DSL v2 ===
Tutte le righe di §1.1. Priorità di consegna in §9.

=== 5.3 Mani multiple e serie ===
<code><nowiki>count</nowiki></code> ≤ 100 per richiesta; opzione <code><nowiki>distinct: true</nowiki></code> (nessuna mano duplicata nella serie);
opzione <code><nowiki>balance: "round_robin" | "weighted"</nowiki></code> per distribuire gli scenari della stessa convenzione.

=== 5.4 Spiegazione per mano ===
Per ogni smazzata: per posizione, elenco dei vincoli con esito (✓) e valore effettivo
("♥: 5 carte, richiesto 5+"), e i '''binding''' (<code><nowiki>$a = ♥</nowiki></code>, <code><nowiki>x di opener = ♦</nowiki></code>). Serve al frontend.

=== 5.5 Verifica di una smazzata data ===
<code><nowiki>POST /api/deals/check</nowiki></code> con quattro mani e una <code><nowiki>source</nowiki></code> → elenco di vincoli soddisfatti/violati.
Usa lo stesso giudice del §3. Serve a: smazzate inserite a mano, correzione in aula, test.

=== 5.6 Mani parzialmente fissate (<code><nowiki>fixed</nowiki></code>) ===
Accettare mani complete o parziali (<code><nowiki>"opener": "SAK2."</nowiki></code>, o carte singole) e completare il resto
rispettando lo scenario. Se impossibile → 422 <code><nowiki>fixed_cards_conflict</nowiki></code>.

=== 5.7 Contesto di gioco della carta ===
<code><nowiki>contract</nowiki></code>, <code><nowiki>declarer</nowiki></code>, <code><nowiki>lead</nowiki></code>: il motore garantisce che la carta d'attacco sia nella mano giusta e
fornisce nel risultato <code><nowiki>play: { "contract":"4H", "declarer":"responder", "leader":"opp2", "lead":"SK" }</nowiki></code>.
(Il gioco successivo, oltre la prima carta, non è nel DSL: per Segnali e Attacchi la prima carta e le
mani bastano a mostrare la situazione.)

=== 5.8 Statistiche ===
Per scenario: tasso di successo, tentativi medi, p95 ms, codici di fallimento. Esposte in
<code><nowiki>GET /api/deals/stats</nowiki></code> e inviate a BridgePedia (§8.5) per tarare i vincoli.

----

== 6. Codici di errore (422 e simili) ==

Già in uso: <code><nowiki>exact_cards_always_conflict</nowiki></code>, <code><nowiki>generation_time_limit</nowiki></code>, <code><nowiki>suit_cards_below_hcp_min</nowiki></code>,
<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>, <code><nowiki>suit_cards_exceed_hcp_max</nowiki></code>. Da aggiungere:

{| class="wikitable"
! Codice
! Quando
|-
| <code><nowiki>unsupported_feature</nowiki></code>
| lo scenario richiede un tag non supportato (<code><nowiki>detail</nowiki></code>: il tag)
|-
| <code><nowiki>dsl_errors</nowiki></code>
| l'API ha restituito <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> (riportarli)
|-
| <code><nowiki>variable_unsatisfiable</nowiki></code>
| nessuna assegnazione dei semi variabili rende lo scenario possibile
|-
| <code><nowiki>fixed_cards_conflict</nowiki></code>
| <code><nowiki>fixed</nowiki></code> contraddice lo scenario o carte duplicate
|-
| <code><nowiki>pair_points_unreachable</nowiki></code>
| <code><nowiki>pairhcp/pairtp</nowiki></code> incompatibili con i limiti per posizione
|-
| <code><nowiki>lead_conflict</nowiki></code>
| <code><nowiki>lead</nowiki></code> incompatibile con la mano dell'attaccante
|-
| <code><nowiki>no_branch_left</nowiki></code>
| <code><nowiki>any()</nowiki></code>/<code><nowiki>S~</nowiki></code>/<code><nowiki>not()</nowiki></code> eliminano tutti i rami
|-
| <code><nowiki>shape_unreachable</nowiki></code>
| forma/lunghezze incompatibili con 13 carte per mano e per seme
|-
| <code><nowiki>invalid_request</nowiki></code>
| parametri non validi (count, seed...)
|}

Ogni 422 porta <code><nowiki>reasons: [{code, position?, detail}]</nowiki></code> leggibili dal frontend.

----

== 7. Test di conformità e qualità ==

=== 7.1 Invarianti (property test, ≥ 10.000 smazzate per scenario del wiki) ===
* 52 carte distinte; 13 per mano; nessun duplicato.
* <code><nowiki>satisfies()</nowiki></code> vero per ogni smazzata emessa (il giudice '''non''' deve condividere codice con il generatore).
* Stesso seed → stesso risultato.

=== 7.2 Casi minimi per costrutto (la DSL → cosa deve valere) ===

{| class="wikitable"
! #
! DSL
! Asserzione
|-
| 1
| <code><nowiki>opener S:5+ hcp:12-21</nowiki></code>
| ♠ ≥ 5, PO in intervallo
|-
| 2
| <code><nowiki>@M=H,S opener ${M}:5+</nowiki></code>
| due scenari generabili (<code><nowiki>H</nowiki></code>, <code><nowiki>S</nowiki></code>)
|-
| 3
| <code><nowiki>$a=M opener $a:5+; responder $a:3+</nowiki></code>
| in ogni mano: un nobile ≥5 in opener, lo stesso seme ≥3 in responder; entrambi i nobili compaiono su 1000 mani
|-
| 4
| <code><nowiki>$a=M $b=m opener $a:5+ $b:4+</nowiki></code>
| $a nobile, $b minore, mai lo stesso seme
|-
| 5
| <code><nowiki>opener stop:S</nowiki></code> su 1000 mani
| tutte le mani hanno A, Kx, Qxx o Jxxx a ♠
|-
| 6
| <code><nowiki>opener nostop:S S:3+</nowiki></code>
| nessuna mano con A, né Kx, Qxx o Jxxx a ♠ (con 3 carte: né A, né K, né Q)
|-
| 7
| <code><nowiki>opener aces:2 kc:H3</nowiki></code>
| 2 assi; assi + K♥ = 3 (<code><nowiki>kc:H4</nowiki></code> con <code><nowiki>aces:2</nowiki></code> è impossibile: max 2+1)
|-
| 8
| <code><nowiki>opener has:HQ lacks:SK</nowiki></code>
| Q♥ presente, K♠ assente
|-
| 9
| <code><nowiki>opener tp:20-22</nowiki></code>
| <code><nowiki>tp</nowiki></code> corretto con la definizione di §2
|-
| 10
| <code><nowiki>opener ltc:6-7</nowiki></code>
| LTC con la definizione di §2
|-
| 11
| <code><nowiki>opener H>S</nowiki></code> e <code><nowiki>opener H>=S longest:H</nowiki></code>
| confronti rispettati; <code><nowiki>longest</nowiki></code> con pari merito
|-
| 12
| <code><nowiki>opener shape:5-4-x-x</nowiki></code>
| 5 e 4 come due semi più lunghi in ordine; gli altri due sommano 4
|-
| 13
| <code><nowiki>opener shape:semi_balanced</nowiki></code>
| solo 5422 e 6322
|-
| 14
| <code><nowiki>opener any(S:5+, H:5+)</nowiki></code>
| almeno un nobile ≥ 5
|-
| 15
| <code><nowiki>opener not(S:4+, H:4+)</nowiki></code>
| nessun nobile ≥ 4
|-
| 16
| <code><nowiki>opener any(S:4+ hcp:12+, H:4+)</nowiki></code>
| rami composti
|-
| 17
| <code><nowiki>pairhcp:25+ ... opp1 quiet; opp2 quiet</nowiki></code>
| coppia ≥ 25, avversari entro i limiti quiet
|-
| 18
| <code><nowiki>weight:1 ... // weight:3 ...</nowiki></code>
| 1000 estrazioni ~ 25%/75% (± tolleranza)
|-
| 19
| <code><nowiki>dealer:opp1 vul:both</nowiki></code>
| output con dealer/vul corretti e PBN ruotato
|-
| 20
| <code><nowiki>declarer:responder lead:SJ opp2 S=KJT</nowiki></code>
| J♠ in opp2; con <code><nowiki>lead:SQ</nowiki></code> → 422 <code><nowiki>lead_conflict</nowiki></code>
|-
| 21
| <code><nowiki>fixed</nowiki></code> con Q♥ in opener
| opener ha Q♥ e rispetta lo scenario
|-
| 22
| scenario impossibile (<code><nowiki>S=AK Shcp:0-2</nowiki></code>)
| 422 con ragione
|-
| 23
| scenario con <code><nowiki>unsupported</nowiki></code> simulato
| 422 <code><nowiki>unsupported_feature</nowiki></code>
|}

Aggiungere come test di regressione '''tutti gli scenari reali''' delle pagine del wiki
(<code><nowiki>shapeaction=list</nowiki></code> → <code><nowiki>get</nowiki></code>): per ciascuno ≥ 1000 smazzate valide entro il budget, oppure una
diagnosi documentata. Gli scenari più duri oggi: ''Multirever'' (Gran rever, 20 scenari) e
''Segnale di Smith'' (20 scenari con <code><nowiki>suit_cards</nowiki></code>).

=== 7.3 Qualità statistica ===
Per ogni scenario del wiki misurare su 5000 mani: distribuzione delle lunghezze e dei PO nei limiti
consentiti, tasso di riuscita al primo tentativo, tempo p50/p95. Segnalare distorsioni evidenti
(es. la posizione A prende sempre i PO alti).

=== 7.4 Prestazioni ===
Obiettivo: p95 < 300 ms per mano sugli scenari comuni; < 2,5 s sul peggiore. Se non si rispetta,
non allargare i vincoli: segnalare lo scenario a BridgePedia (§8.5) che può rivederlo.

----

== 8. Frontend di Play ==

Il frontend deve permettere di '''consultare''', '''generare''', '''creare''' e '''gestire''' smazzate.
Lingua: italiano, con i18n predisposta (en, fr, es, de). Tutti i testi dei vincoli vengono
dall'API (<code><nowiki>descriptions</nowiki></code>, parametro <code><nowiki>lang</nowiki></code>): non riscriverli.

=== 8.1 Catalogo delle convenzioni ===
* Elenco da <code><nowiki>shapeaction=list</nowiki></code> (con vincoli) e <code><nowiki>listall</nowiki></code> (tutte, con <code><nowiki>hasShape</nowiki></code>).
* Per ogni voce: titolo, numero di scenari, link alla pagina del wiki, stato: ''generabile'', ''parzialmente generabile'' (alcuni scenari con <code><nowiki>requires</nowiki></code> non supportato), ''non generabile''.
* Ricerca testuale; filtri per tipologia/sistema se esposti; badge "da verificare" per le traduzioni non verificate.
* Le 27 convenzioni senza vincoli compaiono come "scenari in arrivo" con link al wiki.

=== 8.2 Visualizzatore di scenario ===
* Tabella a colonne per posizione (come la tabella del wiki): etichetta scenario, frasi di <code><nowiki>descriptions[i].positions</nowiki></code>, <code><nowiki>positionLabels</nowiki></code> (rispettare i ruoli personalizzati, es. "Attaccante"), <code><nowiki>fit</nowiki></code>, <code><nowiki>context</nowiki></code>.
* Semi ♥ ♦ in rosso. Mostrare <code><nowiki>requires</nowiki></code> come chip (tooltip con spiegazione).
* Pulsante "Mostra DSL" (testo <code><nowiki>raw</nowiki></code>) e "Apri la pagina nel wiki".

=== 8.3 Generatore ===
* Scelta convenzione → scenario (singolo, "a caso", "tutti a rotazione", pesato) → quantità (1-100) → opzioni (seed, mani distinte, nascondi avversari).
* Risultato: schede smazzata con 4 mani (formato BridgeCards: ♠♥♦♣, bordi, dealer, vulnerabilità), etichetta scenario, '''pannello "perché questa mano"''': per posizione le frasi di <code><nowiki>explanation</nowiki></code> con spunta, binding (<code><nowiki>$a = ♥</nowiki></code>), PO/lunghezze effettive.
* Azioni per smazzata: rigenera, "blocca questa mano e rigenera le altre" (usa <code><nowiki>fixed</nowiki></code>), copia link con seed, esporta PBN/LIN/immagine, aggiungi alla raccolta.
* Se la licita <code><nowiki>auction</nowiki></code> è presente: mostrarla con <code><nowiki><bidding></nowiki></code> (stile BridgeCards) o nascosta per esercizio ("indovina la risposta").
* Gestione 422: messaggio per codice (§6) con suggerimento ("lo scenario è impossibile perché..."). Per <code><nowiki>unsupported_feature</nowiki></code>: spiegare quale capacità manca.

=== 8.4 Editor / creazione di scenari ===
Due modalità sincronizzate:

# '''Modulo guidato''' per posizione (Apertore, Compagno, Avv. sinistro, Avv. destro):
#* lunghezze per seme (slider min-max), PO totali e per seme, forma (classi + schema <code><nowiki>5-4-x-x</nowiki></code>);
#* griglia carte per seme (A K Q J 10 9 + "basse") con stati ''deve avere / non deve avere / indifferente'' che produce <code><nowiki>S=...</nowiki></code>; costruttore di pattern per <code><nowiki>S~</nowiki></code> con anteprima;
#* interruttori: fermata (per seme), assi/re/dame/controlli, carte chiave con atout, <code><nowiki>tp/dp/ltc</nowiki></code>, confronti tra semi, <code><nowiki>any(...)</nowiki></code>/<code><nowiki>not(...)</nowiki></code> come gruppi aggiungibili;
#* variabili di seme <code><nowiki>$a..$d</nowiki></code> con dominio (nobili/minori/qualsiasi);
#* contesto: dealer, vulnerabilità, licita, contratto, attacco, peso;
#* avversari: pulsante '''quiet''' (e <code><nowiki>quiet:max</nowiki></code>);
#* macro: "ripeti per ogni nobile / minore / seme" genera <code><nowiki>@M=...</nowiki></code>.
# '''Editor testuale''' del DSL con evidenziazione, completamento e ''validazione live'': chiama <code><nowiki>shapeaction=validate</nowiki></code> (debounce 400 ms) e mostra <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>, <code><nowiki>descriptions</nowiki></code> e <code><nowiki>requires</nowiki></code> (con il supporto del motore). Le due modalità si convertono a vicenda (modulo → DSL è obbligatorio; DSL → modulo almeno per i costrutti elementari, il resto resta testuale).

* Pulsante "Prova": genera 5 mani di test dallo scenario in modifica e mostra tempi e tassi di riuscita.
* Salvataggio come '''bozza personale''' in Play (non scrive sul wiki). Pulsante "Copia per BridgePedia" produce la riga <code><nowiki>shape_constraints</nowiki></code> da incollare nella pagina (gli editor del wiki fanno il resto).
* Libreria di '''modelli''' presi dalle convenzioni del wiki ("parti da Landy").

=== 8.5 Retroazione verso BridgePedia ===
* Pulsante "Segnala scenario problematico" (lento / troppo raro / 422 / distribuzione strana) che invia: pagina, scenario, <code><nowiki>dslVersion</nowiki></code>, codice errore, statistiche (§5.8) al canale concordato (sessione/issue). Nessuna scrittura diretta sul wiki.
* Report periodico automatico delle statistiche di generazione per scenario.

=== 8.6 Smazzate manuali ===
* Compositore: assegnare le 52 carte alle quattro mani con trascinamento o digitazione (<code><nowiki>AK2.QJ5.K84.T65</nowiki></code>), controllo duplicati, completamento casuale delle carte mancanti (opzionalmente rispettando uno scenario: usa <code><nowiki>fixed</nowiki></code>).
* Pulsante "Verifica rispetto a uno scenario" (§5.5) con l'elenco dei vincoli soddisfatti e violati.
* Importa/esporta PBN, LIN, testo semplice.

=== 8.7 Gestione delle smazzate ===
* Raccolte ("mazzi di esercizio"): nome, descrizione, convenzione, tag; ordinamento; duplicati evitati.
* Ricerca per convenzione, scenario, tag, data; filtri per vulnerabilità, dealer.
* Metadati salvati: <code><nowiki>seed</nowiki></code>, <code><nowiki>source.page</nowiki></code>, scenario, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>revid</nowiki></code>, data, autore.
* Note personali per smazzata; stampa di una raccolta (fogli A4 con 4 o 6 smazzate per pagina, versione "solo mano dell'apertore" per esercizio).
* Condivisione: link con seed/raccolta, permessi (privato, gruppo, pubblico) secondo il modello utenti di Play. Esportazione in blocco (PBN).
* Modalità "esercizio di licita": mostra le mani di un lato, l'utente inserisce la licita, il frontend confronta con <code><nowiki>context.auction</nowiki></code> se presente.

=== 8.8 Requisiti trasversali ===
* Mobile first; tastiera accessibile; semi anche come lettere per daltonici.
* Nessuna dipendenza dal wiki per il rendering delle carte (usare componenti propri; stile coerente con BridgeCards).
* Tempi: la generazione deve mostrare avanzamento e poter essere annullata.
* Tracciare (analytics interni) tempi, errori e scenari più usati.
* Testo dei vincoli sempre da <code><nowiki>descriptions</nowiki></code> con <code><nowiki>lang</nowiki></code> coerente con la lingua dell'interfaccia.

----

== 9. Piano di consegna consigliato ==

{| class="wikitable"
! Fase
! Contenuto
! Esito atteso
|-
| '''P0 — compatibilità''' (subito)
| leggere <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>requires</nowiki></code>, <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>; esporre <code><nowiki>/capabilities</nowiki></code>; rifiutare con <code><nowiki>unsupported_feature</nowiki></code>; giudice <code><nowiki>satisfies()</nowiki></code> per v1
| nessuna smazzata errata con le pagine nuove
|-
| '''P1 — core v2'''
| macro (nessun lavoro, già espanse), <code><nowiki>weight</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, classi nuove, <code><nowiki>compare</nowiki></code>/<code><nowiki>longest</nowiki></code>, <code><nowiki>any/not</nowiki></code>, <code><nowiki>pair_*</nowiki></code>
| scenari per Landy/Cappelletti/DONT/Smolen con forme e alternative
|-
| '''P2 — variabili e carte'''
| <code><nowiki>vars</nowiki></code> condivise tra posizioni, <code><nowiki>has/lacks</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>aces/kings/queens/controls/kc</nowiki></code>
| Michaels, Sputnik, Lebensohl, Blackwood/RKCB, Exclusion
|-
| '''P3 — punteggi'''
| <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>
| sistemi a forza (Fiori forte, 2♣ forte, Gazzilli)
|-
| '''P4 — frontend lettura'''
| catalogo, visualizzatore, generatore con spiegazioni
| tutti possono provare le convenzioni
|-
| '''P5 — frontend creazione'''
| editor guidato + testuale con validazione live, "Prova", bozze
| gli editor creano e collaudano scenari senza il wiki
|-
| '''P6 — gestione'''
| raccolte, smazzate manuali, <code><nowiki>check</nowiki></code>, <code><nowiki>fixed</nowiki></code>, esportazioni, esercizi di licita
| uso didattico completo
|-
| '''P7 — qualità'''
| suite di conformità (§7), statistiche, report verso BridgePedia
| motore misurabile
|}

Ogni fase deve chiudersi con i test di §7 per i costrutti introdotti. BridgePedia estende le
pagine del wiki man mano che i tag diventano disponibili: '''comunicate a ogni fase la lista dei tag supportati''' (<code><nowiki>/capabilities</nowiki></code>) così il wiki passa dalle approssimazioni (pattern <code><nowiki>S~</nowiki></code>) ai
costrutti nativi solo quando il motore li regge.

----

== 10. Cosa fa BridgePedia (per non sovrapporsi) ==

* Mantiene il DSL, il parser, le descrizioni e l'API; aggiunge costrutti su richiesta motivata.
* Scrive e tiene aggiornati gli scenari nelle pagine delle convenzioni; le 27 mancanti saranno coperte via via con i costrutti v2.
* Fornisce il catalogo di ricette (come descrivere Landy, Blackwood, un attacco sotto onore...).
* Riceve da Play le segnalazioni di §8.5 e rivede i vincoli troppo duri.

== 11. Decisioni aperte (da concordare con Play) ==

# Definizione definitiva delle classi di forma (§2) rispetto a quanto già implementato.
# Formato di <code><nowiki>explanation</nowiki></code> (testo semplice vs struttura con esito per vincolo).
# Modello di persistenza e permessi delle raccolte (utenti Play).
# Canale per le segnalazioni verso BridgePedia (§8.5).
# Se <code><nowiki>fixed</nowiki></code> deve accettare anche vincoli aggiuntivi temporanei (override locali dello scenario).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape API

2026-10-27T19:06:24Z

Lpala: Aggiunto link a Smazzate di gioco

Documentazione BridgeShape: [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]] · [[Progetto:BridgeShape Smazzate di gioco|Smazzate di gioco]]

= BridgeShape — API per Generatori di Smazzate =

Documentazione tecnica per chi sviluppa un generatore di smazzate di test
che legge i vincoli di distribuzione (shape constraints) dalle convenzioni
di BridgePedia.

== Panoramica ==

Ogni pagina wiki di convenzione su BridgePedia può definire nel template
<code><nowiki>{{Convenzione}}</nowiki></code> un campo <code><nowiki>shape_constraints</nowiki></code> che descrive, in un formato
DSL compatto, i vincoli di distribuzione delle mani dei 4 giocatori al tavolo.

L'estensione '''BridgeShape''' espone un'API REST/JSON per leggere questi
vincoli in modo strutturato.

----

== API Endpoint ==

<syntaxhighlight lang="text">
GET /api.php?action=bridgeshape&shapeaction=ACTION&format=json
</syntaxhighlight>

=== Azioni disponibili ===

{| class="wikitable"
! Azione
! Descrizione
! Parametri
|-
| <code><nowiki>get</nowiki></code>
| Vincoli per una singola convenzione
| <code><nowiki>pageid</nowiki></code> oppure <code><nowiki>title</nowiki></code>
|-
| <code><nowiki>list</nowiki></code>
| Elenco convenzioni con vincoli definiti
| —
|-
| <code><nowiki>listall</nowiki></code>
| Elenco tutte le convenzioni (con/senza vincoli)
| —
|-
| <code><nowiki>validate</nowiki></code>
| Valida una stringa DSL senza bisogno di una pagina wiki
| <code><nowiki>dsl</nowiki></code>
|}

=== Esempi di chiamata ===

<syntaxhighlight lang="bash">
# Per titolo pagina
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&title=Splinter&format=json"

# Per page ID
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&pageid=42&format=json"

# Elenco pagine con vincoli
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=list&format=json"

# Validare una stringa DSL
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=validate&dsl=opener+H:5%2B+hcp:12-21&format=json"
</syntaxhighlight>

----

== Formato risposta JSON ==

=== <code><nowiki>shapeaction=get</nowiki></code> ===

<syntaxhighlight lang="json">
{
"shapeconstraints": {
"pageId": 42,
"raw": "1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 // ...",
"scenarios": [
{
"label": "1H-4C",
"positions": {
"opener": {
"suits": {
"H": { "min": 5, "max": null }
},
"hcp": { "min": 12, "max": 21 }
},
"responder": {
"suits": {
"H": { "min": 4, "max": null },
"C": { "min": 0, "max": 1 }
},
"suit_hcp": {
"C": { "min": 0, "max": 0 }
},
"hcp": { "min": 10, "max": 15 }
}
},
"fit": []
}
]
}
}
</syntaxhighlight>

'''Descrizioni leggibili.''' Insieme a <code><nowiki>scenarios</nowiki></code>, <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono
<code><nowiki>descriptions</nowiki></code> (stesso ordine): per ogni scenario <code><nowiki>label</nowiki></code>, <code><nowiki>positions</nowiki></code>
(per posizione, elenco di frasi già tradotte, es. <code><nowiki>"♠: ha K J 10 (e non A Q 9)"</nowiki></code>),
<code><nowiki>positionLabels</nowiki></code> (nome del ruolo, es. "Attaccante" se la pagina ha <code><nowiki>shape_roles</nowiki></code>;
altrimenti "Apertore (chi usa la convenzione)", "Compagno", ...) e <code><nowiki>fit</nowiki></code>.
Parametro opzionale <code><nowiki>lang</nowiki></code> (it, en, ...; default lingua dell'API, di solito <code><nowiki>it</nowiki></code>).
Serve a mostrare nell'interfaccia di Play '''perché''' la mano è fatta così.
Nella posizione compare anche <code><nowiki>quiet: 1</nowiki></code> se è stata usata la macro <code><nowiki>quiet</nowiki></code>.

=== <code><nowiki>shapeaction=list</nowiki></code> ===

<syntaxhighlight lang="json">
{
"pages": [
{
"pageId": 42,
"title": "Splinter",
"scenarioCount": 6,
"labels": ["1H-4C", "1H-4D", "1H-4S", "1S-4C", "1S-4D", "1S-4H"]
},
{
"pageId": 15,
"title": "Stayman",
"scenarioCount": 2,
"labels": ["fit a cuori", "fit a picche"]
}
]
}
</syntaxhighlight>

----

== Formato DSL ==

Il DSL (Domain Specific Language) è la stringa scritta nel campo
<code><nowiki>shape_constraints</nowiki></code> del template wiki.

=== Struttura ===

<syntaxhighlight lang="text">
etichetta: vincoli posizione; vincoli posizione // etichetta: vincoli // ...
</syntaxhighlight>

* '''<code><nowiki>//</nowiki></code>''' separa gli scenari (il generatore ne sceglie uno random o li presenta all'utente)
* '''<code><nowiki>;</nowiki></code>''' separa le posizioni dentro uno scenario
* Ogni scenario ha un''''etichetta''' opzionale seguita da <code><nowiki>:</nowiki></code>
* Ogni posizione inizia col nome del ruolo, seguito da vincoli separati da spazi

=== Posizioni ===

{| class="wikitable"
! Nome
! Ruolo
|-
| <code><nowiki>opener</nowiki></code>
| Chi apre o fa la prima licita convenzionale
|-
| <code><nowiki>responder</nowiki></code>
| Il compagno dell'opener
|-
| <code><nowiki>opp1</nowiki></code>
| Avversario a sinistra dell'opener
|-
| <code><nowiki>opp2</nowiki></code>
| Avversario a destra dell'opener (compagno di opp1)
|}

=== Vincoli ===

==== Lunghezza seme (specifico) ====

<syntaxhighlight lang="text">
S:5+ — almeno 5 picche
H:0-1 — 0 o 1 cuori
D:3 — esattamente 3 quadri
C:2-5 — da 2 a 5 fiori
</syntaxhighlight>

Semi: <code><nowiki>S</nowiki></code> = Spades/Picche, <code><nowiki>H</nowiki></code> = Hearts/Cuori, <code><nowiki>D</nowiki></code> = Diamonds/Quadri, <code><nowiki>C</nowiki></code> = Clubs/Fiori

==== Lunghezza seme (wildcard) ====

<syntaxhighlight lang="text">
x:0-1 — un seme qualsiasi (tra quelli non specificati) con 0-1 carte
x:6+ — un seme non specificato con almeno 6 carte
</syntaxhighlight>

Il generatore sceglie casualmente quale seme assegnare a <code><nowiki>x</nowiki></code> tra quelli
non già vincolati esplicitamente (S/H/D/C).

==== HCP totali ====

<syntaxhighlight lang="text">
hcp:15-17 — da 15 a 17 punti onore
hcp:12+ — almeno 12 punti
hcp:0-7 — da 0 a 7 punti
</syntaxhighlight>

==== HCP nel seme (specifico) ====

<syntaxhighlight lang="text">
Shcp:3+ — almeno 3 HCP a picche
Chcp:0 — 0 HCP a fiori (nessun onore)
Hhcp:0-2 — da 0 a 2 HCP a cuori
</syntaxhighlight>

==== HCP nel seme (wildcard) ====

<syntaxhighlight lang="text">
xhcp:0 — 0 HCP nel seme wildcard (x)
xhcp:0-1 — 0-1 HCP nel seme x
</syntaxhighlight>

==== Shape class ====

<syntaxhighlight lang="text">
shape:balanced — distribuzione bilanciata (4333, 4432, 5332)
shape:semi_balanced — semibilanciata (5422, 6322)
shape:one_suiter — monocolore
shape:two_suiter — bicolore
shape:three_suiter — tricolore
shape:any — qualsiasi (default)
</syntaxhighlight>

==== Onori esatti in un seme (<code><nowiki>S=KJT</nowiki></code>) ====

<syntaxhighlight lang="text">
S=KJT — in picche ha K, J e 10; NON ha A, Q, 9 (le carte basse 8-2 completano)
S=KT9 — sequenza interna: K, 10, 9; NON ha A, Q, J
H=Q — a cuori ha la Q come unico onore tra A K Q J 10
D=x — nessun onore a quadri (solo carte basse)
</syntaxhighlight>

Le lettere ammesse sono <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>). La regola è: '''le carte elencate sono possedute, le altre tra A K Q J 10 9 NON lo sono'''; le carte
dall'8 in giù sono libere e riempiono fino alla lunghezza del seme. Serve a
descrivere attacchi (sequenza interrotta <code><nowiki>KJT</nowiki></code>, interna <code><nowiki>KT</nowiki></code>, sotto onore <code><nowiki>K</nowiki></code> o
<code><nowiki>Q</nowiki></code>) e le carte del compagno. Si combina con la lunghezza (<code><nowiki>S:5 S=KJT</nowiki></code>).

Nel JSON compare <code><nowiki>suit_cards</nowiki></code> nella posizione, es. <code><nowiki>{"S": "KJT", "H": ""}</nowiki></code>
(stringa vuota = nessuna carta alta). Il generatore deve:
* assegnare esattamente quegli onori alla mano e '''escluderli''' dalle altre mani del seme; gli onori non nominati da nessuna posizione sono distribuiti a caso, ma mai a una posizione con <code><nowiki>suit_cards</nowiki></code> per quel seme che non li elenca;
* rispettare comunque <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code> (la validazione segnala le contraddizioni, es. <code><nowiki>S=KQ Shcp:0-2</nowiki></code> o lo stesso onore a due mani).

==== Pattern di mano in un seme (<code><nowiki>S~...</nowiki></code>, stile regex) ====

Descrive '''l'intera mano in quel seme''', dall'alto in basso, come una piccola
espressione regolare ancorata (inizio e fine):

<syntaxhighlight lang="text">
S~AKQ. — A, K, Q + una carta bassa (4 carte)
S~A... — A + tre carte basse (4 carte)
S~AJT9. — A, J, 10, 9 + una bassa
S~AKQ.|A... — alternative: una OPPURE l'altra
S~[KQ]x{2,3} — K o Q (come unico onore) + 2 o 3 carte basse
S~KJT.* — K, J, 10 + qualunque numero di basse (anche zero)
</syntaxhighlight>

Elementi:
* '''Carte alte''' <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>), '''sempre in ordine decrescente''', ciascuna posseduta; quelle non nominate tra A K Q J 10 9 NON sono possedute.
* '''Classe''' <code><nowiki>[KQ]</nowiki></code> = una carta tra quelle (si espande in alternative).
* '''Carta bassa''' <code><nowiki>.</nowiki></code> (o <code><nowiki>x</nowiki></code>) = una carta qualsiasi tra 8 e 2; compare solo in fondo. Quantificatori: <code><nowiki>?</nowiki></code> (0-1), <code><nowiki>*</nowiki></code> (0 o più), <code><nowiki>+</nowiki></code> (1 o più), <code><nowiki>{n}</nowiki></code>, <code><nowiki>{n,m}</nowiki></code>. Più punti si sommano (<code><nowiki>...</nowiki></code> = tre basse).
* '''Alternative''' <code><nowiki>|</nowiki></code>: il generatore ne sceglie una a caso per ogni mano.

È la forma più espressiva di <code><nowiki>S=KJT</nowiki></code> (che resta valida): il pattern fissa anche
la lunghezza (<code><nowiki>S~A...</nowiki></code> = 4 carte). Se c'è anche <code><nowiki>S:N</nowiki></code> i due vincoli devono
essere compatibili (la validazione API segnala le incompatibilità).

Nel JSON compare <code><nowiki>suit_patterns</nowiki></code> nella posizione, già '''normalizzato''' (classi
espanse, quantificatori risolti), così il generatore non deve interpretare la
regex:

<syntaxhighlight lang="json">
"suit_patterns": {
"S": [
{"cards": "AKQ", "low_min": 1, "low_max": 1},
{"cards": "A", "low_min": 3, "low_max": 3}
]
}
</syntaxhighlight>

<code><nowiki>cards</nowiki></code> = carte alte possedute (ordine A K Q J T 9); <code><nowiki>low_min</nowiki></code>/<code><nowiki>low_max</nowiki></code> =
numero di carte basse (2-8), <code><nowiki>low_max: null</nowiki></code> = nessun limite. La lunghezza del
seme è <code><nowiki>len(cards) + numero di basse</nowiki></code>. Il generatore sceglie una alternativa e
rispetta anche <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code>. Gli onori di <code><nowiki>cards</nowiki></code> vanno esclusi dalle altre
mani; quelli non nominati nella mano vanno ad altri a caso.

==== Avversari "quiet" (nessun intervento) ====

<syntaxhighlight lang="text">
opp1 quiet — solo per opp1/opp2
opp2 quiet:0-7 — come quiet, ma con HCP personalizzati
</syntaxhighlight>

<code><nowiki>quiet</nowiki></code> è una '''macro espansa dall'API''': nel JSON non compare mai la parola
<code><nowiki>quiet</nowiki></code>, ma i vincoli già risolti. Chi legge l'API (il generatore) non deve
implementare nulla di nuovo. Si espande in:

<syntaxhighlight lang="text">
S:0-4 H:0-4 D:0-5 C:0-5 hcp:0-9 Shcp:0-3 Hhcp:0-3 Dhcp:0-4 Chcp:0-4
(con quiet:0-7 → hcp:0-7)
</syntaxhighlight>

Significato: gli avversari possono avere colori lunghi (così le mani sono
varie), ma poveri di onori e con pochi punti: nessun colore da 6+ carte
(niente apertura di sbarramento), nessun contro informativo, nessun intervento
naturale credibile. Le distribuzioni ammesse sono quindi molte, ma con punti
ridotti: il generatore ha meno margine sugli HCP della coppia dichiarante
(40 punti totali: apertore+rispondente restano sopra ~22).
I token espliciti scritti sulla stessa posizione '''sostituiscono''' i default,
in qualsiasi ordine: <code><nowiki>opp1 quiet S:0-4</nowiki></code> lascia le picche 0-4 e tiene il resto.
Su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> la macro viene ignorata.

==== Fit (vincolo cross-posizione) ====

<syntaxhighlight lang="text">
fit:H8+ — almeno 8 cuori totali tra i compagni
fit:S9+ — almeno 9 picche totali tra i compagni
fit:M8+ — almeno 8 carte in un seme maggiore (H o S)
fit:m8+ — almeno 8 carte in un seme minore (D o C)
fit:8+ — almeno 8 carte in un seme qualsiasi
</syntaxhighlight>

Il fit si applica tra '''compagni''':
* Se appare su <code><nowiki>opener</nowiki></code> o <code><nowiki>responder</nowiki></code>, o a livello di scenario → coppia dichiarante
* Se appare su <code><nowiki>opp1</nowiki></code> o <code><nowiki>opp2</nowiki></code> → coppia difensiva

=== Formato range ===

{| class="wikitable"
! Sintassi
! Significato
|-
| <code><nowiki>5+</nowiki></code>
| Almeno 5 (min=5, max=null)
|-
| <code><nowiki>0-1</nowiki></code>
| Da 0 a 1 (min=0, max=1)
|-
| <code><nowiki>3</nowiki></code>
| Esattamente 3 (min=3, max=3)
|-
| <code><nowiki>12-21</nowiki></code>
| Da 12 a 21 (min=12, max=21)
|}

Nella risposta JSON, <code><nowiki>max: null</nowiki></code> significa "nessun limite superiore".

=== Semi non menzionati ===

I semi '''non vincolati''' e non coperti da <code><nowiki>x:</nowiki></code> sono distribuiti '''casualmente'''
dal generatore, rispettando il vincolo che il totale delle carte per mano sia 13.

----

== DSL versione 2 (<code><nowiki>dslVersion: 2</nowiki></code>) ==

Tutto ciò che sopra resta valido e '''invariato''': i campi v1 hanno lo stesso significato di prima.
La v2 aggiunge sintassi nuova; '''ogni scenario ha nel JSON il campo <code><nowiki>requires</nowiki></code>''' (elenco di tag,
vuoto se usa solo la v1; vedi sotto) così un motore parziale può rifiutare uno scenario con un
errore esplicito invece di generare mani sbagliate. <code><nowiki>descriptions[].context</nowiki></code> è sempre presente
(array, eventualmente vuoto).
Le definizioni normative (cosa è una fermata, i punti totali, le perdenti...) e
l'architettura del motore sono in '''<code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code>'''.

=== Macro di scrittura (<code><nowiki>@NOME=v1,v2</nowiki></code>) — risolte dal parser, il motore non le vede ===

<syntaxhighlight lang="text">
@M=H,S 1${M}: opener ${M}:5+ hcp:12-21; responder ${M}:3+
</syntaxhighlight>
Genera due scenari (<code><nowiki>1H</nowiki></code>, <code><nowiki>1S</nowiki></code>) sostituendo <code><nowiki>${M}</nowiki></code> ovunque, etichetta compresa.
Più prefissi fanno il prodotto cartesiano (max 64 scenari): <code><nowiki>@M=H,S @N=15-17,12-14</nowiki></code>.
I valori possono essere intervalli (<code><nowiki>hcp:${N}</nowiki></code>): servono anche come parametri del
sistema (SA 15-17 contro 14-16).

=== Semi variabili <code><nowiki>$a $b $c $d</nowiki></code> ===

Un seme "da scegliere" condiviso da più posizioni dello stesso scenario. Ogni
variabile è un seme diverso dalle altre. Dominio dichiarato a livello di scenario
(prima delle posizioni):

<syntaxhighlight lang="text">
Landy: $a=M $b=any opener hcp:12-21 ; opp1 $a:5+ $b:4+ ; responder $a:0-2
</syntaxhighlight>
<code><nowiki>$a=M</nowiki></code> nobili, <code><nowiki>$a=m</nowiki></code> minori, <code><nowiki>$a=any</nowiki></code> (default) qualunque, <code><nowiki>$a=SH</nowiki></code> insieme esplicito.
Una variabile non dichiarata vale <code><nowiki>any</nowiki></code> (tutti i semi). Si usano al posto di <code><nowiki>S H D C</nowiki></code> in: <code><nowiki>$a:5+</nowiki></code> (lunghezza), <code><nowiki>$ahcp:</nowiki></code>, <code><nowiki>$a=KQ</nowiki></code>, <code><nowiki>$a~...</nowiki></code>,
<code><nowiki>stop:$a</nowiki></code>, <code><nowiki>has:$aQ</nowiki></code>, <code><nowiki>kc:$a3</nowiki></code>, confronti (<code><nowiki>$a>$b</nowiki></code>), <code><nowiki>longest:$a</nowiki></code>.
Differisce da <code><nowiki>x:</nowiki></code> (che vale per una sola posizione).
JSON: lo stesso dizionario <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, ... ma con chiave <code><nowiki>"$a"</nowiki></code>;
a livello di scenario <code><nowiki>"vars": {"$a": ["S","H"]}</nowiki></code>.

=== Controlli, carte chiave, carte precise ===

{| class="wikitable"
! Token
! Significato
|-
| <code><nowiki>aces:2</nowiki></code> <code><nowiki>kings:1-2</nowiki></code> <code><nowiki>queens:0</nowiki></code>
| numero di assi / re / dame nella mano
|-
| <code><nowiki>controls:6+</nowiki></code>
| controlli (A=2, K=1)
|-
| <code><nowiki>kc:H3</nowiki></code> <code><nowiki>kc:H2-3</nowiki></code> <code><nowiki>kc:$a3</nowiki></code>
| carte chiave con atout H: i 4 assi + il Re di H (0-5)
|-
| <code><nowiki>has:HQ</nowiki></code> <code><nowiki>has:S10</nowiki></code>
| possiede quella carta precisa
|-
| <code><nowiki>lacks:HQ</nowiki></code>
| NON possiede quella carta
|-
| <code><nowiki>stop:S</nowiki></code> <code><nowiki>nostop:S</nowiki></code>
| ha / non ha una fermata nel seme (definizione in SPEC)
|}

JSON: <code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code> (Range); <code><nowiki>keycards: {"H": Range}</nowiki></code>;
<code><nowiki>cards_held: ["HQ"]</nowiki></code>, <code><nowiki>cards_not_held: ["SK"]</nowiki></code>; <code><nowiki>stoppers: {"S": 1, "H": 0}</nowiki></code>
(1 = deve averla, 0 = non deve averla).

=== Punti e perdenti ===

<code><nowiki>tp:</nowiki></code> punti totali (PO + 1 per ogni carta oltre la quarta in ogni seme),
<code><nowiki>dp:</nowiki></code> punti distribuzione (PO + 3 chicane + 2 singolo + 1 doubleton),
<code><nowiki>ltc:</nowiki></code> perdenti (Losing Trick Count). A livello di scenario: <code><nowiki>pairhcp:25+</nowiki></code>
(PO della coppia dichiarante), <code><nowiki>defhcp:0-14</nowiki></code> (coppia avversaria), <code><nowiki>pairtp:26+</nowiki></code>.
JSON: <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code> (Range) nella posizione; <code><nowiki>pair_hcp: {"declarer": R, "defense": R}</nowiki></code>,
<code><nowiki>pair_tp: {"declarer": R}</nowiki></code> nello scenario.

=== Confronti tra semi e forme precise ===

<syntaxhighlight lang="text">
H>S H>=S H<S H<=S H==S $a>$b — confronto di lunghezze nella stessa mano
longest:H — H è tra i semi più lunghi (pari merito ammesso)
shape:5-4-x-x shape:5422 shape:54xx — lunghezze ordinate in modo decrescente, x = qualsiasi
shape:semi_balanced — 5422 e 6322 (si aggiunge alle classi esistenti)
</syntaxhighlight>
JSON: <code><nowiki>compare: [{"left":"H","op":">=","right":"S"}]</nowiki></code>, <code><nowiki>longest: ["H"]</nowiki></code>,
<code><nowiki>shape_pattern: "54xx"</nowiki></code>.

=== Alternative e negazioni nella stessa mano: <code><nowiki>any(...)</nowiki></code> e <code><nowiki>not(...)</nowiki></code> ===

<syntaxhighlight lang="text">
opener any(S:4+ hcp:12+, H:4+) not(D:6+)
</syntaxhighlight>
<code><nowiki>any(A, B)</nowiki></code>: la mano soddisfa '''almeno una''' delle alternative (separate da virgola;
ogni alternativa è una congiunzione di token). <code><nowiki>not(A, B)</nowiki></code>: la mano non soddisfa
'''nessuna''' delle alternative. Si possono scrivere più gruppi (si combinano in AND);
niente annidamenti.
JSON: <code><nowiki>any: [[altA, altB], ...]</nowiki></code> (lista di gruppi; ogni alternativa è un oggetto
con gli stessi campi di una posizione), <code><nowiki>not: [altA, altB]</nowiki></code>.

=== Contesto dello scenario ===

Token prima delle posizioni: <code><nowiki>weight:3</nowiki></code> (frequenza relativa, 1-100, default 1),
<code><nowiki>dealer:opener</nowiki></code>, <code><nowiki>vul:none|us|them|both</nowiki></code> (<code><nowiki>us</nowiki></code> = apertore+rispondente),
<code><nowiki>auction:1SA,P,2C,P</nowiki></code> (licite, notazione BridgeCards; SA = NT), <code><nowiki>contract:4H</nowiki></code>,
<code><nowiki>declarer:responder</nowiki></code>, <code><nowiki>lead:SK</nowiki></code>.
JSON: <code><nowiki>weight</nowiki></code> (int) e <code><nowiki>context: {"dealer":..,"vul":..,"auction":[..],"contract":"4H","declarer":..,"lead":"SK"}</nowiki></code>.
Il motore deve usare <code><nowiki>dealer</nowiki></code>/<code><nowiki>vul</nowiki></code> quando li espone (per la numerazione del tavolo) e,
se c'è <code><nowiki>lead</nowiki></code>, la carta deve stare nella mano dell'attaccante (a sinistra del
dichiarante) e rispettare i vincoli di quella mano.

=== Tag <code><nowiki>requires</nowiki></code> ===

<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>vars</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>card_presence</nowiki></code> (has/lacks),
<code><nowiki>controls</nowiki></code> (aces/kings/queens/controls/kc), <code><nowiki>points</nowiki></code> (tp/dp/ltc), <code><nowiki>pair_points</nowiki></code>,
<code><nowiki>compare</nowiki></code> (confronti, longest), <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>any_not</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>weight</nowiki></code>.
Le macro <code><nowiki>@</nowiki></code> e <code><nowiki>quiet</nowiki></code> non compaiono: sono già espanse.

=== Avvisi di parsing (<code><nowiki>warnings</nowiki></code>) ===

<code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono <code><nowiki>warnings</nowiki></code> quando un frammento del DSL non è stato
capito e quindi '''scartato''': nome di posizione sbagliato, token sconosciuto o con valore
non valido (<code><nowiki>aces:5</nowiki></code>, <code><nowiki>S=Kx</nowiki></code>, <code><nowiki>shape:4-5-x-x</nowiki></code>), token di scenario dopo le posizioni, posizione
definita due volte, <code><nowiki>quiet</nowiki></code> su opener/responder, gruppo <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> con alternative non
valide (in tal caso '''l'intero gruppo è ignorato''', mai applicato a metà). <code><nowiki>validate.valid</nowiki></code> è 1
solo se non ci sono né <code><nowiki>errors</nowiki></code> né <code><nowiki>warnings</nowiki></code>. Un motore non deve generare se ci sono
<code><nowiki>warnings</nowiki></code> o <code><nowiki>errors</nowiki></code>.

Limiti (oltre i quali il parser avvisa e tronca): 60.000 caratteri di input, 200 scenari, 6
prefissi <code><nowiki>@</nowiki></code>, 64 valori per macro, 64 scenari per espansione, 8 gruppi <code><nowiki>any/not</nowiki></code> e 16 alternative
per posizione. Le etichette non possono contenere <code><nowiki>:</nowiki></code>.

----

== Struttura JSON di uno scenario ==

<syntaxhighlight lang="typescript">
interface Scenario {
label: string; // Etichetta (es. "1H-4C"), vuota se non specificata
positions: {
[posName: string]: Position; // "opener", "responder", "opp1", "opp2"
};
fit: FitConstraint[]; // Vincoli di fit (array, può essere vuoto)
}

interface Position {
suit_patterns?: { // Pattern regex-like normalizzati: {"S":[{"cards":"AKQ","low_min":1,"low_max":1}]}
[suit: string]: { cards: string; low_min: number; low_max: number | null }[];
};
suit_cards?: { [suit: string]: string }; // Onori esatti, es. {"S":"KJT"}; "" = nessuna carta alta
suits?: { // Vincoli lunghezza seme (solo semi esplicitati)
[suit: string]: Range; // "S", "H", "D", "C"
};
hcp?: Range; // HCP totali
suit_hcp?: { // HCP per seme specifico
[suit: string]: Range;
};
x?: Range; // Lunghezza seme wildcard
x_hcp?: Range; // HCP seme wildcard
shape?: string; // Shape class: "balanced", "one_suiter", etc.
}

interface Range {
min: number;
max: number | null; // null = nessun limite superiore
}

interface FitConstraint {
suit: string | null; // "S","H","D","C" o null
suit_class: string | null; // "major", "minor" o null
min: number; // Numero minimo di carte (es. 8)
pair: string; // "declarer" o "defense"
}
</syntaxhighlight>

----

== Logica per il generatore ==

=== Algoritmo base ===

Per ogni scenario:

# '''Scegli lo scenario''': random tra quelli disponibili, oppure lascia scegliere all'utente
# '''Risolvi wildcard''':
#* Se una posizione ha <code><nowiki>x:</nowiki></code>, scegli un seme casuale tra quelli non esplicitamente vincolati
#* <code><nowiki>xhcp:</nowiki></code> si applica allo stesso seme scelto per <code><nowiki>x:</nowiki></code>
# '''Risolvi fit''':
#* Se <code><nowiki>fit.suit</nowiki></code> è specificato, entrambi i compagni devono avere un totale >= <code><nowiki>fit.min</nowiki></code> in quel seme
#* Se <code><nowiki>fit.suit_class</nowiki></code> è "major", scegli tra H e S; se "minor", tra D e C
#* Se entrambi sono null, scegli un seme qualsiasi
#* <code><nowiki>fit.pair</nowiki></code> indica quale coppia: "declarer" (opener+responder) o "defense" (opp1+opp2)
# '''Genera le mani''':
#* Per ogni posizione, genera una mano che rispetti tutti i vincoli
#* I semi senza vincoli vengono riempiti casualmente
#* Il totale delle carte per mano deve essere esattamente 13
#* Il totale delle carte per seme (tutte e 4 le mani) deve essere esattamente 13
# '''Posizioni non menzionate''': se uno scenario non menziona <code><nowiki>opp1</nowiki></code>/<code><nowiki>opp2</nowiki></code>, distribuisci le carte rimanenti casualmente tra gli avversari

=== Priorità dei vincoli ===

# Vincoli di fit (cross-posizione) — determinano la distribuzione di base
# Vincoli di seme specifico (S:, H:, D:, C:) — limitano i singoli semi
# Vincoli wildcard (x:) — dopo aver fissato i semi specifici
# Vincoli HCP (hcp:, Shcp:, xhcp:) — filtro finale
# Shape class (shape:) — validazione della forma complessiva

=== Gestione di <code><nowiki>max: null</nowiki></code> ===

Quando <code><nowiki>max</nowiki></code> è <code><nowiki>null</nowiki></code>, non c'è limite superiore esplicito. I limiti fisici
del bridge si applicano comunque:
* Massimo 13 carte per seme (tutte e 4 le mani)
* Massimo 13 carte per mano
* Massimo 10 HCP per seme (A+K+Q+J = 4+3+2+1)
* Massimo 37 HCP per mano (raro ma teoricamente possibile con tutti gli onori)

----

== Esempi completi ==

=== Splinter (tutti gli scenari specifici) ===

DSL nel template wiki:
<syntaxhighlight lang="text">
1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 //
1H-4D: opener H:5+ hcp:12-21; responder H:4+ D:0-1 Dhcp:0 hcp:10-15 //
1H-4S: opener H:5+ hcp:12-21; responder H:4+ S:0-1 Shcp:0 hcp:10-15 //
1S-4C: opener S:5+ hcp:12-21; responder S:4+ C:0-1 Chcp:0 hcp:10-15 //
1S-4D: opener S:5+ hcp:12-21; responder S:4+ D:0-1 Dhcp:0 hcp:10-15 //
1S-4H: opener S:5+ hcp:12-21; responder S:4+ H:0-1 Hhcp:0 hcp:10-15
</syntaxhighlight>

=== Splinter (compatto con fit e wildcard) ===

<syntaxhighlight lang="text">
dopo 1H: fit:H8+ opener H:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15 //
dopo 1S: fit:S8+ opener S:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15
</syntaxhighlight>

=== Stayman ===

<syntaxhighlight lang="text">
fit a cuori: fit:H8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder H:4+ hcp:8+ //
fit a picche: fit:S8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder S:4+ hcp:8+
</syntaxhighlight>

=== Contro informativo ===

<syntaxhighlight lang="text">
base: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; responder hcp:0-8 //
con intervento: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; opp2 hcp:8+ x:5+
</syntaxhighlight>

=== Preempt 3-a-livello ===

<syntaxhighlight lang="text">
opener H:7+ x:0-1 hcp:5-10
</syntaxhighlight>

=== Overcall con fit avversari ===

<syntaxhighlight lang="text">
overcall semplice: opener hcp:12-21 x:5+; opp1 hcp:10+ x:5+; opp2 fit:8+ //
con barrage: opener hcp:12-21 x:5+; opp1 hcp:6-10 x:6+; opp2 fit:9+
</syntaxhighlight>

----

== Note implementative ==

* L'API è read-only, non richiede token CSRF
* L'accesso anonimo è abilitato di default (<code><nowiki>BridgeShapeAllowAnonymous: true</nowiki></code>) perché i dati sono pubblici e i tool esterni ne hanno bisogno
* Il campo <code><nowiki>raw</nowiki></code> nella risposta <code><nowiki>get</nowiki></code> contiene la stringa DSL originale, utile per debug
* L'azione <code><nowiki>validate</nowiki></code> permette di testare stringhe DSL senza creare pagine wiki
* I calcoli HCP usano la scala standard: A=4, K=3, Q=2, J=1

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Smazzate di gioco

2026-10-27T19:06:07Z

Lpala: Nuova pagina: smazzate di gioco BridgeShape (da DSL_SMAZZATE_GIOCO.md)

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — Regole per generare smazzate di gioco (eliminazione e messa in mano) =

Come descrivere con <code><nowiki>shape_constraints</nowiki></code> le smazzate didattiche sul '''gioco della carta''' (eliminazione,
messa in mano, expasse, sblocco, conteggio, carta falsa), per esempio quelle della lezione
"Gioco di Eliminazione" di ProgettoBridge. Gli scenari qui sotto sono '''archetipi scritti da BridgePedia''' (non copiano le mani né il testo della lezione). Ogni riga è verificata dal parser
(<code><nowiki>RecipesTest</nowiki></code>).

== 1. Cosa può fare la DSL e cosa no ==

La DSL descrive la '''struttura''' della smazzata: forma, punti, fit, colori lunghi, contesto
(contratto, attaccante, vulnerabilità). '''Non''' può dire "la mano si realizza solo con la messa in
mano": quella è una proprietà del ''gioco'', non della distribuzione. Quindi la generazione ha due
fasi:

# '''Generazione strutturale''' con gli scenari di questa pagina (il motore Play).
# '''Filtro tecnico''' (post-filtro), da realizzare in Play con un risolutore a carte scoperte (double dummy): si tiene la smazzata solo se supera i controlli del §3.

Senza il passo 2 la maggior parte delle mani generate non conterrebbe il tema voluto.

== 2. Archetipi (scenari) ==

Messa in mano dopo eliminazione, fit nobile 5-4, contratto di manche:
<syntaxhighlight lang="text">
Eliminazione base 4S: declarer:opener contract:4S opener S:5 hcp:16-19 ; responder S:4 hcp:8-11
Eliminazione base 4H: declarer:opener contract:4H opener H:5 hcp:16-19 ; responder H:4 hcp:8-11
</syntaxhighlight>

Colore laterale corto da eliminare (singolo o doubleton) con taglio e scarto possibile:
<syntaxhighlight lang="text">
Eliminazione colore corto: declarer:opener contract:4S opener S:5-6 hcp:15-19 $a:2-3 ; responder S:4 $a:2 hcp:8-12
</syntaxhighlight>

Slam con undici prese vincenti e un solo colore da giocare bene:
<syntaxhighlight lang="text">
Slam con colore chiave: declarer:opener contract:6S pairhcp:30-34 opener S:5+ hcp:17-21 ; responder S:3+ hcp:10-14
</syntaxhighlight>

Expasse e impasse nello stesso colore (stessa posizione di una carta):
<syntaxhighlight lang="text">
Impasse o expasse: declarer:opener contract:6D pairhcp:30-34 opener D:5+ hcp:14-18 ; responder D:4+ hcp:14+
</syntaxhighlight>

Gioco a senza atout con sblocco al primo giro:
<syntaxhighlight lang="text">
SA con sblocco: declarer:opener contract:3NT opener shape:balanced hcp:15-17 ; responder shape:balanced hcp:9-12 ; opp1 S:5+
SA con onore secondo in mano: declarer:opener contract:3NT opener H:2-3 hcp:15-17 ; responder H:4 hcp:10-12 ; opp1 S:5+
</syntaxhighlight>

Conteggio della mano di un avversario che ha aperto di barrage o sottoapertura:
<syntaxhighlight lang="text">
Conteggio dopo barrage: dealer:opp1 declarer:opener contract:4H opp1 S:7 hcp:5-9 ; opener H:5+ hcp:16-20 ; responder H:3+
Conteggio dopo sottoapertura: dealer:opp1 declarer:opener contract:6C opp1 D:6 hcp:5-9 ; opener C:6+ hcp:19+ ; responder C:2-4 hcp:12+
</syntaxhighlight>

Atout 2-2 favorevoli e doppio impasse:
<syntaxhighlight lang="text">
Quattro picche 2-2: declarer:opener contract:4S opener S:5 hcp:12-15 ; responder S:4 hcp:8-11 ; opp1 S:2 ; opp2 S:2
</syntaxhighlight>

Controgioco e attacco per la difesa (si impersona la difesa):
<syntaxhighlight lang="text">
Difesa contro 4 cuori: declarer:opener contract:4H lead:SQ opener H:5+ hcp:17+ ; opp1 S=QJ
Difesa contro 6 fiori: declarer:opener contract:6C opener C:6+ hcp:19+ ; opp1 H:4-5 hcp:6-10
</syntaxhighlight>

Contro informativo e risposta del compagno:
<syntaxhighlight lang="text">
Contro informativo e risposta: dealer:opener opener S:6 hcp:12-15 ; opp1 hcp:12+ H:4+ ; responder hcp:0-5 C:5+
</syntaxhighlight>

Mano troppo forte per l'appoggio barrage (fit quinto con 2NT Truscott):
<syntaxhighlight lang="text">
Fit quinto con mano forte: declarer:opener contract:4S pairhcp:25-30 opener S:5 hcp:15-18 ; responder S:5+ hcp:9-12
</syntaxhighlight>

== 3. Filtri tecnici (post-filtro con risolutore a carte scoperte) ==

Applicare dopo la generazione strutturale. Soglie indicative da tarare con esempi reali:

* '''Contratto realizzabile ma non banale''': il risolutore trova la linea vincente, e la prima linea "ovvia" (per esempio impasse a prima vista) fallisce nella maggior parte delle posizioni alternative.
* '''Esistenza di una linea ≥ 90 % più alta della naturale''': confrontare le probabilità delle linee; tenere la smazzata se la linea di eliminazione supera la naturale di almeno il 15 %.
* '''Eliminazione necessaria''': dopo aver tolto i colori laterali la difesa deve essere messa in presa e restare senza uscite neutre (verifica: il contratto cade se si salta l'eliminazione).
* '''Una sola linea vincente''' (o pochissime): scartare le mani risolvibili in molti modi.
* '''Coerenza con la licita''': licita ricostruita con le convenzioni del sistema scelto, mai incompatibile con le mani (usare il giudice <code><nowiki>satisfies()</nowiki></code> sulla smazzata finale).
* '''Carta falsa / radiografia''': nelle mani sul conteggio richiedere che le carte da dedurre siano una distribuzione plausibile (almeno due ipotesi alternative con probabilità diverse).

== 4. Come usarli nelle pagine ==

* Un archetipo per pagina di tecnica, come <code><nowiki>shape_constraints</nowiki></code> nel template <code><nowiki>{{Convenzione}}</nowiki></code> o nella pagina della tecnica, con <code><nowiki>shape_roles</nowiki></code> adatti (Dichiarante, Morto, Attaccante, Compagno).
* Le soglie PO nell'archetipo sono punti di partenza: nella pagina si citano quelle della fonte e le mani reali (con <code><nowiki><deal></nowiki></code>) dall'antologia di smazzate, con la fonte citata.
* Per smazzate per la '''difesa''' usare <code><nowiki>declarer:</nowiki></code> e <code><nowiki>lead:</nowiki></code> e descrivere la mano dell'attaccante.

== Fonti ==

* ProgettoBridge, ''Lezione 18 — Gioco di Eliminazione, smazzate esplicative'' (tecniche e temi trattati; gli archetipi qui sopra sono ricostruzioni originali di BridgePedia, non riproduzioni).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Motore e frontend

2026-10-23T16:31:40Z

Lpala: Aggiornamento da DEAL_ENGINE_SPEC.md (LTC, semi_balanced, jolly x, casi di test)

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — Specifica del motore di smazzate e del frontend (per Play) =

Destinatario: il team/sessione di '''Play''' (generatore di smazzate e relativo frontend).
Obiettivo: realizzare un '''motore completo''' che generi mani per ''qualsiasi'' scenario
descritto nelle pagine di BridgePedia, e un '''frontend''' per consultare gli scenari,
generare, creare e gestire smazzate.

Documenti collegati (leggere in quest'ordine):

# <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code> — riferimento della sintassi (DSL v1 + v2) e del JSON dell'API.
# '''questo file''' — semantica normativa, architettura del motore, test di conformità, specifica del frontend, piano di consegna.
# Wiki: <code><nowiki>Progetto:BridgeShape API</nowiki></code>; le pagine di convenzione con <code><nowiki>shape_constraints</nowiki></code> (elenco: <code><nowiki>GET /api.php?action=bridgeshape&shapeaction=list</nowiki></code>).

Fonte di verità del contratto: l'API <code><nowiki>action=bridgeshape</nowiki></code> di https://bridgepedia.it.
Se questo documento e l'API divergono vale l'API; segnalatelo a BridgePedia.

----

== 1. Contratto, versioni e compatibilità ==

{| class="wikitable"
! Elemento
! Dove
! Uso
|-
| <code><nowiki>dslVersion</nowiki></code>
| risposta di <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code>
| oggi <code><nowiki>2</nowiki></code>. Cambia solo con modifiche non retrocompatibili
|-
| <code><nowiki>scenarios[].requires</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| tag delle capacità richieste dallo scenario (§1.1)
|-
| <code><nowiki>errors</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| contraddizioni semantiche: '''non generare'''
|-
| <code><nowiki>warnings</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| frammenti del DSL scartati dal parser: '''non generare'''
|-
| <code><nowiki>descriptions</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| testo leggibile per scenario, tradotto (<code><nowiki>lang=it|en|...</nowiki></code>)
|-
| <code><nowiki>valid</nowiki></code>
| <code><nowiki>validate</nowiki></code>
| 1/0
|}

Regole di compatibilità:

* I campi nuovi compaiono '''solo se usati''': un motore v1 continua a funzionare sulle pagine v1.
* Campi sconosciuti: ignorarli '''non''' è permesso se compaiono in <code><nowiki>requires</nowiki></code>. Se il motore non supporta un tag di <code><nowiki>requires</nowiki></code>, deve rifiutare lo scenario con codice <code><nowiki>unsupported_feature</nowiki></code> (e nome del tag) e il frontend deve mostrarlo come "non ancora generabile", non nasconderlo.
* Il booleano nel JSON è sempre <code><nowiki>1</nowiki></code>/<code><nowiki>0</nowiki></code> (MediaWiki rimuove i <code><nowiki>false</nowiki></code>).
* Tutte le chiavi di seme sono <code><nowiki>S H D C</nowiki></code> oppure una variabile <code><nowiki>"$a".."$d"</nowiki></code>.

=== 1.1 Tag <code><nowiki>requires</nowiki></code> ===

{| class="wikitable"
! Tag
! Costrutti
! Impatto sul motore
|-
| <code><nowiki>suit_cards</nowiki></code>
| <code><nowiki>S=KJT</nowiki></code>
| assegnazione di onori precisi
|-
| <code><nowiki>suit_patterns</nowiki></code>
| <code><nowiki>S~AKQ.|A...</nowiki></code>
| alternative di mano nel seme
|-
| <code><nowiki>vars</nowiki></code>
| <code><nowiki>$a $b</nowiki></code>, <code><nowiki>vars</nowiki></code>
| seme scelto a runtime, condiviso tra posizioni
|-
| <code><nowiki>stoppers</nowiki></code>
| <code><nowiki>stop:S</nowiki></code>
| filtro/vincolo sulla mano
|-
| <code><nowiki>card_presence</nowiki></code>
| <code><nowiki>has:HQ</nowiki></code>, <code><nowiki>lacks:SK</nowiki></code>
| carte fisse
|-
| <code><nowiki>controls</nowiki></code>
| <code><nowiki>aces kings queens controls kc</nowiki></code>
| conteggi di onori
|-
| <code><nowiki>points</nowiki></code>
| <code><nowiki>tp dp ltc</nowiki></code>
| punteggi derivati
|-
| <code><nowiki>pair_points</nowiki></code>
| <code><nowiki>pairhcp pairtp defhcp</nowiki></code>
| vincolo sulla coppia
|-
| <code><nowiki>compare</nowiki></code>
| <code><nowiki>H>S</nowiki></code>, <code><nowiki>longest:</nowiki></code>
| relazioni tra lunghezze
|-
| <code><nowiki>shape_pattern</nowiki></code>
| <code><nowiki>shape:5-4-x-x</nowiki></code>
| forma ordinata
|-
| <code><nowiki>any_not</nowiki></code>
| <code><nowiki>any(...)</nowiki></code>, <code><nowiki>not(...)</nowiki></code>
| disgiunzioni e negazioni
|-
| <code><nowiki>context</nowiki></code>
| <code><nowiki>dealer vul auction contract declarer lead</nowiki></code>
| metadati e carta d'attacco
|-
| <code><nowiki>weight</nowiki></code>
| <code><nowiki>weight:N</nowiki></code>
| scelta ponderata dello scenario
|}

Le macro <code><nowiki>@M=H,S</nowiki></code> e <code><nowiki>quiet</nowiki></code> sono già espanse dal parser (non compaiono mai).

=== 1.2 Endpoint consigliati lato Play ===

Il motore deve esporre (nomi indicativi; l'importante è la semantica):

<syntaxhighlight lang="text">
POST /api/deals/generate
{
"source": { "page": "Splinter", "scenario": "1H-4C" } // oppure { "dsl": "..." }
| { "page": "Splinter" }, // scenario scelto per peso
"count": 10, // 1..100
"seed": 12345, // opzionale, riproducibilità
"fixed": { "opener": "SAK2.H.D.C", "responder": "..." }, // carte/mani già fissate (§5.6)
"lang": "it"
}
→ 200 { "seed":..., "deals":[ {
"scenario": "1H-4C", "index": 0,
"dealer": "opener", "vul": "none",
"hands": { "opener":"AK2.QJ53.K84.T65", "responder":"...", "opp1":"...", "opp2":"..." },
"bindings": { "$a": "H", "x:opener": "D" }, // come sono state risolte variabili e jolly
"pbn": "[Deal \"N:...\"]", "lin": "...",
"explanation": { "opener": ["♥: 5+ carte", ...], ... }, // dalle descriptions
"stats": { "attempts": 412, "ms": 38 }
} ] }
→ 422 { "code": "...", "reasons": [ {"code":"...", "position":"opp1", "detail":"..."} ] }
GET /api/deals/capabilities → { "dslVersion": 2, "supports": ["suit_cards", ...] }
</syntaxhighlight>

Posizioni → sedi: <code><nowiki>opener</nowiki></code> = Nord per default; il motore ruota in base a <code><nowiki>context.dealer</nowiki></code> solo
per la numerazione/PBN; i vincoli restano sempre in termini di ruoli (<code><nowiki>opener</nowiki></code>, <code><nowiki>responder</nowiki></code>,
<code><nowiki>opp1</nowiki></code> = a sinistra dell'apertore, <code><nowiki>opp2</nowiki></code> = a destra).

----

== 2. Definizioni normative ==

Il motore e il frontend devono usare '''esattamente''' queste definizioni (le descrizioni in
italiano dell'API le presuppongono).

* '''Carte''': A K Q J 10 9 8 7 6 5 4 3 2. Nei vincoli <code><nowiki>T</nowiki></code> = 10. "Carte basse" = 8..2.
* '''PO / HCP''': A=4, K=3, Q=2, J=1. <code><nowiki>Shcp</nowiki></code> ecc. = PO nel solo seme.
* '''Posizioni e coppie''': coppia dichiarante = <code><nowiki>opener</nowiki></code>+<code><nowiki>responder</nowiki></code>; difesa = <code><nowiki>opp1</nowiki></code>+<code><nowiki>opp2</nowiki></code>. Senso di gioco: opener → opp1 → responder → opp2 (orario). Lo stesso per l'attaccante: siede a sinistra del dichiarante (<code><nowiki>declarer</nowiki></code> = opener → attacca opp1; responder → opp2; opp1 → responder; opp2 → opener).
* '''Forma ordinata''': le 4 lunghezze in ordine decrescente (es. 5431).
* '''Classi di forma''' (possono sovrapporsi; le pagine oggi usano solo <code><nowiki>balanced</nowiki></code>):
** <code><nowiki>balanced</nowiki></code>: 4333, 4432, 5332.
** <code><nowiki>semi_balanced</nowiki></code>: 5422, 6322.
** <code><nowiki>one_suiter</nowiki></code>: seme più lungo ≥ 6 e secondo ≤ 3.
** <code><nowiki>two_suiter</nowiki></code>: i due semi più lunghi hanno entrambi ≥ 4 carte e insieme ≥ 9 (5-4, 6-4, 5-5, ...).
** <code><nowiki>three_suiter</nowiki></code>: tre semi ≥ 4 (4441, 5440, 4450...).
** <code><nowiki>any</nowiki></code>: nessun vincolo. Se la vostra implementazione attuale differisce, allineatela a questa o segnalate la differenza.
* '''<code><nowiki>shape_pattern</nowiki></code>''' (<code><nowiki>54xx</nowiki></code>): la forma ordinata deve corrispondere cifra per cifra; <code><nowiki>x</nowiki></code> = qualsiasi.
* '''<code><nowiki>longest:H</nowiki></code>''': la lunghezza di H è ≥ di ogni altro seme (pari merito ammesso).
* '''Confronti''' <code><nowiki>A op B</nowiki></code>: sulle lunghezze dei due semi nella stessa mano; <code><nowiki>==</nowiki></code> uguali.
* '''Controlli''': A=2, K=1 (le dame non contano). <code><nowiki>controls:6+</nowiki></code> somma sulla mano.
* '''Carte chiave per l'atout T''' (<code><nowiki>kc:T</nowiki></code>): numero di assi (0-4) + 1 se possiede il Re di T. Valori 0-5. La Dama di atout si esprime con <code><nowiki>has:TQ</nowiki></code>.
* '''Fermata''' nel seme X (<code><nowiki>stop:X</nowiki></code>): possiede almeno una tra: A; Kx (Re con ≥ 2 carte nel seme); Qxx (Dama con ≥ 3); Jxxx (Fante con ≥ 4). <code><nowiki>nostop:X</nowiki></code> = nessuna di queste.
* '''Punti totali <code><nowiki>tp</nowiki></code>''': PO + (per ogni seme, <code><nowiki>max(0, lunghezza − 4)</nowiki></code>).
* '''Punti distribuzione <code><nowiki>dp</nowiki></code>''': PO + 3 per ogni chicane + 2 per ogni singolo + 1 per ogni doubleton.
* '''Perdenti <code><nowiki>ltc</nowiki></code>''' (Losing Trick Count classico): per ogni seme con <code><nowiki>n</nowiki></code> carte, <code><nowiki>m = min(n,3)</nowiki></code>; perdenti del seme = <code><nowiki>m − [A] − [K e n≥2] − [Q e n≥3]</nowiki></code>; somma sui 4 semi (seme vuoto = 0). Tabella di controllo: x=1, A=0, K=1, Q=1; xx=2, Ax=1, Kx=1, Qx=2, AK=0, AQ=1, KQ=1; AKQ=0, AKx=1, AQx=1, KQx=1, Axx=2, Kxx=2, Qxx=2, xxx=3. (Correzione: la formula precedente <code><nowiki>m − #A,K,Q</nowiki></code> contava anche K e Q secchi o Q doppia.)
* '''<code><nowiki>S=KJT</nowiki></code>''' (<code><nowiki>suit_cards</nowiki></code>): tra A K Q J 10 9 possiede ''esattamente'' quelle elencate; 8..2 liberi. Stringa vuota = nessuna carta alta. Gli onori elencati sono esclusi dalle altre mani solo per quel che riguarda la proprietà: ogni carta ha un unico proprietario.
* '''<code><nowiki>S~...</nowiki></code>''' (<code><nowiki>suit_patterns</nowiki></code>): una sola alternativa (scelta a caso, uniformemente tra quelle compatibili con gli altri vincoli) descrive tutta la mano in quel seme: <code><nowiki>cards</nowiki></code> + tra <code><nowiki>low_min</nowiki></code> e <code><nowiki>low_max</nowiki></code> carte basse (<code><nowiki>low_max: null</nowiki></code> = illimitato, ma ≤ 13 − len(cards)).
* '''<code><nowiki>x:</nowiki></code>''' (jolly di posizione): un seme scelto a caso tra quelli ''non'' vincolati esplicitamente in quella posizione. Dentro una foglia di <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> il jolly vede '''solo i semi nominati nella foglia'''; un seme nominato soltanto in <code><nowiki>fit</nowiki></code>, confronti o <code><nowiki>longest:</nowiki></code> non è escluso da <code><nowiki>x</nowiki></code>; <code><nowiki>xhcp:</nowiki></code> si riferisce allo stesso seme. Il jolly '''non''' è condiviso con altre posizioni.
* '''Variabili <code><nowiki>$a..$d</nowiki></code>''': a inizio generazione ogni variabile usata riceve un seme dal proprio dominio (<code><nowiki>vars</nowiki></code>, default tutti e quattro). Variabili diverse hanno '''semi diversi'''; una variabile non dichiarata ha dominio completo. Una variabile può coincidere con un seme nominato esplicitamente (<code><nowiki>$a</nowiki></code> e <code><nowiki>H</nowiki></code>): se non è voluto, restringere il dominio (<code><nowiki>$a=SD</nowiki></code>). La scelta è uniforme tra le assegnazioni che rendono lo scenario soddisfacibile.
* '''<code><nowiki>fit</nowiki></code>''': somma delle lunghezze dei due compagni nel seme (o in qualunque seme del tipo <code><nowiki>major</nowiki></code>/ <code><nowiki>minor</nowiki></code>/<code><nowiki>any</nowiki></code>, a scelta del motore, uniformemente tra i semi che soddisfano il vincolo).
* '''<code><nowiki>any(A,B)</nowiki></code>''': la mano soddisfa almeno una alternativa. '''<code><nowiki>not(A,B)</nowiki></code>''': non ne soddisfa nessuna. Più gruppi → AND. Dentro <code><nowiki>A</nowiki></code>,<code><nowiki>B</nowiki></code> valgono gli stessi campi di una posizione (senza <code><nowiki>any/not/fit</nowiki></code>).
* '''<code><nowiki>pair_hcp.declarer</nowiki></code>''' = PO(opener)+PO(responder); <code><nowiki>defense</nowiki></code> = PO(opp1)+PO(opp2). <code><nowiki>pair_tp</nowiki></code>: somma <code><nowiki>tp</nowiki></code>.
* '''Posizioni non nominate''': ricevono le carte rimanenti a caso (nessun vincolo); non applicare <code><nowiki>quiet</nowiki></code> implicito.
* '''<code><nowiki>weight</nowiki></code>''': probabilità relativa di scelta dello scenario quando non è scelto dall'utente (default 1). Non influenza la generazione dentro lo scenario.
* '''<code><nowiki>context</nowiki></code>''': metadati. <code><nowiki>dealer</nowiki></code> e <code><nowiki>vul</nowiki></code> (<code><nowiki>us</nowiki></code> = coppia dichiarante) vanno riportati nell'output (PBN/LIN) e mostrati. <code><nowiki>auction</nowiki></code> è la sequenza da mostrare/verificare (notazione BridgeCards: <code><nowiki>P</nowiki></code>, <code><nowiki>X</nowiki></code>, <code><nowiki>XX</nowiki></code>, <code><nowiki>1NT</nowiki></code>...). <code><nowiki>contract</nowiki></code>/<code><nowiki>declarer</nowiki></code>/<code><nowiki>lead</nowiki></code>: vedi §5.7.

----

== 3. Architettura consigliata del motore ==

Pipeline per ogni mano richiesta:

<syntaxhighlight lang="text">
parse risposta API → controllo requires/errors/warnings
→ scelta scenario (utente | peso)
→ ASSEGNAZIONE SIMBOLICA : variabili $a.., jolly x:, fit, alternative any()/S~, pattern di forma
→ MATRICE DELLE LUNGHEZZE : 4 posizioni × 4 semi (somme 13 per riga e per colonna)
→ ASSEGNAZIONE DELLE CARTE : carte fissate/vincolate, poi resto casuale
→ RIPARAZIONE PUNTI : scambi mirati per entrare negli intervalli PO/tp/dp/ltc/controlli
→ VERIFICA FINALE : valutazione indipendente di TUTTI i vincoli sulla smazzata completa
→ output + spiegazione
</syntaxhighlight>

Punti chiave:

# '''Verifica finale indipendente''' (il "giudice"): una funzione pura <code><nowiki>satisfies(deal, scenario, bindings)</nowiki></code> che valuta ogni vincolo dalle definizioni di §2. Ogni smazzata emessa deve passarla. Questa funzione è anche la base dei test e del pulsante "verifica" del frontend.
# '''Costruzione, non solo scarto.''' Il rejection sampling puro non regge scenari stretti (es. Gran rever nel Multirever, <code><nowiki>quiet</nowiki></code> con coppia 25+ PO). Costruire prima la matrice delle lunghezze con propagazione dei vincoli (backtracking con limiti per riga/colonna), poi assegnare le carte onore per posizione secondo <code><nowiki>suit_cards</nowiki></code>/<code><nowiki>suit_patterns</nowiki></code>/<code><nowiki>has</nowiki></code>/<code><nowiki>lacks</nowiki></code>/<code><nowiki>aces</nowiki></code>..., infine le basse.
# '''Riparazione PO''': dopo l'assegnazione, se i PO (o <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, controlli, <code><nowiki>pair_*</nowiki></code>) sono fuori intervallo, scambiare due carte tra due mani preservando lunghezze e vincoli ''rigidi'' (carte fissate, pattern). Ricerca locale con budget; poi nuovo tentativo dall'inizio.
# '''Uniformità''': l'obiettivo è una distribuzione quasi uniforme tra le smazzate che soddisfano lo scenario. Le euristiche di costruzione introducono distorsioni: misuratele (§7.3) e non dichiarate "uniformi" se non lo sono.
# '''Budget e fallimenti''': limite di tempo (oggi 2,5 s CPU/mano), massimo tentativi, e diagnosi. Su fallimento restituire 422 con i <code><nowiki>reasons</nowiki></code> di §6, mai una smazzata che viola i vincoli.
# '''Riproducibilità''': stesso <code><nowiki>seed</nowiki></code> + stessa versione del DSL → stessa smazzata. Salvare nel record <code><nowiki>seed</nowiki></code>, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>source.page</nowiki></code>, <code><nowiki>revid</nowiki></code> della pagina se disponibile.
# '''Concorrenza e cache''': cache del JSON dell'API per pagina con TTL breve (60 s) e rivalidazione sulla <code><nowiki>list</nowiki></code>; mai servire DSL non validato.

=== 3.1 Ordine di risoluzione dei vincoli ===

# Variabili <code><nowiki>$a..</nowiki></code>, jolly <code><nowiki>x:</nowiki></code>, <code><nowiki>fit</nowiki></code> (decidono ''quali'' semi).
# Alternative: scegliere un ramo per ogni <code><nowiki>any()</nowiki></code> e ogni <code><nowiki>S~</nowiki></code> (escludendo i rami impossibili con i vincoli già noti); applicare <code><nowiki>not()</nowiki></code> come vincoli di esclusione.
# Lunghezze (<code><nowiki>suits</nowiki></code>, <code><nowiki>compare</nowiki></code>, <code><nowiki>longest</nowiki></code>, <code><nowiki>shape</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>fit</nowiki></code>).
# Carte precise (<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>cards_held/not_held</nowiki></code>, <code><nowiki>lead</nowiki></code>).
# Conteggi (<code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code>, <code><nowiki>keycards</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>).
# Punteggi derivati (<code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, <code><nowiki>pair_*</nowiki></code>) e <code><nowiki>stoppers</nowiki></code>.
# Verifica finale.

Un vincolo è "rigido" se riguarda carte/lunghezze fissate (1-4); "morbido" se si ripara per scambio (5-6).

----

== 4. Semantica delle combinazioni delicate ==

* <code><nowiki>quiet</nowiki></code> è già espanso in <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>: nessun trattamento speciale (il campo <code><nowiki>quiet: 1</nowiki></code> serve solo alla descrizione). Una difesa quiet '''riduce''' il margine PO per la coppia dichiarante: verificare la compatibilità prima di costruire (<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>...).
* <code><nowiki>S=...</nowiki></code> / <code><nowiki>S~...</nowiki></code> + <code><nowiki>S:N</nowiki></code> + <code><nowiki>Shcp</nowiki></code>: devono essere coerenti; l'API segnala le contraddizioni evidenti.
* Una carta (<code><nowiki>has:HQ</nowiki></code>) può comparire in una sola posizione; due posizioni con la stessa carta sono un errore di validazione, non un caso da risolvere a caso.
* <code><nowiki>any()</nowiki></code> dentro una posizione con variabili: le variabili si legano '''prima''', poi si sceglie il ramo.
* <code><nowiki>not()</nowiki></code> con <code><nowiki>S~</nowiki></code>: escludere dall'insieme di alternative, non solo filtrare a posteriori.
* <code><nowiki>longest:</nowiki></code> e <code><nowiki>compare</nowiki></code> valgono sulle lunghezze finali (dopo il bind delle variabili).
* <code><nowiki>context.lead</nowiki></code> (<code><nowiki>SK</nowiki></code>): la carta deve stare nella mano dell'attaccante (§2) e quella mano deve soddisfare i suoi vincoli (es. se ha <code><nowiki>S=KJT</nowiki></code>, <code><nowiki>lead:SJ</nowiki></code> è coerente, <code><nowiki>lead:SQ</nowiki></code> no).

=== Chiarimenti (concordati con Play) ===

* '''<code><nowiki>context.auction</nowiki></code>''': la sequenza parte dal '''mazziere''' (<code><nowiki>dealer</nowiki></code>); il primo token è la sua chiamata. Se <code><nowiki>dealer</nowiki></code> manca, l'asta è solo descrittiva e non si verifica nulla. Nella v2 l'asta e <code><nowiki>contract</nowiki></code> sono '''informativi''': il motore non deve ricavarne vincoli sulle mani.
* '''<code><nowiki>declarer</nowiki></code>''': non deve discendere dall'asta (non verificata). Serve a stabilire chi attacca (vedi §2) e quindi a validare <code><nowiki>lead</nowiki></code>.
* '''<code><nowiki>errors</nowiki></code>''': array di '''stringhe''' <code><nowiki>"<etichetta scenario o 'scenario #N'>: <messaggio in inglese>"</nowiki></code>, senza codici né struttura. Il motore li riporta così come sono (codice proprio <code><nowiki>dsl_errors</nowiki></code>, §6). Un formato strutturato (<code><nowiki>code</nowiki></code>, <code><nowiki>scenario</nowiki></code>, <code><nowiki>position</nowiki></code>) è una possibile evoluzione: lo si introdurrebbe come campo nuovo <code><nowiki>errorDetails</nowiki></code>, senza toccare <code><nowiki>errors</nowiki></code>.
* '''<code><nowiki>descriptions</nowiki></code>''': oggi un elemento per scenario con <code><nowiki>positions</nowiki></code> (testo per posizione) e <code><nowiki>context</nowiki></code>; '''non esiste un id per singolo vincolo'''. Se il frontend lo richiede, si aggiungerà un campo additivo (da concordare, §11).
* '''«Uniforme»''' (variabili, jolly, <code><nowiki>fit</nowiki></code>): tra le assegnazioni di semi che rendono lo scenario soddisfacibile, ciascuna ha uguale probabilità (a meno di tolleranza statistica nei test: ±5 % su 1000 estrazioni per due valori, vedi caso 3). Non implica uniformità sulle carte o sulle mani.

----

== 5. Funzionalità del motore (elenco completo da realizzare) ==

=== 5.1 Core (parità v1) — già in produzione, da conservare ===
Lunghezze, PO totali/per seme, <code><nowiki>x:</nowiki></code>, <code><nowiki>shape:</nowiki></code>, <code><nowiki>fit</nowiki></code>, <code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>quiet</nowiki></code>
(espanso), 422 con ragioni, tetto 2,5 s.

=== 5.2 Nuove funzioni DSL v2 ===
Tutte le righe di §1.1. Priorità di consegna in §9.

=== 5.3 Mani multiple e serie ===
<code><nowiki>count</nowiki></code> ≤ 100 per richiesta; opzione <code><nowiki>distinct: true</nowiki></code> (nessuna mano duplicata nella serie);
opzione <code><nowiki>balance: "round_robin" | "weighted"</nowiki></code> per distribuire gli scenari della stessa convenzione.

=== 5.4 Spiegazione per mano ===
Per ogni smazzata: per posizione, elenco dei vincoli con esito (✓) e valore effettivo
("♥: 5 carte, richiesto 5+"), e i '''binding''' (<code><nowiki>$a = ♥</nowiki></code>, <code><nowiki>x di opener = ♦</nowiki></code>). Serve al frontend.

=== 5.5 Verifica di una smazzata data ===
<code><nowiki>POST /api/deals/check</nowiki></code> con quattro mani e una <code><nowiki>source</nowiki></code> → elenco di vincoli soddisfatti/violati.
Usa lo stesso giudice del §3. Serve a: smazzate inserite a mano, correzione in aula, test.

=== 5.6 Mani parzialmente fissate (<code><nowiki>fixed</nowiki></code>) ===
Accettare mani complete o parziali (<code><nowiki>"opener": "SAK2."</nowiki></code>, o carte singole) e completare il resto
rispettando lo scenario. Se impossibile → 422 <code><nowiki>fixed_cards_conflict</nowiki></code>.

=== 5.7 Contesto di gioco della carta ===
<code><nowiki>contract</nowiki></code>, <code><nowiki>declarer</nowiki></code>, <code><nowiki>lead</nowiki></code>: il motore garantisce che la carta d'attacco sia nella mano giusta e
fornisce nel risultato <code><nowiki>play: { "contract":"4H", "declarer":"responder", "leader":"opp2", "lead":"SK" }</nowiki></code>.
(Il gioco successivo, oltre la prima carta, non è nel DSL: per Segnali e Attacchi la prima carta e le
mani bastano a mostrare la situazione.)

=== 5.8 Statistiche ===
Per scenario: tasso di successo, tentativi medi, p95 ms, codici di fallimento. Esposte in
<code><nowiki>GET /api/deals/stats</nowiki></code> e inviate a BridgePedia (§8.5) per tarare i vincoli.

----

== 6. Codici di errore (422 e simili) ==

Già in uso: <code><nowiki>exact_cards_always_conflict</nowiki></code>, <code><nowiki>generation_time_limit</nowiki></code>, <code><nowiki>suit_cards_below_hcp_min</nowiki></code>,
<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>, <code><nowiki>suit_cards_exceed_hcp_max</nowiki></code>. Da aggiungere:

{| class="wikitable"
! Codice
! Quando
|-
| <code><nowiki>unsupported_feature</nowiki></code>
| lo scenario richiede un tag non supportato (<code><nowiki>detail</nowiki></code>: il tag)
|-
| <code><nowiki>dsl_errors</nowiki></code>
| l'API ha restituito <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> (riportarli)
|-
| <code><nowiki>variable_unsatisfiable</nowiki></code>
| nessuna assegnazione dei semi variabili rende lo scenario possibile
|-
| <code><nowiki>fixed_cards_conflict</nowiki></code>
| <code><nowiki>fixed</nowiki></code> contraddice lo scenario o carte duplicate
|-
| <code><nowiki>pair_points_unreachable</nowiki></code>
| <code><nowiki>pairhcp/pairtp</nowiki></code> incompatibili con i limiti per posizione
|-
| <code><nowiki>lead_conflict</nowiki></code>
| <code><nowiki>lead</nowiki></code> incompatibile con la mano dell'attaccante
|-
| <code><nowiki>no_branch_left</nowiki></code>
| <code><nowiki>any()</nowiki></code>/<code><nowiki>S~</nowiki></code>/<code><nowiki>not()</nowiki></code> eliminano tutti i rami
|-
| <code><nowiki>shape_unreachable</nowiki></code>
| forma/lunghezze incompatibili con 13 carte per mano e per seme
|-
| <code><nowiki>invalid_request</nowiki></code>
| parametri non validi (count, seed...)
|}

Ogni 422 porta <code><nowiki>reasons: [{code, position?, detail}]</nowiki></code> leggibili dal frontend.

----

== 7. Test di conformità e qualità ==

=== 7.1 Invarianti (property test, ≥ 10.000 smazzate per scenario del wiki) ===
* 52 carte distinte; 13 per mano; nessun duplicato.
* <code><nowiki>satisfies()</nowiki></code> vero per ogni smazzata emessa (il giudice '''non''' deve condividere codice con il generatore).
* Stesso seed → stesso risultato.

=== 7.2 Casi minimi per costrutto (la DSL → cosa deve valere) ===

{| class="wikitable"
! #
! DSL
! Asserzione
|-
| 1
| <code><nowiki>opener S:5+ hcp:12-21</nowiki></code>
| ♠ ≥ 5, PO in intervallo
|-
| 2
| <code><nowiki>@M=H,S opener ${M}:5+</nowiki></code>
| due scenari generabili (<code><nowiki>H</nowiki></code>, <code><nowiki>S</nowiki></code>)
|-
| 3
| <code><nowiki>$a=M opener $a:5+; responder $a:3+</nowiki></code>
| in ogni mano: un nobile ≥5 in opener, lo stesso seme ≥3 in responder; entrambi i nobili compaiono su 1000 mani
|-
| 4
| <code><nowiki>$a=M $b=m opener $a:5+ $b:4+</nowiki></code>
| $a nobile, $b minore, mai lo stesso seme
|-
| 5
| <code><nowiki>opener stop:S</nowiki></code> su 1000 mani
| tutte le mani hanno A, Kx, Qxx o Jxxx a ♠
|-
| 6
| <code><nowiki>opener nostop:S S:3+</nowiki></code>
| nessuna mano con A, né Kx, Qxx o Jxxx a ♠ (con 3 carte: né A, né K, né Q)
|-
| 7
| <code><nowiki>opener aces:2 kc:H3</nowiki></code>
| 2 assi; assi + K♥ = 3 (<code><nowiki>kc:H4</nowiki></code> con <code><nowiki>aces:2</nowiki></code> è impossibile: max 2+1)
|-
| 8
| <code><nowiki>opener has:HQ lacks:SK</nowiki></code>
| Q♥ presente, K♠ assente
|-
| 9
| <code><nowiki>opener tp:20-22</nowiki></code>
| <code><nowiki>tp</nowiki></code> corretto con la definizione di §2
|-
| 10
| <code><nowiki>opener ltc:6-7</nowiki></code>
| LTC con la definizione di §2
|-
| 11
| <code><nowiki>opener H>S</nowiki></code> e <code><nowiki>opener H>=S longest:H</nowiki></code>
| confronti rispettati; <code><nowiki>longest</nowiki></code> con pari merito
|-
| 12
| <code><nowiki>opener shape:5-4-x-x</nowiki></code>
| 5 e 4 come due semi più lunghi in ordine; gli altri due sommano 4
|-
| 13
| <code><nowiki>opener shape:semi_balanced</nowiki></code>
| solo 5422 e 6322
|-
| 14
| <code><nowiki>opener any(S:5+, H:5+)</nowiki></code>
| almeno un nobile ≥ 5
|-
| 15
| <code><nowiki>opener not(S:4+, H:4+)</nowiki></code>
| nessun nobile ≥ 4
|-
| 16
| <code><nowiki>opener any(S:4+ hcp:12+, H:4+)</nowiki></code>
| rami composti
|-
| 17
| <code><nowiki>pairhcp:25+ ... opp1 quiet; opp2 quiet</nowiki></code>
| coppia ≥ 25, avversari entro i limiti quiet
|-
| 18
| <code><nowiki>weight:1 ... // weight:3 ...</nowiki></code>
| 1000 estrazioni ~ 25%/75% (± tolleranza)
|-
| 19
| <code><nowiki>dealer:opp1 vul:both</nowiki></code>
| output con dealer/vul corretti e PBN ruotato
|-
| 20
| <code><nowiki>declarer:responder lead:SJ opp2 S=KJT</nowiki></code>
| J♠ in opp2; con <code><nowiki>lead:SQ</nowiki></code> → 422 <code><nowiki>lead_conflict</nowiki></code>
|-
| 21
| <code><nowiki>fixed</nowiki></code> con Q♥ in opener
| opener ha Q♥ e rispetta lo scenario
|-
| 22
| scenario impossibile (<code><nowiki>S=AK Shcp:0-2</nowiki></code>)
| 422 con ragione
|-
| 23
| scenario con <code><nowiki>unsupported</nowiki></code> simulato
| 422 <code><nowiki>unsupported_feature</nowiki></code>
|}

Aggiungere come test di regressione '''tutti gli scenari reali''' delle pagine del wiki
(<code><nowiki>shapeaction=list</nowiki></code> → <code><nowiki>get</nowiki></code>): per ciascuno ≥ 1000 smazzate valide entro il budget, oppure una
diagnosi documentata. Gli scenari più duri oggi: ''Multirever'' (Gran rever, 20 scenari) e
''Segnale di Smith'' (20 scenari con <code><nowiki>suit_cards</nowiki></code>).

=== 7.3 Qualità statistica ===
Per ogni scenario del wiki misurare su 5000 mani: distribuzione delle lunghezze e dei PO nei limiti
consentiti, tasso di riuscita al primo tentativo, tempo p50/p95. Segnalare distorsioni evidenti
(es. la posizione A prende sempre i PO alti).

=== 7.4 Prestazioni ===
Obiettivo: p95 < 300 ms per mano sugli scenari comuni; < 2,5 s sul peggiore. Se non si rispetta,
non allargare i vincoli: segnalare lo scenario a BridgePedia (§8.5) che può rivederlo.

----

== 8. Frontend di Play ==

Il frontend deve permettere di '''consultare''', '''generare''', '''creare''' e '''gestire''' smazzate.
Lingua: italiano, con i18n predisposta (en, fr, es, de). Tutti i testi dei vincoli vengono
dall'API (<code><nowiki>descriptions</nowiki></code>, parametro <code><nowiki>lang</nowiki></code>): non riscriverli.

=== 8.1 Catalogo delle convenzioni ===
* Elenco da <code><nowiki>shapeaction=list</nowiki></code> (con vincoli) e <code><nowiki>listall</nowiki></code> (tutte, con <code><nowiki>hasShape</nowiki></code>).
* Per ogni voce: titolo, numero di scenari, link alla pagina del wiki, stato: ''generabile'', ''parzialmente generabile'' (alcuni scenari con <code><nowiki>requires</nowiki></code> non supportato), ''non generabile''.
* Ricerca testuale; filtri per tipologia/sistema se esposti; badge "da verificare" per le traduzioni non verificate.
* Le 27 convenzioni senza vincoli compaiono come "scenari in arrivo" con link al wiki.

=== 8.2 Visualizzatore di scenario ===
* Tabella a colonne per posizione (come la tabella del wiki): etichetta scenario, frasi di <code><nowiki>descriptions[i].positions</nowiki></code>, <code><nowiki>positionLabels</nowiki></code> (rispettare i ruoli personalizzati, es. "Attaccante"), <code><nowiki>fit</nowiki></code>, <code><nowiki>context</nowiki></code>.
* Semi ♥ ♦ in rosso. Mostrare <code><nowiki>requires</nowiki></code> come chip (tooltip con spiegazione).
* Pulsante "Mostra DSL" (testo <code><nowiki>raw</nowiki></code>) e "Apri la pagina nel wiki".

=== 8.3 Generatore ===
* Scelta convenzione → scenario (singolo, "a caso", "tutti a rotazione", pesato) → quantità (1-100) → opzioni (seed, mani distinte, nascondi avversari).
* Risultato: schede smazzata con 4 mani (formato BridgeCards: ♠♥♦♣, bordi, dealer, vulnerabilità), etichetta scenario, '''pannello "perché questa mano"''': per posizione le frasi di <code><nowiki>explanation</nowiki></code> con spunta, binding (<code><nowiki>$a = ♥</nowiki></code>), PO/lunghezze effettive.
* Azioni per smazzata: rigenera, "blocca questa mano e rigenera le altre" (usa <code><nowiki>fixed</nowiki></code>), copia link con seed, esporta PBN/LIN/immagine, aggiungi alla raccolta.
* Se la licita <code><nowiki>auction</nowiki></code> è presente: mostrarla con <code><nowiki><bidding></nowiki></code> (stile BridgeCards) o nascosta per esercizio ("indovina la risposta").
* Gestione 422: messaggio per codice (§6) con suggerimento ("lo scenario è impossibile perché..."). Per <code><nowiki>unsupported_feature</nowiki></code>: spiegare quale capacità manca.

=== 8.4 Editor / creazione di scenari ===
Due modalità sincronizzate:

# '''Modulo guidato''' per posizione (Apertore, Compagno, Avv. sinistro, Avv. destro):
#* lunghezze per seme (slider min-max), PO totali e per seme, forma (classi + schema <code><nowiki>5-4-x-x</nowiki></code>);
#* griglia carte per seme (A K Q J 10 9 + "basse") con stati ''deve avere / non deve avere / indifferente'' che produce <code><nowiki>S=...</nowiki></code>; costruttore di pattern per <code><nowiki>S~</nowiki></code> con anteprima;
#* interruttori: fermata (per seme), assi/re/dame/controlli, carte chiave con atout, <code><nowiki>tp/dp/ltc</nowiki></code>, confronti tra semi, <code><nowiki>any(...)</nowiki></code>/<code><nowiki>not(...)</nowiki></code> come gruppi aggiungibili;
#* variabili di seme <code><nowiki>$a..$d</nowiki></code> con dominio (nobili/minori/qualsiasi);
#* contesto: dealer, vulnerabilità, licita, contratto, attacco, peso;
#* avversari: pulsante '''quiet''' (e <code><nowiki>quiet:max</nowiki></code>);
#* macro: "ripeti per ogni nobile / minore / seme" genera <code><nowiki>@M=...</nowiki></code>.
# '''Editor testuale''' del DSL con evidenziazione, completamento e ''validazione live'': chiama <code><nowiki>shapeaction=validate</nowiki></code> (debounce 400 ms) e mostra <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>, <code><nowiki>descriptions</nowiki></code> e <code><nowiki>requires</nowiki></code> (con il supporto del motore). Le due modalità si convertono a vicenda (modulo → DSL è obbligatorio; DSL → modulo almeno per i costrutti elementari, il resto resta testuale).

* Pulsante "Prova": genera 5 mani di test dallo scenario in modifica e mostra tempi e tassi di riuscita.
* Salvataggio come '''bozza personale''' in Play (non scrive sul wiki). Pulsante "Copia per BridgePedia" produce la riga <code><nowiki>shape_constraints</nowiki></code> da incollare nella pagina (gli editor del wiki fanno il resto).
* Libreria di '''modelli''' presi dalle convenzioni del wiki ("parti da Landy").

=== 8.5 Retroazione verso BridgePedia ===
* Pulsante "Segnala scenario problematico" (lento / troppo raro / 422 / distribuzione strana) che invia: pagina, scenario, <code><nowiki>dslVersion</nowiki></code>, codice errore, statistiche (§5.8) al canale concordato (sessione/issue). Nessuna scrittura diretta sul wiki.
* Report periodico automatico delle statistiche di generazione per scenario.

=== 8.6 Smazzate manuali ===
* Compositore: assegnare le 52 carte alle quattro mani con trascinamento o digitazione (<code><nowiki>AK2.QJ5.K84.T65</nowiki></code>), controllo duplicati, completamento casuale delle carte mancanti (opzionalmente rispettando uno scenario: usa <code><nowiki>fixed</nowiki></code>).
* Pulsante "Verifica rispetto a uno scenario" (§5.5) con l'elenco dei vincoli soddisfatti e violati.
* Importa/esporta PBN, LIN, testo semplice.

=== 8.7 Gestione delle smazzate ===
* Raccolte ("mazzi di esercizio"): nome, descrizione, convenzione, tag; ordinamento; duplicati evitati.
* Ricerca per convenzione, scenario, tag, data; filtri per vulnerabilità, dealer.
* Metadati salvati: <code><nowiki>seed</nowiki></code>, <code><nowiki>source.page</nowiki></code>, scenario, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>revid</nowiki></code>, data, autore.
* Note personali per smazzata; stampa di una raccolta (fogli A4 con 4 o 6 smazzate per pagina, versione "solo mano dell'apertore" per esercizio).
* Condivisione: link con seed/raccolta, permessi (privato, gruppo, pubblico) secondo il modello utenti di Play. Esportazione in blocco (PBN).
* Modalità "esercizio di licita": mostra le mani di un lato, l'utente inserisce la licita, il frontend confronta con <code><nowiki>context.auction</nowiki></code> se presente.

=== 8.8 Requisiti trasversali ===
* Mobile first; tastiera accessibile; semi anche come lettere per daltonici.
* Nessuna dipendenza dal wiki per il rendering delle carte (usare componenti propri; stile coerente con BridgeCards).
* Tempi: la generazione deve mostrare avanzamento e poter essere annullata.
* Tracciare (analytics interni) tempi, errori e scenari più usati.
* Testo dei vincoli sempre da <code><nowiki>descriptions</nowiki></code> con <code><nowiki>lang</nowiki></code> coerente con la lingua dell'interfaccia.

----

== 9. Piano di consegna consigliato ==

{| class="wikitable"
! Fase
! Contenuto
! Esito atteso
|-
| '''P0 — compatibilità''' (subito)
| leggere <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>requires</nowiki></code>, <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>; esporre <code><nowiki>/capabilities</nowiki></code>; rifiutare con <code><nowiki>unsupported_feature</nowiki></code>; giudice <code><nowiki>satisfies()</nowiki></code> per v1
| nessuna smazzata errata con le pagine nuove
|-
| '''P1 — core v2'''
| macro (nessun lavoro, già espanse), <code><nowiki>weight</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, classi nuove, <code><nowiki>compare</nowiki></code>/<code><nowiki>longest</nowiki></code>, <code><nowiki>any/not</nowiki></code>, <code><nowiki>pair_*</nowiki></code>
| scenari per Landy/Cappelletti/DONT/Smolen con forme e alternative
|-
| '''P2 — variabili e carte'''
| <code><nowiki>vars</nowiki></code> condivise tra posizioni, <code><nowiki>has/lacks</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>aces/kings/queens/controls/kc</nowiki></code>
| Michaels, Sputnik, Lebensohl, Blackwood/RKCB, Exclusion
|-
| '''P3 — punteggi'''
| <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>
| sistemi a forza (Fiori forte, 2♣ forte, Gazzilli)
|-
| '''P4 — frontend lettura'''
| catalogo, visualizzatore, generatore con spiegazioni
| tutti possono provare le convenzioni
|-
| '''P5 — frontend creazione'''
| editor guidato + testuale con validazione live, "Prova", bozze
| gli editor creano e collaudano scenari senza il wiki
|-
| '''P6 — gestione'''
| raccolte, smazzate manuali, <code><nowiki>check</nowiki></code>, <code><nowiki>fixed</nowiki></code>, esportazioni, esercizi di licita
| uso didattico completo
|-
| '''P7 — qualità'''
| suite di conformità (§7), statistiche, report verso BridgePedia
| motore misurabile
|}

Ogni fase deve chiudersi con i test di §7 per i costrutti introdotti. BridgePedia estende le
pagine del wiki man mano che i tag diventano disponibili: '''comunicate a ogni fase la lista dei tag supportati''' (<code><nowiki>/capabilities</nowiki></code>) così il wiki passa dalle approssimazioni (pattern <code><nowiki>S~</nowiki></code>) ai
costrutti nativi solo quando il motore li regge.

----

== 10. Cosa fa BridgePedia (per non sovrapporsi) ==

* Mantiene il DSL, il parser, le descrizioni e l'API; aggiunge costrutti su richiesta motivata.
* Scrive e tiene aggiornati gli scenari nelle pagine delle convenzioni; le 27 mancanti saranno coperte via via con i costrutti v2.
* Fornisce il catalogo di ricette (come descrivere Landy, Blackwood, un attacco sotto onore...).
* Riceve da Play le segnalazioni di §8.5 e rivede i vincoli troppo duri.

== 11. Decisioni aperte (da concordare con Play) ==

# Definizione definitiva delle classi di forma (§2) rispetto a quanto già implementato.
# Formato di <code><nowiki>explanation</nowiki></code> (testo semplice vs struttura con esito per vincolo).
# Modello di persistenza e permessi delle raccolte (utenti Play).
# Canale per le segnalazioni verso BridgePedia (§8.5).
# Se <code><nowiki>fixed</nowiki></code> deve accettare anche vincoli aggiuntivi temporanei (override locali dello scenario).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape API

2026-10-23T16:31:39Z

Lpala: Aggiornamento da DEAL_GENERATOR_API.md (LTC, semi_balanced, jolly x, chiarimenti)

Documentazione BridgeShape: [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — API per Generatori di Smazzate =

Documentazione tecnica per chi sviluppa un generatore di smazzate di test
che legge i vincoli di distribuzione (shape constraints) dalle convenzioni
di BridgePedia.

== Panoramica ==

Ogni pagina wiki di convenzione su BridgePedia può definire nel template
<code><nowiki>{{Convenzione}}</nowiki></code> un campo <code><nowiki>shape_constraints</nowiki></code> che descrive, in un formato
DSL compatto, i vincoli di distribuzione delle mani dei 4 giocatori al tavolo.

L'estensione '''BridgeShape''' espone un'API REST/JSON per leggere questi
vincoli in modo strutturato.

----

== API Endpoint ==

<syntaxhighlight lang="text">
GET /api.php?action=bridgeshape&shapeaction=ACTION&format=json
</syntaxhighlight>

=== Azioni disponibili ===

{| class="wikitable"
! Azione
! Descrizione
! Parametri
|-
| <code><nowiki>get</nowiki></code>
| Vincoli per una singola convenzione
| <code><nowiki>pageid</nowiki></code> oppure <code><nowiki>title</nowiki></code>
|-
| <code><nowiki>list</nowiki></code>
| Elenco convenzioni con vincoli definiti
| —
|-
| <code><nowiki>listall</nowiki></code>
| Elenco tutte le convenzioni (con/senza vincoli)
| —
|-
| <code><nowiki>validate</nowiki></code>
| Valida una stringa DSL senza bisogno di una pagina wiki
| <code><nowiki>dsl</nowiki></code>
|}

=== Esempi di chiamata ===

<syntaxhighlight lang="bash">
# Per titolo pagina
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&title=Splinter&format=json"

# Per page ID
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&pageid=42&format=json"

# Elenco pagine con vincoli
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=list&format=json"

# Validare una stringa DSL
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=validate&dsl=opener+H:5%2B+hcp:12-21&format=json"
</syntaxhighlight>

----

== Formato risposta JSON ==

=== <code><nowiki>shapeaction=get</nowiki></code> ===

<syntaxhighlight lang="json">
{
"shapeconstraints": {
"pageId": 42,
"raw": "1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 // ...",
"scenarios": [
{
"label": "1H-4C",
"positions": {
"opener": {
"suits": {
"H": { "min": 5, "max": null }
},
"hcp": { "min": 12, "max": 21 }
},
"responder": {
"suits": {
"H": { "min": 4, "max": null },
"C": { "min": 0, "max": 1 }
},
"suit_hcp": {
"C": { "min": 0, "max": 0 }
},
"hcp": { "min": 10, "max": 15 }
}
},
"fit": []
}
]
}
}
</syntaxhighlight>

'''Descrizioni leggibili.''' Insieme a <code><nowiki>scenarios</nowiki></code>, <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono
<code><nowiki>descriptions</nowiki></code> (stesso ordine): per ogni scenario <code><nowiki>label</nowiki></code>, <code><nowiki>positions</nowiki></code>
(per posizione, elenco di frasi già tradotte, es. <code><nowiki>"♠: ha K J 10 (e non A Q 9)"</nowiki></code>),
<code><nowiki>positionLabels</nowiki></code> (nome del ruolo, es. "Attaccante" se la pagina ha <code><nowiki>shape_roles</nowiki></code>;
altrimenti "Apertore (chi usa la convenzione)", "Compagno", ...) e <code><nowiki>fit</nowiki></code>.
Parametro opzionale <code><nowiki>lang</nowiki></code> (it, en, ...; default lingua dell'API, di solito <code><nowiki>it</nowiki></code>).
Serve a mostrare nell'interfaccia di Play '''perché''' la mano è fatta così.
Nella posizione compare anche <code><nowiki>quiet: 1</nowiki></code> se è stata usata la macro <code><nowiki>quiet</nowiki></code>.

=== <code><nowiki>shapeaction=list</nowiki></code> ===

<syntaxhighlight lang="json">
{
"pages": [
{
"pageId": 42,
"title": "Splinter",
"scenarioCount": 6,
"labels": ["1H-4C", "1H-4D", "1H-4S", "1S-4C", "1S-4D", "1S-4H"]
},
{
"pageId": 15,
"title": "Stayman",
"scenarioCount": 2,
"labels": ["fit a cuori", "fit a picche"]
}
]
}
</syntaxhighlight>

----

== Formato DSL ==

Il DSL (Domain Specific Language) è la stringa scritta nel campo
<code><nowiki>shape_constraints</nowiki></code> del template wiki.

=== Struttura ===

<syntaxhighlight lang="text">
etichetta: vincoli posizione; vincoli posizione // etichetta: vincoli // ...
</syntaxhighlight>

* '''<code><nowiki>//</nowiki></code>''' separa gli scenari (il generatore ne sceglie uno random o li presenta all'utente)
* '''<code><nowiki>;</nowiki></code>''' separa le posizioni dentro uno scenario
* Ogni scenario ha un''''etichetta''' opzionale seguita da <code><nowiki>:</nowiki></code>
* Ogni posizione inizia col nome del ruolo, seguito da vincoli separati da spazi

=== Posizioni ===

{| class="wikitable"
! Nome
! Ruolo
|-
| <code><nowiki>opener</nowiki></code>
| Chi apre o fa la prima licita convenzionale
|-
| <code><nowiki>responder</nowiki></code>
| Il compagno dell'opener
|-
| <code><nowiki>opp1</nowiki></code>
| Avversario a sinistra dell'opener
|-
| <code><nowiki>opp2</nowiki></code>
| Avversario a destra dell'opener (compagno di opp1)
|}

=== Vincoli ===

==== Lunghezza seme (specifico) ====

<syntaxhighlight lang="text">
S:5+ — almeno 5 picche
H:0-1 — 0 o 1 cuori
D:3 — esattamente 3 quadri
C:2-5 — da 2 a 5 fiori
</syntaxhighlight>

Semi: <code><nowiki>S</nowiki></code> = Spades/Picche, <code><nowiki>H</nowiki></code> = Hearts/Cuori, <code><nowiki>D</nowiki></code> = Diamonds/Quadri, <code><nowiki>C</nowiki></code> = Clubs/Fiori

==== Lunghezza seme (wildcard) ====

<syntaxhighlight lang="text">
x:0-1 — un seme qualsiasi (tra quelli non specificati) con 0-1 carte
x:6+ — un seme non specificato con almeno 6 carte
</syntaxhighlight>

Il generatore sceglie casualmente quale seme assegnare a <code><nowiki>x</nowiki></code> tra quelli
non già vincolati esplicitamente (S/H/D/C).

==== HCP totali ====

<syntaxhighlight lang="text">
hcp:15-17 — da 15 a 17 punti onore
hcp:12+ — almeno 12 punti
hcp:0-7 — da 0 a 7 punti
</syntaxhighlight>

==== HCP nel seme (specifico) ====

<syntaxhighlight lang="text">
Shcp:3+ — almeno 3 HCP a picche
Chcp:0 — 0 HCP a fiori (nessun onore)
Hhcp:0-2 — da 0 a 2 HCP a cuori
</syntaxhighlight>

==== HCP nel seme (wildcard) ====

<syntaxhighlight lang="text">
xhcp:0 — 0 HCP nel seme wildcard (x)
xhcp:0-1 — 0-1 HCP nel seme x
</syntaxhighlight>

==== Shape class ====

<syntaxhighlight lang="text">
shape:balanced — distribuzione bilanciata (4333, 4432, 5332)
shape:semi_balanced — semibilanciata (5422, 6322)
shape:one_suiter — monocolore
shape:two_suiter — bicolore
shape:three_suiter — tricolore
shape:any — qualsiasi (default)
</syntaxhighlight>

==== Onori esatti in un seme (<code><nowiki>S=KJT</nowiki></code>) ====

<syntaxhighlight lang="text">
S=KJT — in picche ha K, J e 10; NON ha A, Q, 9 (le carte basse 8-2 completano)
S=KT9 — sequenza interna: K, 10, 9; NON ha A, Q, J
H=Q — a cuori ha la Q come unico onore tra A K Q J 10
D=x — nessun onore a quadri (solo carte basse)
</syntaxhighlight>

Le lettere ammesse sono <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>). La regola è: '''le carte elencate sono possedute, le altre tra A K Q J 10 9 NON lo sono'''; le carte
dall'8 in giù sono libere e riempiono fino alla lunghezza del seme. Serve a
descrivere attacchi (sequenza interrotta <code><nowiki>KJT</nowiki></code>, interna <code><nowiki>KT</nowiki></code>, sotto onore <code><nowiki>K</nowiki></code> o
<code><nowiki>Q</nowiki></code>) e le carte del compagno. Si combina con la lunghezza (<code><nowiki>S:5 S=KJT</nowiki></code>).

Nel JSON compare <code><nowiki>suit_cards</nowiki></code> nella posizione, es. <code><nowiki>{"S": "KJT", "H": ""}</nowiki></code>
(stringa vuota = nessuna carta alta). Il generatore deve:
* assegnare esattamente quegli onori alla mano e '''escluderli''' dalle altre mani del seme; gli onori non nominati da nessuna posizione sono distribuiti a caso, ma mai a una posizione con <code><nowiki>suit_cards</nowiki></code> per quel seme che non li elenca;
* rispettare comunque <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code> (la validazione segnala le contraddizioni, es. <code><nowiki>S=KQ Shcp:0-2</nowiki></code> o lo stesso onore a due mani).

==== Pattern di mano in un seme (<code><nowiki>S~...</nowiki></code>, stile regex) ====

Descrive '''l'intera mano in quel seme''', dall'alto in basso, come una piccola
espressione regolare ancorata (inizio e fine):

<syntaxhighlight lang="text">
S~AKQ. — A, K, Q + una carta bassa (4 carte)
S~A... — A + tre carte basse (4 carte)
S~AJT9. — A, J, 10, 9 + una bassa
S~AKQ.|A... — alternative: una OPPURE l'altra
S~[KQ]x{2,3} — K o Q (come unico onore) + 2 o 3 carte basse
S~KJT.* — K, J, 10 + qualunque numero di basse (anche zero)
</syntaxhighlight>

Elementi:
* '''Carte alte''' <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>), '''sempre in ordine decrescente''', ciascuna posseduta; quelle non nominate tra A K Q J 10 9 NON sono possedute.
* '''Classe''' <code><nowiki>[KQ]</nowiki></code> = una carta tra quelle (si espande in alternative).
* '''Carta bassa''' <code><nowiki>.</nowiki></code> (o <code><nowiki>x</nowiki></code>) = una carta qualsiasi tra 8 e 2; compare solo in fondo. Quantificatori: <code><nowiki>?</nowiki></code> (0-1), <code><nowiki>*</nowiki></code> (0 o più), <code><nowiki>+</nowiki></code> (1 o più), <code><nowiki>{n}</nowiki></code>, <code><nowiki>{n,m}</nowiki></code>. Più punti si sommano (<code><nowiki>...</nowiki></code> = tre basse).
* '''Alternative''' <code><nowiki>|</nowiki></code>: il generatore ne sceglie una a caso per ogni mano.

È la forma più espressiva di <code><nowiki>S=KJT</nowiki></code> (che resta valida): il pattern fissa anche
la lunghezza (<code><nowiki>S~A...</nowiki></code> = 4 carte). Se c'è anche <code><nowiki>S:N</nowiki></code> i due vincoli devono
essere compatibili (la validazione API segnala le incompatibilità).

Nel JSON compare <code><nowiki>suit_patterns</nowiki></code> nella posizione, già '''normalizzato''' (classi
espanse, quantificatori risolti), così il generatore non deve interpretare la
regex:

<syntaxhighlight lang="json">
"suit_patterns": {
"S": [
{"cards": "AKQ", "low_min": 1, "low_max": 1},
{"cards": "A", "low_min": 3, "low_max": 3}
]
}
</syntaxhighlight>

<code><nowiki>cards</nowiki></code> = carte alte possedute (ordine A K Q J T 9); <code><nowiki>low_min</nowiki></code>/<code><nowiki>low_max</nowiki></code> =
numero di carte basse (2-8), <code><nowiki>low_max: null</nowiki></code> = nessun limite. La lunghezza del
seme è <code><nowiki>len(cards) + numero di basse</nowiki></code>. Il generatore sceglie una alternativa e
rispetta anche <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code>. Gli onori di <code><nowiki>cards</nowiki></code> vanno esclusi dalle altre
mani; quelli non nominati nella mano vanno ad altri a caso.

==== Avversari "quiet" (nessun intervento) ====

<syntaxhighlight lang="text">
opp1 quiet — solo per opp1/opp2
opp2 quiet:0-7 — come quiet, ma con HCP personalizzati
</syntaxhighlight>

<code><nowiki>quiet</nowiki></code> è una '''macro espansa dall'API''': nel JSON non compare mai la parola
<code><nowiki>quiet</nowiki></code>, ma i vincoli già risolti. Chi legge l'API (il generatore) non deve
implementare nulla di nuovo. Si espande in:

<syntaxhighlight lang="text">
S:0-4 H:0-4 D:0-5 C:0-5 hcp:0-9 Shcp:0-3 Hhcp:0-3 Dhcp:0-4 Chcp:0-4
(con quiet:0-7 → hcp:0-7)
</syntaxhighlight>

Significato: gli avversari possono avere colori lunghi (così le mani sono
varie), ma poveri di onori e con pochi punti: nessun colore da 6+ carte
(niente apertura di sbarramento), nessun contro informativo, nessun intervento
naturale credibile. Le distribuzioni ammesse sono quindi molte, ma con punti
ridotti: il generatore ha meno margine sugli HCP della coppia dichiarante
(40 punti totali: apertore+rispondente restano sopra ~22).
I token espliciti scritti sulla stessa posizione '''sostituiscono''' i default,
in qualsiasi ordine: <code><nowiki>opp1 quiet S:0-4</nowiki></code> lascia le picche 0-4 e tiene il resto.
Su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> la macro viene ignorata.

==== Fit (vincolo cross-posizione) ====

<syntaxhighlight lang="text">
fit:H8+ — almeno 8 cuori totali tra i compagni
fit:S9+ — almeno 9 picche totali tra i compagni
fit:M8+ — almeno 8 carte in un seme maggiore (H o S)
fit:m8+ — almeno 8 carte in un seme minore (D o C)
fit:8+ — almeno 8 carte in un seme qualsiasi
</syntaxhighlight>

Il fit si applica tra '''compagni''':
* Se appare su <code><nowiki>opener</nowiki></code> o <code><nowiki>responder</nowiki></code>, o a livello di scenario → coppia dichiarante
* Se appare su <code><nowiki>opp1</nowiki></code> o <code><nowiki>opp2</nowiki></code> → coppia difensiva

=== Formato range ===

{| class="wikitable"
! Sintassi
! Significato
|-
| <code><nowiki>5+</nowiki></code>
| Almeno 5 (min=5, max=null)
|-
| <code><nowiki>0-1</nowiki></code>
| Da 0 a 1 (min=0, max=1)
|-
| <code><nowiki>3</nowiki></code>
| Esattamente 3 (min=3, max=3)
|-
| <code><nowiki>12-21</nowiki></code>
| Da 12 a 21 (min=12, max=21)
|}

Nella risposta JSON, <code><nowiki>max: null</nowiki></code> significa "nessun limite superiore".

=== Semi non menzionati ===

I semi '''non vincolati''' e non coperti da <code><nowiki>x:</nowiki></code> sono distribuiti '''casualmente'''
dal generatore, rispettando il vincolo che il totale delle carte per mano sia 13.

----

== DSL versione 2 (<code><nowiki>dslVersion: 2</nowiki></code>) ==

Tutto ciò che sopra resta valido e '''invariato''': i campi v1 hanno lo stesso significato di prima.
La v2 aggiunge sintassi nuova; '''ogni scenario ha nel JSON il campo <code><nowiki>requires</nowiki></code>''' (elenco di tag,
vuoto se usa solo la v1; vedi sotto) così un motore parziale può rifiutare uno scenario con un
errore esplicito invece di generare mani sbagliate. <code><nowiki>descriptions[].context</nowiki></code> è sempre presente
(array, eventualmente vuoto).
Le definizioni normative (cosa è una fermata, i punti totali, le perdenti...) e
l'architettura del motore sono in '''<code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code>'''.

=== Macro di scrittura (<code><nowiki>@NOME=v1,v2</nowiki></code>) — risolte dal parser, il motore non le vede ===

<syntaxhighlight lang="text">
@M=H,S 1${M}: opener ${M}:5+ hcp:12-21; responder ${M}:3+
</syntaxhighlight>
Genera due scenari (<code><nowiki>1H</nowiki></code>, <code><nowiki>1S</nowiki></code>) sostituendo <code><nowiki>${M}</nowiki></code> ovunque, etichetta compresa.
Più prefissi fanno il prodotto cartesiano (max 64 scenari): <code><nowiki>@M=H,S @N=15-17,12-14</nowiki></code>.
I valori possono essere intervalli (<code><nowiki>hcp:${N}</nowiki></code>): servono anche come parametri del
sistema (SA 15-17 contro 14-16).

=== Semi variabili <code><nowiki>$a $b $c $d</nowiki></code> ===

Un seme "da scegliere" condiviso da più posizioni dello stesso scenario. Ogni
variabile è un seme diverso dalle altre. Dominio dichiarato a livello di scenario
(prima delle posizioni):

<syntaxhighlight lang="text">
Landy: $a=M $b=any opener hcp:12-21 ; opp1 $a:5+ $b:4+ ; responder $a:0-2
</syntaxhighlight>
<code><nowiki>$a=M</nowiki></code> nobili, <code><nowiki>$a=m</nowiki></code> minori, <code><nowiki>$a=any</nowiki></code> (default) qualunque, <code><nowiki>$a=SH</nowiki></code> insieme esplicito.
Una variabile non dichiarata vale <code><nowiki>any</nowiki></code> (tutti i semi). Si usano al posto di <code><nowiki>S H D C</nowiki></code> in: <code><nowiki>$a:5+</nowiki></code> (lunghezza), <code><nowiki>$ahcp:</nowiki></code>, <code><nowiki>$a=KQ</nowiki></code>, <code><nowiki>$a~...</nowiki></code>,
<code><nowiki>stop:$a</nowiki></code>, <code><nowiki>has:$aQ</nowiki></code>, <code><nowiki>kc:$a3</nowiki></code>, confronti (<code><nowiki>$a>$b</nowiki></code>), <code><nowiki>longest:$a</nowiki></code>.
Differisce da <code><nowiki>x:</nowiki></code> (che vale per una sola posizione).
JSON: lo stesso dizionario <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, ... ma con chiave <code><nowiki>"$a"</nowiki></code>;
a livello di scenario <code><nowiki>"vars": {"$a": ["S","H"]}</nowiki></code>.

=== Controlli, carte chiave, carte precise ===

{| class="wikitable"
! Token
! Significato
|-
| <code><nowiki>aces:2</nowiki></code> <code><nowiki>kings:1-2</nowiki></code> <code><nowiki>queens:0</nowiki></code>
| numero di assi / re / dame nella mano
|-
| <code><nowiki>controls:6+</nowiki></code>
| controlli (A=2, K=1)
|-
| <code><nowiki>kc:H3</nowiki></code> <code><nowiki>kc:H2-3</nowiki></code> <code><nowiki>kc:$a3</nowiki></code>
| carte chiave con atout H: i 4 assi + il Re di H (0-5)
|-
| <code><nowiki>has:HQ</nowiki></code> <code><nowiki>has:S10</nowiki></code>
| possiede quella carta precisa
|-
| <code><nowiki>lacks:HQ</nowiki></code>
| NON possiede quella carta
|-
| <code><nowiki>stop:S</nowiki></code> <code><nowiki>nostop:S</nowiki></code>
| ha / non ha una fermata nel seme (definizione in SPEC)
|}

JSON: <code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code> (Range); <code><nowiki>keycards: {"H": Range}</nowiki></code>;
<code><nowiki>cards_held: ["HQ"]</nowiki></code>, <code><nowiki>cards_not_held: ["SK"]</nowiki></code>; <code><nowiki>stoppers: {"S": 1, "H": 0}</nowiki></code>
(1 = deve averla, 0 = non deve averla).

=== Punti e perdenti ===

<code><nowiki>tp:</nowiki></code> punti totali (PO + 1 per ogni carta oltre la quarta in ogni seme),
<code><nowiki>dp:</nowiki></code> punti distribuzione (PO + 3 chicane + 2 singolo + 1 doubleton),
<code><nowiki>ltc:</nowiki></code> perdenti (Losing Trick Count). A livello di scenario: <code><nowiki>pairhcp:25+</nowiki></code>
(PO della coppia dichiarante), <code><nowiki>defhcp:0-14</nowiki></code> (coppia avversaria), <code><nowiki>pairtp:26+</nowiki></code>.
JSON: <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code> (Range) nella posizione; <code><nowiki>pair_hcp: {"declarer": R, "defense": R}</nowiki></code>,
<code><nowiki>pair_tp: {"declarer": R}</nowiki></code> nello scenario.

=== Confronti tra semi e forme precise ===

<syntaxhighlight lang="text">
H>S H>=S H<S H<=S H==S $a>$b — confronto di lunghezze nella stessa mano
longest:H — H è tra i semi più lunghi (pari merito ammesso)
shape:5-4-x-x shape:5422 shape:54xx — lunghezze ordinate in modo decrescente, x = qualsiasi
shape:semi_balanced — 5422 e 6322 (si aggiunge alle classi esistenti)
</syntaxhighlight>
JSON: <code><nowiki>compare: [{"left":"H","op":">=","right":"S"}]</nowiki></code>, <code><nowiki>longest: ["H"]</nowiki></code>,
<code><nowiki>shape_pattern: "54xx"</nowiki></code>.

=== Alternative e negazioni nella stessa mano: <code><nowiki>any(...)</nowiki></code> e <code><nowiki>not(...)</nowiki></code> ===

<syntaxhighlight lang="text">
opener any(S:4+ hcp:12+, H:4+) not(D:6+)
</syntaxhighlight>
<code><nowiki>any(A, B)</nowiki></code>: la mano soddisfa '''almeno una''' delle alternative (separate da virgola;
ogni alternativa è una congiunzione di token). <code><nowiki>not(A, B)</nowiki></code>: la mano non soddisfa
'''nessuna''' delle alternative. Si possono scrivere più gruppi (si combinano in AND);
niente annidamenti.
JSON: <code><nowiki>any: [[altA, altB], ...]</nowiki></code> (lista di gruppi; ogni alternativa è un oggetto
con gli stessi campi di una posizione), <code><nowiki>not: [altA, altB]</nowiki></code>.

=== Contesto dello scenario ===

Token prima delle posizioni: <code><nowiki>weight:3</nowiki></code> (frequenza relativa, 1-100, default 1),
<code><nowiki>dealer:opener</nowiki></code>, <code><nowiki>vul:none|us|them|both</nowiki></code> (<code><nowiki>us</nowiki></code> = apertore+rispondente),
<code><nowiki>auction:1SA,P,2C,P</nowiki></code> (licite, notazione BridgeCards; SA = NT), <code><nowiki>contract:4H</nowiki></code>,
<code><nowiki>declarer:responder</nowiki></code>, <code><nowiki>lead:SK</nowiki></code>.
JSON: <code><nowiki>weight</nowiki></code> (int) e <code><nowiki>context: {"dealer":..,"vul":..,"auction":[..],"contract":"4H","declarer":..,"lead":"SK"}</nowiki></code>.
Il motore deve usare <code><nowiki>dealer</nowiki></code>/<code><nowiki>vul</nowiki></code> quando li espone (per la numerazione del tavolo) e,
se c'è <code><nowiki>lead</nowiki></code>, la carta deve stare nella mano dell'attaccante (a sinistra del
dichiarante) e rispettare i vincoli di quella mano.

=== Tag <code><nowiki>requires</nowiki></code> ===

<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>vars</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>card_presence</nowiki></code> (has/lacks),
<code><nowiki>controls</nowiki></code> (aces/kings/queens/controls/kc), <code><nowiki>points</nowiki></code> (tp/dp/ltc), <code><nowiki>pair_points</nowiki></code>,
<code><nowiki>compare</nowiki></code> (confronti, longest), <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>any_not</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>weight</nowiki></code>.
Le macro <code><nowiki>@</nowiki></code> e <code><nowiki>quiet</nowiki></code> non compaiono: sono già espanse.

=== Avvisi di parsing (<code><nowiki>warnings</nowiki></code>) ===

<code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono <code><nowiki>warnings</nowiki></code> quando un frammento del DSL non è stato
capito e quindi '''scartato''': nome di posizione sbagliato, token sconosciuto o con valore
non valido (<code><nowiki>aces:5</nowiki></code>, <code><nowiki>S=Kx</nowiki></code>, <code><nowiki>shape:4-5-x-x</nowiki></code>), token di scenario dopo le posizioni, posizione
definita due volte, <code><nowiki>quiet</nowiki></code> su opener/responder, gruppo <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> con alternative non
valide (in tal caso '''l'intero gruppo è ignorato''', mai applicato a metà). <code><nowiki>validate.valid</nowiki></code> è 1
solo se non ci sono né <code><nowiki>errors</nowiki></code> né <code><nowiki>warnings</nowiki></code>. Un motore non deve generare se ci sono
<code><nowiki>warnings</nowiki></code> o <code><nowiki>errors</nowiki></code>.

Limiti (oltre i quali il parser avvisa e tronca): 60.000 caratteri di input, 200 scenari, 6
prefissi <code><nowiki>@</nowiki></code>, 64 valori per macro, 64 scenari per espansione, 8 gruppi <code><nowiki>any/not</nowiki></code> e 16 alternative
per posizione. Le etichette non possono contenere <code><nowiki>:</nowiki></code>.

----

== Struttura JSON di uno scenario ==

<syntaxhighlight lang="typescript">
interface Scenario {
label: string; // Etichetta (es. "1H-4C"), vuota se non specificata
positions: {
[posName: string]: Position; // "opener", "responder", "opp1", "opp2"
};
fit: FitConstraint[]; // Vincoli di fit (array, può essere vuoto)
}

interface Position {
suit_patterns?: { // Pattern regex-like normalizzati: {"S":[{"cards":"AKQ","low_min":1,"low_max":1}]}
[suit: string]: { cards: string; low_min: number; low_max: number | null }[];
};
suit_cards?: { [suit: string]: string }; // Onori esatti, es. {"S":"KJT"}; "" = nessuna carta alta
suits?: { // Vincoli lunghezza seme (solo semi esplicitati)
[suit: string]: Range; // "S", "H", "D", "C"
};
hcp?: Range; // HCP totali
suit_hcp?: { // HCP per seme specifico
[suit: string]: Range;
};
x?: Range; // Lunghezza seme wildcard
x_hcp?: Range; // HCP seme wildcard
shape?: string; // Shape class: "balanced", "one_suiter", etc.
}

interface Range {
min: number;
max: number | null; // null = nessun limite superiore
}

interface FitConstraint {
suit: string | null; // "S","H","D","C" o null
suit_class: string | null; // "major", "minor" o null
min: number; // Numero minimo di carte (es. 8)
pair: string; // "declarer" o "defense"
}
</syntaxhighlight>

----

== Logica per il generatore ==

=== Algoritmo base ===

Per ogni scenario:

# '''Scegli lo scenario''': random tra quelli disponibili, oppure lascia scegliere all'utente
# '''Risolvi wildcard''':
#* Se una posizione ha <code><nowiki>x:</nowiki></code>, scegli un seme casuale tra quelli non esplicitamente vincolati
#* <code><nowiki>xhcp:</nowiki></code> si applica allo stesso seme scelto per <code><nowiki>x:</nowiki></code>
# '''Risolvi fit''':
#* Se <code><nowiki>fit.suit</nowiki></code> è specificato, entrambi i compagni devono avere un totale >= <code><nowiki>fit.min</nowiki></code> in quel seme
#* Se <code><nowiki>fit.suit_class</nowiki></code> è "major", scegli tra H e S; se "minor", tra D e C
#* Se entrambi sono null, scegli un seme qualsiasi
#* <code><nowiki>fit.pair</nowiki></code> indica quale coppia: "declarer" (opener+responder) o "defense" (opp1+opp2)
# '''Genera le mani''':
#* Per ogni posizione, genera una mano che rispetti tutti i vincoli
#* I semi senza vincoli vengono riempiti casualmente
#* Il totale delle carte per mano deve essere esattamente 13
#* Il totale delle carte per seme (tutte e 4 le mani) deve essere esattamente 13
# '''Posizioni non menzionate''': se uno scenario non menziona <code><nowiki>opp1</nowiki></code>/<code><nowiki>opp2</nowiki></code>, distribuisci le carte rimanenti casualmente tra gli avversari

=== Priorità dei vincoli ===

# Vincoli di fit (cross-posizione) — determinano la distribuzione di base
# Vincoli di seme specifico (S:, H:, D:, C:) — limitano i singoli semi
# Vincoli wildcard (x:) — dopo aver fissato i semi specifici
# Vincoli HCP (hcp:, Shcp:, xhcp:) — filtro finale
# Shape class (shape:) — validazione della forma complessiva

=== Gestione di <code><nowiki>max: null</nowiki></code> ===

Quando <code><nowiki>max</nowiki></code> è <code><nowiki>null</nowiki></code>, non c'è limite superiore esplicito. I limiti fisici
del bridge si applicano comunque:
* Massimo 13 carte per seme (tutte e 4 le mani)
* Massimo 13 carte per mano
* Massimo 10 HCP per seme (A+K+Q+J = 4+3+2+1)
* Massimo 37 HCP per mano (raro ma teoricamente possibile con tutti gli onori)

----

== Esempi completi ==

=== Splinter (tutti gli scenari specifici) ===

DSL nel template wiki:
<syntaxhighlight lang="text">
1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 //
1H-4D: opener H:5+ hcp:12-21; responder H:4+ D:0-1 Dhcp:0 hcp:10-15 //
1H-4S: opener H:5+ hcp:12-21; responder H:4+ S:0-1 Shcp:0 hcp:10-15 //
1S-4C: opener S:5+ hcp:12-21; responder S:4+ C:0-1 Chcp:0 hcp:10-15 //
1S-4D: opener S:5+ hcp:12-21; responder S:4+ D:0-1 Dhcp:0 hcp:10-15 //
1S-4H: opener S:5+ hcp:12-21; responder S:4+ H:0-1 Hhcp:0 hcp:10-15
</syntaxhighlight>

=== Splinter (compatto con fit e wildcard) ===

<syntaxhighlight lang="text">
dopo 1H: fit:H8+ opener H:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15 //
dopo 1S: fit:S8+ opener S:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15
</syntaxhighlight>

=== Stayman ===

<syntaxhighlight lang="text">
fit a cuori: fit:H8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder H:4+ hcp:8+ //
fit a picche: fit:S8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder S:4+ hcp:8+
</syntaxhighlight>

=== Contro informativo ===

<syntaxhighlight lang="text">
base: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; responder hcp:0-8 //
con intervento: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; opp2 hcp:8+ x:5+
</syntaxhighlight>

=== Preempt 3-a-livello ===

<syntaxhighlight lang="text">
opener H:7+ x:0-1 hcp:5-10
</syntaxhighlight>

=== Overcall con fit avversari ===

<syntaxhighlight lang="text">
overcall semplice: opener hcp:12-21 x:5+; opp1 hcp:10+ x:5+; opp2 fit:8+ //
con barrage: opener hcp:12-21 x:5+; opp1 hcp:6-10 x:6+; opp2 fit:9+
</syntaxhighlight>

----

== Note implementative ==

* L'API è read-only, non richiede token CSRF
* L'accesso anonimo è abilitato di default (<code><nowiki>BridgeShapeAllowAnonymous: true</nowiki></code>) perché i dati sono pubblici e i tool esterni ne hanno bisogno
* Il campo <code><nowiki>raw</nowiki></code> nella risposta <code><nowiki>get</nowiki></code> contiene la stringa DSL originale, utile per debug
* L'azione <code><nowiki>validate</nowiki></code> permette di testare stringhe DSL senza creare pagine wiki
* I calcoli HCP usano la scala standard: A=4, K=3, Q=2, J=1

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Motore e frontend

2026-10-23T05:55:08Z

Lpala: BridgeShape: allineamento docs DSL v2

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — Specifica del motore di smazzate e del frontend (per Play) =

Destinatario: il team/sessione di '''Play''' (generatore di smazzate e relativo frontend).
Obiettivo: realizzare un '''motore completo''' che generi mani per ''qualsiasi'' scenario
descritto nelle pagine di BridgePedia, e un '''frontend''' per consultare gli scenari,
generare, creare e gestire smazzate.

Documenti collegati (leggere in quest'ordine):

# <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code> — riferimento della sintassi (DSL v1 + v2) e del JSON dell'API.
# '''questo file''' — semantica normativa, architettura del motore, test di conformità, specifica del frontend, piano di consegna.
# Wiki: <code><nowiki>Progetto:BridgeShape API</nowiki></code>; le pagine di convenzione con <code><nowiki>shape_constraints</nowiki></code> (elenco: <code><nowiki>GET /api.php?action=bridgeshape&shapeaction=list</nowiki></code>).

Fonte di verità del contratto: l'API <code><nowiki>action=bridgeshape</nowiki></code> di https://bridgepedia.it.
Se questo documento e l'API divergono vale l'API; segnalatelo a BridgePedia.

----

== 1. Contratto, versioni e compatibilità ==

{| class="wikitable"
! Elemento
! Dove
! Uso
|-
| <code><nowiki>dslVersion</nowiki></code>
| risposta di <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code>
| oggi <code><nowiki>2</nowiki></code>. Cambia solo con modifiche non retrocompatibili
|-
| <code><nowiki>scenarios[].requires</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| tag delle capacità richieste dallo scenario (§1.1)
|-
| <code><nowiki>errors</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| contraddizioni semantiche: '''non generare'''
|-
| <code><nowiki>warnings</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| frammenti del DSL scartati dal parser: '''non generare'''
|-
| <code><nowiki>descriptions</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| testo leggibile per scenario, tradotto (<code><nowiki>lang=it|en|...</nowiki></code>)
|-
| <code><nowiki>valid</nowiki></code>
| <code><nowiki>validate</nowiki></code>
| 1/0
|}

Regole di compatibilità:

* I campi nuovi compaiono '''solo se usati''': un motore v1 continua a funzionare sulle pagine v1.
* Campi sconosciuti: ignorarli '''non''' è permesso se compaiono in <code><nowiki>requires</nowiki></code>. Se il motore non supporta un tag di <code><nowiki>requires</nowiki></code>, deve rifiutare lo scenario con codice <code><nowiki>unsupported_feature</nowiki></code> (e nome del tag) e il frontend deve mostrarlo come "non ancora generabile", non nasconderlo.
* Il booleano nel JSON è sempre <code><nowiki>1</nowiki></code>/<code><nowiki>0</nowiki></code> (MediaWiki rimuove i <code><nowiki>false</nowiki></code>).
* Tutte le chiavi di seme sono <code><nowiki>S H D C</nowiki></code> oppure una variabile <code><nowiki>"$a".."$d"</nowiki></code>.

=== 1.1 Tag <code><nowiki>requires</nowiki></code> ===

{| class="wikitable"
! Tag
! Costrutti
! Impatto sul motore
|-
| <code><nowiki>suit_cards</nowiki></code>
| <code><nowiki>S=KJT</nowiki></code>
| assegnazione di onori precisi
|-
| <code><nowiki>suit_patterns</nowiki></code>
| <code><nowiki>S~AKQ.|A...</nowiki></code>
| alternative di mano nel seme
|-
| <code><nowiki>vars</nowiki></code>
| <code><nowiki>$a $b</nowiki></code>, <code><nowiki>vars</nowiki></code>
| seme scelto a runtime, condiviso tra posizioni
|-
| <code><nowiki>stoppers</nowiki></code>
| <code><nowiki>stop:S</nowiki></code>
| filtro/vincolo sulla mano
|-
| <code><nowiki>card_presence</nowiki></code>
| <code><nowiki>has:HQ</nowiki></code>, <code><nowiki>lacks:SK</nowiki></code>
| carte fisse
|-
| <code><nowiki>controls</nowiki></code>
| <code><nowiki>aces kings queens controls kc</nowiki></code>
| conteggi di onori
|-
| <code><nowiki>points</nowiki></code>
| <code><nowiki>tp dp ltc</nowiki></code>
| punteggi derivati
|-
| <code><nowiki>pair_points</nowiki></code>
| <code><nowiki>pairhcp pairtp defhcp</nowiki></code>
| vincolo sulla coppia
|-
| <code><nowiki>compare</nowiki></code>
| <code><nowiki>H>S</nowiki></code>, <code><nowiki>longest:</nowiki></code>
| relazioni tra lunghezze
|-
| <code><nowiki>shape_pattern</nowiki></code>
| <code><nowiki>shape:5-4-x-x</nowiki></code>
| forma ordinata
|-
| <code><nowiki>any_not</nowiki></code>
| <code><nowiki>any(...)</nowiki></code>, <code><nowiki>not(...)</nowiki></code>
| disgiunzioni e negazioni
|-
| <code><nowiki>context</nowiki></code>
| <code><nowiki>dealer vul auction contract declarer lead</nowiki></code>
| metadati e carta d'attacco
|-
| <code><nowiki>weight</nowiki></code>
| <code><nowiki>weight:N</nowiki></code>
| scelta ponderata dello scenario
|}

Le macro <code><nowiki>@M=H,S</nowiki></code> e <code><nowiki>quiet</nowiki></code> sono già espanse dal parser (non compaiono mai).

=== 1.2 Endpoint consigliati lato Play ===

Il motore deve esporre (nomi indicativi; l'importante è la semantica):

<syntaxhighlight lang="text">
POST /api/deals/generate
{
"source": { "page": "Splinter", "scenario": "1H-4C" } // oppure { "dsl": "..." }
| { "page": "Splinter" }, // scenario scelto per peso
"count": 10, // 1..100
"seed": 12345, // opzionale, riproducibilità
"fixed": { "opener": "SAK2.H.D.C", "responder": "..." }, // carte/mani già fissate (§5.6)
"lang": "it"
}
→ 200 { "seed":..., "deals":[ {
"scenario": "1H-4C", "index": 0,
"dealer": "opener", "vul": "none",
"hands": { "opener":"AK2.QJ53.K84.T65", "responder":"...", "opp1":"...", "opp2":"..." },
"bindings": { "$a": "H", "x:opener": "D" }, // come sono state risolte variabili e jolly
"pbn": "[Deal \"N:...\"]", "lin": "...",
"explanation": { "opener": ["♥: 5+ carte", ...], ... }, // dalle descriptions
"stats": { "attempts": 412, "ms": 38 }
} ] }
→ 422 { "code": "...", "reasons": [ {"code":"...", "position":"opp1", "detail":"..."} ] }
GET /api/deals/capabilities → { "dslVersion": 2, "supports": ["suit_cards", ...] }
</syntaxhighlight>

Posizioni → sedi: <code><nowiki>opener</nowiki></code> = Nord per default; il motore ruota in base a <code><nowiki>context.dealer</nowiki></code> solo
per la numerazione/PBN; i vincoli restano sempre in termini di ruoli (<code><nowiki>opener</nowiki></code>, <code><nowiki>responder</nowiki></code>,
<code><nowiki>opp1</nowiki></code> = a sinistra dell'apertore, <code><nowiki>opp2</nowiki></code> = a destra).

----

== 2. Definizioni normative ==

Il motore e il frontend devono usare '''esattamente''' queste definizioni (le descrizioni in
italiano dell'API le presuppongono).

* '''Carte''': A K Q J 10 9 8 7 6 5 4 3 2. Nei vincoli <code><nowiki>T</nowiki></code> = 10. "Carte basse" = 8..2.
* '''PO / HCP''': A=4, K=3, Q=2, J=1. <code><nowiki>Shcp</nowiki></code> ecc. = PO nel solo seme.
* '''Posizioni e coppie''': coppia dichiarante = <code><nowiki>opener</nowiki></code>+<code><nowiki>responder</nowiki></code>; difesa = <code><nowiki>opp1</nowiki></code>+<code><nowiki>opp2</nowiki></code>. Senso di gioco: opener → opp1 → responder → opp2 (orario). Lo stesso per l'attaccante: siede a sinistra del dichiarante (<code><nowiki>declarer</nowiki></code> = opener → attacca opp1; responder → opp2; opp1 → responder; opp2 → opener).
* '''Forma ordinata''': le 4 lunghezze in ordine decrescente (es. 5431).
* '''Classi di forma''' (possono sovrapporsi; le pagine oggi usano solo <code><nowiki>balanced</nowiki></code>):
** <code><nowiki>balanced</nowiki></code>: 4333, 4432, 5332.
** <code><nowiki>semi_balanced</nowiki></code>: 5422, 6322.
** <code><nowiki>one_suiter</nowiki></code>: seme più lungo ≥ 6 e secondo ≤ 3.
** <code><nowiki>two_suiter</nowiki></code>: i due semi più lunghi hanno entrambi ≥ 4 carte e insieme ≥ 9 (5-4, 6-4, 5-5, ...).
** <code><nowiki>three_suiter</nowiki></code>: tre semi ≥ 4 (4441, 5440, 4450...).
** <code><nowiki>any</nowiki></code>: nessun vincolo. Se la vostra implementazione attuale differisce, allineatela a questa o segnalate la differenza.
* '''<code><nowiki>shape_pattern</nowiki></code>''' (<code><nowiki>54xx</nowiki></code>): la forma ordinata deve corrispondere cifra per cifra; <code><nowiki>x</nowiki></code> = qualsiasi.
* '''<code><nowiki>longest:H</nowiki></code>''': la lunghezza di H è ≥ di ogni altro seme (pari merito ammesso).
* '''Confronti''' <code><nowiki>A op B</nowiki></code>: sulle lunghezze dei due semi nella stessa mano; <code><nowiki>==</nowiki></code> uguali.
* '''Controlli''': A=2, K=1 (le dame non contano). <code><nowiki>controls:6+</nowiki></code> somma sulla mano.
* '''Carte chiave per l'atout T''' (<code><nowiki>kc:T</nowiki></code>): numero di assi (0-4) + 1 se possiede il Re di T. Valori 0-5. La Dama di atout si esprime con <code><nowiki>has:TQ</nowiki></code>.
* '''Fermata''' nel seme X (<code><nowiki>stop:X</nowiki></code>): possiede almeno una tra: A; Kx (Re con ≥ 2 carte nel seme); Qxx (Dama con ≥ 3); Jxxx (Fante con ≥ 4). <code><nowiki>nostop:X</nowiki></code> = nessuna di queste.
* '''Punti totali <code><nowiki>tp</nowiki></code>''': PO + (per ogni seme, <code><nowiki>max(0, lunghezza − 4)</nowiki></code>).
* '''Punti distribuzione <code><nowiki>dp</nowiki></code>''': PO + 3 per ogni chicane + 2 per ogni singolo + 1 per ogni doubleton.
* '''Perdenti <code><nowiki>ltc</nowiki></code>''' (Losing Trick Count): per ogni seme con <code><nowiki>n</nowiki></code> carte, considerare <code><nowiki>m = min(n,3)</nowiki></code>; perdenti del seme = <code><nowiki>m − (numero di A, K, Q posseduti nel seme)</nowiki></code>; somma sui 4 semi. (Seme vuoto = 0.)
* '''<code><nowiki>S=KJT</nowiki></code>''' (<code><nowiki>suit_cards</nowiki></code>): tra A K Q J 10 9 possiede ''esattamente'' quelle elencate; 8..2 liberi. Stringa vuota = nessuna carta alta. Gli onori elencati sono esclusi dalle altre mani solo per quel che riguarda la proprietà: ogni carta ha un unico proprietario.
* '''<code><nowiki>S~...</nowiki></code>''' (<code><nowiki>suit_patterns</nowiki></code>): una sola alternativa (scelta a caso, uniformemente tra quelle compatibili con gli altri vincoli) descrive tutta la mano in quel seme: <code><nowiki>cards</nowiki></code> + tra <code><nowiki>low_min</nowiki></code> e <code><nowiki>low_max</nowiki></code> carte basse (<code><nowiki>low_max: null</nowiki></code> = illimitato, ma ≤ 13 − len(cards)).
* '''<code><nowiki>x:</nowiki></code>''' (jolly di posizione): un seme scelto a caso tra quelli ''non'' vincolati esplicitamente in quella posizione; <code><nowiki>xhcp:</nowiki></code> si riferisce allo stesso seme. Il jolly '''non''' è condiviso con altre posizioni.
* '''Variabili <code><nowiki>$a..$d</nowiki></code>''': a inizio generazione ogni variabile usata riceve un seme dal proprio dominio (<code><nowiki>vars</nowiki></code>, default tutti e quattro). Variabili diverse hanno '''semi diversi'''; una variabile non dichiarata ha dominio completo. Una variabile può coincidere con un seme nominato esplicitamente (<code><nowiki>$a</nowiki></code> e <code><nowiki>H</nowiki></code>): se non è voluto, restringere il dominio (<code><nowiki>$a=SD</nowiki></code>). La scelta è uniforme tra le assegnazioni che rendono lo scenario soddisfacibile.
* '''<code><nowiki>fit</nowiki></code>''': somma delle lunghezze dei due compagni nel seme (o in qualunque seme del tipo <code><nowiki>major</nowiki></code>/ <code><nowiki>minor</nowiki></code>/<code><nowiki>any</nowiki></code>, a scelta del motore, uniformemente tra i semi che soddisfano il vincolo).
* '''<code><nowiki>any(A,B)</nowiki></code>''': la mano soddisfa almeno una alternativa. '''<code><nowiki>not(A,B)</nowiki></code>''': non ne soddisfa nessuna. Più gruppi → AND. Dentro <code><nowiki>A</nowiki></code>,<code><nowiki>B</nowiki></code> valgono gli stessi campi di una posizione (senza <code><nowiki>any/not/fit</nowiki></code>).
* '''<code><nowiki>pair_hcp.declarer</nowiki></code>''' = PO(opener)+PO(responder); <code><nowiki>defense</nowiki></code> = PO(opp1)+PO(opp2). <code><nowiki>pair_tp</nowiki></code>: somma <code><nowiki>tp</nowiki></code>.
* '''Posizioni non nominate''': ricevono le carte rimanenti a caso (nessun vincolo); non applicare <code><nowiki>quiet</nowiki></code> implicito.
* '''<code><nowiki>weight</nowiki></code>''': probabilità relativa di scelta dello scenario quando non è scelto dall'utente (default 1). Non influenza la generazione dentro lo scenario.
* '''<code><nowiki>context</nowiki></code>''': metadati. <code><nowiki>dealer</nowiki></code> e <code><nowiki>vul</nowiki></code> (<code><nowiki>us</nowiki></code> = coppia dichiarante) vanno riportati nell'output (PBN/LIN) e mostrati. <code><nowiki>auction</nowiki></code> è la sequenza da mostrare/verificare (notazione BridgeCards: <code><nowiki>P</nowiki></code>, <code><nowiki>X</nowiki></code>, <code><nowiki>XX</nowiki></code>, <code><nowiki>1NT</nowiki></code>...). <code><nowiki>contract</nowiki></code>/<code><nowiki>declarer</nowiki></code>/<code><nowiki>lead</nowiki></code>: vedi §5.7.

----

== 3. Architettura consigliata del motore ==

Pipeline per ogni mano richiesta:

<syntaxhighlight lang="text">
parse risposta API → controllo requires/errors/warnings
→ scelta scenario (utente | peso)
→ ASSEGNAZIONE SIMBOLICA : variabili $a.., jolly x:, fit, alternative any()/S~, pattern di forma
→ MATRICE DELLE LUNGHEZZE : 4 posizioni × 4 semi (somme 13 per riga e per colonna)
→ ASSEGNAZIONE DELLE CARTE : carte fissate/vincolate, poi resto casuale
→ RIPARAZIONE PUNTI : scambi mirati per entrare negli intervalli PO/tp/dp/ltc/controlli
→ VERIFICA FINALE : valutazione indipendente di TUTTI i vincoli sulla smazzata completa
→ output + spiegazione
</syntaxhighlight>

Punti chiave:

# '''Verifica finale indipendente''' (il "giudice"): una funzione pura <code><nowiki>satisfies(deal, scenario, bindings)</nowiki></code> che valuta ogni vincolo dalle definizioni di §2. Ogni smazzata emessa deve passarla. Questa funzione è anche la base dei test e del pulsante "verifica" del frontend.
# '''Costruzione, non solo scarto.''' Il rejection sampling puro non regge scenari stretti (es. Gran rever nel Multirever, <code><nowiki>quiet</nowiki></code> con coppia 25+ PO). Costruire prima la matrice delle lunghezze con propagazione dei vincoli (backtracking con limiti per riga/colonna), poi assegnare le carte onore per posizione secondo <code><nowiki>suit_cards</nowiki></code>/<code><nowiki>suit_patterns</nowiki></code>/<code><nowiki>has</nowiki></code>/<code><nowiki>lacks</nowiki></code>/<code><nowiki>aces</nowiki></code>..., infine le basse.
# '''Riparazione PO''': dopo l'assegnazione, se i PO (o <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, controlli, <code><nowiki>pair_*</nowiki></code>) sono fuori intervallo, scambiare due carte tra due mani preservando lunghezze e vincoli ''rigidi'' (carte fissate, pattern). Ricerca locale con budget; poi nuovo tentativo dall'inizio.
# '''Uniformità''': l'obiettivo è una distribuzione quasi uniforme tra le smazzate che soddisfano lo scenario. Le euristiche di costruzione introducono distorsioni: misuratele (§7.3) e non dichiarate "uniformi" se non lo sono.
# '''Budget e fallimenti''': limite di tempo (oggi 2,5 s CPU/mano), massimo tentativi, e diagnosi. Su fallimento restituire 422 con i <code><nowiki>reasons</nowiki></code> di §6, mai una smazzata che viola i vincoli.
# '''Riproducibilità''': stesso <code><nowiki>seed</nowiki></code> + stessa versione del DSL → stessa smazzata. Salvare nel record <code><nowiki>seed</nowiki></code>, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>source.page</nowiki></code>, <code><nowiki>revid</nowiki></code> della pagina se disponibile.
# '''Concorrenza e cache''': cache del JSON dell'API per pagina con TTL breve (60 s) e rivalidazione sulla <code><nowiki>list</nowiki></code>; mai servire DSL non validato.

=== 3.1 Ordine di risoluzione dei vincoli ===

# Variabili <code><nowiki>$a..</nowiki></code>, jolly <code><nowiki>x:</nowiki></code>, <code><nowiki>fit</nowiki></code> (decidono ''quali'' semi).
# Alternative: scegliere un ramo per ogni <code><nowiki>any()</nowiki></code> e ogni <code><nowiki>S~</nowiki></code> (escludendo i rami impossibili con i vincoli già noti); applicare <code><nowiki>not()</nowiki></code> come vincoli di esclusione.
# Lunghezze (<code><nowiki>suits</nowiki></code>, <code><nowiki>compare</nowiki></code>, <code><nowiki>longest</nowiki></code>, <code><nowiki>shape</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>fit</nowiki></code>).
# Carte precise (<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>cards_held/not_held</nowiki></code>, <code><nowiki>lead</nowiki></code>).
# Conteggi (<code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code>, <code><nowiki>keycards</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>).
# Punteggi derivati (<code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, <code><nowiki>pair_*</nowiki></code>) e <code><nowiki>stoppers</nowiki></code>.
# Verifica finale.

Un vincolo è "rigido" se riguarda carte/lunghezze fissate (1-4); "morbido" se si ripara per scambio (5-6).

----

== 4. Semantica delle combinazioni delicate ==

* <code><nowiki>quiet</nowiki></code> è già espanso in <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>: nessun trattamento speciale (il campo <code><nowiki>quiet: 1</nowiki></code> serve solo alla descrizione). Una difesa quiet '''riduce''' il margine PO per la coppia dichiarante: verificare la compatibilità prima di costruire (<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>...).
* <code><nowiki>S=...</nowiki></code> / <code><nowiki>S~...</nowiki></code> + <code><nowiki>S:N</nowiki></code> + <code><nowiki>Shcp</nowiki></code>: devono essere coerenti; l'API segnala le contraddizioni evidenti.
* Una carta (<code><nowiki>has:HQ</nowiki></code>) può comparire in una sola posizione; due posizioni con la stessa carta sono un errore di validazione, non un caso da risolvere a caso.
* <code><nowiki>any()</nowiki></code> dentro una posizione con variabili: le variabili si legano '''prima''', poi si sceglie il ramo.
* <code><nowiki>not()</nowiki></code> con <code><nowiki>S~</nowiki></code>: escludere dall'insieme di alternative, non solo filtrare a posteriori.
* <code><nowiki>longest:</nowiki></code> e <code><nowiki>compare</nowiki></code> valgono sulle lunghezze finali (dopo il bind delle variabili).
* <code><nowiki>context.lead</nowiki></code> (<code><nowiki>SK</nowiki></code>): la carta deve stare nella mano dell'attaccante (§2) e quella mano deve soddisfare i suoi vincoli (es. se ha <code><nowiki>S=KJT</nowiki></code>, <code><nowiki>lead:SK</nowiki></code> è coerente, <code><nowiki>lead:SQ</nowiki></code> no).

----

== 5. Funzionalità del motore (elenco completo da realizzare) ==

=== 5.1 Core (parità v1) — già in produzione, da conservare ===
Lunghezze, PO totali/per seme, <code><nowiki>x:</nowiki></code>, <code><nowiki>shape:</nowiki></code>, <code><nowiki>fit</nowiki></code>, <code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>quiet</nowiki></code>
(espanso), 422 con ragioni, tetto 2,5 s.

=== 5.2 Nuove funzioni DSL v2 ===
Tutte le righe di §1.1. Priorità di consegna in §9.

=== 5.3 Mani multiple e serie ===
<code><nowiki>count</nowiki></code> ≤ 100 per richiesta; opzione <code><nowiki>distinct: true</nowiki></code> (nessuna mano duplicata nella serie);
opzione <code><nowiki>balance: "round_robin" | "weighted"</nowiki></code> per distribuire gli scenari della stessa convenzione.

=== 5.4 Spiegazione per mano ===
Per ogni smazzata: per posizione, elenco dei vincoli con esito (✓) e valore effettivo
("♥: 5 carte, richiesto 5+"), e i '''binding''' (<code><nowiki>$a = ♥</nowiki></code>, <code><nowiki>x di opener = ♦</nowiki></code>). Serve al frontend.

=== 5.5 Verifica di una smazzata data ===
<code><nowiki>POST /api/deals/check</nowiki></code> con quattro mani e una <code><nowiki>source</nowiki></code> → elenco di vincoli soddisfatti/violati.
Usa lo stesso giudice del §3. Serve a: smazzate inserite a mano, correzione in aula, test.

=== 5.6 Mani parzialmente fissate (<code><nowiki>fixed</nowiki></code>) ===
Accettare mani complete o parziali (<code><nowiki>"opener": "SAK2."</nowiki></code>, o carte singole) e completare il resto
rispettando lo scenario. Se impossibile → 422 <code><nowiki>fixed_cards_conflict</nowiki></code>.

=== 5.7 Contesto di gioco della carta ===
<code><nowiki>contract</nowiki></code>, <code><nowiki>declarer</nowiki></code>, <code><nowiki>lead</nowiki></code>: il motore garantisce che la carta d'attacco sia nella mano giusta e
fornisce nel risultato <code><nowiki>play: { "contract":"4H", "declarer":"responder", "leader":"opp2", "lead":"SK" }</nowiki></code>.
(Il gioco successivo, oltre la prima carta, non è nel DSL: per Segnali e Attacchi la prima carta e le
mani bastano a mostrare la situazione.)

=== 5.8 Statistiche ===
Per scenario: tasso di successo, tentativi medi, p95 ms, codici di fallimento. Esposte in
<code><nowiki>GET /api/deals/stats</nowiki></code> e inviate a BridgePedia (§8.5) per tarare i vincoli.

----

== 6. Codici di errore (422 e simili) ==

Già in uso: <code><nowiki>exact_cards_always_conflict</nowiki></code>, <code><nowiki>generation_time_limit</nowiki></code>, <code><nowiki>suit_cards_below_hcp_min</nowiki></code>,
<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>, <code><nowiki>suit_cards_exceed_hcp_max</nowiki></code>. Da aggiungere:

{| class="wikitable"
! Codice
! Quando
|-
| <code><nowiki>unsupported_feature</nowiki></code>
| lo scenario richiede un tag non supportato (<code><nowiki>detail</nowiki></code>: il tag)
|-
| <code><nowiki>dsl_errors</nowiki></code>
| l'API ha restituito <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> (riportarli)
|-
| <code><nowiki>variable_unsatisfiable</nowiki></code>
| nessuna assegnazione dei semi variabili rende lo scenario possibile
|-
| <code><nowiki>fixed_cards_conflict</nowiki></code>
| <code><nowiki>fixed</nowiki></code> contraddice lo scenario o carte duplicate
|-
| <code><nowiki>pair_points_unreachable</nowiki></code>
| <code><nowiki>pairhcp/pairtp</nowiki></code> incompatibili con i limiti per posizione
|-
| <code><nowiki>lead_conflict</nowiki></code>
| <code><nowiki>lead</nowiki></code> incompatibile con la mano dell'attaccante
|-
| <code><nowiki>no_branch_left</nowiki></code>
| <code><nowiki>any()</nowiki></code>/<code><nowiki>S~</nowiki></code>/<code><nowiki>not()</nowiki></code> eliminano tutti i rami
|-
| <code><nowiki>shape_unreachable</nowiki></code>
| forma/lunghezze incompatibili con 13 carte per mano e per seme
|-
| <code><nowiki>invalid_request</nowiki></code>
| parametri non validi (count, seed...)
|}

Ogni 422 porta <code><nowiki>reasons: [{code, position?, detail}]</nowiki></code> leggibili dal frontend.

----

== 7. Test di conformità e qualità ==

=== 7.1 Invarianti (property test, ≥ 10.000 smazzate per scenario del wiki) ===
* 52 carte distinte; 13 per mano; nessun duplicato.
* <code><nowiki>satisfies()</nowiki></code> vero per ogni smazzata emessa (il giudice '''non''' deve condividere codice con il generatore).
* Stesso seed → stesso risultato.

=== 7.2 Casi minimi per costrutto (la DSL → cosa deve valere) ===

{| class="wikitable"
! #
! DSL
! Asserzione
|-
| 1
| <code><nowiki>opener S:5+ hcp:12-21</nowiki></code>
| ♠ ≥ 5, PO in intervallo
|-
| 2
| <code><nowiki>@M=H,S opener ${M}:5+</nowiki></code>
| due scenari generabili (<code><nowiki>H</nowiki></code>, <code><nowiki>S</nowiki></code>)
|-
| 3
| <code><nowiki>$a=M opener $a:5+; responder $a:3+</nowiki></code>
| in ogni mano: un nobile ≥5 in opener, lo stesso seme ≥3 in responder; entrambi i nobili compaiono su 1000 mani
|-
| 4
| <code><nowiki>$a=M $b=m opener $a:5+ $b:4+</nowiki></code>
| $a nobile, $b minore, mai lo stesso seme
|-
| 5
| <code><nowiki>opener stop:S</nowiki></code> su 1000 mani
| tutte le mani hanno A, Kx, Qxx o Jxxx a ♠
|-
| 6
| <code><nowiki>opener nostop:S S:3+</nowiki></code>
| nessuna mano con A, né Kx, Qxx o Jxxx a ♠ (con 3 carte: né A, né K, né Q)
|-
| 7
| <code><nowiki>opener aces:2 kc:H4</nowiki></code>
| 2 assi; assi + K♥ = 4
|-
| 8
| <code><nowiki>opener has:HQ lacks:SK</nowiki></code>
| Q♥ presente, K♠ assente
|-
| 9
| <code><nowiki>opener tp:20-22</nowiki></code>
| <code><nowiki>tp</nowiki></code> corretto con la definizione di §2
|-
| 10
| <code><nowiki>opener ltc:6-7</nowiki></code>
| LTC con la definizione di §2
|-
| 11
| <code><nowiki>opener H>S</nowiki></code> e <code><nowiki>opener H>=S longest:H</nowiki></code>
| confronti rispettati; <code><nowiki>longest</nowiki></code> con pari merito
|-
| 12
| <code><nowiki>opener shape:5-4-x-x</nowiki></code>
| 5 e 4 come due semi più lunghi in ordine; gli altri due sommano 4
|-
| 13
| <code><nowiki>opener shape:semi_balanced</nowiki></code>
| solo 5422 e 6322
|-
| 14
| <code><nowiki>opener any(S:5+, H:5+)</nowiki></code>
| almeno un nobile ≥ 5
|-
| 15
| <code><nowiki>opener not(S:4+, H:4+)</nowiki></code>
| nessun nobile ≥ 4
|-
| 16
| <code><nowiki>opener any(S:4+ hcp:12+, H:4+)</nowiki></code>
| rami composti
|-
| 17
| <code><nowiki>pairhcp:25+ ... opp1 quiet; opp2 quiet</nowiki></code>
| coppia ≥ 25, avversari entro i limiti quiet
|-
| 18
| <code><nowiki>weight:1 ... // weight:3 ...</nowiki></code>
| 1000 estrazioni ~ 25%/75% (± tolleranza)
|-
| 19
| <code><nowiki>dealer:opp1 vul:both</nowiki></code>
| output con dealer/vul corretti e PBN ruotato
|-
| 20
| <code><nowiki>declarer:responder lead:SK opp2 S=KJT</nowiki></code>
| K♠ in opp2; con <code><nowiki>lead:SQ</nowiki></code> → 422 <code><nowiki>lead_conflict</nowiki></code>
|-
| 21
| <code><nowiki>fixed</nowiki></code> con Q♥ in opener
| opener ha Q♥ e rispetta lo scenario
|-
| 22
| scenario impossibile (<code><nowiki>S=AK Shcp:0-2</nowiki></code>)
| 422 con ragione
|-
| 23
| scenario con <code><nowiki>unsupported</nowiki></code> simulato
| 422 <code><nowiki>unsupported_feature</nowiki></code>
|}

Aggiungere come test di regressione '''tutti gli scenari reali''' delle pagine del wiki
(<code><nowiki>shapeaction=list</nowiki></code> → <code><nowiki>get</nowiki></code>): per ciascuno ≥ 1000 smazzate valide entro il budget, oppure una
diagnosi documentata. Gli scenari più duri oggi: ''Multirever'' (Gran rever, 20 scenari) e
''Segnale di Smith'' (20 scenari con <code><nowiki>suit_cards</nowiki></code>).

=== 7.3 Qualità statistica ===
Per ogni scenario del wiki misurare su 5000 mani: distribuzione delle lunghezze e dei PO nei limiti
consentiti, tasso di riuscita al primo tentativo, tempo p50/p95. Segnalare distorsioni evidenti
(es. la posizione A prende sempre i PO alti).

=== 7.4 Prestazioni ===
Obiettivo: p95 < 300 ms per mano sugli scenari comuni; < 2,5 s sul peggiore. Se non si rispetta,
non allargare i vincoli: segnalare lo scenario a BridgePedia (§8.5) che può rivederlo.

----

== 8. Frontend di Play ==

Il frontend deve permettere di '''consultare''', '''generare''', '''creare''' e '''gestire''' smazzate.
Lingua: italiano, con i18n predisposta (en, fr, es, de). Tutti i testi dei vincoli vengono
dall'API (<code><nowiki>descriptions</nowiki></code>, parametro <code><nowiki>lang</nowiki></code>): non riscriverli.

=== 8.1 Catalogo delle convenzioni ===
* Elenco da <code><nowiki>shapeaction=list</nowiki></code> (con vincoli) e <code><nowiki>listall</nowiki></code> (tutte, con <code><nowiki>hasShape</nowiki></code>).
* Per ogni voce: titolo, numero di scenari, link alla pagina del wiki, stato: ''generabile'', ''parzialmente generabile'' (alcuni scenari con <code><nowiki>requires</nowiki></code> non supportato), ''non generabile''.
* Ricerca testuale; filtri per tipologia/sistema se esposti; badge "da verificare" per le traduzioni non verificate.
* Le 27 convenzioni senza vincoli compaiono come "scenari in arrivo" con link al wiki.

=== 8.2 Visualizzatore di scenario ===
* Tabella a colonne per posizione (come la tabella del wiki): etichetta scenario, frasi di <code><nowiki>descriptions[i].positions</nowiki></code>, <code><nowiki>positionLabels</nowiki></code> (rispettare i ruoli personalizzati, es. "Attaccante"), <code><nowiki>fit</nowiki></code>, <code><nowiki>context</nowiki></code>.
* Semi ♥ ♦ in rosso. Mostrare <code><nowiki>requires</nowiki></code> come chip (tooltip con spiegazione).
* Pulsante "Mostra DSL" (testo <code><nowiki>raw</nowiki></code>) e "Apri la pagina nel wiki".

=== 8.3 Generatore ===
* Scelta convenzione → scenario (singolo, "a caso", "tutti a rotazione", pesato) → quantità (1-100) → opzioni (seed, mani distinte, nascondi avversari).
* Risultato: schede smazzata con 4 mani (formato BridgeCards: ♠♥♦♣, bordi, dealer, vulnerabilità), etichetta scenario, '''pannello "perché questa mano"''': per posizione le frasi di <code><nowiki>explanation</nowiki></code> con spunta, binding (<code><nowiki>$a = ♥</nowiki></code>), PO/lunghezze effettive.
* Azioni per smazzata: rigenera, "blocca questa mano e rigenera le altre" (usa <code><nowiki>fixed</nowiki></code>), copia link con seed, esporta PBN/LIN/immagine, aggiungi alla raccolta.
* Se la licita <code><nowiki>auction</nowiki></code> è presente: mostrarla con <code><nowiki><bidding></nowiki></code> (stile BridgeCards) o nascosta per esercizio ("indovina la risposta").
* Gestione 422: messaggio per codice (§6) con suggerimento ("lo scenario è impossibile perché..."). Per <code><nowiki>unsupported_feature</nowiki></code>: spiegare quale capacità manca.

=== 8.4 Editor / creazione di scenari ===
Due modalità sincronizzate:

# '''Modulo guidato''' per posizione (Apertore, Compagno, Avv. sinistro, Avv. destro):
#* lunghezze per seme (slider min-max), PO totali e per seme, forma (classi + schema <code><nowiki>5-4-x-x</nowiki></code>);
#* griglia carte per seme (A K Q J 10 9 + "basse") con stati ''deve avere / non deve avere / indifferente'' che produce <code><nowiki>S=...</nowiki></code>; costruttore di pattern per <code><nowiki>S~</nowiki></code> con anteprima;
#* interruttori: fermata (per seme), assi/re/dame/controlli, carte chiave con atout, <code><nowiki>tp/dp/ltc</nowiki></code>, confronti tra semi, <code><nowiki>any(...)</nowiki></code>/<code><nowiki>not(...)</nowiki></code> come gruppi aggiungibili;
#* variabili di seme <code><nowiki>$a..$d</nowiki></code> con dominio (nobili/minori/qualsiasi);
#* contesto: dealer, vulnerabilità, licita, contratto, attacco, peso;
#* avversari: pulsante '''quiet''' (e <code><nowiki>quiet:max</nowiki></code>);
#* macro: "ripeti per ogni nobile / minore / seme" genera <code><nowiki>@M=...</nowiki></code>.
# '''Editor testuale''' del DSL con evidenziazione, completamento e ''validazione live'': chiama <code><nowiki>shapeaction=validate</nowiki></code> (debounce 400 ms) e mostra <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>, <code><nowiki>descriptions</nowiki></code> e <code><nowiki>requires</nowiki></code> (con il supporto del motore). Le due modalità si convertono a vicenda (modulo → DSL è obbligatorio; DSL → modulo almeno per i costrutti elementari, il resto resta testuale).

* Pulsante "Prova": genera 5 mani di test dallo scenario in modifica e mostra tempi e tassi di riuscita.
* Salvataggio come '''bozza personale''' in Play (non scrive sul wiki). Pulsante "Copia per BridgePedia" produce la riga <code><nowiki>shape_constraints</nowiki></code> da incollare nella pagina (gli editor del wiki fanno il resto).
* Libreria di '''modelli''' presi dalle convenzioni del wiki ("parti da Landy").

=== 8.5 Retroazione verso BridgePedia ===
* Pulsante "Segnala scenario problematico" (lento / troppo raro / 422 / distribuzione strana) che invia: pagina, scenario, <code><nowiki>dslVersion</nowiki></code>, codice errore, statistiche (§5.8) al canale concordato (sessione/issue). Nessuna scrittura diretta sul wiki.
* Report periodico automatico delle statistiche di generazione per scenario.

=== 8.6 Smazzate manuali ===
* Compositore: assegnare le 52 carte alle quattro mani con trascinamento o digitazione (<code><nowiki>AK2.QJ5.K84.T65</nowiki></code>), controllo duplicati, completamento casuale delle carte mancanti (opzionalmente rispettando uno scenario: usa <code><nowiki>fixed</nowiki></code>).
* Pulsante "Verifica rispetto a uno scenario" (§5.5) con l'elenco dei vincoli soddisfatti e violati.
* Importa/esporta PBN, LIN, testo semplice.

=== 8.7 Gestione delle smazzate ===
* Raccolte ("mazzi di esercizio"): nome, descrizione, convenzione, tag; ordinamento; duplicati evitati.
* Ricerca per convenzione, scenario, tag, data; filtri per vulnerabilità, dealer.
* Metadati salvati: <code><nowiki>seed</nowiki></code>, <code><nowiki>source.page</nowiki></code>, scenario, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>revid</nowiki></code>, data, autore.
* Note personali per smazzata; stampa di una raccolta (fogli A4 con 4 o 6 smazzate per pagina, versione "solo mano dell'apertore" per esercizio).
* Condivisione: link con seed/raccolta, permessi (privato, gruppo, pubblico) secondo il modello utenti di Play. Esportazione in blocco (PBN).
* Modalità "esercizio di licita": mostra le mani di un lato, l'utente inserisce la licita, il frontend confronta con <code><nowiki>context.auction</nowiki></code> se presente.

=== 8.8 Requisiti trasversali ===
* Mobile first; tastiera accessibile; semi anche come lettere per daltonici.
* Nessuna dipendenza dal wiki per il rendering delle carte (usare componenti propri; stile coerente con BridgeCards).
* Tempi: la generazione deve mostrare avanzamento e poter essere annullata.
* Tracciare (analytics interni) tempi, errori e scenari più usati.
* Testo dei vincoli sempre da <code><nowiki>descriptions</nowiki></code> con <code><nowiki>lang</nowiki></code> coerente con la lingua dell'interfaccia.

----

== 9. Piano di consegna consigliato ==

{| class="wikitable"
! Fase
! Contenuto
! Esito atteso
|-
| '''P0 — compatibilità''' (subito)
| leggere <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>requires</nowiki></code>, <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>; esporre <code><nowiki>/capabilities</nowiki></code>; rifiutare con <code><nowiki>unsupported_feature</nowiki></code>; giudice <code><nowiki>satisfies()</nowiki></code> per v1
| nessuna smazzata errata con le pagine nuove
|-
| '''P1 — core v2'''
| macro (nessun lavoro, già espanse), <code><nowiki>weight</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, classi nuove, <code><nowiki>compare</nowiki></code>/<code><nowiki>longest</nowiki></code>, <code><nowiki>any/not</nowiki></code>, <code><nowiki>pair_*</nowiki></code>
| scenari per Landy/Cappelletti/DONT/Smolen con forme e alternative
|-
| '''P2 — variabili e carte'''
| <code><nowiki>vars</nowiki></code> condivise tra posizioni, <code><nowiki>has/lacks</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>aces/kings/queens/controls/kc</nowiki></code>
| Michaels, Sputnik, Lebensohl, Blackwood/RKCB, Exclusion
|-
| '''P3 — punteggi'''
| <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>
| sistemi a forza (Fiori forte, 2♣ forte, Gazzilli)
|-
| '''P4 — frontend lettura'''
| catalogo, visualizzatore, generatore con spiegazioni
| tutti possono provare le convenzioni
|-
| '''P5 — frontend creazione'''
| editor guidato + testuale con validazione live, "Prova", bozze
| gli editor creano e collaudano scenari senza il wiki
|-
| '''P6 — gestione'''
| raccolte, smazzate manuali, <code><nowiki>check</nowiki></code>, <code><nowiki>fixed</nowiki></code>, esportazioni, esercizi di licita
| uso didattico completo
|-
| '''P7 — qualità'''
| suite di conformità (§7), statistiche, report verso BridgePedia
| motore misurabile
|}

Ogni fase deve chiudersi con i test di §7 per i costrutti introdotti. BridgePedia estende le
pagine del wiki man mano che i tag diventano disponibili: '''comunicate a ogni fase la lista dei tag supportati''' (<code><nowiki>/capabilities</nowiki></code>) così il wiki passa dalle approssimazioni (pattern <code><nowiki>S~</nowiki></code>) ai
costrutti nativi solo quando il motore li regge.

----

== 10. Cosa fa BridgePedia (per non sovrapporsi) ==

* Mantiene il DSL, il parser, le descrizioni e l'API; aggiunge costrutti su richiesta motivata.
* Scrive e tiene aggiornati gli scenari nelle pagine delle convenzioni; le 27 mancanti saranno coperte via via con i costrutti v2.
* Fornisce il catalogo di ricette (come descrivere Landy, Blackwood, un attacco sotto onore...).
* Riceve da Play le segnalazioni di §8.5 e rivede i vincoli troppo duri.

== 11. Decisioni aperte (da concordare con Play) ==

# Definizione definitiva delle classi di forma (§2) rispetto a quanto già implementato.
# Formato di <code><nowiki>explanation</nowiki></code> (testo semplice vs struttura con esito per vincolo).
# Modello di persistenza e permessi delle raccolte (utenti Play).
# Canale per le segnalazioni verso BridgePedia (§8.5).
# Se <code><nowiki>fixed</nowiki></code> deve accettare anche vincoli aggiuntivi temporanei (override locali dello scenario).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape API

2026-10-23T05:55:07Z

Lpala: BridgeShape: allineamento docs DSL v2

Documentazione BridgeShape: [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — API per Generatori di Smazzate =

Documentazione tecnica per chi sviluppa un generatore di smazzate di test
che legge i vincoli di distribuzione (shape constraints) dalle convenzioni
di BridgePedia.

== Panoramica ==

Ogni pagina wiki di convenzione su BridgePedia può definire nel template
<code><nowiki>{{Convenzione}}</nowiki></code> un campo <code><nowiki>shape_constraints</nowiki></code> che descrive, in un formato
DSL compatto, i vincoli di distribuzione delle mani dei 4 giocatori al tavolo.

L'estensione '''BridgeShape''' espone un'API REST/JSON per leggere questi
vincoli in modo strutturato.

----

== API Endpoint ==

<syntaxhighlight lang="text">
GET /api.php?action=bridgeshape&shapeaction=ACTION&format=json
</syntaxhighlight>

=== Azioni disponibili ===

{| class="wikitable"
! Azione
! Descrizione
! Parametri
|-
| <code><nowiki>get</nowiki></code>
| Vincoli per una singola convenzione
| <code><nowiki>pageid</nowiki></code> oppure <code><nowiki>title</nowiki></code>
|-
| <code><nowiki>list</nowiki></code>
| Elenco convenzioni con vincoli definiti
| —
|-
| <code><nowiki>listall</nowiki></code>
| Elenco tutte le convenzioni (con/senza vincoli)
| —
|-
| <code><nowiki>validate</nowiki></code>
| Valida una stringa DSL senza bisogno di una pagina wiki
| <code><nowiki>dsl</nowiki></code>
|}

=== Esempi di chiamata ===

<syntaxhighlight lang="bash">
# Per titolo pagina
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&title=Splinter&format=json"

# Per page ID
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&pageid=42&format=json"

# Elenco pagine con vincoli
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=list&format=json"

# Validare una stringa DSL
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=validate&dsl=opener+H:5%2B+hcp:12-21&format=json"
</syntaxhighlight>

----

== Formato risposta JSON ==

=== <code><nowiki>shapeaction=get</nowiki></code> ===

<syntaxhighlight lang="json">
{
"shapeconstraints": {
"pageId": 42,
"raw": "1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 // ...",
"scenarios": [
{
"label": "1H-4C",
"positions": {
"opener": {
"suits": {
"H": { "min": 5, "max": null }
},
"hcp": { "min": 12, "max": 21 }
},
"responder": {
"suits": {
"H": { "min": 4, "max": null },
"C": { "min": 0, "max": 1 }
},
"suit_hcp": {
"C": { "min": 0, "max": 0 }
},
"hcp": { "min": 10, "max": 15 }
}
},
"fit": []
}
]
}
}
</syntaxhighlight>

'''Descrizioni leggibili.''' Insieme a <code><nowiki>scenarios</nowiki></code>, <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono
<code><nowiki>descriptions</nowiki></code> (stesso ordine): per ogni scenario <code><nowiki>label</nowiki></code>, <code><nowiki>positions</nowiki></code>
(per posizione, elenco di frasi già tradotte, es. <code><nowiki>"♠: ha K J 10 (e non A Q 9)"</nowiki></code>),
<code><nowiki>positionLabels</nowiki></code> (nome del ruolo, es. "Attaccante" se la pagina ha <code><nowiki>shape_roles</nowiki></code>;
altrimenti "Apertore (chi usa la convenzione)", "Compagno", ...) e <code><nowiki>fit</nowiki></code>.
Parametro opzionale <code><nowiki>lang</nowiki></code> (it, en, ...; default lingua dell'API, di solito <code><nowiki>it</nowiki></code>).
Serve a mostrare nell'interfaccia di Play '''perché''' la mano è fatta così.
Nella posizione compare anche <code><nowiki>quiet: 1</nowiki></code> se è stata usata la macro <code><nowiki>quiet</nowiki></code>.

=== <code><nowiki>shapeaction=list</nowiki></code> ===

<syntaxhighlight lang="json">
{
"pages": [
{
"pageId": 42,
"title": "Splinter",
"scenarioCount": 6,
"labels": ["1H-4C", "1H-4D", "1H-4S", "1S-4C", "1S-4D", "1S-4H"]
},
{
"pageId": 15,
"title": "Stayman",
"scenarioCount": 2,
"labels": ["fit a cuori", "fit a picche"]
}
]
}
</syntaxhighlight>

----

== Formato DSL ==

Il DSL (Domain Specific Language) è la stringa scritta nel campo
<code><nowiki>shape_constraints</nowiki></code> del template wiki.

=== Struttura ===

<syntaxhighlight lang="text">
etichetta: vincoli posizione; vincoli posizione // etichetta: vincoli // ...
</syntaxhighlight>

* '''<code><nowiki>//</nowiki></code>''' separa gli scenari (il generatore ne sceglie uno random o li presenta all'utente)
* '''<code><nowiki>;</nowiki></code>''' separa le posizioni dentro uno scenario
* Ogni scenario ha un''''etichetta''' opzionale seguita da <code><nowiki>:</nowiki></code>
* Ogni posizione inizia col nome del ruolo, seguito da vincoli separati da spazi

=== Posizioni ===

{| class="wikitable"
! Nome
! Ruolo
|-
| <code><nowiki>opener</nowiki></code>
| Chi apre o fa la prima licita convenzionale
|-
| <code><nowiki>responder</nowiki></code>
| Il compagno dell'opener
|-
| <code><nowiki>opp1</nowiki></code>
| Avversario a sinistra dell'opener
|-
| <code><nowiki>opp2</nowiki></code>
| Avversario a destra dell'opener (compagno di opp1)
|}

=== Vincoli ===

==== Lunghezza seme (specifico) ====

<syntaxhighlight lang="text">
S:5+ — almeno 5 picche
H:0-1 — 0 o 1 cuori
D:3 — esattamente 3 quadri
C:2-5 — da 2 a 5 fiori
</syntaxhighlight>

Semi: <code><nowiki>S</nowiki></code> = Spades/Picche, <code><nowiki>H</nowiki></code> = Hearts/Cuori, <code><nowiki>D</nowiki></code> = Diamonds/Quadri, <code><nowiki>C</nowiki></code> = Clubs/Fiori

==== Lunghezza seme (wildcard) ====

<syntaxhighlight lang="text">
x:0-1 — un seme qualsiasi (tra quelli non specificati) con 0-1 carte
x:6+ — un seme non specificato con almeno 6 carte
</syntaxhighlight>

Il generatore sceglie casualmente quale seme assegnare a <code><nowiki>x</nowiki></code> tra quelli
non già vincolati esplicitamente (S/H/D/C).

==== HCP totali ====

<syntaxhighlight lang="text">
hcp:15-17 — da 15 a 17 punti onore
hcp:12+ — almeno 12 punti
hcp:0-7 — da 0 a 7 punti
</syntaxhighlight>

==== HCP nel seme (specifico) ====

<syntaxhighlight lang="text">
Shcp:3+ — almeno 3 HCP a picche
Chcp:0 — 0 HCP a fiori (nessun onore)
Hhcp:0-2 — da 0 a 2 HCP a cuori
</syntaxhighlight>

==== HCP nel seme (wildcard) ====

<syntaxhighlight lang="text">
xhcp:0 — 0 HCP nel seme wildcard (x)
xhcp:0-1 — 0-1 HCP nel seme x
</syntaxhighlight>

==== Shape class ====

<syntaxhighlight lang="text">
shape:balanced — distribuzione bilanciata (4333, 4432, 5332)
shape:one_suiter — monocolore
shape:two_suiter — bicolore
shape:three_suiter — tricolore
shape:any — qualsiasi (default)
</syntaxhighlight>

==== Onori esatti in un seme (<code><nowiki>S=KJT</nowiki></code>) ====

<syntaxhighlight lang="text">
S=KJT — in picche ha K, J e 10; NON ha A, Q, 9 (le carte basse 8-2 completano)
S=KT9 — sequenza interna: K, 10, 9; NON ha A, Q, J
H=Q — a cuori ha la Q come unico onore tra A K Q J 10
D=x — nessun onore a quadri (solo carte basse)
</syntaxhighlight>

Le lettere ammesse sono <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>). La regola è: '''le carte elencate sono possedute, le altre tra A K Q J 10 9 NON lo sono'''; le carte
dall'8 in giù sono libere e riempiono fino alla lunghezza del seme. Serve a
descrivere attacchi (sequenza interrotta <code><nowiki>KJT</nowiki></code>, interna <code><nowiki>KT</nowiki></code>, sotto onore <code><nowiki>K</nowiki></code> o
<code><nowiki>Q</nowiki></code>) e le carte del compagno. Si combina con la lunghezza (<code><nowiki>S:5 S=KJT</nowiki></code>).

Nel JSON compare <code><nowiki>suit_cards</nowiki></code> nella posizione, es. <code><nowiki>{"S": "KJT", "H": ""}</nowiki></code>
(stringa vuota = nessuna carta alta). Il generatore deve:
* assegnare esattamente quegli onori alla mano e '''escluderli''' dalle altre mani del seme; gli onori non nominati da nessuna posizione sono distribuiti a caso, ma mai a una posizione con <code><nowiki>suit_cards</nowiki></code> per quel seme che non li elenca;
* rispettare comunque <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code> (la validazione segnala le contraddizioni, es. <code><nowiki>S=KQ Shcp:0-2</nowiki></code> o lo stesso onore a due mani).

==== Pattern di mano in un seme (<code><nowiki>S~...</nowiki></code>, stile regex) ====

Descrive '''l'intera mano in quel seme''', dall'alto in basso, come una piccola
espressione regolare ancorata (inizio e fine):

<syntaxhighlight lang="text">
S~AKQ. — A, K, Q + una carta bassa (4 carte)
S~A... — A + tre carte basse (4 carte)
S~AJT9. — A, J, 10, 9 + una bassa
S~AKQ.|A... — alternative: una OPPURE l'altra
S~[KQ]x{2,3} — K o Q (come unico onore) + 2 o 3 carte basse
S~KJT.* — K, J, 10 + qualunque numero di basse (anche zero)
</syntaxhighlight>

Elementi:
* '''Carte alte''' <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>), '''sempre in ordine decrescente''', ciascuna posseduta; quelle non nominate tra A K Q J 10 9 NON sono possedute.
* '''Classe''' <code><nowiki>[KQ]</nowiki></code> = una carta tra quelle (si espande in alternative).
* '''Carta bassa''' <code><nowiki>.</nowiki></code> (o <code><nowiki>x</nowiki></code>) = una carta qualsiasi tra 8 e 2; compare solo in fondo. Quantificatori: <code><nowiki>?</nowiki></code> (0-1), <code><nowiki>*</nowiki></code> (0 o più), <code><nowiki>+</nowiki></code> (1 o più), <code><nowiki>{n}</nowiki></code>, <code><nowiki>{n,m}</nowiki></code>. Più punti si sommano (<code><nowiki>...</nowiki></code> = tre basse).
* '''Alternative''' <code><nowiki>|</nowiki></code>: il generatore ne sceglie una a caso per ogni mano.

È la forma più espressiva di <code><nowiki>S=KJT</nowiki></code> (che resta valida): il pattern fissa anche
la lunghezza (<code><nowiki>S~A...</nowiki></code> = 4 carte). Se c'è anche <code><nowiki>S:N</nowiki></code> i due vincoli devono
essere compatibili (la validazione API segnala le incompatibilità).

Nel JSON compare <code><nowiki>suit_patterns</nowiki></code> nella posizione, già '''normalizzato''' (classi
espanse, quantificatori risolti), così il generatore non deve interpretare la
regex:

<syntaxhighlight lang="json">
"suit_patterns": {
"S": [
{"cards": "AKQ", "low_min": 1, "low_max": 1},
{"cards": "A", "low_min": 3, "low_max": 3}
]
}
</syntaxhighlight>

<code><nowiki>cards</nowiki></code> = carte alte possedute (ordine A K Q J T 9); <code><nowiki>low_min</nowiki></code>/<code><nowiki>low_max</nowiki></code> =
numero di carte basse (2-8), <code><nowiki>low_max: null</nowiki></code> = nessun limite. La lunghezza del
seme è <code><nowiki>len(cards) + numero di basse</nowiki></code>. Il generatore sceglie una alternativa e
rispetta anche <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code>. Gli onori di <code><nowiki>cards</nowiki></code> vanno esclusi dalle altre
mani; quelli non nominati nella mano vanno ad altri a caso.

==== Avversari "quiet" (nessun intervento) ====

<syntaxhighlight lang="text">
opp1 quiet — solo per opp1/opp2
opp2 quiet:0-7 — come quiet, ma con HCP personalizzati
</syntaxhighlight>

<code><nowiki>quiet</nowiki></code> è una '''macro espansa dall'API''': nel JSON non compare mai la parola
<code><nowiki>quiet</nowiki></code>, ma i vincoli già risolti. Chi legge l'API (il generatore) non deve
implementare nulla di nuovo. Si espande in:

<syntaxhighlight lang="text">
S:0-4 H:0-4 D:0-5 C:0-5 hcp:0-9 Shcp:0-3 Hhcp:0-3 Dhcp:0-4 Chcp:0-4
(con quiet:0-7 → hcp:0-7)
</syntaxhighlight>

Significato: gli avversari possono avere colori lunghi (così le mani sono
varie), ma poveri di onori e con pochi punti: nessun colore da 6+ carte
(niente apertura di sbarramento), nessun contro informativo, nessun intervento
naturale credibile. Le distribuzioni ammesse sono quindi molte, ma con punti
ridotti: il generatore ha meno margine sugli HCP della coppia dichiarante
(40 punti totali: apertore+rispondente restano sopra ~22).
I token espliciti scritti sulla stessa posizione '''sostituiscono''' i default,
in qualsiasi ordine: <code><nowiki>opp1 quiet S:0-4</nowiki></code> lascia le picche 0-4 e tiene il resto.
Su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> la macro viene ignorata.

==== Fit (vincolo cross-posizione) ====

<syntaxhighlight lang="text">
fit:H8+ — almeno 8 cuori totali tra i compagni
fit:S9+ — almeno 9 picche totali tra i compagni
fit:M8+ — almeno 8 carte in un seme maggiore (H o S)
fit:m8+ — almeno 8 carte in un seme minore (D o C)
fit:8+ — almeno 8 carte in un seme qualsiasi
</syntaxhighlight>

Il fit si applica tra '''compagni''':
* Se appare su <code><nowiki>opener</nowiki></code> o <code><nowiki>responder</nowiki></code>, o a livello di scenario → coppia dichiarante
* Se appare su <code><nowiki>opp1</nowiki></code> o <code><nowiki>opp2</nowiki></code> → coppia difensiva

=== Formato range ===

{| class="wikitable"
! Sintassi
! Significato
|-
| <code><nowiki>5+</nowiki></code>
| Almeno 5 (min=5, max=null)
|-
| <code><nowiki>0-1</nowiki></code>
| Da 0 a 1 (min=0, max=1)
|-
| <code><nowiki>3</nowiki></code>
| Esattamente 3 (min=3, max=3)
|-
| <code><nowiki>12-21</nowiki></code>
| Da 12 a 21 (min=12, max=21)
|}

Nella risposta JSON, <code><nowiki>max: null</nowiki></code> significa "nessun limite superiore".

=== Semi non menzionati ===

I semi '''non vincolati''' e non coperti da <code><nowiki>x:</nowiki></code> sono distribuiti '''casualmente'''
dal generatore, rispettando il vincolo che il totale delle carte per mano sia 13.

----

== DSL versione 2 (<code><nowiki>dslVersion: 2</nowiki></code>) ==

Tutto ciò che sopra resta valido e '''invariato''': i campi v1 hanno lo stesso significato di prima.
La v2 aggiunge sintassi nuova; '''ogni scenario ha nel JSON il campo <code><nowiki>requires</nowiki></code>''' (elenco di tag,
vuoto se usa solo la v1; vedi sotto) così un motore parziale può rifiutare uno scenario con un
errore esplicito invece di generare mani sbagliate. <code><nowiki>descriptions[].context</nowiki></code> è sempre presente
(array, eventualmente vuoto).
Le definizioni normative (cosa è una fermata, i punti totali, le perdenti...) e
l'architettura del motore sono in '''<code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code>'''.

=== Macro di scrittura (<code><nowiki>@NOME=v1,v2</nowiki></code>) — risolte dal parser, il motore non le vede ===

<syntaxhighlight lang="text">
@M=H,S 1${M}: opener ${M}:5+ hcp:12-21; responder ${M}:3+
</syntaxhighlight>
Genera due scenari (<code><nowiki>1H</nowiki></code>, <code><nowiki>1S</nowiki></code>) sostituendo <code><nowiki>${M}</nowiki></code> ovunque, etichetta compresa.
Più prefissi fanno il prodotto cartesiano (max 64 scenari): <code><nowiki>@M=H,S @N=15-17,12-14</nowiki></code>.
I valori possono essere intervalli (<code><nowiki>hcp:${N}</nowiki></code>): servono anche come parametri del
sistema (SA 15-17 contro 14-16).

=== Semi variabili <code><nowiki>$a $b $c $d</nowiki></code> ===

Un seme "da scegliere" condiviso da più posizioni dello stesso scenario. Ogni
variabile è un seme diverso dalle altre. Dominio dichiarato a livello di scenario
(prima delle posizioni):

<syntaxhighlight lang="text">
Landy: $a=M $b=any opener hcp:12-21 ; opp1 $a:5+ $b:4+ ; responder $a:0-2
</syntaxhighlight>
<code><nowiki>$a=M</nowiki></code> nobili, <code><nowiki>$a=m</nowiki></code> minori, <code><nowiki>$a=any</nowiki></code> (default) qualunque, <code><nowiki>$a=SH</nowiki></code> insieme esplicito.
Una variabile non dichiarata vale <code><nowiki>any</nowiki></code> (tutti i semi). Si usano al posto di <code><nowiki>S H D C</nowiki></code> in: <code><nowiki>$a:5+</nowiki></code> (lunghezza), <code><nowiki>$ahcp:</nowiki></code>, <code><nowiki>$a=KQ</nowiki></code>, <code><nowiki>$a~...</nowiki></code>,
<code><nowiki>stop:$a</nowiki></code>, <code><nowiki>has:$aQ</nowiki></code>, <code><nowiki>kc:$a3</nowiki></code>, confronti (<code><nowiki>$a>$b</nowiki></code>), <code><nowiki>longest:$a</nowiki></code>.
Differisce da <code><nowiki>x:</nowiki></code> (che vale per una sola posizione).
JSON: lo stesso dizionario <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, ... ma con chiave <code><nowiki>"$a"</nowiki></code>;
a livello di scenario <code><nowiki>"vars": {"$a": ["S","H"]}</nowiki></code>.

=== Controlli, carte chiave, carte precise ===

{| class="wikitable"
! Token
! Significato
|-
| <code><nowiki>aces:2</nowiki></code> <code><nowiki>kings:1-2</nowiki></code> <code><nowiki>queens:0</nowiki></code>
| numero di assi / re / dame nella mano
|-
| <code><nowiki>controls:6+</nowiki></code>
| controlli (A=2, K=1)
|-
| <code><nowiki>kc:H3</nowiki></code> <code><nowiki>kc:H2-3</nowiki></code> <code><nowiki>kc:$a3</nowiki></code>
| carte chiave con atout H: i 4 assi + il Re di H (0-5)
|-
| <code><nowiki>has:HQ</nowiki></code> <code><nowiki>has:S10</nowiki></code>
| possiede quella carta precisa
|-
| <code><nowiki>lacks:HQ</nowiki></code>
| NON possiede quella carta
|-
| <code><nowiki>stop:S</nowiki></code> <code><nowiki>nostop:S</nowiki></code>
| ha / non ha una fermata nel seme (definizione in SPEC)
|}

JSON: <code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code> (Range); <code><nowiki>keycards: {"H": Range}</nowiki></code>;
<code><nowiki>cards_held: ["HQ"]</nowiki></code>, <code><nowiki>cards_not_held: ["SK"]</nowiki></code>; <code><nowiki>stoppers: {"S": 1, "H": 0}</nowiki></code>
(1 = deve averla, 0 = non deve averla).

=== Punti e perdenti ===

<code><nowiki>tp:</nowiki></code> punti totali (PO + 1 per ogni carta oltre la quarta in ogni seme),
<code><nowiki>dp:</nowiki></code> punti distribuzione (PO + 3 chicane + 2 singolo + 1 doubleton),
<code><nowiki>ltc:</nowiki></code> perdenti (Losing Trick Count). A livello di scenario: <code><nowiki>pairhcp:25+</nowiki></code>
(PO della coppia dichiarante), <code><nowiki>defhcp:0-14</nowiki></code> (coppia avversaria), <code><nowiki>pairtp:26+</nowiki></code>.
JSON: <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code> (Range) nella posizione; <code><nowiki>pair_hcp: {"declarer": R, "defense": R}</nowiki></code>,
<code><nowiki>pair_tp: {"declarer": R}</nowiki></code> nello scenario.

=== Confronti tra semi e forme precise ===

<syntaxhighlight lang="text">
H>S H>=S H<S H<=S H==S $a>$b — confronto di lunghezze nella stessa mano
longest:H — H è tra i semi più lunghi (pari merito ammesso)
shape:5-4-x-x shape:5422 shape:54xx — lunghezze ordinate in modo decrescente, x = qualsiasi
shape:semi_balanced — 5422 e 6322 (si aggiunge alle classi esistenti)
</syntaxhighlight>
JSON: <code><nowiki>compare: [{"left":"H","op":">=","right":"S"}]</nowiki></code>, <code><nowiki>longest: ["H"]</nowiki></code>,
<code><nowiki>shape_pattern: "54xx"</nowiki></code>.

=== Alternative e negazioni nella stessa mano: <code><nowiki>any(...)</nowiki></code> e <code><nowiki>not(...)</nowiki></code> ===

<syntaxhighlight lang="text">
opener any(S:4+ hcp:12+, H:4+) not(D:6+)
</syntaxhighlight>
<code><nowiki>any(A, B)</nowiki></code>: la mano soddisfa '''almeno una''' delle alternative (separate da virgola;
ogni alternativa è una congiunzione di token). <code><nowiki>not(A, B)</nowiki></code>: la mano non soddisfa
'''nessuna''' delle alternative. Si possono scrivere più gruppi (si combinano in AND);
niente annidamenti.
JSON: <code><nowiki>any: [[altA, altB], ...]</nowiki></code> (lista di gruppi; ogni alternativa è un oggetto
con gli stessi campi di una posizione), <code><nowiki>not: [altA, altB]</nowiki></code>.

=== Contesto dello scenario ===

Token prima delle posizioni: <code><nowiki>weight:3</nowiki></code> (frequenza relativa, 1-100, default 1),
<code><nowiki>dealer:opener</nowiki></code>, <code><nowiki>vul:none|us|them|both</nowiki></code> (<code><nowiki>us</nowiki></code> = apertore+rispondente),
<code><nowiki>auction:1SA,P,2C,P</nowiki></code> (licite, notazione BridgeCards; SA = NT), <code><nowiki>contract:4H</nowiki></code>,
<code><nowiki>declarer:responder</nowiki></code>, <code><nowiki>lead:SK</nowiki></code>.
JSON: <code><nowiki>weight</nowiki></code> (int) e <code><nowiki>context: {"dealer":..,"vul":..,"auction":[..],"contract":"4H","declarer":..,"lead":"SK"}</nowiki></code>.
Il motore deve usare <code><nowiki>dealer</nowiki></code>/<code><nowiki>vul</nowiki></code> quando li espone (per la numerazione del tavolo) e,
se c'è <code><nowiki>lead</nowiki></code>, la carta deve stare nella mano dell'attaccante (a sinistra del
dichiarante) e rispettare i vincoli di quella mano.

=== Tag <code><nowiki>requires</nowiki></code> ===

<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>vars</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>card_presence</nowiki></code> (has/lacks),
<code><nowiki>controls</nowiki></code> (aces/kings/queens/controls/kc), <code><nowiki>points</nowiki></code> (tp/dp/ltc), <code><nowiki>pair_points</nowiki></code>,
<code><nowiki>compare</nowiki></code> (confronti, longest), <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>any_not</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>weight</nowiki></code>.
Le macro <code><nowiki>@</nowiki></code> e <code><nowiki>quiet</nowiki></code> non compaiono: sono già espanse.

=== Avvisi di parsing (<code><nowiki>warnings</nowiki></code>) ===

<code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono <code><nowiki>warnings</nowiki></code> quando un frammento del DSL non è stato
capito e quindi '''scartato''': nome di posizione sbagliato, token sconosciuto o con valore
non valido (<code><nowiki>aces:5</nowiki></code>, <code><nowiki>S=Kx</nowiki></code>, <code><nowiki>shape:4-5-x-x</nowiki></code>), token di scenario dopo le posizioni, posizione
definita due volte, <code><nowiki>quiet</nowiki></code> su opener/responder, gruppo <code><nowiki>any()</nowiki></code>/<code><nowiki>not()</nowiki></code> con alternative non
valide (in tal caso '''l'intero gruppo è ignorato''', mai applicato a metà). <code><nowiki>validate.valid</nowiki></code> è 1
solo se non ci sono né <code><nowiki>errors</nowiki></code> né <code><nowiki>warnings</nowiki></code>. Un motore non deve generare se ci sono
<code><nowiki>warnings</nowiki></code> o <code><nowiki>errors</nowiki></code>.

Limiti (oltre i quali il parser avvisa e tronca): 60.000 caratteri di input, 200 scenari, 6
prefissi <code><nowiki>@</nowiki></code>, 64 valori per macro, 64 scenari per espansione, 8 gruppi <code><nowiki>any/not</nowiki></code> e 16 alternative
per posizione. Le etichette non possono contenere <code><nowiki>:</nowiki></code>.

----

== Struttura JSON di uno scenario ==

<syntaxhighlight lang="typescript">
interface Scenario {
label: string; // Etichetta (es. "1H-4C"), vuota se non specificata
positions: {
[posName: string]: Position; // "opener", "responder", "opp1", "opp2"
};
fit: FitConstraint[]; // Vincoli di fit (array, può essere vuoto)
}

interface Position {
suit_patterns?: { // Pattern regex-like normalizzati: {"S":[{"cards":"AKQ","low_min":1,"low_max":1}]}
[suit: string]: { cards: string; low_min: number; low_max: number | null }[];
};
suit_cards?: { [suit: string]: string }; // Onori esatti, es. {"S":"KJT"}; "" = nessuna carta alta
suits?: { // Vincoli lunghezza seme (solo semi esplicitati)
[suit: string]: Range; // "S", "H", "D", "C"
};
hcp?: Range; // HCP totali
suit_hcp?: { // HCP per seme specifico
[suit: string]: Range;
};
x?: Range; // Lunghezza seme wildcard
x_hcp?: Range; // HCP seme wildcard
shape?: string; // Shape class: "balanced", "one_suiter", etc.
}

interface Range {
min: number;
max: number | null; // null = nessun limite superiore
}

interface FitConstraint {
suit: string | null; // "S","H","D","C" o null
suit_class: string | null; // "major", "minor" o null
min: number; // Numero minimo di carte (es. 8)
pair: string; // "declarer" o "defense"
}
</syntaxhighlight>

----

== Logica per il generatore ==

=== Algoritmo base ===

Per ogni scenario:

# '''Scegli lo scenario''': random tra quelli disponibili, oppure lascia scegliere all'utente
# '''Risolvi wildcard''':
#* Se una posizione ha <code><nowiki>x:</nowiki></code>, scegli un seme casuale tra quelli non esplicitamente vincolati
#* <code><nowiki>xhcp:</nowiki></code> si applica allo stesso seme scelto per <code><nowiki>x:</nowiki></code>
# '''Risolvi fit''':
#* Se <code><nowiki>fit.suit</nowiki></code> è specificato, entrambi i compagni devono avere un totale >= <code><nowiki>fit.min</nowiki></code> in quel seme
#* Se <code><nowiki>fit.suit_class</nowiki></code> è "major", scegli tra H e S; se "minor", tra D e C
#* Se entrambi sono null, scegli un seme qualsiasi
#* <code><nowiki>fit.pair</nowiki></code> indica quale coppia: "declarer" (opener+responder) o "defense" (opp1+opp2)
# '''Genera le mani''':
#* Per ogni posizione, genera una mano che rispetti tutti i vincoli
#* I semi senza vincoli vengono riempiti casualmente
#* Il totale delle carte per mano deve essere esattamente 13
#* Il totale delle carte per seme (tutte e 4 le mani) deve essere esattamente 13
# '''Posizioni non menzionate''': se uno scenario non menziona <code><nowiki>opp1</nowiki></code>/<code><nowiki>opp2</nowiki></code>, distribuisci le carte rimanenti casualmente tra gli avversari

=== Priorità dei vincoli ===

# Vincoli di fit (cross-posizione) — determinano la distribuzione di base
# Vincoli di seme specifico (S:, H:, D:, C:) — limitano i singoli semi
# Vincoli wildcard (x:) — dopo aver fissato i semi specifici
# Vincoli HCP (hcp:, Shcp:, xhcp:) — filtro finale
# Shape class (shape:) — validazione della forma complessiva

=== Gestione di <code><nowiki>max: null</nowiki></code> ===

Quando <code><nowiki>max</nowiki></code> è <code><nowiki>null</nowiki></code>, non c'è limite superiore esplicito. I limiti fisici
del bridge si applicano comunque:
* Massimo 13 carte per seme (tutte e 4 le mani)
* Massimo 13 carte per mano
* Massimo 10 HCP per seme (A+K+Q+J = 4+3+2+1)
* Massimo 37 HCP per mano (raro ma teoricamente possibile con tutti gli onori)

----

== Esempi completi ==

=== Splinter (tutti gli scenari specifici) ===

DSL nel template wiki:
<syntaxhighlight lang="text">
1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 //
1H-4D: opener H:5+ hcp:12-21; responder H:4+ D:0-1 Dhcp:0 hcp:10-15 //
1H-4S: opener H:5+ hcp:12-21; responder H:4+ S:0-1 Shcp:0 hcp:10-15 //
1S-4C: opener S:5+ hcp:12-21; responder S:4+ C:0-1 Chcp:0 hcp:10-15 //
1S-4D: opener S:5+ hcp:12-21; responder S:4+ D:0-1 Dhcp:0 hcp:10-15 //
1S-4H: opener S:5+ hcp:12-21; responder S:4+ H:0-1 Hhcp:0 hcp:10-15
</syntaxhighlight>

=== Splinter (compatto con fit e wildcard) ===

<syntaxhighlight lang="text">
dopo 1H: fit:H8+ opener H:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15 //
dopo 1S: fit:S8+ opener S:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15
</syntaxhighlight>

=== Stayman ===

<syntaxhighlight lang="text">
fit a cuori: fit:H8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder H:4+ hcp:8+ //
fit a picche: fit:S8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder S:4+ hcp:8+
</syntaxhighlight>

=== Contro informativo ===

<syntaxhighlight lang="text">
base: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; responder hcp:0-8 //
con intervento: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; opp2 hcp:8+ x:5+
</syntaxhighlight>

=== Preempt 3-a-livello ===

<syntaxhighlight lang="text">
opener H:7+ x:0-1 hcp:5-10
</syntaxhighlight>

=== Overcall con fit avversari ===

<syntaxhighlight lang="text">
overcall semplice: opener hcp:12-21 x:5+; opp1 hcp:10+ x:5+; opp2 fit:8+ //
con barrage: opener hcp:12-21 x:5+; opp1 hcp:6-10 x:6+; opp2 fit:9+
</syntaxhighlight>

----

== Note implementative ==

* L'API è read-only, non richiede token CSRF
* L'accesso anonimo è abilitato di default (<code><nowiki>BridgeShapeAllowAnonymous: true</nowiki></code>) perché i dati sono pubblici e i tool esterni ne hanno bisogno
* Il campo <code><nowiki>raw</nowiki></code> nella risposta <code><nowiki>get</nowiki></code> contiene la stringa DSL originale, utile per debug
* L'azione <code><nowiki>validate</nowiki></code> permette di testare stringhe DSL senza creare pagine wiki
* I calcoli HCP usano la scala standard: A=4, K=3, Q=2, J=1

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Ricette DSL

2026-10-23T05:49:08Z

Lpala: BridgeShape: documentazione DSL v2

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Motore e frontend|Motore e frontend]]

= BridgeShape — Ricette DSL v2 per gli editor =

Come descrivere con <code><nowiki>shape_constraints</nowiki></code> le situazioni tipiche. Ogni ricetta è verificata dal
parser (<code><nowiki>tests/phpunit/unit/RecipesTest.php</nowiki></code>). I punti sono esempi di partenza: '''le soglie vanno prese dalla fonte citata nella pagina''', non da qui.

Regole: scenari separati da <code><nowiki>//</nowiki></code>; posizioni da <code><nowiki>;</nowiki></code>; <code><nowiki>|</nowiki></code> dentro i template si scrive <code><nowiki>{{!}}</nowiki></code>.
Per ogni pagina con scenari aggiungere <code><nowiki>shape_roles</nowiki></code> se i nomi "Apertore/Compagno" non calzano.

== Apertura e risposta con fit variabile (macro) ==

Un solo testo per entrambi i nobili:
<syntaxhighlight lang="text">
@M=H,S 1${M}-fit: opener ${M}:5+ hcp:12-21; responder ${M}:3+ hcp:6+
</syntaxhighlight>

== Splinter con seme singolo variabile ==

<syntaxhighlight lang="text">
@M=H,S 1${M}: $a=SHDC opener ${M}:5+ hcp:12-21; responder ${M}:4+ $a:0-1 $ahcp:0 hcp:10-15
</syntaxhighlight>
(se <code><nowiki>$a</nowiki></code> deve essere diverso da <code><nowiki>${M}</nowiki></code>, restringere: <code><nowiki>$a=SDC</nowiki></code>.)

== Intervento bicolore su apertura (Landy, Michaels, Cappelletti) ==

Un nobile + un minore, seme dell'apertore escluso con <code><nowiki>not</nowiki></code>:
<syntaxhighlight lang="text">
Michaels nobile+minore: $a=M $b=m opener hcp:12-21 ; opp1 $a:5+ $b:5+ hcp:8-16 ; responder hcp:0-9
</syntaxhighlight>
Landy (5-4 nei nobili):
<syntaxhighlight lang="text">
Landy 5-4 picche: opener shape:balanced hcp:15-17; opp1 S:5 H:4 hcp:8+
Landy 4-5 cuori: opener shape:balanced hcp:15-17; opp1 S:4 H:5 hcp:8+
Landy 5-5: opener shape:balanced hcp:15-17; opp1 S:5+ H:5+ hcp:8+
</syntaxhighlight>

== Avversari che non possono intervenire ==
<syntaxhighlight lang="text">
Avversari quiet: opener hcp:12-21; responder hcp:6+; opp1 quiet; opp2 quiet
Avversari quiet stretti: opener hcp:12-21; responder hcp:6+; opp1 quiet:0-7; opp2 quiet:0-7
</syntaxhighlight>

== Fermate (Lebensohl, Michaels, SA dopo intervento) ==
<syntaxhighlight lang="text">
Lebensohl con fermata: opener shape:balanced hcp:15-17; opp1 S:5+ hcp:8-15; responder stop:S hcp:10+ H:0-3
Lebensohl senza fermata: opener shape:balanced hcp:15-17; opp1 S:5+ hcp:8-15; responder nostop:S hcp:10+
</syntaxhighlight>

== Blackwood / RKCB / richiesta della Dama ==
<syntaxhighlight lang="text">
@M=H,S RKCB-${M}-1o4: opener ${M}:5+ hcp:16+; responder ${M}:3+ kc:${M}1 has:${M}Q
@M=H,S RKCB-${M}-2senzaDama: opener ${M}:5+ hcp:16+; responder ${M}:3+ kc:${M}2 lacks:${M}Q
@M=H,S RKCB-${M}-3: opener ${M}:5+ hcp:16+; responder ${M}:3+ kc:${M}3
Blackwood-2-assi: opener hcp:18+; responder aces:2
</syntaxhighlight>
(<code><nowiki>kc:H1</nowiki></code> = un asso oppure il Re di cuori; l'atout viene dalla macro.)

== Forze con punteggi alternativi ==
<syntaxhighlight lang="text">
Apertura forte per punti totali: opener tp:23+ ; responder hcp:0-7
Aperture a perdenti: opener ltc:5-6 hcp:17+
</syntaxhighlight>

== Alternative di mano senza duplicare gli scenari ==
<syntaxhighlight lang="text">
Smolen: opener shape:balanced hcp:15-17 any(S:3+ H:2-3, H:3+ S:2-3); responder any(S:5 H:4, S:4 H:5) hcp:10+
Mano con almeno un nobile lungo: opener any(S:5+, H:5+) hcp:12-21
Nessun nobile 4+: opener not(S:4+, H:4+) shape:balanced
</syntaxhighlight>

== Confronti e forme ==
<syntaxhighlight lang="text">
Colore più lungo a cuori: opener H>S longest:H hcp:12-21
Bicolore 5-4 qualsiasi: opener shape:5-4-x-x hcp:12-21
Semibilanciata: opener shape:semi_balanced
</syntaxhighlight>

== Barrage / preempt per vulnerabilità e frequenza ==
<syntaxhighlight lang="text">
Preempt in zona sfavorevole: vul:us dealer:opener weight:2 opener H:7 hcp:5-10
</syntaxhighlight>

== Segnali e attacchi (contesto di gioco) ==
<syntaxhighlight lang="text">
Segnale di Smith: declarer:opener contract:4H lead:SK opener H:5+; opp1 S=KQT
Attacco sotto onore: declarer:opener contract:3NT lead:S4 opener hcp:15-17; opp1 S~K.{2,3}
</syntaxhighlight>
(L'attacco deve stare nella mano a sinistra del dichiarante: <code><nowiki>declarer:opener</nowiki></code> → <code><nowiki>opp1</nowiki></code>.)

== Coppia e forza totale ==
<syntaxhighlight lang="text">
Slam: pairhcp:33+ opener hcp:17+ ; responder hcp:14+
</syntaxhighlight>

== Cose da NON fare ==
* Non ripetere uno scenario per ogni nobile: usare <code><nowiki>@M=H,S</nowiki></code>.
* Non usare <code><nowiki>S~</nowiki></code> per esprimere "ha almeno 4 carte": usare <code><nowiki>S:4+</nowiki></code>.
* Non usare <code><nowiki>quiet</nowiki></code> su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> (viene ignorato).
* <code><nowiki>{{!}}</nowiki></code> e non <code><nowiki>|</nowiki></code> dentro i parametri dei template.
* Controllare sempre con <code><nowiki>shapeaction=validate</nowiki></code>: se compaiono <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> lo scenario va corretto.

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape Motore e frontend

2026-10-23T05:49:07Z

Lpala: BridgeShape: documentazione DSL v2

Documentazione BridgeShape: [[Progetto:BridgeShape API|API e sintassi DSL]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — Specifica del motore di smazzate e del frontend (per Play) =

Destinatario: il team/sessione di '''Play''' (generatore di smazzate e relativo frontend).
Obiettivo: realizzare un '''motore completo''' che generi mani per ''qualsiasi'' scenario
descritto nelle pagine di BridgePedia, e un '''frontend''' per consultare gli scenari,
generare, creare e gestire smazzate.

Documenti collegati (leggere in quest'ordine):

# <code><nowiki>DEAL_GENERATOR_API.md</nowiki></code> — riferimento della sintassi (DSL v1 + v2) e del JSON dell'API.
# '''questo file''' — semantica normativa, architettura del motore, test di conformità, specifica del frontend, piano di consegna.
# Wiki: <code><nowiki>Progetto:BridgeShape API</nowiki></code>; le pagine di convenzione con <code><nowiki>shape_constraints</nowiki></code> (elenco: <code><nowiki>GET /api.php?action=bridgeshape&shapeaction=list</nowiki></code>).

Fonte di verità del contratto: l'API <code><nowiki>action=bridgeshape</nowiki></code> di https://bridgepedia.it.
Se questo documento e l'API divergono vale l'API; segnalatelo a BridgePedia.

----

== 1. Contratto, versioni e compatibilità ==

{| class="wikitable"
! Elemento
! Dove
! Uso
|-
| <code><nowiki>dslVersion</nowiki></code>
| risposta di <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code>
| oggi <code><nowiki>2</nowiki></code>. Cambia solo con modifiche non retrocompatibili
|-
| <code><nowiki>scenarios[].requires</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| tag delle capacità richieste dallo scenario (§1.1)
|-
| <code><nowiki>errors</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| contraddizioni semantiche: '''non generare'''
|-
| <code><nowiki>warnings</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| frammenti del DSL scartati dal parser: '''non generare'''
|-
| <code><nowiki>descriptions</nowiki></code>
| <code><nowiki>get</nowiki></code>, <code><nowiki>validate</nowiki></code>
| testo leggibile per scenario, tradotto (<code><nowiki>lang=it|en|...</nowiki></code>)
|-
| <code><nowiki>valid</nowiki></code>
| <code><nowiki>validate</nowiki></code>
| 1/0
|}

Regole di compatibilità:

* I campi nuovi compaiono '''solo se usati''': un motore v1 continua a funzionare sulle pagine v1.
* Campi sconosciuti: ignorarli '''non''' è permesso se compaiono in <code><nowiki>requires</nowiki></code>. Se il motore non supporta un tag di <code><nowiki>requires</nowiki></code>, deve rifiutare lo scenario con codice <code><nowiki>unsupported_feature</nowiki></code> (e nome del tag) e il frontend deve mostrarlo come "non ancora generabile", non nasconderlo.
* Il booleano nel JSON è sempre <code><nowiki>1</nowiki></code>/<code><nowiki>0</nowiki></code> (MediaWiki rimuove i <code><nowiki>false</nowiki></code>).
* Tutte le chiavi di seme sono <code><nowiki>S H D C</nowiki></code> oppure una variabile <code><nowiki>"$a".."$d"</nowiki></code>.

=== 1.1 Tag <code><nowiki>requires</nowiki></code> ===

{| class="wikitable"
! Tag
! Costrutti
! Impatto sul motore
|-
| <code><nowiki>suit_cards</nowiki></code>
| <code><nowiki>S=KJT</nowiki></code>
| assegnazione di onori precisi
|-
| <code><nowiki>suit_patterns</nowiki></code>
| <code><nowiki>S~AKQ.|A...</nowiki></code>
| alternative di mano nel seme
|-
| <code><nowiki>vars</nowiki></code>
| <code><nowiki>$a $b</nowiki></code>, <code><nowiki>vars</nowiki></code>
| seme scelto a runtime, condiviso tra posizioni
|-
| <code><nowiki>stoppers</nowiki></code>
| <code><nowiki>stop:S</nowiki></code>
| filtro/vincolo sulla mano
|-
| <code><nowiki>card_presence</nowiki></code>
| <code><nowiki>has:HQ</nowiki></code>, <code><nowiki>lacks:SK</nowiki></code>
| carte fisse
|-
| <code><nowiki>controls</nowiki></code>
| <code><nowiki>aces kings queens controls kc</nowiki></code>
| conteggi di onori
|-
| <code><nowiki>points</nowiki></code>
| <code><nowiki>tp dp ltc</nowiki></code>
| punteggi derivati
|-
| <code><nowiki>pair_points</nowiki></code>
| <code><nowiki>pairhcp pairtp defhcp</nowiki></code>
| vincolo sulla coppia
|-
| <code><nowiki>compare</nowiki></code>
| <code><nowiki>H>S</nowiki></code>, <code><nowiki>longest:</nowiki></code>
| relazioni tra lunghezze
|-
| <code><nowiki>shape_pattern</nowiki></code>
| <code><nowiki>shape:5-4-x-x</nowiki></code>
| forma ordinata
|-
| <code><nowiki>any_not</nowiki></code>
| <code><nowiki>any(...)</nowiki></code>, <code><nowiki>not(...)</nowiki></code>
| disgiunzioni e negazioni
|-
| <code><nowiki>context</nowiki></code>
| <code><nowiki>dealer vul auction contract declarer lead</nowiki></code>
| metadati e carta d'attacco
|-
| <code><nowiki>weight</nowiki></code>
| <code><nowiki>weight:N</nowiki></code>
| scelta ponderata dello scenario
|}

Le macro <code><nowiki>@M=H,S</nowiki></code> e <code><nowiki>quiet</nowiki></code> sono già espanse dal parser (non compaiono mai).

=== 1.2 Endpoint consigliati lato Play ===

Il motore deve esporre (nomi indicativi; l'importante è la semantica):

<syntaxhighlight lang="text">
POST /api/deals/generate
{
"source": { "page": "Splinter", "scenario": "1H-4C" } // oppure { "dsl": "..." }
| { "page": "Splinter" }, // scenario scelto per peso
"count": 10, // 1..100
"seed": 12345, // opzionale, riproducibilità
"fixed": { "opener": "SAK2.H.D.C", "responder": "..." }, // carte/mani già fissate (§5.6)
"lang": "it"
}
→ 200 { "seed":..., "deals":[ {
"scenario": "1H-4C", "index": 0,
"dealer": "opener", "vul": "none",
"hands": { "opener":"AK2.QJ53.K84.T65", "responder":"...", "opp1":"...", "opp2":"..." },
"bindings": { "$a": "H", "x:opener": "D" }, // come sono state risolte variabili e jolly
"pbn": "[Deal \"N:...\"]", "lin": "...",
"explanation": { "opener": ["♥: 5+ carte", ...], ... }, // dalle descriptions
"stats": { "attempts": 412, "ms": 38 }
} ] }
→ 422 { "code": "...", "reasons": [ {"code":"...", "position":"opp1", "detail":"..."} ] }
GET /api/deals/capabilities → { "dslVersion": 2, "supports": ["suit_cards", ...] }
</syntaxhighlight>

Posizioni → sedi: <code><nowiki>opener</nowiki></code> = Nord per default; il motore ruota in base a <code><nowiki>context.dealer</nowiki></code> solo
per la numerazione/PBN; i vincoli restano sempre in termini di ruoli (<code><nowiki>opener</nowiki></code>, <code><nowiki>responder</nowiki></code>,
<code><nowiki>opp1</nowiki></code> = a sinistra dell'apertore, <code><nowiki>opp2</nowiki></code> = a destra).

----

== 2. Definizioni normative ==

Il motore e il frontend devono usare '''esattamente''' queste definizioni (le descrizioni in
italiano dell'API le presuppongono).

* '''Carte''': A K Q J 10 9 8 7 6 5 4 3 2. Nei vincoli <code><nowiki>T</nowiki></code> = 10. "Carte basse" = 8..2.
* '''PO / HCP''': A=4, K=3, Q=2, J=1. <code><nowiki>Shcp</nowiki></code> ecc. = PO nel solo seme.
* '''Posizioni e coppie''': coppia dichiarante = <code><nowiki>opener</nowiki></code>+<code><nowiki>responder</nowiki></code>; difesa = <code><nowiki>opp1</nowiki></code>+<code><nowiki>opp2</nowiki></code>. Senso di gioco: opener → opp1 → responder → opp2 (orario). Lo stesso per l'attaccante: siede a sinistra del dichiarante (<code><nowiki>declarer</nowiki></code> = opener → attacca opp1; responder → opp2; opp1 → responder; opp2 → opener).
* '''Forma ordinata''': le 4 lunghezze in ordine decrescente (es. 5431).
* '''Classi di forma''' (possono sovrapporsi; le pagine oggi usano solo <code><nowiki>balanced</nowiki></code>):
** <code><nowiki>balanced</nowiki></code>: 4333, 4432, 5332.
** <code><nowiki>semi_balanced</nowiki></code>: 5422, 6322.
** <code><nowiki>one_suiter</nowiki></code>: seme più lungo ≥ 6 e secondo ≤ 3.
** <code><nowiki>two_suiter</nowiki></code>: i due semi più lunghi hanno entrambi ≥ 4 carte e insieme ≥ 9 (5-4, 6-4, 5-5, ...).
** <code><nowiki>three_suiter</nowiki></code>: tre semi ≥ 4 (4441, 5440, 4450...).
** <code><nowiki>any</nowiki></code>: nessun vincolo. Se la vostra implementazione attuale differisce, allineatela a questa o segnalate la differenza.
* '''<code><nowiki>shape_pattern</nowiki></code>''' (<code><nowiki>54xx</nowiki></code>): la forma ordinata deve corrispondere cifra per cifra; <code><nowiki>x</nowiki></code> = qualsiasi.
* '''<code><nowiki>longest:H</nowiki></code>''': la lunghezza di H è ≥ di ogni altro seme (pari merito ammesso).
* '''Confronti''' <code><nowiki>A op B</nowiki></code>: sulle lunghezze dei due semi nella stessa mano; <code><nowiki>==</nowiki></code> uguali.
* '''Controlli''': A=2, K=1 (le dame non contano). <code><nowiki>controls:6+</nowiki></code> somma sulla mano.
* '''Carte chiave per l'atout T''' (<code><nowiki>kc:T</nowiki></code>): numero di assi (0-4) + 1 se possiede il Re di T. Valori 0-5. La Dama di atout si esprime con <code><nowiki>has:TQ</nowiki></code>.
* '''Fermata''' nel seme X (<code><nowiki>stop:X</nowiki></code>): possiede almeno una tra: A; Kx (Re con ≥ 2 carte nel seme); Qxx (Dama con ≥ 3); Jxxx (Fante con ≥ 4). <code><nowiki>nostop:X</nowiki></code> = nessuna di queste.
* '''Punti totali <code><nowiki>tp</nowiki></code>''': PO + (per ogni seme, <code><nowiki>max(0, lunghezza − 4)</nowiki></code>).
* '''Punti distribuzione <code><nowiki>dp</nowiki></code>''': PO + 3 per ogni chicane + 2 per ogni singolo + 1 per ogni doubleton.
* '''Perdenti <code><nowiki>ltc</nowiki></code>''' (Losing Trick Count): per ogni seme con <code><nowiki>n</nowiki></code> carte, considerare <code><nowiki>m = min(n,3)</nowiki></code>; perdenti del seme = <code><nowiki>m − (numero di A, K, Q posseduti nel seme)</nowiki></code>; somma sui 4 semi. (Seme vuoto = 0.)
* '''<code><nowiki>S=KJT</nowiki></code>''' (<code><nowiki>suit_cards</nowiki></code>): tra A K Q J 10 9 possiede ''esattamente'' quelle elencate; 8..2 liberi. Stringa vuota = nessuna carta alta. Gli onori elencati sono esclusi dalle altre mani solo per quel che riguarda la proprietà: ogni carta ha un unico proprietario.
* '''<code><nowiki>S~...</nowiki></code>''' (<code><nowiki>suit_patterns</nowiki></code>): una sola alternativa (scelta a caso, uniformemente tra quelle compatibili con gli altri vincoli) descrive tutta la mano in quel seme: <code><nowiki>cards</nowiki></code> + tra <code><nowiki>low_min</nowiki></code> e <code><nowiki>low_max</nowiki></code> carte basse (<code><nowiki>low_max: null</nowiki></code> = illimitato, ma ≤ 13 − len(cards)).
* '''<code><nowiki>x:</nowiki></code>''' (jolly di posizione): un seme scelto a caso tra quelli ''non'' vincolati esplicitamente in quella posizione; <code><nowiki>xhcp:</nowiki></code> si riferisce allo stesso seme. Il jolly '''non''' è condiviso con altre posizioni.
* '''Variabili <code><nowiki>$a..$d</nowiki></code>''': a inizio generazione ogni variabile usata riceve un seme dal proprio dominio (<code><nowiki>vars</nowiki></code>, default tutti e quattro). Variabili diverse hanno '''semi diversi'''. Una variabile può coincidere con un seme nominato esplicitamente (<code><nowiki>$a</nowiki></code> e <code><nowiki>H</nowiki></code>): se non è voluto, restringere il dominio (<code><nowiki>$a=SD</nowiki></code>). La scelta è uniforme tra le assegnazioni che rendono lo scenario soddisfacibile.
* '''<code><nowiki>fit</nowiki></code>''': somma delle lunghezze dei due compagni nel seme (o in qualunque seme del tipo <code><nowiki>major</nowiki></code>/ <code><nowiki>minor</nowiki></code>/<code><nowiki>any</nowiki></code>, a scelta del motore, uniformemente tra i semi che soddisfano il vincolo).
* '''<code><nowiki>any(A,B)</nowiki></code>''': la mano soddisfa almeno una alternativa. '''<code><nowiki>not(A,B)</nowiki></code>''': non ne soddisfa nessuna. Più gruppi → AND. Dentro <code><nowiki>A</nowiki></code>,<code><nowiki>B</nowiki></code> valgono gli stessi campi di una posizione (senza <code><nowiki>any/not/fit</nowiki></code>).
* '''<code><nowiki>pair_hcp.declarer</nowiki></code>''' = PO(opener)+PO(responder); <code><nowiki>defense</nowiki></code> = PO(opp1)+PO(opp2). <code><nowiki>pair_tp</nowiki></code>: somma <code><nowiki>tp</nowiki></code>.
* '''Posizioni non nominate''': ricevono le carte rimanenti a caso (nessun vincolo); non applicare <code><nowiki>quiet</nowiki></code> implicito.
* '''<code><nowiki>weight</nowiki></code>''': probabilità relativa di scelta dello scenario quando non è scelto dall'utente (default 1). Non influenza la generazione dentro lo scenario.
* '''<code><nowiki>context</nowiki></code>''': metadati. <code><nowiki>dealer</nowiki></code> e <code><nowiki>vul</nowiki></code> (<code><nowiki>us</nowiki></code> = coppia dichiarante) vanno riportati nell'output (PBN/LIN) e mostrati. <code><nowiki>auction</nowiki></code> è la sequenza da mostrare/verificare (notazione BridgeCards: <code><nowiki>P</nowiki></code>, <code><nowiki>X</nowiki></code>, <code><nowiki>XX</nowiki></code>, <code><nowiki>1NT</nowiki></code>...). <code><nowiki>contract</nowiki></code>/<code><nowiki>declarer</nowiki></code>/<code><nowiki>lead</nowiki></code>: vedi §5.7.

----

== 3. Architettura consigliata del motore ==

Pipeline per ogni mano richiesta:

<syntaxhighlight lang="text">
parse risposta API → controllo requires/errors/warnings
→ scelta scenario (utente | peso)
→ ASSEGNAZIONE SIMBOLICA : variabili $a.., jolly x:, fit, alternative any()/S~, pattern di forma
→ MATRICE DELLE LUNGHEZZE : 4 posizioni × 4 semi (somme 13 per riga e per colonna)
→ ASSEGNAZIONE DELLE CARTE : carte fissate/vincolate, poi resto casuale
→ RIPARAZIONE PUNTI : scambi mirati per entrare negli intervalli PO/tp/dp/ltc/controlli
→ VERIFICA FINALE : valutazione indipendente di TUTTI i vincoli sulla smazzata completa
→ output + spiegazione
</syntaxhighlight>

Punti chiave:

# '''Verifica finale indipendente''' (il "giudice"): una funzione pura <code><nowiki>satisfies(deal, scenario, bindings)</nowiki></code> che valuta ogni vincolo dalle definizioni di §2. Ogni smazzata emessa deve passarla. Questa funzione è anche la base dei test e del pulsante "verifica" del frontend.
# '''Costruzione, non solo scarto.''' Il rejection sampling puro non regge scenari stretti (es. Gran rever nel Multirever, <code><nowiki>quiet</nowiki></code> con coppia 25+ PO). Costruire prima la matrice delle lunghezze con propagazione dei vincoli (backtracking con limiti per riga/colonna), poi assegnare le carte onore per posizione secondo <code><nowiki>suit_cards</nowiki></code>/<code><nowiki>suit_patterns</nowiki></code>/<code><nowiki>has</nowiki></code>/<code><nowiki>lacks</nowiki></code>/<code><nowiki>aces</nowiki></code>..., infine le basse.
# '''Riparazione PO''': dopo l'assegnazione, se i PO (o <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, controlli, <code><nowiki>pair_*</nowiki></code>) sono fuori intervallo, scambiare due carte tra due mani preservando lunghezze e vincoli ''rigidi'' (carte fissate, pattern). Ricerca locale con budget; poi nuovo tentativo dall'inizio.
# '''Uniformità''': l'obiettivo è una distribuzione quasi uniforme tra le smazzate che soddisfano lo scenario. Le euristiche di costruzione introducono distorsioni: misuratele (§7.3) e non dichiarate "uniformi" se non lo sono.
# '''Budget e fallimenti''': limite di tempo (oggi 2,5 s CPU/mano), massimo tentativi, e diagnosi. Su fallimento restituire 422 con i <code><nowiki>reasons</nowiki></code> di §6, mai una smazzata che viola i vincoli.
# '''Riproducibilità''': stesso <code><nowiki>seed</nowiki></code> + stessa versione del DSL → stessa smazzata. Salvare nel record <code><nowiki>seed</nowiki></code>, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>source.page</nowiki></code>, <code><nowiki>revid</nowiki></code> della pagina se disponibile.
# '''Concorrenza e cache''': cache del JSON dell'API per pagina con TTL breve (60 s) e rivalidazione sulla <code><nowiki>list</nowiki></code>; mai servire DSL non validato.

=== 3.1 Ordine di risoluzione dei vincoli ===

# Variabili <code><nowiki>$a..</nowiki></code>, jolly <code><nowiki>x:</nowiki></code>, <code><nowiki>fit</nowiki></code> (decidono ''quali'' semi).
# Alternative: scegliere un ramo per ogni <code><nowiki>any()</nowiki></code> e ogni <code><nowiki>S~</nowiki></code> (escludendo i rami impossibili con i vincoli già noti); applicare <code><nowiki>not()</nowiki></code> come vincoli di esclusione.
# Lunghezze (<code><nowiki>suits</nowiki></code>, <code><nowiki>compare</nowiki></code>, <code><nowiki>longest</nowiki></code>, <code><nowiki>shape</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>fit</nowiki></code>).
# Carte precise (<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>cards_held/not_held</nowiki></code>, <code><nowiki>lead</nowiki></code>).
# Conteggi (<code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code>, <code><nowiki>keycards</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>).
# Punteggi derivati (<code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>, <code><nowiki>pair_*</nowiki></code>) e <code><nowiki>stoppers</nowiki></code>.
# Verifica finale.

Un vincolo è "rigido" se riguarda carte/lunghezze fissate (1-4); "morbido" se si ripara per scambio (5-6).

----

== 4. Semantica delle combinazioni delicate ==

* <code><nowiki>quiet</nowiki></code> è già espanso in <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, <code><nowiki>hcp</nowiki></code>: nessun trattamento speciale (il campo <code><nowiki>quiet: 1</nowiki></code> serve solo alla descrizione). Una difesa quiet '''riduce''' il margine PO per la coppia dichiarante: verificare la compatibilità prima di costruire (<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>...).
* <code><nowiki>S=...</nowiki></code> / <code><nowiki>S~...</nowiki></code> + <code><nowiki>S:N</nowiki></code> + <code><nowiki>Shcp</nowiki></code>: devono essere coerenti; l'API segnala le contraddizioni evidenti.
* Una carta (<code><nowiki>has:HQ</nowiki></code>) può comparire in una sola posizione; due posizioni con la stessa carta sono un errore di validazione, non un caso da risolvere a caso.
* <code><nowiki>any()</nowiki></code> dentro una posizione con variabili: le variabili si legano '''prima''', poi si sceglie il ramo.
* <code><nowiki>not()</nowiki></code> con <code><nowiki>S~</nowiki></code>: escludere dall'insieme di alternative, non solo filtrare a posteriori.
* <code><nowiki>longest:</nowiki></code> e <code><nowiki>compare</nowiki></code> valgono sulle lunghezze finali (dopo il bind delle variabili).
* <code><nowiki>context.lead</nowiki></code> (<code><nowiki>SK</nowiki></code>): la carta deve stare nella mano dell'attaccante (§2) e quella mano deve soddisfare i suoi vincoli (es. se ha <code><nowiki>S=KJT</nowiki></code>, <code><nowiki>lead:SK</nowiki></code> è coerente, <code><nowiki>lead:SQ</nowiki></code> no).

----

== 5. Funzionalità del motore (elenco completo da realizzare) ==

=== 5.1 Core (parità v1) — già in produzione, da conservare ===
Lunghezze, PO totali/per seme, <code><nowiki>x:</nowiki></code>, <code><nowiki>shape:</nowiki></code>, <code><nowiki>fit</nowiki></code>, <code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>quiet</nowiki></code>
(espanso), 422 con ragioni, tetto 2,5 s.

=== 5.2 Nuove funzioni DSL v2 ===
Tutte le righe di §1.1. Priorità di consegna in §9.

=== 5.3 Mani multiple e serie ===
<code><nowiki>count</nowiki></code> ≤ 100 per richiesta; opzione <code><nowiki>distinct: true</nowiki></code> (nessuna mano duplicata nella serie);
opzione <code><nowiki>balance: "round_robin" | "weighted"</nowiki></code> per distribuire gli scenari della stessa convenzione.

=== 5.4 Spiegazione per mano ===
Per ogni smazzata: per posizione, elenco dei vincoli con esito (✓) e valore effettivo
("♥: 5 carte, richiesto 5+"), e i '''binding''' (<code><nowiki>$a = ♥</nowiki></code>, <code><nowiki>x di opener = ♦</nowiki></code>). Serve al frontend.

=== 5.5 Verifica di una smazzata data ===
<code><nowiki>POST /api/deals/check</nowiki></code> con quattro mani e una <code><nowiki>source</nowiki></code> → elenco di vincoli soddisfatti/violati.
Usa lo stesso giudice del §3. Serve a: smazzate inserite a mano, correzione in aula, test.

=== 5.6 Mani parzialmente fissate (<code><nowiki>fixed</nowiki></code>) ===
Accettare mani complete o parziali (<code><nowiki>"opener": "SAK2."</nowiki></code>, o carte singole) e completare il resto
rispettando lo scenario. Se impossibile → 422 <code><nowiki>fixed_cards_conflict</nowiki></code>.

=== 5.7 Contesto di gioco della carta ===
<code><nowiki>contract</nowiki></code>, <code><nowiki>declarer</nowiki></code>, <code><nowiki>lead</nowiki></code>: il motore garantisce che la carta d'attacco sia nella mano giusta e
fornisce nel risultato <code><nowiki>play: { "contract":"4H", "declarer":"responder", "leader":"opp2", "lead":"SK" }</nowiki></code>.
(Il gioco successivo, oltre la prima carta, non è nel DSL: per Segnali e Attacchi la prima carta e le
mani bastano a mostrare la situazione.)

=== 5.8 Statistiche ===
Per scenario: tasso di successo, tentativi medi, p95 ms, codici di fallimento. Esposte in
<code><nowiki>GET /api/deals/stats</nowiki></code> e inviate a BridgePedia (§8.5) per tarare i vincoli.

----

== 6. Codici di errore (422 e simili) ==

Già in uso: <code><nowiki>exact_cards_always_conflict</nowiki></code>, <code><nowiki>generation_time_limit</nowiki></code>, <code><nowiki>suit_cards_below_hcp_min</nowiki></code>,
<code><nowiki>suit_minimums_exceed_hcp_max</nowiki></code>, <code><nowiki>suit_cards_exceed_hcp_max</nowiki></code>. Da aggiungere:

{| class="wikitable"
! Codice
! Quando
|-
| <code><nowiki>unsupported_feature</nowiki></code>
| lo scenario richiede un tag non supportato (<code><nowiki>detail</nowiki></code>: il tag)
|-
| <code><nowiki>dsl_errors</nowiki></code>
| l'API ha restituito <code><nowiki>errors</nowiki></code> o <code><nowiki>warnings</nowiki></code> (riportarli)
|-
| <code><nowiki>variable_unsatisfiable</nowiki></code>
| nessuna assegnazione dei semi variabili rende lo scenario possibile
|-
| <code><nowiki>fixed_cards_conflict</nowiki></code>
| <code><nowiki>fixed</nowiki></code> contraddice lo scenario o carte duplicate
|-
| <code><nowiki>pair_points_unreachable</nowiki></code>
| <code><nowiki>pairhcp/pairtp</nowiki></code> incompatibili con i limiti per posizione
|-
| <code><nowiki>lead_conflict</nowiki></code>
| <code><nowiki>lead</nowiki></code> incompatibile con la mano dell'attaccante
|-
| <code><nowiki>no_branch_left</nowiki></code>
| <code><nowiki>any()</nowiki></code>/<code><nowiki>S~</nowiki></code>/<code><nowiki>not()</nowiki></code> eliminano tutti i rami
|-
| <code><nowiki>shape_unreachable</nowiki></code>
| forma/lunghezze incompatibili con 13 carte per mano e per seme
|-
| <code><nowiki>invalid_request</nowiki></code>
| parametri non validi (count, seed...)
|}

Ogni 422 porta <code><nowiki>reasons: [{code, position?, detail}]</nowiki></code> leggibili dal frontend.

----

== 7. Test di conformità e qualità ==

=== 7.1 Invarianti (property test, ≥ 10.000 smazzate per scenario del wiki) ===
* 52 carte distinte; 13 per mano; nessun duplicato.
* <code><nowiki>satisfies()</nowiki></code> vero per ogni smazzata emessa (il giudice '''non''' deve condividere codice con il generatore).
* Stesso seed → stesso risultato.

=== 7.2 Casi minimi per costrutto (la DSL → cosa deve valere) ===

{| class="wikitable"
! #
! DSL
! Asserzione
|-
| 1
| <code><nowiki>opener S:5+ hcp:12-21</nowiki></code>
| ♠ ≥ 5, PO in intervallo
|-
| 2
| <code><nowiki>@M=H,S opener ${M}:5+</nowiki></code>
| due scenari generabili (<code><nowiki>H</nowiki></code>, <code><nowiki>S</nowiki></code>)
|-
| 3
| <code><nowiki>$a=M opener $a:5+; responder $a:3+</nowiki></code>
| in ogni mano: un nobile ≥5 in opener, lo stesso seme ≥3 in responder; entrambi i nobili compaiono su 1000 mani
|-
| 4
| <code><nowiki>$a=M $b=m opener $a:5+ $b:4+</nowiki></code>
| $a nobile, $b minore, mai lo stesso seme
|-
| 5
| <code><nowiki>opener stop:S</nowiki></code> su 1000 mani
| tutte le mani hanno A, Kx, Qxx o Jxxx a ♠
|-
| 6
| <code><nowiki>opener nostop:S S:3+</nowiki></code>
| nessuna mano con A, né Kx, Qxx o Jxxx a ♠ (con 3 carte: né A, né K, né Q)
|-
| 7
| <code><nowiki>opener aces:2 kc:H4</nowiki></code>
| 2 assi; assi + K♥ = 4
|-
| 8
| <code><nowiki>opener has:HQ lacks:SK</nowiki></code>
| Q♥ presente, K♠ assente
|-
| 9
| <code><nowiki>opener tp:20-22</nowiki></code>
| <code><nowiki>tp</nowiki></code> corretto con la definizione di §2
|-
| 10
| <code><nowiki>opener ltc:6-7</nowiki></code>
| LTC con la definizione di §2
|-
| 11
| <code><nowiki>opener H>S</nowiki></code> e <code><nowiki>opener H>=S longest:H</nowiki></code>
| confronti rispettati; <code><nowiki>longest</nowiki></code> con pari merito
|-
| 12
| <code><nowiki>opener shape:5-4-x-x</nowiki></code>
| 5 e 4 come due semi più lunghi in ordine; gli altri due sommano 4
|-
| 13
| <code><nowiki>opener shape:semi_balanced</nowiki></code>
| solo 5422 e 6322
|-
| 14
| <code><nowiki>opener any(S:5+, H:5+)</nowiki></code>
| almeno un nobile ≥ 5
|-
| 15
| <code><nowiki>opener not(S:4+, H:4+)</nowiki></code>
| nessun nobile ≥ 4
|-
| 16
| <code><nowiki>opener any(S:4+ hcp:12+, H:4+)</nowiki></code>
| rami composti
|-
| 17
| <code><nowiki>pairhcp:25+ ... opp1 quiet; opp2 quiet</nowiki></code>
| coppia ≥ 25, avversari entro i limiti quiet
|-
| 18
| <code><nowiki>weight:1 ... // weight:3 ...</nowiki></code>
| 1000 estrazioni ~ 25%/75% (± tolleranza)
|-
| 19
| <code><nowiki>dealer:opp1 vul:both</nowiki></code>
| output con dealer/vul corretti e PBN ruotato
|-
| 20
| <code><nowiki>declarer:responder lead:SK opp2 S=KJT</nowiki></code>
| K♠ in opp2; con <code><nowiki>lead:SQ</nowiki></code> → 422 <code><nowiki>lead_conflict</nowiki></code>
|-
| 21
| <code><nowiki>fixed</nowiki></code> con Q♥ in opener
| opener ha Q♥ e rispetta lo scenario
|-
| 22
| scenario impossibile (<code><nowiki>S=AK Shcp:0-2</nowiki></code>)
| 422 con ragione
|-
| 23
| scenario con <code><nowiki>unsupported</nowiki></code> simulato
| 422 <code><nowiki>unsupported_feature</nowiki></code>
|}

Aggiungere come test di regressione '''tutti gli scenari reali''' delle pagine del wiki
(<code><nowiki>shapeaction=list</nowiki></code> → <code><nowiki>get</nowiki></code>): per ciascuno ≥ 1000 smazzate valide entro il budget, oppure una
diagnosi documentata. Gli scenari più duri oggi: ''Multirever'' (Gran rever, 20 scenari) e
''Segnale di Smith'' (20 scenari con <code><nowiki>suit_cards</nowiki></code>).

=== 7.3 Qualità statistica ===
Per ogni scenario del wiki misurare su 5000 mani: distribuzione delle lunghezze e dei PO nei limiti
consentiti, tasso di riuscita al primo tentativo, tempo p50/p95. Segnalare distorsioni evidenti
(es. la posizione A prende sempre i PO alti).

=== 7.4 Prestazioni ===
Obiettivo: p95 < 300 ms per mano sugli scenari comuni; < 2,5 s sul peggiore. Se non si rispetta,
non allargare i vincoli: segnalare lo scenario a BridgePedia (§8.5) che può rivederlo.

----

== 8. Frontend di Play ==

Il frontend deve permettere di '''consultare''', '''generare''', '''creare''' e '''gestire''' smazzate.
Lingua: italiano, con i18n predisposta (en, fr, es, de). Tutti i testi dei vincoli vengono
dall'API (<code><nowiki>descriptions</nowiki></code>, parametro <code><nowiki>lang</nowiki></code>): non riscriverli.

=== 8.1 Catalogo delle convenzioni ===
* Elenco da <code><nowiki>shapeaction=list</nowiki></code> (con vincoli) e <code><nowiki>listall</nowiki></code> (tutte, con <code><nowiki>hasShape</nowiki></code>).
* Per ogni voce: titolo, numero di scenari, link alla pagina del wiki, stato: ''generabile'', ''parzialmente generabile'' (alcuni scenari con <code><nowiki>requires</nowiki></code> non supportato), ''non generabile''.
* Ricerca testuale; filtri per tipologia/sistema se esposti; badge "da verificare" per le traduzioni non verificate.
* Le 27 convenzioni senza vincoli compaiono come "scenari in arrivo" con link al wiki.

=== 8.2 Visualizzatore di scenario ===
* Tabella a colonne per posizione (come la tabella del wiki): etichetta scenario, frasi di <code><nowiki>descriptions[i].positions</nowiki></code>, <code><nowiki>positionLabels</nowiki></code> (rispettare i ruoli personalizzati, es. "Attaccante"), <code><nowiki>fit</nowiki></code>, <code><nowiki>context</nowiki></code>.
* Semi ♥ ♦ in rosso. Mostrare <code><nowiki>requires</nowiki></code> come chip (tooltip con spiegazione).
* Pulsante "Mostra DSL" (testo <code><nowiki>raw</nowiki></code>) e "Apri la pagina nel wiki".

=== 8.3 Generatore ===
* Scelta convenzione → scenario (singolo, "a caso", "tutti a rotazione", pesato) → quantità (1-100) → opzioni (seed, mani distinte, nascondi avversari).
* Risultato: schede smazzata con 4 mani (formato BridgeCards: ♠♥♦♣, bordi, dealer, vulnerabilità), etichetta scenario, '''pannello "perché questa mano"''': per posizione le frasi di <code><nowiki>explanation</nowiki></code> con spunta, binding (<code><nowiki>$a = ♥</nowiki></code>), PO/lunghezze effettive.
* Azioni per smazzata: rigenera, "blocca questa mano e rigenera le altre" (usa <code><nowiki>fixed</nowiki></code>), copia link con seed, esporta PBN/LIN/immagine, aggiungi alla raccolta.
* Se la licita <code><nowiki>auction</nowiki></code> è presente: mostrarla con <code><nowiki><bidding></nowiki></code> (stile BridgeCards) o nascosta per esercizio ("indovina la risposta").
* Gestione 422: messaggio per codice (§6) con suggerimento ("lo scenario è impossibile perché..."). Per <code><nowiki>unsupported_feature</nowiki></code>: spiegare quale capacità manca.

=== 8.4 Editor / creazione di scenari ===
Due modalità sincronizzate:

# '''Modulo guidato''' per posizione (Apertore, Compagno, Avv. sinistro, Avv. destro):
#* lunghezze per seme (slider min-max), PO totali e per seme, forma (classi + schema <code><nowiki>5-4-x-x</nowiki></code>);
#* griglia carte per seme (A K Q J 10 9 + "basse") con stati ''deve avere / non deve avere / indifferente'' che produce <code><nowiki>S=...</nowiki></code>; costruttore di pattern per <code><nowiki>S~</nowiki></code> con anteprima;
#* interruttori: fermata (per seme), assi/re/dame/controlli, carte chiave con atout, <code><nowiki>tp/dp/ltc</nowiki></code>, confronti tra semi, <code><nowiki>any(...)</nowiki></code>/<code><nowiki>not(...)</nowiki></code> come gruppi aggiungibili;
#* variabili di seme <code><nowiki>$a..$d</nowiki></code> con dominio (nobili/minori/qualsiasi);
#* contesto: dealer, vulnerabilità, licita, contratto, attacco, peso;
#* avversari: pulsante '''quiet''' (e <code><nowiki>quiet:max</nowiki></code>);
#* macro: "ripeti per ogni nobile / minore / seme" genera <code><nowiki>@M=...</nowiki></code>.
# '''Editor testuale''' del DSL con evidenziazione, completamento e ''validazione live'': chiama <code><nowiki>shapeaction=validate</nowiki></code> (debounce 400 ms) e mostra <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>, <code><nowiki>descriptions</nowiki></code> e <code><nowiki>requires</nowiki></code> (con il supporto del motore). Le due modalità si convertono a vicenda (modulo → DSL è obbligatorio; DSL → modulo almeno per i costrutti elementari, il resto resta testuale).

* Pulsante "Prova": genera 5 mani di test dallo scenario in modifica e mostra tempi e tassi di riuscita.
* Salvataggio come '''bozza personale''' in Play (non scrive sul wiki). Pulsante "Copia per BridgePedia" produce la riga <code><nowiki>shape_constraints</nowiki></code> da incollare nella pagina (gli editor del wiki fanno il resto).
* Libreria di '''modelli''' presi dalle convenzioni del wiki ("parti da Landy").

=== 8.5 Retroazione verso BridgePedia ===
* Pulsante "Segnala scenario problematico" (lento / troppo raro / 422 / distribuzione strana) che invia: pagina, scenario, <code><nowiki>dslVersion</nowiki></code>, codice errore, statistiche (§5.8) al canale concordato (sessione/issue). Nessuna scrittura diretta sul wiki.
* Report periodico automatico delle statistiche di generazione per scenario.

=== 8.6 Smazzate manuali ===
* Compositore: assegnare le 52 carte alle quattro mani con trascinamento o digitazione (<code><nowiki>AK2.QJ5.K84.T65</nowiki></code>), controllo duplicati, completamento casuale delle carte mancanti (opzionalmente rispettando uno scenario: usa <code><nowiki>fixed</nowiki></code>).
* Pulsante "Verifica rispetto a uno scenario" (§5.5) con l'elenco dei vincoli soddisfatti e violati.
* Importa/esporta PBN, LIN, testo semplice.

=== 8.7 Gestione delle smazzate ===
* Raccolte ("mazzi di esercizio"): nome, descrizione, convenzione, tag; ordinamento; duplicati evitati.
* Ricerca per convenzione, scenario, tag, data; filtri per vulnerabilità, dealer.
* Metadati salvati: <code><nowiki>seed</nowiki></code>, <code><nowiki>source.page</nowiki></code>, scenario, <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>revid</nowiki></code>, data, autore.
* Note personali per smazzata; stampa di una raccolta (fogli A4 con 4 o 6 smazzate per pagina, versione "solo mano dell'apertore" per esercizio).
* Condivisione: link con seed/raccolta, permessi (privato, gruppo, pubblico) secondo il modello utenti di Play. Esportazione in blocco (PBN).
* Modalità "esercizio di licita": mostra le mani di un lato, l'utente inserisce la licita, il frontend confronta con <code><nowiki>context.auction</nowiki></code> se presente.

=== 8.8 Requisiti trasversali ===
* Mobile first; tastiera accessibile; semi anche come lettere per daltonici.
* Nessuna dipendenza dal wiki per il rendering delle carte (usare componenti propri; stile coerente con BridgeCards).
* Tempi: la generazione deve mostrare avanzamento e poter essere annullata.
* Tracciare (analytics interni) tempi, errori e scenari più usati.
* Testo dei vincoli sempre da <code><nowiki>descriptions</nowiki></code> con <code><nowiki>lang</nowiki></code> coerente con la lingua dell'interfaccia.

----

== 9. Piano di consegna consigliato ==

{| class="wikitable"
! Fase
! Contenuto
! Esito atteso
|-
| '''P0 — compatibilità''' (subito)
| leggere <code><nowiki>dslVersion</nowiki></code>, <code><nowiki>requires</nowiki></code>, <code><nowiki>errors</nowiki></code>, <code><nowiki>warnings</nowiki></code>; esporre <code><nowiki>/capabilities</nowiki></code>; rifiutare con <code><nowiki>unsupported_feature</nowiki></code>; giudice <code><nowiki>satisfies()</nowiki></code> per v1
| nessuna smazzata errata con le pagine nuove
|-
| '''P1 — core v2'''
| macro (nessun lavoro, già espanse), <code><nowiki>weight</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>shape_pattern</nowiki></code>, classi nuove, <code><nowiki>compare</nowiki></code>/<code><nowiki>longest</nowiki></code>, <code><nowiki>any/not</nowiki></code>, <code><nowiki>pair_*</nowiki></code>
| scenari per Landy/Cappelletti/DONT/Smolen con forme e alternative
|-
| '''P2 — variabili e carte'''
| <code><nowiki>vars</nowiki></code> condivise tra posizioni, <code><nowiki>has/lacks</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>aces/kings/queens/controls/kc</nowiki></code>
| Michaels, Sputnik, Lebensohl, Blackwood/RKCB, Exclusion
|-
| '''P3 — punteggi'''
| <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code>
| sistemi a forza (Fiori forte, 2♣ forte, Gazzilli)
|-
| '''P4 — frontend lettura'''
| catalogo, visualizzatore, generatore con spiegazioni
| tutti possono provare le convenzioni
|-
| '''P5 — frontend creazione'''
| editor guidato + testuale con validazione live, "Prova", bozze
| gli editor creano e collaudano scenari senza il wiki
|-
| '''P6 — gestione'''
| raccolte, smazzate manuali, <code><nowiki>check</nowiki></code>, <code><nowiki>fixed</nowiki></code>, esportazioni, esercizi di licita
| uso didattico completo
|-
| '''P7 — qualità'''
| suite di conformità (§7), statistiche, report verso BridgePedia
| motore misurabile
|}

Ogni fase deve chiudersi con i test di §7 per i costrutti introdotti. BridgePedia estende le
pagine del wiki man mano che i tag diventano disponibili: '''comunicate a ogni fase la lista dei tag supportati''' (<code><nowiki>/capabilities</nowiki></code>) così il wiki passa dalle approssimazioni (pattern <code><nowiki>S~</nowiki></code>) ai
costrutti nativi solo quando il motore li regge.

----

== 10. Cosa fa BridgePedia (per non sovrapporsi) ==

* Mantiene il DSL, il parser, le descrizioni e l'API; aggiunge costrutti su richiesta motivata.
* Scrive e tiene aggiornati gli scenari nelle pagine delle convenzioni; le 27 mancanti saranno coperte via via con i costrutti v2.
* Fornisce il catalogo di ricette (come descrivere Landy, Blackwood, un attacco sotto onore...).
* Riceve da Play le segnalazioni di §8.5 e rivede i vincoli troppo duri.

== 11. Decisioni aperte (da concordare con Play) ==

# Definizione definitiva delle classi di forma (§2) rispetto a quanto già implementato.
# Formato di <code><nowiki>explanation</nowiki></code> (testo semplice vs struttura con esito per vincolo).
# Modello di persistenza e permessi delle raccolte (utenti Play).
# Canale per le segnalazioni verso BridgePedia (§8.5).
# Se <code><nowiki>fixed</nowiki></code> deve accettare anche vincoli aggiuntivi temporanei (override locali dello scenario).

[[Categoria:Documentazione tecnica]]

Progetto:BridgeShape API

2026-10-23T05:49:06Z

Lpala: BridgeShape: documentazione DSL v2

Documentazione BridgeShape: [[Progetto:BridgeShape Motore e frontend|Motore e frontend]] · [[Progetto:BridgeShape Ricette DSL|Ricette DSL]]

= BridgeShape — API per Generatori di Smazzate =

Documentazione tecnica per chi sviluppa un generatore di smazzate di test
che legge i vincoli di distribuzione (shape constraints) dalle convenzioni
di BridgePedia.

== Panoramica ==

Ogni pagina wiki di convenzione su BridgePedia può definire nel template
<code><nowiki>{{Convenzione}}</nowiki></code> un campo <code><nowiki>shape_constraints</nowiki></code> che descrive, in un formato
DSL compatto, i vincoli di distribuzione delle mani dei 4 giocatori al tavolo.

L'estensione '''BridgeShape''' espone un'API REST/JSON per leggere questi
vincoli in modo strutturato.

----

== API Endpoint ==

<syntaxhighlight lang="text">
GET /api.php?action=bridgeshape&shapeaction=ACTION&format=json
</syntaxhighlight>

=== Azioni disponibili ===

{| class="wikitable"
! Azione
! Descrizione
! Parametri
|-
| <code><nowiki>get</nowiki></code>
| Vincoli per una singola convenzione
| <code><nowiki>pageid</nowiki></code> oppure <code><nowiki>title</nowiki></code>
|-
| <code><nowiki>list</nowiki></code>
| Elenco convenzioni con vincoli definiti
| —
|-
| <code><nowiki>listall</nowiki></code>
| Elenco tutte le convenzioni (con/senza vincoli)
| —
|-
| <code><nowiki>validate</nowiki></code>
| Valida una stringa DSL senza bisogno di una pagina wiki
| <code><nowiki>dsl</nowiki></code>
|}

=== Esempi di chiamata ===

<syntaxhighlight lang="bash">
# Per titolo pagina
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&title=Splinter&format=json"

# Per page ID
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=get&pageid=42&format=json"

# Elenco pagine con vincoli
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=list&format=json"

# Validare una stringa DSL
curl "https://bridgepedia.it/api.php?action=bridgeshape&shapeaction=validate&dsl=opener+H:5%2B+hcp:12-21&format=json"
</syntaxhighlight>

----

== Formato risposta JSON ==

=== <code><nowiki>shapeaction=get</nowiki></code> ===

<syntaxhighlight lang="json">
{
"shapeconstraints": {
"pageId": 42,
"raw": "1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 // ...",
"scenarios": [
{
"label": "1H-4C",
"positions": {
"opener": {
"suits": {
"H": { "min": 5, "max": null }
},
"hcp": { "min": 12, "max": 21 }
},
"responder": {
"suits": {
"H": { "min": 4, "max": null },
"C": { "min": 0, "max": 1 }
},
"suit_hcp": {
"C": { "min": 0, "max": 0 }
},
"hcp": { "min": 10, "max": 15 }
}
},
"fit": []
}
]
}
}
</syntaxhighlight>

'''Descrizioni leggibili.''' Insieme a <code><nowiki>scenarios</nowiki></code>, <code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono
<code><nowiki>descriptions</nowiki></code> (stesso ordine): per ogni scenario <code><nowiki>label</nowiki></code>, <code><nowiki>positions</nowiki></code>
(per posizione, elenco di frasi già tradotte, es. <code><nowiki>"♠: ha K J 10 (e non A Q 9)"</nowiki></code>),
<code><nowiki>positionLabels</nowiki></code> (nome del ruolo, es. "Attaccante" se la pagina ha <code><nowiki>shape_roles</nowiki></code>;
altrimenti "Apertore (chi usa la convenzione)", "Compagno", ...) e <code><nowiki>fit</nowiki></code>.
Parametro opzionale <code><nowiki>lang</nowiki></code> (it, en, ...; default lingua dell'API, di solito <code><nowiki>it</nowiki></code>).
Serve a mostrare nell'interfaccia di Play '''perché''' la mano è fatta così.
Nella posizione compare anche <code><nowiki>quiet: 1</nowiki></code> se è stata usata la macro <code><nowiki>quiet</nowiki></code>.

=== <code><nowiki>shapeaction=list</nowiki></code> ===

<syntaxhighlight lang="json">
{
"pages": [
{
"pageId": 42,
"title": "Splinter",
"scenarioCount": 6,
"labels": ["1H-4C", "1H-4D", "1H-4S", "1S-4C", "1S-4D", "1S-4H"]
},
{
"pageId": 15,
"title": "Stayman",
"scenarioCount": 2,
"labels": ["fit a cuori", "fit a picche"]
}
]
}
</syntaxhighlight>

----

== Formato DSL ==

Il DSL (Domain Specific Language) è la stringa scritta nel campo
<code><nowiki>shape_constraints</nowiki></code> del template wiki.

=== Struttura ===

<syntaxhighlight lang="text">
etichetta: vincoli posizione; vincoli posizione // etichetta: vincoli // ...
</syntaxhighlight>

* '''<code><nowiki>//</nowiki></code>''' separa gli scenari (il generatore ne sceglie uno random o li presenta all'utente)
* '''<code><nowiki>;</nowiki></code>''' separa le posizioni dentro uno scenario
* Ogni scenario ha un''''etichetta''' opzionale seguita da <code><nowiki>:</nowiki></code>
* Ogni posizione inizia col nome del ruolo, seguito da vincoli separati da spazi

=== Posizioni ===

{| class="wikitable"
! Nome
! Ruolo
|-
| <code><nowiki>opener</nowiki></code>
| Chi apre o fa la prima licita convenzionale
|-
| <code><nowiki>responder</nowiki></code>
| Il compagno dell'opener
|-
| <code><nowiki>opp1</nowiki></code>
| Avversario a sinistra dell'opener
|-
| <code><nowiki>opp2</nowiki></code>
| Avversario a destra dell'opener (compagno di opp1)
|}

=== Vincoli ===

==== Lunghezza seme (specifico) ====

<syntaxhighlight lang="text">
S:5+ — almeno 5 picche
H:0-1 — 0 o 1 cuori
D:3 — esattamente 3 quadri
C:2-5 — da 2 a 5 fiori
</syntaxhighlight>

Semi: <code><nowiki>S</nowiki></code> = Spades/Picche, <code><nowiki>H</nowiki></code> = Hearts/Cuori, <code><nowiki>D</nowiki></code> = Diamonds/Quadri, <code><nowiki>C</nowiki></code> = Clubs/Fiori

==== Lunghezza seme (wildcard) ====

<syntaxhighlight lang="text">
x:0-1 — un seme qualsiasi (tra quelli non specificati) con 0-1 carte
x:6+ — un seme non specificato con almeno 6 carte
</syntaxhighlight>

Il generatore sceglie casualmente quale seme assegnare a <code><nowiki>x</nowiki></code> tra quelli
non già vincolati esplicitamente (S/H/D/C).

==== HCP totali ====

<syntaxhighlight lang="text">
hcp:15-17 — da 15 a 17 punti onore
hcp:12+ — almeno 12 punti
hcp:0-7 — da 0 a 7 punti
</syntaxhighlight>

==== HCP nel seme (specifico) ====

<syntaxhighlight lang="text">
Shcp:3+ — almeno 3 HCP a picche
Chcp:0 — 0 HCP a fiori (nessun onore)
Hhcp:0-2 — da 0 a 2 HCP a cuori
</syntaxhighlight>

==== HCP nel seme (wildcard) ====

<syntaxhighlight lang="text">
xhcp:0 — 0 HCP nel seme wildcard (x)
xhcp:0-1 — 0-1 HCP nel seme x
</syntaxhighlight>

==== Shape class ====

<syntaxhighlight lang="text">
shape:balanced — distribuzione bilanciata (4333, 4432, 5332)
shape:one_suiter — monocolore
shape:two_suiter — bicolore
shape:three_suiter — tricolore
shape:any — qualsiasi (default)
</syntaxhighlight>

==== Onori esatti in un seme (<code><nowiki>S=KJT</nowiki></code>) ====

<syntaxhighlight lang="text">
S=KJT — in picche ha K, J e 10; NON ha A, Q, 9 (le carte basse 8-2 completano)
S=KT9 — sequenza interna: K, 10, 9; NON ha A, Q, J
H=Q — a cuori ha la Q come unico onore tra A K Q J 10
D=x — nessun onore a quadri (solo carte basse)
</syntaxhighlight>

Le lettere ammesse sono <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>). La regola è: '''le carte elencate sono possedute, le altre tra A K Q J 10 9 NON lo sono'''; le carte
dall'8 in giù sono libere e riempiono fino alla lunghezza del seme. Serve a
descrivere attacchi (sequenza interrotta <code><nowiki>KJT</nowiki></code>, interna <code><nowiki>KT</nowiki></code>, sotto onore <code><nowiki>K</nowiki></code> o
<code><nowiki>Q</nowiki></code>) e le carte del compagno. Si combina con la lunghezza (<code><nowiki>S:5 S=KJT</nowiki></code>).

Nel JSON compare <code><nowiki>suit_cards</nowiki></code> nella posizione, es. <code><nowiki>{"S": "KJT", "H": ""}</nowiki></code>
(stringa vuota = nessuna carta alta). Il generatore deve:
* assegnare esattamente quegli onori alla mano e '''escluderli''' dalle altre mani del seme; gli onori non nominati da nessuna posizione sono distribuiti a caso, ma mai a una posizione con <code><nowiki>suit_cards</nowiki></code> per quel seme che non li elenca;
* rispettare comunque <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code> (la validazione segnala le contraddizioni, es. <code><nowiki>S=KQ Shcp:0-2</nowiki></code> o lo stesso onore a due mani).

==== Pattern di mano in un seme (<code><nowiki>S~...</nowiki></code>, stile regex) ====

Descrive '''l'intera mano in quel seme''', dall'alto in basso, come una piccola
espressione regolare ancorata (inizio e fine):

<syntaxhighlight lang="text">
S~AKQ. — A, K, Q + una carta bassa (4 carte)
S~A... — A + tre carte basse (4 carte)
S~AJT9. — A, J, 10, 9 + una bassa
S~AKQ.|A... — alternative: una OPPURE l'altra
S~[KQ]x{2,3} — K o Q (come unico onore) + 2 o 3 carte basse
S~KJT.* — K, J, 10 + qualunque numero di basse (anche zero)
</syntaxhighlight>

Elementi:
* '''Carte alte''' <code><nowiki>A K Q J T 9</nowiki></code> (anche <code><nowiki>10</nowiki></code>), '''sempre in ordine decrescente''', ciascuna posseduta; quelle non nominate tra A K Q J 10 9 NON sono possedute.
* '''Classe''' <code><nowiki>[KQ]</nowiki></code> = una carta tra quelle (si espande in alternative).
* '''Carta bassa''' <code><nowiki>.</nowiki></code> (o <code><nowiki>x</nowiki></code>) = una carta qualsiasi tra 8 e 2; compare solo in fondo. Quantificatori: <code><nowiki>?</nowiki></code> (0-1), <code><nowiki>*</nowiki></code> (0 o più), <code><nowiki>+</nowiki></code> (1 o più), <code><nowiki>{n}</nowiki></code>, <code><nowiki>{n,m}</nowiki></code>. Più punti si sommano (<code><nowiki>...</nowiki></code> = tre basse).
* '''Alternative''' <code><nowiki>|</nowiki></code>: il generatore ne sceglie una a caso per ogni mano.

È la forma più espressiva di <code><nowiki>S=KJT</nowiki></code> (che resta valida): il pattern fissa anche
la lunghezza (<code><nowiki>S~A...</nowiki></code> = 4 carte). Se c'è anche <code><nowiki>S:N</nowiki></code> i due vincoli devono
essere compatibili (la validazione API segnala le incompatibilità).

Nel JSON compare <code><nowiki>suit_patterns</nowiki></code> nella posizione, già '''normalizzato''' (classi
espanse, quantificatori risolti), così il generatore non deve interpretare la
regex:

<syntaxhighlight lang="json">
"suit_patterns": {
"S": [
{"cards": "AKQ", "low_min": 1, "low_max": 1},
{"cards": "A", "low_min": 3, "low_max": 3}
]
}
</syntaxhighlight>

<code><nowiki>cards</nowiki></code> = carte alte possedute (ordine A K Q J T 9); <code><nowiki>low_min</nowiki></code>/<code><nowiki>low_max</nowiki></code> =
numero di carte basse (2-8), <code><nowiki>low_max: null</nowiki></code> = nessun limite. La lunghezza del
seme è <code><nowiki>len(cards) + numero di basse</nowiki></code>. Il generatore sceglie una alternativa e
rispetta anche <code><nowiki>suits</nowiki></code> e <code><nowiki>suit_hcp</nowiki></code>. Gli onori di <code><nowiki>cards</nowiki></code> vanno esclusi dalle altre
mani; quelli non nominati nella mano vanno ad altri a caso.

==== Avversari "quiet" (nessun intervento) ====

<syntaxhighlight lang="text">
opp1 quiet — solo per opp1/opp2
opp2 quiet:0-7 — come quiet, ma con HCP personalizzati
</syntaxhighlight>

<code><nowiki>quiet</nowiki></code> è una '''macro espansa dall'API''': nel JSON non compare mai la parola
<code><nowiki>quiet</nowiki></code>, ma i vincoli già risolti. Chi legge l'API (il generatore) non deve
implementare nulla di nuovo. Si espande in:

<syntaxhighlight lang="text">
S:0-4 H:0-4 D:0-5 C:0-5 hcp:0-9 Shcp:0-3 Hhcp:0-3 Dhcp:0-4 Chcp:0-4
(con quiet:0-7 → hcp:0-7)
</syntaxhighlight>

Significato: gli avversari possono avere colori lunghi (così le mani sono
varie), ma poveri di onori e con pochi punti: nessun colore da 6+ carte
(niente apertura di sbarramento), nessun contro informativo, nessun intervento
naturale credibile. Le distribuzioni ammesse sono quindi molte, ma con punti
ridotti: il generatore ha meno margine sugli HCP della coppia dichiarante
(40 punti totali: apertore+rispondente restano sopra ~22).
I token espliciti scritti sulla stessa posizione '''sostituiscono''' i default,
in qualsiasi ordine: <code><nowiki>opp1 quiet S:0-4</nowiki></code> lascia le picche 0-4 e tiene il resto.
Su <code><nowiki>opener</nowiki></code>/<code><nowiki>responder</nowiki></code> la macro viene ignorata.

==== Fit (vincolo cross-posizione) ====

<syntaxhighlight lang="text">
fit:H8+ — almeno 8 cuori totali tra i compagni
fit:S9+ — almeno 9 picche totali tra i compagni
fit:M8+ — almeno 8 carte in un seme maggiore (H o S)
fit:m8+ — almeno 8 carte in un seme minore (D o C)
fit:8+ — almeno 8 carte in un seme qualsiasi
</syntaxhighlight>

Il fit si applica tra '''compagni''':
* Se appare su <code><nowiki>opener</nowiki></code> o <code><nowiki>responder</nowiki></code>, o a livello di scenario → coppia dichiarante
* Se appare su <code><nowiki>opp1</nowiki></code> o <code><nowiki>opp2</nowiki></code> → coppia difensiva

=== Formato range ===

{| class="wikitable"
! Sintassi
! Significato
|-
| <code><nowiki>5+</nowiki></code>
| Almeno 5 (min=5, max=null)
|-
| <code><nowiki>0-1</nowiki></code>
| Da 0 a 1 (min=0, max=1)
|-
| <code><nowiki>3</nowiki></code>
| Esattamente 3 (min=3, max=3)
|-
| <code><nowiki>12-21</nowiki></code>
| Da 12 a 21 (min=12, max=21)
|}

Nella risposta JSON, <code><nowiki>max: null</nowiki></code> significa "nessun limite superiore".

=== Semi non menzionati ===

I semi '''non vincolati''' e non coperti da <code><nowiki>x:</nowiki></code> sono distribuiti '''casualmente'''
dal generatore, rispettando il vincolo che il totale delle carte per mano sia 13.

----

== DSL versione 2 (<code><nowiki>dslVersion: 2</nowiki></code>) ==

Tutto ciò che sopra resta valido e '''invariato''': una pagina che usa solo la v1
produce lo stesso JSON di prima. La v2 aggiunge sintassi nuova; ogni scenario che
la usa ha nel JSON il campo <code><nowiki>requires</nowiki></code> (elenco di tag, vedi sotto) così un motore
parziale può rifiutarlo con un errore esplicito invece di generare mani sbagliate.
Le definizioni normative (cosa è una fermata, i punti totali, le perdenti...) e
l'architettura del motore sono in '''<code><nowiki>DEAL_ENGINE_SPEC.md</nowiki></code>'''.

=== Macro di scrittura (<code><nowiki>@NOME=v1,v2</nowiki></code>) — risolte dal parser, il motore non le vede ===

<syntaxhighlight lang="text">
@M=H,S 1${M}: opener ${M}:5+ hcp:12-21; responder ${M}:3+
</syntaxhighlight>
Genera due scenari (<code><nowiki>1H</nowiki></code>, <code><nowiki>1S</nowiki></code>) sostituendo <code><nowiki>${M}</nowiki></code> ovunque, etichetta compresa.
Più prefissi fanno il prodotto cartesiano (max 64 scenari): <code><nowiki>@M=H,S @N=15-17,12-14</nowiki></code>.
I valori possono essere intervalli (<code><nowiki>hcp:${N}</nowiki></code>): servono anche come parametri del
sistema (SA 15-17 contro 14-16).

=== Semi variabili <code><nowiki>$a $b $c $d</nowiki></code> ===

Un seme "da scegliere" condiviso da più posizioni dello stesso scenario. Ogni
variabile è un seme diverso dalle altre. Dominio dichiarato a livello di scenario
(prima delle posizioni):

<syntaxhighlight lang="text">
Landy: $a=M $b=any opener hcp:12-21 ; opp1 $a:5+ $b:4+ ; responder $a:0-2
</syntaxhighlight>
<code><nowiki>$a=M</nowiki></code> nobili, <code><nowiki>$a=m</nowiki></code> minori, <code><nowiki>$a=any</nowiki></code> (default) qualunque, <code><nowiki>$a=SH</nowiki></code> insieme esplicito.
Si usano al posto di <code><nowiki>S H D C</nowiki></code> in: <code><nowiki>$a:5+</nowiki></code> (lunghezza), <code><nowiki>$ahcp:</nowiki></code>, <code><nowiki>$a=KQ</nowiki></code>, <code><nowiki>$a~...</nowiki></code>,
<code><nowiki>stop:$a</nowiki></code>, <code><nowiki>has:$aQ</nowiki></code>, <code><nowiki>kc:$a3</nowiki></code>, confronti (<code><nowiki>$a>$b</nowiki></code>), <code><nowiki>longest:$a</nowiki></code>.
Differisce da <code><nowiki>x:</nowiki></code> (che vale per una sola posizione).
JSON: lo stesso dizionario <code><nowiki>suits</nowiki></code>, <code><nowiki>suit_hcp</nowiki></code>, ... ma con chiave <code><nowiki>"$a"</nowiki></code>;
a livello di scenario <code><nowiki>"vars": {"$a": ["S","H"]}</nowiki></code>.

=== Controlli, carte chiave, carte precise ===

{| class="wikitable"
! Token
! Significato
|-
| <code><nowiki>aces:2</nowiki></code> <code><nowiki>kings:1-2</nowiki></code> <code><nowiki>queens:0</nowiki></code>
| numero di assi / re / dame nella mano
|-
| <code><nowiki>controls:6+</nowiki></code>
| controlli (A=2, K=1)
|-
| <code><nowiki>kc:H3</nowiki></code> <code><nowiki>kc:H2-3</nowiki></code> <code><nowiki>kc:$a3</nowiki></code>
| carte chiave con atout H: i 4 assi + il Re di H (0-5)
|-
| <code><nowiki>has:HQ</nowiki></code> <code><nowiki>has:S10</nowiki></code>
| possiede quella carta precisa
|-
| <code><nowiki>lacks:HQ</nowiki></code>
| NON possiede quella carta
|-
| <code><nowiki>stop:S</nowiki></code> <code><nowiki>nostop:S</nowiki></code>
| ha / non ha una fermata nel seme (definizione in SPEC)
|}

JSON: <code><nowiki>aces</nowiki></code>, <code><nowiki>kings</nowiki></code>, <code><nowiki>queens</nowiki></code>, <code><nowiki>controls</nowiki></code> (Range); <code><nowiki>keycards: {"H": Range}</nowiki></code>;
<code><nowiki>cards_held: ["HQ"]</nowiki></code>, <code><nowiki>cards_not_held: ["SK"]</nowiki></code>; <code><nowiki>stoppers: {"S": 1, "H": 0}</nowiki></code>
(1 = deve averla, 0 = non deve averla).

=== Punti e perdenti ===

<code><nowiki>tp:</nowiki></code> punti totali (PO + 1 per ogni carta oltre la quarta in ogni seme),
<code><nowiki>dp:</nowiki></code> punti distribuzione (PO + 3 chicane + 2 singolo + 1 doubleton),
<code><nowiki>ltc:</nowiki></code> perdenti (Losing Trick Count). A livello di scenario: <code><nowiki>pairhcp:25+</nowiki></code>
(PO della coppia dichiarante), <code><nowiki>defhcp:0-14</nowiki></code> (coppia avversaria), <code><nowiki>pairtp:26+</nowiki></code>.
JSON: <code><nowiki>tp</nowiki></code>, <code><nowiki>dp</nowiki></code>, <code><nowiki>ltc</nowiki></code> (Range) nella posizione; <code><nowiki>pair_hcp: {"declarer": R, "defense": R}</nowiki></code>,
<code><nowiki>pair_tp: {"declarer": R}</nowiki></code> nello scenario.

=== Confronti tra semi e forme precise ===

<syntaxhighlight lang="text">
H>S H>=S H<S H<=S H==S $a>$b — confronto di lunghezze nella stessa mano
longest:H — H è tra i semi più lunghi (pari merito ammesso)
shape:5-4-x-x shape:5422 shape:54xx — lunghezze ordinate in modo decrescente, x = qualsiasi
shape:semi_balanced — 5422 e 6322 (si aggiunge alle classi esistenti)
</syntaxhighlight>
JSON: <code><nowiki>compare: [{"left":"H","op":">=","right":"S"}]</nowiki></code>, <code><nowiki>longest: ["H"]</nowiki></code>,
<code><nowiki>shape_pattern: "54xx"</nowiki></code>.

=== Alternative e negazioni nella stessa mano: <code><nowiki>any(...)</nowiki></code> e <code><nowiki>not(...)</nowiki></code> ===

<syntaxhighlight lang="text">
opener any(S:4+ hcp:12+, H:4+) not(D:6+)
</syntaxhighlight>
<code><nowiki>any(A, B)</nowiki></code>: la mano soddisfa '''almeno una''' delle alternative (separate da virgola;
ogni alternativa è una congiunzione di token). <code><nowiki>not(A, B)</nowiki></code>: la mano non soddisfa
'''nessuna''' delle alternative. Si possono scrivere più gruppi (si combinano in AND);
niente annidamenti.
JSON: <code><nowiki>any: [[altA, altB], ...]</nowiki></code> (lista di gruppi; ogni alternativa è un oggetto
con gli stessi campi di una posizione), <code><nowiki>not: [altA, altB]</nowiki></code>.

=== Contesto dello scenario ===

Token prima delle posizioni: <code><nowiki>weight:3</nowiki></code> (frequenza relativa, 1-100, default 1),
<code><nowiki>dealer:opener</nowiki></code>, <code><nowiki>vul:none|us|them|both</nowiki></code> (<code><nowiki>us</nowiki></code> = apertore+rispondente),
<code><nowiki>auction:1SA,P,2C,P</nowiki></code> (licite, notazione BridgeCards; SA = NT), <code><nowiki>contract:4H</nowiki></code>,
<code><nowiki>declarer:responder</nowiki></code>, <code><nowiki>lead:SK</nowiki></code>.
JSON: <code><nowiki>weight</nowiki></code> (int) e <code><nowiki>context: {"dealer":..,"vul":..,"auction":[..],"contract":"4H","declarer":..,"lead":"SK"}</nowiki></code>.
Il motore deve usare <code><nowiki>dealer</nowiki></code>/<code><nowiki>vul</nowiki></code> quando li espone (per la numerazione del tavolo) e,
se c'è <code><nowiki>lead</nowiki></code>, la carta deve stare nella mano dell'attaccante (a sinistra del
dichiarante) e rispettare i vincoli di quella mano.

=== Tag <code><nowiki>requires</nowiki></code> ===

<code><nowiki>suit_cards</nowiki></code>, <code><nowiki>suit_patterns</nowiki></code>, <code><nowiki>vars</nowiki></code>, <code><nowiki>stoppers</nowiki></code>, <code><nowiki>card_presence</nowiki></code> (has/lacks),
<code><nowiki>controls</nowiki></code> (aces/kings/queens/controls/kc), <code><nowiki>points</nowiki></code> (tp/dp/ltc), <code><nowiki>pair_points</nowiki></code>,
<code><nowiki>compare</nowiki></code> (confronti, longest), <code><nowiki>shape_pattern</nowiki></code>, <code><nowiki>any_not</nowiki></code>, <code><nowiki>context</nowiki></code>, <code><nowiki>weight</nowiki></code>.
Le macro <code><nowiki>@</nowiki></code> e <code><nowiki>quiet</nowiki></code> non compaiono: sono già espanse.

=== Avvisi di parsing (<code><nowiki>warnings</nowiki></code>) ===

<code><nowiki>get</nowiki></code> e <code><nowiki>validate</nowiki></code> restituiscono <code><nowiki>warnings</nowiki></code> quando un frammento del DSL non è stato
capito e quindi '''scartato''' (nome di posizione sbagliato, token fuori posto). Un
motore non deve generare se ci sono <code><nowiki>warnings</nowiki></code> o <code><nowiki>errors</nowiki></code>.

----

== Struttura JSON di uno scenario ==

<syntaxhighlight lang="typescript">
interface Scenario {
label: string; // Etichetta (es. "1H-4C"), vuota se non specificata
positions: {
[posName: string]: Position; // "opener", "responder", "opp1", "opp2"
};
fit: FitConstraint[]; // Vincoli di fit (array, può essere vuoto)
}

interface Position {
suit_patterns?: { // Pattern regex-like normalizzati: {"S":[{"cards":"AKQ","low_min":1,"low_max":1}]}
[suit: string]: { cards: string; low_min: number; low_max: number | null }[];
};
suit_cards?: { [suit: string]: string }; // Onori esatti, es. {"S":"KJT"}; "" = nessuna carta alta
suits?: { // Vincoli lunghezza seme (solo semi esplicitati)
[suit: string]: Range; // "S", "H", "D", "C"
};
hcp?: Range; // HCP totali
suit_hcp?: { // HCP per seme specifico
[suit: string]: Range;
};
x?: Range; // Lunghezza seme wildcard
x_hcp?: Range; // HCP seme wildcard
shape?: string; // Shape class: "balanced", "one_suiter", etc.
}

interface Range {
min: number;
max: number | null; // null = nessun limite superiore
}

interface FitConstraint {
suit: string | null; // "S","H","D","C" o null
suit_class: string | null; // "major", "minor" o null
min: number; // Numero minimo di carte (es. 8)
pair: string; // "declarer" o "defense"
}
</syntaxhighlight>

----

== Logica per il generatore ==

=== Algoritmo base ===

Per ogni scenario:

# '''Scegli lo scenario''': random tra quelli disponibili, oppure lascia scegliere all'utente
# '''Risolvi wildcard''':
#* Se una posizione ha <code><nowiki>x:</nowiki></code>, scegli un seme casuale tra quelli non esplicitamente vincolati
#* <code><nowiki>xhcp:</nowiki></code> si applica allo stesso seme scelto per <code><nowiki>x:</nowiki></code>
# '''Risolvi fit''':
#* Se <code><nowiki>fit.suit</nowiki></code> è specificato, entrambi i compagni devono avere un totale >= <code><nowiki>fit.min</nowiki></code> in quel seme
#* Se <code><nowiki>fit.suit_class</nowiki></code> è "major", scegli tra H e S; se "minor", tra D e C
#* Se entrambi sono null, scegli un seme qualsiasi
#* <code><nowiki>fit.pair</nowiki></code> indica quale coppia: "declarer" (opener+responder) o "defense" (opp1+opp2)
# '''Genera le mani''':
#* Per ogni posizione, genera una mano che rispetti tutti i vincoli
#* I semi senza vincoli vengono riempiti casualmente
#* Il totale delle carte per mano deve essere esattamente 13
#* Il totale delle carte per seme (tutte e 4 le mani) deve essere esattamente 13
# '''Posizioni non menzionate''': se uno scenario non menziona <code><nowiki>opp1</nowiki></code>/<code><nowiki>opp2</nowiki></code>, distribuisci le carte rimanenti casualmente tra gli avversari

=== Priorità dei vincoli ===

# Vincoli di fit (cross-posizione) — determinano la distribuzione di base
# Vincoli di seme specifico (S:, H:, D:, C:) — limitano i singoli semi
# Vincoli wildcard (x:) — dopo aver fissato i semi specifici
# Vincoli HCP (hcp:, Shcp:, xhcp:) — filtro finale
# Shape class (shape:) — validazione della forma complessiva

=== Gestione di <code><nowiki>max: null</nowiki></code> ===

Quando <code><nowiki>max</nowiki></code> è <code><nowiki>null</nowiki></code>, non c'è limite superiore esplicito. I limiti fisici
del bridge si applicano comunque:
* Massimo 13 carte per seme (tutte e 4 le mani)
* Massimo 13 carte per mano
* Massimo 10 HCP per seme (A+K+Q+J = 4+3+2+1)
* Massimo 37 HCP per mano (raro ma teoricamente possibile con tutti gli onori)

----

== Esempi completi ==

=== Splinter (tutti gli scenari specifici) ===

DSL nel template wiki:
<syntaxhighlight lang="text">
1H-4C: opener H:5+ hcp:12-21; responder H:4+ C:0-1 Chcp:0 hcp:10-15 //
1H-4D: opener H:5+ hcp:12-21; responder H:4+ D:0-1 Dhcp:0 hcp:10-15 //
1H-4S: opener H:5+ hcp:12-21; responder H:4+ S:0-1 Shcp:0 hcp:10-15 //
1S-4C: opener S:5+ hcp:12-21; responder S:4+ C:0-1 Chcp:0 hcp:10-15 //
1S-4D: opener S:5+ hcp:12-21; responder S:4+ D:0-1 Dhcp:0 hcp:10-15 //
1S-4H: opener S:5+ hcp:12-21; responder S:4+ H:0-1 Hhcp:0 hcp:10-15
</syntaxhighlight>

=== Splinter (compatto con fit e wildcard) ===

<syntaxhighlight lang="text">
dopo 1H: fit:H8+ opener H:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15 //
dopo 1S: fit:S8+ opener S:5+ hcp:12-21; responder x:0-1 xhcp:0 hcp:10-15
</syntaxhighlight>

=== Stayman ===

<syntaxhighlight lang="text">
fit a cuori: fit:H8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder H:4+ hcp:8+ //
fit a picche: fit:S8+ opener hcp:15-17 S:2-4 H:2-4 D:2-5 C:2-5; responder S:4+ hcp:8+
</syntaxhighlight>

=== Contro informativo ===

<syntaxhighlight lang="text">
base: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; responder hcp:0-8 //
con intervento: opener hcp:12-21 x:5+; opp1 hcp:12+ S:3+ H:3+ D:3+ C:3+; opp2 hcp:8+ x:5+
</syntaxhighlight>

=== Preempt 3-a-livello ===

<syntaxhighlight lang="text">
opener H:7+ x:0-1 hcp:5-10
</syntaxhighlight>

=== Overcall con fit avversari ===

<syntaxhighlight lang="text">
overcall semplice: opener hcp:12-21 x:5+; opp1 hcp:10+ x:5+; opp2 fit:8+ //
con barrage: opener hcp:12-21 x:5+; opp1 hcp:6-10 x:6+; opp2 fit:9+
</syntaxhighlight>

----

== Note implementative ==

* L'API è read-only, non richiede token CSRF
* L'accesso anonimo è abilitato di default (<code><nowiki>BridgeShapeAllowAnonymous: true</nowiki></code>) perché i dati sono pubblici e i tool esterni ne hanno bisogno
* Il campo <code><nowiki>raw</nowiki></code> nella risposta <code><nowiki>get</nowiki></code> contiene la stringa DSL originale, utile per debug
* L'azione <code><nowiki>validate</nowiki></code> permette di testare stringhe DSL senza creare pagine wiki
* I calcoli HCP usano la scala standard: A=4, K=3, Q=2, J=1

[[Categoria:Documentazione tecnica]]

Segnale di Smith

2026-10-22T05:20:36Z

Lpala: shape_roles: nomi dei ruoli negli scenari

{{Convenzione
|nome=Segnale di Smith
|tipologia=Segnale / difesa
|scopo=Dare al compagno, con la prima carta libera giocata contro un contratto a senza atout, un'informazione sul gradimento del colore d'attacco: una carta "inutilmente alta" dice che nel colore d'attacco si ha più di quanto si è potuto mostrare (gradimento a scoppio ritardato), la carta più piccola dice che non si gradisce l'attacco o che non si ha più di quanto già mostrato
|trigger=Esclusivamente contro contratti a senza atout (SA), riguarda solo la prima presa della smazzata. È a disposizione di entrambi i difensori (sia dell'attaccante sia del terzo di mano): vale la prima carta libera giocata da un difensore dopo l'attacco, quando l'avversario muove un suo colore. È una convenzione di coppia che va concordata e poi giocata sempre
|risposte=Smith positiva (gradimento): prima carta libera "inutilmente alta" (non presumibilmente la più piccola) = nel colore d'attacco ho più di quanto ho potuto mostrare. Smith negativa: prima carta libera la più piccola = non gradisco l'attacco o non ho più di quanto già mostrato. Se alla prima mossa dell'avversario il difensore è costretto a giocare una carta per economia di gioco, non può segnalare e la Smith slitta alla giocata successiva. Per l'attaccante la Smith positiva dice che il colore è praticamente affrancato (tornare in quel colore), la negativa che è meglio cercare di sfondare altrove
|note=Si applica solo contro SA e non si protrae durante la smazzata. Positiva, negativa e di gradimento sono parti della stessa convenzione. Pericolo: dimenticarsene; se si è d'accordo di giocarla va giocata sempre, senza fare economie sulla carta alta (con 854 per un gradimento si mette l'8). Fonte: Marina Causa, Corso Preagonistica 2026
|tag_cc=signal_smith
|tag_sistema=naturale
|shape_constraints = Attacco picche sequenza KJ10: opener S:5-6 S=KJT hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche sequenza KT9: opener S:5-6 S=KT9 hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche sequenza QT9: opener S:5-6 S=QT9 hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche K sotto onore: opener S:4-5 S=K hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche Q sotto onore: opener S:4-5 S=Q hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori sequenza KJ10: opener H:5-6 H=KJT hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori sequenza KT9: opener H:5-6 H=KT9 hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori sequenza QT9: opener H:5-6 H=QT9 hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori K sotto onore: opener H:4-5 H=K hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori Q sotto onore: opener H:4-5 H=Q hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri sequenza KJ10: opener D:5-6 D=KJT hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri sequenza KT9: opener D:5-6 D=KT9 hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri sequenza QT9: opener D:5-6 D=QT9 hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri K sotto onore: opener D:4-5 D=K hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri Q sotto onore: opener D:4-5 D=Q hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori sequenza KJ10: opener C:5-6 C=KJT hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori sequenza KT9: opener C:5-6 C=KT9 hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori sequenza QT9: opener C:5-6 C=QT9 hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori K sotto onore: opener C:4-5 C=K hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori Q sotto onore: opener C:4-5 C=Q hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17
|shape_roles = opener=Attaccante;responder=Compagno dell'attaccante;opp1=Morto;opp2=Dichiarante

|cc_text_default=Segnale di Smith (prima carta libera contro SA)
|cc_text_default_en=Smith Signal (first free card against notrump)
|cc_text_signal_smith=Smith: carta alta alla prima carta libera = gradisce seme d'attacco
|cc_text_signal_smith_en=Smith: high on first free card = likes opening lead suit
}}

Il '''segnale di Smith''' è un segnale difensivo che si applica '''solo contro contratti a senza atout (SA)''' ed è a disposizione di entrambi i difensori. Dopo l'attacco, la '''prima carta libera''' giocata da un difensore parla del '''gradimento del colore d'attacco''': se è "inutilmente alta", quel difensore sta dicendo che nel colore d'attacco '''ha più di quanto ha potuto mostrare'''. È un "gradimento a scoppio ritardato del colore di attacco".

== Funzionamento ==

Il segnale di Smith si applica esclusivamente contro SA:

* Lo possono dare '''entrambi i difensori''': sia l'attaccante sia il terzo di mano.
* Vale la '''prima carta libera''' giocata da un difensore: alla prima occasione, quando l'avversario muove un suo colore, il difensore che gioca inutilmente una carta alta (non presumibilmente la più piccola) segnala la Smith di gradimento; se gioca la più piccola mostra di non gradire l'attacco (o di non avere più di quanto già mostrato).
* Il segnale riguarda il '''colore d'attacco originale''' (non il colore su cui si gioca).
* Se nella prima mossa dell'avversario un difensore è costretto a giocare una carta per economia di gioco, non può segnalare nulla e la Smith slitta alla giocata successiva.
* La Smith '''non si protrae durante la smazzata''': riguarda solo la prima presa di un contratto a senza.

=== Termini ===

* '''Carta libera''': carta scelta liberamente, quando non si è impegnati a fare la presa o a giocare una carta precisa per economia di gioco.
* '''"Più di quanto ha potuto mostrare"''': ferma restando la grammatica della presa ben conosciuta (e che il terzo di mano sappia che carta giocare quando ha due o più carte equivalenti), significa possedere una carta importantissima per il compagno, né promessa né esclusa nella prima presa.

=== Versioni ===

La fonte descrive la Smith con la carta alta come gradimento. Nella versione precedente di questa pagina era citata anche una versione "rovescia" (carta bassa = gradimento, carta alta = nessun gradimento, indicata come più comune in agonistico): la fonte non la tratta e non ne descrive differenze, per cui non ha una pagina propria.

{| class="wikitable"
! Versione !! Carta alta !! Carta bassa
|-
| '''Standard (descritta nella fonte)''' || Gradimento per l'attacco || Nessun gradimento
|-
| '''Rovescia''' (citata in precedenza, non nella fonte) || Nessun gradimento || Gradimento per l'attacco
|}

== Perché è utile ==

Il segnale di Smith risolve un problema comune: l'attaccante ha scelto un colore d'attacco ma non sa se continuarlo, perché la sua carta (o quella del compagno) non basta a decidere. Il compagno può comunicare in ritardo il proprio gradimento per quel colore, anche quando l'occasione non si presenta subito.

Esempio motivante: contro 3SA si attacca il 2 di {{picche}}.

<bidding dealer="S">1SA P 3SA P P P</bidding>

Ovest e il morto:

<hand position="W">A10862.Q42.K2.1063</hand>

<hand position="N">97.A105.J10543.KJ2</hand>

Ovest non sa se Est ha messo il fante da QJ o da J solo: basta essere d'accordo e giocare la Smith.

== La Smith dell'attaccante ==

Quando l'attacco è ambiguo per il compagno, l'attaccante può chiarire con la Smith.

* '''Attacco di piccola''': a volte da Qxxxx (e si vorrebbe che il compagno non perdesse tempo a ritornare), altre da AKxxx o AJxxxx (e se il compagno non ritorna è un infarto). Smith '''positiva''' (carta alta) quando il colore è praticamente affrancato; '''negativa''' quando si vuol comunicare che sarebbe meglio cercare di sfondare altrove. Esempi di figura (Ovest / Est / morto / Sud): Q9753 / J62 / 84 / AK10 (colore non pronto: cercare altrove); AQ953 / J62 / 84 / K107 (diverso).
* '''Attacco di fante o di 10''': ambiguo (J108xx contro AJ10xx). Ovest AJ1083, Est 962, morto 74, Sud KQ5: Est deve sapere se Ovest ha 4 prese.
* '''Attacchi da doppio onore o anomali da forchetta''' (per esempio la Dama da AQJxx; oppure A Q 10 6 4 di {{fiori}} dopo che il giocante ha preso in mano con il fante e sappiamo che ha K J): si dice al compagno che deve assolutamente tornare in quel colore giocando una carta ALTA alla prima carta libera. Se si è deciso di regalare un Re per affrancare una lunga (per esempio A Q J 10 4 di {{fiori}}), alla prima occasione si fa una Smith inequivocabile per ordinare al compagno di tornare.

== La Smith del terzo di mano ==

Le situazioni sono ancora più ambigue per l'attaccante. Il terzo di mano segnala tutte le volte che:

# '''ha impegnato il più basso di due onori contigui''': Ovest A10753, morto 84, Est QJ2, Sud K96. Dopo 3, 4, J, K Ovest non sa cosa fare; Est deve segnalare la Dama: nella prossima presa farà Smith.
# '''ha filato con l'asso per conservare il controllo su un onore del morto''': Ovest J1093, morto K42, Est A86, Sud Q75. Dopo J, 2, 6, Q Ovest non ha la situazione chiara; Est alla prima occasione spiega che l'attacco gli è piaciuto.
# '''ha impegnato la più alta di due carte non contigue''': Ovest Q10532, morto 864, Est KJ7, Sud A9. Est DEVE giocare il Re e mai il fante; il fante che possiede è carta importantissima per Ovest; con la Smith Est dice "nel colore d'attacco ho più di quanto mi hai visto".
# '''eccezionalmente''', con un numero imprevedibilmente alto di carte nel colore, sapendo che il restante onore è in mano al giocante ma secco, per comunicare all'attaccante la possibilità di incassarsi l'asso: Ovest A952, morto QJ, Est 108763, Sud K4. Giocate 2, J, 8, 4, Est (presupponendo attacco da onore quarto) è quasi certo che Sud sia singolo: appena possibile fa Smith positiva, che Ovest interpreterà come grande lunghezza e quindi tirerà l'asso.

== Il pericolo della Smith ==

Il pericolo è uno solo: dimenticarsene. Se si è d'accordo di giocarla, bisogna giocarla '''sempre'''. Per esempio, attaccato da AKxxx, se sul primo colore mosso dal giocante vi scappa un due, il compagno non tornerà più nel colore (è quanto gli avete chiesto di fare). Non fate economie sulla carta alta: se dovete fare Smith di gradimento con 854 mettete l'8.

== Esempi ==

Otto mani dalla dispensa. Contratto 3SA giocato da Sud; la licita è omessa (non leggibile nella fonte). La fonte indica le carte piccole con "x": qui sono rese con carte basse scelte arbitrariamente per rispettare il formato, senza alcun significato; le carte indicate esplicitamente sono quelle della fonte.

Per la generazione delle smazzate, nei vincoli le posizioni sono: `opener` = chi attacca, `responder` = il suo compagno, `opp1` = il morto, `opp2` = il dichiarante; i tipi di attacco (sequenza interrotta KJ10, interna KT9, QT9, sotto onore K o Q) sono un'indicazione della redazione di BridgePedia, non tratti dalla dispensa.

=== Mano 1 (attacco 2{{picche}}) ===

<deal>
N: AK105.AQ102.J103.J2
E: J9432.J43.A4.AQ3
S: 76.K5.KQ9765.654
W: Q8.9876.82.K10987
</deal>

Piccola dal morto, Dama di Ovest, asso di Nord; fante di {{quadri}} di Nord, Est liscia, Ovest fornisce il 2 e poi l'8: è una Smith negativa (non ha nulla a {{picche}} oltre l'onore già giocato). Est ricostruisce dall'apertura di 1SA la mano di Nord.

=== Mano 2 (attacco 3{{fiori}}) ===

<deal>
N: 10982.K432.A2.1032
E: AQ3.J105.Q1043.AKJ
S: KJ54.76.65.Q9654
W: 76.AQ98.KJ987.87
</deal>

Sud sa che Est ci prende ancora due volte e che il down va cercato altrove; per dissuadere Nord dal tornare a {{fiori}} fornisce la sua carta più piccola a {{quadri}} o a {{cuori}} a seconda del colore che muoverà Est. Nord prova con successo a sfondare a {{picche}}.

=== Mano 3 (attacco piccola di {{cuori}}) ===

<deal>
N: 432.432.AQ32.AKQ
E: AJ105.105.J104.8654
S: KQ76.KQ6.K976.J10
W: 98.AJ987.85.9732
</deal>

Ovest deve fornire la più grossa carta possibile per impedire che Sud (che muove {{picche}}) si trasferisca al morto; Est non deve precipitarsi a prendere.

=== Mano 4 (attacco piccola di {{picche}}) ===

<deal>
N: KJ932.KJ2.432.32
E: 54.43.AJ1065.KJ54
S: 106.A8765.K7.876
W: AQ7.Q109.Q98.AQ109
</deal>

Nord, dopo la prima presa, fa Smith negativa: non ha altro oltre quanto detto con l'attacco di piccola; il ritorno a {{cuori}} batte. Con A J di {{picche}} (variante della mano) Nord farebbe Smith positiva: "se torni a {{picche}} sono tutte mie".

Nota: nella fonte la mano di Sud risulta di 12 carte (le {{picche}} sono 12 in totale invece di 13); è riportata come trascritta, senza correzione.

=== Mano 5 (attacco 6{{cuori}}) ===

<deal>
N: 432.432.J2.AKJ109
E: KJ5.K10975.A43.74
S: AQ76.AJ.KQ65.Q63
W: 1098.Q86.10987.852
</deal>

Ovest deve far capire a Est che le {{cuori}} sono tutt'altro (Smith negativa). Sud cerca la nona presa giocando {{fiori}} al morto e il fante di {{quadri}}; Est non deve dormire: precipitarsi con l'asso e tornare {{cuori}}.

=== Mano 6 (attacco 3{{quadri}}) ===

<deal>
N: K432.J102.104.AQ32
E: Q1065.95.KJ9.J1094
S: A87.AQ43.A82.K65
W: J9.K876.Q7653.87
</deal>

Re di {{quadri}} di Est, asso di Sud; Est segnala il fante di {{quadri}} con Smith positiva ("nel colore d'attacco ho più di quanto mi hai visto"). Ovest, in presa a {{cuori}}, segue con la piccola di {{quadri}} e deve fidarsi: se incassa la Dama blocca il colore e regala 3SA.

=== Mano 7 (attacco 2{{picche}}) ===

<deal>
N: 65.96.AJ1054.Q653
E: 1084.A8732.K8.984
S: AQ7.Q104.Q76.AKJ10
W: KJ932.KJ5.932.72
</deal>

Ovest attacca il 2 di {{picche}} e vede il 10 e la Dama di Sud; Est deve fare Smith negativa lasciando che Est scelga liberamente (la Smith negativa dell'attaccante non significa "non voglio che torni": lascia aperte le altre strade; la positiva vincola al colore iniziale).

Nota: il testo della fonte presenta una svista nei ruoli Est/Ovest (la frase "Est deve fare Smith negativa lasciando che Est scelga" è riportata fedelmente).

=== Mano 8 (attacco 6{{picche}}) ===

<deal>
N: 842.652.KJ96.QJ10
E: AK1093.1093.872.82
S: QJ7.AQ.AQ105.A976
W: 65.KJ874.43.K543
</deal>

Est deve lisciare il primo giro (senza ingressi); Sud prende e si trasferisce al morto a {{quadri}} (impasse a {{fiori}}). Ovest deve stare attento alla {{quadri}} giocata da Est: si deve dare l'8, che ribadisce le {{picche}}.

== Varianti ==

La fonte non descrive varianti del segnale di Smith: Smith positiva, negativa e di gradimento sono parti della stessa convenzione. Una versione "rovescia" era citata nella precedente versione della pagina, ma non risulta nella fonte e non ha pagina propria.

== Vedi anche ==

* [[Gradimento_naturale|Gradimento naturale]]
* [[Gradimento_rovescio|Gradimento rovescio]]
* [[Segnale_di_conteggio|Segnale di conteggio]]
* [[Segnale_di_preferenza|Segnale di preferenza]]

== Fonti ==

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "02. La 'Smith': un aiuto nel controgioco a Senza" (PDF, 6 pagine).

[[Categoria:Difesa]]
[[Categoria:Segnali difensivi]]
[[Categoria:Gioco a senza atout]]

Template:Convenzione

2026-10-22T05:20:35Z

Lpala: Mostra gli scenari shape_constraints in forma leggibile (BridgeShape)

<noinclude>
Questo è il template base per le pagine delle convenzioni. Uso:
<nowiki>{{Convenzione
|nome=Stayman
|tipologia=Apertura / Intervento / Supporto
|scopo=Ricerca 4° nobile dopo 1NT
|trigger=Quando il compagno ha dichiarato 1NT
|risposte=2♦=no 4° nobile; 2♥/2♠=mostra 4 carte nel seme
|note=Varianti: 4° maggiori, 5-4 Stayman, ecc.
|tag_cc=response_stayman,opening_1nt
|tag_sistema=naturale
|cc_text_default=Stayman
|cc_text_response_1nt=2♣ Stayman
}}</nowiki>

'''Parametri aggiuntivi (opzionali, invisibili):'''
* '''tag_cc''': Tag per Convention Card (separati da virgola). Usati dall'estensione BridgeCC per suggerire convenzioni. Es: opening_1nt, response_stayman, slam_rkcb
* '''tag_sistema''': Tag del sistema. Valori: naturale, quinta_nobile, precision, 2over1, forcing_club
* '''cc_text_default''': Testo predefinito da inserire nelle Convention Card quando si seleziona questa convenzione. Se non specificato, viene usato il nome della pagina.
* '''cc_text_<codice_sezione>''': Testo specifico per una sezione della CC (es: cc_text_response_1nt, cc_text_opening_1c). Ha priorità su cc_text_default.

'''Parametri per tabella attacchi (opzionali):'''
* '''lead_holding_N''': Riga N della tabella attacchi. Formato: <code>Possesso;vs Atout;vs SA;Comp.</code> (separatore punto e virgola). Esempio: <code>lead_holding_1=AKx;A;A;A</code>
</noinclude>

<includeonly>{{DaVerificare}}
{| class="wikitable" style="width:100%"
|-
! style="width:18%" | {{#switch:{{PAGELANGUAGE}}|en=Name|fr=Nom|es=Nombre|de=Name|#default=Nome}}
| {{{nome|{{PAGENAME}}}}}
|-
! {{#switch:{{PAGELANGUAGE}}|en=Type|fr=Type|es=Tipo|de=Typ|#default=Tipologia}}
| {{{tipologia|}}}
|-
! {{#switch:{{PAGELANGUAGE}}|en=Purpose|fr=But|es=Propósito|de=Zweck|#default=Scopo}}
| {{{scopo|}}}
|-
! {{#switch:{{PAGELANGUAGE}}|en=Trigger (when to use)|fr=Déclencheur (quand l’utiliser)|es=Desencadenante (cuándo se usa)|de=Auslöser (wann man es einsetzt)|#default=Trigger (quando si usa)}}
| {{{trigger|}}}
|-
! {{#switch:{{PAGELANGUAGE}}|en=Responses / developments|fr=Réponses / développements|es=Respuestas / desarrollos|de=Antworten / Fortsetzungen|#default=Risposte / sviluppi}}
| {{{risposte|}}}
|-
! {{#switch:{{PAGELANGUAGE}}|en=Notes|fr=Notes|es=Notas|de=Hinweise|#default=Note}}
| {{{note|}}}
|}

{{#if: {{{lead_holding_1|}}} |
=== {{#switch:{{PAGELANGUAGE}}|en=Leads table|fr=Tableau des entames|es=Tabla de salidas|de=Ausspieltabelle|#default=Tabella attacchi}} ===
{{#invoke:StileAttacco|tabella}}
}}
{{#if: {{{shape_constraints|}}} | {{#shapescenari: {{{shape_constraints}}} | {{{shape_roles|}}} }} }}

{{#switch: {{{tipologia|}}}
| Apertura = [[Categoria:Convenzioni di apertura]]
| Intervento = [[Categoria:Convenzioni di intervento]]
| Supporto = [[Categoria:Convenzioni di supporto]]
}}

[[Categoria:Convenzioni]]

{{#if: {{{nome|}}} | {{DEFAULTSORT:{{{nome}}}}} }}

{{#if: {{{tag_cc|}}} | <span class="bridgecc-tag-cc" style="display:none;">{{{tag_cc|}}}</span> }}
{{#if: {{{tag_sistema|}}} | <span class="bridgecc-tag-sistema" style="display:none;">{{{tag_sistema|}}}</span> }}
{{BridgeRAG|tipo=convenzione}}
</includeonly>

Segnale di Smith

2026-10-21T18:49:41Z

Lpala: shape_constraints: KT9 e QT9 con il 9 garantito

{{Convenzione
|nome=Segnale di Smith
|tipologia=Segnale / difesa
|scopo=Dare al compagno, con la prima carta libera giocata contro un contratto a senza atout, un'informazione sul gradimento del colore d'attacco: una carta "inutilmente alta" dice che nel colore d'attacco si ha più di quanto si è potuto mostrare (gradimento a scoppio ritardato), la carta più piccola dice che non si gradisce l'attacco o che non si ha più di quanto già mostrato
|trigger=Esclusivamente contro contratti a senza atout (SA), riguarda solo la prima presa della smazzata. È a disposizione di entrambi i difensori (sia dell'attaccante sia del terzo di mano): vale la prima carta libera giocata da un difensore dopo l'attacco, quando l'avversario muove un suo colore. È una convenzione di coppia che va concordata e poi giocata sempre
|risposte=Smith positiva (gradimento): prima carta libera "inutilmente alta" (non presumibilmente la più piccola) = nel colore d'attacco ho più di quanto ho potuto mostrare. Smith negativa: prima carta libera la più piccola = non gradisco l'attacco o non ho più di quanto già mostrato. Se alla prima mossa dell'avversario il difensore è costretto a giocare una carta per economia di gioco, non può segnalare e la Smith slitta alla giocata successiva. Per l'attaccante la Smith positiva dice che il colore è praticamente affrancato (tornare in quel colore), la negativa che è meglio cercare di sfondare altrove
|note=Si applica solo contro SA e non si protrae durante la smazzata. Positiva, negativa e di gradimento sono parti della stessa convenzione. Pericolo: dimenticarsene; se si è d'accordo di giocarla va giocata sempre, senza fare economie sulla carta alta (con 854 per un gradimento si mette l'8). Fonte: Marina Causa, Corso Preagonistica 2026
|tag_cc=signal_smith
|tag_sistema=naturale
|shape_constraints = Attacco picche sequenza KJ10: opener S:5-6 S=KJT hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche sequenza KT9: opener S:5-6 S=KT9 hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche sequenza QT9: opener S:5-6 S=QT9 hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche K sotto onore: opener S:4-5 S=K hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco picche Q sotto onore: opener S:4-5 S=Q hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori sequenza KJ10: opener H:5-6 H=KJT hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori sequenza KT9: opener H:5-6 H=KT9 hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori sequenza QT9: opener H:5-6 H=QT9 hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori K sotto onore: opener H:4-5 H=K hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco cuori Q sotto onore: opener H:4-5 H=Q hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri sequenza KJ10: opener D:5-6 D=KJT hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri sequenza KT9: opener D:5-6 D=KT9 hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri sequenza QT9: opener D:5-6 D=QT9 hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri K sotto onore: opener D:4-5 D=K hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco quadri Q sotto onore: opener D:4-5 D=Q hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori sequenza KJ10: opener C:5-6 C=KJT hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori sequenza KT9: opener C:5-6 C=KT9 hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori sequenza QT9: opener C:5-6 C=QT9 hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori K sotto onore: opener C:4-5 C=K hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // // Attacco fiori Q sotto onore: opener C:4-5 C=Q hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17

|cc_text_default=Segnale di Smith (prima carta libera contro SA)
|cc_text_default_en=Smith Signal (first free card against notrump)
|cc_text_signal_smith=Smith: carta alta alla prima carta libera = gradisce seme d'attacco
|cc_text_signal_smith_en=Smith: high on first free card = likes opening lead suit
}}

Il '''segnale di Smith''' è un segnale difensivo che si applica '''solo contro contratti a senza atout (SA)''' ed è a disposizione di entrambi i difensori. Dopo l'attacco, la '''prima carta libera''' giocata da un difensore parla del '''gradimento del colore d'attacco''': se è "inutilmente alta", quel difensore sta dicendo che nel colore d'attacco '''ha più di quanto ha potuto mostrare'''. È un "gradimento a scoppio ritardato del colore di attacco".

== Funzionamento ==

Il segnale di Smith si applica esclusivamente contro SA:

* Lo possono dare '''entrambi i difensori''': sia l'attaccante sia il terzo di mano.
* Vale la '''prima carta libera''' giocata da un difensore: alla prima occasione, quando l'avversario muove un suo colore, il difensore che gioca inutilmente una carta alta (non presumibilmente la più piccola) segnala la Smith di gradimento; se gioca la più piccola mostra di non gradire l'attacco (o di non avere più di quanto già mostrato).
* Il segnale riguarda il '''colore d'attacco originale''' (non il colore su cui si gioca).
* Se nella prima mossa dell'avversario un difensore è costretto a giocare una carta per economia di gioco, non può segnalare nulla e la Smith slitta alla giocata successiva.
* La Smith '''non si protrae durante la smazzata''': riguarda solo la prima presa di un contratto a senza.

=== Termini ===

* '''Carta libera''': carta scelta liberamente, quando non si è impegnati a fare la presa o a giocare una carta precisa per economia di gioco.
* '''"Più di quanto ha potuto mostrare"''': ferma restando la grammatica della presa ben conosciuta (e che il terzo di mano sappia che carta giocare quando ha due o più carte equivalenti), significa possedere una carta importantissima per il compagno, né promessa né esclusa nella prima presa.

=== Versioni ===

La fonte descrive la Smith con la carta alta come gradimento. Nella versione precedente di questa pagina era citata anche una versione "rovescia" (carta bassa = gradimento, carta alta = nessun gradimento, indicata come più comune in agonistico): la fonte non la tratta e non ne descrive differenze, per cui non ha una pagina propria.

{| class="wikitable"
! Versione !! Carta alta !! Carta bassa
|-
| '''Standard (descritta nella fonte)''' || Gradimento per l'attacco || Nessun gradimento
|-
| '''Rovescia''' (citata in precedenza, non nella fonte) || Nessun gradimento || Gradimento per l'attacco
|}

== Perché è utile ==

Il segnale di Smith risolve un problema comune: l'attaccante ha scelto un colore d'attacco ma non sa se continuarlo, perché la sua carta (o quella del compagno) non basta a decidere. Il compagno può comunicare in ritardo il proprio gradimento per quel colore, anche quando l'occasione non si presenta subito.

Esempio motivante: contro 3SA si attacca il 2 di {{picche}}.

<bidding dealer="S">1SA P 3SA P P P</bidding>

Ovest e il morto:

<hand position="W">A10862.Q42.K2.1063</hand>

<hand position="N">97.A105.J10543.KJ2</hand>

Ovest non sa se Est ha messo il fante da QJ o da J solo: basta essere d'accordo e giocare la Smith.

== La Smith dell'attaccante ==

Quando l'attacco è ambiguo per il compagno, l'attaccante può chiarire con la Smith.

* '''Attacco di piccola''': a volte da Qxxxx (e si vorrebbe che il compagno non perdesse tempo a ritornare), altre da AKxxx o AJxxxx (e se il compagno non ritorna è un infarto). Smith '''positiva''' (carta alta) quando il colore è praticamente affrancato; '''negativa''' quando si vuol comunicare che sarebbe meglio cercare di sfondare altrove. Esempi di figura (Ovest / Est / morto / Sud): Q9753 / J62 / 84 / AK10 (colore non pronto: cercare altrove); AQ953 / J62 / 84 / K107 (diverso).
* '''Attacco di fante o di 10''': ambiguo (J108xx contro AJ10xx). Ovest AJ1083, Est 962, morto 74, Sud KQ5: Est deve sapere se Ovest ha 4 prese.
* '''Attacchi da doppio onore o anomali da forchetta''' (per esempio la Dama da AQJxx; oppure A Q 10 6 4 di {{fiori}} dopo che il giocante ha preso in mano con il fante e sappiamo che ha K J): si dice al compagno che deve assolutamente tornare in quel colore giocando una carta ALTA alla prima carta libera. Se si è deciso di regalare un Re per affrancare una lunga (per esempio A Q J 10 4 di {{fiori}}), alla prima occasione si fa una Smith inequivocabile per ordinare al compagno di tornare.

== La Smith del terzo di mano ==

Le situazioni sono ancora più ambigue per l'attaccante. Il terzo di mano segnala tutte le volte che:

# '''ha impegnato il più basso di due onori contigui''': Ovest A10753, morto 84, Est QJ2, Sud K96. Dopo 3, 4, J, K Ovest non sa cosa fare; Est deve segnalare la Dama: nella prossima presa farà Smith.
# '''ha filato con l'asso per conservare il controllo su un onore del morto''': Ovest J1093, morto K42, Est A86, Sud Q75. Dopo J, 2, 6, Q Ovest non ha la situazione chiara; Est alla prima occasione spiega che l'attacco gli è piaciuto.
# '''ha impegnato la più alta di due carte non contigue''': Ovest Q10532, morto 864, Est KJ7, Sud A9. Est DEVE giocare il Re e mai il fante; il fante che possiede è carta importantissima per Ovest; con la Smith Est dice "nel colore d'attacco ho più di quanto mi hai visto".
# '''eccezionalmente''', con un numero imprevedibilmente alto di carte nel colore, sapendo che il restante onore è in mano al giocante ma secco, per comunicare all'attaccante la possibilità di incassarsi l'asso: Ovest A952, morto QJ, Est 108763, Sud K4. Giocate 2, J, 8, 4, Est (presupponendo attacco da onore quarto) è quasi certo che Sud sia singolo: appena possibile fa Smith positiva, che Ovest interpreterà come grande lunghezza e quindi tirerà l'asso.

== Il pericolo della Smith ==

Il pericolo è uno solo: dimenticarsene. Se si è d'accordo di giocarla, bisogna giocarla '''sempre'''. Per esempio, attaccato da AKxxx, se sul primo colore mosso dal giocante vi scappa un due, il compagno non tornerà più nel colore (è quanto gli avete chiesto di fare). Non fate economie sulla carta alta: se dovete fare Smith di gradimento con 854 mettete l'8.

== Esempi ==

Otto mani dalla dispensa. Contratto 3SA giocato da Sud; la licita è omessa (non leggibile nella fonte). La fonte indica le carte piccole con "x": qui sono rese con carte basse scelte arbitrariamente per rispettare il formato, senza alcun significato; le carte indicate esplicitamente sono quelle della fonte.

Per la generazione delle smazzate, nei vincoli le posizioni sono: `opener` = chi attacca, `responder` = il suo compagno, `opp1` = il morto, `opp2` = il dichiarante; i tipi di attacco (sequenza interrotta KJ10, interna KT9, QT9, sotto onore K o Q) sono un'indicazione della redazione di BridgePedia, non tratti dalla dispensa.

=== Mano 1 (attacco 2{{picche}}) ===

<deal>
N: AK105.AQ102.J103.J2
E: J9432.J43.A4.AQ3
S: 76.K5.KQ9765.654
W: Q8.9876.82.K10987
</deal>

Piccola dal morto, Dama di Ovest, asso di Nord; fante di {{quadri}} di Nord, Est liscia, Ovest fornisce il 2 e poi l'8: è una Smith negativa (non ha nulla a {{picche}} oltre l'onore già giocato). Est ricostruisce dall'apertura di 1SA la mano di Nord.

=== Mano 2 (attacco 3{{fiori}}) ===

<deal>
N: 10982.K432.A2.1032
E: AQ3.J105.Q1043.AKJ
S: KJ54.76.65.Q9654
W: 76.AQ98.KJ987.87
</deal>

Sud sa che Est ci prende ancora due volte e che il down va cercato altrove; per dissuadere Nord dal tornare a {{fiori}} fornisce la sua carta più piccola a {{quadri}} o a {{cuori}} a seconda del colore che muoverà Est. Nord prova con successo a sfondare a {{picche}}.

=== Mano 3 (attacco piccola di {{cuori}}) ===

<deal>
N: 432.432.AQ32.AKQ
E: AJ105.105.J104.8654
S: KQ76.KQ6.K976.J10
W: 98.AJ987.85.9732
</deal>

Ovest deve fornire la più grossa carta possibile per impedire che Sud (che muove {{picche}}) si trasferisca al morto; Est non deve precipitarsi a prendere.

=== Mano 4 (attacco piccola di {{picche}}) ===

<deal>
N: KJ932.KJ2.432.32
E: 54.43.AJ1065.KJ54
S: 106.A8765.K7.876
W: AQ7.Q109.Q98.AQ109
</deal>

Nord, dopo la prima presa, fa Smith negativa: non ha altro oltre quanto detto con l'attacco di piccola; il ritorno a {{cuori}} batte. Con A J di {{picche}} (variante della mano) Nord farebbe Smith positiva: "se torni a {{picche}} sono tutte mie".

Nota: nella fonte la mano di Sud risulta di 12 carte (le {{picche}} sono 12 in totale invece di 13); è riportata come trascritta, senza correzione.

=== Mano 5 (attacco 6{{cuori}}) ===

<deal>
N: 432.432.J2.AKJ109
E: KJ5.K10975.A43.74
S: AQ76.AJ.KQ65.Q63
W: 1098.Q86.10987.852
</deal>

Ovest deve far capire a Est che le {{cuori}} sono tutt'altro (Smith negativa). Sud cerca la nona presa giocando {{fiori}} al morto e il fante di {{quadri}}; Est non deve dormire: precipitarsi con l'asso e tornare {{cuori}}.

=== Mano 6 (attacco 3{{quadri}}) ===

<deal>
N: K432.J102.104.AQ32
E: Q1065.95.KJ9.J1094
S: A87.AQ43.A82.K65
W: J9.K876.Q7653.87
</deal>

Re di {{quadri}} di Est, asso di Sud; Est segnala il fante di {{quadri}} con Smith positiva ("nel colore d'attacco ho più di quanto mi hai visto"). Ovest, in presa a {{cuori}}, segue con la piccola di {{quadri}} e deve fidarsi: se incassa la Dama blocca il colore e regala 3SA.

=== Mano 7 (attacco 2{{picche}}) ===

<deal>
N: 65.96.AJ1054.Q653
E: 1084.A8732.K8.984
S: AQ7.Q104.Q76.AKJ10
W: KJ932.KJ5.932.72
</deal>

Ovest attacca il 2 di {{picche}} e vede il 10 e la Dama di Sud; Est deve fare Smith negativa lasciando che Est scelga liberamente (la Smith negativa dell'attaccante non significa "non voglio che torni": lascia aperte le altre strade; la positiva vincola al colore iniziale).

Nota: il testo della fonte presenta una svista nei ruoli Est/Ovest (la frase "Est deve fare Smith negativa lasciando che Est scelga" è riportata fedelmente).

=== Mano 8 (attacco 6{{picche}}) ===

<deal>
N: 842.652.KJ96.QJ10
E: AK1093.1093.872.82
S: QJ7.AQ.AQ105.A976
W: 65.KJ874.43.K543
</deal>

Est deve lisciare il primo giro (senza ingressi); Sud prende e si trasferisce al morto a {{quadri}} (impasse a {{fiori}}). Ovest deve stare attento alla {{quadri}} giocata da Est: si deve dare l'8, che ribadisce le {{picche}}.

== Varianti ==

La fonte non descrive varianti del segnale di Smith: Smith positiva, negativa e di gradimento sono parti della stessa convenzione. Una versione "rovescia" era citata nella precedente versione della pagina, ma non risulta nella fonte e non ha pagina propria.

== Vedi anche ==

* [[Gradimento_naturale|Gradimento naturale]]
* [[Gradimento_rovescio|Gradimento rovescio]]
* [[Segnale_di_conteggio|Segnale di conteggio]]
* [[Segnale_di_preferenza|Segnale di preferenza]]

== Fonti ==

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "02. La 'Smith': un aiuto nel controgioco a Senza" (PDF, 6 pagine).

[[Categoria:Difesa]]
[[Categoria:Segnali difensivi]]
[[Categoria:Gioco a senza atout]]

Segnale di Smith

2026-10-21T18:48:29Z

Lpala: shape_constraints: attacchi da sequenza interrotta/sotto onore

{{Convenzione
|nome=Segnale di Smith
|tipologia=Segnale / difesa
|scopo=Dare al compagno, con la prima carta libera giocata contro un contratto a senza atout, un'informazione sul gradimento del colore d'attacco: una carta "inutilmente alta" dice che nel colore d'attacco si ha più di quanto si è potuto mostrare (gradimento a scoppio ritardato), la carta più piccola dice che non si gradisce l'attacco o che non si ha più di quanto già mostrato
|trigger=Esclusivamente contro contratti a senza atout (SA), riguarda solo la prima presa della smazzata. È a disposizione di entrambi i difensori (sia dell'attaccante sia del terzo di mano): vale la prima carta libera giocata da un difensore dopo l'attacco, quando l'avversario muove un suo colore. È una convenzione di coppia che va concordata e poi giocata sempre
|risposte=Smith positiva (gradimento): prima carta libera "inutilmente alta" (non presumibilmente la più piccola) = nel colore d'attacco ho più di quanto ho potuto mostrare. Smith negativa: prima carta libera la più piccola = non gradisco l'attacco o non ho più di quanto già mostrato. Se alla prima mossa dell'avversario il difensore è costretto a giocare una carta per economia di gioco, non può segnalare e la Smith slitta alla giocata successiva. Per l'attaccante la Smith positiva dice che il colore è praticamente affrancato (tornare in quel colore), la negativa che è meglio cercare di sfondare altrove
|note=Si applica solo contro SA e non si protrae durante la smazzata. Positiva, negativa e di gradimento sono parti della stessa convenzione. Pericolo: dimenticarsene; se si è d'accordo di giocarla va giocata sempre, senza fare economie sulla carta alta (con 854 per un gradimento si mette l'8). Fonte: Marina Causa, Corso Preagonistica 2026
|tag_cc=signal_smith
|tag_sistema=naturale
|shape_constraints = Attacco picche sequenza KJ10: opener S:5-6 S=KJT hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco picche sequenza KT9: opener S:5-6 S=KT hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco picche sequenza QT9: opener S:5-6 S=QT hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco picche K sotto onore: opener S:4-5 S=K hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco picche Q sotto onore: opener S:4-5 S=Q hcp:6-9; responder S:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco cuori sequenza KJ10: opener H:5-6 H=KJT hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco cuori sequenza KT9: opener H:5-6 H=KT hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco cuori sequenza QT9: opener H:5-6 H=QT hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco cuori K sotto onore: opener H:4-5 H=K hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco cuori Q sotto onore: opener H:4-5 H=Q hcp:6-9; responder H:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco quadri sequenza KJ10: opener D:5-6 D=KJT hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco quadri sequenza KT9: opener D:5-6 D=KT hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco quadri sequenza QT9: opener D:5-6 D=QT hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco quadri K sotto onore: opener D:4-5 D=K hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco quadri Q sotto onore: opener D:4-5 D=Q hcp:6-9; responder D:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco fiori sequenza KJ10: opener C:5-6 C=KJT hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco fiori sequenza KT9: opener C:5-6 C=KT hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco fiori sequenza QT9: opener C:5-6 C=QT hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco fiori K sotto onore: opener C:4-5 C=K hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17 // Attacco fiori Q sotto onore: opener C:4-5 C=Q hcp:6-9; responder C:2-4 hcp:2-7; opp1 hcp:10-14; opp2 shape:balanced hcp:15-17

|cc_text_default=Segnale di Smith (prima carta libera contro SA)
|cc_text_default_en=Smith Signal (first free card against notrump)
|cc_text_signal_smith=Smith: carta alta alla prima carta libera = gradisce seme d'attacco
|cc_text_signal_smith_en=Smith: high on first free card = likes opening lead suit
}}

Il '''segnale di Smith''' è un segnale difensivo che si applica '''solo contro contratti a senza atout (SA)''' ed è a disposizione di entrambi i difensori. Dopo l'attacco, la '''prima carta libera''' giocata da un difensore parla del '''gradimento del colore d'attacco''': se è "inutilmente alta", quel difensore sta dicendo che nel colore d'attacco '''ha più di quanto ha potuto mostrare'''. È un "gradimento a scoppio ritardato del colore di attacco".

== Funzionamento ==

Il segnale di Smith si applica esclusivamente contro SA:

* Lo possono dare '''entrambi i difensori''': sia l'attaccante sia il terzo di mano.
* Vale la '''prima carta libera''' giocata da un difensore: alla prima occasione, quando l'avversario muove un suo colore, il difensore che gioca inutilmente una carta alta (non presumibilmente la più piccola) segnala la Smith di gradimento; se gioca la più piccola mostra di non gradire l'attacco (o di non avere più di quanto già mostrato).
* Il segnale riguarda il '''colore d'attacco originale''' (non il colore su cui si gioca).
* Se nella prima mossa dell'avversario un difensore è costretto a giocare una carta per economia di gioco, non può segnalare nulla e la Smith slitta alla giocata successiva.
* La Smith '''non si protrae durante la smazzata''': riguarda solo la prima presa di un contratto a senza.

=== Termini ===

* '''Carta libera''': carta scelta liberamente, quando non si è impegnati a fare la presa o a giocare una carta precisa per economia di gioco.
* '''"Più di quanto ha potuto mostrare"''': ferma restando la grammatica della presa ben conosciuta (e che il terzo di mano sappia che carta giocare quando ha due o più carte equivalenti), significa possedere una carta importantissima per il compagno, né promessa né esclusa nella prima presa.

=== Versioni ===

La fonte descrive la Smith con la carta alta come gradimento. Nella versione precedente di questa pagina era citata anche una versione "rovescia" (carta bassa = gradimento, carta alta = nessun gradimento, indicata come più comune in agonistico): la fonte non la tratta e non ne descrive differenze, per cui non ha una pagina propria.

{| class="wikitable"
! Versione !! Carta alta !! Carta bassa
|-
| '''Standard (descritta nella fonte)''' || Gradimento per l'attacco || Nessun gradimento
|-
| '''Rovescia''' (citata in precedenza, non nella fonte) || Nessun gradimento || Gradimento per l'attacco
|}

== Perché è utile ==

Il segnale di Smith risolve un problema comune: l'attaccante ha scelto un colore d'attacco ma non sa se continuarlo, perché la sua carta (o quella del compagno) non basta a decidere. Il compagno può comunicare in ritardo il proprio gradimento per quel colore, anche quando l'occasione non si presenta subito.

Esempio motivante: contro 3SA si attacca il 2 di {{picche}}.

<bidding dealer="S">1SA P 3SA P P P</bidding>

Ovest e il morto:

<hand position="W">A10862.Q42.K2.1063</hand>

<hand position="N">97.A105.J10543.KJ2</hand>

Ovest non sa se Est ha messo il fante da QJ o da J solo: basta essere d'accordo e giocare la Smith.

== La Smith dell'attaccante ==

Quando l'attacco è ambiguo per il compagno, l'attaccante può chiarire con la Smith.

* '''Attacco di piccola''': a volte da Qxxxx (e si vorrebbe che il compagno non perdesse tempo a ritornare), altre da AKxxx o AJxxxx (e se il compagno non ritorna è un infarto). Smith '''positiva''' (carta alta) quando il colore è praticamente affrancato; '''negativa''' quando si vuol comunicare che sarebbe meglio cercare di sfondare altrove. Esempi di figura (Ovest / Est / morto / Sud): Q9753 / J62 / 84 / AK10 (colore non pronto: cercare altrove); AQ953 / J62 / 84 / K107 (diverso).
* '''Attacco di fante o di 10''': ambiguo (J108xx contro AJ10xx). Ovest AJ1083, Est 962, morto 74, Sud KQ5: Est deve sapere se Ovest ha 4 prese.
* '''Attacchi da doppio onore o anomali da forchetta''' (per esempio la Dama da AQJxx; oppure A Q 10 6 4 di {{fiori}} dopo che il giocante ha preso in mano con il fante e sappiamo che ha K J): si dice al compagno che deve assolutamente tornare in quel colore giocando una carta ALTA alla prima carta libera. Se si è deciso di regalare un Re per affrancare una lunga (per esempio A Q J 10 4 di {{fiori}}), alla prima occasione si fa una Smith inequivocabile per ordinare al compagno di tornare.

== La Smith del terzo di mano ==

Le situazioni sono ancora più ambigue per l'attaccante. Il terzo di mano segnala tutte le volte che:

# '''ha impegnato il più basso di due onori contigui''': Ovest A10753, morto 84, Est QJ2, Sud K96. Dopo 3, 4, J, K Ovest non sa cosa fare; Est deve segnalare la Dama: nella prossima presa farà Smith.
# '''ha filato con l'asso per conservare il controllo su un onore del morto''': Ovest J1093, morto K42, Est A86, Sud Q75. Dopo J, 2, 6, Q Ovest non ha la situazione chiara; Est alla prima occasione spiega che l'attacco gli è piaciuto.
# '''ha impegnato la più alta di due carte non contigue''': Ovest Q10532, morto 864, Est KJ7, Sud A9. Est DEVE giocare il Re e mai il fante; il fante che possiede è carta importantissima per Ovest; con la Smith Est dice "nel colore d'attacco ho più di quanto mi hai visto".
# '''eccezionalmente''', con un numero imprevedibilmente alto di carte nel colore, sapendo che il restante onore è in mano al giocante ma secco, per comunicare all'attaccante la possibilità di incassarsi l'asso: Ovest A952, morto QJ, Est 108763, Sud K4. Giocate 2, J, 8, 4, Est (presupponendo attacco da onore quarto) è quasi certo che Sud sia singolo: appena possibile fa Smith positiva, che Ovest interpreterà come grande lunghezza e quindi tirerà l'asso.

== Il pericolo della Smith ==

Il pericolo è uno solo: dimenticarsene. Se si è d'accordo di giocarla, bisogna giocarla '''sempre'''. Per esempio, attaccato da AKxxx, se sul primo colore mosso dal giocante vi scappa un due, il compagno non tornerà più nel colore (è quanto gli avete chiesto di fare). Non fate economie sulla carta alta: se dovete fare Smith di gradimento con 854 mettete l'8.

== Esempi ==

Otto mani dalla dispensa. Contratto 3SA giocato da Sud; la licita è omessa (non leggibile nella fonte). La fonte indica le carte piccole con "x": qui sono rese con carte basse scelte arbitrariamente per rispettare il formato, senza alcun significato; le carte indicate esplicitamente sono quelle della fonte.

Per la generazione delle smazzate, nei vincoli le posizioni sono: `opener` = chi attacca, `responder` = il suo compagno, `opp1` = il morto, `opp2` = il dichiarante; i tipi di attacco (sequenza interrotta KJ10, interna KT9, QT9, sotto onore K o Q) sono un'indicazione della redazione di BridgePedia, non tratti dalla dispensa.

=== Mano 1 (attacco 2{{picche}}) ===

<deal>
N: AK105.AQ102.J103.J2
E: J9432.J43.A4.AQ3
S: 76.K5.KQ9765.654
W: Q8.9876.82.K10987
</deal>

Piccola dal morto, Dama di Ovest, asso di Nord; fante di {{quadri}} di Nord, Est liscia, Ovest fornisce il 2 e poi l'8: è una Smith negativa (non ha nulla a {{picche}} oltre l'onore già giocato). Est ricostruisce dall'apertura di 1SA la mano di Nord.

=== Mano 2 (attacco 3{{fiori}}) ===

<deal>
N: 10982.K432.A2.1032
E: AQ3.J105.Q1043.AKJ
S: KJ54.76.65.Q9654
W: 76.AQ98.KJ987.87
</deal>

Sud sa che Est ci prende ancora due volte e che il down va cercato altrove; per dissuadere Nord dal tornare a {{fiori}} fornisce la sua carta più piccola a {{quadri}} o a {{cuori}} a seconda del colore che muoverà Est. Nord prova con successo a sfondare a {{picche}}.

=== Mano 3 (attacco piccola di {{cuori}}) ===

<deal>
N: 432.432.AQ32.AKQ
E: AJ105.105.J104.8654
S: KQ76.KQ6.K976.J10
W: 98.AJ987.85.9732
</deal>

Ovest deve fornire la più grossa carta possibile per impedire che Sud (che muove {{picche}}) si trasferisca al morto; Est non deve precipitarsi a prendere.

=== Mano 4 (attacco piccola di {{picche}}) ===

<deal>
N: KJ932.KJ2.432.32
E: 54.43.AJ1065.KJ54
S: 106.A8765.K7.876
W: AQ7.Q109.Q98.AQ109
</deal>

Nord, dopo la prima presa, fa Smith negativa: non ha altro oltre quanto detto con l'attacco di piccola; il ritorno a {{cuori}} batte. Con A J di {{picche}} (variante della mano) Nord farebbe Smith positiva: "se torni a {{picche}} sono tutte mie".

Nota: nella fonte la mano di Sud risulta di 12 carte (le {{picche}} sono 12 in totale invece di 13); è riportata come trascritta, senza correzione.

=== Mano 5 (attacco 6{{cuori}}) ===

<deal>
N: 432.432.J2.AKJ109
E: KJ5.K10975.A43.74
S: AQ76.AJ.KQ65.Q63
W: 1098.Q86.10987.852
</deal>

Ovest deve far capire a Est che le {{cuori}} sono tutt'altro (Smith negativa). Sud cerca la nona presa giocando {{fiori}} al morto e il fante di {{quadri}}; Est non deve dormire: precipitarsi con l'asso e tornare {{cuori}}.

=== Mano 6 (attacco 3{{quadri}}) ===

<deal>
N: K432.J102.104.AQ32
E: Q1065.95.KJ9.J1094
S: A87.AQ43.A82.K65
W: J9.K876.Q7653.87
</deal>

Re di {{quadri}} di Est, asso di Sud; Est segnala il fante di {{quadri}} con Smith positiva ("nel colore d'attacco ho più di quanto mi hai visto"). Ovest, in presa a {{cuori}}, segue con la piccola di {{quadri}} e deve fidarsi: se incassa la Dama blocca il colore e regala 3SA.

=== Mano 7 (attacco 2{{picche}}) ===

<deal>
N: 65.96.AJ1054.Q653
E: 1084.A8732.K8.984
S: AQ7.Q104.Q76.AKJ10
W: KJ932.KJ5.932.72
</deal>

Ovest attacca il 2 di {{picche}} e vede il 10 e la Dama di Sud; Est deve fare Smith negativa lasciando che Est scelga liberamente (la Smith negativa dell'attaccante non significa "non voglio che torni": lascia aperte le altre strade; la positiva vincola al colore iniziale).

Nota: il testo della fonte presenta una svista nei ruoli Est/Ovest (la frase "Est deve fare Smith negativa lasciando che Est scelga" è riportata fedelmente).

=== Mano 8 (attacco 6{{picche}}) ===

<deal>
N: 842.652.KJ96.QJ10
E: AK1093.1093.872.82
S: QJ7.AQ.AQ105.A976
W: 65.KJ874.43.K543
</deal>

Est deve lisciare il primo giro (senza ingressi); Sud prende e si trasferisce al morto a {{quadri}} (impasse a {{fiori}}). Ovest deve stare attento alla {{quadri}} giocata da Est: si deve dare l'8, che ribadisce le {{picche}}.

== Varianti ==

La fonte non descrive varianti del segnale di Smith: Smith positiva, negativa e di gradimento sono parti della stessa convenzione. Una versione "rovescia" era citata nella precedente versione della pagina, ma non risulta nella fonte e non ha pagina propria.

== Vedi anche ==

* [[Gradimento_naturale|Gradimento naturale]]
* [[Gradimento_rovescio|Gradimento rovescio]]
* [[Segnale_di_conteggio|Segnale di conteggio]]
* [[Segnale_di_preferenza|Segnale di preferenza]]

== Fonti ==

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "02. La 'Smith': un aiuto nel controgioco a Senza" (PDF, 6 pagine).

[[Categoria:Difesa]]
[[Categoria:Segnali difensivi]]
[[Categoria:Gioco a senza atout]]

Multirever

2026-10-20T21:32:03Z

Lpala: shape_constraints: rispondente 5-13 punti

{{DEFAULTSORT:Multirever}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di sviluppo]]
[[Categoria:Convenzioni di licita]]

= Multirever =

{{Convenzione
|nome=Multirever (Primo Rever Disponibile, PRD)
|tipologia=Sviluppo / Rever dell'apertore (rever ambiguo, forzante)
|scopo=Dopo apertura in un minore e risposta di 1 a colore, dare un significato convenzionale al primo rever a colore nuovo disponibile dell'apertore: una dichiarazione forzante e ambigua sulla tipologia della mano (sempre mano forte), chiarita dal rispondente con un relè e dalla successiva descrizione dell'apertore
|trigger=Apertura di 1{{fiori}} o 1{{quadri}}, risposta di uno a colore, nessun intervento avversario; la più economica tra le dichiarazioni di livello due a colore nuovo che rappresentino un rever. Le sequenze sono cinque: 1{{fiori}} 1{{quadri}} 2{{cuori}}; 1{{fiori}} 1{{cuori}} 2{{quadri}}; 1{{fiori}} 1{{picche}} 2{{quadri}}; 1{{quadri}} 1{{cuori}} 2{{picche}}; 1{{quadri}} 1{{picche}} 2{{cuori}}
|risposte=Il rispondente non passa mai (il secondo colore potrebbe essere vuoto). Tre repliche deboli: riporto nel minore di apertura (scoraggiantissima), ripetizione del proprio colore (scoraggiante), sign-off nel secondo colore dichiarato dall'apertore (la meno economica tra senza atout e quarto colore). Una replica forzante: il relè, la più economica tra senza atout e quarto colore (7+ punti, tendenzialmente forzante a manche). Sul relè l'apertore si descrive: primo gradino libero = rever reale 5/4; ripetizione del minore di apertura = monocolore minore; ripetizione del secondo colore = rever 6-4; appoggio a tre nel colore del rispondente = mano sbilanciata di 18-20 con fit quarto (Gran Rever)
|note=Ideatore non indicato nella fonte; descrizione secondo la trattazione di Marina Causa. Forzante senza eccezioni: l'apertore può anche non avere il secondo colore, ma ha sempre almeno 5 carte nel minore di apertura. Non è convenzionale ogni rever dell'apertore, solo il primo rever possibile; non vale su risposta di 1SA. Nessun intervento avversario. Non sono note varianti nella fonte
|tag_cc=rebid_rever
|tag_sistema=naturale
|shape_constraints = 1C-1D-2H mono: opener C:6-7 S:0-3 H:0-3 D:0-3 hcp:18-21; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1D-2H RR 5/4: opener C:5 H:4 S:0-3 D:0-3 hcp:16-21; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1D-2H RR 6/4: opener C:6-7 H:4 S:0-3 D:0-3 hcp:16-21; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1D-2H Gran rever: fit:D8+ opener C:5-6 D:4 H:0-1 hcp:18-20; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1H-2D mono: opener C:6-7 S:0-3 H:0-3 D:0-3 hcp:18-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1H-2D RR 5/4: opener C:5 D:4 S:0-3 H:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1H-2D RR 6/4: opener C:6-7 D:4 S:0-3 H:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1H-2D Gran rever: fit:H8+ opener C:5-6 H:4 D:0-1 hcp:18-20; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1S-2D mono: opener C:6-7 S:0-3 H:0-3 D:0-3 hcp:18-21; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1S-2D RR 5/4: opener C:5 D:4 S:0-3 H:0-3 hcp:16-21; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1S-2D RR 6/4: opener C:6-7 D:4 S:0-3 H:0-3 hcp:16-21; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1C-1S-2D Gran rever: fit:S8+ opener C:5-6 S:4 D:0-1 hcp:18-20; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1H-2S mono: opener D:6-7 S:0-3 H:0-3 C:0-3 hcp:18-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1H-2S RR 5/4: opener D:5 S:4 H:0-3 C:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1H-2S RR 6/4: opener D:6-7 S:4 H:0-3 C:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1H-2S Gran rever: fit:H8+ opener D:5-6 H:4 S:0-1 hcp:18-20; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1S-2H mono: opener D:6-7 S:0-3 H:0-3 C:0-3 hcp:18-21; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1S-2H RR 5/4: opener D:5 H:4 S:0-3 C:0-3 hcp:16-21; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1S-2H RR 6/4: opener D:6-7 H:4 S:0-3 C:0-3 hcp:16-21; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet // 1D-1S-2H Gran rever: fit:S8+ opener D:5-6 S:4 H:0-1 hcp:18-20; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:5-13; opp1 quiet; opp2 quiet
}}

Il '''Multirever''', detto anche '''Primo Rever Disponibile (PRD)''', è un rever ''ambiguo'' dell'apertore che segue un'apertura in un colore minore e una risposta di 1 a colore. Questa pagina riporta la trattazione di Marina Causa (vedi [[#Fonti|Fonti]]); l'ideatore originale della convenzione non è indicato nella fonte.

== Idea ==

Secondo la trattazione di Marina Causa, l'ambiguità del Multirever non riguarda la forza (è sempre una mano forte) ma la '''tipologia della mano'''. La dichiarazione, per esempio

<bidding>1D P 1S P 2H(multirever)</bidding>

non dice in modo univoco "ho una bicolore quadri-cuori di rovescio": il colore espresso è solo una delle possibilità. È un rever "Multicolor" la cui fisionomia si chiarisce dopo. È '''tassativamente forzante''': l'apertore potrebbe non avere affatto il secondo colore, ma ha sempre almeno 5 carte nel primo.

=== Lo spunto ===

Nota sulle mani: nelle trascrizioni della fonte le cartine indicate con "x" sono state sostituite da carte basse non duplicate, perché il parser delle mani non accetta le "x".

Con questa mano (3 picche, 1 cuori, 3 quadri, 6 fiori) un buon naturalista apre di 1{{fiori}} e, se il compagno risponde 1 in un nobile, dichiara 2{{quadri}}:

<hand>AJ4.2.KQ3.AKJ765</hand>

I motivi sono tre:

* è l'unico modo per tenere aperta la dichiarazione (un rever a colore nuovo è forzante anche nel liscione);

* si evita di rischiare il passo e di mortificare la mano con il salto 1{{fiori}} - 3{{fiori}} ("uno poi tre" rappresenta piccoli rever di 15/17 punti);

* il compagno, anche se dovesse preferire le quadri, sarà portato a rispettare le pressioni della mano forte, tanto più trattandosi di colori entrambi minori.

Le quadri sono terze e il compagno non lo sa, ma poco importa, tanto è forzante. Allora "tanto vale codificarlo".

== Presupposti: quale rever è convenzionale ==

Condizioni: apertura in un minore; risposta uno su uno a colore; nessun intervento avversario; la dichiarazione è il più economico dei possibili rever a colore nuovo. Non tutti i rever dell'apertore sono convenzionali: lo è solo "il primo rever possibile", cioè la più bassa dichiarazione di livello due che rappresenti un rever.

Le sequenze convenzionali sono esattamente cinque (tre con partenza fiori, due con quadri):

<bidding>1C P 1D P 2H(multirever)</bidding>

<bidding>1C P 1H P 2D(multirever)</bidding>

<bidding>1C P 1S P 2D(multirever)</bidding>

<bidding>1D P 1H P 2S(multirever)</bidding>

<bidding>1D P 1S P 2H(multirever)</bidding>

Restano rever "normali" (nulla cambia rispetto a prima) le sequenze seguenti:

<bidding>1C P 1D P 2S</bidding>

Non è il primo rever possibile: il primo sarebbe 2{{cuori}}.

<bidding>1C P 1H P 3H</bidding>

Non è una dichiarazione a colore nuovo (è un appoggio).

<bidding>1C P 1NT P 2D</bidding>

La convenzione non funziona su risposta di 1SA.

== Quali mani ==

Per cominciare, solo quattro possibilità:

# la monocolore minore di 18/20 punti (che attualmente non ha collocazione);

# la mano con vero rever 5/4 (il Rever Reale, RR);

# la mano con vero rever ma distribuzione 6/4;

# la mano sbilanciata di Gran Rever con fit quarto nel nobile di risposta.

Il rispondente, per chiedere, usa come relè interrogativo la prima dichiarazione possibile che non corrisponda né alla ripetizione del seme di risposta né al riporto nel minore di apertura.

Esempi di mani dell'apertore nella sequenza

<bidding>1D P 1S P 2H(multirever)</bidding>

* monocolore di quadri forte, più di "uno poi tre" ma non abbastanza per 2{{fiori}}; punteggio promesso 18-21 (13 carte):

<hand>2.AQ54.KQJ76.A83</hand>

* rever reale 5/4, punteggio 16-21 (13 carte):

<hand>2.KQ54.AQJ76.A83</hand>

* rever reale con distribuzione 6/4 ("un asso in più"), punteggio 16-21: la fonte riporta ♠Kx ♥KJxx ♦AKQxxxx ♣x, che contiene 14 carte (probabile refuso); la mano non viene quindi mostrata. Si tratta di una mano con sei o sette quadri e quattro cuori;

* rever nel nobile di risposta (picche), punteggio massimo 18-21 (13 carte):

<hand>KQ54.2.AKJT7.AQ8</hand>

=== La monocolore minore 18/20 ===

È il tipo di mano che costituisce il vero vantaggio del PRD. Poter dare una sesta o settima di quella forza (a volte con 17) permette di "abbassare" la soglia della descrizione di una monocolore di piccolo rever: prima era inquadrata nel range 15/17, ora si potrà far onore anche alla mano di 14 molto belli. Per esempio è legittimo aprire di 1{{quadri}} e ripeterla a salto su risposta di un nobile:

<hand>AJ4.2.AKQ765.983</hand>

=== Il rever sbilanciato con fit quarto ===

Crea un gradino espressivo in più per la bicolore di fit e amplia l'arco di punteggio. Da adesso, nell'ordine:

* '''1{{quadri}} 1{{cuori}} 3{{cuori}}''': appoggio a livello 3. Può "scendere" a coprire anche l'area dei 14/15 punti, con buone bicolori 5/4 e oltre, mai con la 4432. Campo di forza 14/16 (prima era 15/17); non tutti i 14, la fonte raccomanda solo quelli con cui sembra un peccato appoggiare soltanto a 2. Mano modello del punteggio minimo ("Distribuzione, mano pura, qualità dei punti. Se no, no."):

<bidding>1D P 1H P 3H</bidding>

<hand>2.AK54.AKT97.853</hand>

* '''1{{quadri}} 1{{cuori}} 4{{fiori}}''': appoggio a manche, diretto (nessun singolo che piaccia descrivere) o con le varie splinter. Mano forte ma "di prese" piuttosto che "di punti": una bella 6/4 o 7/4 di 15-16 punti con 8-9 vincenti teoriche. La mano di esempio della fonte (♠xxx ♥AQJx ♦AKJ10xx ♣-) contiene 14 carte (probabile refuso) e non viene mostrata.

<bidding>1D P 1H P 4C</bidding>

* '''1{{quadri}} 1{{cuori}} 2{{picche}}(*)''': il Multirever. Un rovescio fatto di "punti", troppi per una delle opzioni precedenti ma troppo pochi per l'apertura di 2{{fiori}}; mediamente una mano di circa 18, 19, 20.

<bidding>1D P 1H P 2S(multirever)</bidding>

Per confronto, la fonte riporta la sequenza seguente come "il massimo immaginabile": una mano che non ha voluto rischiare il passo, perché può far manche da sola o con un re o una dama al posto giusto.

<bidding>2C P 2H P 3H</bidding>

=== Rever reale 5/4 e rever reale 6/4 ===

Sono differenziati perché una mano con una sesta ha una affrancabile in più e con vie naturali sarebbe difficile descriverla: una licita per la 5/4 e una per la 6/4 o 7/4.

== Le ridichiarazioni del rispondente ==

Il Passo è impensabile (il secondo colore potrebbe essere vuoto). Per ognuna delle cinque sequenze le repliche possibili del rispondente sono le seguenti; la seconda dichiarazione elencata come "relè" è quella forzante.

{| class="wikitable"
! Sequenza
! Repliche del rispondente
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}}
| 2{{picche}} (relè), 2SA, 3{{fiori}}, 3{{quadri}}
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}}
| 2{{cuori}}, 2{{picche}} (relè), 2SA, 3{{fiori}}
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}}
| 2{{cuori}} (relè), 2{{picche}}, 2SA, 3{{fiori}}
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}}
| 2SA (relè), 3{{fiori}}, 3{{quadri}}, 3{{cuori}}
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}}
| 2{{picche}}, 2SA (relè), 3{{fiori}}, 3{{quadri}}
|}

In ognuna ci sono due dichiarazioni assolutamente scoraggianti:

* il riporto nel minore dell'apertore (debolissima: "giocherei un parziale nella tua lunga, in cui ho mediamente due/tre cartine");

* la ripetizione del proprio colore (anch'essa estremamente scoraggiante: lunga e desiderio di giocare quel parziale, salvo plusvalori e fit dell'apertore; tende a escludere visuale di manche: mediamente 4/5 punti, forse 6 brutti, e sei carte, cinque solo se annunciabili a livello due).

Rimangono due dichiarazioni, i senza atout e il quarto colore. Per ognuno dei cinque casi:

* la più economica è il '''relè''', tendenzialmente forzante a manche, con 6/7+ punti;

* la meno economica è il '''sign-off''' nel secondo colore detto dall'apertore, sempre che lo abbia davvero.

Quindi tre dichiarazioni deboli per arrestarsi al parziale in uno dei tre colori detti e un'unica dichiarazione forzante per chiedere all'apertore che tipo di rever possiede. Il relè si usa con tutte le mani con cui è legittimo affrontare almeno un tentativo di manche (sempre con 7+ punti, anche con 5/6 carini).

Sequenze forzanti (relè):

<bidding>1C P 1D P 2H(multirever) P 2S(rele)</bidding>

<bidding>1C P 1H P 2D(multirever) P 2S(rele)</bidding>

<bidding>1C P 1S P 2D(multirever) P 2H(rele)</bidding>

<bidding>1D P 1H P 2S(multirever) P 2NT(rele)</bidding>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele)</bidding>

Il sign-off (secondo footnote della fonte) è un segnale scoraggiante di arresto: "se hai per davvero il secondo colore che hai detto, giocherei un parziale nel secondo colore; nessuna prospettiva di manche: semplicemente aspetto di riportarti nel minore lungo perché se per caso hai davvero il secondo colore può darsi che te lo possa appoggiare". Il "gradino libero" è la più bassa dichiarazione a cui non sia già stato assegnato un significato particolare.

== L'apertore si descrive sul relè forzante ==

Regole mnemoniche:

* il primo gradino libero è sempre il '''Rever Reale''' (5/4);

* la ripetizione del '''minore di apertura''' mostra sempre la monocolore minore;

* la ripetizione del '''secondo colore''' mostra sempre la 6-4;

* l'appoggio a '''tre''' nel colore del rispondente mostra la sbilanciata 18-20 di Gran Rever con fit quarto.

Dopo il relè si dà per scontato che la coppia abbia la forza per la manche: nulla è più passabile sotto manche.

{| class="wikitable"
! Sequenza fino al relè
! 1° gradino libero: RR 5/4
! Ripetizione del minore: monocolore
! Ripetizione del 2° colore: RR 6-4
! Appoggio a tre: sbilanciata 18-20 con 4 carte
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{cuori}} (6 fiori, 4 cuori)
| 3{{quadri}} (4 quadri)
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{cuori}} (4 cuori)
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}} P 2{{cuori}}
| 2{{picche}} (nella fonte segnalato con "(!!!)")
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{picche}} (4 picche)
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{picche}} (6 quadri, 4 picche)
| 3{{cuori}} (4 cuori)
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{cuori}} (6 quadri, 4 cuori)
| 3{{picche}} (4 picche)
|}

=== Esempi dopo il relè ===

Nota sulle mani: le cartine "x" della fonte sono state sostituite da carte basse non duplicate; il "10" è scritto T.

'''Rever reale 5/4.''' Su 1{{quadri}} 1{{picche}} 2{{cuori}} il rispondente fa il relè 2SA; 3{{fiori}} (primo gradino libero) mostra il rever reale 5/4. Su 3{{picche}}, che allunga le picche, Sud appoggia; Nord capisce che la Q{{fiori}} è valore nullo e si accontenta.

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3C(RR) P 3S P 4S</bidding>

Sud (apertore):

<hand>AQ6.AJ97.AK976.4</hand>

Nord (rispondente):

<hand>JT872.Q85.Q2.AQ8</hand>

'''Monocolore forte.''' Sud svela la monocolore con la ripetizione del minore, Nord dichiara 3SA.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 3C(monocolore) P 3NT</bidding>

Sud (apertore):

<hand>AK5.A94.4.AQJ974</hand>

Nord (rispondente):

<hand>Q87.JT85.QJT2.K8</hand>

'''Il riporto è una replica debolissima.''' Secondo la fonte, il riporto significa: non vorrei giocare la manche neppure se hai il rever con fit quarto nel mio colore, a meno che tu non abbia "i serpenti in mano". Sud (apertore):

<hand>A4.K9.KQJ976.AJ5</hand>

Nord (rispondente):

<hand>J875.876.32.K876</hand>

<bidding>1D P 1S P 2H(multirever) P 3D P P</bidding>

'''Relè debole (secondo gradino libero).''' Nord ha una sola prospettiva di manche, il rever fiori-picche; il 2SA è il secondo gradino libero, debole, mentre il relè sarebbe stato 2{{cuori}}. Sud ridichiara a seconda della sua mano e dice 3{{quadri}} solo con la 5/4 minore e punteggio minimo; con 20 direbbe 3SA.

<bidding>1C P 1S P 2D(multirever) P 2NT P 3D P P</bidding>

Sud (apertore):

<hand>2.A63.KQ76.AKJ54</hand>

Nord (rispondente):

<hand>J9854.87.A985.87</hand>

'''Atout fissato nel nobile.''' Con il rever di appoggio quarto nel nobile l'atout è inequivocabilmente fissato: il 4{{quadri}} è una cue bid, non un ripensamento sull'atout. Sud (apertore):

<hand>AQJ4.3.AQJ765.A2</hand>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3S P 4D</bidding>

La mano di Nord riportata dalla fonte (♠K109xxx ♥xx ♦Kx ♣Qx) contiene soltanto 12 carte (probabile refuso) e non viene mostrata.

'''Minore dell'apertore fissato a livello 4.''' Il minore dell'apertore si può fissare dichiarandolo a livello 3 (comunque forzante) o a livello 4: inequivocabilmente atout fissato e visuale di slam. La mano limite si sarebbe espressa riportando a 3{{fiori}} subito, direttamente su 2{{cuori}}, evitando il relè.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 2NT P 4C</bidding>

Sud (apertore):

<hand>AK5.A876.2.AQJ98</hand>

Nord (rispondente):

<hand>43.KQ4.AJ83.K765</hand>

'''Arresto a livello di riporto, ma Sud chiama manche.''' Nord frena con la ripetizione del proprio colore, ma Sud, con la mano di fit a picche, chiama comunque manche.

<bidding>1D P 1S P 2H(multirever) P 2S P 4S</bidding>

Sud (apertore):

<hand>AKJ2.A82.KQJ4.J9</hand>

Nord (rispondente):

<hand>Q98764.K75.2.763</hand>

Nota: nella fonte il commento a questa sequenza contiene una formula poco chiara ("5 0 6??"); qui si riportano la sequenza e le mani con le cartine sostituite.

== Varianti ==

La fonte descrive una sola versione della convenzione e non menziona varianti: non sono note varianti significative e per questo non esistono pagine di variante.

== Vedi anche ==

* [[Splinter]]

== Fonti ==

I vincoli di distribuzione per il generatore di smazzate (campo shape_constraints) sono ricavati dalla trattazione di Marina Causa (Corso Preagonistica 2026); i range di punti sono indicativi.

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "03. Il Multirever, o Primo Rever Disponibile (PRD)" (PDF, 5 pagine). L'ideatore originale della convenzione non è indicato nella fonte.

Multirever

2026-10-20T21:27:09Z

Lpala: shape_constraints: rispondente meno sbilanciato (seme 4-5, altri max 5, 6-11 PO; mani apertore max 7 carte, altri semi max 3)

{{DEFAULTSORT:Multirever}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di sviluppo]]
[[Categoria:Convenzioni di licita]]

= Multirever =

{{Convenzione
|nome=Multirever (Primo Rever Disponibile, PRD)
|tipologia=Sviluppo / Rever dell'apertore (rever ambiguo, forzante)
|scopo=Dopo apertura in un minore e risposta di 1 a colore, dare un significato convenzionale al primo rever a colore nuovo disponibile dell'apertore: una dichiarazione forzante e ambigua sulla tipologia della mano (sempre mano forte), chiarita dal rispondente con un relè e dalla successiva descrizione dell'apertore
|trigger=Apertura di 1{{fiori}} o 1{{quadri}}, risposta di uno a colore, nessun intervento avversario; la più economica tra le dichiarazioni di livello due a colore nuovo che rappresentino un rever. Le sequenze sono cinque: 1{{fiori}} 1{{quadri}} 2{{cuori}}; 1{{fiori}} 1{{cuori}} 2{{quadri}}; 1{{fiori}} 1{{picche}} 2{{quadri}}; 1{{quadri}} 1{{cuori}} 2{{picche}}; 1{{quadri}} 1{{picche}} 2{{cuori}}
|risposte=Il rispondente non passa mai (il secondo colore potrebbe essere vuoto). Tre repliche deboli: riporto nel minore di apertura (scoraggiantissima), ripetizione del proprio colore (scoraggiante), sign-off nel secondo colore dichiarato dall'apertore (la meno economica tra senza atout e quarto colore). Una replica forzante: il relè, la più economica tra senza atout e quarto colore (7+ punti, tendenzialmente forzante a manche). Sul relè l'apertore si descrive: primo gradino libero = rever reale 5/4; ripetizione del minore di apertura = monocolore minore; ripetizione del secondo colore = rever 6-4; appoggio a tre nel colore del rispondente = mano sbilanciata di 18-20 con fit quarto (Gran Rever)
|note=Ideatore non indicato nella fonte; descrizione secondo la trattazione di Marina Causa. Forzante senza eccezioni: l'apertore può anche non avere il secondo colore, ma ha sempre almeno 5 carte nel minore di apertura. Non è convenzionale ogni rever dell'apertore, solo il primo rever possibile; non vale su risposta di 1SA. Nessun intervento avversario. Non sono note varianti nella fonte
|tag_cc=rebid_rever
|tag_sistema=naturale
|shape_constraints = 1C-1D-2H mono: opener C:6-7 S:0-3 H:0-3 D:0-3 hcp:18-21; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1D-2H RR 5/4: opener C:5 H:4 S:0-3 D:0-3 hcp:16-21; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1D-2H RR 6/4: opener C:6-7 H:4 S:0-3 D:0-3 hcp:16-21; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1D-2H Gran rever: fit:D8+ opener C:5-6 D:4 H:0-1 hcp:18-20; responder S:0-5 H:0-3 D:4-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1H-2D mono: opener C:6-7 S:0-3 H:0-3 D:0-3 hcp:18-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1H-2D RR 5/4: opener C:5 D:4 S:0-3 H:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1H-2D RR 6/4: opener C:6-7 D:4 S:0-3 H:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1H-2D Gran rever: fit:H8+ opener C:5-6 H:4 D:0-1 hcp:18-20; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1S-2D mono: opener C:6-7 S:0-3 H:0-3 D:0-3 hcp:18-21; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1S-2D RR 5/4: opener C:5 D:4 S:0-3 H:0-3 hcp:16-21; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1S-2D RR 6/4: opener C:6-7 D:4 S:0-3 H:0-3 hcp:16-21; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1C-1S-2D Gran rever: fit:S8+ opener C:5-6 S:4 D:0-1 hcp:18-20; responder S:4-5 H:0-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1H-2S mono: opener D:6-7 S:0-3 H:0-3 C:0-3 hcp:18-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1H-2S RR 5/4: opener D:5 S:4 H:0-3 C:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1H-2S RR 6/4: opener D:6-7 S:4 H:0-3 C:0-3 hcp:16-21; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1H-2S Gran rever: fit:H8+ opener D:5-6 H:4 S:0-1 hcp:18-20; responder S:0-5 H:4-5 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1S-2H mono: opener D:6-7 S:0-3 H:0-3 C:0-3 hcp:18-21; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1S-2H RR 5/4: opener D:5 H:4 S:0-3 C:0-3 hcp:16-21; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1S-2H RR 6/4: opener D:6-7 H:4 S:0-3 C:0-3 hcp:16-21; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet // 1D-1S-2H Gran rever: fit:S8+ opener D:5-6 S:4 H:0-1 hcp:18-20; responder S:4-5 H:0-3 D:0-5 C:0-5 hcp:6-11; opp1 quiet; opp2 quiet
}}

Il '''Multirever''', detto anche '''Primo Rever Disponibile (PRD)''', è un rever ''ambiguo'' dell'apertore che segue un'apertura in un colore minore e una risposta di 1 a colore. Questa pagina riporta la trattazione di Marina Causa (vedi [[#Fonti|Fonti]]); l'ideatore originale della convenzione non è indicato nella fonte.

== Idea ==

Secondo la trattazione di Marina Causa, l'ambiguità del Multirever non riguarda la forza (è sempre una mano forte) ma la '''tipologia della mano'''. La dichiarazione, per esempio

<bidding>1D P 1S P 2H(multirever)</bidding>

non dice in modo univoco "ho una bicolore quadri-cuori di rovescio": il colore espresso è solo una delle possibilità. È un rever "Multicolor" la cui fisionomia si chiarisce dopo. È '''tassativamente forzante''': l'apertore potrebbe non avere affatto il secondo colore, ma ha sempre almeno 5 carte nel primo.

=== Lo spunto ===

Nota sulle mani: nelle trascrizioni della fonte le cartine indicate con "x" sono state sostituite da carte basse non duplicate, perché il parser delle mani non accetta le "x".

Con questa mano (3 picche, 1 cuori, 3 quadri, 6 fiori) un buon naturalista apre di 1{{fiori}} e, se il compagno risponde 1 in un nobile, dichiara 2{{quadri}}:

<hand>AJ4.2.KQ3.AKJ765</hand>

I motivi sono tre:

* è l'unico modo per tenere aperta la dichiarazione (un rever a colore nuovo è forzante anche nel liscione);

* si evita di rischiare il passo e di mortificare la mano con il salto 1{{fiori}} - 3{{fiori}} ("uno poi tre" rappresenta piccoli rever di 15/17 punti);

* il compagno, anche se dovesse preferire le quadri, sarà portato a rispettare le pressioni della mano forte, tanto più trattandosi di colori entrambi minori.

Le quadri sono terze e il compagno non lo sa, ma poco importa, tanto è forzante. Allora "tanto vale codificarlo".

== Presupposti: quale rever è convenzionale ==

Condizioni: apertura in un minore; risposta uno su uno a colore; nessun intervento avversario; la dichiarazione è il più economico dei possibili rever a colore nuovo. Non tutti i rever dell'apertore sono convenzionali: lo è solo "il primo rever possibile", cioè la più bassa dichiarazione di livello due che rappresenti un rever.

Le sequenze convenzionali sono esattamente cinque (tre con partenza fiori, due con quadri):

<bidding>1C P 1D P 2H(multirever)</bidding>

<bidding>1C P 1H P 2D(multirever)</bidding>

<bidding>1C P 1S P 2D(multirever)</bidding>

<bidding>1D P 1H P 2S(multirever)</bidding>

<bidding>1D P 1S P 2H(multirever)</bidding>

Restano rever "normali" (nulla cambia rispetto a prima) le sequenze seguenti:

<bidding>1C P 1D P 2S</bidding>

Non è il primo rever possibile: il primo sarebbe 2{{cuori}}.

<bidding>1C P 1H P 3H</bidding>

Non è una dichiarazione a colore nuovo (è un appoggio).

<bidding>1C P 1NT P 2D</bidding>

La convenzione non funziona su risposta di 1SA.

== Quali mani ==

Per cominciare, solo quattro possibilità:

# la monocolore minore di 18/20 punti (che attualmente non ha collocazione);

# la mano con vero rever 5/4 (il Rever Reale, RR);

# la mano con vero rever ma distribuzione 6/4;

# la mano sbilanciata di Gran Rever con fit quarto nel nobile di risposta.

Il rispondente, per chiedere, usa come relè interrogativo la prima dichiarazione possibile che non corrisponda né alla ripetizione del seme di risposta né al riporto nel minore di apertura.

Esempi di mani dell'apertore nella sequenza

<bidding>1D P 1S P 2H(multirever)</bidding>

* monocolore di quadri forte, più di "uno poi tre" ma non abbastanza per 2{{fiori}}; punteggio promesso 18-21 (13 carte):

<hand>2.AQ54.KQJ76.A83</hand>

* rever reale 5/4, punteggio 16-21 (13 carte):

<hand>2.KQ54.AQJ76.A83</hand>

* rever reale con distribuzione 6/4 ("un asso in più"), punteggio 16-21: la fonte riporta ♠Kx ♥KJxx ♦AKQxxxx ♣x, che contiene 14 carte (probabile refuso); la mano non viene quindi mostrata. Si tratta di una mano con sei o sette quadri e quattro cuori;

* rever nel nobile di risposta (picche), punteggio massimo 18-21 (13 carte):

<hand>KQ54.2.AKJT7.AQ8</hand>

=== La monocolore minore 18/20 ===

È il tipo di mano che costituisce il vero vantaggio del PRD. Poter dare una sesta o settima di quella forza (a volte con 17) permette di "abbassare" la soglia della descrizione di una monocolore di piccolo rever: prima era inquadrata nel range 15/17, ora si potrà far onore anche alla mano di 14 molto belli. Per esempio è legittimo aprire di 1{{quadri}} e ripeterla a salto su risposta di un nobile:

<hand>AJ4.2.AKQ765.983</hand>

=== Il rever sbilanciato con fit quarto ===

Crea un gradino espressivo in più per la bicolore di fit e amplia l'arco di punteggio. Da adesso, nell'ordine:

* '''1{{quadri}} 1{{cuori}} 3{{cuori}}''': appoggio a livello 3. Può "scendere" a coprire anche l'area dei 14/15 punti, con buone bicolori 5/4 e oltre, mai con la 4432. Campo di forza 14/16 (prima era 15/17); non tutti i 14, la fonte raccomanda solo quelli con cui sembra un peccato appoggiare soltanto a 2. Mano modello del punteggio minimo ("Distribuzione, mano pura, qualità dei punti. Se no, no."):

<bidding>1D P 1H P 3H</bidding>

<hand>2.AK54.AKT97.853</hand>

* '''1{{quadri}} 1{{cuori}} 4{{fiori}}''': appoggio a manche, diretto (nessun singolo che piaccia descrivere) o con le varie splinter. Mano forte ma "di prese" piuttosto che "di punti": una bella 6/4 o 7/4 di 15-16 punti con 8-9 vincenti teoriche. La mano di esempio della fonte (♠xxx ♥AQJx ♦AKJ10xx ♣-) contiene 14 carte (probabile refuso) e non viene mostrata.

<bidding>1D P 1H P 4C</bidding>

* '''1{{quadri}} 1{{cuori}} 2{{picche}}(*)''': il Multirever. Un rovescio fatto di "punti", troppi per una delle opzioni precedenti ma troppo pochi per l'apertura di 2{{fiori}}; mediamente una mano di circa 18, 19, 20.

<bidding>1D P 1H P 2S(multirever)</bidding>

Per confronto, la fonte riporta la sequenza seguente come "il massimo immaginabile": una mano che non ha voluto rischiare il passo, perché può far manche da sola o con un re o una dama al posto giusto.

<bidding>2C P 2H P 3H</bidding>

=== Rever reale 5/4 e rever reale 6/4 ===

Sono differenziati perché una mano con una sesta ha una affrancabile in più e con vie naturali sarebbe difficile descriverla: una licita per la 5/4 e una per la 6/4 o 7/4.

== Le ridichiarazioni del rispondente ==

Il Passo è impensabile (il secondo colore potrebbe essere vuoto). Per ognuna delle cinque sequenze le repliche possibili del rispondente sono le seguenti; la seconda dichiarazione elencata come "relè" è quella forzante.

{| class="wikitable"
! Sequenza
! Repliche del rispondente
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}}
| 2{{picche}} (relè), 2SA, 3{{fiori}}, 3{{quadri}}
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}}
| 2{{cuori}}, 2{{picche}} (relè), 2SA, 3{{fiori}}
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}}
| 2{{cuori}} (relè), 2{{picche}}, 2SA, 3{{fiori}}
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}}
| 2SA (relè), 3{{fiori}}, 3{{quadri}}, 3{{cuori}}
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}}
| 2{{picche}}, 2SA (relè), 3{{fiori}}, 3{{quadri}}
|}

In ognuna ci sono due dichiarazioni assolutamente scoraggianti:

* il riporto nel minore dell'apertore (debolissima: "giocherei un parziale nella tua lunga, in cui ho mediamente due/tre cartine");

* la ripetizione del proprio colore (anch'essa estremamente scoraggiante: lunga e desiderio di giocare quel parziale, salvo plusvalori e fit dell'apertore; tende a escludere visuale di manche: mediamente 4/5 punti, forse 6 brutti, e sei carte, cinque solo se annunciabili a livello due).

Rimangono due dichiarazioni, i senza atout e il quarto colore. Per ognuno dei cinque casi:

* la più economica è il '''relè''', tendenzialmente forzante a manche, con 6/7+ punti;

* la meno economica è il '''sign-off''' nel secondo colore detto dall'apertore, sempre che lo abbia davvero.

Quindi tre dichiarazioni deboli per arrestarsi al parziale in uno dei tre colori detti e un'unica dichiarazione forzante per chiedere all'apertore che tipo di rever possiede. Il relè si usa con tutte le mani con cui è legittimo affrontare almeno un tentativo di manche (sempre con 7+ punti, anche con 5/6 carini).

Sequenze forzanti (relè):

<bidding>1C P 1D P 2H(multirever) P 2S(rele)</bidding>

<bidding>1C P 1H P 2D(multirever) P 2S(rele)</bidding>

<bidding>1C P 1S P 2D(multirever) P 2H(rele)</bidding>

<bidding>1D P 1H P 2S(multirever) P 2NT(rele)</bidding>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele)</bidding>

Il sign-off (secondo footnote della fonte) è un segnale scoraggiante di arresto: "se hai per davvero il secondo colore che hai detto, giocherei un parziale nel secondo colore; nessuna prospettiva di manche: semplicemente aspetto di riportarti nel minore lungo perché se per caso hai davvero il secondo colore può darsi che te lo possa appoggiare". Il "gradino libero" è la più bassa dichiarazione a cui non sia già stato assegnato un significato particolare.

== L'apertore si descrive sul relè forzante ==

Regole mnemoniche:

* il primo gradino libero è sempre il '''Rever Reale''' (5/4);

* la ripetizione del '''minore di apertura''' mostra sempre la monocolore minore;

* la ripetizione del '''secondo colore''' mostra sempre la 6-4;

* l'appoggio a '''tre''' nel colore del rispondente mostra la sbilanciata 18-20 di Gran Rever con fit quarto.

Dopo il relè si dà per scontato che la coppia abbia la forza per la manche: nulla è più passabile sotto manche.

{| class="wikitable"
! Sequenza fino al relè
! 1° gradino libero: RR 5/4
! Ripetizione del minore: monocolore
! Ripetizione del 2° colore: RR 6-4
! Appoggio a tre: sbilanciata 18-20 con 4 carte
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{cuori}} (6 fiori, 4 cuori)
| 3{{quadri}} (4 quadri)
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{cuori}} (4 cuori)
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}} P 2{{cuori}}
| 2{{picche}} (nella fonte segnalato con "(!!!)")
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{picche}} (4 picche)
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{picche}} (6 quadri, 4 picche)
| 3{{cuori}} (4 cuori)
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{cuori}} (6 quadri, 4 cuori)
| 3{{picche}} (4 picche)
|}

=== Esempi dopo il relè ===

Nota sulle mani: le cartine "x" della fonte sono state sostituite da carte basse non duplicate; il "10" è scritto T.

'''Rever reale 5/4.''' Su 1{{quadri}} 1{{picche}} 2{{cuori}} il rispondente fa il relè 2SA; 3{{fiori}} (primo gradino libero) mostra il rever reale 5/4. Su 3{{picche}}, che allunga le picche, Sud appoggia; Nord capisce che la Q{{fiori}} è valore nullo e si accontenta.

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3C(RR) P 3S P 4S</bidding>

Sud (apertore):

<hand>AQ6.AJ97.AK976.4</hand>

Nord (rispondente):

<hand>JT872.Q85.Q2.AQ8</hand>

'''Monocolore forte.''' Sud svela la monocolore con la ripetizione del minore, Nord dichiara 3SA.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 3C(monocolore) P 3NT</bidding>

Sud (apertore):

<hand>AK5.A94.4.AQJ974</hand>

Nord (rispondente):

<hand>Q87.JT85.QJT2.K8</hand>

'''Il riporto è una replica debolissima.''' Secondo la fonte, il riporto significa: non vorrei giocare la manche neppure se hai il rever con fit quarto nel mio colore, a meno che tu non abbia "i serpenti in mano". Sud (apertore):

<hand>A4.K9.KQJ976.AJ5</hand>

Nord (rispondente):

<hand>J875.876.32.K876</hand>

<bidding>1D P 1S P 2H(multirever) P 3D P P</bidding>

'''Relè debole (secondo gradino libero).''' Nord ha una sola prospettiva di manche, il rever fiori-picche; il 2SA è il secondo gradino libero, debole, mentre il relè sarebbe stato 2{{cuori}}. Sud ridichiara a seconda della sua mano e dice 3{{quadri}} solo con la 5/4 minore e punteggio minimo; con 20 direbbe 3SA.

<bidding>1C P 1S P 2D(multirever) P 2NT P 3D P P</bidding>

Sud (apertore):

<hand>2.A63.KQ76.AKJ54</hand>

Nord (rispondente):

<hand>J9854.87.A985.87</hand>

'''Atout fissato nel nobile.''' Con il rever di appoggio quarto nel nobile l'atout è inequivocabilmente fissato: il 4{{quadri}} è una cue bid, non un ripensamento sull'atout. Sud (apertore):

<hand>AQJ4.3.AQJ765.A2</hand>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3S P 4D</bidding>

La mano di Nord riportata dalla fonte (♠K109xxx ♥xx ♦Kx ♣Qx) contiene soltanto 12 carte (probabile refuso) e non viene mostrata.

'''Minore dell'apertore fissato a livello 4.''' Il minore dell'apertore si può fissare dichiarandolo a livello 3 (comunque forzante) o a livello 4: inequivocabilmente atout fissato e visuale di slam. La mano limite si sarebbe espressa riportando a 3{{fiori}} subito, direttamente su 2{{cuori}}, evitando il relè.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 2NT P 4C</bidding>

Sud (apertore):

<hand>AK5.A876.2.AQJ98</hand>

Nord (rispondente):

<hand>43.KQ4.AJ83.K765</hand>

'''Arresto a livello di riporto, ma Sud chiama manche.''' Nord frena con la ripetizione del proprio colore, ma Sud, con la mano di fit a picche, chiama comunque manche.

<bidding>1D P 1S P 2H(multirever) P 2S P 4S</bidding>

Sud (apertore):

<hand>AKJ2.A82.KQJ4.J9</hand>

Nord (rispondente):

<hand>Q98764.K75.2.763</hand>

Nota: nella fonte il commento a questa sequenza contiene una formula poco chiara ("5 0 6??"); qui si riportano la sequenza e le mani con le cartine sostituite.

== Varianti ==

La fonte descrive una sola versione della convenzione e non menziona varianti: non sono note varianti significative e per questo non esistono pagine di variante.

== Vedi anche ==

* [[Splinter]]

== Fonti ==

I vincoli di distribuzione per il generatore di smazzate (campo shape_constraints) sono ricavati dalla trattazione di Marina Causa (Corso Preagonistica 2026); i range di punti sono indicativi.

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "03. Il Multirever, o Primo Rever Disponibile (PRD)" (PDF, 5 pagine). L'ideatore originale della convenzione non è indicato nella fonte.

Multirever

2026-10-20T14:10:33Z

Lpala: shape_constraints: avversari quiet

{{DEFAULTSORT:Multirever}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di sviluppo]]
[[Categoria:Convenzioni di licita]]

= Multirever =

{{Convenzione
|nome=Multirever (Primo Rever Disponibile, PRD)
|tipologia=Sviluppo / Rever dell'apertore (rever ambiguo, forzante)
|scopo=Dopo apertura in un minore e risposta di 1 a colore, dare un significato convenzionale al primo rever a colore nuovo disponibile dell'apertore: una dichiarazione forzante e ambigua sulla tipologia della mano (sempre mano forte), chiarita dal rispondente con un relè e dalla successiva descrizione dell'apertore
|trigger=Apertura di 1{{fiori}} o 1{{quadri}}, risposta di uno a colore, nessun intervento avversario; la più economica tra le dichiarazioni di livello due a colore nuovo che rappresentino un rever. Le sequenze sono cinque: 1{{fiori}} 1{{quadri}} 2{{cuori}}; 1{{fiori}} 1{{cuori}} 2{{quadri}}; 1{{fiori}} 1{{picche}} 2{{quadri}}; 1{{quadri}} 1{{cuori}} 2{{picche}}; 1{{quadri}} 1{{picche}} 2{{cuori}}
|risposte=Il rispondente non passa mai (il secondo colore potrebbe essere vuoto). Tre repliche deboli: riporto nel minore di apertura (scoraggiantissima), ripetizione del proprio colore (scoraggiante), sign-off nel secondo colore dichiarato dall'apertore (la meno economica tra senza atout e quarto colore). Una replica forzante: il relè, la più economica tra senza atout e quarto colore (7+ punti, tendenzialmente forzante a manche). Sul relè l'apertore si descrive: primo gradino libero = rever reale 5/4; ripetizione del minore di apertura = monocolore minore; ripetizione del secondo colore = rever 6-4; appoggio a tre nel colore del rispondente = mano sbilanciata di 18-20 con fit quarto (Gran Rever)
|note=Ideatore non indicato nella fonte; descrizione secondo la trattazione di Marina Causa. Forzante senza eccezioni: l'apertore può anche non avere il secondo colore, ma ha sempre almeno 5 carte nel minore di apertura. Non è convenzionale ogni rever dell'apertore, solo il primo rever possibile; non vale su risposta di 1SA. Nessun intervento avversario. Non sono note varianti nella fonte
|tag_cc=rebid_rever
|tag_sistema=naturale
|shape_constraints = 1C-1D-2H mono: opener C:6+ hcp:18-21; responder D:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1D-2H RR 5/4: opener C:5 H:4 D:0-3 hcp:16-21; responder D:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1D-2H RR 6/4: opener C:6+ H:4 hcp:16-21; responder D:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1D-2H Gran rever: fit:D8+ opener C:5+ D:4 H:0-1 hcp:18-20; responder D:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1H-2D mono: opener C:6+ hcp:18-21; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1H-2D RR 5/4: opener C:5 D:4 H:0-3 hcp:16-21; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1H-2D RR 6/4: opener C:6+ D:4 hcp:16-21; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1H-2D Gran rever: fit:H8+ opener C:5+ H:4 D:0-1 hcp:18-20; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1S-2D mono: opener C:6+ hcp:18-21; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1S-2D RR 5/4: opener C:5 D:4 S:0-3 hcp:16-21; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1S-2D RR 6/4: opener C:6+ D:4 hcp:16-21; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1C-1S-2D Gran rever: fit:S8+ opener C:5+ S:4 D:0-1 hcp:18-20; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1H-2S mono: opener D:6+ hcp:18-21; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1H-2S RR 5/4: opener D:5 S:4 H:0-3 hcp:16-21; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1H-2S RR 6/4: opener D:6+ S:4 hcp:16-21; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1H-2S Gran rever: fit:H8+ opener D:5+ H:4 S:0-1 hcp:18-20; responder H:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1S-2H mono: opener D:6+ hcp:18-21; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1S-2H RR 5/4: opener D:5 H:4 S:0-3 hcp:16-21; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1S-2H RR 6/4: opener D:6+ H:4 hcp:16-21; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet // 1D-1S-2H Gran rever: fit:S8+ opener D:5+ S:4 H:0-1 hcp:18-20; responder S:4+ hcp:6+; opp1 quiet; opp2 quiet
}}

Il '''Multirever''', detto anche '''Primo Rever Disponibile (PRD)''', è un rever ''ambiguo'' dell'apertore che segue un'apertura in un colore minore e una risposta di 1 a colore. Questa pagina riporta la trattazione di Marina Causa (vedi [[#Fonti|Fonti]]); l'ideatore originale della convenzione non è indicato nella fonte.

== Idea ==

Secondo la trattazione di Marina Causa, l'ambiguità del Multirever non riguarda la forza (è sempre una mano forte) ma la '''tipologia della mano'''. La dichiarazione, per esempio

<bidding>1D P 1S P 2H(multirever)</bidding>

non dice in modo univoco "ho una bicolore quadri-cuori di rovescio": il colore espresso è solo una delle possibilità. È un rever "Multicolor" la cui fisionomia si chiarisce dopo. È '''tassativamente forzante''': l'apertore potrebbe non avere affatto il secondo colore, ma ha sempre almeno 5 carte nel primo.

=== Lo spunto ===

Nota sulle mani: nelle trascrizioni della fonte le cartine indicate con "x" sono state sostituite da carte basse non duplicate, perché il parser delle mani non accetta le "x".

Con questa mano (3 picche, 1 cuori, 3 quadri, 6 fiori) un buon naturalista apre di 1{{fiori}} e, se il compagno risponde 1 in un nobile, dichiara 2{{quadri}}:

<hand>AJ4.2.KQ3.AKJ765</hand>

I motivi sono tre:

* è l'unico modo per tenere aperta la dichiarazione (un rever a colore nuovo è forzante anche nel liscione);

* si evita di rischiare il passo e di mortificare la mano con il salto 1{{fiori}} - 3{{fiori}} ("uno poi tre" rappresenta piccoli rever di 15/17 punti);

* il compagno, anche se dovesse preferire le quadri, sarà portato a rispettare le pressioni della mano forte, tanto più trattandosi di colori entrambi minori.

Le quadri sono terze e il compagno non lo sa, ma poco importa, tanto è forzante. Allora "tanto vale codificarlo".

== Presupposti: quale rever è convenzionale ==

Condizioni: apertura in un minore; risposta uno su uno a colore; nessun intervento avversario; la dichiarazione è il più economico dei possibili rever a colore nuovo. Non tutti i rever dell'apertore sono convenzionali: lo è solo "il primo rever possibile", cioè la più bassa dichiarazione di livello due che rappresenti un rever.

Le sequenze convenzionali sono esattamente cinque (tre con partenza fiori, due con quadri):

<bidding>1C P 1D P 2H(multirever)</bidding>

<bidding>1C P 1H P 2D(multirever)</bidding>

<bidding>1C P 1S P 2D(multirever)</bidding>

<bidding>1D P 1H P 2S(multirever)</bidding>

<bidding>1D P 1S P 2H(multirever)</bidding>

Restano rever "normali" (nulla cambia rispetto a prima) le sequenze seguenti:

<bidding>1C P 1D P 2S</bidding>

Non è il primo rever possibile: il primo sarebbe 2{{cuori}}.

<bidding>1C P 1H P 3H</bidding>

Non è una dichiarazione a colore nuovo (è un appoggio).

<bidding>1C P 1NT P 2D</bidding>

La convenzione non funziona su risposta di 1SA.

== Quali mani ==

Per cominciare, solo quattro possibilità:

# la monocolore minore di 18/20 punti (che attualmente non ha collocazione);

# la mano con vero rever 5/4 (il Rever Reale, RR);

# la mano con vero rever ma distribuzione 6/4;

# la mano sbilanciata di Gran Rever con fit quarto nel nobile di risposta.

Il rispondente, per chiedere, usa come relè interrogativo la prima dichiarazione possibile che non corrisponda né alla ripetizione del seme di risposta né al riporto nel minore di apertura.

Esempi di mani dell'apertore nella sequenza

<bidding>1D P 1S P 2H(multirever)</bidding>

* monocolore di quadri forte, più di "uno poi tre" ma non abbastanza per 2{{fiori}}; punteggio promesso 18-21 (13 carte):

<hand>2.AQ54.KQJ76.A83</hand>

* rever reale 5/4, punteggio 16-21 (13 carte):

<hand>2.KQ54.AQJ76.A83</hand>

* rever reale con distribuzione 6/4 ("un asso in più"), punteggio 16-21: la fonte riporta ♠Kx ♥KJxx ♦AKQxxxx ♣x, che contiene 14 carte (probabile refuso); la mano non viene quindi mostrata. Si tratta di una mano con sei o sette quadri e quattro cuori;

* rever nel nobile di risposta (picche), punteggio massimo 18-21 (13 carte):

<hand>KQ54.2.AKJT7.AQ8</hand>

=== La monocolore minore 18/20 ===

È il tipo di mano che costituisce il vero vantaggio del PRD. Poter dare una sesta o settima di quella forza (a volte con 17) permette di "abbassare" la soglia della descrizione di una monocolore di piccolo rever: prima era inquadrata nel range 15/17, ora si potrà far onore anche alla mano di 14 molto belli. Per esempio è legittimo aprire di 1{{quadri}} e ripeterla a salto su risposta di un nobile:

<hand>AJ4.2.AKQ765.983</hand>

=== Il rever sbilanciato con fit quarto ===

Crea un gradino espressivo in più per la bicolore di fit e amplia l'arco di punteggio. Da adesso, nell'ordine:

* '''1{{quadri}} 1{{cuori}} 3{{cuori}}''': appoggio a livello 3. Può "scendere" a coprire anche l'area dei 14/15 punti, con buone bicolori 5/4 e oltre, mai con la 4432. Campo di forza 14/16 (prima era 15/17); non tutti i 14, la fonte raccomanda solo quelli con cui sembra un peccato appoggiare soltanto a 2. Mano modello del punteggio minimo ("Distribuzione, mano pura, qualità dei punti. Se no, no."):

<bidding>1D P 1H P 3H</bidding>

<hand>2.AK54.AKT97.853</hand>

* '''1{{quadri}} 1{{cuori}} 4{{fiori}}''': appoggio a manche, diretto (nessun singolo che piaccia descrivere) o con le varie splinter. Mano forte ma "di prese" piuttosto che "di punti": una bella 6/4 o 7/4 di 15-16 punti con 8-9 vincenti teoriche. La mano di esempio della fonte (♠xxx ♥AQJx ♦AKJ10xx ♣-) contiene 14 carte (probabile refuso) e non viene mostrata.

<bidding>1D P 1H P 4C</bidding>

* '''1{{quadri}} 1{{cuori}} 2{{picche}}(*)''': il Multirever. Un rovescio fatto di "punti", troppi per una delle opzioni precedenti ma troppo pochi per l'apertura di 2{{fiori}}; mediamente una mano di circa 18, 19, 20.

<bidding>1D P 1H P 2S(multirever)</bidding>

Per confronto, la fonte riporta la sequenza seguente come "il massimo immaginabile": una mano che non ha voluto rischiare il passo, perché può far manche da sola o con un re o una dama al posto giusto.

<bidding>2C P 2H P 3H</bidding>

=== Rever reale 5/4 e rever reale 6/4 ===

Sono differenziati perché una mano con una sesta ha una affrancabile in più e con vie naturali sarebbe difficile descriverla: una licita per la 5/4 e una per la 6/4 o 7/4.

== Le ridichiarazioni del rispondente ==

Il Passo è impensabile (il secondo colore potrebbe essere vuoto). Per ognuna delle cinque sequenze le repliche possibili del rispondente sono le seguenti; la seconda dichiarazione elencata come "relè" è quella forzante.

{| class="wikitable"
! Sequenza
! Repliche del rispondente
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}}
| 2{{picche}} (relè), 2SA, 3{{fiori}}, 3{{quadri}}
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}}
| 2{{cuori}}, 2{{picche}} (relè), 2SA, 3{{fiori}}
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}}
| 2{{cuori}} (relè), 2{{picche}}, 2SA, 3{{fiori}}
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}}
| 2SA (relè), 3{{fiori}}, 3{{quadri}}, 3{{cuori}}
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}}
| 2{{picche}}, 2SA (relè), 3{{fiori}}, 3{{quadri}}
|}

In ognuna ci sono due dichiarazioni assolutamente scoraggianti:

* il riporto nel minore dell'apertore (debolissima: "giocherei un parziale nella tua lunga, in cui ho mediamente due/tre cartine");

* la ripetizione del proprio colore (anch'essa estremamente scoraggiante: lunga e desiderio di giocare quel parziale, salvo plusvalori e fit dell'apertore; tende a escludere visuale di manche: mediamente 4/5 punti, forse 6 brutti, e sei carte, cinque solo se annunciabili a livello due).

Rimangono due dichiarazioni, i senza atout e il quarto colore. Per ognuno dei cinque casi:

* la più economica è il '''relè''', tendenzialmente forzante a manche, con 6/7+ punti;

* la meno economica è il '''sign-off''' nel secondo colore detto dall'apertore, sempre che lo abbia davvero.

Quindi tre dichiarazioni deboli per arrestarsi al parziale in uno dei tre colori detti e un'unica dichiarazione forzante per chiedere all'apertore che tipo di rever possiede. Il relè si usa con tutte le mani con cui è legittimo affrontare almeno un tentativo di manche (sempre con 7+ punti, anche con 5/6 carini).

Sequenze forzanti (relè):

<bidding>1C P 1D P 2H(multirever) P 2S(rele)</bidding>

<bidding>1C P 1H P 2D(multirever) P 2S(rele)</bidding>

<bidding>1C P 1S P 2D(multirever) P 2H(rele)</bidding>

<bidding>1D P 1H P 2S(multirever) P 2NT(rele)</bidding>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele)</bidding>

Il sign-off (secondo footnote della fonte) è un segnale scoraggiante di arresto: "se hai per davvero il secondo colore che hai detto, giocherei un parziale nel secondo colore; nessuna prospettiva di manche: semplicemente aspetto di riportarti nel minore lungo perché se per caso hai davvero il secondo colore può darsi che te lo possa appoggiare". Il "gradino libero" è la più bassa dichiarazione a cui non sia già stato assegnato un significato particolare.

== L'apertore si descrive sul relè forzante ==

Regole mnemoniche:

* il primo gradino libero è sempre il '''Rever Reale''' (5/4);

* la ripetizione del '''minore di apertura''' mostra sempre la monocolore minore;

* la ripetizione del '''secondo colore''' mostra sempre la 6-4;

* l'appoggio a '''tre''' nel colore del rispondente mostra la sbilanciata 18-20 di Gran Rever con fit quarto.

Dopo il relè si dà per scontato che la coppia abbia la forza per la manche: nulla è più passabile sotto manche.

{| class="wikitable"
! Sequenza fino al relè
! 1° gradino libero: RR 5/4
! Ripetizione del minore: monocolore
! Ripetizione del 2° colore: RR 6-4
! Appoggio a tre: sbilanciata 18-20 con 4 carte
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{cuori}} (6 fiori, 4 cuori)
| 3{{quadri}} (4 quadri)
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{cuori}} (4 cuori)
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}} P 2{{cuori}}
| 2{{picche}} (nella fonte segnalato con "(!!!)")
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{picche}} (4 picche)
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{picche}} (6 quadri, 4 picche)
| 3{{cuori}} (4 cuori)
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{cuori}} (6 quadri, 4 cuori)
| 3{{picche}} (4 picche)
|}

=== Esempi dopo il relè ===

Nota sulle mani: le cartine "x" della fonte sono state sostituite da carte basse non duplicate; il "10" è scritto T.

'''Rever reale 5/4.''' Su 1{{quadri}} 1{{picche}} 2{{cuori}} il rispondente fa il relè 2SA; 3{{fiori}} (primo gradino libero) mostra il rever reale 5/4. Su 3{{picche}}, che allunga le picche, Sud appoggia; Nord capisce che la Q{{fiori}} è valore nullo e si accontenta.

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3C(RR) P 3S P 4S</bidding>

Sud (apertore):

<hand>AQ6.AJ97.AK976.4</hand>

Nord (rispondente):

<hand>JT872.Q85.Q2.AQ8</hand>

'''Monocolore forte.''' Sud svela la monocolore con la ripetizione del minore, Nord dichiara 3SA.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 3C(monocolore) P 3NT</bidding>

Sud (apertore):

<hand>AK5.A94.4.AQJ974</hand>

Nord (rispondente):

<hand>Q87.JT85.QJT2.K8</hand>

'''Il riporto è una replica debolissima.''' Secondo la fonte, il riporto significa: non vorrei giocare la manche neppure se hai il rever con fit quarto nel mio colore, a meno che tu non abbia "i serpenti in mano". Sud (apertore):

<hand>A4.K9.KQJ976.AJ5</hand>

Nord (rispondente):

<hand>J875.876.32.K876</hand>

<bidding>1D P 1S P 2H(multirever) P 3D P P</bidding>

'''Relè debole (secondo gradino libero).''' Nord ha una sola prospettiva di manche, il rever fiori-picche; il 2SA è il secondo gradino libero, debole, mentre il relè sarebbe stato 2{{cuori}}. Sud ridichiara a seconda della sua mano e dice 3{{quadri}} solo con la 5/4 minore e punteggio minimo; con 20 direbbe 3SA.

<bidding>1C P 1S P 2D(multirever) P 2NT P 3D P P</bidding>

Sud (apertore):

<hand>2.A63.KQ76.AKJ54</hand>

Nord (rispondente):

<hand>J9854.87.A985.87</hand>

'''Atout fissato nel nobile.''' Con il rever di appoggio quarto nel nobile l'atout è inequivocabilmente fissato: il 4{{quadri}} è una cue bid, non un ripensamento sull'atout. Sud (apertore):

<hand>AQJ4.3.AQJ765.A2</hand>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3S P 4D</bidding>

La mano di Nord riportata dalla fonte (♠K109xxx ♥xx ♦Kx ♣Qx) contiene soltanto 12 carte (probabile refuso) e non viene mostrata.

'''Minore dell'apertore fissato a livello 4.''' Il minore dell'apertore si può fissare dichiarandolo a livello 3 (comunque forzante) o a livello 4: inequivocabilmente atout fissato e visuale di slam. La mano limite si sarebbe espressa riportando a 3{{fiori}} subito, direttamente su 2{{cuori}}, evitando il relè.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 2NT P 4C</bidding>

Sud (apertore):

<hand>AK5.A876.2.AQJ98</hand>

Nord (rispondente):

<hand>43.KQ4.AJ83.K765</hand>

'''Arresto a livello di riporto, ma Sud chiama manche.''' Nord frena con la ripetizione del proprio colore, ma Sud, con la mano di fit a picche, chiama comunque manche.

<bidding>1D P 1S P 2H(multirever) P 2S P 4S</bidding>

Sud (apertore):

<hand>AKJ2.A82.KQJ4.J9</hand>

Nord (rispondente):

<hand>Q98764.K75.2.763</hand>

Nota: nella fonte il commento a questa sequenza contiene una formula poco chiara ("5 0 6??"); qui si riportano la sequenza e le mani con le cartine sostituite.

== Varianti ==

La fonte descrive una sola versione della convenzione e non menziona varianti: non sono note varianti significative e per questo non esistono pagine di variante.

== Vedi anche ==

* [[Splinter]]

== Fonti ==

I vincoli di distribuzione per il generatore di smazzate (campo shape_constraints) sono ricavati dalla trattazione di Marina Causa (Corso Preagonistica 2026); i range di punti sono indicativi.

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "03. Il Multirever, o Primo Rever Disponibile (PRD)" (PDF, 5 pagine). L'ideatore originale della convenzione non è indicato nella fonte.

Multirever

2026-10-20T07:17:12Z

Lpala: Aggiunti shape_constraints per il generatore di smazzate

{{DEFAULTSORT:Multirever}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di sviluppo]]
[[Categoria:Convenzioni di licita]]

= Multirever =

{{Convenzione
|nome=Multirever (Primo Rever Disponibile, PRD)
|tipologia=Sviluppo / Rever dell'apertore (rever ambiguo, forzante)
|scopo=Dopo apertura in un minore e risposta di 1 a colore, dare un significato convenzionale al primo rever a colore nuovo disponibile dell'apertore: una dichiarazione forzante e ambigua sulla tipologia della mano (sempre mano forte), chiarita dal rispondente con un relè e dalla successiva descrizione dell'apertore
|trigger=Apertura di 1{{fiori}} o 1{{quadri}}, risposta di uno a colore, nessun intervento avversario; la più economica tra le dichiarazioni di livello due a colore nuovo che rappresentino un rever. Le sequenze sono cinque: 1{{fiori}} 1{{quadri}} 2{{cuori}}; 1{{fiori}} 1{{cuori}} 2{{quadri}}; 1{{fiori}} 1{{picche}} 2{{quadri}}; 1{{quadri}} 1{{cuori}} 2{{picche}}; 1{{quadri}} 1{{picche}} 2{{cuori}}
|risposte=Il rispondente non passa mai (il secondo colore potrebbe essere vuoto). Tre repliche deboli: riporto nel minore di apertura (scoraggiantissima), ripetizione del proprio colore (scoraggiante), sign-off nel secondo colore dichiarato dall'apertore (la meno economica tra senza atout e quarto colore). Una replica forzante: il relè, la più economica tra senza atout e quarto colore (7+ punti, tendenzialmente forzante a manche). Sul relè l'apertore si descrive: primo gradino libero = rever reale 5/4; ripetizione del minore di apertura = monocolore minore; ripetizione del secondo colore = rever 6-4; appoggio a tre nel colore del rispondente = mano sbilanciata di 18-20 con fit quarto (Gran Rever)
|note=Ideatore non indicato nella fonte; descrizione secondo la trattazione di Marina Causa. Forzante senza eccezioni: l'apertore può anche non avere il secondo colore, ma ha sempre almeno 5 carte nel minore di apertura. Non è convenzionale ogni rever dell'apertore, solo il primo rever possibile; non vale su risposta di 1SA. Nessun intervento avversario. Non sono note varianti nella fonte
|tag_cc=rebid_rever
|tag_sistema=naturale
|shape_constraints = 1C-1D-2H mono: opener C:6+ hcp:18-21; responder D:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1D-2H RR 5/4: opener C:5 H:4 D:0-3 hcp:16-21; responder D:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1D-2H RR 6/4: opener C:6+ H:4 hcp:16-21; responder D:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1D-2H Gran rever: fit:D8+ opener C:5+ D:4 H:0-1 hcp:18-20; responder D:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1H-2D mono: opener C:6+ hcp:18-21; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1H-2D RR 5/4: opener C:5 D:4 H:0-3 hcp:16-21; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1H-2D RR 6/4: opener C:6+ D:4 hcp:16-21; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1H-2D Gran rever: fit:H8+ opener C:5+ H:4 D:0-1 hcp:18-20; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1S-2D mono: opener C:6+ hcp:18-21; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1S-2D RR 5/4: opener C:5 D:4 S:0-3 hcp:16-21; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1S-2D RR 6/4: opener C:6+ D:4 hcp:16-21; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1C-1S-2D Gran rever: fit:S8+ opener C:5+ S:4 D:0-1 hcp:18-20; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1H-2S mono: opener D:6+ hcp:18-21; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1H-2S RR 5/4: opener D:5 S:4 H:0-3 hcp:16-21; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1H-2S RR 6/4: opener D:6+ S:4 hcp:16-21; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1H-2S Gran rever: fit:H8+ opener D:5+ H:4 S:0-1 hcp:18-20; responder H:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1S-2H mono: opener D:6+ hcp:18-21; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1S-2H RR 5/4: opener D:5 H:4 S:0-3 hcp:16-21; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1S-2H RR 6/4: opener D:6+ H:4 hcp:16-21; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11 // 1D-1S-2H Gran rever: fit:S8+ opener D:5+ S:4 H:0-1 hcp:18-20; responder S:4+ hcp:6+; opp1 hcp:0-11; opp2 hcp:0-11
}}

Il '''Multirever''', detto anche '''Primo Rever Disponibile (PRD)''', è un rever ''ambiguo'' dell'apertore che segue un'apertura in un colore minore e una risposta di 1 a colore. Questa pagina riporta la trattazione di Marina Causa (vedi [[#Fonti|Fonti]]); l'ideatore originale della convenzione non è indicato nella fonte.

== Idea ==

Secondo la trattazione di Marina Causa, l'ambiguità del Multirever non riguarda la forza (è sempre una mano forte) ma la '''tipologia della mano'''. La dichiarazione, per esempio

<bidding>1D P 1S P 2H(multirever)</bidding>

non dice in modo univoco "ho una bicolore quadri-cuori di rovescio": il colore espresso è solo una delle possibilità. È un rever "Multicolor" la cui fisionomia si chiarisce dopo. È '''tassativamente forzante''': l'apertore potrebbe non avere affatto il secondo colore, ma ha sempre almeno 5 carte nel primo.

=== Lo spunto ===

Nota sulle mani: nelle trascrizioni della fonte le cartine indicate con "x" sono state sostituite da carte basse non duplicate, perché il parser delle mani non accetta le "x".

Con questa mano (3 picche, 1 cuori, 3 quadri, 6 fiori) un buon naturalista apre di 1{{fiori}} e, se il compagno risponde 1 in un nobile, dichiara 2{{quadri}}:

<hand>AJ4.2.KQ3.AKJ765</hand>

I motivi sono tre:

* è l'unico modo per tenere aperta la dichiarazione (un rever a colore nuovo è forzante anche nel liscione);

* si evita di rischiare il passo e di mortificare la mano con il salto 1{{fiori}} - 3{{fiori}} ("uno poi tre" rappresenta piccoli rever di 15/17 punti);

* il compagno, anche se dovesse preferire le quadri, sarà portato a rispettare le pressioni della mano forte, tanto più trattandosi di colori entrambi minori.

Le quadri sono terze e il compagno non lo sa, ma poco importa, tanto è forzante. Allora "tanto vale codificarlo".

== Presupposti: quale rever è convenzionale ==

Condizioni: apertura in un minore; risposta uno su uno a colore; nessun intervento avversario; la dichiarazione è il più economico dei possibili rever a colore nuovo. Non tutti i rever dell'apertore sono convenzionali: lo è solo "il primo rever possibile", cioè la più bassa dichiarazione di livello due che rappresenti un rever.

Le sequenze convenzionali sono esattamente cinque (tre con partenza fiori, due con quadri):

<bidding>1C P 1D P 2H(multirever)</bidding>

<bidding>1C P 1H P 2D(multirever)</bidding>

<bidding>1C P 1S P 2D(multirever)</bidding>

<bidding>1D P 1H P 2S(multirever)</bidding>

<bidding>1D P 1S P 2H(multirever)</bidding>

Restano rever "normali" (nulla cambia rispetto a prima) le sequenze seguenti:

<bidding>1C P 1D P 2S</bidding>

Non è il primo rever possibile: il primo sarebbe 2{{cuori}}.

<bidding>1C P 1H P 3H</bidding>

Non è una dichiarazione a colore nuovo (è un appoggio).

<bidding>1C P 1NT P 2D</bidding>

La convenzione non funziona su risposta di 1SA.

== Quali mani ==

Per cominciare, solo quattro possibilità:

# la monocolore minore di 18/20 punti (che attualmente non ha collocazione);

# la mano con vero rever 5/4 (il Rever Reale, RR);

# la mano con vero rever ma distribuzione 6/4;

# la mano sbilanciata di Gran Rever con fit quarto nel nobile di risposta.

Il rispondente, per chiedere, usa come relè interrogativo la prima dichiarazione possibile che non corrisponda né alla ripetizione del seme di risposta né al riporto nel minore di apertura.

Esempi di mani dell'apertore nella sequenza

<bidding>1D P 1S P 2H(multirever)</bidding>

* monocolore di quadri forte, più di "uno poi tre" ma non abbastanza per 2{{fiori}}; punteggio promesso 18-21 (13 carte):

<hand>2.AQ54.KQJ76.A83</hand>

* rever reale 5/4, punteggio 16-21 (13 carte):

<hand>2.KQ54.AQJ76.A83</hand>

* rever reale con distribuzione 6/4 ("un asso in più"), punteggio 16-21: la fonte riporta ♠Kx ♥KJxx ♦AKQxxxx ♣x, che contiene 14 carte (probabile refuso); la mano non viene quindi mostrata. Si tratta di una mano con sei o sette quadri e quattro cuori;

* rever nel nobile di risposta (picche), punteggio massimo 18-21 (13 carte):

<hand>KQ54.2.AKJT7.AQ8</hand>

=== La monocolore minore 18/20 ===

È il tipo di mano che costituisce il vero vantaggio del PRD. Poter dare una sesta o settima di quella forza (a volte con 17) permette di "abbassare" la soglia della descrizione di una monocolore di piccolo rever: prima era inquadrata nel range 15/17, ora si potrà far onore anche alla mano di 14 molto belli. Per esempio è legittimo aprire di 1{{quadri}} e ripeterla a salto su risposta di un nobile:

<hand>AJ4.2.AKQ765.983</hand>

=== Il rever sbilanciato con fit quarto ===

Crea un gradino espressivo in più per la bicolore di fit e amplia l'arco di punteggio. Da adesso, nell'ordine:

* '''1{{quadri}} 1{{cuori}} 3{{cuori}}''': appoggio a livello 3. Può "scendere" a coprire anche l'area dei 14/15 punti, con buone bicolori 5/4 e oltre, mai con la 4432. Campo di forza 14/16 (prima era 15/17); non tutti i 14, la fonte raccomanda solo quelli con cui sembra un peccato appoggiare soltanto a 2. Mano modello del punteggio minimo ("Distribuzione, mano pura, qualità dei punti. Se no, no."):

<bidding>1D P 1H P 3H</bidding>

<hand>2.AK54.AKT97.853</hand>

* '''1{{quadri}} 1{{cuori}} 4{{fiori}}''': appoggio a manche, diretto (nessun singolo che piaccia descrivere) o con le varie splinter. Mano forte ma "di prese" piuttosto che "di punti": una bella 6/4 o 7/4 di 15-16 punti con 8-9 vincenti teoriche. La mano di esempio della fonte (♠xxx ♥AQJx ♦AKJ10xx ♣-) contiene 14 carte (probabile refuso) e non viene mostrata.

<bidding>1D P 1H P 4C</bidding>

* '''1{{quadri}} 1{{cuori}} 2{{picche}}(*)''': il Multirever. Un rovescio fatto di "punti", troppi per una delle opzioni precedenti ma troppo pochi per l'apertura di 2{{fiori}}; mediamente una mano di circa 18, 19, 20.

<bidding>1D P 1H P 2S(multirever)</bidding>

Per confronto, la fonte riporta la sequenza seguente come "il massimo immaginabile": una mano che non ha voluto rischiare il passo, perché può far manche da sola o con un re o una dama al posto giusto.

<bidding>2C P 2H P 3H</bidding>

=== Rever reale 5/4 e rever reale 6/4 ===

Sono differenziati perché una mano con una sesta ha una affrancabile in più e con vie naturali sarebbe difficile descriverla: una licita per la 5/4 e una per la 6/4 o 7/4.

== Le ridichiarazioni del rispondente ==

Il Passo è impensabile (il secondo colore potrebbe essere vuoto). Per ognuna delle cinque sequenze le repliche possibili del rispondente sono le seguenti; la seconda dichiarazione elencata come "relè" è quella forzante.

{| class="wikitable"
! Sequenza
! Repliche del rispondente
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}}
| 2{{picche}} (relè), 2SA, 3{{fiori}}, 3{{quadri}}
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}}
| 2{{cuori}}, 2{{picche}} (relè), 2SA, 3{{fiori}}
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}}
| 2{{cuori}} (relè), 2{{picche}}, 2SA, 3{{fiori}}
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}}
| 2SA (relè), 3{{fiori}}, 3{{quadri}}, 3{{cuori}}
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}}
| 2{{picche}}, 2SA (relè), 3{{fiori}}, 3{{quadri}}
|}

In ognuna ci sono due dichiarazioni assolutamente scoraggianti:

* il riporto nel minore dell'apertore (debolissima: "giocherei un parziale nella tua lunga, in cui ho mediamente due/tre cartine");

* la ripetizione del proprio colore (anch'essa estremamente scoraggiante: lunga e desiderio di giocare quel parziale, salvo plusvalori e fit dell'apertore; tende a escludere visuale di manche: mediamente 4/5 punti, forse 6 brutti, e sei carte, cinque solo se annunciabili a livello due).

Rimangono due dichiarazioni, i senza atout e il quarto colore. Per ognuno dei cinque casi:

* la più economica è il '''relè''', tendenzialmente forzante a manche, con 6/7+ punti;

* la meno economica è il '''sign-off''' nel secondo colore detto dall'apertore, sempre che lo abbia davvero.

Quindi tre dichiarazioni deboli per arrestarsi al parziale in uno dei tre colori detti e un'unica dichiarazione forzante per chiedere all'apertore che tipo di rever possiede. Il relè si usa con tutte le mani con cui è legittimo affrontare almeno un tentativo di manche (sempre con 7+ punti, anche con 5/6 carini).

Sequenze forzanti (relè):

<bidding>1C P 1D P 2H(multirever) P 2S(rele)</bidding>

<bidding>1C P 1H P 2D(multirever) P 2S(rele)</bidding>

<bidding>1C P 1S P 2D(multirever) P 2H(rele)</bidding>

<bidding>1D P 1H P 2S(multirever) P 2NT(rele)</bidding>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele)</bidding>

Il sign-off (secondo footnote della fonte) è un segnale scoraggiante di arresto: "se hai per davvero il secondo colore che hai detto, giocherei un parziale nel secondo colore; nessuna prospettiva di manche: semplicemente aspetto di riportarti nel minore lungo perché se per caso hai davvero il secondo colore può darsi che te lo possa appoggiare". Il "gradino libero" è la più bassa dichiarazione a cui non sia già stato assegnato un significato particolare.

== L'apertore si descrive sul relè forzante ==

Regole mnemoniche:

* il primo gradino libero è sempre il '''Rever Reale''' (5/4);

* la ripetizione del '''minore di apertura''' mostra sempre la monocolore minore;

* la ripetizione del '''secondo colore''' mostra sempre la 6-4;

* l'appoggio a '''tre''' nel colore del rispondente mostra la sbilanciata 18-20 di Gran Rever con fit quarto.

Dopo il relè si dà per scontato che la coppia abbia la forza per la manche: nulla è più passabile sotto manche.

{| class="wikitable"
! Sequenza fino al relè
! 1° gradino libero: RR 5/4
! Ripetizione del minore: monocolore
! Ripetizione del 2° colore: RR 6-4
! Appoggio a tre: sbilanciata 18-20 con 4 carte
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{cuori}} (6 fiori, 4 cuori)
| 3{{quadri}} (4 quadri)
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{cuori}} (4 cuori)
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}} P 2{{cuori}}
| 2{{picche}} (nella fonte segnalato con "(!!!)")
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{picche}} (4 picche)
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{picche}} (6 quadri, 4 picche)
| 3{{cuori}} (4 cuori)
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{cuori}} (6 quadri, 4 cuori)
| 3{{picche}} (4 picche)
|}

=== Esempi dopo il relè ===

Nota sulle mani: le cartine "x" della fonte sono state sostituite da carte basse non duplicate; il "10" è scritto T.

'''Rever reale 5/4.''' Su 1{{quadri}} 1{{picche}} 2{{cuori}} il rispondente fa il relè 2SA; 3{{fiori}} (primo gradino libero) mostra il rever reale 5/4. Su 3{{picche}}, che allunga le picche, Sud appoggia; Nord capisce che la Q{{fiori}} è valore nullo e si accontenta.

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3C(RR) P 3S P 4S</bidding>

Sud (apertore):

<hand>AQ6.AJ97.AK976.4</hand>

Nord (rispondente):

<hand>JT872.Q85.Q2.AQ8</hand>

'''Monocolore forte.''' Sud svela la monocolore con la ripetizione del minore, Nord dichiara 3SA.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 3C(monocolore) P 3NT</bidding>

Sud (apertore):

<hand>AK5.A94.4.AQJ974</hand>

Nord (rispondente):

<hand>Q87.JT85.QJT2.K8</hand>

'''Il riporto è una replica debolissima.''' Secondo la fonte, il riporto significa: non vorrei giocare la manche neppure se hai il rever con fit quarto nel mio colore, a meno che tu non abbia "i serpenti in mano". Sud (apertore):

<hand>A4.K9.KQJ976.AJ5</hand>

Nord (rispondente):

<hand>J875.876.32.K876</hand>

<bidding>1D P 1S P 2H(multirever) P 3D P P</bidding>

'''Relè debole (secondo gradino libero).''' Nord ha una sola prospettiva di manche, il rever fiori-picche; il 2SA è il secondo gradino libero, debole, mentre il relè sarebbe stato 2{{cuori}}. Sud ridichiara a seconda della sua mano e dice 3{{quadri}} solo con la 5/4 minore e punteggio minimo; con 20 direbbe 3SA.

<bidding>1C P 1S P 2D(multirever) P 2NT P 3D P P</bidding>

Sud (apertore):

<hand>2.A63.KQ76.AKJ54</hand>

Nord (rispondente):

<hand>J9854.87.A985.87</hand>

'''Atout fissato nel nobile.''' Con il rever di appoggio quarto nel nobile l'atout è inequivocabilmente fissato: il 4{{quadri}} è una cue bid, non un ripensamento sull'atout. Sud (apertore):

<hand>AQJ4.3.AQJ765.A2</hand>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3S P 4D</bidding>

La mano di Nord riportata dalla fonte (♠K109xxx ♥xx ♦Kx ♣Qx) contiene soltanto 12 carte (probabile refuso) e non viene mostrata.

'''Minore dell'apertore fissato a livello 4.''' Il minore dell'apertore si può fissare dichiarandolo a livello 3 (comunque forzante) o a livello 4: inequivocabilmente atout fissato e visuale di slam. La mano limite si sarebbe espressa riportando a 3{{fiori}} subito, direttamente su 2{{cuori}}, evitando il relè.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 2NT P 4C</bidding>

Sud (apertore):

<hand>AK5.A876.2.AQJ98</hand>

Nord (rispondente):

<hand>43.KQ4.AJ83.K765</hand>

'''Arresto a livello di riporto, ma Sud chiama manche.''' Nord frena con la ripetizione del proprio colore, ma Sud, con la mano di fit a picche, chiama comunque manche.

<bidding>1D P 1S P 2H(multirever) P 2S P 4S</bidding>

Sud (apertore):

<hand>AKJ2.A82.KQJ4.J9</hand>

Nord (rispondente):

<hand>Q98764.K75.2.763</hand>

Nota: nella fonte il commento a questa sequenza contiene una formula poco chiara ("5 0 6??"); qui si riportano la sequenza e le mani con le cartine sostituite.

== Varianti ==

La fonte descrive una sola versione della convenzione e non menziona varianti: non sono note varianti significative e per questo non esistono pagine di variante.

== Vedi anche ==

* [[Splinter]]

== Fonti ==

I vincoli di distribuzione per il generatore di smazzate (campo shape_constraints) sono ricavati dalla trattazione di Marina Causa (Corso Preagonistica 2026); i range di punti sono indicativi.

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "03. Il Multirever, o Primo Rever Disponibile (PRD)" (PDF, 5 pagine). L'ideatore originale della convenzione non è indicato nella fonte.

Multirever

2026-10-20T07:09:12Z

Lpala: Aggiunto tag_cc rebid_rever

{{DEFAULTSORT:Multirever}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di sviluppo]]
[[Categoria:Convenzioni di licita]]

= Multirever =

{{Convenzione
|nome=Multirever (Primo Rever Disponibile, PRD)
|tipologia=Sviluppo / Rever dell'apertore (rever ambiguo, forzante)
|scopo=Dopo apertura in un minore e risposta di 1 a colore, dare un significato convenzionale al primo rever a colore nuovo disponibile dell'apertore: una dichiarazione forzante e ambigua sulla tipologia della mano (sempre mano forte), chiarita dal rispondente con un relè e dalla successiva descrizione dell'apertore
|trigger=Apertura di 1{{fiori}} o 1{{quadri}}, risposta di uno a colore, nessun intervento avversario; la più economica tra le dichiarazioni di livello due a colore nuovo che rappresentino un rever. Le sequenze sono cinque: 1{{fiori}} 1{{quadri}} 2{{cuori}}; 1{{fiori}} 1{{cuori}} 2{{quadri}}; 1{{fiori}} 1{{picche}} 2{{quadri}}; 1{{quadri}} 1{{cuori}} 2{{picche}}; 1{{quadri}} 1{{picche}} 2{{cuori}}
|risposte=Il rispondente non passa mai (il secondo colore potrebbe essere vuoto). Tre repliche deboli: riporto nel minore di apertura (scoraggiantissima), ripetizione del proprio colore (scoraggiante), sign-off nel secondo colore dichiarato dall'apertore (la meno economica tra senza atout e quarto colore). Una replica forzante: il relè, la più economica tra senza atout e quarto colore (7+ punti, tendenzialmente forzante a manche). Sul relè l'apertore si descrive: primo gradino libero = rever reale 5/4; ripetizione del minore di apertura = monocolore minore; ripetizione del secondo colore = rever 6-4; appoggio a tre nel colore del rispondente = mano sbilanciata di 18-20 con fit quarto (Gran Rever)
|note=Ideatore non indicato nella fonte; descrizione secondo la trattazione di Marina Causa. Forzante senza eccezioni: l'apertore può anche non avere il secondo colore, ma ha sempre almeno 5 carte nel minore di apertura. Non è convenzionale ogni rever dell'apertore, solo il primo rever possibile; non vale su risposta di 1SA. Nessun intervento avversario. Non sono note varianti nella fonte
|tag_cc=rebid_rever
|tag_sistema=naturale
}}

Il '''Multirever''', detto anche '''Primo Rever Disponibile (PRD)''', è un rever ''ambiguo'' dell'apertore che segue un'apertura in un colore minore e una risposta di 1 a colore. Questa pagina riporta la trattazione di Marina Causa (vedi [[#Fonti|Fonti]]); l'ideatore originale della convenzione non è indicato nella fonte.

== Idea ==

Secondo la trattazione di Marina Causa, l'ambiguità del Multirever non riguarda la forza (è sempre una mano forte) ma la '''tipologia della mano'''. La dichiarazione, per esempio

<bidding>1D P 1S P 2H(multirever)</bidding>

non dice in modo univoco "ho una bicolore quadri-cuori di rovescio": il colore espresso è solo una delle possibilità. È un rever "Multicolor" la cui fisionomia si chiarisce dopo. È '''tassativamente forzante''': l'apertore potrebbe non avere affatto il secondo colore, ma ha sempre almeno 5 carte nel primo.

=== Lo spunto ===

Nota sulle mani: nelle trascrizioni della fonte le cartine indicate con "x" sono state sostituite da carte basse non duplicate, perché il parser delle mani non accetta le "x".

Con questa mano (3 picche, 1 cuori, 3 quadri, 6 fiori) un buon naturalista apre di 1{{fiori}} e, se il compagno risponde 1 in un nobile, dichiara 2{{quadri}}:

<hand>AJ4.2.KQ3.AKJ765</hand>

I motivi sono tre:

* è l'unico modo per tenere aperta la dichiarazione (un rever a colore nuovo è forzante anche nel liscione);

* si evita di rischiare il passo e di mortificare la mano con il salto 1{{fiori}} - 3{{fiori}} ("uno poi tre" rappresenta piccoli rever di 15/17 punti);

* il compagno, anche se dovesse preferire le quadri, sarà portato a rispettare le pressioni della mano forte, tanto più trattandosi di colori entrambi minori.

Le quadri sono terze e il compagno non lo sa, ma poco importa, tanto è forzante. Allora "tanto vale codificarlo".

== Presupposti: quale rever è convenzionale ==

Condizioni: apertura in un minore; risposta uno su uno a colore; nessun intervento avversario; la dichiarazione è il più economico dei possibili rever a colore nuovo. Non tutti i rever dell'apertore sono convenzionali: lo è solo "il primo rever possibile", cioè la più bassa dichiarazione di livello due che rappresenti un rever.

Le sequenze convenzionali sono esattamente cinque (tre con partenza fiori, due con quadri):

<bidding>1C P 1D P 2H(multirever)</bidding>

<bidding>1C P 1H P 2D(multirever)</bidding>

<bidding>1C P 1S P 2D(multirever)</bidding>

<bidding>1D P 1H P 2S(multirever)</bidding>

<bidding>1D P 1S P 2H(multirever)</bidding>

Restano rever "normali" (nulla cambia rispetto a prima) le sequenze seguenti:

<bidding>1C P 1D P 2S</bidding>

Non è il primo rever possibile: il primo sarebbe 2{{cuori}}.

<bidding>1C P 1H P 3H</bidding>

Non è una dichiarazione a colore nuovo (è un appoggio).

<bidding>1C P 1NT P 2D</bidding>

La convenzione non funziona su risposta di 1SA.

== Quali mani ==

Per cominciare, solo quattro possibilità:

# la monocolore minore di 18/20 punti (che attualmente non ha collocazione);

# la mano con vero rever 5/4 (il Rever Reale, RR);

# la mano con vero rever ma distribuzione 6/4;

# la mano sbilanciata di Gran Rever con fit quarto nel nobile di risposta.

Il rispondente, per chiedere, usa come relè interrogativo la prima dichiarazione possibile che non corrisponda né alla ripetizione del seme di risposta né al riporto nel minore di apertura.

Esempi di mani dell'apertore nella sequenza

<bidding>1D P 1S P 2H(multirever)</bidding>

* monocolore di quadri forte, più di "uno poi tre" ma non abbastanza per 2{{fiori}}; punteggio promesso 18-21 (13 carte):

<hand>2.AQ54.KQJ76.A83</hand>

* rever reale 5/4, punteggio 16-21 (13 carte):

<hand>2.KQ54.AQJ76.A83</hand>

* rever reale con distribuzione 6/4 ("un asso in più"), punteggio 16-21: la fonte riporta ♠Kx ♥KJxx ♦AKQxxxx ♣x, che contiene 14 carte (probabile refuso); la mano non viene quindi mostrata. Si tratta di una mano con sei o sette quadri e quattro cuori;

* rever nel nobile di risposta (picche), punteggio massimo 18-21 (13 carte):

<hand>KQ54.2.AKJT7.AQ8</hand>

=== La monocolore minore 18/20 ===

È il tipo di mano che costituisce il vero vantaggio del PRD. Poter dare una sesta o settima di quella forza (a volte con 17) permette di "abbassare" la soglia della descrizione di una monocolore di piccolo rever: prima era inquadrata nel range 15/17, ora si potrà far onore anche alla mano di 14 molto belli. Per esempio è legittimo aprire di 1{{quadri}} e ripeterla a salto su risposta di un nobile:

<hand>AJ4.2.AKQ765.983</hand>

=== Il rever sbilanciato con fit quarto ===

Crea un gradino espressivo in più per la bicolore di fit e amplia l'arco di punteggio. Da adesso, nell'ordine:

* '''1{{quadri}} 1{{cuori}} 3{{cuori}}''': appoggio a livello 3. Può "scendere" a coprire anche l'area dei 14/15 punti, con buone bicolori 5/4 e oltre, mai con la 4432. Campo di forza 14/16 (prima era 15/17); non tutti i 14, la fonte raccomanda solo quelli con cui sembra un peccato appoggiare soltanto a 2. Mano modello del punteggio minimo ("Distribuzione, mano pura, qualità dei punti. Se no, no."):

<bidding>1D P 1H P 3H</bidding>

<hand>2.AK54.AKT97.853</hand>

* '''1{{quadri}} 1{{cuori}} 4{{fiori}}''': appoggio a manche, diretto (nessun singolo che piaccia descrivere) o con le varie splinter. Mano forte ma "di prese" piuttosto che "di punti": una bella 6/4 o 7/4 di 15-16 punti con 8-9 vincenti teoriche. La mano di esempio della fonte (♠xxx ♥AQJx ♦AKJ10xx ♣-) contiene 14 carte (probabile refuso) e non viene mostrata.

<bidding>1D P 1H P 4C</bidding>

* '''1{{quadri}} 1{{cuori}} 2{{picche}}(*)''': il Multirever. Un rovescio fatto di "punti", troppi per una delle opzioni precedenti ma troppo pochi per l'apertura di 2{{fiori}}; mediamente una mano di circa 18, 19, 20.

<bidding>1D P 1H P 2S(multirever)</bidding>

Per confronto, la fonte riporta la sequenza seguente come "il massimo immaginabile": una mano che non ha voluto rischiare il passo, perché può far manche da sola o con un re o una dama al posto giusto.

<bidding>2C P 2H P 3H</bidding>

=== Rever reale 5/4 e rever reale 6/4 ===

Sono differenziati perché una mano con una sesta ha una affrancabile in più e con vie naturali sarebbe difficile descriverla: una licita per la 5/4 e una per la 6/4 o 7/4.

== Le ridichiarazioni del rispondente ==

Il Passo è impensabile (il secondo colore potrebbe essere vuoto). Per ognuna delle cinque sequenze le repliche possibili del rispondente sono le seguenti; la seconda dichiarazione elencata come "relè" è quella forzante.

{| class="wikitable"
! Sequenza
! Repliche del rispondente
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}}
| 2{{picche}} (relè), 2SA, 3{{fiori}}, 3{{quadri}}
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}}
| 2{{cuori}}, 2{{picche}} (relè), 2SA, 3{{fiori}}
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}}
| 2{{cuori}} (relè), 2{{picche}}, 2SA, 3{{fiori}}
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}}
| 2SA (relè), 3{{fiori}}, 3{{quadri}}, 3{{cuori}}
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}}
| 2{{picche}}, 2SA (relè), 3{{fiori}}, 3{{quadri}}
|}

In ognuna ci sono due dichiarazioni assolutamente scoraggianti:

* il riporto nel minore dell'apertore (debolissima: "giocherei un parziale nella tua lunga, in cui ho mediamente due/tre cartine");

* la ripetizione del proprio colore (anch'essa estremamente scoraggiante: lunga e desiderio di giocare quel parziale, salvo plusvalori e fit dell'apertore; tende a escludere visuale di manche: mediamente 4/5 punti, forse 6 brutti, e sei carte, cinque solo se annunciabili a livello due).

Rimangono due dichiarazioni, i senza atout e il quarto colore. Per ognuno dei cinque casi:

* la più economica è il '''relè''', tendenzialmente forzante a manche, con 6/7+ punti;

* la meno economica è il '''sign-off''' nel secondo colore detto dall'apertore, sempre che lo abbia davvero.

Quindi tre dichiarazioni deboli per arrestarsi al parziale in uno dei tre colori detti e un'unica dichiarazione forzante per chiedere all'apertore che tipo di rever possiede. Il relè si usa con tutte le mani con cui è legittimo affrontare almeno un tentativo di manche (sempre con 7+ punti, anche con 5/6 carini).

Sequenze forzanti (relè):

<bidding>1C P 1D P 2H(multirever) P 2S(rele)</bidding>

<bidding>1C P 1H P 2D(multirever) P 2S(rele)</bidding>

<bidding>1C P 1S P 2D(multirever) P 2H(rele)</bidding>

<bidding>1D P 1H P 2S(multirever) P 2NT(rele)</bidding>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele)</bidding>

Il sign-off (secondo footnote della fonte) è un segnale scoraggiante di arresto: "se hai per davvero il secondo colore che hai detto, giocherei un parziale nel secondo colore; nessuna prospettiva di manche: semplicemente aspetto di riportarti nel minore lungo perché se per caso hai davvero il secondo colore può darsi che te lo possa appoggiare". Il "gradino libero" è la più bassa dichiarazione a cui non sia già stato assegnato un significato particolare.

== L'apertore si descrive sul relè forzante ==

Regole mnemoniche:

* il primo gradino libero è sempre il '''Rever Reale''' (5/4);

* la ripetizione del '''minore di apertura''' mostra sempre la monocolore minore;

* la ripetizione del '''secondo colore''' mostra sempre la 6-4;

* l'appoggio a '''tre''' nel colore del rispondente mostra la sbilanciata 18-20 di Gran Rever con fit quarto.

Dopo il relè si dà per scontato che la coppia abbia la forza per la manche: nulla è più passabile sotto manche.

{| class="wikitable"
! Sequenza fino al relè
! 1° gradino libero: RR 5/4
! Ripetizione del minore: monocolore
! Ripetizione del 2° colore: RR 6-4
! Appoggio a tre: sbilanciata 18-20 con 4 carte
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{cuori}} (6 fiori, 4 cuori)
| 3{{quadri}} (4 quadri)
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{cuori}} (4 cuori)
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}} P 2{{cuori}}
| 2{{picche}} (nella fonte segnalato con "(!!!)")
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{picche}} (4 picche)
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{picche}} (6 quadri, 4 picche)
| 3{{cuori}} (4 cuori)
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{cuori}} (6 quadri, 4 cuori)
| 3{{picche}} (4 picche)
|}

=== Esempi dopo il relè ===

Nota sulle mani: le cartine "x" della fonte sono state sostituite da carte basse non duplicate; il "10" è scritto T.

'''Rever reale 5/4.''' Su 1{{quadri}} 1{{picche}} 2{{cuori}} il rispondente fa il relè 2SA; 3{{fiori}} (primo gradino libero) mostra il rever reale 5/4. Su 3{{picche}}, che allunga le picche, Sud appoggia; Nord capisce che la Q{{fiori}} è valore nullo e si accontenta.

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3C(RR) P 3S P 4S</bidding>

Sud (apertore):

<hand>AQ6.AJ97.AK976.4</hand>

Nord (rispondente):

<hand>JT872.Q85.Q2.AQ8</hand>

'''Monocolore forte.''' Sud svela la monocolore con la ripetizione del minore, Nord dichiara 3SA.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 3C(monocolore) P 3NT</bidding>

Sud (apertore):

<hand>AK5.A94.4.AQJ974</hand>

Nord (rispondente):

<hand>Q87.JT85.QJT2.K8</hand>

'''Il riporto è una replica debolissima.''' Secondo la fonte, il riporto significa: non vorrei giocare la manche neppure se hai il rever con fit quarto nel mio colore, a meno che tu non abbia "i serpenti in mano". Sud (apertore):

<hand>A4.K9.KQJ976.AJ5</hand>

Nord (rispondente):

<hand>J875.876.32.K876</hand>

<bidding>1D P 1S P 2H(multirever) P 3D P P</bidding>

'''Relè debole (secondo gradino libero).''' Nord ha una sola prospettiva di manche, il rever fiori-picche; il 2SA è il secondo gradino libero, debole, mentre il relè sarebbe stato 2{{cuori}}. Sud ridichiara a seconda della sua mano e dice 3{{quadri}} solo con la 5/4 minore e punteggio minimo; con 20 direbbe 3SA.

<bidding>1C P 1S P 2D(multirever) P 2NT P 3D P P</bidding>

Sud (apertore):

<hand>2.A63.KQ76.AKJ54</hand>

Nord (rispondente):

<hand>J9854.87.A985.87</hand>

'''Atout fissato nel nobile.''' Con il rever di appoggio quarto nel nobile l'atout è inequivocabilmente fissato: il 4{{quadri}} è una cue bid, non un ripensamento sull'atout. Sud (apertore):

<hand>AQJ4.3.AQJ765.A2</hand>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3S P 4D</bidding>

La mano di Nord riportata dalla fonte (♠K109xxx ♥xx ♦Kx ♣Qx) contiene soltanto 12 carte (probabile refuso) e non viene mostrata.

'''Minore dell'apertore fissato a livello 4.''' Il minore dell'apertore si può fissare dichiarandolo a livello 3 (comunque forzante) o a livello 4: inequivocabilmente atout fissato e visuale di slam. La mano limite si sarebbe espressa riportando a 3{{fiori}} subito, direttamente su 2{{cuori}}, evitando il relè.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 2NT P 4C</bidding>

Sud (apertore):

<hand>AK5.A876.2.AQJ98</hand>

Nord (rispondente):

<hand>43.KQ4.AJ83.K765</hand>

'''Arresto a livello di riporto, ma Sud chiama manche.''' Nord frena con la ripetizione del proprio colore, ma Sud, con la mano di fit a picche, chiama comunque manche.

<bidding>1D P 1S P 2H(multirever) P 2S P 4S</bidding>

Sud (apertore):

<hand>AKJ2.A82.KQJ4.J9</hand>

Nord (rispondente):

<hand>Q98764.K75.2.763</hand>

Nota: nella fonte il commento a questa sequenza contiene una formula poco chiara ("5 0 6??"); qui si riportano la sequenza e le mani con le cartine sostituite.

== Varianti ==

La fonte descrive una sola versione della convenzione e non menziona varianti: non sono note varianti significative e per questo non esistono pagine di variante.

== Vedi anche ==

* [[Splinter]]

== Fonti ==

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "03. Il Multirever, o Primo Rever Disponibile (PRD)" (PDF, 5 pagine). L'ideatore originale della convenzione non è indicato nella fonte.

Multirever

2026-10-20T07:05:28Z

Lpala: Creazione pagina Multirever (PRD) da dispensa di Marina Causa

{{DEFAULTSORT:Multirever}}
[[Categoria:Convenzioni]]
[[Categoria:Convenzioni di sviluppo]]
[[Categoria:Convenzioni di licita]]

= Multirever =

{{Convenzione
|nome=Multirever (Primo Rever Disponibile, PRD)
|tipologia=Sviluppo / Rever dell'apertore (rever ambiguo, forzante)
|scopo=Dopo apertura in un minore e risposta di 1 a colore, dare un significato convenzionale al primo rever a colore nuovo disponibile dell'apertore: una dichiarazione forzante e ambigua sulla tipologia della mano (sempre mano forte), chiarita dal rispondente con un relè e dalla successiva descrizione dell'apertore
|trigger=Apertura di 1{{fiori}} o 1{{quadri}}, risposta di uno a colore, nessun intervento avversario; la più economica tra le dichiarazioni di livello due a colore nuovo che rappresentino un rever. Le sequenze sono cinque: 1{{fiori}} 1{{quadri}} 2{{cuori}}; 1{{fiori}} 1{{cuori}} 2{{quadri}}; 1{{fiori}} 1{{picche}} 2{{quadri}}; 1{{quadri}} 1{{cuori}} 2{{picche}}; 1{{quadri}} 1{{picche}} 2{{cuori}}
|risposte=Il rispondente non passa mai (il secondo colore potrebbe essere vuoto). Tre repliche deboli: riporto nel minore di apertura (scoraggiantissima), ripetizione del proprio colore (scoraggiante), sign-off nel secondo colore dichiarato dall'apertore (la meno economica tra senza atout e quarto colore). Una replica forzante: il relè, la più economica tra senza atout e quarto colore (7+ punti, tendenzialmente forzante a manche). Sul relè l'apertore si descrive: primo gradino libero = rever reale 5/4; ripetizione del minore di apertura = monocolore minore; ripetizione del secondo colore = rever 6-4; appoggio a tre nel colore del rispondente = mano sbilanciata di 18-20 con fit quarto (Gran Rever)
|note=Ideatore non indicato nella fonte; descrizione secondo la trattazione di Marina Causa. Forzante senza eccezioni: l'apertore può anche non avere il secondo colore, ma ha sempre almeno 5 carte nel minore di apertura. Non è convenzionale ogni rever dell'apertore, solo il primo rever possibile; non vale su risposta di 1SA. Nessun intervento avversario. Non sono note varianti nella fonte
|tag_cc=
|tag_sistema=naturale
}}

Il '''Multirever''', detto anche '''Primo Rever Disponibile (PRD)''', è un rever ''ambiguo'' dell'apertore che segue un'apertura in un colore minore e una risposta di 1 a colore. Questa pagina riporta la trattazione di Marina Causa (vedi [[#Fonti|Fonti]]); l'ideatore originale della convenzione non è indicato nella fonte.

== Idea ==

Secondo la trattazione di Marina Causa, l'ambiguità del Multirever non riguarda la forza (è sempre una mano forte) ma la '''tipologia della mano'''. La dichiarazione, per esempio

<bidding>1D P 1S P 2H(multirever)</bidding>

non dice in modo univoco "ho una bicolore quadri-cuori di rovescio": il colore espresso è solo una delle possibilità. È un rever "Multicolor" la cui fisionomia si chiarisce dopo. È '''tassativamente forzante''': l'apertore potrebbe non avere affatto il secondo colore, ma ha sempre almeno 5 carte nel primo.

=== Lo spunto ===

Nota sulle mani: nelle trascrizioni della fonte le cartine indicate con "x" sono state sostituite da carte basse non duplicate, perché il parser delle mani non accetta le "x".

Con questa mano (3 picche, 1 cuori, 3 quadri, 6 fiori) un buon naturalista apre di 1{{fiori}} e, se il compagno risponde 1 in un nobile, dichiara 2{{quadri}}:

<hand>AJ4.2.KQ3.AKJ765</hand>

I motivi sono tre:

* è l'unico modo per tenere aperta la dichiarazione (un rever a colore nuovo è forzante anche nel liscione);

* si evita di rischiare il passo e di mortificare la mano con il salto 1{{fiori}} - 3{{fiori}} ("uno poi tre" rappresenta piccoli rever di 15/17 punti);

* il compagno, anche se dovesse preferire le quadri, sarà portato a rispettare le pressioni della mano forte, tanto più trattandosi di colori entrambi minori.

Le quadri sono terze e il compagno non lo sa, ma poco importa, tanto è forzante. Allora "tanto vale codificarlo".

== Presupposti: quale rever è convenzionale ==

Condizioni: apertura in un minore; risposta uno su uno a colore; nessun intervento avversario; la dichiarazione è il più economico dei possibili rever a colore nuovo. Non tutti i rever dell'apertore sono convenzionali: lo è solo "il primo rever possibile", cioè la più bassa dichiarazione di livello due che rappresenti un rever.

Le sequenze convenzionali sono esattamente cinque (tre con partenza fiori, due con quadri):

<bidding>1C P 1D P 2H(multirever)</bidding>

<bidding>1C P 1H P 2D(multirever)</bidding>

<bidding>1C P 1S P 2D(multirever)</bidding>

<bidding>1D P 1H P 2S(multirever)</bidding>

<bidding>1D P 1S P 2H(multirever)</bidding>

Restano rever "normali" (nulla cambia rispetto a prima) le sequenze seguenti:

<bidding>1C P 1D P 2S</bidding>

Non è il primo rever possibile: il primo sarebbe 2{{cuori}}.

<bidding>1C P 1H P 3H</bidding>

Non è una dichiarazione a colore nuovo (è un appoggio).

<bidding>1C P 1NT P 2D</bidding>

La convenzione non funziona su risposta di 1SA.

== Quali mani ==

Per cominciare, solo quattro possibilità:

# la monocolore minore di 18/20 punti (che attualmente non ha collocazione);

# la mano con vero rever 5/4 (il Rever Reale, RR);

# la mano con vero rever ma distribuzione 6/4;

# la mano sbilanciata di Gran Rever con fit quarto nel nobile di risposta.

Il rispondente, per chiedere, usa come relè interrogativo la prima dichiarazione possibile che non corrisponda né alla ripetizione del seme di risposta né al riporto nel minore di apertura.

Esempi di mani dell'apertore nella sequenza

<bidding>1D P 1S P 2H(multirever)</bidding>

* monocolore di quadri forte, più di "uno poi tre" ma non abbastanza per 2{{fiori}}; punteggio promesso 18-21 (13 carte):

<hand>2.AQ54.KQJ76.A83</hand>

* rever reale 5/4, punteggio 16-21 (13 carte):

<hand>2.KQ54.AQJ76.A83</hand>

* rever reale con distribuzione 6/4 ("un asso in più"), punteggio 16-21: la fonte riporta ♠Kx ♥KJxx ♦AKQxxxx ♣x, che contiene 14 carte (probabile refuso); la mano non viene quindi mostrata. Si tratta di una mano con sei o sette quadri e quattro cuori;

* rever nel nobile di risposta (picche), punteggio massimo 18-21 (13 carte):

<hand>KQ54.2.AKJT7.AQ8</hand>

=== La monocolore minore 18/20 ===

È il tipo di mano che costituisce il vero vantaggio del PRD. Poter dare una sesta o settima di quella forza (a volte con 17) permette di "abbassare" la soglia della descrizione di una monocolore di piccolo rever: prima era inquadrata nel range 15/17, ora si potrà far onore anche alla mano di 14 molto belli. Per esempio è legittimo aprire di 1{{quadri}} e ripeterla a salto su risposta di un nobile:

<hand>AJ4.2.AKQ765.983</hand>

=== Il rever sbilanciato con fit quarto ===

Crea un gradino espressivo in più per la bicolore di fit e amplia l'arco di punteggio. Da adesso, nell'ordine:

* '''1{{quadri}} 1{{cuori}} 3{{cuori}}''': appoggio a livello 3. Può "scendere" a coprire anche l'area dei 14/15 punti, con buone bicolori 5/4 e oltre, mai con la 4432. Campo di forza 14/16 (prima era 15/17); non tutti i 14, la fonte raccomanda solo quelli con cui sembra un peccato appoggiare soltanto a 2. Mano modello del punteggio minimo ("Distribuzione, mano pura, qualità dei punti. Se no, no."):

<bidding>1D P 1H P 3H</bidding>

<hand>2.AK54.AKT97.853</hand>

* '''1{{quadri}} 1{{cuori}} 4{{fiori}}''': appoggio a manche, diretto (nessun singolo che piaccia descrivere) o con le varie splinter. Mano forte ma "di prese" piuttosto che "di punti": una bella 6/4 o 7/4 di 15-16 punti con 8-9 vincenti teoriche. La mano di esempio della fonte (♠xxx ♥AQJx ♦AKJ10xx ♣-) contiene 14 carte (probabile refuso) e non viene mostrata.

<bidding>1D P 1H P 4C</bidding>

* '''1{{quadri}} 1{{cuori}} 2{{picche}}(*)''': il Multirever. Un rovescio fatto di "punti", troppi per una delle opzioni precedenti ma troppo pochi per l'apertura di 2{{fiori}}; mediamente una mano di circa 18, 19, 20.

<bidding>1D P 1H P 2S(multirever)</bidding>

Per confronto, la fonte riporta la sequenza seguente come "il massimo immaginabile": una mano che non ha voluto rischiare il passo, perché può far manche da sola o con un re o una dama al posto giusto.

<bidding>2C P 2H P 3H</bidding>

=== Rever reale 5/4 e rever reale 6/4 ===

Sono differenziati perché una mano con una sesta ha una affrancabile in più e con vie naturali sarebbe difficile descriverla: una licita per la 5/4 e una per la 6/4 o 7/4.

== Le ridichiarazioni del rispondente ==

Il Passo è impensabile (il secondo colore potrebbe essere vuoto). Per ognuna delle cinque sequenze le repliche possibili del rispondente sono le seguenti; la seconda dichiarazione elencata come "relè" è quella forzante.

{| class="wikitable"
! Sequenza
! Repliche del rispondente
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}}
| 2{{picche}} (relè), 2SA, 3{{fiori}}, 3{{quadri}}
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}}
| 2{{cuori}}, 2{{picche}} (relè), 2SA, 3{{fiori}}
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}}
| 2{{cuori}} (relè), 2{{picche}}, 2SA, 3{{fiori}}
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}}
| 2SA (relè), 3{{fiori}}, 3{{quadri}}, 3{{cuori}}
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}}
| 2{{picche}}, 2SA (relè), 3{{fiori}}, 3{{quadri}}
|}

In ognuna ci sono due dichiarazioni assolutamente scoraggianti:

* il riporto nel minore dell'apertore (debolissima: "giocherei un parziale nella tua lunga, in cui ho mediamente due/tre cartine");

* la ripetizione del proprio colore (anch'essa estremamente scoraggiante: lunga e desiderio di giocare quel parziale, salvo plusvalori e fit dell'apertore; tende a escludere visuale di manche: mediamente 4/5 punti, forse 6 brutti, e sei carte, cinque solo se annunciabili a livello due).

Rimangono due dichiarazioni, i senza atout e il quarto colore. Per ognuno dei cinque casi:

* la più economica è il '''relè''', tendenzialmente forzante a manche, con 6/7+ punti;

* la meno economica è il '''sign-off''' nel secondo colore detto dall'apertore, sempre che lo abbia davvero.

Quindi tre dichiarazioni deboli per arrestarsi al parziale in uno dei tre colori detti e un'unica dichiarazione forzante per chiedere all'apertore che tipo di rever possiede. Il relè si usa con tutte le mani con cui è legittimo affrontare almeno un tentativo di manche (sempre con 7+ punti, anche con 5/6 carini).

Sequenze forzanti (relè):

<bidding>1C P 1D P 2H(multirever) P 2S(rele)</bidding>

<bidding>1C P 1H P 2D(multirever) P 2S(rele)</bidding>

<bidding>1C P 1S P 2D(multirever) P 2H(rele)</bidding>

<bidding>1D P 1H P 2S(multirever) P 2NT(rele)</bidding>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele)</bidding>

Il sign-off (secondo footnote della fonte) è un segnale scoraggiante di arresto: "se hai per davvero il secondo colore che hai detto, giocherei un parziale nel secondo colore; nessuna prospettiva di manche: semplicemente aspetto di riportarti nel minore lungo perché se per caso hai davvero il secondo colore può darsi che te lo possa appoggiare". Il "gradino libero" è la più bassa dichiarazione a cui non sia già stato assegnato un significato particolare.

== L'apertore si descrive sul relè forzante ==

Regole mnemoniche:

* il primo gradino libero è sempre il '''Rever Reale''' (5/4);

* la ripetizione del '''minore di apertura''' mostra sempre la monocolore minore;

* la ripetizione del '''secondo colore''' mostra sempre la 6-4;

* l'appoggio a '''tre''' nel colore del rispondente mostra la sbilanciata 18-20 di Gran Rever con fit quarto.

Dopo il relè si dà per scontato che la coppia abbia la forza per la manche: nulla è più passabile sotto manche.

{| class="wikitable"
! Sequenza fino al relè
! 1° gradino libero: RR 5/4
! Ripetizione del minore: monocolore
! Ripetizione del 2° colore: RR 6-4
! Appoggio a tre: sbilanciata 18-20 con 4 carte
|-
| 1{{fiori}} P 1{{quadri}} P 2{{cuori}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{cuori}} (6 fiori, 4 cuori)
| 3{{quadri}} (4 quadri)
|-
| 1{{fiori}} P 1{{cuori}} P 2{{quadri}} P 2{{picche}}
| 2SA
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{cuori}} (4 cuori)
|-
| 1{{fiori}} P 1{{picche}} P 2{{quadri}} P 2{{cuori}}
| 2{{picche}} (nella fonte segnalato con "(!!!)")
| 3{{fiori}}
| 3{{quadri}} (6 fiori, 4 quadri)
| 3{{picche}} (4 picche)
|-
| 1{{quadri}} P 1{{cuori}} P 2{{picche}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{picche}} (6 quadri, 4 picche)
| 3{{cuori}} (4 cuori)
|-
| 1{{quadri}} P 1{{picche}} P 2{{cuori}} P 2SA
| 3{{fiori}}
| 3{{quadri}}
| 3{{cuori}} (6 quadri, 4 cuori)
| 3{{picche}} (4 picche)
|}

=== Esempi dopo il relè ===

Nota sulle mani: le cartine "x" della fonte sono state sostituite da carte basse non duplicate; il "10" è scritto T.

'''Rever reale 5/4.''' Su 1{{quadri}} 1{{picche}} 2{{cuori}} il rispondente fa il relè 2SA; 3{{fiori}} (primo gradino libero) mostra il rever reale 5/4. Su 3{{picche}}, che allunga le picche, Sud appoggia; Nord capisce che la Q{{fiori}} è valore nullo e si accontenta.

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3C(RR) P 3S P 4S</bidding>

Sud (apertore):

<hand>AQ6.AJ97.AK976.4</hand>

Nord (rispondente):

<hand>JT872.Q85.Q2.AQ8</hand>

'''Monocolore forte.''' Sud svela la monocolore con la ripetizione del minore, Nord dichiara 3SA.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 3C(monocolore) P 3NT</bidding>

Sud (apertore):

<hand>AK5.A94.4.AQJ974</hand>

Nord (rispondente):

<hand>Q87.JT85.QJT2.K8</hand>

'''Il riporto è una replica debolissima.''' Secondo la fonte, il riporto significa: non vorrei giocare la manche neppure se hai il rever con fit quarto nel mio colore, a meno che tu non abbia "i serpenti in mano". Sud (apertore):

<hand>A4.K9.KQJ976.AJ5</hand>

Nord (rispondente):

<hand>J875.876.32.K876</hand>

<bidding>1D P 1S P 2H(multirever) P 3D P P</bidding>

'''Relè debole (secondo gradino libero).''' Nord ha una sola prospettiva di manche, il rever fiori-picche; il 2SA è il secondo gradino libero, debole, mentre il relè sarebbe stato 2{{cuori}}. Sud ridichiara a seconda della sua mano e dice 3{{quadri}} solo con la 5/4 minore e punteggio minimo; con 20 direbbe 3SA.

<bidding>1C P 1S P 2D(multirever) P 2NT P 3D P P</bidding>

Sud (apertore):

<hand>2.A63.KQ76.AKJ54</hand>

Nord (rispondente):

<hand>J9854.87.A985.87</hand>

'''Atout fissato nel nobile.''' Con il rever di appoggio quarto nel nobile l'atout è inequivocabilmente fissato: il 4{{quadri}} è una cue bid, non un ripensamento sull'atout. Sud (apertore):

<hand>AQJ4.3.AQJ765.A2</hand>

<bidding>1D P 1S P 2H(multirever) P 2NT(rele) P 3S P 4D</bidding>

La mano di Nord riportata dalla fonte (♠K109xxx ♥xx ♦Kx ♣Qx) contiene soltanto 12 carte (probabile refuso) e non viene mostrata.

'''Minore dell'apertore fissato a livello 4.''' Il minore dell'apertore si può fissare dichiarandolo a livello 3 (comunque forzante) o a livello 4: inequivocabilmente atout fissato e visuale di slam. La mano limite si sarebbe espressa riportando a 3{{fiori}} subito, direttamente su 2{{cuori}}, evitando il relè.

<bidding>1C P 1D P 2H(multirever) P 2S(rele) P 2NT P 4C</bidding>

Sud (apertore):

<hand>AK5.A876.2.AQJ98</hand>

Nord (rispondente):

<hand>43.KQ4.AJ83.K765</hand>

'''Arresto a livello di riporto, ma Sud chiama manche.''' Nord frena con la ripetizione del proprio colore, ma Sud, con la mano di fit a picche, chiama comunque manche.

<bidding>1D P 1S P 2H(multirever) P 2S P 4S</bidding>

Sud (apertore):

<hand>AKJ2.A82.KQJ4.J9</hand>

Nord (rispondente):

<hand>Q98764.K75.2.763</hand>

Nota: nella fonte il commento a questa sequenza contiene una formula poco chiara ("5 0 6??"); qui si riportano la sequenza e le mani con le cartine sostituite.

== Varianti ==

La fonte descrive una sola versione della convenzione e non menziona varianti: non sono note varianti significative e per questo non esistono pagine di variante.

== Vedi anche ==

* [[Splinter]]

== Fonti ==

* Marina Causa, ''Corso Preagonistica 2026'', dispensa "03. Il Multirever, o Primo Rever Disponibile (PRD)" (PDF, 5 pagine). L'ideatore originale della convenzione non è indicato nella fonte.

Glossario del bridge

2026-10-16T11:03:11Z

Lpala: Versione segnata per la traduzione

{{Glossario}}<languages/>
<translate>

'''Questo glossario definisce i termini più comuni utilizzati nel gioco del [[Regole del bridge|bridge]], sia nella fase di dichiarazione che in quella di gioco della carta.'''
</translate>

<translate>

L'elenco è in ordine alfabetico. Clicca su una lettera per navigare direttamente alla sezione corrispondente.
</translate>

<div style="text-align:center; font-size:1.2em; margin-bottom:15px;">
'''[[#A|A]] · [[#B|B]] · [[#C|C]] · [[#D|D]] · [[#F|F]] · [[#G|G]] · [[#I|I]] · [[#L|L]] · [[#M|M]] · [[#N|N]] · [[#O|O]] · [[#P|P]] · [[#Q|Q]] · [[#R|R]] · [[#S|S]] · [[#T|T]] · [[#V|V]]'''
</div>

__TOC__

== A ==
* <translate> '''Apertura''': La prima dichiarazione di un colore o a Senza Atout (diversa da "Passo") effettuata in una smazzata.</translate>
* <translate> '''Appoggio''': Dichiarazione che supporta il colore licitato dal compagno, indicando di possedere un buon numero di carte in quel seme (solitamente almeno tre).</translate>
* <translate> '''Atout''' (o ''Atù'', in inglese ''Trump''): Il seme che viene scelto come briscola durante la licitazione e che comanda su tutti gli altri semi durante il gioco della carta.</translate>
* <translate> '''Attacco''': La prima carta giocata dal difensore che si trova alla sinistra del dichiarante, all'inizio del gioco della carta. La scelta della carta d'attacco è un momento cruciale della difesa.</translate>

== B ==
* <translate> '''Bilanciata (Mano)''': Una mano con una distribuzione di carte equilibrata, senza vuoti o singleton e con al massimo un doubleton. Le distribuzioni tipiche sono 4-3-3-3, 4-4-3-2 e 5-3-3-2.</translate>
* <translate> '''Blackwood''': Una famosa convenzione dichiarativa (solitamente la licita di 4SA) usata per chiedere al compagno il numero di Assi (e talvolta Re) posseduti, al fine di esplorare la possibilità di giocare uno slam.</translate>

== C ==
* <translate> '''Colore''': Uno dei quattro semi delle carte: Fiori (♣), Quadri (♦), Cuori (♥) e Picche (♠).</translate>
* <translate> '''Contratto''': L'impegno finale preso da una coppia durante la fase di dichiarazione. Consiste in un numero di prese da effettuare (da 1 a 7) e un seme di atout (o Senza Atout).</translate>
* <translate> '''Contro''' (in inglese ''Double''): Una dichiarazione che aumenta il punteggio (sia in positivo che in negativo) del contratto avversario. Può avere un significato informativo (per descrivere la propria mano) o punitivo (se si pensa che gli avversari non possano mantenere il contratto).</translate>
* <translate> '''Convenzione''': Un accordo tra compagni su un significato artificiale o specifico di una determinata licita, che non corrisponde al suo significato naturale. Esempi famosi sono la Stayman e la Jacoby Transfer.</translate>
* <translate> '''Copertura''': Una carta che può vincere una presa dopo che una carta più alta dello stesso seme è già stata giocata.</translate>
* <translate> '''Cue Bid''': Una licita in un colore mostrato dagli avversari. Viene usata come licita forzante per mostrare una mano forte e chiedere maggiori informazioni al compagno.</translate>

== D ==
* <translate> '''Dichiarazione''' (o ''Licita''): Ogni offerta fatta da un giocatore durante la fase di licitazione (es. "1 Cuori", "Passo", "Contro").</translate>
* <translate> '''Dichiarante''': Il giocatore della coppia che per primo ha dichiarato il seme (o Senza Atout) del contratto finale. Il dichiarante gioca sia le proprie carte che quelle del morto.</translate>
* <translate> '''Difesa''': La coppia che non si è aggiudicata il contratto e che cerca di impedire al dichiarante di realizzare le prese necessarie.</translate>
* <translate> '''Distribuzione''': La suddivisione delle 13 carte di una mano nei quattro semi.</translate>

== F ==
* <translate> '''Fallo''' (o ''Scarto''): Giocare una carta di un seme diverso da quello di uscita, quando non si possiedono più carte di quel seme.</translate>
* <translate> '''Fit''': Avere un numero sufficiente di carte di un determinato seme in combinazione con il proprio compagno (solitamente almeno 8 carte in totale) per poterlo eleggere a seme di atout.</translate>
* <translate> '''Forzante''': Una dichiarazione che obbliga il compagno a parlare di nuovo, a meno che non intervengano gli avversari. Indica una mano forte o una situazione in cui è necessario scambiare altre informazioni.</translate>

== G ==
* <translate> '''Grande Slam''': Un contratto al livello di 7, che richiede di effettuare tutte le 13 prese possibili.</translate>
* <translate> '''Gioco''': La fase della smazzata che segue la dichiarazione, in cui i giocatori giocano le loro carte per effettuare le prese.</translate>

== I ==
* <translate> '''Impasso''' (in inglese ''Finesse''): Una tecnica di gioco che consiste nel tentare di vincere una presa con una carta più bassa, sperando che una carta avversaria più alta sia in una posizione favorevole.</translate>
* <translate> '''Invito''': Una dichiarazione che non è forzante, ma che invita il compagno a licitare un contratto superiore (solitamente a manche o a slam) se ha una mano non minima per le sue precedenti dichiarazioni.</translate>

== L ==
* <translate> '''Licita''': Vedi [[#D|Dichiarazione]].</translate>
* <translate> '''Linea''': Si usa per indicare le due coppie. La ''linea Nord-Sud'' e la ''linea Est-Ovest''.</translate>

== M ==
* <translate> '''Manche''': Un contratto il cui punteggio, se realizzato, è sufficiente a vincere una partita (es. 3 Senza Atout, 4 Cuori, 4 Picche, 5 Fiori, 5 Quadri).</translate>
* <translate> '''Mano''': Le 13 carte iniziali distribuite a un giocatore.</translate>
* <translate> '''Morto''' (in inglese ''Dummy''): Il compagno del dichiarante. Dopo l'attacco iniziale, il morto stende le proprie carte scoperte sul tavolo e non partecipa più attivamente al gioco; sarà il dichiarante a giocare le carte per lui.</translate>

== N ==
* <translate> '''Nobili (Semi)''': I semi di Cuori (♥) e Picche (♠), chiamati così perché valgono di più nel calcolo del punteggio (30 punti per presa) rispetto ai semi minori.</translate>

== O ==
* <translate> '''Onori''': Le cinque carte di maggior valore in ogni seme: Asso (A), Re (K), Donna (Q), Fante (J) e Dieci (10).</translate>

== P ==
* <translate> '''Passo''': Dichiarazione con cui un giocatore decide di non fare nessuna licita, contro o surcontro. Se tutti e quattro i giocatori passano all'inizio, le carte vengono raccolte e ridistribuite.</translate>
* <translate> '''Piccolo Slam''': Un contratto al livello di 6, che richiede di effettuare 12 prese su 13.</translate>
* <translate> '''Presa''': L'insieme delle quattro carte giocate in un round (una per ogni giocatore). La presa è vinta dal giocatore che ha giocato la carta più alta nel seme di uscita, o l'atout più alto.</translate>
* <translate> '''Punti Onori (PO)''': Un metodo di valutazione della forza di una mano basato sugli onori posseduti: Asso=4, Re=3, Donna=2, Fante=1.</translate>

== Q ==
* <translate> '''Qualificante''': Una mano o una licita che soddisfa i requisiti minimi per una determinata azione, secondo il sistema dichiarativo della coppia.</translate>

== R ==
* <translate> '''Rientro''': Una carta alta che permette di guadagnare la presa e quindi il controllo del gioco, consentendo di muovere da una delle due mani della coppia (dichiarante o morto).</translate>
* <translate> '''Rispondente''': Il compagno dell'apertore.</translate>

== S ==
* <translate> '''Scarto''': Vedi [[#F|Fallo]].</translate>
* <translate> '''Senza Atout (SA)''': Un contratto in cui non esiste un seme di atout. La presa è vinta semplicemente dalla carta più alta nel seme di uscita.</translate>
* <translate> '''Singleton''': Possedere una sola carta di un determinato seme.</translate>
* <translate> '''Squeeze''': Una tecnica di gioco avanzata con cui il dichiarante, giocando una carta vincente, costringe uno o entrambi i difensori a scartare una carta che custodiva una presa futura.</translate>
* <translate> '''Stayman''': Una convenzione (solitamente la licita di 2 Fiori in risposta a un'apertura a Senza Atout) usata per chiedere all'apertore se possiede un seme nobile di almeno quattro carte.</translate>
* <translate> '''Surcontro''' (in inglese ''Redouble''): Una dichiarazione fatta dopo un "Contro" avversario, che aumenta ulteriormente il valore del punteggio del contratto.</translate>

== T ==
* <translate> '''Taglio''' (o ''Tuffo''): Giocare una carta di atout quando non si possiedono più carte del seme di uscita. Il taglio permette di vincere una presa che altrimenti andrebbe agli avversari.</translate>

== V ==
* <translate> '''Vulnerabile''': Condizione di una coppia in una determinata smazzata che aumenta i bonus e le penalità. La vulnerabilità cambia secondo uno schema predefinito durante una partita.</translate>
* <translate> '''Vuoto''': Non possedere alcuna carta di un determinato seme.</translate>

<translate>
== Voci correlate == 
</translate>
* <translate> [[Storia del bridge]]</translate>
* <translate> [[Federazioni di bridge]]</translate>

[[Categoria:Bridge]]
[[Categoria:Glossario]]

Pagina principale

2026-10-16T11:03:11Z

Lpala: Versione segnata per la traduzione

{{Articolo}}<languages/>
<translate>
= Benvenuti su '''BridgePedia''' = 
</translate>

<translate>

'''BridgePedia''' è il punto di riferimento collaborativo per tutti i giocatori, le coppie e le associazioni che desiderano raccogliere, documentare e condividere le conoscenze sul gioco del bridge.
</translate>
<translate>

Qui troverai regole, licite, convenzioni e carte delle convenzioni, aggiornate e mantenute direttamente dagli utenti della comunità.
</translate>

<translate>
== Obiettivi == 
</translate>
* <translate> Rendere facilmente accessibili le [[Regole del bridge|regole ufficiali del bridge]].</translate>
* <translate> Documentare in modo strutturato le principali [[Licite|sequenze di licita]].</translate>
* <translate> Creare un archivio aggiornato delle [[Convenzioni|convenzioni più usate]].</translate>
* <translate> Fornire uno spazio per le [[Carte delle convenzioni|carte delle convenzioni di coppia e di squadra]].</translate>
* <translate> Offrire alle associazioni uno strumento condiviso per gestire e pubblicare materiali tecnici.</translate>

<translate>
== Come contribuire == 
</translate>
* <translate> Ogni utente registrato può modificare o integrare i contenuti esistenti.</translate>
* <translate> Per iniziare, visita la guida: [[Aiuto:Come modificare una pagina]].</translate>
* <translate> Usa i link interni (tra [[ ]]) per creare nuove voci.</translate>

<translate>
== Struttura del Wiki == 
</translate>
* <translate> [[Storia del bridge]] - come è nato e si è evoluto.</translate>
* <translate> [[Regole del bridge]] – regolamenti ufficiali e adattamenti locali.</translate>
* <translate> [[Licite]] – spiegazioni e sequenze tipiche.</translate>
* <translate> [[Convenzioni]] – elenchi e descrizioni di convenzioni (Stayman, Blackwood, ecc.).</translate>
* <translate> [[Carte delle convenzioni]] – schede personalizzate di coppia o associazione.</translate>
* <translate> [[Associazioni di bridge]] – spazi dedicati ad associazioni e circoli.</translate>
* <translate> [[Glossario del bridge]] – termini e definizioni.</translate>

<translate>
== Linee guida == 
</translate>
* <translate> Mantieni i contenuti chiari e neutrali.</translate>
* <translate> Cita fonti affidabili quando riporti regole ufficiali o documenti federali.</translate>
* <translate> Usa una terminologia coerente con il lessico del bridge.</translate>

<translate>
== Risorse utili == 
</translate>
* <translate> [https://www.federbridge.it/ FIGB – Federazione Italiana Gioco Bridge]</translate>
* <translate> [https://www.worldbridge.org/ WBF – World Bridge Federation]</translate>

----

{{Nota|<translate> Questa è una piattaforma collaborativa: ogni contributo è prezioso per arricchire la conoscenza condivisa sul bridge.</translate>}}

Glossario del bridge

2026-10-16T11:01:58Z

Lpala: Corretti link rossi (bridge, Voci correlate)

{{Glossario}}<languages/>
<translate>
'''Questo glossario definisce i termini più comuni utilizzati nel gioco del [[Regole del bridge|bridge]], sia nella fase di dichiarazione che in quella di gioco della carta.'''
</translate>

<translate>
L'elenco è in ordine alfabetico. Clicca su una lettera per navigare direttamente alla sezione corrispondente.
</translate>

<div style="text-align:center; font-size:1.2em; margin-bottom:15px;">
'''[[#A|A]] · [[#B|B]] · [[#C|C]] · [[#D|D]] · [[#F|F]] · [[#G|G]] · [[#I|I]] · [[#L|L]] · [[#M|M]] · [[#N|N]] · [[#O|O]] · [[#P|P]] · [[#Q|Q]] · [[#R|R]] · [[#S|S]] · [[#T|T]] · [[#V|V]]'''
</div>

__TOC__

== A ==
* <translate>'''Apertura''': La prima dichiarazione di un colore o a Senza Atout (diversa da "Passo") effettuata in una smazzata.</translate>
* <translate>'''Appoggio''': Dichiarazione che supporta il colore licitato dal compagno, indicando di possedere un buon numero di carte in quel seme (solitamente almeno tre).</translate>
* <translate>'''Atout''' (o ''Atù'', in inglese ''Trump''): Il seme che viene scelto come briscola durante la licitazione e che comanda su tutti gli altri semi durante il gioco della carta.</translate>
* <translate>'''Attacco''': La prima carta giocata dal difensore che si trova alla sinistra del dichiarante, all'inizio del gioco della carta. La scelta della carta d'attacco è un momento cruciale della difesa.</translate>

== B ==
* <translate>'''Bilanciata (Mano)''': Una mano con una distribuzione di carte equilibrata, senza vuoti o singleton e con al massimo un doubleton. Le distribuzioni tipiche sono 4-3-3-3, 4-4-3-2 e 5-3-3-2.</translate>
* <translate>'''Blackwood''': Una famosa convenzione dichiarativa (solitamente la licita di 4SA) usata per chiedere al compagno il numero di Assi (e talvolta Re) posseduti, al fine di esplorare la possibilità di giocare uno slam.</translate>

== C ==
* <translate>'''Colore''': Uno dei quattro semi delle carte: Fiori (♣), Quadri (♦), Cuori (♥) e Picche (♠).</translate>
* <translate>'''Contratto''': L'impegno finale preso da una coppia durante la fase di dichiarazione. Consiste in un numero di prese da effettuare (da 1 a 7) e un seme di atout (o Senza Atout).</translate>
* <translate>'''Contro''' (in inglese ''Double''): Una dichiarazione che aumenta il punteggio (sia in positivo che in negativo) del contratto avversario. Può avere un significato informativo (per descrivere la propria mano) o punitivo (se si pensa che gli avversari non possano mantenere il contratto).</translate>
* <translate>'''Convenzione''': Un accordo tra compagni su un significato artificiale o specifico di una determinata licita, che non corrisponde al suo significato naturale. Esempi famosi sono la Stayman e la Jacoby Transfer.</translate>
* <translate>'''Copertura''': Una carta che può vincere una presa dopo che una carta più alta dello stesso seme è già stata giocata.</translate>
* <translate>'''Cue Bid''': Una licita in un colore mostrato dagli avversari. Viene usata come licita forzante per mostrare una mano forte e chiedere maggiori informazioni al compagno.</translate>

== D ==
* <translate>'''Dichiarazione''' (o ''Licita''): Ogni offerta fatta da un giocatore durante la fase di licitazione (es. "1 Cuori", "Passo", "Contro").</translate>
* <translate>'''Dichiarante''': Il giocatore della coppia che per primo ha dichiarato il seme (o Senza Atout) del contratto finale. Il dichiarante gioca sia le proprie carte che quelle del morto.</translate>
* <translate>'''Difesa''': La coppia che non si è aggiudicata il contratto e che cerca di impedire al dichiarante di realizzare le prese necessarie.</translate>
* <translate>'''Distribuzione''': La suddivisione delle 13 carte di una mano nei quattro semi.</translate>

== F ==
* <translate>'''Fallo''' (o ''Scarto''): Giocare una carta di un seme diverso da quello di uscita, quando non si possiedono più carte di quel seme.</translate>
* <translate>'''Fit''': Avere un numero sufficiente di carte di un determinato seme in combinazione con il proprio compagno (solitamente almeno 8 carte in totale) per poterlo eleggere a seme di atout.</translate>
* <translate>'''Forzante''': Una dichiarazione che obbliga il compagno a parlare di nuovo, a meno che non intervengano gli avversari. Indica una mano forte o una situazione in cui è necessario scambiare altre informazioni.</translate>

== G ==
* <translate>'''Grande Slam''': Un contratto al livello di 7, che richiede di effettuare tutte le 13 prese possibili.</translate>
* <translate>'''Gioco''': La fase della smazzata che segue la dichiarazione, in cui i giocatori giocano le loro carte per effettuare le prese.</translate>

== I ==
* <translate>'''Impasso''' (in inglese ''Finesse''): Una tecnica di gioco che consiste nel tentare di vincere una presa con una carta più bassa, sperando che una carta avversaria più alta sia in una posizione favorevole.</translate>
* <translate>'''Invito''': Una dichiarazione che non è forzante, ma che invita il compagno a licitare un contratto superiore (solitamente a manche o a slam) se ha una mano non minima per le sue precedenti dichiarazioni.</translate>

== L ==
* <translate>'''Licita''': Vedi [[#D|Dichiarazione]].</translate>
* <translate>'''Linea''': Si usa per indicare le due coppie. La ''linea Nord-Sud'' e la ''linea Est-Ovest''.</translate>

== M ==
* <translate>'''Manche''': Un contratto il cui punteggio, se realizzato, è sufficiente a vincere una partita (es. 3 Senza Atout, 4 Cuori, 4 Picche, 5 Fiori, 5 Quadri).</translate>
* <translate>'''Mano''': Le 13 carte iniziali distribuite a un giocatore.</translate>
* <translate>'''Morto''' (in inglese ''Dummy''): Il compagno del dichiarante. Dopo l'attacco iniziale, il morto stende le proprie carte scoperte sul tavolo e non partecipa più attivamente al gioco; sarà il dichiarante a giocare le carte per lui.</translate>

== N ==
* <translate>'''Nobili (Semi)''': I semi di Cuori (♥) e Picche (♠), chiamati così perché valgono di più nel calcolo del punteggio (30 punti per presa) rispetto ai semi minori.</translate>

== O ==
* <translate>'''Onori''': Le cinque carte di maggior valore in ogni seme: Asso (A), Re (K), Donna (Q), Fante (J) e Dieci (10).</translate>

== P ==
* <translate>'''Passo''': Dichiarazione con cui un giocatore decide di non fare nessuna licita, contro o surcontro. Se tutti e quattro i giocatori passano all'inizio, le carte vengono raccolte e ridistribuite.</translate>
* <translate>'''Piccolo Slam''': Un contratto al livello di 6, che richiede di effettuare 12 prese su 13.</translate>
* <translate>'''Presa''': L'insieme delle quattro carte giocate in un round (una per ogni giocatore). La presa è vinta dal giocatore che ha giocato la carta più alta nel seme di uscita, o l'atout più alto.</translate>
* <translate>'''Punti Onori (PO)''': Un metodo di valutazione della forza di una mano basato sugli onori posseduti: Asso=4, Re=3, Donna=2, Fante=1.</translate>

== Q ==
* <translate>'''Qualificante''': Una mano o una licita che soddisfa i requisiti minimi per una determinata azione, secondo il sistema dichiarativo della coppia.</translate>

== R ==
* <translate>'''Rientro''': Una carta alta che permette di guadagnare la presa e quindi il controllo del gioco, consentendo di muovere da una delle due mani della coppia (dichiarante o morto).</translate>
* <translate>'''Rispondente''': Il compagno dell'apertore.</translate>

== S ==
* <translate>'''Scarto''': Vedi [[#F|Fallo]].</translate>
* <translate>'''Senza Atout (SA)''': Un contratto in cui non esiste un seme di atout. La presa è vinta semplicemente dalla carta più alta nel seme di uscita.</translate>
* <translate>'''Singleton''': Possedere una sola carta di un determinato seme.</translate>
* <translate>'''Squeeze''': Una tecnica di gioco avanzata con cui il dichiarante, giocando una carta vincente, costringe uno o entrambi i difensori a scartare una carta che custodiva una presa futura.</translate>
* <translate>'''Stayman''': Una convenzione (solitamente la licita di 2 Fiori in risposta a un'apertura a Senza Atout) usata per chiedere all'apertore se possiede un seme nobile di almeno quattro carte.</translate>
* <translate>'''Surcontro''' (in inglese ''Redouble''): Una dichiarazione fatta dopo un "Contro" avversario, che aumenta ulteriormente il valore del punteggio del contratto.</translate>

== T ==
* <translate>'''Taglio''' (o ''Tuffo''): Giocare una carta di atout quando non si possiedono più carte del seme di uscita. Il taglio permette di vincere una presa che altrimenti andrebbe agli avversari.</translate>

== V ==
* <translate>'''Vulnerabile''': Condizione di una coppia in una determinata smazzata che aumenta i bonus e le penalità. La vulnerabilità cambia secondo uno schema predefinito durante una partita.</translate>
* <translate>'''Vuoto''': Non possedere alcuna carta di un determinato seme.</translate>

<translate>
== Voci correlate ==
</translate>
* <translate>[[Storia del bridge]]</translate>
* <translate>[[Federazioni di bridge]]</translate>

[[Categoria:Bridge]]
[[Categoria:Glossario]]

Pagina principale

2026-10-16T11:01:57Z

Lpala: Nota: frase in translate

{{Articolo}}<languages/>
<translate>
= Benvenuti su '''BridgePedia''' =
</translate>

<translate>
'''BridgePedia''' è il punto di riferimento collaborativo per tutti i giocatori, le coppie e le associazioni che desiderano raccogliere, documentare e condividere le conoscenze sul gioco del bridge.
</translate>
<translate>
Qui troverai regole, licite, convenzioni e carte delle convenzioni, aggiornate e mantenute direttamente dagli utenti della comunità.
</translate>

<translate>
== Obiettivi ==
</translate>
* <translate>Rendere facilmente accessibili le [[Regole del bridge|regole ufficiali del bridge]].</translate>
* <translate>Documentare in modo strutturato le principali [[Licite|sequenze di licita]].</translate>
* <translate>Creare un archivio aggiornato delle [[Convenzioni|convenzioni più usate]].</translate>
* <translate>Fornire uno spazio per le [[Carte delle convenzioni|carte delle convenzioni di coppia e di squadra]].</translate>
* <translate>Offrire alle associazioni uno strumento condiviso per gestire e pubblicare materiali tecnici.</translate>

<translate>
== Come contribuire ==
</translate>
* <translate>Ogni utente registrato può modificare o integrare i contenuti esistenti.</translate>
* <translate>Per iniziare, visita la guida: [[Aiuto:Come modificare una pagina]].</translate>
* <translate>Usa i link interni (tra [[ ]]) per creare nuove voci.</translate>

<translate>
== Struttura del Wiki ==
</translate>
* <translate>[[Storia del bridge]] - come è nato e si è evoluto.</translate>
* <translate>[[Regole del bridge]] – regolamenti ufficiali e adattamenti locali.</translate>
* <translate>[[Licite]] – spiegazioni e sequenze tipiche.</translate>
* <translate>[[Convenzioni]] – elenchi e descrizioni di convenzioni (Stayman, Blackwood, ecc.).</translate>
* <translate>[[Carte delle convenzioni]] – schede personalizzate di coppia o associazione.</translate>
* <translate>[[Associazioni di bridge]] – spazi dedicati ad associazioni e circoli.</translate>
* <translate>[[Glossario del bridge]] – termini e definizioni.</translate>

<translate>
== Linee guida ==
</translate>
* <translate>Mantieni i contenuti chiari e neutrali.</translate>
* <translate>Cita fonti affidabili quando riporti regole ufficiali o documenti federali.</translate>
* <translate>Usa una terminologia coerente con il lessico del bridge.</translate>

<translate>
== Risorse utili ==
</translate>
* <translate>[https://www.federbridge.it/ FIGB – Federazione Italiana Gioco Bridge]</translate>
* <translate>[https://www.worldbridge.org/ WBF – World Bridge Federation]</translate>

----

{{Nota|<translate>Questa è una piattaforma collaborativa: ogni contributo è prezioso per arricchire la conoscenza condivisa sul bridge.</translate>}}

Template:Nota

2026-10-16T11:01:56Z

Lpala: Creato template Nota (riquadro di nota)

<div style="border:1px solid #a2a9b1; border-left:4px solid #36c; background:#eaf3ff; color:#202122; padding:0.5em 1em; margin:1em 0; border-radius:2px;">{{{1|}}}</div><noinclude>
Riquadro di nota semplice. Uso: <code><nowiki>{{Nota|Testo della nota}}</nowiki></code>. Il primo parametro posizionale è il testo; può contenere anche elenchi puntati e wikitesto. Se il testo contiene il segno "=" usare <code>1=</code>.
Vedi anche [[Template:Avviso]].
</noinclude>

Glossario del bridge

2026-10-16T10:52:37Z

Lpala: Predisposizione traduzione

{{Glossario}}<languages/>
<translate>
'''Questo glossario definisce i termini più comuni utilizzati nel gioco del [[:it:bridge|bridge]], sia nella fase di dichiarazione che in quella di gioco della carta.'''
</translate>

<translate>
L'elenco è in ordine alfabetico. Clicca su una lettera per navigare direttamente alla sezione corrispondente.
</translate>

<div style="text-align:center; font-size:1.2em; margin-bottom:15px;">
'''[[#A|A]] · [[#B|B]] · [[#C|C]] · [[#D|D]] · [[#F|F]] · [[#G|G]] · [[#I|I]] · [[#L|L]] · [[#M|M]] · [[#N|N]] · [[#O|O]] · [[#P|P]] · [[#Q|Q]] · [[#R|R]] · [[#S|S]] · [[#T|T]] · [[#V|V]]'''
</div>

__TOC__

== A ==
* <translate>'''Apertura''': La prima dichiarazione di un colore o a Senza Atout (diversa da "Passo") effettuata in una smazzata.</translate>
* <translate>'''Appoggio''': Dichiarazione che supporta il colore licitato dal compagno, indicando di possedere un buon numero di carte in quel seme (solitamente almeno tre).</translate>
* <translate>'''Atout''' (o ''Atù'', in inglese ''Trump''): Il seme che viene scelto come briscola durante la licitazione e che comanda su tutti gli altri semi durante il gioco della carta.</translate>
* <translate>'''Attacco''': La prima carta giocata dal difensore che si trova alla sinistra del dichiarante, all'inizio del gioco della carta. La scelta della carta d'attacco è un momento cruciale della difesa.</translate>

== B ==
* <translate>'''Bilanciata (Mano)''': Una mano con una distribuzione di carte equilibrata, senza vuoti o singleton e con al massimo un doubleton. Le distribuzioni tipiche sono 4-3-3-3, 4-4-3-2 e 5-3-3-2.</translate>
* <translate>'''Blackwood''': Una famosa convenzione dichiarativa (solitamente la licita di 4SA) usata per chiedere al compagno il numero di Assi (e talvolta Re) posseduti, al fine di esplorare la possibilità di giocare uno slam.</translate>

== C ==
* <translate>'''Colore''': Uno dei quattro semi delle carte: Fiori (♣), Quadri (♦), Cuori (♥) e Picche (♠).</translate>
* <translate>'''Contratto''': L'impegno finale preso da una coppia durante la fase di dichiarazione. Consiste in un numero di prese da effettuare (da 1 a 7) e un seme di atout (o Senza Atout).</translate>
* <translate>'''Contro''' (in inglese ''Double''): Una dichiarazione che aumenta il punteggio (sia in positivo che in negativo) del contratto avversario. Può avere un significato informativo (per descrivere la propria mano) o punitivo (se si pensa che gli avversari non possano mantenere il contratto).</translate>
* <translate>'''Convenzione''': Un accordo tra compagni su un significato artificiale o specifico di una determinata licita, che non corrisponde al suo significato naturale. Esempi famosi sono la Stayman e la Jacoby Transfer.</translate>
* <translate>'''Copertura''': Una carta che può vincere una presa dopo che una carta più alta dello stesso seme è già stata giocata.</translate>
* <translate>'''Cue Bid''': Una licita in un colore mostrato dagli avversari. Viene usata come licita forzante per mostrare una mano forte e chiedere maggiori informazioni al compagno.</translate>

== D ==
* <translate>'''Dichiarazione''' (o ''Licita''): Ogni offerta fatta da un giocatore durante la fase di licitazione (es. "1 Cuori", "Passo", "Contro").</translate>
* <translate>'''Dichiarante''': Il giocatore della coppia che per primo ha dichiarato il seme (o Senza Atout) del contratto finale. Il dichiarante gioca sia le proprie carte che quelle del morto.</translate>
* <translate>'''Difesa''': La coppia che non si è aggiudicata il contratto e che cerca di impedire al dichiarante di realizzare le prese necessarie.</translate>
* <translate>'''Distribuzione''': La suddivisione delle 13 carte di una mano nei quattro semi.</translate>

== F ==
* <translate>'''Fallo''' (o ''Scarto''): Giocare una carta di un seme diverso da quello di uscita, quando non si possiedono più carte di quel seme.</translate>
* <translate>'''Fit''': Avere un numero sufficiente di carte di un determinato seme in combinazione con il proprio compagno (solitamente almeno 8 carte in totale) per poterlo eleggere a seme di atout.</translate>
* <translate>'''Forzante''': Una dichiarazione che obbliga il compagno a parlare di nuovo, a meno che non intervengano gli avversari. Indica una mano forte o una situazione in cui è necessario scambiare altre informazioni.</translate>

== G ==
* <translate>'''Grande Slam''': Un contratto al livello di 7, che richiede di effettuare tutte le 13 prese possibili.</translate>
* <translate>'''Gioco''': La fase della smazzata che segue la dichiarazione, in cui i giocatori giocano le loro carte per effettuare le prese.</translate>

== I ==
* <translate>'''Impasso''' (in inglese ''Finesse''): Una tecnica di gioco che consiste nel tentare di vincere una presa con una carta più bassa, sperando che una carta avversaria più alta sia in una posizione favorevole.</translate>
* <translate>'''Invito''': Una dichiarazione che non è forzante, ma che invita il compagno a licitare un contratto superiore (solitamente a manche o a slam) se ha una mano non minima per le sue precedenti dichiarazioni.</translate>

== L ==
* <translate>'''Licita''': Vedi [[#D|Dichiarazione]].</translate>
* <translate>'''Linea''': Si usa per indicare le due coppie. La ''linea Nord-Sud'' e la ''linea Est-Ovest''.</translate>

== M ==
* <translate>'''Manche''': Un contratto il cui punteggio, se realizzato, è sufficiente a vincere una partita (es. 3 Senza Atout, 4 Cuori, 4 Picche, 5 Fiori, 5 Quadri).</translate>
* <translate>'''Mano''': Le 13 carte iniziali distribuite a un giocatore.</translate>
* <translate>'''Morto''' (in inglese ''Dummy''): Il compagno del dichiarante. Dopo l'attacco iniziale, il morto stende le proprie carte scoperte sul tavolo e non partecipa più attivamente al gioco; sarà il dichiarante a giocare le carte per lui.</translate>

== N ==
* <translate>'''Nobili (Semi)''': I semi di Cuori (♥) e Picche (♠), chiamati così perché valgono di più nel calcolo del punteggio (30 punti per presa) rispetto ai semi minori.</translate>

== O ==
* <translate>'''Onori''': Le cinque carte di maggior valore in ogni seme: Asso (A), Re (K), Donna (Q), Fante (J) e Dieci (10).</translate>

== P ==
* <translate>'''Passo''': Dichiarazione con cui un giocatore decide di non fare nessuna licita, contro o surcontro. Se tutti e quattro i giocatori passano all'inizio, le carte vengono raccolte e ridistribuite.</translate>
* <translate>'''Piccolo Slam''': Un contratto al livello di 6, che richiede di effettuare 12 prese su 13.</translate>
* <translate>'''Presa''': L'insieme delle quattro carte giocate in un round (una per ogni giocatore). La presa è vinta dal giocatore che ha giocato la carta più alta nel seme di uscita, o l'atout più alto.</translate>
* <translate>'''Punti Onori (PO)''': Un metodo di valutazione della forza di una mano basato sugli onori posseduti: Asso=4, Re=3, Donna=2, Fante=1.</translate>

== Q ==
* <translate>'''Qualificante''': Una mano o una licita che soddisfa i requisiti minimi per una determinata azione, secondo il sistema dichiarativo della coppia.</translate>

== R ==
* <translate>'''Rientro''': Una carta alta che permette di guadagnare la presa e quindi il controllo del gioco, consentendo di muovere da una delle due mani della coppia (dichiarante o morto).</translate>
* <translate>'''Rispondente''': Il compagno dell'apertore.</translate>

== S ==
* <translate>'''Scarto''': Vedi [[#F|Fallo]].</translate>
* <translate>'''Senza Atout (SA)''': Un contratto in cui non esiste un seme di atout. La presa è vinta semplicemente dalla carta più alta nel seme di uscita.</translate>
* <translate>'''Singleton''': Possedere una sola carta di un determinato seme.</translate>
* <translate>'''Squeeze''': Una tecnica di gioco avanzata con cui il dichiarante, giocando una carta vincente, costringe uno o entrambi i difensori a scartare una carta che custodiva una presa futura.</translate>
* <translate>'''Stayman''': Una convenzione (solitamente la licita di 2 Fiori in risposta a un'apertura a Senza Atout) usata per chiedere all'apertore se possiede un seme nobile di almeno quattro carte.</translate>
* <translate>'''Surcontro''' (in inglese ''Redouble''): Una dichiarazione fatta dopo un "Contro" avversario, che aumenta ulteriormente il valore del punteggio del contratto.</translate>

== T ==
* <translate>'''Taglio''' (o ''Tuffo''): Giocare una carta di atout quando non si possiedono più carte del seme di uscita. Il taglio permette di vincere una presa che altrimenti andrebbe agli avversari.</translate>

== V ==
* <translate>'''Vulnerabile''': Condizione di una coppia in una determinata smazzata che aumenta i bonus e le penalità. La vulnerabilità cambia secondo uno schema predefinito durante una partita.</translate>
* <translate>'''Vuoto''': Non possedere alcuna carta di un determinato seme.</translate>

<translate>
== Voci correlate ==
</translate>
* <translate>[[Bridge]]</translate>
* <translate>[[Federazione Italiana Gioco Bridge]]</translate>

[[Categoria:Bridge]]
[[Categoria:Glossario]]

Pagina principale

2026-10-16T10:52:36Z

Lpala: Predisposizione traduzione

{{Articolo}}<languages/>
<translate>
= Benvenuti su '''BridgePedia''' =
</translate>

<translate>
'''BridgePedia''' è il punto di riferimento collaborativo per tutti i giocatori, le coppie e le associazioni che desiderano raccogliere, documentare e condividere le conoscenze sul gioco del bridge.
</translate>
<translate>
Qui troverai regole, licite, convenzioni e carte delle convenzioni, aggiornate e mantenute direttamente dagli utenti della comunità.
</translate>

<translate>
== Obiettivi ==
</translate>
* <translate>Rendere facilmente accessibili le [[Regole del bridge|regole ufficiali del bridge]].</translate>
* <translate>Documentare in modo strutturato le principali [[Licite|sequenze di licita]].</translate>
* <translate>Creare un archivio aggiornato delle [[Convenzioni|convenzioni più usate]].</translate>
* <translate>Fornire uno spazio per le [[Carte delle convenzioni|carte delle convenzioni di coppia e di squadra]].</translate>
* <translate>Offrire alle associazioni uno strumento condiviso per gestire e pubblicare materiali tecnici.</translate>

<translate>
== Come contribuire ==
</translate>
* <translate>Ogni utente registrato può modificare o integrare i contenuti esistenti.</translate>
* <translate>Per iniziare, visita la guida: [[Aiuto:Come modificare una pagina]].</translate>
* <translate>Usa i link interni (tra [[ ]]) per creare nuove voci.</translate>

<translate>
== Struttura del Wiki ==
</translate>
* <translate>[[Storia del bridge]] - come è nato e si è evoluto.</translate>
* <translate>[[Regole del bridge]] – regolamenti ufficiali e adattamenti locali.</translate>
* <translate>[[Licite]] – spiegazioni e sequenze tipiche.</translate>
* <translate>[[Convenzioni]] – elenchi e descrizioni di convenzioni (Stayman, Blackwood, ecc.).</translate>
* <translate>[[Carte delle convenzioni]] – schede personalizzate di coppia o associazione.</translate>
* <translate>[[Associazioni di bridge]] – spazi dedicati ad associazioni e circoli.</translate>
* <translate>[[Glossario del bridge]] – termini e definizioni.</translate>

<translate>
== Linee guida ==
</translate>
* <translate>Mantieni i contenuti chiari e neutrali.</translate>
* <translate>Cita fonti affidabili quando riporti regole ufficiali o documenti federali.</translate>
* <translate>Usa una terminologia coerente con il lessico del bridge.</translate>

<translate>
== Risorse utili ==
</translate>
* <translate>[https://www.federbridge.it/ FIGB – Federazione Italiana Gioco Bridge]</translate>
* <translate>[https://www.worldbridge.org/ WBF – World Bridge Federation]</translate>

----

{{Nota|Questa è una piattaforma collaborativa: ogni contributo è prezioso per arricchire la conoscenza condivisa sul bridge.}}

Glossario del bridge

2026-10-16T10:52:23Z

Lpala: Predisposizione traduzione

{{Glossario}}
<languages/>
<translate>
'''Questo glossario definisce i termini più comuni utilizzati nel gioco del [[:it:bridge|bridge]], sia nella fase di dichiarazione che in quella di gioco della carta.'''
</translate>

<translate>
L'elenco è in ordine alfabetico. Clicca su una lettera per navigare direttamente alla sezione corrispondente.
</translate>

<div style="text-align:center; font-size:1.2em; margin-bottom:15px;">
'''[[#A|A]] · [[#B|B]] · [[#C|C]] · [[#D|D]] · [[#F|F]] · [[#G|G]] · [[#I|I]] · [[#L|L]] · [[#M|M]] · [[#N|N]] · [[#O|O]] · [[#P|P]] · [[#Q|Q]] · [[#R|R]] · [[#S|S]] · [[#T|T]] · [[#V|V]]'''
</div>

__TOC__

== A ==
* <translate>'''Apertura''': La prima dichiarazione di un colore o a Senza Atout (diversa da "Passo") effettuata in una smazzata.</translate>
* <translate>'''Appoggio''': Dichiarazione che supporta il colore licitato dal compagno, indicando di possedere un buon numero di carte in quel seme (solitamente almeno tre).</translate>
* <translate>'''Atout''' (o ''Atù'', in inglese ''Trump''): Il seme che viene scelto come briscola durante la licitazione e che comanda su tutti gli altri semi durante il gioco della carta.</translate>
* <translate>'''Attacco''': La prima carta giocata dal difensore che si trova alla sinistra del dichiarante, all'inizio del gioco della carta. La scelta della carta d'attacco è un momento cruciale della difesa.</translate>

== B ==
* <translate>'''Bilanciata (Mano)''': Una mano con una distribuzione di carte equilibrata, senza vuoti o singleton e con al massimo un doubleton. Le distribuzioni tipiche sono 4-3-3-3, 4-4-3-2 e 5-3-3-2.</translate>
* <translate>'''Blackwood''': Una famosa convenzione dichiarativa (solitamente la licita di 4SA) usata per chiedere al compagno il numero di Assi (e talvolta Re) posseduti, al fine di esplorare la possibilità di giocare uno slam.</translate>

== C ==
* <translate>'''Colore''': Uno dei quattro semi delle carte: Fiori (♣), Quadri (♦), Cuori (♥) e Picche (♠).</translate>
* <translate>'''Contratto''': L'impegno finale preso da una coppia durante la fase di dichiarazione. Consiste in un numero di prese da effettuare (da 1 a 7) e un seme di atout (o Senza Atout).</translate>
* <translate>'''Contro''' (in inglese ''Double''): Una dichiarazione che aumenta il punteggio (sia in positivo che in negativo) del contratto avversario. Può avere un significato informativo (per descrivere la propria mano) o punitivo (se si pensa che gli avversari non possano mantenere il contratto).</translate>
* <translate>'''Convenzione''': Un accordo tra compagni su un significato artificiale o specifico di una determinata licita, che non corrisponde al suo significato naturale. Esempi famosi sono la Stayman e la Jacoby Transfer.</translate>
* <translate>'''Copertura''': Una carta che può vincere una presa dopo che una carta più alta dello stesso seme è già stata giocata.</translate>
* <translate>'''Cue Bid''': Una licita in un colore mostrato dagli avversari. Viene usata come licita forzante per mostrare una mano forte e chiedere maggiori informazioni al compagno.</translate>

== D ==
* <translate>'''Dichiarazione''' (o ''Licita''): Ogni offerta fatta da un giocatore durante la fase di licitazione (es. "1 Cuori", "Passo", "Contro").</translate>
* <translate>'''Dichiarante''': Il giocatore della coppia che per primo ha dichiarato il seme (o Senza Atout) del contratto finale. Il dichiarante gioca sia le proprie carte che quelle del morto.</translate>
* <translate>'''Difesa''': La coppia che non si è aggiudicata il contratto e che cerca di impedire al dichiarante di realizzare le prese necessarie.</translate>
* <translate>'''Distribuzione''': La suddivisione delle 13 carte di una mano nei quattro semi.</translate>

== F ==
* <translate>'''Fallo''' (o ''Scarto''): Giocare una carta di un seme diverso da quello di uscita, quando non si possiedono più carte di quel seme.</translate>
* <translate>'''Fit''': Avere un numero sufficiente di carte di un determinato seme in combinazione con il proprio compagno (solitamente almeno 8 carte in totale) per poterlo eleggere a seme di atout.</translate>
* <translate>'''Forzante''': Una dichiarazione che obbliga il compagno a parlare di nuovo, a meno che non intervengano gli avversari. Indica una mano forte o una situazione in cui è necessario scambiare altre informazioni.</translate>

== G ==
* <translate>'''Grande Slam''': Un contratto al livello di 7, che richiede di effettuare tutte le 13 prese possibili.</translate>
* <translate>'''Gioco''': La fase della smazzata che segue la dichiarazione, in cui i giocatori giocano le loro carte per effettuare le prese.</translate>

== I ==
* <translate>'''Impasso''' (in inglese ''Finesse''): Una tecnica di gioco che consiste nel tentare di vincere una presa con una carta più bassa, sperando che una carta avversaria più alta sia in una posizione favorevole.</translate>
* <translate>'''Invito''': Una dichiarazione che non è forzante, ma che invita il compagno a licitare un contratto superiore (solitamente a manche o a slam) se ha una mano non minima per le sue precedenti dichiarazioni.</translate>

== L ==
* <translate>'''Licita''': Vedi [[#D|Dichiarazione]].</translate>
* <translate>'''Linea''': Si usa per indicare le due coppie. La ''linea Nord-Sud'' e la ''linea Est-Ovest''.</translate>

== M ==
* <translate>'''Manche''': Un contratto il cui punteggio, se realizzato, è sufficiente a vincere una partita (es. 3 Senza Atout, 4 Cuori, 4 Picche, 5 Fiori, 5 Quadri).</translate>
* <translate>'''Mano''': Le 13 carte iniziali distribuite a un giocatore.</translate>
* <translate>'''Morto''' (in inglese ''Dummy''): Il compagno del dichiarante. Dopo l'attacco iniziale, il morto stende le proprie carte scoperte sul tavolo e non partecipa più attivamente al gioco; sarà il dichiarante a giocare le carte per lui.</translate>

== N ==
* <translate>'''Nobili (Semi)''': I semi di Cuori (♥) e Picche (♠), chiamati così perché valgono di più nel calcolo del punteggio (30 punti per presa) rispetto ai semi minori.</translate>

== O ==
* <translate>'''Onori''': Le cinque carte di maggior valore in ogni seme: Asso (A), Re (K), Donna (Q), Fante (J) e Dieci (10).</translate>

== P ==
* <translate>'''Passo''': Dichiarazione con cui un giocatore decide di non fare nessuna licita, contro o surcontro. Se tutti e quattro i giocatori passano all'inizio, le carte vengono raccolte e ridistribuite.</translate>
* <translate>'''Piccolo Slam''': Un contratto al livello di 6, che richiede di effettuare 12 prese su 13.</translate>
* <translate>'''Presa''': L'insieme delle quattro carte giocate in un round (una per ogni giocatore). La presa è vinta dal giocatore che ha giocato la carta più alta nel seme di uscita, o l'atout più alto.</translate>
* <translate>'''Punti Onori (PO)''': Un metodo di valutazione della forza di una mano basato sugli onori posseduti: Asso=4, Re=3, Donna=2, Fante=1.</translate>

== Q ==
* <translate>'''Qualificante''': Una mano o una licita che soddisfa i requisiti minimi per una determinata azione, secondo il sistema dichiarativo della coppia.</translate>

== R ==
* <translate>'''Rientro''': Una carta alta che permette di guadagnare la presa e quindi il controllo del gioco, consentendo di muovere da una delle due mani della coppia (dichiarante o morto).</translate>
* <translate>'''Rispondente''': Il compagno dell'apertore.</translate>

== S ==
* <translate>'''Scarto''': Vedi [[#F|Fallo]].</translate>
* <translate>'''Senza Atout (SA)''': Un contratto in cui non esiste un seme di atout. La presa è vinta semplicemente dalla carta più alta nel seme di uscita.</translate>
* <translate>'''Singleton''': Possedere una sola carta di un determinato seme.</translate>
* <translate>'''Squeeze''': Una tecnica di gioco avanzata con cui il dichiarante, giocando una carta vincente, costringe uno o entrambi i difensori a scartare una carta che custodiva una presa futura.</translate>
* <translate>'''Stayman''': Una convenzione (solitamente la licita di 2 Fiori in risposta a un'apertura a Senza Atout) usata per chiedere all'apertore se possiede un seme nobile di almeno quattro carte.</translate>
* <translate>'''Surcontro''' (in inglese ''Redouble''): Una dichiarazione fatta dopo un "Contro" avversario, che aumenta ulteriormente il valore del punteggio del contratto.</translate>

== T ==
* <translate>'''Taglio''' (o ''Tuffo''): Giocare una carta di atout quando non si possiedono più carte del seme di uscita. Il taglio permette di vincere una presa che altrimenti andrebbe agli avversari.</translate>

== V ==
* <translate>'''Vulnerabile''': Condizione di una coppia in una determinata smazzata che aumenta i bonus e le penalità. La vulnerabilità cambia secondo uno schema predefinito durante una partita.</translate>
* <translate>'''Vuoto''': Non possedere alcuna carta di un determinato seme.</translate>

<translate>
== Voci correlate ==
</translate>
* <translate>[[Bridge]]</translate>
* <translate>[[Federazione Italiana Gioco Bridge]]</translate>

[[Categoria:Bridge]]
[[Categoria:Glossario]]

Pagina principale

2026-10-16T10:52:23Z

Lpala: Predisposizione traduzione

{{Articolo}}
<languages/>
<translate>
= Benvenuti su '''BridgePedia''' =
</translate>

<translate>
'''BridgePedia''' è il punto di riferimento collaborativo per tutti i giocatori, le coppie e le associazioni che desiderano raccogliere, documentare e condividere le conoscenze sul gioco del bridge.
</translate>
<translate>
Qui troverai regole, licite, convenzioni e carte delle convenzioni, aggiornate e mantenute direttamente dagli utenti della comunità.
</translate>

<translate>
== Obiettivi ==
</translate>
* <translate>Rendere facilmente accessibili le [[Regole del bridge|regole ufficiali del bridge]].</translate>
* <translate>Documentare in modo strutturato le principali [[Licite|sequenze di licita]].</translate>
* <translate>Creare un archivio aggiornato delle [[Convenzioni|convenzioni più usate]].</translate>
* <translate>Fornire uno spazio per le [[Carte delle convenzioni|carte delle convenzioni di coppia e di squadra]].</translate>
* <translate>Offrire alle associazioni uno strumento condiviso per gestire e pubblicare materiali tecnici.</translate>

<translate>
== Come contribuire ==
</translate>
* <translate>Ogni utente registrato può modificare o integrare i contenuti esistenti.</translate>
* <translate>Per iniziare, visita la guida: [[Aiuto:Come modificare una pagina]].</translate>
* <translate>Usa i link interni (tra [[ ]]) per creare nuove voci.</translate>

<translate>
== Struttura del Wiki ==
</translate>
* <translate>[[Storia del bridge]] - come è nato e si è evoluto.</translate>
* <translate>[[Regole del bridge]] – regolamenti ufficiali e adattamenti locali.</translate>
* <translate>[[Licite]] – spiegazioni e sequenze tipiche.</translate>
* <translate>[[Convenzioni]] – elenchi e descrizioni di convenzioni (Stayman, Blackwood, ecc.).</translate>
* <translate>[[Carte delle convenzioni]] – schede personalizzate di coppia o associazione.</translate>
* <translate>[[Associazioni di bridge]] – spazi dedicati ad associazioni e circoli.</translate>
* <translate>[[Glossario del bridge]] – termini e definizioni.</translate>

<translate>
== Linee guida ==
</translate>
* <translate>Mantieni i contenuti chiari e neutrali.</translate>
* <translate>Cita fonti affidabili quando riporti regole ufficiali o documenti federali.</translate>
* <translate>Usa una terminologia coerente con il lessico del bridge.</translate>

<translate>
== Risorse utili ==
</translate>
* <translate>[https://www.federbridge.it/ FIGB – Federazione Italiana Gioco Bridge]</translate>
* <translate>[https://www.worldbridge.org/ WBF – World Bridge Federation]</translate>

----

{{Nota|Questa è una piattaforma collaborativa: ogni contributo è prezioso per arricchire la conoscenza condivisa sul bridge.}}

BridgePedia:Glossario multilingua

2026-10-16T07:02:29Z

Lpala: Fase 3: glossario multilingua (pagina di servizio)

Glossario di riferimento per le traduzioni del wiki (it, en, fr, es, de). Pagina di servizio, fuori dal namespace principale.

== Regole d'uso ==
* I termini della colonna '''it''' sono la fonte: le altre colonne sono traduzioni da allineare a essa.
* Le notazioni dei tag BridgeCards (<code><bidding></code>, <code><hand></code>, <code><deal></code>) non si traducono mai.
* I nomi delle convenzioni invarianti restano uguali in tutte le lingue (vedi sezione dedicata).
* Le traduzioni in en, fr, es, de sono tutte '''da verificare con madrelingua''' (colonna stato).

== Termini fondamentali ==
{| class="wikitable sortable"
! it !! en !! fr !! es !! de !! stato
|-
| fiori || clubs || trèfle || tréboles || Kreuz (Treff) || it: verificato; altre lingue: da verificare con madrelingua
|-
| quadri || diamonds || carreau || diamantes || Karo || it: verificato; altre lingue: da verificare con madrelingua
|-
| cuori || hearts || cœur || corazones || Herz || it: verificato; altre lingue: da verificare con madrelingua
|-
| picche || spades || pique || picas || Pik || it: verificato; altre lingue: da verificare con madrelingua
|-
| senza atout || no trump || sans atout || sin triunfos || Sans Atout || it: verificato; altre lingue: da verificare con madrelingua
|-
| Passo || Pass || Passe || Paso || Passe (Pass) || it: verificato; altre lingue: da verificare con madrelingua
|-
| Contro || Double || Contre || Contra || Kontra || it: verificato; altre lingue: da verificare con madrelingua
|-
| Surcontro || Redouble || Surcontre || Recontra || Rekontra || it: verificato; altre lingue: da verificare con madrelingua
|-
| apertura || opening bid || ouverture || apertura || Eröffnung || it: verificato; altre lingue: da verificare con madrelingua
|-
| risposta || response || réponse || respuesta || Antwort || it: verificato; altre lingue: da verificare con madrelingua
|-
| rispondente || responder || répondant || respondedor || Antwortender || it: verificato; altre lingue: da verificare con madrelingua
|-
| apertore || opener || ouvreur || abridor || Eröffner || it: verificato; altre lingue: da verificare con madrelingua
|-
| manche || game || manche || manga || Manche || it: verificato; altre lingue: da verificare con madrelingua
|-
| slam || slam || chelem || slam || Slam || it: verificato; altre lingue: da verificare con madrelingua
|-
| piccolo slam || small slam || petit chelem || pequeño slam || Kleinslam || it: verificato; altre lingue: da verificare con madrelingua
|-
| grande slam || grand slam || grand chelem || gran slam || Großslam || it: verificato; altre lingue: da verificare con madrelingua
|-
| licita || bidding || enchères || subasta (licitación) || Reizung || it: verificato; altre lingue: da verificare con madrelingua
|-
| dichiarante || declarer || déclarant || declarante || Alleinspieler || it: verificato; altre lingue: da verificare con madrelingua
|-
| difensore || defender || défenseur || defensor || Verteidiger || it: verificato; altre lingue: da verificare con madrelingua
|-
| attacco || opening lead || entame || salida || Ausspiel || it: verificato; altre lingue: da verificare con madrelingua
|-
| morto || dummy || mort || muerto || Dummy (Blatt des Tisches) || it: verificato; altre lingue: da verificare con madrelingua
|-
| mano || hand || main || mano || Blatt (Hand) || it: verificato; altre lingue: da verificare con madrelingua
|-
| smazzata || deal (board) || donne || mano (reparto) || Spiel (Board) || it: verificato; altre lingue: da verificare con madrelingua
|-
| presa || trick || levée || baza || Stich || it: verificato; altre lingue: da verificare con madrelingua
|-
| atout || trump || atout || triunfo || Trumpf || it: verificato; altre lingue: da verificare con madrelingua
|-
| impasse || finesse || impasse || impasse || Schnitt (Impasse) || it: verificato; altre lingue: da verificare con madrelingua
|-
| singolo || singleton || singleton || singleton || Single (Singleton) || it: verificato; altre lingue: da verificare con madrelingua
|-
| vuoto (chicane) || void || chicane || fallo || Chicane (Renonce) || it: verificato; altre lingue: da verificare con madrelingua
|-
| controllo || control || contrôle || control || Kontrolle || it: verificato; altre lingue: da verificare con madrelingua
|-
| cue-bid || cue-bid || cue-bid || cue-bid || Cue-Bid || it: verificato; altre lingue: da verificare con madrelingua
|-
| convenzione || convention || convention || convención || Konvention || it: verificato; altre lingue: da verificare con madrelingua
|-
| sistema || system || système || sistema || System || it: verificato; altre lingue: da verificare con madrelingua
|-
| surlicita || overcall || intervention || intervención || Intervention || it: verificato; altre lingue: da verificare con madrelingua
|-
| fit || fit || fit || fit || Fit || it: verificato; altre lingue: da verificare con madrelingua
|-
| zona (vulnerabilità) || vulnerability || vulnérabilité || vulnerabilidad || Gefahrenlage (Zone) || it: verificato; altre lingue: da verificare con madrelingua
|-
| mazziere || dealer || donneur || dador || Teiler (Geber) || it: verificato; altre lingue: da verificare con madrelingua
|-
| torneo || tournament || tournoi || torneo || Turnier || it: verificato; altre lingue: da verificare con madrelingua
|-
| coppie || pairs || paires || parejas || Paarturnier || it: verificato; altre lingue: da verificare con madrelingua
|-
| squadre || teams || équipes (par quatre) || equipos || Mannschaft (Teams) || it: verificato; altre lingue: da verificare con madrelingua
|-
| direttore (arbitro) || director (referee) || directeur de jeu (arbitre) || director (árbitro) || Turnierleiter (Schiedsrichter) || it: verificato; altre lingue: da verificare con madrelingua
|-
| nome (etichetta template) || Name || Nom || Nombre || Name || it: verificato; altre lingue: da verificare con madrelingua
|-
| tipologia (etichetta template) || Type || Type || Tipo || Typ || it: verificato; altre lingue: da verificare con madrelingua
|-
| scopo (etichetta template) || Purpose || But || Propósito || Zweck || it: verificato; altre lingue: da verificare con madrelingua
|-
| trigger (etichetta template) || Trigger (when to use) || Déclencheur (quand l’utiliser) || Desencadenante (cuándo se usa) || Auslöser (wann man es einsetzt) || it: verificato; altre lingue: da verificare con madrelingua
|-
| risposte / sviluppi (etichetta template) || Responses / developments || Réponses / développements || Respuestas / desarrollos || Antworten / Fortsetzungen || it: verificato; altre lingue: da verificare con madrelingua
|-
| note (etichetta template) || Notes || Notes || Notas || Hinweise || it: verificato; altre lingue: da verificare con madrelingua
|-
| tabella attacchi (etichetta template) || Leads table || Tableau des entames || Tabla de salidas || Ausspieltabelle || it: verificato; altre lingue: da verificare con madrelingua
|}

== Nomi di convenzioni invarianti ==
{| class="wikitable"
! Nome !! Regola !! stato
|-
| Stayman, Jacoby, Blackwood, Gerber, Texas, Splinter, Smith, Michaels, Unusual, Landy || Restano invariati in tutte le lingue (it, en, fr, es, de). || it: verificato; altre lingue: da verificare con madrelingua
|}

== Fonte ==
Glossario redatto dalla redazione di BridgePedia. Non deriva da una fonte esterna citabile: va validato con madrelingua e confrontato con i glossari ufficiali (WBF, EBL) prima di essere considerato definitivo.

Categoria:Traduzioni da verificare (de)

2026-10-16T07:02:22Z

Lpala: Fase 3: pagina di servizio traduzioni

Pagine tradotte automaticamente in tedesco (de) e non ancora verificate da una persona. Categoria principale: [[:Categoria:Traduzioni da verificare]].