feat: Introduce PolyWeather Pro commercialization, update project documentation, and add Telegram push utility.
This commit is contained in:
2569718930@qq.com
+44
-94
@@ -1,115 +1,65 @@
|
||||
# Technical Debt
|
||||
# 🛠️ Technical Debt & Engineering Backlog
|
||||
|
||||
Last updated: 2026-03-06
|
||||
> **Vision**: Moving from a research script to a production SaaS.
|
||||
|
||||
## Current State
|
||||
---
|
||||
|
||||
Overall system status: usable and deployable.
|
||||
## 🏛️ System Health: 75%
|
||||
|
||||
Stable pieces:
|
||||
- Multi-source weather collection
|
||||
- DEB forecast blending
|
||||
- Web dashboard on Vercel
|
||||
- FastAPI API backend
|
||||
- Telegram proactive push loop
|
||||
- Alert dedupe and cooldown
|
||||
- Late-day peak suppression
|
||||
```mermaid
|
||||
pie title System Health & Tech Debt
|
||||
"Stable Engine" : 75
|
||||
"Centralized Logic Debt" : 10
|
||||
"Subscription DB Debt" : 10
|
||||
"Testing/Replay Debt" : 5
|
||||
```
|
||||
|
||||
Recently removed:
|
||||
- Old FastAPI static web page
|
||||
- Polymarket market-price integration
|
||||
- `/tradealert` preview command
|
||||
The core engine is stable, but several infrastructure "shortcut" decisions remain.
|
||||
|
||||
## High-Priority Debt
|
||||
### Current Stable Modules
|
||||
|
||||
### 1. Bot orchestration is still too centralized
|
||||
`bot_listener.py` is operational, but too much runtime behavior is still coordinated from a single entrypoint.
|
||||
- [x] Multi-source Weather Aggregation
|
||||
- [x] DEB Blending Algorithm
|
||||
- [x] Proactive Telegram Alert Engine
|
||||
- [x] Vercel Dashboard Infrastructure
|
||||
|
||||
Impact:
|
||||
- Harder to test
|
||||
- Harder to evolve subscription logic
|
||||
- Harder to isolate push bugs
|
||||
---
|
||||
|
||||
Suggested direction:
|
||||
- Keep moving push and analysis concerns into `src/utils` and `src/analysis`
|
||||
## 🔴 High Priority: Immediate Focus
|
||||
|
||||
### 2. Alert transparency needs better operator visibility
|
||||
The system now pushes the correct trigger types more conservatively, but group operators still need better evidence lines.
|
||||
| Debt Item | Impact | Suggested Fix |
|
||||
| :--------------------- | :-------------------------------------------------- | :--------------------------------------------------------------- |
|
||||
| **Monolithic Bot** | `bot_listener.py` is hard to test and evolve. | Isolate UI interaction from business logic into `src/analysis`. |
|
||||
| **Subscription Store** | No persistent record of who has paid. | Migrate from in-memory user checks to **Supabase/PostgreSQL**. |
|
||||
| **Alert Transparency** | Operators cannot easily audit "why" an alert fired. | Add an `Evidence` metadata block to all internal alert payloads. |
|
||||
|
||||
Impact:
|
||||
- Hard to audit why a message fired
|
||||
- Hard to distinguish strong vs weak advection calls
|
||||
---
|
||||
|
||||
Suggested direction:
|
||||
- Add a compact `依据 / Evidence` line to alert messages
|
||||
- Expose raw trigger metrics in a debug API or operator log
|
||||
## 🟡 Medium Priority: Quality of Life
|
||||
|
||||
### 3. No persistent application store for subscriptions
|
||||
Current architecture is ready for commercialization planning, but there is no real subscription state model yet.
|
||||
| Debt Item | Impact | Suggested Fix |
|
||||
| :------------------------ | :-------------------------------------------------- | :--------------------------------------------------------------------------- |
|
||||
| **Hard-coded Thresholds** | Modification requires code changes (e.g., 5s CD). | Extract all business constants into a structured `config.yaml`. |
|
||||
| **Simulation Harness** | No way to "replay" a rainy day to test alert logic. | Build a `ReplayEngine` using `data/daily_records.json`. |
|
||||
| **Backend Naming** | Artifacts of "market price" logic remain in naming. | Systematic refactor of variable names to reflect weather-intelligence focus. |
|
||||
|
||||
Impact:
|
||||
- No paid access enforcement
|
||||
- No renewal logic
|
||||
- No expiry / access revocation
|
||||
---
|
||||
|
||||
Suggested direction:
|
||||
- Add a database-backed subscription table before automating billing
|
||||
## 🟢 Low Priority: Optimization
|
||||
|
||||
## Medium-Priority Debt
|
||||
| Debt Item | Impact | Suggested Fix |
|
||||
| :------------------------- | :---------------------------------------------- | :------------------------------------------------------------- |
|
||||
| **Serverless Cold Starts** | Initial Vercel API calls can be slow. | Implement edge-cache or warming cron for major city endpoints. |
|
||||
| **Local SQLite Files** | Not compatible with Vercel's ephemeral storage. | Full transition to a remote DB (Supabase/Redis). |
|
||||
|
||||
### 4. Backtesting is still missing
|
||||
The system has live rules, but no proper replay framework for validating whether rule changes improve quality.
|
||||
---
|
||||
|
||||
Impact:
|
||||
- Rule changes are hard to evaluate objectively
|
||||
- Alert tuning is still partly manual
|
||||
## 🗓️ Next Milestones
|
||||
|
||||
Suggested direction:
|
||||
- Build a replay harness from stored observations and forecasts
|
||||
1. **DB Integration**: Connect Supabase to `src/database/db_manager.py`.
|
||||
2. **Alert Transparency**: Append logic metrics (slope, lead delta) to push messages.
|
||||
3. **Authentication**: Secure `/api/city` on Vercel with subscription keys.
|
||||
|
||||
### 5. Thresholds remain code-defined
|
||||
Important thresholds are still embedded in Python.
|
||||
---
|
||||
|
||||
Examples:
|
||||
- Momentum slope threshold
|
||||
- Peak-passed rollback threshold
|
||||
- Advection lead delta threshold
|
||||
- Cooldown defaults
|
||||
|
||||
Suggested direction:
|
||||
- Extract to constants or structured config
|
||||
|
||||
### 6. Frontend still uses a legacy shell inside Next
|
||||
The production frontend is on Vercel, but the page is still driven by `public/legacy/index.html` plus static scripts.
|
||||
|
||||
Impact:
|
||||
- Slower UI evolution
|
||||
- Harder component-level reuse
|
||||
- Harder design-system integration
|
||||
|
||||
Suggested direction:
|
||||
- Migrate the legacy dashboard into native Next components incrementally
|
||||
|
||||
## Low-Priority Debt
|
||||
|
||||
### 7. Caching is simple in-process cache only
|
||||
Current cache is sufficient for the current deployment size, but not ideal long term.
|
||||
|
||||
Suggested direction:
|
||||
- Move to Redis or another shared cache if multi-instance deployment is needed
|
||||
|
||||
### 8. Test tooling is not fully provisioned everywhere
|
||||
The repository has tests, but some environments still do not have `pytest` installed.
|
||||
|
||||
Impact:
|
||||
- Harder to run full verification on every host
|
||||
|
||||
Suggested direction:
|
||||
- Standardize test dependencies in deployment and CI environments
|
||||
|
||||
## Immediate Next Steps
|
||||
|
||||
1. Add evidence lines to Telegram alerts
|
||||
2. Finish cleaning backend naming after removal of old static web flow
|
||||
3. Design subscription storage for commercialization
|
||||
4. Start replay/backtest tooling for alert-quality tuning
|
||||
**📅 Last Updated**: 2026-03-06
|
||||
|
||||
Reference in New Issue
Block a user