|
|
@@ -29,10 +29,16 @@ Health:
|
|
|
1) `get_latest_events(topic, limit)`
|
|
|
- `topic` is a coarse category: `crypto | macro | regulation | ai | other`
|
|
|
|
|
|
+Optional boolean:
|
|
|
+- `include_articles` (default: `false`) — when `true`, includes `articles[].url` + minimal fields per returned cluster.
|
|
|
+
|
|
|
2) `get_events_for_entity(entity, limit)`
|
|
|
- substring, case-insensitive match over extracted `entities`
|
|
|
- uses a shallow recent scan first, then falls back to a wider historical scan if needed
|
|
|
|
|
|
+Optional boolean:
|
|
|
+- `include_articles` (default: `false`) — when `true`, includes `articles[].url` + minimal fields per returned cluster.
|
|
|
+
|
|
|
### Entity aliasing
|
|
|
|
|
|
The server keeps a conservative alias map in `config/entity_aliases.json` for obvious shorthands
|
|
|
@@ -42,6 +48,9 @@ to reduce false misses, not to rewrite every possible name variant.
|
|
|
3) `get_event_summary(event_id)`
|
|
|
- Groq-written compressed narrative for a given `cluster_id`
|
|
|
|
|
|
+Optional boolean:
|
|
|
+- `include_articles` (default: `false`) — when `true`, includes the underlying `articles` list (with `url`) from the stored cluster.
|
|
|
+
|
|
|
4) `detect_emerging_topics(limit)`
|
|
|
- derives “emerging” signals from recent cached clusters
|
|
|
|