@mevdragon/vidfarm-devcli 0.2.1 → 0.2.2

package/templates/template_0000/README.md

@@ -2,12 +2,11 @@
 
 Standalone GitHub-distributable package for the Vidfarm `template_0000` starter template.
 
-This package exists for two operational reasons:
+This package exists to give third-party developers a concrete example of the Vidfarm template contract.
 
-- keep the template code in its own private GitHub repo for manual admin review/import
-- preserve the exact checked-in config and build shape the release admin will later promote to shared Remotion AWS and the production Docker image
+Developers should treat this repo as an authoring and review unit.
 
-Developers should treat this repo as an authoring and review unit, not as an authorized deployment unit.
+When a template is ready, it is handed off for Vidfarm admin review and approval before it becomes available on the hosted platform.
 
 Every new template should keep its source-format research checked in:
 
@@ -15,33 +14,21 @@ Every new template should keep its source-format research checked in:
 - `research/preview/` for the screenshots or source video the DNA analyzers inspect
 - `src/template-dna.ts` for the generated viral and visual DNA that feed the published template metadata
 
-The production release flow is:
-
-1. developer pushes template code to GitHub
-2. admin reviews the repo and selects a commit from `production`
-3. admin publishes the approved Remotion site bundle to shared AWS
-4. admin imports and activates the approved commit in Vidfarm
-5. admin rebuilds and redeploys the production Docker image
-
-Template authors do not publish directly to shared Remotion Lambda and do not directly promote templates into production Docker.
-
 Production integration settings are checked into `template.config.json`. AI agents and developers should treat that file as the source of truth for:
 
 - project identity
 - `template_id` as the self-issued UUIDv4 platform identifier
 - `slug_id` as the human-readable stable slug
-- GitHub repo target
-- production source branch
-- Remotion region/function/bucket/site/composition settings
-- release control expectations for admin promotion
+- the template module path
+- the local Remotion composition settings used by the starter template
 
 ## Included
 
 - `SKILL.md` for customer AI-agent usage
 - `src/template.ts` for the Vidfarm platform contract
-- `src/remotion/*` for local and cloud video rendering
+- `src/remotion/*` for local video rendering
 - `src/lib/images.ts` for non-cropping portrait normalization
-- `composition.json` sample props for cloud render smoke tests
+- `composition.json` sample props for local render tests
 
 ## Template behavior
 
@@ -87,35 +74,3 @@ vidfarm analyze-visual-dna --template-dir .
 ```
 
 If you scaffold a template with `vidfarm generate-template` and provide `--source-preview-dir`, the CLI will run both analyzers automatically unless `--skip-dna-analysis` is set.
-
-## Shared Remotion AWS
-
-Expected shared infra:
-
-- region: stored in `template.config.json`
-- function: stored in `template.config.json`
-- bucket: stored in `template.config.json`
-
-The only runtime secrets expected from the execution environment are AWS credentials. The production Remotion topology is intentionally checked into `template.config.json`, not spread across `.env` values.
-
-These shared-AWS operations are release-admin tasks. Template developers should not run them against the shared production AWS account.
-
-Release admin create-site:
-
-```bash
-npm run admin:create-site
-```
-
-Release admin cloud render smoke test:
-
-```bash
-npm run admin:render:cloud
-```
-
-Release admin cloud render from a real stage-1 manifest:
-
-```bash
-npm run admin:render:cloud -- --manifest /abs/path/to/template-0000.json
-```
-
-Use the manifest mode when you want the cloud render verification to include the actual composited slide frames with text overlays, not just the static sample props.

package/templates/template_0000/SKILL.md

@@ -5,8 +5,8 @@ Use this template when the customer wants a fast vertical slideshow for TikTok-s
 Operational rule:
 
 - template developers author and test this template locally
-- only the release admin publishes the approved Remotion site bundle to shared AWS
-- only the release admin promotes the approved template into production Docker
+- the hosted platform later runs the approved template behind the standard Vidfarm API wrapper
+- a Vidfarm admin reviews and approves the template before it is made available in production
 
 Inputs:
 
@@ -51,7 +51,7 @@ Allowed text background colors:
 - `light_gray`
 - `dark_gray`
 
-REST API routes for this template:
+Typical routes for this template:
 
 - `GET /templates/template_0000`
 - `GET /templates/template_0000/skill`

package/templates/template_0000/package.json

@@ -2,19 +2,16 @@
   "name": "vidfarm_template_0000",
   "version": "1.0.0",
   "private": true,
-  "description": "Standalone Vidfarm template_0000 project for authoring, admin review, and controlled production promotion.",
+  "description": "Standalone Vidfarm template_0000 starter project for local template authoring.",
   "type": "module",
   "scripts": {
     "check": "tsc -p tsconfig.json --noEmit",
     "build": "tsc -p tsconfig.json",
-    "studio": "remotion studio src/remotion/index.tsx",
-    "admin:create-site": "node ./scripts/create-site.mjs",
-    "admin:render:cloud": "node ./scripts/render-cloud.mjs"
+    "studio": "remotion studio src/remotion/index.tsx"
   },
   "dependencies": {
     "@remotion/bundler": "4.0.355",
     "@remotion/cli": "4.0.355",
-    "@remotion/lambda": "4.0.355",
     "@remotion/renderer": "4.0.355",
     "react": "^18.3.1",
     "react-dom": "^18.3.1",
@@ -22,7 +19,7 @@
     "sharp": "^0.34.2"
   },
   "devDependencies": {
-    "@mevdragon/vidfarm-devcli": "^0.2.0",
+    "@mevdragon/vidfarm-devcli": "^0.2.2",
     "@types/node": "^24.0.1",
     "@types/react": "^18.3.23",
     "@types/react-dom": "^18.3.7",

package/templates/template_0000/template.config.json

@@ -2,21 +2,16 @@
   "template_id": "4c7a7e1a-7f35-4f30-9f86-9c8a63c7f2db",
   "slug_id": "template_0000",
   "project_name": "vidfarm_template_0000",
-  "github_repo": "mevdragon/vidfarm_template_0000",
-  "source_branch": "production",
+  "github_repo": "your-org/your-template-repo",
+  "source_branch": "main",
   "skill_path": "SKILL.md",
   "template_module_path": "src/template.js",
-  "release_controls": {
-    "shared_remotion_publish": "admin_only",
-    "platform_activation": "admin_only",
-    "production_docker_promotion": "admin_only"
-  },
   "remotion": {
-    "region": "us-east-1",
-    "function_name": "remotion-render-4-0-355-mem2048mb-disk2048mb-180sec",
-    "bucket_name": "remotionlambda-useast1-ujg7c0h43q",
+    "region": "local",
+    "function_name": "",
+    "bucket_name": "",
     "site_name": "vidfarm-template-0000",
-    "serve_url": "https://remotionlambda-useast1-ujg7c0h43q.s3.us-east-1.amazonaws.com/sites/vidfarm-template-0000/index.html",
+    "serve_url": "",
     "composition_id": "template-0000",
     "entry_point": "src/remotion/index.tsx",
     "props_file": "composition.json",

package/AWS_REMOTION_HANDOFF.md

@@ -1,311 +0,0 @@
-# New Repo AWS Remotion Handoff
-
-This document is for a fresh repo that wants to keep using the current shared Remotion AWS setup.
-
-It is not a description of how this repo is organized. It is the operating contract a new repo should follow.
-
-## Live AWS resources to reuse
-
-These were verified from AWS on 2026-05-16:
-
-- AWS account: `994816277608`
-- Region: `us-east-1`
-- Remotion render bucket: `remotionlambda-useast1-ujg7c0h43q`
-- Shared Lambda function: `remotion-render-4-0-355-mem2048mb-disk2048mb-180sec`
-- Lambda ARN: `arn:aws:lambda:us-east-1:994816277608:function:remotion-render-4-0-355-mem2048mb-disk2048mb-180sec`
-- Lambda execution role: `arn:aws:iam::994816277608:role/remotion-lambda-role`
-- Lambda runtime: `nodejs20.x`
-- Lambda architecture: `arm64`
-- Lambda timeout: `180`
-- Lambda memory: `2048`
-- Lambda ephemeral storage: `2048`
-
-The bucket is in `us-east-1` and site URLs follow this pattern:
-
-```text
-https://remotionlambda-useast1-ujg7c0h43q.s3.us-east-1.amazonaws.com/sites/<site-name>/index.html
-```
-
-## New repo rule set
-
-The new repo should treat AWS in two layers:
-
-1. Shared infrastructure you are reusing
-2. Repo-specific site bundle you will publish
-
-Shared infrastructure:
-
-- the AWS account
-- the Remotion render bucket
-- the existing Lambda render function
-- the Lambda execution role
-
-Repo-specific asset:
-
-- your new site bundle under `sites/<site-name>/index.html`
-
-That means a new repo does not need to deploy a new Lambda function just to render a new composition. It only needs to:
-
-1. use the same Remotion major/minor version as the shared Lambda
-2. publish a new site bundle
-3. render against that site URL and the shared function name
-
-## Required package versions
-
-The shared Lambda is tied to Remotion `4.0.355`, so the new repo should pin:
-
-```json
-{
-  "dependencies": {
-    "@remotion/cli": "4.0.355",
-    "@remotion/lambda": "4.0.355",
-    "@remotion/renderer": "4.0.355",
-    "remotion": "4.0.355"
-  }
-}
-```
-
-If you upgrade Remotion later, treat that as shared infra work, not normal app work.
-
-## What the new repo should configure
-
-The new repo should store these values in env or a small config module:
-
-```bash
-REMOTION_REGION=us-east-1
-REMOTION_FUNCTION_NAME=remotion-render-4-0-355-mem2048mb-disk2048mb-180sec
-REMOTION_BUCKET_NAME=remotionlambda-useast1-ujg7c0h43q
-REMOTION_SITE_NAME=my-new-site
-REMOTION_SERVE_URL=https://remotionlambda-useast1-ujg7c0h43q.s3.us-east-1.amazonaws.com/sites/my-new-site/index.html
-REMOTION_COMPOSITION_ID=MyComposition
-```
-
-Do not hard-code old values like `tweet-to-tiktok-2`.
-
-## Publish flow for the new repo
-
-The new repo should publish its own dedicated site name:
-
-```bash
-npx -y --package remotion@4.0.355 remotion lambda sites create src/index.ts \
-  --site-name=my-new-site \
-  --region=us-east-1
-```
-
-That writes your bundle into the shared bucket under:
-
-```text
-sites/my-new-site/index.html
-```
-
-Use a dedicated site name per repo or per video format. Do not reuse another repo’s site name unless you intentionally want one repo to overwrite another repo’s published bundle.
-
-## Render flow for the new repo
-
-CLI:
-
-```bash
-npx -y --package remotion@4.0.355 remotion lambda render \
-  "https://remotionlambda-useast1-ujg7c0h43q.s3.us-east-1.amazonaws.com/sites/my-new-site/index.html" \
-  "MyComposition" \
-  --props="./src/my-format/composition.json" \
-  --region="us-east-1" \
-  --timeout="120000" \
-  --function-name="remotion-render-4-0-355-mem2048mb-disk2048mb-180sec" \
-  --frames-per-lambda=100
-```
-
-Node:
-
-```ts
-import { renderMediaOnLambda } from "@remotion/lambda/client";
-
-await renderMediaOnLambda({
-  region: "us-east-1",
-  functionName: "remotion-render-4-0-355-mem2048mb-disk2048mb-180sec",
-  serveUrl:
-    "https://remotionlambda-useast1-ujg7c0h43q.s3.us-east-1.amazonaws.com/sites/my-new-site/index.html",
-  composition: "MyComposition",
-  inputProps: {},
-  codec: "h264",
-  timeoutInMilliseconds: 120000,
-  privacy: "private",
-});
-```
-
-## IAM: what already exists on the Lambda side
-
-The current Lambda execution role is:
-
-- `arn:aws:iam::994816277608:role/remotion-lambda-role`
-
-Trust policy:
-
-- principal: `lambda.amazonaws.com`
-- action: `sts:AssumeRole`
-
-Attached managed policy:
-
-- `arn:aws:iam::994816277608:policy/remotion-lambda-policy`
-
-The attached policy currently grants:
-
-- `s3:ListAllMyBuckets` on `*`
-- `s3:CreateBucket`
-- `s3:ListBucket`
-- `s3:PutBucketAcl`
-- `s3:GetObject`
-- `s3:DeleteObject`
-- `s3:PutObjectAcl`
-- `s3:PutObject`
-- `s3:GetBucketLocation`
-  on `arn:aws:s3:::remotionlambda-*`
-- `lambda:InvokeFunction`
-  on `arn:aws:lambda:*:*:function:remotion-render-*`
-- `logs:CreateLogGroup`
-  on `/aws/lambda-insights`
-- `logs:CreateLogStream`
-- `logs:PutLogEvents`
-  on `/aws/lambda/remotion-render-*` and `/aws/lambda-insights:*`
-
-The new repo does not need to recreate this role if it is reusing the existing shared Lambda.
-
-## IAM: what the new repo runner should have
-
-There are two separate permission sets to think about.
-
-### Option A: publish site bundles and render, but do not manage shared infra
-
-This is the safest default for a new repo.
-
-The repo runner needs enough permission to:
-
-- upload a site bundle into the shared Remotion bucket
-- render with the existing Lambda function
-- optionally inspect function metadata
-
-Recommended policy shape:
-
-```json
-{
-  "Version": "2012-10-17",
-  "Statement": [
-    {
-      "Sid": "RemotionBucketAccess",
-      "Effect": "Allow",
-      "Action": [
-        "s3:CreateBucket",
-        "s3:ListBucket",
-        "s3:GetBucketLocation",
-        "s3:GetObject",
-        "s3:PutObject",
-        "s3:DeleteObject",
-        "s3:PutBucketAcl",
-        "s3:PutObjectAcl"
-      ],
-      "Resource": [
-        "arn:aws:s3:::remotionlambda-useast1-ujg7c0h43q",
-        "arn:aws:s3:::remotionlambda-useast1-ujg7c0h43q/*"
-      ]
-    },
-    {
-      "Sid": "RemotionRenderInvoke",
-      "Effect": "Allow",
-      "Action": [
-        "lambda:InvokeFunction",
-        "lambda:GetFunctionConfiguration"
-      ],
-      "Resource": [
-        "arn:aws:lambda:us-east-1:994816277608:function:remotion-render-4-0-355-mem2048mb-disk2048mb-180sec"
-      ]
-    }
-  ]
-}
-```
-
-If the repo uses Remotion commands that list functions or sites, add:
-
-- `lambda:ListFunctions`
-
-If the repo needs broader compatibility across future Remotion function versions, widen the Lambda ARN to:
-
-- `arn:aws:lambda:us-east-1:994816277608:function:remotion-render-*`
-
-### Option B: also allow shared infra changes
-
-Only use this if the new repo is allowed to:
-
-- redeploy the shared Lambda function
-- rotate or replace the Lambda execution role
-- manage future Remotion infra upgrades
-
-That requires more than render permissions. At minimum, expect to need permissions in these areas:
-
-- `lambda:*` for create/update of the Remotion function family
-- `iam:PassRole` for `remotion-lambda-role`
-- potentially IAM role/policy create/update if Remotion is allowed to create or change roles
-- S3 bucket/object permissions on the shared Remotion bucket
-- CloudWatch Logs permissions
-
-Do not give this to a normal app repo unless that repo really owns shared infrastructure.
-
-## Recommended IAM split
-
-For a clean handoff, use two identities:
-
-1. `remotion-app-runner`
-   For normal repo use. Can publish sites and render videos.
-2. `remotion-infra-admin`
-   Rarely used. Can redeploy shared Lambda infra and manage IAM if needed.
-
-That prevents a content-format repo from accidentally mutating the shared Remotion backend.
-
-## What the new repo should not do
-
-- Do not store long-lived AWS keys in repo `.env` files.
-- Do not hard-code old site names from previous repos.
-- Do not assume this repo’s multi-site router pattern is required.
-- Do not redeploy the shared Lambda function during ordinary composition work.
-
-## Suggested new repo scripts
-
-`package.json`:
-
-```json
-{
-  "scripts": {
-    "create-site": "npx -y --package remotion@4.0.355 remotion lambda sites create src/index.ts --site-name=$REMOTION_SITE_NAME --region=$REMOTION_REGION",
-    "render:cloud": "npx -y --package remotion@4.0.355 remotion lambda render $REMOTION_SERVE_URL $REMOTION_COMPOSITION_ID --props=./src/composition.json --region=$REMOTION_REGION --function-name=$REMOTION_FUNCTION_NAME --timeout=120000 --frames-per-lambda=100"
-  }
-}
-```
-
-If shell interpolation in `package.json` is awkward in your environment, wrap these in small shell scripts instead.
-
-## Bootstrap checklist for the new repo
-
-1. Pin Remotion packages to `4.0.355`.
-2. Add the config variables listed above.
-3. Create a new dedicated site name.
-4. Use a non-admin AWS identity that can publish and render.
-5. Publish the site bundle once.
-6. Run one smoke render against the shared function.
-7. Save the resulting serve URL and composition ID in repo config.
-
-## Verified facts vs inferred guidance
-
-Verified from AWS:
-
-- account id
-- region
-- bucket name
-- function name
-- function config
-- Lambda execution role name
-- attached Lambda execution policy
-
-Not directly readable with the current AWS identity:
-
-- the current IAM policies attached to the calling IAM user `remotion-user`
-
-Because of that, the caller policy in this document is the recommended minimum policy for a new repo runner, derived from the live setup and the operations the new repo needs to perform.