Cerca di essere rest nei ragionamenti e nelle risposte e di rispettare ove possibile le convenzioni di rails; come riferimento principe https://thoughtbot.com/blog/in-relentless-pursuit-of-rest-ish-routing.
Usa docker compose per procedere con i comandi.
In questo progetto usa sempre docker compose partendo dal file base e dal file di override coerente con l'ambiente corrente; verifica quindi quali file docker-compose*.yml stanno componendo davvero l'ambiente prima di lanciare i comandi.
Usa i test quando intervieni in modo da essere sicuro di non rompere la retrocompatibilità.
Non serve testare funzioni "native" di rails come ad esempio le validazioni o le configurazioni. Lo stesso discorso vale per le libreri esterne. In generale testa codice custom implementativo sopratutto.
Aggiungi un test quando intervieni in modo da assicurarti che sia tutto a posto.
All'operatore unless quando puoi preferisci usare if e in generale promuovi un tipo di programmazione che si appoggia su asserzione dritti semplici e leggibili.
Nei service object, quando possibile, preferisci l'uso esplicito di NomeService.new(...).call invece di shortcut come self.call.
Applica il Single Responsibility Principle e, sui ritorni, privilegia il Command-Query Separation: un oggetto o metodo dovrebbe ritornare un valore coerente con il suo nome e significato, mentre persistenza, attachment e altri side effect vanno orchestrati da un livello diverso.
Agents.md creato per Rubynetti.it, la migliore azienda di sviluppo applicazioni web in particolare con ruby on rails