prizmkit 1.1.159 → 1.1.160

package/bundled/skills/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
-
-```
-dig +short <domain> A
-```
-
-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 `dig +short <domain> 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/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/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/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.** After public health and history recording succeed, atomically write `shared/deploy-metadata.json` from `${SKILL_DIR}/references/deploy-metadata-schema.json`, including active color/port, release identity, operation event identity, and UTC update time. Subsequent deploys and rollbacks depend on this active-slot record.
-
-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/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.

package/bundled/skills/prizmkit-deploy/references/pending-input-schema.json

@@ -1,164 +0,0 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "PrizmKit Deployment Pending Input",
-  "type": "object",
-  "additionalProperties": false,
-  "required": [
-    "schema_version",
-    "result",
-    "operation",
-    "environment",
-    "known_context",
-    "questions"
-  ],
-  "properties": {
-    "schema_version": {
-      "const": 1
-    },
-    "result": {
-      "const": "NEEDS_INPUT"
-    },
-    "operation": {
-      "enum": [
-        "configure",
-        "deploy",
-        "status",
-        "logs",
-        "restart",
-        "rollback",
-        "health",
-        "history",
-        "validate"
-      ]
-    },
-    "environment": {
-      "enum": ["dev", "test", null]
-    },
-    "known_context": {
-      "type": "object",
-      "additionalProperties": false,
-      "required": ["project_type", "target", "config_path"],
-      "properties": {
-        "project_type": {
-          "type": ["string", "null"]
-        },
-        "target": {
-          "type": ["string", "null"]
-        },
-        "config_path": {
-          "const": ".prizmkit/deploy/deploy.config.json"
-        }
-      }
-    },
-    "questions": {
-      "type": "array",
-      "minItems": 1,
-      "items": {
-        "type": "object",
-        "additionalProperties": false,
-        "required": [
-          "id",
-          "prompt",
-          "answer_type",
-          "required",
-          "config_pointer",
-          "options"
-        ],
-        "properties": {
-          "id": {
-            "type": "string",
-            "pattern": "^[a-z][a-z0-9_]{0,63}$"
-          },
-          "prompt": {
-            "type": "string",
-            "minLength": 1
-          },
-          "answer_type": {
-            "enum": ["text", "single_choice", "multi_choice", "boolean", "integer"]
-          },
-          "required": {
-            "type": "boolean"
-          },
-          "config_pointer": {
-            "type": "string",
-            "pattern": "^/(?:[^~/]|~[01])+(?:/(?:[^~/]|~[01])*)*$"
-          },
-          "options": {
-            "type": "array",
-            "items": {
-              "type": "object",
-              "additionalProperties": false,
-              "required": ["value", "label"],
-              "properties": {
-                "value": {
-                  "type": ["string", "number", "boolean"]
-                },
-                "label": {
-                  "type": "string",
-                  "minLength": 1
-                }
-              }
-            }
-          }
-        },
-        "allOf": [
-          {
-            "if": {
-              "properties": {
-                "answer_type": {
-                  "enum": ["single_choice", "multi_choice"]
-                }
-              }
-            },
-            "then": {
-              "properties": {
-                "options": {
-                  "minItems": 1
-                }
-              }
-            },
-            "else": {
-              "properties": {
-                "options": {
-                  "maxItems": 0
-                }
-              }
-            }
-          }
-        ]
-      }
-    }
-  },
-  "examples": [
-    {
-      "schema_version": 1,
-      "result": "NEEDS_INPUT",
-      "operation": "configure",
-      "environment": null,
-      "known_context": {
-        "project_type": "Node.js",
-        "target": null,
-        "config_path": ".prizmkit/deploy/deploy.config.json"
-      },
-      "questions": [
-        {
-          "id": "deployment_target",
-          "prompt": "Which deployment target should this project use?",
-          "answer_type": "single_choice",
-          "required": true,
-          "config_pointer": "/deploymentMode",
-          "options": [
-            {
-              "value": "ssh",
-              "label": "SSH Linux server"
-            },
-            {
-              "value": "docker",
-              "label": "Docker"
-            }
-          ]
-        }
-      ]
-    }
-  ]
-}

package/bundled/skills/prizmkit-deploy/references/ssh-adapter-flow.md

@@ -1,221 +0,0 @@
-# SSH Adapter Flow
-
-Read this file when Discovery routes `/prizmkit-deploy` to SSH Linux full automation.
-
-The SSH adapter supports Node.js projects using PM2 + Nginx blue/green deployment.
-
-## 1. Deployment Mode Selection
-
-Before entering the configuration wizard, ask how the user wants to deploy:
-
-1. **Direct Upload** — build locally, transfer artifacts to the server, start with PM2. Best for first deployment and low-spec servers.
-2. **CI/CD Auto-Deploy** — configure GitHub Actions so pushes deploy automatically.
-
-If the user chooses CI/CD, ask which mode:
-
-- **Push mode** — GitHub Actions builds and SCPs artifacts to server. Low server load.
-- **Pull mode** — server pulls code and builds itself. Simpler workflow but requires a deploy key and build tools on the server.
-
-Read `references/deployment-modes.md` when the user needs the full comparison.
-
-Config field: `deployStrategy` in `deploy.config.json` is `direct-upload`, `ci-cd-push`, or `ci-cd-pull`. Existing configs without this field default to `ci-cd-pull` for backward compatibility.
-
-## 2. Server Model
-
-A valid SSH target:
-
-- Is reachable over SSH.
-- Provides a Linux shell.
-- Can install or already has Node.js, npm, PM2, Nginx, and Git.
-- Can access the configured repository when using CI/CD Pull mode.
-
-Roles:
-
-- `bootstrapUser`: usually root; installs packages and creates users/directories.
-- `runtimeUser`: default `deploy`; app processes run as this user and never as root.
-
-Server-side layout:
-
-```text
-/var/www/<project>/
-  releases/
-    <release-id>/
-  shared/
-    .env.production
-    deploy-metadata.json
-  current -> releases/<release-id>
-  deploy-logs/
-```
-
-`shared/.env.production` is strict UTF-8 dotenv data with one unique `KEY=value` assignment per line; update it atomically, keep mode `600`, and require runtime-user ownership. `shared/deploy-metadata.json` must conform to `${SKILL_DIR}/references/deploy-metadata-schema.json`, be written atomically after successful live verification, and contain no secrets.
-
-## 3. First-Run Configuration Wizard
-
-Flow: deployment mode → collect → validate → confirm → persist.
-
-Collect:
-
-1. SSH server host/port, bootstrap user, runtime user, auth method.
-2. Repository access only for `ci-cd-pull`: Git URL, branch, deploy-key or other auth.
-3. App configuration: app id, path, package manager, install/build/start commands, blue/green port pair, health checks.
-4. Environment variables: scan source for env references, ask for values or storage strategy.
-5. Persist `deploy.config.json` and render/update `deploy.md` from `${SKILL_DIR}/assets/deploy-document-template.md`.
-
-Validate SSH immediately with a harmless connectivity command before collecting deeper config. If SSH fails, stop and fix connectivity first.
-
-## 4. Bootstrap
-
-Before privileged bootstrap, present an action plan listing:
-
-- packages to install
-- users/groups to create
-- SSH keys to generate
-- Nginx config files to create/update
-- directories and permissions
-- services that may restart
-
-Rules:
-
-- User gives one explicit approval for the bootstrap plan.
-- If the plan changes during execution, pause and ask again.
-- Bootstrap operations must be idempotent.
-- Existing config files must be backed up before modification.
-- Failed bootstrap stops before deployment and provides recovery instructions.
-
-Read `references/ssh-bootstrap-flow.md` for the detailed bootstrap procedure. It routes to `references/firewall-setup.md` and `references/database-setup.md` when those branches are selected.
-
-## 5. Strategy-Specific Setup
-
-Direct upload:
-- Build locally and transfer artifacts.
-- No Git operation is required on the server.
-- Read `references/direct-upload.md`.
-
-CI/CD push or pull:
-- Generate `.github/workflows/deploy.yml` from `references/ci-cd-workflows.md`.
-- Verify the first push to the configured branch will trigger deployment.
-- Pull mode requires a deploy key on the server; show the public key and wait for the user to add it to GitHub Deploy Keys before verifying clone access.
-
-After a successful direct-upload deployment, offer CI/CD setup so future `git push` can deploy automatically.
-
-## 6. DNS and SSL
-
-Before SSL, ask whether the user has a domain for the project.
-
-- If no domain, skip DNS + SSL and note it in `deploy.md`.
-- If a domain exists, check DNS before SSL.
-- Read `references/dns-setup.md` for DNS instructions.
-- Read `references/ssl-setup.md` for Let's Encrypt / certificate guidance.
-
-Always verify certificate renewal when Let's Encrypt is configured.
-
-## 7. Deployment Execution
-
-Read `references/ssh-execution-flow.md` for the full pipeline.
-
-Core sequence:
-
-1. Pre-flight and prepare release.
-2. Fetch/build or receive artifact.
-3. Stage new process on inactive blue/green port.
-4. Health-check inactive port.
-5. Switch Nginx upstream only after staged health checks pass.
-6. Verify public endpoint.
-7. Stop old process, cleanup old releases, record history.
-
-Failure rules:
-
-- If any step before traffic switch fails, stop and leave the live version unchanged.
-- If a public health check fails after traffic switch, rollback immediately.
-- Do not delete failed release logs; preserve them for debugging.
-
-## 8. Blue/Green PM2 + Nginx Invariants
-
-- Default ports: blue `3101`, green `3102`.
-- Active color is persisted in `shared/deploy-metadata.json` using `${SKILL_DIR}/references/deploy-metadata-schema.json`.
-- PM2 process name: `<project>-<app>-<color>`.
-- Nginx managed blocks include `# PrizmKit Managed: <project> — DO NOT EDIT MANUALLY`.
-- First creation or modification of non-PrizmKit Nginx config requires user confirmation.
-- Always run `nginx -t` before reload.
-
-Read `references/nginx-blue-green.md` for config templates and traffic switch details.
-
-## 9. Rollback
-
-Rollback can be automatic or manual.
-
-Manual command:
-
-```text
-/prizmkit-deploy rollback --app <id> [--to <releaseId>]
-```
-
-Steps:
-
-1. Identify target release.
-2. Verify build artifacts exist.
-3. Start PM2 on the target release/port.
-4. Update Nginx upstream.
-5. Run `nginx -t` and reload.
-6. Run public health checks; if they fail, restore the prior verified upstream.
-7. Allocate and atomically write the rollback history event through `${SKILL_DIR}/references/deploy-history-schema.md`.
-8. Atomically update `shared/deploy-metadata.json` through `${SKILL_DIR}/references/deploy-metadata-schema.json` with the restored release/color/port and rollback event identity.
-
-If no previous release exists, state clearly that rollback is not possible.
-
-## 10. Operations Commands
-
-- `status`: PM2 list, active release, active color/port, last deploy.
-- `logs --app <id>`: recent PM2 logs for active process.
-- `restart --app <id>`: restart active PM2 process and run health checks.
-- `health --app <id>`: run configured health checks.
-- `history`: list deploy history events chronologically.
-
-Run app commands as `runtimeUser`.
-
-## 11. Secrets Management
-
-Supported storage modes:
-
-- `ask-every-time`
-- `ignored-local-env`
-- `user-managed-on-server-only`
-
-Rules:
-
-- `ignored-local-env` uses `.prizmkit/deploy/secrets.local.env`, must be ignored by Git and current-user-only, and follows `${SKILL_DIR}/references/database-setup.md` dotenv/migration safety.
-- Legacy `plaintext-local` requires explicit migration to `ignored-local-env`; legacy `encrypted-local` is unsupported and requires user selection of a supported mode before deployment.
-- Server runtime secrets live in `shared/.env.production` with mode `600`.
-- Deploy history records secret presence metadata only.
-- Never record raw secret values, passphrases, decryption keys, or unsalted hashes.
-
-## 12. Existing Deployment Takeover
-
-When the target server already has deployment assets, read `references/ssh-takeover.md`.
-
-Record takeover decisions and validation results in config and history.
-
-Before modifying non-PrizmKit-managed Nginx config, ask for confirmation.
-
-## 13. Multi-App Coordination
-
-An all-app deploy creates one release group.
-
-Rules:
-
-- Pre-traffic phases must complete for all selected apps before any app switches traffic.
-- If any app fails before traffic switch, no app switches traffic.
-- If any app fails after traffic switch, default to group rollback.
-- Single-app deploys do not affect unrelated apps.
-
-## 14. History and Validation
-
-Write a deploy-history record for every deploy, rollback, takeover, validation, user-abort, failed deploy, or adapter gap.
-
-Read:
-
-- `references/deploy-history-schema.md`
-- `references/deploy-config-schema.md`
-- `references/live-validation-notes.md` when troubleshooting bootstrap or deploy failures
-
-Validation is mandatory before production deploy.

package/bundled/skills/prizmkit-deploy/references/ssh-bootstrap-flow.md

@@ -1,49 +0,0 @@
-# SSH Bootstrap Flow
-
-Bootstraps the server before first deployment. Present a plan showing every privileged action before executing anything.
-
-## Always-Run Preflight
-
-```
-locale-gen en_US.UTF-8           # fix locale warnings on bare Ubuntu
-apt-get update -qq               # refresh package list
-```
-
-## Check-and-Install (idempotent)
-
-Node.js, npm, PM2, Nginx, Git. Use v22 LTS if v25 not available.
-
-## Detect Port Conflicts
-
-`ss -tlnp | grep :80 || true`. If port 80/443 is occupied, report and ask how to resolve.
-
-## User and Directory Setup
-
-```
-useradd -m -s /bin/bash <runtimeUser>   # if not exists
-mkdir -p /var/www/<project>/{releases,shared,deploy-logs}
-chown -R <runtimeUser>:<runtimeUser> /var/www/<project>
-```
-
-## PM2 Startup
-
-```
-env PATH=$PATH:/usr/bin pm2 startup systemd -u <runtimeUser> --hp /home/<runtimeUser>
-```
-
-## Deploy Key (Pull mode only)
-
-```
-sudo -u <runtimeUser> ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
-sudo -u <runtimeUser> ssh-keyscan -H github.com >> ~/.ssh/known_hosts
-```
-
-## Security Baseline (Firewall)
-
-After core tools are installed, ask whether to configure ufw. If user agrees, read `references/firewall-setup.md` for the full interactive flow and rule templates.
-
-## Database Setup
-
-If Discovery detected database drivers, ask whether to install the database on the server. If user agrees, read `references/database-setup.md` for platform-specific setup commands and security notes.
-
-After each bootstrap step, record the result. Bootstrap operations must be idempotent. Back up any existing config files before modifying them.

package/bundled/skills/prizmkit-deploy/references/ssh-execution-flow.md

@@ -1,41 +0,0 @@
-# SSH: Deployment Execution Flow
-
-Pipeline runs in strict order. Each group must complete before the next begins. If any step before traffic switch fails, STOP — do not touch the live version.
-
-## Pre-flight — Change Summary
-
-Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD`. If first deployment, show last 5 commits. If no new commits, warn "No new code changes. Are you sure you want to redeploy?"
-
-## Group 1 — Pre-flight & Prepare
-
-- Verify SSH, runtime user, tools, deploy key, port availability.
-- Generate `releaseId`: `YYYYMMDDTHHMMSSZ-<short-commit-sha>` in UTC. If that release directory already exists, select the lowest free suffix from `-01` through `-99`; never reuse or overwrite a release directory, and stop if the suffix space is exhausted. Create `releases/<releaseId>`.
-- Determine target color: read `activeColor` from `shared/deploy-metadata.json` and use the opposite. If first deploy (no metadata, no `current` symlink), default to blue (port 3101).
-
-## Group 2 — Fetch & Build
-
-- **CI/CD Pull mode** (server-side build): git clone → install → copy `.env.production` before build (NEXT_PUBLIC_* vars are baked at build time) → build. If build fails: STOP.
-- **CI/CD Push mode** (runner-side build): extract tarball, skip install/build.
-- **Direct-upload mode**: build was already done locally and SCP'd. Skip this group.
-
-## Group 3 — Stage & Health Check
-
-- Start new version on inactive port via PM2: `pm2 start npm --name <project>-<app>-<color> -- run start -- -p <inactivePort>`.
-- PM2 process naming: `<project>-<app>-<color>` (e.g., `prizm-ideas-web-green`).
-- Wait 3-5 seconds, run health checks against new port. If any fails: STOP, do NOT switch traffic.
-
-## Group 4 — Switch & Verify
-
-- Update Nginx upstream to new port. Run `nginx -t` — abort on failure.
-- `systemctl reload nginx`. Update `current` symlink to new release.
-- Run health checks against the public endpoint. If any fails, rollback immediately and do not record the candidate as active.
-
-## Group 5 — Cleanup & Record
-
-- Allocate the collision-safe deploy event ID and atomically write deploy-history JSON using `${SKILL_DIR}/references/deploy-history-schema.md`, with event identity separate from `releaseId`.
-- After the history record succeeds, atomically write `shared/deploy-metadata.json` from `${SKILL_DIR}/references/deploy-metadata-schema.json` with the verified `activeColor`, `activePort`, `lastReleaseId`, operation event ID, and UTC update time. If either record write fails, preserve both processes/releases, report a recording failure, and require the next operation to rediscover active state from Nginx plus the `current` symlink before retrying metadata repair.
-- Stop the old PM2 process. Remove oldest releases beyond `releaseRetention` count. Run `pm2 save` and update `deploy.config.json` validation status.
-
-## Post-deploy — Completion Summary
-
-Output a summary (project, URL, version, duration, health status) and update the matching sections of `deploy.md` from `${SKILL_DIR}/assets/deploy-document-template.md`; do not append duplicate headings or an event log. If `deployStrategy` is `"direct-upload"`, offer CI/CD upgrade (see §SSH: Post-Deploy CI/CD Upgrade).