@iaforged/context-code 1.0.85 → 1.0.86

package/docs/PHASE_4_RISKS_AND_TESTS.md

@@ -0,0 +1,182 @@
+# 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/RECOVERY_NOTES.md

@@ -0,0 +1,78 @@
+# 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

@@ -0,0 +1,25 @@
+# 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

@@ -0,0 +1,27 @@
+## 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.