The new independent token source collector in internal/services/tele/commands/token.go now hardcodes both market probes to <TOKEN>USDT.
Scope of this issue
This issue is only about spot/future symbol resolution behavior. It is separate from Alpha lookup behavior.
Problem
The repo already has existing symbol-resolution rules for non-trivial contracts:
futures prefixes like 1000 and 1M
suffix alias handling around USDC
explicit future->spot mapping such as LUNA2USDT -> LUNAUSDT
Those rules are implemented in the existing helper flow (Token2Symbols(...) and Future2SpotSymbol(...)), but the new collector bypasses them by probing only:
futureSymbol := token + "USDT"
spotSymbol := token + "USDT"
Impact
Supported tokens with prefixes, aliases, or explicit future->spot mappings can lose future data, spot data, or both when rendered through the independent collector.
Example
LUNA2USDT is mapped to spot LUNAUSDT in existing config, but the new collector probes spot as LUNA2USDT, which can miss the intended spot pair.
Suggested direction
Keep Alpha lookup logic separate, but restore spot/future resolution through the existing symbol-resolution rules instead of assuming <TOKEN>USDT for both markets.
Context
This is a follow-up issue extracted from PR #19 review so spot/future resolution can be handled independently from Alpha lookup changes.
The new independent token source collector in `internal/services/tele/commands/token.go` now hardcodes both market probes to `<TOKEN>USDT`.
Scope of this issue
This issue is only about spot/future symbol resolution behavior. It is separate from Alpha lookup behavior.
Problem
The repo already has existing symbol-resolution rules for non-trivial contracts:
- futures prefixes like `1000` and `1M`
- suffix alias handling around `USDC`
- explicit future->spot mapping such as `LUNA2USDT -> LUNAUSDT`
Those rules are implemented in the existing helper flow (`Token2Symbols(...)` and `Future2SpotSymbol(...)`), but the new collector bypasses them by probing only:
- `futureSymbol := token + "USDT"`
- `spotSymbol := token + "USDT"`
Impact
Supported tokens with prefixes, aliases, or explicit future->spot mappings can lose future data, spot data, or both when rendered through the independent collector.
Example
`LUNA2USDT` is mapped to spot `LUNAUSDT` in existing config, but the new collector probes spot as `LUNA2USDT`, which can miss the intended spot pair.
Suggested direction
Keep Alpha lookup logic separate, but restore spot/future resolution through the existing symbol-resolution rules instead of assuming `<TOKEN>USDT` for both markets.
Context
This is a follow-up issue extracted from PR #19 review so spot/future resolution can be handled independently from Alpha lookup changes.
Mình đồng ý với issue này: hiện tại collectRichTokenData đang assume token+USDT cho cả spot/future nên có thể làm rơi các case mapping đặc biệt.
Vì sao đáng sửa
Có thể mất dữ liệu cho token có prefix/alias/mapping đặc thù (ví dụ LUNA2USDT -> LUNAUSDT).
Làm lệch behavior so với luồng resolve symbol đã tồn tại trước đó.
Đề xuất implementation
Giữ logic “independent collector” như hiện tại.
Nhưng thay phần build symbol bằng resolver hiện có (Token2Symbols + Future2SpotSymbol) thay vì hardcode <TOKEN>USDT.
Nếu có nhiều candidate futures symbol thì thử theo thứ tự resolver trả về; lấy kết quả đầu tiên hợp lệ.
Test nên thêm
Case mapping explicit: LUNA2USDT -> LUNAUSDT.
Case prefix (1000*, 1M*) vẫn trả đúng spot/future.
Regression: spot-only / future-fail-but-spot vẫn pass như #18.
[claudecode gpt-5.3-codex]
## Ý kiến
Mình **đồng ý** với issue này: hiện tại `collectRichTokenData` đang assume `token+USDT` cho cả spot/future nên có thể làm rơi các case mapping đặc biệt.
## Vì sao đáng sửa
- Có thể mất dữ liệu cho token có prefix/alias/mapping đặc thù (ví dụ `LUNA2USDT -> LUNAUSDT`).
- Làm lệch behavior so với luồng resolve symbol đã tồn tại trước đó.
## Đề xuất implementation
- Giữ logic “independent collector” như hiện tại.
- Nhưng thay phần build symbol bằng resolver hiện có (`Token2Symbols` + `Future2SpotSymbol`) thay vì hardcode `<TOKEN>USDT`.
- Nếu có nhiều candidate futures symbol thì thử theo thứ tự resolver trả về; lấy kết quả đầu tiên hợp lệ.
## Test nên thêm
- Case mapping explicit: `LUNA2USDT -> LUNAUSDT`.
- Case prefix (`1000*`, `1M*`) vẫn trả đúng spot/future.
- Regression: spot-only / future-fail-but-spot vẫn pass như #18.
Legacy Issue: Một số Token sẽ có symbol khác nhau cho Spot và Future, và có thể alpha
Ví dụ
Luna trong spot là LUNA_USDT, trong future là luna2USDT
Một số đồng có thêm tiền tố 1000 1M hay 1000000 như babydoge...
Legacy Issue: Một số Token sẽ có symbol khác nhau cho Spot và Future, và có thể alpha
Ví dụ
- Luna trong spot là LUNA_USDT, trong future là luna2USDT
- Một số đồng có thêm tiền tố 1000 1M hay 1000000 như babydoge...
Thay hardcode <TOKEN>USDT trong collector bằng luồng resolver Spot/Future hiện có (Token2Symbols + Future2SpotSymbol).
Giữ nguyên luồng Alpha như hiện tại (theo token user nhập, không normalize theo Spot/Future).
Regression coverage
Explicit remap: LUNA2USDT -> LUNAUSDT
Prefix families: 1000*, 1M* (và biến thể liên quan)
Không làm hỏng các case đã fix ở #18: spot-only, future fail but spot exists.
[claudecode gpt-5.3-codex]
## Scope alignment
Chốt lại scope theo định hướng mới:
- **Alpha lookup giữ độc lập**: không cần ép đồng nhất symbol với Spot/Future.
- **Spot/Future cần đồng nhất**: khôi phục resolver hiện có để tránh miss dữ liệu ở các case prefix/remap.
## Direction for fix in #21
- Thay hardcode `<TOKEN>USDT` trong collector bằng luồng resolver Spot/Future hiện có (`Token2Symbols` + `Future2SpotSymbol`).
- Giữ nguyên luồng Alpha như hiện tại (theo token user nhập, không normalize theo Spot/Future).
## Regression coverage
- Explicit remap: `LUNA2USDT -> LUNAUSDT`
- Prefix families: `1000*`, `1M*` (và biến thể liên quan)
- Không làm hỏng các case đã fix ở #18: `spot-only`, `future fail but spot exists`.
Nếu bạn ok, bước tiếp theo mới bắt đầu implement theo plan này.
[claudecode gpt-5.3-codex]
## Kế hoạch xử lý (chưa implement)
Mình đã viết plan đầy đủ theo hướng mới: **không reuse trực tiếp 2 helper cũ ở command**, thay vào đó tạo **shared resolver**:
- `TokenToFutureSymbols(token)`
- `TokenToSpotSymbols(token)`
Giữ nguyên tư tưởng:
- Alpha độc lập (không normalize theo Spot/Future)
- Spot/Future đồng nhất qua resolver chung
## Plan file
`docs/superpowers/plans/2026-04-26-issue-21-shared-symbol-resolver.md`
## Nội dung chính
1. Viết failing tests cho resolver mới (RED)
2. Implement resolver tối thiểu để pass (GREEN)
3. Nối resolver vào `collectRichTokenData`
4. Bổ sung regression matrix cho #18 + #21
5. Verify `go test ./...` và `go build ./...`
Nếu bạn ok, bước tiếp theo mới bắt đầu implement theo plan này.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The new independent token source collector in
internal/services/tele/commands/token.gonow hardcodes both market probes to<TOKEN>USDT.Scope of this issue
This issue is only about spot/future symbol resolution behavior. It is separate from Alpha lookup behavior.
Problem
The repo already has existing symbol-resolution rules for non-trivial contracts:
1000and1MUSDCLUNA2USDT -> LUNAUSDTThose rules are implemented in the existing helper flow (
Token2Symbols(...)andFuture2SpotSymbol(...)), but the new collector bypasses them by probing only:futureSymbol := token + "USDT"spotSymbol := token + "USDT"Impact
Supported tokens with prefixes, aliases, or explicit future->spot mappings can lose future data, spot data, or both when rendered through the independent collector.
Example
LUNA2USDTis mapped to spotLUNAUSDTin existing config, but the new collector probes spot asLUNA2USDT, which can miss the intended spot pair.Suggested direction
Keep Alpha lookup logic separate, but restore spot/future resolution through the existing symbol-resolution rules instead of assuming
<TOKEN>USDTfor both markets.Context
This is a follow-up issue extracted from PR #19 review so spot/future resolution can be handled independently from Alpha lookup changes.
[claudecode gpt-5.3-codex]
Ý kiến
Mình đồng ý với issue này: hiện tại
collectRichTokenDatađang assumetoken+USDTcho cả spot/future nên có thể làm rơi các case mapping đặc biệt.Vì sao đáng sửa
LUNA2USDT -> LUNAUSDT).Đề xuất implementation
Token2Symbols+Future2SpotSymbol) thay vì hardcode<TOKEN>USDT.Test nên thêm
LUNA2USDT -> LUNAUSDT.1000*,1M*) vẫn trả đúng spot/future.Legacy Issue: Một số Token sẽ có symbol khác nhau cho Spot và Future, và có thể alpha
Ví dụ
[claudecode gpt-5.3-codex]
Scope alignment
Chốt lại scope theo định hướng mới:
Direction for fix in #21
<TOKEN>USDTtrong collector bằng luồng resolver Spot/Future hiện có (Token2Symbols+Future2SpotSymbol).Regression coverage
LUNA2USDT -> LUNAUSDT1000*,1M*(và biến thể liên quan)spot-only,future fail but spot exists.[claudecode gpt-5.3-codex]
Kế hoạch xử lý (chưa implement)
Mình đã viết plan đầy đủ theo hướng mới: không reuse trực tiếp 2 helper cũ ở command, thay vào đó tạo shared resolver:
TokenToFutureSymbols(token)TokenToSpotSymbols(token)Giữ nguyên tư tưởng:
Plan file
docs/superpowers/plans/2026-04-26-issue-21-shared-symbol-resolver.mdNội dung chính
collectRichTokenDatago test ./...vàgo build ./...Nếu bạn ok, bước tiếp theo mới bắt đầu implement theo plan này.