Name update

README.md

@@ -5,12 +5,12 @@ Container-native PXE boot server. A Rust reimplementation of
 for Docker/OCI and OpenShift. Upload `.iso` files via the web UI; network
 clients PXE-boot them.
 
-> **Status:** v0.2.0 / pre-beta. Phases 1–5 complete: full PXE stack,
+> **Status:** v0.3.2 / pre-beta. Phases 1–5 complete: full PXE stack,
 > Queued Deployment queue, NFS-share ISO sources, live tracing log + an
 > operator terminal, per-MAC host bindings (Tinkerbell-style),
-> Prometheus `/metrics`, light/dark theme toggle, animated anvil
-> imaging-progress widget. **66 tests passing**, clippy clean. Ready
-> for real-hardware validation.
+> Prometheus `/metrics`, light/dark theme toggle, animated OpenPXE
+> imaging-progress widget, and per-ISO boot passwords. The test suite and
+> clippy are part of the release checklist. Ready for real-hardware validation.
 
 ## Design non-negotiables
 
@@ -41,13 +41,13 @@ clients PXE-boot them.
    Tools          > Utilities / OpenPXE Shell / Network Card Info
    Queued Deployment
    ```
-6. **Queued Deployment queue** — the "horse race" launch flow. A client that
+6. **Queued Deployment queue** — the coordinated launch flow. A client that
    selects *Queued Deployment* gets a numbered position and waits. The
    operator picks an ISO in the web UI and fires it to every waiting
    client simultaneously.
-7. **Web UI** (Netbox-style): sidebar nav (Dashboard / Network / Forge
-   Gate / Storage / Hosts / Terminal / About), light + dark themes
-   (toggle top-right or press `T`), animated anvil "forge progress"
+7. **Web UI** (Netbox-style): sidebar nav (Dashboard / Network / Queue /
+   Storage / Hosts / Terminal / About), light + dark themes
+   (toggle top-right or press `T`), animated OpenPXE progress
    widget when devices are imaging. All assets served from the binary —
    no external requests.
 8. **Per-MAC host bindings.** Pin a MAC to a boot target and the client
@@ -81,7 +81,7 @@ skip TFTP and respond with an HTTP URL.
 ./scripts/fetch-ipxe.sh
 
 # 2. Build the container image (~3 min first time).
-docker buildx build -f deploy/docker/Dockerfile -t openpxe:0.1.0 --load .
+docker buildx build -f deploy/docker/Dockerfile -t openpxe:0.3.2 --load .
 
 # 3. Run it on the box plugged into your PXE network. Set PUBLIC_IP to
 #    this host's LAN address so advertised iPXE URLs are reachable.
@@ -91,7 +91,7 @@ docker run -d --name openpxe \
   -e OPENPXE_DHCP_MODE=proxy \
   -v $PWD/data/isos:/var/lib/openpxe/isos \
   -v $PWD/data/work:/var/lib/openpxe/work \
-  openpxe:0.1.0
+  openpxe:0.3.2
 
 # 4. Open the UI and drop an ISO in.
 open http://10.0.0.5
@@ -122,7 +122,7 @@ docker buildx create --name openpxe-multi --driver docker-container --use
 # Build + push both linux/amd64 and linux/arm64 under one tag.
 docker buildx build --builder openpxe-multi \
   --platform linux/amd64,linux/arm64 \
-  -t ghcr.io/YOUR-ORG/openpxe:0.1.0 \
+  -t ghcr.io/YOUR-ORG/openpxe:0.3.2 \
   --push \
   -f deploy/docker/Dockerfile .
 ```
@@ -155,10 +155,10 @@ docker run --rm \
   -v /my/iso-library:/seed:ro \
   -v openpxe-data:/var/lib/openpxe/isos \
   -e OPENPXE_PUBLIC_IP=10.0.0.5 \
-  openpxe:0.1.0 seed --from /seed
+  openpxe:0.3.2 seed --from /seed
 
 # Dry run first to see what would be imported:
-docker run --rm -v /my/iso-library:/seed:ro openpxe:0.1.0 seed --from /seed --dry-run
+docker run --rm -v /my/iso-library:/seed:ro openpxe:0.3.2 seed --from /seed --dry-run
 ```
 
 ### Environment overrides
@@ -273,7 +273,7 @@ operational constraints inherited from the design:
 
 ## Queued Deployment
 
-The "horse race" launch flow, end to end:
+The coordinated launch flow, end to end:
 
 1. A client boots and picks **Queued Deployment** in the PXE menu (or falls
    through on timeout with the default `timeout_action`).
@@ -285,8 +285,9 @@ The "horse race" launch flow, end to end:
    The server broadcasts the assignment to every queued client via a
    `tokio::sync::Notify`; each client's next poll returns the boot script
    for the chosen image.
-5. Every client chains the same image at effectively the same moment — the
-   queue releases and the horses run together.
+5. Every client chains the same image at effectively the same moment. The
+   queue stays visible until the operator releases entries, which keeps a
+   useful audit trail during hardware testing.
 
 No user-facing iPXE anywhere in this flow. The client only ever runs
 scripts we generate; the operator only interacts with the web UI.