L’ANALISI
Alook 0.1.64: allegati IMAP e inviti senza ambiguità
Alook 0.1.64 corregge dimensioni degli allegati, byte IMAP e orari assoluti degli inviti. Cosa verificare prima di affidargli email reali.
In breve: Alook 0.1.64 corregge la lettura degli allegati e dei messaggi IMAP e la gestione temporale degli inviti. È un aggiornamento di affidabilità per chi collega email e agenti, non un nuovo modello né una garanzia che un flusso con caselle e calendari reali sia già verificato. Release Alook 0.1.64.
Verifica documentale del 5 novembre 2026: release REST, tag v0.1.64 fissato al commit 6fc4c31afe491c7125d0a49a290b8ccd1ba3fc52, README e descrizioni delle pull request 1174 e 1177. Nessuna installazione, autenticazione a provider, generazione del modello o prova di consegna e calendario. L’immagine è fornita dal progetto e illustra l’interfaccia, non il risultato di un nostro test.
Che cosa cambia nella release del 5 novembre?
La v0.1.64 è pubblicata il 5 novembre alle 06:55:34 ora italiana e l’API la distingue da una prerelease. Le due correzioni email erano state integrate il 4 novembre: la data della modifica e quella della release non sono lo stesso evento. Le note elencano anche interventi su interfaccia, daemon e documentazione, ma qui ci concentriamo sui dati che un agente deve ricevere senza alterazioni. Il repository pubblico non è archiviato e il tag identifica il commit verificato; non assumiamo che il ramo main resti identico nel tempo. Alook 0.1.64: note ufficiali di rilascio.
Perché i byte IMAP e la dimensione di un allegato contano?
La PR 1174 descrive due difetti distinti. Gli allegati restituiti dal parser come viste Uint8Array potevano essere registrati con dimensione zero. Inoltre IMAP esprime la lunghezza dei literal in ottetti: decodificare il testo prima di delimitarli poteva troncare messaggi non ASCII o scambiare una riga dentro al messaggio per la fine della risposta di protocollo. La correzione usa la lunghezza della vista e conserva i byte fino al passaggio al parser. È una modifica al percorso di ricezione, non una promessa di recuperare messaggi già persi o di neutralizzare contenuti malevoli negli allegati. Alook PR 1174: dimensioni degli allegati e byte IMAP.
Come vengono trattati gli inviti con un orario incerto?
La PR 1177 affronta inviti che potevano perdere il fuso o acquisire un istante iniziale sbagliato. Producer e consumer condividono un valore canonico in millisecondi UTC oppure null; i casi non supportati non diventano automaticamente un orario valido. La descrizione prevede che inviti incerti restino pending e che l’email originale sia conservata. Il limite è deliberato: non basta visualizzare una data plausibile per dimostrare una conversione corretta. La validazione descritta dal progetto non include una prova effettiva di scheduling, autojoin o richiesta al provider del meeting. Alook PR 1177: istanti assoluti degli inviti.
Agenti locali significa che tutti i dati restano sul computer?
No. Il README descrive agenti che continuano a girare sulla macchina dell’utente, ma anche una componente ospitata, WebSocket, code e storage. Alook collega runtime esistenti e non fornisce un proprio modello. Il perimetro è quindi ibrido nel percorso documentato: esecuzione locale dell’agente e servizi di collaborazione non vanno confusi con inferenza offline o assenza di trasferimenti. Prima di collegare una casella, occorre verificare separatamente il servizio Alook, il runtime scelto, il provider del modello e le autorizzazioni. Qui non abbiamo misurato traffico, retention o isolamento fra account. Alook: architettura e runtime al commit della release.
Quale prova controllata proporre prima dell’uso reale?
Un test utile confronta la sorgente con ciò che il sistema conserva, senza partire dalla casella personale. Proponiamo un account di prova e messaggi creati appositamente: testo con caratteri non ASCII, allegato di dimensione e hash noti, invito con fuso esplicito e un caso temporale non supportato. Si controllano byte e dimensione ricevuti, istante UTC atteso e permanenza dello stato incerto dove necessario. Ricezione, interpretazione, pianificazione ed eventuale azione dell’agente sono quattro passaggi da registrare separatamente. Questa è una proposta di verifica derivata dai difetti descritti, non un protocollo già eseguito né una certificazione della release. Alook PR 1174: dimensioni degli allegati e byte IMAP.
Il diverso confine dei permessi è analizzato nella scheda Alook 0.1.62 su Automation e invii. Per confrontare gli altri aggiornamenti torna all’hub Radar AI.
Condizioni e limitazioni
Verifica documentale di release, tag e pull request, non prova end-to-end. Non abbiamo installato Alook, collegato caselle, ricevuto allegati o eseguito inviti reali. I test riportati dal progetto non dimostrano consegna email, collegamento ai provider o corretto scheduling in produzione; gli inviti non risolti restano incerti.
Checklist pratica
- Fissare v0.1.64 e il commit verificato; non confondere il tag con il ramo main aggiornabile.
- Usare soltanto una casella e inviti di prova, senza dati di clienti o messaggi personali.
- Conservare sorgente del messaggio, dimensione e hash dell’allegato prima dell’invio; confrontarli dopo la ricezione.
- Includere caratteri non ASCII e controllare che la lettura IMAP non tronchi il contenuto.
- Verificare separatamente fuso dichiarato, istante UTC e stato pending per un invito non risolto.
- Non abilitare invii, autojoin o altre azioni su account reali sulla sola base dei test unitari del progetto.
- Documentare runtime, provider del modello, autorizzazioni, servizi ospitati ed esiti prima di ampliare il test.