# Decisions: current truth

Latest decision wins. Sources: Jira comments by Harpreet Randhawa (Management) and Harsh Tyagi (PM, PRD v0.5), 30 Oct to 2 Nov 2026, plus calls made by Arshdeep where noted. Update this file whenever Jira changes a rule.

## In force

### Access and identity
| Topic | Decision | Source |
|---|---|---|
| Who can use Meetings | Every user of a company with Meetings enabled. No per-role Meetings permission. | HEL-1044 / HEL-972 |
| Company enablement | Rhysley companies only in Phase 1; customer companies need Management approval; enforced in the backend | HEL-1044 (Mgmt) |
| Where enablement is set | In Rhysley's CRM, as one of the usages a company gets with HelixtaHR. The module asks HelixtaHR `GET /api/v1/meetings/allowed` (user's own token) and enforces the answer; no allowlist of our own. Fresh at Join now and in the re-check; other requests reuse it up to 60 s | Arshdeep, 3 Nov |
| Organisation key | HelixtaHR `company_id` claim from the verified token. Test server: 26 = Mehar by Rhysley | Token analysis |
| Organisation Administrator | HelixtaHR `admin` and `superadmin`, matched by role name; controls only the Settings tab | HEL-1044 / HEL-972 |
| Login | HelixtaHR `meeting_jwt_token` (HS256, `token_type: meeting`, returned by `POST /api/v1/login`); the Helix AI token is refused. Header only, never URL | Surinder Chahal, 3 Nov |
| Meeting pass | Issued only at Join now or on admission; one user, one org, one meeting, one device; ~10 min | HEL-1044 (Harsh 30 Oct) |
| Not signed in | Redirect to HelixtaHR sign-in; no new screen | HEL-1044 (pending Harsh's confirm) |
| External guests | Phase 2. Users of another org or unauthenticated cannot join | HEL-1044 (Mgmt) |
| Revocation | **No HelixtaHR notices in Phase 1** (Arshdeep, 3 Nov): our backend re-checks every connected or waiting user every 4 min through `GET /api/v1/meetings/allowed` (401 = user lost access, `false` = company lost Meetings) → removal within 5 min; also checked fresh at every join; removed user sees "You were removed from this meeting" (the same as a host's Remove, HEL-984); others see a normal leave | HEL-1044 / PRD v0.5 |

### Joining and admission
| Topic | Decision | Source |
|---|---|---|
| Admission | Only Host and Co-hosts join directly. Everyone else (invited or not, same company) waits for Host / Co-host / Acting Host. Link or login never bypasses | HEL-972 (Mgmt) |
| No host present | People keep waiting until one arrives | HEL-1044 (confirmed) |
| Who can admit | Host, Co-hosts, Acting Host only; ordinary participants never | PRD v0.5 |
| Waiting users | Not connected to LiveKit; no audio/video/content; private preview; not counted toward 25 | HEL-976 / HEL-977 |
| Capacity | 25 connected devices; same person on two devices counts twice, one attendance entry | HEL-977 |
| Held place | **Host and Co-hosts: held for the whole meeting** (always get back in, nobody disconnected). Other admitted participants: held for the 2-minute reconnection window; then join as new and "This meeting is full" can apply | HEL-977 story update, 3 Nov |
| Reconnection | Within 2 min: no re-admission. Removed / denied / expired → fresh admission | HEL-975 (PRD v0.5) |
| Mic defaults | Host/Co-host mic on at their **first** connection; others mic off (can unmute); any return (drop, reload, Leave) muted for everyone, Host included; camera per pre-join choice. Sent as `microphone_on` at Join now | HEL-976 (Mgmt); first-connection wording Arshdeep, 3 Nov |
| Reconnect mic | **Always muted** after any reconnect | Arshdeep, 2 Nov |
| Refusal screen buttons | After Join now, "You can't join this meeting…" and "This meeting is full…" end with **Back to Meetings**; "This meeting link is no longer valid" shows the **message only** (no meeting details on any of them) | HEL-977 story update, 3 Nov (to confirm with Harsh: reverses the 30 Oct rule) |
| Browsers | Desktop Chrome, Edge, Firefox, Safari; iPhone Safari, Android Chrome; latest two versions | PRD v0.5 |
| Unavailable device | "Your camera can't be used right now" / "Your microphone can't be used right now"; continue without it | HEL-975 (Mgmt) |
| Expired pass on pre-join | Not possible: pass issued only at Join now. Expired HelixtaHR login → HelixtaHR sign-in. No "session expired" screen | HEL-977 |

### Meetings and lifecycle
| Topic | Decision | Source |
|---|---|---|
| Meeting types in Phase 1 | Instant meetings (scheduling and interviews are Phase 2) | HEL-1043 (Mgmt) |
| Creation | At Join now, not Start meeting; nothing created if pre-join abandoned | HEL-973 |
| Creation audit | Audit record at Join now: meeting, creator, organisation, timestamp | HEL-973 (Mgmt) |
| Instant meeting title | "Instant meeting"; no renaming/auto titles | HEL-973 |
| Who can start | Any user of an enabled company; starter is Host | HEL-973 |
| Ready-panel note | "Only the Host and Co-hosts join directly. Everyone else waits until you or a co-host lets them in." | HEL-979 story update (replaces the HEL-973 wording) |
| Mute and Remove: who on whom (HEL-983, HEL-984) | Host, Co-hosts, standing Co-hosts and Acting Host only (others 403 `not_a_host`). The Host (room owner) acts on anyone but themselves, Co-hosts included; the others only on ordinary participants (403 `not_allowed`); nobody on the Host | Arshdeep, 3 Nov |
| Mute (HEL-983) | Server-side mute of the microphone on all the person's devices; they unmute themselves, nobody unmutes them. Mute all: everyone connected except the caller, the Host and every Co-host or standing Co-host; one-time. Notice `meetings.muted`. Audit `participant_muted` / `all_muted` | Arshdeep, 3 Nov |
| Remove (HEL-984) | All devices disconnected, passes refused, place freed at once; asking again = fresh admission. A removed Co-host loses the role for this meeting; a standing Co-host stays one for later sessions. Message "You were removed from this meeting" + Back to Meetings (also for the re-check) | Arshdeep, 3 Nov |
| Remove and Block (HEL-985) | Phase 2 (guests only) | Story, 3 Nov |
| Copy joining link (HEL-979) | Every participant in the meeting (not the waiting screen). Normal meeting: `/meetings/{id}`, invalid once it ends. Room session: the room's address `/meet/<org_id>/<url>`, never the session id. Built by the frontend from `GET /v1/meetings/{id}` (`kind`, `room_name`); no backend change | Arshdeep, 3 Nov |
| Lifecycle | Leave + End Meeting only. End Meeting ends the session for everyone; a normal meeting's link becomes invalid. Deliberate handover when the last Host/Co-host leaves on purpose; Acting Host only on unexpected drop (normal meetings only). Host and Co-hosts rejoin directly, their places protected within the 25-device limit | Lifecycle direction, 3 Nov (all of Phase 1) |
| Start Meeting | One button, no meeting type to choose. Creator = Host; secure temporary link, invalid when the meeting ends unless converted to a Permanent Meeting Room | Lifecycle direction, 3 Nov |
| When a meeting is created (HEL-973) | At **Start meeting**, active and listed at once (story update 3 Nov). The audit record only at the Host's first **Join now**. Never joined within **10 minutes** of Start → ends on its own (off the list, link invalid, no audit). Start meeting again while the user has a meeting they started but haven't joined → the **same** meeting (covers double-click, AC-02.5) | Story update + Arshdeep, 3 Nov |
| Host joining (HEL-973) | Join now connects the Host: LiveKit room created, Host meeting pass (mic on, ~10 min to connect, camera + microphone). Everyone else's joining and the waiting room: HEL-976/977 | Arshdeep, 3 Nov |
| Full at Join now (HEL-977) | Someone who would wait (not Host/Co-host, not within a held place) gets **"This meeting is full. The meeting has reached its limit of 25 participants."** at Join now and doesn't enter the waiting room. Anyone already waiting when it fills keeps waiting; Admit is refused until a place frees (AC-06.5, AC-10.6) | Arshdeep, 3 Nov |
| Admit / deny and Co-hosts (HEL-982, HEL-981) | Backend built with HEL-977 (Host and Co-hosts admit/deny; Host appoints Co-hosts); screens later by the frontend team. Acting Host arrives with the lifecycle story (HEL-1026) | Arshdeep, 3 Nov |
| Places in use (technical) | Connected devices + passes issued but not connected yet + **1 per Host/Co-host with no device in use** (held the whole meeting) + **1 per admitted participant** just admitted or within 2 minutes of their last device leaving. A Host's or Co-host's held place covers one device; an extra device needs a free place. Decided under a lock on the meeting, so two people never get the last place | Arshdeep's design, 3 Nov |
| Waiting presence (technical) | The waiting screen asks for its status every ~3 s; not seen for 30 s (tab closed) → the request is gone from the list (AC-10.7). No other timeout (BR-10.2). Leaving the waiting screen cancels it | Arshdeep's design, 3 Nov |
| Notifying hosts (technical) | On every change to the waiting list the backend sends a LiveKit data message (topic `meetings.waiting`, the count) to the Host's and Co-hosts' devices → pop-up + badge; the list itself comes from our API (only Host/Co-hosts may read it, AC-10.5) | Arshdeep's design, 3 Nov |
| Mic on joining | On only for a Host's or Co-host's first connection in a meeting. Admitted participants and **every return** (reconnect, rejoin, second device) start muted | HEL-982 + reconnect rule (2 Nov) |
| Engineering alerts (for now) | Logged as `ALERT` lines (rate-limited) when LiveKit, the database or HelixtaHR can't be reached; **Mukesh builds the email (SMTP) channel** behind the same alert interface | Arshdeep, 3 Nov |
| 4-minute re-check | Its own merge request right after HEL-977 (needs HEL-977's waiting/connected tracking) | Arshdeep, 3 Nov |
| Leave Meeting or End Meeting (HEL-1026) | Story updated 3 Nov (PRD v0.6): Leave + End Meeting + Cancel; last Host/Co-host leaving a normal meeting chooses an admitted employee as new Host, or the meeting ends for everyone (link invalid); no Acting Host on a deliberate leave; End Meeting ends it for everyone, link invalid; waiting people released; "The meeting has ended" with Back to Meetings; handover notice naming the new Host. Acting Host after an unexpected drop: HEL-1012. Permanent Meeting Room parts: HEL-1136 | HEL-1026 + Harsh, 3 Nov |
| Host leaves while a Co-host stays (HEL-1026) | No handover: the **Host stays Host** (place held, rejoins as Host); the meeting carries on under the Co-host meanwhile. Handover (and Host → Co-host, BR-24.6) only when the **last** Host/Co-host leaves | Arshdeep, 3 Nov |
| Coming back after Leave (HEL-1026) | Same as a drop: an admitted participant who leaves on purpose may come back **within 2 minutes** without waiting, muted; their place is held meanwhile | Arshdeep, 3 Nov |
| Auto-end (HEL-1026) | Built now: a normal meeting with **nobody connected for 2 minutes** ends on its own (LiveKit closes the empty room and tells us): link invalid, into history, waiting people released, audit record | Arshdeep, 3 Nov |
| Attendance records (HEL-1026) | **One audit record per event** from LiveKit's webhook: connected, reconnected, left (person, device, time). Attendance = those records grouped by person | Arshdeep, 3 Nov |
| Leave and End, technical (HEL-1026) | Leave is per device; someone else managing (or the same Host on another device) = not the last. The last Host/Co-host gets 409 `handover_required` and must choose a new Host or say `end_for_everyone`: a meeting is never ended by accident. Candidates = admitted people connected now who aren't Host/Co-host. On handover the previous Host (the leaver, or an absent Host when a Co-host leaves) becomes Co-host. Leave and End check only our session token (work for a switched-off company or with HelixtaHR down). Waiting screens get status `ended` ("The meeting has ended") | Arshdeep's design, 3 Nov |
| Acting Host (HEL-1012) | Only after an **unexpected** drop (never on Leave), **straight away**: Host drops with a Co-host present → the Co-host(s) manage, pop-up names them; the last Host/Co-host drops → the admitted employee **connected longest in their current connection** becomes Acting Host, pop-up names them, they get the waiting alerts; repeats when the Acting Host drops; nobody eligible → the 2-minute auto-end. Normal meetings only; no tie-break rule | HEL-1012 + Harsh, 29 Oct |
| Acting Host steps down (HEL-1012) | An Acting Host exists only while no Host or Co-host is in the meeting: **any Host or Co-host reconnecting** takes over again (the Host gets their rights back, AC-22.7); the Acting Host goes back to participant | Arshdeep, 3 Nov |
| Acting Host leaves on purpose (HEL-1012 / BR-24.9) | Same choose-or-end rule as HEL-1026, but the chosen person becomes the **next Acting Host**; the original Host stays Host and gets their rights back on return. An Acting Host can't give away the Host role or appoint Co-hosts (BR-22.3) | Arshdeep, 3 Nov |
| Quick reload by the Host (HEL-1012) | No waiting period: the drop promotes at once and the return restores at once (two notices) | Arshdeep, 3 Nov (Harsh's "straight away") |
| Room address (HEL-1136) | `/meet/<organisation id>/<url>`, e.g. `/meet/26/standup`: the id never changes, so links survive a company rename. The backend stays product-neutral (it only sees the organisation id) | Arshdeep, 3 Nov |
| Standing Co-hosts: who can be picked (HEL-1136) | Phase 1: employees admitted to the meeting being converted, or to a later session (like Make Co-host). No employee directory needed from HelixtaHR | Arshdeep, 3 Nov |
| Owner loses access (HEL-1136, AC-39.17) | Rooms are disabled when we see the owner lose access (the access re-check is refused, 401, while they are in a meeting; a live session of the room finishes first). An owner who left while offline isn't detected until then: known gap (we can only ask HelixtaHR about a person with their own token) | Arshdeep, 3 Nov |
| Reserved and offensive URL words (HEL-1136) | We ship a short reserved list and an offensive list in one config file; Harsh / Management extend them | Arshdeep, 3 Nov |
| Room sessions in Meeting history | **Each session shows in history** (AC-39.19, HEL-1136); replaces HEL-972's "not in history" | HEL-1136 story, 3 Nov |
| Room data model (technical, HEL-1136) | A room is its own row (name, URL, owner, standing Co-hosts, grace period, status); **each session is a meeting** linked to it, so admission, places, Leave/End, history and the audit records work per session unchanged. The converted meeting becomes the first session (its temporary link works until it ends, AC-39.8) | Arshdeep's design, 3 Nov |
| Share requests (HEL-980) | One share at a time; **one waiting request** (C sees "Someone is already waiting to share", not queued); a request stays until B cancels, the share stops, or the meeting ends (Harsh, 2 Nov). **Any end of A's share** (A stops, a Host / Co-host / Acting Host stops it, A drops) lets the waiting B go live (Arshdeep, 3 Nov). Unlike Google Meet, B never takes over directly | HEL-980 + Harsh 2 Nov + Arshdeep 3 Nov |
| Chat transport (HEL-980) | LiveKit data messages between participants (every pass may send data); nothing passes through or is kept by our backend. **No chat record of any kind** (no text, no counts) (BR-08.1, AC-08.5; Arshdeep, 3 Nov). The screens trust our system messages (waiting, managers, share) only when sent by the server, never by a participant | Arshdeep, 3 Nov |
| Raised hands, technical (HEL-1032) | A LiveKit participant attribute `hand_raised_at` (the time it went up) on the device that raised it, set by our backend (passes can't change their own attributes). Nothing in our database: it disappears with the device (AC-28.5) and isn't kept after the meeting (BR-28.3). A host lowering a hand clears it on all that person's devices and sends them a message. **No audit record for hands** (BR-28.3 is specific to this story; the general "host actions are audited" rule doesn't apply here) | Arshdeep's design, 3 Nov |
| Never-joined meetings (HEL-973, technical) | Forgotten = **deleted**, not ended: never in Meeting history (it never took place), link answers "no longer valid", no audit record (none was written). Join now refuses them on time even before the 60 s clean-up runs | Arshdeep, 3 Nov |
| Non-host Join now until HEL-977 | 403 `admission_required` "Only the Host and Co-hosts join directly. Others wait until the Host or a Co-host admits them."; replaced by the waiting room in HEL-977 | Placeholder, 3 Nov |
| Device ID | The frontend makes a random ID once per browser tab, keeps it across reloads (sessionStorage) and sends it on Join now (8 to 64 of `A-Z a-z 0-9 _ -`); the pass identity is product + organisation + user + device | Arshdeep, 3 Nov |
| Permanent Meeting Rooms (**Phase 1**) | Only the original Host converts a running meeting (Meeting Settings → Save, no interruption): name, custom URL (e.g. `/meet/harpreet`, naming + uniqueness rules), standing Co-hosts, grace period. Owner = creator, permanent Host; only the owner changes settings, appoints/removes standing Co-hosts, disables the room (turn permanent off). Only owner or standing Co-hosts start sessions; locked until then; everyone else waits for admission; URL grants nothing. No Acting Host or succession; auto-ends after the grace period with no owner/standing Co-host present (default = regular meetings, owner can change). End Meeting ends the session, not the room. Owner leaves the company / loses access → rooms disabled; Co-hosts don't inherit | Lifecycle direction, 3 Nov |

### In the meeting
| Topic | Decision | Source |
|---|---|---|
| Screen share | One at a time; request model with Stop sharing to current presenter (hosts see it); next share starts automatically when current stops; hosts stop any share | HEL-980 (Mgmt) |
| Screen share on phones | Starting a share not available on mobile | E5 |
| Chat | Everyone only; plain text; links not clickable; no files; not stored; late joiners/reconnects see no history | HEL-980 |
| Layout | Per Ishank's design; no pinning or speaker highlight | HEL-980 |
| Labels | Host, Co-host (no Acting Host label) | HEL-980 |
| Raised hands | Earliest first; hosts see indicator while presenting; hosts lower any hand; person sees a message and icon disappears | HEL-1032 (Mgmt) + Arshdeep |
| Reactions | Thumbs up, Clap, Heart, Laugh, Wow; shown briefly; not stored | HEL-1032 |
| Background blur | Phase 2 separate story | HEL-1032 (Mgmt) |
| Speed targets | Internal QA benchmarks (1/2/3 s), set by Amit with Deepak; app delay = defect, network delay ≠ | HEL-980 (Mgmt) |
| Storage | No media/chat storage is a Phase 1 limit; audit records apply | HEL-980 (Mgmt) |

### Integration and process
| Topic | Decision | Source |
|---|---|---|
| Integration pattern | Same as Helix AI: Bearer `ai_assist_jwt_token` to HelixtaHR `/api/v1/ai/...` endpoints | Postman collection |
| HelixtaHR Phase 1 changes | H1 status endpoint, H2 deactivation/role-change notice, H3 menu item (see HELIXTAHR_CONTRACT.md) | HLD |
| Phase 2 integration | Guest invitations, interviews, scheduling, rescheduling, webhooks to HelixtaHR, link-disabled handling in HelixtaHR | HEL-1043 (Mgmt) |
| Product neutrality | Core is product-neutral; product specifics in adapters; keys (product, organisation) | Arshdeep, 2 Nov |
| Developer assignment | Amit assigns; names removed from business rules | HEL-1044 (Mgmt) |
| QA | Story-level QA approval by Deepak (QA HOD) recorded in Jira; combined email sign-off not accepted | Mgmt |
| Before development | BA records corrections in each story; BA readiness score (≥95%) pasted as text | Mgmt |
| Monitoring | Alerts to more than one person (Amit + second contact), with escalation | HEL-977 (Mgmt) |

## Reversed decisions (do NOT build the old behaviour)

| Old decision (date) | Replaced by |
|---|---|
| Internal users never wait; all colleagues join directly (30 Oct) | Only Host/Co-hosts join directly; everyone else waits (Mgmt, HEL-972) |
| Camera and mic start on for everyone (30 Oct) | Regular participants mic off; Host/Co-host mic on |
| Nothing created at Start meeting; meeting created at Join now (HEL-973, 30 Oct) | Meeting created at Start meeting; only the audit record waits for Join now (story update 3 Nov) |
| Invalid link: Back to Meetings for internal users (HEL-977, 30 Oct) | Link message only; Back to Meetings on the not-authorised and full messages (HEL-977 update, 3 Nov) |
| No reserved place for the Host in Phase 1 (HEL-977, 30 Oct) | Host and Co-host places held for the whole meeting within the 25 (HEL-977 update, 3 Nov) |
| Permanent Meeting Room sessions not in Meeting history (HEL-972, 3 Nov) | Each session in history (HEL-1136, 3 Nov) |
| Links reusable until the Host disables them (HEL-973, 30 Oct) | End Meeting invalidates a normal meeting's link (HEL-1026 direction) |
| Three end options: Leave / End for All / End and Disable Link | Leave + End Meeting |
| Acting Host whenever Host leaves | Deliberate handover on voluntary leave; Acting Host only on unexpected drop |
| "[Name] is already presenting" (30 Oct) | Request model with Stop sharing |
| Host can't stop internal participants' shares | Hosts can stop any share |
| Host can't lower hands (30 Oct) | Hosts can lower any hand |
| Blur in HEL-1032 | Phase 2 story |
| Re-check every 5–10 min | Removal within 5 min → re-check at least every 4 min |
| "Sign in to HelixtaHR to join" screen | Redirect to HelixtaHR sign-in, no new screen |
| Guest invitations / interviews / scheduled meetings / webhooks to HelixtaHR in Phase 1 | Phase 2 |
| Meetings permission in HelixtaHR Roles-Permissions | No permission; company-level enablement |
| Our own allowlist of enabled companies, maintained by Amit/DevOps (HLD) | Enablement set in the CRM, read from HelixtaHR `GET /api/v1/meetings/allowed` (3 Nov) |
| HelixtaHR deactivation / role-change notice → remove immediately; separate status endpoint H1 (HLD) | Our 4-minute re-check via `/api/v1/meetings/allowed` only; no notices, no H1 (3 Nov) |
| Reuse `ai_assist_jwt_token` under `/api/v1/ai/...` (HLD) | Separate `meeting_jwt_token`; Meetings endpoints under `/api/v1/meetings/...` (3 Nov) |

## Open decisions (from the HLD; recommendation in brackets)

1. ~~Last person leaves without End Meeting~~ Decided 3 Nov (Arshdeep): a normal meeting ends automatically after **2 minutes with nobody connected** (same as the reconnection hold); it leaves the list and its link becomes invalid. Default Permanent Meeting Room grace period is the same 2 minutes
2. ~~Last host leaves without handing over~~ Direction 3 Nov: deliberate handover on voluntary leave; Acting Host only on unexpected drop (normal meetings). Exact Leave dialog still to design
3. Who can receive a handover [any admitted employee]: Harsh
4. ~~Ended meetings on Meetings page~~ Resolved by HEL-972 update (3 Nov): ended normal meetings leave the list and show only in Meeting history (US-30); link invalid
5. ~~Permanent Meeting Rooms phase~~ Phase 1 (lifecycle direction, 3 Nov). Open details: (a) detecting an owner who left the company while offline (needs a HelixtaHR user-status check without the user's token, or a notice); ~~(b) custom URL uniqueness~~ the URL includes the company, so room names are unique **per company** (3 Nov); (c) what a visitor sees before the room is started; ~~(d) default grace period~~ 2 minutes (3 Nov); ~~(e) are rooms shown on the Meetings page~~ yes, for owner and standing Co-hosts (HEL-972 update)
6. ~~Meetings page list~~ Resolved by HEL-972 update (3 Nov): not-ended meetings the user hosts, co-hosts, was invited to through HelixtaHR, or has joined, plus Permanent Meeting Rooms they own or are a standing Co-host of; rows show title and Host only; no date column, no "Live now". Details decided 3 Nov (Arshdeep): "joined" = admitted and connected at least once (waiting only doesn't count); removed users stay listed, blocked users don't; order = Permanent Meeting Rooms first (by name), then meetings newest first; the API returns the meeting id and room name, the frontend builds the link; meetings are created only by Start meeting (US-34 = our API); Meeting history (US-30) built in HEL-972. Open: "invited through HelixtaHR": no source of invitees yet (Arshdeep checking with Harsh)
7. ~~Rhysley company IDs and who owns the allowlist~~ Resolved 3 Nov: enablement is set in the CRM and read from HelixtaHR. Still open: if a company loses Meetings mid-meeting, are its users removed at once or only refused on their next join? (Amit, Harsh)
8. ~~HelixtaHR unreachable~~ Agreed 3 Nov (Arshdeep; Amit to be informed): people already in a meeting or waiting **stay**, and are re-checked when HelixtaHR answers again; new joins, Start meeting and admissions are refused with "Meetings are temporarily unavailable"; Engineering is alerted
8a. ~~Company switched off in the CRM mid-meeting~~ Decided 3 Nov (Arshdeep): **running meetings go on until they end; nothing new starts.** The re-check ignores HelixtaHR's `false` for people already connected; Start meeting, Join now (including rejoining after leaving or reloading), opening Meetings and admitting are all refused ("You don't have access to Meetings"); people waiting are refused at their next check. Brief network blips that LiveKit reconnects by itself are unaffected. One person losing access (HelixtaHR 401) is still removed within 5 minutes (AC-35.6). Note for HEL-1026: Leave and End Meeting must still work for a switched-off company
9. Not signed in [redirect to HelixtaHR sign-in]: Harsh
10. HelixtaHR developer for H1–H3 [Surinder Chahal]: Amit
11. ~~Embedding~~ Decided 3 Nov (Arshdeep): the Meetings screens are built **inside HelixtaHR's own frontend**, which already holds `meeting_jwt_token`; no token handover needed. CORS must allow HelixtaHR's frontend addresses. Note: HEL-1044 asks for one reusable interface; build the screens as a self-contained module so another product can reuse them later (confirm with Amit).
12. Stack and hosting [Python FastAPI + PostgreSQL; React + LiveKit components; LiveKit + TURN on company servers with a named owner]: Amit
13. Alert recipients [Amit + named second contact; email + team chat; escalation]: Amit
14. Several share requesters [one request at a time; stays until cancelled or answered]: Harsh
15. ~~Speaker choice where unsupported~~ Resolved (HEL-976 Jira update): where the browser can't set the output (iPhone Safari) the speaker list is hidden and sound uses the default speaker; real-device checks planned
16. ~~Admitted guests copying link~~ Resolved 3 Nov: the HEL-979 story update moves guests (and their copying) to Phase 2
17. Record retention [Epic 7 org settings]: Harsh
18. ~~Token shared with Helix AI, no `aud`~~ Resolved 3 Nov: separate `meeting_jwt_token` with `token_type: meeting`, signed with its own secret (Surinder confirmed). Lifetime is still 30 days.
21. ~~Live environment values~~ Handled on the HelixtaHR side (3 Nov): live secret, issuer and base URL are the same as those in use; not our concern.
19. ~~Our own short-lived token (HEL-1044 flow step 3 / BR-35.2)~~ Decided 3 Nov (Arshdeep): the browser swaps HelixtaHR's token once at `POST /v1/session` for our own session token (15 min, our secret); every other call uses ours. The per-meeting LiveKit pass at Join now covers "scoped to one meeting".
20. ~~Where AC-35.8 is enforced~~ Resolved 3 Nov: in the CRM. Our module only acts on HelixtaHR's `meetings_allowed`.

**Other open items:** ~~meaning of HelixtaHR `user_type`~~ (not significant, ignored; 3 Nov); webhooks to HelixtaHR in Phase 1 or Phase 2; frontend in this repo or separate; second alert recipient name; LiveKit version to pin.