[#2191] Phase 2 — Prototype store unifié Postgres + Qdrant (schéma + writer + recherche 2-temps)

[myia-ai-01]

Parent : #2191 — ADR : #2197 (ADR 010 v2.0, Option E / Scénario B) — GO user 2026-05-29 (avec override Q1)

Scope (Phase 2 du RESPEC #2191)

Prototype greenfield du store unifié. Aucun code Postgres actuellement (pg absent du codebase — vérifié par review po-2025).

• DB unique : un seul Postgres sur ai-01, exposé via sous-domaine myia.io dédié (pg.myia.io / db.myia.io). PAS de réplication (override user Q1 — voir Décision ci-dessous).
• Exposition : DNS → ai-01 + SSL/TLS natif Postgres (option pgbouncer pour pooling). ⚠️ Postgres = protocole TCP natif, pas le reverse proxy HTTP IIS qui fronte embeddings/qdrant/mcp-tools — exposition à câbler spécifiquement.
• Schéma Postgres : conversations (PK task_id), messages (PK id, tool_calls JSONB). Pas de pgvector.
• Writer path : étendre SkeletonCacheService.addOrUpdate() (skeleton-cache.service.ts:112) → upsert Postgres + payload message_id côté Qdrant. Throttle ~30s (Q7).
• Reader path : recherche 2-temps Qdrant ANN → JOIN Postgres dans conversation_browser.
• Backward compat : skeleton-cache local reste fonctionnel pendant la transition (30j).

Décision user 2026-05-29 (débloque la Phase 2)

Q	Sujet	Décision
Q1	Réplication	OVERRIDE → DB unique exposée via sous-domaine myia.io, AUCUNE réplication. Résilience = GDrive + backup 30j + ré-ingestion depuis sources (#2428).
Q2	Hosting	Docker sur ai-01 ✅
Q3	Rétention backup	30 jours ✅
Q4	Failover	Simplifié — plus de promotion replica ; restore backup + ré-ingestion ✅
Q5	Backfill message_id	Nullable + progressif ✅
Q6	Texte messages	Dupliquer dans Postgres ✅
Q7	Throttle GDrive 30s	Suffisant ✅

Estimation (review po-2025, Sprint #9)

~700-900 LOC + ~200 LOC tests, ~3-4 sessions. (Légèrement réduit : pas de setup réplication/failover.)

Critères d'acceptation

• Schéma + migration Postgres (Docker ai-01)
• Exposition via sous-domaine dédié (DNS + SSL natif) validée depuis une 2e machine
• Prototype fonctionnel (latence < 500ms lecture, < 2s écriture)
• Recherche 2-temps validée vs skeleton-cache actuel (parité résultats)
• Backward compat skeleton-cache local

Owner suggéré : po-2025 ou po-2026 (expertise MCP). Model : sonnet/opus. Statut : DÉBLOQUÉ, prêt à dispatcher.

[jsboige]

Spec d'intégration writer — déblocage prototype (par ai-01 coordinateur)

Engagement tenu (dispatch Sprint #9). Ancrage code vérifié : SkeletonCacheService.addOrUpdate() existe à src/services/skeleton-cache.service.ts:112. Greenfield confirmé : 0 référence pg/postgres dans src/.

Contraintes architecturales gravées (décision user 2026-05-29 — NE PAS dévier)

• DB UNIQUE sur ai-01, AUCUNE réplication (override Q1). Le store est un index dérivé : données brutes survivent sur chaque machine + GDrive → résilience = backup 30j ([#2191] Ingestion continue multi-machine → store unifié (la réplication EST le backup) #2427 Q3) + ré-ingestion ([#2191] Re-injection des archives récupérées (catastrophe 2026-05-28) dans le store unifié #2428), pas replicas.
• Exposition externe = sous-domaine dédié pg.myia.io : DNS→ai-01 + TCP natif Postgres + SSL/TLS (option pgbouncer). PAS derrière le reverse proxy HTTP IIS (po-2023) qui fronte embeddings/qdrant/mcp-tools — Postgres n'est pas HTTP.
• PAS de pgvector (Qdrant garde les embeddings/ANN). PAS de décommission Qdrant. Hybride permanent (ADR 010 / docs(#2191): ADR 010 — conversation_browser GDrive storage architecture #2197 Scénario B).

Schéma SQL minimal (prototype)

CREATE TABLE conversations (
  task_id      TEXT PRIMARY KEY,
  machine_id   TEXT NOT NULL,
  harness      TEXT NOT NULL,              -- 'roo' | 'zoo' | 'claude'
  workspace    TEXT,
  parent_task_id TEXT,                      -- arbre parent-enfant
  title        TEXT,
  first_ts     TIMESTAMPTZ,                 -- ts INTERNE (ui_messages.json), PAS mtime
  last_ts      TIMESTAMPTZ,
  msg_count    INT,
  metadata     JSONB,
  ingested_at  TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE messages (
  id           BIGSERIAL PRIMARY KEY,
  task_id      TEXT NOT NULL REFERENCES conversations(task_id) ON DELETE CASCADE,
  message_id   TEXT,                        -- Q5: nullable + backfill progressif
  seq          INT NOT NULL,                -- ordre dans la conversation
  role         TEXT,                        -- user | assistant | tool
  content      TEXT,                        -- Q6: dupliqué dans Postgres = source vérité requêtable
  tool_calls   JSONB,                       -- restaure les filtres roosync_search #636 (tool_name, etc.)
  ts           TIMESTAMPTZ,
  UNIQUE (task_id, seq)
);
CREATE INDEX idx_msg_task ON messages(task_id);
CREATE INDEX idx_msg_toolcalls ON messages USING gin(tool_calls);
CREATE INDEX idx_conv_machine_harness ON conversations(machine_id, harness);

Point d'intégration writer (dual-write non-bloquant)

SkeletonCacheService.addOrUpdate(taskId, skeleton) est le hook canonique (déjà appelé par tout le pipeline d'ingestion). Y ajouter, après l'écriture cache existante :

// après this.cache.set(...) / persistance existante
await this.unifiedStore?.upsertConversation(taskId, skeleton);   // best-effort, JAMAIS bloquer le cache

• Best-effort : un échec Postgres ne doit PAS casser le cache local (try/catch + log, le store est dérivé).
• unifiedStore = nouveau UnifiedStoreWriter injecté optionnellement (null si DB indisponible → dégradation propre, machine continue).
• Mapping ConversationSkeleton → conversations + messages[] : first_ts/last_ts depuis le ts interne des messages (le mtime des dossiers est corrompu, cf. catastrophe — ne JAMAIS s'en servir).

Recherche 2-temps (read path prototype)

1. Qdrant ANN sur l'embedding de la requête → top-K task_id/chunk_id (inchangé, collection existante).
2. Postgres JOIN : SELECT ... FROM conversations c JOIN messages m USING(task_id) WHERE c.task_id = ANY($1) → enrichissement metadata + filtres (tool_calls, machine, harness, période). Pas de vecteur en Postgres.

Livrables prototype (#2426, ~700-900 LOC)

• docker-compose.postgres.yml (Postgres sur ai-01, volume persistant, SSL)
• migrations/001_init.sql (schéma ci-dessus)
• src/services/unified-store/UnifiedStoreWriter.ts (upsertConversation, pool pg, best-effort)
• src/services/unified-store/UnifiedStoreReader.ts (recherche 2-temps)
• src/types/unified-task.ts (UnifiedTask — partagé avec [#2191] Adaptateur Zoo-Code — ingestion des tâches Zoo dans le store unifié #2429 adaptateur Zoo)
• Hook dans skeleton-cache.service.ts:112 (dual-write optionnel)
• Tests : writer (mock pg), reader (2-temps), mapping ts-interne. Exclure du vitest.config.ci.ts si dépend d'un Postgres réel.

Hors scope prototype (différé aux sous-issues)

• Ingestion continue multi-machine = [#2191] Ingestion continue multi-machine → store unifié (la réplication EST le backup) #2427 (réutilise l'indexeur leader-election feat(indexing): leader-election / partition task-space pour l'indexeur Qdrant (élimine la redondance N×) #2352 ; écriture distante via pg.myia.io).
• Ré-injection archives = [#2191] Re-injection des archives récupérées (catastrophe 2026-05-28) dans le store unifié #2428 (seed gelé jusqu'à audit fleet 6/6).
• Adaptateur Zoo = [#2191] Adaptateur Zoo-Code — ingestion des tâches Zoo dans le store unifié #2429 (détecteur storage zoocodeorganization.zoo-code).

Si un agent re-propose la réplication Postgres → STOP, citer l'override Q1 user 2026-05-29.

— ai-01 coordinateur (Opus 4.8)

[jsboige]

[CLAIMED] by claude on myia-po-2023 at 2026-05-30T08:42:23.0571996+02:00