~/progetti/magosox/README.md

COOKIES_ADVICE PRIVACY_POLICY.

~/progetti/magosox/README.md

magosox

{ data: “2026-08-01”, stato: “live”, moduli_stack: 12 }

Automatizza i contenuti social di un marchio — sceglie l'argomento, scrive il testo, crea le grafiche e pubblica

magosox produce i contenuti social di un marchio e li manda online da solo. Agli orari che gli sono stati fissati decide di cosa parlare, scrive il testo, ne ricava le grafiche e pubblica: nessuno deve aprire niente. La parte difficile non è pubblicare — la parte difficile è farlo mantenendo una voce riconoscibile. Un post automatico che suona come un post automatico non vale nulla, ed è esattamente lì che questo progetto mette la fatica.

## Il contesto del marchio è un dato, non del codice

Quello che rende un post riconoscibile — la voce, il modo di rivolgersi a chi legge, le cose che il marchio sa e quelle che di proposito non dice, insieme al magazzino degli argomenti — in magosox vive dentro il prodotto e non nel codice sorgente. Si scrive e si corregge dall'interfaccia, e la modifica vale dal post successivo, senza rilasci. Da qui discende tutto il resto: prendere in carico un marchio nuovo è configurazione e non sviluppo, e ogni marchio si porta il proprio contesto senza toccare quello degli altri.

## Strutturare la prosa, non spezzettarla

La qualità di un post non viene da un'architettura: viene da un migliaio di parole scritte bene. È una distinzione che sembra ovvia e che quasi tutti i sistemi di questo tipo mancano — spezzettano quelle parole in colonne, tono, formalità, usaEmoji: false, e poi le ricompongono, ottenendo istruzioni peggiori di quelle di partenza. In magosox le regole di voce sono righe che contengono testo reso alla lettera, a capo e rientri compresi. Il sistema sa soltanto quando iniettarle, in che ordine e sotto quale intestazione: struttura l'ambito, la gravità e la collocazione della prosa, mai la prosa. E perché un intervento sul motore non cambi la voce di nascosto, un test di regressione ricompila il prompt da quelle righe e lo confronta, carattere per carattere, con un riferimento congelato.

## Un registro invece di una query

Perché il feed non si ripeta, il sistema deve sapere di cosa si è parlato di recente. La mossa ovvia è ricavarlo dai post pubblicati, e non regge. La finestra conta i post, non i giorni, e nello stesso giorno può uscire più di un post: nessun ordinamento temporale sa metterli in fila. Ci sono poi i post scritti su richiesta, che non fanno riferimento ad alcun argomento in catalogo e quindi non potranno mai essere chiavi esterne. Così l'anti-ripetizione è un registro che si può solo accrescere, con una numerazione tutta sua. Un post schedulato brucia il suo argomento subito e lo restituisce se la pubblicazione fallisce: un ciclo di vita che lo stato di un post non saprebbe rappresentare senza mentire.

## Limiti dichiarati e limiti applicati

Per ogni superficie di testo esistono due numeri diversi: quello dichiarato al modello e quello che il controllo applica davvero. Un titolo può essere annunciato a 55 caratteri e rifiutato solo a 65, mentre il messaggio di correzione continua a dire 55. Quel margine di circa il 18% è ciò che tiene il tasso di rigenerazione vicino a zero, e pesa più di quanto sembri: il secondo tentativo produce in media un testo peggiore del primo. Collassare i due numeri in una colonna sola significa o inondare il ciclo di correzione, o lasciare che ogni titolo ingrassi del 18%.

## Dall'idea al post pubblicato

La pipeline gira senza sorveglianza, agli orari che il calendario prevede, e ogni passaggio lascia una traccia che si può rileggere:

·Scelta dell'argomento: cadenza dei pilastri di contenuto, cooldown, rotazione delle categorie per uso meno recente, stagionalità — con un generatore casuale seminato, così una scelta si può rigiocare
·Generazione: prompt compilato dal contesto del marchio, structured output, sanitizzazione, validazione e ciclo di correzione conversazionale
·Rendering: mustache e Chrome headless producono i JPEG; tema, template e versione di Chrome vengono fissati su ogni render
·Pubblicazione: Instagram Graph API in tre fasi, con ripresa dai container già costruiti e rinnovo automatico del token
·Scheduling: slot che fissano giorni e ora — e volendo il pilastro o il formato di quel giorno — occorrenze materializzate da questi, e un worker che genera in anticipo e pubblica all'ora esatta

## L'interfaccia

L'amministrazione è il posto in cui il contesto del marchio viene davvero modificato, senza che nessuno debba avvicinarsi a un repository. L'accesso è senza password, con un codice via email; la registrazione non esiste, le utenze si creano da terminale.

·Contesto: sezioni di prompt, regole di voce e documenti, tutto modificabile
·Prompt: il testo esatto che partirebbe verso il modello, senza chiamarlo
·Argomenti: il magazzino, con eleggibilità e distanza dall'ultimo uso in colonna
·Tassonomia: pilastri con la loro cadenza, categorie, tag con il loro colore, formati con i limiti dichiarati e quelli applicati
·Post e calendario: cosa esce e quando, e in che stato
·Impostazioni: i provider di modello, storage, email e rendering, ognuno con l'esito di un controllo vero

## Stack tecnologico

L'approccio alla configurazione merita una nota: le variabili d'ambiente sono l'unico modo di configurare il servizio prima che il database esista, quindi restano. Dal primo avvio in poi, però, vince il valore salvato, e l'interfaccia mostra quale dei due sta vincendo. Cambiare la chiave del modello alle tre di notte non deve richiedere un accesso al server.

·API: NestJS su Fastify, Prisma e PostgreSQL
·Amministrazione: React, Vite, HeroUI, TanStack Query e Router
·Generazione: Claude con structured output
·Rendering: Chrome headless, con i font inlinati come data URI perché Chrome applica il CORS ai @font-face anche tra documenti file://
·Storage: Cloudflare R2 — Instagram scarica le immagini da un URL pubblico
·Accesso: better-auth con codice usa-e-getta via email, sessione in un cookie httpOnly
·Esercizio: Docker Compose dietro un Caddy condiviso, con TLS automatico

magosox è in produzione dal 1 agosto 2026 e pubblica senza sorveglianza, con la cadenza che gli è stata impostata. Prima di partire è stato caricato anche lo storico dei contenuti già usciti in passato, così che l'anti-ripetizione avesse una memoria fin dal primo giorno invece di doversela costruire in settimane.

// stack
[nestjs”, fastify”, prisma”, postgres”, react”, vite”, typescript”, claude-api”, instagram-api”, docker”, caddy”, content-automation”, ]