chore: auto-commit (799 archivos)
- .claude/CLAUDE.md - .claude/commands/subagentes.md - .claude/rules/INDEX.md - .mcp.json - bash/functions/cybersecurity/analyze_dns.md - bash/functions/cybersecurity/audit_http_headers.md - bash/functions/cybersecurity/audit_ssh_config.md - bash/functions/cybersecurity/check_firewall.md - bash/functions/cybersecurity/detect_suspicious_users.md - bash/functions/cybersecurity/encrypt_file.md - ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,121 @@
|
||||
# /autonomous-task — Lanza fn-orquestador (Fase 6 del ciclo reactivo)
|
||||
|
||||
Lanza el meta-orquestador autonomo que recorre el bucle CONSTRUIR → EJECUTAR → RECOPILAR → ANALIZAR → MEJORAR sobre un issue, sin intervencion humana, hasta convergencia / estancamiento / timeout / limite de iteraciones.
|
||||
|
||||
Issue 0069. Pre-condiciones obligatorias (chequear ANTES de despachar):
|
||||
|
||||
1. Migration `fn_operations/migrations/006_task_runs.sql` aplicada.
|
||||
2. Subagentes `fn-constructor`, `fn-executor`, `fn-recopilador`, `fn-analizador`, `fn-mejorador`, `fn-orquestador` presentes en `.claude/agents/`.
|
||||
3. `dev/autonomous_protected_paths.json` existe.
|
||||
4. `master` local up-to-date con `origin/master`.
|
||||
5. Branch `auto/<issue_id>` NO existe ya.
|
||||
6. `gh auth status` OK (necesario para PR draft al converger).
|
||||
7. Tipo de tarea soportado: `feature_app_simple`, `bugfix_with_repro`, `refactor_safe`, `add_e2e_check`.
|
||||
|
||||
Si alguna pre-condicion falla → ABORT con razon. NO improvisar.
|
||||
|
||||
---
|
||||
|
||||
## Argumento
|
||||
|
||||
`$ARGUMENTS` — `<issue_id>` o `<task_spec_path>` + flags opcionales.
|
||||
|
||||
```
|
||||
/autonomous-task 0070
|
||||
/autonomous-task 0070 --max-iterations 15 --max-minutes 90
|
||||
/autonomous-task 0070 --auto-apply-proposals safe
|
||||
/autonomous-task 0070 --dry-run
|
||||
/autonomous-task path/to/spec.yaml --branch auto/custom-name
|
||||
```
|
||||
|
||||
Flags:
|
||||
- `--max-iterations N` tope de iteraciones (default 10)
|
||||
- `--max-minutes M` timeout total (default 60)
|
||||
- `--auto-apply-proposals` `none|safe|aggressive` (default `safe`)
|
||||
- `--branch NAME` rama TBD (default `auto/<issue_id>`)
|
||||
- `--dry-run` simula, NO aplica
|
||||
|
||||
---
|
||||
|
||||
## Comportamiento
|
||||
|
||||
1. **Verificar pre-condiciones** con script bash (ver arriba). Si alguna falla, reportar y salir.
|
||||
2. **Despachar a `fn-orquestador`** via Agent tool con `subagent_type=fn-orquestador`. Pasar:
|
||||
- `issue_id` o `task_spec`
|
||||
- flags resueltos
|
||||
- paths protegidos (leidos de `dev/autonomous_protected_paths.json`)
|
||||
3. **El subagente:**
|
||||
- Crea worktree aislado `/tmp/fn_orq_<issue>_<ts>/` desde `master`.
|
||||
- Persiste estado en `task_runs` (operations.db del app target o repo root).
|
||||
- Despacha por fases a los 5 subagentes especializados.
|
||||
- Aplica proposals filtradas por `--auto-apply-proposals`.
|
||||
- Termina con: `converged` (PR draft creado) | `stalled` | `timeout` | `iterations_exhausted` | `needs_human` | `aborted`.
|
||||
4. **Reportar resultado al humano** con:
|
||||
- `status`, `iterations / max`, `duration / max`
|
||||
- `branch`, `worktree`, `PR draft url` si converged
|
||||
- `proposals creadas / aplicadas`
|
||||
- `last run_id` y status
|
||||
- Resumen iter-por-iter del `progress_json`
|
||||
|
||||
---
|
||||
|
||||
## Reglas duras (no negociables)
|
||||
|
||||
- Sandbox de rama EN WORKTREE — nunca toca master ni el working tree del humano.
|
||||
- No merge automatico — PR draft siempre.
|
||||
- No `--no-verify`, no `--force`, no skip hooks.
|
||||
- Paths protegidos via `dev/autonomous_protected_paths.json`.
|
||||
- Watchdog: 2 iteraciones con mismo set de fails → `status=stalled`.
|
||||
- Auditoria total en `task_runs.progress_json`.
|
||||
- No self-modification: NO toca `.claude/agents/` ni `.claude/commands/`.
|
||||
|
||||
---
|
||||
|
||||
## Integracion con call_monitor (issue 0085)
|
||||
|
||||
El orquestador puede leer `projects/fn_monitoring/apps/call_monitor/operations.db` para:
|
||||
|
||||
- Consultar `function_stats` antes de decidir que funciones usar/reusar.
|
||||
- Filtrar proposals existentes via `mcp__registry__fn_proposal --status pending` para evitar duplicados.
|
||||
- Loggear sus invocaciones via el hook PostToolUse (automatico).
|
||||
|
||||
Tras converger, el `call_monitor propose` ejecutado por el humano (o futuro cron) absorbera las nuevas violations / copied_code / fails para alimentar la siguiente ronda.
|
||||
|
||||
---
|
||||
|
||||
## Tipos NO soportados
|
||||
|
||||
- Diseño arquitectura nuevo (humano decide).
|
||||
- Decisiones UX subjetivas.
|
||||
- Cambios BD productiva.
|
||||
- Cualquier cosa que toque secrets/credenciales.
|
||||
- Self-modification del propio orquestador.
|
||||
|
||||
Si el issue contiene criterios no-verificables programaticamente, ABORT con `status=needs_human`.
|
||||
|
||||
---
|
||||
|
||||
## Output canonico
|
||||
|
||||
```
|
||||
=== /autonomous-task: 0070 ===
|
||||
status: converged
|
||||
iterations: 7 / 10
|
||||
duration: 23 min / 60
|
||||
branch: auto/0070
|
||||
worktree: /tmp/fn_orq_0070_1731612345
|
||||
PR draft: https://github.com/.../pull/123
|
||||
proposals: 3 creadas, 2 auto-aplicadas
|
||||
last run_id: e2e_run_abc123 (status: pass)
|
||||
|
||||
Iter:
|
||||
1. construir → ok (2 funciones nuevas)
|
||||
2. ejecutar → ok
|
||||
3. analizar → fail (2/8 checks)
|
||||
4. mejorar → 3 proposals (2 auto-applicadas)
|
||||
5. construir → ok (re-build tras patches)
|
||||
6. analizar → pass
|
||||
7. recopilador → ok (operations.db integra)
|
||||
|
||||
Siguiente: revisar PR draft + fn proposal list -s pending --target-id 0070
|
||||
```
|
||||
@@ -0,0 +1,191 @@
|
||||
---
|
||||
description: "Auto-auditoria: verifica que la sesion registra uso de funciones, detecta gaps (patrones inline repetidos, wrappers saltados, heredocs sin function_id), lanza fn-constructor en paralelo para crear las funciones que faltan, y valida que Claude usara las nuevas en el siguiente turno"
|
||||
---
|
||||
|
||||
# /fn_claude — auto-auditoria + auto-construccion del registry
|
||||
|
||||
Comando meta: Claude se audita a si mismo. Verifica que su comportamiento en esta sesion (y las recientes) deja rastro en `call_monitor.operations.db`, detecta gaps reales del registry para el trabajo actual, lanza sub-agentes `fn-constructor` en paralelo para cerrar esos gaps, y verifica que la proxima vez usara las funciones nuevas.
|
||||
|
||||
Issue 0085 fase autocompleta. Reemplaza el flujo manual de "veo un patron, decido si extraer, escribo proposal, espero humano, fn-mejorador genera, fn-orquestador opera". Con `/fn_claude` Claude hace todo eso solo, **autonomamente para si mismo**.
|
||||
|
||||
---
|
||||
|
||||
## Comportamiento (ejecutalo en este orden)
|
||||
|
||||
### 1. AUDIT — ¿estoy siendo registrado?
|
||||
|
||||
```bash
|
||||
ROOT="/home/lucas/fn_registry"
|
||||
MON="$ROOT/projects/fn_monitoring/apps/call_monitor/operations.db"
|
||||
|
||||
# Pre-condiciones
|
||||
[ -f "$MON" ] || { echo "call_monitor.operations.db NO existe — issue 0085a no aplicado"; exit 1; }
|
||||
[ "$FN_TELEMETRY" = "1" ] || echo "WARNING: FN_TELEMETRY != 1 — wrappers Python/Bash inactivos"
|
||||
|
||||
# Metricas de la sesion actual + ultimas 24h
|
||||
sqlite3 "$MON" <<SQL
|
||||
SELECT 'calls_session', COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}'
|
||||
UNION ALL SELECT 'calls_24h', COUNT(*) FROM calls WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER)
|
||||
UNION ALL SELECT 'violations_24h', COUNT(*) FROM violations WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER)
|
||||
UNION ALL SELECT 'tool_used_distribution_24h', NULL;
|
||||
SELECT tool_used, COUNT(*) FROM calls WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER) GROUP BY tool_used ORDER BY 2 DESC;
|
||||
SQL
|
||||
```
|
||||
|
||||
Si `calls_session = 0` → algo esta mal (hook PostToolUse no fire o BD no escribible). Reporta y para.
|
||||
|
||||
Si `mcp_*` / total < 0.4 → estas usando demasiado heredoc/sqlite directo. Reporta como warning.
|
||||
|
||||
### 2. GAP — ¿que funciones faltan?
|
||||
|
||||
Dos fuentes:
|
||||
|
||||
#### 2a. Patrones repetidos en heredocs/Edit
|
||||
|
||||
```sql
|
||||
-- En call_monitor.operations.db
|
||||
SELECT tool_used, COUNT(*) AS hits
|
||||
FROM calls
|
||||
WHERE function_id = ''
|
||||
AND ts >= CAST(strftime('%s','now','-7 days') AS INTEGER)
|
||||
AND tool_used IN ('heredoc_py', 'heredoc_bash', 'sqlite_direct')
|
||||
GROUP BY tool_used;
|
||||
```
|
||||
|
||||
Si `heredoc_py > 5` sin function_id → Claude esta componiendo logica que probablemente debe ser pipeline. Investigar el ultimo heredoc del transcript: si reescribe algo que ya es funcion del registry → violation candidate. Si no, es candidato a pipeline nuevo.
|
||||
|
||||
#### 2b. Trabajo actual de la sesion — gap inferido del contexto
|
||||
|
||||
Lee el ultimo prompt del usuario y los ultimos 10 turnos. Lista funciones que:
|
||||
|
||||
- Has llamado inline (sed/awk/jq custom, transformaciones de datos, parsing).
|
||||
- Has reinventado (HTTP client raw, SQLite open con flags, FS walks).
|
||||
- Has compuesto >2 veces con el mismo shape.
|
||||
|
||||
Para cada candidato:
|
||||
|
||||
```bash
|
||||
# Verifica si ya existe algo similar en el registry
|
||||
mcp__registry__fn_search "<keyword del candidato>"
|
||||
```
|
||||
|
||||
Si NO existe match relevante → candidato a `fn-constructor`.
|
||||
Si existe pero firma incompleta → candidato a `improve_function` (proposal, NO auto-construccion).
|
||||
|
||||
### 3. PROPOSE — lista candidatos
|
||||
|
||||
Genera tabla:
|
||||
|
||||
```
|
||||
| Candidato | Razon | Lenguaje | Dominio | Evidencia (snippet) |
|
||||
|---|---|---|---|---|
|
||||
| <name> | inline_repeated/wrapper_skip/new | go/py/bash | core/infra/... | <heredoc fragment> |
|
||||
```
|
||||
|
||||
Si lista vacia → "no gaps detected, sesion saludable" + reporta metricas. Para.
|
||||
|
||||
### 4. CONSTRUCT — lanza fn-constructor en paralelo
|
||||
|
||||
Para cada candidato, dispara un sub-agente `fn-constructor` con prompt autocontenido:
|
||||
|
||||
```
|
||||
Agent(subagent_type="fn-constructor", prompt=...)
|
||||
```
|
||||
|
||||
Prompts en PARALELO en un mismo mensaje (varios Agent calls). Pasar:
|
||||
- nombre propuesto, lang, domain
|
||||
- firma esperada (params + return)
|
||||
- pureza
|
||||
- descripcion + ejemplo de uso (heredoc real detectado)
|
||||
- nota: "esta funcion la necesita Claude para auto-uso futuro"
|
||||
|
||||
### 5. VALIDATE — ¿la proxima sesion la usara?
|
||||
|
||||
Despues de que fn-constructor termine:
|
||||
|
||||
```bash
|
||||
./fn index 2>&1 | tail -2
|
||||
# Verifica que las nuevas funciones existen
|
||||
for fn in <lista>; do
|
||||
mcp__registry__fn_show "$fn" >/dev/null && echo "OK: $fn" || echo "FAIL: $fn"
|
||||
done
|
||||
```
|
||||
|
||||
Tambien actualiza `call_monitor.copied_code` + `function_stats` corriendo:
|
||||
|
||||
```bash
|
||||
cd "$ROOT/projects/fn_monitoring/apps/call_monitor" && ./call_monitor copied-code && ./call_monitor propose
|
||||
```
|
||||
|
||||
Reporta:
|
||||
- N funciones nuevas creadas (con IDs)
|
||||
- N proposals nuevas en `registry.db.proposals`
|
||||
- Recomendacion al usuario: "proximo turno mencionar/usar `<fn_id>` para validar que el wrapper se invoca correctamente"
|
||||
|
||||
### 6. SELF-TEST — telemetria del propio /fn_claude
|
||||
|
||||
`/fn_claude` mismo debe quedar registrado. Tras ejecutar, query final:
|
||||
|
||||
```bash
|
||||
sqlite3 "$MON" "SELECT COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}' AND ts >= <inicio_comando>"
|
||||
```
|
||||
|
||||
Si la cuenta no aumento → el comando esta operando fuera de la telemetria (bug). Reportar.
|
||||
|
||||
---
|
||||
|
||||
## Reglas duras
|
||||
|
||||
1. **NO ejecutar fn-constructor para algo que ya existe.** Buscar primero via `mcp__registry__fn_search`. Si match relevante → NO crear duplicado.
|
||||
2. **NO crear funciones especulativas.** Cada candidato debe tener evidencia real (snippet de heredoc o llamada inline detectada en esta sesion o en `call_monitor.calls` reciente).
|
||||
3. **PARALELO**: si hay >1 candidato, lanza todos los `fn-constructor` en un solo mensaje con multiples `Agent` calls. NO secuencial.
|
||||
4. **No autonomous merge**: las funciones nuevas viven en el branch local. NO push automatico. Humano revisa y push manual.
|
||||
5. **Limites duros**: max 5 funciones nuevas por invocacion. Si detectas mas, prioriza por evidence weight (`occurrences * recency`) y reporta el resto como pending.
|
||||
6. **Si la sesion no esta siendo registrada (`calls_session = 0`)**: ABORT antes de fase 2. No tiene sentido auto-construir sin telemetria.
|
||||
|
||||
---
|
||||
|
||||
## Output canonico
|
||||
|
||||
```
|
||||
=== /fn_claude — auto-auditoria ===
|
||||
session_id: <id>
|
||||
calls_session: N
|
||||
calls_24h: M (mcp_ratio: 0.XX)
|
||||
violations_24h: K
|
||||
pending_proposals: P (existentes en registry.db)
|
||||
|
||||
GAPS DETECTADOS:
|
||||
1. <name>_<lang>_<domain> — razon — evidencia
|
||||
2. ...
|
||||
|
||||
LANZADOS (en paralelo):
|
||||
fn-constructor #1: <name1> → en progreso
|
||||
fn-constructor #2: <name2> → en progreso
|
||||
...
|
||||
|
||||
VALIDADAS tras ./fn index:
|
||||
✓ <name1>_<lang>_<domain>
|
||||
✓ <name2>_<lang>_<domain>
|
||||
|
||||
PROPOSALS NUEVAS: <count>
|
||||
|
||||
PROXIMO TURNO: menciona `<name1>` para validar wrapper.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cuando usar
|
||||
|
||||
- Al inicio de una sesion larga, para verificar telemetria activa.
|
||||
- A media sesion, cuando notes que estas reescribiendo el mismo bloque.
|
||||
- Antes de cerrar sesion, para capitalizar lo aprendido como funciones reutilizables.
|
||||
- Tras `/autonomous-task` para validar que el orquestador no genero ruido (proposals/funciones huerfanas).
|
||||
|
||||
---
|
||||
|
||||
## Cuando NO usar
|
||||
|
||||
- En sesiones cortas (<5 turnos) — no hay datos suficientes.
|
||||
- Si `call_monitor.operations.db` no esta inicializado (`call_monitor init` primero).
|
||||
- Si el usuario quiere control manual del proceso de extraccion. Este comando es agresivo.
|
||||
@@ -77,4 +77,21 @@ Input: <paths absolutos, IDs registry, run_id si aplica>
|
||||
Tarea: <accion concreta y acotada>
|
||||
Criterio exito: <como sabe que termino>
|
||||
Limites: <que NO debe tocar>
|
||||
Telemetria: tus tool calls quedan registradas en projects/fn_monitoring/apps/call_monitor/operations.db
|
||||
via hook PostToolUse heredado de settings.local.json. Sigue patrones canonicos
|
||||
(mcp__registry__fn_*, ./fn run, heredoc importando) — los antipatrones se loguean
|
||||
como violations.
|
||||
```
|
||||
|
||||
## Telemetria heredada (issue 0085 hardening 5)
|
||||
|
||||
Los hooks de `.claude/settings.local.json` se heredan automaticamente por cada sub-agente que Claude Code lance via la tool `Agent`. Eso significa:
|
||||
|
||||
- Cada Bash, Edit, Write, MultiEdit, `mcp__registry__*` del sub-agente dispara `hook_call_monitor.sh` exactamente igual que en la sesion principal.
|
||||
- El `session_id` del JSON de input del hook viene del sub-agente, distinto al de la sesion padre. Util para auditar comportamiento por agente.
|
||||
- Las violations detectadas (sqlite3 directo, heredoc reinventando, etc) cuentan tambien para sub-agentes — un `fn-constructor` que reescribe inline en lugar de delegar a otro `fn-constructor` queda registrado.
|
||||
- `FN_TELEMETRY=1` esta en el `env` block de settings.local.json — los heredocs Python/Bash de sub-agentes ya tienen wrappers activos automaticamente.
|
||||
|
||||
Implicacion: NO necesitas pasar flags `--telemetry` a sub-agentes. Solo asegurate de que el prompt sigue patrones canonicos. La regla `.claude/rules/registry_calls.md` se aplica igual.
|
||||
|
||||
Si un sub-agente abre un proceso hijo que escapa al hook (ej. `nohup ... &`, daemons), ese subproceso queda fuera de la telemetria — documentalo en el prompt si es un caso valido.
|
||||
|
||||
Reference in New Issue
Block a user