Homepage: record the completed build in the KB

- Homepage.md: status is now 'built, pending deploy' (all assets + checker +
  deploy are in the repo, 112 tests green). To go live: add CADDY_ADMIN_HASH
  to the target .env, then deploy.sh.
- Homepage Design Grilling.md: the build is complete (all 6 slices, full TDD);
  the only remaining step is the operator adding the admin hash + deploying.
- pi log.md: build-complete entry.

docs/Infrastructure/Homepage Design Grilling.md

@@ -69,7 +69,10 @@ These are the deltas from the initial recommendations. Everything else was accep
 - **Q41** — **no client-side auto-refresh.**
 - **Q43** — the footer shows the **last master deployment datetime** (not last-check).
 
-## Build order (unblocked)
+## Build status — complete (2026-08-23)
+
+The build is done, slice by slice, full TDD (each slice red → green, committed
+and pushed). 112 tests pass. The render logic is verified with a Node DOM shim.
 
 ```mermaid
 flowchart LR
@@ -82,4 +85,12 @@ flowchart LR
     G --> H[verify in browser]
 ```
 
+Slices: 1 the checker core (tcp/wip/atomic/generated_at), 2 the http probe, 3
+the real `services.json` + schema, 4 the pages + theme + toggle, 5 the Caddyfile
+auth split, 6 the git-driven deploy (both hashes, `deployed.js`, the timer).
+
+**Remaining to go live:** the operator adds `CADDY_ADMIN_HASH` (the
+operator-only password, `caddy hash-password`) to the target `.env`, then runs
+`./scripts/deploy.sh dankclaw`. Until then the admin hash stays a placeholder.
+
 The per-service docs pages (Q22/Q29/Q30/Q31) are a separate workstream, built as each service goes active.