feat: Introduce PolyWeather Pro commercialization, update project documentation, and add Telegram push utility.
This commit is contained in:
2569718930@qq.com
+54
-116
@@ -1,141 +1,79 @@
|
||||
# Commercialization Plan
|
||||
# 📈 Commercialization Roadmap
|
||||
|
||||
## Product Direction
|
||||
> **Target**: Transforming PolyWeather for paid weather intelligence delivery.
|
||||
|
||||
PolyWeather is being positioned as a paid weather intelligence product built around:
|
||||
- Web dashboard subscription
|
||||
- Telegram paid group subscription
|
||||
- Fast, rules-based weather alerting
|
||||
- High-confidence Ankara specialization
|
||||
---
|
||||
|
||||
Current pricing target:
|
||||
- Web dashboard: $5 / month
|
||||
- Telegram paid group: $1 / month
|
||||
## 🎯 Product Focus
|
||||
|
||||
Current payment direction under discussion:
|
||||
- Polygon / USDC
|
||||
PolyWeather is positioned as a **premium intelligence service** for weather-based prediction markets (**Polymarket**). The value proposition lies in **Ankara-specialization**, **advanced advection forecasting**, and **DEB-weighted consensus**.
|
||||
|
||||
Important current state:
|
||||
- Polymarket market-price integration has been removed from the codebase
|
||||
- The current product focuses on weather intelligence, not exchange/orderbook execution data
|
||||
---
|
||||
|
||||
## Production Architecture
|
||||
## 💰 Pricing & Monetization
|
||||
|
||||
### Web
|
||||
- Next.js frontend on Vercel
|
||||
- Public URL: `https://polyweather-pro.vercel.app/`
|
||||
- FastAPI backend serves API only
|
||||
| Tier | Price | Primary Value Proposition |
|
||||
| :------------------- | :------------ | :------------------------------------------------------------ |
|
||||
| **Telegram Channel** | **$1 / mo** | High-fidelity proactive alerts, low noise. |
|
||||
| **Web Dashboard** | **$5 / mo** | Comprehensive multi-model view + historical MAE benchmarking. |
|
||||
| **VIP Bundle** | **$5.5 / mo** | Full access to all intelligence streams. |
|
||||
|
||||
### Backend
|
||||
- FastAPI on VPS
|
||||
- Shared analysis layer for web and bot
|
||||
- City data cache in-process
|
||||
### 🛠️ Payment Infrastructure
|
||||
|
||||
### Telegram
|
||||
- Bot runs on VPS
|
||||
- Paid group receives proactive alerts
|
||||
- Push engine includes dedupe, cooldown, and late-day suppression
|
||||
- **Currency**: Polygon / USDC.
|
||||
- **Method**: Initially manual activation; migrating to automatic deposit detection (Phase 2).
|
||||
|
||||
## Alert Product Strategy
|
||||
---
|
||||
|
||||
Current alert strategy is weather-first:
|
||||
- Ankara Center reached DEB
|
||||
- Momentum spike
|
||||
- Forecast breakthrough
|
||||
- Advection / nearby lead station
|
||||
## 🗺️ Execution Roadmap
|
||||
|
||||
Operational controls already implemented:
|
||||
- Same city + same trigger type only pushes once while active
|
||||
- City-level cooldown
|
||||
- Peak-passed suppression for late-day rollover
|
||||
```mermaid
|
||||
graph LR
|
||||
P1[Phase 1: Manual Beta] --> P2[Phase 2: USDC Automation]
|
||||
P2 --> P3[Phase 3: Scaling & Analytics]
|
||||
|
||||
Ankara special handling:
|
||||
- Center signal only uses `Ankara (Bolge/Center)` / `17130`
|
||||
- This should remain a product differentiator and be documented clearly in sales copy
|
||||
subgraph P1_Detail [Manual Operations]
|
||||
P1 -->|DM Bot| Pay[Manual Payment]
|
||||
Pay -->|Invite| Link[One-time Link]
|
||||
end
|
||||
|
||||
## Recommended Subscription Structure
|
||||
subgraph P2_Detail [Smart Automation]
|
||||
P2 -->|Monitor| Chain[Polygon/USDC]
|
||||
Chain -->|Auto| Access[JWT/Sub Activation]
|
||||
end
|
||||
```
|
||||
|
||||
### Tier A: Telegram Group
|
||||
- Price: $1 / month
|
||||
- Value proposition:
|
||||
- Real-time proactive weather alerts
|
||||
- Fast anomaly delivery
|
||||
- Focused operational signal, minimal clutter
|
||||
- Suggested restrictions:
|
||||
- No raw API access
|
||||
- No historical analytics export
|
||||
- No advanced chart controls
|
||||
### 📦 Phase 1: Manual Beta
|
||||
|
||||
### Tier B: Web Dashboard
|
||||
- Price: $5 / month
|
||||
- Value proposition:
|
||||
- Full city dashboard
|
||||
- Trend and nearby-station visualization
|
||||
- Multi-model comparison
|
||||
- Historical view
|
||||
- Suggested restrictions:
|
||||
- View-only unless future premium tools are added
|
||||
- **Goal**: Stabilize current alert quality and build core user group.
|
||||
- **Actions**:
|
||||
- Manual subscription activation via Telegram DM.
|
||||
- Small, focused paid Telegram channel for signal tests.
|
||||
- Invitation-only Web Access (Vercel).
|
||||
|
||||
### Bundle Option
|
||||
- Optional future bundle: Web + Group
|
||||
- Use only if conversion data shows users want both together
|
||||
### 🛠️ Phase 2: Automation (USDC)
|
||||
|
||||
## Payment Roadmap
|
||||
- **Goal**: Reduce operational friction.
|
||||
- **Actions**:
|
||||
- **On-chain monitoring**: Detect USDC deposits to unique addresses.
|
||||
- **One-time Links**: Telegram bot automatically generates invite links with `member_limit=1`.
|
||||
- **JWT Auth**: Securing the Next.js frontend with subscriber-only tokens.
|
||||
|
||||
### Phase 1: Manual Ops
|
||||
- User pays manually
|
||||
- Operator manually activates web access / Telegram access
|
||||
- Lowest engineering cost, fastest launch
|
||||
### 🌐 Phase 3: Scaling & Analytics
|
||||
|
||||
### Phase 2: Polygon / USDC Automation
|
||||
- Generate unique deposit address or payment intent
|
||||
- Confirm on-chain payment
|
||||
- Activate subscription automatically
|
||||
- Telegram bot issues one-time group invite link
|
||||
- **Goal**: Retention and expansion.
|
||||
- **Actions**:
|
||||
- **Accuracy Leaderboard**: Monthly reports of DEB vs Market outcomes.
|
||||
- **Self-Serve Portal**: User dashboard for billing and alert settings.
|
||||
|
||||
### Phase 3: Full Subscription Management
|
||||
- Renewal reminders
|
||||
- Grace period handling
|
||||
- Automatic expiry / revocation
|
||||
- Self-serve billing status page
|
||||
---
|
||||
|
||||
## Recommended Near-Term Roadmap
|
||||
## 🚧 Critical Constraints
|
||||
|
||||
### Step 1: Stabilize Current Product
|
||||
- Finish cleaning docs and deployment flow
|
||||
- Keep Vercel as the only web entry point
|
||||
- Keep backend API-only
|
||||
- Tune Telegram cooldown and trigger quality
|
||||
- **Weather-First**: We focus on the **physical variable changes** rather than exchange-side order book execution.
|
||||
- **Quality > Quantity**: Alert fatigue will churn subscribers. We enforce a "True Probability Shift" rule for notifications.
|
||||
- **Local Niche**: Ankara is our flagship differentiator.
|
||||
|
||||
### Step 2: Launch Manual Paid Beta
|
||||
- Start with a small paid Telegram group
|
||||
- Start web dashboard on invite basis
|
||||
- Track which alert types users actually value
|
||||
---
|
||||
|
||||
### Step 3: Add Access Control
|
||||
- Web login and session layer
|
||||
- Subscription table in backend
|
||||
- Telegram membership verification
|
||||
|
||||
### Step 4: Add Polygon / USDC Collection
|
||||
- Payment detection
|
||||
- Subscription activation
|
||||
- One-time Telegram invite issuance
|
||||
|
||||
## Metrics To Track
|
||||
|
||||
Minimum metrics before scaling:
|
||||
- Alert-to-action usefulness feedback
|
||||
- Daily active dashboard users
|
||||
- Telegram retention after first payment cycle
|
||||
- Most valuable cities by engagement
|
||||
- False-positive complaint rate for alerts
|
||||
|
||||
## Constraints To Keep In Mind
|
||||
|
||||
- The current system is strongest in weather intelligence, not execution plumbing
|
||||
- Ankara is a differentiated niche and should be treated as premium signal inventory
|
||||
- Over-pushing alerts will destroy paid-group value faster than under-pushing
|
||||
- Payment automation should come after alert quality is operationally stable
|
||||
|
||||
Last updated: 2026-03-06
|
||||
**📅 Last Updated**: 2026-03-06
|
||||
|
||||
+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