@lifeaitools/rdc-skills 0.35.4 → 0.35.6

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rdc",
-  "version": "0.35.4",
+  "version": "0.35.6",
   "description": "RDC typed-agent dispatch skill suite for Claude Code — plan, build, review, overnight unattended builds with work-item tracking and TDD enforcement.",
   "author": {
     "name": "LIFEAI",

package/commands/build.md

@@ -69,6 +69,25 @@ Read the task title and description, then:
 - Mentions visualization, chart, diagram, SVG → `viz`
 - Multiple types? Dispatch multiple agents, each with its guide.
 
+### Execution primitive for create/open/build/deploy checklist rows
+
+When a dispatched agent's checklist row is to materialize a product shape,
+open a signed edit session, run a target's declared build gates, or deploy
+to dev-PM2/npm-registry, it uses the real, tested `rdc-harness` CLI instead
+of hand-rolled bash/curl:
+
+```bash
+node C:/Dev/rdc-harness/bin/rdc-harness.mjs <create|open|edit|build|deploy> <slug> --monorepo-root <the dispatched agent's own worktree>
+```
+
+One JSON receipt per call, exit 0/1 — tick the checklist row with the parsed
+receipt as evidence, not the raw dump. No Coolify awareness (production
+deploy stays `/rdc:deploy`'s own path) and no live co-editing surface
+outside `site-html`/`site-ts` (other classes get file-boundary save only —
+real, currently-unbuilt gap for other product classes, not something to
+paper over here). `open`/`edit` require `RDC_HARNESS_ISSUER_SECRET` set
+explicitly per-session — never a default.
+
 ## Procedure
 
 1. **Load the epic and its durable admission decisions:**

package/commands/deploy.md

@@ -27,11 +27,30 @@ No raw MCP dumps. No UUIDs unless asked.
 - `rdc:deploy audit` — fleet-wide scan for missed failures
 - `rdc:deploy audit --fix` — fleet scan + auto-remediate safe issues
 - `rdc:deploy maintenance <service>` — create, update, or verify a template-declared private service; no public domain or host port
+- `rdc:deploy dev <slug>` — deploy to PM2 dev (Vultr), not Coolify — see Mode 0
 - `rdc:deploy` (no args) — print mode menu, ask which
 
 ## Modes
 
-### Mode 1 — deploy <slug> [build-id]
+### Mode 0 — dev <slug> (PM2 development, not Coolify)
+
+PM2 dev deploys route through the real, tested `rdc-harness` CLI instead of
+raw PM2/curl — it already implements this path (`shipRoute: pm2-development`,
+via `@lifeaitools/regen-deploy-mgr` on loopback :52438, never raw PM2):
+
+```
+rdc:deploy dev: <slug>
+[ ] node C:/Dev/rdc-harness/bin/rdc-harness.mjs deploy <slug> --monorepo-root <caller's own worktree>
+[ ] JSON receipt parsed — shipRoute confirmed "pm2-development" (else: not this product's route, see receipt.reason)
+[ ] Receipt reports ok / the specific refusal, reported verbatim — not narrated
+✅ rdc:deploy dev: <slug> — <receipt outcome in one line>
+```
+
+A receipt with `applicable: false, reason: 'not_pm2_shipped'` means this slug
+ships a different way (registry, static, or Coolify) — report that plainly,
+do not retry as Coolify without confirming that's actually the right route.
+
+### Mode 1 — deploy <slug> [build-id] (Coolify — staging/production)
 
 ```
 rdc:deploy: <slug> → <domain>

package/commands/fixit.md

@@ -70,6 +70,23 @@ This signals the Stop hook that fixit is handling its own documentation.
 
 ### 4. Make the fix
 
+If the fix is a create/open/build/deploy step against a real fleet
+repository (materialize a product shape, open a signed edit session, run a
+target's declared build gates, or deploy to dev-PM2/npm-registry), use the
+real, tested `rdc-harness` CLI instead of hand-rolled bash/curl:
+
+```bash
+node C:/Dev/rdc-harness/bin/rdc-harness.mjs <create|open|edit|build|deploy> <slug> --monorepo-root <your own worktree, never the shared checkout>
+```
+
+One JSON receipt on stdout, exit 0/1 — use it as the evidence for whichever
+checklist/commit step it satisfies. It has no Coolify awareness (deploy here
+means PM2 dev or npm publish only — Coolify stays this skill's own §5.5 path)
+and no live co-editing surface outside `site-html`/`site-ts` targets (other
+classes get boundary-checked file save only). `open`/`edit` need
+`RDC_HARNESS_ISSUER_SECRET` set explicitly — no default exists or should.
+For anything not create/open/build/deploy shaped, edit files directly as below.
+
 Do the minimal work, conforming to `docs/CODING-STANDARDS.md` where present
 (regen-root; skip if absent). Scope creep rule: if you discover the fix requires more than originally scoped, **stop immediately**:
 1. Close the work item: `update_work_item_status('<id>', 'blocked', '["Escalated — scope exceeded fixit threshold"]')`

package/commands/flow.md

@@ -0,0 +1,94 @@
+---
+name: flow
+description: >-
+  Usage `rdc:flow [status|<state> ["<reason>"]|normal]` — show or set the current flow state. Flow is the single FSM surface for both work-shape (plan/design/collab/build/refactor/overnight/harness-testing) and ceremony relaxation (hotfix/maintenance). Supersedes `rdc:mode` — hotfix/maintenance are flow values now, not a separate system.
+---
+
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
+> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
+
+# rdc:flow — the one FSM surface
+
+## When to Use
+- Starting a turn — declare what kind of work this is (`build` needs a work item, `plan`/`design`/`collab` don't)
+- A production incident where process ceremony is costing minutes that matter (`hotfix`)
+- Routine upkeep that needs the same relaxation, without calling it an incident (`maintenance`)
+- Checking what's currently declared, and why
+
+## The one thing to understand first
+
+**There used to be two systems — mode (safety relaxation) and flow (work-shape declaration) — kept deliberately separate.** Operator instruction, 2026-08-25/26, direct and live: *"no special modes -- flow states only -- move hotfix to a flow state -- move env-bypass to a flow state -- the fsm will set what is enabled."*
+
+`hotfix` and `maintenance` are now real flow values, carrying the exact same safety guarantee they always did as modes: a reason is required to enter either, and only the named ceremony allowlist (`HOTFIX_DISABLES`/`HOTFIX_RELAXES_GATES` in `$LIFEAI_ENV/hooks/lib/rdc-flow.mjs` and `C:/Dev/rdc-harness/fsm-daemon/src/matrix.js`) is ever relaxed — never a safety guard (`execution-scope`, `rm-rf-danger`, `push-force`, credential-exposure, etc.).
+
+`rdc:mode` still exists for backward compatibility — the old mode axis is untouched, working code — but new work should use `rdc:flow` for everything, including what used to be a mode change.
+
+## States
+
+| State | Meaning | Requires a reason | Work item required |
+|---|---|---|---|
+| `plan` / `design` / `collab` | Conversational — nothing shipping | no | no |
+| `build` / `refactor` / `overnight` | Shipping code | no | **yes** |
+| `harness-testing` | Proving/testing rdc-harness's own binding guard | no | yes |
+| `hotfix` | Incident — ceremony relaxed for a bounded reason | **yes** | no |
+| `maintenance` | Routine upkeep — same relaxation power as hotfix, different label | **yes** | no |
+
+## Usage
+
+```
+rdc:flow                          # status — the default
+rdc:flow status
+rdc:flow build                    # declare shipping work — no reason needed
+rdc:flow hotfix "prod checkout 500s"   # relax ceremony — reason required
+rdc:flow normal                   # clear — back to no flow declared
+```
+
+## Steps
+
+### 1. Read the current state
+
+```bash
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-flow.mjs').href).then(m=>console.log(JSON.stringify(m.currentState(),null,2)))"
+```
+
+`currentState()` reads BOTH axes at once — the declared flow AND any live `rdc-mode.mjs` hotfix/maintenance window — because a relaxed mode overrides a required flow (loosest state wins) and a status check that only showed flow would miss that override entirely. Report `flow` (or `null` if nothing declared — the fail-closed default), `flowReason`/`flowSetBy`/`flowSetAt` when set, and `mode` (`normal` unless a hotfix/maintenance window is open), with `modeReason`/`modeMinutesLeft` when it isn't.
+
+### 2. Setting a plain work-shape flow — no reason required
+
+```bash
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-flow.mjs').href).then(m=>console.log(JSON.stringify(m.setFlow(process.argv[1],{setBy:process.argv[2]}),null,2)))" "<flow>" "<session-id>"
+```
+
+### 3. Setting hotfix or maintenance — a reason is REQUIRED
+
+Refuse to proceed without one — `setFlow` throws on an empty reason for these two values, by design, same as `setMode` always did: an unexplained disarm is how a temporary state becomes permanent.
+
+```bash
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-flow.mjs').href).then(m=>console.log(JSON.stringify(m.setFlow('hotfix',{reason:process.argv[1],setBy:process.argv[2]}),null,2)))" "<reason>" "<session-id>"
+```
+
+Then state plainly, in the checklist: **which guards are now relaxed, that the safety set is still armed, and that this stays active until explicitly cleared (no TTL — active management, not a silent timer).**
+
+### 4. Returning to normal
+
+```bash
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-flow.mjs').href).then(m=>{m.clearFlow();console.log('cleared')})"
+```
+
+Do this **as soon as the incident is over**, or the moment the declared work-shape changes.
+
+## Rules
+
+- **A reason is mandatory for `hotfix`/`maintenance`.** Every other flow value is a plain, reason-free declaration.
+- **No TTL, ever, by default.** A flow — including `hotfix`/`maintenance` — stays active until explicitly cleared or replaced. Never a silent expiry.
+- **Fail-closed.** No flow declared, an unreadable daemon, or a malformed response all read as `{flow: null}` — same behavior a work-shipping turn always had before this mechanism existed.
+- **Never widen the relaxation set to unblock yourself.** A guard blocking a hotfix flow is information. Editing the allowlist to get past a red guard is the same violation as editing code to satisfy a failing gate (`.claude/rules/debugging-protocol.md` Rule 10).
+- **hotfix/maintenance flow is not a bypass of review.** Work done under it still needs its work item, its evidence, and its close.
+
+## Verification
+
+```bash
+node --test $LIFEAI_ENV/tests/rdc-flow.test.mjs
+node --test C:/Dev/rdc-harness/fsm-daemon/tests/matrix.test.js
+```

package/commands/mode.md

@@ -8,6 +8,12 @@ description: >-
 > Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
 > One checklist upfront, updated in place, shown again at end with a 1-line verdict.
 
+> **Superseded by `rdc:flow`, 2026-08-26.** `hotfix`/`maintenance` are now
+> flow values (same reason-required, same relaxation allowlist, no TTL by
+> default) — one FSM surface instead of two. This skill's underlying code
+> (`rdc-mode.mjs`) is untouched and still works; new work should use
+> `rdc:flow hotfix "<reason>"` instead of `rdc:mode hotfix ...`.
+
 # rdc:mode — operating mode
 
 ## When to Use
@@ -64,7 +70,7 @@ rdc:mode normal                       # close it early
 ### 1. Read the current mode
 
 ```bash
-node -e "import('file:///C:/Dev/lifeai-env/hooks/lib/rdc-mode.mjs').then(m=>console.log(JSON.stringify(m.currentMode(),null,2)))"
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-mode.mjs').href).then(m=>console.log(JSON.stringify(m.currentMode(),null,2)))"
 ```
 
 Report `mode`, and when not normal also `reason`, `setBy`, and `minutesLeft`.
@@ -78,7 +84,7 @@ unexplained disarm is how a temporary state becomes permanent, and the reason is
 the entire content of the audit line.
 
 ```bash
-node -e "import('file:///C:/Dev/lifeai-env/hooks/lib/rdc-mode.mjs').then(m=>console.log(JSON.stringify(m.setMode('hotfix',{reason:process.argv[1],minutes:Number(process.argv[2]||60),setBy:process.argv[3]}),null,2)))" "<reason>" "<minutes>" "<session-id>"
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-mode.mjs').href).then(m=>console.log(JSON.stringify(m.setMode('hotfix',{reason:process.argv[1],minutes:Number(process.argv[2]||60),setBy:process.argv[3]}),null,2)))" "<reason>" "<minutes>" "<session-id>"
 ```
 
 Then state plainly, in the checklist: **which guards are now off, that the safety
@@ -87,7 +93,7 @@ set is still armed, and the exact wall-clock time the window closes.**
 ### 3. Returning to normal
 
 ```bash
-node -e "import('file:///C:/Dev/lifeai-env/hooks/lib/rdc-mode.mjs').then(m=>{m.clearMode();console.log('normal')})"
+node -e "import(require('url').pathToFileURL(process.env.LIFEAI_ENV + '/hooks/lib/rdc-mode.mjs').href).then(m=>{m.clearMode();console.log('normal')})"
 ```
 
 Do this **as soon as the incident is over**. The window expiring on its own is

package/commands/open.md

@@ -0,0 +1,84 @@
+---
+name: open
+description: >-
+  Usage `rdc:open [<slug>]` — orient before working. Answers where you are (repo, worktree, branch, dirty state) and what the target is (runtime, port, host, deploy path) from the registry, then names the harness shape to use. Run this first in any session that will change something.
+---
+
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
+
+# rdc:open — you are here, this is the thing, use this shape
+
+## Why this exists
+
+Orientation ran **3.4× production work** across a measured 36-hour window —
+47.6% of tool calls establishing position and identity, 14.1% actually changing
+something. `git rev-parse` alone was 316 calls, 6% of everything.
+
+Cross-session rediscovery was **1.4%**. That number is the point: agents are not
+forgetting what they learned, they are working new ground almost every time and
+nothing tells them where they are. This is a surfacing problem, not a memory
+problem, so caching buys nothing and an opening statement buys everything.
+
+## When to Use
+
+- **First call of any session that will change something.** Before the first
+  read, not after the third `git status`.
+- When you are handed a slug and do not know its runtime, port, or host.
+- After a compaction, when position facts have aged out of context.
+- Before any deploy — `rdc:deploy` assumes you already know the target's shape.
+
+Not needed for a pure conversation turn.
+
+## What it answers
+
+| Question | Source | Never |
+|---|---|---|
+| which repo / worktree / branch am I in | `git rev-parse`, `git status` | assumed from a hardcoded path |
+| is my tree clean, am I behind | `git status -sb` | inferred from elapsed time |
+| what IS this slug | `get_deployment('<slug>')` | guessed from the directory name |
+| runtime, port, PM2 name, host | the registry | inferred from files on disk |
+| who depends on it | the registry | assumed to be nothing |
+
+**Two guesses this replaces, both measured wrong in practice:** filesystem
+inference said `node-build` where the registry says `ts-server`; and
+directory-name-as-slug fails outright — `packages/codeflow` is `codeflow-mcp`,
+`apps/admin` is `portal`.
+
+## Steps
+
+1. **Position.** `node scripts/orient.mjs` — repo, worktree, branch @ sha,
+   upstream, dirty count. Relative paths from here are correct by construction;
+   a hardcoded `C:/Dev/regen-root/...` from a lane points at a *different
+   checkout*.
+2. **Target.** `node scripts/orient.mjs <slug>` — resolves the slug through
+   `get_deployment`, printing runtime, port, host, deploy path and dependents.
+   `monorepo_path` NULL means a standalone repo, not in this tree.
+3. **Harness.** Name the shape the target's class implies:
+
+   | class | build | dev | prod |
+   |---|---|---|---|
+   | `apps/<name>` | `pnpm --filter @regen/<name> build` | PM2 @ Vultr | Coolify |
+   | `packages/<name>` | `pnpm --filter @regen/<name> build` | imported | `npm publish` |
+   | `sites/`, `models/` | static/vite | PM2 @ Vultr | Coolify |
+   | standalone | its own tooling | — | Coolify |
+
+4. **State the ground in one line** and start. Do not re-derive it later in the
+   turn.
+
+## Checklist
+
+```
+[ ] position resolved — repo, worktree, branch, dirty count
+[ ] target resolved from the registry (or: no slug given, position only)
+[ ] harness shape named for the target's class
+[ ] blockers noted — behind upstream, dirty tree, service down
+```
+
+## Related
+
+- `rdc:flow` — declares what KIND of work this is. `rdc:open` says where you are;
+  `rdc:flow` says what you are doing. Both, in that order.
+- `rdc:status` — open epics and queue. That is the work; this is the ground.
+- `$LIFEAI_ENV/docs/GATES-GUARDS-DENIES.md` — when a guard stops you, that names
+  the shape that works.

package/commands/release.md

@@ -39,6 +39,17 @@ rdc:release: <repo> vX.Y.Z -> vA.B.C
 - Never force push or bypass hooks.
 - Never declare success without verifying the installed or deployed version.
 
+For a `package`-class target that already resolves through `rdc-harness`
+(a real monorepo subtree, not a standalone repo like this one), its
+`packages/deploy/src/runners/registry-release.mjs` runner already proves the
+"Tests/self-test passed" through "Local install/update executed" steps
+safely — real `npm pack`, isolated-prefix install (never the real global
+store), real verify, and `--live` explicitly gates the actual publish. Where
+applicable, `node C:/Dev/rdc-harness/bin/rdc-harness.mjs deploy <slug>
+[--live]` can supply those checklist rows' evidence directly instead of
+hand-rolling the same pack/install/verify cycle. This does not replace
+version bump/tag/push — the harness CLI does neither.
+
 ## RDC Skills Package
 
 After publishing this package to npm, a clean-box install should use: