Scarica Markdown Documento originale su GitHub

Integrare Licentivo Launch con l'IA

Le modifiche attualmente non pubblicate adottano lo scambio dell'identità dell'account. Le responsabilità specifiche e i vincoli di migrazione sono descritti in Durata degli acquisti e limiti degli SDK account. Launch calcola la durata dell'acquisto; gli SDK Licentivo applicano l'autorizzazione.

Nel backend Launch, Strumenti operativi → Integrazione rapida con IA genera una descrizione del compito in inglese da fornire agli strumenti di programmazione con IA. Usa la configurazione pubblica effettiva del negozio corrente, del software esistente e dei piani pubblicati e richiede all'IA di installare il pacchetto client pubblico Launch, chiamare le API reali, inserire i controlli dei permessi nelle operazioni applicative e completare infine i test di integrazione.

La navigazione Verifica dell'integrazione e codice / Integrazione rapida con IA nella pagina di integrazione del programma consente di accedere alla stessa funzionalità. Lo sviluppo manuale non richiede l'IA: è possibile consultare direttamente la guida all'integrazione manuale in nove linguaggi.

Preparazione prima della generazione

Creare in Launch il software e i piani di vendita, quindi associare i piani ai prodotti Licentivo e alle politiche di autorizzazione.
Pubblicare i piani nell'ambiente sandbox o live da testare.
Verificare che l'indirizzo pubblico di Launch sia raggiungibile dal software del cliente; usare HTTPS nell'ambiente di produzione.
In Integrazione del programma → Verifica dell'integrazione e codice, leggere le informazioni del prodotto e verificare che le mappature del prodotto e la chiave pubblica di firma superino il controllo.
Specificare le operazioni applicative effettive da proteggere, ad esempio export, save o render; non limitarsi a scrivere «l'intero software».

È possibile generare una bozza prima di aver completato la configurazione del prodotto, ma gli elementi da compilare saranno indicati esplicitamente e la bozza non potrà essere usata come configurazione di integrazione pronta per la consegna. Dopo aver completato la configurazione del prodotto e dell'ambiente, generarla nuovamente.

Generare il prompt nel backend

Selezionare Go, Python, C#, Java, JavaScript / Node.js, Rust, Ruby, C oppure C++. Le soluzioni backend Web usano Go e non costituiscono un ulteriore linguaggio SDK.
Selezionare Windows, Linux, macOS o la piattaforma applicabile e un progetto desktop, backend Web o servizio in background.
Descrivere in inglese la struttura del progetto esistente, il metodo di avvio, il framework dell'interfaccia e le funzionalità applicative da proteggere. Non inserire password, chiavi, dati dei clienti o codice sorgente privato.
Selezionare il software esistente e l'ambiente sandbox / live. Launch legge automaticamente l'indirizzo del negozio corrente, le mappature tra i prodotti Launch e Licentivo, l'ambiente e la chiave pubblica di firma.
Controllare nell'anteprima la versione del pacchetto, i comandi di installazione, i link alla documentazione e la funzione di connessione precompilata, quindi copiare o scaricare il prompt.
Fornire il prompt al proprio strumento di programmazione con IA affinché completi le modifiche, la compilazione e i test locali nel progetto.

Launch genera soltanto testo nel browser. Non si connette automaticamente a servizi di IA, non carica il progetto e non esegue i programmi generati per conto dello sviluppatore.

Il prompt indica all'IA dove scaricare l'SDK

Tutte le verifiche dell'installazione pubblica nei nove linguaggi della versione attuale 0.1.6 sono state superate (9/9); i comandi dei registri e i download nativi riportati di seguito sono stati verificati. Anche i file Java di Maven Central con le quattro firme, la versione esatta di Rust su crates.io e tutto il codice di inizializzazione generato dal backend hanno superato verifiche indipendenti dal punto di vista di chi utilizza i pacchetti; la release v0.1.6 su GitHub fornisce inoltre pacchetti nativi e file offline.

Il prompt generato deve includere un metodo di installazione pubblico con versione fissa per il linguaggio selezionato:

Go:         go get github.com/spf86/licentivo-launch-sdk/pkg/launchclient@v0.1.6
Python:     python -m pip install licentivo-launch==0.1.6
C# / .NET: dotnet add package Licentivo.Launch --version 0.1.6
Java:       com.licentivo.launch:launch-client:0.1.6
Node.js:    npm install @licentivo/launch@0.1.6
Rust:       cargo add licentivo-launch@=0.1.6
Ruby:       gem install licentivo-launch --version 0.1.6
C / C++:    https://github.com/spf86/licentivo-launch-sdk/releases/tag/v0.1.6

Il codice sorgente pubblico, i README dei singoli linguaggi e lo stato della release corrente sono disponibili qui:

Installare soltanto il pacchetto Launch per il linguaggio selezionato. La v0.1.6 include già l'SDK ufficiale Licentivo v0.11.6, l'adattatore predefinito e la configurazione della connessione; non occorre più installare separatamente una seconda copia dell'SDK ufficiale.

Il prompt indica all'IA come eseguire l'integrazione

Il prompt configurato include la funzione di connessione generata dal backend. La funzione contiene già l'indirizzo pubblico del negozio, le mappature tra i prodotti Launch e Licentivo, la chiave pubblica di firma e l'ambiente di pagamento. L'IA non deve indovinare o inserire manualmente i due identificativi interni dei prodotti, né creare launch-config.json o product.json.

Il file privato config.yaml del server serve soltanto a eseguire il sito Launch e non deve mai essere incluso nelle applicazioni dei clienti, nei prompt o nei pacchetti di installazione.

L'IA deve modificare il software del cliente seguendo questo ciclo di vita:

Connect/connect → Login or Restore → RunFeature → Logout / Close
                                      └──────────→ ReleaseDevice (explicit device unlink only)

Connect/connect crea il client Launch e inizializza l'SDK ufficiale incluso; ciò non significa che l'account abbia già effettuato l'accesso o che le funzionalità siano già autorizzate.
Login usa l'indirizzo email e la password con cui il cliente si è registrato nel negozio corrente per ottenere le credenziali del prodotto per quell'account.
Restore ripristina dall'archivio sicuro una sessione ricordata; se non esiste una sessione, mostra l'accesso. Un rifiuto esplicito non deve essere considerato un'autorizzazione offline riuscita.
RunFeature deve racchiudere le operazioni applicative effettive, come esportazione, salvataggio, rendering o attività in background. Disabilitare soltanto i pulsanti non sostituisce il controllo nel punto di esecuzione.
Logout chiama prima la procedura unificata di disconnessione dell'SDK ufficiale, quindi elimina la sessione dell'account; ReleaseDevice è un punto di ingresso compatibile della stessa procedura di disconnessione esplicita. Close conserva l'associazione del dispositivo durante la chiusura ordinaria.
L'oggetto client deve rimanere attivo durante l'esecuzione dell'applicazione, affinché l'SDK possa gestire gli heartbeat, i posti delle licenze flottanti e le regole di esecuzione.

Le applicazioni Web eseguono i controlli di autorizzazione soltanto in un backend attendibile. Node.js / Electron colloca le credenziali e l'SDK nel processo principale o sul server; il browser e il processo di rendering non conservano segreti di autorizzazione.

Cosa deve consegnare l'IA

Il prompt richiede all'IA di completare e documentare quanto segue:

Esaminare la versione del linguaggio, la gestione delle dipendenze, le procedure di avvio e chiusura del progetto esistente e le operazioni applicative effettive da proteggere.
Installare un pacchetto Launch con il comando a versione fissa riportato sopra e verificare le interfacce effettive nel README del linguaggio corrispondente.
Aggiungere l'accesso con l'account del cliente, i messaggi di errore e il ripristino sicuro delle sessioni, senza salvare password o licenze complete nel codice sorgente o nei log.
Inizializzare usando la funzione di connessione fornita dal backend, senza inventare identificativi dei prodotti, chiavi pubbliche di firma o file di configurazione.
Usare RunFeature o il metodo del linguaggio corrispondente nel punto di esecuzione di ogni operazione applicativa protetta, gestendo correttamente il conteggio degli utilizzi e i tentativi successivi.
Distinguere gli errori dell'account, l'email in attesa di verifica, i diritti in fase di sincronizzazione, l'assenza di acquisti, la scadenza, la sospensione, il limite di dispositivi raggiunto, gli errori di rete e la scadenza dell'autorizzazione offline.
Implementare la chiusura ordinaria, la disconnessione dell'account e il rilascio esplicito del dispositivo, isolando le cache per negozio, account, prodotto e ambiente.
Eseguire la compilazione e i test appropriati per il progetto e, al termine, elencare i file modificati, le mappature delle funzionalità, i risultati effettivi e i passaggi di collaudo per il cliente.

Dopo che l'IA ha prodotto il codice, gli sviluppatori devono comunque verificare che i nomi delle funzionalità corrispondano esattamente alle politiche Licentivo e completare i test end-to-end con un account reale del negozio sandbox.

Contenuti da escludere dal prompt

Il prompt contiene soltanto l'origine pubblica del negozio, le mappature dei prodotti, l'ambiente, la versione del pacchetto e la chiave pubblica di firma. I contenuti seguenti non devono essere inclusi nel prompt:

Indirizzi email dei clienti, password, sessioni di accesso e token di aggiornamento;
Licenze complete, credenziali dei dispositivi e cache locali delle autorizzazioni;
API Key amministrativa di Licentivo;
Chiavi Stripe, PayPal, Waffo o Paddle;
Connessioni al database, master_key e config.yaml del server;
Codice sorgente privato, dati applicativi o log che non è necessario fornire a strumenti esterni.

Le verifiche della configurazione pubblica di Launch, le bozze dell'IA e le compilazioni locali non dimostrano che i pagamenti reali, il rilascio delle licenze o le attivazioni esterne siano riusciti. Le sandbox di pagamento, gli account del negozio e l'ambiente Licentivo devono essere collaudati separatamente.

Lista di controllo per il collaudo dopo l'integrazione

I nuovi clienti riescono ad accedere; gli indirizzi email non verificati e le password errate producono messaggi chiari senza rivelare informazioni eccessive.
Gli account che hanno effettuato un acquisto possono eseguire le funzionalità previste; gli account senza acquisto, scaduti o sospesi non possono eseguire lo stesso codice applicativo.
Dopo un riavvio, l'uso può continuare soltanto se la sessione è stata ripristinata con successo e i controlli di autorizzazione sono stati superati.
Le politiche offline valide funzionano e l'accesso viene negato alla scadenza dell'autorizzazione offline; le risposte esplicite 401/403/404 non vengono trasformate in esiti offline positivi.
Il conteggio degli utilizzi delle funzionalità viene confermato correttamente soltanto quando l'operazione applicativa riesce; gli errori e i tentativi successivi non causano detrazioni duplicate.
La chiusura ordinaria conserva l'associazione del dispositivo; la disconnessione esplicita chiama prima la procedura unificata di disconnessione dell'SDK ufficiale, conserva i log delle revoche in sospeso e riporta il risultato effettivo.
Gli heartbeat dei posti delle licenze flottanti continuano durante l'esecuzione dell'applicazione; il tempo di recupero dopo una chiusura anomala rispetta la politica di autorizzazione corrente.
Il cambio di negozio, account, prodotto o ambiente non riutilizza la cache di un'altra identità.

Per una descrizione più completa dei limiti del collaudo automatico ed esterno, consultare acceptance.md.

Usare il generatore di prompt nel pacchetto di distribuzione del codice sorgente

licentivo-launch-0.1.6-source.zip conserva i file seguenti per facilitare la generazione di prompt con la stessa struttura nei propri strumenti:

internal/httpapi/web/integration-prompts.js: modulo di generazione dei prompt indipendente dalle pagine e dal server;
scripts/integration-prompts.test.mjs: test locali Node;
internal/httpapi/web/integration-state.js e scripts/integration-state.test.mjs: isolamento delle bozze di configurazione e rimozione dei risultati delle verifiche precedenti;
Questa guida, i pacchetti di integrazione dei singoli linguaggi, gli esempi e le istruzioni di collaudo.

Il modulo esporta integrationTargets e buildIntegrationPrompt(options). Le opzioni includono language, appKind, platform, projectNotes, feature, merchantOrigin, environment e il report verificato; il risultato è { text, ready, title, code }. Se non viene fornito report, viene generata soltanto una bozza; non è possibile aggirare la verifica della configurazione pubblica manomettendo manualmente il report.

Negli strumenti di sviluppo che supportano i moduli ES è possibile generare una bozza locale dalla directory radice del pacchetto sorgente:

@'
import { readFile, writeFile } from 'node:fs/promises';
const source = await readFile('internal/httpapi/web/integration-prompts.js', 'utf8');
const { buildIntegrationPrompt } = await import(
  'data:text/javascript;base64,' + Buffer.from(source).toString('base64')
);
const prompt = buildIntegrationPrompt({
  language: 'python',
  appKind: 'desktop',
  platform: 'windows',
  projectNotes: 'Existing Python desktop application. Add account sign-in and protect report exports.',
  feature: 'export'
});
await writeFile('integration-prompt.md', prompt.text, 'utf8');
console.log(prompt.title);
'@ | node --input-type=module

Questo comando genera soltanto una bozza non configurata e non chiama servizi di IA o di autorizzazione. Per l'integrazione effettiva, tornare alla propria istanza Launch, selezionare il software e l'ambiente esistenti e rigenerare una versione che includa la configurazione pubblica.

Verificare il generatore locale:

node --test scripts/integration-prompts.test.mjs scripts/integration-state.test.mjs