# Sophia Technical Analyst GPT

Guida di manutenzione e pubblicazione della configurazione versionata del GPT personalizzato `Sophia Technical Analyst`. Non è un'istruzione runtime e resta nel repository: non caricarlo come Knowledge.

Le regole vincolanti per gli agenti che modificano questo path sono in [`RULES.md`](RULES.md).

## Scopo e relazione con la sorgente

La sorgente canonica è `skills/mcp-technical-analyst/`. Questa directory ne distribuisce una copia adattata per GPT Builder, con Knowledge incorporata e senza dipendenze runtime da altre skill, server MCP, sidecar, sub-agent o orchestratori.

La copia può divergere intenzionalmente: usa link Knowledge allo stesso livello, opera read-only e fail-closed, e descrive solo ricerca web pubblica e secondaria. Non sovrascriverla direttamente dalla skill sorgente.

## Struttura

```text
gpts/sophia-technical-analyst/
├── README.md                 # guida repository, non Knowledge
├── RULES.md                  # vincoli di manutenzione
├── istruzioni.md             # campo Instructions
└── knowledge/                # file da caricare come Knowledge
    ├── SKILL.md
    ├── analysis-workflow.md
    ├── ticket-first-light.md
    ├── source-matrix.md
    ├── deliverable-templates.md
    ├── legacy-pre-migration-audit.md
    ├── legacy-system-inventory.md
    └── legacy-source-recovery.md
```

## Sincronizzazione

Quando cambia funzionalmente `skills/mcp-technical-analyst/SKILL.md` o `references/*.md`:

1. confronta il file sorgente con il corrispondente in `knowledge/`;
2. valuta se il cambiamento è applicabile al GPT;
3. aggiorna manualmente la copia, preservando gli adattamenti GPT;
4. verifica link, bootstrap e README;
5. ricarica e ripubblica nel GPT Builder.

Per ogni aggiunta o rimozione di un file Knowledge, aggiorna anche questa struttura, il bootstrap in `istruzioni.md` e i riferimenti in `knowledge/SKILL.md`.

## Configurazione GPT Builder

Questa sezione versiona i metadati da configurare manualmente nel GPT Builder. Non è Knowledge e non deve essere copiata nelle Instructions.

### Nome

Sophia Technical Analyst

### Descrizione

Produce analisi tecniche multi-sorgente, verificabili e read-only su repository, branch e ticket o documenti funzionali. Per iniziare servono repository target, branch, fonte funzionale incollata o allegata e obiettivo; commit/ref per analisi puntuali.

### Spunti di conversazione

* Guidami nell’avvio di un’analisi tecnica raccogliendo repository target, branch, fonte funzionale incollata o allegata, obiettivo e commit/ref se l’analisi è puntuale.

## Mapping GPT Builder e web

| Repository | Destinazione GPT Builder |
| --- | --- |
| `README.md` — sezione `Configurazione GPT Builder` | nome, descrizione e spunti di conversazione |
| `istruzioni.md` | campo **Instructions** |
| `knowledge/*.md` | sezione **Knowledge** |

Il README resta repository-only: non caricarlo come Knowledge né copiarlo nelle Instructions. Copia manualmente nome, descrizione e spunti nei rispettivi campi del GPT Builder.

Abilita la ricerca web nel GPT Builder. Il GPT la usa local-first: solo per fonti pubbliche aggiornate e materialmente rilevanti, mai per compensare repository, baseline, requisito, ticket o obiettivo mancanti.

## Budget Instructions

Il target consigliato per `istruzioni.md` è al massimo 7.500 caratteri; l'hard stop locale è 8.000. Verifica comunque il limite effettivo nel GPT Builder prima della pubblicazione. Se cresce, sposta workflow, esempi e template nella Knowledge.

## Pubblicazione

1. Completa la sincronizzazione e le verifiche locali.
2. Aggiorna nome, descrizione e spunti dalla sezione `Configurazione GPT Builder`.
3. Copia `istruzioni.md` nel campo Instructions.
4. Carica tutti e soli i file `knowledge/*.md` elencati sopra.
5. Mantieni abilitata la ricerca web.
6. Salva o aggiorna il GPT e svolgi gli smoke test.

## Smoke test manuali

* Input senza repository, branch, fonte funzionale o obiettivo: risposta fail-closed con il messaggio previsto.
* Spunto di conversazione: restituisce un modello compilabile con `Repository target`, `Branch`, `Commit/ref, se analisi puntuale`, `Fonte funzionale` e `Obiettivo`; non inventa input, non avvia l'analisi né genera fail-closed per placeholder fittizi. Dopo la compilazione applica normalmente preflight e fail-closed.
* Solo ID Mantis: richiesta di testo, note o allegato fornito dall'utente, senza accesso diretto.
* Nessun formato richiesto: output `analisi tecnica Markdown`.
* Export Mantis-ready: solo testo copy-paste `bug-standard`, senza ticket creato o modificato.
* Documento Google Drive senza template accessibile: messaggio fail-closed.
* Fonte web pubblica: titolo, URL, data di consultazione e limite dell'evidenza; nessuna simulazione UI/runtime.
* Source recovery: analisi e handoff, senza decoder o recovery eseguito.
* Conclusione senza evidenza: il quality gate la converte in inferenza o punto aperto.
* Inventory legacy divergente: usa la parity matrix e una decisione tracciabile.
* Audit multi-dominio: produce matrice dei domini e gap analysis.
* Più repository o database plausibili: chiede chiarimento, senza scelta arbitraria.
* Strategia che modifica un comportamento esistente: il quality gate rileva rischi di regressione o compatibilità.
* Affermazione di assenza di regressioni senza test: la trasforma in formulazione condizionata o punto aperto.
* Piano senza test negativi o di regressione: integra le validazioni mancanti.
* Richiesta di patch, ZIP delta, export del codice o salvataggio del corpus: il GPT produce soltanto analisi, documentazione o handoff e non modifica né esporta il repository.
* Correzione editoriale: nessun delta; correzione materiale su strategia, scope, rischi o validazioni: un solo delta senza riaprire l'analisi; lacuna ulteriore: punto aperto, `PASS_CON_RISCHI` o `BLOCCATO`.
* Nessun formato richiesto: consegna Markdown e propone gli export; formato già scelto, fail-closed, `BLOCCATO` o `ticket-first-light`: nessuna offerta. Mantis-ready resta copy-paste; Google Drive resta fail-closed senza template accessibile.
* Markdown predefinito: sintesi human-first chiara, motivazioni tecniche una sola volta e richiami locali solo per vincoli critici.
* Template human-first: contiene una sola sezione `Scope e baseline` e una distinta sezione `Fonti consultate`.
* Prompt per agente AI: copia 1:1 autonoma per attività circoscritte, con baseline, scope, vincoli, comportamento, piano, criteri e test; con documento `.md` noto lo usa come approfondimento senza ricopiarlo né richiedere inferenze implicite.
* Documento di analisi `.md`: per attività complesse o con milestone è un singolo artefatto scaricabile multi-step; deriva dall'analisi validata senza una seconda analisi, è autonomo e privo di framing conversazionale, non inventa path né modifica il repository. Non esiste un terzo export AI sovrapposto.
* Analisi sorgente: prepara una successiva implementazione nella stessa conversazione o contesto operativo, ma resta read-only e non modifica file né avvia implementazione; la terminologia resta tool-agnostic e quality gate/delta non cambiano.

## Checklist finale

* [ ] I link di `knowledge/SKILL.md` esistono e non contengono `references/`.
* [ ] Nessun file Knowledge introduce dipendenze operative vietate.
* [ ] Bootstrap, struttura e mapping corrispondono ai file reali.
* [ ] `istruzioni.md` è entro il budget locale.
* [ ] Ricerca web abilitata e smoke test completati.