Files
vfxreview/PROMPT2.md
T
twotalesanimation 0fbe856dce Initial commit
2026-05-19 22:20:29 +02:00

12 KiB

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:

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:

TODO
IN_PROGRESS
REVIEW
CHANGES
DONE

NEW ENUM: TaskType

Add:

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:

Shot -> Versions

Refactor to:

Task -> Versions

Reason: The review process is task-specific.

Example:

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:

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:

/tasks
/tasks/[taskId]

Project Views

Extend:

/projects/[id]

Add tabs:

  • Shots
  • Assets
  • Tasks
  • Kanban
  • Activity

Asset Views

Add:

/projects/[id]/assets/[assetId]

Task Views

Add:

/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:

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:

TASK_ASSIGNED
TASK_OVERDUE
TASK_APPROVED
TASK_CHANGES_REQUESTED
TASK_READY_FOR_REVIEW

Slack examples:

SH010 COMP task ready for review
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:

Internal Review
→ Client Review
→ Approved / Changes

When a user clicks:

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:

TODO
IN_PROGRESS
INTERNAL_REVIEW
CLIENT_REVIEW
CHANGES
DONE

This mirrors actual VFX review flow more accurately.


SHARE WITH CLIENT BUTTON

Add a prominent:

Share With Client

button in multiple locations.

PRIMARY LOCATION

Inside the internal review player page:

/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:

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:

isClientVisible Boolean @default(false)
sharedAt DateTime?
sharedById String?

Only versions with:

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:

Client approved SH010 COMP v004

Or:

Client requested changes on SH020 TRACK v002

OPTIONAL EMAIL FLOW

Allow optional:

Send Review Email

Email contains:

  • project name
  • shot/task name
  • review link
  • optional message

SMART STATUS AUTOMATION

Recommended automatic transitions:

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:

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.