Verification Team

Verification Team — 4-Persona Verification Framework

Purpose: Multi-angle verification of implementation results from 4 frontier engineer perspectives. Use only the lenses relevant to the requested review and changed behavior. Delegate independent, bounded reviews when tools are available and doing so improves coverage or speed; one reviewer may cover several lenses. The names below label perspectives, not impersonated reviewers or attributed findings. Follow verification gates for check scope, evidence reuse, and unavailable-tool handling.

Team Composition

1. Kent Beck — Design Quality & Testing

Questions Kent Beck would ask:

• Were tests written before this code? Or added after implementation?
• Is this the simplest implementation? Are there unnecessary abstractions or future-proofing designs?
• Is there any part that "could be improved by deleting code"? (Simplicity)
• Do the tests document the implementation's intent?
• Is the same thing being said twice? (DRY violation)

Verification checklist:

• Tests exist for new code
• Tests verify behavior, not implementation details
• Shared behavior is unified only when a named consumer or failure justifies it
• Interfaces have minimal surface area
• Error paths are tested

2. Andrej Karpathy — Agent Design & Constraints

Questions Karpathy would ask:

• How much of the agent's context window does this feature consume? (P6 Context Budget)
• Does failure produce the declared recovery or explicit failure outcome? (P4 Ratchet)
• Was "what it cannot do" defined first? (P1 Constraint-based design)
• Would deleting this code make the system better? (P10 Simplicity Selection)
• Is the modification surface area minimized? (P2 Single-file constraint)

Verification checklist (see karpathy-patterns skill):

• Token Guard — Tool results do not explode the context
• Ratchet — Required behavior and coverage gates survive; explain removed tests rather than treating counts as proof
• Constraints stated — Limitations are explicit in code/config
• No over-abstraction — No single-use utilities/helpers
• Time budget — Timeouts exist for infinite loops/recursion

3. Peter Steinberger — Gateway Operations & Plugin Architecture

Questions Steinberger would ask:

• What session key isolates this request? Is there state leakage between sessions?
• Is message routing deterministic (0 LLM calls)? Is it predictable via Binding rules?
• When concurrent requests arrive, are they serialized via Lane Queue, or is there a race condition?
• Does extension follow the existing registry or composition boundary without introducing a duplicate plugin layer?
• Are MCP server processes cleaned up on exit? Are there no orphans?
• Is atomic write (tmp+rename) used? Are state files corruption-safe on crash?

Verification checklist (see openclaw-patterns skill):

• Session Key — Per-request session isolation boundary exists
• Binding — Static routing rules (config hot-reload capable)
• Lane Queue — Serial by default, explicitly parallel principle followed
• Extension — New channels/tools/skills use the owning registration path
• Failover — Only configured and authorized fallback paths run; otherwise preserve the failure
• Lifecycle — start/stop/cleanup explicit, atexit registered

4. Boris Cherny — CLI Agents & Sub-Agents

Questions Cherny would ask:

• Is this tool correctly selected in the while(tool_use) loop? Is the tool description sufficient?
• Is the HITL classification appropriate? Does the WRITE tool have an approval gate?
• Does the sub-agent correctly inherit parent tools/MCP/skills?
• Context window management — does sliding window, clear_tool_uses work?
• Is the prompt clear, unambiguous, and does it guide tool calls?
• Permission model — are dangerous operations requesting user confirmation?

Verification checklist:

• Tool definitions.json includes bilingual descriptions
• SAFE/STANDARD/WRITE/DANGEROUS classification appropriate
• Sub-agent depth limit, token guard configured
• No unnecessary instructions in prompts (minimal surface area)
• MCP tool auto-approve list appropriate
• Clear error messages displayed to user on failure

Verification Execution Method

Research Verification

Select relevant perspectives; require primary-source evidence for external claims and preserve benchmark authority boundaries. The following questions are optional review assignments, not a required four-agent deployment:

  Agent 1 (Beck): "What unnecessary complexity exists in this design?"
  Agent 2 (Karpathy): "What are the constraints and context costs of this feature?"
  Agent 3 (Steinberger): "What operational patterns are missing compared to OpenClaw patterns?"
  Agent 4 (Cherny): "Is this consistent with the AgenticLoop/tool system?"

Implementation Verification

Provide the exact diff and affected invariants to each selected reviewer.
Keep review read-only unless implementation is separately assigned.
Consolidate actionable findings with file/line evidence; omit unused lenses.

Verification Results Format

## Verification Team Review Results

| Reviewer | Findings | Severity | Key Findings |
|----------|----------|----------|--------------|
| <actual reviewer / selected lens> | N items | P0/P1/P2 | ... |

### P0 (Fix immediately)
- ...

### P1 (Fix in this PR)
- ...

### P2 (Follow-up work)
- ...

Adversarial Review Routing

For a consequential document, design, PR, or publication, use the adversarial review procedure when challenging the claims would improve the decision. This is an optional focus for the existing reviewer, not another persona or a mandatory review.

GEODE's built-in reviewer uses the canonical system prompt. Supply the selected perspective and frozen task inputs, not a second system prompt or a copy of its criteria. The Markdown report above is the coordinator's summary; the runtime reviewer keeps its existing JSON output contract.