Walkthrough: Code Review

What This Walkthrough Shows

A single scenario—code review—traced from user intent through governed outcome. You'll see how DaemonCore validates, routes, and constrains agent actions at each step.

Baseline: Without Governance

In a typical setup:

  • User asks an agent to "review this code"
  • Agent interprets the request based on prompt instructions
  • Scope, depth, and output format depend on model interpretation
  • No structural guarantee the agent stays within bounds
  • Results vary between runs, models, and prompt variations

The agent might do a thorough review, a superficial glance, or wander into unrelated refactoring— depending on how it interprets "review."

Step-by-Step with DaemonCore

1

User Intent

The user submits a request:

"Review the authentication module for security issues and code quality."

This is natural language—ambiguous by nature. DaemonCore doesn't try to make the agent "understand better." Instead, it requires the agent to produce a structured response that can be validated.

2

Preflight Classification

Before any action, the request is classified:

Operation Type: CODE_REVIEW
Target Scope: authentication/*
Risk Level: READ_ONLY
Requires Approval: No

If unsafe: Requests that don't map to a known operation type, target files outside permitted scope, or require elevated permissions are flagged before the agent begins work. The user sees a clear rejection with the reason.

3

Action Proposal Shape

The agent produces a protocol-shaped proposal—not free-form text, but a structured object that can be validated:

{
  "action": "code_review",
  "template": "security-review-v1",
  "scope": {
    "include": ["src/auth/**"],
    "exclude": ["src/auth/legacy/**"]
  },
  "checks": ["security", "quality"],
  "output_format": "structured_report"
}

This proposal is validated against the action protocol schema. Malformed proposals are rejected. The agent cannot "decide" to expand scope or skip checks—the structure enforces the boundaries.

4

MAX Bus Routing

The validated proposal becomes a typed message on the MAX bus:

{
  "type": "ACTION_REQUEST",
  "sender": "claude-developer",
  "recipient": "review-executor",
  "payload": { /* validated proposal */ },
  "schema_version": "1.0",
  "timestamp": "2025-01-01T12:00:00Z"
}

Schema validation: Messages that don't match the expected schema are rejected at the bus level. An agent cannot send a malformed message—it simply won't route.

Typed routing: The message type determines which handlers can receive it. A CODE_REVIEW action goes to review executors, not to deployment handlers.

5

Template-Driven Execution

The review executes within template constraints. The security-review-v1 template defines:

Required Checks

  • Input validation patterns
  • Authentication flow integrity
  • Secret handling practices
  • Error exposure risks

Output Structure

  • Findings list with severity
  • Line references for each issue
  • Suggested remediation
  • Summary statistics

Boundaries

  • Read-only file access
  • No code modifications
  • No external API calls
  • Scoped to specified paths

The agent cannot produce a review that skips required checks or includes out-of-scope analysis. The template is the contract.

6

Result

The user receives a structured review report:

Review Complete src/auth/** • 12 files analysed
2 Critical
5 Warnings
8 Suggestions

The output follows the template structure. Every run with the same inputs produces the same output shape. Findings are attributable, auditable, and bounded to scope.

What Happens on a Scope Violation

Suppose during the review, the agent attempts to access files outside the permitted scope:

Attempted access: src/payments/stripe.js
Permitted scope: src/auth/**

ACTION BLOCKED: Scope violation
Reason: File outside permitted review scope
Agent: claude-developer
Timestamp: 2025-01-01T12:01:23Z

The access is blocked at the governance layer—not by asking the agent nicely, but by preventing the operation. The violation is logged with full context for audit.

Prompt Injection: Honest Limitations

V1 Reality

DaemonCore V1 does not prevent prompt injection at the model level. If malicious content in reviewed code attempts to manipulate the agent, the agent might still be influenced.

What V1 does:

  • Detects anomalous outputs: If the agent's response doesn't match the expected protocol shape, it's flagged and rejected.
  • Constrains actions: Even if the agent is manipulated, it cannot perform actions outside its permitted scope. A review agent cannot suddenly deploy code.
  • Logs everything: Unusual patterns are recorded for human review.

This is defence in depth, not prevention. The injection might influence the agent's reasoning, but the governance layer limits what that influence can achieve.

V1 vs V1.5

V1 (Current)

Protocol validation, schema enforcement, template constraints, scope boundaries, audit logging. Defence through structure.

V1.5 (Planned)

Adds cryptographic signing of actions, hardware-backed attestation, and real-time constraint verification. Defence through verification.