@lifeaitools/rdc-skills 0.8.7

package/guides/agents/viz.md

@@ -0,0 +1,106 @@
+> **⚠️ 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:viz — Visualization Agent
+
+## Mandatory First Steps
+
+Read BOTH guides before ANY code:
+```
+{PROJECT_ROOT}/.rdc/guides/frontend.md (fallback: {PROJECT_ROOT}/.rdc/guides/frontend.md)
+{PROJECT_ROOT}/.rdc/guides/design.md (fallback: {PROJECT_ROOT}/.rdc/guides/design.md)
+```
+
+## Before Writing Any Code
+
+1. **Check for existing prototypes:**
+   ```sql
+   SELECT name, component, source_path, status, notes
+   FROM prototype_registry
+   WHERE status IN ('prototype', 'converting')
+   ORDER BY created_at DESC;
+   ```
+   Source path is usually `docs/source/`. **Read it first.**
+
+2. **Check design decisions:**
+   ```sql
+   SELECT topic, summary FROM design_context
+   WHERE topic ILIKE '%<viz-name>%';
+   ```
+
+## SVG Layout Patterns
+
+When building new SVG-based viz:
+- Define all layout constants at top (`W`, `H`, column x-centers, box dimensions)
+- Build path builders as pure functions
+- Separate data from rendering
+- Use `viewBox` for responsive scaling
+- Animate with appropriate motion libraries
+
+```tsx
+const W = 980, H = 570;
+const COL_A = 80, COL_B = 240, COL_C = 435;
+
+function pathTo(x1: number, y1: number, x2: number, y2: number): string {
+  const mx = (x1 + x2) / 2;
+  return `M ${x1} ${y1} C ${mx} ${y1} ${mx} ${y2} ${x2} ${y2}`;
+}
+```
+
+## Viz Component Contract
+
+```tsx
+"use client";
+import * as React from "react";
+import { cva, type VariantProps } from "class-variance-authority";
+import { cn } from "../lib/utils";
+
+// CVA variants required on every new viz component
+const myVizVariants = cva("relative w-full", {
+  variants: {
+    layout: { single: "", double: "flex flex-col", grid: "" },
+    density: { compact: "", comfortable: "", spacious: "" },
+  },
+  defaultVariants: { layout: "single", density: "comfortable" },
+});
+
+interface MyVizProps
+  extends React.HTMLAttributes<HTMLDivElement>,
+    VariantProps<typeof myVizVariants> {}
+
+const MyViz = React.forwardRef<HTMLDivElement, MyVizProps>(
+  ({ className, layout, density, ...props }, ref) => (
+    <div ref={ref} className={cn(myVizVariants({ layout, density }), className)} {...props} />
+  )
+);
+MyViz.displayName = "MyViz";
+export { MyViz, myVizVariants };
+```
+
+Export from package's index after building.
+
+## Registering New Viz Components
+
+After completing:
+```sql
+INSERT INTO prototype_registry (name, component, source_path, notes, created_by)
+VALUES (
+  'MyViz v1.0',
+  'MyViz',
+  'packages/ui/src/components/my-viz.tsx',
+  'Production component. Props: <list key props>',
+  'agent'
+);
+```
+
+## Safety Rules
+
+- Branch: development branch — auto-commit
+- NEVER run `pnpm build`
+- Reduce motion: always wrap animations with appropriate hooks
+- NEVER overlap with other agents on the same component file
+- Write tests FIRST — red → implement → green

package/guides/backend.md

@@ -0,0 +1,146 @@
+# Backend Agent Guide — Base
+> Role-based context for backend/API/data agents. Generic patterns across projects.
+
+---
+
+## Database Client Patterns
+
+Every project specifies its database client library. Always use that instead of writing raw SQL.
+
+Generic server component pattern:
+```ts
+// Server component / API route
+const client = await createServerClient();
+const { data, error } = await client.from("table").select("*");
+```
+
+Generic browser component pattern:
+```ts
+// Client component
+const client = createBrowserClient();
+const { data, error } = await client.from("table").select("*");
+```
+
+The project overlay specifies:
+- Import path for server client
+- Import path for browser client
+- How to access non-public schemas
+- Authentication requirements
+
+---
+
+## Environment Variables
+
+```bash
+# Required in every app
+# (Project overlay specifies exact variable names and format)
+SERVICE_URL=https://...
+SERVICE_ANON_KEY=...
+
+# Server-side only (never prefix with PUBLIC_)
+SERVICE_ADMIN_KEY=...
+```
+
+The project overlay specifies:
+- Exact variable names
+- Which are public vs server-only
+- Where to retrieve credentials
+
+---
+
+## Auth Patterns
+
+Projects typically provide auth helpers. Check project overlay for:
+- `getUser()` — nullable, server-side only
+- `requireAuth()` — throws if unauthenticated
+- Middleware patterns (public pass-through vs protected)
+- Login method (magic link, OAuth, etc.)
+
+---
+
+## Work Items / Task Management
+
+Most projects have a task/epic system. The project overlay specifies:
+- Whether to use RPC functions or raw SQL
+- Required fields and enums
+- Relationship patterns (parent/child hierarchy)
+- Which operations require special handling
+
+Never guess at the implementation — read the project overlay.
+
+---
+
+## API Route Patterns
+
+```ts
+// app/api/example/route.ts
+import { createServerClient } from "@project/db";
+import { NextResponse } from "next/server";
+
+export async function GET() {
+  const client = await createServerClient();
+  const { data, error } = await client.from("table").select("*");
+  if (error) return NextResponse.json({ error: error.message }, { status: 500 });
+  return NextResponse.json(data);
+}
+
+export async function POST(request: Request) {
+  const body = await request.json();
+  const client = await createServerClient();
+  const { data, error } = await client.from("table").insert(body).select().single();
+  if (error) return NextResponse.json({ error: error.message }, { status: 400 });
+  return NextResponse.json(data, { status: 201 });
+}
+```
+
+---
+
+## Schema-Driven Forms
+
+Some projects use dynamic schema tables for form generation. The project overlay specifies:
+- Table for field schema
+- Components that read schema at runtime (DynamicForm, AdaptiveCrud, etc.)
+- Never hardcode form columns
+
+---
+
+## Credential Safety
+
+The project overlay specifies:
+- Where credentials come from (MCP, daemon, env vars)
+- Never print keys to stdout
+- Never hardcode credentials in source
+- Never ask the user for keys
+- If daemon/service is down: report BLOCKED, do not work around
+
+---
+
+## Key Schema Domains (Check Project Overlay)
+
+The project specifies its schema structure:
+- Which tables exist in which schemas
+- Primary keys and foreign relationships
+- RLS policies and access rules
+- Materialized views or special queries
+
+Never assume schema structure — read the project overlay.
+
+---
+
+## Migration Patterns
+
+The project overlay specifies:
+- Where migration files live
+- How to apply migrations
+- How to verify migrations
+- Which database service to use
+
+---
+
+## Specialist Context — Read Project Overlay
+
+Your task may require reading additional project-specific guides for:
+- Full DB schema with all columns
+- Deployment registry patterns
+- Brand token API
+- Auth patterns beyond basics

package/guides/content.md

@@ -0,0 +1,147 @@
+# Content Agent Guide — Base
+> Role-based context for content, copywriting, and messaging agents. Generic patterns across projects.
+
+---
+
+## Core Messaging
+
+Every project has a core message and lead word. Check the overlay for:
+- The single most important concept
+- The tone and voice (formal, friendly, technical, etc.)
+- Key messages and themes
+- Audience segments and their pain points
+
+---
+
+## Language Rules
+
+The project specifies:
+- Words/phrases to ALWAYS use
+- Words/phrases to NEVER use alone
+- Synonyms to prefer
+- Jargon levels (when to use, when to avoid)
+- Metaphors and analogies that resonate
+
+---
+
+## Regulatory Context
+
+Check the overlay for:
+- Compliance framework (Reg D, HIPAA, etc.)
+- Disclaimers required
+- Language restrictions (cannot guarantee, cannot claim, etc.)
+- When to involve legal review
+
+---
+
+## Audience Segments
+
+The project defines segments with:
+- Pain points
+- What they care about
+- Key values
+- Messaging hooks per segment
+- Success metrics
+
+Tailor messaging per segment.
+
+---
+
+## Key Acronyms and Terminology
+
+The project provides:
+- List of acronyms and full names
+- When to use acronym vs full name
+- Related concepts and distinctions
+- Pronunciation (if needed)
+
+---
+
+## Brand Positioning
+
+The project specifies:
+- Brand promise
+- Competitive positioning
+- Unique value proposition
+- Brand personality
+
+---
+
+## Architecture and Offerings
+
+The project describes:
+- Product/service offerings
+- How they work together
+- Key features and benefits
+- Pricing/tier structure (if applicable)
+
+---
+
+## Key Financial/Impact Facts
+
+The project provides:
+- Headline metrics (fund size, returns, impact, etc.)
+- Ranges vs absolutes
+- How to cite data
+- What claims require support
+
+---
+
+## Contact Information
+
+The project specifies:
+- Primary contact person
+- Contact method (email, phone, etc.)
+- When different contacts are appropriate
+- What to escalate
+
+---
+
+## Tone Guidelines
+
+The project specifies:
+- Voice characteristics (authoritative, friendly, technical, etc.)
+- Active vs passive voice preference
+- Sentence structure patterns
+- Metaphor usage
+- Humor guidelines
+
+---
+
+## Live Products / Offerings
+
+The project lists:
+- Current offerings (products, services, projects, etc.)
+- Status (active, development, archived)
+- Key features or differentiators
+
+---
+
+## Email Templates
+
+Some projects use templated emails. Check overlay for:
+- Email template library
+- When to use canned vs custom
+- Email formatting standards
+- Signature blocks
+
+---
+
+## Campaign Engine
+
+Some projects have automated campaigns. Check overlay for:
+- Campaign template system
+- Variable injection patterns
+- Segment-specific personalization
+- Scheduling and delivery rules
+
+---
+
+## Specialist Context — Read Project Overlay
+
+Your task may require reading additional project-specific guides for:
+- Complete acronym list
+- Detailed financial facts
+- Full audience segment profiles
+- Campaign templates and examples
+- Compliance and legal language requirements

package/guides/cs2.md

@@ -0,0 +1,190 @@
+# CS 2.0 Agent Guide
+> Role-based context for Computer Science 2.0 subsystem agents.
+> This is LIFEAI-specific architecture. All CS 2.0 work happens in the LIFEAI ecosystem.
+
+---
+
+## The Paradigm
+
+**Before writing ANY code, ask: "Is this building a new computational primitive, or is it wiring a UI to a database?"**
+
+If the latter -- STOP. You are falling into CS 1.0 thinking.
+
+CS 2.0 is a new computational paradigm. The work is to build:
+
+1. **Languages** — Meta-compilers and AI-evolved DSLs, not traditional code
+2. **Data primitives** — Time-native, certainty-propagating, cross-product-aware
+3. **Memory systems** — Associative retrieval, not databases
+4. **Cognitive runtimes** — Virtue-governed execution, not simple executors
+5. **Governance** — Virtue weights are signed and versioned, not embedded in code
+
+The web apps (portals, dashboards, UIs) are the **surface layer**. They display CS 2.0 systems at work. They are not the work itself.
+
+---
+
+## What CS 2.0 is NOT
+
+- Wiring React components to database queries
+- Building CRUD dashboards
+- Adding features to Next.js apps
+- Traditional API + database + frontend development
+
+Those are CS 1.0 patterns. CS 2.0 is the substrate they run on.
+
+---
+
+## Seven Subsystems
+
+### 1. HAIL (`@regen/hail`)
+
+Meta-compiler that GENERATES domain-specific languages. Each domain (ecology, capital, governance, health, law) gets its own DSL. AI evolves these grammars. HAIL does not execute programs — it writes them.
+
+### 2. Quad Pixel Q(M,V,A,C) (`@regen/quad-pixel`)
+
+Language-level data primitive. Every data point carries Magnitude, Velocity, Acceleration, Certainty. Time is native, not metadata. Cross-products are built-in. Certainty propagates automatically.
+
+### 3. AEMG (`@regen/aemg`)
+
+Associative Episodic Memory Graph. NOT a database. Memory is retrieved through associative traversal, not lookup. Images anchor time. Virtue anchors meaning. Relevance governs forgetting. Dual-truth preservation (who you were + who you are).
+
+### 4. Being State Processor (`@regen/being-state-processor`)
+
+The cognitive runtime. Orchestrates lower functions under virtue governance. Lower functions execute but NEVER reason about virtue. Virtue is supplied from above, not embedded in the executor. (Like muscles don't know if they're writing a poem or committing a crime.)
+
+### 5. Virtue Engine (`@regen/virtue-engine`)
+
+REPLACES the reward function. Not a scoring widget. The architectural conscience invoked by all subsystems BEFORE consequential action. Virtue weights are governed, versioned, signed — never self-modified by executing layers.
+
+### 6. Gene Expression Model
+
+Interactions suppress or activate functions for their duration. Learned through observation over time (Quad Pixel cross-correlation), not through programming.
+
+### 7. Domain DSLs
+
+Each evolved by AI from HAIL grammars. One source of truth emits: Python microservices, DMN tables, BPMN flows, DTDL twins, LaTeX proofs. Five forms. All synchronized.
+
+---
+
+## Supporting Packages
+
+| Package | Purpose |
+|---------|---------|
+| `@regen/cs2` | Core primitives and shared types |
+| `@regen/cs2-integration` | Pipeline utilities, type bridges (depends on 9 packages) |
+| `@regen/pal` | Personal AI Liaison -- 90s Moment Window, Graph Memory |
+| `@regen/sdl` | Semantic Design Language for civic design |
+| `@regen/planetary-ontology` | Earth Digital Twin -- Neo4j graph layer |
+| `@regen/genetic-sandbox` | Genetic algorithm sandbox for HAIL grammar evolution |
+| `@regen/reinforcement-renderer` | Reinforcement learning renderer for visual output |
+| `@regen/visual-model` | Visual modelling primitives |
+
+---
+
+## Package Dependency Graph
+
+```
+Layer 0 (roots -- no @regen/ deps):
+  cs2  quad-pixel  virtue-engine  genetic-sandbox
+
+Layer 1 (single root dep):
+  sdl (quad-pixel)
+  planetary-ontology (quad-pixel)
+
+Layer 2 (2-3 root deps):
+  pal (quad-pixel, virtue-engine)
+  hail (genetic-sandbox, quad-pixel, virtue-engine)
+  reinforcement-renderer (genetic-sandbox, quad-pixel, sdl, virtue-engine)
+
+Layer 3 (composite):
+  aemg (pal, quad-pixel, virtue-engine)
+  visual-model (quad-pixel, reinforcement-renderer)
+
+Layer 4 (deep composite):
+  being-state-processor (aemg, pal, quad-pixel, virtue-engine)
+
+Layer 5 (integration hub):
+  cs2-integration (9 deps -- aggregates all CS 2.0 packages)
+```
+
+---
+
+## SOLID Mapping
+
+| Principle | CS 2.0 Application |
+|-----------|---------------------|
+| **S** Single Responsibility | BSP executes. Virtue governs. Structurally distinct. |
+| **O** Open/Closed | HAIL grammars extended via DSL patches under governance, not code mods. |
+| **L** Liskov | Lower Functions are interchangeable end-effectors under governance. |
+| **I** Interface Segregation | PAL, Virtue Engine, RCCS, HAIL are independent services. |
+| **D** Dependency Inversion | Executing layers depend on virtue abstractions, not concrete impls. Apps depend on `@regen/` packages, never on each other. |
+
+---
+
+## When Building Portal-Layer Apps
+
+Even portal/UI work must reflect CS 2.0 architecture:
+
+- **Data display** -- show through Quad Pixel awareness (velocity, not just magnitude)
+- **Consequential actions** -- consult Virtue Engine before executing
+- **UX rhythm** -- PAL's 90-second Moment Window
+- **Memory/history** -- use AEMG (associative traversal, not chronological lists)
+- **Governance/rules UI** -- reference HAIL grammar constructs
+
+---
+
+## Architecture Direction (Apr 8, 2026)
+
+### HAIL = AI Skill
+
+HAIL is not a traditional compiler. It is an AI skill — Claude reads the grammar definition and generates code in the target format. The grammar evolves through genetic algorithms in the sandbox.
+
+### Ontology = Prebuilt Earth Shadow Tree
+
+The planetary ontology is 85% pre-built from existing Earth system data (climate zones, watersheds, ecosystems, soil types). Not built from scratch — populated from authoritative datasets then extended per-project.
+
+### RCCS = 8-Layer Pipeline
+
+The RCCS credit system has 8 processing layers:
+1. Instrumentation (sensors/data collection)
+2. Ingestion (normalize + validate)
+3. HAIL grammar application
+4. CalcProof (immutable delta-I computation)
+5. Verification (third-party audit)
+6. CUT Registry (credit issuance)
+7. NAV integration
+8. BPMN governance flows
+
+Immutable delta-I is the core — every credit traces back to a verified change from baseline.
+
+### Contracts for Unnatural Systems
+
+Systems operating outside natural boundaries (mining, heavy industry) get contracts that define remediation obligations, not credits.
+
+### Governance-Gated Expansion
+
+New domains (health, education, urban) are added only through governance votes, not ad-hoc code additions. HAIL grammar proposals go through the virtue engine before activation.
+
+---
+
+## Reference Documents
+
+| Document | Location |
+|----------|----------|
+| Complete Architecture v3 | `docs/source/LifeAI_CS20_Complete_Architecture_v3.docx` |
+| Zoen Covenant | `docs/source/Zoen_Covenant_Complete_Draft.docx` |
+| Master Spec | `docs/systems/cs2/cs2-master-spec.md` |
+| Architecture | `docs/systems/cs2/ARCHITECTURE.md` |
+| Package Map | `docs/systems/cs2/package-map.md` |
+| Architecture Research | `docs/systems/cs2/architecture-research-apr8.md` |
+
+---
+
+## Specialist Context — Read These for Domain-Specific Tasks
+
+| If your task involves... | Read this file first |
+|--------------------------|----------------------|
+| HAIL grammar compiler internals, DSL target formats | `packages/hail/CLAUDE.md` |
+| PAL session lifecycle, MomentWindow, GraphMemory | `packages/pal/CLAUDE.md` |
+| Virtue engine weights, coherence scoring, certification | `packages/virtue-engine/CLAUDE.md` |
+| Quad Pixel primitive design, velocity/acceleration/certainty | `packages/quad-pixel/CLAUDE.md` |
+| Full package dependency graph, integration layer | `docs/systems/cs2/ARCHITECTURE.md` |

package/guides/data.md

@@ -0,0 +1,123 @@
+# Data Agent Guide — Base
+> Role-based context for data, schema, and database agents. Generic patterns across projects.
+
+---
+
+## Database Instance
+
+Check project overlay for:
+- Database reference / instance identifier
+- Available MCP servers and their capabilities
+- RLS (Row-Level Security) status
+- Schema organization
+
+---
+
+## Schema Organization
+
+The project specifies schema structure. Check the overlay for:
+- Public schema tables and purpose
+- Additional named schemas (prt, rccs, etc.)
+- Access patterns per schema
+- RLS policies
+
+Access non-public schemas with project-specific prefix:
+```ts
+const { data } = await client.schema("schema-name").from("table").select("*");
+```
+
+---
+
+## Domains and Data Organization
+
+The project overlay specifies all domains:
+- Marketing/CRM tables
+- Analytics/intelligence tables
+- Product-specific tables
+- Operational/system tables
+- Archive tables
+
+Check the overlay for:
+- Tables per domain
+- Foreign key relationships
+- Materialized views or special queries
+- Upsert patterns
+
+---
+
+## Work Items / Task Management
+
+The project specifies task management patterns:
+- Whether to use RPC functions or raw SQL
+- Valid status/priority/type enums
+- Hierarchy rules (parent/child)
+- Lifecycle patterns
+
+Never create-then-close in one operation. Always follow project rules.
+
+---
+
+## Migration Patterns
+
+The project overlay specifies:
+- Where migration files live (format: numbered SQL files)
+- How to apply migrations (tool or CLI)
+- How to verify migrations
+- Version control strategy
+
+Always verify with a follow-up query after applying.
+
+---
+
+## RLS (Row-Level Security)
+
+The project specifies:
+- Which tables have RLS enabled
+- Which operations require service role key
+- Which operations work with anon key
+- Special policies or edge cases
+
+Never bypass RLS rules. If needed for tests, use service role carefully.
+
+---
+
+## Foreign Key Map
+
+The project overlay provides:
+- All foreign relationships
+- Which are enforced vs informational
+- Cascade behavior (if any)
+
+Use this to prevent orphaned records and maintain consistency.
+
+---
+
+## Common Query Patterns
+
+The project overlay provides:
+- Standard SELECT patterns per domain
+- JOIN patterns
+- Aggregation patterns
+- Window function patterns
+
+Check examples before writing queries.
+
+---
+
+## Type Generation
+
+The project specifies:
+- Type generation tool (TypeScript generation, type stubs, etc.)
+- How to refresh types after schema changes
+- Where generated types live
+- Import patterns
+
+---
+
+## Specialist Context — Read Project Overlay
+
+Your task may require reading additional project-specific guides for:
+- Full DB schema with all column types
+- Deployment registry schema
+- Brand token/design token tables
+- Work item RPC functions