ykcheungab
c37efd7a44
The pre-push gate linted only the dirty tree, so the commits about to be pushed went unchecked; and every failed overlay projection was sticky, which cost a finger result its overlay over one bad frame while box results were retried nowhere. gate.ps1 now takes -LintBase (default origin/main, exit 2 on an unknown ref), the projector declares whether its own failures are permanent, and serve_stored_view decides before it sets the view. Verified with gate.ps1 (PASS: 569 studio + 485 shared tests, 632 ui_check checks) and the two round-2 red samples kept in scratch.
Test recordings
box_short_20260930/ is one real recording, kept in the repository because several tests
must drive the real SDK chain over real footage. A synthetic clip cannot replace it: the
box chain's stitch probe looks for the lenslet grid in the image, does not converge on
generated pixels, and a synthetic 896² clip sent the chain into minutes of work where this
33-frame clip takes about two seconds.
What it is
| Sensor | box (shipped bundle) |
| Source | .scratch/result-visible/recording/20260930T015028Z_session0002_40cb8e7441434feab48bb646afdba011/ — recorded 2026-09-30, session_id 2. The directory name is the recording's own identity, so it matches the dist/ path below. |
| Length | 33 frames, frame ids 20…52, 1.92 s of signal time |
| Files | raw_0001.mp4, frames.csv, forces.csv, events.csv, session.json (3.8 MB) |
| Not included | preroll_0001.mp4 (3.5 MB, optional for every reader: RecordingReader.preroll_segment() answers None when the file is absent) |
dist/ is build output and is not tracked, so the copy under dist/OrisysStudio/outputs/recordings/ disappeared on 2026-10-14 when the studio was repackaged. That took 11 tests to ERROR and 4 to failed without anyone noticing — see docs/test-repair-plan.zh.md §1 and §3 #1–#2.
The dist/ original is gone, so the files here cannot be compared against it byte for byte. They are byte-identical to the copy preserved under .scratch/result-visible/ (the source named above), which is the strongest provenance available. The hashes are recorded here so a future copy can be checked against this one instead of argued about:
| File | SHA256 |
|---|---|
raw_0001.mp4 |
907867d0fe82966dbaacf97a8bb0a8d5647de25458ad5fd4640535d83d417207 |
frames.csv |
fab25e6780908aef8f7616504b43cf34062ab7ca3ba317b6ff4c0631969e0601 |
forces.csv |
972d3c951ff0be847a6a224b53339401f115cd3728039f1acb24a33bf215ecb1 |
events.csv |
6fe7121b1c621ebed472ee42376babfd76a32a364ab9f11660da077fb365a946 |
session.json |
f3c9afc4502180d2a88cd260cb70f1f4313e203f2c3c8441704de6ac53a1db4c |
The frame ids are deliberately not 0…32: a test that used the frame index would pass on a 0-based recording, and real recordings start wherever the device's counter was.
Rules
- Do not replace it with a generated recording. The chain's behaviour on these pixels is part of what the tests defend.
- Do not write into it from a test. The tests that analyse it copy it into
tmp_pathfirst, because a pass writes its result beside the recording. - If it goes missing, restore it or the tests fail. They no longer skip on a missing input: a skip is how this went unnoticed.