Perla · Matriz de capabilities

Cómo leerla

Una tabla por dominio. Cada fila es una capability.

Las columnas dicen en qué superficie vive, qué tan implementada está, si bloquea el primer beta y qué decisión la destraba.

Estado actual

repo cableado completo

queued falla último cable

parcial solo una superficie

mockup solo diseño

Ø no existe

Beta 1 · recorte

blocker sin esto no hay beta

nice mejora pero no bloquea

post después del primer beta

Audiencia

customer escribe al número

owner dueño · control total

staff empleado · parcial

PrincipioCómo se decide qué entra a la matriz

Una capability entra solo si está anclada en una de tres fuentes: repo real (existe código en src/backend/ o tool cableada), dashboard real (existe ruta en src/routes/) o roadmap v3 (nombrada explícita en el roadmap del agente). Si no está en ninguna, no se agrega. Anti-wishlist.

La columna Audiencia sale de src/backend/agent/audience.ts, que mapea phone → role en cada mensaje entrante.

A0 · queuedPor qué hay un único caso amarillo

El smoke test del 19/05 dejó el envío de respuesta en messages.outbound.status='queued' sin envío real a Meta. La cadena recibe → procesa → encola, pero el último cable no está conectado. Tomi tiene la decisión sobre el approach (reusar el helper existente vs. nueva ruta). Por eso A0 es el único queued en la matriz — desbloquea, junto con otros hitos, todo el resto.

§1

Agenda y turnos

Siete capabilities. Seis funcionan; A0 (responder_mensaje) hoy es la única en queued.

ID	Capability	Audiencia	Dashboard	WA	Tool real	Estado	Beta 1	Decisión
A0*	responder_mensaje	sistema	—	queued	dispatch + sender	queued	blocker	Tomi: reusar `sendWhatsAppTextMessage` vs. nueva ruta
A1	listar_servicios	customer, owner, staff	/app/settings/services	ok	get_services	repo	blocker	—
A2	listar_staff	customer, owner, staff	/app/settings/team	ok	get_staff	repo	blocker	—
A3	ver_agenda	customer, owner, staff	/app/schedule	ok	list_appointments	repo	blocker	Negocio: ¿customer ve toda la agenda o solo sus turnos?
A4	crear_turno	customer, owner, staff	/app/schedule	ok	create_appointment medium	repo	blocker	Negocio: confirmación siempre o solo en conflicto
A5	cancelar_turno	customer, owner, staff	/app/schedule	ok	cancel_appointment medium	repo	blocker	Negocio: ¿customer cancela solo o requiere staff?
A6	mover_turno	customer, owner, staff	/app/schedule	ok	reschedule_appointment medium	repo	blocker	Producto: ¿confirmar nueva fecha antes de commitear?

NotaA0 es la fila vertebral

Sin A0 cableada, todo el resto de §1 está «listo pero mudo». Las 6 tools de A1-A6 funcionan, pero el agente no le contesta al customer. Por eso A0 va primero y manda el orden del beta. El gap es un solo cable, no una arquitectura.

§2

Conversaciones y handoff

Cuatro capabilities. Listar y tomar ya funcionan; devolver y no-show tienen service layer pero falta exposición como tool.

ID	Capability	Audiencia	Dashboard	WA	Tool real	Estado	Beta 1	Decisión
C1	listar_conversaciones	owner, staff	/app/messages	ok	list_conversations	repo	blocker	—
C2	tomar_conversacion	owner, staff	/app/messages	ok	take_conversation medium	repo	blocker	—
C3	devolver_al_agente	owner, staff	/app/messages	Ø	Ø handoff-service existe	parcial	nice	Tomi: reactivación auto 12h (PR #89) o explícita
C4	marcar_no_show	owner, staff	/app/schedule	Ø	Ø service existe	parcial	nice	—

NotaC3 y C4 son tools nuevas chicas

Ambas tienen el método correspondiente en el service layer (handoff-service y markAppointmentNoShowForBusiness). Cablearlas como tools del agente es trabajo menor — podrían cerrar en 1 sprint si valen para beta.

§3

Configuración del negocio

Catorce capabilities. Todas con ruta dashboard real y ninguna expuesta como tool. Es el contrato visible de H6: trabajo nuevo, no exposición.

ID	Capability	Audiencia	Dashboard	WA	Tool real	Estado	Beta 1	Decisión
S1	editar_info_general	owner	/app/settings/general	Ø	Ø	parcial	nice	—
S2	editar_datos_comerciales	owner	/app/settings/business	Ø	Ø	parcial	post	Producto: ¿editar fiscal por WA tiene sentido?
S3	gestionar_cuenta_usuario	owner	/app/settings/account	Ø	Ø	parcial	post	— (seguridad)
S4	abm_servicios	owner	/app/settings/services	Ø	Ø	parcial	blocker	Producto: ABM completo o solo precio
S5	invitar_staff	owner	/app/settings/team	Ø	Ø	parcial	nice	Negocio: link mágico o code
S6	gestionar_locales	owner	/app/settings/locations	Ø	Ø	parcial	post	Negocio: ¿multi-locación en el primer piloto?
S7	configurar_horarios	owner	/app/settings/availability	Ø	Ø	parcial	blocker	Producto: bloqueos puntuales = capability o subcaso
S8	configurar_agente	owner	/app/settings/assistant	Ø	Ø	parcial	blocker	Tomi: prompt editable directo o con review
S9	gestionar_billing	owner	/app/settings/billing	Ø	Ø	parcial	post	— (MP flujo paralelo)
S10	configurar_experiencia_cliente	owner	/app/settings/experience	Ø	Ø	parcial	nice	Diseño: qué se edita por WA vs. dashboard
S11	configurar_operaciones	owner	/app/settings/operations	Ø	Ø	parcial	post	—
S12	configurar_notificaciones	owner	/app/settings/notifications	Ø	Ø	parcial	nice	Producto: qué eventos notifican al owner
S13	configurar_politicas	owner	/app/settings/policies	Ø	Ø	parcial	post	Negocio: políticas por WA o dashboard
S14	gestionar_recursos_api	owner	/app/settings/resources	Ø	Ø	parcial	post	— (seguridad)

InsightEl gap H6 no es diseño — son 14 dashboards esperando tool

El modelo del negocio ya está construido en el frontend. El owner ya puede configurar todo por dashboard. Falta cablear el agente al backend para que también lo pueda configurar por chat.

Lectura rápida

La foto en números.

Capabilities

25

total mapeadas

Repo

8

end-to-end

Queued

1

A0 send cable

Parcial

16

una superficie

Blockers beta

10

mínimo viable

Mapa visual del estado

§1 Agenda y turnos6 ok · 1 queued

§2 Conversaciones y handoff2 ok · 2 parcial

§3 Configuración del negocio14 parcial · gap H6

RecorteBeta 1 · qué entra y qué queda afuera

Blocker (10): A0-A6 + C1-C2 + S4 + S7 + S8. El owner puede configurar lo crítico antes del primer cliente real.
Nice (7): C3 + C4 + S1 + S5 + S10 + S12 — mejoran experiencia, no bloquean.
Post-beta (8): S2 + S3 + S6 + S9 + S11 + S13 + S14. Lo administrativo/legal/financiero se hace una vez por dashboard.

ToolsEstado de las tools del agente

Cableadas: 8 (get_services, get_staff, list_appointments, list_conversations, create_appointment, cancel_appointment, reschedule_appointment, take_conversation).
Candidatas (service existe): 2 (devolver_al_agente, marcar_no_show).
Nuevas para H6 completo: 14 (una por cada /app/settings/*).

Decisiones pendientes

Quince filas con decisión abierta.

Resolver el bloque de Negocio en una sesión de 20-30 min destraba cuatro capabilities a la vez.

ID	Decide	Pregunta
A0	Tomi	Send cable: reusar `sendWhatsAppTextMessage` o ruta nueva
A3	Negocio	¿Customer ve agenda completa o solo sus turnos?
A4	Negocio	Confirmación turno: siempre o solo en conflicto
A5	Negocio	¿Customer cancela solo o requiere staff?
A6	Producto	Confirmación de nueva fecha al mover
C3	Tomi	Reactivación auto a 12h (PR #89) o explícita
S2	Producto	¿Editar fiscal por WA tiene sentido?
S4	Producto	ABM servicios completo o solo precio
S5	Negocio	Invitación staff: link o code
S6	Negocio	Multi-locación entra al primer piloto
S7	Producto	Bloqueos puntuales = capability o subcaso
S8	Tomi	Prompt editable directo o con review
S10	Diseño	Qué experiencia se edita por WA
S12	Producto	Qué eventos notifican al owner
S13	Negocio	Políticas por WA o dashboard

Próximas vueltas

El orden que destraba más con menos.

1 · Resolver A0 con Tomi. Destraba el reporte canónico del 19/05 y el blocker número uno del beta. Sin esto, todo §1 está mudo.
2 · Sesión rápida con Negocio (~20 min). Resolver A3, A4, A5 y S6 de una sentada — son las que más impactan al MVP percibido por el cliente.
3 · Cablear C3 y C4. Service layer existe; son tools nuevas chicas. Pueden cerrar en 1 sprint.
4 · Subset mínimo de §3 para beta. Cuáles 3-4 settings son críticas que el owner pueda tocar por WA.