Changelog
What's new.
Every improvement to the platform, as it ships.
· SecurityService
Google Home account linking — an IOT_GOOGLE principal provider and Google's redirect URIs
IOT_GOOGLE is the Alexa voice-link provider with assistant GOOGLE on I-A1/I-A2 (one link table in IoTService). The client admin takes a Google Cloud project id as the vendor id and writes Google's production and sandbox redirects. The consent view now names the client's purpose so the page can word Google Home or Alexa.
· MCPGatewayService
Notifications_list today:true counts what arrived today in the owner's zone
TPONBEHALF live check (sp00verify 2026-10-28 07:27Z): asked "how many notifications did I get today?", the SI read the member's own account correctly (on behalf, audited) but answered with the total (12) when none had arrived today. today:true counts, read or not, every notification since midnight in the caller's own zone (the member's when the SI acts on their account): receivedToday, todayStartsAt, timeZone. Tool-list snapshots updated deliberately for this one tool.
· kamo-shared-library
One voice-link model for Alexa and Google Home (assistant column, IOT_GOOGLE OAuth client purpose)
iot_alexa_links.assistant = ALEXA | GOOGLE (applied by hand from iot-service **************** default ALEXA) and the OAuth client purpose IOT_GOOGLE for "Works with Google Home" account linking, whose grants name the same VOICE_LINK principal.
· kamo-internal
Done on your behalf — what SI teammates did through your own account
TPONBEHALF (owner 2026-10-28): when someone an SI reports to asks it for something of their own ("How many notifications did I get today?"), the SI works on their own account, and every such step is logged. New page /on-behalf lists them in plain words: which SI, what it did, how you asked, how it went, patient information flagged; Everyone for those who manage the SI workforce. Linked both ways with /authentications. BFF route /api/security/si-on-behalf (pass-through to SecurityService). Brand tokens only, MotionConfig reducedMotion, axe clean, phone width; full next build green.
· kamo-internal
Voice assistants card explains the two Alexa skills and how a shared Echo learns your voice
"Which Alexa skill?": KamoUniverse (devices + your SI Assistant on your own Echo, "Alexa, ask Kamo Universe …") beside KamoUniverse Assistant (your own assistant on a shared Echo that knows your voice, "Alexa, ask Kamo Assistant …"), and a fold-out with the voice-ID / Personalize skills / link-as-yourself steps. Static copy (dictionary 6bd34a83 first).
· kamo-login
Consent for the KamoUniverse Assistant skill, and the decision route forwards whose link it is
Client iot.alexa.assistant (the second, assistant-only Alexa skill) always links "Just me": no owner cards, no place, no "What can Alexa use?", no routines; a default name "KamoUniverse Assistant", Replace only for the member's own links; plain words on what it means on a shared Echo (voice profile with Personalize skills, your own SI Assistant with your own access, others only after they link their own voice, PIN for sending/payments/unlocking, nothing private read aloud). It posts ownerKind MEMBER and grantChoice {preset NONE, sensors {kamoAlert false}}; SecurityService enforces the same. Fix: decisionPayload rebuilt the link from mode/name/linkId only, so ownerKind, siteId and grantChoice chosen on the consent screen never reached SecurityService. They now travel on, each rebuilt from known fields (grantChoiceOf).
· kamo-internal
Easter eggs settings tab, wake-up calls first (TPWAKEUP)
Owner order 2026-10-28: /settings/ai?tab=easter-eggs (menu entry + landing card; SI workforce + VIEW/MANAGE_AI_WORKFORCE): every easter egg of the registry with what it does in plain words, how people use it, what to say, its built-in safeguards; on for the organization (default) with a style (drill sergeant, gentle, morning show); more specific settings per department, job title, team or SI (the most specific wins); what each SI does and why; the latest wake-up calls (when, number, for whom, who asked, tries, snoozes, outcome in words). Brand tokens, corner ribbons, motion under reduced motion.
· MCPGatewayService
OnBehalfOf — an SI acts through its higher-up's own account on their authenticated request
TPONBEHALF (owner 2026-10-28): Sage asked Luna how many notifications HE got today and she could only read her own. On an authenticated request from anyone up the SI's chain of command, a tool's AI copy now takes onBehalfOf: "requester" (offered in that run's tools/list, naming them): the planner and handler run on a short session of the requester's own account that SecurityService mints for the run and tool, so every service answers with their notifications, mail, calendar, tasks. Every gate still judges the SI (charter, union rights, limits, taint, identity guard, PHI, outreach). - Reads need only their authenticated question; changing anything on their account needs a direct order. - The account is always the order's author (the only value is "requester"): never another member's. - Refused in plain words: no authenticated request (NO_ORDER), a question for a write (NOT_AN_ORDER), not in the chain of command, another SI, the SI's own work (identity, self, collab, memory, workstation, approvals, disclosure, oversight, wakeup, iot). - Audit: authority_basis SI_ON_BEHALF_OF_MEMBER on mcp_tool_call_audit, and a si_on_behalf_actions row written BEFORE the action (no row, no action) and completed with its outcome. - A read through their own account for them alone is a SELF read (OrderPrincipal.ownAccount). - An on-behalf session presented to the Tool Plane itself is refused. - NotificationsPack: SI_ASSISTANT_REPLY (Voice Assistant's new kind) decided as not offered to SIs. Tests: ToolCallPipelineOnBehalfTest 12, OrderPrincipalOwnAccountTest 2; full suite 2038 green but the two notification-kind guards, fixed here.
· kamo-internal
Alexa's invocation is "kamo" — Try it says devices need no name and the SI Assistant starts with "Alexa, ask kamo"; open-kamo step; shared-Echo voice profiles removed (Amazon refused them)
· kamo-shared-library
Voice quiet hours have their own on/off flag
**************** (applied by hand, nullable, null = on), so switching voice quiet hours off and on keeps the member's own start and end.
· SecurityService
An SI may act through its higher-up's own account on their authenticated order
TPONBEHALF (owner 2026-10-28), the NO INSUBORDINATION RULE extended: on an authenticated direct order, the SI may use everything the requester can do under their own account (their notifications, mail, calendar, tasks...), with the security of both combined, all the way up its chain of command. - OnBehalfService: the chain of command (anyone above the SI in its reporting line, manager and SI-supervisor edges, transitively, or the org owner; never peers, reports or another SI) and the mint of a short session OF THE REQUESTER (memberID theirs, actorType AI, delegation block SI_ON_BEHALF_OF_MEMBER naming the SI, order and run). Rights = (requester's live rights + the SI's own) less AiRightsFloor and the SI's NUKEs, scoped to the tool's needs; 15 minutes; access-logged. No live session, password or one-time key of the member is used. - POST **************** for the Tool Plane. - GET /api/security/si-on-behalf (mine; scope=org for MANAGE_AI_WORKFORCE / VIEW_ACCESS_LOGS): the append-only si_on_behalf_actions log the Tool Plane writes before each such action. - A delegated session is never widened at mint (a grant-all owner's floor rights never come back) and never counts as the member signed in elsewhere. - DDL **************** (applied).
· kamo-shared-library
SiOnBehalfAction, the append-only log of what an SI did through a member's own account
TPONBEHALF (owner 2026-10-28): on an authenticated direct order from anyone up its chain of command, an SI may act through the ordering member's own account; every such action must leave an audit trail visible to that member. Declares si_on_behalf_actions (hand-applied DDL in securityservice **************** for KamoInitializer.
· SecurityService
A short member session for the member speaking on an Alexa link, and voice turns as order references
Voice Assistant R3: POST **************** {orgId, memberId, linkId, grantId} -> {***, expiresAt} (X-Internal-Auth = IOT_INTERNAL_AUTH_SECRET). Minted only for an active human member on their own LINKED personal link, or an ORG link carrying their mapped voice profile, on the link's ACTIVE grant; re-checked after the mint; the member's own rights, at most 15 minutes, no sign-in side effects (PostAuth***Service gains a timeout ceiling); audited. R6: OrderDelegation accepts orderRef voice:<turn id> (sent by the voice gateway only after the spoken PIN).
· kamo-internal
Status tabs with counts, Terminate/Activate instead of Delete, and an SI terminated like anyone
- /account?tab=team-members: tabs by employment status with counts (All Statuses first, Active the default), from SecurityService's grouped count, narrowed by the All/Human/SI segment. Delete removed. - /account?tab=members: Active / Terminated tabs; row and bulk Terminate / Activate with a plain-language confirmation (member record only). - /account?tab=accounts: Active / Inactive tabs; row and bulk Deactivate / Activate. Delete removed (and the client call to it). - Profile: the same status select for a person and an SI; an SI is offered Active/Terminated, and Terminated is confirmed in words that say it retires the SI for good (with the workstation choice); a person's termination is confirmed too and stays reversible. A terminated SI's status is read-only. - The /account tab bar wears the corner ribbon instead of an underline.
· AIService
A Speaches sentence is said clause by clause, so its first audio comes after its first clause
Luna), but Speaches' Kokoro/Piper make each request whole before the first byte (~0.6 s + 25 ms a character on k3m1), so an SI with an in-cluster voice (sp00verify's Nell, TPEARDEAF: 0.9-1.9 s) waited for the whole sentence. A streamed PCM request to Speaches is now cut after its commas, semicolons, colons and dashes (never inside 1,000; tiny clauses join a neighbour; at most four pieces), the first clause is handed on as soon as it is made and the next is made beside it (at most two in flight), and the silence at each join is trimmed to about a comma's pause. An empty or failed first clause still fails over; other formats and providers are asked once, as before.
· MCPGatewayService
SI mortgage reads take View Own Mortgage Loans
Every MLOS staff right now implies View Own Mortgage Loans, and SecurityService narrows a member without View Mortgage Pipeline to the loans they are assigned loan officer on. Gating the read tools on the new right lets an own-loans member's SI work their own loans; all-loans members are unchanged.
· kamo-internal
Own-loan members see their pipeline; HMDA and reassignment stay with all-loans
The pipeline hides the HMDA LAR button and loan-officer assignment from members who hold only View Own Mortgage Loans. The rights mirror puts the mortgage rights under the new root, and the mortgage tour opens for either view right.
· SecurityService
Enforce own-loan access; Team Members default to their own loans
MLOS endpoints now tell apart members who see all of the organization's loans (View Mortgage Pipeline, or god mode) from members who hold only View Own Mortgage Loans. Own-loan members see and work only loans whose deal names them as assigned loan officer; another officer's loan is 403. Lists (applications, transactions, pipeline, QC queue, legacy POS) are narrowed to their loans. Writes need ownership unless the caller sees all loans. Loan-officer reassignment, HMDA, QC training export/accuracy, webhooks and marketing stay all-loans. An own-loan member who creates a deal with no officer is assigned to it. Borrower (party) access is unchanged. MortgageLoanOwnership answers each check with one scalar, org-bounded query, cached per request, and fails closed when absent. Rights sync seeds View Own Mortgage Loans from the existing mortgage rights (so nobody loses access) and grants it once to every organization's Team Members role; security model templates do the same for the team member template. Administrator roles are grant-all and keep all loans.
· kamo-shared-library
View Own Mortgage Loans right; loan reports scope to the member's own loans
MLOS_VIEW_OWN_LOANS (660) is the new root of the mortgage rights: it lets a member see and work the loans they are the assigned loan officer on. View Mortgage Pipeline (139) now means all of the organization's loans, and the write rights (140-144) hang under the new root, so holding a write right no longer implies seeing every loan. New organizations' Team Members role is granted the new right; the Administrator role is grant-all and keeps all loans. The 12 loan-level mortgage reports accept the new right and narrow their rows to the caller's own loans; the 6 organization-wide reports (HMDA LAR, edit checks, fair lending, call report, licensing, config changes) still require all loans.
· MCPGatewayService
Phone_schedule_wakeup, phone_cancel_wakeup, phone_list_wakeups (TPWAKEUP)
Owner order 2026-10-28, the first SI easter egg: anyone, signed in or not, on any channel, may ask an SI for a wake-up call (or cancel the ones for any number). The tools rely on nobody's identity, so the identity guard leaves them open on unproven channels; kamoai-service holds every safeguard (the easter egg setting, the read-back confirmation, do-not-call, opt-outs, toll fraud, limits, snooze cap). The run or call id tells it who is asking and their caller ID. ACCESS_VOIP, SI only; not disclosing, not content, approval phrases; goldens regenerated.
· kamo-login
Alexa consent asks whose link it is, which place, and what Alexa can use
Voice Assistant program (P1-6, P2-8, P5-3): "Just me" or "The organization" cards, the place whose devices an organization link sees, "What can Alexa use?" (presets, copy from a link, devices by room with security functions one by one; unlock, open and disarm door by door) or "Ask an admin to choose devices", and the "Kamo Alert" routine sensor. Customer words say devices. An older SecurityService answer (no options) still shows the original screen.
· SecurityService
The Alexa consent carries whose link it is, the place and "What can Alexa use?" to IoTService
Voice Assistant program (P1-6, P2-8, P5-3): LinkChoice gains ownerKind (ORG | MEMBER), siteId and grantChoice, shape-checked here and judged by IoTService; the consent view passes IoTService's options (ownership, devices, sites, sensors) and each link's owner kind to the page unchanged. Older pages without the new fields work as before.
· kamo-internal
Every card opens the thing it is about
A new-email notification opened /messages and left the member to find the mail. It now opens that message in the reading pane, scrolls the list to it with a brief wash in the org colour, and marks it read. That works from a cold load, while the mail client is already open, and from a shared mailbox (it switches back to the member's own). Reading the message by any route retires its card. The same pass over every kind: - The toast and the OS desktop notification followed the raw deepLink, so chat, text, voicemail and Hold'em cards went to the homepage. Both now use the intent resolver the centre uses, and so do producer buttons (resolveHrefIntent). - Hold'em invites and SI voice replies (/?tool=ai-chat&session=) open their window in place. - Billing cards open the invoices tab and the invoice's drawer. IoT automation-failure cards open the run they name. A repeat calendar reminder reopens its event. - Buttons say where they go ("Open the email", "Open the task", "Join the meeting") instead of "Open". - The centre's inert "Open" chip is now a one-click button beside each row. The row still opens the detail dialog.
· kamo-internal
Alexa link status in plain words, Try it, Choose devices, org voice assistant settings, my voice assistants and PIN, per-channel notifications, SI_ASSISTANT_REPLY
Voice Assistant program P1-9, P2-4, P2-5, P3-5, P4-5 (web). Each new call renders nothing until its backend answers (404), so this ships ahead of iot-service and emailservice. @kamo/iot-core 0.12.0.
· kamo-internal
Make or remove administrators and owners on the member profile; edit another member's own photos
Membership card: Administrator and Organization owner sit beside Membership type, each with its status and, only when SecurityService would accept it (GET .../leadership), a Make / Remove action behind a typed confirmation. A withheld action says why (not on yourself, owners are always administrators, the only owner). Make member is withheld from an owner or administrator until that status goes. The Roles & Permissions tab follows the same answer: its owner switch is offered to administrators too and never for the only owner, and the Administrator role checkbox locks when the change would be refused. Avatars: editing someone else's profile now lists, uploads to, picks from and deletes THEIR avatar library through the member-scoped routes (never the editor's own), and a refused save says so. The "use everywhere" scope is offered only on your own profile or an org-owned AI's.
· SecurityService
Owner and administrator changes follow one set of rules; another member's avatars are theirs
Leadership (OrgLeadershipService): - GET/PATCH **************** for the profile page. - PATCH .../access owner changes go through the same rules (an administrator may now change owners; echoing the current owner flag is no change); the Administrator role moves with it there. - The roles list may only move the Administrator role under those rules. - An administrator is not demoted to a member until that status goes. - Setting the org's only leader to a non-Active status is refused before anything is written. Avatars: MemberAvatarController **************** lists, uploads, creates and deletes the TARGET member's own avatars (self or MANAGE_MEMBER_SECURITY / open god window), and sets the account-wide default only for an org-owned AI. Written 2026-10-20 but never committed; ported onto main with fixes (god ELIGIBILITY no longer passes, missing size variants no longer NPE). PUT /members/{id} now answers 400 for an avatar from someone else's library instead of logging and returning 200, which is why an admin's photo pick looked saved and was not.
· kamo-shared-library
Owners and administrators, with one leader always kept; administrators always keep CONFIGURE_SYSTEM
OrgLeadershipService holds every rule for making or unmaking an organization owner or administrator: only an owner or administrator (or an open god window) may; nobody removes their own; an owner is always an administrator; and every organization keeps at least one LEADER, an active team member with status ACTIVE who is both **************** **************** a member holding the org's Administrator role resolves **************** (CONFIGURE_SYSTEM) as GRANTED after every level and the security model's FORCE rules, so a Department, Job Title, team, member override or FORCE_NUKE can no longer lock administrators out of Security Roles. AI guardrails still run after it.
· kamo-shared-library
Easter egg settings and wake-up call entities (TPWAKEUP)
Declares ai_easter_egg_settings, ai_wakeup_calls and ai_wakeup_optouts (kamoai-service **************** so KamoInitializer can recreate them.
· AIService
The SI Assistant's voice turn for Alexa
Voice Assistant program (2026-10-27) P3-1, P3-5. POST **************** (internal, X-Internal-Auth): the member's own assistant conversation through the same sync orchestration, with a voice style (two short spoken sentences, nothing clinical or secret), no PHI tools (EHR/health packs never, and PHI-sensitive tools in PHI organizations), risky calls held and asked as 'Shall I ...? Say yes or no.' (sends, money, security and devices need the spoken PIN before the yes is taken), a deadline after which the turn keeps running and raises SI_ASSISTANT_REPLY with phone push, 'put me through to <SI>' with that SI's own session (kamoai-service K5; paused or retired SIs refused), and 'send that to my phone'. Orchestration hooks are additive: TurnOptions on handleMessageSyncDetailed, SyncTurn.held, a tool filter on AssistantService.withTools, PlaneTool.phiSensitive from the Tool Plane's _meta.
· EmailService
Per-kind phone and voice channels, the voice mirror, and SI_ASSISTANT_REPLY
Voice Assistant program (2026-10-27) P3-5, P4-1, P4-2, P4-4. - GET/PUT /api/notifications/channels and PUT **************** per-kind PHONE/VOICE choices (BELL always on), voice quiet hours (default 21:00-08:00 member zone), voice daily cap (default 10). - raise(): the phone push honours the PHONE choice; NotificationVoiceSender sends a passing card after commit to IoTService /api/iot/internal/voice/notify (voice quiet hours, Kamo Do Not Disturb, a running calendar event and the cap hold it unless URGENT; RPM_ALERT and SI_AUTH_REQUEST never). Titles spoken are voice-safe. - **************** and /read for 'ask Kamo Universe what's new'. - SI_ASSISTANT_REPLY belongs to no app; listed after SI_AUTH_REQUEST.
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