@mevdragon/vidfarm-devcli 0.2.1 → 0.2.3

package/SKILL.director.md

@@ -1,599 +0,0 @@
----
-name: vidfarm-director
-description: Use Vidfarm as a director-facing agent-first video production platform. Use this whenever the user wants to log in with OTP, store their own AI provider keys, discover templates, read a template's published skill, submit template jobs, poll job status, inspect logs, or operate a multi-stage media production workflow through the Vidfarm REST API.
----
-
-# Vidfarm Director
-
-Vidfarm is an agent-first media production platform.
-
-Use this skill when the user wants to operate Vidfarm as a director, not when they want to build templates or modify the platform.
-
-The user of this skill is a director or template operator:
-
-- they sign in to Vidfarm
-- they bring their own AI API keys
-- they discover available templates
-- they read each template's published skill and metadata
-- they submit async jobs to template operations
-- they poll jobs, read logs, and chain stages together
-
-Do not explain template developer internals unless the user explicitly asks for them.
-
-## Core Mental Model
-
-Treat Vidfarm as a shared control plane for many production templates.
-
-Each template is a production format with a common platform wrapper:
-
-- auth
-- API keys
-- async jobs
-- logs
-- webhooks
-- artifacts
-
-Each template then adds its own production logic through its operations.
-
-The platform is intentionally async-first:
-
-- every meaningful production action becomes a job
-- jobs immediately return `job_id`
-- the caller polls for status or receives a webhook
-
-This is important because video production is inherently multi-stage and often slow:
-
-- concept generation
-- research
-- script or storyboard scaffolding
-- image or scene generation
-- human review or revision
-- final render
-
-You should frame Vidfarm as a production pipeline system, not as a single prompt-response tool.
-
-## Agent-First Operating Style
-
-Vidfarm is designed for users who work through AI agents.
-
-Your role is usually to operate the API on the user's behalf:
-
-1. log the user in
-2. store their provider keys
-3. list templates
-4. inspect the selected template
-5. read the template's published skill
-6. choose the right operation
-7. submit the job
-8. monitor progress
-9. use outputs from one stage as inputs to the next stage
-
-Prefer doing this operational work for the user instead of only describing the docs.
-
-When helping a user choose what to do next, think in terms of pipeline stages. Ask what stage they are in:
-
-- idea
-- storyboard
-- asset generation
-- refinement
-- rendering
-- delivery
-
-## Bring Your Own AI Keys
-
-Vidfarm expects customers to bring their own AI provider credentials.
-
-Today the user-facing provider key API supports:
-
-- `openai`
-- `gemini`
-- `openrouter`
-- `perplexity`
-
-Before running most AI-backed template operations, the user should save at least one provider key that matches the template's expected provider flow.
-
-Do not imply that Vidfarm supplies the AI credits itself. The customer is expected to supply their own upstream AI access.
-
-## Base URL And Auth
-
-Production is intended to run under:
-
-```txt
-https://vidfarm.cloud.zoomgtm.com
-```
-
-The REST API base path is:
-
-```txt
-/api/v1
-```
-
-Authenticated API calls use these headers:
-
-```txt
-vidfarm-user-id: <customer id>
-vidfarm-api-key: <api key>
-```
-
-The API key is issued after OTP verification.
-
-## Login Flow
-
-Use this sequence for API login:
-
-1. `POST /api/v1/user/request-otp`
-2. `POST /api/v1/user/verify-otp`
-
-Request OTP:
-
-```bash
-curl -X POST "https://vidfarm.cloud.zoomgtm.com/api/v1/user/request-otp" \
-  -H "content-type: application/json" \
-  -d '{
-    "email": "user@example.com"
-  }'
-```
-
-Verify OTP:
-
-```bash
-curl -X POST "https://vidfarm.cloud.zoomgtm.com/api/v1/user/verify-otp" \
-  -H "content-type: application/json" \
-  -d '{
-    "email": "user@example.com",
-    "code": "123456",
-    "name": "Example User"
-  }'
-```
-
-Expected response shape:
-
-```json
-{
-  "customer": {
-    "id": "cus_...",
-    "email": "user@example.com",
-    "name": "Example User",
-    "defaultWebhookUrl": null,
-    "isDeveloper": false,
-    "isPaidPlan": true
-  },
-  "apiKey": "vf_key_..."
-}
-```
-
-Persist these values for later API calls:
-
-- `customer.id`
-- `apiKey`
-
-Useful shell variables:
-
-```bash
-BASE_URL="https://vidfarm.cloud.zoomgtm.com/api/v1"
-VIDFARM_USER_ID="cus_replace_me"
-VIDFARM_API_KEY="vf_replace_me"
-AUTH_HEADERS=(
-  -H "vidfarm-user-id: ${VIDFARM_USER_ID}"
-  -H "vidfarm-api-key: ${VIDFARM_API_KEY}"
-)
-JSON_HEADERS=(
-  "${AUTH_HEADERS[@]}"
-  -H "content-type: application/json"
-)
-```
-
-## Save Provider Keys
-
-Store the user's own AI key before starting template work:
-
-```bash
-curl -X POST "${BASE_URL}/user/me/provider-keys" \
-  "${JSON_HEADERS[@]}" \
-  -d '{
-    "provider": "openrouter",
-    "label": "primary",
-    "secret": "sk-or-v1-...",
-    "weight": 1
-  }'
-```
-
-List saved provider keys:
-
-```bash
-curl "${BASE_URL}/user/me/provider-keys" \
-  "${AUTH_HEADERS[@]}"
-```
-
-Use `GET /api/v1/user/me` to inspect the current authenticated customer profile:
-
-```bash
-curl "${BASE_URL}/user/me" \
-  "${AUTH_HEADERS[@]}"
-```
-
-## Template Standard
-
-Every customer-usable template follows the same platform shape:
-
-- `GET /api/v1/templates`
-- `GET /api/v1/templates/:templateId`
-- `GET /api/v1/templates/:templateId/skill`
-- `GET /api/v1/templates/:templateId/about/*`
-- `POST /api/v1/templates/:templateId/config`
-- `POST /api/v1/templates/:templateId/operations/:operationName`
-- `GET /api/v1/templates/:templateId/jobs`
-- `GET /api/v1/templates/:templateId/jobs/:jobId`
-- `GET /api/v1/templates/:templateId/jobs/:jobId/logs`
-- `POST /api/v1/templates/:templateId/jobs/:jobId/cancel`
-
-This common wrapper is the most important concept for users.
-
-No matter which template is chosen, the operating pattern stays the same:
-
-1. discover
-2. inspect
-3. configure
-4. submit operation
-5. monitor job
-6. feed outputs into the next stage
-
-## Discover Templates
-
-List all templates:
-
-```bash
-curl "${BASE_URL}/templates" \
-  "${AUTH_HEADERS[@]}"
-```
-
-The response includes each template's:
-
-- `id`
-- `slug_id`
-- `version`
-- `title`
-- `description`
-- `skill_url`
-- `operations`
-
-Read one template's about metadata:
-
-```bash
-curl "${BASE_URL}/templates/template_0000" \
-  "${AUTH_HEADERS[@]}"
-```
-
-Expected about fields include:
-
-- `id`
-- `slug_id`
-- `version`
-- `title`
-- `description`
-- `viral_dna`
-- `preview_media`
-- `link_to_original`
-- `skill_url`
-- `operations`
-
-Important detail:
-
-- `templateId` may be either the UUID-like template id or the human-readable `slug_id`
-- in practice, users will usually prefer the `slug_id`
-
-## Read The Template's Own Skill
-
-After identifying a template, read its published skill:
-
-```bash
-curl "${BASE_URL}/templates/template_0000/skill" \
-  "${AUTH_HEADERS[@]}"
-```
-
-This is how you discover the template's unique operating details.
-
-The template skill is the customer-facing contract for things like:
-
-- which operations exist
-- what each operation does
-- the expected payload shape
-- which output artifacts come back
-- any template-specific stage sequence
-- any style or formatting constraints
-
-When a user asks how to use a specific template, always inspect both:
-
-1. `GET /templates/:templateId`
-2. `GET /templates/:templateId/skill`
-
-Use the metadata endpoint for the standard wrapper and the skill endpoint for the template-specific behavior.
-
-## Template Configuration
-
-Some templates support saved per-user configuration.
-
-Write config with:
-
-```bash
-curl -X POST "${BASE_URL}/templates/template_0000/config" \
-  "${JSON_HEADERS[@]}" \
-  -d '{
-    "config": {
-      "defaultProvider": "gemini"
-    }
-  }'
-```
-
-Treat config as stable preferences for that template, such as:
-
-- default provider
-- default models
-- style settings
-- rendering defaults
-
-Always check the template skill for the config fields that the specific template expects.
-
-## Submit Template Operations
-
-Template work is submitted through operation routes:
-
-```txt
-POST /api/v1/templates/:templateId/operations/:operationName
-```
-
-Request shape:
-
-```json
-{
-  "tracer": "client-generated-reference",
-  "payload": {},
-  "webhook_url": "https://example.com/webhooks/vidfarm"
-}
-```
-
-`webhook_url` is optional.
-
-The standard response shape is:
-
-```json
-{
-  "job_id": "job_...",
-  "tracer": "client-generated-reference",
-  "status": "queued"
-}
-```
-
-Example, using the sample template's first stage:
-
-```bash
-curl -X POST "${BASE_URL}/templates/template_0000/operations/create_slideshow" \
-  "${JSON_HEADERS[@]}" \
-  -d '{
-    "tracer": "launch-story-001",
-    "payload": {
-      "slides": [
-        ["late night founder at laptop", "launching after hours", 2200],
-        {
-          "image_prompt": "skincare serum bottle on a clean bathroom counter near a window",
-          "caption": "the routine was simpler than i thought",
-          "duration_ms": 2800
-        }
-      ],
-      "meta_details_prompt": "Write native TikTok metadata for a US audience. Keep it curiosity-driven and casual."
-    }
-  }'
-```
-
-## Monitor Jobs
-
-List jobs for one template:
-
-```bash
-curl "${BASE_URL}/templates/template_0000/jobs" \
-  "${AUTH_HEADERS[@]}"
-```
-
-Filter by tracer or time window:
-
-```bash
-curl "${BASE_URL}/templates/template_0000/jobs?tracer=launch-story-001&start_time=2026-05-17T00:00:00.000Z&end_time=2026-05-18T00:00:00.000Z&limit=20" \
-  "${AUTH_HEADERS[@]}"
-```
-
-Get one job:
-
-```bash
-JOB_ID="job_replace_me"
-
-curl "${BASE_URL}/templates/template_0000/jobs/${JOB_ID}" \
-  "${AUTH_HEADERS[@]}"
-```
-
-Job responses commonly include:
-
-- `job_id`
-- `template_id`
-- `operation_name`
-- `workflow_name`
-- `tracer`
-- `status`
-- `progress`
-- `result`
-- `error`
-- `created_at`
-- `updated_at`
-- `started_at`
-- `completed_at`
-
-Current job statuses are:
-
-- `queued`
-- `running`
-- `waiting_for_child`
-- `waiting_for_human`
-- `succeeded`
-- `failed`
-- `cancelled`
-
-## Read Structured Logs
-
-Every job can expose a structured timeline:
-
-```bash
-curl "${BASE_URL}/templates/template_0000/jobs/${JOB_ID}/logs?start_time=2026-05-17T00:00:00.000Z&end_time=2026-05-18T00:00:00.000Z&limit=200" \
-  "${AUTH_HEADERS[@]}"
-```
-
-Treat logs as the best source for:
-
-- progress checkpoints
-- stage-level diagnostics
-- artifact references
-- machine-readable metadata emitted during production
-
-When a job fails or stalls, inspect logs before retrying blindly.
-
-## Cancel Jobs
-
-Cancel a job with:
-
-```bash
-curl -X POST "${BASE_URL}/templates/template_0000/jobs/${JOB_ID}/cancel" \
-  "${AUTH_HEADERS[@]}"
-```
-
-## Cross-Template Job Listing
-
-To see the current user's jobs across templates:
-
-```bash
-curl "${BASE_URL}/user/me/jobs" \
-  "${AUTH_HEADERS[@]}"
-```
-
-This endpoint also supports filters such as:
-
-- `template_id`
-- `tracer`
-- `start_time`
-- `end_time`
-- `limit`
-
-## Webhooks
-
-Vidfarm supports optional job webhooks on operation submission.
-
-Use them when the user wants asynchronous completion handling instead of polling.
-
-Webhook events can include:
-
-- `job.queued`
-- `job.running`
-- `job.succeeded`
-- `job.failed`
-- `job.cancelled`
-
-Webhook requests include:
-
-- `x-vidfarm-event`
-- `x-vidfarm-signature`
-
-The JSON body shape is:
-
-```json
-{
-  "type": "job.succeeded",
-  "emitted_at": "2026-05-17T12:00:00.000Z",
-  "job": {
-    "job_id": "job_...",
-    "tracer": "launch-story-001",
-    "status": "succeeded",
-    "template_id": "template_0000",
-    "operation_name": "create_slideshow",
-    "progress": 1,
-    "result": {},
-    "error": null
-  }
-}
-```
-
-## Multi-Stage Production Guidance
-
-The right way to think about Vidfarm is as a chain of production states.
-
-One operation often prepares the next one.
-
-Typical pattern:
-
-1. generate or scaffold assets
-2. inspect the result payload and artifacts
-3. optionally revise inputs
-4. submit the next operation
-5. repeat until final render or export
-
-For example, the current sample template behaves like this:
-
-1. `create_slideshow` generates finished slide frames plus manifest data
-2. the returned `renderVideoInput` becomes the clean handoff into `render_video`
-3. `render_video` turns those frames into a final vertical video
-
-When helping users, always look for explicit handoff fields in the previous stage's `result`.
-
-## How To Understand A Template's Unique API
-
-Vidfarm templates share the same outer API, but each template has unique operations and payloads.
-
-Use this exact sequence:
-
-1. call `GET /api/v1/templates`
-2. pick a template id or `slug_id`
-3. call `GET /api/v1/templates/:templateId`
-4. inspect `operations`
-5. call `GET /api/v1/templates/:templateId/skill`
-6. extract operation names, payload examples, and stage order from the skill
-7. submit the chosen operation under `/operations/:operationName`
-
-Do not invent undocumented subroutes.
-
-For customers, the unique template surface is primarily:
-
-- the operation names
-- the config schema
-- the payload contract
-- the returned artifacts and result structure
-
-The template skill is the authoritative human-readable guide for those differences.
-
-## Alpha Posture
-
-Vidfarm is in alpha.
-
-Prefer teaching users the flows that exist now and avoid dwelling on features that may arrive later.
-
-Focus on what lets a user become operational immediately:
-
-- OTP login
-- API key issuance
-- provider key upload
-- template discovery
-- template skill inspection
-- async job submission
-- job polling
-- logs
-- webhooks
-
-## Default Assistance Pattern
-
-When a user asks for help using Vidfarm, default to this style:
-
-1. get or confirm their auth state
-2. confirm they have brought their own AI key
-3. list templates
-4. inspect the chosen template
-5. read the template skill
-6. identify the current production stage
-7. submit the smallest sensible next operation
-8. monitor the job and interpret the outputs
-
-This keeps the interaction agentic, operational, and immediately useful.

package/dist/infra/cdk/bin/vidfarm-prod.js

@@ -1,59 +0,0 @@
-#!/usr/bin/env node
-import { App } from "aws-cdk-lib";
-import { VidfarmProdStack } from "../lib/vidfarm-prod-stack.js";
-function required(name) {
-    const value = process.env[name]?.trim();
-    if (!value) {
-        throw new Error(`Missing required environment variable: ${name}`);
-    }
-    return value;
-}
-function optional(name) {
-    const value = process.env[name]?.trim();
-    return value ? value : undefined;
-}
-const account = optional("CDK_DEFAULT_ACCOUNT") ?? optional("AWS_ACCOUNT_ID");
-const region = optional("CDK_DEFAULT_REGION") ?? optional("AWS_REGION") ?? "us-east-1";
-if (!account) {
-    throw new Error("Set CDK_DEFAULT_ACCOUNT or AWS_ACCOUNT_ID before running CDK.");
-}
-const env = { account, region };
-const app = new App();
-new VidfarmProdStack(app, "VidfarmProdStack", {
-    env,
-    zoneName: optional("VIDFARM_ZONE_NAME") ?? "cloud.zoomgtm.com",
-    zoneId: required("VIDFARM_ZONE_ID"),
-    recordName: optional("VIDFARM_RECORD_NAME") ?? "vidfarm",
-    publicBaseUrl: optional("VIDFARM_PUBLIC_BASE_URL") ?? "https://vidfarm.cloud.zoomgtm.com",
-    adminEmails: required("VIDFARM_ADMIN_EMAILS"),
-    developerEmails: optional("VIDFARM_DEVELOPER_EMAILS") ?? "",
-    encryptionSecret: required("VIDFARM_ENCRYPTION_SECRET"),
-    apiKeySalt: required("VIDFARM_API_KEY_SALT"),
-    webhookSecret: required("VIDFARM_WEBHOOK_SECRET"),
-    resendApiKey: optional("VIDFARM_RESEND_API_KEY"),
-    resendFromEmail: optional("VIDFARM_RESEND_FROM_EMAIL") ?? "noreply@zoomgtm.com",
-    superagencyKey: optional("SUPERAGENCY_KEY"),
-    openAiApiKey: optional("VIDFARM_OPENAI_API_KEY"),
-    openRouterApiKey: optional("VIDFARM_OPENROUTER_API_KEY"),
-    geminiApiKey: optional("VIDFARM_GEMINI_API_KEY"),
-    perplexityApiKey: optional("VIDFARM_PERPLEXITY_API_KEY"),
-    remotionMode: optional("VIDFARM_REMOTION_MODE") ?? "auto",
-    remotionRegion: optional("VIDFARM_REMOTION_REGION") ?? "us-east-1",
-    remotionBucketName: optional("VIDFARM_REMOTION_BUCKET_NAME"),
-    remotionSiteName: optional("VIDFARM_REMOTION_SITE_NAME"),
-    remotionFunctionName: optional("VIDFARM_REMOTION_FUNCTION_NAME"),
-    remotionServeUrl: optional("VIDFARM_REMOTION_SERVE_URL"),
-    remotionCompositionId: optional("VIDFARM_REMOTION_COMPOSITION_ID") ?? "template-0000",
-    remotionAwsAccessKeyId: optional("VIDFARM_REMOTION_AWS_ACCESS_KEY_ID"),
-    remotionAwsSecretAccessKey: optional("VIDFARM_REMOTION_AWS_SECRET_ACCESS_KEY"),
-    mockProviderResponses: optional("VIDFARM_MOCK_PROVIDER_RESPONSES") ?? "false",
-    workerPollMs: Number(optional("VIDFARM_WORKER_POLL_MS") ?? "1500"),
-    workerBatchSize: Number(optional("VIDFARM_WORKER_BATCH_SIZE") ?? "2"),
-    workerMaxConcurrentJobs: Number(optional("VIDFARM_WORKER_MAX_CONCURRENT_JOBS") ?? "1"),
-    defaultJobDelaySeconds: Number(optional("VIDFARM_DEFAULT_JOB_DELAY_SECONDS") ?? "20"),
-    maxPendingJobsGlobal: Number(optional("VIDFARM_MAX_PENDING_JOBS_GLOBAL") ?? "0"),
-    maxPendingJobsPerCustomer: Number(optional("VIDFARM_MAX_PENDING_JOBS_PER_CUSTOMER") ?? "0"),
-    instanceType: optional("VIDFARM_INSTANCE_TYPE") ?? "t3.small",
-    dataVolumeSizeGiB: Number(optional("VIDFARM_DATA_VOLUME_SIZE_GIB") ?? "80")
-});
-app.synth();