# Phase 1 stories: current state

Source: Jira HelixtaHR space, PRD v0.5 (RH001ES-735), Management reviews of 31 Oct to 2 Nov 2026. Where Management changed a rule, the **current** rule is given and the old one is marked *superseded*. Exact on-screen messages are in quotes; use them verbatim.

## Epic map (Video Conferencing Module, Phase 1)

| Epic | Name | Stories | Ours (Arshdeep) | Others |
|---|---|---|---|---|
| E1 | Meetings entry and pre-join | US-01 to US-06 | HEL-972, 973, 975, 976, 977 | HEL-974 (Harsh) |
| E2 | Host and Co-host meeting control | US-07 to US-14 | HEL-979, 980; backend of HEL-981, 982 (with HEL-977) | HEL-981 Co-hosts, 982 admit/deny, 983 mute/mute all, 984 remove, 985 remove+block, 986 guest screen sharing (Harsh) |
| E3 | External guest access | US-15 to US-20 | — | Phase 2 |
| E4 | Meeting continuity and ending | US-21 to US-27 | HEL-1026 | HEL-1010 reconnect, 1012 Host leaves, 1025 Host returns, 1027 last internal user, 1028 lose access, 1029 device/platform problems |
| E5 | Engagement and mobile | US-28 to US-29 | HEL-1032 | HEL-1033 mobile essentials (Harsh) |
| E6 | Meeting history and records | US-30 to US-31 | — | others |
| E7 | Organisation administration | US-32 to US-33 | — | others (Settings tab contents) |
| E8 | Integration and security foundation | US-34 to US-35 | HEL-1043, HEL-1044 | — |

Users: **Internal user** (authenticated user of the meeting's organisation), **Host**, **Co-host** (appointed by Host for that meeting), **Acting Host** (eligible internal user promoted automatically), **Organisation Administrator** (HelixtaHR admin/superadmin; Settings tab only), **External guest** (Phase 2).

---

## HEL-1044 (US-35): Secure access, organisation isolation and the embedded interface

**Status:** Story updated in Jira (version received 3 Nov). Part 1 (access gate) built.

**User story:** As an organisation using HelixtaHR, I want meetings to open from HelixtaHR with no separate sign-in while keeping my users, meetings and records separate from every other organisation, so that video meetings are convenient and secure.

**Scope:** launch without separate authentication, token issue and expiry, backend authorisation, access revocation, organisation isolation, look and feel inside HelixtaHR. Out of scope: login, 2FA, passwords, registration, employee lists, branding, extra consent screens.

**Flow**
1. A user signed in to HelixtaHR opens Meetings with no separate login. Signing in is not admission: only Host and Co-hosts join directly; everyone else waits.
2. The module validates identity, organisation, permissions and authorised meeting access, and checks the company has Meetings switched on.
3. The module issues a **short-lived, properly scoped access token**. It opens Meetings; it does not admit the user to a meeting.
4. The embedded interface connects with that token; LiveKit and API secrets stay on company servers.
5. Every action is checked in the backend.
6. HelixtaHR access lost → module access revoked (US-26). Deactivation notice failed or late → re-check removes the user within 5 minutes.
7. Phase 1: only authenticated HelixtaHR users of the meeting's organisation join; other organisations refused; not signed in → HelixtaHR sign-in page. External guests: Phase 2.

**Business rules**
- BR-35.1 No authentication, 2FA, password, registration or login screens.
- BR-35.2 Tokens are short-lived and scoped to one user, organisation and meeting; expired or out-of-scope tokens refused.
- BR-35.3 Encrypted in transit; secrets only on company servers.
- BR-35.4 Administrators of one organisation never reach another's meetings, users or records.
- BR-35.5 Interface appears as part of HelixtaHR; no LiveKit demo elements.
- BR-35.6 No privacy notice, disclosure screen, consent checkbox or acknowledgement script on pre-join or waiting screens.
- BR-35.7 Phase 1: Meetings switched on only for Rhysley companies, by the Platform Administrator; a customer company needs Management approval; the backend enforces this.
- BR-35.8 Deactivation notice failed or late → re-check and remove within 5 minutes.
- Also: one reusable embeddable interface (other Rhysley products later); LiveKit unmodified; keyboard-usable controls labelled for screen readers.

**Acceptance criteria**
- AC-35.1 Signed in to HelixtaHR → opens Meetings with no further sign-in; not admitted to a meeting.
- AC-35.2 All screens appear as part of HelixtaHR, no LiveKit demo elements.
- AC-35.3 Unauthorised user trying to join → refused.
- AC-35.4 User of organisation A, any action on organisation B's meetings or records → refused every time.
- AC-35.5 Expired token or one used outside its scope → refused.
- AC-35.6 Access revoked mid-meeting → cannot remain or rejoin.
- AC-35.7 Rhysley company switched on by the Platform Administrator → Meetings opens.
- AC-35.8 Customer company without Management approval, someone tries to switch Meetings on → the backend refuses it.
- AC-35.9 Deactivation notice failed or late → re-check removes the user within 5 minutes.
- AC-35.10 User removed after a late notice tries to rejoin → refused.
- AC-35.11 User of another organisation opens the meeting link → refused.
- AC-35.12 Not signed in, opens the meeting link → HelixtaHR sign-in page shows.

**QA (Deepak):** admission rule, organisation separation, token security, revocation, failed-notice recovery, company enablement.

**Settled 3 Nov:** our own 15-minute session token (decision 19); AC-35.8 is enforced in the CRM (decision 20); no HelixtaHR deactivation notice in Phase 1, so removal is within 5 minutes via our re-check.

---

## HEL-972 (US-01): View the Meetings page

**Status:** Story updated (version received 3 Nov).

**User story:** As an internal user, I want to open Meetings in HelixtaHR and see my meetings, so that I can start or open one without leaving HelixtaHR.

**Placement:** Left navigation → Meetings → tab Meetings (empty state on first visit; list of meetings and Permanent Meeting Rooms).

**Scope:** empty state; list of meetings that have not ended that the user hosts, co-hosts, was invited to through HelixtaHR, or has joined; Permanent Meeting Rooms the user owns or is a standing Co-host of; Start meeting, Open, Copy link. Out of scope: schedules, invitations and reminders (HelixtaHR's); scheduled meetings (US-38); a "Live now" label.

**Business rules**
- BR-01.1 Only meetings of the user's own product and organisation.
- BR-01.2 No scheduling or invitation creation in the module.
- BR-01.3 Only HelixtaHR admin and superadmin see and use the Settings tab.
- BR-01.4 All users of a company with Meetings switched on can open Meetings.
- BR-01.5 Being on the list does not mean joining directly. Ordinary participants can never admit anyone.
- BR-01.6 The list shows only not-ended meetings the user hosts, co-hosts, was invited to through HelixtaHR, or has joined, and Permanent Meeting Rooms the user owns or is a standing Co-host of.
- BR-01.7 Rows show the title and Host only. No "Live now" label in Phase 1.
- BR-01.8 An ended normal meeting shows only in Meeting history (US-30), and its link no longer works. A Permanent Meeting Room stays on Meetings for its owner and standing Co-hosts.
- Dependencies: HelixtaHR authentication and navigation; instant meetings created through the API (US-34).

**Acceptance criteria**
- AC-01.1 No meetings → "No meetings yet" and Start meeting.
- AC-01.2 Listed meetings show title, Host, Copy link and Open.
- AC-01.3 Ended normal meeting → not on the list; its link shows "This meeting link is no longer valid".
- AC-01.4 Company without Meetings → Meetings not available ("You don't have access to Meetings", HEL-1044).
- AC-01.5 User of organisation A → no meeting of organisation B appears.
- AC-01.6 Opens without a separate login; not admitted to any meeting.
- AC-01.7 Admin or superadmin → Settings tab shows.
- AC-01.8 Any other user → no Settings tab.
- AC-01.9 A meeting the user doesn't host or co-host, wasn't invited to and hasn't joined → not shown.
- AC-01.10 Permanent Meeting Room → shows for its owner and standing Co-hosts, also after a session has ended.
- AC-01.11 Ended normal meeting → shows in Meeting history (US-30).
- AC-01.12 Running meeting → no "Live now" label.

---

## HEL-973 (US-02): Start an instant meeting

**Status:** Story updated (version received 3 Nov).

**User story:** As an internal user, I want to start a meeting immediately from Meetings, so that I can talk to colleagues without waiting for a schedule.

**Placement:** Meetings → Start meeting, then the pre-join page, then a "Your meeting's ready" confirmation.

**Flow**
1. User selects Start meeting on Meetings (empty or list).
2. System **creates the meeting** with the user as Host and generates a temporary meeting link.
3. System opens the pre-join screen titled "Instant meeting" (US-04, US-05).
4. User selects Join now: the system creates an **audit record** (meeting, creator, company, time). Leaving pre-join first creates no record.
5. "Your meeting's ready: share this link" with the link, Copy link, and the note that only the Host and Co-hosts join directly; everyone else waits until the Host, a Co-host or an Acting Host lets them in.
6. User is in the meeting as Host (Epic E2).

**Business rules**
- BR-02.1 The starter is Host. Any user of a company with Meetings switched on can start.
- BR-02.2 The link is temporary: it stops working when the meeting ends, unless the original Host turns it into a Permanent Meeting Room (US-39).
- BR-02.3 Meeting and link belong to the starter's organisation only.
- BR-02.4 Only Host and Co-hosts join directly; everyone else waits to be admitted.
- BR-02.5 The audit record is created only when Join now is selected, never earlier.
- Title "Instant meeting" (no other naming rules). Out of scope: scheduling, calendar invitations.
- FR: secure, documented, versioned APIs to create, join, manage and end meetings and generate temporary links.

**Acceptance criteria**
- AC-02.1 Start meeting + Join now → Host; link panel with the note about direct joining and admission.
- AC-02.2 Copy link copies and confirms.
- AC-02.3 Meeting service unavailable → "Meetings are temporarily unavailable" at **Start meeting**.
- AC-02.4 Start request from a company without Meetings → refused in the backend.
- AC-02.5 (Edge, Assumption) Double-selecting Start meeting creates only one meeting.
- AC-02.6 Join now → audit record with meeting, creator, company, time.
- AC-02.7 Leaving pre-join before Join now → no audit record.
- AC-02.8 An employee who is not Host or Co-host opens the link → waits for admission.

---

## HEL-975 (US-04): Allow camera and microphone

**Status:** Approved with conditions; PM readiness 20/20. Closed 3 Nov: the backend part (AC-04.8) was built by HEL-977; the rest is the pre-join screen (Deepak, in HelixtaHR's frontend).

**User story:** As a user joining a meeting, I want a clear browser permission step and help if access is blocked, so that I can get my camera and microphone working or join without them.

**Placement:** Pre-join page: first-time permission prompt and blocked-permission help. Out of scope: operating-system level fixes (device in use by another app).

**Flow**
1. First visit in this browser: "Allow camera and microphone to see your preview"; Camera and Microphone "Waiting for permission"; the browser shows its prompt.
2. Allow → preview and device lists (US-05).
3. Block → "Camera and microphone are blocked" with three steps (lock icon, set to Allow, reload), worded for the user's browser; "I've allowed it, try again" and "Join without camera and mic".
4. Connected but unusable device → "Your camera can't be used right now" / "Your microphone can't be used right now" (not "No camera detected"); continue without it.
5. Join without camera and mic follows the admission rule.

**Business rules**
- BR-04.1 The user can always join without camera or mic; it still follows admission.
- BR-04.2 Instructions are specific to the user's browser.
- BR-04.3 No consent, privacy or acknowledgement screen.
- BR-04.4 Supported: desktop Chrome, Edge, Firefox, Safari; iPhone Safari, Android Chrome; latest two versions each.
- BR-04.5 A connected but unusable device is not "no device": different messages.
- Reload after allowing: covered by the 2-minute reconnection window (no re-admission, muted).

**Acceptance criteria**
- AC-04.1 First visit → waiting-for-permission state.
- AC-04.2 Allowed → live preview and device lists.
- AC-04.3 Blocked → the three steps, retry and join-without.
- AC-04.4 Retry while still blocked → blocked state remains, same steps.
- AC-04.5 Only the camera blocked → mic works, join with camera off.
- AC-04.6 Camera connected but unusable → "Your camera can't be used right now", continue without it.
- AC-04.7 Microphone connected but unusable → "Your microphone can't be used right now", continue without it.
- AC-04.8 Join without camera and mic → Host and Co-hosts join; everyone else waits to be admitted.

---

## HEL-976 (US-05): Complete the pre-join check and join

**Status:** Approved with conditions. Closed 3 Nov: the backend part (admission, mic defaults, nothing from people waiting) was built by HEL-973 and HEL-977; the rest is the pre-join screen (Deepak).

**User story:** As a user about to join, I want to check my camera, microphone and speaker and choose my devices, so that I join ready to be seen and heard.

**Placement:** Pre-join "Ready to join?" > Join now. Out of scope: background blur (US-36), remembering device choices.

**Flow**
1. The user's name, meeting title, live camera preview, mic level meter.
2. Camera, microphone and speaker dropdowns; the choice carries into the meeting. Test speaker (Should).
3. Camera and mic toggles: the camera follows the choice; the mic starts off for regular participants (they unmute after joining), on for the Host and Co-hosts.
4. Join now; with no camera: "You can still join with your camera off".
5. Host and Co-hosts join directly; everyone else, employees included, waits for Host, Co-host or Acting Host. People waiting send no audio or video; their preview stays private.
6. Unusable device messages and the browser list as US-04.

**Business rules**
- BR-05.1 No camera → "No camera detected", join with camera off.
- BR-05.2 No microphone → "No microphone detected", join muted.
- BR-05.3 Only Host and Co-hosts join directly; Join now never skips admission.
- BR-05.4 Regular participants join mic off; Host and Co-hosts mic on.
- BR-05.5 People waiting send no audio or video; preview private.
- BR-05.6 Supported browsers as BR-04.4.
- Also: visible to everyone within 1 second (internal QA benchmark, as HEL-980); controls usable by keyboard and labelled for screen readers.

**Acceptance criteria**
- AC-05.1 Mic level meter moves. AC-05.2 Second camera used in the meeting. AC-05.3 Test speaker through the selected speaker.
- AC-05.4 No camera → "No camera detected", Join now works. AC-05.5 No microphone → "No microphone detected", joins muted.
- AC-05.6 Host or Co-host → enters directly.
- AC-05.7 Camera on/off choice carries in. AC-05.8 Selected mic and speaker used in the meeting.
- AC-05.9 Anyone else, employees included → waiting room until admitted.
- AC-05.10 Admitted regular participant → mic off, can unmute; Host or Co-host → mic on.
- AC-05.11 A person waiting → others see and hear nothing; preview private.
- AC-05.12 Connected but unusable device → "can't be used right now", continue without it.

**Dev notes (3 Nov, Arshdeep)**
- "Mic on" for Host and Co-hosts is their first connection to the meeting (`microphone_on` in the Join now answer). Coming back after a drop, reload or Leave is muted for everyone, Host included (HEL-975 reconnection rule). A normal meeting's Co-host is appointed while already in it, so in practice "Co-host mic on" is a standing Co-host starting a room session.
- Speaker selection where the browser can't set the output (iPhone Safari): the list is hidden and sound uses the default speaker; real-device checks planned (HEL-976 Jira update; decision 15).

---

## HEL-977 (US-06): Pass access and capacity checks when joining

**Status:** Story updated (version received 3 Nov).

**User story:** As a user, I want to be told clearly when I cannot join, so that I know whether it is an access problem or a full meeting.

**Placement:** After Join now: not authorised, meeting full, and link no longer valid messages. Each ends with Back to Meetings, except the link message.

**Scope:** authorisation refusal, 25-participant limit, invalid link. Out of scope: raising the participant limit.

**Flow**
1. User selects Join now (or opens a link).
2. System validates identity, organisation, permission and token. Another organisation's user can't join; anyone not signed in goes to the HelixtaHR sign-in page.
3. Not authorised → "You can't join this meeting. Your HelixtaHR account doesn't have access to this meeting."
4. 25 devices connected → "This meeting is full. The meeting has reached its limit of 25 participants." People waiting for admission are not counted.
5. Link disabled, revoked, expired or altered, or a normal meeting that has ended → "This meeting link is no longer valid", no meeting details.
6. Meeting service unavailable → "Meetings are temporarily unavailable", and Engineering is alerted (more than one person).
7. Otherwise Host or Co-host enters directly. Everyone else goes to the waiting room until the Host, a Co-host or an Acting Host admits them. Holding the link or belonging to the company doesn't skip admission.
8. Waiting people don't count toward 25 and receive no meeting audio, video or content.
9. **Host's and Co-hosts' places are held for the whole meeting**, so they always get back in without anyone being disconnected. Other admitted participants' places are held for their 2-minute reconnection window; after that they join as new and "This meeting is full" can apply.

**Functional requirements (summary)**
- Only Host and Co-hosts join directly; everyone else waits for Host, Co-host or Acting Host.
- Identity, organisation and access checked before the join. Phase 1: only authenticated HelixtaHR users of the meeting's organisation; others refused; not signed in → HelixtaHR sign-in.
- Waiting people: not counted, no audio, video or content.
- Host and Co-host places held for the whole meeting within the 25; others' places held for 2 minutes after a drop.
- Monitoring alerts to more than one person; LiveKit unavailable → "temporarily unavailable" + alert Engineering.
- All permissions enforced in the backend; short-lived, scoped tokens; expired or out-of-scope tokens refused.
- "This meeting is full" to the 26th person; each connected device counts; waiting people can't be admitted until a place frees.
- Same user on two devices: both stay connected, both count, attendance shows the person once.

**Business rules**
- BR-06.1 Each connected device counts toward 25; the same person on two devices counts twice but appears once in attendance.
- BR-06.2 Everyone except Host and Co-hosts waits to be admitted.
- BR-06.3 Refusal screens reveal no meeting details.
- BR-06.4 Waiting people don't count toward 25.
- BR-06.5 Host and Co-host places held for the whole meeting; others' for 2 minutes after a drop, then they join as new and the meeting may be full.
- BR-06.6 Phase 1: only authenticated HelixtaHR users of the meeting's organisation. External guests in Phase 2.

**Acceptance criteria**
- AC-06.1 Host or Co-host with a free place → enters directly.
- AC-06.2 Unauthorised organisation user → "You can't join this meeting", no media connects.
- AC-06.3 25 connected devices → another user sees "This meeting is full".
- AC-06.4 Expired token → refused.
- AC-06.5 Full and someone waiting → admitted only after a place frees; waiting people don't count.
- AC-06.6 One person (admitted, Host or Co-host) on phone + laptop → both count, attendance shows one entry.
- AC-06.7 LiveKit unavailable → "Meetings are temporarily unavailable".
- AC-06.8 Anyone else (employee, link holder) → waiting room until Host, Co-host or Acting Host admits.
- AC-06.9 Admitted participant drops and returns within 2 minutes → place held; after 2 minutes joins as new, "This meeting is full" if full.
- AC-06.10 Meeting full, Host or Co-host was away → returns at any time, joins directly, nobody disconnected.
- AC-06.11 Another organisation's user → refused.
- AC-06.12 Not signed in, opens the link → HelixtaHR sign-in page.
- AC-06.13 Ended normal meeting's link → "This meeting link is no longer valid".

---

## HEL-982 (US-10): Admit or deny people waiting (Harsh's story; backend built with HEL-977)

**Status:** Story received 3 Nov. Backend built with HEL-977; screens later.

**User story:** As a Host, Co-host or Acting Host, I want to see who is waiting and admit or deny them, so that only the people I expect enter the meeting.

**Placement:** People panel > Waiting to join; People count badge and pop-up on arrival. The person waiting sees a waiting screen.

**Scope:** waiting screen, waiting list, alert, Admit, Deny. Out of scope: admitting everyone at once, lobby chat, external guests (Phase 2).

**Flow**
1. Someone who is not Host or Co-host selects Join now or opens the link (employees too; invited or holding the link doesn't skip admission).
2. They see "Waiting for the host to let you in". No meeting audio, video or chat either way; preview stays private.
3. Host, Co-hosts and Acting Host get a pop-up and a count on People.
4. Host opens People: the name under Waiting to join (1).
5. Admit → the person enters with the **microphone off** and appears under In the meeting.
6. Deny → the person sees "Your request to join was declined" and may ask again (assumption: no limit in Phase 1).
7. The entry leaves the waiting list.
8. No Host, Co-host or Acting Host present → people keep waiting. Ordinary participants can never admit.
9. Permanent Meeting Rooms: the same once a session has started (US-39).

**Functional requirements (summary)**
- Everyone except Host and Co-hosts waits; nothing before admission; **no timeout** on a waiting request.
- Only Host, Co-host or Acting Host admit or deny; ordinary participants never.
- Deny rejects the current request; the person can ask again.
- Admitted participant starts with the mic off.
- Host, Co-hosts and Acting Host are notified of people waiting.
- Full meeting: "This meeting is full" to the 26th person; waiting people don't count and can't be admitted until a place frees.
- In-meeting notifications (people waiting, disconnects and reconnects, Host handover, connection failures), separate from webhooks.

**Business rules**
- BR-10.1 Only Host, Co-host and Acting Host admit or deny.
- BR-10.2 A waiting request has no timeout; it stays until admitted, denied, the person leaves, or the meeting ends.
- BR-10.3 Assumption: a denied person can ask again, no limit in Phase 1.
- BR-10.4 Meeting full → Admit unavailable until a place frees; waiting people don't count.
- BR-10.5 Link, invitation or company membership doesn't bypass admission.

**Acceptance criteria**
- AC-10.1 Someone waits → Host, Co-hosts and Acting Host get a pop-up; People shows a count.
- AC-10.2 Admit → the person joins with the mic off.
- AC-10.3 Deny → declined message; can ask again.
- AC-10.4 Only ordinary participants present → nobody can admit; the person keeps waiting.
- AC-10.5 Ordinary participant asks for the waiting list → not shown; refused in the backend.
- AC-10.6 25 devices → Admit blocked with "This meeting is full" until someone leaves.
- AC-10.7 The person leaves while waiting → the entry is gone.
- AC-10.8 Employee who isn't Host or Co-host opens the link → waits until admitted.
- AC-10.9 Someone waiting → others see and hear nothing from them; their preview stays private.

---

## HEL-981 (US-09): Appoint Co-hosts (Harsh's story; backend built with HEL-977)

**Status:** Story received 3 Nov. Backend built with HEL-977; screens later.

**User story:** As a Host, I want to appoint one or more Co-hosts, so that others can manage the meeting with me and keep it running if I leave.

**Placement:** People panel > an internal participant's more menu > Make Co-host. Co-hosts show a "Co-host" label.

**Scope:** appointing internal users as Co-hosts, meeting-specific rights. Out of scope: Co-host administration rights, removing a Co-host (open: whether the Host can remove a Co-host).

**Flow**
1. Host opens People, the more menu of an internal participant.
2. Make Co-host.
3. Co-host permissions for this meeting only; the label updates for everyone.
4. The new Co-host sees host controls (admit, mute, remove, end).
5. Host may repeat.

**Functional requirements (summary)**
- Host appoints one or more Co-hosts.
- Co-hosts admit or deny, mute and remove participants, and End Meeting, in that meeting only, with no administrative access.
- Participant list with names, Host and Co-host labels, mic and camera state.

**Business rules**
- BR-09.1 Only the Host makes Co-hosts (several allowed); a Co-host or Acting Host can't.
- BR-09.2 Only authenticated internal users of the meeting's organisation can be Co-hosts.
- BR-09.3 Co-host rights are meeting-specific, no administrative access.

**Acceptance criteria**
- AC-09.1 Host appoints two internal participants → both are Co-hosts.
- AC-09.2 Co-host: admit, mute, remove and End Meeting work in that meeting only.
- AC-09.3 Someone still waiting → Make Co-host not offered until admitted (assumption).
- AC-09.4 Co-host label shows for everyone in People.
- AC-09.5 Co-host disconnects and rejoins → keeps the role for this session.
- AC-09.6 Co-host or Acting Host tries to make a Co-host → refused in the backend.

---

## HEL-983 (US-11): Mute one participant or everyone (Harsh's story; backend built by us)

**Status:** Story received 3 Nov. Backend built on `feature/HEL-983-984-host-controls`; screens later.

**User story:** As a Host, Co-host or Acting Host, I want to mute one participant or everyone, so that I can stop background noise quickly.

**Placement:** People panel > participant more menu > Mute; Mute all in the People panel. Out of scope: forced unmute, unmute requests.

**Flow**
1. Host opens People and selects Mute on a participant, or Mute all.
2. Microphones turn off (Mute all: all other participants, not the person selecting it, the Host or any Co-host).
3. Participants see their mic muted and a short notice; they can unmute themselves at any time.

**Business rules**
- BR-11.1 Only Host, Co-host and Acting Host can mute others.
- BR-11.2 Mute is one-way: no force-unmute, no unmute request.
- BR-11.3 Mute all mutes all other participants; not the person who selects it, the Host or any Co-host.
- BR-11.4 Mute all is one-time: people who join afterwards are not muted.
- Also: visible to everyone within 1 second (QA benchmark, as HEL-980).

**Acceptance criteria**
- AC-11.1 Mute selected → their microphone turns off.
- AC-11.2 Host selects Mute all → everyone but the Host and Co-hosts muted.
- AC-11.3 A muted participant unmutes → audio resumes.
- AC-11.4 An ordinary participant trying to mute another → refused.
- AC-11.5 Joining after Mute all → not muted.
- AC-11.6 A Co-host selects Mute all → the Host and other Co-hosts not muted.

**Dev notes (3 Nov, Arshdeep)**
- Who may mute one person: same rule as Remove (see HEL-984).
- Server-side mute in LiveKit of the microphone track on every connected device of the person; screen-share audio and the camera untouched; a mic already off is left alone (no record, no notice).
- The muted person's devices get `meetings.muted {by_user_id, by_name}` for the notice.
- Audit records: `participant_muted`, `all_muted` (people count).

---

## HEL-984 (US-12): Remove a participant (Harsh's story; backend built by us)

**Status:** Story received 3 Nov. Backend built on `feature/HEL-983-984-host-controls`; screens later.

**User story:** As a Host, Co-host or Acting Host, I want to remove a participant from the meeting, so that I can end a disruption.

**Placement:** People panel > participant more menu > Remove. Out of scope: blocking a person (HEL-985, Phase 2).

**Flow**
1. Host selects Remove in a participant's more menu.
2. The participant is disconnected from the session.
3. They see "You were removed from this meeting" with Back to Meetings; they can ask to join again and need fresh admission.
4. The People list updates for everyone; the removal is recorded.

**Business rules**
- BR-12.1 Remove disconnects the person; asking again needs fresh admission.
- BR-12.2 A removed person asking again goes back to the waiting room.
- BR-12.3 The original Host cannot be removed by Co-hosts (assumption; confirmed as below).

**Acceptance criteria**
- AC-12.1 Remove → disconnected, list updates.
- AC-12.2 A removed person asks again → waiting room, fresh admission.
- AC-12.3 An ordinary participant attempting Remove → refused.
- AC-12.4 A removed person rejoining without admission → can't enter until admitted.

**Dev notes (3 Nov, Arshdeep)**
- Who on whom (mute one person and remove): the Host (room owner) can act on anyone but themselves, Co-hosts included; Co-hosts, standing Co-hosts and the Acting Host only on ordinary participants; nobody on the Host.
- Every device of the person is disconnected and the passes they hold stop working; their place is freed at once; their share stops and their hand goes with the devices.
- A removed Co-host loses the role for this meeting (back only through admission, as a participant); a standing Co-host stays one for the room's later sessions.
- Someone admitted but disconnected (within the 2 minutes) can be removed; waiting people are denied, not removed.
- One message for both kinds of removal (host, access re-check): "You were removed from this meeting" with Back to Meetings.
- Audit `participant_removed` with the host as actor and reason `removed_by_host` (the re-check writes `access_revoked`).

---

## HEL-985 (US-13): Remove and block a guest (Phase 2)

**Status:** Phase 2 (guests only; blocking internal users and organisation-wide lists are out of scope). Not built. Open in the story: how a block is enforced for a guest who used the general link (BR-13.4, AC-13.5).

**User story:** As a Host, Co-host or Acting Host, I want to remove and block a guest and later lift the block, so that an unwanted guest cannot return but a mistake can be undone.

**Summary:** Remove and Block (red) on a guest; "You were removed from this meeting. The host removed you and blocked your access. You can't rejoin unless the host removes the block."; a Blocked section in People with Remove block (hosts only); enforced through invitation or session tokens, not the browser (BR-13.1, 13.2); only hosts block or lift (BR-13.3, AC-13.6, backend-enforced); records for block and unblock.

---

## HEL-979 (US-07): Share the meeting link

**Status:** Approved with conditions. Story updated (BA) after PRD v0.5; built 3 Nov (no new code: covered by HEL-972, 973, 977, 1026, 1136).

**User story:** As a Host, I want to copy the meeting link at any time, so that I can bring colleagues into the meeting.

**Placement:** "Your meeting's ready: share this link" panel right after an instant meeting starts; Meeting details > Joining link > Copy joining link (toolbar) during any meeting.

**Scope:** link panel, copy action, explanatory note. Out: sending invitations or email (HelixtaHR), guest invitations and guest access (Phase 2).

**Flow**
1. Host starts an instant meeting and joins (US-02).
2. Ready panel: the link, Copy link and the note "Only the Host and Co-hosts join directly. Everyone else waits until you or a co-host lets them in."
3. Copy link copies it and confirms.
4. Later, any participant: Meeting details > Copy joining link.

**Business rules**
- BR-07.1 A normal meeting's link is temporary: it stops working whenever the meeting ends. A Permanent Meeting Room keeps its custom URL until the owner turns the room off (US-39).
- BR-07.2 Opening the link, or reaching pre-join, never skips admission. Only the Host and Co-hosts join directly; everyone else, including employees, waits. Forwarded links follow the same rule. Once in the meeting, any participant can copy the joining link.
- BR-07.3 A disabled link, or the link of a normal meeting that has ended: "This meeting link is no longer valid" (US-24).
- Not in Phase 1: resetting a link, ready panel for scheduled meetings, guests (and guests copying the link).

**Acceptance criteria**
- AC-07.1 Started instant meeting, Host joins → ready panel with the link and the note.
- AC-07.2 A participant selects Copy joining link → the link is copied.
- AC-07.3 A forwarded link → the person follows the admission rule and waits.
- AC-07.4 (Negative) An employee who isn't Host or Co-host opens the link, Join now → waits for Host, Co-host or Acting Host.
- AC-07.5 (Negative) The link of an ended meeting → "This meeting link is no longer valid".

**Dev notes (3 Nov, Arshdeep)**
- In a room session, Copy joining link copies the room's address `/meet/<org_id>/<url>`, not the session's id (which stops working when the session ends).
- Copy joining link is shown only to people in the meeting, not on the waiting screen.

---

## HEL-980 (US-08): Conduct the meeting

**Status:** Story updated 3 Nov (PRD v0.5; Harsh's answers of 2 Nov).

**User story:** As a meeting participant, I want audio, video, screen sharing, chat and a participant list, so that I can have a productive conversation.

**Placement:** In-meeting bottom bar and video grid; chat panel; People panel on the right.

**Scope:** mic and camera on/off, screen sharing, live chat, participant list with Host and Co-host labels. Out of scope: recording, transcription, captions.

**Flow**
1. The video grid shows each participant's tile and name (e.g. "Harsh Tyagi (Host, you)").
2. Mic or camera toggled → others see the new state within 1 second (QA benchmark).
3. Share: nobody sharing → the share starts, others see it within 3 seconds. **One share at a time.** A sharing, B selects Share → A gets a request with Stop sharing; Host, Co-hosts and Acting Host see it too. A stops → B's share starts; until then B waits. Host, Co-hosts and Acting Host can stop any share. **Only one request waits at a time**: C selecting Share while B waits sees that someone is already waiting. B's request stays open until B cancels it, A stops sharing, or the meeting ends.
4. Chat: participants see a message within 2 seconds; the panel says messages are visible only during the meeting and not saved.
5. People: every participant with labels and mic/camera state.

**Functional requirements (summary)**
- Audio/video with camera and mic on/off, visible within 1 s; screen share visible within 3 s.
- One share at a time; the request to the presenter (also shown to Host, Co-hosts, Acting Host); B's share starts when A stops.
- Host, Co-hosts and Acting Host can stop any share.
- One waiting request at a time; others told someone is already waiting.
- A waiting request stays open until cancelled, the share stops, or the meeting ends.
- Live chat within 2 s; not kept after the meeting.
- Participant list: names, Host and Co-host labels, mic and camera state.
- Camera, microphone and speaker choice carried into the meeting.
- Keyboard-usable, screen-reader labelled controls.
- Minimum identifiers only; never record or store audio, video or chat (Phase 1). Audit records still apply.

**Business rules**
- BR-08.1 Chat is never stored; no chat record after the meeting.
- BR-08.2 Every participant can share their screen (guest restrictions Phase 2).
- BR-08.3 Controls keyboard operable and screen-reader labelled.
- BR-08.4 1, 2, 3 seconds are internal QA benchmarks: a delay caused by the application is a defect, by a poor network is not.
- BR-08.5 Only one share at a time; Host, Co-hosts and Acting Host can stop any share.
- BR-08.6 Nothing stored in Phase 1 (no recording, transcription, minutes); audit records still apply.
- BR-08.7 Only one share request waits at a time; C sees that someone is already waiting.
- BR-08.8 A waiting request stays open until cancelled, the current share stops, or the meeting ends.

**Acceptance criteria**
- AC-08.1 Mic toggled → everyone sees it within 1 s (QA benchmark).
- AC-08.2 Share started → others see it within 3 s.
- AC-08.3 Chat message → seen within 2 s.
- AC-08.4 N people → People shows N entries with correct labels.
- AC-08.5 Meeting ended → no chat content found anywhere.
- AC-08.6 (Assumption) Joining mid-meeting → earlier chat not shown.
- AC-08.7 A sharing, B selects Share → A gets a request with Stop sharing; Host, Co-hosts, Acting Host see it.
- AC-08.8 A stops after B asked → B's share starts; until then B waits.
- AC-08.9 Host, Co-host or Acting Host stops a share → it ends.
- AC-08.10 Ordinary participant tries to stop someone else's share → refused.
- AC-08.11 Meeting ends → no audio, video, chat, recording, transcript or minutes kept; the audit record exists.
- AC-08.12 A sharing, B waiting, C selects Share → C sees someone is already waiting; not queued.
- AC-08.13 B's request closes when B cancels, A stops, or the meeting ends; if A stops, B's share starts.

**Development notes (Arshdeep, 2 Nov; Jira):** browsers allow a screen share only right after a click and the screen picker, so B picks the screen when selecting Share; B's share is prepared but shown to nobody until A stops, then goes live automatically. B's browser may show its own "sharing" indicator while waiting. Host stop enforced in the backend. Speed benchmarks to be set with Deepak Srivastava (QA HOD).

---

## HEL-1032 (US-28): Raise a hand and send a reaction

**Status:** Approved with conditions (Harpreet, 1 Nov); story updated (PRD v0.5). Background blur moved to a separate Phase 2 story.

**User story:** As a participant, I want to raise my hand and react, so that I can take part politely.

**Placement:** Bottom bar raise-hand and reactions buttons; People panel Raised hands; reaction tray (Thumbs up, Clap, Heart, Laugh, Wow). Host, Co-hosts and Acting Host also see a clear raised-hand indicator and can lower any hand.

**Scope:** raise hand with a Raised hands list, five reactions, lowering a raised hand, the hosts' raised-hand indicator. Out of scope: background blur (Phase 2), hand-queue ordering rules, reaction history.

**Flow**
1. Raise hand → their name appears under Raised hands (n) in People for everyone.
2. They lower it with the same button. Host, Co-hosts and Acting Host can lower anyone's raised hand. Hosts see a clear raised-hand indicator, also while presenting or sharing. No pop-up goes to all participants.
3. Reaction tray → others see the reaction briefly on the participant's tile.

**Functional requirements:** raised hands (Should); emoji reactions (Should); Host, Co-hosts and Acting Host lower any hand; hosts' indicator also while presenting or sharing; no pop-up to all.

**Business rules**
- BR-28.1 Should priority; essential functions are never delayed for them.
- BR-28.2 Available to all participants.
- BR-28.3 Raised hands and reactions are not stored after the meeting.
- BR-28.4 Raising a hand never sends a pop-up to all participants.

**Acceptance criteria**
- AC-28.1 A raised hand shows to participants in Raised hands.
- AC-28.2 A reaction is seen by participants.
- AC-28.3 Host, Co-host or Acting Host lowers a hand → it goes down for that participant.
- AC-28.4 A hand goes up while a host presents or shares → the host sees a clear indicator.
- AC-28.5 Raises a hand then leaves → the hand is removed.
- AC-28.6 A hand goes up → no pop-up to all participants.
- AC-28.7 An ordinary participant tries to lower someone else's hand → refused.

**Management (Harpreet, 1 Nov):** blur to a separate Phase 2 story; host controls to lower any hand (as HEL-972 / HEL-980); hosts see raised hands also while presenting, a simple indicator, no pop-up to all; QA approval by Deepak Srivastava; must not delay essential functions. **Arshdeep (2 Nov, Jira):** lowering someone's hand enforced in the backend; the hosts' indicator stays visible while presenting, per Ishank's design.

---

## HEL-1043 (US-34): Create and manage meetings through the API (ON HOLD)

**Status:** Returned for scope alignment (1 Nov). Resubmit after the lifecycle is agreed.

**Management direction**
- Keep only the APIs and essential integration needed for the approved Phase 1 flow. No scope expansion.
- External guest invitations → separate linked **Phase 2** story. Online interviews depend on guests → interview integration stays in **Phase 2**.
- Internal meeting scheduling → separate story linked to Phase 2.
- Align the API with the lifecycle direction (HEL-1026). Amit resolves integration ownership and capacity. Developer name out of BRs. QA approval by Deepak.

**Expected Phase 1 content:** the module's own versioned APIs used by the interface (list, create instant at Join now, join, admit/deny, co-hosts, share requests, lower hand, leave, end, revocation notice) + HelixtaHR H1 (status endpoint), H2 (deactivation/role-change notice), H3 (menu item). Webhooks to HelixtaHR likely Phase 2 (asked).

*Original rules kept for reference:* versioned documented APIs; integrating product acts only on its own product and organisations; creator may differ from Host; webhook delivery survives endpoint downtime (outbox + retry).

---

## HEL-1136 (US-39): Permanent Meeting Rooms

**Status:** Story received 3 Nov.

**User story:** As an original Host, I want to turn my meeting into a Permanent Meeting Room with my own URL, so that I and my chosen Co-hosts can hold regular meetings at the same address.

**Placement:** **In the meeting:** Meeting Settings > Permanent Meeting Room > Save Changes (an in-meeting panel, not the org-admin Settings tab of the Meetings page). The room shows on Meetings for the owner and standing Co-hosts.

**Scope:** converting a meeting, room settings (name, custom URL, standing Co-hosts, grace period), starting a session, the locked room, admission, ending a session, removing the room, audit records. Out of scope: external guests (Phase 2); limits on rooms per owner; Organisation Administrator disabling rooms; ownership transfer.

**Flow**
1. The original Host, in a normal meeting, opens Meeting Settings.
2. Turns on Permanent Meeting Room: room name, custom URL, standing Co-hosts, grace period (2 minutes default; 2 to 30).
3. The URL is checked for availability; Save Changes.
4. Converted without interrupting the meeting. The temporary link and the custom URL both work until this session ends; then only the custom URL.
5. The room shows on Meetings for the owner and standing Co-hosts.
6. Opening the URL before a session: "The host hasn't started this meeting yet".
7. The owner or a standing Co-host starts a session (Start on the room's row, or opening the URL). People on that screen move to the waiting room.
8. Everyone except Host and Co-hosts waits for admission (US-10). Owner and Co-hosts rejoin directly; places held for the whole session within 25.
9. The session ends on End meeting, or after the grace period with neither the owner nor a standing Co-host present. The room and URL stay.
10. Each session shows in Meeting history.
11. Settings changed, and the room turned off, only during a session, by the owner. Turned off during a live session → the session continues; afterwards the URL shows "This meeting link is no longer valid".

**Roles**

| Role | Convert | Settings, standing Co-hosts, turn off | Start a session | End a session |
|---|---|---|---|---|
| Owner (original Host) | Yes | Yes | Yes | Yes |
| Standing Co-host | No | No | Yes | Yes |
| Co-host appointed in this session | No | No | No | Yes |
| Ordinary employee | No | No | No | No |

**Business rules**
- BR-39.1 Only the original Host converts; not a Co-host or Acting Host.
- BR-39.2 Standing Co-hosts: internal users of the owner's organisation.
- BR-39.3 URL: 3 to 30 of lowercase letters, numbers, hyphens. The address includes the company: unique within a company; the same URL may exist in different companies.
- BR-39.4 A URL from a disabled room can't be reused for 90 days.
- BR-39.5 The URL gives no automatic entry and no management rights.
- BR-39.6 No Acting Host and no handover in a room; the grace period instead.
- BR-39.7 Grace period 2 minutes by default; 2 to 30.
- BR-39.8 Owner leaves the company or loses HelixtaHR access → their rooms disabled; standing Co-hosts don't inherit.
- BR-39.9 Phase 1: internal users only.
- BR-39.10 A meeting can be converted once; no limit on rooms per owner.
- BR-39.11 Settings and turning off only during a session, by the owner.
- BR-39.12 Turning off during a live session takes effect when that session ends.
- BR-39.13 Saving fails midway → nothing changes, retry. URL taken between the check and Save → "This URL was just taken".
- BR-39.14 A removed standing Co-host loses standing rights at once, also during a session.
- BR-39.15 Owner and Co-hosts rejoin a session directly, places held for the whole session within 25.

**Validations:** URL 3 to 30, lowercase/numbers/hyphens; reserved or offensive word refused; already used in the company refused; disabled less than 90 days ago refused; taken between check and save → "This URL was just taken". Grace period 2 to 30 minutes. Standing Co-host: internal user of the owner's organisation.

**Acceptance criteria**
- AC-39.1 Original Host saves → the meeting continues and becomes a room.
- AC-39.2 Co-host or Acting Host → option not available; refused in the backend.
- AC-39.3 Name, URL, standing Co-hosts, grace period each apply.
- AC-39.4 URL used in the same company → refused with a clear message.
- AC-39.5 Same URL in two companies → both accepted.
- AC-39.6 Reserved/offensive word, invalid characters or length → refused.
- AC-39.7 URL disabled 30 days ago → refused.
- AC-39.8 Converted, session running → temporary link and URL both join; session ended → temporary link "no longer valid", URL still works.
- AC-39.9 Owner or standing Co-host opens Meetings → the room shows.
- AC-39.10 Ordinary employee with the URL → cannot start the room.
- AC-39.11 Standing Co-host opens the URL → can start a session, can't change settings.
- AC-39.12 Not started, someone opens the URL → "The host hasn't started this meeting yet"; when a session starts they move to the waiting room.
- AC-39.13 Session started, an employee (not Host/Co-host) opens the URL → waits until admitted.
- AC-39.14 Neither owner nor standing Co-host present for the grace period → the session ends; no Acting Host.
- AC-39.15 End meeting → everyone disconnected; the same URL starts the next session.
- AC-39.16 Turned off and saved during a session → after it ends the URL shows "no longer valid".
- AC-39.17 Owner deactivated in HelixtaHR → when detected, their rooms are disabled; standing Co-hosts don't inherit.
- AC-39.18 Conversion, settings change, standing Co-host change, disabling → audit record.
- AC-39.19 Room used twice → Meetings shows one room, history two sessions.
- AC-39.20 Standing Co-host tries settings or turning off → refused in the backend.
- AC-39.21 No session running → no room settings option for the owner.
- AC-39.22 Start on the room's row (owner or standing Co-host) → a session starts.
- AC-39.23 Room full, owner or a Co-host who dropped rejoins → directly, nobody disconnected.
- AC-39.24 Turned off during a live session → it continues; afterwards the URL "no longer valid".
- AC-39.25 Saving fails midway → nothing changes, meeting continues, retry.
- AC-39.26 URL taken between check and save → "This URL was just taken".
- AC-39.27 Owner removes a standing Co-host who is in a session → standing rights lost at once.
- AC-39.28 Already converted → converting again refused.

---

## HEL-1012 (US-22): Acting Host after an unexpected drop (Harsh's story; backend built by us)

**Status:** Story received 3 Nov.

**User story:** As a participant, I want the meeting to carry on under a clear manager if the Host drops unexpectedly, so that people are admitted and the meeting stays controlled.

**Placement:** Pop-up for everyone: "The host disconnected. Amit is now managing the meeting." (the new manager's name).

**Scope:** an unexpected drop of the last Host or Co-host, Co-host carrying on, Acting Host promotion, repeat rule, notice, the 2-minute end when no one can manage. Out of scope: leaving on purpose and choosing a new Host (US-24, HEL-1026); the Host returning (US-23); Permanent Meeting Rooms, which never have an Acting Host (US-39, HEL-1136).

**Flow**
1. The Host or a Co-host disconnects unexpectedly (tab closed, connection lost).
2. Another Host or Co-host still in the meeting → it carries on under them.
3. The last Host or Co-host dropped → the admitted employee present longest becomes Acting Host.
4. Everyone sees the pop-up naming the new manager. The Acting Host sees the waiting alerts (US-10).
5. The Acting Host later disconnects → steps 2 and 3 repeat.
6. No one can become Acting Host → the meeting ends after 2 minutes, link invalid (US-25).
7. Permanent Meeting Room: no Acting Host; the session ends after the grace period (US-39).
8. The original Host rejoins → their Host rights come back (US-23).

**Functional requirements (summary)**
- Admitted employee present longest becomes Acting Host when the last Host/Co-host of a normal meeting drops unexpectedly.
- Host drops, a Co-host present → carries on under the Co-host.
- Participants notified when Host responsibility moves, naming the new manager.
- Repeat when an Acting Host disconnects.
- No one can become Acting Host → ends after 2 minutes, link invalid.
- Never an Acting Host in a Permanent Meeting Room.
- An Acting Host can admit or deny, mute and remove, stop shares, and End Meeting in a normal meeting.

**Business rules**
- BR-22.1 Eligible: an admitted authenticated internal user of the meeting's organisation, in the meeting now.
- BR-22.2 "Present longest" = current-session connection time.
- BR-22.3 Acting Host = Host's controls except appointing Co-hosts and converting to a Permanent Meeting Room.
- BR-22.4 Several Co-hosts → the pop-up says the Co-hosts are managing.
- BR-22.5 Acting Host only after an unexpected disconnect, never on a deliberate leave (US-24).
- BR-22.6 People waiting for admission are not eligible.

**Acceptance criteria**
- AC-22.1 Host drops, a Co-host present → the Co-host manages; the pop-up names them.
- AC-22.2 Last Host/Co-host drops, an admitted employee present → the one present longest becomes Acting Host.
- AC-22.3 The Acting Host drops, another admitted employee present → the rule repeats.
- AC-22.4 Only waiting people remain when the last Host/Co-host drops → no Acting Host; ends after 2 minutes (US-25).
- AC-22.5 Someone waiting when the Host drops → the new Acting Host sees the waiting alert.
- AC-22.6 Permanent Meeting Room, owner and standing Co-hosts drop → no Acting Host; ends after the grace period.
- AC-22.7 Host dropped, an Acting Host managing, the Host rejoins → Host rights restored.
- AC-22.8 Host leaves on purpose → no Acting Host (US-24).

**PM decisions (Harsh, 29 Oct):** an unexpected drop is handled **straight away**, like Leave: a Co-host keeps managing; with no Co-host, the employee present longest (usually the second person who joined) becomes Acting Host; guests never take over (no guests in Phase 1 anyway); when the Host rejoins, their rights come back. The pop-up names the new manager. No tie-break rule for two people joining at the same moment (not a Phase 1 requirement).

---

## HEL-1026 (US-24): Leave Meeting or End Meeting

**Status:** Story updated 3 Nov (PRD v0.6, Harsh's PM decisions). BA readiness 80% before Harsh's answers; design update asked of Ishank (screens only); Amit, Harshit and Deepak Srivastava to give readiness scores after the design.

**User story:** As a Host, Co-host or Acting Host, I want to leave the meeting or end it, so that I decide whether the meeting carries on and whether its link stays usable.

**Placement:** Bottom bar Leave or end (red) opens the Leave or end dialog; participants without host rights see Leave only. After a normal meeting ends, it shows only in Meeting history. A Permanent Meeting Room stays on Meetings.

**Scope:** Leave Meeting, End Meeting, choosing a new Host when the last Host or Co-host leaves on purpose, Cancel. Out of scope: converting to a Permanent Meeting Room (HEL-1136); the Acting Host after an unexpected disconnect (HEL-1012); HelixtaHR acting on link-disabled events (Phase 2, with scheduling).

**Flow**
1. Host selects Leave or end: Leave meeting, End meeting, Cancel.
2. **Leave meeting:** only the person leaving is disconnected.
   - Another Host or Co-host still in the meeting → it carries on under them.
   - Last Host or Co-host of a normal meeting → asked to choose an **admitted employee** as the new Host; the meeting carries on under that person; everyone sees a notice naming the new Host. If the chosen person disconnects before the handover completes, choose again. An Acting Host leaving on purpose follows the same rule.
   - Leaves without choosing → the meeting ends for everyone and its link stops working. No Acting Host when a Host leaves on purpose.
   - Permanent Meeting Room: no handover; the grace period applies (HEL-1136).
3. **End meeting:** the current session ends, everyone is disconnected. Normal meeting → link stops working. Permanent Meeting Room → room and URL stay. Everyone sees "The meeting has ended" with Back to Meetings.
4. An ended normal meeting shows only in Meeting history; a Permanent Meeting Room stays on Meetings.

**Roles**

| Role | Leave | End (normal) | End (room) | Choose new Host on leaving |
|---|---|---|---|---|
| Host | Yes | Yes | Yes | Yes, if last Host/Co-host (normal only) |
| Co-host | Yes | Yes | Yes | Yes, if last Host/Co-host (normal only) |
| Acting Host | Yes | Yes | n/a (no Acting Host in a room) | Yes, if last Host/Co-host/Acting Host (normal only) |
| Ordinary participant | Yes | No | No | No |

**Functional requirements (summary)**
- Leave disconnects only the person who leaves.
- Last Host/Co-host leaving a normal meeting on purpose → choose an admitted employee as new Host; carries on under them.
- Leaves without choosing → ends for everyone, link invalid. No Acting Host on purpose-leave.
- End Meeting ends the session for everyone (normal: Host, Co-hosts, Acting Host; link invalid. Room: Host, Co-hosts; room and URL stay). No End for All / End and Disable Link.
- **Record:** meeting creation and termination, start and end times, attendance, joins, leaves and reconnections, Host and Co-host changes including handover, admission, denial and removal, link termination and access events, Permanent Meeting Room events, organisation settings and retention changes.
- "This meeting link is no longer valid", no details, for disabled/revoked/expired/altered links and ended normal meetings.

**Business rules**
- BR-24.1 End Meeting: Host, Co-host, Acting Host in a normal meeting; Host and Co-hosts in a room; never ordinary participants.
- BR-24.2 A normal meeting link stops working whenever the meeting ends: End Meeting, last Host/Co-host leaving without choosing, or ending after an unexpected drop (US-22).
- BR-24.3 End Meeting in a room ends only that session.
- BR-24.4 Ending closes the waiting room: people waiting are disconnected.
- BR-24.5 Handover is a choice made on leaving; an Acting Host only after an unexpected disconnect, never in a room.
- BR-24.6 A Host who handed over on purpose rejoins as a Co-host (US-23).
- BR-24.7 No admitted employee present to choose → leaving ends the meeting for everyone (confirmed by PM, no longer an assumption).
- BR-24.8 Chosen new Host disconnects before the handover completes → choose again; leaving without choosing ends the meeting.
- BR-24.9 An Acting Host leaving on purpose follows the same handover rule.
- BR-24.10 Handover → everyone sees a notice naming the new Host. End Meeting → "The meeting has ended" with Back to Meetings.

**Acceptance criteria**
- AC-24.1 Co-host still there, Host leaves → only the Host disconnected; carries on under the Co-host.
- AC-24.2 Normal meeting, Host/Co-host/Acting Host ends → everyone disconnected; link "no longer valid".
- AC-24.3 Room, Host/Co-host ends → everyone disconnected; the URL starts a new session later.
- AC-24.4 Ordinary participant calls End Meeting → refused in the backend.
- AC-24.5 Last Host leaves and chooses an admitted employee → that person is Host; carries on.
- AC-24.6 Cancel → nothing changes.
- AC-24.7 Last Host leaves without choosing → ends for everyone; link "no longer valid".
- AC-24.8 Host leaves on purpose, meeting carries on → no Acting Host.
- AC-24.9 People waiting when the meeting ends → disconnected.
- AC-24.10 Host leaves a room, no owner/standing Co-host remains → no handover; session ends after the grace period.
- AC-24.11 Host who handed over rejoins → directly, as Co-host.
- AC-24.12 Dialog → no End for All / End and Disable Link.
- AC-24.13 Chosen person disconnects before the handover completes → choose again.
- AC-24.14 Acting Host is the last one managing a normal meeting and leaves → asked to choose a new Host.
- AC-24.15 Handover → everyone sees a notice naming the new Host.
- AC-24.16 End Meeting → everyone sees "The meeting has ended" with Back to Meetings.
- AC-24.17 No admitted employee present, last Host leaves → ends for everyone; link "no longer valid".

**PM answers (Harsh, 3 Nov, PRD v0.6):** BR-24.7 confirmed; 2a/2b as BR-24.8/24.9; what others see as BR-24.10; roles table added; title "Leave Meeting or End Meeting". Arshdeep's five lifecycle questions answered: the link becomes invalid whenever a normal meeting ends; leaving without choosing ends the meeting, any admitted employee can be chosen; Permanent Meeting Rooms are Phase 1 (HEL-1136); HelixtaHR link-disabled handling is Phase 2; ended normal meetings show only in Meeting history.

---