# Legacy Source Recovery

Usa questo riferimento soltanto quando:

- non esiste una copia leggibile;
- history, backup e varianti non forniscono la sorgente;
- l'utente è autorizzato ad analizzare il codice;
- il recupero è necessario per inventory o parity analysis.

Non usare source recovery come prima scelta.

## Principi permanenti

1. Non eseguire il payload legacy.
2. Non usare `eval`, `exec`, include dinamici o import del codice recuperato.
3. Non contattare rete, DB o servizi esterni durante la decodifica.
4. Operare su una copia con checksum.
5. Conservare l'originale immutato.
6. Applicare limiti di dimensione, tempo e memoria.
7. Redigere segreti e PII.
8. Dichiarare che l'output derivato è evidenza da verificare, non sorgente autorevole automatica.

## Sequenza

### 1. Cercare una fonte leggibile

Controllare:

- history Git;
- branch/tag precedenti;
- file `_old`, `_orig`, backup o export;
- release package;
- artifact di build;
- documentazione;
- copie sibling;
- source map;
- versioni cliente/platform collegate.

Se esiste una copia affidabile, usare quella e fermare il recovery.

### 2. Congelare gli input

Registrare:

- path;
- dimensione;
- SHA-256;
- provenienza;
- ref/commit;
- autorizzazione;
- obiettivo.

Scrivere gli output in una directory separata e disposable.

### 3. Identificare lo strato

Classificare senza eseguire:

- encoding/compressione;
- string literal escaping;
- minificazione/ridenominazione;
- control-flow flattening;
- packing/encryption;
- bytecode o formato proprietario.

### 4. Decodificare senza esecuzione

Consentito:

- Base64 decode;
- decompressione tramite librerie dati;
- parsing AST;
- tokenizer/lexer;
- decoder di literal non eseguibile;
- source map;
- pretty printer.

Vietato:

- eseguire il file;
- eseguire la stringa decodificata;
- valutare token con `eval`;
- caricare il codice nel runtime applicativo;
- effettuare HTTP, query DB o scritture esterne.

### 5. Stringhe e literal

Preferire parser o AST già disponibili che restituiscano il valore del literal senza eseguire codice.

Se non esiste un decoder sicuro già disponibile, `mcp-technical-analyst` resta read-only e deve:

1. preservare il token originale;
2. documentare la grammatica minima e i requisiti del decoder;
3. indicare escape, Unicode, interpolazione e costrutti da rifiutare;
4. passare l'implementazione alla skill specialistica del linguaggio/runtime;
5. richiedere che l'utility operi soltanto in `neutral_path`, senza rete o credenziali;
6. riesaminare in modalità read-only output, checksum, test e limiti;
7. fermarsi su costrutti non riconosciuti.

L'analyst non crea codice, script o utility di decodifica.

Per stringhe interpolate:

- decodificare soltanto i segmenti literal;
- preservare variabili ed espressioni come token;
- non valutarle.

### 6. Isolamento

Quando serve un tool esterno:

- processo separato;
- working directory temporanea;
- rete disabilitata;
- filesystem limitato agli input/output;
- timeout;
- limite memoria;
- nessuna credenziale nell'ambiente;
- log dell'operazione.

### 7. Verifica

Confrontare:

- numero e posizione dei token;
- delimitatori;
- encoding;
- checksum dell'input;
- campioni di stringhe;
- tabelle/colonne con schema noto;
- costanti con caller osservati.

Non dichiarare il risultato semanticamente corretto soltanto perché è sintatticamente leggibile.

## Output

Produrre:

```md
## Source recovery

- Input:
- Provenienza:
- SHA-256:
- Tecnica:
- Tool/parser:
- Payload eseguito: no
- Rete utilizzata: no
- Output derivato:
- Verifiche:
- Limiti:
- Dati redatti:
- Confidenza:
```

## Stop conditions

Fermarsi se:

- l'autorizzazione è dubbia;
- serve eseguire il payload;
- il formato richiede chiavi non disponibili;
- il parser non distingue dati da codice;
- l'output può contenere segreti non redigibili;
- il recovery rischia side effect;
- la confidenza non è sufficiente per usarlo come evidenza.

In questi casi consegnare fatti, limiti e opzioni, senza improvvisare un decoder eseguibile.