Problem
When a document is soft-promoted from a bare spine or story item — i.e. the author wrote no explicit Sequence shell — the spine is packed at a hardcoded 1080p24 frame duration, ignoring the format actually in play.
Before #42 this lived in Defaults.sequence(spine:format:); it now sits in ModelSequence.init(packing:format:):
let packed = try Layout.pack(
spine.items,
frameDuration: FormatPreset.p1080p24.format.frameDuration // <- always 100/2400s
)
The caller passes a format resource ref, and it is used for the sequence's format attribute — but not for the packing frame duration. Compare the DSL Sequence.build, which does it correctly:
frameDuration: format?.format.frameDuration
Impact
Any soft-promoted document at a non-1080p24 frame rate gets offsets and durations computed against the wrong tick denominator. The .spine and .item promotion paths are affected; the explicit-Sequence path is fine.
Low real-world impact today because the presets are both 24fps, but it is wrong and it will bite the moment a 25/30/60fps preset is added.
Why it went unnoticed
No test drives the .spine or .item promotion arms. SmartCollectionVersionTests.MinimalDoc exercises only .project.
Fix
Thread the real frame duration through, matching Sequence.build. Also add promotion-path coverage — the arms are currently untested for anything beyond smart collections.
Found while refactoring #42; not caused by it.
Problem
When a document is soft-promoted from a bare spine or story item — i.e. the author wrote no explicit
Sequenceshell — the spine is packed at a hardcoded 1080p24 frame duration, ignoring the format actually in play.Before #42 this lived in
Defaults.sequence(spine:format:); it now sits inModelSequence.init(packing:format:):The caller passes a
formatresource ref, and it is used for the sequence'sformatattribute — but not for the packing frame duration. Compare the DSLSequence.build, which does it correctly:Impact
Any soft-promoted document at a non-1080p24 frame rate gets offsets and durations computed against the wrong tick denominator. The
.spineand.itempromotion paths are affected; the explicit-Sequencepath is fine.Low real-world impact today because the presets are both 24fps, but it is wrong and it will bite the moment a 25/30/60fps preset is added.
Why it went unnoticed
No test drives the
.spineor.itempromotion arms.SmartCollectionVersionTests.MinimalDocexercises only.project.Fix
Thread the real frame duration through, matching
Sequence.build. Also add promotion-path coverage — the arms are currently untested for anything beyond smart collections.Found while refactoring #42; not caused by it.