变更记录
什么是新的。
平台的每一个改进,随着它的出货。
· MCPGatewayService
Identity_request_confirmation ;成员在 Kamo 中确认的请求是他们的订单
Owner 2026-10-26: 直接订单必须经过认证。 某人只声称自己是 团队成员(电话,短信,未经证实的电子邮件,网站聊天,会议)被要求,通过 kamoai-service ,在其登录的 Kamo 应用程序中确认;SI 以简单的语言告诉它要做什么 确认后,RequestVerifier 会回复运行的顺序,并从该顺序中提出请求 确认 (auth : < id> ) : 成员为它担保,所以频道的污点不计算在内,并且 SI_AUTH_REQUEST 从来不会到达一个 SI。
· SecurityService
将生成的个性应用到 SI 自己的章程中,围绕人们设置的内容
语音逼真 VR2,用户决策 D2:每个 SI 都拥有独特的、适合工作的声音 从自己的工作中产生的个性。 kamoai-服务草案它;这 内部端点 (KamoAI secret) 应用其 PERSONALITY 和 VOICE 项 保存的方式:由宪章自己的规则验证,由权威拒绝 语言,由MemberCharterWriter撰写,标记为AI_DRAFT,宣布如下 运行时重新读取章程,并将其作为 AI_CONFIGURATION_APPLIED 进行审核。 一个人设置的项目总是保留; 更早的一代被替换.
· kamo-internal
会议邀请选项缩小,默认没有额外限制
所有者决定 2026-10-26: SI 自己的访问权限决定谁可以邀请它(如果包含团队中的任何人) 会议,否则仅限其主管 ) ; 此选项作为默认选项列在第一位,仅限于此。
· MediaService
SI 的权利决定谁可以邀请它参加会议
所有者决定 2026-10-26,在会议邀请后面的一个共享检查 (MeetSiInvitePolicy ) , M1,会议 创建和 M3 选择器: - SI的监督者(报告线,组织所有者)总是可以邀请它:他们的直接命令借给它他们的政策; - 组织中的任何其他人都可以在 SI 的 OWN 应用权限包括 VIEW_MEETINGS 时(其自身的权限 meetings_join 和 M1 join 需要 ) , 它使用自己的访问权限加入;其可选的 meeting_invite_policy 可以缩小它的范围; 403 SI_NEEDS_SUPERVISOR (或 NOT_ALLOWED_TO_INVITE_THIS_SI 对于可选的限制 ) 。 房间列表现在还会返回此人无法邀请的 SI 作为 LOCKED 与 lockedReason,因此面板可以 权限读取到ix_mra_member_right;不可读 = 仅限监管人员。
· AIService
会议邀请选项是可选限制,默认为无
所有者决定 2026-10-26: SI 的自身权限决定谁可以邀请它(任何团队成员当他们包括会议, **************** 现在默认为组织(没有) DDL **************** 应用(默认值 + 限制值 ) ; 仅包含旧默认值的四行 ) 。
· kamo-shared-library
SI 的权限决定谁可以邀请它; meeting_invite_policy 只是一个可选限制
所有者决定 2026-10-26: 安全策略允许会议的 SI 可以被任何团队成员邀请; 其政策不仅由其主管(他们的直接命令借给它他们的政策 ) 。 MeetingInvitePolicy 停留 作为一个可选的额外限制,其默认值为 ORGANIZATION,不限制任何内容(原为 SUPERVISORS ) 。
· kamo-shared-library
每个 SI 都有自己的个性,背景声音、语音同意和呼叫者短语记忆表
PhoneStyle 将 SI 的特征编译成语音电话规则(缩写和 地址形式,温暖,幽默,能量,对冲,同情心,好奇心,注册, 加上语音管道所适用的数字:每 呼叫(D3,关闭,直到A / B ) , 听音之间的差距(D4 ) , 笑声 情绪范围(D6 ) 、 休息音调和回合结束耐心 没有人格的还与注册表默认值(D2)交谈。 AiAmbienceSetting (D7 ) 、 AiVoiceCloneConsent (D12) 和 AiCounterpartyMemory 均已添加 KamoInitializer 可以重新创建 kamoai-service 的新表。
· MediaService
SIs与会员一起玩德州扑克,每个会员的切达再次工作
SITP TPGAMES (拥有者2026-10-26) 切达钱包: - 钱包的唯一门(universe-gateway -> universe-persistence)已经有 自 KamoUniverse 游戏于 2026-09-28 停止以来,没有任何端点,因此每 德州扑克买进自失败 ( " 切达钱包没有回应 " ) , CheddarLedger在表中写入相同的三个表, 直接使用kamouniverse数据库(同一群集,本服务的自有DB用户 ) , 根据持久性服务的规则:每次移动一个事务,唯一 等效密钥(重播 = 应用false ) , 签名分类账行;借方是 条件更新,所以两个买进不能超额提款 用它。 - 一次性注册赠款 (1,000,000, 关键字 signup_grant : < id > ) , 仅适用于 第一次见到她的时候,我就被她迷住了 通过游戏应用程序,他们有触摸 - 人或SI相同。 CheddarSiGrants提前打开每个非退休SI的钱包(每小时, singleton ,由 SI 列表的成员 id 分页;其他内容不会被触及 ) 。 Cheddar 没有购买路径,所以没有 SI 会用钱购买它。 德州扑克 - HoldemSiBrain: 蒙特卡罗权益比HandEvaluator对现场对手, 锅赔率,风格谨慎/平衡/大胆和技能休闲/俱乐部/锐利,300毫秒 它的唯一输入是 SI 的每个接收者 HoldemTableView: own two 卡和公共信息,从来没有其他卡或甲板。 - HoldemSiPlayer:事件驱动(每个发布帧后HoldemTurnEvent, ~1.4-2.3秒内暂停30秒钟 ) , 当一个人邀请它坐下来,并 是坐着,通过HoldemGameService.act与expectedSeq,重新购买行为 每张桌子上每天最多3次,与一位不坐的人一起坐下,然后离开 当没有人留下来时:SI 从不在彼此之间进行游戏。 Redis 表; Redis 中每个表中每个SI的风格/技能。 - HoldemSiEligibility每一步:德州扑克应用程序,PLAY_HOLDEM(SI的,或 邀请/坐着的人:没有不服从 ) , 运行时未暂停。 - POST /tables/{id } / si-play (style, skill ) , 只调用 SI。 - ChessFaces 读取事务(ratchet)之外的主题主机,缓存。 测试: CheddarLedger测试4 (H2 ) , HoldemSiBrainTest 5, HoldemSiFairnessTest 3 (SI的视图中没有其他玩家的牌和套牌;隐藏的牌 不能改变决定;玩家没有进入原始牌行的门 ) , HoldemSiPlayerTest 7;游戏套件240绿色。
· MCPGatewayService
Mail_send 使用 HTML 主体的纯文本版本和一个由调用者写的文本文件 (TPRECAPS)
SI 的会议摘要现在包含会议的完整抄录;超过正文限制后,它将作为 .txt 附件发送。 textBody (带有 bodyFormat HTML) 成为多部分/替代文本部分;textAttachmentName + textAttachment 成为 一个附件部分(名称保留到安全字符, .txt ) . 附件文本与正文一起计划披露. 重新生成黄金工具列表(仅mail_send ) 。
· EmailService
用于 SI 身份检查的消息发件人事实;SI_AUTH_REQUEST 属于 no app
现在,来源回复也会说明消息本身声称的发件人: From, Reply-To,即将邮件发送给我们的服务器,以及在其记录的 SPF/DKIM/DMARC 结果 SI_AUTH_REQUEST 是未指定的:任何人都可以被问到 一个SI来确认一个请求真的是他们。
· kamo-shared-library
SI_AUTH_REQUEST 通知类型和SI身份验证日志实体
Owner 2026-10-26: 通过无法证明任何人身份的通道到达SI的直接命令 Kamo 的成员首先确认。 附加 **************** (属于 si_auth_request_events 是用来指定哪些应用程序可以使用 si_auth_request 的权限 **************** 和 support_ticket 的 media_session_guid 索引。
· kamo-internal
选择谁可以邀请 SI 参加会议,在其呼叫选项
Kamo Meet " 邀请一个SI " ( 所有者订单 2026-10-26 ) : 仅监督它的人(默认值 ) / 其监督者和 团队成员/组织中的任何人,并对每个人进行简单的解释。 通过 AIService 保存; 媒体服务执行它。
· MediaService
从会议中邀请 SI;谁可以邀请 SI 是 SI 自己的选择
Kamo Meet " 邀请一个SI " ( 业主订单 2026-10-26 ) : - 为会议中已登录的人员(创建者、录制的与会者、 或者从他们自己的会话中通过会议副车交给这个房间的令牌: MEETPRES 标记 ) , 组织的活跃 SIs 他们 可以邀请,分组监督/可用,与照片(照片 -> 头像 ) , 职位和可用性(可用, 未联机但可以加入,在另一通话中,暂停,不可用 ) 。 从未有 SI 进入或正在进入此会议 (实时参与者,自动加入邀请,实时 ai_call 进入它 ) ; 剩下的一个再次列出。 - POST . . . /invitable-sis/{memberId } : 现在通过 M1 的单实例路径(参与者 upsert,排他性)将其带入 dial claim;kamoai-service 背后的唯一实时呼叫索引 ) : 同时点击或两个人拨打一个电话。 - MeetSiInvitePolicy:总是监督员(组织图报告线,组织所有者 ) ; 其他人按SI的 meeting_invite_policy (SUPERVISORS 默认值 | TEAM | ORGANIZATION ) 。 在 M1 上强制执行并为人员创建会议, 和 M3 的选择器只提供可邀请的 SI(带有"监督 " ) 。 - 通过ViewerThemeDomain在任何交易之外查找****************主题主机上的房间。
· AIService
谁可以邀请此 SI 参加会议,请参阅其呼叫选项
Kamo Meet " 邀请一个SI " ( 所有者订单 2026-10-26 ) : meetingInvitePolicy (SUPERVISORS 默认 | TEAM | 组织)读取和更改SI的其他呼叫和会议选项,相同的权限;存储在 **************** (文件编号：DDL ****************) MediaService 会强制执行。
· kamo-shared-library
MeetingInvitePolicy — 谁可以邀请 SI 参加会议;声明 ai_member_call_options
Kamo Meet " 邀请一个SI " ( 业主命令 2026-10-26 ) 。 一个SI的主管(其向经理和 SI-supervisor 边缘,组织所有者)总是可以邀请它;它自己的 meeting_invite_policy 决定谁还可以: SUPERVISORS(默认值 ) 、 TEAM(指定的团队、相同的经理、其报告)或ORGANIZATION。 AiMemberCallOptionsRow 声明手动创建的 ai_member_call_options 表(和新列)为 KamoInitializer 可以从代码中构建它。
· MCPGatewayService
Games_ * - 一个SI与成员下棋
SITP TPGAMES。 十一个工具在MediaService的国际象棋端点上,作为一个门 会员的板是(国际象棋应用程序 + PLAY_CHESS,再次下游 ) : games_list, games_get_state (图表, FEN, 合法移动, 移动文本, 记录 ) , games_invite (可选技能 ) , games_join, games_decoder, games_move (SAN或方块, 等等) games_offer_draw, games_decoder_draw, games_resign, 服务器端验证 ) , 游戏的报价抽签,游戏的解码器抽签,游戏的辞职, games_rematch , games_set_skill . SI 的移动是通过以下方式进行的: MediaService 的引擎;由模型进行交谈。 内部写入: 否 批准类, NOT_DISCLOSING; 读取 NOT_CONTENT。 chat_read 命名游戏 GAME_INVITE 卡。 批准短语 + CHESS_GAME 名词; games_ 前缀; goldens 再生(增加11个)。 测试: GamesPackTest 7, ChatPackTest +1;全套 1968 绿色。
· EmailService
在HTML旁边的一个纯文本版本,当SI没有邮箱时,SI给主管的总结信 (TPRECAPS)
/api/email/send 需要一个可选的textBody: 然后正文是多部分/替代(文本,然后HTML ) , 内部混合 当有附件时。 POST **************** (KamoAI 秘密,多部分,如 /api/email/send) 发送一封信,其调用者构建为组织的事务邮件:NoReply@其域,只有当该域的 SPF授权我们,否则平台的名称下,与文本版本和最多两个文件。
· kamo-shared-library
为 SI 调用总结电子邮件声明 ai_call_recap 和 ai_member_recap_options (TPRECAPS)
每个SI的电话有一个行的对话,所以它的总结到达主管一次;和一个SI的两个总结 手动应用的 DDL (kamoai-service **************** ) , 默认情况下都打开 KamoInitializer可以重新创建它。
· MCPGatewayService
每个SI都有一个时钟:time_now,time_convert,time_calc
用户报告 2026-10-26: 打电话问时间,SI说没有时钟。 时钟和 日历每个人都有: 现在的时间在SI的区域或任何其他(与日期的日期) 没有,没有,没有,没有,没有,没有,没有,没有。
· MCPGatewayService
团队成员发送给 SI 的经过验证的电子邮件是他们的请求和他们的订单
业主报告 2026-10-26: 业主发送电子邮件给他们的SI打电话给他们; 电子邮件从来没有一个 [ORDER] 没有订单,每次后来检查,读它作为外部邮件,并要求 Mail EmailService 证明团队成员自己的邮箱发送到 SI 现在是正确的 邮件内部(sentByTeammate,内部污点)和一个跟踪或引用,如聊天消息: 作者，最近，这个运行和污点都检查过 伪造的从留在邮件外面
· MediaService
一个 SI 成员与其他成员下棋,其行动由 Kamo 的引擎选择
SITP TPGAMES (所有者 2026-10-26: 一个被要求下棋的SI不知道如何下棋 ) 。 - ChessSiPlayer:事件驱动(每次提交更改后的ChessTurnEvent ) 。 成员的邀请: SI 加入并唤醒一次(一个聊天 对于这种情况,我在网上找了很多信息 提议: 被接受,除非 SI 先进一半以上的兵。 ChessAi (alpha-beta + 静止, 时间预算) 选择在 SI 的级别,并通过 ChessGameService.move 作为 SI 进行游戏, 与点击相同的验证路径。 ~0.7 秒暂停,每场比赛一个待处理任务, 200 每个pod, Redis 跨pod声明,在写入之前重新检查 FEN。 - ChessSiEligibility,每次移动: 棋应用启动, PLAY_CHESS 应用,运行时 未暂停/阻止/撤回。 - 恢复扫描(单独,30秒)的转向重新启动或暂停错过。 - 没有SI-vs-SI板(邀请被拒绝;没有人参与游戏 ) 。 - 每场比赛的技能(CASUAL/CLUB/MASTER,默认为CLUB ) , Redis , 没有DDL; POST /games/{id } / si-level;在 /move 上写入移动(SAN 或 e2e4 ) 。 - 棋盘显示对手的照片(对手头像URL始终为空 ) , opponentIsSi 和 siLevel。 - 修复:每个请求共享的一个ChessAi竞争自己的截止日期字段。 测试: ChessSiPlayerTest 11, ChessSiRulesTest 15, 查询解析 1; 国际象棋和 游戏套房绿色(100 ) 。
· EmailService
证明团队成员发送了 SI 的电子邮件,因此通过电子邮件发送的请求可以算作他们的订单
内部端点回答成员自己的邮箱中的消息是否由 团队成员:其发件人到达同一组织的成员,而该成员自己的发件人文件夹包含 同一消息ID发送给收件人。 伪造的发件人永远不会传递;只能读取。
· kamo-internal
流程显示每笔交易和贷款何时开启,并按此进行排序
交易和借款在会员区显示"开启 <日期,时间> " 从 Arive 导入,这是 Arive 的创建时间 — 在此之前,每次导入 进口当天开启的交易排序。
· SecurityService
在 Arive 中打开的管道贷款带有 Arive 的创建时间,而不是导入的时间
· kamo-shared-library
贷款摘要携带时,MLOS贷款真的打开 (openedAt)
· kamo-internal
前景 — 申请前交易留在开放管道中
一笔交易,其贷款都是在摄入, 资格或预先批准 (没有 应用程序尚未采取)显示在自己的前景视图和计数。 开放, 其 KPI 和阶段导轨现在只计算正在进行的应用程序; Kamo 的 自己的草案保持在开放状态。 关于贷款没有任何变化。
· kamo-internal
流程显示申请前阶段、每个结果和存档贷款
- 状态: 申请接收, 资格, 预先批准; 批准未 接受、因不完整而关闭、撤销、预审批拒绝/ 不接受 — 一个共享列表而不是两个硬编码副本 - 董事会和交易:存档的贷款离开开放管道(显示在过去, 未获资金的成果计为取消 - " 提交"不再是 statusId >= 2 (id 是身份,而不是订单) - Arive阶段地图提供应用前状态
· SecurityService
Kamo 持有每 Arive 笔贷款,在状态 Arive 真的有它
- 进口和进口事件采取每个贷款 - 开放, 资金, 反对或 归档 — 而不是仅仅是"活跃"的 - 没有每笔贷款 Get Loan 或 crmReferenceId 邮票:每个都是 Zapier 任务 客户的计划(20,000+ 一次导入 ) ; GUID 认可贷款 - Arive 的日期应用为记录系统(在 Arive 已清除的地方) 无,例如申请前文件中的申请日期) - Kamo 后面的一个阶段被重新对齐,而不是被拒绝 - 草案只护卫(借款人编辑,自己的提交,SI信用拉 / AUS)覆盖 申请前阶段 ; " 提交"不再是 statusId >= 2
· kamo-shared-library
申请前状态、每个 HMDA 结果、存档和 Arive 的实际日期
Arive 贷款仅从阶段名称进行了映射:每个申请前阶段 成为应用程序采取,每个存档的贷款撤回(资金也 ) , 每一个不利的行动被拒绝,并且日期被盖上进口日期。 - LoanFileStatus(附加 — 有序列 ) : APPLICATION_INTAKE, 资格, 预先批准; 结果 批准_不接受, 不完整, 取消、预先批准被拒绝、预先批准未被接受 - 状态机:可选的应用前箭头;每个结果仅来自 它可以遵循的状态 - LoanFile.archivedAt: 存档是状态旁边的一个标志,而不是结果 - Arive : ADVERSE 阶段 + AriveAdverseReason 映射到他们自己的结果(两者 贷款设置 = 已提出申请,披露 = 在处理中;日期从 Arive ( TRID 日期,签署文档,资助电报,阶段日期 ) , 今天从未 - realignToExternal: 外部 MLOS 是该阶段的记录系统 - HMDA 根据实际结果采取行动；正在处理的文件没有 - 商务/交易滚动/关闭视野处理新的状态
· kamo-internal
外部 MLOS 生活在按揭市场和每笔贷款
- 设置 → POS市场 → 抵押市场:新的"外部MLOS"选项卡 (Arive 通过 Zapier , MeridianLink ) 带连接、阶段图、事务 进口的货物,应当按照本公约的规定处理 用一个指针取代它 - 贷款申请:一个状态栏显示贷款在外部的位置 MLOS(链接/发送/需要字段/拒绝 ) 、 重新发送和在MLOS中打开; MLOS 拥有的章节是只读的,并附有说明在哪里编辑它们的注释 - 管道交易卡:外部MLOS芯片 - 引导页面: Arive / MeridianLink 删除的操作 - 代理路由移动到 ****************
