@lifeaitools/rdc-skills 0.35.3 → 0.35.5

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rdc",
-  "version": "0.35.3",
+  "version": "0.35.5",
   "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/CHANGELOG.md

@@ -7,6 +7,32 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ---
 
+## v0.35.4 — marketplace sync false-positive: untracked file blocked it forever
+
+### Fixed
+- `syncMarketplaceCheckout()`'s dirty-check used plain `git status --porcelain`,
+  which also reports untracked files. A single harmless untracked file in a
+  marketplace clone (e.g. a stray local scratch file) made the check treat the
+  clone as "has local changes" and permanently refuse to sync it, on every
+  single install run, forever — even though `git reset --hard` never touches
+  untracked files and there was no real edit to preserve. This is the
+  confirmed root cause of the marketplace checkout sitting stale for over a
+  week despite repeated installer runs. Fixed to `--untracked-files=no`, which
+  checks only tracked-file modifications — genuine local edits still block the
+  sync exactly as before (PRESERVE-DIRTY intact); a stray untracked file no
+  longer does.
+- Regression test added: a real temp git origin+clone pair reproduces both the
+  untracked-cruft case (must sync) and the genuine-local-edit case (must still
+  block), so this cannot silently regress.
+- `tests/install-rdc-skills.test.mjs` also had two stale fixtures caught while
+  fixing this: `package-lock.json` version drifted from `package.json`
+  (0.35.2 vs 0.35.3+), and a hardcoded `skillCount === 36` assertion had rotted
+  against the real, current 43 skill directories. The count assertion now
+  compares against the actual `skills/*/SKILL.md` directories on disk instead
+  of a hardcoded number, so it can't go stale the same way again.
+
+---
+
 ## v0.35.3 — coding standards wired into plan/preplan/build/fixit/review
 
 ### Fixed

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('file:///C:/Dev/lifeai-env/hooks/lib/rdc-flow.mjs').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('file:///C:/Dev/lifeai-env/hooks/lib/rdc-flow.mjs').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('file:///C:/Dev/lifeai-env/hooks/lib/rdc-flow.mjs').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('file:///C:/Dev/lifeai-env/hooks/lib/rdc-flow.mjs').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

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: