K-Forge / K-Forge/Beetle

Falta el punto de entrada del agente (doctorjk/main.py) y no tiene dueño

Open
#222 2 comments 0 reactions 1 assignee Claimed by @MauItu View on GitHub
Dominant language
Shell
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Description

## El problema

`doctorjk/main.py` es el punto de entrada del agente. **No tiene tarea asignada y nadie lo está construyendo**, pero cuatro cosas lo dan por hecho.

## Por qué se coló

No es que se olvidara asignarlo: **el documento de proyecto nunca lo definió**. La estructura de módulos de la §8.4 pasa de `__init__.py` directo a `monitor.py`, sin punto de entrada.

Quienes sí lo mencionan son documentos derivados, que lo agregaron después como necesidad evidente:

| Dónde | Qué dice |
|---|---|
| `CONTEXTO-IA.md` | *Punto de entrada — arrancar el agente y parsear `--dry-run` / `--auto-fix`* |
| `doctorjk/README.md` | Lo lista en la estructura y en la tabla de responsabilidades (§14.5) |
| Tarea #196 | `ExecStart=/usr/bin/python3 /opt/doctorjk/main.py` |

Como nunca estuvo en el documento maestro, nunca bajó a las tareas.

## Qué está bloqueando

- **#172 (trigger)** — el script detecta en 0,51 s y dispara correctamente, pero solo contra un stub. No hay agente que lanzar.
- **#171 (monitor)** — necesita un proceso que lo arranque para correr como servicio, no solo un script suelto.
- **#196 (unit systemd)** — su `ExecStart` apunta a un archivo que no existe.
- **#209 y #210** — implementan los flags `--dry-run` y `--auto-fix`, pero nadie crea la CLI que los parsea.

## Qué tendría que hacer

- Parsear `--dry-run` y `--auto-fix` (las salvaguardas 2 y 3 del Modo 3)
- Cargar la configuración vía `config.py`
- Arrancar el monitor y dejarlo en su ciclo
- Ofrecer una vía de invocación puntual, para que el trigger pueda decir "revisa ahora" sin arrancar un segundo monitor

## Una decisión de diseño que conviene fijar aquí

El trigger **no debe declarar un incidente**, solo despertar al pipeline para que recolecte y evalúe. Quien decide sigue siendo `detector.py`, por persistencia.

Si el punto de entrada expone algo que el trigger pueda llamar y que corrija directo, bastaría un warning suelto para que el agente actúe sobre el servidor — y eso rompe la decisión cerrada de detectar por persistencia y nunca por umbral instantáneo.

## Qué hay que decidir

@MauItu esto los afecta a los tres, así que lo dejo abierto en vez de asumirlo:

1. ¿Va como tarea nueva de Fase 1, o se mete en Fase 2 junto al detector?
2. ¿Quién lo toma?
3. ¿Se corrige la §8.4 del documento de proyecto para que incluya el punto de entrada, o se deja como está y se documenta la diferencia?

Lo dejo sin label a propósito: la fase la deciden ustedes.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.