# Cross-Version Migration

Workflow per migrare in modo controllato funzionalità tra versioni, varianti, branch o ambienti dello stesso prodotto usando una directory neutrale.

## Ambito

Usa questa modalità per:

- migrare funzionalità applicative tra versioni prodotto;
- estrarre logica dalla versione sorgente in artefatti neutri;
- integrare artefatti neutri in una versione target;
- spostare funzionalità tra repository layout differenti;
- coordinare due ruoli AI-assisted senza scansioni pesanti ripetute.

Il workflow deve restare product-agnostic.

Non hardcodare nomi prodotto, versioni, moduli, path o layout repository.

## Contratto della directory neutrale

La directory neutrale è isolata sia dal repository sorgente sia dal repository target.

Deve contenere:

- `conventions.md`
- `touched-files.md`

Può contenere:

- `target-structures.md`
- frammenti derivati dalla sorgente;
- file da aggiungere;
- file da fondere;
- note Provider;
- note Consumer;
- riferimenti alla struttura target forniti dall'utente.

## Responsabilità umana

L'utente umano deve fornire le strutture target esatte.

Non indovinare, inventare, normalizzare o estrapolare path target.

Se la struttura target manca, fermati e chiedi la struttura mancante prima di assegnare path target.

## Persone operative

### Provider

Il Provider legge il repository sorgente e scrive artefatti pronti per la migrazione nella directory neutrale.

Il Provider può:

- creare nuovi blocchi iterazione;
- aggiungere righe `TO ADD`;
- aggiungere righe `TO MERGE`;
- produrre frammenti minimi da fondere;
- rispecchiare strutture target fornite dall'utente per nuovi file.

Il Provider non deve:

- aggiornare righe a `ADDED` o `MERGED`;
- modificare il progetto target;
- inventare path target;
- includere refactor non correlati.

### Consumer

Il Consumer legge gli item pendenti dalla directory neutrale e li integra nel repository target.

Il Consumer può:

- processare righe `TO ADD`;
- processare righe `TO MERGE`;
- aggiornare lo stato inline a `ADDED` o `MERGED`.

Il Consumer non deve:

- creare nuove iterazioni;
- aggiungere nuovi item `TO ADD` o `TO MERGE`;
- inventare logica sorgente mancante;
- ampliare lo scope della migrazione.

## Stati

Stati ammessi:

- `TO ADD`
- `TO MERGE`
- `ADDED`
- `MERGED`

Nessun altro stato è ammesso.

## Disciplina iterativa

Ogni passata Provider appende un nuovo blocco iterazione a `touched-files.md`.

Ogni passata Consumer aggiorna solo righe pendenti esistenti.

Mantieni il tracking minimale. Non trasformarlo in un log verboso di attività.