# Video Sync · PM-confirmed Cap=4 + Frame Reorg · Next Session Pickup (2026-05-26)

> Phase A done (text-level propagation). **Phase B = visual frame redesign per PM-confirmed accordion model.** Supersedes [2026-05-25 handoff](./2026-05-25-video-sync-next-session-pickup.md) — read this file first, then the prior one for historical context only.

## 1. PM Confirmation (Slack 2026-05-26, Mateus + Ahmed)

**PM-confirmed values:**
- **Creation cap per Producer Program: 4** (`1- Yes for both minimum and cap`)
- **Concurrent Syncing per Producer Program: 4** (`2- Yes, 4 concurrent in the same production max`)
- **Per-account cross-PP**: backend license, UI does not gate

**Reference for Ahmed's output breakdown** (bein sports case → 2 sync sessions baseline, 2× headroom = cap 4):
- Slot1↔Slot2 (Session #1)
- Slot3↔Slot4 (Session #2)
- Main + Backup output 30MB each (not sync sessions, separate playback chain)

## 2. Phase A Completed (本 session, 2026-05-26)

文本层面 cap=4 全量 propagate 已落地：

### Text updates in Figma (`DtZcMkhNy6qh6jbQQnhreQ`)

| Surface | Old | New |
|---|---|---|
| M0 chip | `1/8 sessions` | `1/4 sessions` |
| M1/M2/M3/M4 chip | `3/8 sessions` | `3/4 sessions` |
| M-Cap-Full chip | `Remove one to add another · 8/8 sessions` | `Remove one to add another · 4/4 sessions` |
| Cap-Full state-label EN/ZH body | "8 sessions in list (3 Syncing + 5 Inactive)" | "4 sessions in list (1 Syncing + 3 Inactive)" |
| Design Rules slot-cap rule EN | "current placeholder: 8, pending PM confirmation" | "4 — PM confirmed 2026-05-26" |
| Design Rules slot-cap rule ZH | "当前暂定 8，以 PM 确认为准" | "4（PM 确认 2026-05-26）" |
| Design Rules anti-hardcode line | "do NOT hardcode 8" | "do NOT hardcode 4" |
| All M-state-label annotations | "PP sub-panel slot counter chip `N/8 sessions`" | "...`N/4 sessions`" |

**Total: 27 text nodes updated across 2 batch use_figma calls (21 first pass + 6 second-pass artifact fix).**

### What is NOT done in Phase A (deferred to Phase B)

⚠️ **The visual content of frames is still on the OLD spec.** Specifically:
- M1 still shows 5 sessions (#1-#5) — should be max 4 per cap
- Cap-Full frame `4528:2768` still shows 8 session rows — should be 4
- Row design is still default-collapsed (need accordion model)
- No new frames built yet

The chip text says `3/4` and `4/4` but the rendered rows don't match. **This is intentional partial progress — the text was the safest cheapest first delivery to give PM confirmation a foothold in the file.**

## 3. PM-confirmed Design Model (Phase B locks in)

### 3.1 Accordion row model — DECISION

**Default state: only the currently-selected session is expanded (192px). All others are collapsed (72px header only).** User can manually click ▼ arrow to expand/collapse additional rows. Beyond 2 expanded rows, list scrolls vertically.

Math validation (LEFT container 1168×680, session-list area ~575 tall):

| Scenario | Height usage | Fits? |
|---|---|---|
| N=4, 1 expanded + 3 collapsed + cap chip + 4 dividers | 192+216+32+4 = **444** | ✅ |
| N=4, 2 expanded + 2 collapsed + cap chip + 4 dividers | 384+144+32+4 = **564** | ✅ |
| N=4, 3+ expanded | 576+72+4+32 = **684+** | ❌ scroll |

### 3.2 Rules per user 2026-05-26 (locked)

| # | Rule |
|---|---|
| 1 | Row default = **selected expanded, others collapsed** (accordion) |
| 2 | Row height: collapsed = **72px**, expanded = **192px** (72 header + 120 expand-panel) |
| 3 | Max 2 default-expanded rows visible without scroll; beyond → vertical scroll |
| 4 | `+ Add another sync session` row position = **always immediately after the last session row** (N+1 slot) |
| 5 | When N=4 (cap reached), Add row is **replaced** by Cap-Full chip `Remove one to add another · 4/4 sessions` (no Add button rendered) |
| 6 | Cap-Full chip position = **bottom of list region** (replaces Add CTA, NOT right-aligned in PP header anymore) |
| 7 | Below the last interactive row (Add or Cap chip), container background extends downward to fill panel — **no placeholder rows, no dashed empty slots** |
| 8 | **Container LEFT height = RIGHT Parameters panel height (680)** — content top-aligned, empty space below is dark bg fill |
| 9 | Session numbering on Remove: **renumber sequentially (#1, #2, #3...)** because the number is a sequence, not a name |
| 10 | UX delivery doc (state-label) carries the concurrency cap statement: "Up to 4 concurrent `Syncing` sessions per PP (PM confirmed 2026-05-26)" — NOT visible in UI itself |

## 4. Phase B Scope (next session, fresh context)

### 4.1 Frame timeline (按用户操作顺序，重命名 + 重排)

| New # | Name | Content | Source frame to modify/create |
|---|---|---|---|
| **M1** | Empty · No PP selected | LEFT 空状态，引导 "Select a Producer Program to begin" | **NEW** |
| **M2** | PP Selected · Session #1 Bootstrap | 1 session, Inactive, expanded, chip `1/4` | Modify old M0 (`4139:1376`) |
| **M3** | Session #1 Syncing | 1 session, Syncing, expanded, chip `1/4`, live Δ | Modify (variant of M2) |
| **M4** | Sync Completion Toast | 1 session expanded + 2 toasts (M4 current `4210:1715` simplified from 3-session to 1-session) | Rework current M4 |
| **M5** | 2 Sessions · #1 selected | 2 sessions; #1 selected & expanded, #2 collapsed; chip `2/4` | **NEW** |
| **M6** | 3 Sessions · Mixed States | 3 sessions; #1 Syncing selected-expanded, #2 Inactive collapsed, #3 Syncing collapsed; chip `3/4` | Modify old M1 (`4119:199`), reduce 5→3 |
| **M7** | Cap Full · 4 Sessions | 4 sessions; #1 expanded selected, #2-4 collapsed; **bottom Cap-Full chip** `Remove one to add another · 4/4 sessions` | Rework Cap-Full (`4528:2768`), reduce 8→4 |
| **M8** | Manual Collapse | 4 sessions, user collapsed #1 via ▼, all 4 collapsed (selected ring still on #1) | **NEW** |
| **M9** | Remove Confirmation | M7 + Notification dialog overlay | Reposition existing dialog (`4528:3222`) into Plan A section |
| **M10** | After Remove · Renumbered | Was 4 sessions, deleted middle one, renumbered → 3 sessions #1 #2 #3 sequential; chip `3/4` + Add restored | **NEW** |

**M-PP-Switch deferred** (user agreed to skip).

### 4.2 Legacy frames to delete

- Old `M2 · Row Expanded — Slot/Channel (R2)` (`4139:988`) — accordion model makes it redundant (selected row IS the expanded row, no separate "expanded variant" needed)

### 4.3 Design Rules card updates needed

Add/update rules in card (`4166:1231`):
- Add: "Row default expanded = currently-selected only (accordion)"
- Add: "Manual ▼ arrow toggles expand/collapse on any row"
- Add: "Renumber session #N sequentially on Remove (sequence, not name)"
- Add: "List scrolls vertically when >2 expanded rows exceed container height"
- Update: existing 14 rules with new cap=4 reference

### 4.4 State-labels needed per new frame

- M1 Empty, M2-M10: each new state-label sticky describing UX intent + invariants
- M-Cap-Full state-label (`4508:2713`): already content-updated to "4 sessions"; positioning needs review when M7 frame is rebuilt

### 4.5 Container规范 to enforce across all frames

- LEFT: 1168 × 680 (no change in size, but internal layout per Phase B rules)
- RIGHT: 680 × 680 Parameters instance (unchanged)
- Section `4119:198`: resize to accommodate 10 frames + dialog + design rules card

## 5. Critical Node IDs (verified 2026-05-26)

| Purpose | Node ID |
|---|---|
| Plan A section | `4119:198` |
| Old M0 (1 session) | `4139:1376` → becomes new M2 |
| Old M1 (3 sessions default) | `4119:199` → becomes new M6 |
| Old M2 (Row Expanded) | `4139:988` → **DELETE** |
| Old M3 (Inactive Selected) | `4165:950` → review, possibly fold into M5 |
| Old M4 (Sync Completion) | `4210:1715` → becomes new M4 (simplified) |
| M-Cap-Full frame | **`4528:2768`** (corrected from prior handoff's `4464:2326`) |
| M-Remove-Dialog container | **`4528:3222`** (corrected from prior handoff's `4503:5337`) |
| state-label · M-Cap-Full | `4508:2713` |
| Design Rules card | `4166:1231` |
| Design Rules slot-cap rule (EN) | `4433:2324` |
| Design Rules slot-cap rule (ZH) | `4433:2325` |
| TVU `Notification` component set | `23535120dbdc93bf90af9a118b5091e58b590dc6` |

LEFT/RIGHT split per frame (all uniform):
- LEFT panel id: see prior handoff table; all 1168×680 starting at (24, 232)
- RIGHT Parameters instance: 680×680 starting at (1216, 232)

## 6. Execution order recommendation (Phase B, fresh session)

1. **Inspect current row architecture deeper** — query M0/M1 to understand row component vs clone, find Stream A/B picker structure in expand-panel
2. **Componentize Session Row** (deferred architectural work `(d)` from prior handoff) — make a file-local component master with variants:
   - state: Syncing / Inactive
   - selected: Yes / No
   - expanded: Yes / No
3. **Replace existing row clones** in M0-M4 with instances
4. **Build new frames** M1 Empty / M5 / M8 / M10 from scratch using component instances
5. **Rework M4/M6/M7** using component instances + content tweaks
6. **Delete legacy M2 frame**
7. **Update Design Rules card** with new rules
8. **State-label fan-out** per new frame
9. **Resize Plan A section** to fit
10. **Screenshot verification** + memory回流 + work log

**Estimated Phase B effort: 25-35 use_figma calls + 3-5 doc writes. Plan a clean conversation context for it.**

## 7. Memory回流 already in place

[MEMORY.md](../../../../.claude/projects/-Users-nancy-Documents-AICoding-VS-Code-MicroApps/memory/MEMORY.md) currently has:
- `microapps-layout-convention.md` — 1216/680 split rule
- `reference_tvu_consumer_conventions.md` — TVU consumer通用工作规则

**Phase B should add** a new memory:
- `figma-video-sync-source.md` (reference type) — anchor pointing here:
  - Figma fileKey: `DtZcMkhNy6qh6jbQQnhreQ`
  - Section: Plan A `4119:198`
  - Handoff chain: `docs/handoffs/2026-05-*-video-sync-*.md`
  - Reason: this is a long-running design with multi-session history; future AI should find context here rather than re-discovering

## 8. Open questions to revisit

1. **Renumber on delete UX detail** — when deleting #2 from [#1, #2, #3, #4], do we animate the shift, or instant re-render? Out of scope for static mockup but PRD spec needs it.
2. **Scroll affordance** — when >2 expanded rows trigger scroll, is the scrollbar visible or auto-hide? Affects whether M8 needs to demonstrate it.
3. **Cap-Full chip styling at bottom** — should it use `Tips` grey or get a subtle warning visual (e.g. `Color Type/Text/Warning` BRAND red text)? Current text is grey; PM did not push back so keep grey unless walkthrough flags.