# Output rules

## Decisione obbligatoria (prima di rispondere)

- Se i dati minimi non bastano: fai solo 1-3 domande bloccanti.
- Se i dati minimi bastano: produci subito il drafting finale Mantis-ready.
- Vietato rimandare la formattazione a un secondo messaggio.
- Il drafting finale va prodotto direttamente in chat. Non creare file `.md`, allegati o documenti esterni salvo richiesta esplicita dell'utente.
- Se sono richiesti piu' ticket, includili tutti nella stessa risposta in chat, separati da intestazioni evidenti e con snippet completi per ciascuna sezione di ogni ticket.

## Selezione tema/template

- Se non richiesto diversamente, usa `bug-standard`.
- Se l'utente richiede esplicitamente legacy (`legacy`, `legacy-markdown`, equivalente non ambiguo), usa `legacy-markdown`.
- Il tema selezionato va sempre dichiarato in `Template usato: ...`.
- Con `legacy-markdown`, snippet tecnici obbligatoriamente in `<pre>...</pre>` e nessuna feature plugin avanzato.
- Con `bug-standard`, snippet tecnici in tripli backtick come default; lingua consigliata quando utile (`php`, `sql`, `cfml`, `js`).

## Formato obbligatorio (quando i dati minimi bastano)

Usa sempre questa struttura direttamente in chat, senza testo dispersivo tra le sezioni:

````md
Template usato: `...`
Scenario: `nuovo ticket` | `ticket esistente`
Fonti consultate: ...
Limiti/dubbi aperti: ...

**Riassunto**
```text
**ARGOMENTO** - ***ARGOMENTO2*** - Descrizione
```

**Description**
```text
...
```

**Steps To Reproduce**
```text
# Sviluppi
**SVILUPPI**
1. ...
2. ...
3. ...

## Riferimenti tecnici (solo se disponibili)
**RIFERIMENTI TECNICI**
- Componente/path relativo: ...
- Funzione/metodo (linea solo se certa): ...
- Tabelle reali coinvolte (se note): ...

```sql
-- snippet codice o query SQL
```
```

**Additional Information** (solo se applicabile)
```text
# Test
**TEST**
- ...
- ...
```
````

Ogni sezione deve essere:

- in snippet dedicato;
- completa e autonoma;
- copy-paste ready per MantisBT.
- senza testo dispersivo tra uno snippet e l'altro.
- con titolo Riassunto obbligatorio in formato `**ARGOMENTO** - ***ARGOMENTO2*** - Descrizione`.
- con heading markdown ammessi e fallback testuale in grassetto per compatibilita' Mantis non uniforme.
- con riferimenti tecnici negli sviluppi solo se verificabili:
  - componente/path relativo;
  - funzione/metodo (linea solo se certa);
  - tabelle reali se note;
  - snippet in formato coerente col template (`bug-standard`: backtick; `legacy-markdown`: `<pre>...</pre>`).

## Formato multi-ticket

Quando l'utente chiede piu' ticket nello stesso task:

- non creare file esterni per separarli, salvo richiesta esplicita;
- non spezzare l'output in piu' risposte se i dati minimi bastano;
- usa una separazione visiva chiara per ogni ticket, ad esempio `## Ticket 1 - <titolo breve>`;
- ripeti per ogni ticket: template usato, scenario, fonti consultate, limiti/dubbi aperti;
- per ogni ticket includi uno snippet dedicato per ciascuna sezione del template (`Riassunto`, `Description`, `Steps To Reproduce`, `Additional Information` se applicabile).

## Formato obbligatorio (quando i dati minimi non bastano)

Usa solo domande di chiarimento, massimo 1-3:

```md
Domande di chiarimento:
- ...
- ...
- ...
```

Non includere draft parziale nello stesso turno.

## Obbligatorio in ogni drafting finale

- template usato;
- scenario (`nuovo ticket` / `ticket esistente`);
- fonti consultate;
- dubbi/limiti aperti;
- output in chat, non in file esterno, salvo richiesta esplicita;
- sezioni complete:
  - Riassunto
  - Description
  - Steps To Reproduce
- sezione opzionale condizionale:
  - Additional Information (solo quando i test sono richiesti o deducibili)

## Stile

- linguaggio concreto e verificabile;
- separare fatti osservati da ipotesi;
- evitare tono accusatorio;
- mantenere utilita' operativa per chi implementera' o analizzera' dopo.
- prosa libera ammessa solo per:
  - domande preliminari bloccanti;
  - limiti/dubbi aperti;
  - handoff/escalation.

## Divieti

- niente preambolo narrativo non necessario;
- niente file `.md` esterno o allegato quando l'utente non lo ha chiesto esplicitamente;
- niente doppia resa ("prima spiego, poi formatto");
- niente diff/patch del ticket;
- niente sezioni parziali;
- niente invenzione di passi di riproduzione;
- niente invenzione di test;
- niente invenzione di path/funzioni/linee/tabelle;
- niente narrativa lunga non utile all'azione.

## Riferimento esempi

- [output-examples.md](output-examples.md)