[jerelvelarde]

openduet-demo-paced.mp4

The problem

The README demo moved too fast to follow. Eli's note on it was that it felt very fast and hard to follow. Waits were fast-forwarded with speed badges, results sat on screen for about a second, and the generated cards appeared in one frame, so a first-time viewer could not tell what the Bot had done before the next thing started.

The approach

The demo is re-recorded on main 3392165, which now builds generated cards in a piece at a time (#69) and keeps a tall morning brief's top in view while it lands (#70, #72). It uses the same script and order as before: the brief arriving by itself, Allow once, a task hand-off, the Make loop and the channels.

The pacing changed rather than the content. Each settled result is held for about 2.2 s. A tap ring sits on its target for about half a second before each tap. The moments that matter play at real speed, and dead waits on the model are cut, not sped up, so there are no speed badges. Every caption stays on screen for at least 3.6 s. The cost is length: 66.7 s, up from 37.6 s.

What is not covered

• The greeting and the first Needs you row appear together. The screen capture dropped about 200 ms of frames as the card landed, so only the rows from Northline down are seen building in.
• The brief's greeting depends on the viewer's clock; this take was recorded in a morning timezone so it reads "Morning, Maya."

Verification

Frames from the brief's arrival show the greeting and Needs you rows on screen from the first frame of the card, with the rows below fading in about 70 ms apart. A contact sheet of the whole cut shows no "can make mistakes" line in any frame. The only change in this PR is the asset link on README line 27.