Name update

docs/NEXT_PHASE.md

@@ -1,6 +1,6 @@
 # Phase 6 — recommendations
 
-The v0.2.0 cut leaves PXEForge in a state where the entire protocol stack
+The v0.2.0 cut leaves OpenPXE in a state where the entire protocol stack
 and operator UI are exercised by 66 automated tests, the container is
 multi-arch buildable, and the image ships at ~97 MB. What's left before
 this looks and feels like a 1.0 product is mostly **real-hardware
@@ -66,7 +66,7 @@ serve-side per request.
 ### 5. Wake-on-LAN trigger
 
 A natural pair with per-MAC host bindings: bind a MAC to an image,
-then click "Wake & Image" to send the magic packet and let PXEForge
+then click "Wake & Image" to send the magic packet and let OpenPXE
 do the rest. Implementation is small (`udp/9` broadcast, magic packet
 construction) but it makes the bound-host workflow feel instant.
 
@@ -113,10 +113,10 @@ for silent breakage.
 
 ### 11. Multi-replica deployment
 
-The current design assumes one PXEForge per broadcast domain. Two
-proxies on the same L2 will race; the gate queue is in-memory, etc.
+The current design assumes one OpenPXE per broadcast domain. Two
+proxies on the same L2 will race; the deployment queue is in-memory, etc.
 For HA we'd need to:
-- Externalize the gate queue (Redis, etcd) or lean into "the menu is
+- Externalize the deployment queue (Redis, etcd) or lean into "the menu is
   cheap to refetch if a replica dies";
 - Ensure DHCP proxy replies are deterministic so a client always
   gets the same answer regardless of which replica replied;
@@ -128,7 +128,7 @@ asking for it.
 ### 12. Pi 4 / SBC quirks
 
 Raspberry Pi netboot uses a specific DHCP option-43 vendor field +
-TFTP path layout that PXEForge doesn't currently special-case. There's
+TFTP path layout that OpenPXE doesn't currently special-case. There's
 a spec; the work is small once we have a Pi to test on.
 
 ## What I'd skip
@@ -137,7 +137,7 @@ a spec; the work is small once we have a Pi to test on.
   abstraction; full DHCP would need raw sockets + a lot of corner-case
   handling for problems no operator wants us to solve.
 - **A pluggable backend abstraction à la Tinkerbell.** Tinkerbell does
-  it because they integrate with k8s CRDs. PXEForge's "the file system
+  it because they integrate with k8s CRDs. OpenPXE's "the file system
   IS the database" model is simpler and good enough for the target
   audience. Don't add a Backend trait until something asks for it.
 - **Multiple language UIs.** Bootimus added these in v0.1.62 and the
@@ -148,8 +148,8 @@ a spec; the work is small once we have a Pi to test on.
 
 - Add a Grafana dashboard JSON to `deploy/grafana/` driven off the
   new `/metrics` endpoint.
-- A `pxeforge bench` subcommand that runs a 10-second internal load
-  test (synthetic gate joins) so an operator can sanity-check tuning.
+- A `openpxe bench` subcommand that runs a 10-second internal load
+  test (synthetic queue joins) so an operator can sanity-check tuning.
 - Ship a basic `docker-compose.yml` for the Unraid path that demos
   the new themes / progress widget.
 - Generate a printable single-page operator runbook from the README