Hold a Stream open and assert a Capture keeps arriving — the dullest test neither suite has

[liversedge]

From PinPointStudio's preview handover, 28 August 2026, §5 — the two things from the preview investigation that generalise, raised for the joint review and for both conformance suites.

1. A library-issued ack is not an application ack

libppcp answers a consumer's stream_open on its own authority, before the embedding's code runs: peer_on_stream_open calls peer_stream_add and acks opened. So on 27–28 August, PinPointStudio's log read opened=1, refused=0 — from a peer that had just refused to produce anything on that Stream, because the application's own openStream was a duplicate the engine rejected under 5.1a.

⛔ Any conformance claim resting on "the peer said opened" is weaker than it looks, at both ends. It says the library parsed a frame. It says nothing about whether an application did anything.

2. Clause-by-clause spec review cannot find any of this

Nine defects across three repositories. Not one of them violates a clause. They are wrong counts, wrong sizes, wrong ordering, and swallowed errors:

An assignment after a throw	not a clause
A 35 kB payload against a 32 kB chunk	not a clause
An openChannel that could only ever fail	not a clause
A duplicate stream_open	not a clause
A shed reaching back before opened_at	not a clause
One preview slot for two Sources	not a clause
A transfer table that never reclaims	not a clause

⚠ Every one was found by running the thing and reading a device console — about ninety seconds, and it should have been the first thing anyone did. The same shape as #98 and #103, both of which a hardware run found and no review had.

What to add, and it is deliberately dull

Hold a continuous Stream open and assert a Capture actually arrives, and keeps arriving.

• Ours: a device-side conformance row that opens a Stream, runs it for a fixed interval, and asserts the count of Captures announced present is what the rate says it should be — not zero, and not one.
• Theirs: the receiving half, asserting frames assembled and not merely chunks accepted.
• ⚠ Nothing anywhere does this today. docs/conformance/ppcp-conform.md and its libppcp counterpart check message shape and clause behaviour; neither holds a stream open and counts.

Both learnings belong in the joint review's ppcp-learnings.md — ⚠ which exists in neither this tree nor libppcp's, so where it lives is part of this item.

Exit criterion

A conformance row in this repository that fails if PreviewProducer stops producing, agreed with PinPointStudio so their suite carries its twin, and the two learnings written down somewhere both teams read.

[liversedge]

Still nothing, checked 31 August — and the case for it got stronger twice

$ grep -n "e33\|preview\|hold" docs/conformance/ppcp-conform.md
(no matches)

No conformance row holds a Stream open and counts. ppcp-learnings.md exists in neither tree.

⚠ What has been added is the unit-level half, not this. 40a6b68 added three preview tests, each verified to fail against the pre-fix code — a segment is produced; a frame larger than one chunk is delivered whole; preview keeps producing past four transfer-table-fulls. That last one is the closest thing in the tree to what this issue asks for, and it is still an in-process test against a fake, not a device-side row against a real host.

Two things since that sharpen the ask

⛔ 8e8f947 tripled the preview rate to 30 fps without any test that would notice preview stopping. The three tests above assert production; none asserts a rate. This issue's exact words — "asserts the count of Captures announced present is what the rate says it should be — not zero, and not one" — are now the only thing that would catch a producer that degrades rather than dies.

⛔ 03a25a6 is a third instance of learning 2. MSG 4.3b's reconnect ordering was tested nowhere, so a refactor resuming the queue before the sync burst would have been green — and the symptom would be shots landing on a relation that drifted through the outage. Not a clause violation. A wrong ordering, found by writing the dull test. ⚠ And the first version of that test was worthless — it enqueued a payload smaller than one chunk, so the job finished on the first pump and passed against a deliberately reordered resume. A test that has never failed proves nothing, which belongs in ppcp-learnings.md beside the other two.

Exit criterion unchanged, and it needs PinPointStudio for the receiving half.