Volver a la wiki

Auditoría Suprema · Plan y método (reutilizable)

Qué es esta página: el plan y el método de la iniciativa “Auditoría Suprema” — el cómo, reutilizable cada vez que decidamos volver a pasarla. Solo métodos, no resultados. Los hallazgos por dominio viven en otro sitio (ver § “Dónde viven los resultados”). Esta página se edita cuando evoluciona el método; nunca se le añaden hallazgos.

Objetivo

Auditoría exhaustiva, sin concesiones de calidad, de todo el código de CreaRack-Pro (fase 1) y del Workspace (fase 2) → de ahí sale un plan de refactor · pulido · huecos · evolución “de nivel Supremo”. Es multi-sesión. Modo Effort Ultracode + Workflows, pero opt-in por tarea (no /effort ultracode global — se lanza workflow donde aporta, para controlar crédito).

Principio rector

Presupuesto de sesión y troceado (no agotar el crédito)

El sistema clave para que la iniciativa no se coma el crédito de golpe — es lo que hace la auditoría sostenible a lo largo de muchas sesiones:

  1. Estimar LOC ANTES de lanzar: git ls-files '<app>/*.py' | xargs wc -l. Un dominio entero suele ser demasiado para una sola corrida.
  2. > ~10k LOC → trocear en sub-áreas, y auditar una sub-área por sesión (~1-1.5M tokens cada una). Ej.: monitoring (16.7k LOC) se partió en 6 sub-áreas, 1/sesión.
  3. 1 workflow sustantivo por sesión. El resto de la sesión, trabajo rutinario (fixes, docs, revisión). No encadenar varios workflows pesados el mismo día.
  4. Opt-in por tarea, NO /effort ultracode global: se lanza un workflow donde aporta, no para cada tarea (eso multiplicaría el gasto).
  5. Lo caro es VERIFICAR (N hallazgos × lentes de verificación), no los finders. Por eso el dedup —que recorta hallazgos duplicados antes de verificarlos— ahorra coste real.
  6. Si un run se corta (crédito, timeout): resume desde runId reaprovecha los finders ya cacheados, no se re-paga lo hecho.
  7. Probar en un slice pequeño primero para calibrar coste antes de comprometer un dominio grande.

Las 7 dimensiones de auditoría

Las 4 de Edu + 3 técnicas:

  1. Bugs / correctness
  2. Seguridad + aislamiento multi-tenant
  3. Rendimiento
  4. Limpieza / optimización
  5. Pulido de lo existente
  6. Huecos / lo que falta
  7. Evolución creativa (no humo)

El motor — comando /audit-subarea

Workflow reutilizable (.claude/workflows/audit-subarea.js, s107) parametrizado por args. Patrón:

finders por slice  →  dedup por grupos de índices  →  verificación adversarial escalonada

Contrato de hallazgo (schema común): title · dimension · severity(ALTA/MEDIA/BAJA) · file · line · evidence · proposal · effort(S/M/L) · risk · already_known.

Invocación:

Workflow({name:"audit-subarea", args:{
  domain:"monitoring",
  subarea:"sa3-cns-ia",
  scope:"<descripción del dominio + contexto YA conocido a NO re-reportar + ficheros a EXCLUIR>",
  slices:[ {key,label,detail}, ... ],
  dimensions_text:"<opcional, override>",
  cap: 60
}})

Las 4 etapas de la iniciativa

Reglas de calibración (vivas — actualizar aquí cuando aprendamos algo)

El presupuesto/troceado de coste vive en su propia sección arriba. Aquí, la calidad del motor.

Alcance completo

Fase 1 · CreaRack-Pro

core · racks · blueprints/Auto-Plan · monitoring/CNS (16.7k LOC → 6 sub-áreas: ① targets+métricas+ingesta · ② protocolos/probes SNMP·ping·HTTP · ③ CNS/Insights/IA · ④ ITSM/alerting · ⑤ wireless+UPS · ⑥ views/realtime) · network/discovery · signage · terminal/agent · config/IA · frontend.

Excluir monitoring/api/signage/* del dominio monitoring → se audita con signage.

Fase 2 · Workspace (CreaRackSL-workspace)

app Astro/CF Pages · MCP (tools bib_*/wiki_*) · grafo de conocimiento · RAG/Oráculo · wiki · D1 · integraciones (Zoho, Holded, GitHub) · ingest/crons del Bibliotecario.

Cómo re-ejecutar en el futuro (receta)

  1. Leer esta página (método) + el doc maestro de estado (resultados/progreso).
  2. Elegir dominio/sub-área. Estimar LOC; trocear si > ~10k.
  3. Definir 2-6 slices (ficheros + foco) y el scope (contexto conocido + exclusiones).
  4. Workflow({name:"audit-subarea", args:{...}}) — 1 por sesión.
  5. Revisar confirmados → decidir scope de arreglo con Edu → PR + tests + Vigía (CI) + dual doc (Regla 27).
  6. Volcar resultados al doc maestro de estado + crear la feature--<dominio>--auditoria-* correspondiente.

Dónde viven los RESULTADOS (no aquí)

Esta página no lleva hallazgos: si alguien añade resultados aquí, muévelos al doc maestro y déjala solo con método.

Véase también

Subir