@mevdragon/vidfarm-devcli 0.2.0 → 0.2.2

package/.env.example

@@ -1,48 +1,15 @@
 NODE_ENV="development"
 PORT="3000"
 
-VIDFARM_DB_PATH="./data/vidfarm.sqlite"
-VIDFARM_DATA_DIR="./data"
-
-ENCRYPTION_SECRET="replace-with-a-long-random-secret"
-API_KEY_SALT="replace-with-a-second-long-random-secret"
-WEBHOOK_SECRET="replace-with-a-third-long-random-secret"
-
-WORKER_POLL_MS="1500"
-WORKER_BATCH_SIZE="2"
-WORKER_MAX_CONCURRENT_JOBS="1"
-DEFAULT_JOB_DELAY_SECONDS="20"
-MAX_PENDING_JOBS_GLOBAL="0"
-MAX_PENDING_JOBS_PER_CUSTOMER="0"
-
-PUBLIC_BASE_URL="https://vidfarm.cloud.zoomgtm.com"
-VIDFARM_ADMIN_EMAILS="admin@example.com"
-VIDFARM_DEVELOPER_EMAILS="developer@example.com"
-TEMPLATE_SOURCE_ROOT="./data/template-sources"
-STORAGE_DRIVER="local"
-AWS_REGION="us-east-1"
-AWS_S3_BUCKET=""
-AWS_S3_PUBLIC_READ="false"
-AWS_S3_ENDPOINT=""
-AWS_ACCESS_KEY_ID=""
-AWS_SECRET_ACCESS_KEY=""
-
-RESEND_API_KEY=""
-RESEND_FROM_EMAIL="noreply@example.com"
-
 OPENAI_API_KEY=""
 OPENROUTER_API_KEY=""
 GEMINI_API_KEY=""
 PERPLEXITY_API_KEY=""
 
-REMOTION_FUNCTION_NAME=""
-REMOTION_REGION="us-east-1"
-REMOTION_BUCKET_NAME=""
-REMOTION_SITE_NAME="vidfarm-template-0000"
-REMOTION_SERVE_URL=""
-REMOTION_COMPOSITION_ID="template-0000"
-REMOTION_AWS_ACCESS_KEY_ID=""
-REMOTION_AWS_SECRET_ACCESS_KEY=""
-REMOTION_MODE="auto"
+# Optional when calling a hosted Vidfarm API directly.
+VIDFARM_USER_ID=""
+VIDFARM_API_KEY=""
 
-MOCK_PROVIDER_RESPONSES="true"
+# Optional local overrides. The CLI will choose sensible local defaults.
+PUBLIC_BASE_URL="http://localhost:3310"
+REMOTION_MODE="local"

package/GETTING_STARTED.developers.md

@@ -0,0 +1,178 @@
+# Vidfarm Third-Party Developer Guide
+
+This guide is for external developers building Vidfarm templates locally.
+
+It covers:
+
+- the local setup
+- the template contract
+- the local CLI workflow
+- the minimum hosted-platform context you need
+
+It does not cover platform internals, admin release flow, or cloud infrastructure.
+
+## Local Setup
+
+1. Create a working folder for your template project.
+2. Install the CLI from npm.
+3. Create a local `.env` from `.env.example`.
+4. Add at least one AI provider key.
+
+Typical `.env`:
+
+```env
+GEMINI_API_KEY=""
+OPENAI_API_KEY=""
+OPENROUTER_API_KEY=""
+PERPLEXITY_API_KEY=""
+```
+
+Start the local runtime:
+
+```bash
+npx @mevdragon/vidfarm-devcli dev --port 3310 --reset
+```
+
+This starts:
+
+- the local Vidfarm API
+- the local worker
+- local SQLite state
+- local filesystem-backed media storage
+- local Remotion rendering when your template uses Remotion
+
+## Local Session
+
+Run:
+
+```bash
+npx @mevdragon/vidfarm-devcli session
+```
+
+This prints a reusable local session so you can test the API with `curl` or your own scripts.
+
+## Generate A Starter Template
+
+To scaffold a new template:
+
+```bash
+npx @mevdragon/vidfarm-devcli generate-template \
+  --slug-id template_0001 \
+  --template-dir ./templates/template_0001
+```
+
+That scaffold includes:
+
+- template source files
+- a template-local `SKILL.md`
+- `research/source_notes.md`
+- `research/preview/`
+- `src/template-dna.ts`
+
+If preview media is present, the scaffold can also help generate `viral_dna` and `visual_dna`.
+
+## Validate Your Template
+
+Use the CLI before handing a template off:
+
+```bash
+npx @mevdragon/vidfarm-devcli validate-template --template-id template_0000
+```
+
+You should also run real local jobs for the operations you added and inspect the results.
+
+## Template Contract
+
+Vidfarm expects templates to fit a consistent contract.
+
+Each template should define:
+
+- `id`
+- `slugId`
+- `version`
+- `about`
+- `configSchema`
+- `operations`
+- `jobs`
+
+The important idea is:
+
+- `operations` are the public actions
+- `jobs` do the actual work
+- every meaningful action should fit the async job pattern
+
+Each operation should include a `smokeTestPayload`.
+
+Each template should also include:
+
+- a template-local `SKILL.md`
+- `about.viral_dna`
+- `about.visual_dna`
+- `about.preview_media`
+- `about.link_to_original` when relevant
+
+## How The Hosted Platform Uses Your Template
+
+The hosted platform loads templates behind a standard wrapper.
+
+From the caller's perspective, templates are used through routes like:
+
+- `GET /api/v1/templates/:templateId`
+- `GET /api/v1/templates/:templateId/skill`
+- `POST /api/v1/templates/:templateId/config`
+- `POST /api/v1/templates/:templateId/operations/:operationName`
+- `GET /api/v1/templates/:templateId/jobs/:jobId`
+- `GET /api/v1/templates/:templateId/jobs/:jobId/logs`
+
+This means your template should focus on:
+
+- clear metadata
+- strong input schemas
+- repeatable workflow logic
+- useful job output
+
+Avoid building custom standalone HTTP APIs inside the template.
+
+## Review And Approval
+
+Finishing a template locally does not make it live automatically.
+
+The expected flow is:
+
+1. build and validate the template locally
+2. hand off the template source for review
+3. wait for Vidfarm admin approval before the template is made available on the hosted platform
+
+This is the key production boundary external developers need to understand. Your job is to produce a clean, repeatable template package that passes review.
+
+## Hosted Auth Context
+
+When you call a hosted Vidfarm API directly, authenticated requests use:
+
+- `vidfarm-user-id`
+- `vidfarm-api-key`
+
+Those values come from Vidfarm user auth and settings.
+
+For local development, the CLI session command handles this for you by printing a seeded local session.
+
+## Remotion
+
+For third-party template authors, Remotion is local-only in this workflow.
+
+If your template uses Remotion:
+
+- build it locally
+- validate it locally
+- keep the template code compatible with local CLI execution
+
+You do not need shared cloud Remotion infrastructure details to author a template.
+
+## Recommended Reading
+
+Start with:
+
+1. `README.md`
+2. `SKILL.developer.md`
+3. `templates/template_0000/SKILL.md`
+4. `templates/template_0000/src/template.ts`

package/README.md

@@ -1,51 +1,28 @@
-# Vidfarm
+# Vidfarm Dev CLI
 
-Vidfarm is a single-container Node.js control plane for async video template pipelines. It follows the architecture in [video-pipeline-architecture-draft.md](/Users/localghost/Projects/OfficeX/OfficeX/ZoomGTM/vidfarm/video-pipeline-architecture-draft.md) and [PLATFORM_SPEC.md](/Users/localghost/Projects/OfficeX/OfficeX/ZoomGTM/vidfarm/PLATFORM_SPEC.md): Hono API, SQLite-backed jobs and provider-key leasing, S3-compatible storage, and an in-process worker suitable for Docker on EC2.
+`@mevdragon/vidfarm-devcli` is the local development toolkit for third-party Vidfarm template authors.
 
-Production is now intended to run as one HTTPS host at `https://vidfarm.cloud.zoomgtm.com`, with the HTML console served from `/` and the API served under `/api/v1/...`.
+This package is intentionally scoped to:
 
-## What Is Included
+- building templates under `templates/*`
+- running the local Vidfarm API and worker
+- testing template operations as async jobs
+- validating template metadata, skills, and smoke test payloads
+- rendering Remotion locally when a template uses Remotion
 
-- Unified frontend and backend on one host
-- Async template API under `/api/v1/templates/:templateId/*`
-- User auth/profile/provider-key routes under `/api/v1/user/*`
-- Email OTP login with API key issuance
-- `is_developer` user flag, assigned from allowlisted emails, required for template source submission
-- Customer-scoped provider key vault with encryption at rest
-- SQLite-backed job queue and provider-key lease coordination
-- Structured job logs, artifacts, billing events, and webhook delivery queue
-- Local storage mode plus S3-compatible mode for AWS
-- Remotion adapter seam and a sample `template_0000` slideshow pipeline
+It is intentionally not documentation for platform internals, production deployment, admin release flow, or shared cloud infrastructure.
 
 ## Quick Start
 
-```bash
-npm install
-cp .env.example .env
-npm run dev
-```
-
-The service starts on `http://localhost:3000` by default and creates SQLite plus local artifact storage under `./data`.
-
-## Template Developer CLI
-
-For local template development, use the bundled CLI instead of manually wiring auth, provider keys, SQLite, and Remotion:
+1. Create a local `.env` from the example file.
+2. Add at least one AI provider key.
+3. Start the local CLI runtime.
 
 ```bash
-npm install
+cp .env.example .env
 npx @mevdragon/vidfarm-devcli dev --port 3310 --reset
 ```
 
-What it does:
-
-- starts the same REST API and in-process worker as production
-- provisions a local SQLite database automatically
-- uses local filesystem storage as an S3 stand-in
-- seeds a dev customer and API key
-- seeds provider keys from local `.env` variables like `OPENAI_API_KEY`, `GEMINI_API_KEY`, and `OPENROUTER_API_KEY`
-- falls back to mock provider keys plus mocked AI responses when no env keys are present
-- renders Remotion compositions locally instead of using Lambda
-
 Useful commands:
 
 ```bash
@@ -57,244 +34,83 @@ npx @mevdragon/vidfarm-devcli analyze-viral-dna --template-dir ./templates/templ
 npx @mevdragon/vidfarm-devcli analyze-visual-dna --template-dir ./templates/template_0001
 ```
 
-After install, the package also exposes `vidfarm` and `vidfarm-devcli` as local binaries.
-
-`vidfarm session` prints reusable auth headers and a sample `curl` request for the local REST API.
-
-`generate-template` now scaffolds a standard `research/` area for new templates:
-
-- `research/source_notes.md` for original-format notes
-- `research/preview/` for source screenshots or video
-- `src/template-dna.ts` as the checked-in metadata module that feeds `about.viral_dna`, `about.visual_dna`, and `about.link_to_original`
-
-If preview media is already present, or if you pass `--source-preview-dir`, scaffold generation will run both DNA analyzers automatically unless `--skip-dna-analysis` is set.
-
-## Environment
-
-Primary variables:
-
-- `PORT`
-- `VIDFARM_DB_PATH`
-- `VIDFARM_DATA_DIR`
-- `VIDFARM_ADMIN_EMAILS`
-- `TEMPLATE_SOURCE_ROOT`
-- `ENCRYPTION_SECRET`
-- `API_KEY_SALT`
-- `STORAGE_DRIVER=local|s3`
-- `AWS_REGION`
-- `AWS_S3_BUCKET`
-- `AWS_S3_PUBLIC_READ=true|false`
-- `PUBLIC_BASE_URL`
-- `RESEND_API_KEY`
-- `WEBHOOK_SECRET`
-- `MOCK_PROVIDER_RESPONSES=true|false`
-- `VIDFARM_DEVELOPER_EMAILS`
-- `WORKER_MAX_CONCURRENT_JOBS`
-- `MAX_PENDING_JOBS_GLOBAL`
-- `MAX_PENDING_JOBS_PER_CUSTOMER`
-
-Remotion-specific variables:
-
-- `REMOTION_REGION`
-- `REMOTION_FUNCTION_NAME`
-- `REMOTION_BUCKET_NAME`
-- `REMOTION_SITE_NAME`
-- `REMOTION_SERVE_URL`
-- `REMOTION_COMPOSITION_ID`
-- `REMOTION_AWS_ACCESS_KEY_ID`
-- `REMOTION_AWS_SECRET_ACCESS_KEY`
-
-When `MOCK_PROVIDER_RESPONSES=true`, AI provider calls use the real key-leasing flow but return mocked content. This makes local end-to-end testing possible without burning customer API calls.
-
-When using `npx @mevdragon/vidfarm-devcli dev`, the CLI automatically chooses local-friendly defaults:
-
-- `STORAGE_DRIVER=local`
-- `REMOTION_MODE=local`
-- a local SQLite path under `.vidfarm/local`
-- `MOCK_PROVIDER_RESPONSES=false` if real provider env keys are present, otherwise `true`
-
-## Remotion AWS
-
-For shared Remotion AWS infra, use [AWS_REMOTION_HANDOFF.md](/Users/localghost/Projects/OfficeX/OfficeX/ZoomGTM/vidfarm/AWS_REMOTION_HANDOFF.md) as the operating contract.
-
-Shared Remotion AWS publish is an admin-only release step. Template developers may build and test locally, but they should not push directly to the shared production Remotion account. The intended promotion flow is:
-
-1. developer pushes template code to GitHub `production`
-2. admin reviews and pins a commit SHA
-3. admin publishes the approved Remotion site bundle
-4. admin activates the approved template release
-5. admin rebuilds and redeploys the production Docker image
-
-The key points verified on `2026-05-16` are:
-
-- region: `us-east-1`
-- shared Lambda function: `remotion-render-4-0-355-mem2048mb-disk2048mb-180sec`
-- shared bucket: `remotionlambda-useast1-ujg7c0h43q`
-- Remotion package version to pin: `4.0.355`
-
-This repo also has separate Remotion AWS runner credentials available in local production env config via:
-
-- `REMOTION_AWS_ACCESS_KEY_ID`
-- `REMOTION_AWS_SECRET_ACCESS_KEY`
-
-Use those for Remotion site publish/render work rather than assuming the generic app AWS credentials are the right identity.
-
-Recommended repo-level config for real Remotion work:
-
-```env
-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=your-site-name
-REMOTION_SERVE_URL=https://remotionlambda-useast1-ujg7c0h43q.s3.us-east-1.amazonaws.com/sites/your-site-name/index.html
-REMOTION_COMPOSITION_ID=YourComposition
-```
-
-If you wire real Lambda rendering into `src/services/remotion.ts`, preserve the current platform contract and make the service read these env vars rather than hard-coding one-off values.
-
-## API Flow
-
-1. `POST /api/v1/user/request-otp`
-2. `POST /api/v1/user/verify-otp`
-3. `POST /api/v1/user/me/provider-keys`
-4. `GET /api/v1/templates/template_0000`
-5. `GET /api/v1/templates/template_0000/skill`
-6. `POST /api/v1/templates/template_0000/config`
-7. `POST /api/v1/templates/template_0000/operations/create_slideshow`
-8. Poll `GET /api/v1/templates/template_0000/jobs/:jobId`
-9. List or filter jobs with `GET /api/v1/templates/template_0000/jobs?tracer=...&start_time=...&end_time=...`
-10. Stream timeline data from `GET /api/v1/templates/template_0000/jobs/:jobId/logs?start_time=...&end_time=...`
-
-## Template Release Flow
+After install, the package exposes both `vidfarm` and `vidfarm-devcli` as local binaries.
 
-Templates can still live in this repo, but the platform now supports a GitHub-backed release workflow for in-house templates:
+## What The Local CLI Does
 
-1. developer keeps template code in GitHub
-2. the approved branch convention is `production`
-3. admin registers the template source with repo URL, module path, build command, and `SKILL.md` path
-4. admin imports a specific commit, or the current `production` head
-5. platform builds the repo, loads the template module, and runs certification
-6. only certified releases can be activated
-7. activation pins the live template to a specific commit SHA, not a floating branch head
+The local CLI runs the same template contract used by the hosted platform, but with local-first defaults:
 
-Template management endpoints:
+- local SQLite state under `.vidfarm/local`
+- local filesystem storage instead of cloud object storage
+- local Remotion rendering
+- a seeded developer session for local testing
+- provider keys sourced from your local `.env`
+- mocked provider responses only when no real provider keys are present
 
-- `GET /api/v1/templates/sources`
-- `POST /api/v1/templates/sources`
-- `GET /api/v1/templates/releases`
-- `POST /api/v1/templates/sources/:sourceId/import`
-- `POST /api/v1/templates/releases/:releaseId/activate`
+Use `vidfarm session` to print reusable auth headers and a sample `curl` request for the local REST API.
 
-`POST /api/v1/templates/sources` requires a user with `is_developer=true`. That flag is assigned from `VIDFARM_DEVELOPER_EMAILS` or `VIDFARM_ADMIN_EMAILS` during OTP verification. Registration now requires a self-issued UUIDv4 `template_id` plus a human-readable `slug_id`, and the platform rejects reused `template_id` values with an explicit conflict error. Import and activation remain admin-only via `VIDFARM_ADMIN_EMAILS`.
+## What The Hosted Platform Expects From Templates
 
-## Template Certification
+Vidfarm treats templates as async job producers, not as ad hoc endpoints.
 
-Every template must have:
+Each template should provide:
 
-- a `SKILL.md` file for customer AI agents
-- both `about.viral_dna` and `about.visual_dna`
-- at least one operation
-- valid workflow references
+- stable template metadata
+- a `SKILL.md` file for users and agents
+- one or more named operations
+- workflow functions behind those operations
 - a `smokeTestPayload` for each operation
+- `about.viral_dna` and `about.visual_dna`
 
-Use the CLI locally before import/activation:
+At runtime, the platform uses the template wrapper to expose a consistent API shape:
 
-```bash
-npx @mevdragon/vidfarm-devcli validate-template --template-id template_0000
-```
+- `GET /api/v1/templates/:templateId`
+- `GET /api/v1/templates/:templateId/skill`
+- `POST /api/v1/templates/:templateId/config`
+- `POST /api/v1/templates/:templateId/operations/:operationName`
+- `GET /api/v1/templates/:templateId/jobs/:jobId`
+- `GET /api/v1/templates/:templateId/jobs/:jobId/logs`
 
-Not every template needs Remotion. Certification only requires Remotion behavior if the template itself calls `ctx.remotion`.
+Operations should return work through the job system rather than inventing one-off synchronous routes.
 
-## Docker
+## Approval Flow
 
-```bash
-docker compose up --build
-```
-
-For local Docker, `docker-compose.yml` already mounts `./data:/app/data`, which keeps SQLite across container restarts and rebuilds on the same machine.
-
-For production on EC2, the CDK stack mounts a dedicated EBS volume at `/var/lib/vidfarm` on the instance and binds it into the container as `/app/data`. That means the following survive shutdowns, reboots, and container updates:
+Third-party developers build and validate templates locally first.
 
-- `vidfarm.sqlite`
-- SQLite WAL/SHM files
-- imported template source checkouts
-- any local fallback runtime data under `/app/data`
+After handoff, a Vidfarm admin reviews the template before it is made available on the hosted platform. Template authors should assume there is an approval step between local development and production availability.
 
-Artifacts and workspace objects should still live in S3 in production:
-
-```env
-STORAGE_DRIVER=s3
-AWS_REGION=us-east-1
-AWS_S3_BUCKET=your-vidfarm-bucket
-AWS_S3_PUBLIC_READ=false
-PUBLIC_BASE_URL=https://vidfarm.cloud.zoomgtm.com
-```
+## Authentication Context
 
-Queue protection for small EC2 instances is now SQLite-backed and built into the app:
+When calling a hosted Vidfarm API directly, authenticated requests use:
 
-- `WORKER_MAX_CONCURRENT_JOBS=1` by default
-- `WORKER_BATCH_SIZE=2` by default
-- `MAX_PENDING_JOBS_GLOBAL=0` by default
-- `MAX_PENDING_JOBS_PER_CUSTOMER=0` by default
+- `vidfarm-user-id`
+- `vidfarm-api-key`
 
-With the default `0` values, submissions are always accepted and persisted in SQLite. The worker simply drains the queue at the configured concurrency. Set either pending-job value above `0` only if you later decide you want a hard backlog cap.
+Those values come from Vidfarm login and settings, not from platform infrastructure secrets.
 
-## AWS CDK Production
+For local CLI usage, the `session` command gives you a local seeded session so you can test without manually wiring auth state.
 
-The production CDK app lives under `infra/cdk` and provisions:
+## Provider Keys
 
-- one S3 bucket for Vidfarm object storage
-- one public ALB with HTTP to HTTPS redirect
-- one ACM certificate for `vidfarm.cloud.zoomgtm.com`
-- one EC2 instance running the Docker image
-- one dedicated encrypted EBS data volume retained separately from the container
-- Route53 `A` and `AAAA` alias records for the production hostname
+Templates should work with the developer's own upstream AI keys.
 
-Required shell variables before synth or deploy:
+Typical local `.env`:
 
-```bash
-export CDK_DEFAULT_ACCOUNT=123456789012
-export CDK_DEFAULT_REGION=us-east-1
-export VIDFARM_ZONE_NAME=cloud.zoomgtm.com
-export VIDFARM_ZONE_ID=Z1234567890ABC
-export VIDFARM_RECORD_NAME=vidfarm
-export VIDFARM_PUBLIC_BASE_URL=https://vidfarm.cloud.zoomgtm.com
-export VIDFARM_ADMIN_EMAILS=admin@zoomgtm.com
-export VIDFARM_DEVELOPER_EMAILS=dev1@zoomgtm.com,dev2@zoomgtm.com
-export VIDFARM_ENCRYPTION_SECRET='replace-with-a-long-random-secret'
-export VIDFARM_API_KEY_SALT='replace-with-a-second-long-random-secret'
-export VIDFARM_WEBHOOK_SECRET='replace-with-a-third-long-random-secret'
+```env
+GEMINI_API_KEY=""
+OPENAI_API_KEY=""
+OPENROUTER_API_KEY=""
+PERPLEXITY_API_KEY=""
 ```
 
-Optional app env passthroughs are supported too, including:
-
-- `VIDFARM_RESEND_API_KEY`
-- `VIDFARM_RESEND_FROM_EMAIL`
-- `VIDFARM_OPENAI_API_KEY`
-- `VIDFARM_OPENROUTER_API_KEY`
-- `VIDFARM_GEMINI_API_KEY`
-- `VIDFARM_PERPLEXITY_API_KEY`
-- `VIDFARM_REMOTION_*`
-- `VIDFARM_INSTANCE_TYPE`
-- `VIDFARM_DATA_VOLUME_SIZE_GIB`
-- `VIDFARM_WORKER_MAX_CONCURRENT_JOBS`
-- `VIDFARM_MAX_PENDING_JOBS_GLOBAL`
-- `VIDFARM_MAX_PENDING_JOBS_PER_CUSTOMER`
+You usually only need one provider key to develop and test a template locally.
 
-If you do not set `VIDFARM_INSTANCE_TYPE`, the CDK app now defaults to `t3.small`.
+## Remotion
 
-Deploy flow:
-
-```bash
-npm install
-npm run cdk:synth
-npx aws-cdk bootstrap aws://$CDK_DEFAULT_ACCOUNT/$CDK_DEFAULT_REGION
-npm run cdk:deploy
-```
+For third-party template authors, Remotion is local.
 
-The stack builds the Docker image locally, pushes it to an asset ECR repository, installs Docker on the EC2 host, mounts the retained EBS volume, writes the production env file, and runs the container as a systemd service.
+If your template uses `ctx.remotion`, develop and validate it locally through the CLI. This package does not document or require shared cloud Remotion infrastructure.
 
-## Notes
+## Next Read
 
-- `template_0000` is the canonical sample internal template slug. Its current sample `template_id` is `4c7a7e1a-7f35-4f30-9f86-9c8a63c7f2db`. Add more templates by registering them in [src/registry.ts](/Users/localghost/Projects/OfficeX/OfficeX/ZoomGTM/vidfarm/src/registry.ts).
-- Remotion is still stubbed behind [src/services/remotion.ts](/Users/localghost/Projects/OfficeX/OfficeX/ZoomGTM/vidfarm/src/services/remotion.ts). When upgrading it to real Lambda submission, follow [AWS_REMOTION_HANDOFF.md](/Users/localghost/Projects/OfficeX/OfficeX/ZoomGTM/vidfarm/AWS_REMOTION_HANDOFF.md) and use the Remotion-specific AWS credentials already available in local production env config.
+For the external template-author workflow, continue with [GETTING_STARTED.developers.md](./GETTING_STARTED.developers.md) and the example template in [`templates/template_0000`](./templates/template_0000).