[green] Correct capability-defined target wording

Signed-off-by: Viwat Vchirawongkwin <viwat.v@chula.ac.th>

Author: yyods

docs/specifications/firmware.md

@@ -78,8 +78,8 @@ prove the required flash/PSRAM topology. The full compatibility, artifact, and
 bounded public-beta contracts are frozen in
 [firmware/browser-flashing.md](firmware/browser-flashing.md).
 
-These targets are the first validated firmware family, not the product
-boundary. A future port MAY use another upstream MicroPython port, CPU
+These targets are the initial reference/build family, not the product boundary.
+A future port MAY use another upstream MicroPython port, CPU
 architecture, BLE host, native integration mechanism, build system, storage
 backend, or provisioning tool. It MUST preserve PBLE/1, the protected
 control-plane boundary, capability negotiation, workspace safety, and the

docs/specifications/hardware.md

@@ -6,9 +6,9 @@ PyBLE's platform scope is any microcontroller board that can run MicroPython
 and provide a Bluetooth Low Energy peripheral stack capable of hosting a
 conforming PBLE/1 agent. It makes no assumptions about wiring and carries no
 board-specific routing profile. Hardware eligibility is broader than current
-support: a board works with PyBLE only after a maintained agent port or firmware
-image for that target passes the protocol, resource, recovery, and
-hardware-in-the-loop gates.
+support. A qualified port must pass its complete protocol, resource, recovery,
+and hardware-in-the-loop gates; a narrower beta must name the exact evidence it
+has passed and the qualification that remains open.
 
 Classic ESP32, ESP32-S3, and ESP32-C3 are the **initial v1 reference target
 families**, not the permanent product boundary. A public browser image is