> ## Documentation Index > Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt > Use this file to discover all available pages before exploring further. # Registro de Preguntas Abiertas — Módulos restantes (v2.0) > Consolida las 70 preguntas únicas de identity, core, messaging y crm. Formato de respuesta: OQ-XXX-NN: respuesta. Cada una lleva mi recomendación (REC). Las de fidelización se cerraron en open-questions-v1.md. ## 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 | Si respondes solo el grupo A, los 37 specs pasan a `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 que `legal/` 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 | Sobre **OQ-COM-09**, que es la única con consecuencia técnica: mi recomendación es que **detenga los efectos facturables pero no la ingesta**. Rechazar `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 1. Respondes `OQ-XXX-NN: `. 2. La decisión entra en la sección normativa del spec y desaparece de su tabla de preguntas. 3. El spec sube de versión y pasa a `review`, luego a `approved` con tu visto bueno. 4. La traducción se actualiza en el mismo cambio — el validador `translation` lo exige. 5. 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 |