Docker Local Development

Delegation

Run in the main conversation by default. Delegation can increase usage: obtain explicit approval for the proposed agent count and scope before using subagents. Reuse that approval within its bounds; ask again before expanding the approved count or scope.

Guardrails

• Design for local development. Keep production images, secrets, deployment, certificates, and runtime topology separate.
• Inspect before asking questions or proposing services. Treat detection as evidence, not authority.
• Preserve existing Docker files and unrelated working-tree changes. Keep a semantic diff for material stack changes. Ordinary configuration edits are covered by a setup or repair request; volume deletion, destructive resets, and data migrations need authorization covering those effects.
• Generate only services the project uses or the user explicitly requests. A database is not mandatory when the project uses SQLite, a host service, or an external database.
• Prefer direct foreground commands and one concern per service. Add Supervisor or PM2 only when the project already requires it or production-parity testing justifies it.
• Prefer a stable top-level Compose name: and role-based service names. Do not set container_name by default because it prevents service scaling and creates cross-project collisions.
• Select images by project constraints, team or production compatibility, trusted publisher, supported version, and architecture. Treat an already-downloaded image only as a tie-breaker. Avoid floating latest tags in generated files.
• Publish only ports needed by the host. Bind local-only ports to 127.0.0.1 by default; keep databases, caches, SMTP, PHP-FPM, and internal APIs unexposed when possible.
• Keep secrets out of committed files, generated documentation, command output, and frontend or proxy containers. Generate an ignored local env file plus a safe example when configuration is needed.

Workflow