From e84fa695d1c3aef3e701da5b81058778a45d5e43 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Tue, 14 Apr 2026 08:17:11 +0000 Subject: [PATCH] chore(i18n): refresh it translations --- docs/it/gateway/local-models.md | 83 ++++++++------ docs/it/reference/RELEASING.md | 184 +++++++++++++++++++++----------- 2 files changed, 169 insertions(+), 98 deletions(-) diff --git a/docs/it/gateway/local-models.md b/docs/it/gateway/local-models.md index e0ead6d35..60805402b 100644 --- a/docs/it/gateway/local-models.md +++ b/docs/it/gateway/local-models.md @@ -1,28 +1,28 @@ --- read_when: - - Vuoi servire modelli dal tuo box GPU personale - - Stai configurando LM Studio o un proxy compatibile con OpenAI - - Hai bisogno della guida più sicura per i modelli locali + - Vuoi servire modelli dalla tua macchina GPU. + - Stai configurando LM Studio o un proxy compatibile con OpenAI. + - Ti serve la guida più sicura per i modelli locali. summary: Esegui OpenClaw su LLM locali (LM Studio, vLLM, LiteLLM, endpoint OpenAI personalizzati) title: Modelli locali x-i18n: - generated_at: "2026-04-13T08:27:14Z" + generated_at: "2026-04-14T08:16:42Z" model: gpt-5.4 provider: openai - source_hash: 3ecb61b3e6e34d3666f9b688cd694d92c5fb211cf8c420fa876f7ccf5789154a + source_hash: 1544c522357ba4b18dfa6d05ea8d60c7c6262281b53863d9aee7002464703ca7 source_path: gateway/local-models.md workflow: 15 --- # Modelli locali -Il locale è fattibile, ma OpenClaw si aspetta un contesto ampio + forti difese contro il prompt injection. Le schede piccole troncano il contesto e indeboliscono la sicurezza. Punta in alto: **≥2 Mac Studio al massimo della configurazione o una macchina GPU equivalente (~30.000$+)**. Una singola GPU da **24 GB** funziona solo per prompt più leggeri con latenza più alta. Usa la **variante di modello più grande / a dimensione piena che puoi eseguire**; checkpoint fortemente quantizzati o “small” aumentano il rischio di prompt injection (vedi [Sicurezza](/it/gateway/security)). +Il locale è fattibile, ma OpenClaw si aspetta un contesto ampio + difese solide contro la prompt injection. Le schede piccole troncano il contesto e indeboliscono la sicurezza. Punta in alto: **≥2 Mac Studio al massimo della configurazione o una macchina GPU equivalente (~$30k+)**. Una singola GPU da **24 GB** funziona solo per prompt più leggeri con latenza più alta. Usa la **variante di modello più grande / full-size che riesci a eseguire**; checkpoint quantizzati in modo aggressivo o “small” aumentano il rischio di prompt injection (vedi [Sicurezza](/it/gateway/security)). -Se vuoi la configurazione locale con meno attrito, inizia con [LM Studio](/it/providers/lmstudio) o [Ollama](/it/providers/ollama) e `openclaw onboard`. Questa pagina è la guida con opinioni precise per stack locali di fascia più alta e server locali personalizzati compatibili con OpenAI. +Se vuoi la configurazione locale con meno attrito, inizia con [LM Studio](/it/providers/lmstudio) o [Ollama](/it/providers/ollama) e `openclaw onboard`. Questa pagina è la guida con indicazioni precise per stack locali di fascia alta e server locali personalizzati compatibili con OpenAI. ## Consigliato: LM Studio + grande modello locale (API Responses) -La migliore stack locale attuale. Carica un modello grande in LM Studio (per esempio, una build completa di Qwen, DeepSeek o Llama), abilita il server locale (predefinito `http://127.0.0.1:1234`), e usa l’API Responses per mantenere il ragionamento separato dal testo finale. +Il miglior stack locale attuale. Carica un modello grande in LM Studio (per esempio una build full-size di Qwen, DeepSeek o Llama), abilita il server locale (predefinito `http://127.0.0.1:1234`), e usa l'API Responses per mantenere il ragionamento separato dal testo finale. ```json5 { @@ -45,7 +45,7 @@ La migliore stack locale attuale. Carica un modello grande in LM Studio (per ese models: [ { id: “my-local-model”, - name: “Modello locale”, + name: “Local Model”, reasoning: false, input: [“text”], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, @@ -62,11 +62,11 @@ La migliore stack locale attuale. Carica un modello grande in LM Studio (per ese **Checklist di configurazione** - Installa LM Studio: [https://lmstudio.ai](https://lmstudio.ai) -- In LM Studio, scarica la **build del modello più grande disponibile** (evita varianti “small”/fortemente quantizzate), avvia il server, conferma che `http://127.0.0.1:1234/v1/models` lo elenchi. -- Sostituisci `my-local-model` con l’ID modello effettivo mostrato in LM Studio. -- Mantieni il modello caricato; il caricamento a freddo aggiunge latenza di avvio. +- In LM Studio, scarica la **build di modello più grande disponibile** (evita varianti “small”/fortemente quantizzate), avvia il server, conferma che `http://127.0.0.1:1234/v1/models` lo elenchi. +- Sostituisci `my-local-model` con l'ID effettivo del modello mostrato in LM Studio. +- Mantieni il modello caricato; il caricamento a freddo aggiunge latenza all'avvio. - Regola `contextWindow`/`maxTokens` se la tua build di LM Studio è diversa. -- Per WhatsApp, mantieni l’API Responses così viene inviato solo il testo finale. +- Per WhatsApp, usa l'API Responses così viene inviato solo il testo finale. Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `models.mode: "merge"` così i fallback restano disponibili. @@ -97,7 +97,7 @@ Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `mode models: [ { id: "my-local-model", - name: "Modello locale", + name: "Local Model", reasoning: false, input: ["text"], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, @@ -111,18 +111,18 @@ Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `mode } ``` -### Locale come prima scelta con rete di sicurezza ospitata +### Prima il locale con rete di sicurezza ospitata -Inverti l’ordine di primario e fallback; mantieni lo stesso blocco `providers` e `models.mode: "merge"` così puoi ripiegare su Sonnet o Opus quando la macchina locale non è disponibile. +Inverti l'ordine di primario e fallback; mantieni lo stesso blocco providers e `models.mode: "merge"` così puoi ripiegare su Sonnet o Opus quando la macchina locale non è disponibile. ### Hosting regionale / instradamento dei dati -- Varianti MiniMax/Kimi/GLM ospitate esistono anche su OpenRouter con endpoint vincolati alla regione (ad esempio ospitati negli Stati Uniti). Scegli lì la variante regionale per mantenere il traffico nella giurisdizione desiderata continuando a usare `models.mode: "merge"` per i fallback Anthropic/OpenAI. -- Solo locale resta il percorso più forte per la privacy; l’instradamento regionale ospitato è la via di mezzo quando ti servono funzionalità del provider ma vuoi controllare il flusso dei dati. +- Varianti ospitate di MiniMax/Kimi/GLM esistono anche su OpenRouter con endpoint vincolati alla regione (ad esempio, ospitati negli Stati Uniti). Scegli lì la variante regionale per mantenere il traffico nella giurisdizione scelta continuando a usare `models.mode: "merge"` per i fallback Anthropic/OpenAI. +- Solo locale resta il percorso più forte per la privacy; l'instradamento regionale ospitato è il compromesso quando ti servono funzionalità del provider ma vuoi controllare il flusso dei dati. ## Altri proxy locali compatibili con OpenAI -vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un endpoint `/v1` in stile OpenAI. Sostituisci il blocco provider sopra con il tuo endpoint e il tuo ID modello: +vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un endpoint `/v1` in stile OpenAI. Sostituisci il blocco provider sopra con il tuo endpoint e l'ID del modello: ```json5 { @@ -136,7 +136,7 @@ vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un end models: [ { id: "my-local-model", - name: "Modello locale", + name: "Local Model", reasoning: false, input: ["text"], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, @@ -152,23 +152,40 @@ vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un end Mantieni `models.mode: "merge"` così i modelli ospitati restano disponibili come fallback. -Nota sul comportamento per backend locali/proxy `/v1`: +Nota sul comportamento per backend locali/proxati `/v1`: -- OpenClaw li tratta come route proxy compatibili con OpenAI, non come endpoint OpenAI nativi -- qui non si applica il modellamento delle richieste riservato a OpenAI nativo: niente `service_tier`, niente `store` di Responses, niente modellamento del payload di compatibilità del ragionamento OpenAI e niente suggerimenti per la cache dei prompt -- gli header di attribuzione nascosti di OpenClaw (`originator`, `version`, `User-Agent`) non vengono iniettati su questi URL proxy personalizzati +- OpenClaw li tratta come route proxy in stile OpenAI compatibili, non come endpoint OpenAI nativi +- il modellamento delle richieste riservato al solo OpenAI nativo non si applica qui: niente + `service_tier`, niente `store` di Responses, niente modellamento del payload di compatibilità del ragionamento OpenAI + e niente suggerimenti per la cache dei prompt +- gli header di attribuzione nascosti di OpenClaw (`originator`, `version`, `User-Agent`) + non vengono iniettati su questi URL di proxy personalizzati -Note di compatibilità per backend compatibili con OpenAI più restrittivi: +Note di compatibilità per backend compatibili con OpenAI più rigorosi: -- Alcuni server accettano solo `messages[].content` come stringa nelle Chat Completions, non array strutturati di content part. Imposta `models.providers..models[].compat.requiresStringContent: true` per quegli endpoint. -- Alcuni backend locali più piccoli o più restrittivi sono instabili con la forma completa del prompt del runtime agent di OpenClaw, soprattutto quando sono inclusi schemi di tool. Se il backend funziona per piccole chiamate dirette a `/v1/chat/completions` ma fallisce nei normali turni agente di OpenClaw, prova prima con `models.providers..models[].compat.supportsTools: false`. -- Se il backend continua a fallire solo su esecuzioni OpenClaw più grandi, il problema rimanente di solito è la capacità del modello/server a monte o un bug del backend, non il livello di trasporto di OpenClaw. +- Alcuni server accettano solo `messages[].content` come stringa su Chat Completions, non + array strutturati di parti di contenuto. Imposta + `models.providers..models[].compat.requiresStringContent: true` per + quegli endpoint. +- Alcuni backend locali più piccoli o più rigorosi sono instabili con la forma completa del prompt + del runtime agente di OpenClaw, soprattutto quando sono inclusi gli schemi degli strumenti. Se il + backend funziona per piccole chiamate dirette a `/v1/chat/completions` ma fallisce nei normali + turni agente di OpenClaw, prova prima + `models.providers..models[].compat.supportsTools: false`. +- Se il backend continua a fallire solo su esecuzioni OpenClaw più grandi, il problema residuo + di solito è la capacità a monte del modello/server o un bug del backend, non il layer di + trasporto di OpenClaw. ## Risoluzione dei problemi - Il Gateway riesce a raggiungere il proxy? `curl http://127.0.0.1:1234/v1/models`. -- Modello LM Studio scaricato dalla memoria? Ricaricalo; l’avvio a freddo è una causa comune di “blocco”. -- Errori di contesto? Riduci `contextWindow` o aumenta il limite del tuo server. -- Il server compatibile con OpenAI restituisce `messages[].content ... expected a string`? Aggiungi `compat.requiresStringContent: true` a quella voce del modello. -- Piccole chiamate dirette a `/v1/chat/completions` funzionano, ma `openclaw infer model run` fallisce su Gemma o un altro modello locale? Disabilita prima gli schemi di tool con `compat.supportsTools: false`, poi riprova. Se il server continua a bloccarsi solo su prompt OpenClaw più grandi, trattalo come un limite del server/modello a monte. -- Sicurezza: i modelli locali saltano i filtri lato provider; mantieni gli agenti limitati e Compaction attivo per ridurre il raggio d’impatto del prompt injection. +- Modello LM Studio scaricato dalla memoria? Ricaricalo; l'avvio a freddo è una causa comune di “blocco”. +- OpenClaw avvisa quando la finestra di contesto rilevata è sotto **32k** e blocca sotto **16k**. Se incontri questo controllo preliminare, aumenta il limite di contesto del server/modello o scegli un modello più grande. +- Errori di contesto? Riduci `contextWindow` o aumenta il limite del server. +- Il server compatibile con OpenAI restituisce `messages[].content ... expected a string`? + Aggiungi `compat.requiresStringContent: true` a quella voce del modello. +- Piccole chiamate dirette a `/v1/chat/completions` funzionano, ma `openclaw infer model run` + fallisce su Gemma o un altro modello locale? Disabilita prima gli schemi degli strumenti con + `compat.supportsTools: false`, poi riprova. Se il server continua a bloccarsi solo + su prompt OpenClaw più grandi, trattalo come un limite a monte del server/modello. +- Sicurezza: i modelli locali saltano i filtri lato provider; mantieni gli agenti limitati e Compaction attivo per limitare il raggio d'azione della prompt injection. diff --git a/docs/it/reference/RELEASING.md b/docs/it/reference/RELEASING.md index 337e07fc9..163fa6a48 100644 --- a/docs/it/reference/RELEASING.md +++ b/docs/it/reference/RELEASING.md @@ -5,10 +5,10 @@ read_when: summary: Canali di rilascio pubblici, denominazione delle versioni e cadenza title: Politica di rilascio x-i18n: - generated_at: "2026-04-14T02:08:38Z" + generated_at: "2026-04-14T08:16:37Z" model: gpt-5.4 provider: openai - source_hash: fdc32839447205d74ba7a20a45fbac8e13b199174b442a1e260e3fce056c63da + source_hash: 3eaf9f1786b8c9fd4f5a9c657b623cb69d1a485958e1a9b8f108511839b63587 source_path: reference/RELEASING.md workflow: 15 --- @@ -17,114 +17,168 @@ x-i18n: OpenClaw ha tre canali di rilascio pubblici: -- stable: release taggate che pubblicano su npm `beta` per impostazione predefinita, oppure su npm `latest` quando richiesto esplicitamente +- stable: release con tag che pubblicano su npm `beta` per impostazione predefinita, oppure su npm `latest` quando richiesto esplicitamente - beta: tag di prerelease che pubblicano su npm `beta` -- dev: la testa mobile di `main` +- dev: la head mobile di `main` ## Denominazione delle versioni -- Versione di rilascio stable: `YYYY.M.D` +- Versione della release stabile: `YYYY.M.D` - Tag Git: `vYYYY.M.D` -- Versione di rilascio stable correttiva: `YYYY.M.D-N` +- Versione della release di correzione stabile: `YYYY.M.D-N` - Tag Git: `vYYYY.M.D-N` -- Versione di prerelease beta: `YYYY.M.D-beta.N` +- Versione della prerelease beta: `YYYY.M.D-beta.N` - Tag Git: `vYYYY.M.D-beta.N` - Non aggiungere zeri iniziali a mese o giorno -- `latest` indica l'attuale release npm stable promossa +- `latest` indica l'attuale release npm stabile promossa - `beta` indica l'attuale destinazione di installazione beta -- Le release stable e stable correttive pubblicano su npm `beta` per impostazione predefinita; gli operatori di rilascio possono scegliere esplicitamente `latest`, oppure promuovere in seguito una build beta verificata +- Le release stabili e le release di correzione stabile pubblicano su npm `beta` per impostazione predefinita; gli operatori della release possono scegliere esplicitamente `latest` come destinazione, oppure promuovere in seguito una build beta verificata - Ogni release di OpenClaw distribuisce insieme il pacchetto npm e l'app macOS ## Cadenza di rilascio - Le release passano prima da beta -- Stable segue solo dopo che l'ultima beta è stata convalidata -- La procedura di rilascio dettagliata, le approvazioni, le credenziali e le note di ripristino sono riservate ai maintainer +- stable segue solo dopo che l'ultima beta è stata convalidata +- La procedura dettagliata di rilascio, le approvazioni, le credenziali e le note di recupero sono + riservate ai maintainer -## Controlli preliminari del rilascio +## Controlli preliminari della release -- Esegui `pnpm build && pnpm ui:build` prima di `pnpm release:check` in modo che gli artifact di rilascio `dist/*` previsti e il bundle della Control UI esistano per il passaggio di convalida del pack -- Esegui `pnpm release:check` prima di ogni release taggata +- Esegui `pnpm build && pnpm ui:build` prima di `pnpm release:check` in modo che gli attesi + artifact di rilascio `dist/*` e il bundle della Control UI esistano per il passaggio di + validazione del pack +- Esegui `pnpm release:check` prima di ogni release con tag - I controlli di rilascio ora vengono eseguiti in un workflow manuale separato: `OpenClaw Release Checks` -- Questa separazione è intenzionale: mantiene il percorso reale di rilascio npm breve, deterministico e focalizzato sugli artifact, mentre i controlli live più lenti restano nel proprio canale così da non rallentare o bloccare la pubblicazione -- I controlli di rilascio devono essere avviati dal workflow ref di `main` in modo che la logica del workflow e i segreti restino canonici -- Quel workflow accetta un tag di rilascio esistente oppure l'attuale commit SHA completo di 40 caratteri di `main` -- In modalità commit-SHA accetta solo l'attuale HEAD di `origin/main`; usa un tag di rilascio per commit di rilascio precedenti -- Anche il controllo preliminare di sola convalida `OpenClaw NPM Release` accetta l'attuale commit SHA completo di 40 caratteri di `main` senza richiedere un tag già pubblicato -- Quel percorso SHA è solo di convalida e non può essere promosso a una pubblicazione reale -- In modalità SHA il workflow sintetizza `v` solo per il controllo dei metadati del pacchetto; la pubblicazione reale richiede comunque un vero tag di rilascio -- Entrambi i workflow mantengono il percorso reale di pubblicazione e promozione su runner ospitati da GitHub, mentre il percorso di convalida non mutante può usare i runner Linux Blacksmith più grandi +- Questa separazione è intenzionale: mantiene il percorso reale di release npm breve, + deterministico e focalizzato sugli artifact, mentre i controlli live più lenti rimangono nel loro + canale così da non rallentare o bloccare la pubblicazione +- I controlli di rilascio devono essere avviati dal workflow ref di `main` in modo che la + logica del workflow e i secret rimangano canonici +- Quel workflow accetta come input un tag di release esistente oppure l'attuale commit SHA completo a 40 caratteri di `main` +- In modalità commit-SHA accetta solo l'attuale HEAD di `origin/main`; usa un + tag di release per commit di release precedenti +- Anche il controllo preliminare di sola validazione `OpenClaw NPM Release` accetta l'attuale + commit SHA completo a 40 caratteri di `main` senza richiedere un tag pubblicato +- Il percorso basato su SHA è solo di validazione e non può essere promosso a una pubblicazione reale +- In modalità SHA il workflow sintetizza `v` solo per il + controllo dei metadati del pacchetto; la pubblicazione reale richiede comunque un vero tag di release +- Entrambi i workflow mantengono il percorso reale di pubblicazione e promozione su runner ospitati da GitHub, + mentre il percorso di validazione non mutante può usare i runner Linux + Blacksmith più grandi - Quel workflow esegue `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` usando entrambi i secret di workflow `OPENAI_API_KEY` e `ANTHROPIC_API_KEY` -- Il controllo preliminare della release npm non aspetta più il canale separato dei controlli di rilascio +- Il controllo preliminare della release npm non attende più il canale separato dei controlli di rilascio - Esegui `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (o il tag beta/correttivo corrispondente) prima dell'approvazione + (oppure il tag beta/correzione corrispondente) prima dell'approvazione - Dopo la pubblicazione su npm, esegui `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (o la versione beta/correttiva corrispondente) per verificare il percorso di installazione del registro pubblicato in un prefisso temporaneo pulito -- L'automazione di rilascio dei maintainer ora usa il modello preflight-then-promote: - - la reale pubblicazione npm deve superare con esito positivo un `preflight_run_id` npm - - le release npm stable usano `beta` per impostazione predefinita - - la pubblicazione npm stable può scegliere esplicitamente `latest` tramite input del workflow - - la promozione npm stable da `beta` a `latest` è ancora disponibile come modalità manuale esplicita nel workflow attendibile `OpenClaw NPM Release` - - le pubblicazioni stable dirette possono anche eseguire una modalità esplicita di sincronizzazione dei dist-tag che punta sia `latest` sia `beta` alla versione stable già pubblicata - - queste modalità dei dist-tag richiedono comunque un `NPM_TOKEN` valido nell'ambiente `npm-release` perché la gestione dei `dist-tag` di npm è separata dalla pubblicazione attendibile - - `macOS Release` pubblico è solo di convalida - - la vera pubblicazione privata mac deve superare con esito positivo i valori `preflight_run_id` e `validate_run_id` del preflight mac privato - - i percorsi di pubblicazione reali promuovono artifact preparati invece di ricostruirli di nuovo -- Per release stable correttive come `YYYY.M.D-N`, il verificatore post-pubblicazione controlla anche lo stesso percorso di aggiornamento con prefisso temporaneo da `YYYY.M.D` a `YYYY.M.D-N`, così le correzioni di rilascio non possono lasciare silenziosamente installazioni globali più vecchie sul payload stable di base -- Il controllo preliminare della release npm fallisce in modalità closed se il tarball non include sia `dist/control-ui/index.html` sia un payload `dist/control-ui/assets/` non vuoto, così evitiamo di distribuire di nuovo una dashboard browser vuota -- Se il lavoro di rilascio ha toccato la pianificazione CI, i manifest di temporizzazione delle estensioni o le matrici di test delle estensioni, rigenera e rivedi gli output della matrice del workflow `checks-node-extensions` gestiti dal planner da `.github/workflows/ci.yml` prima dell'approvazione, così le note di rilascio non descriveranno un layout CI obsoleto -- La prontezza della release stable macOS include anche le superfici dell'updater: - - la release GitHub deve finire con i file pacchettizzati `.zip`, `.dmg` e `.dSYM.zip` - - `appcast.xml` su `main` deve puntare al nuovo zip stable dopo la pubblicazione - - l'app pacchettizzata deve mantenere un bundle id non di debug, un URL del feed Sparkle non vuoto e un `CFBundleVersion` pari o superiore alla soglia canonica di build Sparkle per quella versione di rilascio + (oppure la versione beta/correzione corrispondente) per verificare il percorso di + installazione del registro pubblicato in un nuovo prefisso temporaneo +- L'automazione di rilascio dei maintainer ora usa il modello controllo preliminare-poi-promozione: + - la pubblicazione npm reale deve superare con successo un npm `preflight_run_id` + - le release npm stabili usano `beta` per impostazione predefinita + - la pubblicazione npm stabile può scegliere esplicitamente `latest` tramite input del workflow + - la promozione npm stabile da `beta` a `latest` è ancora disponibile come modalità manuale esplicita nel workflow attendibile `OpenClaw NPM Release` + - le pubblicazioni stabili dirette possono anche eseguire una modalità esplicita di sincronizzazione dei dist-tag che + punta sia `latest` sia `beta` alla versione stabile già pubblicata + - quelle modalità dist-tag richiedono comunque un `NPM_TOKEN` valido nell'ambiente `npm-release` perché la gestione dei `dist-tag` npm è separata dalla pubblicazione attendibile + - `macOS Release` pubblico è solo di validazione + - la pubblicazione reale privata per mac deve superare con successo i controlli preliminari privati per mac + `preflight_run_id` e `validate_run_id` + - i percorsi di pubblicazione reale promuovono artifact preparati invece di ricostruirli + di nuovo +- Per release di correzione stabile come `YYYY.M.D-N`, il verificatore post-pubblicazione + controlla anche lo stesso percorso di aggiornamento con prefisso temporaneo da `YYYY.M.D` a `YYYY.M.D-N` + in modo che le correzioni di rilascio non possano lasciare silenziosamente vecchie installazioni globali sul + payload stabile di base +- Il controllo preliminare della release npm fallisce in modo restrittivo se il tarball non include sia + `dist/control-ui/index.html` sia un payload non vuoto `dist/control-ui/assets/` + così da non distribuire di nuovo una dashboard browser vuota +- `pnpm test:install:smoke` applica anche il budget `unpackedSize` del pack npm al + tarball candidato per l'aggiornamento, così l'installer e2e intercetta l'aumento accidentale del pack + prima del percorso di pubblicazione della release +- Se il lavoro di release ha toccato la pianificazione CI, i manifest temporali delle estensioni o + le matrici di test delle estensioni, rigenera e rivedi gli output della matrice del workflow + `checks-node-extensions` posseduti dal planner da `.github/workflows/ci.yml` + prima dell'approvazione, così le note di rilascio non descrivono un layout CI obsoleto +- La prontezza della release stabile macOS include anche le superfici dell'updater: + - la release GitHub deve finire con `.zip`, `.dmg` e `.dSYM.zip` pacchettizzati + - `appcast.xml` su `main` deve puntare al nuovo zip stabile dopo la pubblicazione + - l'app pacchettizzata deve mantenere un bundle id non di debug, un feed Sparkle URL non vuoto + e un `CFBundleVersion` pari o superiore alla soglia canonica di build Sparkle + per quella versione di rilascio ## Input del workflow NPM `OpenClaw NPM Release` accetta questi input controllati dall'operatore: -- `tag`: tag di rilascio obbligatorio come `v2026.4.2`, `v2026.4.2-1`, oppure `v2026.4.2-beta.1`; quando `preflight_only=true`, può anche essere l'attuale commit SHA completo di 40 caratteri di `main` per un preflight solo di convalida -- `preflight_only`: `true` per sola convalida/build/package, `false` per il percorso di pubblicazione reale -- `preflight_run_id`: obbligatorio nel percorso di pubblicazione reale così il workflow riutilizza il tarball preparato dall'esecuzione di preflight riuscita +- `tag`: tag di release obbligatorio come `v2026.4.2`, `v2026.4.2-1`, oppure + `v2026.4.2-beta.1`; quando `preflight_only=true`, può anche essere l'attuale + commit SHA completo a 40 caratteri di `main` per un controllo preliminare di sola validazione +- `preflight_only`: `true` per sola validazione/build/package, `false` per il + percorso di pubblicazione reale +- `preflight_run_id`: obbligatorio nel percorso di pubblicazione reale in modo che il workflow riutilizzi + il tarball preparato dal controllo preliminare riuscito - `npm_dist_tag`: tag npm di destinazione per il percorso di pubblicazione; il valore predefinito è `beta` -- `promote_beta_to_latest`: `true` per saltare la pubblicazione e spostare su `latest` una build stable `beta` già pubblicata -- `sync_stable_dist_tags`: `true` per saltare la pubblicazione e far puntare sia `latest` sia `beta` a una versione stable già pubblicata +- `promote_beta_to_latest`: `true` per saltare la pubblicazione e spostare una build stabile `beta` + già pubblicata su `latest` +- `sync_stable_dist_tags`: `true` per saltare la pubblicazione e far puntare sia `latest` sia + `beta` a una versione stabile già pubblicata `OpenClaw Release Checks` accetta questi input controllati dall'operatore: -- `ref`: tag di rilascio esistente oppure l'attuale commit SHA completo di 40 caratteri di `main` da convalidare +- `ref`: tag di release esistente oppure l'attuale commit + SHA completo a 40 caratteri di `main` da convalidare Regole: -- I tag stable e correttivi possono pubblicare su `beta` o `latest` +- I tag stabili e di correzione possono pubblicare sia su `beta` sia su `latest` - I tag di prerelease beta possono pubblicare solo su `beta` -- L'input SHA del commit completo è consentito solo quando `preflight_only=true` +- L'input con commit SHA completo è consentito solo quando `preflight_only=true` - La modalità commit-SHA dei controlli di rilascio richiede anche l'attuale HEAD di `origin/main` -- Il percorso di pubblicazione reale deve usare lo stesso `npm_dist_tag` usato durante il preflight; il workflow verifica quei metadati prima di continuare la pubblicazione -- La modalità promozione deve usare un tag stable o correttivo, `preflight_only=false`, un `preflight_run_id` vuoto e `npm_dist_tag=beta` -- La modalità di sincronizzazione dei dist-tag deve usare un tag stable o correttivo, `preflight_only=false`, un `preflight_run_id` vuoto, `npm_dist_tag=latest` e `promote_beta_to_latest=false` -- Le modalità promozione e sincronizzazione dei dist-tag richiedono anche un `NPM_TOKEN` valido perché `npm dist-tag add` richiede ancora l'autenticazione npm normale; la pubblicazione attendibile copre solo il percorso di pubblicazione del pacchetto +- Il percorso di pubblicazione reale deve usare lo stesso `npm_dist_tag` usato durante il controllo preliminare; + il workflow verifica quei metadati prima che la pubblicazione prosegua +- La modalità di promozione deve usare un tag stabile o di correzione, `preflight_only=false`, + un `preflight_run_id` vuoto e `npm_dist_tag=beta` +- La modalità di sincronizzazione dist-tag deve usare un tag stabile o di correzione, + `preflight_only=false`, un `preflight_run_id` vuoto, `npm_dist_tag=latest`, + e `promote_beta_to_latest=false` +- Le modalità di promozione e sincronizzazione dist-tag richiedono anche un `NPM_TOKEN` valido perché + `npm dist-tag add` richiede ancora la normale autenticazione npm; la pubblicazione attendibile copre + solo il percorso di pubblicazione del pacchetto -## Sequenza di rilascio npm stable +## Sequenza della release npm stabile -Quando prepari una release npm stable: +Quando si prepara una release npm stabile: 1. Esegui `OpenClaw NPM Release` con `preflight_only=true` - - Prima che esista un tag, puoi usare l'attuale commit SHA completo di `main` per una prova a secco solo di convalida del workflow di preflight -2. Scegli `npm_dist_tag=beta` per il normale flusso beta-first, oppure `latest` solo quando vuoi intenzionalmente una pubblicazione stable diretta -3. Esegui separatamente `OpenClaw Release Checks` con lo stesso tag o con l'attuale commit SHA completo di `main` quando vuoi una copertura live della cache dei prompt - - Questo è separato di proposito così la copertura live resta disponibile senza riaccoppiare controlli lunghi o instabili al workflow di pubblicazione + - Prima che esista un tag, puoi usare l'attuale commit SHA completo di `main` per un + dry run di sola validazione del workflow di controllo preliminare +2. Scegli `npm_dist_tag=beta` per il normale flusso beta-first, oppure `latest` solo + quando vuoi intenzionalmente una pubblicazione stabile diretta +3. Esegui `OpenClaw Release Checks` separatamente con lo stesso tag oppure con il + commit SHA completo attuale di `main` quando vuoi la copertura live della prompt cache + - Questo è separato apposta così la copertura live resta disponibile senza + riaccoppiare controlli lunghi o instabili al workflow di pubblicazione 4. Salva il `preflight_run_id` riuscito -5. Esegui di nuovo `OpenClaw NPM Release` con `preflight_only=false`, lo stesso `tag`, lo stesso `npm_dist_tag` e il `preflight_run_id` salvato -6. Se la release è arrivata su `beta`, esegui successivamente `OpenClaw NPM Release` con lo stesso `tag` stable, `promote_beta_to_latest=true`, `preflight_only=false`, `preflight_run_id` vuoto e `npm_dist_tag=beta` quando vuoi spostare quella build pubblicata su `latest` -7. Se la release è stata intenzionalmente pubblicata direttamente su `latest` e `beta` deve seguire la stessa build stable, esegui `OpenClaw NPM Release` con lo stesso `tag` stable, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`, `preflight_only=false`, `preflight_run_id` vuoto e `npm_dist_tag=latest` +5. Esegui di nuovo `OpenClaw NPM Release` con `preflight_only=false`, lo stesso + `tag`, lo stesso `npm_dist_tag` e il `preflight_run_id` salvato +6. Se la release è arrivata su `beta`, esegui `OpenClaw NPM Release` più tardi con lo + stesso `tag` stabile, `promote_beta_to_latest=true`, `preflight_only=false`, + `preflight_run_id` vuoto e `npm_dist_tag=beta` quando vuoi spostare quella + build pubblicata su `latest` +7. Se la release è stata intenzionalmente pubblicata direttamente su `latest` e `beta` + deve seguire la stessa build stabile, esegui `OpenClaw NPM Release` con lo stesso + `tag` stabile, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`, + `preflight_only=false`, `preflight_run_id` vuoto e `npm_dist_tag=latest` -Le modalità promozione e sincronizzazione dei dist-tag richiedono comunque l'approvazione dell'ambiente `npm-release` e un `NPM_TOKEN` valido accessibile a quell'esecuzione del workflow. +Le modalità di promozione e sincronizzazione dist-tag richiedono comunque l'approvazione dell'ambiente `npm-release` +e un `NPM_TOKEN` valido accessibile a quell'esecuzione del workflow. -Questo mantiene sia il percorso di pubblicazione diretta sia il percorso di promozione beta-first documentati e visibili agli operatori. +Questo mantiene sia il percorso di pubblicazione diretta sia il percorso di promozione beta-first +documentati e visibili agli operatori. ## Riferimenti pubblici