@lifeaitools/rdc-skills 0.24.36 → 0.24.38

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rdc",
-  "version": "0.24.36",
+  "version": "0.24.38",
   "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/git-sha.json

@@ -1,3 +1,3 @@
 {
-  "sha": "cf32c946a9301254d1cd07754c1d457de585b682"
+  "sha": "89d32243a6d9217b533b5de150c891f0750cdaf5"
 }

package/package.json

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

package/skills/build/SKILL.md

@@ -101,7 +101,7 @@ Read the task title and description, then:
    | Tasks exist but all have empty `description` fields | → Invoke `rdc:plan` on this epic. Tasks without descriptions cannot be safely dispatched. |
    | Plan doc missing `## Checklist Decomposition Matrix` | → Invoke `rdc:plan` on this epic. Do NOT dispatch agents. |
    | Plan doc missing `## Checklist Quality Gate` with `verdict: PASS` | → Invoke `rdc:plan` on this epic. Do NOT dispatch agents. |
-   | Any implementation task lacks `decomp-*` checklist items | → Invoke `rdc:plan` on this epic. Coarse checklists cannot be safely dispatched. |
+   | Any implementation task lacks `decomp-*` items, has < 10 attested rows, or leaves a declared surface (screen/api/db/tool) uncovered | → Invoke `rdc:plan` on this epic. Coarse/under-decomposed checklists cannot be safely dispatched. |
    | Any `decomp-*` item lacks route/file, action, expected result, or evidence artifact | → Invoke `rdc:plan` on this epic. Do NOT dispatch agents. |
    | Tasks exist and have descriptions | → Continue with build. |
 
@@ -144,6 +144,10 @@ Read the task title and description, then:
    - `verdict: PASS`
 
    Required task checklist shape:
+   - Every implementation work item has >= 10 attested `decomp-*`/`test-*` rows and meets the
+     per-surface completeness floors from rdc:plan (each declared surface covered; a multi-surface
+     WP carries the SUM of its surface floors, typically 12-20). A flat 5-6-row checklist for a
+     feature WP is REJECTED — reopen the epic to rdc:plan for full surface-area decomposition.
    - Every implementation work item has at least one `decomp-*` checklist row and one `test-*` checklist row.
    - Every `decomp-*` row names a concrete route or file path.
    - Every `decomp-*` row names one user/agent action.
@@ -163,6 +167,11 @@ Read the task title and description, then:
    - DB/migration task: at least schema object, relationship/guard, policy/permission, seed/fixture or backfill, and smoke query.
    - Editor/sidebar/CLI workflow: at least start, attach/open, enqueue action, observe result, timeout/error, and live refresh where applicable.
 
+   HARD FLOOR (mirrors rdc:plan): every implementation task carries >= 10 attested rows; a
+   multi-surface WP carries the SUM of its per-surface floors (typically 12-20). A flat 5-6-row
+   feature checklist, or any declared surface (screen/api/db/tool) left uncovered, is a REJECT —
+   reopen to rdc:plan. Every row must name its surface + one verification artifact (attested).
+
    ### ⛔ Deliverable / acceptance check-off table — show BEFORE any implementation
    Before dispatching the first wave, render a deliverable/acceptance table and
    keep it visible through the build (lesson 2026-06-16-build-poor-goal-execution-mdk-brain:
@@ -506,7 +515,7 @@ Read the task title and description, then:
     - Starts the dev server and probes every modified route (expects HTTP 200, not 500)
     - Runs vitest for every touched package
     - **Verifies checklist decomposition quality per work item before functional validation:**
-      - Every implementation work item has at least one `decomp-*` item and one `test-*` item
+      - Every implementation work item has >= 10 attested `decomp-*`/`test-*` items, meets the per-surface completeness floors (each declared surface covered), and no feature WP ships a 5-6-row checklist
       - Every `decomp-*` item includes route/file, action, expected result, and evidence artifact
       - Any unchecked `decomp-*` item with `required: true` = work item CANNOT be set to `done`
       - Any coarse or non-falsifiable `decomp-*` item = reopen to `todo` with the specific failure

package/skills/edit/SKILL.md

@@ -34,19 +34,56 @@ description: "Usage `rdc:edit <site|brand|route|file>` — open the local websit
 - `test`, `studio_test`, and `studio-test` resolve to `brandSlug=test` and `appSlug=studio_test`.
 - If the target is a local file or route and the brand/app is unclear, ask one concise question.
 
-### 3. Start or reuse the editor host
-- The editor host lives at `http://localhost:3015`.
-- Launch the host if needed:
+Resolve the **target dev server** (package + port) so the preview iframe has
+something live to load. Read the brand app's `package.json` `name` and its
+`dev` script port — never hard-code a stale port:
+
+| Target | App dir | Package (`name`) | Dev port | `targetUrl` |
+|--------|---------|------------------|----------|-------------|
+| `prt` / `prtrust.fund` | `apps/prt` | `@regen/prt-portal` | `3006` | `http://localhost:3006` |
+| `test` / `studio_test` | (bundled) | — (editor host serves it) | `3015` | auto (`/editor/local-test-target`) |
+
+For any other brand, derive the package name and port by reading
+`apps/<app>/package.json` (`name` field and the `--port` in the `dev` script).
+`brandSlug=test` needs no target server — the editor host serves the fixture
+on its own origin.
+
+### 3. Start or reuse BOTH servers (edit starts everything)
+`rdc:edit` must bring up everything the preview needs — the editor host AND the
+target brand's dev server. Start-or-reuse each: probe the port first, only
+launch if it is dead.
+
+**3a. Editor host (`http://localhost:3015`)**
+- Probe: `curl -s -o /dev/null -w "%{http_code}" http://localhost:3015/` — any
+  non-`000` means it is already up; reuse it.
+- Launch only if down (background, do not block the session):
   ```powershell
   pnpm --filter @regen/editor-host dev
   ```
-- Open the editor page for the resolved target:
+
+**3b. Target brand dev server (skip for `brandSlug=test`)**
+- Probe the resolved dev port (e.g. `http://localhost:3006/`). Non-`000` =
+  already running; reuse it. `EADDRINUSE` on launch also means reuse — not an error.
+- Launch only if down (background), then health-wait on the port before opening:
+  ```powershell
+  pnpm --filter <package> dev
+  ```
+  Bounded health-wait only (no `for`/`seq`/`sleep` polling loops):
+  ```bash
+  until curl -s -o /dev/null http://localhost:<port>/; do sleep 2; done
+  ```
+- Open the editor page for the resolved target once BOTH report a live code:
   ```txt
-  http://localhost:3015/editor/local/<brandSlug>?targetUrl=<targetUrl>
+  http://localhost:3015/editor/local/<brandSlug>?appSlug=<appSlug>&targetUrl=<targetUrl>
   ```
 
 ### 4. Open the page
 - Normal use: open the URL in the browser and confirm the editor loaded.
+  Open via PowerShell `Start-Process`, NOT `cmd start` — `cmd` treats the `&`
+  between query params as a command separator and truncates the URL:
+  ```powershell
+  Start-Process 'http://localhost:3015/editor/local/<brandSlug>?appSlug=<appSlug>&targetUrl=<targetUrl>'
+  ```
 - `RDC_TEST=1`: do not force a foreground browser action; report the exact editor URL and whether the target was resolved.
 
 ### 5. Report the result

package/skills/plan/SKILL.md

@@ -126,12 +126,36 @@ description: "Usage `rdc:plan <topic>` — No epic exists and you need architect
    - Visual work: each named screenshot and visual checkpoint gets its own row.
    - Cross-system workflows: each handoff boundary gets its own row.
 
-   Minimum row-count heuristics:
-   - UI route: at least 4 rows.
-   - CRUD surface: at least 6 rows.
-   - API route: at least 3 rows.
-   - DB work package: at least 5 rows.
-   - Local editor/sidebar workflow: at least 5 rows.
+   Per-surface completeness floors — ATTESTED BY SURFACE AREA (not a flat minimum):
+   A checklist MUST carry at minimum one attested `decomp-*` row for EACH applicable item
+   below. This is a COMPLETENESS requirement measured against the surfaces the WP touches —
+   decompose the whole surface area; do not stop at a token few rows.
+   - UI screen (per screen the WP renders): a row for EACH applicable state — loaded, empty,
+     loading, error, detail — plus mobile and auth-gate where applicable. Floor: >= 6 rows PER screen.
+   - UI actions (per interactive surface): one row for EACH action that exists — open, search,
+     filter, select, create, edit, duplicate, save, assign, activate, archive, delete, import,
+     apply, cancel.
+   - API route (per route): success-read, success-write, validation-failure (4xx),
+     unauthorized/forbidden, and side-effect verification. Floor: >= 4 rows per route.
+   - DB / migration: ONE row per database object — per table, per non-trivial column-group, per
+     index, per RLS policy, per trigger, per function/RPC, per FK/guard — plus rollback/smoke and
+     type-exposure. A 10-table WP therefore carries ~15-20 rows, not 5.
+   - CLI / sidebar / local tool: start, attach, enqueue, poll, reply, timeout/not-found,
+     live-refresh. Floor: >= 6 rows.
+   - Visual: one row per named screenshot/checkpoint. Cross-system: one row per handoff boundary.
+
+   HARD FLOORS — reject the checklist (do NOT create work items) if any is violated:
+   - Every implementation task carries >= 10 attested `decomp-*`/`test-*` rows.
+   - A MULTI-SURFACE WP (two or more of screen/api/db/tool) carries the SUM of its per-surface
+     floors — typically 12-20 rows. A flat 5-6-row checklist for a real feature WP is a REJECT,
+     not a pass.
+   - COVERAGE: the checklist covers EVERY surface the WP declares. A WP touching screen+api+db
+     that lists only db rows FAILS the coverage gate.
+   - ATTESTATION: every row names its surface + ONE concrete verification artifact (test name,
+     route probe, Playwright screenshot, SQL query, migration proof, CLI transcript). A row with
+     no attestation artifact is a REJECT.
+   - If a WP genuinely has < 10 observable behaviors, SPLIT it or justify the low count explicitly
+     in the Quality Gate `deferred:` note — never silently ship a thin checklist.
 
    Reject these checklist items as too coarse:
    - "theme management works"
@@ -146,11 +170,18 @@ description: "Usage `rdc:plan <topic>` — No epic exists and you need architect
    - `decomp-api-import-validation: POST /api/tools/theme-import rejects missing source URL with 400 JSON error; evidence: route probe`
 
    Add a `## Checklist Quality Gate` section with:
-   - `verdict: PASS` only when every row passes the rubric.
-   - `failures:` list any coarse, missing, duplicate, or unverifiable rows.
-   - `deferred:` list any explicit out-of-scope rows.
-
-   Do not create build-ready work items unless this gate is `PASS`.
+   - `verdict: PASS` only when EVERY row passes the rubric AND every WP meets the per-surface
+     completeness floors above (each declared surface covered; >= 10 attested rows; multi-surface =
+     sum of surface floors) AND every row carries a verification artifact.
+   - `per_wp_row_counts:` list each WP and its attested row count so a reviewer sees at a glance
+     that no feature WP is under-decomposed (no 5-6-row feature WP).
+   - `coverage:` per WP, list the surfaces it declares and confirm each is covered by >= its floor.
+   - `failures:` list any coarse, under-decomposed, uncovered-surface, missing, duplicate, or
+     unattested rows.
+   - `deferred:` list any explicit out-of-scope rows (with the reason a low count is justified).
+
+   Do not create build-ready work items unless this gate is `PASS`. A `PASS` with any feature WP
+   under 10 attested rows, or any declared surface left uncovered, is invalid.
 
 5. **Write a test plan for each work package (MANDATORY):**
 

package/skills/review/SKILL.md

@@ -110,7 +110,7 @@ description: "Usage `rdc:review [--unattended]` — Post-build quality gate: tsc
    After any fixes land, run the verify gate on every touched package. See `guides/agents/verify.md`.
    Apply `guides/engineering-behavior.md` while reviewing: flag unnecessary abstraction, drive-by refactors, missing assumptions, hidden uncertainty, out-of-scope edits, and prose-only verification.
    **Iron Law: no CLEAN verdict without fresh evidence.** Quote the checklist decomposition verdict, vitest output, and tsc output in the report.
-   The verify agent must reject any work item that lacks passed `decomp-*` checklist rows or whose rows are too coarse to prove one observable behavior at a time.
+   The verify agent must reject any work item that lacks passed `decomp-*` checklist rows, whose rows are too coarse to prove one observable behavior at a time, OR whose checklist falls below the per-surface completeness floor (a feature WP with 5-6 rows where its surfaces demand 12-20 attested rows is a REJECT).
    If verify fails → do NOT emit CLEAN. Loop back, fix, re-run verify.
 
 10. **Fix issues found:**