Fix CPR AI true-up coordination and MCP retries - #122
Merged
Conversation
Co-authored-by: Codex <codex@openai.com>
DoRmAmMu1997
marked this pull request as ready for review
August 12, 2026 05:27
Source: Intraday Hunter live session, 12 Aug 2026 (CV_Fs3TFF5I, 6:46). A WIN taken from the SAME opening condition that produced the 11 Aug loss, which is what makes it worth encoding. Both days opened flat, sold off immediately, and had IH saying nobody was positioned -- "neither many buyers nor many sellers". On 11 Aug he predicted who would arrive and lost. On 12 Aug he waited for the market to show him and won. So v4e's rule needed reconciling rather than repeating. An empty book is not simply a no-trade condition: it is a statement that the market MUST manufacture a trap, because it has nothing else to work with. What it does not tell you is which side the trap points at. The rule is now: form the hypothesis, but wait for CONFIRMATION IN PRICE before acting. Knowledge changes (all prose): - OPENING_DRIVE: THE CHART DOES NOT REPEAT TWO DAYS RUNNING -- a shape everyone watched yesterday is one everyone is ready for today, so a second-day carbon copy argues for a reversal rather than the continuation; A MOVE THAT DENIED YOU ENTRY WAS NOT YOUR MOVE (v4d's gap logic at intraday scale -- "everything happened in ONE MINUTE"); AN EMPTY BOOK MEANS A TRAP IS COMING, WAIT FOR IT TO REVEAL ITS DIRECTION; THE SHARPEST RECOVERY NAMES THE LEADING INDEX, AND SIZE FOLLOWS IT. - RISK: BOOK WHEN THE PROFIT STOPS GROWING, NOT WHEN IT REVERSES -- the trigger is the rate of accrual, not a price level and not a loss. Three test markers. The important one is test_v4f_confirmation_rule_does_not_reopen_the_v4e_forecasting_hole: v4e and v4f are a matched pair, and v4f read alone would license exactly the forecast v4e forbids, so it asserts the confirmation requirement and v4e's HOLD survive together. Prompt 101,087 -> 105,933 chars (headroom 14,067). The doc addendum also records how our agent traded the same tape. It took ONE trade, on the wrong side: SHORT at 10:30 on double_top_shooting_star_reversal, one minute after IH went long on the recovery, cut at 10:31 by the v3y index-hierarchy rule. The hierarchy rule worked; the entry was the error, and it is exactly what v4f is meant to prevent -- repeated chart, a move that denied entry, and an empty book all argued against selling that drop. ADR-0012 gains the measured outcome of the durable/marks split, since today is the first session running it: total slow-write warnings fell from 281 to 22, and the supervisor path from 254 to 7 against a threshold eight times looser. Recorded with both caveats -- the 12 Aug figures are a partial session, and the worst marks write was 10.065s with no fsync at all, so the disk contention is real and the split only moved those seconds off the trading path. Session P&L is provisional (runner live at 14:15): +13,519.25 across 39 legs, SL Hunting -1,034.25 cross-checked against its own Result summary. Gates: SL Hunting + Dependencies pytest 875 passed, master 513 OK, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dhanhq utcfromtimestamp DeprecationWarning kept appearing despite
the master file installing a scoped ignore at import time. Reproduced,
and the filter itself was never the problem -- in a plain process it
suppresses the warning correctly.
The source is PYTEST. It wraps every test in catch_warnings() +
simplefilter("always"), which RESETS warnings.filters and discards
anything a module installed at import time; only its own -W /
[tool.pytest.ini_options] filterwarnings entries are re-applied inside
that context. The repo had no [tool.pytest.ini_options] section at all,
so nothing was re-applied and the warning surfaced in every run while
the runner's own console stayed silent -- the runner log contains zero
occurrences of it, which is what made this confusing.
Fixes:
- pyproject.toml gains [tool.pytest.ini_options] filterwarnings with the
same narrow ignore. NOTE the format differs from the Python API: in
-W/ini strings warnings._setoption re.escapes the message and module
fields, so they are LITERALS, not regexes -- which is why the two
dhanhq modules need one line each instead of an alternation. There is
deliberately no leading "default"/"error" entry, so every other
warning behaves exactly as before (verified: the dateutil
utcfromtimestamp warning is still surfaced by the suite).
- the master file's filter now covers dhanhq.fulldepth as well as
dhanhq.marketfeed. dhanhq/__init__ imports both and each ships the
same utc_time helper (marketfeed.py:523, fulldepth.py:391). The runner
only subscribes MarketFeed so the second site should never fire; it is
one regex branch and removes a latent surprise.
- the comment claiming the import-time filter "wins over any blanket -W
/ PYTHONWARNINGS setting because filterwarnings PREPENDS" was wrong
and is corrected: importing dhanhq alone pushes our entry to index 1,
because urllib3 prepends its own. It now documents the pytest caveat
instead.
Why the existing test did not catch this: it re-installs the filter by
hand inside simplefilter("always") -- exactly the step pytest does NOT
do for us -- so it proved the filter works while the bug was live. The
new TestPytestReappliesTheDhanhqWarningFilter asserts the ini entries
exist AND feeds the committed strings through warnings._setoption before
triggering the warning, so a plausible-looking entry that matches
nothing fails. Mutation-checked: breaking the module name in pyproject
fails both new tests.
Gates: master 516 OK, market-data-health 26 OK, pytest 1147 passed with
the dhanhq warning gone and only the unrelated dateutil one remaining,
ruff/mypy/compileall clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ideo
Source: Intraday Hunter, "Prediction For 13 AUG 2026" (PfthlsdW2E8,
uploaded 2026-08-12, 2:13).
The seated crowd has FLIPPED to buyers. Yesterday's note described a
spent seller crowd and thin positioning on both sides; today the sellers
are spent for a specific observable reason -- "the market took support
EXACTLY at the round number and gave a positive momentum, so those
sitting short would have been chased out on the retracement" -- and
BankNIFTY, positive from the open, is where the buyers actually sit.
Plan: SELL-side on flat-to-gap-down (targeting those buyers), BUY-side
and go WITH the market on a gap-up above the round number.
The reason that conditional is not symmetric guesswork is the most
transferable part of the note, and a sharper statement of the
round-number idea than the series has carried: "buyers' SLs should be
BELOW the round number. If the market is above the round number, the
buyers are not going to give their SLs." A gap-down puts price INTO the
stop zone and makes the crowd huntable; a gap-up above the round number
puts price away from it, leaves nothing to hunt, and following beats
fading. That pairs with v4c's ROUND NUMBERS AMPLIFY RECRUITMENT, and
contrasts with v4f's empty-book rule -- here the book is not empty, so
the read is geometry rather than waiting for confirmation.
Sensex has expiry tomorrow, flagged explicitly. NIFTY is recorded as the
weakest of the three reads ("selling was seen but some recovery is also
visible") rather than given BankNIFTY's confidence.
Two transcription caveats. NIFTY's resistance pair arrived as "246 and
24500", read as 24600/24500 -- the dropped-trailing-zero artefact seen on
4, 7, 10 and 12 Aug. NIFTY's SECOND support arrived as "2476" and could
not be resolved to a plausible level, so it is OMITTED rather than
guessed; the test asserts NIFTY carries exactly one support so a later
tidy-up cannot invent the missing one. A missing advisory level is safer
than a wrong one.
test_shipped_note_matches_august_13_intraday_hunter_plan replaces the
12 Aug equivalent and asserts both branch directions plus the
round-number stop-location reasoning, because an inverted plan and a
smoothed-away justification are the two failures a copy-forward causes.
Gates: SL Hunting pytest 176 passed, ruff clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
Root cause
The websocket snapshot could expose a provisional five-minute candle before the minute-close REST true-up. Codex inference then ran against that provisional snapshot, and the official true-up changed its signature before validation completed, producing
stale_bar_signature.Separately, an occasional Codex turn returned before completing all four required frozen MCP tools. The host correctly rejected that response, but it had no bounded recovery path, producing
missing_tool_callorfailed_tool_calloutcomes.Safety behavior
Verification
HOLD validation=accepted_hold NO ORDERCo-authored by Codex.