prizmkit 1.1.156 → 1.1.160

package/bundled/skills/prizmkit-deploy/assets/deploy-document-template.md

@@ -1,89 +0,0 @@
-# Deployment Document Template
-
-Render `.prizmkit/deploy/deploy.md` with the exact top-level headings below. Replace placeholders with established values, use `not configured` or `not applicable` when truthful, and never write raw secret values. Update sections in place; do not append duplicate headings or turn this document into deployment history. Immutable operation events belong in `deploy-history/`.
-
-```markdown
-# Deployment
-
-## Target
-
-- Project: <project name>
-- Project type: <detected project type>
-- Environment: <dev | test | production>
-- Target: <SSH host alias | cloud platform | Docker | unsupported target>
-- Adapter: <ssh | cloud-guided | docker-guided | documented-fallback>
-- Strategy: <push | pull | direct-upload | platform-native | container-native | manual>
-- Public URL: <URL | not configured>
-
-## Prerequisites
-
-- <required runtime/tool/account/connectivity prerequisite>
-
-## Required Environment Variables
-
-Record names, purpose, source, and presence only. Never record values.
-
-| Name | Required | Purpose | Secret Source | Present |
-|---|---|---|---|---|
-| `<VARIABLE_NAME>` | yes | <purpose> | <platform secret store or ignored local env file> | yes/no |
-
-## Build and Release
-
-- Install command: `<command | not required>`
-- Build command: `<command | not required>`
-- Start command: `<command>`
-- Release layout: <path/layout or platform-native>
-- Artifact source: <repository checkout | uploaded archive | container image | platform build>
-
-## Runtime
-
-- Process manager: <manager | platform-native>
-- Runtime user: <user | platform-managed>
-- Internal port: <port | platform-managed>
-- Public routing: <Nginx/proxy/platform route>
-- Persistent storage: <mounts/volumes | none>
-
-## Health Checks
-
-| Name | URL or Command | Expected | Last Verified Result |
-|---|---|---|---|
-| <check> | <path/command> | <status/output> | <pass/fail/not run> |
-
-## DNS and TLS
-
-- Domain: <domain | not configured>
-- DNS status: <configured/pending/not applicable>
-- TLS issuer: <issuer | platform-managed | not configured>
-- Renewal: <automatic/manual/not applicable>
-
-## Rollback
-
-- Strategy: <previous release/platform rollback/image rollback/manual>
-- Command or procedure: <safe rollback command/procedure>
-- Readiness: <verified/not verified/not applicable>
-
-## Operations
-
-- Status: `<command or platform action>`
-- Logs: `<command or platform action>`
-- Restart: `<command or platform action>`
-- Health: `<command or platform action>`
-- Rollback: `<command or platform action>`
-
-## Current Validation
-
-- Configuration: <pass/fail/not run>
-- Connectivity: <pass/fail/not run>
-- Build: <pass/fail/not run>
-- Staged health: <pass/fail/not run>
-- Live health: <pass/fail/not run>
-- Latest history record: `.prizmkit/deploy/deploy-history/<event-id>.json` or `none`
-
-## Manual Actions
-
-- <remaining user-owned action, or `None`>
-
-## Notes
-
-- <stable deployment constraint, adapter gap, or operational warning>
-```

package/bundled/skills/prizmkit-deploy/references/ci-cd-workflows.md

@@ -1,145 +0,0 @@
-# CI/CD Workflow Templates
-
-Read this file when `deployStrategy` is `ci-cd-push` or `ci-cd-pull`.
-
-## Shared Configuration
-
-**Secrets** (add to GitHub repository Settings → Secrets and variables → Actions):
-- `SSH_HOST` — server IP/hostname
-- `SSH_USER` — runtime user (e.g., `deploy`)
-- `SSH_KEY` — SSH private key
-- `SSH_PORT` — SSH port (default 22)
-
-**Shared trigger:**
-```yaml
-on:
-  push:
-    branches: [<branch>]
-    paths-ignore:
-      - '.prizmkit/**'
-      - 'docs/**'
-```
-
----
-
-## Push Mode Workflow (`ci-cd-push`)
-
-Build happens on GitHub Actions runner. Only built artifacts are transferred to the server.
-
-```yaml
-name: Deploy to Production (Push)
-
-on:
-  push:
-    branches: [<branch>]
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - name: Allocate Release Identity
-        run: echo "ARCHIVE_ID=$(date -u +%Y%m%dT%H%M%SZ)-$(git rev-parse --short=12 HEAD)" >> "$GITHUB_ENV"
-
-      - name: Install & Build
-        run: |
-          npm ci
-          npm run build
-
-      - name: Package & Transfer
-        run: |
-          tar czf deploy-$ARCHIVE_ID.tar.gz \
-            <build-output-dir>/ node_modules/ package.json package-lock.json
-          scp -P ${{ secrets.SSH_PORT }} deploy-$ARCHIVE_ID.tar.gz \
-            ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:/var/www/<project>/releases/
-
-      - name: Deploy on Server
-        uses: appleboy/ssh-action@v1
-        env:
-          ARCHIVE_ID: ${{ env.ARCHIVE_ID }}
-        with:
-          host: ${{ secrets.SSH_HOST }}
-          username: ${{ secrets.SSH_USER }}
-          key: ${{ secrets.SSH_KEY }}
-          port: ${{ secrets.SSH_PORT }}
-          envs: ARCHIVE_ID
-          script: |
-            set -eu
-            cd /var/www/<project>
-            RELEASE_ID="$ARCHIVE_ID"
-            SUFFIX=1
-            while [ -e "releases/$RELEASE_ID" ]; do
-              [ "$SUFFIX" -le 99 ] || { echo "release identity suffixes exhausted" >&2; exit 1; }
-              RELEASE_ID="$ARCHIVE_ID-$(printf '%02d' "$SUFFIX")"
-              SUFFIX=$((SUFFIX + 1))
-            done
-            mkdir "releases/$RELEASE_ID"
-            tar xzf "releases/deploy-$ARCHIVE_ID.tar.gz" -C "releases/$RELEASE_ID"
-            rm "releases/deploy-$ARCHIVE_ID.tar.gz"
-            # PM2 start, health check, Nginx switch, history, and metadata use RELEASE_ID
-```
-
-**Key difference from Pull:** the runner checks out code, installs, builds, and only transmits the result. The server doesn't need Git or build tools — just Node.js runtime and PM2.
-
----
-
-## Pull Mode Workflow (`ci-cd-pull`)
-
-GitHub Actions runner only triggers the server. The server does all the work.
-
-```yaml
-name: Deploy to Production (Pull)
-
-on:
-  push:
-    branches: [<branch>]
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Allocate Release Identity
-        run: |
-          echo "RELEASE_BASE=$(date -u +%Y%m%dT%H%M%SZ)-$(git rev-parse --short=12 HEAD)" >> "$GITHUB_ENV"
-          echo "DEPLOY_SHA=$(git rev-parse HEAD)" >> "$GITHUB_ENV"
-
-      - name: Trigger Server Deploy
-        uses: appleboy/ssh-action@v1
-        env:
-          RELEASE_BASE: ${{ env.RELEASE_BASE }}
-          DEPLOY_SHA: ${{ env.DEPLOY_SHA }}
-        with:
-          host: ${{ secrets.SSH_HOST }}
-          username: ${{ secrets.SSH_USER }}
-          key: ${{ secrets.SSH_KEY }}
-          port: ${{ secrets.SSH_PORT }}
-          envs: RELEASE_BASE,DEPLOY_SHA
-          script: |
-            set -eu
-            cd /var/www/<project>
-            RELEASE_ID="$RELEASE_BASE"
-            SUFFIX=1
-            while [ -e "releases/$RELEASE_ID" ]; do
-              [ "$SUFFIX" -le 99 ] || { echo "release identity suffixes exhausted" >&2; exit 1; }
-              RELEASE_ID="$RELEASE_BASE-$(printf '%02d' "$SUFFIX")"
-              SUFFIX=$((SUFFIX + 1))
-            done
-            git clone --no-checkout --branch <branch> <repoUrl> "releases/$RELEASE_ID"
-            git -C "releases/$RELEASE_ID" checkout --detach "$DEPLOY_SHA"
-            cd "releases/$RELEASE_ID"
-            npm ci
-            cp ../../shared/.env.production .
-            npm run build
-            # PM2 start, health check, Nginx switch, history, and metadata use RELEASE_ID
-```
-
-**Key difference from Push:** the workflow is simpler (one step: SSH + run script), but the server needs Git, full build toolchain, and must be able to reach the repo.
-
-After generating the workflow, verify: the first `git push` to the configured branch will trigger the first deployment. Monitor the GitHub Actions run and report results.

package/bundled/skills/prizmkit-deploy/references/cloud-platform-deploy.md

@@ -1,109 +0,0 @@
-# Cloud Platform Deployment Path
-
-Guided deployment for Vercel, Netlify, Fly.io, and similar cloud platforms. Full automation isn't available — these platforms require browser-based authentication — but the skill provides structured CLI assistance.
-
-## Detect and Validate
-
-1. Check if the platform CLI is installed: `vercel --version`, `netlify --version`, `fly version`.
-2. If missing, guide the user to install: `npm install -g vercel` or link to docs.
-3. Check authentication: `vercel whoami`, `netlify status`. If not logged in, guide the user through `vercel login`.
-4. Read the platform config file (`vercel.json`, `netlify.toml`, `fly.toml`) to understand existing settings.
-
-## Generate Configuration
-
-1. If no platform config file exists, generate one based on project detection:
-   - **Next.js on Vercel**: minimal config — Vercel auto-detects Next.js. Generate `vercel.json` only if custom rewrites/redirects are needed.
-   - **Static site on Netlify**: generate `netlify.toml` with build command and publish directory.
-   - **Any on Fly.io**: generate `fly.toml` with app name, builder, and HTTP service config.
-2. Set environment variables via the platform CLI: `vercel env add`, `netlify env:set`.
-3. Document all env vars needed (from Discovery Step 1 scan).
-
-## Deploy and Verify
-
-1. Run the platform deploy command: `vercel deploy --prod`, `netlify deploy --prod`, `fly deploy`.
-2. If the command requires interactive input, run it and show output to the user.
-3. After deploy, run health checks against the production URL.
-4. Write a deploy-history event recording: platform, project name, deploy URL, commit SHA, timestamp.
-
-## Operations
-
-| Command | Vercel | Netlify | Fly.io |
-|---------|--------|---------|--------|
-| status | `vercel list` | `netlify status` | `fly status` |
-| logs | `vercel logs` | `netlify logs` | `fly logs` |
-| rollback | `vercel rollback` | `netlify rollback` | `fly rollback` |
-| env | `vercel env ls` | `netlify env:list` | `fly secrets list` |
-
-Platform rollback is instant — no release-based rollback needed.
-
-## Platform-Specific Patterns
-
-### Vercel
-
-Vercel auto-detects Next.js projects — no config file is generated for basic deployments. When confirmed custom routing or static build settings require `vercel.json`, start from this minimal platform-native shape and include only established keys:
-
-```json
-{
-  "$schema": "https://openapi.vercel.sh/vercel.json",
-  "buildCommand": "npm run build",
-  "outputDirectory": "dist",
-  "rewrites": [
-    {
-      "source": "/(.*)",
-      "destination": "/index.html"
-    }
-  ]
-}
-```
-
-Omit `buildCommand`/`outputDirectory` when framework detection owns them, and omit `rewrites` unless the application actually needs SPA fallback or a confirmed route. Validate generated configuration with the installed Vercel CLI before deployment.
-
-Key behaviors:
-- Next.js: framework auto-detected, build command and output directory inferred automatically
-- Static sites: set build command and output directory via `vercel.json` or CLI
-- Env vars: `vercel env add <KEY>` (supports `production`, `preview`, `development` environments)
-- Deploy preview: every branch gets a preview URL automatically (if connected via GitHub)
-
-### Netlify
-
-Netlify requires explicit build and publish configuration. Use `netlify.toml`:
-
-```toml
-[build]
-  command = "npm run build"
-  publish = "dist"
-
-[[redirects]]
-  from = "/*"
-  to = "/index.html"
-  status = 200
-```
-
-Key behaviors:
-- SPA redirects: the catch-all redirect above is essential for client-side routing
-- Env vars: `netlify env:set <KEY> <VALUE>` (per-context: `production`, `deploy-preview`, `branch-deploy`)
-- Branch deploys: every branch gets a deploy-preview URL automatically (if connected via GitHub)
-
-### Fly.io
-
-Fly.io requires a `fly.toml` with app name, builder, and HTTP service config:
-
-```toml
-app = "<app-name>"
-primary_region = "lhr"
-
-[build]
-  dockerfile = "Dockerfile"
-
-[http_service]
-  internal_port = 3000
-  force_https = true
-```
-
-Key behaviors:
-- Build source: `dockerfile = "Dockerfile"` for project-owned images, or a confirmed platform-supported image/build configuration; static sites still need a valid serving image rather than an invented `static` builder value
-- Secrets: `fly secrets set <KEY>=<VALUE>` for runtime environment variables
-- Scale: `fly scale count <N>` to adjust VM instances
-- Volumes: for persistent data, configure `[mounts]` in fly.toml
-
-**Note**: These are minimum-viable platform references; browser-based authentication remains a user-action step. Enriched platform coverage is planned for future iterations.

package/bundled/skills/prizmkit-deploy/references/data-safety-examples.md

@@ -1,120 +0,0 @@
-# Data Safety Examples
-
-Few-shot examples for the Data Safety Gate in `/prizmkit-deploy`. Read this file when a dangerous command pattern is detected — it shows the correct confirmation flow and illustrates what happens when the gate is skipped.
-
-## Example 1: Prisma Force Reset (the incident)
-
-**Context:** User runs `/prizmkit-deploy` to deploy a Next.js + Prisma project. During database setup, the model needs to sync the Prisma schema with the database.
-
-**Wrong — skipping the gate:**
-```
-Model: I'll sync your database schema now.
-$ prisma db push --force-reset --accept-schema
-→ All tables dropped. All production data lost. No backup. No confirmation.
-```
-This happened in production. `--force-reset` drops and recreates every table. `--accept-schema` bypasses Prisma's own confirmation prompt. The model ran both flags without asking the user whether existing data should be preserved.
-
-**Correct — with the safety gate:**
-```
-Model: I detected that your database needs a schema sync. However, before I do anything:
-
-WARNING: The Prisma schema has changes that could affect existing data.
-- New tables to create: 0
-- Tables that may be modified: 2 (users, orders)
-- If I run `prisma db push --force-reset`, ALL existing data will be DESTROYED.
-
-Options:
-1. prisma db push (safe — only adds missing tables/columns, no data loss)
-2. prisma db push --force-reset (DANGEROUS — drops and recreates all tables, all data lost)
-3. prisma migrate dev (creates a migration file you can review first)
-
-Which approach do you want? (1/2/3)
-```
-
-The `--accept-schema` flag should never be used — it suppresses Prisma's own built-in safety prompts that protect the user.
-
-## Example 2: Prisma Migrate Reset
-
-**Context:** User wants to reset their dev database to a clean state for testing.
-
-**Correct detection and confirmation:**
-```
-Model: `prisma migrate reset` will:
-- Drop the entire database
-- Recreate it from scratch
-- Run all migrations
-
-This is a DESTRUCTIVE operation. All data in the database will be permanently lost.
-
-Are you sure this is a dev/test database with no important data? (yes/no)
-```
-
-In production or any environment with real data: refuse immediately. This command should only run in dev with explicit user confirmation.
-
-## Example 3: Raw SQL Data Modification
-
-**Context:** During deployment, the model considers running a SQL command to fix a data issue.
-
-**Correct detection and confirmation:**
-```
-Model: To fix the duplicate user records, I would run:
-```sql
-DELETE FROM users WHERE email IS NULL AND created_at < '2025-01-01';
-```
-
-This would delete approximately 340 user records. BEFORE I run this:
-
-1. Would you like me to run a SELECT first to show you exactly which rows would be deleted?
-2. Do you want to back up the users table before deletion?
-3. Confirm: Delete these 340 records? (yes/no)
-
-I will not proceed without your explicit confirmation.
-```
-
-## Example 4: Overwriting Production Configuration
-
-**Context:** During bootstrap, the model needs to write an Nginx config, but one already exists at the target path.
-
-**Correct detection and confirmation:**
-```
-Model: Found existing Nginx config at /etc/nginx/sites-enabled/myapp.
-
-This file is NOT managed by PrizmKit (no `# PrizmKit Managed:` marker).
-Overwriting it could break existing site configuration.
-
-Options:
-1. Back up the existing config to /etc/nginx/sites-enabled/myapp.bak, then write new config
-2. Create new config alongside existing one with a different name
-3. Skip — keep the existing config as-is
-
-Which approach? (1/2/3)
-```
-
-## Example 5: Confirmation Dialogue Template
-
-When the gate triggers, use this dialogue structure:
-
-```
-============================================================
-DATA SAFETY GATE — DESTRUCTIVE OPERATION DETECTED
-============================================================
-
-Command: <the dangerous command>
-Risk level: HIGH / CRITICAL
-What will be lost: <plain-language description of affected data>
-
-Current state:
-- Database: <name>, <size>, <table count>
-- Affected tables: <list>
-- Last backup: <date if known, or "unknown — backup recommended">
-
-Recommended safe approach:
-<alternative if one exists>
-
-Do you want to proceed with this destructive operation?
-Type "yes, I understand the data will be lost" to confirm.
-Any other response will abort.
-============================================================
-```
-
-This format forces the user to read and acknowledge the risk before proceeding.

package/bundled/skills/prizmkit-deploy/references/database-setup.md

@@ -1,65 +0,0 @@
-# Database Setup
-
-Read this file when Discovery detected a database driver and the user wants AI-assisted database installation on the server.
-
-## Entry condition
-
-During Discovery Step 1 (Project Detection), database drivers were already scanned. If a driver was detected, ask after bootstrap tools are installed:
-
-> "Detected the project uses <PostgreSQL/MySQL/Redis>. Want me to install and configure it on the server?"
-> - **Yes** → proceed with database installation
-> - **No** → skip, record in deploy.md with note "database must be configured by user"
-
-## Secrets file safety
-
-Before writing `.prizmkit/deploy/secrets.local.env`:
-
-1. Verify `.gitignore` or an equivalent ignore rule covers the exact `.prizmkit/deploy/secrets.local.env` path or a compatible `.prizmkit/deploy/*.local.env` pattern.
-2. If the ignore rule is missing, pause and add or request it before writing secrets.
-3. Create/update the file with restrictive creation permissions (for example `umask 077` on POSIX), atomically replace it without widening permissions, set mode `600`, and verify it is ignored by Git.
-4. Use dotenv syntax: one `KEY=value` assignment per line, UTF-8, no JSON braces or commas. Preserve unrelated existing assignments and reject malformed or duplicate keys.
-5. Record only presence metadata in deploy config, docs, reports, and history. Never copy raw passwords, connection strings, passphrases, decryption keys, unsalted hashes, or full env var values into committed files.
-
-```
-apt-get install -y postgresql postgresql-contrib
-sudo -u postgres psql -c "CREATE DATABASE <project>;"
-sudo -u postgres psql -c "CREATE USER <project> WITH PASSWORD '<random-password>';"
-sudo -u postgres psql -c "GRANT ALL ON DATABASE <project> TO <project>;"
-```
-
-- Generate a cryptographically secure 32-character URL-safe password using letters, digits, `_`, and `-`, with no whitespace, quotes, `#`, or `=`.
-- Write or replace the single dotenv assignment `DATABASE_URL=postgresql://<project>:<password>@localhost:5432/<project>` in `.prizmkit/deploy/secrets.local.env`.
-- Re-verify ignore status and current-user-only permissions after atomic replacement.
-- In `deploy.md`, record only: "PostgreSQL connection information is stored in ignored local secret storage; raw values are not committed."
-
-## Legacy Local-Secret Migration
-
-If `.prizmkit/deploy/secrets.local.json` already exists from an earlier installation, treat the filename as legacy input only, never as a current output:
-
-1. Verify it is ignored by Git and restricted to the current user before reading it.
-2. Detect either a JSON object containing string values or strict dotenv `KEY=value` lines; reject mixed, malformed, duplicate, or non-string content without printing values.
-3. Convert the validated assignments to `.prizmkit/deploy/secrets.local.env` through the restrictive atomic-write rules above.
-4. Compare key names and presence only. Remove the legacy file only after successful conversion and explicit user confirmation; otherwise leave it untouched and report migration pending.
-
-## MySQL setup (future)
-
-Similar flow. Not implemented in first version — if project uses MySQL, direct user to documentation fallback.
-
-## Redis setup
-
-```
-apt-get install -y redis-server
-redis-cli CONFIG SET requirepass "<random-password>"
-redis-cli CONFIG REWRITE
-```
-
-- Bind to localhost only (modify `/etc/redis/redis.conf` if needed).
-- Write or replace the single dotenv assignment `REDIS_URL=redis://:<password>@localhost:6379` in `.prizmkit/deploy/secrets.local.env` using the same URL-safe password and atomic permission rules.
-- Re-verify ignore status and current-user-only permissions after replacement.
-
-## Security notes
-
-- Never write database passwords to deploy.md, because deploy.md may be committed to git and passwords would leak.
-- Passwords are stored only in `.prizmkit/deploy/secrets.local.env` after verifying the file is ignored by Git and locked down to current-user read/write permissions.
-- Default: database binds to localhost, no external access, because most indie projects only need local connections.
-- Record a `"database-setup"` event in deploy history (presence metadata only, no passwords).

package/bundled/skills/prizmkit-deploy/references/deploy-config-schema.md

@@ -1,150 +0,0 @@
-# deploy.config.json Schema
-
-This file is the machine-readable deployment configuration. Always read it before executing any deploy operation.
-
-## Top-Level Structure
-
-```json
-{
-  "version": 1,
-  "project": "project-name",
-  "deploymentMode": "ssh",
-  "deployStrategy": "direct-upload|ci-cd-push|ci-cd-pull",
-  "defaults": { ... },
-  "environments": { ... },
-  "servers": [ ... ],
-  "repository": { ... },
-  "apps": [ ... ],
-  "nginx": { ... },
-  "env": { ... }
-}
-```
-
-## defaults
-
-```json
-{
-  "releaseRetention": 5,
-  "credentialMode": "ai-assisted|user-managed",
-  "secretStorage": "ask-every-time|ignored-local-env|user-managed-on-server-only",
-  "rollbackOnFailure": true,
-  "headlessDefaultEnvironment": "test"
-}
-```
-
-`ignored-local-env` means `.prizmkit/deploy/secrets.local.env` after exact ignore and permission verification. Legacy `plaintext-local` may be migrated only through the local-secret migration contract. Legacy `encrypted-local` is unsupported because this Skill has no encryption/key-management implementation; block deployment and require the user to select a supported mode without exposing secret values.
-
-## environments
-
-Keyed by environment name. Each entry:
-```json
-{
-  "dev": {
-    "server": "server-id",
-    "allowHeadless": true,
-    "confirmBeforeDeploy": false
-  }
-}
-```
-
-## servers
-
-Array of server objects:
-```json
-{
-  "id": "prod-1",
-  "host": "IP or hostname",
-  "port": 22,
-  "bootstrapUser": "root",
-  "runtimeUser": "deploy",
-  "roles": ["web"],
-  "validated": {
-    "ssh": true|false,
-    "bootstrap": true|false,
-    "runtimeUser": true|false,
-    "tools": {
-      "node": "version",
-      "npm": "version",
-      "pm2": "version",
-      "nginx": "version",
-      "git": "version"
-    },
-    "directories": true|false,
-    "deployKey": true|false
-  }
-}
-```
-
-## repository
-
-```json
-{
-  "url": "git@github.com:owner/repo.git",
-  "branch": "master",
-  "auth": "deploy-key|ssh-agent|token",
-  "validated": {
-    "clone": true|false
-  }
-}
-```
-
-## apps
-
-Array of app objects:
-```json
-{
-  "id": "web",
-  "path": ".",
-  "runtime": "pm2",
-  "packageManager": "npm",
-  "installCommand": "npm ci",
-  "buildCommand": "npm run build",
-  "startCommand": "npm run start",
-  "ports": {
-    "blue": 3101,
-    "green": 3102
-  },
-  "healthChecks": [
-    { "name": "home", "url": "/", "expectedStatus": [200] },
-    { "name": "login", "url": "/login", "expectedStatus": [200, 302] }
-  ],
-  "activeColor": "blue",
-  "pm2Process": "prizm-ideas-blue"
-}
-```
-
-## nginx
-
-```json
-{
-  "enabled": true,
-  "managed": true,
-  "firstChangeRequiresConfirmation": true,
-  "domain": null,
-  "ipFallback": true,
-  "currentUpstream": "127.0.0.1:3101"
-}
-```
-
-## env
-
-```json
-{
-  "strategy": "ai-assisted|user-managed",
-  "required": ["VAR_NAME"],
-  "secrets": ["SECRET_NAME"],
-  "validated": {
-    "allRequiredPresent": true|false
-  }
-}
-```
-
-## Validation Rules
-
-- `version` must be present (always 1 for first version)
-- `servers` must have at least one entry with host and bootstrapUser
-- `repository.url` must be present
-- `apps` must have at least one entry
-- `apps[*].ports.blue` and `apps[*].ports.green` must differ
-- `apps[*].healthChecks` should have at least one entry
-- Environment referenced in `environments` must have a matching server in `servers`