Codex
82e2c91f42
Add PostgreSQL-backed memory, editable evidence with source review and activation, and human-approved archive repairs across the harness, API, and UI. Include migrations, deployment support, regression coverage, and validation documentation. Refresh permissions from validated session roles so existing administrator logins can access newly deployed archive management features.
5.3 KiB
M1 — Implementazione e verifica
Data: 2026-09-08. Implementazione locale della specifica approvata, associata all' issue 27.
Risultato
La pagina Memory management è disponibile nell'Administration dopo Database management. Gestisce le quattro famiglie di card, elenco completo, ricerca e filtri, ordinamento, dettaglio, creazione, modifica, cancellazione, collegamenti e dipendenze. Richiede un amministratore autenticato e una selezione esplicita del workspace; non richiede una sessione o un database DWH configurato.
Il harness possiede l'archivio PostgreSQL thoth_memory. Card, collegamenti,
dipendenze e lavoro di propagazione sono salvati nella stessa transazione.
La pagina distingue salvataggio fallito e contenuto salvato con indice incompleto,
offrendo retry anche per le cancellazioni. Recall Memory ed exemplar verificano
esistenza, workspace e proiezione corrente nell'archivio prima di restituire contenuto.
Promozione, salvataggio singolo e finalizzazione corrente passano dal servizio autorevole. Le ricevute della sorgente impediscono duplicati e ricreazione di card cancellate. Reindicizzazione e preprocessing non importano vecchi payload o sessioni. L'errore Memory non annulla una sessione già finalizzata; il gate segnala anche una promozione salvata con indicizzazione incompleta.
Le migrazioni sono versionate, controllate tramite checksum e incluse nel wheel
e nell'immagine core. Il servizio di preparazione catalog-migrate le esegue dopo
quelle del Catalog. Il runtime assume il ruolo limitato thoth_memory_runtime,
con isolamento del workspace tramite RLS e senza privilegi DDL.
Verifiche eseguite
| Confine | Esito |
|---|---|
| Harness, test senza L0/L2 | 1.134 passati; i 9 test dei percorsi portabili sono stati eseguiti separatamente e sono passati. |
| Servizio Memory, PostgreSQL e Qdrant reali | 17 passati, inclusi CLI, migrazioni, ruolo runtime, isolamento, transazioni, outage, retry, cancellazioni, cambio famiglia e rebuild. |
| Gate Pi | 190 passati, inclusi identità UUID e avviso dopo salvataggio con indice incompleto. |
| Backend | 1.345 passati nella suite completa, 40 esclusi dalle condizioni previste dai test; un test di autenticazione ha superato il timeout sotto carico. Il relativo file è stato rieseguito isolato: tutti i 17 test passati. |
| Frontend | 632 passati, inclusi ingresso dall'AppShell, form, filtri, collegamenti, dipendenze e retry delle cancellazioni. |
| Browser integrato | Passato: autenticazione amministratore, creazione, modifica, riavvio del backend, rilettura, cancellazione e assenza nel recall. |
| Build e tipi | Build backend e frontend, typecheck TypeScript e build documentale strict superati. |
| Lint e diff | Ruff sui file Python modificati e git diff --check superati. Il lint globale segnala tre rilievi in file non modificati, elencati sotto. |
Il browser utilizza autenticamente frontend, login locale, Fastify, ThtRunner, CLI Python, PostgreSQL e Qdrant. Gli embedding sono deterministici e le attività Pi/sessione estranee al percorso Memory usano le fixture esistenti. Non sono state intercettate le API Memory. Sono stati usati container temporanei PostgreSQL 16 e Qdrant 1.18.2, senza accesso a un DWH remoto o a un modello generativo.
Il test browser ha consentito di correggere etichette accessibili instabili nei campi compilati e la sovrapposizione del pannello di recupero ai comandi del dettaglio. La selezione del workspace e l'uscita dalla pagina sono bloccate durante le operazioni.
Il lint globale preesistente riguarda soltanto:
- ordinamento import in
harness/tests/test_effective_relationships.py; - ordinamento import in
harness/tests/test_p3_dwh_binding.py; - uso di
datetime.UTCinharness/tht/mschema/catalog_snapshot.py.
Riproduzione
Usare Node 24 e le dipendenze installate dei tre layer. Per eseguire il harness
in un ambiente con home non scrivibile si può impostare THT_HOME su una directory
di prova. I test dei percorsi portabili devono essere eseguiti senza questo override,
perché verificano deliberatamente la risoluzione dell'home e di THT_DATA_ROOT.
cd harness
THT_HOME=/private/tmp/thothii-m1-test-home .venv/bin/pytest -m 'not l0 and not l2' --ignore=tests/test_portable_paths.py -q
.venv/bin/pytest tests/test_portable_paths.py -q
.venv/bin/pytest tests/memory/test_administration.py -q
npm test
cd backend
npx vitest run
npx tsc --noEmit -p .
npm run build
cd frontend
npx vitest run
npx tsc -b
npm run build
THT_MEMORY_BROWSER_E2E=1 npx playwright test e2e/memory-real.spec.ts
Il percorso browser richiede Docker, Python del harness, Go per il bridge di
autenticazione e Chromium di Playwright. Avvia risorse isolate e le rimuove alla
fine. Su macOS il browser deve poter avviare i processi Chromium fuori dalle
restrizioni della sandbox. La build documentale si esegue dalla radice con
./scripts/build-docs.sh.
Stato della consegna
Le modifiche sono nel worktree locale. Nessuno stack già attivo è stato aggiornato
e nessun dato esistente è stato migrato o eliminato. Prima di usare M1 su
un'installazione occorrono il nuovo core e la preparazione catalog-migrate.
M2 (retrieval ibrido ed espansione dei collegamenti), M3 (integrazione estesa nel
workflow) ed Evidence management restano incrementi successivi.