# Aisthetix — regole di sviluppo

## GitHub Projects — sviluppo seriale Aisthetix

Board: https://github.com/users/davidemastricci/projects/6

- Mira Toscano è l’unico agente autorizzato a creare e rivedere Draft specs. Promuove a Specs solo dopo approvazione esplicita di Davide in chat della versione corrente. Gli agenti di sviluppo non creano, modificano o prelevano task da queste colonne. Solo Davide sposta manualmente Specs → Work in progress per autorizzare lo sviluppo. Il dossier di prodotto è nella cartella product-agent della workspace; Mira opera solo su Hetzner.
- Una sola issue attiva in totale tra tutti gli otto repository, anche quando Work in progress contiene più issue. Il controllo è orario; riprendere sempre l'issue già attiva. Un blocco non autorizza a passare alla successiva.
- Il coordinatore locale è `workflow/kanban/board.py` nella workspace Aisthetix. Usare `claim` prima di sviluppare; il registro persistente conserva l'issue attiva attraverso i riavvii. Non aggirare il coordinatore avviando altri worker o automazioni.
- Ordine per nuove selezioni: prima eventuali Done da verificare, poi la prima issue Work in progress nell'ordine della board. Ignorare draft e PR come unità di lavoro; se manca repo o criteri di accettazione chiedere chiarimenti senza inventare le specs.
- Usare branch/worktree isolati, preservare modifiche altrui, collegare tutte le PR alla issue. Per task multi-repo resta una sola issue coordinatrice.
- Finita l'implementazione spostare in Done. Eseguire `python3 scripts/quality_gate.py` in ogni repo coinvolto sul commit finale. Test, coverage, controlli statici e build devono passare: tool mancanti, timeout o test assenti sono errori. Non ridurre soglie/escludere codice per ottenere il verde.
- In caso di errore mantenere Done e correggere la stessa task; non passare a QA e non iniziare un'altra issue.
- QA richiede PR, commit verificati, report di qualità, URL dell'ambiente di test, passi numerati con risultato atteso e video reale della funzionalità. Il video deve riferirsi alla versione verificata; niente video simulati o link locali inaccessibili all'utente. Per backend/infra registrare il percorso di verifica su terminale/strumenti pertinenti. Non mostrare credenziali o dati privati.
- Pubblicare il pacchetto QA sulla issue, poi usare `board.py qa --evidence <json>`. Se manca una prova, restare in Done. Una task arrivata in QA libera il posto per la successiva.
- Solo Davide sposta QA → QA done. Se la rimette in Work in progress, riprenderla quando il posto è libero. Non chiudere automaticamente le issue in Done/QA.
- QA done non autorizza automaticamente merge/deploy. Deployed significa rilascio autorizzato effettivamente completato e verificato. Non cambiare pipeline di deploy o protezioni branch per aggirare QA.
- Controllare l'esito una volta all'ora senza notifiche ripetitive: avvisare su consegna QA, fallimento nuovo o richiesta d'intervento.

## Qualità di questo repository

Eseguire `python3 scripts/quality_gate.py --plan` per vedere i comandi; `python3 scripts/quality_gate.py` per eseguirli. Configurazione: `quality-gate.json`. Report in `.quality/reports/`. Installazione strumenti: `bash scripts/quality_setup.sh`. La soglia iniziale di coverage è 80%; eventuali debiti esistenti vanno segnalati e risolti, senza ridurla automaticamente.