Changelog
What's new.
Every improvement to the platform, as it ships.
· MCPGatewayService
Calendar_create_event invites teammates by member id, so 'put it on my calendar' reaches the person who asked
Nobody may write another member's calendar (EmailService: own calendars, the org calendar with the publish right), so a union of rights cannot either. inviteMemberIds sends them as the event's audience, as the calendar dialog's people chips do: a guest row bound to the member, the event on their own calendar, the invitation sent. They are evaluated on MEETING and named in the disclosure plan; the description steers the SI to it.
· kamo-shared-library
AiRealismTestWindow — calls from a test extension to an SI inside a window are test calls
· kamo-internal
The SI Assistant is each member's personal assistant — confirmation cards, live steps, its own settings window and the org defaults
SITP TPASSIST (owner order 2026-10-26). - The assistant window tells AIService it shows confirmation cards, so the assistant works with every tool the member's own access allows. An outside send, money, a delete, a security change or a device command arrives as a card in the chat: one plain question (the Tool Plane's own words, no ids or JSON), the exact message, the records it touches, the risk; Confirm, Edit (the wording only) or Cancel, decided over the socket; it folds to one line once decided. - Each step shows as it starts (the tool's title, a spinner, then a tick); raw tool answers only under Technical details. A reopened conversation shows its waiting cards again. - The header wears the assistant's face and name and a gear that opens its own settings window (ai-assistant-settings): name and character (shared avatar), Personality Engine style and traits, answer length/form/language, voice switches, tool areas, confirmation level, private memory (view, add, forget), notifications (sound, notice when minimized) and model preference — every change saved at once, organization locks shown. - Settings › SI › SI Assistant: what every member's assistant starts with and what members may change, for the organization or a department, job title or team, with locks and limits (tab, menu entry, landing card).
· MCPGatewayService
Identity checks about a named message; an unproven email whose sender confirmed is their order
identity_request_confirmation takes 'about' (email:<folder>/<uid>, chat:<guid>) for a message that is not the run's own wake (a check-in handling it). An email no teammate's mailbox proves is still the order of a member who confirmed, in their own Kamo session, that its sender is them (kamoai-service active?about=). Live 2026-10-26 in sp00verify.
· kamo-internal
Shift reports settings tab and a person's own choice
Owner order 2026-10-26 (TPSHIFTREPORTS): no more empty clock-in/clock-out reports from SIs. - /settings/ai?tab=shift-reports (menu entry + landing card; SI workforce + VIEW/MANAGE_AI_WORKFORCE): the organization's rule, more specific settings for what SIs send and what people receive (department, job title, team, one SI / one person), what each supervisor actually gets and why, and the latest decisions in plain words (sent, waiting for its time, not sent: nothing new...). - Rule editor: Always / Only when there's something new (recommended) / Never; clock-in, clock-out, both or set times; days; chat or email. Org brand tokens, corner ribbons, motion with reduced motion. - Work room > SI colleagues: Shift reports from SIs, the member's own choice (wins over every SI's), the SIs that report to them and their latest reports.
· kamo-internal
Background sound settings, an SI's speaking style and voice consent (voice realism VR2)
- Settings > Super Intelligence > Background sound (D7): the soft room sound callers hear under the SIs' voices, for the organization and per department, job title, team or SI (most specific wins; light office by default), with a preview of the very loops the calls use and what each SI's callers hear now. Tab + menu entry + landing card. - An SI's profile, under its voices: How it speaks (D2: the personality drafted from its job, its signature habits, Draft a fresh personality) and Using a real person's voice (D12: written consent signed in Kamo or as an uploaded form, withdrawable).
· AIService
The settings read carries the archetypes' values and the personality in words
So the settings window's sliders start from the archetype the member picked, and it can show what the Personality Engine makes of the settings (TPASSIST).
· AIService
The nav SI Assistant is each member's personal assistant with the member's full tool power
SITP TPASSIST (owner order 2026-10-26). The member's own assistant conversation now: - lists every Tool Plane tool the member's OWN session may use, under every risk when the client shows confirmation cards (the plain chat's ceiling otherwise), less the tool areas switched off; the long tail is named in an index and loaded on demand (assistant_load_tools) - keys every call **************** so the Tool Plane audits it as the SI Assistant on the member's behalf with the member as actor - holds outside sends, money, deletes, security and device calls (every change under ALWAYS) for the member's confirmation in the chat: a plain-language card from the Tool Plane's renderer read as the member, the do-not-contact list checked first, Confirm / Edit (wording only) / Cancel over the socket (DECIDE_ACTION) or REST, and the turn continues once decided - speaks with its own settings: name, avatar, Personality Engine archetype and traits, answer length and form, language, model preference, through the waterfall ORG > DEPARTMENT > JOB_TITLE > TEAM > MEMBER with locks and limits (/api/ai/assistant/settings, /layers) - keeps a private per-member memory (memory_record / memory_search / memory_forget, and /api/ai/assistant/memory) that no SI or other member reads - streams TOOL_STARTED, CONFIRM_REQUIRED, AWAITING_CONFIRMATION and ACTION_DECIDED frames
· kamo-internal
An SI's identity check pops up on every session: was this you?
Owner 2026-10-26: direct orders reaching an SI by phone, text, outside email, website chat or in a meeting are confirmed by the member in Kamo first. SiAuthRequestHost opens the newest SI_AUTH_REQUEST card from the notification socket (no polling) and closes everywhere when it is withdrawn: which SI asks (its avatar), what was asked, where it came from (numbers and addresses as the app always shows them, every fact Kamo has behind Show every detail), plain risk hints, a countdown ring, Yes / No / This wasn't me, a forced tone and a vibration. In the organization's colours, Framer Motion under MotionConfig reducedMotion, full screen on a phone. /authentications is the log: the member's own, or everyone's for workforce managers. The kind is ungated (belongs to no app), never a second card in the toast deck.
· MCPGatewayService
Audit the SI Assistant's calls as made on the member's behalf
The member's personal SI Assistant (TPASSIST) calls with the member's own session; its keys start assistant:, and such a call by a person is audited with authority basis SI_ASSISTANT and the member as on_behalf_of (the member stays the actor of record). Widens and narrows nothing.
· kamo-shared-library
Tables for shift report settings and decisions, so KamoInitializer can recreate them
Owner order 2026-10-26 (TPSHIFTREPORTS): SI clock-in/clock-out reports become configurable per department, job title, team and member, for the sending SI and for the person receiving them.
· kamo-shared-library
Settings waterfall, private memory and pending confirmation rows for the personal SI Assistant
Declared for KamoInitializer; aiservice created the tables by hand **************** and writes them with targeted SQL.
· AIService
An internal route that runs a model capability's real probe (voice realism VR1)
POST **************** KamoAI secret only: the same live probe as the Verify button on Settings → SI providers, against the provider's own key. It never sets a verification by hand; a model that fails stays unverified. Used to verify crm's realtime model for the speech-to-speech pilot (D9).
· AIService
Verify a realtime speech-to-speech model by opening a session for it (voice realism VR1, D9)
ProbeRunner runs the new REALTIME_SESSION probe (kamo-shared-library 1438893a) for REALTIME_AUDIO: it mints a 10-minute client secret for the model on the and passes when the vendor opens it; the secret is never used or kept. Until now an org's realtime model could only be attested, which org providers cannot be, so an SI never got a speech-to-speech ticket.
· kamo-shared-library
A realtime speech-to-speech model can be verified — REALTIME_AUDIO is probed by opening a session (voice realism VR1, D9)
REALTIME_AUDIO was ATTESTED, and only platform providers can be attested, so no org's realtime model could ever be VERIFIED, and an SI is routed to VERIFIED models only: the speech-to-speech pilot the owner ordered for crm (D9, 2026-10-26) could not get a ticket. New probe kind REALTIME_SESSION, appended last (no existing value moves); AIService's ProbeRunner implements it.
· MCPGatewayService
Holdem_* - an SI plays Texas Hold'em with members
SITP TPGAMES. Twelve tools over MediaService's Hold'em endpoints, gated as a member's seat is (Hold'em app + PLAY_HOLDEM, again downstream): holdem_list_tables, holdem_get_table (the seat's own redacted view: own cards, public play, legal actions with exact amounts), holdem_wallet (own Cheddar), holdem_open_table, holdem_invite, holdem_sit, holdem_act (street totals; BET/RAISE need an amount), holdem_show, holdem_sit_out, holdem_rebuy, holdem_leave, holdem_set_style (style/skill for the SI's own play). Seated with members, MediaService's poker brain acts for the SI; the model does table talk in the table's conversation. Cheddar is not money and cannot be bought: internal writes, no approval class, NOT_DISCLOSING; reads NOT_CONTENT. Approval phrases + HOLDEM_TABLE noun; holdem_ prefix; goldens regenerated (12 added). Tests: HoldemPackTest 5; full suite 1985 (the two notification-kind failures predate this: shared-lib's BILLING_INVOICE/SI_AUTH_REQUEST kinds).
· kamo-shared-library
The AI_CALL_METRICS entity, with the call's voice realism counts (VR1)
kamoai-service writes ai_call_metrics JDBC only; the entity declares every column (and the new REALISM text column, a JSON object of the call's realism counts: perceived gaps, acknowledgements, listening sounds both ways, phantoms, lines cut off, false interruptions) so KamoInitializer can recreate the table from code (owner rule 2026-10-22). DDL: kamoai-service **************** applied.
· AIService
E5 streams a sentence's audio as the model makes it, and with no order set an SI speaks with the org's best verified voice model (voice realism VR1, D1)
- E5 {"stream": true}: the audio is handed on chunk by chunk as the provider sends it (ElevenLabs **************** the candidate walk, so an empty answer still fails over before anything is sent; metered by characters as before. A family that cannot stream keeps the whole answer. Without the field nothing changes. Calls waited 950 ms (p50) for a whole sentence before its first audio. - TtsQualityRanking (D1, owner 2026-10-26: best quality among the org's configured and enabled providers, chosen automatically): with no TTS order the best VERIFIED model by published conversational quality and realtime fitness comes first, provider-neutral; unknown models tie with Kamo's in-cluster voices, so the in-cluster default still decides among them. An org's own order and an AI member's chosen voice still come first.
· EmailService
SI_AUTH_REQUEST in the settings order, after BILLING_INVOICE
· kamo-internal
The call recap page, and the SI's recap options in Calls and meetings (TPRECAPS)
/ai-calls/recap/<call> is what the supervisor's recap email links to (and a PHI organization's secure link): who was on the call, when, how it went, the SI's summary, the action items, what the SI did during and after, and every word of it with search, copy and download; the org's colours, the shared avatar and phone controls, motion that honours reduced motion, no ids. The SI's call options gain two switches, both on by default: email a call recap to the supervisor, and include the full transcript in meeting recaps.
· kamo-shared-library
AiPersonaGeneration, the record of the personality generated for each SI
· MCPGatewayService
Identity_request_confirmation; a request the member confirmed in Kamo is their order
Owner 2026-10-26: direct orders must be authenticated. Someone who only claims to be a teammate (phone, text, unproven email, website chat, meeting) is asked, through kamoai-service, to confirm in their signed-in Kamo app; the SI is told in plain words what to say next. Once confirmed, RequestVerifier answers the run's order and request from that confirmation (auth:<id>): the member vouched for it, so the channel's taint does not count and its own expiry is the window. SI_AUTH_REQUEST never reaches an SI.
· SecurityService
Apply a generated personality to an SI's own charter, around what people set
Voice realism VR2, owner decision D2: every SI gets a unique, job-fit personality, generated from its own work. kamoai-service drafts it; this internal endpoint (KamoAI secret) applies its PERSONALITY and VOICE items the way a save does: validated by the charter's own rules, refused on authority language, written by MemberCharterWriter, marked AI_DRAFT, announced so the runtime re-reads the charter, and audited as AI_CONFIGURATION_APPLIED. Items a person set are always kept; an earlier generation is replaced.
· kamo-internal
The meeting invite option narrows, default no extra limit
Owner decision 2026-10-26: the SI's own access decides who may invite it (anyone on the team when it includes meetings, else only its supervisors); this option, listed first as the default, only narrows that.
· MediaService
The SI's own rights decide who may invite it into a meeting
Owner decision 2026-10-26, in the one shared check (MeetSiInvitePolicy) behind the in-meeting invite, M1, meeting create and the M3 picker: - the SI's supervisors (reporting line, org owner) may always invite it: their direct order lends it their policy; - anyone else in its organization may when the SI's OWN applied rights include VIEW_MEETINGS (the right its own meetings_join and M1 join need), and it joins with its own access; its optional meeting_invite_policy may narrow it; - otherwise 403 SI_NEEDS_SUPERVISOR (or NOT_ALLOWED_TO_INVITE_THIS_SI for the optional restriction). The room listing now also returns the SIs this person cannot invite as LOCKED with lockedReason, so the panel can say why. Rights read on ix_mra_member_right; unreadable = supervisors only.
· AIService
The meeting invite option is an optional restriction, default none
Owner decision 2026-10-26: the SI's own rights decide who may invite it (any team member when they include meetings, else only its supervisors). **************** now defaults to ORGANIZATION (no restriction); DDL **************** applied (default + the four rows that only carried the old default).
· kamo-shared-library
The SI's own rights decide who may invite it; meeting_invite_policy is only an optional restriction
Owner decision 2026-10-26: an SI whose own security policy allows meetings may be invited by any team member; one whose policy does not only by its supervisors (their direct order lends it their policy). MeetingInvitePolicy stays as an optional extra restriction whose default, ORGANIZATION, restricts nothing (was SUPERVISORS).
· kamo-shared-library
Every SI speaks by its personality, and the tables for background sound, voice consent and caller phrase memory
PhoneStyle compiles an SI's traits into spoken phone rules (contractions and address forms, warmth, humor, energy, hedging, empathy, curiosity, register, regional wording) plus the numbers the voice pipeline applies: a filler cap per call (D3, off until the A/B), the gap between listening sounds (D4), laughter and emotion range (D6), the resting tone and the end-of-turn patience. An SI with no personality yet speaks with the registry defaults (D2). AiAmbienceSetting (D7), AiVoiceCloneConsent (D12) and AiCounterpartyMemory are declared so KamoInitializer can recreate kamoai-service's new tables.
· MediaService
SIs play Texas Hold'em with members, and every member's Cheddar works again
SITP TPGAMES (owner 2026-10-26). Cheddar wallet: - The wallet's only door (universe-gateway -> universe-persistence) has had no endpoints since the KamoUniverse game was parked on 2026-09-28, so every Hold'em buy-in since has failed ('the Cheddar wallet is not answering'), for people and SIs alike. CheddarLedger writes the same three tables in the kamouniverse database directly (same cluster, this service's own DB user), with the persistence service's rules: one transaction per movement, unique idempotency key (replay = applied false), signed ledger line; a debit is a conditional update so two buy-ins cannot overdraw. CheddarWalletClient now uses it. - The one-time signup grant (1,000,000, key signup_grant:<id>), which only the parked 3D world ever made, is made the first time a member's wallet is touched through a games app they have - person or SI the same. CheddarSiGrants opens every non-retired SI's wallet ahead of time (hourly, singleton, paged by the SI roster's member ids; nothing else touched). Cheddar has no purchase path, so no SI ever buys it with money. Hold'em SI: - HoldemSiBrain: Monte Carlo equity over HandEvaluator vs the live opponents, pot odds, style CAUTIOUS/BALANCED/BOLD and skill CASUAL/CLUB/SHARP, 300 ms cap. Its only input is the SI's per-recipient HoldemTableView: own two cards and public information, never other cards or the deck. - HoldemSiPlayer: event-driven (HoldemTurnEvent after each published frame, ~1.4-2.3 s pause inside the 30 s clock). Sits when a person invited it and is seated, acts through HoldemGameService.act with expectedSeq, rebuys at most 3 times a day per table, sits out with a sitting-out person and leaves when no person is left: SIs never play among themselves. Redis claim per table; style/skill per SI per table in Redis. - HoldemSiEligibility every step: Hold'em app, PLAY_HOLDEM (SI's, or the inviting/seated person's: No Insubordination), runtime not paused. - POST /tables/{id}/si-play (style, skill), the calling SI only. - ChessFaces reads the theme host outside the transaction (ratchet), cached. Tests: CheddarLedgerTest 4 (H2), HoldemSiBrainTest 5, HoldemSiFairnessTest 3 (the SI's view holds no other player's cards and no deck; hidden cards cannot change the decision; the player has no door to raw hand rows), HoldemSiPlayerTest 7; games suites 240 green.
· MCPGatewayService
Mail_send takes an HTML body's plain-text version and one text file written by the caller (TPRECAPS)
The SI's meeting recap now carries the meeting's full transcript; past the body's limit it goes as a .txt attachment. textBody (with bodyFormat HTML) becomes the multipart/alternative text part; textAttachmentName + textAttachment become one attachments part (name kept to safe characters, .txt). The attached text is planned with the body for disclosure. Golden tool lists regenerated (mail_send only).
Your universe is waiting.
Start free in minutes. Add products whenever you are ready — no migration, no new logins.
Free forever — no credit card required