Files
stack/docs/scratchpads/orch-124-task-config.md
Jason Woltje 12abdfe81d feat(#93): implement agent spawn via federation
Implements FED-010: Agent Spawn via Federation feature that enables
spawning and managing Claude agents on remote federated Mosaic Stack
instances via COMMAND message type.

Features:
- Federation agent command types (spawn, status, kill)
- FederationAgentService for handling agent operations
- Integration with orchestrator's agent spawner/lifecycle services
- API endpoints for spawning, querying status, and killing agents
- Full command routing through federation COMMAND infrastructure
- Comprehensive test coverage (12/12 tests passing)

Architecture:
- Hub → Spoke: Spawn agents on remote instances
- Command flow: FederationController → FederationAgentService →
  CommandService → Remote Orchestrator
- Response handling: Remote orchestrator returns agent status/results
- Security: Connection validation, signature verification

Files created:
- apps/api/src/federation/types/federation-agent.types.ts
- apps/api/src/federation/federation-agent.service.ts
- apps/api/src/federation/federation-agent.service.spec.ts

Files modified:
- apps/api/src/federation/command.service.ts (agent command routing)
- apps/api/src/federation/federation.controller.ts (agent endpoints)
- apps/api/src/federation/federation.module.ts (service registration)
- apps/orchestrator/src/api/agents/agents.controller.ts (status endpoint)
- apps/orchestrator/src/api/agents/agents.module.ts (lifecycle integration)

Testing:
- 12/12 tests passing for FederationAgentService
- All command service tests passing
- TypeScript compilation successful
- Linting passed

Refs #93

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-02-03 14:37:06 -06:00

256 lines
6.5 KiB
Markdown

# Issue ORCH-124: Gate configuration per-task
## Objective
Implement per-task quality gate configuration allowing different quality gates for different task types. Different requirements for worker, reviewer, and tester agents with configurable gate thresholds per task type.
## Approach
### 1. Define Gate Profile Types
- **Strict Profile**: All gates (typecheck, lint, tests, coverage, build, integration, AI review)
- **Standard Profile**: tests + lint + typecheck + coverage
- **Minimal Profile**: tests only
- **Custom Profile**: User-defined gate selection
### 2. Configuration Structure
```typescript
interface GateProfile {
name: "strict" | "standard" | "minimal" | "custom";
gates: {
typecheck?: boolean;
lint?: boolean;
tests?: boolean;
coverage?: { enabled: boolean; threshold?: number };
build?: boolean;
integration?: boolean;
aiReview?: boolean;
};
}
interface TaskGateConfig {
taskId: string;
agentType: "worker" | "reviewer" | "tester";
profile: GateProfile;
}
```
### 3. Implementation Plan
#### Phase 1: Types and Interfaces
- Create gate profile types
- Create task gate configuration interface
- Define default profiles
#### Phase 2: Gate Configuration Service
- Service to manage gate configurations
- Get configuration for task
- Validate gate configuration
- Apply profile to task
#### Phase 3: Integration with Quality Gates Service
- Update QualityGatesService to use task configuration
- Pass gate requirements to coordinator
- Filter gates based on configuration
#### Phase 4: API Integration
- Add gateConfig to SpawnAgentDto
- Store gate configuration with task metadata
- Retrieve configuration during quality checks
## Progress
- [x] Create scratchpad
- [x] Define types and interfaces
- [x] Write tests for GateConfigService (TDD - RED phase)
- [x] Implement GateConfigService (TDD - GREEN phase)
- [x] Integrate with QualityGatesService
- [x] Update SpawnAgentDto
- [x] All tests passing
- [x] Coverage >= 85%
## Testing
### Unit Tests
1. ✅ GateConfigService tests
- Get default configuration for agent types
- Apply profile to task
- Validate gate configuration
- Custom gate configuration
- Invalid profile handling
2. ✅ QualityGatesService integration tests
- Use task-specific gate configuration
- Skip gates not in configuration
- Apply coverage threshold from config
- YOLO mode overrides gate config
### Test Coverage
- Target: >= 85%
- Actual: Will verify after implementation
## Notes
### Design Decisions
1. **Profile-Based Configuration**: Use predefined profiles (strict, standard, minimal) for ease of use, with custom option for flexibility.
2. **Default Behavior**:
- Worker agents: Standard profile (tests + lint + typecheck + coverage)
- Reviewer agents: Strict profile (all gates including AI review)
- Tester agents: Minimal profile (tests only)
3. **Gate Selection**: Configuration specifies which gates to run, not which to skip. This is more explicit and safer.
4. **Coverage Threshold**: Can be customized per task (default 85%).
5. **Integration Pattern**: GateConfigService provides configuration, QualityGatesService enforces it by passing requirements to coordinator.
### Implementation Notes
- Gate configuration is immutable once task is created (stored with task metadata)
- YOLO mode bypasses all gate configurations
- Invalid configurations fall back to safe defaults
- Configuration validation happens at spawn time, not at check time
- Coordinator receives gate requirements and runs only requested gates
### Examples
**Strict Profile (All Gates)**:
```typescript
{
profile: 'strict',
gates: {
typecheck: true,
lint: true,
tests: true,
coverage: { enabled: true, threshold: 85 },
build: true,
integration: true,
aiReview: true
}
}
```
**Standard Profile (Core Gates)**:
```typescript
{
profile: 'standard',
gates: {
typecheck: true,
lint: true,
tests: true,
coverage: { enabled: true, threshold: 85 }
}
}
```
**Minimal Profile (Tests Only)**:
```typescript
{
profile: 'minimal',
gates: {
tests: true
}
}
```
**Custom Profile (Docs Task)**:
```typescript
{
profile: 'custom',
gates: {
lint: true,
tests: false, // No tests required for docs
coverage: { enabled: false }
}
}
```
## Completion Criteria
- [x] Types defined for gate profiles and configurations
- [x] GateConfigService implemented with default profiles
- [x] QualityGatesService updated to use gate configuration
- [x] SpawnAgentDto extended with optional gateConfig
- [x] Unit tests written and passing (TDD)
- [x] Test coverage >= 85% (Achieved: 98.3% for coordinator module)
- [x] Create Gitea issue
- [x] Close issue with completion notes
## Final Results
### Test Results
- **GateConfigService**: 35 tests, all passing
- **QualityGatesService**: 54 tests, all passing (including 7 new gate config tests)
- **Overall Coverage**: 93.58% (coordinator module: 98.3%)
### Files Created/Modified
1. Created: `src/coordinator/types/gate-config.types.ts` - Type definitions
2. Created: `src/coordinator/gate-config.service.ts` - Service implementation
3. Created: `src/coordinator/gate-config.service.spec.ts` - Unit tests
4. Created: `src/coordinator/types/index.ts` - Type exports
5. Modified: `src/coordinator/quality-gates.service.ts` - Integration with gate config
6. Modified: `src/coordinator/quality-gates.service.spec.ts` - Added integration tests
7. Modified: `src/coordinator/coordinator-client.service.ts` - Added gateRequirements to request
8. Modified: `src/api/agents/dto/spawn-agent.dto.ts` - Added gateProfile field
### Features Implemented
1. ✅ Four gate profiles: strict, standard, minimal, custom
2. ✅ Default profiles per agent type (reviewer=strict, worker=standard, tester=minimal)
3. ✅ Custom gate selection with validation
4. ✅ Custom coverage thresholds per task
5. ✅ Backward compatibility (works without gate config)
6. ✅ YOLO mode overrides gate config
7. ✅ Profile metadata tracking
8. ✅ Gate requirements passed to coordinator
### Usage Examples
**Spawn worker with default (standard) profile:**
```typescript
{
taskId: "task-123",
agentType: "worker"
// Uses standard profile automatically
}
```
**Spawn worker with custom profile:**
```typescript
{
taskId: "task-123",
agentType: "worker",
gateProfile: "minimal" // Override to minimal
}
```
**Docs task with custom gates:**
```typescript
{
taskId: "task-docs-001",
agentType: "worker",
gateProfile: "custom",
customGates: {
lint: true // Only lint for docs
}
}
```