Add Linux Docker status surface

docs/linux-docker-pool.md

@@ -25,16 +25,20 @@ This plane exists for private-repo workflows that need real Linux Docker semanti
 ## Operator Commands
 
 ```bash
+pnpm doctor -- linux-docker --env .env --linux-docker-config config/linux-docker-runners.yaml
 pnpm validate-linux-docker-config -- --config config/linux-docker-runners.yaml --env .env
 pnpm validate-linux-docker-github -- --config config/linux-docker-runners.yaml --env .env
+pnpm linux-docker-status -- --config config/linux-docker-runners.yaml --env .env --result .tmp/linux-docker-status.json
 pnpm render-linux-docker-compose -- --config config/linux-docker-runners.yaml --env .env --output docker-compose.linux-docker.yml
 pnpm render-linux-docker-project-manifest -- --config config/linux-docker-runners.yaml --env .env
-pnpm install-linux-docker-project -- --config config/linux-docker-runners.yaml --env .env
-pnpm teardown-linux-docker-project -- --config config/linux-docker-runners.yaml --env .env
+pnpm install-linux-docker-project -- --config config/linux-docker-runners.yaml --env .env --status-output .tmp/linux-docker-status.json
+pnpm teardown-linux-docker-project -- --config config/linux-docker-runners.yaml --env .env --status-output .tmp/linux-docker-status.json
 ```
 
 `install-linux-docker-project` and `teardown-linux-docker-project` use `ssh` and `scp` to stage the compose project on `LINUX_DOCKER_HOST`, then run a generated deployment script on that host. Use SSH keys or agent forwarding; do not bake credentials into the runner image.
 
+Use `pnpm doctor -- linux-docker ...` for preflight validation and `pnpm linux-docker-status ...` to inspect the latest saved install or teardown result after a remote run.
+
 ## Example Workflow Placements
 
 Container jobs:

docs/private-repo-parity.md

@@ -5,7 +5,7 @@ This guide answers two operator questions:
 1. Where should a given GitHub Actions job run?
 2. What still needs GitHub-hosted runners after the self-hosted planes are in place?
 
-Use it alongside `pnpm doctor`, the main [README](../README.md), and the open backlog for gaps that are still intentionally unresolved.
+Use it alongside `pnpm doctor`, `pnpm synology-status`, `pnpm linux-docker-status`, the main [README](../README.md), and the open backlog for gaps that are still intentionally unresolved.
 
 ## Current Runner Classes
 
@@ -23,7 +23,7 @@ These are the main places where GitHub-hosted runners still have broader surface
 - Broad Linux image/tooling coverage:
   even with the Linux Docker plane, GitHub-hosted runners still win when you need the full hosted image catalog without curating your own host baseline.
 - Self-hosted operator ergonomics:
-  the repo is adding better doctor/status surfaces, but GitHub-hosted still wins on out-of-the-box visibility.
+  the repo now has first-class doctor/status entrypoints for Synology and Linux Docker, but GitHub-hosted still wins on out-of-the-box visibility.
 - Public fork trust boundaries:
   keep untrusted PRs on GitHub-hosted runners unless a workflow has been designed very deliberately for that exposure model.
 

package.json

@@ -19,6 +19,7 @@
     "drain-pool": "tsx src/cli.ts drain-pool",
     "install-synology-project": "tsx src/cli.ts install-synology-project",
     "install-linux-docker-project": "tsx src/cli.ts install-linux-docker-project",
+    "linux-docker-status": "tsx src/cli.ts linux-docker-status",
     "install-lume-project": "tsx src/cli.ts install-lume-project",
     "install-windows-project": "tsx src/cli.ts install-windows-project",
     "lint": "tsc --noEmit -p tsconfig.json",
@@ -36,6 +37,7 @@
     "runner-release-manifest": "tsx src/cli.ts runner-release-manifest",
     "scale": "tsx src/cli.ts scale",
     "smoke-test": "bash scripts/smoke-test.sh",
+    "synology-status": "tsx src/cli.ts synology-status",
     "test": "vitest run",
     "test:coverage": "vitest run --coverage",
     "mutation-test": "stryker run",