One call window, its controls, then a recording
A video-call app’s window has a camera, a screen-share button and a status banner, and later a network monitor and a recorder. Like the lesson’s panels and their desk, each control should report to the window, and the window decides what the others show. Each level starts from the previous level’s finished code, so you can begin at any of them.
A teammate’s pull request adds recording: while a meeting records, the banner must say recording, whatever else it says. The recorder sets the banner itself. The same pull request makes the camera report every change, so the window always knows what the camera shows, and the window updates cameraWanted from those reports. QA reports that cameras stay off after presenting, and that the recording notice disappears. You are reviewing the pull request.
People who present once are invisible for the rest of the call. Participants stop seeing that they are being recorded, which the app must show at all times.
Reproduce w.input("share"); w.input("stop") should bring the camera back; with the pull request it stays off. w.input("record"); w.input("share") should say recording, presenting; it says presenting.
Acceptance criteria While the meeting records, the banner always lists recording first, then poor connection, then presenting, as they apply. Only the user’s presses change what the user wants: the camera comes back after a share or a poor connection whenever the user still wants it. Every rule from MEDIATOR-101 and MEDIATOR-102 still holds. Keep what the pull request is right about, and remove what it gets wrong. Notes Each case prints camera=on|off share=on|off banner=<text>, as before. The input record starts the recording. Keep the window’s input method and the fields the checker reads (camera.on, share.sharing, banner.text).