Changelog
Qué hay de nuevo.
Cada mejora de la plataforma, a medida que se envía.
· MCPGatewayService
Identity_request_confirmation; una solicitud que el miembro confirmó en Kamo es su pedido
Propietario 2026-10-26: las órdenes directas deben ser autenticadas. Alguien que solo dice ser un compañero de equipo (teléfono, texto, correo electrónico no probado, chat en el sitio web, reunión) se le pide, a través de kamoai-service, para confirmar en su aplicación Kamo registrada; al SI se le dice en palabras claras qué hacer Una vez confirmado, RequestVerifier responde el orden de la ejecución y la solicitud desde ese punto Confirmación (auth:<id>): el miembro lo garantiza, por lo que la impureza del canal no cuenta y SI_AUTH_REQUEST nunca llega a un SI, sino que se ejecuta en la ventana.
· SecurityService
Aplicar una personalidad generada a la propia carta de un SI, en torno a lo que las personas establecen
Realismo de voz VR2, decisión del propietario D2: cada SI recibe una voz única y adaptada al trabajo Personalidad, generada a partir de su propio trabajo. kamoai-service lo redacta; este El punto final interno (KamoAI secreto) aplica sus elementos PERSONALITY y VOICE al La forma en que lo hace un salvado: validado por las propias reglas del charter, rechazado por la autoridad El lenguaje, escrito por MemberCharterWriter, marcado AI_DRAFT, anunciado para que el El tiempo de ejecución vuelve a leer la carta y se audita como AI_CONFIGURATION_APPLIED. Los artículos que una persona establece siempre se mantienen; una generación anterior se reemplaza.
· kamo-internal
La opción de invitación de reunión se estrecha, por defecto no hay límite adicional
Decisión del propietario 2026-10-26: el propio acceso del SI decide quién puede invitarlo (cualquier persona del equipo cuando incluye reuniones, de lo contrario solo sus supervisores); esta opción, listada primero como la predeterminada, solo restringe eso.
· MediaService
Los propios derechos del SI deciden quién puede invitarlo a una reunión
Decisión del propietario 2026-10-26, en la comprobación compartida (MeetSiInvitePolicy) detrás de la invitación en la reunión, M1, reunión Crear y el selector M3: - los supervisores del SI (líneas de reporte, propietario de la organización) siempre pueden invitarlo: su orden directa le presta su política; - cualquier otra persona en su organización puede cuando los derechos propios del SI aplicados incluyen VIEW_MEETINGS (el derecho propio meetings_join y M1 join need), y se une con su propio acceso; su opcional meeting_invite_policy puede restringirlo; - de lo contrario 403 SI_NEEDS_SUPERVISOR (o NOT_ALLOWED_TO_INVITE_THIS_SI para la restricción opcional). La lista de salas ahora también devuelve los SIs que esta persona no puede invitar como LOCKED con lockedReason, por lo que el panel puede Derechos leídos en ix_mra_member_right; ilegible = solo para supervisores.
· AIService
La opción de invitación de reunión es una restricción opcional, por defecto ninguna
Decisión del propietario 2026-10-26: los propios derechos del SI deciden quién puede invitarlo (cualquier miembro del equipo cuando incluyen reuniones, De lo contrario solo sus supervisores). **************** ahora por defecto es ORGANIZACION (no DDL **************** aplicado (por defecto + la restricción); Cuatro filas que solo llevaban el antiguo valor por defecto).
· kamo-shared-library
Los propios derechos del SI deciden quién puede invitarlo; meeting_invite_policy es solo una restricción opcional
Decisión del propietario 2026-10-26: un SI cuya propia política de seguridad permite reuniones puede ser invitado por cualquier miembro del equipo; Cuya política no se hace solo por sus supervisores (su orden directa le presta su política) como una restricción adicional opcional cuyo valor por defecto, ORGANIZATION, no restringe nada (era SUPERVISORS).
· kamo-shared-library
Cada SI habla por su personalidad, y las tablas de sonido de fondo, consentimiento de voz y memoria de frase de llamada
PhoneStyle compila los rasgos de un SI en reglas telefónicas habladas (contracciones y formas de dirección, calidez, humor, energía, cobertura, empatía, curiosidad, registro, (texto regional) más los números que aplica la canalización de voz: un tope de llenado por llamada (D3, apagado hasta el A/B), la brecha entre los sonidos de escucha (D4), la risa y el rango de emoción (D6), el tono de reposo y la paciencia al final del turno Sin personalidad aún habla con los valores predeterminados del registro (D2). AiAmbienceSetting (D7), AiVoiceCloneConsent (D12) y KamoInitializer puede recrear las nuevas tablas de kamoai-service.
· MediaService
Los SI juegan Texas Hold'em con los miembros, y el Cheddar de cada miembro funciona de nuevo
SITP TPGAMES (propietario 2026-10-26). Cartera de Cheddar: - La única puerta de la billetera (universe-gateway -> universe-persistence) ha tenido No hay puntos finales desde que el juego KamoUniverse fue aparcado el 2026-09-28, por lo que cada Hold'em buy-in desde que ha fallado ('la billetera Cheddar no está respondiendo'), CheddarLedger escribe las mismas tres tablas en el mismo archivo, pero en diferentes direcciones Base de datos kamouniverse directamente (mismo clúster, usuario de la propia base de datos de este servicio), con las reglas del servicio de persistencia: una transacción por movimiento, Clave de idempotencia (repetición = aplicado falso), línea de libro mayor firmada; un débito es un Actualización condicional para que dos buy-ins no puedan sobredibujar. CheddarWalletClient ahora La gente lo usa. - La subvención de inscripción única (1.000.000, clave signup_grant:<id>), que solo El mundo 3D estacionado jamás hecho, se hace la primera vez que la billetera de un miembro es Tocado a través de una aplicación de juegos que tienen - persona o SI lo mismo. CheddarSiGrants abre la cartera de cada SI no jubilado por adelantado (por hora, singleton, paginado por los ids de los miembros de la lista SI; nada más tocado). Cheddar no tiene ruta de compra, por lo que ningún SI lo compra nunca con dinero. Texas Hold'em SI: - HoldemSiBrain: Equidad de Monte Carlo sobre HandEvaluator vs los oponentes en vivo, Pot odds, estilo CAUTIOUS/BALANCED/BOLD y habilidad CASUAL/CLUB/SHARP, 300 ms Su única entrada es el HoldemTableView del SI por receptor: posee dos Las cartas y la información pública, nunca otras cartas o la baraja. - HoldemSiPlayer: impulsado por eventos (HoldemTurnEvent después de cada fotograma publicado, ~1.4-2.3 s pausa dentro del reloj de 30 s). Se sienta cuando una persona lo invitó y Está sentado, actúa a través de HoldemGameService.act con expectedSeq, recompras en 3 veces al día por mesa, se sienta con una persona que está sentada y se va Cuando no queda ninguna persona: los SI nunca juegan entre ellos. Redis reclamación por tabla; estilo/habilidad por SI por tabla en Redis. - HoldemSiEligibility cada paso: aplicación Hold'em, PLAY_HOLDEM (SI, o el Persona invitada/sentada: No Insubordinación), tiempo de ejecución no pausado. - POST /tables/{id}/si-play (estilo, habilidad), solo el SI que llama. - ChessFaces lee el host del tema fuera de la transacción (trinquete), en caché. Pruebas: CheddarLedgerTest 4 (H2), HoldemSiBrainTest 5, HoldemSiFairnessTest 3 (la vista del SI no tiene cartas de otros jugadores ni mazo; cartas ocultas No puede cambiar la decisión; el jugador no tiene puerta a filas de manos crudas), HoldemSiPlayerTest 7; suites de juegos 240 verde.
· MCPGatewayService
Mail_send toma una versión de texto plano del cuerpo HTML y un archivo de texto escrito por el llamador (TPRECAPS)
El resumen de la reunión del SI ahora lleva la transcripción completa de la reunión; más allá del límite del cuerpo, va como un archivo adjunto .txt. textBody (con bodyFormat HTML) se convierte en la parte de texto multiparte/alternativa; textAttachmentName + textAttachment se convierten en Una parte de adjuntos (nombre guardado en caracteres seguros, .txt) El texto adjunto está planeado con el cuerpo para su divulgación. Listas de herramientas doradas regeneradas (mail_send solamente).
· EmailService
Datos del remitente de un mensaje para comprobaciones de identidad SI; SI_AUTH_REQUEST no pertenece a ninguna aplicación
La respuesta de procedencia ahora también dice lo que el propio mensaje afirma acerca de su remitente: De, Responder-A, el servidor que lo entregó al nuestro, y los resultados SPF/DKIM/DMARC registrados en su SI_AUTH_REQUEST no está marcado: cualquiera puede ser preguntado por el servidor de autenticación Un SI para confirmar una solicitud era realmente ellos.
· kamo-shared-library
Tipo de notificación SI_AUTH_REQUEST y las entidades de registro de autenticación SI
Propietario 2026-10-26: órdenes directas que llegan a un SI a través de un canal que no prueba la identidad de nadie Todos los anuncios son confirmados por el miembro en Kamo primero. Añade **************** (pertenece a no app), declara si_auth_requests / si_auth_request_events (DDL aplicado a mano en kamoai-service **************** y el índice media_session_guid de support_ticket.
· kamo-internal
Elegir quién puede invitar a un SI a las reuniones, en sus opciones de llamada
Kamo Meet "Invitar a un SI" (orden del propietario 2026-10-26): Solo las personas que lo supervisan (por defecto) / Sus supervisores y Compañeros de equipo / Cualquier persona en su organización, con una explicación en palabras claras de cada uno. MediaService lo hace cumplir.
· MediaService
Invitar a un SI desde dentro de la reunión; quién puede invitar a un SI es la propia opción del SI
Kamo Meet "Invitar a un SI" (orden del propietario 2026-10-26): - GET **************** para una persona inscrita EN la reunión (creador, participante registrado, o entregado el token de esta sala por el sidecar de la reunión desde su propia sesión: marca MEETPRES), los SIs activos de la organización que Puede invitar, agrupado SUPERVISIÓN / DISPONIBLE, con foto (foto -> avatar), título de trabajo y disponibilidad (disponible, Nunca ha habido un SI en esta reunión o en camino a ella (no está en línea pero puede unirse, en otra llamada, en pausa, no disponible) (participante en vivo, invitación de unión automática, ai_call en vivo en ella); uno que quedó se muestra de nuevo. - POST .../invitable-sis/{memberId}: lo trae ahora a través de la ruta de una instancia de M1 (upsert participante, exclusivo Dial claim; el índice de llamadas en vivo único de kamoai-service detrás de él): clics simultáneos o dos personas realizan una llamada. - MeetSiInvitePolicy: supervisores (línea de informes del gráfico de la organización, propietario de la organización) siempre; otros por los SI meeting_invite_policy (SUPERVISORS default | TEAM | ORGANIZATION). Se aplica en M1 y crea reuniones para personas, El selector de M2 y M3 ofrece solo SIs invitables (con "supervised").Los SIs mantienen la regla TP12 SI-to-SI. - Búsqueda de habitación en **************** anfitrión del tema a través de ViewerThemeDomain fuera de cualquier transacción.
· AIService
Quién puede invitar a este SI a las reuniones, en sus opciones de llamada
Kamo Meet "Invitar a un SI" (orden del propietario 2026-10-26): meetingInvitePolicy (SUPERVISORS default | TEAM | ORGANIZACIÓN) leído y cambiado junto con las otras opciones de llamadas y reuniones del SI, los mismos derechos; almacenado en **************** (DDL) **************** MediaService lo hace cumplir.
· kamo-shared-library
MeetingInvitePolicy — quién puede invitar a un SI a una reunión; declarar ai_member_call_options
Kamo Meet "Invitar a un SI" (orden del propietario 2026-10-26). Los supervisores de un SI (su línea de reporte sobre el gerente y El supervisor de SI (o el propietario de la organización) siempre puede invitarla; su propia política meeting_invite_policy dice quién más puede: SUPERVISORS (por defecto), TEAM (equipo con nombre, mismo gerente, sus informes) u ORGANIZATION (organización). AiMemberCallOptionsRow declara la tabla ai_member_call_options hecha a mano (y la nueva columna) de modo que KamoInitializer Puedes crearlo desde código.
· MCPGatewayService
Games_* - un SI juega al ajedrez con los miembros
SITP TPGAMES. Once herramientas sobre los endpoints de ajedrez de MediaService, El tablero del miembro es (Ajedrez app + PLAY_CHESS, de nuevo abajo): games_list, games_get_state (diagrama, FEN, movimientos legales, texto de movimiento, registro), games_invite (habilidad opcional), games_join, games_decoder, games_move (SAN o cuadrados, validated server-side), juegos_oferta_sorteo, juegos_decodificador_sorteo, juegos_renuncia, games_rematch, games_set_skill. Los movimientos del SI son jugados para él por El motor de MediaService; el modelo habla. Escritura interna: no Clase de aprobación, NOT_DISCLOSING; lee NOT_CONTENT. chat_read nombra el juego en Frases de aprobación + CHESS_GAME sustantivo; games_ prefijo; goldens Regenerado (11 añadidos). Pruebas: GamesPackTest 7, ChatPackTest +1; suite completa 1968 verde.
· EmailService
Una versión en texto plano junto al HTML, y una carta de resumen del SI para un supervisor cuando el SI no tiene buzón (TPRECAPS)
/api/email/send toma un textBody opcional: el cuerpo es entonces multipart/alternative (texto, luego el HTML), dentro de mixto POST **************** (KamoAI secret, multipart like /api/email/send) - Envía un mensaje de correo electrónico a un destinatario Envía una carta a su llamador construido como el correo transaccional de la organización: NoReply@ su dominio solo cuando ese dominio es SPF nos autoriza, de lo contrario la plataforma está bajo su nombre, con la versión de texto y hasta dos archivos.
· kamo-shared-library
Declarar ai_call_recap y ai_member_recap_options para el correo electrónico de resumen de llamadas de SI (TPRECAPS)
Una fila por llamada telefónica de SI que tuvo una conversación, por lo que su resumen llega al supervisor una vez; y un resumen de dos SI DDL aplicado a mano (kamoai-service) **************** Se declara aquí para que KamoInitializer pueda recrearlo.
· MCPGatewayService
Cada SI tiene un reloj: time_now, time_convert, time_calc
Informe del propietario 2026-10-26: preguntó la hora en una llamada, un SI dijo que no tenía reloj Cada persona tiene un calendario: la hora ahora en la zona del SI o cualquier otra (con el día de la semana) semana), una hora dicha en otra zona, y fecha aritmética. Lee, no derecho, no registro.
· MCPGatewayService
El correo electrónico comprobado de un compañero de equipo a un SI es su solicitud y su orden
Informe del propietario 2026-10-26: el propietario envió un correo electrónico a su SI para llamarlos; el correo electrónico nunca fue un Orden ([ORDEN] sin orden) y cada registro posterior lo leyó como correo externo y le preguntó al Mail EmailService demuestra que el propio buzón de un compañero de equipo enviado al SI es ahora dentro del correo (sentByTeammate, internal taint) y un wake o cita como un mensaje de chat: El autor, la fecha, la corrección y la impureza se comprueban. Un correo falso permanece fuera del correo.
· MediaService
Un miembro de SI juega ajedrez con otros miembros, sus movimientos son elegidos por el motor de Kamo
SITP TPGAMES (dueño 2026-10-26: un SI que pidió jugar al ajedrez no sabía cómo). - ChessSiPlayer: impulsado por eventos (ChessTurnEvent después de cada cambio confirmado). Invitación de un miembro: el SI se une y su mente se despierta una vez (un chat Envía una notificación en la conversación de la tarjeta) para saludarlos Oferta: aceptada a menos que el SI esté por delante por más de medio peón. ChessAi (alpha-beta + quiescencia, tiempo presupuestado) escoge el movimiento en el momento El nivel de SI y se juega como el SI a través de ChessGameService.move, el ~0.7 s de pausa, una tarea pendiente por juego, una tarea pendiente por juego, 200 por pod, Redis reclamaciones entre pods, FEN re-comprobado antes de la escritura. - ChessSiEligibility, cada movimiento: aplicación de ajedrez en, PLAY_CHESS aplicado, tiempo de ejecución No está en pausa/bloqueado/retirado. - Recuperación de barrido (singleton, 30 s) para un turno de reinicio o pausa perdido. - No hay tableros SI-vs-SI (invitación rechazada; no se juega por nadie). - Habilidad por partida (CASUAL/CLUB/MASTER, por defecto CLUB) en Redis, sin DDL; POST /games/{id}/si-level; movimientos escritos (SAN o e2e4) en /move. - El tablero muestra la foto del oponente (opponentAvatarUrl siempre era nulo), opponentIsSi y siLevel. - Corrección: un ChessAi compartido por cada solicitud corrió sus propios campos de fecha límite. Pruebas: ChessSiPlayerTest 11, ChessSiRulesTest 15, análisis de consultas 1; ajedrez y Suites de juegos verdes (100).
· EmailService
Demostrar que un compañero de equipo envió un correo electrónico de un SI, por lo que una solicitud enviada por correo electrónico puede contar como su pedido
Un extremo interno responde si un mensaje en el propio buzón de un miembro fue enviado por un compañero de equipo: su From llega a un miembro de la misma organización, y la propia carpeta Sent de ese miembro contiene Un From falsificado nunca pasa; es un mensaje de solo lectura.
· kamo-internal
Pipeline muestra cuándo se abrió cada negocio y préstamo, y ordena por ello
Las ofertas y los préstamos muestran "Abierto <fecha, hora>" en la zona del miembro importado desde Arive, que es el tiempo de creación de Arive — antes, cada vez que se importa El día de la importación, la operación se ordena según su apertura.
· SecurityService
Los préstamos en canalización abiertos en Arive llevan el tiempo de creación de Arive, no el de la importación
· kamo-shared-library
Los resúmenes de préstamos llevan cuando un préstamo MLOS realmente se abrió (openedAt)
· kamo-internal
Perspectivas: los acuerdos previos a la solicitud dejan la canalización abierta
Un acuerdo cuyos préstamos están todos en la toma, calificación o pre-aprobación (no Aplicación tomada todavía) se muestra bajo su propia vista y cuenta de prospectos. Abierto, Sus KPIs y el riel de la etapa ahora cuentan solo las aplicaciones en curso; Kamo Los borradores propios permanecen en Abierto. Nada cambia en los préstamos.
· kamo-internal
Pipeline muestra las etapas previas a la solicitud, todos los resultados y los préstamos archivados
- estados: Admisión de solicitud, Calificación, Pre-aprobado; Aprobado No Aceptado, Cerrado por Incompleto, Rescindido, Preaprobación Denegada / No aceptado: una lista compartida en lugar de dos copias codificadas - tablero y acuerdos: los préstamos archivados dejan la tubería abierta (se muestra bajo pasado, Archivado); los resultados no financiados cuentan como cancelados - "enviado" ya no es statusId >= 2 (id son identidades, no orden) - Arive mapa de etapas ofrece los estados de pre-aplicación
· SecurityService
Kamo tiene cada Arive préstamo, en el estado Arive realmente lo tiene
- los eventos de importación y recepción adoptan todos los préstamos: abiertos, financiados, adversos o Archivados — en lugar de solo los "activos" - sin sello Get Loan o crmReferenceId por préstamo: cada uno es una tarea Zapier en el Plan del cliente (20,000+ para una importación); el GUID reconoce el préstamo - Las fechas de Arive se aplican como el sistema de registro (desactivado donde Arive tiene ninguna, por ejemplo, una fecha de solicitud en un archivo previo a la solicitud) - una etapa detrás de Kamo se realinea, en el registro, en lugar de ser rechazada - Cubierta de guardias de solo borrador (ediciones del prestatario, envío propio, extracción de crédito SI / AUS) Las etapas previas a la solicitud; "enviado" ya no es statusId >= 2
· kamo-shared-library
Estado previo a la solicitud, todos los resultados de HMDA, archivo y fechas reales de Arive
Arive préstamos fueron mapeados solo a partir de los nombres de las etapas: cada etapa previa a la solicitud Se convirtió en Aplicación Tomada, cada préstamo archivado Retirado (los financiados también), Denegada, y las fechas se estamparon con el día de importación. - LoanFileStatus (anexado — columna ordinal): APPLICATION_INTAKE, CALIFICACIÓN, PRE_APROBADA; resultados APPROVED_NOT_ACCEPTED, INCOMPLETE, RESCINDIDO, PREAPPROVAL_DENIED, PREAPPROVAL_NOT_ACCEPTED - máquina de estado: flechas de pre-aplicación opcionales; cada resultado solo desde el Los estados que puede seguir - LoanFile.archivedAt: archivo es una bandera junto al estado, no un resultado - Arive: etapa ADVERSA + mapa AriveAdverseReason a su propio resultado (ambos Configuración del préstamo = Aplicación tomada, Divulgada = En proceso; fechas desde Arive (fecha de TRID, documentos firmados, transferencia de fondos, fechas de las etapas), nunca hoy - realignToExternal: el MLOS externo es el sistema de registro para la etapa - Acción HMDA tomada del resultado real; los archivos en progreso no tienen ninguno - Comercio / transacción rollup / cerrar horizonte manejar los nuevos estados
· kamo-internal
El MLOS externo vive en el mercado hipotecario y en cada préstamo
- Configuración → Mercados POS → Mercado hipotecario: nueva pestaña "MLOS externo" (Arive vía Zapier, MeridianLink) con conexión, mapa de etapas, transacción y la importación de préstamos activos; el selector MLOS de mercado líder es Reemplazado por un puntero a él - Solicitud de préstamo: una barra de estado que muestra el lugar del préstamo en el externo MLOS (enlazado / envío / necesita campos / rechazado), volver a enviar y abrir en MLOS; Las secciones que posee el MLOS son de solo lectura con una nota diciendo dónde editarlas - Tarjeta de acuerdo de tubería: chip MLOS externo - página principal: Arive/MeridianLink acciones eliminadas - las rutas proxy se mueven a ****************
Tu universo está esperando.
Comience gratis en minutos y agregue productos cuando esté listo, sin migración ni nuevos inicios de sesión.
Gratis para siempre: no se requiere tarjeta de crédito