test: add comprehensive docker test suite and update backlog

Introduces `test-in-docker.sh` to provide an exhaustive test suite for all CLI subcommands and code paths within a standard Ubuntu 24.04 environment. Additionally, populates the backlog with several new task definitions addressing bugs and improvements discovered during testing.

Author: superstructor

.tasks/backlog/0037-mcp-bridge-starts-without-backends.md

@@ -0,0 +1,101 @@
+# 0037 — mcp-bridge: Start and Respond to initialize When No Backends Are Found
+
+**Priority:** P1
+**Type:** bugfix
+**Module:** `src/cli/mcp_bridge.rs`, `src/mcp/bridge/server.rs`
+**Status:** Backlog
+**Complexity:** S
+**Created:** 2026-03-02
+
+## Context
+
+`great mcp-bridge` currently calls `anyhow::bail!` if `discover_backends`
+returns an empty list (lines 127-131 of `src/cli/mcp_bridge.rs`). This causes
+the process to exit 1 before reading a single byte from stdin, so any MCP
+client that opens the bridge immediately loses its connection with no valid
+JSON-RPC response.
+
+The problem is most acute during onboarding: a brand-new install of great.sh
+on a machine that has no AI CLIs yet (a common Docker / CI scenario) makes the
+bridge completely unusable. MCP clients (Claude Desktop, Cursor, etc.) see a
+dead process rather than a bridge in degraded mode.
+
+The correct behavior is: the bridge is an MCP server. MCP servers MUST always
+respond to `initialize` and `tools/list`. When no backends are present the
+response to `tools/list` is an empty array; tool calls return a JSON-RPC error
+(`-32601 Method not found` or a structured tool error) explaining that no
+backends are installed.
+
+**Reproduction** (Ubuntu 24.04, no AI CLIs on PATH):
+
+```
+echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0.1"}}}' \
+  | great mcp-bridge
+```
+
+Actual output:
+```
+Error: no AI CLI backends found on PATH. Install at least one of: gemini, codex, claude, grok, ollama
+exit: 1
+```
+
+Expected output: a valid JSON-RPC 2.0 `initialize` response on stdout, then
+the server reading further messages from stdin (returning empty `tools/list`,
+or a descriptive error on tool calls).
+
+**Code location of the hard guard:**
+`src/cli/mcp_bridge.rs` lines 127-131:
+```rust
+let backends = discover_backends(&backend_filter);
+if backends.is_empty() {
+    anyhow::bail!(
+        "no AI CLI backends found on PATH. Install at least one of: gemini, codex, claude, grok, ollama"
+    );
+}
+```
+
+## Acceptance Criteria
+
+- [ ] Piping an MCP `initialize` request to `great mcp-bridge` on a machine
+  with no AI CLIs returns a well-formed JSON-RPC 2.0 response on stdout (i.e.
+  the process does NOT exit 1 before responding). Verified with:
+  `echo '{"jsonrpc":"2.0","id":1,"method":"initialize",...}' | great mcp-bridge`
+  producing valid JSON on stdout.
+
+- [ ] `tools/list` returns an empty `tools` array (not an error) when no
+  backends are discovered, allowing MCP clients to connect without crashing.
+
+- [ ] Any tool call made while no backends are available returns a JSON-RPC
+  error response with a human-readable message such as
+  `"No AI CLI backends found. Install at least one of: gemini, codex, claude, grok, ollama."`
+  rather than silently crashing the bridge process.
+
+- [ ] A `WARN`-level log line is emitted to stderr when the bridge starts with
+  zero backends (e.g. `warn: no AI CLI backends found; bridge running in
+  degraded mode`), so operators can diagnose the situation without reading
+  client-side errors.
+
+- [ ] `cargo test` continues to pass; existing unit tests in
+  `src/mcp/bridge/backends.rs` are unaffected, and at least one new
+  integration test (or `#[test]`) asserts that `run()` does not return an
+  `Err` when no backends are present and an `initialize` message is sent.
+
+## Files That Need to Change
+
+- `src/cli/mcp_bridge.rs` — remove the hard `bail!` guard; pass an empty
+  `Vec<BackendConfig>` to `start_bridge` with a warn-level log instead.
+- `src/mcp/bridge/server.rs` — ensure `GreatBridge::new` and the tool
+  dispatch path handle an empty backend list gracefully (tool calls return
+  a structured error rather than panicking or unwrapping).
+
+## Dependencies
+
+None. All changes are within the MCP bridge module.
+
+## Out of Scope
+
+- Auto-installing any backend CLI (belongs in `great doctor --fix` / task 0005).
+- Surfacing backend availability in `tools/list` metadata (future enhancement).
+- Changing the behavior when a non-empty `--backends` filter is specified but
+  none of the named binaries are found (same fix applies, but keep as a
+  follow-on to keep this change small).

.tasks/backlog/0038-sigpipe-epipe-panic-on-stdout.md

@@ -0,0 +1,127 @@
+# 0038 — CLI: Handle SIGPIPE / EPIPE Gracefully Instead of Panicking
+
+**Priority:** P2
+**Type:** bugfix
+**Module:** `src/main.rs`, all subcommands that write to stdout
+**Status:** Backlog
+**Complexity:** S
+**Created:** 2026-03-02
+
+## Context
+
+Any `great` subcommand that writes to stdout panics (exit code 101) when the
+read end of a pipe closes before the write is complete. This is a POSIX SIGPIPE
+/ EPIPE condition. Rust's standard library does not install a SIGPIPE handler
+by default on Linux; instead, `println!` / `write!` propagate an `io::Error`
+which — when it reaches `main() -> Result<()>` — causes anyhow to print a
+backtrace and exit 101 (Rust's panic exit code).
+
+The failure is most reproducible via `great status --json` because it emits a
+large single `println!` call, but the same root cause affects every subcommand
+(`great doctor`, `great diff`, `great template list`, etc.).
+
+**Reproduction** (Ubuntu 24.04, Docker container, or any Linux shell):
+
+```bash
+# head reads 0 lines then closes the pipe — great exits 101
+great status --json | head -0
+
+# process-substitution variant — stderr shows broken pipe message
+great status --json > >(head -0)
+```
+
+**Actual behavior:**
+
+- Exit code: 101 (Rust panic/anyhow error propagation)
+- stderr: `Error: write /dev/stdout: broken pipe` (or similar anyhow error)
+
+**Expected behavior:**
+
+- Exit code: 0 (or the process is terminated by SIGPIPE, which shells report
+  as exit 141 — both are acceptable to downstream tooling)
+- No output to stderr
+
+**Root cause (code):**
+
+`src/cli/status.rs` line 415:
+
+```rust
+println!("{}", serde_json::to_string_pretty(&report)?);
+```
+
+The `?` propagates the `BrokenPipe` `io::Error` to `main()`, which calls the
+anyhow error handler and exits 101. The same pattern exists wherever `println!`
+or `print!` is used across all subcommands.
+
+**Why this matters:**
+
+- CI pipelines doing `great status --json | jq '.has_issues'` panic if jq
+  exits early (e.g. after finding the first match with `jq -e`).
+- `great status --json | head -1` — a common "is the tool healthy?" one-liner
+  — reliably panics.
+- Any pipeline using `| grep -q`, `| head`, or `| wc -l` may trigger this.
+- The panic message on stderr is alarming and confusing; users file bug reports
+  thinking the CLI is broken, not that the pipe closed.
+- `great status --json` is documented to always exit 0 in JSON mode (by
+  design); exiting 101 on EPIPE is an undocumented and inconsistent exception.
+
+## Acceptance Criteria
+
+- [ ] `great status --json | head -0` exits 0 (or 141) and produces no output
+  on stderr. Verified by: `great status --json | head -0; echo $?` returning
+  0 or 141, with stderr empty.
+
+- [ ] `great status --json | head -1` exits 0 (or 141) with no stderr output,
+  confirming the fix works when some output is consumed before the pipe closes.
+
+- [ ] At least two additional subcommands that write to stdout (`great doctor`,
+  `great diff`, or `great template list`) are verified to not panic on
+  `| head -0` — confirming the fix is applied at the binary entry point rather
+  than per-call-site.
+
+- [ ] Normal operation is unaffected: `great status --json` with stdout open
+  exits 0 and produces valid JSON; `great status` (human mode) with issues
+  still exits 1 as before.
+
+- [ ] `cargo test` passes with no regressions.
+
+## Suggested Fix Approaches
+
+Three options exist; exactly one should be chosen and documented in the commit:
+
+**Option A — `unix_sigpipe` attribute (Rust 1.73+, simplest):**
+Add `#[unix_sigpipe = "sig_dfl"]` to `fn main()` in `src/main.rs`. This
+restores the default POSIX SIGPIPE disposition so the kernel kills the process
+cleanly (exit 141) rather than delivering an `io::Error`.
+
+**Option B — Ignore SIGPIPE at startup, swallow BrokenPipe errors:**
+Call `unsafe { libc::signal(libc::SIGPIPE, libc::SIG_IGN) }` early in `main`,
+then wrap the top-level `Result` handler to treat `io::ErrorKind::BrokenPipe`
+as a clean exit 0.
+
+**Option C — Wrap stdout writes per-call-site:**
+Replace `println!` calls with explicit `writeln!(std::io::stdout(), ...)` and
+match on `io::ErrorKind::BrokenPipe` to return `Ok(())` instead of
+propagating.
+
+Option A is preferred: it is the least invasive, requires no unsafe code or
+extra dependencies, and matches the behavior users expect from a POSIX CLI tool.
+
+## Files That Need to Change
+
+- `src/main.rs` — primary fix location (Option A: one-line attribute)
+- Potentially `src/cli/status.rs`, `src/cli/doctor.rs`, `src/cli/diff.rs`,
+  `src/cli/template.rs` if a per-call-site approach (Option C) is chosen
+
+## Dependencies
+
+None. This is a self-contained fix to the binary entry point (or individual
+write sites).
+
+## Out of Scope
+
+- Changing exit codes for non-EPIPE error paths (separate concern).
+- Handling SIGPIPE in the MCP bridge server (that process is long-lived and
+  EPIPE there has different semantics — track separately if needed).
+- Windows behavior (Windows does not have SIGPIPE; the fix is no-op or
+  conditional on `#[cfg(unix)]`).

.tasks/backlog/0039-docker-on-wsl2-falsely-detected-as-wsl.md

@@ -0,0 +1,73 @@
+# 0039 — Docker-on-WSL2 container falsely detected as WSL
+
+| Field                | Value                              |
+|----------------------|------------------------------------|
+| Priority             | P2                                 |
+| Type                 | bugfix                             |
+| Module               | `src/platform/detection.rs`        |
+| Status               | backlog                            |
+| Estimated Complexity | Small                              |
+
+## Context
+
+`great status` (and any command that branches on platform) reports `WSL Ubuntu 24.04` when run inside a Docker container on a WSL2 host. The container should be identified as plain `Linux Ubuntu 24.04`.
+
+**Reproduction**
+
+```bash
+docker run --rm \
+  -v /path/to/great:/usr/local/bin/great:ro \
+  ubuntu:24.04 \
+  great status 2>&1 | grep Platform
+# Actual:   ℹ Platform: WSL Ubuntu 24.04 (x86_64)
+# Expected: ℹ Platform: Linux Ubuntu 24.04 (x86_64)
+```
+
+**Root cause — three detection tiers, all reachable inside Docker-on-WSL2**
+
+`is_wsl()` in `src/platform/detection.rs` (lines 169–181) runs three checks in order:
+
+1. `WSL_DISTRO_NAME` env var — normally not set inside Docker, so this tier is safe.
+2. `/proc/sys/fs/binfmt_misc/WSLInterop` path check — Docker containers on WSL2 share the host kernel's binfmt_misc namespace; this file **is present** inside containers, causing a false positive.
+3. `/proc/version` contains "microsoft" — inherited from the WSL2 kernel (`6.6.87.2-microsoft-standard-WSL2`), also a false positive.
+
+Both tiers 2 and 3 are hit. `is_wsl2()` (lines 187–189) has the same WSLInterop false positive, so `PlatformCapabilities.is_wsl2` is also wrong.
+
+**Impact of false positive**
+
+- `great apply` may attempt WSL-specific actions: copying fonts to `C:\Users\...\AppData\Local\Microsoft\Windows\Fonts`, invoking `cmd.exe` (fails with "No such file or directory").
+- `great doctor` may suggest WSL-specific tooling (`wslu`, etc.) to a container.
+- Install paths and generated scripts may be incorrect for container environments.
+
+**Container indicators to check (before concluding WSL)**
+
+| Indicator | Path / mechanism | Notes |
+|-----------|-----------------|-------|
+| `/.dockerenv` | File present in all Docker containers | Most reliable; Docker always creates it |
+| `DOCKER_CONTAINER` env var | Set by some base images / compose setups | Secondary |
+| `container` env var | Set by some OCI runtimes (podman, etc.) | Catches non-Docker containers too |
+| cgroup v1 `/proc/1/cgroup` | Contains "docker" in container | Fallback; cgroup v2 may not have it |
+
+The recommended fix: before returning `true` from `is_wsl()`, check for any container indicator and return `false` if one is found. Same guard needed in `is_wsl2()`.
+
+## Acceptance Criteria
+
+1. `is_wsl_with_probe()` returns `false` when `/.dockerenv` exists, even if `/proc/sys/fs/binfmt_misc/WSLInterop` exists and `/proc/version` contains "microsoft".
+2. `is_wsl_with_probe()` returns `false` when the `container` or `DOCKER_CONTAINER` env var is set, regardless of other WSL indicators.
+3. `is_wsl_with_probe()` continues to return `true` on a genuine WSL2 environment (WSLInterop present, no container indicators).
+4. `is_wsl2_with_probe()` is subject to the same container-exclusion guard and returns `false` inside a detected container.
+5. `great status` run inside an `ubuntu:24.04` Docker container on a WSL2 host prints `Platform: Linux Ubuntu 24.04 (x86_64)`, not `WSL Ubuntu 24.04`.
+
+## Files That Need to Change
+
+- `src/platform/detection.rs` — `is_wsl()`, `is_wsl2()`, `is_wsl_with_probe()`, `is_wsl2_with_probe()`, `MockProbe`-based tests (add container scenarios).
+
+## Dependencies
+
+None — self-contained platform module change.
+
+## Out of Scope
+
+- Detecting other container runtimes (LXC, systemd-nspawn) beyond the indicators listed.
+- Changing the `Platform` enum to add a `Container` variant (separate task if needed).
+- Any changes to `great apply` WSL-specific logic (that is downstream; fixing detection unblocks it).