ADR-0017 — WPDoctor: Memoria Ejecutiva v1.0¶
Repository: agent-adk-wpdoctor
Product: WPDoctor
Architecture baseline: ADR-0017 (ADR-0001 dentro del repositorio agent-adk-wpdoctor)
1. Qué estamos construyendo¶
WPDoctor es un SRE autónomo especializado en WordPress y WooCommerce que puede operar la infraestructura que el cliente ya tiene.
La premisa comercial es sencilla:
El cliente no tiene que migrar su WordPress a nuestro hosting. WPDoctor se conecta a su infraestructura y empieza a trabajar sobre ella.
El mecanismo mínimo de integración será SSH.
Por tanto, WPDoctor debe funcionar independientemente de si el servidor está alojado en:
- OVH;
- Hetzner;
- AWS;
- DigitalOcean;
- una VM propia;
- bare metal;
- Proxmox;
- otro proveedor.
La plataforma será hosting-provider agnostic.
2. Qué problema resuelve¶
La operación de WordPress no termina en WordPress.
Un problema percibido como:
puede encontrarse realmente en:
Los agentes WordPress que solamente entienden la aplicación no pueden realizar correctamente el trabajo de un SRE.
WPDoctor debe entender toda la pila.
3. Posicionamiento¶
No pretendemos vender inicialmente:
La propuesta es mucho más concreta:
Un SRE especializado para las infraestructuras WordPress que el cliente ya posee.
Posibles mensajes comerciales:
Connect your WordPress servers. Get an AI SRE.
o:
Autonomous SRE for WordPress estates.
4. Cliente objetivo¶
El producto es especialmente interesante para:
- agencias WordPress;
- agencias WooCommerce;
- MSP;
- proveedores de mantenimiento;
- empresas con decenas de WordPress;
- hostings WordPress;
- equipos técnicos que administran múltiples VPS.
Un tenant WPDoctor podrá controlar:
No será necesario desplegar un agente por WordPress.
5. Experiencia de usuario¶
El cliente verá una única identidad:
y podrá solicitar:
¿Por qué shop.example.com está lenta?
Revisa este servidor, está al 100% de CPU.
Analiza estos 502.
Optimiza PHP-FPM.
Revisa el rendimiento de WooCommerce.
Actualiza de forma segura los plugins que puedan actualizarse.
Comprueba todas mis instalaciones WordPress.
WPDoctor decidirá internamente qué especialistas necesita.
6. Arquitectura conceptual¶
flowchart TD
U[Customer] --> M[WPDoctor SRE Manager]
M --> L[Linux Specialist]
M --> W[Web/PHP Specialist]
M --> D[Database Specialist]
M --> WP[WordPress Specialist]
M --> WC[WooCommerce Specialist]
M --> P[Performance Specialist]
M --> S[Security Specialist]
L --> O[Operations]
W --> O
D --> O
WP --> O
WC --> O
P --> O
S --> O
O --> PE[Policy Engine]
PE --> T[Deterministic Tools]
T --> SSH[SSH]
SSH --> C[Customer Infrastructure]
7. Modelo operativo¶
La operativa seguirá:
La fase learn permitirá que WPDoctor vaya conociendo mejor al cliente.
8. Memoria¶
WPDoctor utilizará Hindsight como memoria operacional persistente por tenant.
Queremos que el sistema termine sabiendo cosas como:
srv01 ejecuta 17 WordPress.
shop.example.com realiza una importación ERP todas las noches.
No reiniciar MariaDB automáticamente en este servidor.
El plugin X ya provocó problemas tras una actualización.
Este servidor suele sufrir IO durante el backup.
Esto crea una diferencia importante respecto a lanzar cada incidencia contra un agente genérico sin contexto.
WPDoctor irá desarrollando conocimiento operacional específico de cada infraestructura.
9. Seguridad¶
La autonomía será gradual.
Existirán tres modos:
En READONLY:
En COPILOT:
En AUTOPILOT solamente se permitirán de forma automática operaciones previamente clasificadas y autorizadas.
El producto no se basará en entregar root sin restricciones a un LLM.
10. Diferenciación¶
No consideramos que ADK, Hindsight o el modelo LLM sean individualmente el moat.
El activo acumulativo será:
WordPress expertise
+
SRE workflows
+
operations
+
skills
+
incident history
+
safe execution policies
+
environment adapters
+
evaluation corpus
+
tenant memory
Con suficiente dogfooding, WPDoctor debería resolver mejor los problemas WordPress que un agente generalista con shell.
11. Wetopi¶
Wetopi desempeñará un papel estratégico:
real production infrastructure
↓
dogfooding
↓
incidents
↓
skills / operations / evals
↓
WPDoctor improves
Pero WPDoctor NO dependerá técnicamente de Wetopi.
Cualquier conocimiento específico de Wetopi quedará separado del core.
12. MVP¶
El primer MVP debe ser pequeño pero real.
Baseline:
Debe poder:
- descubrir hosts;
- descubrir WordPress;
- crear inventario;
- investigar problemas;
- diagnosticar;
- construir planes;
- ejecutar cambios controlados;
- validar resultados;
- recordar aprendizajes.
13. Lo que NO construiremos inicialmente¶
No construiremos todavía:
- un hosting;
- un panel SaaS completo;
- facturación;
- soporte universal para todos los paneles;
- un reemplazo de Prometheus/Grafana;
- un agente DevOps genérico;
- autonomía destructiva;
- Kubernetes SRE general.
El foco inicial es:
hacer excepcionalmente bien SRE sobre WordPress y su stack Linux.
14. Estrategia de desarrollo¶
El orden será:
1. contratos y runtime
2. SSH
3. discovery
4. inventario
5. diagnóstico read-only
6. operations
7. policy
8. ejecución
9. validación
10. Hindsight
11. evals
12. Wetopi dogfooding
13. primer cliente externo
15. Objetivo de la primera versión comercial¶
Un cliente debería poder darnos acceso controlado a uno o varios servidores y obtener un WPDoctor capaz de responder:
¿Qué infraestructura tengo?
¿Qué WordPress existen?
¿Qué está mal?
¿Cuál es la causa?
¿Qué deberíamos cambiar?
¿Puedes arreglarlo?
Y, según su política:
WPDoctor lo diagnostica
↓
WPDoctor prepara el cambio
↓
humano aprueba
↓
WPDoctor ejecuta
↓
WPDoctor valida
↓
WPDoctor aprende
Ese es el producto inicial.
Correspondencia: ADR-0017 en el Knowledge Plane;
docs/MEMORIA-EJECUTIVA.mdenagent-adk-wpdoctor. ADR-0018 amplía esta base con orquestación durable, Activity semántica y WebUI.