commit 444c0db runs 7 screens and sends only alerts
Sequoia-X V2 is a post-close stock screener for mainland China's A-share market. At commit 444c0db, main.py registers 7 strategies, including moving-average volume, turtle breakout, high-tight flag, limit-up shakeout, uptrend limit-down, relative-strength breakout, and private-placement monitoring. The README's strategy table lists only 6, leaving the private-placement screen undocumented there. Results go to Feishu; the program does not place trades.
That narrow job is the appeal. Sequoia-X pulls daily bars, keeps back-adjusted prices in a local SQLite database, applies Python strategy classes, and sends nonempty selections after the market closes. A developer can read each rule and change it without adopting a web dashboard or remote account. The tradeoff is equally plain: portfolio state, order routing, risk limits, and fill handling are outside the documented V2 workflow.
What happened when we ran it
Our run at commit 444c0db installed in 44 seconds and built in 12 seconds on 3 CPUs with 8 GB of RAM. Pytest then ran for 501 seconds. It reported 6 passed and 3 failed out of 9 tests, so the complete checked-out suite did not pass in our fresh unprivileged Debian container. Pip-audit reported 0 known vulnerabilities in the installed Python dependencies.
All 3 failures came from tests/test_feishu.py. The failing cases checked that notifications contained every symbol, used the configured URL, and logged an HTTP failure. The log repeatedly recorded a Feishu push failure with HTTP status 591 and response text error, then Hypothesis surfaced each case through FlakyFailure. The log tail does not identify the reason for status 591, so it supports no stronger conclusion about the network, mocks, or service.
The test directory is a good sign for a repository of 1,552 source lines, and 6 passing cases show that some behavior is checked. There are no GitHub Actions workflow files, however, so the repository does not display an automated test gate on pushes or pull requests. It also has no Dockerfile. Anyone adopting it should reproduce the suite in the actual scheduled host and add a notification test that cannot contact a live webhook by accident.
Python 3.10 gets the code running, not the data flowing
The README presents BaoStock as free, registration-free, and suitable for historical plus incremental daily bars. A first deployment must populate the local database before the daily job has enough history for its screens. Later runs update the snapshot, run each strategy, and notify only when a strategy returns symbols. That makes the SQLite file operational state: back it up, watch its growth, and make the cron working directory explicit.
Data retrieval deserves its own acceptance check. Open issue 107, created on June 17, had 3 follow-up reports through August 28 from users unable to retrieve data or seeing blacklist-style errors. The thread contains no demonstrated fix. That does not prove BaoStock fails for everyone. It does mean a successful package install should not be confused with a successful backfill from the network and a complete daily update.
Eight webhook slots make Feishu configuration easy to misread
The README tells users to copy .env.example and fill in a Feishu webhook. The example at commit 444c0db includes 8 URL variables, and uncommented placeholder values for every route can be read as configured destinations. Open issue 92 records users with working bot links who still saw push failures; commenters suggested keeping only the fallback or commenting out the strategy-specific placeholders. The issue remains open, so treat those comments as field reports rather than official resolution.
There is another small mismatch in the same commit. The README says the data layer uses BaoStock and describes the move away from Eastmoney scraping, while pyproject.toml declares both baostock>=0.9 and akshare>=1.10. The repository history includes cleanup work around the data source, but the dependency declaration still pulls AkShare into the environment we measured. That costs disk and makes the intended boundary less clear than the README suggests.
July code activity and 22 open items show a live maintenance queue
GitHub reported the last push on July 10, 2026, and listed 22 open issues and pull requests on September 2. User activity continued after that push: issue 114 was opened on August 30 about receiving too many recommendations. The latest-release API returned no release, while the tag list contains v1.0-legacy. Sparse release packaging alone does not make the code abandoned; recent issues show people are still running it.
GitHub also showed 5,950 stars, which explains why a compact Chinese-market script draws support questions from users with different Python and network setups. The current queue includes dependency updates, a proposed web dashboard, data-service reports, and notification trouble. For a hobbyist, that is enough activity to make a fork practical. For a team promising daily delivery, 3 failed tests and two unresolved service-boundary threads call for local ownership of the schedule and alerts.
A 256 MB screener is useful when you want code, not a trading desk
Sequoia-X fits a technically capable A-share watcher who wants readable rules, local data, and Feishu output. Qlib is a better match for model research and backtesting, while vn.py covers broker-facing trading infrastructure. AkShare gives a builder broader Chinese financial data without prescribing these screens. Sequoia-X occupies the smaller space between them: 7 editable selectors and a cron-friendly entry point, with the operator responsible for data continuity and delivery checks.
Our 501-second test run is the deciding warning. The codebase is approachable, the 44-second install passed, and the audit found no known dependency vulnerabilities. Yet the exact notification path that turns a screen into a useful alert produced all 3 failures. Trial it with paper decisions, compare its database against an independent source, and require a confirmed Feishu message before trusting the next scheduled run.