rsc-universal 0.1.1

package/skills/remotion-video/scripts/verify.sh

@@ -0,0 +1,169 @@
+#!/usr/bin/env bash
+# verify.sh — check that a Remotion project is well-formed and (optionally) renders.
+#
+# Usage:
+#   bash scripts/verify.sh <project-dir>            # read-only: static + `remotion compositions`
+#   bash scripts/verify.sh <project-dir> --render   # also do a short region test render + ffprobe
+#   bash scripts/verify.sh                          # no target -> nothing to check, exit 0
+#
+# Default mode is READ-ONLY: it never renders, installs, or writes. A render produces
+# a file and burns CPU, so the actual test render is gated behind --render (opt-in).
+#
+# What it checks, in the spec's order:
+#   1. If Node + a Remotion project are present: `npx remotion compositions` succeeds
+#      and lists at least one composition id (read-only).
+#   2. With --render AND ffmpeg present: render a short region (frames 0-15) of the
+#      first composition to a temp MP4, assert it is non-empty, and `ffprobe` confirms
+#      a video stream with width/height. The temp file is removed.
+#   3. Static fallback (no node, or no project, or --render not given): assert at least
+#      one composition .tsx exists and a render script/command references a real
+#      composition id + an output path.
+#
+# Exits 0 on a clean project AND on an empty/clean target (no false failure):
+#   - no argument            -> "nothing to check", exit 0
+#   - dir with no .tsx files -> nothing to verify, exit 0
+# Exits non-zero only when a real, present project breaks a rule.
+#
+# Portability: stock macOS bash 3.2. set -u on; set -e off (each check owns its exit).
+
+set -u
+
+if [ -t 1 ] && command -v tput >/dev/null 2>&1; then
+  RED="$(tput setaf 1)"; GREEN="$(tput setaf 2)"; YELLOW="$(tput setaf 3)"; RESET="$(tput sgr0)"
+else
+  RED=""; GREEN=""; YELLOW=""; RESET=""
+fi
+
+fail() { printf '%s\n' "${RED}FAIL: $1${RESET}"; failures=$((failures + 1)); }
+warn() { printf '%s\n' "${YELLOW}WARN: $1${RESET}"; }
+ok()   { printf '%s\n' "${GREEN}OK: $1${RESET}"; }
+
+# --- args ------------------------------------------------------------------
+target=""
+do_render=0
+for arg in "$@"; do
+  case "$arg" in
+    --render) do_render=1 ;;
+    *) [ -z "$target" ] && target="$arg" || warn "ignoring extra argument '$arg'" ;;
+  esac
+done
+
+if [ -z "$target" ]; then
+  printf '%s\n' "${YELLOW}Nothing to check (no project dir given). Pass a Remotion project directory.${RESET}"
+  exit 0
+fi
+
+if [ ! -d "$target" ]; then
+  printf '%s\n' "${YELLOW}'$target' is not a directory. Pass a Remotion project directory. Nothing to check.${RESET}"
+  exit 0
+fi
+
+failures=0
+
+# --- find composition .tsx files (look in target and target/src) -----------
+tsx_files=""
+for d in "$target" "$target/src"; do
+  [ -d "$d" ] || continue
+  for f in "$d"/*.tsx "$d"/**/*.tsx; do
+    [ -e "$f" ] && tsx_files="${tsx_files}${tsx_files:+
+}$f"
+  done
+done
+# de-dup is unnecessary; just detect presence
+has_tsx=0
+[ -n "$tsx_files" ] && has_tsx=1
+
+if [ "$has_tsx" -eq 0 ]; then
+  printf '%s\n' "${YELLOW}No .tsx files under '$target' (or '$target/src'). Not a Remotion project — nothing to verify.${RESET}"
+  exit 0
+fi
+
+printf '\n%s\n' "Checking Remotion project: $target"
+
+# --- extract a composition id from <Composition id="..."> -------------------
+comp_id="$(grep -rhoE 'id[[:space:]]*=[[:space:]]*"[^"]+"' $tsx_files 2>/dev/null \
+  | head -1 | sed -E 's/.*"([^"]+)".*/\1/')"
+
+# =============================================================================
+# Mode 1: dynamic check via the Remotion CLI (read-only)
+# =============================================================================
+ran_dynamic=0
+if command -v node >/dev/null 2>&1 && command -v npx >/dev/null 2>&1 \
+   && [ -f "$target/package.json" ]; then
+  printf '%s\n' "node + package.json present — listing compositions (read-only)..."
+  comps="$(cd "$target" && npx --no-install remotion compositions 2>/dev/null)"
+  if [ -n "$comps" ]; then
+    ran_dynamic=1
+    ok "remotion compositions succeeded"
+    listed_id="$(printf '%s\n' "$comps" | grep -vE '^(Composition|----|$)' | awk '{print $1}' | grep -v '^$' | head -1)"
+    [ -z "$listed_id" ] && listed_id="$(printf '%s\n' "$comps" | awk 'NR==2{print $1}')"
+    if [ -n "$listed_id" ]; then
+      ok "found composition id: $listed_id"
+      [ -z "$comp_id" ] && comp_id="$listed_id"
+    else
+      fail "remotion compositions listed no usable composition id"
+    fi
+
+    # --- Mode 2: optional region test render (opt-in, writes a temp file) ---
+    if [ "$do_render" -eq 1 ] && [ -n "$comp_id" ]; then
+      if command -v ffprobe >/dev/null 2>&1; then
+        tmp_out="$(mktemp -t remotion-verify-XXXXXX).mp4"
+        printf '%s\n' "Rendering region test (frames 0-15) of '$comp_id' -> $tmp_out ..."
+        if (cd "$target" && npx --no-install remotion render "$comp_id" "$tmp_out" --frames=0-15 >/dev/null 2>&1) && [ -s "$tmp_out" ]; then
+          dims="$(ffprobe -v error -select_streams v:0 -show_entries stream=width,height -of csv=p=0 "$tmp_out" 2>/dev/null)"
+          if [ -n "$dims" ]; then
+            ok "render produced a non-empty MP4 with a video stream ($dims)"
+          else
+            fail "render produced a file but ffprobe found no video stream"
+          fi
+        else
+          fail "region test render failed or produced an empty file"
+        fi
+        rm -f "$tmp_out"
+      else
+        warn "--render requested but ffprobe not found; skipping the render check."
+      fi
+    elif [ "$do_render" -eq 0 ]; then
+      printf '%s\n' "(read-only mode: pass --render to also do a region test render + ffprobe)"
+    fi
+  else
+    warn "remotion CLI not runnable here (deps not installed?) — falling back to static checks."
+  fi
+fi
+
+# =============================================================================
+# Mode 3: static fallback (no node/CLI run, or CLI unavailable)
+# =============================================================================
+if [ "$ran_dynamic" -eq 0 ]; then
+  printf '%s\n' "Static checks (no runnable Remotion CLI):"
+  if [ -n "$comp_id" ]; then
+    ok "found a <Composition> with id: $comp_id"
+  else
+    fail "no <Composition id=\"...\"> found in any .tsx — a Remotion project needs at least one composition."
+  fi
+fi
+
+# --- render command references a real id + an output path (both modes) ------
+render_cmd="$(grep -rhoE 'remotion render[^\"'\''<]*' $tsx_files "$target"/*.json "$target"/*.ts "$target"/*.md "$target"/scripts/* 2>/dev/null | head -1)"
+if [ -n "$render_cmd" ]; then
+  if printf '%s' "$render_cmd" | grep -qE 'remotion render[[:space:]]+[A-Za-z0-9_-]+'; then
+    ok "a render command references a composition id"
+  else
+    warn "found 'remotion render' but no explicit composition id after it (a picker will prompt)."
+  fi
+  if printf '%s' "$render_cmd" | grep -qiE '\.(mp4|mov|webm|gif)'; then
+    ok "the render command names an output path"
+  else
+    warn "render command has no explicit output file (.mp4/.mov/.webm/.gif)."
+  fi
+else
+  warn "no 'remotion render' command found in the project files (scripts/, package.json, *.md)."
+fi
+
+printf '\n'
+if [ "$failures" -gt 0 ]; then
+  printf '%s\n' "${RED}$failures check(s) failed.${RESET}"
+  exit 1
+fi
+printf '%s\n' "${GREEN}All checks passed.${RESET}"
+exit 0

package/skills/render/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: render
+description: "Use when deploying or fixing an app on Render (render.com) — web services, background workers, cron jobs, private services, managed Postgres/Key-Value, and especially the render.yaml Blueprint. Use when a deploy fails with 'no open ports detected' or returns 502 on first deploy, a free service cold-starts after going idle, or a free Postgres is about to expire and take its data. Triggers: 'deploy to Render', 'write a render.yaml', 'render blueprint', 'Render background worker', 'Render cron job', 'no open ports detected', 'wire DATABASE_URL between Render services', 'why does my free Render service take 30 seconds to wake', 'desplegar en Render', 'configurar render.yaml', 'mi servicio en Render da 502'. NOT generic ship/release flow (that is deployment) and NOT another PaaS like railway or fly-io."
+tags: [render, paas, deployment, render-yaml, cron, background-worker, infrastructure-as-code]
+recommends: [deployment, postgresdb, docker, domains-dns, github-actions, scaling]
+origin: risco
+---
+
+# Render — make this repo deploy correctly, wired as code
+
+Take any repo and make it deploy on **Render** (render.com) in one pass: pick the right
+service type, declare everything in a version-controlled `render.yaml` Blueprint, bind the
+port the way Render expects, and wire `DATABASE_URL` / secrets across services so they
+survive rotation. Steer clear of the four traps that eat first deploys: the
+"no open ports detected" 502, the free-tier spin-down, the 30-day free-Postgres expiry,
+and the 12-hour cron kill.
+
+```text
+pick service type → render.yaml at repo root → bind 0.0.0.0:$PORT → wire env across services → push (auto-deploy)
+        │                                                                                            │
+   web|worker|cron|pserv|static|keyvalue                                       full key surface → references/blueprint-reference.md
+```
+
+Facts here are dated to **2026-06-02** against render.com/docs. Render ships changes; if a
+key or limit looks off, confirm against the live Blueprint spec before betting a deploy on it.
+
+## The one decision that decides everything: service type
+
+Pick the type **before** you write a line of YAML. The type sets the billing model, whether
+the process gets a public URL, and whether Render expects it to bind a port. Choosing wrong
+means a worker that never starts because Render waited for a port, or a 12-hour job that dies
+silently as a cron.
+
+| The process… | Type | `runtime` required? | Gets a public URL? |
+| --- | --- | --- | --- |
+| serves HTTP/WebSocket traffic | `web` | yes | yes |
+| runs forever, no inbound URL (queue consumer, Celery) | `worker` | yes | no |
+| runs, does work, exits — on a schedule | `cron` | yes | no |
+| internal-only API, reachable only inside Render's network | `pserv` | yes | no (internal host only) |
+| pre-built static assets (SPA, docs) | `web` + `runtime: static` | yes (`static`) | yes |
+| cache / queue / Redis-compatible store | `keyvalue` | **no** | no (internal) |
+
+`runtime` enum (everything except `keyvalue`): `node`, `python`, `docker`, `image`,
+`static`, `go`, `ruby`, `elixir`, `rust`.
+
+## Blueprint-first: everything lives in render.yaml
+
+**Rule: declare every service, database, and env var group in `render.yaml` at the repo
+root. Touch the dashboard only for `sync: false` secrets and one-off debugging.** Why: the
+Blueprint is the reproducible, reviewable source of truth — it powers preview environments
+and a clean re-deploy, while dashboard-only config is invisible state that drifts and can't
+be code-reviewed.
+
+Top-level keys: `services`, `databases`, `envVarGroups`, `projects`, `previews`.
+
+## Minimal correct render.yaml (annotated)
+
+A multi-service app — a Node web service, a Python worker, a nightly cron, a Postgres db,
+and a shared env group. Every load-bearing key is commented.
+
+```yaml
+databases:
+  - name: app-db
+    plan: starter            # NOT free for anything you care about — free expires in 30 days
+    postgresMajorVersion: "17"
+    region: frankfurt
+
+envVarGroups:
+  - name: app-shared
+    envVars:
+      - key: LOG_LEVEL
+        value: info
+      - key: SENTRY_DSN
+        sync: false          # prompt once at setup; never stored in git
+
+services:
+  - type: web
+    name: api
+    runtime: node
+    region: frankfurt
+    plan: starter            # $7/mo — avoids the free-tier 15-min spin-down on an API
+    buildCommand: npm ci && npm run build
+    startCommand: npm start  # MUST bind 0.0.0.0 and read $PORT — see next section
+    healthCheckPath: /healthz # gates zero-downtime rollout; new instance must pass first
+    preDeployCommand: npm run migrate  # runs before the new instance serves traffic
+    autoDeployTrigger: commit          # commit | checksPass | off
+    envVars:
+      - fromGroup: app-shared
+      - key: DATABASE_URL
+        fromDatabase:
+          name: app-db
+          property: connectionString   # never hardcode the URL
+      - key: SESSION_SECRET
+        generateValue: true            # Render generates a random secret
+
+  - type: worker
+    name: jobs
+    runtime: python
+    plan: starter
+    buildCommand: pip install -r requirements.txt
+    startCommand: celery -A app worker -l info  # no port — workers don't bind one
+    envVars:
+      - fromGroup: app-shared
+      - key: DATABASE_URL
+        fromDatabase: { name: app-db, property: connectionString }
+      - key: API_URL
+        fromService:                   # reference another service
+          name: api
+          type: web
+          property: hostport
+
+  - type: cron
+    name: nightly-cleanup
+    runtime: python
+    schedule: "0 3 * * *"              # required for cron; 03:00 UTC daily
+    buildCommand: pip install -r requirements.txt
+    startCommand: python -m app.cleanup
+    envVars:
+      - key: DATABASE_URL
+        fromDatabase: { name: app-db, property: connectionString }
+```
+
+## Port binding — do this first (the #1 first-deploy failure)
+
+**Rule: a `web` service MUST listen on host `0.0.0.0` and read the `PORT` env var (Render
+sets it, default `10000`).** If Render detects no bound port within its window, the deploy
+**fails with "no open ports detected"** and visitors get a **502**. This is the single most
+common first-deploy break — binding `localhost`/`127.0.0.1` or a hardcoded port does it.
+
+```javascript
+// Bad — binds the wrong host and ignores Render's PORT → "no open ports detected"
+app.listen(3000);
+
+// Good — bind 0.0.0.0 and honor $PORT
+app.listen(process.env.PORT || 3000, "0.0.0.0");
+```
+
+```bash
+# Bad — gunicorn on a fixed local port
+gunicorn app:app --bind 127.0.0.1:8000
+
+# Good — bind 0.0.0.0 and Render's $PORT
+gunicorn app:app --bind 0.0.0.0:$PORT
+```
+
+Only `web` services need this. A `worker`/`cron` that tries to bind a port is fine but
+pointless; a `web` service that doesn't is broken.
+
+## Wiring env vars across services
+
+**Rule: never hardcode `DATABASE_URL`, `REDIS_URL`, or shared secrets as literal `value:`
+strings. Reference the resource** so the value survives a rotation, recreate, or region
+move, and so secrets never land in git.
+
+| Form | Use it for |
+| --- | --- |
+| `fromDatabase: { name, property: connectionString }` | the Postgres connection string |
+| `fromService: { name, type, property }` | another service's host/port/URL (`property: hostport`, `host`, or `port`) |
+| `fromGroup: <group-name>` | pull a whole shared env var group |
+| `generateValue: true` | a random secret Render generates and stores (session keys) |
+| `sync: false` | a secret you type once at setup; not stored in the repo |
+
+For a Key Value store, reference its connection string the same way you reference Postgres,
+via `fromService` against the `keyvalue` service.
+
+## Migrations and zero-downtime deploys
+
+- `preDeployCommand` — runs **once**, before the new instance starts serving traffic. Put
+  migrations here, not in `startCommand` (a startCommand migration runs on every instance
+  and races under multiple replicas).
+- `healthCheckPath` — Render polls it on the new instance and only shifts traffic once it
+  passes, giving zero-downtime rollout. Point it at a route that checks real readiness.
+- `autoDeployTrigger` — `commit` (deploy every push), `checksPass` (wait for CI status),
+  or `off` (manual / deploy-hook only).
+
+## Free-tier traps
+
+Render's free tier is generous for hobby work and a landmine for anything you care about.
+
+| Trap | What happens | Fix |
+| --- | --- | --- |
+| Free web spin-down | after **15 min** of no inbound traffic the instance sleeps; next request waits **30–60s** to wake | Starter at **$7/mo** per service |
+| 750 free instance-hrs/mo | shared across the workspace; spun-down time doesn't count toward it | budget it, or pay Starter |
+| Free Postgres expiry | **deleted 30 days after creation** (14-day grace to upgrade), all data gone; only **one** free Postgres per workspace | Starter Postgres ($7/mo) from day one for anything real |
+| Free Key Value | no disk persistence — data is lost on restart | paid plan if you need durability |
+
+## Cron specifics
+
+- `schedule:` (standard cron expression) is **required** for `type: cron`.
+- Render guarantees **at most one active run at a time** — runs don't overlap.
+- **A run is killed after 12 hours.** Anything that can exceed that must be a `worker` with
+  its own scheduler/queue, not a cron. A long cron fails silently mid-job — partial work,
+  no clean error.
+
+## Scaling and disk knobs
+
+This is the concrete Render surface, not capacity strategy (that's `scaling`).
+
+```yaml
+services:
+  - type: web
+    name: api
+    runtime: node
+    scaling:
+      minInstances: 1
+      maxInstances: 4
+      targetCPUPercent: 70
+      targetMemoryPercent: 80   # autoscale between min/max on CPU/mem
+    disk:
+      name: data
+      mountPath: /var/data
+      sizeGB: 10                # a disk PINS the service to ONE instance — blocks horizontal scale
+```
+
+Use `numInstances` for a fixed replica count instead of `scaling` when you don't want
+autoscaling. A persistent `disk` and horizontal scaling are mutually exclusive — pick one.
+
+Regions: `oregon`, `ohio`, `virginia`, `frankfurt`, `singapore`. Plans: `free`, `starter`,
+`standard`, `pro`, `pro plus`, `pro max`, `pro ultra`.
+
+## Anti-patterns
+
+| Anti-pattern | Why it bites | Do instead |
+| --- | --- | --- |
+| Hardcoding a port (`listen(3000)`) | "no open ports detected" → deploy fails / 502 | bind `0.0.0.0` and `$PORT` |
+| Hardcoding `DATABASE_URL` | breaks on rotation / db recreate | `fromDatabase` reference |
+| A long job as a `cron` | killed at 12h, silent partial work | `worker` + its own scheduler/queue |
+| Free Postgres for production | deleted 30 days after creation | Starter ($7/mo) from day one |
+| Secrets as literal `value:` in render.yaml | leaked in git history | `sync: false` or `generateValue: true` |
+| Migrations in `startCommand` | runs on every instance, races under replicas | `preDeployCommand` |
+| Free web service for a real API | cold-start 502s after idle | Starter, or accept it only for a hobby toy |
+| Dashboard-only config | invisible drift, no preview envs, no review | declare in `render.yaml` |
+
+## When to hand off
+
+- Schema design, queries, indexing, tuning → `../postgresdb/SKILL.md`. This skill only
+  *provisions and connects* Render's managed Postgres.
+- Writing the `Dockerfile` Render consumes via `runtime: docker` → `docker`.
+- Registrar-side DNS records for a custom domain → `domains-dns`. (The Render `domains:`
+  block and verification stay here.)
+- Cross-platform release strategy, promotion, rollback flow → `../deployment/SKILL.md` and
+  `ship`. This skill is Render config and platform mechanics.
+- Build steps Render's native build doesn't run (custom CI) → `github-actions`. Render
+  auto-deploys on push; only reach for Actions when you genuinely need it.
+- Capacity/load strategy beyond the `scaling:` knobs → `scaling`.
+- A different PaaS → its own sibling: `../fly-io/SKILL.md`, `railway`, `vercel`,
+  `../netlify/SKILL.md`, `coolify`, `digitalocean`.
+
+## Full key surface
+
+The exhaustive `render.yaml` key tables per service type, all database keys
+(`postgresMajorVersion`, `diskSizeGB`, `readReplicas`, `highAvailability`, `previewPlan`),
+every env-var reference form, region/plan enums, and four complete copy-paste recipes
+(Next.js web+pg; FastAPI web+worker+cron+keyvalue; Docker monorepo with `rootDir`; static
+SPA with `routes` rewrites) live in `references/blueprint-reference.md` — pull it open when
+you need a key this body didn't cover.

package/skills/render/evals/README.md

@@ -0,0 +1,12 @@
+# render evals
+
+These cases are routing-and-capability fixtures, not an automated test runner. Feed
+`cases.yaml` through the repo's eval harness, which uses an LLM judge. `should_trigger`
+and `should_not_trigger` check that the SKILL.md `description` routes the right prompts in
+(Render deploys, render.yaml authoring, the port/502/cron/free-tier traps) and the wrong
+ones out to the named sibling (`fly-io`, `docker`, `deployment`, `postgresdb`,
+`domains-dns`). The `capability` case is graded against its `must_include` rubric to confirm
+the SKILL.md body actually produces a correct, trap-free `render.yaml` — right service
+types, `0.0.0.0:$PORT` binding, referenced (not hardcoded) env vars, and the cron/Postgres
+warnings. There is nothing to `npm test` here; the judge reads SKILL.md and scores the
+output against the rubric.

package/skills/render/evals/cases.yaml

@@ -0,0 +1,45 @@
+skill: render
+
+should_trigger:
+  - prompt: "Write a render.yaml that deploys my Express API plus a background worker and a Postgres database."
+    why: "Core Blueprint authoring across multiple service types (web + worker + Postgres) — the central job this skill owns."
+  - prompt: "My Render deploy keeps failing with 'no open ports detected'. What's wrong?"
+    why: "Non-obvious symptom phrasing that maps directly to the port-binding trap (must bind 0.0.0.0:$PORT) — the #1 first-deploy failure this skill leads with."
+  - prompt: "How do I run a nightly cleanup job on Render?"
+    why: "Service-type selection: a scheduled run-and-exit job is a `type: cron` with a `schedule:`, not a worker — a decision this skill teaches without naming the type."
+  - prompt: "Wire DATABASE_URL from my Render Postgres into both my web service and my worker without hardcoding it."
+    why: "Cross-service env reference via fromDatabase — the wiring rule (never hardcode the URL) is a signature concern of this skill."
+  - prompt: "Mi web service en Render devuelve 502 después del primer deploy, ¿qué pasa?"
+    why: "Spanish trigger; first-deploy 502 is the port-binding / no-open-ports symptom this skill diagnoses."
+  - prompt: "Should this email-sending job be a Render worker or a cron job?"
+    why: "Non-obvious worker-vs-cron boundary; the answer hinges on the 12h cron kill and run-then-exit semantics, both core to this skill."
+  - prompt: "Why does my free Render service take 30 seconds to respond after no one's hit it for a while?"
+    why: "Free-tier spin-down / cold-start trap described by symptom, not by name — squarely a free-tier mechanic this skill explains."
+
+should_not_trigger:
+  - prompt: "Deploy this app to Fly.io with a Dockerfile and set up volumes."
+    route_to: "fly-io"
+    why: "A different PaaS — Fly.io has its own config surface and sibling skill; this skill is Render-specific."
+  - prompt: "Write the Dockerfile for my Node app with a small multi-stage runtime image."
+    route_to: "docker"
+    why: "Container authoring. Render only consumes a Dockerfile via runtime: docker; writing it is docker's job."
+  - prompt: "Design our blue/green release and rollback strategy across staging and production."
+    route_to: "deployment"
+    why: "Platform-agnostic release flow and promotion strategy belongs to deployment; this skill is Render config and mechanics."
+  - prompt: "Optimize this slow Postgres query and add the right indexes."
+    route_to: "postgresdb"
+    why: "Schema and query tuning is postgresdb; this skill only provisions and connects Render's managed Postgres."
+  - prompt: "Point my custom domain's DNS A and CNAME records at the host at my registrar."
+    route_to: "domains-dns"
+    why: "Registrar-side DNS records belong to domains-dns; only the Render domains: block stays here."
+
+capability:
+  - scenario: "Given a Python FastAPI repo with a Celery worker and a job that must email users every 5 minutes, produce a render.yaml and fix the start command so it deploys correctly on Render."
+    must_include:
+      - "Web service binds 0.0.0.0 and reads $PORT (e.g. gunicorn/uvicorn --bind 0.0.0.0:$PORT), not a hardcoded port"
+      - "The Celery process declared as type: worker (no port binding)"
+      - "The 5-minute email job declared as type: cron with a schedule: expression (e.g. */5 * * * *)"
+      - "DATABASE_URL wired via fromDatabase (and Redis via fromService), never a hardcoded connection string"
+      - "Secrets handled with sync: false or generateValue: true rather than literal value: strings"
+      - "Migrations placed in preDeployCommand, not startCommand"
+      - "Calls out the 12h cron kill (use a worker for longer jobs) and the free-Postgres 30-day expiry trap"