# Legacy System Inventory

Usa questo riferimento per ricostruire read-only il comportamento di un sistema legacy e produrre un contratto di parità per una futura modernizzazione. Non implementare il target.

## Preflight

Richiedi o ricava repository/path sorgente, branch, baseline, target se noto, fonte funzionale, obiettivo, domini prioritari, ambienti/database autorizzati e vincoli su segreti, PII e dati cliente. Non derivare il progetto dal repository delle istruzioni né usare configurazioni di altri progetti.

## Discovery

1. Leggi governance e documentazione rilevante.
2. Identifica entry point, configurazione, dipendenze, persistenza e integrazioni.
3. Cerca cronologia Git, copie leggibili, backup, documentazione, test, release package e source map.
4. Suddividi l'analisi per dominio funzionale; usa source recovery solo come assessment quando manca una fonte leggibile.
5. Se fonti locali e input non bastano, usa solo fonti web pubbliche citabili. Non simulare browser, interfaccia o runtime: registra i comportamenti non verificabili e la validazione necessaria nell'handoff.

## Template inventory

| Campo | Contenuto |
| --- | --- |
| ID | Identificativo stabile |
| Dominio | Area funzionale |
| Fonte | Repository, path, ref, simbolo o endpoint |
| Caller | Entry point o dipendenze |
| Input | Parametri e precondizioni |
| Logica osservata | Regole effettive |
| Accesso dati | Tabelle o query redatte |
| Output | Shape, stato ed errori |
| Side effect | Scritture, notifiche, file o job |
| Edge case | Caso limite osservato |
| Stato legacy | Atteso, anomalo o non chiaro |
| Decisione | Preservare, correggere o chiarire |
| Proposta target | Equivalente o comportamento previsto nel target, senza implementazione |
| Evidenza | Codice, test, log, query o documento |
| Confidenza | Alta, media o bassa |

Presenta la proposta target soltanto come requisito osservato, decisione fornita oppure raccomandazione esplicitamente dichiarata; non inventarla come fatto.

## Regole sulle anomalie legacy

Non correggere silenziosamente un comportamento legacy e non assumere che un'anomalia sia necessariamente un bug. Registra dipendenze e impatti noti, distingui comportamento osservato e decisione target e, senza una decisione verificabile, usa `UNCLEAR`.

```md
Legacy osservato:

Perché può essere un bug:

Dipendenze note:

Opzioni:
- preservare per compatibilità;
- correggere deliberatamente;
- introdurre una gestione configurabile;
- richiedere chiarimento.

Decisione:

Fonte della decisione:
```

## Parity matrix

| Caso | Legacy | Target atteso | Esito | Evidenza | Decisione |
| ---- | ------ | ------------- | ----- | -------- | --------- |
| ... | ... | ... | `MATCH` / `INTENTIONAL_CHANGE` / `LEGACY_BUG_PRESERVED` / `NEW_IMPLEMENTATION_BUG` / `UNCLEAR` | ... | ... |

* `MATCH`: comportamento legacy e target atteso coincidono.
* `INTENTIONAL_CHANGE`: differenza deliberata e supportata da una decisione.
* `LEGACY_BUG_PRESERVED`: comportamento anomalo mantenuto esplicitamente per compatibilità.
* `NEW_IMPLEMENTATION_BUG`: comportamento target osservato divergente senza decisione valida.
* `UNCLEAR`: evidenze o decisioni insufficienti.

Non usare `NEW_IMPLEMENTATION_BUG` senza una fonte target verificabile.

## Output minimo

```md
# Legacy inventory — [sistema o modulo]

## Scope e baseline
## Fonti consultate
## Domini analizzati
## Evidenze osservate
## Inventory
## Anomalie legacy
## Parity matrix
## Inferenze tecniche
## Rischi
## Punti aperti
## Handoff e validazioni necessarie
```

Separa sempre evidenza osservata, inferenza, punto aperto e raccomandazione. Per richieste operative consegna soltanto l'handoff tecnico.