prizmkit 1.1.159 → 1.1.160

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`

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

@@ -1,78 +0,0 @@
-# Deploy History Record Schema
-
-Each immutable event is written atomically to `.prizmkit/deploy/deploy-history/<eventId>.json`. The filename stem must equal the JSON `eventId` exactly.
-
-```json
-{
-  "eventId": "deploy-20260430T142233Z-22783a3",
-  "eventType": "deploy|rollback|status|validation|failed-deploy|user-aborted|takeover|adapter-gap|database-setup",
-  "timestamp": "<ISO 8601 UTC>",
-  "releaseId": "20260430T142233Z-22783a3 or null",
-  "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/20260430T142233Z-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>"
-}
-```
-
-## Event and File Identity
-
-Generate every `eventId` as:
-
-```text
-<event-type>-<UTC-compact-timestamp>-<short-sha-or-none>[-NN]
-```
-
-Rules:
-
-- `UTC-compact-timestamp` is the event time formatted `YYYYMMDDTHHMMSSZ`.
-- `short-sha` is the lowercase 7-12 hexadecimal commit prefix when a commit exists; otherwise use literal `none`.
-- If the candidate filename already exists, append the lowest available two-digit suffix from `-01` through `-99`; never overwrite a history record. If all suffixes are occupied, stop with a recording error.
-- Use the exact event ID as the filename stem. Example: `rollback-20260430T151000Z-22783a3.json`.
-- `releaseId` is a separate deployment/release-directory identity. Set it to the affected release for deploy, failed-deploy, and rollback events; otherwise use `null` when no release applies.
-
-## Field Notes
-
-- `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/prizmkit-deploy/references/deploy-metadata-schema.json

@@ -1,49 +0,0 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "PrizmKit Server Deployment Metadata",
-  "type": "object",
-  "additionalProperties": false,
-  "required": [
-    "schema_version",
-    "activeColor",
-    "activePort",
-    "lastReleaseId",
-    "lastOperationEventId",
-    "updatedAt"
-  ],
-  "properties": {
-    "schema_version": {
-      "const": 1
-    },
-    "activeColor": {
-      "enum": ["blue", "green"]
-    },
-    "activePort": {
-      "type": "integer",
-      "minimum": 1,
-      "maximum": 65535
-    },
-    "lastReleaseId": {
-      "type": "string",
-      "pattern": "^[0-9]{8}T[0-9]{6}Z-[0-9a-f]{7,12}(?:-[0-9]{2})?$"
-    },
-    "lastOperationEventId": {
-      "type": "string",
-      "pattern": "^[a-z][a-z-]*-[0-9]{8}T[0-9]{6}Z-(?:[0-9a-f]{7,12}|none)(?:-[0-9]{2})?$"
-    },
-    "updatedAt": {
-      "type": "string",
-      "format": "date-time"
-    }
-  },
-  "examples": [
-    {
-      "schema_version": 1,
-      "activeColor": "blue",
-      "activePort": 3101,
-      "lastReleaseId": "20260430T142233Z-22783a3",
-      "lastOperationEventId": "deploy-20260430T142233Z-22783a3",
-      "updatedAt": "2026-04-30T14:22:33Z"
-    }
-  ]
-}

package/bundled/skills/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/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.