Ir para o conteúdo
KAMOUniverse

Changelog

O que há de novo.

Cada melhoria para a plataforma, como ele envia.

  1. · MCPGatewayService

    Identity_request_confirmation; uma solicitação que o membro confirmou em Kamo é seu pedido

    Proprietário 2026-10-26: ordens diretas devem ser autenticadas. Alguém que só diz ser um proprietário companheiro de equipe (telefone, texto, e-mail não comprovado, chat do site, reunião) é solicitado, através kamoai-service, para confirmar em seu aplicativo Kamo conectado; o SI é informado em palavras simples o que fazer Uma vez confirmado, o RequestVerifier responde a ordem da execução e a requisição daquele confirmação (auth:<id>): o membro garantiu por isso, então a mancha do canal não conta e SI_AUTH_REQUEST nunca atinge um SI, pois o SI não possui uma data de expiração.

  2. · SecurityService

    Aplicar uma personalidade gerada ao próprio estatuto de um SI, em torno do que as pessoas definem

    Realismo de voz VR2, decisão do proprietário D2: cada SI obtém uma voz única e adequada ao trabalho personalidade, gerada a partir de seu próprio trabalho. kamoai-serviço elabora-lo; este endpoint interno (KamoAI secreto) aplica seus itens PERSONALITY e VOICE ao do jeito que um salvamento faz: validado pelas próprias regras da carta, recusado por autoridade linguagem, escrito por MemberCharterWriter, marcado AI_DRAFT, anunciado para que o O tempo de execução re-lê a carta e é auditado como AI_CONFIGURATION_APPLIED. Os itens que uma pessoa define são sempre mantidos; uma geração anterior é substituída.

  3. · kamo-internal

    A opção de convite de reunião se estreita, por padrão sem limite extra

    Decisão do proprietário 2026-10-26: o próprio acesso do SI decide quem pode convidá-lo (qualquer um na equipe quando inclui reuniões, caso contrário apenas seus supervisores); esta opção, listada primeiro como padrão, apenas restringe isso.

  4. · MediaService

    Os próprios direitos do SI decidem quem pode convidá-lo para uma reunião

    Decisão do proprietário 2026-10-26, na única verificação compartilhada (MeetSiInvitePolicy) por trás do convite na reunião, M1, reunião criar e o seletor M3: - os supervisores do SI (linha de reporte, dono da organização) podem sempre convidá-lo: sua ordem direta lhe empresta sua política; - qualquer outra pessoa em sua organização pode quando os direitos aplicados do SI incluem VIEW_MEETINGS (o direito próprio meetings_join e M1 join need), e ele se junta com seu próprio acesso; seu opcional meeting_invite_policy pode restringi-lo; - caso contrário 403 SI_NEEDS_SUPERVISOR (ou NOT_ALLOWED_TO_INVITE_THIS_SI para a restrição opcional). A listagem de salas agora também retorna os SIs que essa pessoa não pode convidar como LOCKED com lockedReason, para que o painel possa Direitos de leitura em ix_mra_member_right; ilegível = somente supervisores.

  5. · AIService

    A opção de convite de reunião é uma restrição opcional, nenhuma por padrão

    Decisão do proprietário 2026-10-26: os próprios direitos do SI decidem quem pode convidá-lo (qualquer membro da equipe quando eles incluem reuniões, **************** agora é padrão para ORGANIZAÇÃO (não é necessário) restrição); DDL **************** aplicado (padrão + o quatro linhas que carregavam apenas o antigo padrão).

  6. · kamo-shared-library

    Os próprios direitos do SI decidem quem pode convidá-lo; meeting_invite_policy é apenas uma restrição opcional

    Decisão do proprietário 2026-10-26: um SI cuja própria política de segurança permite reuniões pode ser convidado por qualquer membro da equipe; cuja política não é feita apenas por seus supervisores (sua ordem direta lhe empresta sua política) como uma restrição extra opcional cujo padrão, ORGANIZATION, não restringe nada (era SUPERVISORS).

  7. · kamo-shared-library

    Cada SI fala por sua personalidade, e as tabelas para som de fundo, consentimento de voz e memória de frase do chamador

    PhoneStyle compila traços de um SI em regras de telefone falado (contrações e formas de endereçamento, calor, humor, energia, cobertura, empatia, curiosidade, registro, regional) mais os números que o pipeline de voz aplica: uma tampa de enchimento chamada (D3, desligado até o A/B), o intervalo entre os sons de audição (D4), riso e emoção (D6), o tom de repouso e a paciência no final do turno sem personalidade ainda fala com os padrões de registro (D2). AiAmbienceSetting (D7), AiVoiceCloneConsent (D12) e AiCounterpartyMemory são declarado para que KamoInitializer possa recriar as novas tabelas do kamoai-service.

  8. · MediaService

    Os SIs jogam Texas Hold'em com os membros, e o Cheddar de cada membro funciona novamente

    SITP TPGAMES (proprietário 2026-10-26). Cheddar de carteira: - A única porta da carteira (universe-gateway -> universe-persistence) teve não há pontos finais desde que o KamoUniverse jogo foi estacionado em 2026-09-28, então cada Hold'em buy-in desde que falhou ('a carteira Cheddar não está respondendo'), CheddarLedger escreve as mesmas três tabelas no arquivo .csv, kamouniverse banco de dados diretamente (mesmo cluster, usuário de banco de dados próprio deste serviço), com as regras do serviço de persistência: uma transação por movimento, chave de idempotência (replay = aplicado false), linha de livro-razão assinada; um débito é um atualização condicional para que dois buy-ins não possam ser sobrecarregados. CheddarWalletClient agora usa-o. - O subsídio de inscrição único (1.000.000, chave signup_grant:<id>), que só o mundo 3D estacionado já feito, é feito a primeira vez que uma carteira de um membro é tocado através de um aplicativo de jogos que eles têm - pessoa ou SI o mesmo. CheddarSiGrants abre a carteira de cada SI não aposentado com antecedência (a cada hora, singleton, paginado pelos ids de membros da lista SI; nada mais tocado). Cheddar não tem caminho de compra, então nenhum SI compra com dinheiro. Hold'em SI: - HoldemSiBrain: equidade de Monte Carlo sobre HandEvaluator vs os adversários ao vivo, pot odds, estilo CAUTIVO/BALANCEADO/BOLD e habilidade CASUAL/CLUB/SHARP, 300 ms Sua única entrada é o HoldemTableView per-recipient do SI: possui dois cartas e informações públicas, nunca outras cartas ou o baralho. - HoldemSiPlayer: evento-driven (HoldemTurnEvent após cada quadro publicado, ~1.4-2.3 s pausa dentro do relógio de 30 s). senta quando uma pessoa o convidou e está sentado, age através de HoldemGameService.act com expectedSeq, rebuys em no máximo 3 vezes por dia por mesa, senta-se com uma pessoa sentada e sai quando não resta nenhuma pessoa: os SIs nunca jogam entre si. Redis reclamação por tabela; estilo/habilidade por SI por tabela em Redis. - HoldemSiEligibility cada passo: Hold'em app, PLAY_HOLDEM (SI, ou o pessoa convidada/sentada: Sem insubordinação), tempo de execução não pausado. - POST /tables/{id}/si-play (style, skill), o chamador é apenas SI. - ChessFaces lê o host do tema fora da transação (catraca), em cache. Testes: CheddarLedgerTest 4 (H2), HoldemSiBrainTest 5, HoldemSiFairnessTest 3 (a visão do SI não contém cartas de outros jogadores e nenhum baralho; cartas escondidas não pode mudar a decisão; o jogador não tem porta para linhas de mão cruas), HoldemSiPlayerTest 7; suites de jogos 240 verde.

  9. · MCPGatewayService

    Mail_send leva uma versão de texto simples do corpo HTML e um arquivo de texto escrito pelo chamador (TPRECAPS)

    O resumo da reunião do SI agora carrega a transcrição completa da reunião; além do limite do corpo, ele é enviado como um anexo .txt. textBody (com bodyFormat HTML) torna-se a parte de texto multiparte/alternativa; textAttachmentName + textAttachment tornam-se uma parte de anexos (nome mantido em caracteres seguros, .txt) O texto anexado é planejado com o corpo para divulgação. Listas de ferramentas douradas regeneradas (somente mail_send).

  10. · EmailService

    Fatos do remetente de uma mensagem para verificações de identidade SI; SI_AUTH_REQUEST não pertence a nenhum aplicativo

    A resposta de proveniência agora também diz o que a própria mensagem afirma sobre seu remetente: From, Reply-To, o servidor que o entregou ao nosso e os resultados SPF/DKIM/DMARC registrados em seu SI_AUTH_REQUEST não está marcado: qualquer um pode ser solicitado por qualquer usuário um SI para confirmar que um pedido era realmente deles.

  11. · kamo-shared-library

    Tipo de notificação SI_AUTH_REQUEST e as entidades de log de autenticação SI

    Proprietário 2026-10-26: ordens diretas chegando a um SI por um canal que não prova a identidade de ninguém As alterações são confirmadas pelo membro em Kamo primeiro. Anexa **************** (pertence a no app), declara si_auth_requests / si_auth_request_events (DDL aplicado à mão em kamoai-service **************** e o índice media_session_guid de support_ticket.

  12. · kamo-internal

    Escolha quem pode convidar um SI para reuniões, em suas opções de chamada

    Kamo Meet "Convidar um SI" (ordem do proprietário 2026-10-26): Somente as pessoas que o supervisionam (padrão) / Seus supervisores e Companheiros de equipe / Qualquer pessoa em sua organização, com uma explicação em palavras simples de cada um. O MediaService aplica-o.

  13. · MediaService

    Convidar um SI de dentro da reunião; quem pode convidar um SI é opção do próprio SI

    Kamo Meet "Convidar um SI" (ordem do proprietário 2026-10-26): - GET **************** para uma pessoa inscrita na reunião (criador, participante gravado, ou entregou o token desta sala pelo sidecar da reunião de sua própria sessão: marca MEETPRES), os SIs ativos da organização que eles podem convidar, agrupados SUPERVISTOS/DISPONÍVEIS, com foto (foto -> avatar), cargo e disponibilidade (disponível, não está online, mas pode ingressar, em outra chamada, em pausa, indisponível).Nunca um SI em ou a caminho para esta reunião (participante ao vivo, convite de participação automática, ai_call ao vivo nele); um que ficou é listado novamente. - POST .../invitable-sis/{memberId}: traz-o agora através do caminho de uma instância do M1 (upsert participante, exclusivo dial claim; kamoai-service's live-call index behind it): cliques simultâneos ou duas pessoas fazendo uma chamada. - MeetSiInvitePolicy: supervisores (linha de relatório do gráfico da organização, proprietário da organização) sempre; outros por SI meeting_invite_policy (SUPERVISORS padrão | TEAM | ORGANIZAÇÃO). Imposto no M1 e na criação de reuniões para pessoas, e o seletor do M3 oferece apenas SIs convidados (com "supervised").SIs mantêm a regra TP12 SI-to-SI. - Pesquisa de sala no host de temas **************** via ViewerThemeDomain fora de qualquer transação.

  14. · AIService

    Quem pode convidar este SI para reuniões, em suas opções de chamada

    Kamo Meet "Convidar um SI" (ordem do proprietário 2026-10-26): meetingInvitePolicy (SUPERVISORS default | TEAM | ORGANIZAÇÃO) lido e alterado ao lado de outras opções de chamada e reunião do SI, mesmos direitos; armazenado em **************** (DDL **************** O MediaService o impõe.

  15. · kamo-shared-library

    MeetingInvitePolicy — quem pode convidar um SI para uma reunião; declare ai_member_call_options

    Kamo Meet "Convidar um SI" (ordem do proprietário 2026-10-26). Os supervisores de um SI (sua linha de reporte sobre o gerente e O supervisor (ou seja, o proprietário da organização) sempre pode convidá-lo; sua própria meeting_invite_policy diz quem mais pode: SUPERVISORS (padrão), TEAM (equipe nomeada, mesmo gerente, seus relatórios) ou ORGANIZATION (organização). AiMemberCallOptionsRow declara a tabela feita à mão ai_member_call_options (e a nova coluna) para KamoInitializer pode construí-lo a partir do código.

  16. · MCPGatewayService

    Games_* - um SI joga xadrez com membros

    SITP TPGAMES. Onze ferramentas sobre os endpoints de xadrez do MediaService, O tabuleiro do membro é (aplicativo de xadrez + PLAY_CHESS, novamente downstream): games_list, games_get_state (diagrama, FEN, movimentos legais, texto de movimento, registro), games_invite (habilidade opcional), games_join, games_decoder, games_move (SAN ou quadrados, validated server-side), games_offer_draw, games_decoder_draw, games_resign, games_rematch, games_set_skill. Os movimentos do SI são jogados para ele por O motor do MediaService; o modelo fala. Gravações internas: não Aprovação de classe, NOT_DISCLOSING; lê NOT_CONTENT. chat_read nomeia o jogo em um cartão GAME_INVITE. Frases de aprovação + CHESS_GAME substantivo; games_ prefixo; goldens regenerado (11 adicionados). Testes: GamesPackTest 7, ChatPackTest +1; suíte completa 1968 verde.

  17. · EmailService

    Uma versão em texto simples ao lado do HTML, e uma carta de resumo do SI para um supervisor quando o SI não tem caixa de correio (TPRECAPS)

    /api/email/send toma um texto opcional: o corpo é então multipart/alternativo (texto, depois o HTML), dentro misturado quando há anexos. POST **************** (KamoAI secreto, multipart como /api/email/send) envia uma carta seu chamador construído como o correio transacional da organização: NoReply@ seu domínio somente quando esse domínio é O SPF nos autoriza, caso contrário a plataforma está sob seu nome, com a versão de texto e até dois arquivos.

  18. · kamo-shared-library

    Declare ai_call_recap e ai_member_recap_options para o e-mail de resumo de chamada SI (TPRECAPS)

    Uma linha por chamada telefônica de SI que teve uma conversa, então seu resumo chega ao supervisor uma vez; e um resumo de dois SI DDL aplicado à mão (kamoai-service **************** Declarado aqui para que KamoInitializer possa recriá-lo.

  19. · MCPGatewayService

    Cada SI tem um relógio: time_now, time_convert, time_calc

    Relatório do proprietário 2026-10-26: perguntou a hora em uma chamada, um SI disse que não tinha relógio calendário que cada pessoa tem: o tempo agora na zona do SI ou qualquer outro (com o dia do semana), uma hora dita em outra zona, e data aritmética. Leituras, sem direito, sem registro.

  20. · MCPGatewayService

    O e-mail comprovado de um colega de equipe para um SI é o seu pedido e a sua ordem

    Relatório do proprietário 2026-10-26: o proprietário enviou um e-mail ao seu SI para chamá-los; o e-mail nunca foi um ordem ([ORDER] nenhuma ordem) e cada check-in posterior lê-lo como correio exterior e perguntou o O Mail EmailService prova que a caixa de correio de um colega de equipe enviada para o SI está agora dentro do e-mail (sentByTeammate, internal taint) e um wake ou citação como uma mensagem de bate-papo: Autor, data, correção e mancha, tudo verificado. Um From forjado fica fora do correio.

  21. · MediaService

    Um membro SI joga xadrez com membros, seus movimentos escolhidos pelo motor de Kamo

    SITP TPGAMES (proprietário 2026-10-26: um SI que pediu para jogar xadrez não sabia como). - ChessSiPlayer: conduzido por eventos (ChessTurnEvent após cada alteração confirmada). Um convite de um membro: o SI se junta e sua mente é despertada uma vez (um chat notificação na conversa do cartão) para cumprimentá-los oferta: aceita a menos que o SI esteja à frente por mais de meio peão. ChessAi (alpha-beta + quiescência, tempo-orçamentado) escolhe o lance no O nível do SI e é jogado como o SI através do ChessGameService.move, o mesmo caminho validado como um clique. ~0,7 s de pausa, uma tarefa pendente por jogo, 200 por pod, Redis reivindicações entre pods, FEN reverificado antes da gravação. - ChessSiEligibility, cada movimento: aplicativo de xadrez, PLAY_CHESS aplicado, tempo de execução não PAUSADO/BLOQUEADO/RETIRADO. - Varredura de recuperação (singleton, 30 s) para um turno de um reinício ou pausa perdida. - Sem placas SI-vs-SI (convite recusado; ninguém é jogado). - Habilidade por jogo (CASUAL/CLUB/MASTER, padrão CLUB) em Redis, sem DDL; POST /games/{id}/si-level; moves escritos (SAN ou e2e4) em /move. - O tabuleiro mostra a foto do adversário (opponentAvatarUrl era sempre nulo), opponentIsSi e siLevel. - Correção: um ChessAi compartilhado por cada solicitação corria seus próprios campos de prazo. Testes: ChessSiPlayerTest 11, ChessSiRulesTest 15, query parse 1; xadrez e suites de jogos verde (100).

  22. · EmailService

    Prove que um colega de equipe enviou um e-mail de um SI, para que um pedido enviado por e-mail possa contar como seu pedido

    Um endpoint interno responde se uma mensagem na caixa de correio de um membro foi enviada por um colega de equipe: seu De chega a um membro da mesma organização, e a pasta Enviado desse membro contém O mesmo Message-ID endereçado ao destinatário. Um From forjado nunca passa; somente leitura.

  23. · kamo-internal

    Pipeline mostra quando cada negócio e empréstimo foi aberto, e classifica por isso

    Os negócios e empréstimos mostram "Aberto <data, hora>" na zona do membro. Para empréstimos importado de Arive que é o tempo de criação de Arive — antes, cada importação negócio classificado como aberto no dia da importação.

  24. · SecurityService

    Empréstimos de pipeline abertos em Arive levam o tempo de criação de Arive, não o da importação

  25. · kamo-shared-library

    Os resumos de empréstimo carregam quando um empréstimo MLOS realmente abriu (openedAt)

  26. · kamo-internal

    Perspectivas — negócios de pré-aplicação deixam o pipeline aberto

    Um negócio cujos empréstimos são todos na entrada, qualificação ou pré-aprovação (não aplicação ainda não foi tomada) mostra sob sua própria visão e contagem de Perspectivas seus KPIs e o trilho de estágio agora contam apenas aplicativos em andamento; Kamo's Os rascunhos próprios permanecem em Aberto. Nada sobre os empréstimos muda.

  27. · kamo-internal

    Pipeline mostra estágios de pré-aplicação, todos os resultados e empréstimos arquivados

    - status: Recebimento de Aplicações, Qualificação, Pré-Aprovado; Aprovado Não Aceitado, Fechado por Incompleto, Rescindido, Pré-aprovação Negada / Não aceito — uma lista compartilhada em vez de duas cópias codificadas - bordo e negócios: empréstimos arquivados deixam o pipeline aberto (mostrado sob passado, Arquivado); resultados não financiados contam como cancelados - "enviado" não é mais statusId > = 2 (ids são identidades, não ordem) - Arive mapa de estágio oferece os status de pré-aplicação

  28. · SecurityService

    Kamo detém cada Arive empréstimo, no status Arive realmente o tem

    - eventos de importação e entrada adotam cada empréstimo - aberto, financiado, adverso ou arquivados — em vez de apenas os "ativos" - nenhum selo Get Loan ou crmReferenceId por empréstimo: cada um é uma tarefa Zapier no plano do cliente (20.000+ para uma importação); o GUID reconhece o empréstimo - As datas de Arive são aplicadas como o sistema de registro (limpo onde Arive tem nenhum, por exemplo, uma data de aplicação em um arquivo de pré-aplicação) - um estágio atrás de Kamo é realinhado, no registro, em vez de recusado - guardas somente de rascunho (edições de mutuário, submissão própria, puxar crédito SI / AUS) os estágios de pré-aplicação; "enviado" não é mais statusId >= 2

  29. · kamo-shared-library

    Status de pré-aplicação, todos os resultados do HMDA, arquivo e datas reais de Arive

    Arive empréstimos foram mapeados apenas a partir de nomes de estágios: cada estágio de pré-aplicação tornou-se Aplicação Tomada, cada empréstimo arquivado Retirado (os financiados também), todas as ações adversas foram Negadas, e as datas foram carimbadas com o dia da importação. - LoanFileStatus (anexado — coluna ordinal): APPLICATION_INTAKE, QUALIFICAÇÃO, PRE_APPROVED; resultados APPROVED_NOT_ACCEPTED, INCOMPLETE, RESCINDIDO, PREAPPROVAL_DENIED, PREAPPROVAL_NOT_ACCEPTED - máquina de estado: setas de pré-aplicação opcionais; cada resultado apenas a partir do statuses que ele pode seguir - LoanFile.archivedAt: arquivo é um sinalizador ao lado do status, não um resultado - Arive: estágio ADVERSO + mapa AriveAdverseReason para seu próprio resultado (ambos Configuração do Empréstimo = Aplicação Tomada, Divulgada = Em Processamento; datas a partir de Arive (data TRID, documentos assinados, fio de financiamento, datas de estágio), nunca hoje - realignToExternal: o MLOS externo é o sistema de registro para o estágio - Ação HMDA tomada a partir do resultado real; arquivos em andamento não têm - comércio / transação rollup / fechar o horizonte lidar com os novos status

  30. · kamo-internal

    O MLOS externo vive no mercado hipotecário e em cada empréstimo

    - Configurações → Mercados POS → Mercado de hipotecas: nova guia "MLOS externo" (Arive via Zapier, MeridianLink) com conexão, mapa de estágio, transação janela e a importação de empréstimos ativos; o seletor MLOS de mercado líder é substituído por um ponteiro para ele - Pedido de empréstimo: uma barra de status mostrando o lugar do empréstimo no externo MLOS (campos vinculados/enviando/necessários/recusados), reenviar e abrir em MLOS; seções que o MLOS possui são somente leitura com uma nota dizendo onde editá-las - cartão de negócio de pipeline: chip MLOS externo - página inicial: Arive/MeridianLink ações removidas - rotas de proxy mudam para ****************

Seu universo está esperando.

Comece gratuitamente em minutos.Adicione produtos sempre que estiver pronto — sem migração, sem novos logins.

Gratuito para sempre — não é necessário cartão de crédito