FAS Artist System

Clean rebuild target for the artist-management work under the fas.fellies.network repository.

This repository is migrated from /home/cici/_NEW/artist-management through branch-sized workorders and small commit slices. The goal is to preserve proven implementation work while creating a clearer history and structure.

Planned Workspace

apps/admin
apps/public
apps/worker
packages/assets
packages/auth
packages/config
packages/db
packages/schemas
packages/ui
packages/workflows
docs
scripts

Current WO-01 state:

• root Bun workspace tooling is present.
• local PostgreSQL, RustFS, and Temporal service config is present.
• packages/config is present.
• apps/worker exists as a package shell only. Worker bootstrap and activities are added later.

Migration Rules

• One WO-* workorder equals one branch.
• A branch may contain many small commits.
• Each commit should copy or implement one narrow subset of the system.
• Do not copy generated output, local service state, or local environment files.
• Record migration decisions in docs/migration-notes.md.

Source Lock

The active migration source is recorded in:

docs/migration-source.md

Workorders

The workorder definitions live outside this repository during the migration test:

/home/cici/_NEW/workorders

Local Services

Start local dependencies:

docker compose up -d

Services:

• PostgreSQL app database on localhost:5432
• RustFS S3-compatible storage on localhost:9000
• Temporal on localhost:7233
• Temporal UI on localhost:8080

If PostgreSQL and S3 are already real endpoints, Temporal can run as a direct local dev service instead of Docker:

bun run dev:temporal

The dev Temporal server stores state in .temporal/temporal.db. If the CLI logs local persistence errors, stop the Temporal server and reset the local Temporal database:

bun run temporal:reset
bun run dev:temporal

First Commands

bun install
cp .env.example .env
bun run check
bun run typecheck

Database, admin, public app, and real worker commands are wired in root scripts but their packages are migrated in later workorders.

Temporal Worker

WO-05 adds the Temporal workflow package and real worker process.

Start Temporal locally:

bun run dev:temporal

Start the worker in another shell:

bun run dev:worker

The worker listens on TEMPORAL_TASK_QUEUE, which defaults to fas-assets in .env.example.

First Owner Setup

The admin app uses Better Auth. When no human users exist, protected admin routes redirect to /register so the first owner can be created.

For scripted bootstrap, configure these values in .env:

INITIAL_ADMIN_EMAIL
INITIAL_ADMIN_NAME
INITIAL_ADMIN_PASSWORD

Then run:

bun run db:seed --preset dev

The seed entry point can execute all reset presets:

bun run db:seed --preset first-start
bun run db:seed --preset dev
bun run db:seed --preset demo

first-start does not create users. dev and demo seed the owner from the INITIAL_ADMIN_* values. demo also creates the demo user demo@example.invalid with password demo.

dev and demo expect prepared fixture files in S3 under _seed/dev and _seed/demo. They are generated synthetic files, so no artist work is reused. Build or rebuild them with:

bun --filter @fas/db seed:fixtures:build --preset all

The fixture build uploads originals, ready variants, metadata, palettes, the header banner, the artwork image, and the artwork timelapse video manifest.

Docker Deployment

PostgreSQL and RustFS are expected to be provisioned outside these compose files. A single Temporal server is shared by all installs and provides the demo, dev, and prod namespaces:

docker compose -f docker-compose.temporal.yml up -d

Each install then starts its own seed job, worker, admin app, and public app:

docker compose -f docker-compose.demo.yml up -d
docker compose -f docker-compose.dev.yml up -d
docker compose -f docker-compose.prod.yml up -d

The admin/public hostnames are:

admin.demo.fas.fellies.art / demo.fas.fellies.art
admin.dev.fas.fellies.art / dev.fas.fellies.art
admin.fas.fellies.art / fas.fellies.art

Docker Compose reads a root .env file by default. The shared Temporal compose needs these variables for its external PostgreSQL database:

TEMPORAL_POSTGRES_HOST
TEMPORAL_POSTGRES_USER
TEMPORAL_POSTGRES_PASSWORD
TEMPORAL_POSTGRES_DBNAME
TEMPORAL_POSTGRES_VISIBILITY_DBNAME

Each app install needs its own database, bucket, auth secret, and storage credentials. Demo/dev also need the initial admin password because those presets create an admin user. Prod runs the first-start preset and does not create an initial admin.

DEMO_DATABASE_URL
DEMO_BETTER_AUTH_SECRET
DEMO_INITIAL_ADMIN_PASSWORD
DEMO_S3_ACCESS_KEY_ID
DEMO_S3_SECRET_ACCESS_KEY
DEMO_S3_BUCKET
DEMO_S3_ENDPOINT

DEV_DATABASE_URL
DEV_BETTER_AUTH_SECRET
DEV_INITIAL_ADMIN_PASSWORD
DEV_S3_ACCESS_KEY_ID
DEV_S3_SECRET_ACCESS_KEY
DEV_S3_BUCKET
DEV_S3_ENDPOINT

PROD_DATABASE_URL
PROD_BETTER_AUTH_SECRET
PROD_S3_ACCESS_KEY_ID
PROD_S3_SECRET_ACCESS_KEY
PROD_S3_BUCKET
PROD_S3_ENDPOINT

Optional Docker variables are TEMPORAL_POSTGRES_PORT, GLOBAL_TEMPORAL_ADDRESS, per-install *_INITIAL_ADMIN_EMAIL, *_INITIAL_ADMIN_NAME, *_S3_REGION, *_S3_UPLOAD_URL_TTL_SECONDS, and DEMO_RESET_PRESETS_ENABLED / DEV_RESET_PRESETS_ENABLED. Demo/dev seed their presets once per seed_state volume and default reset presets to enabled. Prod seeds first-start once and does not enable reset presets.

SUPPORT_USER_EMAIL, SUPPORT_USER_NAME, and SUPPORT_USER_USERNAME are reserved for the protected support/system user behavior copied from the source repo.