Skip to content

fix(lep): withhold D16 when the spectral certificate is unresolved - #131

Closed
marcohost33-maker wants to merge 2 commits into
mainfrom
chatgpt/pr121-round23-evidence-hardening
Closed

fix(lep): withhold D16 when the spectral certificate is unresolved#131
marcohost33-maker wants to merge 2 commits into
mainfrom
chatgpt/pr121-round23-evidence-hardening

Conversation

@marcohost33-maker

Copy link
Copy Markdown
Owner

Scope

Stacked review-hardening slice on top of PR #121 (base=pr107-fix). This addresses one residual round-23 evidence leak without mixing in the separate TP-norm arithmetic issue tracked as #130.

Defect

The spectral layer deliberately withholds D1 as NaN when the zero-mode certificate is applicable but unresolved. The LEP layer nevertheless reused the same candidate eigenvalues and published a finite D16 proximity/candidate count. That made one consumer treat an unresolved spectrum as measurable while its sibling diagnostics correctly abstained.

Fix

compute_lep_layer() now distinguishes:

  • finite gap, including measured 0.0 -> ordinary D16 computation remains unchanged;
  • non-finite gap / unavailable spectral certificate -> D16 is withheld as NaN, candidate count 0;
  • D18 remains measured because it does not consume the candidate eigenspectrum;
  • D17 retains its existing non-comparable inf semantics for unavailable/non-positive gap.

The low-level lep_proximity() contract is unchanged.

Regression tests

New tests/test_pr121_review_round23.py pins:

  1. unresolved spectrum -> D16 unavailable;
  2. finite-gap positive control -> D16 still computed;
  3. measured gapless 0.0 is not confused with unavailable NaN.

Separate confirmed residue

Issue #130 tracks the independent underflow/overflow weakness in trace_preservation_defect() norms. The correct repair is a scaled xLASSQ-style norm, not a tolerance adjustment.

Promotion boundary

Keep Draft until exact-head CI actually executes. Do not infer a code verdict from workflow conclusion alone: GitHub Actions evidence must include materialized job/step execution.

@marcohost33-maker

Copy link
Copy Markdown
Owner Author

Status 2026-09-07 — the Draft condition in this PR's own body is not met, and cannot be met on this base

This PR's body states the gate itself: "Keep Draft until exact-head CI actually executes." Measured today, it has not executed — not partially, at all:

head 9ed64819 -> check-runs: 0

Zero. Not "green rollup with gaps", not "matrix pending" — no check has ever been created for this SHA. Cause, from .github/workflows/ci.yml:

on:
  push:         { branches: [main, "claude/**"] }
  pull_request: { branches: [main] }

The head is chatgpt/pr121-round23-evidence-hardening — not claude/**, so the push trigger misses it — and the base is pr107-fix, not main, so the pull_request trigger misses it too. It falls through both raster. The Draft condition is therefore not merely unmet; it is unreachable while this PR targets pr107-fix. That is structural and shared with #134, #136, #139, #143, #145, #147.

Two further facts about this head

It conflicts. mergeStateStatus = DIRTY, mergeable = CONFLICTING against its own base.

It is the most stale head in the stack. Measured with git rev-list --left-right --count against pr107-fix@bac5fe0d (the head of #121):

              missing from this PR   unique to this PR
#131                    19                    2
#134 / #136 / #143 / #145  13                 2 / 16 / 4 / 1
#139 / #147 / #149         11                18 / 23 / 18

Nineteen #121 commits are absent here, including the round-24 to round-27 evidence work this branch is named after. Not one open PR in this repository contains the current pr107-fix head — five of them declare it as their base while forking 13 or 19 commits back.

What Marco has to decide

  1. Do not read the absence of red as green. There is no rollup here to be optimistic about. Any statement that this branch passes is currently unsupported by any measurement, on any runner.
  2. Rebase onto the current pr107-fix before anything else. At 19 commits behind and conflicting, a CI result on 9ed64819 would describe a tree nobody intends to merge.
  3. Then solve the trigger, or the rebase produces another zero. Either retarget to main once the stack lands, or extend ci.yml to cover chatgpt/** and non-main bases — one change that closes the same hole for six PRs.

Staying Draft is the correct state and I have not changed it.

Read-only measurement: gh api .../check-runs, git rev-list, workflow file at bac5fe0d. No push, no re-run, no workflow_dispatch, no Draft flip, nothing resolved.

Copy link
Copy Markdown
Owner Author

Closing as superseded/integrated, not as rejected. The substantive round-23 D16 fix from this stacked draft is already present in merged PR #121: compute_lep_layer carries the spectral-resolution verdict, withholds D16 when the zero-mode certificate is applicable-but-unresolved, and the merged round-23 regression coverage pins that behavior. PR #121 is merged to main (merge commit 9dd0290b7f7c4a8199e4212a3e79796a076ef1f7). Keeping #131 open would therefore preserve a stale, conflicting duplicate branch whose own exact-head CI condition was unreachable on the old base. No scientific/result claim is added by this closure; it is backlog deduplication against the merged implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant