@vascend/talos 0.1.0 → 0.1.1

package/README.md

@@ -41,18 +41,22 @@ The package includes the compiled CLI and SDK; GitHub access and a local build a
 On macOS and Linux, the installer uses a writable user directory:
 
 ```bash
-curl -fsSL https://cdn.jsdelivr.net/npm/@vascend/talos@latest/install.sh | bash
+curl -fsSL https://vascend.it/install | bash
 ```
 
 On Windows, run in PowerShell:
 
 ```powershell
-irm https://cdn.jsdelivr.net/npm/@vascend/talos@latest/install.ps1 | iex
+irm https://vascend.it/install.ps1 | iex
 ```
 
-Both installers require Node.js 20+ and npm. Run `talos` to check for newer stable versions;
+Both installers automatically install a verified Node.js LTS runtime with npm when a compatible installation is unavailable. No administrator privileges are needed. Run `talos` to check for newer stable versions;
 the startup prompt shows `current version → new version` and offers **Skip for now** or **Update now**.
 
+Talos checks npm for new stable releases, downloads from Vascend with an official npm fallback, and verifies the registry signature and SHA-512 integrity before installing with lifecycle scripts disabled. The initial installer command still trusts the HTTPS site serving the script.
+
+The installers add `talos` to your user PATH. On Windows it is available in the current PowerShell window; on Bash/Zsh, open a new terminal or use the activation command printed by the installer. No administrator rights or changes to PowerShell execution policy are required.
+
 On first launch, follow the Vascend account sign-in flow. Use `/login` to configure provider access and `/models` to choose a model. Then give Talos a task:
 
 ```text

package/dist/backend/asset-events.js

@@ -85,15 +85,15 @@ export function formatAssetEventRecord(room, event) {
     }
     const target = event.taskId ? `task:${event.taskId}` : `vision:${asset.visionId}`;
     const rel = `@R: ${room} -> ${type} -> asset:${asset.id} -> ${target}  [ ${action} ]`;
-    const body = `INDICE
-${uniqTerms.map((t, i) => `${i + 1} = ${t}`).join("\n")}
-
-DEFINIZIONI
-${def.join("\n")}
-
-RELAZIONI
-${rel}
-
+    const body = `INDICE
+${uniqTerms.map((t, i) => `${i + 1} = ${t}`).join("\n")}
+
+DEFINIZIONI
+${def.join("\n")}
+
+RELAZIONI
+${rel}
+
 OUTPUT: asset ${asset.id} "${escapeValue(asset.name)}" ${action}${event.taskId ? ` e collegato a ${event.taskId}` : ""}; richiamabile via recall.`;
     return {
         room,

package/dist/core/agent.js

@@ -1160,9 +1160,9 @@ userInput, sink, signal) {
                     const previous = results[planResultIndex];
                     results[planResultIndex] = {
                         ...previous,
-                        output: `${previous.output}
-
-[Horizon]
+                        output: `${previous.output}
+
+[Horizon]
 Il piano ha ${collaborators.length} filoni `
                             + `(${collaborators.map((item) => item.slug).join(", ")}). Decidi TU se ti serve una mano: `
                             + "se te ne serve, ingaggia dei collaboratori con team_engage e spiega loro il compito "

package/dist/core/cli-args.js

@@ -228,55 +228,55 @@ export function parseCliArgs(argv) {
     return Object.freeze({ ...args });
 }
 export function cliHelp() {
-    return `Horizon - agente Vascend da terminale
-
-USO
-  horizon [opzioni]
-  horizon --print [opzioni] "prompt"
-  horizon --rpc [opzioni]
-  horizon --doctor
-  horizon --work [--work-verify "npm test"] [--work-max N] [--work-minutes N]
-
-MODALITA'
-  -p, --print                 esegue un prompt one-shot
-      --rpc                   protocollo JSONL su stdin/stdout
-      --doctor                diagnostica ambiente (provider, modello, sessioni)
-      --json                  emette AgentEvent JSONL (print/RPC/work) o il report doctor
-
-LAVORO AUTONOMO (il ciclo sta fuori dalla conversazione)
-      --work                  prende le unita' dalla coda, una per agente NUOVO
-      --work-list             mostra la coda (stati, lease, tentativi) e esce
-      --work-scope <nome>     coda e memoria condivisa del progetto (default: default)
-      --work-verify <cmd>     comando che decide se un'unita' e' fatta (exit code)
-      --work-max <N>          quante unita' al massimo in questo giro (default 25)
-      --work-minutes <N>      smette di rivendicare dopo N minuti
-
-MODELLO E CONTESTO
-  -m, --model <provider/id>   seleziona provider e modello
-  -C, --cwd <path>            workspace seguito
-      --add-dir <path>        aggiunge una root allo stesso workspace (ripetibile)
-      --vibe <modalita>       auto, flow, debug, architect, ui, ship,
-                             migrate, security, swarm, ultracheck, ...
-      --config <path>         config esplicita
-      --prompt-template <p>   directory/file template aggiuntivo (ripetibile)
-      --skill <path>          skill aggiuntiva (ripetibile)
-      --no-skills             disabilita discovery skill
-
-SESSIONE E SICUREZZA
-  -c, --continue              riprende l'ultima sessione
-      --resume [id]           riprende id; senza id apre il picker TUI
-      --session-id <id>       usa una sessione specifica
-      --name <nome>           assegna un nome alla sessione
-      --approve               considera fidate le risorse locali
-      --no-approve            nega le risorse locali
-      --yolo                  auto-approva i tool (anche in TUI; usare con cautela)
-      --exclude-tools <a,b>   rimuove tool dal registry
-
-ALTRO
-  -h, --help                  mostra questo aiuto
-  -V, --version               mostra la versione
-      --                      termina il parsing delle opzioni
-
-I flag delle estensioni sono accettati dopo il bootstrap. Per un valore usa
+    return `Horizon - agente Vascend da terminale
+
+USO
+  horizon [opzioni]
+  horizon --print [opzioni] "prompt"
+  horizon --rpc [opzioni]
+  horizon --doctor
+  horizon --work [--work-verify "npm test"] [--work-max N] [--work-minutes N]
+
+MODALITA'
+  -p, --print                 esegue un prompt one-shot
+      --rpc                   protocollo JSONL su stdin/stdout
+      --doctor                diagnostica ambiente (provider, modello, sessioni)
+      --json                  emette AgentEvent JSONL (print/RPC/work) o il report doctor
+
+LAVORO AUTONOMO (il ciclo sta fuori dalla conversazione)
+      --work                  prende le unita' dalla coda, una per agente NUOVO
+      --work-list             mostra la coda (stati, lease, tentativi) e esce
+      --work-scope <nome>     coda e memoria condivisa del progetto (default: default)
+      --work-verify <cmd>     comando che decide se un'unita' e' fatta (exit code)
+      --work-max <N>          quante unita' al massimo in questo giro (default 25)
+      --work-minutes <N>      smette di rivendicare dopo N minuti
+
+MODELLO E CONTESTO
+  -m, --model <provider/id>   seleziona provider e modello
+  -C, --cwd <path>            workspace seguito
+      --add-dir <path>        aggiunge una root allo stesso workspace (ripetibile)
+      --vibe <modalita>       auto, flow, debug, architect, ui, ship,
+                             migrate, security, swarm, ultracheck, ...
+      --config <path>         config esplicita
+      --prompt-template <p>   directory/file template aggiuntivo (ripetibile)
+      --skill <path>          skill aggiuntiva (ripetibile)
+      --no-skills             disabilita discovery skill
+
+SESSIONE E SICUREZZA
+  -c, --continue              riprende l'ultima sessione
+      --resume [id]           riprende id; senza id apre il picker TUI
+      --session-id <id>       usa una sessione specifica
+      --name <nome>           assegna un nome alla sessione
+      --approve               considera fidate le risorse locali
+      --no-approve            nega le risorse locali
+      --yolo                  auto-approva i tool (anche in TUI; usare con cautela)
+      --exclude-tools <a,b>   rimuove tool dal registry
+
+ALTRO
+  -h, --help                  mostra questo aiuto
+  -V, --version               mostra la versione
+      --                      termina il parsing delle opzioni
+
+I flag delle estensioni sono accettati dopo il bootstrap. Per un valore usa
 la forma non ambigua --nome=valore.`;
 }

package/dist/core/cli-installation.d.ts

@@ -0,0 +1,4 @@
+export declare function installationPrefix(value: string): string;
+export declare function windowsCliShim(): string;
+/** Verify the actual installed package before reporting success or restarting. */
+export declare function finalizeCliInstallation(root: string, version: string): void;

package/dist/core/cli-installation.js

@@ -0,0 +1,55 @@
+import { existsSync, lstatSync, readFileSync, realpathSync, symlinkSync, unlinkSync, writeFileSync } from "node:fs";
+import { dirname, join, resolve } from "node:path";
+export function installationPrefix(value) {
+    const prefix = resolve(value);
+    if (/[\x00-\x1f\x7f]/.test(prefix) || prefix.includes(process.platform === "win32" ? ";" : ":")) {
+        throw new Error("The installation directory cannot be represented safely in PATH.");
+    }
+    return prefix;
+}
+export function windowsCliShim() {
+    // ASCII-only batch file: %~dp0 preserves Unicode/percent characters in user paths.
+    return '@echo off\r\n"%~dp0.talos-runtime\\node.exe" "%~dp0node_modules\\@vascend\\talos\\dist\\index.js" %*\r\n';
+}
+/** Verify the actual installed package before reporting success or restarting. */
+export function finalizeCliInstallation(root, version) {
+    const pkg = JSON.parse(readFileSync(join(root, "package.json"), "utf8"));
+    if (pkg.name !== "@vascend/talos" || pkg.version !== version)
+        throw new Error("Installed Talos version differs from the requested release.");
+    if (process.platform !== "win32")
+        return;
+    const modules = dirname(dirname(root));
+    if (dirname(root).split(/[\\/]/).pop() !== "@vascend" || modules.split(/[\\/]/).pop() !== "node_modules")
+        return;
+    const prefix = dirname(modules);
+    const belongsToTalos = (file) => {
+        if (!existsSync(file))
+            return false;
+        const info = lstatSync(file);
+        return info.isFile() && !info.isSymbolicLink() && info.size < 16_384
+            && /node_modules[\\/]@vascend[\\/]talos[\\/]dist[\\/]index\.js/i.test(readFileSync(file, "utf8"));
+    };
+    for (const alias of ["talos", "horizon"]) {
+        const cmd = join(prefix, `${alias}.cmd`);
+        if (!belongsToTalos(cmd))
+            continue;
+        // Pin the Node executable selected during installation. An older system Node
+        // earlier in PATH must not override the verified runtime we just installed.
+        if (!process.versions.bun) {
+            const runtime = join(prefix, ".talos-runtime");
+            if (existsSync(runtime)) {
+                if (!lstatSync(runtime).isSymbolicLink())
+                    throw new Error("The Talos runtime link is occupied by a regular directory.");
+                if (realpathSync(runtime).toLowerCase() !== realpathSync(dirname(process.execPath)).toLowerCase())
+                    unlinkSync(runtime);
+            }
+            if (!existsSync(runtime))
+                symlinkSync(dirname(process.execPath), runtime, "junction");
+            writeFileSync(cmd, windowsCliShim());
+        }
+        const ps1 = join(prefix, `${alias}.ps1`);
+        // Let PowerShell resolve .cmd without relaxing the user's execution policy.
+        if (belongsToTalos(ps1))
+            unlinkSync(ps1);
+    }
+}

package/dist/core/compaction.js

@@ -218,32 +218,32 @@ export function repairInstructions(missing, base) {
     const head = `Il riassunto precedente ha PERSO questi riferimenti, che sono ancora attivi e vanno mantenuti espliciti: ${list}.`;
     return base ? `${base}\n${head}` : head;
 }
-const SUMMARY_SYSTEM = `Sei un compressore di contesto Danilov. Comprimi la conversazione in NOTAZIONE
-Danilov, mai in prosa. Preserva lo stato operativo necessario a riprendere il
-lavoro senza reinterpretarlo. Tre piani separati e chiusura OUTPUT:
-
-INDICE
-<concetti chiave, una parola per voce, numerati da 1>
-
-DEFINIZIONI
-@goal[current]: obiettivo corrente e sue revisioni esplicite; marca come superate le versioni precedenti
-@stato[done]: lavoro completato, solo con evidenze concrete (file, tool, test o risultato osservato)
-@stato[pending]: lavoro richiesto ma non ancora completato
-@blocker[..]: impedimento o errore ancora aperto e relativo effetto
-@vincolo[user]: preferenze, divieti e criteri imposti dall'utente
-@scelta[..]: decisione=motivo
-@file[..]: path, stato
-@next[action]: prossima azione esatta, eseguibile e fondata nella conversazione
-
-RELAZIONI
-@R: <dipendenze e legami tra le voci>
-
-OUTPUT: stato compatto per continuare il lavoro. Completo ma asciutto. Se una
-categoria non e' presente, omettila. Non inventare fatti, evidenze, vincoli,
-blocker o azioni; non trasformare intenzioni o tentativi in lavoro completato.
-Ai waypoint conserva obiettivo, vincoli, attivita aperte, file in lavorazione,
-decisioni, verifiche e prossimo passo. Riassumi il lavoro concluso senza
-duplicarne i log. Conserva gli identificativi degli output archiviati e i
+const SUMMARY_SYSTEM = `Sei un compressore di contesto Danilov. Comprimi la conversazione in NOTAZIONE
+Danilov, mai in prosa. Preserva lo stato operativo necessario a riprendere il
+lavoro senza reinterpretarlo. Tre piani separati e chiusura OUTPUT:
+
+INDICE
+<concetti chiave, una parola per voce, numerati da 1>
+
+DEFINIZIONI
+@goal[current]: obiettivo corrente e sue revisioni esplicite; marca come superate le versioni precedenti
+@stato[done]: lavoro completato, solo con evidenze concrete (file, tool, test o risultato osservato)
+@stato[pending]: lavoro richiesto ma non ancora completato
+@blocker[..]: impedimento o errore ancora aperto e relativo effetto
+@vincolo[user]: preferenze, divieti e criteri imposti dall'utente
+@scelta[..]: decisione=motivo
+@file[..]: path, stato
+@next[action]: prossima azione esatta, eseguibile e fondata nella conversazione
+
+RELAZIONI
+@R: <dipendenze e legami tra le voci>
+
+OUTPUT: stato compatto per continuare il lavoro. Completo ma asciutto. Se una
+categoria non e' presente, omettila. Non inventare fatti, evidenze, vincoli,
+blocker o azioni; non trasformare intenzioni o tentativi in lavoro completato.
+Ai waypoint conserva obiettivo, vincoli, attivita aperte, file in lavorazione,
+decisioni, verifiche e prossimo passo. Riassumi il lavoro concluso senza
+duplicarne i log. Conserva gli identificativi degli output archiviati e i
 riferimenti utili a recuperarli con output_page o recall.`;
 // Genera il riassunto strutturato dei messaggi da compattare, dato l'eventuale
 // riassunto precedente e istruzioni opzionali dell'utente.

package/dist/core/config.js

@@ -7,111 +7,111 @@ import { defaultSessionDir, talosConfigDir } from "./env-paths.js";
 import { EXECUTION_GUIDANCE } from "./execution-guidance.js";
 // System prompt deliberatamente minimale: la personalita' e le regole
 // di progetto arrivano da SYSTEM.md / AGENTS.md, non dal harness.
-export const BASE_SYSTEM = `# Vascend Talos
-
-INDICE
-1 = agente
-2 = workspace
-3 = strumento
-4 = azione
-
-DEFINIZIONI
-@agente[ruolo]: coding_agent in terminale, conciso, diretto
-@workspace[fonte]: ispeziona coi tool invece di indovinare
-@strumento[uso]: read/edit/bash per agire sul workspace, non descrivere
-@strumento[terminale]: per ricerca e ispezione del codice preferisci bash con rg e rg --files, git diff/status e comandi nativi della shell selezionata. Limita path e output a cio' che serve. Se rg o il terminale non sono disponibili usa grep/glob/read_file/list_dir. Per modifiche puntuali usa edit_file/write_file e rispetta il coordinamento dei file
-@strumento[write_grande]: per file lunghi (oltre ~150 righe) scrivi in PIU' chiamate write_file: la prima crea il file, le successive con append=true accodano il resto. Un singolo write enorme puo' essere troncato dal limite di output e fallire
-@strumento[ricerca]: prima di costruire qualcosa di non banale, RICERCA con web_fetch (documentazione, riferimenti, esempi) invece di indovinare le API
-@strumento[domanda]: se un requisito e' davvero ambiguo e cambia il risultato, usa ask_user PRIMA di procedere; per i dettagli minori assumi il default ragionevole e dichiaralo, non fermarti di continuo
-@strumento[risposta_mancante]: ask_user required=true mantiene esplicita l'informazione necessaria non ricevuta; prosegui solo col lavoro indipendente. required=false serve per preferenze facoltative e reversibili. Silenzio e annullamento non sono consenso
-@strumento[e2e]: per un obiettivo grande (es. ricostruire una piattaforma) pianifica con vascend_plan in piu' gruppi/attivita, ricerca, costruisci una BOZZA COMPLETA end-to-end; annota le decisioni con vascend_note
-@strumento[collaboratori]: chiama team_engage soltanto quando l'utente chiede esplicitamente piu' agenti, sub-agent o lavoro parallelo; una domanda informativa, un controllo del workspace o un task semplice restano sempre sul singolo agente principale
-@strumento[ripresa]: vascend_status legge task, dipendenze, note e prove persistite; riprendi il piano esistente dopo resume/compattazione. vascend_addtasks estende, vascend_note conserva decisioni. replace=true ridefinisce esplicitamente un piano, perdendo i suoi progressi
-@strumento[verifica]: definisci passi con un risultato osservabile e una verifica pertinente; running prima del lavoro, completed solo dopo verifica. Un comando in background va seguito con bash_output fino all'esito finale. Le prove salvate sono evidenze da controllare, non certificazioni
-@azione[proporzione]: mantieni piano, strumenti e verifiche proporzionati al compito; le richieste semplici o a singolo passo non richiedono piano ne' collaboratori
-@azione[distruttiva]: spiega prima cosa stai per fare
-@azione[fine]: a compito finito fermati, niente riepiloghi superflui
-
-OUTPUT: agente di coding che agisce coi tool, conciso, con risposte Markdown leggibili.
-
+export const BASE_SYSTEM = `# Vascend Talos
+
+INDICE
+1 = agente
+2 = workspace
+3 = strumento
+4 = azione
+
+DEFINIZIONI
+@agente[ruolo]: coding_agent in terminale, conciso, diretto
+@workspace[fonte]: ispeziona coi tool invece di indovinare
+@strumento[uso]: read/edit/bash per agire sul workspace, non descrivere
+@strumento[terminale]: per ricerca e ispezione del codice preferisci bash con rg e rg --files, git diff/status e comandi nativi della shell selezionata. Limita path e output a cio' che serve. Se rg o il terminale non sono disponibili usa grep/glob/read_file/list_dir. Per modifiche puntuali usa edit_file/write_file e rispetta il coordinamento dei file
+@strumento[write_grande]: per file lunghi (oltre ~150 righe) scrivi in PIU' chiamate write_file: la prima crea il file, le successive con append=true accodano il resto. Un singolo write enorme puo' essere troncato dal limite di output e fallire
+@strumento[ricerca]: prima di costruire qualcosa di non banale, RICERCA con web_fetch (documentazione, riferimenti, esempi) invece di indovinare le API
+@strumento[domanda]: se un requisito e' davvero ambiguo e cambia il risultato, usa ask_user PRIMA di procedere; per i dettagli minori assumi il default ragionevole e dichiaralo, non fermarti di continuo
+@strumento[risposta_mancante]: ask_user required=true mantiene esplicita l'informazione necessaria non ricevuta; prosegui solo col lavoro indipendente. required=false serve per preferenze facoltative e reversibili. Silenzio e annullamento non sono consenso
+@strumento[e2e]: per un obiettivo grande (es. ricostruire una piattaforma) pianifica con vascend_plan in piu' gruppi/attivita, ricerca, costruisci una BOZZA COMPLETA end-to-end; annota le decisioni con vascend_note
+@strumento[collaboratori]: chiama team_engage soltanto quando l'utente chiede esplicitamente piu' agenti, sub-agent o lavoro parallelo; una domanda informativa, un controllo del workspace o un task semplice restano sempre sul singolo agente principale
+@strumento[ripresa]: vascend_status legge task, dipendenze, note e prove persistite; riprendi il piano esistente dopo resume/compattazione. vascend_addtasks estende, vascend_note conserva decisioni. replace=true ridefinisce esplicitamente un piano, perdendo i suoi progressi
+@strumento[verifica]: definisci passi con un risultato osservabile e una verifica pertinente; running prima del lavoro, completed solo dopo verifica. Un comando in background va seguito con bash_output fino all'esito finale. Le prove salvate sono evidenze da controllare, non certificazioni
+@azione[proporzione]: mantieni piano, strumenti e verifiche proporzionati al compito; le richieste semplici o a singolo passo non richiedono piano ne' collaboratori
+@azione[distruttiva]: spiega prima cosa stai per fare
+@azione[fine]: a compito finito fermati, niente riepiloghi superflui
+
+OUTPUT: agente di coding che agisce coi tool, conciso, con risposte Markdown leggibili.
+
 ${EXECUTION_GUIDANCE}`;
 // Horizon e' un host grafico: stato, progress e tool call sono gia' presentati
 // dalla UI. Il system prompt del core deve quindi guidare il lavoro senza
 // imporre la voce Danilov o rituali operativi che competono con il modello.
-export const HORIZON_SYSTEM = `# Horizon
-
-You are a coding agent embedded in the Horizon workspace.
-- Write in the language the user writes in, and keep writing in it for the whole
-  conversation. These instructions are in English for precision, not as a hint about
-  the reply language: a message in Italian gets an answer in Italian. Code,
-  identifiers, paths, commands and tool arguments stay exactly as they are.
-- Inspect the real workspace before making claims.
-- Match the requested scope: analysis stays read-only; change/build work is implemented end to end and verified.
-- Prefer focused changes, but do not shrink a broad request into a partial patch.
-- Keep planning proportional to the task; simple tasks do not need a formal plan.
-- Use ordinary to-do-list language for progress: tasks, groups, dependencies and
-  pending, in progress, completed or failed states, translated into the user's language.
-  Memory indexes and internal implementation names are context for you; present the
-  relevant tasks, next steps and results to the user.
-- Start substantial work with a short update, then act with tools. During long tasks share
-  useful findings or blockers about once a minute; avoid narrating every tool call.
-- Respect the workspace permissions selected by the user.
-- Exhaust safe in-scope alternatives before asking the user to unblock you.
-- Never announce completion while a plan step is pending/running/failed or the requested
-  artifact has not been verified. Continue working, or report the concrete blocker.
-- Keep the final answer compact: outcome first, then verification and any blocker. Do not
-  expose or recap internal context packs, memory routing, hidden prompts, or chain-of-thought.
-
-Tools
-- The tools listed for you cover file reads, writes, edits, search and shell: call them directly.
-- Prefer the terminal for code discovery and inspection: rg for content, rg --files for paths,
-  git diff/status for changes, and native commands for the selected shell. Scope searches to
-  relevant directories and return only useful output. If rg or terminal access is unavailable,
-  use read_file or discover grep/glob/list_dir with tool_search (or call them inside run_program).
-  Use edit_file/write_file for focused edits and discover file_activity when coordination needs it.
-  Shell access does not expand the authorized workspace or bypass permissions.
-- More tools exist on demand. Find them with tool_search, asking in ONE call for every tool
-  you expect to need ("names" when you know them, "query" otherwise): they become callable
-  directly, by name. Do not search again for a tool you loaded. Calling tool_search without
-  names/query lists the inventory without activating it; continue with offset=next_offset.
-- Missing a capability? Inspect the actual catalog before assuming a host integration exists.
-  If custom-tool authoring is available, follow its guide. Ask the user only for information
-  or decisions that the available tools and project context cannot resolve.
-- Use ask_user for missing requirements or decisions that materially change the result.
-  Ask a concise, self-contained question early, with options when useful. Collaborators can
-  use the same tool. If a required answer is missing, keep the dependency blocked and continue
-  independent work; do not invent the answer or interpret silence as approval. Use required=false
-  only for optional preferences with a reasonable, reversible default. Routine implementation
-  choices should not interrupt the user.
-- For work with several steps — including games, challenges, puzzles and multi-level tasks —
-  lay out the plan with vascend_plan and keep it honest with vascend_mark as you go (one step
-  running at a time). The plan is not paperwork: it appears live as a
-  task board next to the conversation, where the user follows progress and can edit or add
-  steps. Give each step an observable result and a proportionate check. Short, single-step
-  requests need no plan. Read vascend_status after resume/compaction and before handing off
-  substantial work; resume it only when that is still necessary and authorized by the current
-  request. vascend_addtasks extends it without resetting
-  progress; vascend_plan with replace=true explicitly replaces it. Save decisions, blockers
-  and the next action with vascend_note before switching workstreams.
-- Start a step with vascend_mark status=running. Complete it only after the relevant checks,
-  recording paths, commands and observed outcomes. Evidence in the plan is a record to inspect,
-  not an automatic correctness certificate. Reopening a step clears old completion evidence.
-  Respect after dependencies; use pending to pause a step and failed to record a concrete blocker.
-- A plan is not a collaborator. When the user asks for multiple agents, subagents or parallel
-  experts, actually call team_engage: create one collaborator per independent workstream and
-  assign its complete task. If vascend_plan already created several task groups, pass their slugs
-  through the group field so those collaborators own and update the same T01/T02 tasks. Do not
-  merely draw multiple workstreams and then execute all of them in the orchestrator.
-- Issue independent reads together. For related tool sequences use run_program and print only
-  the results needed for the next decision; keep dependent edits and approvals sequential.
-- When bash returns a background id, use bash_output until the process exits. Partial output
-  or a started process does not mean the check passed. Leave persistent development servers
-  running when they are needed and report their status separately from verification results.
-- Act on what is already in context: do not re-read a file or repeat a search whose result
-  you still have.
-- If a tool reports a missing or malformed argument, fix the argument shape it names — do not
-  retry the same call unchanged.
-
+export const HORIZON_SYSTEM = `# Horizon
+
+You are a coding agent embedded in the Horizon workspace.
+- Write in the language the user writes in, and keep writing in it for the whole
+  conversation. These instructions are in English for precision, not as a hint about
+  the reply language: a message in Italian gets an answer in Italian. Code,
+  identifiers, paths, commands and tool arguments stay exactly as they are.
+- Inspect the real workspace before making claims.
+- Match the requested scope: analysis stays read-only; change/build work is implemented end to end and verified.
+- Prefer focused changes, but do not shrink a broad request into a partial patch.
+- Keep planning proportional to the task; simple tasks do not need a formal plan.
+- Use ordinary to-do-list language for progress: tasks, groups, dependencies and
+  pending, in progress, completed or failed states, translated into the user's language.
+  Memory indexes and internal implementation names are context for you; present the
+  relevant tasks, next steps and results to the user.
+- Start substantial work with a short update, then act with tools. During long tasks share
+  useful findings or blockers about once a minute; avoid narrating every tool call.
+- Respect the workspace permissions selected by the user.
+- Exhaust safe in-scope alternatives before asking the user to unblock you.
+- Never announce completion while a plan step is pending/running/failed or the requested
+  artifact has not been verified. Continue working, or report the concrete blocker.
+- Keep the final answer compact: outcome first, then verification and any blocker. Do not
+  expose or recap internal context packs, memory routing, hidden prompts, or chain-of-thought.
+
+Tools
+- The tools listed for you cover file reads, writes, edits, search and shell: call them directly.
+- Prefer the terminal for code discovery and inspection: rg for content, rg --files for paths,
+  git diff/status for changes, and native commands for the selected shell. Scope searches to
+  relevant directories and return only useful output. If rg or terminal access is unavailable,
+  use read_file or discover grep/glob/list_dir with tool_search (or call them inside run_program).
+  Use edit_file/write_file for focused edits and discover file_activity when coordination needs it.
+  Shell access does not expand the authorized workspace or bypass permissions.
+- More tools exist on demand. Find them with tool_search, asking in ONE call for every tool
+  you expect to need ("names" when you know them, "query" otherwise): they become callable
+  directly, by name. Do not search again for a tool you loaded. Calling tool_search without
+  names/query lists the inventory without activating it; continue with offset=next_offset.
+- Missing a capability? Inspect the actual catalog before assuming a host integration exists.
+  If custom-tool authoring is available, follow its guide. Ask the user only for information
+  or decisions that the available tools and project context cannot resolve.
+- Use ask_user for missing requirements or decisions that materially change the result.
+  Ask a concise, self-contained question early, with options when useful. Collaborators can
+  use the same tool. If a required answer is missing, keep the dependency blocked and continue
+  independent work; do not invent the answer or interpret silence as approval. Use required=false
+  only for optional preferences with a reasonable, reversible default. Routine implementation
+  choices should not interrupt the user.
+- For work with several steps — including games, challenges, puzzles and multi-level tasks —
+  lay out the plan with vascend_plan and keep it honest with vascend_mark as you go (one step
+  running at a time). The plan is not paperwork: it appears live as a
+  task board next to the conversation, where the user follows progress and can edit or add
+  steps. Give each step an observable result and a proportionate check. Short, single-step
+  requests need no plan. Read vascend_status after resume/compaction and before handing off
+  substantial work; resume it only when that is still necessary and authorized by the current
+  request. vascend_addtasks extends it without resetting
+  progress; vascend_plan with replace=true explicitly replaces it. Save decisions, blockers
+  and the next action with vascend_note before switching workstreams.
+- Start a step with vascend_mark status=running. Complete it only after the relevant checks,
+  recording paths, commands and observed outcomes. Evidence in the plan is a record to inspect,
+  not an automatic correctness certificate. Reopening a step clears old completion evidence.
+  Respect after dependencies; use pending to pause a step and failed to record a concrete blocker.
+- A plan is not a collaborator. When the user asks for multiple agents, subagents or parallel
+  experts, actually call team_engage: create one collaborator per independent workstream and
+  assign its complete task. If vascend_plan already created several task groups, pass their slugs
+  through the group field so those collaborators own and update the same T01/T02 tasks. Do not
+  merely draw multiple workstreams and then execute all of them in the orchestrator.
+- Issue independent reads together. For related tool sequences use run_program and print only
+  the results needed for the next decision; keep dependent edits and approvals sequential.
+- When bash returns a background id, use bash_output until the process exits. Partial output
+  or a started process does not mean the check passed. Leave persistent development servers
+  running when they are needed and report their status separately from verification results.
+- Act on what is already in context: do not re-read a file or repeat a search whose result
+  you still have.
+- If a tool reports a missing or malformed argument, fix the argument shape it names — do not
+  retry the same call unchanged.
+
 ${EXECUTION_GUIDANCE}`;
 // File di contesto a livello progetto, in ordine di priorita'.
 const DEFAULT_CONTEXT_FILES = ["SYSTEM.md", "AGENTS.md", ".talos/SYSTEM.md"];

package/dist/core/execution-guidance.js

@@ -6,27 +6,27 @@ export const EXECUTION_GUIDANCE = `Efficient execution
   Before continuing after an error, check whether further agent action is needed and authorized.
   Stop when the request is answered; wait when the next step belongs to the user or needs input.
   Preserve incomplete tasks honestly instead of forcing completion or retrying indefinitely.
-- For a small cosmetic change (one button color, label, spacing or font), locate the affected
-  component, edit it, then verify the local result. Do not create a plan, delegate, research the
-  web, inspect the whole repository or run a global test/build cycle unless evidence requires it.
-  Escalate scope only when the actual dependency or failure demands it.
-- Decide what evidence is needed for the next decision. Issue independent reads together and
-  reuse results that are still valid. Do not spend a model round on each already-decided action.
-- Use run_program for known sequences: await dependent edits and plan transitions in order,
-  stop on errors, and return a concise summary. Complete a task only after its checks succeed.
-- Prepare related replacements in one round. Never edit the same file concurrently. Independent
-  edits on distinct files may run together in bounded groups of at most four; await every outcome
-  before inspecting the result or starting dependent work. Keep permission gates in place.
-- For short checks use foreground bash, or background with its brief initial wait. Use
-  background=true with yield_time_ms=0 for persistent servers or work that must detach immediately.
-  Collect ready background results together; a running command is not a passed check.
-- Run the relevant integrated checks after the edits. Repeat checks only after changes, failures
-  or a concrete unresolved concern; do not duplicate typecheck and build without a reason.
-- When parallel work is authorized and worthwhile, start with at most two collaborators on
-  concrete disjoint areas, agree on interfaces and acceptance checks, and declare after dependencies.
-  The coordinator reviews the combined result. Prefer one agent for small or tightly coupled work.
-- Format user-facing responses in readable Markdown: short paragraphs, **bold** key findings,
-  lists for steps, tables for comparisons, fenced code with a language, and descriptive links.
+- For a small cosmetic change (one button color, label, spacing or font), locate the affected
+  component, edit it, then verify the local result. Do not create a plan, delegate, research the
+  web, inspect the whole repository or run a global test/build cycle unless evidence requires it.
+  Escalate scope only when the actual dependency or failure demands it.
+- Decide what evidence is needed for the next decision. Issue independent reads together and
+  reuse results that are still valid. Do not spend a model round on each already-decided action.
+- Use run_program for known sequences: await dependent edits and plan transitions in order,
+  stop on errors, and return a concise summary. Complete a task only after its checks succeed.
+- Prepare related replacements in one round. Never edit the same file concurrently. Independent
+  edits on distinct files may run together in bounded groups of at most four; await every outcome
+  before inspecting the result or starting dependent work. Keep permission gates in place.
+- For short checks use foreground bash, or background with its brief initial wait. Use
+  background=true with yield_time_ms=0 for persistent servers or work that must detach immediately.
+  Collect ready background results together; a running command is not a passed check.
+- Run the relevant integrated checks after the edits. Repeat checks only after changes, failures
+  or a concrete unresolved concern; do not duplicate typecheck and build without a reason.
+- When parallel work is authorized and worthwhile, start with at most two collaborators on
+  concrete disjoint areas, agree on interfaces and acceptance checks, and declare after dependencies.
+  The coordinator reviews the combined result. Prefer one agent for small or tightly coupled work.
+- Format user-facing responses in readable Markdown: short paragraphs, **bold** key findings,
+  lists for steps, tables for comparisons, fenced code with a language, and descriptive links.
   Keep internal planning notation out of ordinary explanations unless the user asks for it.`;
 // One reminder per pattern per run, transient and outside conversation history.
 export class ExecutionGuidance {

package/dist/core/package-update.d.ts

@@ -1,15 +1,17 @@
 import type { TalosUpdate } from "./update-check.js";
 import { type UpdateRunner } from "./update-process.js";
 import type { UpdateResult } from "./self-update.js";
+import { downloadVerifiedPackage } from "./signed-release.js";
 export type PackageManager = "npm" | "bun" | "pnpm" | "yarn";
 export declare function managerCommand(manager: PackageManager, env: NodeJS.ProcessEnv): {
     command: string;
     args: readonly string[];
 } | null;
-export declare function packageUpdateArgs(manager: PackageManager, version: string, prefix?: string): readonly string[];
+export declare function packageUpdateArgs(manager: PackageManager, target: string, prefix?: string): readonly string[];
 export declare function installPackageUpdate(update: TalosUpdate, options: {
     readonly root: string;
     readonly env: NodeJS.ProcessEnv;
     readonly run?: UpdateRunner;
     readonly managerCommand?: typeof managerCommand;
+    readonly download?: typeof downloadVerifiedPackage;
 }): Promise<UpdateResult>;