Package Accordo: estensioni esplicite senza forkare il motore

In breve. In Accordo un dominio opzionale vive in un package: sorgente versionato nel tuo repository, registrato con un import statico, che si attacca e si stacca lasciando invariata l'impronta del nucleo e raggiunge gli altri package solo attraverso capability dichiarate. La tesi che ne ricavo, ed è interpretazione mia: è questo il confine che rende il custom sostenibile — il motore resta agnostico, il business vive nei moduli e nei package. Con il contratto, gli esempi e i limiti dichiarati. Pubblicato il 6 ottobre 2026.

Cosa promette il contratto

La promessa è una sola, ed è verificata dai test: un package scritto dal cliente si attacca e si stacca con l'impronta del nucleo invariata, e raggiunge un altro package solo attraverso una capability che dichiara. Non c'è un meccanismo di estensione privato, nessuna API plugin riservata ai package ufficiali, nessun marketplace: un package è sorgente versionato nel tuo repository, registrato con un import statico. La stessa strada che usano i package interni.

Gli esempi nel repository mostrano tre taglie: il più piccolo package onesto — una risorsa, un'azione, una policy, scritto come lo scriverebbe un cliente; un package che dipende da un altro attraverso una capability dichiarata; uno che una capability la offre agli altri. Tre esempi, non tre livelli di prezzo: il contratto è lo stesso a ogni taglia.

È la stessa disciplina del cluster sul CRM su misura: personalizzare non significa forkare il motore. E dove il modulo nasce da un manifest, il package nasce da una decisione scritta — design-to-CRM dal manifest copre il primo caso, questo articolo il secondo.

Quando NON serve un package

La prima riga della guida è una domanda, non un comando: ti serve davvero un package? La maggior parte delle richieste, no. Un nuovo oggetto con campi, CRUD, API, Admin e test è lavoro per la factory dei moduli — un manifest, un comando, fatto. Il package entra in gioco quando serve un dominio delimitato con le sue policy, le sue azioni, le sue dipendenze dichiarate.

Questa frugalità è progettuale, non pigrizia documentata: ogni package è superficie da mantenere, e il framework preferisce dirti di non aprirne uno piuttosto che venderti estensibilità. La tesi completa sul perché — agenti che propongono, policy che governa, umani che decidono — è nel pillar sull'autonomia sotto controllo.

Cosa manca, dichiarato

I limiti sono scritti nella stessa pagina del contratto, con lo stesso peso. Lo scaffold che avvia un package scrive un package vuoto e nient'altro: nessuna logica di business, nessuna composizione, nessun controllo globale di unicità dell'identità. Non esiste registro, marketplace, pubblicazione né sandboxing — il codice del package gira con l'autorità del processo ospite. Staccare un package ne lascia i dati dietro: non esiste disinstallazione.

Sono limiti che mappano scelte, non dimenticanze: niente marketplace perché il package è tuo e vive nel tuo repository; niente sandboxing perché il confine di fiducia è il processo, dichiarato. Ma restano limiti operativi veri — chi stacca un package deve sapere dove finiscono i suoi dati — e la solution Custom CRM rimanda al registro dei claim per la verità di implementazione, non alla descrizione di prodotto. Se a valutare è un coding agent, la pagina per gli agenti AI gli ordina di ispezionare prima di proporre: niente capability senza evidence nel repository.

Fatti e limiti, separati

Fatti: package che si attacca e stacca con impronta del nucleo invariata; comunicazione tra package solo via capability dichiarate; nessun meccanismo privato, registrazione con import statico; tre implementazioni di riferimento di taglia crescente; guida che dice quando NON aprire un package.

Limiti: scaffold vuoto, nessuna logica generata; nessun registro, marketplace, pubblicazione o sandboxing; codice con autorità del processo ospite; distacco senza pulizia dei dati, nessuna disinstallazione. Un contratto e tre esempi non misurano quanto il disegno regga in produzione: misurano che il confine esiste, è testato e dichiara cosa non fa.

Domande frequenti

Come si aggiunge un dominio senza toccare il nucleo?

Scrivendo un package: sorgente versionato nel tuo repository, registrato con un import statico. Il nucleo non cambia — l'impronta resta invariata — e il package parla con gli altri solo attraverso capability dichiarate.

Quando basta la factory dei moduli?

Quando serve un nuovo oggetto con campi, CRUD, API, Admin e test: un manifest e un comando. Il package serve per un dominio delimitato con policy, azioni e dipendenze proprie.

Cosa succede staccando un package?

Il nucleo resta intatto, ma i dati del package restano dietro: non esiste disinstallazione. È un limite dichiarato — va pianificato, non scoperto.

Dove verifico cosa è vero e cosa è roadmap?

Nel registro dei claim legato alla suite di test, lo stesso della solution: ogni affermazione è legata a prove o marcata come limite.