# Feature status

> Every capability in Starlings, where it works, and the door an agent has into it.

One row per capability: its stance (Have, Partial, Want, Don't want, TBD), where it works, and how an agent reaches it: its doors, "human only" or "built in" with the reason, or "planned" when the door is not built yet.

## Surfaces

- **macOS Host** (`mac-host`): Authoritative host: starts rooms, admits guests, and runs local transcription.
- **macOS Join** (`mac-join`): The Mac app in Join mode: joins another room as a guest through the same waiting-room and media contract as the web. Calendar, Work, Team, Docs and Settings are the app's windows, open in either mode; Home's launch card, hosting and moderation are Host mode only.
- **Web** (`web`): Zero-install guest, booking, and signed-in workspace; live hosting still hands to a native owner client.
- **iOS / iPadOS** (`ios`): Hosts, admits, and transcribes on device, alongside joining and owner scheduling.

## Stances

- **Have** (`have`): Shipped in Starlings (Mac, browser, and/or iOS).
- **Partial** (`partial`): Present, but thinner than peers (scope, polish, or one client only).
- **Want** (`want`): Intentionally on the roadmap.
- **Don't want** (`dont-want`): Out of scope by product decision.
- **TBD** (`tbd`): Needs an explicit call.

## Entry, identity, and room access

- **Open a permanent room link and see room / invite context** (`entry-room`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A page for the guest who holds the link.) · doc: docs/AUDIENCES_AND_IA.md
  Bare room links stay opaque; booking tokens can add title, time, and subject.
- **Book a time from a room** (`entry-book`): Have · macOS Host not available, macOS Join handoff, Web works, iOS / iPadOS not available · agent: human only (A public page for visitors outside the workspace.) · doc: docs/AUDIENCES_AND_IA.md
  The Mac in Join mode opens the public web booking page from Book a time; Host mode has no such button. The phone joins; booking is a web door.
- **Sign up for an event and join with a personal link** (`entry-event-signup`): Have · macOS Host not available, macOS Join not available, Web works, iOS / iPadOS not available · agent: human only (A public page for visitors outside the workspace.) · doc: docs/SESSIONS.md
  An event with a room and a public slug has a sign-up page at /event/<slug>. Each person gets a personal room link and a calendar invite by mail. In the event window the room is a session: guests join muted and the transcript goes to the host only.
- **Send an event’s reminder and follow-up mails** (`event-follow-up`): Have · macOS Host not available, macOS Join not available, Web not available, iOS / iPadOS not available · agent: MCP tool task, /api/events/:id/follow-up · doc: docs/SESSIONS.md
  Each registrant gets one reminder an hour before the start, sent by the workspace on its own. The follow-up, with the event’s note and its call to action, goes out when a workspace admin or the person who made the event asks for it, through MCP or the API, to everyone who signed up and has not had it.
- **Enter guest name and email** (`entry-identity`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings join · doc: docs/ROOM_ENTRY.md
  Human guests do not need an account and provide email; a declared notetaker omits email and joins through the same owner-admission path.
- **Before-you-join camera and microphone check** (`entry-prejoin`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (Capture on the person's own camera and microphone.)
  Each surface uses its platform-native permission and device flow.
- **Ask to join, waiting-room status, cancel, and reconnect** (`entry-waiting`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings join, starlings leave · doc: docs/ROOM_ENTRY.md
  No LiveKit media token is issued until the owner admits the request. Every client can withdraw the knock and lands back on Prejoin.
- **Verified member sign-in** (`entry-owner-auth`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (Sign-in is the member's own Google consent.) · doc: docs/SECURITY.md
  A member signs in with an account on one of the workspace's identity domains. The Mac and iPhone apps sign in through the workspace's own sign-in page; Envisioning keeps its native Google sign-in for now. On the Mac sign-in belongs to the app, not the mode: Join mode fills in the signed-in owner's own name and email when you call a colleague.
- **Several workspaces in one app** (`entry-workspaces`): Have · macOS Host works, macOS Join works, Web not available, iOS / iPadOS works · agent: human only (Sign-in is the member's own Google consent.) · doc: docs/CENTRAL_AUTH.md
  The Mac and iPhone apps hold a session for each workspace a member adds, and switch between them: the Starlings menu › Switch Workspace on the Mac (the app reopens), Settings › Workspaces on iPhone. Each workspace keeps its own session, caches and links; a room link opens in the workspace it belongs to. No switch during a call. Sign Out leaves the other workspaces signed in; Sign Out of All Workspaces does not. On the web, each workspace is its own address.
- **Host presence / lease protection** (`entry-lease`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: built in (A rule the server holds. There is nothing to operate.) · doc: docs/SECURITY.md
  The control plane gates admission and token exchange on the owner device lease.
- **Token invite shows booking title / time / subject** (`invite-token-context`): Have · not built · agent: human only (A page for the guest who holds the link.)
  Booked links reveal that meeting only; bare slug stays opaque.
- **Guest reschedules / cancels a booking** (`book-reschedule`): Have · not built · agent: human only (A public page for visitors outside the workspace.)
  Handled on Core’s pages so calendar and CRM stay in sync.
- **Meeting password / passcode** (`meeting-passcode`): Don't want · not built · agent: none
  Lobby + owner admit is the gate.
- **Disposable / one-off room codes** (`one-off-room-codes`): Don't want · not built · agent: none
  Permanent owner rooms only.
- **Dial-in / PSTN phone audio** (`dial-in`): Don't want · not built · agent: none
  WebRTC clients only.
- **SIP / hardware room systems** (`sip-rooms`): Don't want · not built · agent: none
  Out of scope.

## Live audio, video, and stage

- **Mute and unmute microphone** (`media-mic`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings microphone
  Available before joining and during the meeting.
- **Start and stop camera** (`media-camera`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings camera
  Camera-off tiles retain participant identity across clients.
- **Choose camera, microphone, and output device** (`media-devices`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS partial · agent: starlings devices, starlings select-camera, starlings select-microphone, starlings select-speaker
  Every surface picks camera and microphone before joining and from the same chevron beside mute and camera in the call. iOS output stays with the system audio-route picker.
- **Spatial audio: voices from where the tiles are** (`media-spatial`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (What a person sees or hears in the call.)
  Starlings places each remote microphone on an arc in front of you, where that person's tile is on the stage, and moves the voice when the tile moves. HRTF on headphones, plain panning on speakers. On by default, with a switch on every surface. Screen-share audio stays centred.
- **Participant video grid, participant count, and People panel** (`media-stage`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (What a person sees or hears in the call.)
  Tuned for small rooms with a hard ~100-participant guardrail. People lists who is in the meeting with microphone, camera, and screen-share state; host actions stay native.
- **Publish a screen share** (`media-share-publish`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS not available · agent: starlings screen-share
  Mac uses a display / window picker; browsers also expose their native tab option.
- **Watch and identify a remote screen share** (`media-share-receive`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (What a person sees or hears in the call.)
  Shared tiles are named and visually distinguished from camera video.
- **Stop your own screen share** (`media-share-stop`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS not available · agent: starlings screen-share
  iOS does not publish screen shares.
- **Host stops another participant’s screen share** (`media-share-moderate`): Have · macOS Host works, macOS Join not available, Web not available, iOS / iPadOS works · agent: planned
  Host surfaces only; it stops the active share but does not ban future sharing.
- **Host mutes a participant, or everyone else** (`media-mute-moderate`): Have · macOS Host works, macOS Join not available, Web not available, iOS / iPadOS works · agent: planned
  Mac and iOS owners. Closes microphones and opens none — unmuting stays with the person muted, on every surface.
- **Told who muted you** (`media-mute-notice`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A notice to the person in the call.)
  The SFU mute is what silences the mic; the notice is what stops it reading as broken hardware.
- **Host removes a participant mid-call** (`media-remove`): Have · macOS Host works, macOS Join not available, Web not available, iOS / iPadOS works · agent: planned
  Mac and iOS owners, with confirmation. Disconnects them and spends the admission, so re-entry is a fresh knock.
- **Told you were removed, not dropped** (`media-remove-notice`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A notice to the person in the call.)
  All clients distinguish removal from connection loss. iOS observes the session phase and shows an ended receipt with the reason and a way to join again.
- **Background blur and branded background effects** (`media-background`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings blur
  Mac, web and iOS offer blur, Pixels, Flock and Grid in workspace tones, a workspace picture and a personal picture. Admin sets derived or explicit tones, uploads the public workspace picture and chooses a default; a personal choice, including Off, wins. Personal pictures stay on the device, scaled and re-encoded without metadata. Segmentation runs on the device — the room sees only composited frames.
- **Hide self view** (`media-self-view`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (What a person sees or hears in the call.)
  Hiding the preview does not stop publishing the camera.
- **Connection quality and reconnect handling** (`media-quality`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: built in (The client does this on its own.)
  iOS shows per-person quality and an explicit reconnecting state in the participants panel.
- **Leave the meeting or end it for everyone** (`media-leave`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings leave
  Guests and owner companions leave their own session. Mac and iOS hosts can end a personal room for everyone; ending the shared internal room for everyone is a separate confirmed action.
- **Speaker / output device selection** (`output-device`): Have · not built · agent: starlings select-speaker
  Mac Settings, in-meeting menus, starlings; web prejoin + settings where the browser supports it; iOS route picker.
- **Share a region of the screen** (`share-region`): Want · not built · agent: none
  Natural third option in the Mac picker.
- **Share one browser tab** (`share-tab`): Partial · not built · agent: human only (The browser asks the person which tab to share.)
  Browser guests already can; Mac host shares a whole window.
- **Share computer audio with screen** (`share-computer-audio`): TBD · not built · agent: none
  Common peer feature; not a first-class control today.
- **End meeting for all (host)** (`end-for-all`): Have · not built · agent: starlings leave
  Owner finalizes the room and notes path.
- **Rejoin after brief disconnect** (`rejoin`): Have · not built · agent: built in (The client does this on its own.)
  Admitted credential → fresh token while the lease is live.
- **Speaker / active-speaker emphasis** (`active-speaker`): Partial · not built · agent: human only (What a person sees or hears in the call.)
  Screen share auto-pins on web; no full Speaker View.
- **Pin / spotlight a participant** (`pin-spotlight`): Don't want · not built · agent: none
  Removed. A screen share takes the big tile on its own; there is no local pin and no host spotlight.
- **Gallery vs Speaker view toggle** (`gallery-speaker-toggle`): TBD · not built · agent: none
  Starlings is grid-first today.
- **Full screen meeting window** (`full-screen`): Partial · not built · agent: human only (What a person sees or hears in the call.)
  OS window chrome; no dedicated in-app stage mode.
- **Picture-in-picture / pop-out video** (`picture-in-picture`): Partial · not built · agent: human only (What a person sees or hears in the call.)
  Optional Mac self-view only; it can dock back to the stage. There is no generic participant pop-out.
- **Immersive / together mode layouts** (`together-mode`): Don't want · not built · agent: none
  Novelty layouts.
- **Virtual / brand backgrounds** (`brand-backgrounds`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (Capture on the person's own camera and microphone.)
  Workspace backgrounds are configured in Admin → People → Workspace: derived or explicit tone pairs, a public picture and an optional default. All clients read the live workspace descriptor; personal pictures stay local.
- **Beauty / touch-up filters** (`touch-up-filters`): Don't want · not built · agent: none
  Out of scope.
- **Browser noise suppression / AEC** (`noise-suppression`): Have · not built · agent: human only (Capture on the person's own camera and microphone.)
  Explicit capture defaults on web.
- **Advanced voice isolation** (`voice-isolation`): TBD · not built · agent: none
  OS-level on Mac; not a Starlings control yet.
- **HD / 1080p video toggle** (`hd-video`): Partial · not built · agent: human only (Capture on the person's own camera and microphone.)
  Capture around 720p-class; no user HD switch.
- **Low-light adjustment** (`low-light`): Don't want · not built · agent: none
  Out of scope.
- **Lock meeting (no new joins)** (`lock-meeting`): Partial · not built · agent: built in (A rule the server holds. There is nothing to operate.)
  Implicit when the lease dies; no explicit lock toggle.
- **Co-host / alternate host** (`co-host`): Don't want · not built · agent: none
  Exactly one verified member owns each room.
- **Host tools security menu** (`security-menu`): Don't want · not built · agent: none
  Single-owner model.
- **Domain-restricted hosting** (`domain-restricted-hosting`): Have · not built · agent: built in (A rule the server holds. There is nothing to operate.) · doc: docs/SECURITY.md
  Only members on the workspace's identity domains host.

## In-meeting collaboration and captions

- **Room text chat** (`collab-chat`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: planned
  One room-wide text channel; file attachments and private DMs are not offered.
- **Embedded preview for a pasted link** (`collab-link-previews`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A card drawn for the person who reads the chat.)
  The Worker reads the page and answers text; no client ever fetches a pasted link, so a site never learns who was in the room. In a meeting the read is authorized by the meeting itself, because a guest has no account. The page’s picture comes through the Worker too, on a signed address — without that signature the route would be an open image proxy.
- **Ephemeral emoji reactions** (`collab-reactions`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A gesture between people in the call.)
  Six reactions float in the room and are not stored.
- **Reactions on a chat message** (`collab-chat-reactions`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A gesture between people in the call.)
  The same six emoji, on a message rather than on the room. Reliable rather than lossy, because a tally has to still be right in ten minutes — but stored nowhere: they last as long as the chat does, which is the call, and never reach the record or the summary.
- **Live captions from the owner device** (`collab-captions`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: starlings transcript · doc: docs/TRANSCRIPTION.md
  Speech-to-text runs locally on whichever owner device is the host; only caption text is shared.
- **Show and hide the live transcript / captions view** (`collab-transcript-ui`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (What a person sees or hears in the call.) · doc: docs/TRANSCRIPTION.md
  iOS keeps the caption strip on the stage and opens the full transcript from More.
- **Finalized transcript and AI summary delivery** (`collab-artifacts`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool transcript, MCP resource starlings://meeting/{room}/{meeting_id}, MCP resource starlings://changes/{cursor}, /api/rooms/:slug/meetings · doc: docs/TRANSCRIPTION.md
  Read in Starlings once finalized, by participants with artifact access; consent-filtered. Share a link to the meeting page (it grants nothing), copy the text, or download .md or .txt: on the web from the meeting page, on the Mac and iPhone from the live transcript. Nothing is emailed and nothing is recorded.
- **Meeting duration and ended receipt** (`collab-duration`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A notice to the person in the call.)
  Joining clients explain when the owner ended the room or the session was lost.
- **Chat file attachments** (`chat-attachments`): Don't want · not built · agent: none
  Text only; no file plane.
- **Raise hand** (`raise-hand`): Have · not built · agent: human only (A gesture between people in the call.)
  Stays up until lowered, survives reconnects; badge on the tile, queue count on People. The host can lower every hand at once.
- **Participant list panel** (`people-panel`): Have · not built · agent: planned
  People panel on every client with per-person mic, camera, and share state; host actions (mute, remove) stay native.
- **Private / DM chat** (`private-chat`): Don't want · not built · agent: none
  One room chat.
- **Whiteboard** (`whiteboard`): Don't want · not built · agent: none
  Use external docs.
- **Collaborative docs / slides in-call** (`in-call-docs`): Don't want · not built · agent: none
  Out of scope.
- **Polls / quizzes** (`polls`): Don't want · not built · agent: none
  Out of scope.
- **Breakout rooms** (`breakout-rooms`): Don't want · not built · agent: none
  Explicit non-goal.
- **Annotation on shared screen** (`screen-annotation`): Don't want · not built · agent: none
  Out of scope.
- **Third-party in-meeting apps** (`in-meeting-apps`): Don't want · not built · agent: none
  No marketplace.
- **AI meeting summary** (`ai-summary`): Have · not built · agent: MCP tool transcript · doc: docs/TRANSCRIPTION.md
  Available in Starlings after finalization to participants with artifact access.
- **Cloud A/V recording + playback URL** (`cloud-recording`): Want · not built · agent: none · doc: docs/PRIVACY.md
  Proposed, not decided. Starlings does not record today; consent and retention still open.
- **Local A/V recording** (`local-recording`): Don't want · not built · agent: none
  Cloud recording is the supported path if it ships.
- **Livestream to YouTube / Twitch** (`livestream`): Don't want · not built · agent: none
  Out of scope.
- **Artifact viewer / delete / export** (`artifact-management`): Want · not built · agent: none
  Needed before broad transcript rollout.
- **CRM / meeting log ingest** (`crm-ingest`): Have · not built · agent: MCP resource starlings://feed/{limit} · doc: docs/MEETING_LOG.md
  Hosted Starlings sessions and Granola notes can sync finalized meeting text into Core interactions; deployment needs the optional Core secret and migration.
- **Share a project with people outside the team: a guest thread for clients, an organization’s Claude** (`subject-sharing`): Partial · macOS Host not available, macOS Join not available, Web works, iOS / iPadOS not available · agent: human only (Who outside the team sees a project is a decision for a person.) · doc: docs/ACCESS.md
  Share in a subject’s header on the web grants a member, agent, guest or organization read or write on that one subject, or restricts it to the people added. A guest opens a link to the subject’s guest thread with no account; a partner organization’s Claude reaches the same thread through /mcp with its own token. Outside lines are tagged and never wake an agent. Mac and iPhone draw neither the Share dialog nor the guest thread yet (meet#895).

## Owner workspace, scheduling, and operations

- **Home / own room status / copy room link** (`owner-home`): Have · macOS Host works, macOS Join not available, Web works, iOS / iPadOS works · agent: MCP tool now
  Home is today on web too — the clock, then the modules in the order you chose in Settings → Home, among them your room with its link, a copy button and Schedule…, with Home / Calendar / Work / Team / Docs navigation. The member room flow belongs to Home; `/join` remains a direct public room door. On the Mac the launch card is Host mode only. Starting the room is native (see Start room, admit / reject guests).
- **Connect Google Calendar and subscribed feeds, view the Upcoming agenda** (`owner-calendar`): Have · macOS Host works, macOS Join works, Web partial, iOS / iPadOS works · agent: MCP resource starlings://calendar/{days_back}/{days_ahead}, /api/calendar/events, /api/calendar/upcoming · doc: docs/CALENDAR.md
  Account attachments, Google calendar selection, and subscribed-feed selection use the shared control-plane contract; refresh tokens stay encrypted there, not on the device. Home Upcoming includes selected Google calendars and subscribed feeds on Mac, iOS, and web; events marked Hide from Next are omitted there and from alerts, while remaining visible in Calendar. Web reads the Google week or month at `/calendar`, shows explicit travel duration metadata when present, and can start the Google connect flow. Its Calendars menu turns each account, Google calendar and the subscribed feeds on or off in the same owner-wide choice the Mac and iPhone read. It can create timed events, edit and delete writable ones, and answer an invitation. EventKit calendars are read on the Mac and iPhone only.
- **Native Calendar views (Google + EventKit + subscriptions)** (`owner-calendar-window`): Have · macOS Host works, macOS Join works, Web partial, iOS / iPadOS partial · agent: human only (The person's own preferences and views.) · doc: docs/CALENDAR.md
  Mac has the full window/sidebar and direct grid move/resize; iOS has day/2-day/3-day/week/month/agenda, source management, and deliberate long-press movement, while resize stays in the editor. Upcoming rows show explicit travel duration metadata when supplied; Starlings never estimates routes. Envisioning Internal remains writable shared context but is not a move source or destination; Duplicate is the copy path. Web shows one Google week or one month at a time, with no day or multi-day grid and no drag. It adds read-only Events, Milestones, Tasks, and Core-computed My availability layers, which it toggles only in the browser.
- **Create a meeting invitation from the owner workspace** (`owner-schedule`): Partial · macOS Host works, macOS Join works, Web partial, iOS / iPadOS works · agent: MCP tool schedule · doc: docs/CALENDAR.md
  Native clients create meeting invitations; web creates timed or all-day Google events with invitees, location and notes. Adding a Starlings booking token remains native; visitor booking is separate.
- **Describe an event in one sentence** (`owner-calendar-quick-add`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A typing aid for the event form. An agent passes the fields to schedule.) · doc: docs/CALENDAR.md
  A field above the new-event form fills in title, times, place and guests from one sentence, on all three surfaces; nothing is saved until Add. One grammar in Swift and TypeScript on one fixture; a sentence it cannot read goes to the notes engine, and the form says so.
- **Forward a mail to calendar@ and add the events it describes** (`owner-calendar-from-email`): Have · macOS Host works, macOS Join not available, Web works, iOS / iPadOS works · agent: planned · doc: docs/CALENDAR.md
  A member forwards a booking or an invitation to calendar@ on the inbound domain; the Inbox proposes each event with Add to calendar and Discard, on all three surfaces. Add writes to the primary Google calendar. The mail body is read once and not kept. Needs INBOUND_EMAIL_DOMAIN, which production does not have yet.
- **Calendar selection, display preferences, timezone/weather, public events, and contacts** (`owner-calendar-tools`): Have · macOS Host works, macOS Join works, Web partial, iOS / iPadOS works · agent: human only (The person's own preferences and views.) · doc: docs/CALENDAR.md
  Source selection is one owner-wide choice that the Mac, iPhone and web Calendars menu all write, and Upcoming display policy is shared and editable from Settings on all three surfaces. Device-local grid preferences, timezone/weather, and contacts remain native. Web lists and locally toggles the read-only Events, Milestones, Tasks, and Core-computed My availability layers. Web edits all-day dates and chooses This event or All events on a recurring Google event; the Mac adds All future on EventKit calendars, which the browser does not read.
- **Start room, admit / reject guests, and end room** (`owner-admit`): Have · macOS Host works, macOS Join not available, Web handoff, iOS / iPadOS works · agent: starlings host, starlings lobby, starlings admit, starlings reject · doc: docs/OPERATIONS.md
  iOS hosts its owner’s permanent room: start, waiting room, admit and decline, end. Web still explains the native requirement and offers “Join my room” while the room is open, rather than starting one.
- **Move the host between devices and members** (`owner-host-handoff`): Have · macOS Host works, macOS Join works, Web not available, iOS / iPadOS works · agent: human only (A live call between people.) · doc: https://starlingshq.com/help/surfaces/meeting
  The host sees a Host badge on its tile, and so does everyone. Move host… hands the host to another Mac, iPhone or iPad in the call: another of the same member takes it at once; another member of the workspace is asked and, on yes, rejoins as the host, in any room. A connected Mac companion can also take the host; the current Mac drains local transcription and uploads pending text first. When the host leaves or its lease runs out, a connected companion Mac takes host on its own. The room owner keeps room settings and End meeting, and can take the host back. A live phone host is asked to hand over only when it offered the host itself.
- **Guest knock alerts and host wake protection** (`owner-alerts`): Have · macOS Host works, macOS Join partial, Web not available, iOS / iPadOS partial · agent: human only (Sound, badges and wake on the person's own device.) · doc: docs/OPERATIONS.md
  Mac owns waiting-room sound / Dock alerts and the host wake assertion; in Join mode it still sounds and badges a knock at your own room, but holds no wake assertion. iOS posts a local knock notification while the app is running — there is no push — and holds the screen awake instead of a wake assertion.
- **Account, audio/video, captions, calendar, privacy, and update settings** (`owner-settings`): Have · macOS Host works, macOS Join works, Web partial, iOS / iPadOS partial · agent: human only (The person's own preferences and views.)
  Mac has the complete settings area, in either mode. Web has Settings at /settings from the header gear — account and picture, Google Calendar connection, the Gmail and Drive grant, appearance, about, sign out; audio, video and background stay in the in-meeting Settings. Privacy remains available from the site footer. iOS exposes its applicable subset.
- **Team presence: who in the workspace is around, and call a peer** (`owner-team-presence`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool now, MCP tool search, /api/peers · doc: docs/PRESENCE.md
  Members only, never guests. Every client reads the roster and offers Message, Wave, Call, and Join room from a person's context menu; a video mark on the shared avatar shows a live meeting. Agents are messageable but never waved or called.
- **Profile picture — one face per member, drawn everywhere a person is** (`owner-profile-picture`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (Each member uploads their own picture.)
  Members only, never guests: the roster carries the version, the image is a member-gated read, and every surface falls back to the same initials. Uploaded from the Team window on macOS, the Team tab on iOS, and your own row at `/team`. Seeded once from the Google account picture, which an upload replaces.
- **Direct messages between members** (`owner-direct-messages`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool send_message, MCP resource starlings://thread/{id}, MCP resource starlings://changes/{cursor}, /api/threads/:id/messages, /api/threads/messages · doc: docs/CHANNELS.md
  Team opens DMs, notes to self and Everyone on all clients. Format message text with bold, italic, strikethrough, inline code, links, lists, quotes, and code blocks; each client renders the same Markdown subset. React to any message, including your own; copy your own text to private Quick Notes for the usual Work triage. Web supports send, older history, visible-tab polling, bounded read receipts, and per-member archive; a new message brings an archived DM back.
- **Interactive questions in agent conversations** (`owner-agent-interactive-questions`): Have · macOS Host partial, macOS Join partial, Web works, iOS / iPadOS partial · agent: HMAC callback /api/internal/channel-events · doc: docs/AGENTS_SURFACE.md
  New questions in shared chats name one eligible human recipient; only that person can answer. Existing unassigned shared questions retain their chat behavior. An agent can ask a short informational question with two to eight choices in its DM or a thread it belongs to. A single choice submits immediately; people select several options and explicitly submit them. Starlings stores one winning human reply and resumes the same Eve thread session. Web chat reads canonical terminal state and assigned-recipient controls. Mac and iOS answer inline and render projected replies; canonical dismissal and recipient presentation remain in #774. It does not request approval or authorization.
- **Answer agent questions from Inbox** (`owner-question-inbox`): Have · macOS Host not available, macOS Join not available, Web works, iOS / iPadOS not available · agent: human only (Only the assigned human recipient can answer or dismiss their request.) · doc: https://starlingshq.com/help/howto/answer-a-question
  On the web, Home and Work Inbox show assigned questions with the asker and source context. Answer with button choices or explicitly dismiss. The originating web chat reads the same winning request and closes terminal controls. Native Inbox controls and canonical chat refresh remain in #774; existing native question replies still resolve the server record.
- **Approve the follow-up after a call** (`owner-after-call-follow-up`): Have · macOS Host works, macOS Join not available, Web works, iOS / iPadOS works · agent: human only (Only the host approves; Starlings never sends the mail.) · doc: https://starlingshq.com/help/howto/send-a-follow-up-after-a-call
  After a call filed on a lead, project or partner with people from outside the team, the host gets a drafted follow-up in Inbox with the call's proposed tasks. Approve accepts the ticked tasks, declines the rest, and opens the draft in the host's own mail app. The web edits the draft before Approve; the Mac and the iPhone edit it in the mail app. Unanswered, it leaves Inbox after a week.
- **Check agent work from Inbox** (`owner-agent-review-inbox`): Have · macOS Host works, macOS Join not available, Web works, iOS / iPadOS works · agent: human only (An agent moves a card as far as Review or Blocked. Only a person moves it to Done or Dropped.) · doc: https://starlingshq.com/help/howto/hand-off-a-card-to-an-agent
  A card an agent moved to Review or Blocked is an Inbox row for the person who handed it off, on Work and Home. The row opens the card and leaves when the card moves on. Tasks and GitHub issues both arrive.
- **Private group conversations** (`owner-group-dms`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool send_message, MCP resource starlings://thread/{id} · doc: docs/CHANNELS.md
  A DM with more than one other person in it — same kind, same authorization, no name: the people in it are the name. Started from Team on every client, and found there again afterwards. Up to twelve people; past that the answer is Everyone. Not a channel, and not discoverable — you cannot browse to one, only be in one.
- **Channels on the work itself** (`owner-channels`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool send_message, MCP resource starlings://thread/{id} · doc: docs/CHANNELS.md
  One conversation on each project and lead, reached by opening the subject in Work — never by making a channel. Unread routes to Work on every client: the Mac launch button, the iOS tab badge and Home card, and Work's Mine pane, which lists subjects with something new first. Web opens the subject conversation from Talk in Work.
- **Projects and leads, with their tasks and issues** (`owner-work`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool search, MCP tool open, MCP tool task, MCP tool record_decision, MCP tool set_goal, MCP resource starlings://subject/{kind}/{id}, MCP resource starlings://subjects/{kind}, MCP resource starlings://board/{days}, MCP resource starlings://board/project/{id}/{days}, /api/crm/board, /api/crm/tasks, /api/crm/mine, /api/crm/recently-closed, /api/crm/unowned, /api/crm/goals, /api/crm/decisions, /api/crm/subjects, /api/crm/organizations · doc: docs/WORK.md
  Work: Mine, the workspace's own projects, Projects and Leads — a foldable sidebar on Mac and a single work list on iOS, with the same work graph on web. New leads and projects require a Core organization; the Mac, iPhone/iPad and web pickers search Core and can create an organization inline. Create, assign, date, complete and file a task on GitHub; read, comment on, close and file GitHub issues on a linked project. Mine completes in place on every client (a tick on Mac and web, a swipe on iOS) and files on GitHub from the row natively. Team person details on every client also list assigned open tasks and, when GitHub is connected, issues; task rows open in the client task view, and New task starts the usual editor after a searchable project/lead choice. Recently finished work stays available for seven days on all three clients, with a Reopen action for tasks and issues. A project's Board pane shows its tasks and issues by stage on all three clients, with drag (Mac, web) or a move menu (iOS) to change a stage, Hand off to an agent from a card's menu, a filter by who holds a card, and columns each person hides on every device. Overview lists UNOWNED below Mine on all three clients: open tasks and issues on any subject that nobody on Envisioning's side holds. All three clients create and edit supported project/lead fields through the Worker; Core stays the system of record. A member's Claude creates a lead or a project through MCP `task` with `action: "create_lead"` or `action: "create_project"`, naming the organization by id or by name, on Core and on a D1 workspace; Core posts "New Lead Created" in a lead's channel. Web also creates, edits, comments on, closes/reopens and manages metadata for issues.
- **Goals on a project, decisions on any subject** (`owner-goals-decisions`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool search, MCP tool open, MCP tool record_decision, MCP tool set_goal, MCP tool task, MCP tool transcript, MCP resource starlings://subject/{kind}/{id}, /api/crm/goals, /api/crm/decisions · doc: https://starlingshq.com/help/surfaces/work
  A goal is a title with a status, a target date and an owner on a project; tasks and decisions point at it. A decision is something the team settled on a project, lead, partner or event, written once, with its source: typed, a channel line marked as one, a Claude through MCP, or the meeting notes. Both live in Core. Every client lists them on the subject, picks a goal on the task sheet, marks a channel line as a decision, and finds both in search; the web meeting page records or dismisses what the notes proposed. Meet#261, #262, #278.
- **A queue of decisions waiting on you** (`owner-decision-queue`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool ask_decision, MCP tool now, MCP tool open, MCP resource starlings://subject/{kind}/{id}, /api/decision-asks · doc: https://starlingshq.com/help/howto/answer-a-decision
  An agent puts a question to a member through MCP `ask_decision` — options, a recommendation and a default-by day — when nobody is in the conversation with it, instead of burying it in an issue comment. It is the first row in INBOX on every client, overdue first; one tap on an option answers it, with an optional note, and opening it shows the context and links. The agent reads the answer back through `now` or `ask_decision`. An answer on a subject is recorded as that subject's decision in Core. Past the default-by day a decision shows as overdue; the recommendation is applied only when somebody asks for it.
- **Interaction history on a project or lead** (`owner-interactions`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP resource starlings://feed/{limit}, /api/crm/feed · doc: docs/MEETING_LOG.md
  A read-only History pane combines interactions with quiet subject events. Activity in Work Overview on Mac, iOS and web shows the latest 30 entries from the past seven days across visible, unmuted open projects and events, plus leads with Sales on; every entry opens its subject at History. Activity is separate from response items and unread counts.
- **Every field on a project, lead or partner** (`owner-core-fields`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool cms, MCP resource starlings://core/registry · doc: docs/CORE_REGISTRY.md
  A subject's Fields pane draws every field Core's registry lists for the record behind it — the project, the lead, or a partner's organization — and saves only what changed, when you say, as you. Core decides what you may change. Mac and iOS read Core with a device token; the web reads and writes through Starlings as the member and holds no Core token. The web edits text, numbers, dates, toggles and choices; relations, lists, countries and industries show read-only there and edit on the Mac, the phone or in Core. An event's fields are its CMS page.
- **Core in search** (`owner-core-search`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool cms · doc: docs/CORE_REGISTRY.md
  Search lists each Core entity you can read. On Mac and iOS it opens that entity in Work's Core browser, and Search Core finds records across them. On the web the entity opens on Core's own page, and the palette finds Core records below Docs: a project or lead opens on its Fields in Work, anything else on its Core page. Browsing Core entity by entity stays on Mac and iOS.
- **Keep: client credentials in sealed vaults** (`owner-keep`): Have · macOS Host works, macOS Join works, Web handoff, iOS / iPadOS works · agent: planned · doc: docs/KEEP.md
  Keep holds client credentials in vaults the server cannot read: every value is sealed on the device under keys only the vault's members hold. Mac and iOS open Keep from Work, and a project's menu opens its vault. The web is deliberately without Keep: a browser would have to trust whoever serves its JavaScript with the keys, so a project's Keep vault on the web says to open it on Mac or iPhone and never shows vault material.
- **Release one Keep item to an agent** (`owner-keep-release`): Have · macOS Host works, macOS Join works, Web handoff, iOS / iPadOS works · agent: HMAC callback /api/internal/channel-events, HMAC callback /api/internal/keep-release · doc: docs/KEEP.md
  An agent asks in a thread for one item of a Keep vault, for one task: a card names the item, the task, the reason and the time asked for, never a value. A member of that vault taps Approve on Mac or iPhone and picks how long, 15 minutes by default and 24 hours at most. Keep unlocks there, and that device seals the item to a key the agent made for this request; the server never sees the value. The agent fetches it once before the expiry. End now on the card, or Revoke in Keep's list, ends it sooner. Keep records the approval, the fetch and the end. The web shows the card and says to approve on Mac or iPhone.
- **Issues that read like GitHub's own** (`owner-issues`): Have · macOS Host works, macOS Join works, Web partial, iOS / iPadOS works · agent: MCP tool create_issue, /api/crm/issue · doc: docs/WORK.md
  Both native clients have labels, assignees, milestones, server-backed filters/sort, pagination, issue details, comments and activity, and metadata editing. iOS uses Foundation markdown with fallback text; Mac has its own richer reading surface. Web reads details/activity and supports issue actions with repository metadata pickers; description text preserves markdown source, while native reading remains richer.
- **Today's work on Home** (`owner-today-work`): Have · macOS Host works, macOS Join not available, Web works, iOS / iPadOS works · agent: MCP tool now, /api/crm/mine
  What is overdue and what is due today, on the Mac launch card and menu bar, on the iOS Home and on the web Home (its Work card), each row opening its subject in Work on the Tasks pane. Decided on the device, so "today" is the day you are in. Hidden when there is nothing.
- **Meet about a project or lead** (`owner-meet-about`): Have · macOS Host works, macOS Join not available, Web not available, iOS / iPadOS works · agent: planned
  Start your room from a subject in Work and the meeting is filed under it the moment it opens — notes and tasks land where the conversation is. On the Mac a filed meeting's CRM sidebar opens the subject in Work; the phone's hosting screen owns the session and has no door out.
- **A meeting's trail in its channel** (`owner-channel-events`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP resource starlings://thread/{id}, HMAC callback /api/internal/channel-events
  A project or lead channel carries quiet lines the work graph writes: a meeting filed here, ended and how long it ran, notes filed, a task the meeting proposed and somebody accepted. Never unread on their own, never the preview. Web renders these event rows in Talk too.
- **A calendar event knows its project or lead** (`owner-event-subject`): Have · macOS Host works, macOS Join works, Web partial, iOS / iPadOS works · agent: planned
  File any event under a subject from the Mac inspector or the phone's event sheet; the choice is owner-wide. The web event editor names the subject an event is filed on and links to it, but cannot file one. A room started from that event is filed under it, Home and the launch card name it, and Google events arrive filed from the control plane.
- **Docs: the corpus, read and written from Starlings** (`owner-docs`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool docs_write, MCP resource starlings://document/{id} · doc: docs/DOCS.md
  The fifth surface: newsletters, reports, research, notes and everything written from Starlings, on the shared shell. Documents on a subject in Work are the contextual slice of the same store. Connecting is one act in Settings → Account. A member's Claude shares a document under /work by link when the member asks; other folders and public stay the member's act, in Docs.
- **Docs graph view** (`owner-docs-graph`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A picture of the corpus for people. An agent reads the documents.) · doc: https://starlingshq.com/help/surfaces/docs
  See up to 5,000 accessible Docs documents in the same graph across Mac, iPhone, iPad, and web. Folders group and color nodes; resolved wikilinks draw connections and pull related nodes closer. Filter groups, pan, zoom, fit visible nodes, and open documents.

## Call and task reading

- **Call an available colleague** (`owner-call`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: human only (A live call between people.)
  Call asks an available colleague to open their room, waits up to 45 seconds, and joins through the ordinary admission flow when it opens. When a meeting is already live, the person menu offers Join room directly.
- **Answer an idle-room Call** (`owner-answer-call`): Have · macOS Host works, macOS Join not available, Web handoff, iOS / iPadOS works · agent: human only (A live call between people.)
  Native clients offer Open room / Not now; the browser explains the native hosting requirement and can decline. Calls do not enable notes by default on the answering native device; notes can be turned on deliberately.
- **Read a task directly from Mine** (`owner-task-reader`): Have · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: MCP tool open, MCP tool task, /api/crm/mine
  Every client opens task details and subject navigation from Mine, with edit and completion actions. iOS also opens the same reader from a subject task list.

## Clients, ops, and platform

- **CLI / agent control through `starlings`** (`owner-cli`): Have · macOS Host works, macOS Join not available, Web not available, iOS / iPadOS not available · agent: starlings status, starlings devices, starlings show, starlings auth, starlings host, starlings join, starlings leave, starlings lobby, starlings admit, starlings reject, starlings microphone, starlings camera, starlings blur, starlings screen-share, starlings select-camera, starlings select-microphone, starlings select-speaker, starlings transcript · doc: docs/OPERATIONS.md
  Same-user local socket for status, host, lobby, media, transcript, and leave commands.
- **Native auto-update** (`owner-updates`): Have · macOS Host works, macOS Join works, Web not available, iOS / iPadOS not available · agent: human only (The person installs and updates the app on their own device.) · doc: docs/UPDATER.md
  Mac checks the signed update feed; iOS uses App Store / TestFlight distribution.
- **macOS native host app** (`mac-host-app`): Have · not built · agent: starlings host
  AppKit Host mode.
- **macOS native join** (`mac-join`): Have · not built · agent: starlings join
  Same admit contract as the browser.
- **Browser guest** (`browser-guest`): Have · not built · agent: human only (A page for the guest who holds the link.)
  Primary guest path.
- **Windows / Linux native** (`windows-linux`): Don't want · not built · agent: none
  Browser covers guests.
- **iOS / iPad client** (`ios-client`): Have · not built · agent: human only (The person installs and updates the app on their own device.)
  SwiftUI Host and Join: start your room, admit at the door, transcribe on device, file the meeting. Screen sharing from iOS is still ahead.
- **Android client** (`android-client`): TBD · not built · agent: none
  Browser may be enough.
- **Meeting info panel** (`meeting-info`): Partial · not built · agent: starlings status
  Invite link + room status; no Zoom-style Meeting Info sheet.
- **Webinar / presenter–audience roles** (`webinar-roles`): Want · not built · agent: none
  Backlog; do not market webinars until roles and load work exist.
- **Capacity hard limit (~100)** (`capacity-limit`): Have · not built · agent: built in (A rule the server holds. There is nothing to operate.)
  Safety guardrail, not a webinar product.
- **One wire contract for every client** (`one-wire-contract`): Have · not built · agent: built in (A rule the server holds. There is nothing to operate.) · doc: docs/DOCUMENTATION.md
  Every shape the server sends or accepts is written once, as a schema. The web reads it as types, and the Mac, iPhone and watch read and write Swift generated from it. A field that changes fails the build, not the phone.
- **Notetakers attend as declared meeting participants** (`centaur-room`): Partial · macOS Host works, macOS Join works, Web works, iOS / iPadOS works · agent: planned · doc: docs/CENTAUR.md
  The listening slice works on every client; the row stays partial for the speaking half. A link-joining recording notetaker declares itself, waits for owner admission, is marked across the room, can be refused per room, and leaves a transcript consent line. Speaking agents, their room-side worker, and live MCP tools remain planned.
- **Website content from a Claude** (`cms-content`): Have · not built · agent: MCP tool cms, MCP resource starlings://cms/registry, MCP resource starlings://core/registry · doc: docs/MCP.md
  A member's Claude reads and writes envisioning.com content — events, and the other CMS entities the registry publishes — through Starlings, as the member, with a cms-editor PAT. On the web, a member with that grant also edits an event's CMS record from the Calendar and Work (meet#530). The same tool lists and reads organizations, contacts, interactions, projects and leads, creates and edits all five (a note is an interaction), and deletes an organization only when no record points at it, as the member.
- **An agent starts a meeting** (`agent-meeting`): Have · not built · agent: MCP tool start_meeting, MCP tool schedule, starlings host · doc: docs/MCP.md
  `start_meeting` schedules the meeting in the member's own room and asks their devices to open it: the ask rides `rings` with a 45-second life, and the member answers Open room or Not now. The Worker never hosts and nothing opens a microphone on its own, so an unanswered ask leaves the meeting on the calendar and the room shut. A meeting opened this way transcribes, because it is convened; a walk-up from Call does not.
- **Any agent joins Team by enrollment** (`agent-enrollment`): Have · macOS Host not available, macOS Join not available, Web works, iOS / iPadOS not available · agent: /api/agents/enroll, /api/agents/enroll/poll · doc: docs/AGENTS_SURFACE.md
  An agent runtime anywhere (Hermes, Eve, custom code) asks to join a workspace's Team with its name and an https endpoint, and shows a short code. A workspace admin approves the code in web Admin › Agents. The runtime then collects its address (`<name>@agents.<workspace host>`, given by Starlings) and its own two keys, once. No configuration change or deploy. An admin removes an enrolled agent there too; its keys stop working at once. The agent appears in Team on every client.
- **Default workspace agent for meeting follow-through** (`built-in-meeting-agent`): Want · not built · agent: HMAC callback /api/internal/meeting-agent/context, HMAC callback /api/internal/meeting-agent/commit, HMAC callback /api/internal/meeting-agent/status · doc: docs/AGENTS_SURFACE.md
  A named Starlings-managed agent will read finalized meeting text, propose notes, tasks and decisions, explain their sources and draft an unsent follow-up. Identity, meeting grants and signed context/result tools with canonical persistence are implemented (#1082, #1085); managed runtime, onboarding and dispatch remain #1083, #1084 and #1086. Included product processing remains separate from customer subscriptions; no live media access or automatically accepted work.
- **Agent activity in Admin** (`admin-agent-activity`): Have · macOS Host not available, macOS Join not available, Web works, iOS / iPadOS not available · agent: human only (Oversight of agents is for people.) · doc: docs/ADMIN.md
  Web Admin › Agents shows the last 30 days of handoffs, runtime acceptance or refusal, final replies observed by Starlings, and watchdog reset outcomes. It does not show work inside an agent runtime or model costs.
- **Error overview from a Claude** (`admin-error-overview`): Have · not built · agent: MCP resource starlings://operational-errors/{window} · doc: docs/MCP.md
  An admin asks their own Claude what is failing across Starlings (meet#419). It reads error groups from Mac, iOS, web and the Worker, ranked by count over the last day, week or month, filtered by release, platform or code, each with its trend against the previous window and a few request ids to find the Worker log. Codes and counts only: no error text, people, rooms or meeting content. A member is refused, and so is an agent acting for anyone.

---

Canonical page: https://starlingshq.com/workspace/status