Cómo está ordenado esto
No todas las preguntas son del mismo tipo, y mezclarlas hace que respondas 70 cosas cuando en realidad tienes que decidir 52.| Grupo | Cuántas | Quién decide | Cuándo |
|---|---|---|---|
| A. Bloquean aprobación | 52 | Tú | antes de que su spec pase a approved |
| B. Son del abogado | 7 | Daniel + abogado | van en el mismo paquete que legal/ |
| C. Son comerciales | 10 | Tú, con el ejercicio de pricing | antes del lanzamiento comercial |
| D. Bloqueadas por un ADR | 1 | investigación, no decisión | cuando se escriba el ADR |
review y de ahí a approved. Los grupos B y
C no bloquean nada.
Grupo A — Bloquean aprobación
identity (16)
| ID | Pregunta | Afecta | REC |
|---|---|---|---|
| OQ-IDN-01 | ¿MFA obligatorio para todo usuario, o solo para roles con permisos sensibles? | PRD, FS-IDN-0005 | Solo para roles con permisos sensibles. Obligarlo a un asistente que solo lee un dashboard genera fricción sin reducir riesgo. El modelo de permisos ya distingue lo sensible, así que apuntar ahí es preciso y no arbitrario. |
| OQ-IDN-02 | Duración absoluta de sesión de consola: ¿12 horas, o 30 días deslizantes con re-prompt en acciones sensibles? | PRD, FS-IDN-0004 | 30 días deslizantes con re-prompt. 12 horas obliga a entrar cada mañana y empuja a la gente a guardar contraseñas en el navegador, que es peor. El re-prompt protege lo que importa sin castigar el trabajo diario. |
| OQ-IDN-03 | ¿Passkeys en F1a, o basta contraseña más magic link? | PRD, FS-IDN-0003 | F1a. Better Auth ya los soporta, el costo marginal es bajo, y es lo que permite que un tenant que quiere evitar contraseñas lo haga desde el primer día en vez de esperar una migración de hábitos. |
| OQ-IDN-04 | Expiración de invitación: ¿7 o 14 días? | FS-IDN-0001 | 7 días. Una invitación de dos semanas es un token vivo en una bandeja durante dos semanas. Reenviarla cuesta un clic. |
| OQ-IDN-05 | ¿Un usuario puede borrar su propia cuenta, y qué pasa con sus membresías? | FS-IDN-0001 | Puede abandonar una organización, no borrar la cuenta. Borrarla mientras tiene membresías activas deja huecos en el rastro de auditoría. Sin membresías, la cuenta se puede purgar. |
| OQ-IDN-06 | ¿Falta un rol de sistema de “facturación”? | FS-IDN-0002 | Sí, agregarlo. Es el caso más común que los cinco actuales no cubren: alguien que ve consumo y facturas y nada más. Sale barato ahora y es una fila. |
| OQ-IDN-07 | Largo mínimo de contraseña: ¿12, o 10 con chequeo de filtraciones? | FS-IDN-0003 | 12 con chequeo de filtraciones. El chequeo es lo que sirve; el largo es defensa contra fuerza bruta offline y 12 es el mínimo razonable hoy. |
| OQ-IDN-08 | ¿La lista de acciones sensibles es configurable por organización, o fija? | FS-IDN-0004 | Fija. Es una lista de seguridad, no una preferencia. Un tenant que la relaje se hace daño a sí mismo y nos lo cobra a nosotros cuando pase algo. |
| OQ-IDN-09 | ¿Las API keys expiran por defecto, y en cuánto? | FS-IDN-0006 | No por defecto, con expiración opcional. Una key que expira sola rompe una integración de madrugada. La rotación con solapamiento es el mecanismo correcto; la expiración es para quien la quiera. |
| OQ-IDN-10 | Ventana de solapamiento en rotación: ¿24 h, o configurable hasta 7 días? | FS-IDN-0006 | Configurable hasta 7 días, default 24 h. Un integrador que despliega semanalmente necesita más de un día para propagar una key nueva. |
| OQ-IDN-11 | ¿Los clientes OAuth se revisan antes de activarse, o self-service? | FS-IDN-0007 | Revisados por nosotros en F1b. Un cliente OAuth pide permisos sobre datos de terceros; con el volumen inicial la revisión es barata y evita el primer incidente de reputación. Se automatiza cuando el volumen lo justifique. |
| OQ-IDN-12 | Vida absoluta del refresh token: ¿30 o 90 días? | FS-IDN-0007 | 90 días con rotación. La rotación con detección de reúso es la protección real; 30 días obliga a reautorizar integraciones que funcionan bien. |
| OQ-IDN-13 | ¿Qué proveedores sociales primero — los tres, o solo Google? | FS-IDN-0008 | Google y Microsoft. Cubren casi todo el mercado B2B. GitHub es para equipos técnicos y puede seguir; agregarlo después es configuración. |
| OQ-IDN-14 | ¿Un tenant puede desactivar la impersonación por completo? | FS-IDN-0009 | Sí, con advertencia explícita de soporte más lento. Que un cliente pueda decir que no es lo que hace creíble que sea auditada cuando dice que sí. |
| OQ-IDN-15 | Ventana de impersonación por defecto: ¿60 min, o 30 con renovación fácil? | FS-IDN-0009 | 60 minutos. 30 con renovación fácil genera renovaciones automáticas y convierte la ventana en un trámite en vez de un límite. |
| OQ-IDN-16 | ¿Ofrecemos account linking opcional después, para agencias? | FS-IDN-0001 | Registrado, no ahora. Se responde cuando un cliente real lo pida; la unicidad por organización que definiste es la postura correcta hasta entonces. |
core (18)
| ID | Pregunta | Afecta | REC |
|---|---|---|---|
| OQ-CORE-01 | ¿Qué taxonomía vertical se entrega segunda? | PRD, FS-CORE-0012 | Retail. Es el vertical con más volumen de eventos y el que mejor ejercita el motor de reglas; salud y servicios traen datos sensibles que conviene abordar con el paquete legal ya revisado. |
| OQ-CORE-02 | ¿El historial de un contacto anónimo sobrevive si nunca se vuelve conocido? | PRD, FS-CORE-0006 | Se purga a los 90 días. Retener comportamiento de alguien que nunca se identificó es acumular dato personal sin finalidad, y la retención por plan es para clientes, no para visitantes. |
| OQ-CORE-03 | ¿Sembramos Centroamérica y México ahora? | FS-CORE-0001 | No. Sudamérica cubre el mercado objetivo; agregar un país es una fila más un normalizador, y hacerlo sin un tenant que lo necesite es código sin probar contra datos reales. |
| OQ-CORE-04 | ¿El email es único por tenant, o dos contactos pueden compartirlo? | FS-CORE-0002 | Pueden compartirlo. Los hogares y las casillas comerciales compartidas son reales. La unicidad que importa es la del documento; el email es un canal, no una identidad. |
| OQ-CORE-05 | ¿Normalizamos el teléfono a E.164 y rechazamos lo demás? | FS-CORE-0002 | Normalizar sí, rechazar no. Un teléfono mal formateado no impide operar como sí lo hace un documento inválido. Se guarda normalizado cuando se puede, en crudo cuando no, y se marca. |
| OQ-CORE-06 | ¿Una coincidencia de documento es identidad verificada por sí sola? | FS-CORE-0003 | Sí. Un documento con dígito verificador válido, dentro de un tenant, es la señal más fuerte que tenemos. Exigir una segunda señal deja fusiones legítimas sin hacer y llena la cola de revisión. |
| OQ-CORE-07 | Política de conflicto de campos al fusionar: ¿gana el más reciente o el superviviente? | FS-CORE-0003 | El no nulo más reciente. El superviviente se elige por antigüedad, no por calidad de datos; el dato más nuevo suele ser el correcto. Los descartados quedan en la fila de fusión igual. |
| OQ-CORE-08 | ¿Versionamos el texto de consentimiento, o es un string opaco del tenant? | FS-CORE-0004 | String opaco del tenant. El texto es suyo y su responsabilidad; versionarlo nosotros nos convierte en custodios de un contenido legal que no redactamos. |
| OQ-CORE-09 | ¿Encadenamos hashes en la auditoría ahora, o append-only más grants en F1? | FS-CORE-0005 | Append-only más grants en F1. La cadena de hashes protege contra un atacante con acceso de escritura a la base, que es un escenario donde ya perdimos. Es endurecimiento posterior, no F1. |
| OQ-CORE-10 | ¿Aceptamos eventos con occurred_at futuro, y con qué tolerancia? | FS-CORE-0006 | Sí, con 5 minutos de tolerancia. Los relojes de los POS se desincronizan. Más allá de eso se acepta el evento pero se estampa con received_at y se marca, para no corromper particiones ni ventanas. |
| OQ-CORE-11 | TTL de processed_jobs: ¿7 días, o más? | FS-CORE-0007 | 7 días. Excede con holgura la ventana máxima de reintentos (5 intentos con tope de 1 h). Más allá, la tabla crece sin comprar nada. |
| OQ-CORE-12 | ¿Un dead letter sin revisar escala tras N días? | FS-CORE-0007 | Sí, a los 7 días alerta con severidad mayor. Es la misma lógica que los referidos marcados: lo que no se revisa se olvida, y un dead letter olvidado es un efecto que nunca ocurrió. |
| OQ-CORE-13 | Profundidad y cantidad de nodos máxima en el DSL de segmentos | FS-CORE-0008 | Profundidad 5, 50 nodos. Suficiente para cualquier RFM realista, y acota el costo de la evaluación incremental para que un segmento no pueda degradar la ingesta. |
| OQ-CORE-14 | ¿Las plantillas RFM llegan con la taxonomía o como set aparte? | FS-CORE-0008 | Con la taxonomía. Son la razón por la que instalar una taxonomía vale la pena el primer día; separarlas convierte dos decisiones en lo que debería ser una. |
| OQ-CORE-15 | Duración de sesión de member: ¿30 días deslizantes, o menos? | FS-CORE-0009 | 30 días deslizantes, con re-prompt para canjear. El member entra poco y desde su teléfono; obligarlo a autenticarse cada vez mata el uso del portal. El canje sí vuelve a pedir. |
| OQ-CORE-16 | ¿El token exchange soporta refresh, o el tenant reintercambia? | FS-CORE-0009 | Reintercambia. El tenant ya tiene la sesión del member en su propio sistema; un refresh nuestro duplica un estado que él ya gobierna. |
| OQ-CORE-17 | ¿Se puede instalar más de una taxonomía, y cómo se resuelven colisiones? | FS-CORE-0012 | Sí, y una colisión de nombre de evento se rechaza nombrándola. Un retail con suscripciones es un caso real; resolver la colisión en silencio es peor que pedirle al tenant que elija. |
| OQ-CORE-18 | ¿Soportamos un tipo list (multivalor) en atributos personalizados? | FS-CORE-0011 | No en F1b. Multivalor complica el constructor de segmentos y la validación por un caso que casi siempre se modela mejor como taxonomía de eventos o como segmento. |
messaging (12)
| ID | Pregunta | Afecta | REC |
|---|---|---|---|
| OQ-MSG-01 | ¿Tracking de aperturas y clics activo por defecto? | PRD, FS-MSG-0003 | Clics sí, aperturas no. El píxel de apertura es lo que a reguladores y clientes de correo les molesta, y Apple Mail lo falsea desde hace años, así que el dato es malo y caro políticamente. El clic es una acción deliberada y el dato sirve. |
| OQ-MSG-02 | Quiet hours por defecto para un tenant nuevo | FS-MSG-0001 | 21:00–09:00 local. Un default permisivo significa que el primer tenant descubre las quiet hours cuando un member reclama por un correo a las 3 AM. |
| OQ-MSG-03 | ¿Un tenant puede sobreescribir una plantilla de sistema (OTP, invitación)? | FS-MSG-0002 | Puede cambiar el branding, no el contenido. Un OTP con texto editable es un OTP que alguien va a convertir en phishing sin querer. |
| OQ-MSG-04 | ¿Cuánto se retiene el contenido renderizado? | FS-MSG-0003 | 90 días. Sirve para soporte y disputa; retenerlo 25 meses acumula el texto de cada mensaje enviado a cada persona, que es el dato más difícil de justificar de todo el módulo. |
| OQ-MSG-05 | Frequency cap de marketing por defecto | FS-MSG-0004 | 3 por semana. Por encima de eso la tasa de bajas sube más rápido que la conversión, y quien quiera más lo sube deliberadamente. |
| OQ-MSG-06 | ¿Un member puede resuscribirse tras una queja, o solo tras un rebote? | FS-MSG-0004 | Solo tras un rebote. Una queja de spam es una señal que las operadoras registran; volver a escribirle a quien se quejó daña la reputación compartida de todos los tenants. |
| OQ-MSG-07 | Umbral de profundidad transaccional al que cede marketing | FS-MSG-0005 | Función del throughput: cuando la profundidad supera 30 segundos de trabajo pendiente. Un número fijo se queda corto o largo según el tamaño del tenant; 30 segundos es la promesa que le hacemos al transaccional. |
| OQ-MSG-08 | Fallas consecutivas de webhook antes de desactivar | FS-MSG-0006 | Una tasa: 20 fallas consecutivas o 50% en una hora. Solo consecutivas deja vivo un endpoint que falla la mitad de las veces, que es peor que uno caído. |
| OQ-MSG-09 | ¿Las notificaciones in-app expiran? | FS-MSG-0006 | A los 90 días si no se leyeron. Una bandeja infinita es una bandeja que nadie abre. |
| OQ-MSG-10 | Ventana de envío local por defecto para campañas por fecha | FS-MSG-0007 | 09:00–11:00. Es la ventana con mejor apertura en la mayoría de los mercados y no molesta a nadie. |
| OQ-MSG-11 | Tamaño máximo de blast antes de exigir segunda confirmación | FS-MSG-0007 | 10 000 destinatarios. Por debajo, confirmar dos veces es fricción; por encima, un error cuesta reputación de dominio y no se puede des-enviar. |
| OQ-MSG-12 | ¿Pedimos aumento de límite a Resend antes de G1, y a qué número? | FS-MSG-0005 | Sí, a 50 rps. Con el endpoint batch son 5 000 mensajes por segundo teóricos, holgura suficiente para que los carriles duales tengan margen real y no solo prioridad. |
crm (6)
| ID | Pregunta | Afecta | REC |
|---|---|---|---|
| OQ-CRM-01 | ¿Una nota se puede editar, o solo agregarle? | PRD, FS-CRM-0001 | Editable con historial visible. Append-only suena más defendible pero produce notas llenas de correcciones que nadie lee. El historial conservado da la misma defensa sin el costo de uso. |
| OQ-CRM-02 | ¿Las actividades se asignan a cualquier usuario, o solo al dueño? | PRD, FS-CRM-0002 | A cualquier miembro activo de la organización. Restringirlo al dueño convierte una herramienta de equipo en una lista personal. |
| OQ-CRM-03 | Largo máximo de una nota | FS-CRM-0001 | 10 000 caracteres. Cabe cualquier nota real y evita que alguien pegue un documento completo. |
| OQ-CRM-04 | ¿Una actividad se puede colgar de un evento de fidelización? | FS-CRM-0002 | Sí, con una referencia opcional. “Hacer seguimiento a este canje” es el caso de uso que conecta los dos módulos, y es una columna nullable. |
| OQ-CRM-05 | Tamaño máximo de una lista estática | FS-CRM-0003 | 5 000 contactos, con aviso a los 1 000. Por encima de eso casi siempre debería ser un segmento, y el aviso lo enseña en vez de bloquearlo. |
| OQ-CRM-06 | ¿Una vista guardada puede referenciar un segmento dinámico? | FS-CRM-0003 | Sí. El DSL ya lo permite y es la forma natural de decir “de mis clientes VIP, los de esta región”. |
| OQ-CRM-07 | Rango de fechas por defecto del timeline cuando no se entrega | FS-CRM-0004 | 90 días. Rechazar es correcto pero hostil para el primer integrador; 90 días cubre casi toda consulta de soporte y respeta el predicado de partición. |
| OQ-CRM-08 | Timeout por fuente antes de degradar | FS-CRM-0004 | 300 ms. Con las fuentes en paralelo, el presupuesto de 1 s aguanta un timeout de 300 ms más la mezcla. |
Grupo B — Son del abogado (7)
Estas no se responden por intuición. Van en el mismo paquete quelegal/ cuando lo revise.
| ID | Pregunta | Afecta | Nota para el abogado |
|---|---|---|---|
| OQ-LEG-01 | ¿El consentimiento caduca tras un período de inactividad? | FS-CORE-0004 | Algunas interpretaciones de la Ley 21.719 lo sugieren. Si caduca, hay que definir el plazo y el flujo de re-consentimiento. |
| OQ-LEG-02 | Mínimo legal de retención del registro de auditoría | FS-CORE-0005 | ¿5 años por cercanía tributaria, o menos para entidades no financieras? Determina el piso bajo la política por plan. |
| OQ-LEG-03 | ¿Aceptamos una columna de consentimiento en importaciones CSV? | FS-CORE-0013 | Un tenant afirmando que tiene consentimiento no es lo mismo que tenerlo. ¿Nos deja expuestos como encargados? |
| OQ-LEG-04 | ¿El tenant tiene ventana para objetar antes de una supresión? | FS-CORE-0014 | El titular ejerce ante el responsable, que es el tenant. ¿Podemos ejecutar sin su confirmación? |
| OQ-LEG-05 | ¿Cuánto retenemos subject_requests tras completarse? | FS-CORE-0014 | Es la prueba de que cumplimos. ¿Hay máximo, o se conserva indefinidamente? |
| OQ-LEG-06 | ¿La caducidad de puntos tiene límites legales en los países soportados? | FS-LOY-0002, OQ-LOY-29 | Protección al consumidor. Determina si la política por defecto de las plantillas verticales es siquiera legal. |
| OQ-LEG-07 | Proceso ante bloqueo del último owner de una organización | FS-IDN-0005 | ¿Qué verificación de identidad es suficiente y defendible para restaurar acceso? |
Grupo C — Son comerciales (10)
No bloquean ningún spec. Se responden con el ejercicio de pricing (P-3).| ID | Pregunta | Afecta |
|---|---|---|
| OQ-COM-01 | ¿Los roles personalizados se gatean por plan? | FS-IDN-0002 |
| OQ-COM-02 | ¿El SSO empresarial es tier enterprise o está en todos los planes? | FS-IDN-0008 |
| OQ-COM-03 | ¿El add-on de dominio propio es por dominio o por tenant? | FS-MSG-0008 |
| OQ-COM-04 | ¿El SMS se incluye en un plan o es siempre pago por uso? | FS-MSG-0009 |
| OQ-COM-05 | ¿Cuántos programas incluye el plan base? | FS-LOY-0001 |
| OQ-COM-06 | ¿Cuántas definiciones de atributos por tenant, y se gatea por plan? | FS-CORE-0011 |
| OQ-COM-07 | Tamaño máximo de archivo y filas por importación, ¿gateado por plan? | FS-CORE-0013 |
| OQ-COM-08 | ¿El almacenamiento se mide por bytes en base, en archivo exportado, o ambos? | FS-CORE-0010 |
| OQ-COM-09 | ¿Un spend cap detiene la Runtime API o solo los efectos facturables? | FS-CORE-0010 |
| OQ-COM-10 | P-3: precios unitarios por métrica | ADR-016 |
track rompe el punto de venta de un cliente por
una deuda comercial, y eso es un daño desproporcionado; dejar de acreditar puntos y de enviar
mensajes duele donde tiene que doler sin romper la operación.
Grupo D — Bloqueada por un ADR (1)
| ID | Ítem | Naturaleza |
|---|---|---|
| OQ-ADR-01 | Proveedor de SMS y cobertura por país | Investigación, no decisión. El FS-MSG-0009 no sale de draft hasta que exista el ADR. |
Cómo se cierra una
- Respondes
OQ-XXX-NN: <decisión>. - La decisión entra en la sección normativa del spec y desaparece de su tabla de preguntas.
- El spec sube de versión y pasa a
review, luego aapprovedcon tu visto bueno. - La traducción se actualiza en el mismo cambio — el validador
translationlo exige. - La fila se marca cerrada con fecha y respuesta.
Changelog
| Versión | Fecha | Cambio | Por qué | Autor |
|---|---|---|---|---|
| 2.0.0 | 2026-08-17 | Registro inicial: 70 preguntas de identity, core, messaging y crm, agrupadas por quién decide | Separar 52 decisiones tuyas de 7 del abogado y 10 comerciales, para que responder el grupo A desbloquee 37 specs | daniel + claude-opus-5 |