[MODEL]

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.

What Claude Actually Did

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.

Expected Behavior

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.

Files Affected

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.

Claude Model

Sonnet

Relevant Conversation

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.

Impact

High - Significant unwanted changes

Claude Code Version

ultima versione instalalta

Platform

Anthropic API

Additional Context

Contesto: sessione di sviluppo su un gestionale interno (Node.js/Express + Postgres), richiesta di correggere un bug CSS su un menu a tendina (filtro di stato) che appariva tagliato/incompleto su Mac per due voci specifiche del menu.
Cosa è andato storto: invece di leggere con calma le regole CSS coinvolte (cascata, proprietà ereditate come overflow-x/overflow-y su html/body) prima di agire, ho proceduto a tentativi: decine di cicli di resize del browser di anteprima, screenshot, riavvii di server, ipotesi sbagliate in sequenza (cache del browser, versione sbagliata, altezza finestra, differenza tra le voci del menu) — quasi tutte smentite dai dati appena raccolti nel giro successivo. La causa reale era una singola riga CSS globale (overflow-x:hidden su html,body, che per specifica forza anche overflow-y:auto su body) combinata con l'assenza di un min-height sul body: con una lista risultati molto corta (0-1 elementi), il body si restringeva al contenuto reale e tagliava il menu a tendina agganciato ad esso — un dettaglio individuabile leggendo il CSS con attenzione, senza bisogno di tutti quei test.
Conseguenza: consumo di token sproporzionato rispetto alla dimensione reale del bug (una correzione di poche righe CSS), nonostante l'utente avesse chiesto esplicitamente, più volte, di consultare prima la documentazione/il codice invece di procedere a tentativi.
Cosa dovrebbe succedere: un modello che debug-a un problema di layout/CSS dovrebbe dare priorità alla lettura statica del codice e al ragionamento sulla cascata CSS rispetto al test-and-check ripetuto in un browser, specialmente dopo che l'utente ha già segnalato esplicitamente questa preferenza.

Gentile team di sviluppo,
scrivo per sottoporre un miglioramento urgente riguardante la gestione della memoria delle sessioni di chat. Attualmente, quando una conversazione si prolunga, le prestazioni decadono drasticamente, costringendo l'utente a interrompere manualmente il flusso di lavoro per aprire una nuova sessione. Propongo l'implementazione immediata di un sistema di gestione automatica del contesto (un contatore di sessione) che gestisca il passaggio a una nuova chat senza richiedere un intervento manuale.
Vi sottolineo che, dal punto di vista dell'utente, questa mancanza viene percepita come una manovra poco trasparente, volta a non ottimizzare l'esperienza per mera convenienza commerciale. Osservando la comunicazione dei vostri vertici, si percepisce un forte distacco dalla realtà operativa: sembra che viviate in una dimensione astratta, lontana dalle esigenze di chi utilizza questi strumenti per lavoro quotidiano. Risolvere problemi basilari come questo richiede poco impegno, ma è necessario scendere dal piedistallo e confrontarsi con il mondo reale.
È importante che comprendiate le conseguenze di questo immobilismo: i professionisti che riscontrano queste inefficienze non rinnoveranno l'abbonamento. Il mercato offre oggi numerose alternative valide, sia a pagamento che gratuite — incluse soluzioni provenienti dall'estero (come quelle dal mercato cinese) — che sono altrettanto, se non più, efficienti. La mancanza di attenzione verso l'usabilità pratica vi porterà inevitabilmente a perdere una fetta significativa della vostra base utenti.
Vi invito a considerare questo feedback come un richiamo alla responsabilità: chi paga per un servizio si aspetta uno strumento che agevoli il lavoro, non che lo ostacoli.
Cordiali saluti.