roadmap changes
This commit is contained in:
@@ -431,6 +431,20 @@ The items below are planned improvements roughly ordered by user value. They are
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
### 9. Auto-Derive Display Casing from Mastodon Posts
|
||||||
|
|
||||||
|
**Problem:** `displayTag` is currently set once at research/creation time from whatever the user typed. In reality Mastodon users have an established "canonical" capitalisation for a tag (e.g. `#StPatricksDay` rather than `#stpatricksday`) and our display tag should reflect that.
|
||||||
|
|
||||||
|
**Plan:**
|
||||||
|
- During each price update job the worker already fetches up to 200 posts. The Mastodon API returns each post's `tags` array where `name` contains the tag as typed by the poster (e.g. `StPatricksDay`).
|
||||||
|
- Count the frequency of each distinct casing variant seen across all fetched posts for the hashtag being updated.
|
||||||
|
- If the most frequent variant differs from the current `displayTag`, update `Hashtag.displayTag` as part of the price update transaction.
|
||||||
|
- Only update when a variant accounts for a meaningful majority (e.g. ≥ 50% of occurrences) to avoid flip-flopping on low-signal posts.
|
||||||
|
- Implementation touches: `mastodon.ts` already returns `post.tags` from `getPostsData()` — add a `casing` field to the result (`{ postsPerHour, relatedTags, displayTag? }`); worker checks the returned `displayTag` and includes it in the Prisma update when it differs.
|
||||||
|
- No schema changes required — `displayTag` already exists on `Hashtag`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
### Other Ideas / Nice-to-Haves
|
### Other Ideas / Nice-to-Haves
|
||||||
|
|
||||||
- **Hedge funds**: group of players pool money into a shared portfolio, one designated fund manager places trades.
|
- **Hedge funds**: group of players pool money into a shared portfolio, one designated fund manager places trades.
|
||||||
|
|||||||
Reference in New Issue
Block a user