npm - theus-cli-linux-arm64 - Versions diffs - 1.1.0 → 1.2.1 - Mend

theus-cli-linux-arm64 1.1.0 → 1.2.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (4) hide show

package/README.md CHANGED Viewed

@@ -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 190 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 CHANGED Viewed

@@ -1,18 +1,18 @@
 {
   "schema": "theus.native-release.v1",
   "product": "Theus",
-  "version": "1.1.0",
-  "tag": "v1.1.0",
+  "version": "1.2.1",
+  "tag": "v1.2.1",
   "target": "linux-arm64",
   "compile_target": "bun-linux-arm64",
-  "commit": "813e46b425c3f7b35cb35c6e24479b329875781a",
+  "commit": "c5c83beb9981856f92639afb1cffbc9b34cf0c95",
   "bun_version": "1.3.6",
-  "executable_sha256": "acfef1b4eb6b79e59b935d1da186360c789c111aa926b9d124bbec7e3ede8c72",
-  "executable_bytes": 103029727,
+  "executable_sha256": "3c931f129900cfc59954942b5d46ecd9bd721b0b3ae9d9101a8550a81b2a267a",
+  "executable_bytes": 103067883,
   "format_verified": true,
   "native_smoke": true,
   "signed": null,
   "notarized": null,
   "publishable": true,
-  "finalized_at": "2026-08-18T06:50:29.068Z"
+  "finalized_at": "2026-08-23T05:10:20.311Z"
 }

package/bin/theus CHANGED Viewed

Binary file

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "theus-cli-linux-arm64",
-  "version": "1.1.0",
+  "version": "1.2.1",
   "description": "Binario nativo de Theus CLI para linux-arm64. 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"
   }
 }