La cartella aveva dentro solo rules/ e i settings: nessun posto dove mettere una skill, un hook o un piano. Ora ha lo scheletro completo e un .claude/CLAUDE.md che spiega cosa va dove — non duplica CLAUDE.md di progetto, che resta quello che comanda. Due skill locali (le altre restano globali in ~/.claude/skills/): - /preventivo — la catena agent.ts → schema.ts → assemble.ts → ProposalDeck e i tre modi di romperla, di cui uno solo fa rumore. Nessun prompt di generazione qui dentro: quello vive in agent.ts ed e' l'unico. Porta check-profilo.sh. - /audit — guida scripts/audit-fonti.ts, nuovo, che mette in moto le cinque fonti di src/lib/audit/sources/, in prod dal 2026-08-19 ma mai chiamate da nessuno. Provate su giojello.com: 5 su 5, 42,7 s, PageSpeed mobile 58 / desktop 93. Due hook, provati a mano (6 casi il primo, 5 il secondo): - guardia-migration.sh BLOCCA l'SQL distruttivo sulle entita' protette — il vincolo Data Safety (LOCKED) fatto rispettare dalla macchina invece che dalla memoria. - guardia-token.sh AVVISA sulle classi Tailwind grezze. Non blocca: con ~450 occorrenze di debito, bloccare lo renderebbe un ostacolo da disattivare. I tre piani di v2.5 entrano nel repo: stavano solo in ~/.claude/plans/ e STATE.md avvertiva che senza quelli la milestone non era ricostruibile. Passati al setaccio per credenziali prima di committarli. Corretta in rules/memory-discipline.md la chiave della memoria persistente: e' …-Vault-IAMCAVALLI-hub, non quella del workspace. Sedici file stavano nella prima, la regola indicava la seconda. Impeccable resta abilitato solo a livello globale: fuori da settings.json locale. Nessun tocco al prodotto. Build e lint verdi, lint identico al baseline. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.4 KiB
Regola: la memoria di progetto si aggiorna, sempre
.planning/STATE.md è la fonte di verità su dove siamo. È rimasto fermo dal 2026-06-21 al 2026-07-28 mentre venivano chiusi un audit di sicurezza, una riorganizzazione della cartella e mezzo design system: chi riapriva il progetto leggeva uno stato falso. Questa regola esiste per impedire che si ripeta.
Quando aggiornare
Dopo ogni unità di lavoro conclusa — una fase, una migration applicata, un fix deployato, una decisione presa che cambia la rotta. Non a fine milestone: a fine cosa.
Cosa scrivere in .planning/STATE.md
- Frontmatter:
last_updated(ISO, data reale),last_activity,status,progress. - Current Position: fase, stato, e soprattutto se qualcosa blocca.
- Blocchi: marcati
[BLOCCANTE], con cosa manca e chi/cosa lo sblocca. Un blocco non scritto è un blocco che si riscopre a caro prezzo. - Lezioni: quando un approccio si rivela sbagliato, scrivere perché falliva, non solo cosa si è fatto al suo posto. Serve a non riprovarci fra due mesi.
- Date assolute, mai "ieri" o "la settimana scorsa".
Cosa scrivere nella memoria persistente
~/.claude/projects/-Users-simonecavalli-Vault-IAMCAVALLI-hub/memory/ — un file per fatto, più la riga di indice in MEMORY.md.
⚠️ La chiave finisce in -hub. Quella senza suffisso (…-Vault-IAMCAVALLI/memory/) è la memoria del workspace, un altro posto con altri file: scriverci un fatto di ClientHub significa non ritrovarlo più, perché a inizio sessione qui viene iniettata solo quella con -hub. Da non confondere nemmeno con .claude/memory/, che è versionata nel repo — la distinzione sta in ../CLAUDE.md.
Ci va quello che non si deduce dal repo: decisioni e il loro perché, vincoli operativi, cose che sono state provate e non funzionano. Non ci va quello che il codice già dice: struttura, cronologia dei fix, contenuto di CLAUDE.md.
Se un fatto in memoria diventa falso, correggerlo o cancellarlo. Una memoria sbagliata è peggio di una memoria assente.
Cosa NON fare
- Non scrivere "completato" per lavoro che compila ma non è stato verificato. Distinguere sempre scritto / testato / in produzione — sono tre stati diversi e confonderli è il modo più veloce per deployare un disastro.
- Non lasciare
STATE.mda raccontare la milestone precedente.