feat: config-driven architecture + RSS feed + notifications

[howardpen9]

Summary

• Config-driven architecture: Extract all hardcoded repo lists (CLI_REPOS, OPENCLAW, OPENCLAW_PEERS) into config/sources.yaml. Adding/removing tracked repos now only requires editing YAML — no TypeScript changes needed.
• RSS/Atom feed: New src/rss.ts generates feed.xml on every run, enabling RSS reader subscriptions.
• Notification support: New src/notify.ts dispatches digest summaries to Slack, Discord, and Telegram via webhooks (opt-in via env vars).
• MCP ecosystem tracking: Added a new group tracking 6 MCP repos (spec, TypeScript/Python SDKs, official servers, GitHub MCP, Context7).
• Generalized pipeline: src/index.ts refactored to iterate over N config-defined groups instead of hardcoded CLI vs OpenClaw logic. Each group independently runs fetch → summarize → compare → save.
• Enriched manifest: manifest.json now includes label and emoji per report (read from config), enabling richer Web UI navigation.

New files

File	Purpose
config/sources.yaml	All tracking sources, LLM settings, notification channels
src/config.ts	YAML config loader with validation + env var overrides
src/rss.ts	Atom feed generator (zero dependencies)
src/notify.ts	Slack/Discord/Telegram webhook dispatcher (zero dependencies)

Changed files

File	Change
src/index.ts	Refactored from hardcoded repos to config-driven groups
src/generate-manifest.ts	Reads report metadata from config
.github/workflows/daily-digest.yml	Added notification env vars + feed.xml to git add
package.json	Added yaml runtime dependency

New runtime dependency

• yaml (zero-dependency YAML parser, ~50KB) — the only addition

Backward compatible

• All original reports (ai-cli.md, ai-agents.md, ai-web.md, ai-trending.md) are still generated
• All original prompts in prompts.ts are preserved and reused
• Existing web-state.json format is unchanged
• LLM defaults to claude-sonnet-4-6 if no config override

Test plan

• pnpm typecheck passes
• pnpm lint passes
• pnpm start generates all expected reports
• feed.xml is valid Atom XML
• Adding a new group to config/sources.yaml produces a new report without code changes
• Notification env vars are opt-in (no effect when unset)

🤖 Generated with Claude Code

[duanyytop]

Thanks for this PR — high quality work across the board. Let me share my thoughts on each part:

✅ Happy to merge

1. RSS/Atom feed (src/rss.ts): Clean, zero-dependency implementation — a natural complement to the GitHub Pages UI.
2. Notification support (src/notify.ts): Opt-in via env vars, well-structured. Very useful for anyone running their own fork.
3. MCP ecosystem tracking: Meaningful new data source.

⚠️ Concern: Config-driven refactor

This is where I'd push back a bit:

1. Wrong abstraction layer: ai-cli and ai-agents have fundamentally different prompt structures — the former generates N independent per-tool
   reports plus a cross-tool comparison; the latter generates one deep primary report (OpenClaw) plus 10 peer summaries. Moving that distinction into
   promptStyle: "cli" | "peer" doesn't eliminate the branch — it just makes it harder to trace. The specialization still lives in the code; it's now just
   triggered by a config string.

2. TypeScript arrays vs. YAML: The current CLI_REPOS / OPENCLAW_PEERS are type-safe TypeScript consts with IDE autocomplete and compile-time
   checks. Introducing a yaml runtime dependency to parse what could remain as code adds complexity without meaningfully reducing maintenance burden.

3. Skills integration gap: The Claude Code skills report is currently injected directly into the Claude Code <details> block inside ai-cli.md.
   The config-driven pipeline doesn't appear to fully handle this integration point.

Minor: code comments

One small ask — most comments in the new files are in Chinese. We'd prefer English for comments and docstrings so the codebase stays accessible to
non-Chinese contributors. The config/sources.yaml file in particular has section headers in Chinese that would ideally be in English (or bilingual).

Suggestion: Would you be open to splitting this into two PRs? RSS + notifications + MCP tracking I can merge quickly. The config-driven refactor
deserves a separate discussion — if tracked sources change frequently it's worth the investment, but at current scale the added indirection may cost more
than it saves.

Let me know what you think.

[duanyytop]

I will close this pr and see the #122