mosaic/stack
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases 2 Wiki Activity
Files
7989c089efec6eeb681d6fda1fafa6eb03e69cb2
stack/docs/scratchpads/orch-106-sandbox.md
Jason Woltje 5d348526de feat(#71): implement graph data API 
Implemented three new API endpoints for knowledge graph visualization:

1. GET /api/knowledge/graph - Full knowledge graph
   - Returns all entries and links with optional filtering
   - Supports filtering by tags, status, and node count limit
   - Includes orphan detection (entries with no links)

2. GET /api/knowledge/graph/stats - Graph statistics
   - Total entries and links counts
   - Orphan entries detection
   - Average links per entry
   - Top 10 most connected entries
   - Tag distribution across entries

3. GET /api/knowledge/graph/:slug - Entry-centered subgraph
   - Returns graph centered on specific entry
   - Supports depth parameter (1-5) for traversal distance
   - Includes all connected nodes up to specified depth

New Files:
- apps/api/src/knowledge/graph.controller.ts
- apps/api/src/knowledge/graph.controller.spec.ts

Modified Files:
- apps/api/src/knowledge/dto/graph-query.dto.ts (added GraphFilterDto)
- apps/api/src/knowledge/entities/graph.entity.ts (extended with new types)
- apps/api/src/knowledge/services/graph.service.ts (added new methods)
- apps/api/src/knowledge/services/graph.service.spec.ts (added tests)
- apps/api/src/knowledge/knowledge.module.ts (registered controller)
- apps/api/src/knowledge/dto/index.ts (exported new DTOs)
- docs/scratchpads/71-graph-data-api.md (implementation notes)

Test Coverage: 21 tests (all passing)
- 14 service tests including orphan detection, filtering, statistics
- 7 controller tests for all three endpoints

Follows TDD principles with tests written before implementation.
All code quality gates passed (lint, typecheck, tests).

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-02-02 15:27:00 -06:00

3.8 KiB
Raw Blame History

Issue ORCH-106: Docker sandbox isolation

Objective

Implement Docker container isolation for agents using dockerode to provide security isolation, resource limits, and proper cleanup.

Approach

Following TDD principles:

  1. Write tests for DockerSandboxService
  2. Implement DockerSandboxService with dockerode
  3. Add configuration support (DOCKER_SOCKET, SANDBOX_ENABLED)
  4. Ensure proper cleanup on agent completion

Acceptance Criteria

  • src/spawner/docker-sandbox.service.ts implemented
  • dockerode integration for container management
  • Agent runs in isolated container
  • Resource limits enforced (CPU, memory)
  • Non-root user in container
  • Container cleanup on agent termination
  • Comprehensive unit tests
  • Test coverage >= 85%

Progress

  • Read issue requirements from M6-NEW-ISSUES-TEMPLATES.md
  • Review existing orchestrator structure
  • Verify dockerode is installed in package.json
  • Review existing agent spawner code
  • Create scratchpad
  • Write unit tests for DockerSandboxService (RED)
  • Implement DockerSandboxService (GREEN)
  • Refactor and optimize (REFACTOR)
  • Verify test coverage (100% statements, 100% functions, 100% lines, 70% branches)
  • Update orchestrator config with sandbox settings
  • Update spawner module to include DockerSandboxService
  • Update spawner index.ts to export DockerSandboxService and types
  • Update AgentSession type to include containerId field
  • Typecheck passes
  • Build successful
  • Create Gitea issue #241
  • Close Gitea issue with completion notes

Completion

ORCH-106 implementation completed successfully on 2026-02-02.

All acceptance criteria met:

  • DockerSandboxService fully implemented with comprehensive test coverage
  • Security features: non-root user, resource limits, network isolation
  • Configuration-driven with environment variables
  • Integrated into orchestrator spawner module
  • Ready for use with AgentSpawnerService

Issue: #241

Technical Notes

Key Components

  1. DockerSandboxService: Main service for container management
  2. Configuration: Load from orchestrator.config.ts
  3. Resource Limits: CPU and memory constraints
  4. Security: Non-root user, network isolation options
  5. Cleanup: Proper container removal on termination

Docker Container Spec

  • Base image: node:20-alpine
  • Non-root user: nodejs:nodejs
  • Resource limits:
    • Memory: 512MB default (configurable)
    • CPU: 1.0 default (configurable)
  • Network: bridge (default), none (isolation mode)
  • Volume mounts: workspace for git operations
  • Auto-remove: false (manual cleanup for audit)

Integration with AgentSpawnerService

  • Check if sandbox mode enabled via options.sandbox
  • If enabled, create Docker container via DockerSandboxService
  • Mount workspace volume for git operations
  • Pass containerId to agent session
  • Cleanup container on agent completion/failure/kill

Testing Strategy

  1. Unit tests for DockerSandboxService:
    • createContainer() - success and failure cases
    • startContainer() - success and failure cases
    • stopContainer() - success and failure cases
    • removeContainer() - success and failure cases
    • Resource limits applied correctly
    • Non-root user configuration
    • Network isolation options
  2. Mock dockerode to avoid requiring actual Docker daemon
  3. Test error handling for Docker failures

Dependencies

  • dockerode (already installed)
  • @types/dockerode (already installed)
  • ConfigService from @nestjs/config

Related Files

  • /home/localadmin/src/mosaic-stack/apps/orchestrator/src/spawner/agent-spawner.service.ts
  • /home/localadmin/src/mosaic-stack/apps/orchestrator/src/config/orchestrator.config.ts
  • /home/localadmin/src/mosaic-stack/apps/orchestrator/src/spawner/types/agent-spawner.types.ts
Reference in New Issue View Git Blame Copy Permalink