# Template format (mcp-mantis-ticket-writer)

Ogni template deve separare in modo esplicito:

1. regole di **formattazione MantisBT**;
2. regole **semantiche** del contenuto.

## Schema minimo

```yaml
name: bug-standard
description: template aziendale definitivo per ticket MantisBT
sections:
  - id: summary
    title: Riassunto
    formatting_rules:
      - formato obbligatorio: **ARGOMENTO** - ***ARGOMENTO2*** - Descrizione
    semantic_rules:
      - ARGOMENTO area funzionale
      - ARGOMENTO2 sotto-contesto
  - id: description
    title: Description
    formatting_rules:
      - descrizione funzionale concreta
    semantic_rules:
      - contesto
      - osservato vs atteso
      - evidenze e dubbi
  - id: steps_to_reproduce
    title: Steps To Reproduce
    formatting_rules:
      - heading consigliato: # Sviluppi con fallback **SVILUPPI**
      - elenco operativo
      - se disponibili evidenze tecniche, aggiungere ## Riferimenti tecnici (fallback **RIFERIMENTI TECNICI**)
      - snippet codice/query in formato esplicitato dal template (es. `bug-standard`: tripli backtick; `legacy-markdown`: `<pre>...</pre>`)
    semantic_rules:
      - soli passaggi verificabili
      - dichiarare incertezza se dati incompleti
      - inserire l'intera analisi tecnica all'interno di questa sezione, non come nota isolata
      - riferimenti tecnici condizionali: path relativo, funzione/metodo, linea solo se certa, tabelle reali se note
      - vietato inventare path/funzioni/linee/tabelle
  - id: additional_information
    title: Additional Information
    formatting_rules:
      - heading consigliato: # Test con fallback **TEST**
      - sezione opzionale condizionale
    semantic_rules:
      - includere solo test richiesti o deducibili
      - omettere se non applicabile
```

## Requisiti obbligatori

- l'output finale dei ticket va consegnato direttamente in chat, non in file `.md` o allegati esterni salvo richiesta esplicita;
- ogni sezione resa all'utente deve avere il proprio snippet testuale copy-paste ready per Mantis;
- se il task richiede piu' ticket, tutti i ticket vanno inclusi nella stessa risposta in chat, con intestazioni evidenti e snippet per sezione ripetuti per ciascun ticket;
- `name` univoco;
- `description` sintetica;
- `sections[]` con almeno tre sezioni obbligatorie:
  - `summary`
  - `description`
  - `steps_to_reproduce`
- `additional_information` opzionale, solo quando applicabile;
- ogni sezione deve includere sia `formatting_rules` sia `semantic_rules`.
- heading markdown consentiti con fallback testuale per compatibilita' Mantis eterogenea.

## Built-in attivo

- Built-in attivi: `bug-standard`, `legacy-markdown`.
- Default implicito: `bug-standard`.
- `legacy-markdown` e' opt-in esplicito: usarlo solo se richiesto dall'utente (`legacy`, `legacy-markdown`, equivalente non ambiguo).
- `bug-compact` e `analysis-ready` sono varianti legacy/documentali, non default attivi.

## Template locali esterni

Per template esterni via path locale:

1. validare presenza campi minimi;
2. se incompleto/ambiguo, dichiarare gap;
3. chiedere chiarimenti oppure fallback a template built-in;
4. tracciare sempre quale template e' stato effettivamente usato.
