Imported from FedericoDeBona/perpendicular_desktop (
AGENTS.md). Install upstream withnpx skills add FedericoDeBona/perpendicular_desktop. Copyright stays with the author.
Regole di lavoro
Prima di iniziare o riprendere il lavoro, leggi docs/KNOWN_ISSUES.md per problemi, stato corrente e prossimi passi, poi docs/RESTART_PLAN.md per requisiti e vincoli e docs/TODO.md per attività, priorità e stato di avanzamento. Le istruzioni dell'utente hanno precedenza.
- Mantieni obbligatoriamente aggiornata docs/TODO.md quando cambia un requisito, una priorità, un blocco o l'esito del lavoro. Conserva gli ID e le attività concluse; indica stato, prossimo passo e criterio di completamento. Distingui implementazione, verifica nel clone e verifica nell'app principale. Segna FATTO solo con evidenza pertinente in VERIFICATION.md; per BLOCCATO o IMPOSSIBILE indica motivo, perimetro e cosa potrebbe cambiare l'esito. Se manca un meccanismo concreto di misura, segnala il limite all'utente senza inventare risultati o avviare prove prive di significato. Aggiorna anche KNOWN_ISSUES.md quando riguarda un difetto esistente, senza creare registri concorrenti dello stesso problema.
- Aggiorna il registro dei problemi quando emerge un difetto o cambia l'esito di una verifica. Cerca e aggiorna la voce esistente prima di crearne una nuova; collega le evidenze in VERIFICATION.md. Distingui correzioni nel clone, verifiche circoscritte e distribuzione nell'app ordinaria. Chiudi una voce soltanto quando il suo criterio di chiusura è verificato; conserva gli esiti negativi nel diario delle verifiche.
- Parti dai requisiti del prodotto. Linguaggi, librerie, protocolli e struttura interna richiedono una scelta motivata sul sistema effettivo.
- Distingui requisiti dell'utente, ipotesi tecniche e capacità realmente verificate.
- Consulta implementazioni o esperimenti precedenti soltanto per rispondere a una domanda precisa; non ereditarne automaticamente architettura, dipendenze o conclusioni.
- Verifica prima il percorso minimo completo. Registra anche errori e tentativi falliti; non presentare una singola riuscita come prova di affidabilità generale.
- Fai pochi test mirati: privilegia una breve prova end-to-end nell'app reale e aggiungi controlli automatici soltanto per dubbi concreti o logica critica. Non costruire centinaia di test, grandi harness, benchmark estesi o test che replicano l'implementazione. Dopo una verifica riuscita prosegui; ripetila solo per modifiche pertinenti o nuovi problemi. Non incastrarti a perfezionare un sottocomponente: completa piccoli passaggi utilizzabili.
- Per ogni passaggio definisci un risultato osservabile e una verifica minima. Se tentativi ripetuti non producono un miglioramento utilizzabile, documenta il limite, conserva il percorso funzionante e scegli un passo più piccolo o un'alternativa concreta. Non ampliare i test per compensare la mancanza di progresso nell'app.
- Mantieni separabili i componenti necessari, senza costruire astrazioni per funzioni non ancora richieste.
- Preserva i dati e le modifiche dell'utente. Tieni credenziali, dischi delle VM e artefatti generati fuori dal repository.
- Durante il lavoro, crea commit e fai push su GitHub ai passaggi completati e verificati, senza aspettare una nuova richiesta dell'utente. Raggruppa modifiche coerenti; non pubblicare credenziali, stato privato della VM o artefatti generati. Non usare push forzati.
