@lifeaitools/rdc-skills 0.35.22 → 0.35.24

package/scripts/test-guide-validator.mjs

@@ -32,30 +32,11 @@ const REPO_ROOT = resolve(__dirname, "..");
 // ─── Inline validator (mirrors self-test.mjs logic) ────────────────────────
 import { readFileSync, existsSync, readdirSync, statSync } from "node:fs";
 
-const GUIDE_BANNED_TERMS = [
-  "@masonator/coolify-mcp",
-  "@masonator",
-  "coolify-mcp",
-  "@regen/brand-studio",
-  "brand-studio",
-];
-
-const GUIDE_NEGATION_PATTERNS = [
-  /\bdo not\b/i,
-  /\bnever\b/i,
-  /\bno such\b/i,
-  /\bdoes not exist\b/i,
-  /\bbanned\b/i,
-  /\bnot reference\b/i,
-  /\bnot use\b/i,
-  /\bavoid\b/i,
-  /\bremoved\b/i,
-  /\bdeprecated\b/i,
-  // Markdown table row showing a WRONG→CORRECT mapping (naming-corrections.md pattern)
-  /^\|[^|]*WRONG[^|]*\|/i,
-  // A table row where the term is in the WRONG column (first data column after the | WRONG | header)
-  /^\|\s*(Brand Studio|brand-studio|@regen\/brand-studio|@masonator[^ |]*|coolify-mcp)[^|]*\|\s*\*\*/,
-];
+// Rules imported from the single home — see scripts/lib/guide-content-rules.mjs for why.
+import { GUIDE_BANNED_TERMS, GUIDE_NEGATION_PATTERNS } from "./lib/guide-content-rules.mjs";
+
+
+
 
 const KNOWN_CLAUTH_KEYS = new Set([
   "coolify-api",
@@ -184,6 +165,26 @@ const cleanFindings = scanDir(GOOD_DIR, "fixtures");
 const cleanErrors = cleanFindings.filter((f) => f.level === "error");
 assert("scanDir on clean fixture dir returns 0 errors", cleanErrors.length === 0, `got ${cleanErrors.length}`);
 
+// ─── Test 5: a corrections-table row is a correction, under ANY scope prefix ───
+// Regression, 2026-09-16: the exemption listed `@regen/brand-studio`; after the
+// scope rename, `| @lifeai/brand-studio | **@lifeai/studio** |` in
+// naming-corrections.md — a row declaring that name WRONG — failed strict runs.
+console.log("\nTest 5: corrections-table rows are negations regardless of scope");
+const { isNegatedBannedLine } = await import("./lib/guide-content-rules.mjs");
+for (const row of [
+  "| brand-studio | **studio** | 2026-04-24 |",
+  "| @regen/brand-studio | **@regen/studio** | 2026-04-24 |",
+  "| @lifeai/brand-studio | **@lifeai/studio** | 2026-04-24 |",
+  "| @some-future-scope/brand-studio | **@some-future-scope/studio** | 2027-01-01 |",
+]) {
+  assert(`negated: ${row}`, isNegatedBannedLine(row));
+}
+// The structural exemption must not swallow a real instruction.
+assert("NOT negated: an instruction that merely contains the term",
+  !isNegatedBannedLine("Install @lifeai/brand-studio and import it in the app."));
+assert("NOT negated: a table row whose correction cell is not bold",
+  !isNegatedBannedLine("| package | @lifeai/brand-studio | use it |"));
+
 // ─── Summary ─────────────────────────────────────────────────────────────────
 console.log(`\n${"─".repeat(60)}`);
 console.log(`guide-validator tests: ${passed} passed, ${failed} failed`);

package/skills/behavior-audit/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Behavior Audit"
-  short_description: "Audit Claude and Codex behavior against shared rules."
-  default_prompt: "Run a behavior audit for the last seven days and write the evidence bundle to a report directory."
+interface:
+  display_name: "Behavior Audit"
+  short_description: "Audit Claude and Codex behavior against shared rules."
+  default_prompt: "Run a behavior audit for the last seven days and write the evidence bundle to a report directory."

package/skills/build/SKILL.md

@@ -6,6 +6,11 @@ description: rdc:build (epic-id) - [--no-review] — execute a planned epic, the
 > **⚠️ 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.
+> A decision that changes what happens next — a skipped orchestrator, a substituted branch, a held task — gets ONE plain sentence, never hidden behind a checkbox.
+
+> **⚠️ WORK CONTRACT (READ SECOND):** `guides/work-contract.md`
+> Declare the build before the first change: `rdc-work start --type build --work-item <uuid> --goal … --row "<step> :: <proof>"`.
+> **This skill is written in regen-root's terms.** `develop`, `{PROJECT_ROOT}/.rdc/guides`, `scripts/land.mjs` and `runOrchestrator()` are regen-root facts, not universal ones — for any other target apply that guide's substitution table to every occurrence below, using the target the contract resolved (`rdc-work status`).
 
 > **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag.
 
@@ -26,17 +31,19 @@ description: rdc:build (epic-id) - [--no-review] — execute a planned epic, the
 
 ## Agent Types & Guide Files
 
-Every dispatched agent MUST read two files before starting — in this order:
-1. `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` — credentials, git rules, completion report format
-   (fallback: `.rdc/guides/agent-bootstrap.md` relative to cwd if `{PROJECT_ROOT}` is not substituted)
-2. `{PROJECT_ROOT}/.rdc/guides/engineering-behavior.md` — assumptions, minimal changes, surgical scope, verification evidence
-   (fallback: `.rdc/guides/engineering-behavior.md` relative to cwd if `{PROJECT_ROOT}` is not substituted)
-3. `{PROJECT_ROOT}/.rdc/guides/<type>.md` — role-specific guide
-   (fallback: `.rdc/guides/<type>.md` relative to cwd if `{PROJECT_ROOT}` is not substituted)
+Every dispatched agent MUST read these guides before starting — in this order:
+1. `agent-bootstrap.md` — credentials, git rules, completion report format
+2. `engineering-behavior.md` — assumptions, minimal changes, surgical scope, verification evidence
+3. `<type>.md` — role-specific guide
+
+**Resolve the guides directory from the contract, never from cwd.** `rdc-work status --json` → `contract.target.guides_dir`:
+- present → read `<guides_dir>/<name>.md` (regen-root: `<root>/.rdc/guides`)
+- absent → read the guides shipped with rdc-skills (`guides/<name>.md` in the installed package)
+- **never** fall back to a cwd-relative `.rdc/guides`: when the session was started in one repository and builds another, that path silently loads the wrong repository's rules. That fallback is what imported regen-root's git and deploy assumptions into a CDE build (Codex, 2026-09-16).
 
-Include both lines in every agent prompt:
+Include the resolved paths in every agent prompt:
 ```
-"Read {PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md first (fallback: .rdc/guides/agent-bootstrap.md), then {PROJECT_ROOT}/.rdc/guides/engineering-behavior.md (fallback: .rdc/guides/engineering-behavior.md), then {PROJECT_ROOT}/.rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md) before starting."
+"Read <guides>/agent-bootstrap.md first, then <guides>/engineering-behavior.md, then <guides>/<type>.md before starting. Your target is <root>; its integration branch is <integration>."
 ```
 
 | Agent Type | Guide File | When to dispatch |
@@ -80,10 +87,23 @@ Read the task title and description, then:
    - Ordinary rows (`design_review_required = false`) may be considered for dispatch regardless of a legacy state. Only an explicitly opted-in row requires `automatic_approved` or `human_approved`.
    - For an explicitly opted-in row in `pending`, `needs_human`, or `rejected`, write an `admission_refocus` receipt, keep the child blocked, and route it to the reviewer/planner. **Do not dispatch it, retry it, or call the epic complete.**
 
-1a. **Run the durable CodeFlow supervisor before each wave and after every gate-changing action.**
-   - Invoke `runOrchestrator()` with the project manifest, `SupabaseStateStore`, and the real phase dispatcher. It is the sole authority for resuming/refocusing a phase DAG; do not reconstruct waves by hand from task prose.
+1a. **Run the durable CodeFlow supervisor — where the target has one.**
+
+   **First, decide whether it applies.** The orchestrator needs a phase manifest, and today exactly one exists: `corpus/_shared/build/phase-manifest.json` inside **regen-root** (read by `packages/codeflow/src/orchestrator`). Check the contract's target root:
+
+   | target root contains `corpus/_shared/build/phase-manifest.json` | do this |
+   |---|---|
+   | **yes** (regen-root) | the orchestrator is REQUIRED, exactly as below |
+   | **no** (lifeai-env, rdc-cde, rdc-skills, clauth, …) | it does not apply. Resolve waves from the work items' dependencies (step 6), state it in one sentence — `orchestrator: not applicable, <root> has no phase manifest` — and continue. **This is not a BLOCKED condition.** |
+
+   This used to say "if the project lacks a real dispatcher/manifest, report BLOCKED" while naming a function and no invocation. Every non-regen-root build therefore either stopped or became an infrastructure investigation into how to start work (Codex, building CDE, 2026-09-16). An orchestrator that exists in one repository cannot be a precondition for building every repository.
+
+   When it applies:
+   - Invoke `runOrchestrator()` with the phase manifest, `SupabaseStateStore`, and the real phase dispatcher. It is the sole authority for resuming/refocusing a phase DAG; do not reconstruct waves by hand from task prose.
    - A returned `admission_refocus` or `pipeline_blocked` is a durable hold, not a failed attempt to work around. Preserve its task state and route an explicitly requested Design Review or validator closure.
-   - Only a returned `pipeline_complete` whose phase tasks are durably `done` permits an epic completion claim. If the project lacks a real dispatcher/manifest, report `BLOCKED: CodeFlow supervisor entrypoint unavailable` rather than emulating completion.
+   - Only a returned `pipeline_complete` whose phase tasks are durably `done` permits an epic completion claim. If the manifest exists but the orchestrator itself cannot run, THAT is `BLOCKED: CodeFlow supervisor entrypoint unavailable` — report it rather than emulating completion.
+
+   Either way, the epic's completion claim also requires the session's work contract to pass (`rdc-work check`).
 
    **Read the epic's `plan_ref`, `spec_ref`, `architecture_ref`, and `scoping_statement`** (columns on the epic row). `scoping_statement` bounds what this build may touch. If `architecture_ref` is set, this epic crosses an architectural boundary — read that doc now, before classifying or dispatching any task, and carry it into every agent prompt below.
 
@@ -103,6 +123,15 @@ Read the task title and description, then:
      ```
      This is an atomic Supabase write. A concurrent session that loads the same epic after this point will see `in_progress` and abort. **Do this before any classification, planning, or agent dispatch.**
 
+   **Declare the build — immediately after claiming, before any change** (`guides/work-contract.md`):
+   ```bash
+   node "$LIFEAI_ENV/bin/rdc-work.mjs" start --type build --work-item <epic-or-task-uuid> \
+     --goal "<what this epic delivers, in one sentence>" \
+     --row "<deliverable> :: <read-only command that exits 0 when it is true>"   # one per deliverable
+   ```
+   A proof observes and can fail: `rdc-work` refuses one that commits, pushes, lands, publishes, deploys or writes a file, and one that cannot fail (`true`, `echo`). Prove a landing by observing it (`git merge-base --is-ancestor HEAD origin/<integration>`). Run the gate's printed `rdc-work` lines as printed — they carry `--session`.
+   The printed `target:` line is authoritative for the rest of this skill: its **integration** branch replaces every `develop` below, its **ship** route replaces `scripts/land.mjs`. Without a contract the start gate refuses the first write and the first commit.
+
    **Pre-flight gate — run after claiming:**
 
    | Condition | Action |
@@ -111,7 +140,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-*` 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 implementation task lacks `decomp-*` items, leaves a declared surface (screen/api/db/tool) uncovered, or has a deliverable with no row that can fail | → 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. |
    | Epic has `architecture_ref` set and any implementation task's checklist lacks a required `architecture-fidelity-*` row | → Invoke `rdc:plan` on this epic. That task will hard-fail the exit gate at close regardless of build quality — catch it here, not after a wasted agent run. |
    | Tasks exist and have descriptions | → Continue with build. |
@@ -236,10 +265,11 @@ 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 covers EVERY surface it declares (screen / api / db / tool)
+     and every handoff, with one row per deliverable that can pass or fail on its own. Coverage
+     is the rule; **there is no minimum row count** (`guides/work-contract.md` § Rows). The
+     per-surface lists in rdc:plan are a decomposition checklist for finding deliverables, not a
+     quota to fill.
    - 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.
@@ -259,10 +289,15 @@ 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).
+   HARD GATE (mirrors rdc:plan): any declared surface (screen/api/db/tool) left uncovered, any
+   deliverable with no row that can fail, or any row without its surface + one verification
+   artifact, is a REJECT — reopen to rdc:plan.
+
+   A numeric floor used to sit here ("every task carries >= 10 attested rows; a multi-surface WP
+   carries the SUM of its per-surface floors, typically 12-20"). Removed 2026-09-16: it measured
+   paperwork, not coverage. Building a small CDE increment against it produced 91 checks before a
+   runnable UI existed (Codex). A thin checklist is caught by COVERAGE — an uncovered surface — not
+   by counting; a padded one passed the count and proved nothing extra.
 
    ### ⛔ Deliverable / acceptance check-off table — show BEFORE any implementation
    Before dispatching the first wave, render a deliverable/acceptance table and
@@ -309,7 +344,7 @@ Read the task title and description, then:
     The agent must complete every item on this checklist and return it checked off in AGENT_COMPLETE.
     A checklist with unchecked items = incomplete work. Do not proceed to next wave with unchecked items.
 
-6. **Use the supervisor-resolved waves** — parallelize only phases returned by `runOrchestrator()` after its durable admission check:
+6. **Use the supervisor-resolved waves** — where the orchestrator applies (§1a), parallelize only phases returned by `runOrchestrator()` after its durable admission check; where it does not, derive the same three waves from the work items' declared dependencies:
    - Wave 1: independent tasks (different packages/files)
    - Wave 2: tasks that depend on Wave 1 outputs
    - Wave 3: integration tasks
@@ -326,6 +361,14 @@ Read the task title and description, then:
    worktree. A non-isolated dispatched agent is read-only and may research,
    review, or validate merged source; it may not write.
 
+   **`Agent()`, `isolation: "worktree"` and `max_turns` are Claude Code's dispatch
+   interface.** The requirement is engine-neutral — one leased worktree per writer,
+   read-only for everyone else — but those argument names are not. On an engine
+   whose native dispatch does not accept them (Codex), do not stop to ask:
+   create the writer's worktree yourself from the contract's integration branch
+   (`guides/work-contract.md` § Dispatching writers) and start the writer inside
+   it. The worktree is the requirement; the parameter was only one way to get it.
+
    ### ⛔ Dispatch mode — writers are always isolated
    Isolation is an ownership boundary, not a concurrency optimization. The
    supervisor may implement directly as the sole writer, but once work is
@@ -381,15 +424,24 @@ Read the task title and description, then:
    Without `max_turns: 70`, agents hit the default turn cap mid-task and stop.
    `isolation: "worktree"` gives each agent its own git worktree and branch — eliminates push race conditions and index lock contention when multiple agents commit in parallel. The supervisor merges worktree branches after each wave (Step 9).
 
-   ### ✅ PREVENTION FIRST — create worktrees fresh off origin/develop (kills stale-base by construction)
+   ### ✅ PREVENTION FIRST — create worktrees fresh off the INTEGRATION branch (kills stale-base by construction)
+
+   > **`develop` in this section and the HARD GATE below means the contract's
+   > integration branch** (`rdc-work status` → `integration <branch>`, from
+   > `projects.json`). It is `develop` for regen-root and rdc-harness, `main` for
+   > lifeai-env, clauth and rdc-cde, `master` for rdc-skills. Running these commands
+   > literally against a repository with no `origin/develop` fails — which is what a
+   > CDE build hit (Codex, 2026-09-16). Never infer it from `origin/HEAD`: regen-root's
+   > `origin/HEAD` is `main`, and its integration branch is `develop`.
+
    The repeated stale-base failures below come from creating worktrees off a
    local/old ref. Eliminate the failure mode at the source: ALWAYS create agent
-   worktrees with a fresh fetch + `origin/develop` base, e.g.
-   `git fetch origin develop && git worktree add <dir> -b <branch> origin/develop`
-   — or use the canonical launcher `node scripts/wt.mjs add <name>`, which does
-   exactly that. A worktree cut from `origin/develop` HEAD **cannot** be stale.
+   worktrees with a fresh fetch + integration-branch base, e.g.
+   `git fetch origin <integration> && git worktree add <dir> -b <branch> origin/<integration>`
+   — or, in regen-root, the canonical launcher `node scripts/wt.mjs add <name>`, which does
+   exactly that. A worktree cut from `origin/<integration>` HEAD **cannot** be stale.
    The HARD GATE below remains as the blocking backstop (detection), but
-   construction-from-`origin/develop` is the primary defense.
+   construction-from-`origin/<integration>` is the primary defense.
 
    ### ⛔ HARD GATE — Worktree base MUST equal develop HEAD (blocking, not advisory)
    The worktree-isolation harness has shipped worktrees pinned to a STALE base
@@ -646,7 +698,7 @@ Read the task title and description, then:
       state, persisted outputs, and fixture cleanup on the deploy-equivalent
       runtime; an absent harness is a hard rejection.
     - **Verifies checklist decomposition quality per work item before functional validation:**
-      - 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 implementation work item covers every surface it declares, with one row per deliverable that can fail on its own — coverage, not a row count (`guides/work-contract.md` § Rows)
       - 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/deploy/SKILL.md

@@ -7,6 +7,13 @@ description: rdc:deploy (slug, [action]) — run one command; exit 0 means shipp
 > One command, then one line: the URL on exit 0, or the `DEPLOY-FAILED` block on
 > non-zero. No tool-call narration, no raw JSON dumps, no progress commentary.
 
+> **Sandbox contract:** This skill honors `RDC_TEST=1` per
+> `.rdc/guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Under the flag
+> the run stays read-only — registry read plus health probe — and every
+> mutating step short-circuits: no deploy triggered, no Cloudflare cache purge,
+> no DNS write, no promote to main. `skills/tests/rdc-deploy.test.json` asserts
+> exactly those four absences, so this is an enforced contract, not a promise.
+
 # rdc:deploy — run the program, read the exit code
 
 **This skill is not a procedure. It is one command.**

package/skills/edit/SKILL.md

@@ -17,8 +17,10 @@ description: rdc:edit (target) — open the local website editor for a target
 **This skill is the designated handler `rdc-harness` dispatches to.**
 `packages/work/src/editors.mjs`'s `BY_CLASS` table maps `site-html`/`site-ts`
 product classes to editor id `'rdc:edit'` — when an agent calls
-`npx --package=@lifeai/rdc-harness rdc-harness edit <slug>` (the published
-package; see `guides/agent-bootstrap.md` for registry setup) against a website
+`npx -y --package=@lifeai/rdc-harness rdc-harness edit <slug>` (published on
+GitHub Packages — needs `@lifeai:registry=https://npm.pkg.github.com` in
+`.npmrc`; an `npm` 404 means that mapping is missing. Full setup:
+`{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`) against a website
 target, its receipt names `editorId: 'rdc:edit'` and an `editableBoundary`.
 This skill IS that handler: resolve the same target, launch/reuse the editor
 host, use the harness's `editableBoundary` as the save boundary if the call

package/skills/fixit/SKILL.md

@@ -56,6 +56,22 @@ SELECT insert_work_item(
 
 Note the returned `id`.
 
+### 2a. Declare the fix and its proof (before touching any code)
+
+A fixit is a todo-tier contract (`guides/work-contract.md`). Every row carries the
+command that proves it; the start gate refuses the first edit without one.
+
+```bash
+node "$LIFEAI_ENV/bin/rdc-work.mjs" start --type fixit --goal "<the fix, as an outcome>" \
+  --row "<the defect is gone> :: <command that exits 0 only when it is>" \
+  --row "shipped :: git fetch -q origin && git merge-base --is-ancestor HEAD origin/<integration>"
+```
+
+Use the printed `target:` line for the rest of this skill: `{development-branch}`
+is its **integration** branch, and `scripts/land.mjs` is its **ship** route —
+they differ per repository. A proof observes and can fail — `rdc-work` refuses one
+that changes anything or cannot fail. Finish with `rdc-work verify --all`; Stop checks it.
+
 ### 3. Write the fixit session marker
 
 Write to `{USER_HOME}/.claude/fixit.marker`:

package/skills/open/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: open
-description: rdc:open ([slug]) — orient before working; answers where you are and what the target is from the registry, then names the harness shape
+description: rdc:open ([slug]) - [--for maintenance|fixit|edit|hotfix|build|refactor] — orient, then declare the work and how each step is proved before changing anything
 ---
 
 > **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
@@ -12,12 +12,14 @@ description: rdc:open ([slug]) — orient before working; answers where you are
 ## Run the script. Do not re-derive this by hand.
 
 `rdc-harness` ships as a published package — `@lifeai/rdc-harness` on GitHub
-Packages, not npmjs (see `guides/agent-bootstrap.md` for the registry
-precondition). Invoke it through the installed `bin`, never a
-machine-specific checkout path:
+Packages, not npmjs. That needs `@lifeai:registry=https://npm.pkg.github.com`
+in `.npmrc`; if `npm` 404s on the package, that mapping is what is missing
+(auth token: the clauth `github` PAT — full setup in
+`.rdc/guides/agent-bootstrap.md`). Invoke it through the installed `bin`,
+never a machine-specific checkout path:
 
 ```bash
-npx --package=@lifeai/rdc-harness rdc-harness open <slug>
+npx -y --package=@lifeai/rdc-harness rdc-harness open <slug>
 ```
 
 Only if you are actively developing the harness itself (working ON
@@ -143,9 +145,10 @@ Downstream verbs re-resolve from the registry by slug.
 
 ## Steps
 
-0. **Call `rdc-harness open <slug>`.** Steps 1–2 are what it returns, not a
-   procedure to perform. Only hand-resolve if the harness is genuinely
-   unavailable, and say so explicitly when you do.
+0. **Call `npx -y --package=@lifeai/rdc-harness rdc-harness open <slug>`.**
+   Steps 1–2 are what it returns, not a procedure to perform. Only
+   hand-resolve if the harness is genuinely unavailable, and say so
+   explicitly when you do.
 1. **Position.** Read `sourceBoundary` and `boundaryNote` from the result — they
    already account for pooled repos and lanes. Relative paths from there are
    correct by construction; a hardcoded `C:/Dev/regen-root/...` from a lane
@@ -170,8 +173,34 @@ Downstream verbs re-resolve from the registry by slug.
    this contract. If the contract is absent, record it as a build requirement;
    do not silently substitute a manual visual assertion.
 
-5. **State the ground in one line** and start. Do not re-derive it later in the
-   turn.
+5. **State the ground in one line.** Do not re-derive it later in the turn.
+
+6. **Declare the work — before the first change** (`guides/work-contract.md`).
+   `rdc:open <project> --for <type>` ends here. The type picks the tier:
+
+   | `--for` | tier | what it adds |
+   |---|---|---|
+   | `maintenance`, `hotfix`, `fixit`, `edit` | todo | rows only |
+   | `build`, `refactor`, `overnight` | work-item | `--work-item <uuid>` |
+
+   ```bash
+   node "$LIFEAI_ENV/bin/rdc-work.mjs" start --type <type> --goal "<what done means>" \
+     --row "<step> :: <read-only command that exits 0 when the step is true>"   # one per deliverable
+   ```
+
+   Each row carries the command that proves it; a row passes only when that
+   command ran and exited 0. A proof observes and can fail — one that changes
+   anything, or cannot fail, is refused. On every tier, a work item this session
+   has claimed holds Stop until its database DoD closes. The printed `target:` line is the resolved ship
+   contract — integration branch and ship route — for this target, so no later
+   step assumes regen-root's `develop` or `scripts/land.mjs`. Where the type is
+   also a flow state (`maintenance`, `hotfix`, `build`, `refactor`, `overnight`)
+   the FSM flow is set in the same call.
+
+   Operator, 2026-09-14: *"rdc open website-x for maintenance and it says fsm to
+   be todo list"*. That is this step. Skip it only for a pure conversation turn —
+   the start gate refuses a tracked write or a commit without it anyway, and
+   prints this exact command.
 
 ## Checklist
 
@@ -182,12 +211,16 @@ Downstream verbs re-resolve from the registry by slug.
 [ ] harness shape named for the target's class
 [ ] UI target: project-owned Playwright command/config identified (or absence recorded)
 [ ] blockers noted — behind upstream, dirty tree, service down
+[ ] work declared — rdc-work start, every row with a proof command (or: conversation only)
 ```
 
 ## 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.
+- `guides/work-contract.md` — the contract this skill opens: rows, tiers, proving,
+  staleness, and what Stop checks.
+- `rdc:flow` — declares what KIND of work this is. `rdc-work start --type` sets it
+  for you when the type is a flow state; use `rdc:flow` directly for `plan`,
+  `design`, `collab`.
 - `rdc:status` — open epics and queue. That is the work; this is the ground.
 - `rdc:deploy` — consumes the source key this skill resolves.
 - `$LIFEAI_ENV/docs/GATES-GUARDS-DENIES.md` — when a guard stops you, that names

package/skills/overnight/SKILL.md

@@ -11,6 +11,8 @@ description: rdc:overnight ([scope]) — drain the work queue unattended, end to
 
 > **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag.
 
+> **⚠️ WORK CONTRACT:** `guides/work-contract.md`. Each epic this run builds is declared through `rdc:build`'s contract step, and its Stop is that contract's checklist. This skill names regen-root's `develop` and `scripts/land.mjs` throughout; for any other target, apply that guide's substitution table (integration branch, ship route, orchestrator applicability) using the target each contract resolved.
+
 
 # rdc:overnight — Overnight Build Supervisor
 
@@ -140,7 +142,7 @@ Agents receive the relevant guide file from `.rdc/guides/` (fallback: `.rdc/guid
 
 After each wave: check `BUILD_STATUS`. If `escalated: true`, log the escalation
 in the overnight doc and continue — don't stop the loop.
-After each wave and after every resumed epic, require the `runOrchestrator()` receipt from `rdc:build`. `admission_refocus` or `pipeline_blocked` means the epic is held for an explicitly requested Design Review or validator closure; log that state and do not hand-reconstruct a dispatch wave.
+After each wave and after every resumed epic, require the `runOrchestrator()` receipt from `rdc:build` **where the orchestrator applies** — the target contains `corpus/_shared/build/phase-manifest.json` (today: regen-root; see `rdc:build` §1a). Elsewhere, require the contract checklist (`rdc-work check`) instead; an absent orchestrator is not a hold. `admission_refocus` or `pipeline_blocked` means the epic is held for an explicitly requested Design Review or validator closure; log that state and do not hand-reconstruct a dispatch wave.
 
 **Mandatory code-review gate inherited from rdc:build (Step 9b).** Every wave inside `rdc:build` runs a `pr-review-toolkit:code-reviewer` pass before the next wave dispatches. Critical/high findings reopen the affected work items to `todo` and the next wave fixes them. Overnight does not skip or weaken this gate. If a wave's code-review escalates twice, advisor decides; otherwise the loop continues.
 

package/skills/plan/SKILL.md

@@ -168,18 +168,19 @@ description: rdc:plan (topic) — produce architecture, decisions and an epic wi
      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.
+   HARD GATES — reject the checklist (do NOT create work items) if any is violated:
    - 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.
+     that lists only db rows FAILS the coverage gate. The per-surface lists above are how you FIND
+     the deliverables; they are not a quota.
+   - FALSIFIABLE: every deliverable has a row that can fail on its own, and every row names its
+     surface + ONE concrete verification artifact (test name, route probe, Playwright screenshot,
+     SQL query, migration proof, CLI transcript) — expressible as a proof command
+     (`guides/work-contract.md`). A row with no attestation artifact is a REJECT.
+   - There is **no minimum row count.** A small WP with three real deliverables carries three
+     rows. Removed 2026-09-16: ">= 10 attested rows per task" and "a multi-surface WP carries the
+     SUM of its per-surface floors" measured paperwork, not coverage — a small CDE increment built
+     against them produced 91 checks before a runnable UI existed (Codex). A thin checklist is
+     caught by COVERAGE; a padded one passed the count and proved nothing extra.
 
    Reject these checklist items as too coarse:
    - "theme management works"
@@ -194,18 +195,15 @@ description: rdc:plan (topic) — produce architecture, decisions and an epic wi
    - `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 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.
+   - `verdict: PASS` only when EVERY row passes the rubric AND every WP covers each surface it
+     declares AND every deliverable has a row that can fail AND every row carries a verification
+     artifact.
+   - `coverage:` per WP, list the surfaces it declares and the row(s) that cover each one.
+   - `failures:` list any coarse, uncovered-surface, missing, duplicate, or unattested rows.
+   - `deferred:` list any explicit out-of-scope rows, each with its reason.
+
+   Do not create build-ready work items unless this gate is `PASS`. A `PASS` with any declared
+   surface left uncovered, or any deliverable with no row that can fail, is invalid.
 
 5. **Write a test plan for each work package (MANDATORY):**
 

package/skills/release/SKILL.md

@@ -94,11 +94,13 @@ monorepo subtree, not a standalone repo like this one),
 "Tests/self-test passed" through "Local install/update executed" rows safely:
 real `npm pack`, isolated-prefix install (never the real global store), real
 verify, and `--live` explicitly gating the actual publish. Where applicable,
-`npx --package=@lifeai/rdc-harness rdc-harness deploy <slug> [--live]` (the
-published package; see `guides/agent-bootstrap.md` for registry setup) can
-supply that evidence directly instead of hand-rolling the same
-pack/install/verify cycle. It does **not** replace version bump, tag or push
-— the harness CLI does none of those.
+`npx -y --package=@lifeai/rdc-harness rdc-harness deploy <slug> [--live]`
+(published on GitHub Packages — needs
+`@lifeai:registry=https://npm.pkg.github.com` in `.npmrc`; an `npm` 404 means
+that mapping is missing. Full setup:
+`{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`) can supply that evidence
+directly instead of hand-rolling the same pack/install/verify cycle. It does
+**not** replace version bump, tag or push — the harness CLI does none of those.
 
 ## Resolution Order