theus-cli-linux-x64 1.1.0 → 1.2.0

package/README.md

@@ -1,295 +1,128 @@
-# THEUS — CLI
+# Theus — agente de código para la terminal
 
-> **THEUS · Many intelligences. One decision.**
-> Dominio: [`theus.pe`](https://theus.pe) · Docs: [`docs.theus.pe`](https://docs.theus.pe)
+Theus es un agente de programación que vive en tu terminal. Abres una sesión dentro
+de un proyecto y le hablas en español: lee el código, propone los cambios, edita los
+archivos y ejecuta comandos —siempre pidiéndote permiso antes de tocar o correr algo.
 
-**Theus** es un agente de código **local-first y multimodelo**: abre una sesión interactiva desde cualquier proyecto, lo indexa en tu propia máquina, mantiene memoria y un grafo del código, levanta un dashboard visual, y ejecuta tareas de programación con el modelo que elijas.
+Funciona en macOS, Linux y Windows. Hecho en Perú.
 
-Este repo es el **producto principal**: el CLI `theus` (Bun + Ink/React en TSX). El lado servidor (web, gateway y consola) vive en [`MarketrixPE/theus-pe`](https://github.com/MarketrixPE/theus-pe).
+- Web: <https://theus.pe>
+- Documentación: <https://docs.theus.pe>
+- Estado del servicio: <https://theus.pe/estado>
 
 ---
 
-## 🧠 Cómo encaja en el negocio
-
-Theus se puede usar de dos maneras, y las dos son ciudadanas de primera clase:
-
-1. **Local-first / BYOK** — apunta el CLI a cualquier endpoint OpenAI-compatible (Ollama, LM Studio, un gateway propio, tu propia key). Todo corre en tu máquina; ningún servicio remoto es obligatorio para arrancar.
-2. **Suscripción Theus (gateway gestionado)** — `theus login` conecta el CLI al gateway de `theus.pe`. Con **una sola API key de Theus** accedes a los **~20 mejores modelos** (Claude, GPT, Gemini, DeepSeek, Grok, Qwen, GLM…). **Theus** administra centralmente las keys de cada proveedor; tú solo usas tu suscripción — **no traes tus propias keys de proveedor**.
-
-En el modo suscripción, el modelo por defecto es **`titan`**: el orquestador propio de Theus que analiza cada petición, decide si la resuelve con **un modelo** o la **descompone entre varios**, y **sintetiza** la respuesta final. (Toda la lógica de TITAN, el catálogo y la gestión de keys está documentada en el README de [`theus-pe`](https://github.com/MarketrixPE/theus-pe).)
-
-> **Regla de producto:** el copy visible es **español-first** y **sin marcas externas**. La única excepción es el catálogo de modelos, donde sí aparecen los nombres reales.
-
----
-
-## 🚀 Instalación (usuarios)
-
-Requisito de runtime: **Bun** (`cli.js` es un bundle con target `bun`, no corre bajo Node). El instalador oficial instala Bun por ti si falta, verificando su checksum SHA-256.
-
-```bash
-curl -fsSL https://theus.pe/install.sh | bash
-theus --version
-```
-
-El instalador detecta tu plataforma (macOS/Linux, x64/arm64), descarga el tarball del último release (primario desde `theus.pe/dl`, con GitHub Releases como respaldo — el repo es privado), lo instala en `~/.theus/app` y enlaza `theus` en tu PATH. Es idempotente: para actualizar, vuelve a ejecutarlo. En **Windows** usa el instalador nativo (instala también Ñaupa): `powershell -c "irm https://theus.pe/install.ps1 | iex"`.
-
-**Alternativa vía npm** (no requiere Bun: instala un binario nativo por plataforma):
+## Instalación
 
 ```bash
 npm install -g theus-cli
+theus --version
 ```
 
-El paquete `theus-cli` es un lanzador mínimo; el producto llega compilado en un paquete de plataforma (`theus-cli-darwin-arm64`, `theus-cli-linux-x64`, …) declarado como dependencia opcional. No instales con `--omit=optional`: te quedarías sin binario.
+Con Node 18 o superior basta. El producto viaja como binario nativo dentro de un
+paquete de plataforma (`theus-cli-darwin-arm64`, `theus-cli-linux-x64`, …) que npm
+instala como dependencia opcional: **no instales con `--omit=optional` ni
+`--no-optional`**, te quedarías con el lanzador y sin binario.
 
-Variables del instalador: `THEUS_INSTALL_MODE` (`auto`|`release`|`source`), `THEUS_VERSION` (`latest` o `vX.Y.Z`), `THEUS_HOME`, `THEUS_BIN_DIR`.
+Plataformas publicadas: macOS (arm64 y x64), Linux (x64 y arm64) y Windows (x64).
 
-### Primer uso
+## Primer uso
 
 ```bash
 cd /ruta/de/tu/proyecto
 theus                    # sesión interactiva
-theus -p "tu prompt"     # modo no interactivo
-theus login              # conectar la suscripción Theus
-```
-
----
-
-## 🧩 Conectar un modelo
-
-Theus lee primero las variables `THEUS_*`. Apunta a cualquier endpoint OpenAI-compatible:
-
-```bash
-export THEUS_BASE_URL="http://127.0.0.1:11434/v1"
-export THEUS_MODEL="llama3.1"
-export THEUS_API_KEY="local"
-theus
-```
-
-O define proveedores en `~/.theus/providers.json`:
-
-```json
-{
-  "providers": [
-    { "id": "ollama", "adapter": "openai-compatible", "enabled": true,
-      "options": { "baseURL": "http://127.0.0.1:11434/v1", "model": "llama3.1", "apiKey": "local" } }
-  ],
-  "policy": { "text": ["ollama"] }
-}
-```
-
-**`theus login`** hace el flujo OAuth/PKCE contra `theus.pe`, intercambia el código por token y deja instalado el proveedor `theus-official` (`https://theus.pe/v1`, modelo `titan`) en `~/.theus/providers.json`. A partir de ahí basta con `theus`.
-
-**Orden de selección de proveedor** (`services/api/theus.ts`): `THEUS_DISABLE_MAIN_PROVIDER=1` → env `THEUS_BASE_URL`/`THEUS_OPENAI_BASE_URL` → primer proveedor con texto en `providers.json` → motor de compatibilidad. Ningún servicio remoto es obligatorio para arrancar.
-
-### Variables útiles
-
-| Variable | Uso |
-| --- | --- |
-| `THEUS_BASE_URL` / `THEUS_OPENAI_BASE_URL` | endpoint OpenAI-compatible |
-| `THEUS_MODEL` / `THEUS_API_KEY` / `THEUS_PROVIDER_ID` | modelo, key y nombre del proveedor |
-| `THEUS_DISABLE_MAIN_PROVIDER=1` | fuerza el motor de compatibilidad |
-| `THEUS_NO_PROJECT_INTELLIGENCE=1` | no levanta índice/API/dashboard |
-| `THEUS_NO_OPEN_DASHBOARD=1` | levanta la API sin abrir el navegador |
-| `PROJECT_API_PORT` / `INDEX_MAX_FILES` | puerto local / límite de archivos indexados |
-| `THEUS_TITAN_CONTROL_PLANE_URL` / `THEUS_TITAN_CONTROL_PLANE_API_KEY` | activa el ledger de orquestación TITAN; ambos son obligatorios |
-| `THEUS_TITAN_CONTROL_PLANE_TIMEOUT_MS` | timeout total de reportes y reintentos idempotentes |
-| `THEUS_TITAN_TASK_TIMEOUT_SECONDS` | deadline real de tarea, verificación e integración |
-| `THEUS_TITAN_FLEET_URL` / `THEUS_TITAN_FLEET_REGISTRATION_TOKEN` | habilita únicamente el comando explícito `fleet-worker`; no afecta el arranque normal |
-
----
-
-### Orquestación TITAN y worktrees
-
-El control-plane de programación es opt-in y no es necesario para usar Theus
-localmente. Las URLs remotas deben usar HTTPS; sólo los loopbacks aceptan HTTP.
-Con TITAN activo, un worktree se integra al padre después de
-`integration.started` y sólo bajo `acceptEdits` o `bypassPermissions`. Conflicto,
-dirty solapado, cancelación o timeout fallan cerrados, conservan el worktree y
-no sobrescriben cambios del usuario. La referencia operativa, variables, retry,
-rollback y smoke están en [THEUS.md](./THEUS.md#control-plane-de-orquestación-titan-opt-in).
-
-### Worker distribuido TITAN Fleet
-
-`theus fleet-worker` conecta una máquina a la cola durable compartida por CLI,
-Chat y Enterprise. Es headless y opt-in: rota su token de worker, reclama jobs
-por lease cercado, mantiene heartbeats independientes y ejecuta el runtime
-agentic real de Theus dentro del workspace o un worktree. `SIGINT`/`SIGTERM`
-activa draining, libera jobs todavía no iniciados y espera las ejecuciones en
-curso dentro de un grace period.
-
-```bash
-export THEUS_TITAN_FLEET_URL="https://theus.pe"
-export THEUS_TITAN_FLEET_REGISTRATION_TOKEN="..." # nunca usar un argumento CLI
-export THEUS_TITAN_FLEET_WORKSPACE="/ruta/al/proyecto"
-theus fleet-worker --queues default --max-concurrency 2
-```
-
-Las credenciales rotadas se guardan atómicamente en
-`~/.theus/titan/fleet-worker.json` con modo `0600`. Un `409 stale_lease`
-descarta el resultado y nunca lo publica como propio. La referencia completa de
-variables, seguridad y operación está en
-[THEUS.md](./THEUS.md#worker-distribuido-titan-fleet-opt-in).
-Antes de integrar un worktree o enviar `complete`/`fail`, el worker persiste un
-outbox terminal atómico `0600`. Un ACK perdido conserva el mismo payload,
-fencing token y `completion_key`; al reiniciar se reproduce antes de aceptar
-otro claim. Sólo un rechazo `stale_lease` definitivo autoriza rollback.
-Los workers `platform` son sólo lectura por defecto; cualquier capacidad
-privilegiada requiere HTTPS y una allowlist explícita de queues, sin comodines.
-Los jobs con capacidad de escritura siempre se ejecutan en worktree; nunca
-mutan directamente el workspace.
-
-## 📊 Dashboard e inteligencia local
-
-Al iniciar dentro de un proyecto, el servicio de inteligencia local indexa archivos, extrae símbolos, construye el grafo, detecta esquemas SQL/Prisma, guarda índice y memoria en `~/.theus/knowledge/` y expone un dashboard en `127.0.0.1`:
-
-```text
-/dashboard   /api/status   /api/graph   /api/database   /api/schema   /api/health
+theus -p "arregla el test que falla en checkout"   # una tarea, sin sesión
+theus login              # conectar tu suscripción
+theus update             # actualizar
 ```
 
 ---
 
-## 🧭 Ñaupa (motor de inteligencia de código)
-
-Si el binario [`naupa`](https://theus.pe/naupa/) está instalado, Theus lo monta **automáticamente** como servidor MCP (`theus-naupa`) en cada sesión: grafo de conocimiento AST del proyecto (tree-sitter, 158 lenguajes), cadenas de llamadas, consultas Cypher y análisis de impacto en <1 ms — el agente consulta la estructura antes de recurrir a grep/read.
-
-```bash
-curl -fsSL https://theus.pe/naupa.sh | bash   # instalar Ñaupa (macOS/Linux)
-THEUS_NO_NAUPA=1 theus                        # kill-switch por sesión
-```
-
-En Windows no hace falta comando aparte: el instalador oficial (`powershell -c "irm https://theus.pe/install.ps1 | iex"`) instala también Ñaupa con la UI 3D. (En PowerShell `curl` es un alias de `Invoke-WebRequest`; los comandos `curl … | bash` son solo para macOS/Linux.)
-
-Las tools de lectura (`search_graph`, `trace_path`, `query_graph`, `get_architecture`, …) van pre-permitidas; las que escriben (`index_repository`, `delete_project`, …) pasan por el flujo de permisos normal. Caché en `~/.theus/naupa/`. Código: `services/mcpNaupa/`. Docs: [theus.pe/docs/naupa](https://theus.pe/docs/naupa).
-
----
-
-## 🖥️ Computer-use (control de escritorio — macOS)
-
-Theus puede ver la pantalla y operarla (mouse + teclado). Implementación propia, **sin addons compilados**: se apoya en herramientas nativas del sistema (`screencapture`, `sips`, `cliclick`, `osascript`). Es **opt-in** y solo macOS.
-
-```bash
-brew install cliclick                     # única dependencia externa
-theus --theus-computer-use-selftest       # certifica captura+control en tu Mac
-THEUS_COMPUTER_USE=1 theus                # arranca con computer-use montado
-```
-
-Requiere otorgar **dos permisos** al app que corre Theus (tu terminal), en Ajustes del Sistema → Privacidad y seguridad: **Grabación de pantalla** y **Accesibilidad**. Sin ellos, las tools devuelven un error accionable (no rompen el turno). El agente trabaja tomando un `screenshot`, razonando sobre la imagen y dando coordenadas en píxeles; el server las mapea a puntos lógicos de la pantalla. Tools MCP: `mcp__theus-computer-use__{screenshot,left_click,double_click,right_click,mouse_move,left_click_drag,type,key,scroll,cursor_position,wait,permissions}` (`services/mcpComputerUse/`).
+## Qué hace de verdad
+
+- **Trabaja sobre tu proyecto.** Lee y edita archivos, corre comandos y tests, busca
+  por el repositorio y explica lo que encuentra. Cada acción que escribe, ejecuta o
+  borra pasa por tu confirmación; el permiso es del CLI, no del modelo.
+- **Se orienta solo en el código.** Al arrancar indexa el proyecto **en tu máquina**
+  y mantiene memoria y un grafo del código entre sesiones, para no volver a empezar
+  de cero cada vez. Además levanta un panel local para ver ese mapa y el esquema de
+  tu base de datos.
+- **Arsenal incluido.** 243 skills, 64 agentes, 77 comandos y 21 reglas empaquetados
+  con el binario, listos desde la primera sesión. Catálogo: <https://theus.pe/arsenal>
+- **Conecta herramientas externas** por MCP (servidores propios o de terceros), con
+  el mismo flujo de permisos.
+- **Opera tu navegador** cuando se lo pides: abrir páginas, leerlas, hacer clic,
+  escribir, tomar capturas y leer consola y red para depurar tu web. Necesita la
+  extensión de navegador de Theus; el comando `/chrome` te guía para instalarla.
+- **Graba y repite tareas de navegador** (Kuti): grabas una vez, Theus entiende el
+  paso y lo repite adaptándose; puedes exportar el guion y pasárselo a tu equipo.
+- **Control remoto** (`/wokitoki`): sigues la sesión desde <https://theus.pe/code> y
+  le escribes desde el móvil. Desde el remoto solo se aprueban acciones de lectura;
+  lo que escribe o ejecuta sigue pidiendo confirmación en tu máquina.
+
+Opcional: si instalas el motor de análisis **Ñaupa** (`curl -fsSL
+https://theus.pe/naupa.sh | bash`), Theus lo detecta y lo monta solo, y suma 19
+herramientas de análisis del código —arquitectura, radio de impacto de un cambio,
+esquema de base de datos, código muerto, duplicados—. Es 100% local.
 
 ---
 
-## 🛠️ Desarrollo
+## Los modelos
 
-```bash
-bun install
-bun run dev                 # corre desde fuente (entrypoints/cli.tsx)
-./bin/theus --version       # vía el launcher (preload de shims)
-bun run build               # bundle → ./cli.js  (usa el macro feature(); --define feature=false)
-bun run typecheck           # tsc --noEmit — ⚠️ ver caveat
-```
+Theus no trae modelo propio. Tienes dos formas de darle uno, y las dos son de
+primera clase:
 
-**Smoke tests** (la verificación real, no el typecheck):
+**1. Local o con tu propia clave.** Apunta el CLI a cualquier endpoint compatible
+con el estándar `/v1/chat/completions` —un motor corriendo en tu máquina, un gateway
+tuyo, tu propia clave—:
 
 ```bash
-THEUS_NO_PROJECT_INTELLIGENCE=1 ./bin/theus --help
-THEUS_NO_OPEN_DASHBOARD=1 ./bin/theus
-curl http://127.0.0.1:<puerto>/api/status
-curl http://127.0.0.1:<puerto>/api/database
+export THEUS_BASE_URL="http://127.0.0.1:11434/v1"
+export THEUS_MODEL="tu-modelo"
+export THEUS_API_KEY="local"
+theus
 ```
 
-> **Typecheck:** `bun run typecheck` está en 0 y es **gate real** del release (`release.yml` aborta si falla). Córrelo antes de tagear. Verde no basta: valida además con tests enfocados + smoke tests del CLI + chequeos del dashboard.
+Ningún servicio remoto es obligatorio para arrancar el CLI.
 
-### Flujo de arranque
+**2. Suscripción Theus.** `theus login` conecta el CLI al servicio de `theus.pe`:
+una sola cuenta te da acceso a un catálogo de 188 modelos de código, razonamiento
+y multimodal, escalonado por plan. Theus administra las claves de cada proveedor;
+**tú no traes ninguna**. El catálogo, con los nombres de cada modelo, está en
+<https://theus.pe/#modelos>, y la lista viva la devuelve `GET /v1/models`.
 
-```
-bin/theus → entrypoints/cli.tsx → main.tsx → setup.ts → replLauncher.tsx → screens/REPL.tsx → query.ts
-```
-
-`bin/theus` corre Bun con `--preload bun-shims/preload.ts` (registra el shim del macro `feature()`/`bun:bundle` y stubs internos para correr sin bundlear). `login`/`signin`/`entrar` los intercepta el launcher y los enruta a `entrypoints/theus-login.ts`.
-
-### Mapa de arquitectura
-
-```text
-services/api/theus.ts            proveedor de modelos — router OpenAI-compatible + fallback
-services/knowledge/              índice local, grafo del proyecto, memoria (~/.theus/knowledge/)
-services/projectIntelligence/    API HTTP local + dashboard + DB visual (detección SQL/Prisma)
-tools.ts                         registro de herramientas (¡el orden importa!)
-commands.ts                      registro de slash-commands (¡el orden importa!)
-components/Theus/                 identidad textual, menú y setup de proveedor
-vendor/theus-packages/           paquetes propios (agent-sdk, sdk, mcpb)
-vendor/theus-stubs/              adaptadores locales para dependencias opcionales
-types/                           tipos públicos + shims
-```
+En modo suscripción el modelo por defecto es `titan`, el orquestador de Theus:
+analiza cada petición, decide si la resuelve con un modelo o la reparte entre varios,
+y sintetiza la respuesta.
 
 ---
 
-## ⚠️ Convenciones que NO se rompen (léelas antes de tocar código)
+## Precios
 
-Este CLI es el producto THEUS Code. Varios invariantes de build son
-**load-bearing** y fáciles de romper sin querer.
+En soles, IGV incluido. El plan anual cuesta diez mensualidades (dos meses gratis).
 
-- **Mantén las extensiones `.js` en imports ESM** aunque el archivo fuente sea `.ts`/`.tsx`.
-- Usa `import type` para imports de solo-tipo (`verbatimModuleSyntax` está activo).
-- **No auto-ordenes ni reordenes `tools.ts` ni `commands.ts`** — el orden es significativo.
-- `feature("FLAG")` es un **macro de build**, no un `if` de runtime. No lo reescribas como condicional normal; el bundler hace dead-code-elimination desde ahí (`build` pasa `--define feature=false`). Los módulos gateados por build se cargan con `require()` condicional dentro de un ternario.
-- Mantén inline `process.env.THEUS_BUILD_AUDIENCE === 'internal'` en ramas que
-  dependan de DCE. El nombre ya fue migrado al contrato propio de THEUS.
-- Evita editar `main.tsx` en bloque (entrada grande heredada). Prefiere `components/`, `hooks/`, `screens/`, `services/`, `tools/`, `commands/`.
-- No cambies prompts sensibles sin motivo: `query.ts`, reglas de thinking, permisos, seguridad, prompts de herramientas.
+| Plan | Al mes | Incluye |
+| --- | --- | --- |
+| Free | S/ 0 | 25 créditos, sin tarjeta |
+| Impulso | S/ 39 | 1.000 créditos |
+| Pro | S/ 79 | 2.000 créditos, visión ampliada |
+| Power | S/ 199 | 5.000 créditos, multi-agente (hasta 4 subtareas por petición) |
+| Creativo | S/ 349 | 6.000 créditos + 150 imágenes + vídeo, con cuota propia |
+| Empresa | S/ 599 | 12.000 créditos + 200 imágenes + consola de equipo |
 
-### Añadir una herramienta o comando
+El plan Free da para una sesión de trabajo, no para el día a día. Cada plan
+desbloquea lo del anterior y añade su tramo del catálogo.
 
-- **Herramienta:** `buildTool(...) satisfies ToolDef<...>`, constante de nombre en `prompt.ts`/`constants.ts`, regístrala en `getAllBaseTools()`, declara permisos + destructividad con precisión, y añádela a `constants/tools.ts` si los subagentes deben verla.
-- **Slash-command:** vive en `commands/<nombre>/`, tipo `prompt` | `local` | `local-jsx`. Mantén `COMMANDS` como función memoizada — no la conviertas en array top-level.
+Se paga en soles desde Perú con tarjeta peruana. También hay una escalera en
+dólares con tarjeta internacional, con sus propios planes y cuotas —no es la misma
+tabla convertida—. Detalle y comparativa: <https://theus.pe/precios>
 
 ---
 
-## 🚢 Releases y distribución
-
-```bash
-bun run scripts/release.ts --tag vX.Y.Z    # genera dist/release/* + SHA256SUMS
-bun run release:native --tag vX.Y.Z        # candidatos nativos + manifiesto
-bun run release:msix -- --help              # paquete Windows para Partner Center
-```
-
-El workflow `release.yml` publica todos los canales al empujar el tag: GitHub Releases, `theus.pe/dl` y npm. En npm rige el **modelo stub + binarios**: `theus-cli` es un lanzador Node mínimo y el producto viaja compilado (y minificado) en 5 paquetes de plataforma generados por `scripts/package-npm.ts` — a npm no sale ni `cli.js` legible ni el arsenal dentro del stub. El `package.json` del repo es `private: true` a propósito: **nunca** publiques con `npm publish` desde la raíz.
-
-El release canónico sigue siendo el bundle firmado por checksum que usa el
-instalador oficial. `release:native` produce ejecutables autónomos para macOS
-ARM64/x64, Linux ARM64/x64 y Windows x64, valida su formato y genera
-`SHA256SUMS` + `RELEASE-MANIFEST.json`. Esos binarios nacen con
-`publishable:false`: antes de publicarlos deben completarse sus gates de
-distribución. macOS se firma/notariza y repite los smokes en runners nativos.
-Windows repite los smokes sobre el PE real y se empaqueta como MSIX; Microsoft
-Store firma ese paquete durante la certificación. El `.exe` sin firma no se
-publica como descarga estable.
-
-El workflow de release prepara `theus-cli-vX.Y.Z.tar.gz`,
-`theus-cli.tar.gz`, los cuatro tarballs Unix y un MSIX Windows privado para
-Partner Center. GitHub queda en borrador hasta que Microsoft certifique/firme
-el MSIX; sólo entonces se coordinan GitHub, npm y `theus.pe/dl`. Si falta una
-firma, notarización, identidad Store o smoke nativo, no crea una publicación
-pública.
-
-La suite completa, el typecheck y el bundle portable se validan una vez en el
-gate canónico de Linux. Los cuatro targets Unix compilan y ejecutan su binario
-en el runner nativo. Windows x64 baseline se compila con el mismo Bun fijado
-desde Linux y el PE resultante se transfiere al runner Windows, donde ejecuta
-`--version`, `--help` y `fleet-worker --help` antes de empaquetarse como MSIX.
-Así no se omite ninguna prueba y tampoco se fuerzan sobre Windows pruebas
-internas que validan permisos POSIX o scripts de shell.
-
----
-
-## 📖 Docs adicionales del subproyecto
-
-- `AGENTS.md` — reglas de trabajo para agentes.
-- `THEUS.md` — manual de producto/operaciones.
-- `THEUS_SOURCE_NOTES.md` — internals de runtime/build.
+## Soporte
 
-## Principios de producto
+- Novedades de cada versión: `theus` → `/novedades`, o <https://theus.pe/novedades>
+- Diagnóstico de tu instalación: `theus doctor`
+- Escríbenos: **contacto@theus.pe**
 
-- Local-first por defecto; cada usuario controla su modelo y su llave.
-- Cero marca externa en el copy visible (excepto el catálogo de modelos).
-- Identidad Theus coherente: `theus`, `.theus`, `THEUS_*`, `theus.pe`.
-- El dashboard **explica** el proyecto, no solo dibuja puntos.
-- Las funciones incompletas se nombran como deuda técnica, no como promesa terminada.
+Theus es software propietario. Licencia en el archivo `LICENSE` del paquete.

package/RELEASE.json

@@ -1,18 +1,18 @@
 {
   "schema": "theus.native-release.v1",
   "product": "Theus",
-  "version": "1.1.0",
-  "tag": "v1.1.0",
+  "version": "1.2.0",
+  "tag": "v1.2.0",
   "target": "linux-x64",
   "compile_target": "bun-linux-x64-baseline",
-  "commit": "813e46b425c3f7b35cb35c6e24479b329875781a",
+  "commit": "c63942c0ff2c454a7aa7fd19d992cd3986b31d97",
   "bun_version": "1.3.6",
-  "executable_sha256": "6692d085aa1d5233e8debc9c71ffcd2baf4202a43544aaf0a23045db424ffe7f",
-  "executable_bytes": 109217166,
+  "executable_sha256": "2c848b24bde6b72beb090efef381deaba206836a1598da1195a446fef69bb548",
+  "executable_bytes": 109247329,
   "format_verified": true,
   "native_smoke": true,
   "signed": null,
   "notarized": null,
   "publishable": true,
-  "finalized_at": "2026-08-18T06:50:33.666Z"
+  "finalized_at": "2026-08-22T00:13:27.421Z"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "theus-cli-linux-x64",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Binario nativo de Theus CLI para linux-x64. No se instala directamente: es una dependencia de theus-cli.",
   "os": [
     "linux"
@@ -10,9 +10,9 @@
   ],
   "preferUnplugged": true,
   "license": "SEE LICENSE IN LICENSE",
-  "author": "Mariano Suquilanda Gallo <contacto.tonyjaxx@gmail.com>",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/MarketrixPE/theuscode.git"
+  "author": "Marketrix SAC <contacto@theus.pe>",
+  "homepage": "https://theus.pe",
+  "bugs": {
+    "email": "contacto@theus.pe"
   }
 }