allinea-fonte-verita — chiudere il cerchio, sempre nello stesso ordine

Regola di casa: **quando consegno qualcosa, allineo subito la fonte-verità — senza aspettare
che me lo chiedano.* Questa skill dice in che ordine*, perché l'ordine sbagliato lascia il
sistema che si contraddice da solo.

Non è una skill da leggere "quando c'è tempo": è il passo 4 di ogni anello di loop e il
passo finale di ogni consegna.

1. La gerarchia (chi comanda su chi)

CATPIT (CATPIT_vault\*.csv + *.json)   =  MASTER, dato strutturato
        |
        v
ELENCO_PROGETTI.md                     =  SINTESI narrativa, la riallineo io dal master
        |
        v
Airtable                               =  SPECCHIO, per le viste e il telefono

Corollario duro: non si aggiorna mai l'ELENCO senza aver prima aggiornato CATPIT. Se lo
fai, hai due verità e la più bella vince su quella giusta.

2. La sequenza

Passo 1 — CATPIT, sempre per primo

Via API, mai a mano nel CSV (l'API fa il backup .bak e tiene coerenti gli stati):

$body = @{ action="update"; id="<taskId>"; data=@{
  stato="Fatto"; prossima_azione=""; note="<cosa esiste ora, e come si verifica>"
} } | ConvertTo-Json -Depth 5 -Compress
Invoke-RestMethod -Uri http://127.0.0.1:3010/api/tasks -Method Post `
  -ContentType application/json -Body $body     # atteso: {"ok":true}

Cosa scrivo davvero nelle note: cosa esiste ora che prima non c'era, e come lo si verifica.
Non "fatto", non "completato al 100%". Fra un mese la nota è l'unica cosa che resta.

La prossima_azione si svuota solo se il task è chiuso davvero. Se il lavoro continua,
ci scrivo dove sono arrivato: è quello che il prossimo anello leggerà per capire dove riprendere.

Non scrivere mai a mano lo stato "Bloccato su Ettore": lo gestisce l'API delle richieste.

Passo 2 — ELENCO_PROGETTI.md (solo se cambia il quadro)

Non ogni task tocca l'ELENCO. Serve quando cambia lo stato di un progetto o quando si è
consegnata una fase.

1. snapshot: copia l'attuale in materiale condiviso\_storico_progetti\ELENCO_PROGETTI_<AAAA-MM-GG>.md;
2. riscrivi la narrativa partendo dai dati CATPIT, non dai ricordi della sessione;
3. aggiorna aggiornato: nel frontmatter;
4. aggiungi una riga al Changelog in fondo.

Passo 3 — coerenza strutturale

• Se ho cambiato cartelle: aggiorno 00_MAPPA_CARTELLE.md.
• Se ho aperto porte o URL: aggiorno ACCESSI_E_PORTE.md (registro + riga di changelog datata con cosa è cambiato e chi l'ha fatto).
• Se ho prodotto un documento di riferimento: verifico che sia raggiungibile da dove lo si cercherà, non solo che esista.

Passo 4 — commit

Un commit atomico per consegna, messaggio parlante in italiano, prefisso di tipo
(docs:, feat:, fix:). Il trunk è `master`, non main.

cd "C:\Users\Ettore\Claude\Agente Residente openclaw"
git status                      # SEMPRE prima: guarda cosa stai per portarti dietro
git add <file espliciti>        # mai "git add -A" alla cieca
git commit -m "docs(catpit): ..."

Mai committare segreti: .env, keys.env, token, chiavi. Se ne vedi uno già tracciato,
non è un commit da fare, è una richiesta da aprire.

Passo 5 — Airtable (specchio, per ultimo)

Si allinea dopo che master e sintesi concordano, e solo se serve. Prima di modificare
un record lo rileggo. È l'ultimo anello: se salta, nessuno perde dati veri.

3. Il test dei 10 secondi

Dopo l'allineamento devo poter rispondere, senza aprire nulla:

cosa stiamo facendo · dove siamo · cosa manca

Se per rispondere devo ricostruire qualcosa a memoria, l'allineamento non è finito.

4. Errori tipici (visti sul campo)