bobs-workshop 3.1.1 → 3.1.4

package/src/tools/manual/verify-manual.ts

@@ -1,5 +1,38 @@
 import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool";
 
+const MAX_SYSTEM_CONTENT_LENGTH = 50000;
+
+/**
+ * Sanitize content for safe JSON transmission to kimi model
+ * Handles Unicode issues, control characters, and length limits
+ */
+function sanitizeForModel(content: string, maxLength: number = MAX_SYSTEM_CONTENT_LENGTH): string {
+  if (!content) return "";
+  
+  // Step 1: Remove control characters (keep only \n, \r, \t)
+  let sanitized = content
+    .replace(/[\x00-\x08\x0B-\x0C\x0E-\x1F]/g, '')
+    // Step 2: Replace Unicode line/paragraph separators
+    .replace(/\u2028/g, '\n')
+    .replace(/\u2029/g, '\n')
+    // Step 3: Replace other problematic Unicode
+    .replace(/\uFEFF/g, '') // BOM
+    .replace(/[\u200B-\u200D]/g, '') // Zero-width spaces
+    // Step 4: Escape backslashes to prevent JSON issues
+    .replace(/\\/g, '\\\\')
+    // Step 5: Normalize line endings
+    .replace(/\r\n/g, '\n')
+    .replace(/\r/g, '\n');
+  
+  // Step 6: Truncate if too long (with indicator)
+  if (sanitized.length > maxLength) {
+    const truncationMsg = "\n\n[Content truncated due to length limits]";
+    sanitized = sanitized.substring(0, maxLength - truncationMsg.length) + truncationMsg;
+  }
+  
+  return sanitized;
+}
+
 const VerifyManualTool: ToolDefinition = tool({
   description: "Run bob-rev verification in background for a MANUAL",
   args: {
@@ -27,24 +60,29 @@ const VerifyManualTool: ToolDefinition = tool({
     let manualContent = "";
     if (existsSync(args.manual_path)) {
       manualContent = readFileSync(args.manual_path, "utf8");
-      // Sanitize content to prevent JSON parsing issues with kimi model
-      manualContent = manualContent
-        .replace(/[\x00-\x08\x0B-\x0C\x0E-\x1F]/g, '') // Remove control chars except \n, \r, \t
-        .replace(/\u2028/g, '\n') // Replace line separator with newline
-        .replace(/\u2029/g, '\n'); // Replace paragraph separator with newline
+      // Sanitize content for kimi model compatibility
+      manualContent = sanitizeForModel(manualContent, 30000);
     }
     
     const skillPath = join(directory, ".opencode", "agent", "bobs-workshop", "bob-rev.md");
     let agentPrompt = "You are bob-rev, a reviewer agent that verifies implementation against MANUAL requirements.";
     if (existsSync(skillPath)) {
       agentPrompt = readFileSync(skillPath, "utf8");
+      // Sanitize agent prompt as well
+      agentPrompt = sanitizeForModel(agentPrompt, 20000);
     }
     
+    // Build and sanitize system prompt
+    const systemPrompt = sanitizeForModel(
+      `${agentPrompt}\n\n## MANUAL to Verify:\n${manualContent}`,
+      MAX_SYSTEM_CONTENT_LENGTH
+    );
+    
     await (client as { session: { prompt: (args: unknown) => Promise<unknown> } }).session.prompt({
       path: { id: createData.data.id },
       body: {
         agent: "bob-rev",
-        system: `${agentPrompt}\n\n## MANUAL to Verify:\n${manualContent}`,
+        system: systemPrompt,
         tools: {
           task: false,
           delegate_task: false,

package/src/skills/verification/SKILL.md

@@ -1,286 +0,0 @@
----
-name: verification
-description: Evidence-based verification methodology. SEE code working, do not just trust tests. Use when shipping code, final verification, output validation, evidence gathering. CRITICAL: Evidence before assertions.
-metadata:
-  recommended_for: bob-send
-  category: verification
----
-
-# Evidence-Based Verification Skill
-
-## Core Philosophy
-
-> "Evidence before assertions. Always."
-
-Never claim code works without **seeing** it work. Tests passing is not enough. You must SEE the output.
-
-## When to Use
-
-Use this skill during the SEND phase or any final verification:
-- Before shipping code
-- When validating implementation works
-- When gathering evidence for review
-- When tests pass but you need runtime proof
-
-## The Three Laws
-
-1. **See it working** - Screenshots, curl responses, CLI output. Actual evidence.
-2. **Human checkpoint** - No auto-shipping. Human reviews evidence and decides.
-3. **Fallback hierarchy** - If primary method fails, try the next method down.
-
-## Project Type Detection
-
-First, detect what type of project you're verifying:
-
-| Detection Pattern | Project Type | Primary Method |
-|-------------------|--------------|----------------|
-| package.json + src/app or pages/ | Web app | Screenshot + test flows |
-| package.json + routes or controllers/ | API | Curl endpoints |
-| Cargo.toml + src/main.rs with clap | CLI | Run commands |
-| pyproject.toml + `__main__.py` | CLI | Run commands |
-| `**/lib.rs` or `setup.py` | Library | Run examples |
-| Dockerfile or docker-compose.yml | Service | Health check + logs |
-
-## Verification Methods
-
-### Web Applications
-
-```bash
-# 1. Start dev server
-npm run dev &
-SERVER_PID=$!
-
-# 2. Wait for server (max 30s)
-sleep 5  # or: until curl -s http://localhost:3000 > /dev/null
-
-# 3. Verify key pages load
-curl -s http://localhost:3000 | head -20
-
-# 4. Check for errors (if browser available, take screenshots)
-
-# 5. Cleanup
-kill $SERVER_PID
-```
-
-**Evidence to capture:**
-- Screenshots of key pages (if browser available)
-- HTML response showing expected content
-- Console errors (if any)
-
-### Browser Verification (Playwright)
-
-For web applications, use Playwright for comprehensive browser verification:
-
-**Capabilities:**
-- **Verification**: Ensure web elements are present and functional
-- **Browsing**: Navigate through web pages to gather information
-- **Web Scraping**: Extract data from websites
-- **Testing**: Run end-to-end tests
-- **Screenshots**: Capture visual evidence of web states
-
-**Usage:**
-When a task involves browser interactions, use Playwright MCP tools:
-```bash
-# Navigate to page
-playwright_browser_navigate(url="http://localhost:3000")
-
-# Take screenshot
-playwright_browser_take_screenshot(filename="homepage.png", type="png")
-
-# Interact with elements
-playwright_browser_click(ref="submit-button")
-
-# Verify element present
-playwright_browser_snapshot()
-```
-
-**Best practices:**
-- Capture screenshots before and after interactions
-- Verify console for errors
-- Test across different viewport sizes
-- Document all browser-based evidence
-
-### APIs
-
-```bash
-# 1. Start server
-npm start &
-sleep 3
-
-# 2. Test key endpoints
-curl -s -w "%{http_code}" http://localhost:3000/api/health
-curl -s -X POST http://localhost:3000/api/[endpoint] \
-  -H "Content-Type: application/json" \
-  -d '{"test": true}'
-
-# 3. Verify response shapes match spec
-```
-
-**Evidence to capture:**
-- Status codes for each endpoint
-- Response bodies (truncated if large)
-- Error responses
-
-### CLI Tools
-
-```bash
-# 1. Test help
-./cli --help
-echo "Exit code: $?"
-
-# 2. Test primary commands
-./cli [command] test-input.txt
-echo "Exit code: $?"
-
-# 3. Test error handling
-./cli [command] nonexistent.txt
-echo "Exit code: $?"  # Should be non-zero
-```
-
-**Evidence to capture:**
-- Command output (stdout)
-- Error output (stderr)
-- Exit codes
-
-### Libraries
-
-```bash
-# 1. Run tests (confirm they pass)
-npm test
-
-# 2. Run examples from documentation
-node examples/basic-usage.js
-
-# 3. Check types compile
-npm run typecheck
-```
-
-**Evidence to capture:**
-- Example output
-- Test coverage summary
-
-## Fallback Hierarchy
-
-If primary method fails, fall back in order:
-
-```
-1. Full runtime (screenshot/curl/run) ─ FAILED
-   │
-   └─► 2. Integration tests ─ FAILED
-       │
-       └─► 3. Unit tests + examples ─ FAILED
-           │
-           └─► 4. Type check + lint only ─ FAILED
-               │
-               └─► 5. Code review only (last resort)
-                   └─► Report: "Unable to verify runtime behavior"
-```
-
-**Always record:**
-- Which method was attempted
-- Why it failed
-- Which fallback was used
-
-## Timeout Handling
-
-**30-second timeout per verification method.**
-
-If method times out:
-1. Kill the process
-2. Log the timeout
-3. Try fallback method
-
-## Evidence Storage
-
-Document evidence in MANUAL Verification Logs:
-
-```markdown
-## ✅ Verification Evidence
-
-### Runtime Verification
-**Project Type**: web
-**Method Used**: curl + HTML inspection
-**Fallback Level**: Primary (no fallback needed)
-
-### Evidence Captured
-1. **Homepage**: Returns 200, contains expected title
-2. **API Health**: /api/health returns {"status": "ok"}
-3. **Login Flow**: Form renders, submits correctly
-
-### Screenshots/Output
-- [Describe what was observed]
-- [Key behaviors verified]
-
-### Result: ✅ VERIFIED
-```
-
-## Red Flags — STOP and Reassess
-
-If you're thinking any of these, you're about to violate the methodology:
-
-- "Tests pass, that's good enough" → **NO. SEE it working.**
-- "I'll verify after shipping" → **NO. Verify BEFORE ship.**
-- "The type checker caught everything" → **NO. Types don't catch runtime issues.**
-- "Screenshot failed but it probably works" → **NO. "Probably" isn't evidence.**
-- "It should work because..." → **NO. SHOW it works.**
-- "Evidence isn't necessary for this change" → **NO. Every change gets verified.**
-
-## Rationalizations to Resist
-
-| Excuse | Reality |
-|--------|---------|
-| "Tests pass" | Tests aren't enough. SEE it working. |
-| "Type checker caught everything" | Types don't catch runtime issues. |
-| "It worked before" | Prove it works NOW. |
-| "Human checkpoint is formality" | Human checkpoint is the gate. |
-| "Code review is enough" | Code review is last resort fallback. |
-| "Tests are flaky, ignore failure" | Flaky tests hide real failures. Fix or accept with caveat. |
-
-## Flaky Test Detection
-
-```
-Test fails?
-├── Re-run failed tests
-├── Pass 2nd time?
-│   └── Yes → Note flakiness, accept with caveat
-└── Fail 2nd time?
-    ├── Run isolated
-    └── Still fail? → Real failure, must fix
-```
-
-## Output Format
-
-When verification completes:
-
-```markdown
-### Verification Summary
-
-| Check | Status | Method | Notes |
-|-------|--------|--------|-------|
-| Build | ✅ | npm run build | No errors |
-| Lint | ✅ | npm run lint | 0 issues |
-| Tests | ✅ | npm test | 47/47 passed |
-| Runtime | ✅ | curl + inspect | Evidence captured |
-
-### Evidence
-- Homepage renders correctly (verified via curl)
-- API returns expected responses
-- No console errors observed
-
-### Result: ✅ ALL CHECKS PASS + EVIDENCE GATHERED
-```
-
-## Anti-Patterns
-
-**Don't do these:**
-
-- Trusting test results without seeing code run
-- Skipping output verification because "tests pass"
-- Proceeding when verification method fails without fallback
-- Modifying code after verification passes (invalidates verification)
-- Ignoring flaky test warnings
-- Auto-approving without human checkpoint
-
----
-
-**Remember**: You are gathering EVIDENCE. The human decides if it ships. Your job is to SEE the code work and document what you observed.