DeltaCapture: record windowId on applyDeltas-tap records

Context

Surfaced as a named non-blocking follow-up in the PR #13014 Cycle-1 review (the #12991 capture facade, APPROVED). The applyDeltas tap's wrapper receives (windowId, deltas, ...args) and forwards them faithfully — but the captured record stores only {deltas, epoch, layer, tap}. The window dimension is dropped at record time. Notably this is a gap in the originating ticket's facade spec (same author as this ticket), not implementer drift — the review's V-B-A caught it against the epic's own partition model.

Release classification: post-release (test-substrate enhancement; non-blocking follow-up from an Approved review).

The Problem

Multi-window and teleportation forensics capture through one tap. Without windowId on the record, batches from different windows interleave indistinguishably — the same blindness the hand-rolled patterns had for epochs, one dimension over. The parent epic established {windowId, idSort, id} as the delta-stream partition model precisely because teleportation legitimately reuses ids across windows: two same-id batches from different windows are NOT the same node, and a capture consumer (e.g. the future operation-signature helpers) cannot tell them apart from the current record shape.

The Architectural Reality

• test/playwright/util/DeltaCapture.mjs — the applyDeltas tap config wraps Neo.applyDeltas(windowId, deltas, ...) (seam: src/worker/App.mjs:119-125); windowId is in scope inside wrap() but not passed to capture.record(deltas).
• The helperReturn tap (VdomHelper.update() return) has no window dimension at its seam — the field is tap-dependent, not universal.
• Record shape is consumed by recordsIn/deltasIn/opsIn/findingsIn; an additive optional field is backward-compatible with all of them.

The Fix

1. record(deltas) → record(deltas, meta = {}); the applyDeltas wrap passes {windowId}. Record gains windowId: meta.windowId ?? null (helperReturn records carry null — the seam has no window context, and null states that explicitly rather than omitting the key per-tap).
2. Optional convenience: recordsIn(label) stays unchanged; window filtering composes via plain .filter(r => r.windowId === id) — no new accessor unless a consumer proves the need (avoid speculative API surface).
3. Spec: extend the existing applyDeltas capture test to assert windowId on records; one multi-window-interleave fixture (two windowIds through one tap, attribution asserted).

Contract Ledger Matrix

Decision Record impact: none.

Acceptance Criteria

• applyDeltas-tap records carry the seam's windowId; helperReturn records carry explicit null.
• Multi-window interleave fixture: two windowIds through one tap, per-window attribution asserted via plain record filtering.
• All existing DeltaCapture spec assertions pass unchanged (additive-only record shape).

Out of Scope

• New window-scoped accessor API (compose via .filter; add only on proven consumer need).
• Any change to the tapped seams' behavior.
• The OQ2 signature helpers themselves (they consume this, separately).

Avoided Traps

• Per-tap key omission (record shape varying by tap) — explicit null keeps the record shape uniform and greppable.
• Speculative accessor surface — the epoch accessors earned their place via four legacy patterns; window filtering has no equivalent precedent yet.

Related

Parent: Epic #12986 (capture leaf follow-up). Source review: PR #13014 (depth-floor challenge 2). Facade ticket: #12991. Partition-model sibling: #13011 / PR #13016.

Live latest-open sweep: checked latest 20 open issues at 2026-06-12T20:50Z; no equivalent found. A2A in-flight sweep: clean (latest 15 messages scanned; no overlapping claim).

Origin Session ID: e7e5274c-6486-45ec-9c5d-0933ca3f123a

Retrieval Hint: "DeltaCapture windowId applyDeltas tap record multi-window attribution"