CreaRack-SL

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

Vista limpiaEditar
Conceptoactivecreado Thu Jun 04#staff-share#owner-edu#auditoria-suprema#metodo#workflow#seguridad

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

  • Profundidad máxima, línea a línea — incluido lo que un repaso rápido daría por bueno.
  • La fase de auditoría es solo lectura: no se toca código. Los arreglos vienen después, por decisión explícita de Edu.
  • 1 workflow sustantivo por sesión (prudencia de crédito). El resto de la sesión, trabajo rutinario.

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
  • Finders: 2-6 agentes en paralelo, uno por slice (un grupo de ficheros con foco concreto). Cada uno lee el código real y reporta hallazgos con el contrato común.
  • Dedup (barrier): un consolidador devuelve solo grupos de índices duplicados; la fusión se hace en código (try/catch que degrada a “sin dedup” si falla). No se le pide que devuelva hallazgos completos — eso lo atasca.
  • Verificación adversarial escalonada (su objetivo es REFUTAR cada hallazgo): ALTA = 3 lentes (precisión-de-código · impacto-real · novedad-validez), MEDIA = 2, BAJA = 1. Sobrevive con ≥ mayoría de votos is_real. Cap de seguridad con log de lo no verificado.

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

  • Etapa 0 · Calibración — alcance/profundidad/presupuesto, contrato de hallazgo, sembrar backlog con deudas ya conocidas, correr un piloto.
  • Etapa 1 · Auditoría — fan-out read-only dominio × sub-área con el motor de arriba. Solo sobreviven los confirmados.
  • Etapa 2 · Consolidación — dedup global, priorización (severidad × impacto-negocio × esfuerzo), Informe Supremo + backlog en tandas. Doc dual técnica+coloquial (Regla 27).
  • Etapa 3 · Ejecución por tandas — (1) seguridad ALTA · (2) limpieza/deuda · (3) pulido+huecos · (4) evolución. Cada fix: rama → PR → CI verde (vigilado por Vigía) → auto-merge, con tests y verificación.

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.

  • Dedup robusto = el consolidador devuelve grupos de índices + fusión en código (no hallazgos completos, que lo atascan).
  • Slices con foco: cada slice nombra sus ficheros y su foco concreto; el scope lista el contexto ya conocido (para no re-reportar lo de dominios anteriores) y las exclusiones.
  • Verificación escalonada por severidad (ALTA 3 / MEDIA 2 / BAJA 1 lentes) + cap con log de lo no verificado: concentra el esfuerzo donde más importa.
  • Tras auditar, decidir el arreglo (Regla 22, decide Edu por dominio): “todo de una vez” (ALTA + quick-wins en 1 PR; carve-outs perf-L/arquitectónicos a Etapa 3) o mini-tanda ALTA. Cada fix con tests + dual doc.

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í)

  • Doc maestro de estado + datos crudos: public/supercontext/auditoria-suprema/AUDITORIA_SUPREMA.md + *.{md,json} por dominio (repo workspace).
  • Páginas wiki por dominio: feature--<dominio>--auditoria-* (p. ej. [[feature—monitoring—auditoria-sa1-s106]], [[feature—monitoring—auditoria-sa2-s107]], [[feature—blueprints—auditoria-s105]]).

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

  • [[feature—monitoring—auditoria-sa1-s106]]
  • [[feature—monitoring—auditoria-sa2-s107]]
  • [[feature—blueprints—auditoria-s105]]
  • [[concept—onboarding—mapa-maestro-ecosistema-crearack]]

Referenciado desde

Inicio
Yo