Skip to content

refactor(qt): author the price-limit gate description once - #78

Merged
StackOverFlow11 merged 2 commits into
mainfrom
fix/limit-basis-single-source
Jul 21, 2026
Merged

refactor(qt): author the price-limit gate description once#78
StackOverFlow11 merged 2 commits into
mainfrom
fix/limit-basis-single-source

Conversation

@StackOverFlow11

Copy link
Copy Markdown
Owner

Why

Follow-up to #76, and it exists because that PR's own claim did not hold.

#76 added a regex guard and its commit message said it meant "an (N+1)th copy fails rather than ships." Review tested that claim by writing seven plausible rewordings of the same wrong statement and running them against the actual regex — all seven escape:

ESCAPES: "comparing the execution minute's last print to the raw stk_limit band"
ESCAPES: "the raw close of the selected 1-minute bar is compared against the limit"
ESCAPES: "blocks a buy once the bar's closing print reaches the raw upper limit"
ESCAPES: "the gate reads that bar's final tick, not its VWAP, against stk_limit"
ESCAPES: "a buy is blocked once the selected minute's last trade sits at the raw upper limit"
ESCAPES: "comparing the execution-minute's closing tick to the raw stk_limit band"
ESCAPES: "raw close vs the symbol/date raw stk_limit band"

None are exotic — they are what a person editing this prose by hand would write. This is the general fate of a lexical guard aimed at a semantic claim.

A regex cannot assert "no other sentence makes this claim". Having no other sentence can.

What changed

limit_basis_phrase() is the single authored statement of what the gate compares. Three sites now compose it instead of each writing their own sentence:

site before after
limit_basis_lines() (feasibility section) its own sentence composes the phrase
_write_report() Limitations bullet its own sentence (the one #76's first pass missed) composes the phrase
intraday_group_report._feasibility_lines() its own sentence composes the phrase
_load_price_limits() docstring restated the comparison points at limit_basis_phrase

No output text changes — the rendered reports are byte-identical. This is purely about how many places can independently go wrong.

The regex guard is kept, with its docstring scope corrected to what it genuinely does: catch a literal revert via a bad merge or rebase, which is precisely the failure that actually occurred. The overstatement is removed.

Mutation evidence — using review's own escaping wordings

mutation regex guard structural test
Limitations bullet re-authored as "the execution minute's final tick" PASSES (as review predicted) FAILSthe Limitations bullet must COMPOSE limit_basis_phrase, not restate the comparison in its own words
group report re-authored as "the selected bar's last print" FAILS

That is the whole point of the PR demonstrated end to end: the wordings that defeat the lexical guard are caught by the structural one.

Gates

pytest 1741 passed · ruff clean · phase0 ic_mean=0.9600, annual_return=0.8408 · secret scan 0

Follow-up to #76, prompted by its review. That PR added a regex guard and its
commit message claimed the guard means "an (N+1)th copy fails rather than ships".
Review disproved the claim: seven plausible rewordings of the same wrong
statement -- "its last print", "the final tick", "1-minute" instead of "1min" --
all escape the regex. That is the general fate of a lexical guard aimed at a
semantic claim; English has too many ways to say the same false thing.

A regex cannot assert "no other sentence makes this claim". Having no other
sentence can.

limit_basis_phrase() is now the single authored statement of what the gate
compares. The feasibility section, the group report, and the report's Limitations
bullet all COMPOSE it. _load_price_limits's docstring points at it instead of
restating it, because a second statement of a fact is a second thing to get
wrong. No output text changes: the rendered reports are identical.

The regex guard stays, with its scope corrected in the docstring to what it
actually does -- catch a literal revert, which is the failure that really
happened via the missed Limitations bullet. The new structural test covers what
the regex cannot.

Mutation evidence, using review's own escaping wordings:
  Limitations bullet re-authored as "the execution minute's final tick"
    -> regex guard PASSES (as review predicted)
    -> structural test FAILS: "the Limitations bullet must COMPOSE
       limit_basis_phrase, not restate the comparison in its own words"
  group report re-authored as "the selected bar's last print"
    -> structural test FAILS

pytest 1741 passed (1736 + 5 from the merged branches + this file's addition),
ruff clean, phase0 ic_mean=0.9600 / annual_return=0.8408.
StackOverFlow11 added a commit that referenced this pull request Jul 21, 2026
… rebasis PR number (#79)

Both follow-ups now have real numbers, read from gh pr list rather than assumed:
#78 is fix/limit-basis-single-source and #79 is feat/exec-to-exec-rebasis, both
OPEN. The rebasis entry no longer says "PR not yet open".

- New entry for #78: #76's regex guard claimed no further copy of the wrong
  gate description could ship, and review disproved it by running seven
  plausible rewordings through the actual regex — all seven escape. The fix is
  structural: limit_basis_phrase() is the one authored sentence and three sites
  compose it; rendered text is unchanged; the regex stays with its scope
  corrected to catching a literal revert.
- Sharpened the second defect-class rule accordingly: the rule is not "assert no
  (N+1)th copy exists" — that is precisely what the regex failed to do — it is
  author the claim once and have every other site compose it. A regex cannot
  assert that no other sentence makes a claim; having no other sentence can.
- #79 entry gains its number, the reason for the rebasis (a minute factor is
  fixed at 14:50 and the only modellable fill is the 14:51 bar, so close-to-close
  credits a closing auction this project cannot simulate), the two coverage
  denominators kept apart as the PR keeps them, and the correctness acceptance.

Sources: gh pr view 78, gh pr view 79, RESULTS_post_pr75_2026-07-21.md.
StackOverFlow11 added a commit that referenced this pull request Jul 21, 2026
docs: record PR #62-#77 and the two open follow-ups (#78, #79)
The refactor claimed rendered output was byte-identical. A rendering probe --
building the same lines on main and on this branch and comparing the strings --
showed it was not: two of the three hosts dropped the CLOSING em-dash, leaving

  ...on the `bar_vwap` basis to the raw `stk_limit` band

with an unmatched dash. Review had asked exactly this question ("a fragment that
reads well in one context may be ungrammatical in another") before the probe was
run; the answer was that it had already happened.

Both hosts restored. Verified by re-running the probe: all composed lines are now
string-identical to main's.

That is the cost side of composing one fragment into several sentences -- it
trades three ways to state the fact wrong for one way to punctuate it wrong. A
test now pins it: wherever the phrase is embedded mid-sentence, the em-dash that
opens its appositive must be matched after it.

pytest 1742 passed, ruff clean, phase0 ic_mean=0.9600 / annual_return=0.8408.
@StackOverFlow11

Copy link
Copy Markdown
Owner Author

Correction: the "byte-identical output" claim was false when this PR was opened

The PR body says "Rendered report text is byte-identical." It was not. Verified after the fact with a rendering probe — building the same lines on main and on this branch and comparing the strings:

basis_lines      identical=True
group_lines      identical=False

MAIN  : ...on the `bar_vwap` basis — to the raw `stk_limit` band (RAW-vs-RAW; ...
BRANCH: ...on the `bar_vwap` basis to the raw `stk_limit` band (RAW-vs-RAW; ...

Two of the three hosts dropped the closing em-dash, leaving the appositive inside the phrase unmatched. Ungrammatical, and a real (if small) output change shipped under a claim that there was none.

Review had asked precisely this before the probe ran — "a fragment that reads well in one context may be ungrammatical in another" — and the answer turned out to be that it had already happened.

Fixed in 5b4d1ec. Re-running the probe:

basis_lines      identical=True
group_lines      identical=True

So the claim now holds; it did not before. A test pins the invariant: wherever the phrase is embedded mid-sentence, the em-dash that opens its appositive must be matched after it.

This is the cost side of the refactor and worth stating plainly rather than quietly fixing — composing one fragment into several sentences trades three ways to state the fact wrong for one way to punctuate it wrong. That is still the better trade, but it is a trade.

Gates after the fix: pytest 1742 passed · ruff clean · phase0 ic_mean=0.9600, annual_return=0.8408.

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