Implementation Plan: Creating a Work
Feature ID: creating-a-work
Spec: ./spec.md
Status: Done (Retrospective)
Last updated: 2026-05-01
1. Architecture
2. Tech Choices
| Concern | Choice | Rationale |
|---|---|---|
| Repo provisioning | GitFacadeService.createRepository × 3 | Principle II |
| Atomicity | DB transaction + best-effort rollback if any repo fails | Avoid orphan rows |
| Generation dispatch | Trigger.dev work-generation task | Principle IV |
| Slug uniqueness | Per-user case-insensitive lookup | Matches GitHub repo naming |
| Form schema | Plugin form-schema-provider capability | Pipelines own their own UI |
3. Data Model
worksentity (existing) with all the fields the three flows need: name, slug, description, owner, gitProvider, deployProvider, pipeline, aiProvider, searchProvider, screenshotProvider, contentExtractor, initialPrompt, expansionFactor, generateStatus, etc.- No new tables. Each new field added over time ships as an additive migration.
4. API Surface
| Method | Endpoint | Description |
|---|---|---|
POST | /api/works | Create (AI / Manual) |
POST | /api/works/import/preview | Import dry-run |
POST | /api/works/import | Import confirmation |
5. Plugin / Web / CLI
- Plugins: form-schema-provider lets pipelines contribute fields.
- Web: separate steps under
apps/web/src/app/[locale]/works/new/for each method. - CLI:
ever-works work createcommand wraps the API.
6. Background Jobs
work-generationTrigger.dev task — dispatched on AI / Awesome Import.work-import-awesome-normalise— fan-out to normalise items after Awesome import.