prizmkit 1.1.99 → 1.1.101

package/bundled/skills-windows/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-windows/prizmkit-deploy/references/database-setup.md

@@ -1,46 +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"
-
-## PostgreSQL setup
-
-```
-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 secure random password (32 chars, alphanumeric + symbols).
-- Write the connection string to `.prizmkit/deploy/secrets.local.json`: `DATABASE_URL=postgresql://<project>:<password>@localhost:5432/<project>`.
-- In deploy.md, write: "PostgreSQL installed, connection info recorded in `.prizmkit/deploy/secrets.local.json` (not committed to git)".
-
-## 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 `REDIS_URL=redis://:<password>@localhost:6379` to `.prizmkit/deploy/secrets.local.json`.
-
-## Security notes
-
-- Never write database passwords to deploy.md, because deploy.md may be committed to git and passwords would leak.
-- Passwords stored in `.prizmkit/deploy/secrets.local.json` (gitignored).
-- 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-windows/prizmkit-deploy/references/deploy-config-schema.md

@@ -1,148 +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|encrypted-local|plaintext-local|user-managed-on-server-only",
-  "rollbackOnFailure": true,
-  "headlessDefaultEnvironment": "test"
-}
-```
-
-## 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`

package/bundled/skills-windows/prizmkit-deploy/references/deploy-history-schema.md

@@ -1,62 +0,0 @@
-# Deploy History Record Schema
-
-Each event in `.prizmkit/deploy/deploy-history/<id>.json` follows this schema:
-
-```json
-{
-  "eventId": "<releaseId or event id>",
-  "eventType": "deploy|rollback|status|validation|failed-deploy|user-aborted|takeover|adapter-gap",
-  "timestamp": "<ISO 8601>",
-  "serverId": "<server id from deploy.config.json>",
-  "appIds": ["<app ids involved>"],
-  "branch": "<git branch>",
-  "commitSha": "<full or short commit SHA>",
-  "releasePath": "<full server path, e.g. /var/www/prizm-ideas/releases/20260430-22783a3>",
-  "previousReleasePath": "<previous release path or null for first deploy>",
-  "targetPort": 3101,
-  "targetColor": "blue|green",
-  "previousPort": 3102,
-  "phases": {
-    "preflight": "success|failed|skipped",
-    "prepareRelease": "success|failed|skipped",
-    "fetchCode": "success|failed|skipped",
-    "installDependencies": "success|failed|skipped",
-    "build": "success|failed|skipped",
-    "stageRuntime": "success|failed|skipped",
-    "healthCheck": "success|failed|skipped",
-    "switchTraffic": "success|failed|skipped",
-    "verifyLive": "success|failed|skipped",
-    "cleanupOldReleases": "success|failed|skipped",
-    "recordHistory": "success|failed|skipped"
-  },
-  "healthCheckResults": [
-    {
-      "name": "home",
-      "url": "/",
-      "expected": [200],
-      "actual": 200,
-      "pass": true
-    }
-  ],
-  "rollbackResult": null,
-  "logPath": "<server log path>",
-  "operatorMode": "ai-assisted|user-managed",
-  "notes": "<human-readable summary of what happened>"
-}
-```
-
-## Field Notes
-
-- `eventId`: Use `<releaseId>` for deploy events, `<releaseId>-rollback` for rollbacks.
-- `eventType`: Use `failed-deploy` when deploy fails before traffic switch, `deploy` when it succeeds. Use `adapter-gap` when no adapter exists for the detected project type or target — include `detectedProjectType`, `missingAdapter`, and `fallbackOutput` in the record.
-- `phases`: Only include phases that were attempted. Skip phases that were never reached.
-- `healthCheckResults`: Include all configured health checks. `pass` = actual status matches one of the expected status codes.
-- `rollbackResult`: `null` for non-rollback events, `"success"` or `"failed"` for rollbacks.
-- `notes`: Keep concise but include any anomalies or manual interventions.
-
-## What NOT to record
-
-- Raw secret values or API keys — never.
-- Unsalted hashes of secret values — inferable with rainbow tables.
-- Passphrases or decryption keys — even if hashed.
-- Full environment variable values — presence metadata only (e.g., `{"SUPABASE_KEY": {"present": true}}`).

package/bundled/skills-windows/prizmkit-deploy/references/deployment-modes.md

@@ -1,50 +0,0 @@
-# Deployment Mode Details
-
-Read this file when the user needs a detailed comparison of deployment modes during mode selection. SKILL.md contains the routing logic; this file has the full descriptions.
-
-## Mode A — Direct Upload
-
-1. Local build on the user's machine.
-2. SCP built output + `node_modules` + `.env.production` to server.
-3. PM2 start → health check → Nginx switch.
-4. After success: offer to upgrade to CI/CD.
-5. Bypasses: deploy key, git clone on server, server-side build.
-
-Best for: first-time deployment, getting something live fast, low-spec servers.
-
-## Mode B1 — CI/CD Push
-
-1. Generate `.github/workflows/deploy.yml`: checkout → install → build → SCP tarball → SSH restart.
-2. Add GitHub Secrets: `SSH_HOST`, `SSH_USER`, `SSH_KEY`, `SSH_PORT`.
-3. First deploy triggered by push to configured branch.
-4. Server only needs Node.js runtime + PM2 — no git, no build tools needed.
-5. GitHub Actions runner handles the heavy lifting.
-
-Best for: low-spec servers, heavy build processes, projects with large dependencies.
-
-## Mode B2 — CI/CD Pull
-
-1. Configure deploy key on server → add to GitHub.
-2. Generate `.github/workflows/deploy.yml`: triggers SSH command on server.
-3. Server-side deploy script: `git pull` → install → build → PM2 restart → health check.
-4. Server needs full build toolchain (Node.js, npm, git).
-5. Simpler workflow file, heavier server load.
-
-Best for: simple setup, servers with sufficient CPU/RAM, projects where build is fast.
-
-## Comparison
-
-| Aspect | Push mode | Pull mode |
-|------|----------|----------|
-| Build location | GitHub Actions runner | Server (local) |
-| Server load | Low (runs app only) | High (build + run) |
-| Config complexity | Medium (needs SCP transfer) | Low (SSH-triggered script only) |
-| Best for | Low-spec servers, heavy builds | Simple setup, capable servers |
-| Deploy Key required | No | Yes |
-| Artifact transfer | SCP tarball | git pull (incremental) |
-
-## Common ground between all modes
-
-- Same PM2 + Nginx blue/green strategy.
-- Same health check and traffic switch procedure.
-- Same ops commands (status/logs/restart/rollback).

package/bundled/skills-windows/prizmkit-deploy/references/direct-upload.md

@@ -1,26 +0,0 @@
-# Direct Upload Deployment
-
-Read this file when `deployStrategy` is `"direct-upload"`. The AI handles the build locally and transfers built artifacts to the server. No Git operations on the server.
-
-## Build phase (local)
-
-1. Run `<buildCommand>` locally (e.g., `npm run build`) in the project root.
-2. Identify the build output directory: `.next/` for Next.js, `dist/` for Vite, `build/` for CRA.
-3. Prepare a deployment tarball containing: build output + `node_modules/` + `package.json` + `package-lock.json` + any runtime config files.
-
-## Transfer phase (SCP)
-
-```
-scp -P <port> deploy-<releaseId>.tar.gz <runtimeUser>@<host>:/var/www/<project>/releases/
-ssh <runtimeUser>@<host> "cd /var/www/<project>/releases && mkdir <releaseId> && tar xzf deploy-<releaseId>.tar.gz -C <releaseId>"
-```
-
-## Server-side setup
-
-1. Copy `.env.production` from `shared/` into the release directory (or SCP it alongside the tarball if first deploy).
-2. No `npm install` needed — `node_modules` was transferred directly.
-3. Start PM2 on the inactive port. Health checks and traffic switch follow the standard flow (Groups 3-5 in SKILL.md).
-
-## Why transfer node_modules
-
-Direct upload is optimized for "fast first deploy." Re-running `npm ci` on a low-spec server can be slow. Transferring pre-built artifacts means the server only needs to run the app.

package/bundled/skills-windows/prizmkit-deploy/references/dns-setup.md

@@ -1,42 +0,0 @@
-# DNS Setup Guidance
-
-Read this file when the user has a domain for their project but DNS is not yet pointing to the server.
-
-## Step 1 — Check DNS resolution
-
-```powershell
-Resolve-DnsName <domain> -Type A | Where-Object { $_.QueryType -eq 'A' } | Select-Object -ExpandProperty IPAddress
-```
-
-If it resolves to the server IP: DNS is already configured, proceed to SSL (`references/ssl-setup.md`).
-If not: continue below.
-
-## Step 2 — DNS setup guidance
-
-```
-Domain <example.com> is not yet pointing to server <server-IP>.
-
-Add the following record at your DNS provider (e.g., Alibaba Cloud, Cloudflare, Namecheap):
-
-  Type:  A
-  Name:  @
-  Value: <server-IP>
-  TTL:   600
-
-To also support the www subdomain:
-  Type:  A
-  Name:  www
-  Value: <server-IP>
-
-Reply "done" when configured, and I'll verify and set up the SSL certificate.
-```
-
-## Step 3 — Verify after user confirmation
-
-- Re-run `Resolve-DnsName <domain> -Type A` to confirm resolution.
-- If still not resolved: warn about DNS propagation delay (can take up to 48 hours, usually 5-30 minutes). Offer to wait or continue without SSL for now.
-- Once confirmed: proceed to SSL (`references/ssl-setup.md`).
-
-## Edge case — IP-only deployment
-
-If user has no domain: skip DNS + SSL sections. Generate a note in deploy.md: "Project accessed via IP, no domain or HTTPS configured. Recommend purchasing a domain and running `/prizmkit-deploy setup-ssl`."

package/bundled/skills-windows/prizmkit-deploy/references/docker-deploy.md

@@ -1,31 +0,0 @@
-# Docker Deployment Path
-
-Guided deployment when a `Dockerfile` or `docker-compose.yml` is detected, or the user requests Docker deployment.
-
-## Detect and Configure
-
-1. Read `Dockerfile` — extract base image, exposed ports, build steps.
-2. Read `docker-compose.yml` if present — extract services, volumes, environment, ports.
-3. Identify image name: from compose project name or repo directory name.
-4. Identify port mappings: from `EXPOSE`, `ports:` in compose, or ask the user.
-
-## Build and Deploy
-
-1. Build: `docker build -t <project>:<releaseId> .` or `docker compose build`.
-2. Check for running containers with the same name: `docker ps -a --filter name=<project>`.
-3. If a previous container exists:
-   - For blue/green on a server with Nginx: start new container on different port, health check, switch upstream.
-   - For single-container setup: stop old, start new — warn about brief downtime.
-4. Start: `docker run -d --name <project>-<releaseId> -p <port>:<port> <project>:<releaseId>` or `docker compose up -d`.
-5. Health check the new container.
-6. Write deploy-history event.
-
-## Operations
-
-| Command | Docker CLI |
-|---------|-----------|
-| status | `docker ps --filter name=<project>` |
-| logs | `docker logs <container-name> --tail 100` |
-| restart | `docker restart <container-name>` |
-| rollback | `docker stop <new-container> && docker start <old-container>` |
-| cleanup | `docker image prune -a --filter "label=project=<project>"` |

package/bundled/skills-windows/prizmkit-deploy/references/firewall-setup.md

@@ -1,37 +0,0 @@
-# Firewall Setup (UFW)
-
-Read this file when the user wants AI-assisted firewall configuration during bootstrap.
-
-## Flow
-
-1. After core tools are installed, ask the user:
-   > "Want me to configure the firewall (ufw)? Only necessary ports will be opened, improving server security."
-
-2. If user declines: skip, record to deploy config.
-
-3. If user agrees, ask which additional ports to open (beyond SSH/HTTP/HTTPS):
-   > "By default only SSH(22), HTTP(80), HTTPS(443) are opened. Should the blue/green preview ports (3101/3102) also be opened? If you need other ports (e.g., for remote database management), list them together."
-
-4. Collect ports, then ask:
-   > "Firewall rules are ready. Should I apply them directly, or will you do it yourself?"
-   > - **A. You apply them** — AI runs ufw commands
-   > - **B. I'll do it myself** — output rule list, user executes manually
-
-## Planned rules (output before executing)
-
-```
-ufw default deny incoming
-ufw default allow outgoing
-ufw allow 22/tcp       # SSH
-ufw allow 80/tcp       # HTTP
-ufw allow 443/tcp      # HTTPS
-ufw allow 3101/tcp     # blue preview (user-approved)
-ufw allow 3102/tcp     # green preview (user-approved)
-ufw --force enable
-```
-
-## Rules for automatic execution
-
-- Check `ufw status` first — if rules already exist, append only missing rules, don't overwrite.
-- Never `ufw reset` unless explicitly asked, because it wipes custom rules the user may have configured manually.
-- Record a `"security-baseline"` event in deploy history with the rule list, so future sessions can detect existing configuration.

package/bundled/skills-windows/prizmkit-deploy/references/live-validation-notes.md

@@ -1,21 +0,0 @@
-# Implementation Notes from Live Validation
-
-These findings from the first PrizmKit deployment (PrizmIdeas) guide edge-case handling. Read when troubleshooting bootstrap or deploy issues.
-
-1. **Detect port conflicts before installing Nginx.** Check what's on port 80/443 and ask before stopping anything, because overwriting an existing web server without confirmation can break unrelated services.
-
-2. **Verify npm separately from node.** Minimal Node installs may not bundle npm. Run `which npm` after installing Node, because `node --version` succeeding doesn't guarantee npm is available.
-
-3. **Fix locale on bare Ubuntu.** Run `locale-gen en_US.UTF-8` early to avoid perl warnings in apt. This is safe to run unconditionally even if locale is already configured.
-
-4. **Deploy key workflow is inherently interactive.** Generate key → wait for user to add to GitHub → verify. Headless mode cannot complete this because it requires the user to paste the key into GitHub's UI.
-
-5. **`pm2 startup` needs explicit PATH.** Always use `env PATH=$PATH:/usr/bin pm2 startup ...`, because the pm2 binary may not be on root's default PATH.
-
-6. **Persist deploy metadata on server.** Write `activeColor`, `activePort`, `lastReleaseId`, `lastDeployTimestamp` to `shared/deploy-metadata.json`, because subsequent deploys and rollbacks depend on knowing the current active slot.
-
-7. **Detect first deployment.** If no `current` symlink and no PM2 process for the app, skip rollback safety checks and use blue (3101) as initial color.
-
-8. **Build-time env vars.** Copy `.env.production` before `npm run build`, not after. `NEXT_PUBLIC_*` vars are baked at build time and won't be picked up if the .env is added later.
-
-9. **Node.js version flexibility.** Default to v22 LTS if v25 is unavailable. Most frameworks tolerate a minor version diff, and v22 has broader package compatibility.

package/bundled/skills-windows/prizmkit-deploy/references/nginx-blue-green.md

@@ -1,59 +0,0 @@
-# Nginx Blue/Green Configuration Template
-
-## Server Block Template
-
-```nginx
-# PrizmKit Managed: <project> — DO NOT EDIT MANUALLY
-upstream <project>_backend {
-    server 127.0.0.1:<activePort>;
-}
-
-server {
-    listen 80 default_server;
-    server_name _;
-
-    # PrizmKit managed marker: <project>
-    location / {
-        proxy_pass http://<project>_backend;
-        proxy_http_version 1.1;
-        proxy_set_header Host $host;
-        proxy_set_header X-Real-IP $remote_addr;
-        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-        proxy_set_header X-Forwarded-Proto $scheme;
-    }
-}
-```
-
-## Traffic Switch Procedure
-
-When switching from one color to another:
-
-1. Update the `upstream` block: change `server 127.0.0.1:<oldPort>` to `server 127.0.0.1:<newPort>`
-2. Run `nginx -t` to validate syntax
-3. If syntax check passes: `systemctl reload nginx`
-4. If syntax check fails: DO NOT reload. Abort the switch. Report the error.
-
-## Managed Marker
-
-All PrizmKit-generated Nginx config must contain:
-```
-# PrizmKit Managed: <project> — DO NOT EDIT MANUALLY
-```
-
-Before modifying any server block that lacks this marker, ask for user confirmation.
-
-## First-Time Setup
-
-- Disable default nginx site: `rm -f /etc/nginx/sites-enabled/default`
-- Create new config: `/etc/nginx/sites-available/<project>`
-- Symlink: `ln -sf /etc/nginx/sites-available/<project> /etc/nginx/sites-enabled/<project>`
-- Test: `nginx -t`
-- Reload: `systemctl reload nginx`
-
-## Rediscovery of Active Port
-
-If `deploy-metadata.json` is missing, rediscover the active upstream port from Nginx config:
-```
-grep "server 127.0.0.1:" /etc/nginx/sites-available/<project>
-```
-Then match the port against configured blue/green ports to determine active color.