|
| 1 | +# GitHub Issue Context |
| 2 | + |
| 3 | +## Source |
| 4 | + |
| 5 | +- Repository: marciomyst/SmartMovieCatalog |
| 6 | +- Issue: #11 |
| 7 | +- URL: https://github.com/marciomyst/SmartMovieCatalog/issues/11 |
| 8 | +- State: OPEN |
| 9 | +- Created: 05/02/2026 22:05:54 |
| 10 | +- Updated: 05/02/2026 22:25:51 |
| 11 | +- Milestone: M1 — Core Movie Catalog |
| 12 | + |
| 13 | +## Title |
| 14 | + |
| 15 | +Create movie |
| 16 | + |
| 17 | +## Labels |
| 18 | + |
| 19 | +- type:feature |
| 20 | +- priority:high |
| 21 | +- area:api |
| 22 | +- area:backend |
| 23 | +- area:catalog |
| 24 | +- v1 |
| 25 | + |
| 26 | +## Assignees |
| 27 | + |
| 28 | +- marciomyst |
| 29 | + |
| 30 | + |
| 31 | + |
| 32 | +## Issue Body |
| 33 | + |
| 34 | +## Summary |
| 35 | + |
| 36 | +Implement the first real product vertical slice for creating a movie in Smart Movie Catalog. |
| 37 | + |
| 38 | +This issue replaces part of the scaffold direction with an actual movie catalog behavior, while keeping the implementation intentionally simple and aligned with the current Clean Architecture structure. |
| 39 | + |
| 40 | +## Goal |
| 41 | + |
| 42 | +Allow a user to create a movie with basic metadata through the application. |
| 43 | + |
| 44 | +## Scope |
| 45 | + |
| 46 | +- Add a create movie API endpoint. |
| 47 | +- Define explicit request/response DTOs in `SmartMovieCatalog.Contracts`. |
| 48 | +- Add minimal application use case/orchestration in `SmartMovieCatalog.Application`. |
| 49 | +- Add minimal domain model or domain representation only if required by the behavior. |
| 50 | +- Persist or store the movie using the currently accepted persistence approach. |
| 51 | +- Return a stable response containing the created movie identifier and main movie data. |
| 52 | +- Add/update basic frontend flow if the movie creation page already exists or is part of this slice. |
| 53 | +- Update documentation if API contracts or architecture behavior changes. |
| 54 | + |
| 55 | +## Suggested API |
| 56 | + |
| 57 | +```http |
| 58 | +POST /api/movies |
| 59 | +
|
| 60 | +{ |
| 61 | + "title": "Central do Brasil", |
| 62 | + "originalTitle": "Central do Brasil", |
| 63 | + "releaseYear": 1998, |
| 64 | + "countryCode": "BR", |
| 65 | + "originalLanguage": "pt-BR", |
| 66 | + "genres": ["Drama"], |
| 67 | + "director": "Walter Salles", |
| 68 | + "synopsis": "A retired teacher and a young boy travel through Brazil in search of his father.", |
| 69 | + "durationMinutes": 110, |
| 70 | + "ageRating": "12" |
| 71 | +} |
| 72 | +``` |
| 73 | + |
| 74 | + |
| 75 | +### Acceptance Criteria |
| 76 | + |
| 77 | +- A movie can be created through the API. |
| 78 | +- The endpoint returns `201 Created` when creation succeeds. |
| 79 | +- The response includes the created movie ID. |
| 80 | +- Required fields are validated. |
| 81 | +- Invalid input returns a consistent validation/error response. |
| 82 | +- Business rules do not live directly in controllers. |
| 83 | +- API contracts do not expose persistence models. |
| 84 | +- The implementation respects Clean Architecture dependency direction. |
| 85 | +- No authentication is required in this issue. |
| 86 | +- No Gemini, SignalR, CQRS, Wolverine, RAG, semantic search, or event-driven behavior is introduced. |
| 87 | + |
| 88 | +### Technical Notes |
| 89 | + |
| 90 | +- Keep the first implementation small. |
| 91 | +- Prefer explicit DTOs. |
| 92 | +- Do not introduce speculative abstractions. |
| 93 | +- If persistence is not fully implemented yet, this issue depends on the persistence foundation decision or must use a clearly documented temporary storage approach. |
| 94 | +- Do not leak database-specific details through API responses. |
| 95 | + |
| 96 | +### Out of Scope |
| 97 | + |
| 98 | +- Poster upload. |
| 99 | +- Gemini Vision analysis. |
| 100 | +- SignalR notifications. |
| 101 | +- Authentication/authorization. |
| 102 | +- Semantic search. |
| 103 | +- Advanced duplicate detection. |
| 104 | +- Bulk import. |
| 105 | +- TMDb integration. |
| 106 | + |
| 107 | +## Comments |
| 108 | + |
| 109 | +_No comments_ |
| 110 | + |
| 111 | +## Instructions for Spec Kit |
| 112 | + |
| 113 | +Use this GitHub issue as the primary source of truth. |
| 114 | + |
| 115 | +Convert the issue into a Spec Kit feature specification before creating the implementation plan. |
| 116 | + |
| 117 | +Preserve: |
| 118 | + |
| 119 | +- business goal; |
| 120 | +- user stories; |
| 121 | +- acceptance criteria; |
| 122 | +- technical constraints; |
| 123 | +- non-goals; |
| 124 | +- dependencies; |
| 125 | +- open questions. |
| 126 | + |
| 127 | +If information is missing, add it under a clearly marked **Clarifications Needed** section instead of inventing requirements. |
| 128 | + |
| 129 | +If the issue conflicts with existing project documentation, explicitly call out the conflict. |
| 130 | + |
| 131 | +Prefer a small, incremental implementation plan aligned with the repository's existing architecture, folder structure, language, framework, and conventions. |
0 commit comments