fix(build): primitive-compliance-trace's gapsAfter silently fell back to gapsBefore (#786) - #790
Merged
Conversation
… to gapsBefore (#786) Found live while verifying #774/#785's Stripe primitive didn't regress ZeroCommerce: a real, genuinely fully-compliant generation (confirmed by reading the actual saved code -- it called every one of ZeroCommerce/ ZeroPipeline/ZeroVoice/Content Workflow/ZeroMemory) showed a trace with closed:true alongside gapsAfter listing all 5 primitives as still open -- self-contradictory, for the exact endpoint built specifically so live verification doesn't require guessing (#624). Root cause: closePrimitiveComplianceGap's `gapsAfter` was only ever assigned INSIDE the retry loop body, on a candidate that passed validation. The post-loop fallback return computes `closed` from a fresh `final` check but never touched `gapsAfter`, so finish()'s own `gapsAfter.length ? gapsAfter : gapsBefore` substitution silently used the stale pre-retry gap list for display. Fixed by always deriving gapsAfter from the SAME fresh compliance check `closed` is computed from, immediately before every finish() call -- removed the stale gapsBefore fallback entirely since gapsAfter is now always set fresh beforehand. Verified the fix is real (not a tautology): temporarily reverted just the route change and confirmed the new test genuinely fails against the old code, then restored the fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #786.
Found live while verifying #774/#785's Stripe primitive didn't regress ZeroCommerce: a real, genuinely fully-compliant generation (confirmed by reading the actual saved code) showed a trace with
closed:truealongsidegapsAfterlisting all 5 primitives as still open — self-contradictory, for the exact endpoint built specifically so live verification doesn't require guessing (#624).Root cause:
closePrimitiveComplianceGap'sgapsAfterwas only ever assigned inside the retry loop body. The post-loop fallback return computesclosedfrom a freshfinalcheck but never touchedgapsAfter, sofinish()'s owngapsAfter.length ? gapsAfter : gapsBeforesubstitution silently used the stale pre-retry gap list.Fix: always derive
gapsAfterfrom the SAME fresh compliance checkclosedis computed from, immediately before everyfinish()call — removed the stalegapsBeforefallback entirely sincegapsAfteris now always set fresh beforehand.Test plan
npx tsc --noEmit— cleannpx vitest run— full suite: 397 files, 5620 tests passed, 0 failuresgapsAfterassignment before the fallbackfinish()call, stale fallback removed)