Cleanup
This commit is contained in:
twotalesanimation
@@ -1,75 +0,0 @@
|
||||
We need to update how shotcodes are generated and stored.
|
||||
|
||||
to do this:
|
||||
|
||||
projects need a new field called
|
||||
- showId (1–10 chars, `[A-Z0-9_]`, uppercase)
|
||||
- projectType (`STANDARD` or `EPISODIC`)
|
||||
|
||||
# Shot Naming Conventions
|
||||
|
||||
## Shot Code Format
|
||||
|
||||
Shot codes are auto-generated on creation
|
||||
|
||||
### Standard Project
|
||||
|
||||
```
|
||||
{SHOW_ID}_{SCENE}_{SHOT_NUMBER}
|
||||
```
|
||||
|
||||
Example: `PRJX_10_0010`
|
||||
|
||||
### Episodic Project
|
||||
|
||||
```
|
||||
{SHOW_ID}_{EPISODE}_{SCENE}_{SHOT_NUMBER}
|
||||
```
|
||||
|
||||
Example: `PRJX_101_10_0010`
|
||||
|
||||
---
|
||||
|
||||
## Segments
|
||||
|
||||
| Segment | Source | Notes |
|
||||
|---|---|---|
|
||||
| `SHOW_ID` | `Project.showId` | 1–10 chars, letters/numbers/underscores, stored uppercase. Set once on the project. |
|
||||
| `EPISODE` | `Shot.episode` | Only present on `EPISODIC` projects. Free-text, stored uppercase (e.g. `EP01`). |
|
||||
| `SCENE` | `Shot.scene` | Required on every shot. Stored uppercase (e.g. `SC010`). |
|
||||
| `SHOT_NUMBER` | Auto-incremented | 4-digit zero-padded integer, increments by 10 (e.g. `0010`, `0020`). |
|
||||
|
||||
---
|
||||
|
||||
## Auto-Incrementing Shot Numbers
|
||||
|
||||
The shot number is scoped to the **scene within a project** (and additionally to the **episode** for episodic projects):
|
||||
|
||||
- On create, the system queries `MAX(shotNumber)` for all shots sharing the same `projectId + scene` (+ `episode` for episodic).
|
||||
- The new shot number = `MAX + 10`, starting at `0010` when no prior shots exist in that scene.
|
||||
- The number is zero-padded to 4 digits.
|
||||
|
||||
This means shot numbers are **non-contiguous by design** — gaps allow shots to be inserted between existing ones without renumbering.
|
||||
|
||||
When a shot is **duplicated**, it inherits the scene/episode of the original and receives the next available shot number in that scope. Only the trailing 4-digit segment in the code is replaced; the rest of the code is preserved.
|
||||
|
||||
---
|
||||
|
||||
## Where Fields Come From
|
||||
|
||||
| Field | Model | Required? |
|
||||
|---|---|---|
|
||||
| `showId` | `Project` | Yes — validated 1–10 chars, `[A-Z0-9_]` |
|
||||
| `projectCode` | `Project` | Yes — unique across all projects, used for billing/reference (not in shot code) |
|
||||
| `projectType` | `Project` | Yes — `STANDARD` or `EPISODIC`; controls whether episode segment is included |
|
||||
| `scene` | `Shot` | Yes — required by `shotSchema` |
|
||||
| `episode` | `Shot` | Optional — only meaningful (and included in code) when `projectType === EPISODIC` |
|
||||
| `shotGroup` | `Shot` | Optional — organisational grouping only, not part of the shot code |
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- `projectCode` is a separate billing/admin identifier on the Project and does **not** appear in shot codes. Shot codes use `showId` instead.
|
||||
- Shot codes are not regenerated on edit — if scene or episode values change after creation, the stored `shotCode` will not reflect those changes.
|
||||
- All string segments are uppercased before being written into the code.
|
||||
-300
@@ -1,300 +0,0 @@
|
||||
# FeedBack — App Overview & Status
|
||||
|
||||
> Last updated: May 2026
|
||||
|
||||
---
|
||||
|
||||
## What It Is
|
||||
|
||||
FeedBack is a self-hosted VFX review and approval platform for boutique studios. Internal teams (admins, producers, supervisors, artists) manage projects and shots, upload versioned video files, draw frame-accurate annotations, and leave timestamped comments. External clients receive token-gated review links and can approve, reject, or request changes — no login required.
|
||||
|
||||
---
|
||||
|
||||
## Current Status
|
||||
|
||||
All core features are built and functional:
|
||||
|
||||
| Area | Status |
|
||||
|------|--------|
|
||||
| Auth (login, roles, sessions) | ✅ Complete |
|
||||
| Projects & shots (CRUD) | ✅ Complete |
|
||||
| Version upload (local storage) | ✅ Complete |
|
||||
| Review player + frame timeline | ✅ Complete |
|
||||
| Annotation drawing (canvas) | ✅ Complete — persists across frame navigation |
|
||||
| Frame-anchored comments + replies | ✅ Complete |
|
||||
| Approval workflow | ✅ Complete |
|
||||
| Client management (internal) | ✅ Complete |
|
||||
| Client portal (external, token-gated) | ✅ Complete |
|
||||
| Tokenized review links | ✅ Complete |
|
||||
| Slack notifications | ✅ Complete (optional webhook) |
|
||||
| In-app notifications | ✅ Complete |
|
||||
| Email (nodemailer) | ⚙️ Wired, requires SMTP env vars |
|
||||
| S3 / R2 / MinIO / B2 storage | ⚙️ Wired, requires env vars |
|
||||
| Docker Compose deployment | ✅ Complete |
|
||||
|
||||
---
|
||||
|
||||
## Route Map
|
||||
|
||||
### Public / Unauthenticated
|
||||
|
||||
| Route | Description |
|
||||
|-------|-------------|
|
||||
| `/login` | Credentials sign-in page |
|
||||
| `/client/[token]` | External client project overview — lists shots visible to client |
|
||||
| `/client/[token]/review/[versionId]` | External client review page — video player, comments, approve/reject |
|
||||
|
||||
### Dashboard (requires login)
|
||||
|
||||
| Route | Description |
|
||||
|-------|-------------|
|
||||
| `/dashboard` | Home — stats cards, shot queue, recent activity |
|
||||
| `/projects` | Project list |
|
||||
| `/projects/[id]` | Project detail — shot grid, stats |
|
||||
| `/projects/[id]/shots/[shotId]` | Shot detail — version list, approval history |
|
||||
| `/review/[versionId]` | Full-screen review player (internal) |
|
||||
| `/clients` | Client list — ADMIN/PRODUCER only |
|
||||
| `/clients/[clientId]` | Client detail — linked projects, active review sessions |
|
||||
| `/settings` | User profile settings |
|
||||
|
||||
---
|
||||
|
||||
## API Routes
|
||||
|
||||
### Internal (authenticated)
|
||||
|
||||
| Method | Route | Purpose |
|
||||
|--------|-------|---------|
|
||||
| GET/POST | `/api/projects` | List / create projects |
|
||||
| GET/POST/DELETE | `/api/shots` | Shot CRUD |
|
||||
| GET | `/api/versions/[versionId]/comments` | Fetch comments for a version |
|
||||
| GET | `/api/versions/[versionId]/annotations` | Fetch annotations for a version |
|
||||
| GET/POST | `/api/clients` | List / create clients |
|
||||
| GET/POST/DELETE | `/api/review-sessions` | Manage tokenized review links |
|
||||
| GET/POST | `/api/notifications` | In-app notification CRUD |
|
||||
| GET | `/api/files/[...key]` | Serve locally-stored files (no auth) |
|
||||
| POST | `/api/upload/local` | Local file upload handler |
|
||||
|
||||
### Client portal (no auth — token-gated)
|
||||
|
||||
| Method | Route | Purpose |
|
||||
|--------|-------|---------|
|
||||
| GET | `/api/client/[token]/project` | Project + shots (CLIENT_REVIEW / REVISIONS / APPROVED / FINAL only) |
|
||||
| GET | `/api/client/[token]/versions/[versionId]` | Version detail + comments |
|
||||
| POST | `/api/client/[token]/approve` | Submit approval decision |
|
||||
| POST | `/api/client/[token]/comment` | Post a comment |
|
||||
|
||||
---
|
||||
|
||||
## Server Actions (`/actions`)
|
||||
|
||||
| File | Exports |
|
||||
|------|---------|
|
||||
| `projects.ts` | `createProject`, `updateProject` |
|
||||
| `shots.ts` | `createShot`, `updateShotStatus`, `getShotById` |
|
||||
| `versions.ts` | `createVersion`, `setLatestVersion` |
|
||||
| `comments.ts` | `addComment`, `addReply`, `resolveComment` |
|
||||
| `annotations.ts` | `saveAnnotation`, `getAnnotationsForVersion`, `getAnnotationsForFrame` |
|
||||
| `approvals.ts` | `submitApproval` |
|
||||
|
||||
---
|
||||
|
||||
## Database Schema
|
||||
|
||||
### Enums
|
||||
|
||||
| Enum | Values |
|
||||
|------|--------|
|
||||
| `Role` | `ADMIN` · `PRODUCER` · `SUPERVISOR` · `ARTIST` · `CLIENT` |
|
||||
| `ProjectStatus` | `ACTIVE` · `ON_HOLD` · `COMPLETED` · `ARCHIVED` |
|
||||
| `ShotStatus` | `WAITING` · `IN_PROGRESS` · `INTERNAL_REVIEW` · `CLIENT_REVIEW` · `REVISIONS` · `APPROVED` · `FINAL` |
|
||||
| `ShotPriority` | `LOW` · `NORMAL` · `HIGH` · `URGENT` |
|
||||
| `ApprovalStatus` | `PENDING_REVIEW` · `APPROVED` · `REJECTED` · `NEEDS_CHANGES` |
|
||||
| `NotificationType` | `VERSION_UPLOADED` · `FEEDBACK_ADDED` · `SHOT_APPROVED` · `SHOT_REJECTED` · `COMMENT_REPLY` · `MENTION` · `REVISION_REQUESTED` |
|
||||
|
||||
### Models
|
||||
|
||||
#### `User`
|
||||
Core identity. Has a `role` (see enum). `passwordHash` used for credentials login. NextAuth `Account` and `Session` models hang off this.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `id` | cuid | PK |
|
||||
| `email` | String | unique |
|
||||
| `role` | Role | default `ARTIST` |
|
||||
| `passwordHash` | String? | bcrypt hash |
|
||||
| `isActive` | Boolean | soft-disable |
|
||||
|
||||
#### `Client`
|
||||
Represents an external studio or client company.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `company` | String | |
|
||||
| `contactPerson` | String | |
|
||||
| `email` | String | unique |
|
||||
| `phone`, `notes`, `logoUrl` | optional | |
|
||||
|
||||
#### `ClientAccess`
|
||||
Junction between a `User` (with `CLIENT` role) and a `Client` record. Allows a portal user account to be linked to a specific client company.
|
||||
|
||||
#### `Project`
|
||||
Top-level container. Linked to an optional `Client`, `producer` (User), and `supervisor` (User).
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `code` | String | unique, used as short label |
|
||||
| `status` | ProjectStatus | default `ACTIVE` |
|
||||
| `clientId` | String? | nullable |
|
||||
| `slackWebhook` | String? | per-project Slack alerts |
|
||||
|
||||
#### `Shot`
|
||||
Belongs to a `Project`. Tracks pipeline status and priority.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `shotCode` | String | unique per project |
|
||||
| `sequence` | String? | grouping label |
|
||||
| `status` | ShotStatus | default `WAITING` |
|
||||
| `priority` | ShotPriority | default `NORMAL` |
|
||||
| `fps` | Float | default 24 |
|
||||
| `frameStart`, `frameEnd` | Int? | optional frame range |
|
||||
|
||||
> **Client visibility rule**: only shots with status `CLIENT_REVIEW`, `REVISIONS`, `APPROVED`, or `FINAL` are returned by the client portal API.
|
||||
|
||||
#### `Version`
|
||||
A specific upload for a shot. Multiple versions per shot; only one has `isLatest = true`.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `versionNumber` | Int | unique per shot |
|
||||
| `fileUrl` | String | path/URL to video |
|
||||
| `fileSize` | BigInt? | serialized to string in API responses |
|
||||
| `fps` | Float | |
|
||||
| `approvalStatus` | ApprovalStatus | default `PENDING_REVIEW` |
|
||||
| `isLatest` | Boolean | |
|
||||
|
||||
#### `Comment`
|
||||
Frame-anchored comment on a version. Supports replies via `CommentReply`.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `frameNumber` | Int | exact frame |
|
||||
| `timestamp` | Float | seconds |
|
||||
| `text` | Text | |
|
||||
| `isResolved` | Boolean | |
|
||||
|
||||
#### `CommentReply`
|
||||
Flat child of `Comment`. No threading beyond one level.
|
||||
|
||||
#### `Annotation`
|
||||
Canvas drawing saved against a version + frame. `drawingData` is JSON containing an array of `AnnotationShape` objects with normalized (0–1) coordinates.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `frameNumber` | Int | |
|
||||
| `drawingData` | Json | `{ shapes, canvasWidth, canvasHeight, version }` |
|
||||
| `color` | String | hex, default `#ef4444` |
|
||||
| `isVisible` | Boolean | soft-hide |
|
||||
| `commentId` | String? | optional companion comment link |
|
||||
|
||||
#### `Approval`
|
||||
Immutable approval record created each time a user submits a decision. The version's `approvalStatus` is updated separately.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `status` | ApprovalStatus | |
|
||||
| `notes` | Text? | |
|
||||
|
||||
#### `Notification`
|
||||
In-app notification for a user.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `type` | NotificationType | |
|
||||
| `data` | Json? | extra context (versionId, shotCode, etc.) |
|
||||
| `isRead` | Boolean | |
|
||||
|
||||
#### `ReviewSession`
|
||||
A tokenized, time-limited review link for external clients. Tied to a `Project`.
|
||||
|
||||
| Key field | Type | Notes |
|
||||
|-----------|------|-------|
|
||||
| `token` | String | unique cuid, used in client portal URLs |
|
||||
| `label` | String? | friendly name shown to client |
|
||||
| `email` | String? | recipient email |
|
||||
| `expiresAt` | DateTime | |
|
||||
| `isActive` | Boolean | can be deactivated manually |
|
||||
| `accessCount` | Int | incremented on each portal visit |
|
||||
|
||||
---
|
||||
|
||||
## Key Component Map
|
||||
|
||||
```
|
||||
components/
|
||||
player/
|
||||
ReviewPlayer.tsx — Forwardref player, keyboard shortcuts, fullscreen
|
||||
FrameTimeline.tsx — Canvas ruler with comment/annotation markers
|
||||
PlaybackControls.tsx — Transport bar, speed selector, annotation toggle
|
||||
annotations/
|
||||
AnnotationCanvas.tsx — Canvas overlay; per-frame shape map persists navigation
|
||||
AnnotationTools.tsx — Tool/colour/stroke picker (shown when annotating)
|
||||
comments/
|
||||
CommentPanel.tsx — Comment list, filter, reply, resolve; seekToFrame on click
|
||||
versions/
|
||||
VersionUpload.tsx — Drag-and-drop uploader
|
||||
VersionList.tsx — Version history with approval badges
|
||||
shots/
|
||||
ShotCard.tsx — Shot grid card with status dropdown
|
||||
NewShotDialog.tsx — Create shot form
|
||||
projects/
|
||||
ProjectCard.tsx — Project list card
|
||||
NewProjectDialog.tsx — Create project form
|
||||
clients/
|
||||
NewClientDialog.tsx — Create client form
|
||||
ShareReviewDialog.tsx — Generate tokenized review link
|
||||
ReviewSessionList.tsx — Active sessions with copy/deactivate actions
|
||||
dashboard/
|
||||
StatsCards.tsx — Top-level counts
|
||||
ShotQueue.tsx — Shots needing attention
|
||||
RecentActivity.tsx — Latest version/comment events
|
||||
layout/
|
||||
Sidebar.tsx — Nav + role-based link visibility
|
||||
Header.tsx — Breadcrumb + notification bell
|
||||
NotificationBell.tsx — Dropdown of unread notifications
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Auth & Roles
|
||||
|
||||
Authentication uses **NextAuth v5** with a Credentials provider (email + bcrypt password). Sessions are JWT-based.
|
||||
|
||||
| Role | Access |
|
||||
|------|--------|
|
||||
| `ADMIN` | Full access including user management, client management |
|
||||
| `PRODUCER` | Full project/shot/version access, client management |
|
||||
| `SUPERVISOR` | Full project/shot/version access, no client management |
|
||||
| `ARTIST` | Own shots and versions; can comment |
|
||||
| `CLIENT` | Dashboard login only (legacy); primary access via portal token links |
|
||||
|
||||
The **client portal** routes (`/client/[token]/*` and `/api/client/[token]/*`) bypass auth entirely — access is controlled by token validity, `isActive`, and `expiresAt`.
|
||||
|
||||
---
|
||||
|
||||
## Storage
|
||||
|
||||
Controlled by `STORAGE_PROVIDER` env var. Currently defaults to `local` (files saved in `/public/uploads/`, served via `/api/files/[...key]`). Switching to S3/R2/B2/MinIO/UploadThing requires only env var changes.
|
||||
|
||||
---
|
||||
|
||||
## Environment Variables (minimum for local dev)
|
||||
|
||||
```env
|
||||
DATABASE_URL="postgresql://user:pass@localhost:5432/feedback"
|
||||
AUTH_SECRET="<32-char random string>"
|
||||
NEXTAUTH_URL="http://localhost:3000"
|
||||
NEXT_PUBLIC_APP_URL="http://localhost:3000"
|
||||
STORAGE_PROVIDER="local"
|
||||
```
|
||||
@@ -1,400 +0,0 @@
|
||||
Build a modern web-based VFX review and approval platform prototype focused on simplicity, speed, and reliability for boutique VFX/animation studios.
|
||||
|
||||
The goal is NOT to compete with enterprise systems immediately.
|
||||
|
||||
The goal is:
|
||||
|
||||
* dead simple uploads
|
||||
* fast review cycles
|
||||
* frame-accurate feedback
|
||||
* artist/client collaboration
|
||||
* approval tracking
|
||||
* production-ready architecture
|
||||
|
||||
The UX should feel modern, cinematic, lightweight, and extremely responsive.
|
||||
|
||||
Tech stack requirements:
|
||||
|
||||
* Next.js latest App Router
|
||||
* TypeScript
|
||||
* TailwindCSS
|
||||
* shadcn/ui
|
||||
* PostgreSQL
|
||||
* Prisma ORM
|
||||
* React Query / TanStack Query
|
||||
* UploadThing or S3-compatible uploads
|
||||
* Server Actions where appropriate
|
||||
* Docker support
|
||||
* Self-hostable architecture
|
||||
* Dark mode first
|
||||
|
||||
The system should support:
|
||||
|
||||
* clients
|
||||
* projects
|
||||
* shots
|
||||
* versions
|
||||
* comments
|
||||
* annotations
|
||||
* approvals
|
||||
|
||||
# CORE GOAL
|
||||
|
||||
Artists upload shot versions.
|
||||
|
||||
Clients and supervisors can:
|
||||
|
||||
* watch versions
|
||||
* pause on frames
|
||||
* leave timestamped comments
|
||||
* draw annotations directly on frames
|
||||
* approve/reject versions
|
||||
|
||||
Everything should feel frictionless.
|
||||
|
||||
# DATA MODEL
|
||||
|
||||
## CLIENTS
|
||||
|
||||
* company
|
||||
* contact person
|
||||
* email
|
||||
|
||||
## PROJECTS
|
||||
|
||||
* project name
|
||||
* code
|
||||
* linked client
|
||||
* status
|
||||
* due dates
|
||||
|
||||
## SHOTS
|
||||
|
||||
* shot code
|
||||
* sequence
|
||||
* description
|
||||
* status
|
||||
* assigned artist
|
||||
* priority
|
||||
|
||||
Statuses:
|
||||
|
||||
* Waiting
|
||||
* In Progress
|
||||
* Internal Review
|
||||
* Client Review
|
||||
* Revisions
|
||||
* Approved
|
||||
* Final
|
||||
|
||||
## VERSIONS
|
||||
|
||||
Each shot can have many versions.
|
||||
|
||||
Fields:
|
||||
|
||||
* version number
|
||||
* upload file
|
||||
* thumbnail
|
||||
* artist
|
||||
* upload date
|
||||
* notes
|
||||
* fps
|
||||
* duration
|
||||
* frame count
|
||||
* approval status
|
||||
|
||||
Approval statuses:
|
||||
|
||||
* Pending Review
|
||||
* Approved
|
||||
* Rejected
|
||||
* Needs Changes
|
||||
|
||||
Support:
|
||||
|
||||
* mp4
|
||||
* mov
|
||||
* jpg sequences
|
||||
* png sequences
|
||||
|
||||
# VIDEO REVIEW PLAYER
|
||||
|
||||
Build a custom review player optimized for frame review.
|
||||
|
||||
Features:
|
||||
|
||||
* frame stepping
|
||||
* JKL playback
|
||||
* timeline scrubbing
|
||||
* timestamp display
|
||||
* frame number display
|
||||
* fullscreen
|
||||
* playback speed controls
|
||||
|
||||
VERY IMPORTANT:
|
||||
Comments must attach to:
|
||||
|
||||
* exact frame number
|
||||
* timestamp
|
||||
* version
|
||||
|
||||
Example:
|
||||
Frame 115:
|
||||
"Tracking slips here."
|
||||
|
||||
# FRAME-ACCURATE COMMENTS
|
||||
|
||||
Users can:
|
||||
|
||||
* pause playback
|
||||
* click "Add Comment"
|
||||
* comment attaches to exact frame
|
||||
|
||||
Comment structure:
|
||||
|
||||
* author
|
||||
* frame number
|
||||
* timestamp
|
||||
* text
|
||||
* resolved/unresolved
|
||||
* replies
|
||||
* created date
|
||||
|
||||
Allow threaded replies.
|
||||
|
||||
# DRAW-OVER ANNOTATIONS
|
||||
|
||||
Users should be able to:
|
||||
|
||||
* draw directly on paused frame
|
||||
* arrows
|
||||
* circles
|
||||
* freehand lines
|
||||
* rectangles
|
||||
|
||||
Annotations must save:
|
||||
|
||||
* frame number
|
||||
* vector drawing data
|
||||
* author
|
||||
* linked comment
|
||||
|
||||
Allow:
|
||||
|
||||
* toggling annotations
|
||||
* multiple annotations per frame
|
||||
|
||||
Use HTML canvas or Konva.js.
|
||||
|
||||
# REVIEW WORKFLOW
|
||||
|
||||
Implement a lightweight approval pipeline.
|
||||
|
||||
Review statuses:
|
||||
|
||||
* Pending
|
||||
* Internal Approved
|
||||
* Client Approved
|
||||
* Needs Changes
|
||||
* Final Approved
|
||||
|
||||
Clients should be able to:
|
||||
|
||||
* approve version
|
||||
* reject version
|
||||
* request revisions
|
||||
|
||||
Artists should:
|
||||
|
||||
* receive notifications
|
||||
* upload new versions
|
||||
* compare against previous versions
|
||||
|
||||
# SIDE-BY-SIDE VERSION COMPARISON
|
||||
|
||||
Allow:
|
||||
|
||||
* A/B version comparison
|
||||
* wipe comparison slider
|
||||
* previous version overlay
|
||||
|
||||
Useful for:
|
||||
|
||||
* comp revisions
|
||||
* cleanup changes
|
||||
* color tweaks
|
||||
|
||||
# NOTIFICATIONS
|
||||
|
||||
Add notification system.
|
||||
|
||||
Examples:
|
||||
|
||||
* New version uploaded
|
||||
* New feedback added
|
||||
* Shot approved
|
||||
* Shot rejected
|
||||
* Comment reply added
|
||||
|
||||
Support:
|
||||
|
||||
* in-app notifications
|
||||
* email notifications
|
||||
* Slack integration
|
||||
|
||||
# SLACK INTEGRATION
|
||||
|
||||
Integrate with Slack webhooks.
|
||||
|
||||
Examples:
|
||||
|
||||
```plaintext id="6j6t2g"
|
||||
SH020 v004 approved by client
|
||||
```
|
||||
|
||||
```plaintext id="p5v8rz"
|
||||
New feedback added on SH035 frame 122
|
||||
```
|
||||
|
||||
Allow configurable channels per project.
|
||||
|
||||
# FILE STORAGE
|
||||
|
||||
Use S3-compatible architecture.
|
||||
|
||||
Support:
|
||||
|
||||
* local storage
|
||||
* Backblaze B2
|
||||
* AWS S3
|
||||
* Cloudflare R2
|
||||
* self-hosted MinIO
|
||||
|
||||
Generate:
|
||||
|
||||
* thumbnails
|
||||
* proxies
|
||||
* poster frames
|
||||
|
||||
# SECURITY
|
||||
|
||||
Implement:
|
||||
|
||||
* signed upload URLs
|
||||
* secure client review links
|
||||
* expiring review sessions
|
||||
* role permissions
|
||||
|
||||
Roles:
|
||||
|
||||
* Admin
|
||||
* Producer
|
||||
* Supervisor
|
||||
* Artist
|
||||
* Client
|
||||
|
||||
Clients should ONLY see:
|
||||
|
||||
* assigned projects
|
||||
* approved review material
|
||||
|
||||
# CLIENT REVIEW PORTAL
|
||||
|
||||
Clients should have a very simple portal:
|
||||
|
||||
* open project
|
||||
* review shots
|
||||
* leave notes
|
||||
* approve/reject
|
||||
|
||||
No production complexity exposed.
|
||||
|
||||
Keep it clean and minimal.
|
||||
|
||||
# DASHBOARD
|
||||
|
||||
Internal dashboard should show:
|
||||
|
||||
* shots awaiting review
|
||||
* shots needing revisions
|
||||
* approved shots
|
||||
* overdue shots
|
||||
* recent comments
|
||||
* artist assignments
|
||||
|
||||
# UI REQUIREMENTS
|
||||
|
||||
The UI should feel:
|
||||
|
||||
* modern
|
||||
* film-industry oriented
|
||||
* dark themed
|
||||
* fast
|
||||
* minimal clutter
|
||||
|
||||
Inspiration:
|
||||
|
||||
* Frame.io
|
||||
* SyncSketch
|
||||
* ShotGrid Review
|
||||
* Vimeo Review
|
||||
|
||||
But simpler and cleaner.
|
||||
|
||||
# IMPORTANT PERFORMANCE REQUIREMENTS
|
||||
|
||||
Optimize for:
|
||||
|
||||
* fast scrubbing
|
||||
* lightweight annotation rendering
|
||||
* low-latency comments
|
||||
* proxy playback
|
||||
|
||||
Avoid bloated enterprise complexity.
|
||||
|
||||
# BONUS FEATURES
|
||||
|
||||
If possible implement:
|
||||
|
||||
* LUT viewing
|
||||
* EXR sequence support
|
||||
* burn-ins
|
||||
* watermarking
|
||||
* presentation playlists
|
||||
* review sessions
|
||||
* audio comments
|
||||
* webhook API
|
||||
* task linking
|
||||
* AI feedback summaries
|
||||
|
||||
# ARCHITECTURE
|
||||
|
||||
Design the system so it can later integrate into a larger VFX pipeline platform including:
|
||||
|
||||
* bidding
|
||||
* production tracking
|
||||
* artist scheduling
|
||||
* invoicing
|
||||
* asset management
|
||||
* render tracking
|
||||
|
||||
Avoid hardcoding review-specific assumptions.
|
||||
|
||||
# MVP PRIORITY
|
||||
|
||||
Prioritize these features FIRST:
|
||||
|
||||
1. Upload video
|
||||
2. Scrub by frame
|
||||
3. Add timestamp comments
|
||||
4. Draw annotations
|
||||
5. Approve/reject versions
|
||||
6. View feedback history
|
||||
|
||||
Those six features are the core product.
|
||||
|
||||
Everything else is secondary.
|
||||
|
||||
The app should feel like:
|
||||
“A modern lightweight review system that actually respects artists’ time.”
|
||||
-916
@@ -1,916 +0,0 @@
|
||||
Update the existing FeedBack platform to add a lightweight production tracking system directly into the current architecture.
|
||||
|
||||
IMPORTANT:
|
||||
Do NOT redesign the app from scratch.
|
||||
Do NOT build enterprise production management.
|
||||
Do NOT attempt full ShotGrid/ftrack complexity.
|
||||
|
||||
The goal is:
|
||||
|
||||
* simple
|
||||
* fast
|
||||
* usable
|
||||
* production-focused
|
||||
* minimal friction
|
||||
|
||||
FeedBack already has:
|
||||
|
||||
* projects
|
||||
* shots
|
||||
* versions
|
||||
* reviews
|
||||
* comments
|
||||
* approvals
|
||||
* client portal
|
||||
|
||||
We are now extending it into a lightweight VFX production tracker.
|
||||
|
||||
The philosophy should be:
|
||||
“A clean operational layer for boutique VFX studios.”
|
||||
|
||||
---
|
||||
|
||||
# HIGH LEVEL GOAL
|
||||
|
||||
Add:
|
||||
|
||||
* production tracking
|
||||
* tasks
|
||||
* artist assignment
|
||||
* deadlines
|
||||
* kanban boards
|
||||
* simple scheduling
|
||||
* upload/review workflow integration
|
||||
|
||||
The existing review/version system should become directly attached to production tasks.
|
||||
|
||||
IMPORTANT:
|
||||
The TASK should become the core production object.
|
||||
|
||||
Architecture should evolve toward:
|
||||
|
||||
```plaintext id="c2o8kh"
|
||||
Project
|
||||
├── Shots
|
||||
│ ├── Tasks
|
||||
│ │ ├── Versions
|
||||
│ │ ├── Comments
|
||||
│ │ └── Approvals
|
||||
│
|
||||
├── Assets
|
||||
│ ├── Tasks
|
||||
│ │ ├── Versions
|
||||
│ │ ├── Comments
|
||||
│ │ └── Approvals
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# NEW CORE CONCEPTS
|
||||
|
||||
Add:
|
||||
|
||||
* Assets
|
||||
* Tasks
|
||||
* Artist Assignment
|
||||
* Kanban Views
|
||||
* Deadlines
|
||||
* Task Statuses
|
||||
|
||||
DO NOT add:
|
||||
|
||||
* timesheets
|
||||
* complex dependencies
|
||||
* render management
|
||||
* resource planning
|
||||
* advanced scheduling
|
||||
* Gantt charts
|
||||
|
||||
Keep the system intentionally lightweight.
|
||||
|
||||
---
|
||||
|
||||
# DATABASE CHANGES
|
||||
|
||||
## NEW ENUM: `TaskStatus`
|
||||
|
||||
Add:
|
||||
|
||||
```ts
|
||||
TODO
|
||||
IN_PROGRESS
|
||||
REVIEW
|
||||
CHANGES
|
||||
DONE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## NEW ENUM: `TaskType`
|
||||
|
||||
Add:
|
||||
|
||||
```ts
|
||||
TRACK
|
||||
ROTO
|
||||
KEY
|
||||
COMP
|
||||
FX
|
||||
LIGHTING
|
||||
RENDER
|
||||
ANIMATION
|
||||
MODEL
|
||||
TEXTURE
|
||||
RIG
|
||||
LOOKDEV
|
||||
GENERAL
|
||||
```
|
||||
|
||||
Allow custom values later.
|
||||
|
||||
---
|
||||
|
||||
# NEW MODEL: `Asset`
|
||||
|
||||
Assets should behave similarly to shots.
|
||||
|
||||
Fields:
|
||||
|
||||
* id
|
||||
* projectId
|
||||
* assetCode
|
||||
* name
|
||||
* description
|
||||
* status
|
||||
* priority
|
||||
* assignedLeadId
|
||||
* dueDate
|
||||
* createdAt
|
||||
* updatedAt
|
||||
|
||||
Assets belong to:
|
||||
|
||||
* Project
|
||||
|
||||
Assets contain:
|
||||
|
||||
* Tasks
|
||||
|
||||
---
|
||||
|
||||
# NEW MODEL: `Task`
|
||||
|
||||
This becomes the core operational object.
|
||||
|
||||
Fields:
|
||||
|
||||
* id
|
||||
* title
|
||||
* description
|
||||
* type
|
||||
* status
|
||||
* priority
|
||||
* dueDate
|
||||
* estimatedHours
|
||||
* sortOrder
|
||||
* shotId (nullable)
|
||||
* assetId (nullable)
|
||||
* assignedArtistId (nullable)
|
||||
* createdById
|
||||
* createdAt
|
||||
* updatedAt
|
||||
|
||||
Rules:
|
||||
|
||||
* task belongs to either:
|
||||
|
||||
* a Shot
|
||||
* or an Asset
|
||||
* never both
|
||||
|
||||
Tasks can contain:
|
||||
|
||||
* Versions
|
||||
* Comments
|
||||
* Approvals
|
||||
|
||||
IMPORTANT:
|
||||
Refactor existing Version model:
|
||||
|
||||
* versions should optionally belong to a Task
|
||||
* NOT only a Shot
|
||||
|
||||
This is critical.
|
||||
|
||||
---
|
||||
|
||||
# VERSION REFACTOR
|
||||
|
||||
Currently:
|
||||
|
||||
```plaintext id="vw7z0h"
|
||||
Shot -> Versions
|
||||
```
|
||||
|
||||
Refactor to:
|
||||
|
||||
```plaintext id="7wfp9e"
|
||||
Task -> Versions
|
||||
```
|
||||
|
||||
Reason:
|
||||
The review process is task-specific.
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="x4fq6o"
|
||||
SH010
|
||||
├── Track Task
|
||||
│ └── Versions
|
||||
│
|
||||
├── Roto Task
|
||||
│ └── Versions
|
||||
│
|
||||
└── Comp Task
|
||||
└── Versions
|
||||
```
|
||||
|
||||
This massively improves production clarity.
|
||||
|
||||
Still allow:
|
||||
|
||||
* shot-level overview
|
||||
* latest task version summary
|
||||
|
||||
---
|
||||
|
||||
# TASK WORKFLOW
|
||||
|
||||
Tasks should support:
|
||||
|
||||
* assignment
|
||||
* deadlines
|
||||
* uploads
|
||||
* review
|
||||
* approvals
|
||||
|
||||
Simple lifecycle:
|
||||
|
||||
```plaintext id="y8y95u"
|
||||
TODO
|
||||
→ IN_PROGRESS
|
||||
→ REVIEW
|
||||
→ CHANGES
|
||||
→ DONE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# KANBAN BOARD
|
||||
|
||||
Implement lightweight kanban production views.
|
||||
|
||||
Views:
|
||||
|
||||
* By Project
|
||||
* By Shot
|
||||
* By Asset
|
||||
* By Artist
|
||||
|
||||
Columns:
|
||||
|
||||
* Todo
|
||||
* In Progress
|
||||
* Review
|
||||
* Changes
|
||||
* Done
|
||||
|
||||
Cards should display:
|
||||
|
||||
* task title
|
||||
* shot/asset code
|
||||
* assigned artist
|
||||
* due date
|
||||
* latest version
|
||||
* comment count
|
||||
* approval state
|
||||
|
||||
Support:
|
||||
|
||||
* drag and drop
|
||||
* optimistic updates
|
||||
* instant status changes
|
||||
|
||||
Use:
|
||||
|
||||
* dnd-kit
|
||||
|
||||
NOT:
|
||||
|
||||
* giant enterprise scheduling systems
|
||||
|
||||
---
|
||||
|
||||
# NEW ROUTES
|
||||
|
||||
## Dashboard
|
||||
|
||||
Add:
|
||||
|
||||
```plaintext id="pwttmf"
|
||||
/tasks
|
||||
/tasks/[taskId]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Project Views
|
||||
|
||||
Extend:
|
||||
|
||||
```plaintext id="6yq0o5"
|
||||
/projects/[id]
|
||||
```
|
||||
|
||||
Add tabs:
|
||||
|
||||
* Shots
|
||||
* Assets
|
||||
* Tasks
|
||||
* Kanban
|
||||
* Activity
|
||||
|
||||
---
|
||||
|
||||
## Asset Views
|
||||
|
||||
Add:
|
||||
|
||||
```plaintext id="y5xj4q"
|
||||
/projects/[id]/assets/[assetId]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task Views
|
||||
|
||||
Add:
|
||||
|
||||
```plaintext id="g3fcdj"
|
||||
/tasks/[taskId]
|
||||
```
|
||||
|
||||
Task page should contain:
|
||||
|
||||
* task details
|
||||
* status
|
||||
* assignment
|
||||
* uploads
|
||||
* comments
|
||||
* review player
|
||||
* annotations
|
||||
* approval history
|
||||
|
||||
Essentially:
|
||||
task page = review page + production metadata
|
||||
|
||||
---
|
||||
|
||||
# REVIEW SYSTEM INTEGRATION
|
||||
|
||||
DO NOT duplicate review systems.
|
||||
|
||||
Existing:
|
||||
|
||||
* review player
|
||||
* comments
|
||||
* annotations
|
||||
* approvals
|
||||
|
||||
should now attach to:
|
||||
|
||||
* Task Versions
|
||||
|
||||
The review player remains mostly unchanged.
|
||||
|
||||
---
|
||||
|
||||
# VERSION UPLOAD FLOW
|
||||
|
||||
New upload flow:
|
||||
|
||||
```plaintext id="v3r0xy"
|
||||
Project
|
||||
→ Shot / Asset
|
||||
→ Task
|
||||
→ Upload Version
|
||||
```
|
||||
|
||||
Version uploads should:
|
||||
|
||||
* automatically increment version number
|
||||
* optionally notify assigned reviewers
|
||||
* optionally move task to REVIEW
|
||||
|
||||
---
|
||||
|
||||
# TASK CREATION UX
|
||||
|
||||
Allow:
|
||||
|
||||
* manual task creation
|
||||
* templates
|
||||
* quick-add buttons
|
||||
|
||||
Example:
|
||||
For shots:
|
||||
|
||||
* Add Track
|
||||
* Add Roto
|
||||
* Add Comp
|
||||
|
||||
For assets:
|
||||
|
||||
* Add Model
|
||||
* Add Texture
|
||||
* Add Rig
|
||||
|
||||
---
|
||||
|
||||
# ARTIST ASSIGNMENTS
|
||||
|
||||
Tasks should support:
|
||||
|
||||
* assigned artist
|
||||
* assigned supervisor
|
||||
* watcher/follower users
|
||||
|
||||
Add lightweight workload views:
|
||||
|
||||
* my tasks
|
||||
* due this week
|
||||
* overdue
|
||||
* awaiting review
|
||||
|
||||
---
|
||||
|
||||
# DASHBOARD IMPROVEMENTS
|
||||
|
||||
Add widgets:
|
||||
|
||||
* Tasks Due Today
|
||||
* Tasks In Review
|
||||
* Overdue Tasks
|
||||
* Latest Uploads
|
||||
* Recent Feedback
|
||||
* Artist Workload
|
||||
|
||||
---
|
||||
|
||||
# NOTIFICATIONS
|
||||
|
||||
Extend notification system.
|
||||
|
||||
New notification types:
|
||||
|
||||
```ts
|
||||
TASK_ASSIGNED
|
||||
TASK_OVERDUE
|
||||
TASK_APPROVED
|
||||
TASK_CHANGES_REQUESTED
|
||||
TASK_READY_FOR_REVIEW
|
||||
```
|
||||
|
||||
Slack examples:
|
||||
|
||||
```plaintext id="hjlwmz"
|
||||
SH010 COMP task ready for review
|
||||
```
|
||||
|
||||
```plaintext id="64q9vx"
|
||||
ASSET_CAR01 MODEL task approved
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# PERMISSIONS
|
||||
|
||||
Maintain current auth architecture.
|
||||
|
||||
Permissions:
|
||||
|
||||
* ADMIN/PRODUCER/SUPERVISOR:
|
||||
full task control
|
||||
* ARTIST:
|
||||
view assigned tasks
|
||||
upload versions
|
||||
comment
|
||||
* CLIENT:
|
||||
review approved review sessions only
|
||||
|
||||
Clients should NEVER see:
|
||||
|
||||
* kanban
|
||||
* production internals
|
||||
* task assignments
|
||||
|
||||
---
|
||||
|
||||
# UI REQUIREMENTS
|
||||
|
||||
The UI should feel:
|
||||
|
||||
* modern
|
||||
* dark-mode first
|
||||
* fast
|
||||
* clean
|
||||
* film-production oriented
|
||||
|
||||
Inspiration:
|
||||
|
||||
* Linear
|
||||
* Trello
|
||||
* Frame.io
|
||||
* ShotGrid (but MUCH simpler)
|
||||
|
||||
---
|
||||
|
||||
# IMPORTANT PRODUCT DIRECTION
|
||||
|
||||
This should feel like:
|
||||
“Trello + Frame.io specifically for boutique VFX studios.”
|
||||
|
||||
NOT:
|
||||
“Enterprise production software.”
|
||||
|
||||
Keep:
|
||||
|
||||
* interactions fast
|
||||
* layouts uncluttered
|
||||
* onboarding minimal
|
||||
|
||||
---
|
||||
---
|
||||
|
||||
# CLIENT REVIEW SHARING FLOW
|
||||
|
||||
Add a lightweight “Share With Client” workflow directly into the production/review system.
|
||||
|
||||
The goal is:
|
||||
|
||||
* one-click client sharing
|
||||
* minimal friction
|
||||
* no complicated publishing workflows
|
||||
* tightly integrated into task review
|
||||
|
||||
This should feel extremely simple for producers/supervisors.
|
||||
|
||||
---
|
||||
|
||||
# CORE CONCEPT
|
||||
|
||||
A task version can move through two review stages:
|
||||
|
||||
```plaintext id="y5ibk0"
|
||||
Internal Review
|
||||
→ Client Review
|
||||
→ Approved / Changes
|
||||
```
|
||||
|
||||
When a user clicks:
|
||||
|
||||
```plaintext id="l5l90p"
|
||||
Share With Client
|
||||
```
|
||||
|
||||
the system should:
|
||||
|
||||
* mark the task/version as ready for client review
|
||||
* expose the version in the client portal
|
||||
* optionally notify the client
|
||||
* generate/share a review link if needed
|
||||
|
||||
IMPORTANT:
|
||||
Do NOT require duplicate uploads or separate publish steps.
|
||||
|
||||
The uploaded task version itself becomes the client review version.
|
||||
|
||||
---
|
||||
|
||||
# NEW TASK STATUS
|
||||
|
||||
Extend `TaskStatus` enum:
|
||||
|
||||
```ts id="z1vc6r"
|
||||
TODO
|
||||
IN_PROGRESS
|
||||
INTERNAL_REVIEW
|
||||
CLIENT_REVIEW
|
||||
CHANGES
|
||||
DONE
|
||||
```
|
||||
|
||||
This mirrors actual VFX review flow more accurately.
|
||||
|
||||
---
|
||||
|
||||
# SHARE WITH CLIENT BUTTON
|
||||
|
||||
Add a prominent:
|
||||
|
||||
```plaintext id="mqkn6v"
|
||||
Share With Client
|
||||
```
|
||||
|
||||
button in multiple locations.
|
||||
|
||||
## PRIMARY LOCATION
|
||||
|
||||
Inside the internal review player page:
|
||||
|
||||
```plaintext id="m1sjc9"
|
||||
/review/[versionId]
|
||||
```
|
||||
|
||||
This is the most important placement.
|
||||
|
||||
Supervisors reviewing a version internally should be able to immediately push it to client review.
|
||||
|
||||
---
|
||||
|
||||
## ADDITIONAL LOCATIONS
|
||||
|
||||
Add button/action in:
|
||||
|
||||
* task detail page
|
||||
* version list rows
|
||||
* kanban task cards
|
||||
* project shot overview
|
||||
* latest version cards
|
||||
|
||||
Use:
|
||||
|
||||
* dropdown action menu
|
||||
* quick action button
|
||||
* contextual right-click menu where appropriate
|
||||
|
||||
---
|
||||
|
||||
# SHARE FLOW
|
||||
|
||||
When clicked:
|
||||
|
||||
## IF NO ACTIVE CLIENT REVIEW SESSION EXISTS
|
||||
|
||||
Prompt:
|
||||
|
||||
```plaintext id="4v0j9h"
|
||||
Create review link for client?
|
||||
```
|
||||
|
||||
Allow:
|
||||
|
||||
* create new tokenized review session
|
||||
* select existing review session
|
||||
* choose expiry date
|
||||
* optional password later
|
||||
* optional email send
|
||||
|
||||
---
|
||||
|
||||
## IF REVIEW SESSION EXISTS
|
||||
|
||||
Immediately:
|
||||
|
||||
* mark version as client-visible
|
||||
* move task to CLIENT_REVIEW
|
||||
* notify client if enabled
|
||||
|
||||
---
|
||||
|
||||
# VERSION VISIBILITY
|
||||
|
||||
Add fields to `Version`:
|
||||
|
||||
```ts id="e88z4o"
|
||||
isClientVisible Boolean @default(false)
|
||||
sharedAt DateTime?
|
||||
sharedById String?
|
||||
```
|
||||
|
||||
Only versions with:
|
||||
|
||||
```plaintext id="vlfvhy"
|
||||
isClientVisible = true
|
||||
```
|
||||
|
||||
appear in client portal APIs.
|
||||
|
||||
This is MUCH cleaner than relying only on shot status.
|
||||
|
||||
---
|
||||
|
||||
# CLIENT REVIEW RULES
|
||||
|
||||
Clients should ONLY see:
|
||||
|
||||
* explicitly shared versions
|
||||
* latest shared version by default
|
||||
|
||||
Clients should NEVER see:
|
||||
|
||||
* internal versions
|
||||
* WIP uploads
|
||||
* rejected internal passes
|
||||
* production notes
|
||||
* kanban/task internals
|
||||
|
||||
---
|
||||
|
||||
# CLIENT REVIEW UX
|
||||
|
||||
When shared:
|
||||
|
||||
* client sees version immediately in portal
|
||||
* can comment
|
||||
* approve
|
||||
* request changes
|
||||
|
||||
Client actions should:
|
||||
|
||||
* update task status automatically
|
||||
* create notifications
|
||||
* appear in activity feed
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="yv2hfe"
|
||||
Client approved SH010 COMP v004
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
```plaintext id="z61rq5"
|
||||
Client requested changes on SH020 TRACK v002
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# OPTIONAL EMAIL FLOW
|
||||
|
||||
Allow optional:
|
||||
|
||||
```plaintext id="jk3o5i"
|
||||
Send Review Email
|
||||
```
|
||||
|
||||
Email contains:
|
||||
|
||||
* project name
|
||||
* shot/task name
|
||||
* review link
|
||||
* optional message
|
||||
|
||||
---
|
||||
|
||||
# SMART STATUS AUTOMATION
|
||||
|
||||
Recommended automatic transitions:
|
||||
|
||||
```plaintext id="mxti1g"
|
||||
Upload Version
|
||||
→ INTERNAL_REVIEW
|
||||
|
||||
Click "Share With Client"
|
||||
→ CLIENT_REVIEW
|
||||
|
||||
Client Approves
|
||||
→ DONE
|
||||
|
||||
Client Requests Changes
|
||||
→ CHANGES
|
||||
```
|
||||
|
||||
This keeps production flow extremely simple.
|
||||
|
||||
---
|
||||
|
||||
# UI REQUIREMENTS
|
||||
|
||||
The "Share With Client" action should feel:
|
||||
|
||||
* fast
|
||||
* obvious
|
||||
* production-friendly
|
||||
|
||||
Suggested styling:
|
||||
|
||||
* accent button
|
||||
* paper-plane/share icon
|
||||
* visible near approval controls
|
||||
|
||||
Avoid:
|
||||
|
||||
* buried menus
|
||||
* multi-step publish systems
|
||||
* complicated permission dialogs
|
||||
|
||||
---
|
||||
|
||||
# IMPORTANT PRODUCT DIRECTION
|
||||
|
||||
This feature is one of the biggest differentiators of the platform.
|
||||
|
||||
The ideal workflow should feel like:
|
||||
|
||||
```plaintext id="v5z9eo"
|
||||
Artist uploads →
|
||||
Supervisor reviews →
|
||||
Clicks "Share With Client" →
|
||||
Client reviews instantly
|
||||
```
|
||||
|
||||
No exporting.
|
||||
No re-uploading.
|
||||
No external tools.
|
||||
No confusion.
|
||||
|
||||
That simplicity is the product advantage.
|
||||
|
||||
---
|
||||
|
||||
# IMPLEMENTATION PLAN
|
||||
|
||||
Implement in phases.
|
||||
|
||||
## PHASE 1 — DATABASE & CORE MODELS
|
||||
|
||||
1. Add Asset model
|
||||
2. Add Task model
|
||||
3. Add Task enums
|
||||
4. Refactor Version relationships
|
||||
5. Add Prisma migrations
|
||||
6. Seed example tasks/assets
|
||||
|
||||
---
|
||||
|
||||
## PHASE 2 — TASK CRUD
|
||||
|
||||
1. Task creation dialogs
|
||||
2. Task detail page
|
||||
3. Task assignment
|
||||
4. Status updates
|
||||
5. Due dates
|
||||
6. Quick-add task templates
|
||||
|
||||
---
|
||||
|
||||
## PHASE 3 — VERSION INTEGRATION
|
||||
|
||||
1. Attach uploads to tasks
|
||||
2. Refactor review routes
|
||||
3. Task-based version history
|
||||
4. Latest version indicators
|
||||
|
||||
---
|
||||
|
||||
## PHASE 4 — KANBAN
|
||||
|
||||
1. Build kanban board
|
||||
2. Drag/drop task movement
|
||||
3. Real-time updates
|
||||
4. Artist filtering
|
||||
5. Project filtering
|
||||
|
||||
---
|
||||
|
||||
## PHASE 5 — DASHBOARD & NOTIFICATIONS
|
||||
|
||||
1. Task widgets
|
||||
2. Workload summaries
|
||||
3. Slack updates
|
||||
4. In-app notifications
|
||||
5. Overdue indicators
|
||||
6. Client Review button implementation
|
||||
|
||||
---
|
||||
|
||||
# IMPORTANT TECHNICAL REQUIREMENTS
|
||||
|
||||
Maintain:
|
||||
|
||||
* current auth system
|
||||
* current storage abstraction
|
||||
* current review functionality
|
||||
* current client portal
|
||||
|
||||
Avoid:
|
||||
|
||||
* breaking existing APIs
|
||||
* rewriting review logic
|
||||
* giant refactors
|
||||
|
||||
This should be an additive evolution of the existing FeedBack architecture.
|
||||
|
||||
---
|
||||
|
||||
-523
@@ -1,523 +0,0 @@
|
||||
The current architecture has a conceptual problem around:
|
||||
|
||||
* shots
|
||||
* tasks
|
||||
* versions
|
||||
* approvals
|
||||
* client review visibility
|
||||
|
||||
We need to refactor the production/review workflow so that TASKS become the true operational and review unit.
|
||||
|
||||
IMPORTANT:
|
||||
Do NOT redesign the whole app.
|
||||
This is a workflow/data relationship correction and cleanup.
|
||||
|
||||
The goal is:
|
||||
|
||||
* clearer production flow
|
||||
* correct review behavior
|
||||
* correct client review visibility
|
||||
* correct kanban behavior
|
||||
* proper task-based versioning
|
||||
|
||||
---
|
||||
|
||||
# CORE ARCHITECTURAL DECISION
|
||||
|
||||
A SHOT is:
|
||||
|
||||
* a container/grouping
|
||||
* a production entity
|
||||
* NOT directly reviewable
|
||||
|
||||
A TASK is:
|
||||
|
||||
* the actual work unit
|
||||
* the review unit
|
||||
* the approval unit
|
||||
* the kanban unit
|
||||
* the upload/version unit
|
||||
|
||||
This means:
|
||||
|
||||
```plaintext id="b89ah6"
|
||||
Shot
|
||||
├── Track Task
|
||||
│ └── Versions
|
||||
│
|
||||
├── Roto Task
|
||||
│ └── Versions
|
||||
│
|
||||
└── Comp Task
|
||||
└── Versions
|
||||
```
|
||||
|
||||
NOT:
|
||||
|
||||
```plaintext id="6fjlwm"
|
||||
Shot
|
||||
└── Versions
|
||||
```
|
||||
|
||||
That old structure is incorrect.
|
||||
|
||||
---
|
||||
|
||||
# REQUIRED REFACTOR
|
||||
|
||||
## 1. VERSIONS MUST BELONG TO TASKS
|
||||
|
||||
Currently:
|
||||
|
||||
```plaintext id="y7txg8"
|
||||
Shot -> Versions
|
||||
```
|
||||
|
||||
Refactor to:
|
||||
|
||||
```plaintext id="dh4mf6"
|
||||
Task -> Versions
|
||||
```
|
||||
|
||||
A version upload must ALWAYS belong to:
|
||||
|
||||
* exactly one task
|
||||
|
||||
Remove the concept of:
|
||||
|
||||
* "shot latest version"
|
||||
|
||||
Instead:
|
||||
|
||||
* each task has its own latest version
|
||||
|
||||
Examples:
|
||||
|
||||
```plaintext id="hskx5e"
|
||||
SH010
|
||||
├── Track Task
|
||||
│ └── latest: v003
|
||||
│
|
||||
├── Roto Task
|
||||
│ └── latest: v005
|
||||
│
|
||||
└── Comp Task
|
||||
└── latest: v008
|
||||
```
|
||||
|
||||
This is the correct production model.
|
||||
|
||||
---
|
||||
|
||||
# 2. SHOTS SHOULD NOT DIRECTLY DRIVE CLIENT REVIEW
|
||||
|
||||
Currently:
|
||||
|
||||
* shot status = CLIENT_REVIEW
|
||||
* portal shows latest uploaded version
|
||||
* task context lost
|
||||
|
||||
This is incorrect.
|
||||
|
||||
Client review should be TASK-BASED.
|
||||
|
||||
---
|
||||
|
||||
# NEW CLIENT REVIEW RULE
|
||||
|
||||
The client portal should display:
|
||||
|
||||
```plaintext id="rlazoz"
|
||||
Tasks
|
||||
where latest version is marked:
|
||||
isClientVisible = true
|
||||
```
|
||||
|
||||
NOT:
|
||||
|
||||
```plaintext id="cr7j27"
|
||||
Shots where shot.status = CLIENT_REVIEW
|
||||
```
|
||||
|
||||
This fixes:
|
||||
|
||||
* incorrect versions
|
||||
* missing task context
|
||||
* review ambiguity
|
||||
|
||||
---
|
||||
|
||||
# CLIENT PORTAL SHOULD SHOW
|
||||
|
||||
Instead of:
|
||||
|
||||
```plaintext id="l3l0xr"
|
||||
SH010
|
||||
```
|
||||
|
||||
Show:
|
||||
|
||||
```plaintext id="1e2dn4"
|
||||
SH010 — COMP
|
||||
v008
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
```plaintext id="nyc0h4"
|
||||
SH010 — ROTO
|
||||
v005
|
||||
```
|
||||
|
||||
Clients review TASK DELIVERABLES.
|
||||
|
||||
Not abstract shots.
|
||||
|
||||
---
|
||||
|
||||
# 3. SHOT STATUS SHOULD BE DERIVED, NOT MANUALLY DRIVEN
|
||||
|
||||
Current shot statuses:
|
||||
|
||||
```plaintext id="5f9n1d"
|
||||
WAITING
|
||||
IN_PROGRESS
|
||||
INTERNAL_REVIEW
|
||||
CLIENT_REVIEW
|
||||
REVISIONS
|
||||
APPROVED
|
||||
FINAL
|
||||
```
|
||||
|
||||
This is creating confusion because:
|
||||
|
||||
* shots are containers
|
||||
* tasks are actual workflow units
|
||||
|
||||
Refactor shot statuses to be:
|
||||
|
||||
* simplified
|
||||
* mostly derived automatically from task states
|
||||
|
||||
---
|
||||
|
||||
# NEW SHOT STATUS MODEL
|
||||
|
||||
Reduce shot statuses to:
|
||||
|
||||
```ts id="8km4hh"
|
||||
WAITING
|
||||
IN_PROGRESS
|
||||
IN_REVIEW
|
||||
REVISIONS
|
||||
COMPLETE
|
||||
```
|
||||
|
||||
Definitions:
|
||||
|
||||
## WAITING
|
||||
|
||||
No active tasks started.
|
||||
|
||||
## IN_PROGRESS
|
||||
|
||||
At least one task is:
|
||||
|
||||
* TODO
|
||||
* IN_PROGRESS
|
||||
|
||||
## IN_REVIEW
|
||||
|
||||
At least one task is:
|
||||
|
||||
* INTERNAL_REVIEW
|
||||
* CLIENT_REVIEW
|
||||
|
||||
## REVISIONS
|
||||
|
||||
At least one task is:
|
||||
|
||||
* CHANGES
|
||||
|
||||
## COMPLETE
|
||||
|
||||
All tasks are:
|
||||
|
||||
* DONE
|
||||
|
||||
IMPORTANT:
|
||||
Shot status should mostly be AUTO-CALCULATED from tasks.
|
||||
|
||||
NOT manually set constantly.
|
||||
|
||||
---
|
||||
|
||||
# 4. REMOVE "FINAL"
|
||||
|
||||
The current:
|
||||
|
||||
```plaintext id="qmv5ps"
|
||||
APPROVED
|
||||
FINAL
|
||||
```
|
||||
|
||||
is redundant/confusing.
|
||||
|
||||
Recommendation:
|
||||
REMOVE `FINAL`.
|
||||
|
||||
Use:
|
||||
|
||||
```plaintext id="tyf56q"
|
||||
DONE
|
||||
```
|
||||
|
||||
at task level.
|
||||
|
||||
And:
|
||||
|
||||
```plaintext id="7u6wvp"
|
||||
COMPLETE
|
||||
```
|
||||
|
||||
at shot level.
|
||||
|
||||
Cleaner.
|
||||
Much easier mentally.
|
||||
|
||||
---
|
||||
|
||||
# 5. TASK STATUS IS THE TRUE KANBAN STATUS
|
||||
|
||||
Task statuses should drive:
|
||||
|
||||
* kanban columns
|
||||
* review state
|
||||
* client review state
|
||||
|
||||
Task statuses:
|
||||
|
||||
```ts id="l0m39n"
|
||||
TODO
|
||||
IN_PROGRESS
|
||||
INTERNAL_REVIEW
|
||||
CLIENT_REVIEW
|
||||
CHANGES
|
||||
DONE
|
||||
```
|
||||
|
||||
These statuses represent:
|
||||
|
||||
* actual workflow state
|
||||
* actual review state
|
||||
|
||||
---
|
||||
|
||||
# 6. REVIEW FLOW RULES
|
||||
|
||||
## Upload Version
|
||||
|
||||
When artist uploads new version:
|
||||
|
||||
```plaintext id="0q6qzx"
|
||||
Task → INTERNAL_REVIEW
|
||||
```
|
||||
|
||||
Kanban card moves automatically:
|
||||
|
||||
```plaintext id="ym9x1s"
|
||||
IN_PROGRESS
|
||||
→ INTERNAL_REVIEW
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Supervisor Shares With Client
|
||||
|
||||
When clicking:
|
||||
|
||||
```plaintext id="rxry5f"
|
||||
Share With Client
|
||||
```
|
||||
|
||||
System should:
|
||||
|
||||
* mark latest version:
|
||||
isClientVisible = true
|
||||
* set task status:
|
||||
CLIENT_REVIEW
|
||||
|
||||
Kanban updates automatically:
|
||||
|
||||
```plaintext id="7j69vz"
|
||||
INTERNAL_REVIEW
|
||||
→ CLIENT_REVIEW
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Client Approves
|
||||
|
||||
Client approval should:
|
||||
|
||||
* approve ONLY the task
|
||||
* NOT the entire shot
|
||||
|
||||
System:
|
||||
|
||||
```plaintext id="xcl9sy"
|
||||
Task.status = DONE
|
||||
Version.approvalStatus = APPROVED
|
||||
```
|
||||
|
||||
Kanban:
|
||||
|
||||
```plaintext id="p1m31i"
|
||||
CLIENT_REVIEW
|
||||
→ DONE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Client Requests Changes
|
||||
|
||||
System:
|
||||
|
||||
```plaintext id="z5fprm"
|
||||
Task.status = CHANGES
|
||||
Version.approvalStatus = NEEDS_CHANGES
|
||||
```
|
||||
|
||||
Kanban:
|
||||
|
||||
```plaintext id="r6phfx"
|
||||
CLIENT_REVIEW
|
||||
→ CHANGES
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 7. SHOT COMPLETION RULE
|
||||
|
||||
A shot becomes:
|
||||
|
||||
```plaintext id="l16lq6"
|
||||
COMPLETE
|
||||
```
|
||||
|
||||
ONLY when:
|
||||
|
||||
```plaintext id="t62l6n"
|
||||
ALL TASKS == DONE
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="0b2b7h"
|
||||
SH010
|
||||
├── Track → DONE
|
||||
├── Roto → DONE
|
||||
└── Comp → DONE
|
||||
|
||||
=> Shot COMPLETE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 8. CLIENT PORTAL STRUCTURE
|
||||
|
||||
Refactor client portal to show:
|
||||
|
||||
```plaintext id="t1qn79"
|
||||
Project
|
||||
├── Shot
|
||||
│ ├── Task
|
||||
│ │ └── Latest Shared Version
|
||||
```
|
||||
|
||||
Example UI:
|
||||
|
||||
```plaintext id="mjgr1k"
|
||||
SH010
|
||||
COMP — v008
|
||||
ROTO — v005
|
||||
|
||||
SH020
|
||||
COMP — v003
|
||||
```
|
||||
|
||||
This is MUCH clearer.
|
||||
|
||||
---
|
||||
|
||||
# 9. TASK DETAIL PAGE SHOULD BECOME PRIMARY REVIEW HUB
|
||||
|
||||
Task page should become:
|
||||
|
||||
* upload page
|
||||
* review page
|
||||
* approval page
|
||||
* history page
|
||||
|
||||
Structure:
|
||||
|
||||
```plaintext id="e2bd4f"
|
||||
/tasks/[taskId]
|
||||
```
|
||||
|
||||
Contains:
|
||||
|
||||
* task info
|
||||
* latest version
|
||||
* version history
|
||||
* comments
|
||||
* annotations
|
||||
* approvals
|
||||
* review actions
|
||||
|
||||
---
|
||||
|
||||
# 10. IMPORTANT IMPLEMENTATION NOTES
|
||||
|
||||
DO NOT:
|
||||
|
||||
* rewrite comment system
|
||||
* rewrite annotation system
|
||||
* rewrite player
|
||||
|
||||
JUST:
|
||||
|
||||
* move relationships from Shot → Task
|
||||
* update logic
|
||||
* update queries
|
||||
* update review flow
|
||||
|
||||
This is mostly:
|
||||
|
||||
* schema cleanup
|
||||
* workflow cleanup
|
||||
* state cleanup
|
||||
|
||||
---
|
||||
|
||||
# IMPORTANT PRODUCT PRINCIPLE
|
||||
|
||||
The production hierarchy should now be:
|
||||
|
||||
```plaintext id="crkxfm"
|
||||
Project
|
||||
→ Shot
|
||||
→ Task
|
||||
→ Version
|
||||
→ Comments / Annotations / Approvals
|
||||
```
|
||||
|
||||
NOT:
|
||||
|
||||
```plaintext id="zebvlz"
|
||||
Project
|
||||
→ Shot
|
||||
→ Version
|
||||
```
|
||||
|
||||
That distinction fixes nearly all current workflow inconsistencies.
|
||||
-413
@@ -1,413 +0,0 @@
|
||||
Add a lightweight scheduling system to the existing FeedBack production tracking platform.
|
||||
|
||||
IMPORTANT:
|
||||
This is NOT enterprise scheduling.
|
||||
Do NOT build Microsoft Project.
|
||||
Do NOT build ShotGrid resource planning.
|
||||
|
||||
The goal is:
|
||||
|
||||
* simple visual scheduling
|
||||
* artist workload visibility
|
||||
* drag-and-drop planning
|
||||
* lightweight production coordination
|
||||
|
||||
Think:
|
||||
“Trello timeline view for VFX tasks.”
|
||||
|
||||
The complexity level should match the existing kanban implementation.
|
||||
|
||||
---
|
||||
|
||||
# CORE GOAL
|
||||
|
||||
Allow producers/supervisors to:
|
||||
|
||||
* assign tasks to artists
|
||||
* schedule when tasks should be worked on
|
||||
* visualize artist workload
|
||||
* see upcoming deadlines
|
||||
* drag tasks around visually
|
||||
|
||||
The scheduling system should integrate directly with:
|
||||
|
||||
* existing Tasks
|
||||
* existing Artists/Users
|
||||
* existing Due Dates
|
||||
* existing Kanban workflow
|
||||
|
||||
---
|
||||
|
||||
# IMPORTANT PRODUCT PRINCIPLE
|
||||
|
||||
Scheduling is:
|
||||
|
||||
* lightweight planning
|
||||
* not time tracking
|
||||
* not timesheets
|
||||
* not attendance management
|
||||
|
||||
We are ONLY planning:
|
||||
|
||||
* who works on what
|
||||
* when
|
||||
* for roughly how long
|
||||
|
||||
---
|
||||
|
||||
# NEW PAGE
|
||||
|
||||
Add:
|
||||
|
||||
```plaintext id="9m0ynj"
|
||||
/schedule
|
||||
```
|
||||
|
||||
Add navigation item:
|
||||
|
||||
```plaintext id="9cxij0"
|
||||
Schedule
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# SCHEDULING MODEL
|
||||
|
||||
Each task already has:
|
||||
|
||||
* assignedArtistId
|
||||
* estimatedHours
|
||||
* dueDate
|
||||
|
||||
Add:
|
||||
|
||||
* scheduledStartDate
|
||||
* scheduledEndDate
|
||||
|
||||
Optional:
|
||||
|
||||
* scheduleNotes
|
||||
|
||||
---
|
||||
|
||||
# ARTIST WORKLOAD ASSUMPTION
|
||||
|
||||
Assume:
|
||||
|
||||
```plaintext id="sls7sz"
|
||||
8 working hours per day
|
||||
```
|
||||
|
||||
Use estimatedHours to determine task duration visually.
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="1o9r76"
|
||||
16 estimated hours
|
||||
= 2 scheduled work days
|
||||
```
|
||||
|
||||
Keep calculations simple.
|
||||
|
||||
---
|
||||
|
||||
# MAIN UI
|
||||
|
||||
The scheduling page should be a hybrid:
|
||||
|
||||
* kanban
|
||||
* timeline/calendar
|
||||
|
||||
Layout:
|
||||
|
||||
```plaintext id="8fys2r"
|
||||
Artists vertically
|
||||
Dates horizontally
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="ltm7d0"
|
||||
Mon Tue Wed Thu Fri
|
||||
|
||||
Chris [SH010 Comp------]
|
||||
|
||||
Sarah [SH020 Roto--]
|
||||
|
||||
Mike [Asset Car Model----]
|
||||
```
|
||||
|
||||
This should feel:
|
||||
|
||||
* visual
|
||||
* fast
|
||||
* draggable
|
||||
* uncluttered
|
||||
|
||||
---
|
||||
|
||||
# TASK CARDS
|
||||
|
||||
Each scheduled task block should show:
|
||||
|
||||
* shot/asset code
|
||||
* task type
|
||||
* task status
|
||||
* due date
|
||||
* estimated hours
|
||||
|
||||
Optional:
|
||||
|
||||
* latest version indicator
|
||||
* review status badge
|
||||
|
||||
Color coding:
|
||||
|
||||
* TODO
|
||||
* IN_PROGRESS
|
||||
* INTERNAL_REVIEW
|
||||
* CLIENT_REVIEW
|
||||
* CHANGES
|
||||
* DONE
|
||||
|
||||
---
|
||||
|
||||
# DRAG AND DROP
|
||||
|
||||
Use:
|
||||
|
||||
* dnd-kit
|
||||
|
||||
Allow:
|
||||
|
||||
* drag tasks between artists
|
||||
* resize tasks across days
|
||||
* move tasks along timeline
|
||||
|
||||
When dragged:
|
||||
|
||||
* update scheduledStartDate
|
||||
* update scheduledEndDate
|
||||
* update assignedArtistId if moved to another artist row
|
||||
|
||||
Use optimistic updates.
|
||||
|
||||
---
|
||||
|
||||
# SCHEDULING RULES
|
||||
|
||||
Simple rules only.
|
||||
|
||||
## WARNING STATES
|
||||
|
||||
Highlight:
|
||||
|
||||
* overdue tasks
|
||||
* tasks ending after due date
|
||||
* artist overload
|
||||
|
||||
Example overload:
|
||||
|
||||
```plaintext id="qff2t0"
|
||||
Artist scheduled > 8h/day
|
||||
```
|
||||
|
||||
Use visual indicators only.
|
||||
DO NOT block scheduling.
|
||||
|
||||
---
|
||||
|
||||
# FILTERS
|
||||
|
||||
Add:
|
||||
|
||||
* project filter
|
||||
* artist filter
|
||||
* task status filter
|
||||
|
||||
Optional:
|
||||
|
||||
* department filter
|
||||
|
||||
---
|
||||
|
||||
# TASK SOURCE
|
||||
|
||||
The schedule should ONLY display:
|
||||
|
||||
* tasks with assigned artists
|
||||
OR
|
||||
* tasks with scheduled dates
|
||||
|
||||
Unscheduled tasks remain in kanban/backlog.
|
||||
|
||||
---
|
||||
|
||||
# BACKLOG PANEL
|
||||
|
||||
Add optional side panel:
|
||||
|
||||
```plaintext id="o0lm45"
|
||||
Unscheduled Tasks
|
||||
```
|
||||
|
||||
Allow dragging tasks:
|
||||
|
||||
* from backlog
|
||||
* onto artist schedule
|
||||
|
||||
This is VERY useful.
|
||||
|
||||
---
|
||||
|
||||
# REVIEW INTEGRATION
|
||||
|
||||
Scheduling should integrate with review flow.
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="hr4lxg"
|
||||
Task enters CLIENT_REVIEW
|
||||
→ visually marked on schedule
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="4f8pl5"
|
||||
Task enters CHANGES
|
||||
→ warning badge appears
|
||||
```
|
||||
|
||||
This creates production awareness.
|
||||
|
||||
---
|
||||
|
||||
# KANBAN INTEGRATION
|
||||
|
||||
The schedule and kanban should share:
|
||||
|
||||
* same task objects
|
||||
* same statuses
|
||||
* same assignments
|
||||
|
||||
Changing status in:
|
||||
|
||||
* kanban
|
||||
* task page
|
||||
* review flow
|
||||
|
||||
should instantly reflect in schedule.
|
||||
|
||||
Example:
|
||||
|
||||
```plaintext id="rmy3ud"
|
||||
CLIENT_REVIEW
|
||||
→ DONE
|
||||
```
|
||||
|
||||
Task visually updates in schedule immediately.
|
||||
|
||||
---
|
||||
|
||||
# DASHBOARD WIDGETS
|
||||
|
||||
Add:
|
||||
|
||||
* Artist Utilization
|
||||
* Tasks Due This Week
|
||||
* Overloaded Artists
|
||||
* Upcoming Reviews
|
||||
|
||||
Simple summaries only.
|
||||
|
||||
---
|
||||
|
||||
# UI REQUIREMENTS
|
||||
|
||||
The scheduler should feel:
|
||||
|
||||
* modern
|
||||
* clean
|
||||
* cinematic
|
||||
* dark mode first
|
||||
|
||||
Inspiration:
|
||||
|
||||
* Linear roadmap
|
||||
* Trello timeline
|
||||
* Notion timeline
|
||||
* Monday.com timeline
|
||||
|
||||
BUT:
|
||||
simpler and faster.
|
||||
|
||||
Avoid:
|
||||
|
||||
* giant grids
|
||||
* enterprise clutter
|
||||
* complex dependencies
|
||||
* gantt-chart nightmares
|
||||
|
||||
---
|
||||
|
||||
# IMPLEMENTATION PLAN
|
||||
|
||||
## PHASE 1 — DATABASE
|
||||
|
||||
1. Add scheduling fields to Task
|
||||
2. Add indexes for schedule queries
|
||||
3. Add task duration helpers
|
||||
|
||||
---
|
||||
|
||||
## PHASE 2 — BASIC TIMELINE
|
||||
|
||||
1. Build schedule page
|
||||
2. Artist rows
|
||||
3. Date columns
|
||||
4. Render scheduled tasks
|
||||
|
||||
---
|
||||
|
||||
## PHASE 3 — DRAG/DROP
|
||||
|
||||
1. Move tasks
|
||||
2. Resize durations
|
||||
3. Reassign artists
|
||||
4. Optimistic updates
|
||||
|
||||
---
|
||||
|
||||
## PHASE 4 — BACKLOG
|
||||
|
||||
1. Unscheduled task panel
|
||||
2. Drag from backlog to schedule
|
||||
3. Quick scheduling
|
||||
|
||||
---
|
||||
|
||||
## PHASE 5 — POLISH
|
||||
|
||||
1. Filters
|
||||
2. Overload indicators
|
||||
3. Review status badges
|
||||
4. Utilization summaries
|
||||
|
||||
---
|
||||
|
||||
# IMPORTANT
|
||||
|
||||
Keep this system intentionally lightweight.
|
||||
|
||||
The ideal workflow should feel like:
|
||||
|
||||
```plaintext id="xmv8lx"
|
||||
Create task
|
||||
→ Assign artist
|
||||
→ Drag onto schedule
|
||||
→ Artist uploads version
|
||||
→ Review
|
||||
→ Approve
|
||||
```
|
||||
|
||||
That simplicity is the product advantage.
|
||||
-1239
File diff suppressed because it is too large
Load Diff
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
-1355
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user