Design devcontainer and Nix export bridges from Base manifests

[codeforester]

Problem

Base should coexist with container-first and reproducible-environment workflows instead of pretending to replace them. The product review identified Dev Containers and Nix/devenv as important overlap areas, but the right Base posture is likely export or bridge generation from base_manifest.yaml, not direct ownership of those ecosystems.

Desired outcome

Design how Base could export or assist Dev Container and Nix/devenv configuration from Base manifests while preserving Base's delegation-first boundary.

Scope

• Identify which Base manifest fields can map cleanly to .devcontainer/devcontainer.json, Docker-oriented setup, Nix, or devenv.
• Identify which fields cannot map safely and should be reported as unsupported or advisory.
• Decide whether the first slice should be basectl export-devcontainer, a design-only compatibility matrix, or a narrower Docker/devcontainer bridge.
• Preserve Base as the source of local workspace/project intent while delegating container and reproducible environment mechanics to their native tools.
• Tie the design to Linux/runtime and Docker-related roadmap work where appropriate.

Non-goals

• Do not reimplement Dev Containers, Nix, or devenv.
• Do not make container workflows mandatory for Base projects.
• Do not promise a lossless manifest conversion when Base and target-tool semantics differ.

Acceptance criteria

• A design document defines the export/bridge boundary for Dev Containers and Nix/devenv.
• The design names the first shippable slice and the unsupported cases.
• The design explains how generated files are reviewed, overwritten or preserved, and kept consistent with base_manifest.yaml.