Deliver the first complete Description Generation path: a Catalog Administrator selects one Catalog Column and a configured model, starts generation, follows a persistent asynchronous run, and sees the valid result written immediately to Generated Description.
Acceptance criteria
The catalog migration introduces the minimal Description Generation Run and ordered Description Generation Event persistence required by spec #4.
A start request creates the run, schedules backend processing, and returns without waiting for the model call.
At most one run is queued or running across the installation, and a second start returns a clear conflict.
The target Workspace Database is reserved through the existing Catalog Operation Coordinator while generation is active.
A short-lived internal Python/LiteLLM helper performs one structured completion through stdin/stdout; it is not exposed as a user CLI or HTTP service.
The backend has an injectable Model Completer seam so deterministic tests do not call a real provider.
A valid result is applied immediately to the selected column's Generated Description and produces safe progress events.
Basic provider/helper or response failure terminates the run as failed without writing ambiguous output.
Database Management can start the selected-column run and inspect status, counters, and chronological events using polling.
Generation requires database-management permission; keys, prompts, samples, and provider payloads do not appear in API data or event text.
The primary Fastify/PostgreSQL test seam and the Python helper contract test cover the complete success and basic failure paths.
Blocked by
#5 — Configure metadata-generation models end to end
## Parent
https://git.tylconsulting.it/mptyl/ThothII/issues/4
## What to build
Deliver the first complete Description Generation path: a Catalog Administrator selects one Catalog Column and a configured model, starts generation, follows a persistent asynchronous run, and sees the valid result written immediately to Generated Description.
## Acceptance criteria
- [ ] The catalog migration introduces the minimal Description Generation Run and ordered Description Generation Event persistence required by spec #4.
- [ ] A start request creates the run, schedules backend processing, and returns without waiting for the model call.
- [ ] At most one run is queued or running across the installation, and a second start returns a clear conflict.
- [ ] The target Workspace Database is reserved through the existing Catalog Operation Coordinator while generation is active.
- [ ] A short-lived internal Python/LiteLLM helper performs one structured completion through stdin/stdout; it is not exposed as a user CLI or HTTP service.
- [ ] The backend has an injectable Model Completer seam so deterministic tests do not call a real provider.
- [ ] A valid result is applied immediately to the selected column's Generated Description and produces safe progress events.
- [ ] Basic provider/helper or response failure terminates the run as failed without writing ambiguous output.
- [ ] Database Management can start the selected-column run and inspect status, counters, and chronological events using polling.
- [ ] Generation requires database-management permission; keys, prompts, samples, and provider payloads do not appear in API data or event text.
- [ ] The primary Fastify/PostgreSQL test seam and the Python helper contract test cover the complete success and basic failure paths.
## Blocked by
- #5 — Configure metadata-generation models end to end
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Parent
#4
What to build
Deliver the first complete Description Generation path: a Catalog Administrator selects one Catalog Column and a configured model, starts generation, follows a persistent asynchronous run, and sees the valid result written immediately to Generated Description.
Acceptance criteria
Blocked by