LearnNewsExamplesServices
Frontmatter
id16500
titleScene-1 continuity oracle reds on a cleared workspace body
stateClosed
labels
bugaitesting
assigneesneo-opus-vega
createdAtAug 4, 2026, 2:14 PM
updatedAtAug 8, 2026, 10:43 PM
githubUrlhttps://github.com/neomjs/neo/issues/16500
authorneo-fable
commentsCount3
parentIssuenull
subIssues[]
subIssuesCompleted0
subIssuesTotal0
contentTrust
projected
quarantined0
signals[]
blockedBy[]
blocking[]
closedAtAug 8, 2026, 10:43 PM

Scene-1 continuity oracle reds on a cleared workspace body

Closed Backlog/active-chunk-12 bugaitesting
neo-fable
neo-fable commented on Aug 4, 2026, 2:14 PM

Premise refined, then RESOLVED — 2026-08-08T11:38Z. The original body attributed this to film pacing and cited spec-paced green as the contrast. That contrast does not exist (see Context), because spec-paced mode never runs the oracle. Refinement evidence from @neo-gpt-emmy, verified against source before adoption; falsifier 1 then run by @neo-fable on the staged rig, which located the defect at entry time and named the owner.

Owner: the unconditional entry projection added by 62c1a400d3 (#16473). Red-control first, same head ac1c197648, same take-19b stage, minutes apart:

arm minEntropy floor / baseline min frame
control 0.4088 floor 3.4475 7 / 59
treatment (entry geometryOnly: true) 5.3480 baseline 5.3515 no dip

minFrameIndex 7/59 is the load-bearing number. It discharges the caveat I attached to this probe — that a green might prove only that the entry projection sat inside the measured window. The dip is located at the start of the capture, not merely enclosed by it. Receipt: #16500 issuecomment-5225908387.

Context

The WorkstationFiveBeatNL scene-1 continuity test carries an entropy oracle: scene-1-run-1-resize must not present a cleared dense workspace body. In film mode (NEO_FILM_TAKE=1) that oracle went RED 2-for-2 on 2026-08-04 at dev head 2cd55fdd7d, on two different displays, minEntropy 0.41 against the required ≥ 3.48. That measurement stands.

What does not stand is the comparison I drew from it. The original body cited the test as "GREEN 5+-for-5 spec-paced at the same head" and inferred pacing-dependence. But WorkstationFiveBeatNL.spec.mjs:1012 reads continuity = filmTake ? await captureWorkspaceContinuity(page, runSpec) : nullrunSpec (the resize) executes in both modes, and filmTake gates only whether the oracle wraps it. Spec-paced mode never runs the oracle, so its green could not have failed and is not evidence about this defect. A comparison between a mode that measures and a mode that does not is not a discriminator.

A real baseline exists instead, and it is stronger. The take16 runner at head 61a8d34e6d recorded film-mode baselineEntropy 5.0156 / minEntropy 5.0147 over 63 compositor frames. So this is a regression inside 61a8d34e6d..2cd55fdd7d, not an inherent screencast artifact — which the pacing framing would never have established.

The Problem

At least one captured frame presents a workspace body that is effectively cleared (entropy 0.41 ≈ flat fill). Two things previously asserted are now open questions rather than premises:

  1. Whether the cleared frame is resize-time at all. captureWorkspaceContinuity(page, runSpec) measures the entire runTourSpec call, not the resizeSplit step. Its window therefore includes runTourSpec's entry work, which happens after dockModel is reset to initialDocument and before runner.start()/resizeSplit.
  2. What the discriminator is. Film mode also switches the viewport to null/native staging and enables video capture (:404-416). Those are live candidates; pacing is not established as one.

The Architectural Reality

  • Candidate root (#16473, not yet a verdict). Commit 62c1a400d3 (merged Aug 4, before the first red) changed runTourSpec entry from refreshDockWorkspace({geometryOnly: true}) to an unconditional refreshDockWorkspace() — verified in that diff. Scene 1 is built from the same initialDocument, so the oracle may be catching a pre-replay full shell projection and mislabeling it resize-time.
  • Why the old flag was not unsafe. DockProjectionReconciler.reconcileProjection treats geometryOnly as admission to reconcileStableTopology, validating node count/type/ancestry/order/orientation and falling back to the full staged path on any mismatch. So the old path permitted in-place reconciliation only when proven, while preserving #16467 probe correctness for changed topology.
  • The oracle and its screenshot instrument live in the spec (test/playwright/e2e/workstation/WorkstationFiveBeatNL.spec.mjs, scene 1).
  • Deterministic reproduction: NEO_E2E_PORT=<port> NEO_FILM_TAKE=1 npx playwright test workstation/WorkstationFiveBeatNL -c test/playwright/playwright.config.e2e.mjs --workers=1 --headed --grep "scene 1".

The Fix

Two repairs with different owners, and neither substitutes for the other.

The blank is real, not a measurement artifact. A compositor frame shows a cleared body; during a take the camera records it. So narrowing the oracle's window alone would turn it green while the film still contains the blank — the trap this split exists to avoid.

1. The entry seam (owner: #16473's author). geometryOnly: true was the probe, not the fix — shipping it reverts a deliberate correctness change and trades back the #16412 topology-swap hazard. Recommended shape is a narrowing rather than a revert: DockProjectionReconciler.reconcileProjection treats geometryOnly as admission to reconcileStableTopology, which validates node count/type/ancestry/order/orientation and falls back to full staging on any mismatch. So the entry can attempt the validated in-place path and stage only when topology actually changed. Scene 1 rebuilds from the same initialDocument — the proven-stable case — while changed topology keeps #16467/#16412 correctness. Both properties, no trade. The stronger alternative is present-no-intermediate-state (build off-document, commit atomically), which also removes the blank for changed-topology swaps; proportionality is the seam owner's call.

2. The instrument (owner: me). Scope the capture per step so scene-1-run-1-resize measures the resize, and add entry-beat coverage in the same change. Doing the first without the second converts a caught defect into an uncaught one: the oracle would go green on a blank that merely moved outside the window.

2a. The boundary is ±1 frame and cannot be made exact — established 2026-08-08 with @tobiu. PR #16703's first shape stamped entryCompletedAt in the App Worker after refreshDockWorkspace() resolved. That is DOM-applied, not presented (@neo-gpt's RA-1). The timing topology:

  • Main.mjs:527 schedules renderFrame via requestAnimationFrame — or setTimeout(callback, 0) when document.hidden, so frame alignment is visibility-conditional.
  • Main.mjs:581 drains the read/write queues inside that callback. It returns early on budget overrun, but that does not give the awaited operation a multi-frame tail (@neo-gpt, verified at :462-479): an overrun unshifts the operation back unapplied, and an applied operation resolves its reply immediately after DeltaUpdates.update() in the same iteration. Only the rest of the batch slips.
  • Worker messages cost 0-3ms but their send instant is not tick-aligned, so any worker-side timestamp of a DOM effect is uncertain by up to one frame.

A presentation fence cannot close this. A DomAccess.afterNextPaint() round-trip travels the same unaligned channel, inherits the identical ±1 frame error, and would add latency while appearing to guarantee ordering. Designed, then withdrawn.

The shape instead: three regions, partitioned ORDINALLY (@neo-gpt's convergence — my first form used a symmetric median-duration window and both halves of that were wrong):

entryCertain  = every frame with timestamp <  entryCompletedAt
ambiguous     = the FIRST frame with timestamp >= entryCompletedAt (plus timestamp ties)
resizeCertain = every later frame
  • The uncertainty is one-sided. entryCompletedAt is sampled immediately before runner.start(), so a frame presenting before it cannot belong to resize — program order already proves entry ownership. A symmetric band reports uncertainty where none exists.
  • Ordinal, not a derived duration. A per-run median beats a 16.7ms constant and is still wrong: a first post-boundary frame arriving 31ms after the stamp under a 16ms median would fall back into resize and recreate the defect. The partition derives from presentation order at this boundary; median and adjacent gaps stay in the receipt as diagnostics and never own correctness.
  • Tie-break toward entry, because the misattributions are not equally costly: an entry frame called "resize" is the defect being removed; a resize frame called "entry" is an investigable false red. Assert continuity over entryCertain ∪ ambiguous, resize over resizeCertain, keep the whole-window oracle, and fail closed unless both certain regions and the ambiguous frame are observed with finite timestamps — so a one-frame resize defect moved into ambiguity still reds rather than going green.
  • The model is falsifiable and the disproof is named: if the real falsifier observes more than one entry-owned presented frame after the stamp, the one-frame model is wrong and independently captured phases become the next shape.

Independent files, so the two run in parallel; the entry fix is not gated behind the instrument refactor, since it is what the film actually needs.

Newly open, and this is progress: whether a resize-time defect exists at all is unknown. The control's minimum sat at entry, so no resize-time dip was observed — but the window was too wide to have detected a smaller one. Per-step capture answers that for the first time.

Acceptance Criteria

  • The oracle's measurement window is narrowed to what its name claims, or its name is corrected to what it measures. A window spanning the entry projection cannot attribute a frame to resize.
  • The ±1 frame residual is represented, not hidden — an ambiguous band derived from observed frame cadence, resolving toward entry, with its frame count reported in the receipt. A boundary asserted as exact is a precision claim the message layer cannot support (see 2a).
  • Falsifier for the tie-break: a cleared frame placed deliberately inside the ambiguous window reds the entry band. This is the case the early-presenting mutation proof does not cover.
  • The cleared frame's owner is named with a frame + worker-truth + DOM triplet receipt.
  • Falsifier 1 is run and recorded either way — a red result is a result, and it is what routes to the later range.
  • Scene-1 film-paced runs green ×3 consecutive on the repaired head (both plain-headed and isolated-display staging).
  • The oracle is shown capable of failing in the mode used to certify it — the defect this premise refinement corrects. A green from a run that never executes the oracle is not evidence.
  • No oracle loosening: the fix is presentation truth, not threshold surgery.
  • If the boot-blank cold-start frame shares the owner, note it; otherwise leave it explicitly out of scope.

Out of Scope

  • Cold-boot first-paint blanking (cosmetic, camera-only — trimmed in film composition).
  • Conversion/re-entry defects (#16497, #16499) and the empty sibling pane (#16498).
  • Re-litigating #16467's correctness goal. If falsifier 1 implicates #16473, the repair must keep probe correctness for changed topology, not revert it.

Decision Record impact

none.

Related

#15252 (film epic) · #16473 / #16467 (candidate root) · #16402 (RO dispatch-dam precedent) · in-range seams not yet excluded: #16390 grid measurement, #16403 DockFlip geometry classification, #16426 ResizeObserver starvation delivery, #16436 DockFlip starvation completion · closed #16356 (staging-frame precedent)

Premise-refinement evidence: @neo-gpt-emmy, 2026-08-08 (cc4ab97b, 28859816); source claims verified by me before adoption.

Origin Session ID: 1913de09-6dc0-4d1e-a9a3-b51c33b46cdc

Retrieval Hint: query_raw_memories("scene-1 oracle window spans runTourSpec entry, spec-paced green never runs the oracle, take16 gold baseline")

tobiu referenced in commit ae23a5f - "The scene-1 continuity oracle measures the step it is named for (#16500) (#16703) on Aug 8, 2026, 10:43 PM
tobiu closed this issue on Aug 8, 2026, 10:43 PM