springdotnew
diff --git a/‎.claude/skills/critic-review/skill.md‎
Lines changed: 180 additions & 0 deletions b/‎.claude/skills/critic-review/skill.md‎
Lines changed: 180 additions & 0 deletions
diff --git a/‎README.md‎
Lines changed: 7 additions & 11 deletions b/‎README.md‎
Lines changed: 7 additions & 11 deletions
@@ -0,0 +1,180 @@
+---
+name: critic-review
+description: "Spawn 6 critic agents (3 code quality, 3 security) to review recent changes, validate all claims, and present findings. Triggers on: critic review, review critics, spawn critics, code review agents, security review agents."
+---
+
+# Critic Review
+
+Spawn parallel critic agents to review code changes, validate their findings, and present actionable results.
+
+---
+
+## The Job
+
+1. **Identify changed files** from the current branch vs base
+2. **Spawn 6 critic agents** in parallel (3 code quality, 3 security)
+3. **Collect and deduplicate** all findings
+4. **Validate each claim** by reading the actual code
+5. **Present validated findings** grouped by severity
+
+---
+
+## Step 1: Identify Changed Files
+
+Determine what files to review:
+
+```bash
+# Get the diff of changed files
+git diff --name-only HEAD~$(git rev-list --count HEAD --not $(git merge-base HEAD master))..HEAD 2>/dev/null || git diff --name-only HEAD~3..HEAD
+```
+
+If the user specifies particular files or directories, scope the review to those instead.
+
+Read all changed files so you can provide them as context to the critic agents.
+
+---
+
+## Step 2: Spawn Critic Agents
+
+Launch **6 agents in parallel** using the Agent tool. All agents should receive:
+- The full content of each changed file
+- The diff showing what changed
+
+### Code Quality Critics (3 agents)
+
+Each code quality critic should focus on a different area. Read the project's coding rules from `docs/coding-rules.md` and include them in the agent prompt.
+
+**Agent 1 — Structure & Patterns:**
+- Zero mutation violations
+- Nested if statements (must be zero)
+- Function size (≤20 lines)
+- Single responsibility principle
+- Classes (must not exist — functional only)
+
+**Agent 2 — Types & Naming:**
+- `any` type usage
+- Descriptive variable/function names
+- Strict interfaces
+- Reuse of existing types
+- Boolean function naming (is/has/can/should prefixes)
+
+**Agent 3 — Code Hygiene:**
+- DRY violations
+- Comments explaining "what" instead of "why"
+- Error handling patterns
+- Dead code
+- Dependency inversion
+
+### Security Critics (3 agents)
+
+**Agent 4 — Input Validation & Injection:**
+- Input validation at system boundaries
+- Prototype pollution vectors
+- Injection risks (command, XSS, etc.)
+- Unsafe type assertions that skip validation
+
+**Agent 5 — Auth & Access Control:**
+- Authentication bypass vectors
+- Authorization check completeness
+- Token/credential handling
+- Session management
+- Event authorization gaps
+
+**Agent 6 — Transport & Protocol Security:**
+- WebSocket security (origin checks, message validation)
+- Binary protocol parsing safety
+- Error message information leakage
+- CORS configuration
+- Race conditions in connection/disconnection handling
+
+### Agent Prompt Template
+
+Each agent prompt MUST include:
+
+```
+You are a critic reviewing code changes. Your job is to find REAL issues, not theoretical ones.
+
+**Rules:**
+- Only report issues in the CHANGED code (not pre-existing issues)
+- Each finding must reference a specific file and line number
+- Each finding must include the actual problematic code snippet
+- Rate severity: HIGH (exploitable/broken), MEDIUM (should fix), LOW (nice to have)
+- Do NOT report issues that are by design or documented trade-offs
+- Be specific — "could be improved" is not a finding
+
+**Output format for each finding:**
+### [SEVERITY] Title
+- **File:** path/to/file.ts:LINE
+- **Code:** `the problematic code`
+- **Issue:** What's wrong
+- **Fix:** How to fix it
+```
+
+---
+
+## Step 3: Collect and Deduplicate
+
+After all 6 agents complete:
+
+1. Gather all findings into a single list
+2. Remove exact duplicates (same file, same line, same issue)
+3. Merge similar findings that point to the same root cause
+4. Sort by severity: HIGH → MEDIUM → LOW
+
+---
+
+## Step 4: Validate Each Claim
+
+For every finding, **read the actual code** at the referenced location and verify:
+
+1. Does the file and line exist?
+2. Does the code snippet match what's actually there?
+3. Is the issue real or a false positive?
+4. Is this a change we made, or pre-existing code?
+
+Mark each finding as:
+- **CONFIRMED** — Issue is real and in changed code
+- **FALSE POSITIVE** — Code is correct, critic was wrong (explain why)
+- **PRE-EXISTING** — Real issue but not in our changes
+- **BY DESIGN** — Intentional trade-off (explain rationale)
+
+---
+
+## Step 5: Present Results
+
+Show the user a summary table:
+
+```
+## Critic Review Results
+
+### Summary
+- Total findings: X
+- Confirmed: X (Y high, Z medium, W low)
+- False positives: X
+- Pre-existing: X
+- By design: X
+
+### Confirmed Findings
+
+#### HIGH
+[List each confirmed HIGH finding with file, line, issue, and suggested fix]
+
+#### MEDIUM
+[List each confirmed MEDIUM finding]
+
+#### LOW
+[List each confirmed LOW finding]
+
+### Dismissed Findings
+[Brief list of false positives / pre-existing / by-design with one-line explanations]
+```
+
+---
+
+## Important Notes
+
+- **Do NOT fix anything** — this skill only reports. The user decides what to fix.
+- **Validate before presenting** — never show unvalidated claims to the user.
+- **Scope to changes** — pre-existing issues should be noted but clearly labeled.
+- If a critic agent fails or returns no results, note it in the summary.
+- Use `subagent_type: "general-purpose"` for all critic agents.
@@ -58,12 +58,11 @@ export const views = createViews({ Dashboard, ProcessTable, LogStream });
 // server/index.tsx
 import os from "os";
 import { Render } from "@playfast/echoform-render";
-import { Server, useViews, useStream } from "@playfast/echoform/server";
+import { Server, useStream } from "@playfast/echoform/server";
 import { createBunWebSocketServer } from "@playfast/echoform-bun-ws-server";
-import { views, LogStream } from "../shared/views";
+import { Dashboard, ProcessTable, LogStream } from "../shared/views";
 
 function Monitor() {
-  const View = useViews(views);
   const log = useStream(LogStream, "lines");
   const [processes, setProcesses] = useState([]);
 
@@ -76,25 +75,23 @@ function Monitor() {
     return () => clearInterval(interval);
   }, []);
 
-  if (!View) return null;
-
   return (
     <>
-      <View.Dashboard
+      <Dashboard
         hostname={os.hostname()}
         cpuUsage={getCpuUsage()}
         memoryUsed={os.totalmem() - os.freemem()}
         memoryTotal={os.totalmem()}
       />
-      <View.ProcessTable
+      <ProcessTable
         processes={processes}
         onKill={(pid) => {
           process.kill(pid, "SIGTERM");
           log.emit(`Killed PID ${pid}`);
         }}
         onRefresh={() => refresh()}
       />
-      <View.LogStream lines={log} />
+      <LogStream lines={log} />
     </>
   );
 }
@@ -152,16 +149,15 @@ The server reads system data, manages state, handles kill signals. The client is
 
 | Function | Description |
 |----------|-------------|
-| `view(name, config)` | Define a view with input, callbacks, and streams |
+| `view(name, config)` | Define a view — returns a React component usable as JSX on the server |
 | `callback(config?)` | Define a callback with optional input/output schemas |
 | `stream(schema)` | Define a server→client stream with chunk schema |
-| `createViews(record)` | Compose view definitions into a registry |
+| `createViews(record)` | Compose view definitions into a registry (optional, for validation) |
 
 ### Server (`@playfast/echoform/server`)
 
 | Export | Description |
 |--------|-------------|
-| `useViews(viewDefs)` | Get typed view components for rendering |
 | `useStream(viewDef, name)` | Create a `StreamEmitter` for pushing data to clients |
 | `Server` | Root component that manages client connections |