@iaforged/context-code 2.0.3 → 2.1.0

package/docs/PHASE_4_RISKS_AND_TESTS.md

@@ -1,182 +0,0 @@
-# Fase 4: autonomia, seleccion automatica y resiliencia
-
-Fase 4 debe convertir la orquestacion por dominio en un sistema capaz de elegir agentes, cambiar de proveedor cuando convenga y explicar por que tomo cada decision. La regla base es mantener a SQLite como fuente de verdad y no ejecutar automatismos silenciosos sin dejar evidencia en `orchestration_messages`.
-
-## Objetivo
-
-- Seleccionar automaticamente agentes por dominio usando capacidades, costo, latencia, calidad, disponibilidad y resiliencia.
-- Reasignar tareas cuando un agente, perfil o proveedor no pueda continuar.
-- Definir politicas de retry y fallback por tipo de error.
-- Registrar cada decision de seleccion y fallback para auditoria posterior.
-- Mantener comandos manuales para inspeccionar, aceptar o corregir decisiones automaticas.
-
-## Modelo de politica
-
-Fase 4 queda implementada como primer corte operativo con tipos en `src/services/orchestration/policy/types.ts` y scoring deterministico en `src/services/orchestration/policy/scoring.ts`.
-
-Conceptos principales:
-
-- `OrchestrationSelectionPolicy`: define modo de seleccion, objetivo de optimizacion, capabilities requeridas/preferidas, pesos y profundidad de fallback.
-- `OrchestrationFallbackPolicy`: define que hacer ante errores de auth, cuota, rate-limit, timeout, modelo no disponible, proveedor caido, tool error o validacion.
-- `OrchestrationAgentScoreBreakdown`: explica el puntaje de un candidato por capability, costo, latencia, calidad, disponibilidad y resiliencia.
-- `OrchestrationSelectionDecision`: registra el agente elegido, candidatos evaluados, fallback candidates y razon final.
-
-## Modos de seleccion
-
-- `manual`: usa exactamente el agente asignado en el team o dominio.
-- `score`: rankea candidatos dentro del dominio y elige el mejor disponible.
-- `score-with-fallback`: rankea candidatos y conserva alternativas para errores recuperables.
-- `fallback-only`: no cambia la seleccion inicial, pero puede reasignar cuando una tarea falla.
-
-## Objetivos de optimizacion
-
-- `balanced`: ponderacion equilibrada para trabajo general.
-- `cost`: prioriza proveedores o modelos baratos cuando las capabilities minimas se cumplen.
-- `latency`: prioriza respuesta rapida para tareas pequenas o iterativas.
-- `quality`: prioriza agentes de mayor calidad para arquitectura, revision o cambios riesgosos.
-- `capability`: prioriza especializacion declarada o inferida.
-- `resilience`: prioriza agentes con historial estable y fallback fuerte.
-
-## Scoring propuesto
-
-El puntaje total debe calcularse con pesos normalizados entre `0` y `1`.
-
-Formula inicial:
-
-```text
-total =
-  capabilityScore * capabilityWeight +
-  costScore * costWeight +
-  latencyScore * latencyWeight +
-  qualityScore * qualityWeight +
-  availabilityScore * availabilityWeight +
-  resilienceScore * resilienceWeight
-```
-
-Reglas:
-
-- Si falta una capability requerida, el candidato queda bloqueado aunque tenga buen puntaje.
-- Las capabilities preferidas suman puntaje, pero no bloquean.
-- Un workspace deshabilitado bloquea todos sus agentes.
-- Un agente deshabilitado no entra al ranking.
-- Un perfil sin credenciales validas puede aparecer como candidato bloqueado, pero no debe ejecutarse automaticamente.
-- Si dos candidatos empatan, gana el de mayor `qualityScore`; si persiste empate, gana el de menor costo estimado; si persiste, se ordena por nombre para mantener determinismo.
-
-## Fallback entre proveedores
-
-El fallback no debe tratar todos los errores igual.
-
-Politica recomendada:
-
-- `auth`: bloquear para intervencion humana; no reintentar con la misma credencial.
-- `quota`: intentar fallback a otro provider/profile si existe candidato compatible.
-- `rate-limit`: reintentar con backoff o mover a fallback si la tarea es urgente.
-- `timeout`: permitir retry limitado con el mismo agente y luego fallback.
-- `model-unavailable`: permitir cambio de modelo dentro del mismo perfil si la politica lo permite.
-- `provider-unavailable`: fallback a otro proveedor compatible.
-- `tool-error`: bloquear si la tarea requiere tool especifica; de lo contrario permitir fallback.
-- `validation`: no reintentar automaticamente; requiere ajuste del plan o instrucciones.
-- `unknown`: un retry controlado y luego bloqueo.
-
-Cada fallback debe escribir un mensaje con:
-
-- tarea afectada
-- error clasificado
-- agente original
-- agente nuevo, si aplica
-- razon de la decision
-- si hubo cambio de provider, profile o modelo
-
-## Comandos operativos
-
-Estos comandos ya operan sobre SQLite y registran decisiones auditables en `orchestration_messages` con prefijo `policy.*`.
-
-```sh
-/run optimize <run-id> [policy]
-/run assign <run-id> [policy]
-/run fallback <run-id> [task-id] [policy]
-/run retry <run-id> <task-id>
-/run reassign <task-id> <provider>/<agent>
-/run explain <run-id>
-/policy list
-/policy show <policy>
-```
-
-Comportamiento esperado:
-
-- `/run assign` aplica una politica de seleccion a tareas abiertas.
-- `/run optimize` propone cambios sin ejecutarlos.
-- `/run fallback` intenta reasignar tareas fallidas o bloqueadas con una politica vigente.
-- `/run retry` reintenta una tarea concreta respetando su clasificacion de error.
-- `/run reassign` fuerza una reasignacion manual.
-- `/run explain` muestra scoring, bloqueos y razones de seleccion.
-- `/policy` lista y muestra politicas predefinidas.
-
-Ejemplos:
-
-```sh
-/policy show score-with-fallback:quality
-/run optimize <run-id> score-with-fallback:quality
-/run assign <run-id> score:capability
-/run fallback <run-id> <task-id> score-with-fallback:resilience
-/run explain <run-id>
-```
-
-Quedan fuera de este primer corte:
-
-- persistencia editable de politicas personalizadas
-- `/policy create`
-- `/policy set-weights`
-- clasificacion automatica profunda de errores por provider mas alla del fallback manual/auditable
-
-## Riesgos principales
-
-- Seleccion automatica sin scoring claro: puede enviar dominios criticos a agentes rapidos pero debiles.
-- Fallback entre proveedores sin contexto: puede repetir el mismo fallo con otro proveedor y gastar tokens.
-- Reintentos agresivos: pueden duplicar cambios o saturar cuentas con cuota baja.
-- Conflictos entre escuadrones: frontend, backend y reviewer pueden producir salidas incompatibles.
-- Reportes demasiado resumidos: el orquestador global puede cerrar una corrida sin evidencia suficiente.
-- Capabilities desactualizadas: un agente puede declararse apto para un dominio que ya no soporta.
-- Credenciales por perfil: un agente valido puede fallar si su provider profile no tiene credenciales activas.
-- Scoring opaco: el usuario puede perder confianza si no entiende por que se eligio un proveedor.
-- Fallback cross-provider sin equivalencia de modelo: la salida puede cambiar de formato o calidad.
-- Costos no observados: una politica de calidad puede consumir cuota rapidamente.
-
-## Pruebas recomendadas
-
-- Ranking deterministico de agentes con mismas capacidades.
-- Preferencia por `requiredCapabilities` sobre `preferredCapabilities`.
-- Fallback cuando el agente principal esta deshabilitado.
-- Fallback cuando el workspace del agente esta deshabilitado.
-- Reasignacion de tareas `blocked` a otro miembro del dominio.
-- Politica de no retry para errores no recuperables de proveedor.
-- Consolidacion global con reportes mixtos: completados, bloqueados y fallidos.
-- Autocompletado de `team`, `domain`, `agent` y `run-id`.
-- Persistencia de metricas por dominio y agente.
-- Verificacion de que un run cancelado no se reejecute accidentalmente.
-- Explicacion completa de scoring para cada decision automatica.
-- Fallback de `quota` hacia otro proveedor compatible.
-- Bloqueo de `auth` sin retry automatico.
-- Retry limitado de `timeout` con conteo de intentos persistido.
-- Determinismo cuando dos agentes tienen el mismo score.
-- Validacion de pesos de politica para evitar totales incoherentes.
-
-## Gates para implementar Fase 4
-
-- `npm run build`
-- pruebas unitarias para scoring y fallback
-- harness de stores para mensajes `policy.*`
-- escenario manual con dos proveedores, dos dominios y un fallo forzado por cuota
-- escenario manual con timeout recuperable
-- revision de costos/cuotas antes de habilitar reintentos automaticos
-
-## Criterio de cierre
-
-Fase 4 solo debe considerarse cerrada cuando:
-
-- las decisiones automaticas sean explicables desde `/run explain`
-- el scoring sea deterministico
-- cada fallback quede persistido como mensaje auditable
-- los errores no recuperables no disparen retries agresivos
-- el usuario pueda forzar reasignacion manual
-- la documentacion de politicas y comandos coincida con el comportamiento real

package/docs/PUBLISH.md

@@ -1,199 +0,0 @@
-# Publicar Context Code en npmjs
-
-Guía completa de los caminos para publicar el paquete `@iaforged/context-code`.
-El paquete se publica al registry oficial de npmjs (`https://registry.npmjs.org/`)
-y puede subirse tanto con `pnpm` como con `npm`. El cliente que uses al publicar
-es independiente del cliente que usen los usuarios finales para instalarlo.
-
----
-
-## Antes de publicar — checks obligatorios
-
-```bash
-pnpm whoami                              # debe imprimir tu usuario de npmjs
-# o si vas a usar npm:
-npm whoami
-
-pnpm view @iaforged/context-code version # versión actual en el registry
-git status                               # cero cambios pendientes en main
-node --check cli.js                      # bundle de producción válido
-```
-
-Si no estás logueado:
-
-```bash
-pnpm login --registry=https://registry.npmjs.org/
-# o:
-npm login --registry=https://registry.npmjs.org/
-```
-
-Variables/flags que la pipeline interna necesita:
-
-- `AUTHORIZED=1` — obligatorio. El script `scripts/preflight-check.mjs` corre
-  como `prepublishOnly` y aborta si esa variable no está. Es la salvaguarda
-  contra publicaciones accidentales desde una terminal cualquiera.
-- `--access public` — el paquete es scoped (`@iaforged/...`); por defecto los
-  scoped son privados, hay que forzar público.
-- `--no-git-checks` (pnpm) — la pipeline modifica `package.json` durante la
-  publicación, así que `pnpm` no debe quejarse por árbol sucio.
-
----
-
-## Opción A — Pipeline completa (recomendado): `pnpm pubpackages`
-
-Es el flujo "todo en uno" que vive en `scripts/pubpackages.sh`:
-
-```bash
-pnpm pubpackages
-```
-
-Pasos que ejecuta:
-
-1. `pnpm build` — compila TypeScript a `dist/`.
-2. Bump de versión automático en `package.json` (1.3.5 → 1.3.6; al llegar a
-   x.x.9 salta a x.(y+1).0).
-3. Genera un `package.json` "limpio" para publicar (sin `devDependencies`, sin
-   `pnpm.*`, sin scripts de desarrollo). Mantiene una copia del original.
-4. `pnpm publish --access public --no-git-checks`.
-5. Restaura el `package.json` original (vía `trap EXIT`) aunque la publicación
-   falle.
-
-Equivalente con npm si prefieres no usar pnpm para publicar (mismo script,
-mismo flujo — pnpm solo orquesta el bash):
-
-```bash
-AUTHORIZED=1 bash ./scripts/pubpackages.sh
-```
-
-> El `pnpm` interno del script seguirá invocándose para `pnpm build` y
-> `pnpm publish`. Si quieres una versión 100% npm, copia el script y reemplaza
-> esas dos invocaciones por `npm run build` y `npm publish --access public`.
-
----
-
-## Opción B — Publicación manual desde PowerShell (Windows)
-
-`publish-package.ps1` está en la raíz del repo. No bumpea versión: publica
-exactamente lo que haya en `package.json`. Útil para reintentar una publicación
-que falló o para subir versiones beta/preview.
-
-```powershell
-.\publish-package.ps1                     # tag latest, access public
-.\publish-package.ps1 -Tag beta
-.\publish-package.ps1 -Tag rc -Access public
-```
-
-Lo que hace:
-
-1. Localiza `pnpm` en el PATH (o en rutas típicas de Windows: `nvm`, `npm` global, `Program Files\nodejs`).
-2. Pone `AUTHORIZED=1`.
-3. Corre `node --check cli.js` para validar el bundle.
-4. `pnpm publish --tag <tag> --access <access> --no-git-checks`.
-
----
-
-## Opción C — Una línea directa (cuando ya sabes qué quieres subir)
-
-Con pnpm:
-
-```bash
-pnpm build
-AUTHORIZED=1 pnpm publish --access public --no-git-checks
-```
-
-Con npm:
-
-```bash
-pnpm build                                # o npm run build si quieres todo npm
-AUTHORIZED=1 npm publish --access public
-```
-
-Variantes con tag distinto a `latest`:
-
-```bash
-AUTHORIZED=1 pnpm publish --access public --tag beta --no-git-checks
-AUTHORIZED=1 npm publish --access public --tag beta
-```
-
-> Nota: con `npm publish` no necesitas `--no-git-checks` — npm no valida árbol
-> de git, solo pnpm lo hace por defecto.
-
----
-
-## Diferencias prácticas pnpm vs npm al publicar
-
-| Aspecto | pnpm | npm |
-|---|---|---|
-| Lee `.npmrc` raíz | sí | sí |
-| Lee `pnpm-workspace.yaml#allowBuilds` | sí | no aplica (no bloquea install scripts) |
-| Valida árbol git por defecto | sí (necesita `--no-git-checks`) | no |
-| Respeta `prepublishOnly` script | sí | sí |
-| Respeta `publishConfig.registry` | sí | sí |
-| Archivos incluidos en el tar | igual (lee `files` de `package.json` y `.npmignore`) | igual |
-| Reduce el tamaño del tar | igual (ambos comprimen con `tar.gz`) | igual |
-| Velocidad real | parecida; pnpm hace una pasada más para validar el lockfile | parecida |
-
-El paquete resultante en el registry es **bit-by-bit idéntico** independiente
-del cliente que lo suba — los usuarios finales pueden instalar con `npm`,
-`pnpm`, `yarn` o `bun` sin diferencia.
-
----
-
-## Verificación post-publicación
-
-```bash
-pnpm view @iaforged/context-code version      # versión publicada
-pnpm view @iaforged/context-code dist-tags    # qué dist-tag apunta dónde
-
-# instalar la versión recién subida en una carpeta limpia para probar:
-mkdir /tmp/cc-test && cd /tmp/cc-test
-pnpm add @iaforged/context-code@latest
-./node_modules/.bin/context --version
-```
-
-Si publicaste con un tag distinto a `latest`:
-
-```bash
-pnpm add @iaforged/context-code@beta
-```
-
----
-
-## Si algo falla
-
-| Error | Causa típica | Cómo se arregla |
-|---|---|---|
-| `ENEEDAUTH` | no estás logueado | `pnpm login` o `npm login` |
-| `403 Forbidden` | el usuario no tiene permisos de publish en el scope | añade el usuario al scope `@iaforged` en npmjs.com |
-| `Cannot publish over previously published version` | la versión ya existe | bump de versión (manual o por `pubpackages`) |
-| `ERR_PNPM_GIT_UNCLEAN` | árbol sucio | `git stash` o `--no-git-checks` |
-| El preflight aborta sin publicar | falta `AUTHORIZED=1` | añadir la variable al entorno |
-| `tsc no se reconoce` durante prepublish | falta `typescript` en devDeps | `pnpm add -D typescript` (ya está en main) |
-
----
-
-## Política de versiones
-
-El bump automático del `pubpackages.sh` sigue una variante mínima:
-- `patch` incrementa cada release.
-- Al llegar a `patch === 9` salta a `minor + 1` y `patch = 0`.
-- Nunca toca `major`.
-
-Para bumpear manualmente (p. ej. una major):
-
-```bash
-node -e "const p=require('./package.json'); p.version='2.0.0'; require('fs').writeFileSync('package.json', JSON.stringify(p,null,2)+'\n')"
-AUTHORIZED=1 pnpm publish --access public --no-git-checks
-```
-
----
-
-## Despublicar / depreciar (no recomendado)
-
-npm bloquea unpublish después de 72h. Para marcar una versión como obsoleta:
-
-```bash
-npm deprecate @iaforged/context-code@1.3.5 "Usa 1.3.6 o superior"
-```
-
-Esto no quita el paquete del registry, solo añade un warning al instalar.

package/docs/RECOVERY_NOTES.md

@@ -1,78 +0,0 @@
-# Recovery Notes
-
-Recovered source files from `cli.js.map`.
-
-## Summary
-
-- Total entries in source map: 4756
-- Files written: 4756
-- Entries without inline content: 0
-- Main application files under `src/`: 1902
-- Dependency files under `node_modules/`: 2850
-- Native/vendor helper files under `vendor/`: 4
-- Other recovered paths: 0
-
-## Recommended Review Order
-
-1. `src/cli/`
-2. `src/commands/`
-3. `src/components/`
-4. `src/services/`
-5. `src/tools/`
-6. `src/utils/`
-
-## Top-Level `src/` Breakdown
-
-- utils: 564 files
-- components: 389 files
-- commands: 207 files
-- tools: 184 files
-- services: 130 files
-- hooks: 104 files
-- ink: 96 files
-- bridge: 31 files
-- constants: 21 files
-- skills: 20 files
-- cli: 19 files
-- keybindings: 14 files
-- tasks: 12 files
-- types: 11 files
-- migrations: 11 files
-- context: 9 files
-- entrypoints: 8 files
-- memdir: 8 files
-- state: 6 files
-- buddy: 6 files
-- vim: 5 files
-- native-ts: 4 files
-- query: 4 files
-- remote: 4 files
-- screens: 3 files
-- server: 3 files
-- plugins: 2 files
-- upstreamproxy: 2 files
-- bootstrap: 1 files
-- schemas: 1 files
-- Tool.ts: 1 files
-- ink.ts: 1 files
-- context.ts: 1 files
-- coordinator: 1 files
-- cost-tracker.ts: 1 files
-- tasks.ts: 1 files
-- voice: 1 files
-- tools.ts: 1 files
-- query.ts: 1 files
-- outputStyles: 1 files
-- projectOnboardingState.ts: 1 files
-- history.ts: 1 files
-- commands.ts: 1 files
-- Task.ts: 1 files
-- assistant: 1 files
-- moreright: 1 files
-- costHook.ts: 1 files
-- replLauncher.tsx: 1 files
-- interactiveHelpers.tsx: 1 files
-- dialogLaunchers.tsx: 1 files
-- setup.ts: 1 files
-- QueryEngine.ts: 1 files
-- main.tsx: 1 files

package/docs/RENAMING_NOTES.md

@@ -1,25 +0,0 @@
-# Context Code Renaming Notes
-
-This folder is a working copy created from recovered sources and the original bundle.
-
-What was changed:
-- Package name changed to `@context-ai/context-code`
-- CLI bin name changed from `claude` to `context`
-- README branding changed to `Context Code`
-- Executable launcher added: `context.cmd`
-- Visible bundle strings `Claude Code` were rebranded where possible
-
-What was not fully changed:
-- Internal identifiers, service integrations, telemetry, and some upstream references may still mention Claude or Anthropic
-- Source files under `src/` were left mostly intact to avoid breaking runtime behavior
-
-Recommended local run:
-
-```powershell
-.\context.cmd --help
-```
-
-Validation status:
-- `.\context.cmd --help` works
-- `.\context.cmd --version` works and reports `Context Code`
-- No complete build pipeline was recovered with the source map copy, so there is no guaranteed `build` script or `tsconfig`-driven compile step yet

package/docs/SKILLS.md

@@ -1,27 +0,0 @@
-## Skills de Context
-
-Context usa `.context/skills` como carpeta oficial de skills del proyecto y `~/.context/skills` como carpeta global de usuario.
-
-Formato:
-
-```text
-.context/skills/<nombre-skill>/SKILL.md
-```
-
-Comandos:
-
-```sh
-/skills
-/skills import
-/skills import .claude
-/skills import .codex
-/skills import .agents
-```
-
-Uso practico:
-
-- `/skills` lista las skills disponibles.
-- `/skills import` busca skills legacy en `.claude/skills`, `.codex/skills` y `.agents/skills`, y las copia a `.context/skills`.
-- `/skills import .claude` importa solo desde `.claude/skills`.
-- Las nuevas skills deben crearse en `.context/skills/<nombre>/SKILL.md`.
-- `CONTEXT_CONFIG_DIR` es la variable principal para cambiar la carpeta global; `CLAUDE_CONFIG_DIR` queda como fallback temporal de compatibilidad.