@lifeaitools/rdc-skills 0.35.7 → 0.35.8

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rdc",
-  "version": "0.35.7",
+  "version": "0.35.8",
   "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/clauth-plugin.json

@@ -1,7 +1,7 @@
 {
   "schema": "lifeai.plugin.v1",
   "id": "rdc-skills",
-  "version": "0.35.7",
+  "version": "0.35.8",
   "publisher": "LIFEAI",
   "core": false,
   "documentation": {

package/package.json

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

package/commands/prototype.md

@@ -1,144 +0,0 @@
----
-name: prototype
-description: rdc:prototype (description) — build a JSX/TSX mockup for visual review
----
-
-> **⚠️ 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.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:prototype — Prototype Builder
-
-## When to Use
-
-- Project lead wants to see a design before committing to implementation
-- A new component or page needs visual review before wiring to database
-- Testing a data layout or interaction pattern
-- Building a visual mockup for approval
-
-## What This Produces
-
-- JSX/TSX prototype file → `docs/source/<ComponentName>.jsx`
-- prototype_registry entry in database
-- design_context entries for key decisions
-
-## Prototype Rules
-
-1. **Self-contained** — no real database calls. Mock data arrays only.
-2. **Realistic data** — mock data must reflect actual schema field names
-3. **Full fidelity** — looks exactly like the final product should look
-4. **Annotated** — key design decisions commented at the top of the file
-5. **Handoff-ready** — includes the spec block at the bottom
-
-## Standard Mock Data Pattern
-
-Use realistic field names from the actual database schema:
-
-```tsx
-// Mock data — mirrors your_table
-const MOCK_DATA = [
-  {
-    id: "uuid-1",
-    slug: "example-slug",
-    name: "Example Name",
-    description: "...",
-    location_city: "City",
-    location_state: "State",
-    status: "active",
-    category: "example-category",
-    total_capital: 1000000,
-    total_area: 2400,
-    deploy_url: "https://...",
-    tags: ["tag1", "tag2"],
-    alignment: ["value1", "value2"],
-    web_visible: true,
-    ticker_label: "LABEL",
-    ticker_capital: "$1M",
-    scores: { field1: 82, field2: 71, field3: 68 },
-  },
-];
-```
-
-## File Header Template
-
-```tsx
-/**
- * <ComponentName>.jsx — PROTOTYPE
- * ─────────────────────────────────────────────
- * Status: Prototype — reference only, not production code
- * Created: <date>
- * Route (production target): <app-route>
- *
- * Key design decisions:
- * 1. <Decision and rationale>
- * 2. <Decision and rationale>
- *
- * What to preserve in production:
- * - <Design element>
- * - <Interaction pattern>
- *
- * What production implementation must do differently:
- * - Replace mock data with database query
- * - Import <Component> from @regen/ui instead of inline implementation
- * - Extract <Part> into shared component at src/components/<name>
- *
- * Production agent type: frontend | backend | data | viz
- * Production guide: .rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md)
- */
-```
-
-## File Footer Template
-
-```tsx
-// ─── HANDOFF SPEC ─────────────────────────────
-// Production files:
-//   apps/<app>/src/app/<route>/page.tsx           (server component)
-//   apps/<app>/src/app/<route>/<Name>Client.tsx   (client component)
-//   apps/<app>/src/app/<route>/<Name>Wrapper.tsx  (modal/state shell, if needed)
-//
-// Design system components to use (do not re-implement):
-//   <ComponentName> — <what it does>
-//
-// Database tables:
-//   <table> — <what to query>
-//
-// Form field schema additions needed:
-//   <table>.<column> — <input_type> — <label>
-```
-
-## After Building — Register and Record
-
-```sql
--- Register prototype
-INSERT INTO prototype_registry (name, component, source_path, notes, created_by)
-VALUES (
-  '<Name> Prototype v1',
-  '<ComponentName>',
-  'docs/source/<ComponentName>.jsx',
-  '<One-line description of key design: layout, data shape, interactions>',
-  'planning'
-);
-
--- Record design decisions
-INSERT INTO design_context (topic, context_type, summary, source, created_by)
-VALUES
-  ('<Topic>', 'prototype', 'Prototype built with <X> layout and <Y> interaction pattern', 'planning', 'planning'),
-  ('<Topic>', 'decision',  '<Key decision made during prototyping and why>', 'planning', 'planning');
-```
-
-## Handoff
-
-After prototype is approved, use `rdc:handoff` to create the plan doc and database work items.
-
-Or tell the project lead:
-```
-Prototype complete.
-File: docs/source/<ComponentName>.jsx
-Registered: prototype_registry
-
-To hand off to CLI build: use /rdc:handoff
-To build immediately: use /rdc:build
-```

package/commands/report.md

@@ -1,98 +0,0 @@
----
-name: report
-description: rdc:report () — write the session summary to .rdc/reports/
----
-
-> **⚠️ 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.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:report — Nightly Report
-
-## When to Use
-- End of a build session
-- Project lead asks for a report or summary
-- Nightly scheduled task
-- Before handing off to another session
-- Called by `rdc:overnight` at the end of every session
-
-## Arguments
-- `rdc:report` — interactive, prints summary to conversation
-- `rdc:report --unattended` — silent mode, writes file only, returns status block
-
-## Procedure
-
-1. **Query completed work (last 24h or since last report):**
-   ```sql
-   SELECT title, labels, completed_at, notes
-   FROM work_items
-   WHERE completed_at > now() - interval '24 hours'
-   ORDER BY completed_at;
-   ```
-
-2. **Query open work:**
-   ```sql
-   SELECT title, status, priority, labels
-   FROM work_items
-   WHERE status IN ('todo', 'in_progress', 'blocked')
-   ORDER BY priority, created_at;
-   ```
-
-3. **Git stats (since last report or last 24h):**
-   ```bash
-   git log --since="24 hours ago" --shortstat --oneline
-   git diff --shortstat HEAD~N  # where N = commits in window
-   ```
-
-4. **Infrastructure deployment snapshot** (if MCP available):
-   - List all apps with current status
-   - Flag any failures
-
-5. **Write report** to `.rdc/reports/YYYY-MM-DD.md` (fallback: `.rdc/reports/YYYY-MM-DD.md` if `.rdc/` does not exist):
-   ```markdown
-   # Daily Report — YYYY-MM-DD
-
-   ## Completed Today
-   | Item | Project | Priority |
-
-   ## Git Activity
-   - Commits: N
-   - Files changed: N
-   - Lines: +N / -N
-
-   ## Open Work
-   ### Urgent (N)
-   ### High (N)
-   ### Normal (N)
-
-   ## Deployment Status
-   | App | Domain | Status |
-
-   ## Blockers
-   <any blocked items or failed deploys>
-
-   ## Next Session Recommendation
-   <highest priority unstarted work>
-   ```
-
-6. **Check if weekly rollup needed** (if today is Sunday):
-   - Aggregate daily reports for the week
-   - Write `.rdc/reports/week-YYYY-WNN.md` (fallback: `.rdc/reports/week-YYYY-WNN.md`)
-
-7. **Report results:**
-   - Interactive: print summary to conversation
-   - Unattended: no interactive output, emit status block only:
-     ```
-     REPORT_STATUS: { report_path, completed_count, open_count, blockers_count }
-     ```
-
-## Rules
-- Reports go in `.rdc/reports/` (fallback: `.rdc/reports/`) — create dir if missing
-- One report per day — overwrite if re-run same day
-- Keep under 100 lines — scannable, not exhaustive
-- Include links to relevant CLAUDE.md files where helpful
-- Always end with "Next Session Recommendation"
-- Unattended: NEVER print to conversation — write file only

package/commands/self-test.md

@@ -1,112 +0,0 @@
----
-name: self-test
-description: rdc:self-test () - [--strict] — validate every rdc skill, the manifest and tooling
----
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No tool-call narration. No raw runner dumps — summarize.
-> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
-
-
-# rdc:self-test — Skill Library Self-Test (Tier 1)
-
-## When to Use
-- Before every `rdc:release rdc-skills` tag push
-- After editing any skill description or frontmatter
-- When a skill mysteriously disappears from the menu (backtick bug repro)
-- In CI on every rdc-skills PR (once wired)
-
-## Tiers
-
-| Tier | What it checks | Status |
-|------|----------------|--------|
-| Tier 1 | Static lint — frontmatter, Usage line, referenced files, name match | ✅ live |
-| Tier 2 | Behavioral — headless Claude or Codex runs each skill in sandbox, asserts artifacts | ✅ live — 30 manifests; acceptance harness records transcripts, tool calls, artifacts, and lessons learned |
-| Tier 3 | Golden checklists — snapshot output format, regress on drift | 🔒 future |
-
-## Procedure (Tier 1)
-
-1. **Run the linter:**
-   ```bash
-   node {RDC_SKILLS_ROOT}/scripts/self-test.mjs
-   ```
-
-2. **Interpret exit codes:**
-   - `0` = all skills pass
-   - `1` = at least one FAIL or (in `--strict` mode) at least one WARN
-   - `2` = runner itself crashed (e.g., skills dir unreadable)
-   - `3` = `.claude-plugin/plugin.json` missing entirely (distinct from skill failures)
-
-3. **Common findings and fixes:**
-
-   | Finding code | Cause | Fix |
-   |---|---|---|
-   | `description-backtick-leading` | Folded YAML starts with `` ` `` — parser drops skill | Rewrite description to start with a word |
-   | `usage-marker-missing` | No `` Usage `rdc:name <args>` `` in description | Front-load arg contract |
-   | `usage-marker-mismatch` | `Usage` line references a different skill's name (copy-paste drift) | Fix the skill name in the Usage marker |
-   | `name-filename-mismatch` | frontmatter `name:` ≠ filename | `--fix` auto-renames; or rewrite name |
-   | `guide-not-found` / `rule-not-found` / `hook-not-found` | Dead reference in skill body | Create file or fix link |
-   | `banner-missing` | Skill missing OUTPUT CONTRACT banner | `--fix` auto-inserts |
-   | `manifest-missing` / `manifest-version-mismatch` | `.claude-plugin/plugin.json` missing or out-of-sync with `package.json` | Create/update manifest |
-   | `duplicate-skill-name` / `skill-guide-filename-collision` | Two skills claim same name, or skill collides with agent guide | Rename one |
-   | `orphan-hook` | File under `hooks/` isn't referenced by any skill, settings.json, or plugin.json | Wire it up or delete |
-
-4. **Flags:**
-   - `--strict` — promotes warnings to failures (use in CI and before release)
-   - `--skill <name>` — run against a single skill (e.g. `--skill rdc:build`)
-   - `--json` — machine-readable schema v2 (per-skill `findings[]` with `code` + `level`, plugin_manifest block, global_findings, summary.exit_code). Consumed by Tier 2 runner as pre-gate.
-   - `--fix` — auto-repair fixable findings: insert missing OUTPUT CONTRACT banner, rename files to match frontmatter name. Prints `FIXED:` lines + touched file list so you can git diff + commit. Backtick-leading descriptions are NOT auto-fixed (need human rewrite).
-
-5. **Report to the project lead:**
-   ```
-   Self-test: X/Y pass, Z warnings, W failures
-   Failures: <list>
-   Verdict: PASS | FAIL
-   ```
-
-## Procedure (Tier 2)
-
-Tier 2 runs each skill end-to-end in an isolated sandbox and asserts on observed state (files touched, commits made, work items, exit code). Build acceptance additionally records all observable engine events/tool calls, assistant output, stdout/stderr artifacts, lessons learned, and next build optimizations. It supports `--engine claude` and `--engine codex`; both engines use the same manifests, worktree sandbox, JSONL evidence, and Markdown report. Use it before shipping behavioral changes — Tier 1 alone can't catch runtime drift.
-
-1. **Prerequisites:**
-   - `claude` CLI on PATH for Claude runs (headless mode: `claude --print`)
-   - `codex` CLI on PATH for Codex runs (headless mode: `codex exec --json`)
-   - clauth daemon unlocked (`curl -s http://127.0.0.1:52437/ping`)
-   - Supabase MCP reachable (runner creates a throwaway test branch)
-   - Clean git tree in `rdc-skills` (worktrees are added under `.rdc/sandbox/<run-id>/`)
-
-2. **Run:**
-   ```bash
-   node scripts/self-test.mjs --tier2                    # all skills with manifests
-   node scripts/self-test.mjs --tier2 --skill rdc:build  # single skill
-   node scripts/self-test.mjs --tier2 --parallel 3       # up to 3 skills in parallel
-   node scripts/self-test.mjs --tier2 --quick            # skip long-running assertions
-   node scripts/acceptance.mjs --skill rdc:build         # build acceptance with JSONL/tool-call evidence
-   node scripts/acceptance.mjs --engine codex --skill rdc:build
-   ```
-
-3. **What it does:**
-   - Runs Tier 1 as a pre-gate (fails fast if static lint fails)
-   - Creates one Supabase test branch for the run
-   - For each skill: `git worktree add` into `.rdc/sandbox/<run-id>/<skill>/`, sets `RDC_TEST=1`, invokes the selected headless engine with the skill prompt, waits for exit
-   - Asserts per the skill's manifest: exit code, files touched, commits made, stdout patterns
-   - Build acceptance writes JSONL evidence and extracts tool calls from the engine stream
-   - Cleans up worktrees + deletes the Supabase branch at the end (even on failure)
-
-4. **Reports:**
-   - `.rdc/reports/self-test-tier2-<iso>.json` — full per-skill result, findings, timings
-   - `.rdc/reports/acceptance-*.jsonl` and `.rdc/reports/acceptance-*.md` — build acceptance evidence, transcript artifact pointers, lessons learned, and next build optimizations
-   - Exit codes: `0` pass, `1` fail (one or more skills failed assertions), `2` runner error (couldn't set up sandbox / branch)
-
-5. **Adding a new manifest:**
-   - Create `skills/tests/<skill>.test.json` (one per skill, colocated)
-   - Validate the shape against the schema at `scripts/lib/manifest-schema.mjs`
-   - Test it in isolation: `node scripts/self-test.mjs --tier2 --skill rdc:name`
-   - Commit the manifest alongside any skill body changes
-
-## Rules
-- Run Tier 1 **before every `rdc:release rdc-skills`** — it catches the backtick-drift class of bugs that break the skill menu silently.
-- Use `--strict` in CI. Warnings matter in the release path.
-- Do NOT skip findings by relaxing the linter. Fix the skill.
-- Run Tier 2 before tagging a release. Gate the tag if any manifested skill fails.
-- Headless sessions must not steal focus. The runner uses hidden process launch options where supported; if windows flash or focus is grabbed, inspect `scripts/lib/runner.mjs` before changing skill behavior.

package/commands/watch.md

@@ -1,97 +0,0 @@
----
-name: watch
-description: rdc:watch () — open a live session-log viewer and report its path
----
-
-> **⚠️ 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.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:watch — Session Log Watcher
-
-## When to Use
-- Start of any long-running session where Dave needs visibility into what you're doing
-- Before `rdc:overnight`, `rdc:build` on a large epic, or any multi-hour grind
-- Anytime the user asks for "a log", "a viewer", "tail", or "what are you doing right now"
-
-## Procedure
-
-1. **Initialize the log and viewer.** Run the helper script from the plugin directory in the user's current project:
-   ```bash
-   node ${CLAUDE_PLUGIN_ROOT}/scripts/watch-init.mjs
-   ```
-   (If `CLAUDE_PLUGIN_ROOT` is not set, resolve the plugin path from your invocation context or the installed plugin cache.)
-
-2. **Parse the output.** The script prints `run_id`, `log_path`, `current`, `viewer`, and `open_hint`. Capture `log_path` and `viewer` for the rest of the session.
-
-3. **Open the viewer in the browser, unless running under `RDC_TEST=1`.**
-   - Normal attended use: run the exact `open_hint` line from the script output. On Windows that's `start "" "<viewer-path>"`.
-   - `RDC_TEST=1`: do not run `open_hint`, `start`, `open`, `xdg-open`, or any focus/window API. Report the viewer path only.
-
-4. **Report to the user.** One line:
-   ```
-   watcher live at <viewer-path> — tailing <log-path>
-   ```
-   In `RDC_TEST=1`, say:
-   ```
-   watcher initialized at <viewer-path> — not opened because RDC_TEST=1
-   ```
-
-5. **Append one line per substantive action for the rest of the session.** Use the documented format — one line, no multi-line payloads:
-   ```
-   [<ISO-timestamp>] [<kind>] <message>
-   ```
-   Append to BOTH `<log-path>` (the full history) AND `current.log` (what the viewer polls). The viewer diffs `current.log` by length and only appends new lines.
-
-### Log format
-
-- `ISO-timestamp` — `new Date().toISOString()`
-- `kind` — one of: `dispatch`, `commit`, `test`, `error`, `note`, `banner`
-- `message` — single line, no newlines. Keep under ~200 chars.
-
-### Kinds
-
-| Kind | When to append |
-|------|----------------|
-| `dispatch` | About to dispatch a subagent — include role + epic/task id |
-| `commit` | After a git commit lands — include short sha + subject |
-| `test` | Test run kicked off or result came back |
-| `error` | Anything that failed — include what and why in one line |
-| `note` | General progress ticks (reading files, analyzing, planning) |
-| `banner` | Session start/end markers, major phase changes |
-
-### Examples
-
-```
-[2026-04-15T23:14:02.318Z] [dispatch] frontend agent → epic abc123 task 4 (rebuild DynamicForm)
-[2026-04-15T23:17:41.902Z] [commit] 3f2a1b9 feat(marketing-engine): DynamicForm rhf+zod
-[2026-04-15T23:18:05.113Z] [test] pnpm --filter @regen/rdc-marketing-engine test
-[2026-04-15T23:18:41.002Z] [error] tsc: src/components/Form.tsx:42 — Property 'foo' does not exist
-[2026-04-15T23:19:00.000Z] [note] retrying with corrected type import
-[2026-04-15T23:45:10.000Z] [banner] Phase 2 complete — moving to review
-```
-
-### Appending from bash (Windows-safe)
-
-```bash
-printf '[%s] [%s] %s\n' "$(date -u +%Y-%m-%dT%H:%M:%S.000Z)" "dispatch" "your message" >> "$LOG_PATH"
-printf '[%s] [%s] %s\n' "$(date -u +%Y-%m-%dT%H:%M:%S.000Z)" "dispatch" "your message" >> "$CURRENT_PATH"
-```
-
-Or from Node:
-```js
-import { appendFileSync } from "node:fs";
-const line = `[${new Date().toISOString()}] [note] ${msg}\n`;
-appendFileSync(logPath, line);
-appendFileSync(currentPath, line);
-```
-
-## Notes
-
-- Log files live in the **user's project**, not the rdc-skills repo. Path: `<projectRoot>/.rdc/session-log/`
-- Each invocation creates a **new run id** and overwrites `current.log`. Prior run logs remain on disk as `<runId>.log`.
-- The viewer is a single static HTML file polling `current.log` via `fetch()` every 2s — no server, no deps.
-- This skill does NOT replace `rdc:report` (the end-of-session Obsidian writeup). It's a live tail for attended or semi-attended sessions.

package/commands/workitems.md

@@ -1,148 +0,0 @@
----
-name: workitems
-description: rdc:workitems ([subcommand]) — create, update and query work items directly
----
-
-> **⚠️ 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.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:workitems — Work Item Management
-
-## Rules
-
-1. **Epic first, always.** Never create a task without a parent epic.
-2. **Label everything.** Minimum one system label per item.
-3. **Check first.** `get_open_epics()` before creating anything new.
-4. **Link design docs.** Put `.rdc/plans/` or `.rdc/research/` paths in descriptions (fallback: `.rdc/plans/` / `.rdc/research/`).
-
-## Read Epics
-
-```sql
-SELECT get_open_epics();
-SELECT get_open_epics('urgent');
-SELECT get_open_epics(p_label_filter := 'custom-label');
-```
-
-## Create Epic
-
-```sql
-SELECT insert_work_item(
-  p_title       := 'EPIC: Clear descriptive title',
-  p_description := 'What and why. Reference .rdc/plans/<n>.md if applicable.',
-  p_item_type   := 'epic',
-  p_priority    := 'high',
-  p_labels      := ARRAY['system-label'],
-  p_source      := 'planning'
-);
-
--- Immediately populate governance refs. architecture_ref stays NULL unless this epic
--- crosses an architectural boundary (storage authority, process topology, auth boundary,
--- deployment model, persistence, service ownership, public contract) — setting it holds
--- every child task for a required architecture-fidelity-* checklist row at close time.
-SELECT set_epic_governance_refs(
-  p_epic_id := '<epic-uuid>'::uuid,
-  p_plan_ref := '.rdc/plans/<n>.md or NULL',
-  p_spec_ref := '.rdc/plans/<n>.md or NULL',
-  p_architecture_ref := NULL,
-  p_scoping_statement := '<one paragraph: what is in scope and what is explicitly out>'
-);
-```
-
-## Create Task
-
-```sql
-SELECT insert_work_item(
-  p_title       := 'Specific actionable task title',
-  p_description := 'What: <deliverable>
-Where: <files to create/modify>
-Agent type: frontend | backend | data | design | infra | content | cs2
-Guide: .rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md)
-Design doc: .rdc/plans/<n>.md (fallback: .rdc/plans/<n>.md, if exists)
-Depends on: <other task title if sequential>
-Est: <hours>',
-  p_parent_id   := '<epic-uuid>'::uuid,
-  p_item_type   := 'task',
-  p_priority    := 'high',
-  p_labels      := ARRAY['system-label'],
-  p_estimated_hours := 2,
-  p_source      := 'planning'
-);
-```
-
-## Update Status
-
-```sql
-SELECT update_work_item_status('<uuid>'::uuid, 'in_progress');
-SELECT update_work_item_status('<uuid>'::uuid, 'review', '["Implementation complete; ready for validator"]'::jsonb, '<agent-session-id>', 'agent');
-SELECT update_work_item_status('<uuid>'::uuid, 'done', '["Validator verified implementation report, CodeFlow post, and checklist evidence"]'::jsonb, '<validator-session-id>', 'validator');
-SELECT update_work_item_status('<uuid>'::uuid, 'blocked', '["Why it is blocked"]'::jsonb);
-```
-
-Non-epic `done` is a validator-only close and requires an existing
-`implementation_report.codeflow_post`, checked required checklist evidence, and
-originating-agent tick audit.
-
-## Read Tasks in an Epic
-
-```sql
-SELECT get_work_items_by_epic('<epic-uuid>'::uuid);
-SELECT get_work_items_by_epic('<epic-uuid>'::uuid, 'todo');
-```
-
-## Bump Epic Version
-
-```sql
-SELECT bump_epic_version('<epic-uuid>'::uuid, '0.2.0', 'What changed', 'planning');
-```
-
-## Valid Values
-
-| Field | Values |
-|-------|--------|
-| status | `todo` `in_progress` `blocked` `review` `done` `archived` |
-| priority | `urgent` `high` `normal` `low` |
-| item_type | `epic` `task` `subtask` `bug` `spike` |
-
-## System Labels
-
-| Label | When |
-|-------|------|
-| `project-a` | Your-app-specific work |
-| `project-b` | Another app work |
-| `cs2` | Core paradigm packages |
-| `hail` | Grammar, DSL compiler |
-| `pal` | Moment windows, memory |
-| `virtue` | Virtue engine, coherence |
-| `marketing` | Outreach, campaigns |
-| `media` | Assets, R2, image pipeline |
-| `infrastructure` | CI/CD, deployment |
-| `ui` | Component library |
-| `data` | Schema, migrations |
-| `content` | Copy, messaging |
-| `website` | Public-facing sites |
-
-## Agent Type → Guide File Reference
-
-| Type | Guide | Use For |
-|------|-------|---------|
-| `frontend` | .rdc/guides/frontend.md | React, pages, UI, Tailwind |
-| `backend` | .rdc/guides/backend.md | API routes, database, auth |
-| `data` | .rdc/guides/data.md | Migrations, schema, RPC |
-| `design` | .rdc/guides/design.md | Brand, palette, OG images |
-| `infra` | .rdc/guides/infrastructure.md | CI/CD, deploy, DNS |
-| `content` | .rdc/guides/content.md | Copy, messaging, tone |
-| `cs2` | .rdc/guides/cs2.md | CS 2.0 paradigm |
-| `hail` | .rdc/guides/cs2.md + packages/hail/CLAUDE.md | Grammar, DSL |
-| `viz` | .rdc/guides/frontend.md + design.md | Custom visualizations |
-
-## What NOT to Do
-
-- Never raw INSERT/UPDATE against work items — RPC functions only
-- Never create tasks without a parent epic
-- Never leave labels empty
-- Never write vague titles ("Fix stuff") — be specific
-- Never put design intention in the task — put it in `.rdc/research/` (fallback: `.rdc/research/`) and link