Rig Community

Canonical write-up (opening post may have mangled markdown from an earlier push): Ask: First-class DDEV (and Magento) integration — detect .ddev/, map ddev start / ddev stop / HTTPS URLs, and ship Magento scaffolds/recipes. Today: DDEV isn’t a first-class integration (no Magento/DDEV-specific recipes). If DDEV exposes the site on localhost ports and you point Rig at the project folder, you get the outer control plane (start/stop the compose/DDEV command you configure, logs from that process, MCP against that project). Honest limit: For Magento-in-DDEV day-to-day, DDEV + Magento MCP stay the primary tools; Rig is optional glue, not a replacement — until this ships. Sketch: Detect .ddev/ on add-project / setup assist Preferred scripts: ddev start / stop / describe URLs Magento scaffold / recipe beside existing Laravel / WordPress paths Docs: when Rig helps vs when DDEV + store MCP should lead Source: Prospect feedback (Magento 2 / angeo module-aeo-audit), 2026-09-03. Tracked in docs/feature-ideas-todo-2.md.

Canonical write-up (opening post may have mangled markdown from an earlier push): Ask: Give Rig optional visibility into processes inside containers — not only host processes and published ports. Today: Rig is host-oriented. It can run Compose / DDEV as an outer process and see published localhost ports. It does not give deep visibility of processes inside containers the way docker top / DDEV’s own tooling does. Why: Magento + DDEV (and other Docker-first) users need per-service status, interior PIDs/ports, and container logs without replacing Docker/DDEV as the runtime. Sketch: Optional container-aware board for Compose / DDEV projects Per-service status + logs via Docker CLI MCP: surface container services under get_status / get_logs without a raw shell Source: Prospect feedback (Magento 2 / DDEV), 2026-09-03. Tracked in docs/feature-ideas-todo-2.md.