chore: bump to 0.5.6 for the discovery liquidity probe - #189
Merged
Conversation
`assets discover --probe-liquidity` and `screen.median_daily_quote_volume` are on main but not in any release, so the deployment (0.5.5) cannot run them. The scout skill now makes the probe the first step of every sweep, which fails against 0.5.5 -- this closes that gap. Co-Authored-By: Claude Opus 5 (1M context) <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
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.
Bumps
pyproject.tomland all four workspace members 0.5.5 → 0.5.6, plusuv.lock. Same shape as #184.Why now
assets discover --probe-liquidityandscreen.median_daily_quote_volumelanded on main in #188 but are in no release, so the deployment — runningkeel 0.5.5+7b02bfd8fbbc [release]— cannot run them. Thekeel-asset-scoutskill has been updated to make the probe the first step of every sweep, which fails outright against 0.5.5. This closes that gap.What 0.5.6 contains
The discovery pre-filter now measures what the admission gate measures.
assets discoverfiltered on the venue's reported 24h quote volume whileassets screenadmits on the median ofvolume × closeover cached history — same units, different statistics, and the gap changes outcomes in both directions:screen.median_daily_quote_volumeis now the single definition of the statistic (cli._market_factshad it inline; a second copy next todiscoverwould drift, and that drift is the bug).--probe-liquiditysamples 180 days of daily candles per candidate — one extra request, same cost model as--probe-history— and marksLOW/okagainst the same floorscreen_assetapplies.Against the live venue it catches BICO (36,137) plus two the old filter passed straight through: IMU (71,713) and GWEI (440,864). Three of the top fourteen by 24h volume are sub-floor on the real criterion.
It is an estimator, not a verdict, and the output says so: 180 days recent vs the screen's full cached history. ZEC probes 33.1M against a full-history median of 1.23M — a 27× spread from a recent surge.
okmeans "worth pulling candles for", never "will be admitted". A recent window also makes a falseLOWunlikely for a currently-active asset, which is the safe direction for a pre-filter.No behaviour change to the gate itself — same criterion, same floor, same verdicts.
Verification
2137 passed,ruffclean,mypyclean across 203 source fileskeel --version→0.5.6+9dcccadb6939on this branchNote on #188
#188 squash-merged the code change together with the
docs/experimentsharness, so its title and body describe only the research work. Its body is whatscripts/release_notes.pywill inline for 0.5.6, so it has been edited to describe the code change that actually shipped in it.🤖 Generated with Claude Code