Portare il workspace alla readiness con controlli runtime #49

New Issue

2026-09-28T13:06:22Z

mptyl commented

2026-09-28 13:06:22 +00:00

Parent

Spec: installazione da documenti verificati e distribuzione Docker Hub.

What to build

Da un binding applicato, il percorso completa sincronizzazione dello schema e
preparazione necessaria e rende visibili i risultati dei controlli runtime.
Un workspace è pronto solo quando tutti i requisiti applicabili sono verificati;
le decisioni umane già previste dai contratti rimangono esplicite.

Acceptance criteria

La sincronizzazione usa i Catalog Sync Runs durabili con lock, freschezza e transazioni esistenti; non introduce una seconda implementazione.
Diff distruttive fermano il percorso in attesa della revisione di dominio esistente; ripresa successiva senza auto-conferme né domande sui parametri di setup.
Preprocessing e consolidamento riusano descrizioni/commenti ed Evidence curate; nessuna generazione AI implicita, nessuna cancellazione di Memory o sovrascrittura di curation.
Assenza lecita di Evidence non blocca; Evidence configurate ma invalide e indici necessari non pronti restano blocchi reali.
Pi, modello embedding, trasporto DWH e altri obblighi differiti sono eseguiti a runtime e rendicontati; nessun obbligo scompare o viene considerato superato senza prova.
Stato piattaforma, Workspace Readiness e collaudo funzionale sono distinti; una domanda reale con revisione rimane la prova funzionale, senza SQL target.
Test di servizio e integrazione dimostrano esiti, conservazione dati e ripresa dei run; guide IT/EN spiegano le eventuali revisioni umane residue.

Blocked by

#48 — Applicare i binding preparati al Catalog.

## Parent [Spec: installazione da documenti verificati e distribuzione Docker Hub](https://git.tylconsulting.it/mptyl/ThothII/issues/42). ## What to build Da un binding applicato, il percorso completa sincronizzazione dello schema e preparazione necessaria e rende visibili i risultati dei controlli runtime. Un workspace è pronto solo quando tutti i requisiti applicabili sono verificati; le decisioni umane già previste dai contratti rimangono esplicite. ## Acceptance criteria - [ ] La sincronizzazione usa i Catalog Sync Runs durabili con lock, freschezza e transazioni esistenti; non introduce una seconda implementazione. - [ ] Diff distruttive fermano il percorso in attesa della revisione di dominio esistente; ripresa successiva senza auto-conferme né domande sui parametri di setup. - [ ] Preprocessing e consolidamento riusano descrizioni/commenti ed Evidence curate; nessuna generazione AI implicita, nessuna cancellazione di Memory o sovrascrittura di curation. - [ ] Assenza lecita di Evidence non blocca; Evidence configurate ma invalide e indici necessari non pronti restano blocchi reali. - [ ] Pi, modello embedding, trasporto DWH e altri obblighi differiti sono eseguiti a runtime e rendicontati; nessun obbligo scompare o viene considerato superato senza prova. - [ ] Stato piattaforma, Workspace Readiness e collaudo funzionale sono distinti; una domanda reale con revisione rimane la prova funzionale, senza SQL target. - [ ] Test di servizio e integrazione dimostrano esiti, conservazione dati e ripresa dei run; guide IT/EN spiegano le eventuali revisioni umane residue. ## Blocked by - [#48](https://git.tylconsulting.it/mptyl/ThothII/issues/48) — Applicare i binding preparati al Catalog.

mptyl added the ready-for-agent label 2026-09-28 13:06:22 +00:00

mptyl referenced this issue

2026-09-28 13:06:23 +00:00

Riprendere dopo correzioni e interruzioni senza perdere stato #51

mptyl added a new dependency 2026-09-28 13:06:35 +00:00

#48 Applicare i binding preparati al Catalog

mptyl added a new dependency 2026-09-28 13:06:37 +00:00

#51 Riprendere dopo correzioni e interruzioni senza perdere stato

Sign in to join this conversation.