· 2026-05-19 ·v2.6.1 (Docker latest, last image push 2024-12-15) · main archived 2026-03-20

WeWe RSS

cooderl/wewe-rss

🛑

24 / 100Don't use

📝

⚛

→

⚗

→

🧬

🛑

0–29

⚠️

30–49

🛠

50–79

🏭

80–100

▼

🛑· 24 / 100

✓7 claims passed, no critical failures
✓MIT / Apache / etc., installable per deployment.install_methods
◐release_pipeline=2, recently_active=False
⚪EN-only or ZH-only README
⚪static-only eval; live e2e pending

#1👤

#2🎯

#3🧭

#4⇄


`Zeabur 一键模板 / Railway / Hugging Face Spaces`	managed (browser)	easy
`docker-compose -f docker-compose.yml up -d (MySQL)`	any (Docker)	easy
`docker-compose -f docker-compose.sqlite.yml up -d`	any (Docker)	easy
`pnpm install && pnpm run -r build && pnpm run start:server`	Node.js 20+ host	moderate

🌐

WeRead (微信读书)

Free WeChat account works; risk of being rate-limited or banned

weread.111965.xyz (maintainer-operated forward proxy)

Routes some WeRead API calls through a Cloudflare-fronted proxy run by the repo author

No SLA, no successor commitment — single point of failure for the whole project

MySQL or SQLite

Persistence — accounts, subscriptions, articles, cron state

Self-hosted; SQLite path explicitly marked 'not recommended' by author

Zeabur (optional)

Managed one-click hosting

Free tier limited; paid for sustained use

· 7

	+40
	+18
	+5
	+6
	+5
	-50

7 / 7

passed claim-001

passed claim-002

passed claim-003

passed claim-004

passed claim-006

passed claim-007

`input_contract`
`output_contract`
`determinism`
`idempotence`
`no_skill_callouts`
`failure_mode_clarity`

evidence_completeness='partial' (not portable) → capped at 'usable'

archetype: api-service→core_layer_tested? True→evidence: partial→recommended: usable→final: usable

ceiling 1 · evidence_completeness='partial' (not portable) → capped at 'usable'


claim-001	cooderl/wewe-rss + wewe-rss-sqlite Docker 镜像存在且公开	critical	shipped-artifacts	● passed
claim-002	docker-compose.yml + docker-compose.sqlite.yml 在仓库根	high	shipped-artifacts	● passed
claim-003	weread.111965.xyz 当前可达 (HTTP 200, Cloudflare)	critical	dependency-liveness	● passed
claim-004	README 列出的 RSS endpoint 三格式 + 过滤 + 手动刷新参数	high	api-surface	● passed
claim-005	LICENSE 文件存在 + GitHub API license=mit	medium	maintainer	● passed
claim-006	GitHub API 报告 archived=true	high	maintainer	● passed
claim-007	Docker `:latest` (v2.6.1, 2024-12-15) 比最后一次提交 (2026-03-20) 落后 ~15 个月	high	maintainer	● passed

0.00s

# Final Verdict

## Repo

- **Name**:
- **Version tested**:
- **Date**:
- **Archetype**:
- **Layer**: (atom | molecule | compound)
- **Score**:  /100  (from `verdict_calculator.py`, not judgement)
- **Category**:  (🏭 Production-ready / 🛠 Available / ⚠️ Risky / 🛑 Don't use)
- **Tier**: (recommend ≥90 / team ≥80 / self ≥65 / try ≥50 / risky ≥30 / broken <30)

## Plain English

Two sentences max. What does the user get if they adopt this repo today, and what would make them regret it?

- Outcome if adopted:
- Regret scenario:

## Why This Score

State the user-visible outcome first, mechanism second. Lead with what the repo *does* for the user, then the evidence.

### Top 3 score drivers

What earned or cost the most points. Reference `breakdown` from the calculator output.

- +/- :
- +/- :
- +/- :

### Core outcome
What observably works end-to-end? What observably does not?

### Scenario breadth
How many real inputs has it been tested against? Which dimensions vary (platform, data shape, scale)?

### Repeatability
Same input twice → same result? Filesystem-level or only log-level?

### Failure transparency
When it fails, do you learn something actionable, or does it swallow the error?

## What Would Move The Score Up

Concrete, testable next actions in score-impact order. Not "be better" — "add X test against Y fixture showing Z (lifts ~+N)".

1. (~+N)
2. (~+N)
3. (~+N)

## Remaining Risks

Ranked. Each risk with severity + impact + mitigation if known.

| Risk | Severity | Impact | Mitigation |
|---|---|---|---|

## Related Artifacts

- Claim map:
- Plan:
- Runs:
- Verdict calculator input:
- Rendered HTML dossier: