@lifeaitools/rdc-skills 0.26.0 → 0.26.2

package/commands/deploy.md

@@ -155,6 +155,22 @@ _COOLIFY=$(curl -s http://127.0.0.1:52437/v/coolify-api)
 curl -s -H "Authorization: Bearer $_COOLIFY" "$DEPLOY_API_BASE/api/v1/applications"
 ```
 
+**Triggering the actual deploy is different — use the wrapper, not raw curl.**
+`hooks/lib/guard-rules.mjs`'s `coolify-direct` rule blocks a raw curl (or any command whose
+TEXT contains the literal URL) to `/api/v1/deploy` — the deploy-trigger endpoint — on
+purpose, so a production deploy is never one arbitrary curl an agent can fire silently. This
+is NOT a bug to route around with SSH or a differently-worded command
+(`.rdc/lessons/2026-08-07-deploy-coolify-direct-blocks-own-documented-step.md`). The
+sanctioned way to actually trigger a deploy for Mode 1's "Deploy triggered" step is:
+
+```bash
+python3 scripts/coolify-deployments.py deploy <application-uuid>
+```
+
+Run from the regen-root repo root. Poll `status <deployment-uuid>` (the same script) or
+`GET /api/v1/deployments/<deployment-uuid>` (read-only, not blocked) until `status` is
+`finished`/`failed`/`cancelled` before moving to the gate checks.
+
 If clauth daemon is not responding:
 ```
 BLOCKED: clauth daemon not responding. Run scripts\restart-clauth.bat, unlock at http://127.0.0.1:52437

package/git-sha.json

@@ -1,3 +1,3 @@
 {
-  "sha": "77862e606f1a235f41025233d6159eec5f5346d3"
+  "sha": "e634f9ffc42be06bccedfa3d6ab4e85bf79b5c70"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lifeaitools/rdc-skills",
-  "version": "0.26.0",
+  "version": "0.26.2",
   "description": "RDC typed-agent dispatch skill suite for Claude Code - plan, build, review, overnight builds",
   "keywords": [
     "claude-code",

package/skills/deploy/SKILL.md

@@ -207,7 +207,17 @@ Severity rules:
 
 Promote a **verified `develop` change** for one app to production. This is the sanctioned production-patch fast path — one command instead of fighting branch protection, the main-push hook, and a flaky Coolify webhook by hand.
 
-**Authorization:** production promote requires explicit user go-ahead ("promote", "patch prod", "push live", "go"). A dev deploy does NOT. If the user has not given it for THIS promote, stop and ask first.
+**Authorization:** production promote requires explicit user go-ahead, in either form:
+- **Per-promote:** a direct go word for THIS call ("promote", "patch prod", "push live", "go").
+- **Standing opt-in:** the user names one slug and grants it for the current session only ("auto-promote <slug> whenever dev is green", "standing go-ahead for <slug> this session"). Scope rules:
+  - One named slug per opt-in — never blanket ("auto-promote everything").
+  - Expires with the session. A new session/conversation needs a fresh opt-in; never infer one from a prior session's transcript or memory.
+  - Does not skip any other gate below — metadata-audit block, content-level verify, mandatory code review block on critical/high, scope guard, and back-merge all still run in full. The opt-in only removes the "stop and ask" step.
+  - Before EACH promote under a standing opt-in, re-verify dev is green with a **fresh** check (the content-level check further down this checklist) — "dev is green" means checked now for this call, not remembered from earlier in the session.
+
+A dev deploy requires neither form. If the user has not given either form of go-ahead for THIS promote, stop and ask first.
+
+Approved: option-2 — standing per-slug/session opt-in. Interview: 2026-07-31 (Dave), regen-root session.
 
 ```
 rdc:deploy promote: <slug> → <prod-domain>

package/skills/release/SKILL.md

@@ -17,7 +17,7 @@ description: "Usage `rdc:release <repo> [version|--patch|--minor|--major|--dry-r
 - A package or app needs versioning plus verification.
 - A repo provides release metadata in `package.json`, `.rdc/release.json`, README release instructions, or CI config.
 
-Never release without explicit user authorization.
+Never release without explicit user authorization — either a direct go-ahead for THIS release, or a standing opt-in for one named repo scoped to the current session only (same contract as `rdc:deploy` Mode 5's standing opt-in: one repo, expires with the session, does not skip the code-review block or any other gate below, requires a fresh dev-green check before each release under the opt-in). Approved: option-2 — standing per-slug/session opt-in. Interview: 2026-07-31 (Dave), regen-root session.
 
 ## Inputs