# Red Team System Specification

## Overview

The Red Team system is an adversarial review feature for makima contracts that provides real-time quality assurance during task execution. When enabled, a parallel "red team" task instance monitors the output of work tasks, verifying that implementations adhere to the contract requirements, repository standards, and the execution plan.

### Goals

1. **Quality Assurance**: Catch deviations from the plan before they compound
2. **Standards Compliance**: Ensure code follows repository conventions (CONTRIBUTING.md, linting rules, etc.)
3. **Contract Adherence**: Verify implementations match the specification and requirements
4. **Proactive Issue Detection**: Flag potential problems early, not after task completion

### Non-Goals

1. The red team should NOT write code or make commits
2. The red team should NOT be overly pedantic or block progress for minor style issues
3. The red team is NOT a replacement for code review - it's an early warning system

---

## 1. Feature Overview

### 1.1 Concept

The Red Team operates as a parallel observer task that:
- Monitors all work task outputs in real-time via the broadcast system
- Has read-only access to task diffs and outputs
- Can access contract specifications, plans, and repository standards
- Can notify the supervisor when it detects issues requiring attention

### 1.2 Relationship to Existing Components

```
┌─────────────────────────────────────────────────────────────┐
│                       Contract                               │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐  │
│  │  Supervisor  │    │  Work Task 1 │    │  Work Task 2 │  │
│  │              │<───│              │    │              │  │
│  │              │<───│              │    │              │  │
│  └──────────────┘    └──────────────┘    └──────────────┘  │
│         ^                   │                   │           │
│         │              outputs             outputs          │
│         │                   │                   │           │
│    [NOTIFY]                 v                   v           │
│         │            ┌─────────────────────────────┐        │
│         └────────────│       Red Team Task         │        │
│                      │  (Monitoring & Validation)  │        │
│                      └─────────────────────────────┘        │
└─────────────────────────────────────────────────────────────┘
```

### 1.3 Task Type

The Red Team task is a special task variant with the following characteristics:
- `is_red_team: true` flag on the Task model
- Has tool key for API access (like supervisor tasks)
- Does NOT have write permissions to the repository
- Subscribes to task output broadcasts
- Can use `makima red-team notify` command to alert supervisor

---

## 2. Contract Configuration

### 2.1 Contract Model Changes

Add the following field to the `Contract` model in `makima/src/db/models.rs`:

```rust
/// Contract record from the database
#[derive(Debug, Clone, FromRow, Serialize, ToSchema)]
#[serde(rename_all = "camelCase")]
pub struct Contract {
    // ... existing fields ...

    /// Whether to spawn a red team task to monitor work tasks.
    /// When enabled, a parallel task monitors outputs and can alert
    /// the supervisor about potential issues.
    #[serde(default)]
    pub red_team_enabled: bool,

    /// Optional custom prompt/criteria for the red team to use
    /// when evaluating task outputs. If not provided, uses default
    /// quality criteria.
    #[serde(skip_serializing_if = "Option::is_none")]
    pub red_team_prompt: Option<String>,
}
```

### 2.2 CreateContractRequest Changes

```rust
#[derive(Debug, Clone, Deserialize, ToSchema)]
#[serde(rename_all = "camelCase")]
pub struct CreateContractRequest {
    // ... existing fields ...

    /// Enable red team monitoring for this contract.
    /// When enabled, a parallel task monitors work task outputs
    /// and can alert the supervisor about potential issues.
    #[serde(default)]
    pub red_team_enabled: Option<bool>,

    /// Optional custom criteria for the red team to evaluate.
    /// Examples: "Focus on security vulnerabilities",
    /// "Ensure all functions have tests", etc.
    pub red_team_prompt: Option<String>,
}
```

### 2.3 CLI Flag for Contract Creation

The daemon CLI should support red team enablement during contract creation:

```bash
# Enable red team with default criteria
makima supervisor create --red-team "Contract Name" "Description"

# Enable red team with custom review criteria
makima supervisor create --red-team --red-team-prompt "Focus on performance and memory usage" "Contract Name" "Description"
```

---

## 3. Red Team Task Lifecycle

### 3.1 Spawning

The red team task is spawned automatically when:
1. A contract has `red_team_enabled: true`
2. The first work task is spawned (not the supervisor itself)

**Spawn Logic** (in `spawn_task` handler or supervisor spawn logic):

```rust
// In spawn_task after creating a work task:
if contract.red_team_enabled && !is_supervisor_task {
    // Check if red team task already exists
    let existing_red_team = repository::get_red_team_task_for_contract(pool, contract_id).await?;

    if existing_red_team.is_none() {
        // Spawn red team task
        let red_team_task = spawn_red_team_task(
            pool,
            state,
            contract_id,
            owner_id,
            contract.red_team_prompt.as_deref(),
        ).await?;

        tracing::info!(
            contract_id = %contract_id,
            red_team_task_id = %red_team_task.id,
            "Spawned red team task for contract"
        );
    }
}
```

### 3.2 Task Properties

When creating the red team task:

```rust
CreateTaskRequest {
    name: "Red Team Monitor".to_string(),
    description: Some("Adversarial review task monitoring work task outputs".to_string()),
    plan: generate_red_team_plan(contract, custom_prompt),
    contract_id: Some(contract_id),
    parent_task_id: None,  // Not a child of supervisor
    is_supervisor: false,
    is_red_team: true,     // NEW FIELD
    // ... other fields ...
}
```

### 3.3 Lifespan

The red team task:
- Lives for the duration of the **execute phase**
- Is automatically terminated when:
  - The contract advances past the execute phase
  - The contract is completed
  - The contract is archived
- Can be paused/resumed along with other contract tasks
- Does NOT restart automatically after daemon failure (not critical path)

### 3.4 Read-Only Enforcement

The red team task:
- Has NO worktree of its own (or a read-only clone)
- Cannot use git operations (commit, branch, etc.)
- Can only READ files, not write them
- Has API access limited to read operations

---

## 4. Red Team Notification CLI Command

### 4.1 Command Specification

New CLI command available only to red team tasks:

```bash
makima red-team notify "<message>"
```

**Arguments:**
- `<message>`: A detailed description of the issue detected

**Options:**
- `--severity <level>`: Issue severity: `low`, `medium`, `high`, `critical` (default: `medium`)
- `--task <task_id>`: The specific task this relates to (optional)
- `--file <path>`: The file path where the issue was detected (optional)
- `--context <text>`: Additional context about the issue (optional)

**Example:**

```bash
makima red-team notify "Task is adding console.log statements which violates the no-debug-logging rule in CONTRIBUTING.md" \
  --severity medium \
  --task 550e8400-e29b-41d4-a716-446655440000 \
  --file "src/api/handler.rs"
```

### 4.2 CLI Arguments Structure

```rust
// In makima/src/daemon/cli/mod.rs

/// Red Team subcommand - red team task commands.
#[derive(Subcommand, Debug)]
pub enum RedTeamCommand {
    /// Send a notification to the supervisor about a detected issue.
    /// Only available to red team tasks.
    Notify(NotifyArgs),
}

/// Arguments for red-team notify command.
#[derive(Args, Debug)]
pub struct NotifyArgs {
    /// API URL
    #[arg(long, env = "MAKIMA_API_URL", default_value = "https://api.makima.jp")]
    pub api_url: String,

    /// API key for authentication
    #[arg(long, env = "MAKIMA_API_KEY")]
    pub api_key: String,

    /// Current task ID (must be a red team task)
    #[arg(long, env = "MAKIMA_TASK_ID")]
    pub task_id: Uuid,

    /// Contract ID
    #[arg(long, env = "MAKIMA_CONTRACT_ID")]
    pub contract_id: Uuid,

    /// The notification message
    #[arg(index = 1)]
    pub message: String,

    /// Severity level: low, medium, high, critical
    #[arg(long, default_value = "medium")]
    pub severity: String,

    /// Related task ID (optional)
    #[arg(long)]
    pub task: Option<Uuid>,

    /// Related file path (optional)
    #[arg(long)]
    pub file: Option<String>,

    /// Additional context (optional)
    #[arg(long)]
    pub context: Option<String>,
}
```

### 4.3 API Endpoint

**POST** `/api/v1/mesh/red-team/notify`

**Request Body:**
```json
{
  "message": "Issue description",
  "severity": "medium",
  "relatedTaskId": "uuid-optional",
  "filePath": "src/path/optional.rs",
  "context": "Additional context optional"
}
```

**Response:**
```json
{
  "notificationId": "uuid",
  "delivered": true,
  "supervisorTaskId": "uuid"
}
```

### 4.4 Notification Delivery

When a red team notification is received:

1. **Validate Caller**: Ensure the request comes from a valid red team task
2. **Find Supervisor**: Get the supervisor task for the contract
3. **Format Message**: Create an `[ACTION REQUIRED]` formatted message
4. **Send to Supervisor**: Inject the message into the supervisor's stdin via `SendMessage` command

**Message Format:**

```
════════════════════════════════════════════════════════════════
[RED TEAM ALERT] Severity: MEDIUM
════════════════════════════════════════════════════════════════

Issue: Task is adding console.log statements which violates the
no-debug-logging rule in CONTRIBUTING.md

Related Task: 550e8400-e29b-41d4-a716-446655440000
File: src/api/handler.rs

Context: The CONTRIBUTING.md file explicitly states that debug
logging should use the tracing crate, not console.log or println!

════════════════════════════════════════════════════════════════
You can:
- Pause the related task to investigate
- Send feedback to the task to correct the issue
- Acknowledge this alert and continue monitoring
════════════════════════════════════════════════════════════════
```

### 4.5 Supervisor Response Handling

The supervisor can respond to red team notifications by:
1. **Pausing the task**: `makima supervisor pause <task_id>`
2. **Sending feedback**: `makima supervisor message <task_id> "Please use tracing instead of console.log"`
3. **Acknowledging**: Simply continue (the red team will keep monitoring)
4. **Dismissing**: Mark the alert as false positive (future consideration)

---

## 5. Red Team Access Patterns

### 5.1 Task Output Subscription

The red team task subscribes to the `task_outputs` broadcast channel:

```rust
// In red team task initialization
let mut task_output_rx = state.task_outputs.subscribe();

loop {
    match task_output_rx.recv().await {
        Ok(notification) => {
            // Only process outputs from work tasks in our contract
            if notification.contract_id == Some(self.contract_id)
               && !notification.is_supervisor
               && !notification.is_red_team {
                self.analyze_output(notification).await;
            }
        }
        Err(e) => {
            tracing::warn!("Red team task output subscription error: {}", e);
        }
    }
}
```

### 5.2 Task Diff Access

The red team can request diffs via the supervisor API:

**GET** `/api/v1/mesh/supervisor/tasks/{task_id}/diff`

This endpoint already exists and can be used by the red team (with tool key auth).

### 5.3 Contract Information Access

The red team can read:
- Contract plan and specifications (via contract files)
- Repository standards (CONTRIBUTING.md, .editorconfig, etc.)
- Task descriptions and plans

**Existing endpoints used:**
- `GET /api/v1/contracts/{id}` - Contract details
- `GET /api/v1/contracts/{id}/files` - Contract files
- `GET /api/v1/files/{id}` - File content

### 5.4 Repository File Access

For repository standards, the red team uses the existing daemon file read capability:

```bash
# Via makima CLI (from within the red team task)
makima supervisor read-file <task_id> "CONTRIBUTING.md"
makima supervisor read-file <task_id> ".editorconfig"
makima supervisor read-file <task_id> "rustfmt.toml"
```

Or direct filesystem access if the red team has a read-only worktree clone.

---

## 6. System Prompt for Red Team Task

The red team task receives a specialized system prompt that guides its behavior:

```markdown
# Red Team Monitor

You are an adversarial quality reviewer for a software development contract. Your role is to monitor work task outputs in real-time and flag potential issues BEFORE they compound into larger problems.

## Your Mission

Monitor all task outputs and verify:
1. **Plan Adherence**: Are tasks following the implementation plan?
2. **Code Quality**: Does the code meet repository standards?
3. **Contract Requirements**: Does the implementation match the specification?
4. **Best Practices**: Are there obvious anti-patterns or issues?

## Access Available

You have read-only access to:
- Task outputs (streamed in real-time)
- Task diffs (code changes)
- Contract specifications and plan documents
- Repository configuration files (CONTRIBUTING.md, linting configs, etc.)

## How to Monitor

1. **Subscribe to task outputs**: You'll receive outputs from all work tasks
2. **Analyze code changes**: Request diffs for completed tasks
3. **Cross-reference**: Compare outputs against the plan and specifications
4. **Report issues**: Use `makima red-team notify` when you detect problems

## When to Notify

NOTIFY the supervisor when you observe:
- **Critical**: Security vulnerabilities, data loss risks, breaking changes
- **High**: Significant deviations from the plan, major code quality issues
- **Medium**: Missing tests, suboptimal implementations, minor standard violations
- **Low**: Style inconsistencies, documentation gaps (use sparingly)

## What NOT to Do

- Do NOT nitpick minor style issues (that's what linters are for)
- Do NOT block progress for trivial concerns
- Do NOT write code or make changes yourself
- Do NOT notify for things that are already in progress and being addressed
- Do NOT create duplicate notifications for the same issue

## Notification Format

When notifying, always include:
1. A clear, concise description of the issue
2. The severity level (critical/high/medium/low)
3. The related task ID if applicable
4. The specific file or code location if known
5. Why this matters (reference to plan, spec, or standards)

## Example Notification

```
makima red-team notify "Task is implementing authentication with plaintext password storage, which contradicts the security requirements in the specification document" \
  --severity critical \
  --task <task_id> \
  --file "src/auth/user.rs" \
  --context "Specification section 3.2 requires bcrypt hashing for all passwords"
```

## Custom Review Criteria

{{#if red_team_prompt}}
Additional review criteria for this contract:
{{red_team_prompt}}
{{/if}}

## Contract Context

Contract: {{contract_name}}
Phase: {{contract_phase}}
Repository: {{repository_url}}

Focus your monitoring on outputs that relate to the active work tasks. Prioritize issues that could affect the success of the contract or introduce technical debt.
```

---

## 7. API Changes Summary

### 7.1 New Endpoints

| Method | Path | Description |
|--------|------|-------------|
| POST | `/api/v1/mesh/red-team/notify` | Send notification from red team to supervisor |
| GET | `/api/v1/mesh/red-team/status` | Get red team task status for a contract |

### 7.2 Modified Endpoints

| Method | Path | Change |
|--------|------|--------|
| POST | `/api/v1/contracts` | Add `red_team_enabled` and `red_team_prompt` fields |
| GET | `/api/v1/contracts/{id}` | Include red team task info in response |

### 7.3 New Request/Response Types

**RedTeamNotifyRequest:**
```rust
#[derive(Debug, Deserialize, ToSchema)]
#[serde(rename_all = "camelCase")]
pub struct RedTeamNotifyRequest {
    pub message: String,
    #[serde(default = "default_severity")]
    pub severity: String,
    pub related_task_id: Option<Uuid>,
    pub file_path: Option<String>,
    pub context: Option<String>,
}
```

**RedTeamNotifyResponse:**
```rust
#[derive(Debug, Serialize, ToSchema)]
#[serde(rename_all = "camelCase")]
pub struct RedTeamNotifyResponse {
    pub notification_id: Uuid,
    pub delivered: bool,
    pub supervisor_task_id: Uuid,
}
```

**RedTeamStatusResponse:**
```rust
#[derive(Debug, Serialize, ToSchema)]
#[serde(rename_all = "camelCase")]
pub struct RedTeamStatusResponse {
    pub contract_id: Uuid,
    pub red_team_task_id: Option<Uuid>,
    pub status: Option<String>,
    pub notifications_sent: i32,
    pub last_activity: Option<DateTime<Utc>>,
}
```

---

## 8. Database Schema Changes

### 8.1 Contracts Table

```sql
ALTER TABLE contracts
ADD COLUMN red_team_enabled BOOLEAN NOT NULL DEFAULT FALSE,
ADD COLUMN red_team_prompt TEXT;
```

### 8.2 Tasks Table

```sql
ALTER TABLE tasks
ADD COLUMN is_red_team BOOLEAN NOT NULL DEFAULT FALSE;
```

### 8.3 Red Team Notifications Table (New)

```sql
CREATE TABLE red_team_notifications (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    contract_id UUID NOT NULL REFERENCES contracts(id) ON DELETE CASCADE,
    red_team_task_id UUID NOT NULL REFERENCES tasks(id) ON DELETE CASCADE,
    related_task_id UUID REFERENCES tasks(id) ON DELETE SET NULL,

    message TEXT NOT NULL,
    severity VARCHAR(20) NOT NULL DEFAULT 'medium',
    file_path TEXT,
    context TEXT,

    -- Delivery status
    delivered BOOLEAN NOT NULL DEFAULT FALSE,
    delivered_at TIMESTAMP WITH TIME ZONE,
    acknowledged BOOLEAN NOT NULL DEFAULT FALSE,
    acknowledged_at TIMESTAMP WITH TIME ZONE,

    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

-- Indexes
CREATE INDEX idx_red_team_notifications_contract_id ON red_team_notifications(contract_id);
CREATE INDEX idx_red_team_notifications_red_team_task_id ON red_team_notifications(red_team_task_id);
CREATE INDEX idx_red_team_notifications_created_at ON red_team_notifications(created_at DESC);
```

### 8.4 Index for Red Team Task Lookup

```sql
CREATE INDEX idx_tasks_contract_red_team ON tasks(contract_id, is_red_team)
WHERE is_red_team = TRUE;
```

---

## 9. Implementation Phases

### Phase 1: Foundation (MVP)
- [ ] Add `red_team_enabled` and `red_team_prompt` to Contract model
- [ ] Add `is_red_team` to Task model
- [ ] Database migrations
- [ ] Basic red team task spawning logic
- [ ] `makima red-team notify` CLI command
- [ ] Red team notification API endpoint

### Phase 2: Monitoring Infrastructure
- [ ] Task output subscription for red team
- [ ] Diff access for red team tasks
- [ ] Red team system prompt generation
- [ ] Notification delivery to supervisor

### Phase 3: Polish & UX
- [ ] Red team status in contract view
- [ ] Notification history and acknowledgment
- [ ] TUI integration for red team alerts
- [ ] Frontend display of red team notifications

### Phase 4: Future Enhancements
- [ ] Configurable notification thresholds
- [ ] Automatic pause on critical issues
- [ ] Red team notification digest/summary
- [ ] Integration with external code review tools

---

## 10. Security Considerations

### 10.1 Access Control

- Red team tasks MUST only have read access
- Verify `is_red_team` flag before allowing notification API calls
- Red team cannot spawn tasks or modify contract state
- Tool key scope should be limited for red team tasks

### 10.2 Abuse Prevention

- Rate limit red team notifications (max 10 per minute per task)
- Prevent notification spam with deduplication
- Log all red team activities for audit

### 10.3 Isolation

- Red team task runs in separate worktree (or no worktree)
- Cannot affect work task execution directly
- Supervisor controls whether to act on notifications

---

## 11. Testing Strategy

### 11.1 Unit Tests

- Contract model serialization with red team fields
- Red team task spawning conditions
- Notification message formatting

### 11.2 Integration Tests

- Full contract lifecycle with red team enabled
- Notification delivery to supervisor
- Red team output subscription

### 11.3 E2E Tests

- Create contract with `--red-team` flag
- Red team detects intentional violation
- Supervisor receives and responds to notification

---

## 12. Success Metrics

1. **Detection Rate**: Percentage of issues caught by red team before task completion
2. **False Positive Rate**: Percentage of notifications that are dismissed as not actionable
3. **Response Time**: Time between red team detection and supervisor acknowledgment
4. **Contract Success Rate**: Compare success rates for contracts with/without red team

---

## Appendix A: Message Protocol

### Task Output Notification Structure

The red team subscribes to `TaskOutputNotification`:

```rust
pub struct TaskOutputNotification {
    pub task_id: Uuid,
    pub owner_id: Option<Uuid>,
    pub message_type: String,      // "assistant", "tool_use", "tool_result", etc.
    pub content: String,
    pub tool_name: Option<String>,
    pub tool_input: Option<serde_json::Value>,
    pub is_error: Option<bool>,
    pub cost_usd: Option<f64>,
    pub duration_ms: Option<u64>,
    pub is_partial: bool,
}
```

### Daemon Command for Supervisor Message

```rust
DaemonCommand::SendMessage {
    task_id: supervisor_id,
    message: formatted_red_team_alert,
}
```

---

## Appendix B: Configuration Examples

### Contract Creation with Red Team (API)

```json
POST /api/v1/contracts
{
  "name": "Implement User Authentication",
  "description": "Add OAuth2 authentication flow",
  "contract_type": "specification",
  "red_team_enabled": true,
  "red_team_prompt": "Pay special attention to security best practices and OWASP guidelines. Flag any hardcoded secrets or insecure token handling."
}
```

### Contract Creation with Red Team (CLI)

```bash
makima contract create \
  --type specification \
  --red-team \
  --red-team-prompt "Focus on API backwards compatibility and deprecation handling" \
  "API v2 Migration" \
  "Migrate public API from v1 to v2"
```