Declare the correct minimum host version #6

Activity

1. pullfrog commented on Sep 11, 2026

   

   pullfrogBot

   on Sep 11, 2026 – with Pullfrog

   Contributor

   More actions

     ^{｜ Build this ➔ ｜ Make a plan ➔}
2. cchacs commented on Sep 11, 2026

   

   cchacs

   on Sep 11, 2026 – with Claude

   CollaboratorAuthor

   More actions

   Investigated before touching the manifest — the actual scope here is bigger than "declare the correct minHost."

   I checked the three APIs this plugin calls (window.highway.renderFrameAt, window.highway.getCanvas, and splitscreen's beginOfflineRender/renderFrameAt/endOfflineRender) against the current get-flashbacks/feedback core and get-flashbacks/feedback-plugin-splitscreen source. None of them exist in either repo, in any version. There's no .git history, changelog entry, or code path for deterministic frame rendering anywhere in core, and splitscreen has no offline-render hooks at all.

   That means there's no minHost (or minimum splitscreen version) I can honestly write into the manifest — any number would claim compatibility with something no released build actually provides. Declaring a version wouldn't fix the runtime error; the error is currently correct, just unhelpfully worded (it reads like a version mismatch when it's actually "this feature was never built").

   Two ways to actually close this:

   1. Implement the API — add renderFrameAt(time)/getCanvas() to core's highway (static/highway.js) and beginOfflineRender()/renderFrameAt()/endOfflineRender() to splitscreen, then declare the real versions those APIs shipped in. This is the only way minHost becomes a true statement.
   2. Reframe as a feature-request/design issue for that API, separate from this manifest-metadata ask — if that's a bigger undertaking than fits here.

   I don't want to guess at a version number for an unreleased feature, so I haven't touched plugin.json. Let me know which direction you want and I can scope the actual API design, or if this should just get re-labeled/re-titled to reflect the real ask.

   ---

   Generated by Claude Code
3. cchacs

   added the

   Task

   issue type on Sep 23, 2026
4. cchacs

   added

   documentationImprovements or additions to documentationImprovements or additions to documentation

   and removed

   documentationImprovements or additions to documentationImprovements or additions to documentation

   on Sep 23, 2026
5. cchacs commented on Sep 26, 2026

   

   cchacs

   on Sep 26, 2026

   CollaboratorAuthor

   More actions

   Compatibility follow-up for Visual Export 0.2.1 (inspected revision e05e4be):

   • Core renderFrameAt(time), renderFrame and setExternalFrameDriver landed in get-flashbacks/feedBack@f7c761c on September 16: get-flashbacks/feedBack@f7c761c.
   • Splitscreen added beginOfflineRender/renderFrameAt/endOfflineRender in get-flashbacks/feedBack-plugin-splitscreen@2301dd5 on September 16: get-flashbacks/feedBack-plugin-splitscreen@2301dd5. They are present in the inspected Splitscreen 1.14.18 checkout.
   • Therefore the dependency is now implemented in this fork. A runtime-tested release/commit floor still needs to replace minHost: "1.0.0"; do not infer compatibility from the shared 0.3.0-alpha.2 string alone.
   • Keep the single-highway requirement distinct from the optional Splitscreen integration, and list FFmpeg/WebCodecs requirements separately.

   These are source/history findings, not an end-to-end historical release certification. The previous audit also found a separate lyrics-only panel export defect; availability of the API does not certify all layouts.

   Core baseline tracker: get-flashbacks/feedBack#102
   Splitscreen compatibility: get-flashbacks/feedBack-plugin-splitscreen#69
6. cchacs

   added a commit that references this issue on Sep 27, 2026

   docs: add CLAUDE.md and AGENTS.md (#10)

   ...

   8d845d0
7. cchacs commented on Oct 1, 2026

   

   cchacs

   on Oct 1, 2026 – with Claude

   CollaboratorAuthor

   More actions

   @pullfrog please build this (Effort: Low), using the compatibility follow-up already in this thread: core renderFrameAt landed in feedBack f7c761c and Splitscreen's offline-render hooks in 2301dd5. Don't infer a floor from the shared 0.3.0-alpha.2 string alone. Keep the single-highway requirement distinct from the optional Splitscreen integration, and list FFmpeg and WebCodecs requirements separately. Follow the repo's CLAUDE.md (version bump and CHANGELOG) and open a PR against main. Please don't merge it.

   ---

   Generated by Claude Code

   👀React with 👀1Reacted by pullfrog
8. pullfrog commented on Oct 1, 2026

   

   pullfrogBot

   on Oct 1, 2026 – with Pullfrog

   Last edited by pullfrog

   Contributor

   More actions

   Opened #15 fixing #6.

   The headline is that minHost is removed rather than corrected. It read 1.14.8, a Split Screen version, but plugin-spec §4.1 defines minHost as the minimum Host (core) version — so it described a core compatibility level the number says nothing about. No core version can replace it: feedBack's VERSION has read 0.3.0-alpha.2 since five weeks before renderFrameAt() landed in f7c761c, and feedBack ships no releases or tags. It's also advisory-only today (no minHost reference anywhere in feedBack's plugin-loader.js).

   So compatibility is enforced by capability instead. A pre-flight check now names the side that's actually too old: highway.renderFrameAt() (feedBack f7c761c) for every export, or Split Screen's offline-render bridge (1.14.8) only when exporting a split layout. Previously one message blamed both at once, so a stale Split Screen was indistinguishable from a stale host.

   Worth flagging for review: this reverses 7e9f52c, which set minHost to 1.14.8. If you'd expected a value there rather than field removal, that's the piece to push back on.

   Two corrections a self-review caught, both of which had made it into the docs:

   • I'd written that a partial Split Screen bridge "silently rendered non-deterministically." Wrong — that repo's renderFrameAt returns false unless beginOfflineRender() ran, so it died on frame 0 with a misleading generic error. It's a better error message, not a corruption fix, and the changelog now says so.
   • I'd attributed the bridge to 87e3622a alone and called 2301dd5 a red herring. Split Screen's own v1.14.20 notes say "added in 2301dd5 and completed in 87e3622a"; the PR follows them.

   Also added tests/js/screen.test.js (9 tests, run in CI) since screen.js has no exports — the gate is extracted from real source, and I mutation-checked the suite to confirm it can fail. Cleared a stale "Known gap" note in CLAUDE.md about Staff View, which survived PR #4 merging; flag it if you'd rather split that out.

   All CI steps pass locally. Left for follow-up, not done here: CHANGELOG.md still has no ## [0.2.1] section (v0.2.1 was cut as a prerelease and Split Screen's notes depend on that version number), PR #14 independently targets 0.3.0 so one version bump will need adjusting, and nothing runs the gate against a real old/new Split Screen build.

   Task list (6/7 completed)

   • Correct CLAUDE.md 2301dd5 attribution to upstream's own wording (added in 2301dd5, completed in 87e3622a)
   • Fix screen.js comment: a partial bridge fails at frame 0 via renderFrameAt's own guard, it does not silently render
   • Reword CHANGELOG partial-bridge entry to match verified behavior
   • Add tests/js/screen.test.js covering frameDriverProblem's branches + CI step
   • Fix stale CLAUDE.md Staff View 'Known gap' (PR Fix Staff View notation never appearing in exported video #4 merged)
   • Final consistency pass on README + full diff, re-run all CI checks
   • Commit, push, open PR with reversal + follow-up context

     ^{｜ View workflow run ｜ via Pullfrog ｜ Using big-pickle (free) ｜ 𝕏}
9. cchacs

   added a commit that references this issue on Oct 1, 2026

   fix: declare host compatibility by capability, not a wrong minHost (#15)

   ...

   a7bad12
10. cchacs

    closed this as completedin #15on Oct 1, 2026