Investigation: Port sandboxed Docker + MCP + skills to other

Tinker

Home Epics Investigation: Port sandboxed Docker + MCP + skills to other repositoriesEdit

Investigation: Port sandboxed Docker + MCP + skills to other repositories

Cancel

Title *

Project *

Description

## Problem

Our current repository has a sandboxed Docker environment with:
- MCP (Model Context Protocol) bridge/servers
- Skills system
- REST API capabilities

We need to figure out how to make this same functionality work in other internal repositories. Each repo has its own Docker setup - we can't just share a Docker image.

## Investigation Goals

Explore how other repositories can adopt the same capabilities. Consider approaches like:

1. **Dockerfile patterns** - Can we provide a modular Dockerfile that other repos can include/adapt?
2. **Bootstrap scripts** - A script that injects/setup the required components into an existing Docker environment?
3. **Base image extension** - Can we create a base Docker image that others extend?
4. **Other approaches** - Whatever makes sense

## What to Investigate

1. Analyze the current Docker setup in this repository:
   - How MCP servers are configured and started
   - How the skills system is integrated
   - How the REST API works
   - What environment variables are required

2. Identify what's specific to this repo vs what's generic/reusable

3. Explore different portability approaches:
   - What are the pros/cons of each approach?
   - What would need to change in other repos to adopt it?
   - What configuration would be needed?

4. Consider constraints:
   - Other repos have their own Dockerfiles
   - Environment variable configuration is the preferred way to customize
   - This is for internal projects

## Expected Output

The worker should produce:

1. **Analysis document** explaining:
   - How the current system works
   - What components are involved
   - Dependencies and requirements

2. **Options with tradeoffs**:
   - At least 2-3 different approaches
   - Pros and cons of each
   - Effort required
   - Risks or limitations

3. **Recommendation**:
   - Which approach makes most sense for our use case
   - Why it's the best fit

4. **Proof of concept (optional but encouraged)**:
   - If feasible, create a small example showing how it would work
   - Could be a sample Dockerfile, bootstrap script, or template

## Success Criteria

- Clear understanding of what needs to be portable
- At least 2 viable approaches documented with tradeoffs
- A recommended path forward
- Enough detail that the next team can implement the solution