Background
MindSpring currently has 3,007 conversation vectors (verified 2026-05-19) from a historical bulk export. AEGIS has no scheduled task that writes new conversations into MindSpring — every integration that reads from it (grounding RRF, curiosity Source 8, PRISM Step 4.5) queries a static snapshot that grows staler as new conversations accumulate in D1.
What's needed
A write path from AEGIS's scheduled pipeline into MindSpring's ingest API. The natural home is the conversation-facts task (runs every 2h in aegis-oss/web/src/kernel/scheduled/conversation-facts.ts) which already iterates recent D1 conversation threads. After processing a batch, it should serialize the threads as NDJSON and POST to POST /api/uploads/simple.
Expected format (from queue.ts)
One JSON object per line:
{"id": "<thread_id>", "title": "<first user message or thread summary>", "create_time": <unix_seconds>, "messages": [{"author": {"role": "user"}, "content": {"parts": ["..."]}}, ...]}MindSpring's built-in processed:<id> KV deduplication means re-uploading already-ingested threads is safe.
Integration context
Three AEGIS systems now depend on MindSpring being current:
- Grounding RRF (
recall.ts) — Rank 4, limit=5, threshold=0.4
- Curiosity Source 8 (
curiosity.ts, shipped 2026-05-19) — thin MW topic seeds → MindSpring gap scan
- PRISM Step 4.5 (
synthesis.ts, shipped 2026-05-19) — dedicated conversation context block for synthesis prompt
All three read-only. None write.
Auth
AEGIS has a read-scoped API key (ms_aegis_*) for search. The ingest call would need an ingest-scoped key — either a new key or an upgrade of the existing one. Key provisioning is on the AEGIS side once the scope is available.
Notes
- File size for a 2h conversation batch should stay well under the 5MB simple upload limit
- AEGIS's D1
messages table stores role and content per message, keyed by conversation_id — straightforward to serialize
- The
conversation-facts task already has a watermark pattern for tracking processed threads; the MindSpring upload can reuse the same batch window
Background
MindSpring currently has 3,007 conversation vectors (verified 2026-05-19) from a historical bulk export. AEGIS has no scheduled task that writes new conversations into MindSpring — every integration that reads from it (grounding RRF, curiosity Source 8, PRISM Step 4.5) queries a static snapshot that grows staler as new conversations accumulate in D1.
What's needed
A write path from AEGIS's scheduled pipeline into MindSpring's ingest API. The natural home is the
conversation-factstask (runs every 2h inaegis-oss/web/src/kernel/scheduled/conversation-facts.ts) which already iterates recent D1 conversation threads. After processing a batch, it should serialize the threads as NDJSON and POST toPOST /api/uploads/simple.Expected format (from queue.ts)
One JSON object per line:
{"id": "<thread_id>", "title": "<first user message or thread summary>", "create_time": <unix_seconds>, "messages": [{"author": {"role": "user"}, "content": {"parts": ["..."]}}, ...]}MindSpring's built-in
processed:<id>KV deduplication means re-uploading already-ingested threads is safe.Integration context
Three AEGIS systems now depend on MindSpring being current:
recall.ts) — Rank 4,limit=5,threshold=0.4curiosity.ts, shipped 2026-05-19) — thin MW topic seeds → MindSpring gap scansynthesis.ts, shipped 2026-05-19) — dedicated conversation context block for synthesis promptAll three read-only. None write.
Auth
AEGIS has a
read-scoped API key (ms_aegis_*) for search. The ingest call would need aningest-scoped key — either a new key or an upgrade of the existing one. Key provisioning is on the AEGIS side once the scope is available.Notes
messagestable storesroleandcontentper message, keyed byconversation_id— straightforward to serializeconversation-factstask already has a watermark pattern for tracking processed threads; the MindSpring upload can reuse the same batch window