a 43 second demo video built from the real binary, in the hero

[gerardrecinto]

The hero now plays a 43 second, silent, 1080 by 1080 demo in place of the YouTube embed. An agent says the backup is fine and proposes dropping production, Joltrin blocks it because no validated backup is on record, the structured block result is shown, the agent runs the missing steps, and the same action is then allowed. It ends on the tagline, joltrinhq.com and the demo command.

Every line of terminal text and the JSON in the video is read from the real binary at build time. scripts/promo/capture.mjs runs sop-mcp-server demo, demo --json, and one execute_step over MCP stdio, scripts/promo/render.mjs draws the scene at 30 fps in Chromium, and scripts/promo/build.sh encodes it with ffmpeg. Rebuilding from this tree gives byte-identical files, so the video cannot drift from the product. The only things not from the binary are the captions and the check line, which are labelled as narration in the footer.

Files: joltrin-barrier.mp4 (1.3 MB, H.264, faststart), a 720 px copy for phones (714 KB), and two posters. The page picks the small file on a narrow screen or with data saver on.

Homepage: the video is in the hero beside the headline and the YouTube embed and its roughly 6 MB of third-party scripts are gone. It has no source until the page has loaded, plays only while on screen, pauses when scrolled away, has a keyboard-reachable Play and Pause button, and does not autoplay for visitors who prefer reduced motion, who get the poster and the button. There is a text version under it for people who cannot play video. The layout is fixed square, so there is no layout shift. The README uses the poster linking to the file.

Measured in headless Chromium against the homepage on master, three runs each: requests 38 to 12, third-party bytes about 6.9 MB to 0.93 MB. The load event was already about 340 to 370 ms because the YouTube player started after load, and is 340 to 450 ms now, so that did not change. Cumulative layout shift 0. On emulated Fast 3G with a phone viewport the first paint was 2.3 s and the load event 3.2 s, and the video file was not requested during load.

Tests: the homepage tests for the old iframe are replaced with tests that the video is in the hero and silent with a poster and no source at parse time, that it plays when on screen and the button pauses and resumes it, that reduced motion gets no autoplay but can still start it, and that the files exist and stay under size limits. The homepage and interaction suites pass on Chromium and Pixel 5, and the homepage suite also passes on WebKit and iPhone 12.

Thanks, Gerard Recinto

[github-actions]

Gemini PR Review

Reviewed commit: e852bbca166bab6c31281f9bfc879c4c8cee882f
Verdict: FAIL

• Correctness bug: In demo/index.html, the fallback text within the <figcaption> for the demo video currently only lists one BLOCKED step. The video itself and the prior static text for #hero-example described two blocked steps followed by two allowed steps, then the final blocked step becomes allowed. The current static text is:

  <ol id="hero-example" class="mt-2 space-y-1 font-mono text-[12px] text-slate-300 list-decimal list-inside">
      <li><span class="text-white">drop_prod_db</span> <span class="text-rose-400 font-bold">BLOCKED</span>, <code>backup_validated</code> is missing from the trace</li>
      <li><span class="text-white">take_backup</span> <span class="text-brand-400 font-bold">ALLOWED</span></li>
      <li><span class="text-white">validate_backup</span> <span class="text-brand-400 font-bold">ALLOWED</span></li>
      <li><span class="text-white">drop_prod_db</span> <span class="text-brand-400 font-bold">ALLOWED</span>, the evidence now exists</li>
  </ol>

  This sequence omits the second "BLOCKED" step ("validate_backup BLOCKED, backup_taken missing") that was present in the old static text and is implied by the demo video's narrative (where take_backup and validate_backup are explicitly run before drop_prod_db is allowed). The static text should accurately reflect the full sequence or clarify that it's a simplified version. The test tests/homepage.spec.ts was changed from toHaveCount(2) to toHaveCount(1) for BLOCKED steps, correctly reflecting this new simplified static text, but the static text itself could be considered less complete.

This result blocks merge. Push a fix and comment /gemini review. To contest a finding, see the Gemini dispute process in CONTRIBUTING.md.

[gerardrecinto]

/gemini dispute

1. Finding: "the fallback text within the figcaption currently only lists one BLOCKED step ... omits the second BLOCKED step (validate_backup BLOCKED, backup_taken missing)".
2. Refers to #hero-example in demo/index.html and the BLOCKED count assertion in tests/homepage.spec.ts.
3. Status: unsupported. The text is the sequence the product actually produces.
4. Evidence: sop-mcp-server demo prints exactly one BLOCKED line (drop_prod_db), then take_backup ALLOWED, validate_backup ALLOWED, drop_prod_db ALLOWED. In that order, validate_backup is never blocked, because take_backup runs first. The video is built from that same output (scripts/promo/capture.mjs), and TestDemoBlocksTheDropThenAllowsItInOrder pins the order. The old two-BLOCKED text described a different ordering (validate before backup), which is not what the video or demo shows, so keeping it would contradict the video. The test count of 1 is the correct assertion for the real sequence.
5. Not applicable, this is repository behavior.
6. No security reachability. Documentation text only.
7. Reproduce: go run ./cmd/sop-mcp-server demo.

Thanks, Gerard Recinto

[gerardrecinto]

/gemini review

[github-actions]

Gemini PR Review

Reviewed commit: e852bbca166bab6c31281f9bfc879c4c8cee882f
Verdict: PASS

No actionable findings.