Docker Implementation Guide Audit¶

## SECTION 2 — WARNINGS ### W-01 — “CURRENT LIMIT” conflates host RAM with Docker VM RAM What I found The callout says JUKEBOX has 32 GB and that “the full target portfolio does not fit safely inside the current memory allocation.” The grammatical subject makes “current memory allocation” sound like the 32 GB host rather than Docker Desktop’s 7.75 GiB VM limit. Consequence A reader can reasonably conclude that the hardware is undersized. Recommended fix Rename it **CURRENT DOCKER ALLOCATION LIMIT** and state separately: 32 GB physical RAM is expected to support the approved portfolio; Docker’s present 7.75 GiB allocation is insufficient for the complete target; begin near 16 GiB and increase only from measured demand. Docker documents that the memory setting controls RAM allocated to the Docker VM and defaults to 50% of host memory. See [Docker Desktop resource settings](https://docs.docker.com/desktop/settings-and-maintenance/settings/). ### W-02 — Caddy’s early readiness test depends on backends that start later What I found Caddy is Docker step 010, but its readiness condition requires the health endpoint and “approved HTTPS routes” to answer. Most route backends do not start until steps 100–240. Consequence The test is ambiguous: accepting 502/503 responses is too weak, while requiring successful application responses deadlocks the sequence. Recommended fix At step 010, test Caddy configuration, listener binding, admin health, certificate availability, and a proxy-independent sentinel route. Test each application route only after its backend becomes ready, then run a complete route verification at the end. ### W-03 — Native Plex is both a global gate and an optional degraded dependency What I found The Non-Docker Startup Table places native Plex before Docker Desktop, yet its failure effect says unrelated platform containers may start under an “explicit degraded-start policy.” That policy is not defined. Consequence An implementation cannot determine whether Plex failure halts Docker entirely or permits Caddy, Portainer, Dozzle, monitoring, and download services. Recommended fix Define a branch: platform/diagnostic containers may start without Plex; Plex-dependent containers remain held. List the exact permitted steps and the operator alert. ### W-04 — Host, Docker VM, and container metrics are not fully distinguished What I found The portfolio lists Node Exporter as a Docker image, while its dependency calls for an approved macOS host-exporter method. cAdvisor is also listed without a final statement of whether its filesystem and machine metrics describe JUKEBOX, the Docker Linux VM, or individual containers. Consequence Dashboards could label Docker VM data as macOS host data, producing incorrect capacity conclusions. Recommended fix Choose the collector location explicitly. Node Exporter supports Darwin when run on Darwin and is designed to monitor the system on which it runs; a containerized copy under Docker Desktop principally observes the Linux VM. Label every metric source accordingly. See the official [Node Exporter README](https://github.com/prometheus/node_exporter/blob/master/README.md). ### W-05 — Standard Compose templates omit the health checks required by startup control What I found Section 13.6 relies on machine-testable readiness, but Templates A–E contain no health-check pattern, timeout, retry budget, or unhealthy-state response. Consequence Every recipe author must invent a readiness implementation, reducing predictability and making the startup table difficult to automate. Recommended fix Add a required health-check block or a documented external probe to the canonical recipe. Define interval, timeout, retries, start period, and what the orchestrator does on timeout. Compose only waits for readiness when a health check is present and the dependency uses `service_healthy`. ### W-06 — “Approved,” “planned,” “installed,” and “authorized” carry overlapping meanings What I found Section 12 calls the list the Approved Application Portfolio, then says approval does not authorize deployment. The INSTALLED column mixes physical state, migration intent, and feasibility labels such as “No — Grafana dependency” and “No — feasibility gate.” Consequence Another reviewer cannot reliably filter the table into current, approved-to-build, conditional, migration-source, and retirement states. Recommended fix Add a controlled **DEPLOYMENT STATE** column with values such as Implemented, Approved–Pending, Conditional, Migration Source, and Retire After Acceptance. Keep INSTALLED strictly Yes/No plus Native/Container location. ### W-07 — Resource estimates are arithmetically correct but insufficiently traceable What I found The 28 per-application estimates sum correctly to 6,314 MiB idle and 19,622 MiB burst, matching the rounded aggregate table. The document does not record how each estimate was derived, the confidence level, or which values have been measured. Consequence Future edits can change individual figures without an auditable basis, and another AI may treat planning assumptions as observations. Recommended fix Add columns for BASIS (vendor guidance, observed, or engineering estimate), VERIFIED DATE, and CONFIDENCE. Preserve measured values separately from planning allowances. ### W-08 — Word metadata retains unrelated template history What I found The visible title, filename, version, page count, and core title are correct. However, `docProps/app.xml` identifies the title-of-part as “McGuckin Home Network - Network Architecture Standard,” and the core property `lastPrinted` predates this document’s creation. An empty APA bibliography custom-XML part also remains. Consequence Search, indexing, forensic review, or a second AI inspecting the package may infer the wrong document lineage. Recommended fix Refresh extended properties from NET-004, clear or accurately regenerate stale print metadata, and remove the empty bibliography artifact if Word does not require it. Revalidate and reopen the resulting package in Word. ### W-09 — Dense operational tables use type that is too small for comfortable review What I found The startup tables render cleanly, but body text is approximately 5.8 pt and several other wide tables use approximately 6–7 pt text. Consequence The information is technically legible at high zoom but difficult to review, print, annotate, and compare—especially for the second AI’s human reviewer. Recommended fix Prefer 8 pt or larger table text. Split the startup table into numbered waves or use portrait detail tables plus a compact master sequence. Preserve repeated headers and avoid shrinking prose to fit one landscape page.