Mapa Maestro del Ecosistema CreaRack (Máster para agentes)

Qué es esto. Mapa mental único del ecosistema CreaRack pensado para que un Claude (o dev) nuevo coja el harness rápido: cómo encajan las piezas, los flujos transversales, las reglas operativas, los footguns más peligrosos y el ritual de sesión. Generado por un “Máster en CreaRack” (flujo de trabajo multi-agente, 16 dominios estudiados en paralelo y verificados contra el código real el 28-05-2026), consolidado a partir de 16 briefs de dominio. Encargo de Edu (s94); compartido con el equipo vía tag staff-share.

Regla de uso. Este documento da el MAPA. La fuente de verdad runtime es SIEMPRE el código (config/settings/base.py para versión/IA, bib_stats para cifras del grafo). La doc de contexto (context/agents/dev-*.md) y partes de la Biblioteca tienen drift conocido — verificar contra código.

Producto: CreaRack Pro v1.0.73 · plataforma SaaS multi-tenant para diseño y gestión de datacenters. Empresa: Esferic Labs SL (razón social) = CreaRack (nombre comercial). Stack: Django 6 + Ninja + Channels · PostgreSQL 18 · Valkey 7.2 · Docker/Dokploy/Hetzner. UI del producto en INGLÉS; comunicación del agente y comentarios/commits en español.

1. Visión de una página

CreaRack Pro es un SaaS para que operadores de datacenter diseñen y monitoricen su infraestructura física y de red. Ocho módulos sobre una base multi-tenant común:

• Core (core/): autenticación (allauth + passkeys + MFA), usuarios, organizaciones (tenants), permisos granulares, gating de módulos por plan, auditoría, Credential Store cifrado (Fernet), y el pipeline de middleware que incluye el aislamiento doble ORM + RLS PostgreSQL.
• Rack Editor (racks/): diseño visual de armarios 19” sobre Konva.js; inventario por unidad U; stencils; export CSV/JSON/PDF/QR; SSH/SFTP embebido vía Local Agent.
• Map Editor + Auto-Plan AI (blueprints/): lienzo 2D de topología de planta; Auto-Plan digitaliza la imagen de un plano con visión (Gemma 4) y crea racks/conexiones/paredes automáticamente (entregable comercial, calidad 100% obligatoria).
• Network Observatory + CNS/ITSM (monitoring/): monitorización ping/SNMP/HTTP, series en VictoriaMetrics, alertas, WebSocket en vivo; encima CNS (diagnóstico IA de incidentes + remediación SSH) e ITSM (SLA, escalado, correlación, runbooks).
• Network / Auto-Provision (network/): descubrimiento y caracterización automática de dispositivos (ping/nmap/HTTP/SNMP/SSH), confidence score; DeviceProfile es la fuente de verdad que alimenta Observatory, Rack Editor y Network Management.
• Digital Signage CMS (signage/): gestión de contenido/playlists/schedules para reproductores de cartelería; integrador estrella SpinetiX (SVG dinámico + WebDAV).
• Terminal SSH + Local Agent (terminal/ + terminal/agent/): acceso SSH desde navegador y el Local Agent (CreaRackAgent.exe, Windows), puente a IPs privadas + Sentinel 24/7.
• Config/Settings + stack IA (config/settings/): configuración por entorno + el contrato de IA mono-proveedor (Gemma 4 vía Google AI Studio, Claude Haiku alternativo).

Todo corre en contenedores Docker en Hetzner (gestionados por Dokploy), validado por CI en GitHub Actions, y gobernado por un ecosistema externo de tres repos hermanos que NO son el producto pero lo sostienen: Workspace (CreaRackSL-workspace: dashboard, wiki, Biblioteca, MCP server en Cloudflare serverless), claude-method (el harness: hooks, reglas, agentes, skills, onboarding) y Supercontexto/Biblioteca (grafo de conocimiento código↔doc, la memoria externa del equipo, vía tools MCP bib_*).

El equipo es plano de 3 (Edu CEO/Dev, Dani Dev, Txell COO), todos con Claude Code CLI y memorias independientes; el conocimiento compartido vive en CLAUDE.md, context/, la wiki y la Biblioteca.

2. Mapa de componentes y cómo se conectan

2.1 El producto por dentro (apps Django y su acoplamiento)

core es la base de todo: Organization y User (= AUTH_USER_MODEL) son FK de prácticamente todos los modelos; get_current_org(request) e is_admin(user)/has_permission() se importan transversalmente; las políticas RLS de core/migrations/0017 cubren tablas de todas las apps.

core  ◄── racks ◄── blueprints (coloca racks en planos vía BlueprintPlacement)
  ▲        ▲   ▲
  │        │   └── network (auto-link DeviceProfile↔Device por IP; stencil; PortConnection)
  │        │
  │        └── monitoring (MonitoringTarget FK a racks.Device; lee management_config cifrado)
  │
  ├── network ──► monitoring (configure_observatory crea MonitoringTarget + OIDs)
  ├── signage ──► monitoring (¡publish/deploy vive en monitoring/api/signage/, no en signage/!)
  └── terminal/agent ──► monitoring (Sentinel empuja métricas) + network (discovery proxy)

Acoplamientos que sorprenden (verificados en código, contra-intuitivos):

• Config Backups (ConfigBackup) viven en racks/models.py pero su API se sirve desde network/api/backups.py (/api/network/...).
• Publish/deploy de Signage vive en monitoring/api/signage/deploy.py (/api/monitoring/signage/...), no en signage/api/.
• /api/scripts lo sirve network.api.scripts_router (modelo ScriptTemplate), NO terminal/api/scripts.py (modelo Script, casi dead code).
• El StateManager de Undo/Redo (frontend) es global y compartido entre Rack Editor y Map Editor.

2.2 Frontend (patrón híbrido, no SPA)

Django renderiza HTML (templates + partials HTMX); JS modular ES6 vanilla añade interactividad sobre el DOM. Alpine.js cubre widgets reactivos puntuales (sin x-html por CSP). No hay React/Vue en el producto. Konva.js para canvas (editores), ECharts para gráficas, xterm.js para terminal (corre en el Local Agent, no en la página).

Núcleo CSP-safe: core/middleware/csp.py aplica nonce por request, script-src sin unsafe-inline → prohibido onclick= inline. La solución es event delegation en base.js con atributos data-action="fn" resueltos por dot-notation contra window. CSP es Report-Only en dev, Enforce en prod (un handler inline “funciona” en dev y rompe en prod).

Dos mundos JS coexisten (footgun crítico): static/js/*.js (218 archivos, el código vivo) vs frontend/src/*.ts (Vite+TS, migración estancada — solo echarts-loader.ts y terminal.ts se consumen en runtime). Editar el .ts equivocado no cambia nada.

2.3 Infra / despliegue (PROD y STAGE)

Internet ─HTTPS─► Traefik v3.6.7 (SSL Let's Encrypt) ─► web (Daphne ASGI :8000)
                                                          ├─ DB vía pgbouncer ─► PostgreSQL 18
                                                          ├─ cache/broker ─► Valkey 7.2
                                                          └─ métricas ─► VictoriaMetrics :8428

• 2 servidores Hetzner: PROD (CCX 4vCPU/16GB, crearack.com) y STAGE (CX23, BD independiente sin datos de cliente; aloja además Dokploy panel + crons Bibliotecario + DR backups).
• Dokploy (Docker Swarm single-node + Traefik) despliega vía webhook de GitHub al hacer push a main. Dokploy y el CI son independientes: Dokploy deploya aunque el CI esté rojo (→ Regla 14).
• NetBird Cloud Free (VPN WireGuard) da acceso SSH y a servicios internos por *.netbird.cloud; salvavidas = SSH directo por IP pública whitelisted en Hetzner.
• CI (.github/workflows/ci.yml): 4 jobs (frontend, backend, security, docker). Backend corre pytest en 2 pasadas (RLS secuencial aparte por race del rol PG compartido).

2.4 El ecosistema de gobernanza (workspace + Biblioteca + harness)

Claude Code (Edu/Dani/Txell) ──┬── consulta ──► MCP server (workspace.crearack.com/api/mcp)
                               │                    ├─ bib_*  (grafo + Archivo Maestro RAG)
                               │                    ├─ wiki_* (ciclo de vida wiki)
                               │                    └─ workspace/holded/github/email/infra
                               ├── pre-commit hook ──► bib_report_change obligatorio
                               └── SessionStart hook ──► git pull + hot-cache + hora local + sync

Repos (.py/.ts/.md) ──extractores AST/OpenAPI/docs──► Cloudflare D1 (nodes/edges/chunks/wiki)
                                              embeddings BGE-M3 + síntesis Gemma 4 / curación Haiku

• Workspace: Astro 6 estático + Cloudflare Pages Functions + D1 (SQLite edge) + Workers AI (embeddings) + Vectorize + R2. Síntesis IA con Gemma 4 (REST directa, sin SDK). Curación/ingest con Claude Haiku 4.5.
• Biblioteca/Supercontexto: grafo (≈4466 nodos / 6453 edges / 504 endpoints / 430 comunidades a 28-05-2026) + Archivo Maestro (RAG sobre chunks de docs/wiki). Reindex AST cada 10 min (cron STAGE), OpenAPI+docs cada hora, communities 1×/día. Wiki ingest 3-tier post-merge (filtro $0 → triage Haiku → deep Haiku).
• claude-method: harness (hooks pre-commit + SessionStart), reglas globales, agentes, skills, onboarding reproducible (~30 min) y propagación automática a los 3 perfiles.

3. Flujos transversales

3.1 Auth + aislamiento multi-tenant (ORM + RLS)

Pipeline de middleware (config/settings/base.py, orden REAL): Prometheus → MetricsIPRestriction → Security → WhiteNoise → RateLimit → Session → CSRF → Auth → Account(allauth) → Impersonation → AdminPaths → ModuleGating → TenantRLS → … → CSP.

• TenantRLSMiddleware abre transaction.atomic() y ejecuta SET LOCAL app.current_org_id = '<id>' (pgbouncer-safe; superuser/anónimo/sin-org → '0' = bypass).
• Aislamiento de DOS capas: filtrado ORM por organization=org (obligatorio en todo query) + RLS PostgreSQL como red de seguridad. RLS solo tiene USING, NO WITH CHECK: protege lectura cross-tenant, NO escritura — el aislamiento de escritura depende 100% del ORM.
• core_user está EXCLUIDO de RLS a propósito (AuthMiddleware consulta antes de fijar org).
• No hay auth global en NinjaAPI: cada endpoint chequea permisos a mano (is_admin(request.user)).
• El test cross-tenant (tests/api/test_tenant_isolation.py + test_rls.py) es la suite de seguridad más crítica del proyecto.

3.2 Stack IA — Gemma 4 mono-proveedor (Regla 8)

Toda llamada LLM del producto usa un modelo único gemma-4-26b-a4b-it vía Google AI Studio Paid Tier (SDK google-genai), con Claude Haiku 4.5 como red de seguridad. Diseño (refactor s61): cambiar de modelo = 1 env var, no N ediciones. Los model strings resuelven contra config/settings/base.py (GEMMA4_GENAI_MODEL, EDGE_AI_GOOGLE_GENAI_MODEL, ANTHROPIC_HAIKU_MODEL).

Cuatro flujos IA con provider independiente: Auto-Plan visión (AUTOPLAN_PROVIDER) → google_genai_driver.py; CNS/Tutor/MIB/Explain (EDGE_AI_PROVIDER) → factory get_provider(); chain genérica ai_fallback() (google_genai → Claude); workspace usa Gemma 4 (Help/Oráculo/Tutor/traducción) + Haiku (curación).

Invariantes Gemma 4 (replicados en driver + router + provider): sampling temp 1.0 / top_p 0.95 / top_k 64; response_mime_type="application/json" load-bearing (sin él la calidad cae ~100%→75%); NO enviar safety_settings ni thinking_config (Gemma open-weights devuelve 400). Salida siempre por sanitizeRawJson + fallback regex (Gemma rompe el JSON ~1/20-30 runs). Prohibidos en runtime: OpenRouter (retirado s55), Gemini, DeepSeek (s66), OpenAI, free tier, self-host PROD. Cambio de modelo = ADR + Regla 8 + AI_CONFIG.md en el mismo commit.

3.3 Despliegue PROD/STAGE (push → CI → Dokploy)

git pull --rebase origin main → git push a main → (GitHub Actions ci.yml como gate de validación) + (webhook GitHub → Dokploy → git pull + build Dockerfile.prod → recrea containers). [skip ci] PROHIBIDO (Regla 16): Dokploy filtra “skip” y omite el deploy silenciosamente, y rompe CF Pages + Bibliotecario-Ingest. Tras push: gh run list --limit 1 (Regla 14). SSL lo termina Traefik (SECURE_SSL_REDIRECT=False a propósito). CONN_MAX_AGE=0 inviolable con Daphne ASGI (revertido mal 4 veces).

3.4 Ciclo de la Biblioteca: report_change → commit → reindex

1. Tras editar código, antes de commitear: bib_report_change(file_path, change_type) por cada archivo.
2. El hook pre-commit bib_report_check.py bloquea el commit si un fichero MODIFIED no tiene report en la ventana de 10 min. Bypass: BIB_SKIP=1 git commit (queda logueado en Pulse).
3. El reindex AST (cada 10 min, cron STAGE) recoge el cambio y re-popula nodos/edges.
4. Al mergear/push a main: post-merge-ingest.yml decide crear/actualizar páginas wiki (filtro $0 → triage Haiku → deep Haiku) vía tools wiki_*.

Identidad del grafo = qualified_name (POST:/api/racks/, racks.models.Device, doc:CLAUDE.md), nunca el id. Reindexar es idempotente.

3.5 Local Agent — el puente a IPs privadas

El SaaS en Hetzner (EU) no alcanza IPs privadas del cliente. El Local Agent (CreaRackAgent.exe, Windows) corre en el PC del operador y puentea: SSH/SFTP en navegador, discovery/SNMP de Auto-Provision, Sentinel 24/7 (métricas a VictoriaMetrics + anomalías CNS), y deploy de Signage (WebDAV). El frontend decide con isPrivateIPAddress(ip); los endpoints /api/network/... que tocan IPs privadas devuelven HTTP 422 USE_LOCAL_AGENT y el navegador reenvía al agente en localhost:5050. Release del agente = docs + tag git + .exe como asset (los 3).

4. Las 26 Reglas de Oro destiladas a lo operativo

Detalle: CLAUDE.md §1 + context/RULES_DETAIL.md. Marcadas [HOOK] las que bloquea un check automático del pre-commit.

4.1 Push vs PR (Regla 20) + auto-merge

• PR obligatorio si: >5 archivos · toca migrations//compose.yml/Dockerfile/requirements.txt/config/settings//.github/workflows/ · commit feat:/refactor:.
• Push directo a main si: docs-only · fix <5 archivos sin infra · commit fix:/chore:/style:.
• Auto-merge: Claude mergea solo al ponerse el CI verde (Edu pre-aprueba el plan). Aplica incluso a migrations (el CI valida sintaxis; la migration la corre Edu). Única excepción: secrets/credenciales accidentales en el diff → parar y preguntar.
• Modo B (default): esperar solo Backend + Frontend del CI (~2 min), no Docker Build.
• Contexto: se trabaja/prueba en CreaRack online no abierto al público → push directo a main en fixes/UI es bajo riesgo.

4.2 Directrices Karpathy (CLAUDE.md §12)

1. Pensar antes de codificar — verbalizar suposiciones; varias interpretaciones → presentarlas.
2. Simplicidad primero — el mínimo código; sin features especulativas.
3. Cambios quirúrgicos — tocar solo lo imprescindible; dead code preexistente → mencionar, no borrar.
4. Ejecución dirigida por objetivo — transformar tareas en objetivos verificables.

5. Footguns más peligrosos del ecosistema

Ordenados por probabilidad de morder a un agente nuevo.

1. Drift de IA en doc/Biblioteca: dicen Gemini/OpenRouter/DeepSeek/Ollama, temp 0.1, 2 endpoints Auto-Plan. Todo histórico/retirado. El runtime real es Gemma 4 + chain google_genai → Claude. RULES_DETAIL.md Regla 8 aún dice “Gemma vía OpenRouter”. Verificar contra base.py + AI_CONFIG.md.
2. Dos mundos JS (static/js vivo vs frontend/src Vite estancado): editar el .ts equivocado no cambia nada (salvo echarts-loader.ts/terminal.ts).
3. RLS solo USING, sin WITH CHECK: protege lectura cross-tenant, NO escritura. Siempre filtrar por organization=org.
4. Cifrado de credenciales atado a SECRET_KEY: rotar DJANGO_SECRET_KEY rompe el descifrado de TODAS las StoredCredential. Hay además una DEV_KEY hardcodeada de fallback (deuda de seguridad conocida).
5. CONN_MAX_AGE=0 con Daphne ASGI es inviolable (revertido mal 4 veces; satura max_connections).
6. Dokploy / Swarm / Traefik — qué NO tocar: nunca docker swarm leave; nunca docker compose up/down manual en el servidor (containers sin labels Traefik → 404); editar .env directo se sobreescribe en deploy (usar panel); el webhook usa la IP por la que accedes al panel (entrar por NetBird grabó IP privada → auto-deploy muerto). Labels Traefik los inyecta Dokploy en cada deploy.
7. NetBird nameserver “all domains” (catch-all) rompe el DNS de toda la máquina: acotar a netbird.cloud. Resolve-DnsName siempre falla para *.netbird.cloud (no es fallo real).
8. Auto-Plan: response_mime_type JSON + sin safety_settings/thinking_config son load-bearing (quitar el primero baja calidad 100%→75%; enviar los otros da 400).
9. sanitizeRawJson en TODA síntesis Gemma 4: rompe el JSON ~1/20-30 runs. Nunca JSON.parse directo.
10. bib_ask puede dar 429 (cuota AI Studio) o timeout (cold start >80s → 524): caer a bib_search_semantic + lectura directa de código.
11. DELETE /api/racks/{id} hace HARD delete (CASCADE borra Devices + ConfigBackups), pese a que la doc dice soft. La vista rack_editor (GET) NO filtra por org. El auto-save es SYNC destructivo.
12. Crear/editar wiki vía MCP (wiki_create_page), no a mano: commitear .md a mano en un PR con código hace que Bibliotecario-Ingest re-genere y borre el campo product → la página no lista. Los [[wikilinks]] del cuerpo NO son enlaces en la web (solo backlinks related[]).
13. Doble fuente de config pytest: pytest.ini (settings dev) vs pyproject.toml (settings test). El split RLS en CI es intocable (race en DROP ROLE → flaky).
14. Los checks del pre-commit corren desde claude-method/harness/ (fuente única en ejecución desde el 05-08-2026): ya no hay copias scripts/harness/ que puedan desincronizarse. install_hooks.sh solo escribe el git hook pre-commit; los otros dos hooks (pre-push, commit-msg) los pone el instalador convergente install-git-hooks.ps1.
15. Opus 4.8 baja el effort a high pisando el xhigh del settings al actualizar → adherencia floja a reglas. Fix: /effort xhigh + env CLAUDE_CODE_EFFORT_LEVEL=xhigh.
16. Doble /signage en URLs CMS (/api/signage/signage/...) — patrón real, no typo. Y 7/12 vendors de signage caen al fallback generic_snmp (sin push real); el camino vivo es SpinetiX.
17. PowerShell & solitario manda a background, no encadena — usar ;, && o call operator & <ruta>.
18. Crons wiki del Bibliotecario migrados a systemd STAGE (schedule: comentado en GH Actions desde s66) — no buscar el log de Lint/Curator en GitHub Actions. El reindex del grafo sí está activo.

6. Glosario de términos propios

• CreaRack (Pro): el producto SaaS Django de diseño/gestión de datacenters. Nombre comercial.
• Esferic Labs SL: razón social legal (mismo CIF). Lo interno (GitHub, servers, paths, env vars) sigue usando “CreaRack”. NO hacer sweeps de renombrado.
• PROD / STAGE: los 2 servidores Hetzner. PROD = crearack.com. STAGE = testing con BD independiente sin datos de cliente; aloja también Dokploy panel + crons Bibliotecario + DR.
• NetBird: la VPN del equipo (Cloudflare Free, WireGuard). Acceso por *.netbird.cloud. Salvavidas = SSH por IP pública whitelisted.
• Dokploy: el PaaS auto-hospedado (Docker Swarm single-node + Traefik) que despliega el producto al push a main. Panel en :3000.
• Local Agent / Sentinel: CreaRackAgent.exe (Windows) en el PC del operador, puente a IPs privadas + monitorización 24/7 (Sentinel → métricas a VictoriaMetrics).
• Auto-Plan AI (“Magic Import”): digitaliza la imagen de un plano con Gemma 4 y crea racks/conexiones automáticamente. Entregable comercial, calidad 100%.
• CNS (CreaRack Network Sentinel): Edge Intelligence sobre Observatory — diagnóstico IA de anomalías + remediación SSH (dry-run, explain, revise, rollback). Encima vive ITSM.
• Observatory: Network Observatory, la torre de control de monitorización.
• Supercontexto / Biblioteca: el grafo de conocimiento código↔doc (Cloudflare D1) + Archivo Maestro (RAG). La memoria externa del equipo. Vía tools MCP bib_*.
• Bibliotecario: los automatismos que mantienen la Biblioteca fresca (reindex AST/OpenAPI/docs/communities + ingest post-merge + crons lint/curator/utility/drift).
• Oráculo (de EL): la caja de búsqueda+chat del header del workspace; modo oracle del motor RAG, scope EsfericLabs, para el equipo.
• Archivo Maestro: búsqueda semántica + síntesis NL de la Biblioteca (embeddings BGE-M3 + Gemma 4). Lo consumen bib_ask/bib_search_semantic, el Help Widget y el Oráculo.
• MCP server: workspace.crearack.com/api/mcp — expone ~100 tools (bib_*, wiki_*, workspace, Holded, GitHub, email, infra) por JSON-RPC. Auth Bearer + CF Access.
• claude-method: el harness reutilizable. Repo privado clonado en cada PC del staff. Principio: “Agent = Model + Harness”.
• STATE.md / LOG.md / NEXT.md: los 3 archivos del Supercontexto operativo (public/supercontext/) — estado vivo, bitácora append-only, briefing permanente (Regla 19).
• WORKLOG.md: el dietario del equipo (Regla 12), en el repo workspace.
• Pulse: panel en vivo del estado del Bibliotecario (/biblioteca/pulse).
• VictoriaMetrics (VM): almacén de series temporales (180 días) para las gráficas de Observatory.
• DeviceProfile: el modelo (app network) fuente de verdad de un dispositivo descubierto; alimenta Observatory, Rack Editor y Network Management.
• Valkey: cache + broker (Redis-compatible) para sesiones, cache, broker Huey y channel layer.

7. Cómo arrancar y cerrar sesión (Regla 19) + ritual “Apaga”

Arranque: (1) hora local — el hook SessionStart inyecta [Local time] … Europe/Madrid (esa línea manda, no el currentDate UTC); verificar /effort = xhigh. (2) Supercontexto — leer STATE.md + briefings/NEXT.md (en CreaRackSL-workspace/public/supercontext/). (3) Biblioteca primero (Regla 0). (4) la sesión se ancla en C:\dev\CreaRack-Pro.

Trabajo: respetar las 26 reglas; agentes/MCP especializados antes que general-purpose (Regla 26); antes de commitear código modificado bib_report_change por archivo (el hook bloquea); antes de push git pull --rebase origin main; tras push de código gh run list --limit 1.

Ritual “Apaga” (palabra clave de cierre — ejecutar SIN preguntar; disparado por “Apaga”/“lo dejamos”): (1) Supercontexto si se tocó (STATE + LOG; NEXT si cambia backlog; reconciliar 🔔 Pendientes contra estado real). (2) WORKLOG.md del workspace (Resumen coloquial + Detalle técnico). (3) tag opcional supercontext/sesion-N-done. (4) Sync Cascade si se tocó src/content/wiki/*.md. (5) commits + push (git pull --rebase antes; nunca [skip ci]). (6) verificar CI. (7) memorias + MEMORY.md. (8) backup memoria (claude-method/harness/claude-backup.ps1 -PushGit).

NUNCA sugerir cierre ni preguntar “¿cerramos o seguimos?” — Edu decide cuándo parar.

8. Los 16 dominios estudiados (para profundizar)

El detalle profundo de cada dominio se estudió en un brief dedicado (verificado contra código). Para profundizar en cualquiera: bib_app_summary(app="…") + bib_ask + lectura directa del código; los briefs completos del Máster los custodia Edu (C:\dev\crearack-master\briefs\, regenerables con el flujo master-crearack).

Aviso transversal de fidelidad: los 16 briefs coinciden en que context/agents/dev-*.md, el README/FEATURE_CATALOG (conteos JS/templates) y partes de la Biblioteca tienen drift conocido. La fuente de verdad es el código (config/settings/base.py, bib_stats en vivo). Verificar siempre.

Generado por el flujo de trabajo dinámico master-crearack (Claude Opus 4.8) el 28-05-2026. Última actualización: 28-05-2026.

Véase también

• [[crearack-tech—agents—dev-map-editor]]
• [[feature—workspace—master-generador]]
• [[feature—workspace-tech—master-generador-workflow]]
• [[crearack-tech—agents-overview]]