Add Network migration readiness audit

NetworkBackendGuide.md

@@ -283,6 +283,8 @@ xcodebuild test -project PeerConnectivity.xcodeproj \
 
 ## Known follow-ups
 
+See [NetworkMigrationReadinessAudit.md](NetworkMigrationReadinessAudit.md) for the authoritative stable/default/removal gates and PR #50+ priority classification.
+
 - Revisit public Network connection policy configuration after more device and CI validation.
 - Reconsider a reusable Network-native browser component only after app-owned `PeerBrowserModel` integrations establish common UI requirements.
 - Revisit stream or file transfer only as a separately scoped future feature; these APIs remain MultipeerConnectivity-only for the current Network backend.

NetworkFrameworkMigrationPlan.md

@@ -4,6 +4,8 @@
 
 Begin migrating PeerConnectivity away from direct MultipeerConnectivity dependence toward Apple's Network framework while preserving public API compatibility where practical.
 
+> Status: this is the original staged architecture plan. The Network backend is now implemented as an experimental opt-in. Use [NetworkMigrationReadinessAudit.md](NetworkMigrationReadinessAudit.md) for the authoritative checklist governing stable status, a default switch, and MultipeerConnectivity removal.
+
 > Note: the iOS 27 MultipeerConnectivity deprecation claim has not yet been verified against Apple SDK headers or release notes. Treat Network framework migration as proactive risk reduction until confirmed.
 
 ## Current State
@@ -253,22 +255,14 @@ xcodebuild test -workspace PeerConnectivity.xcworkspace \
 - Backend selection/deprecation notes.
 - Known limitations vs MultipeerConnectivity.
 
-## Open Questions
-
-1. Should Network framework be introduced as an opt-in backend first, or should it replace MC internally once stable?
-2. What is the minimum supported OS after migration?
-3. Is preserving `multipeerSession: MCSession` required for a transition release?
-4. Should unreliable send semantics be preserved, deprecated, or documented as best-effort?
-5. What service type naming convention should be required for Bonjour compatibility?
-6. Which individually authenticated mode from [NetworkTrustModelPlan.md](NetworkTrustModelPlan.md) should graduate the Network backend from experimental status: pairwise derived keys, signed per-peer identity, certificate/pinning, or app-provided verification?
-7. When should Network connection policy values become public configuration instead of fixed internal defaults?
-
-## Immediate Next Step
+## Resolved decisions and remaining gates
 
-Implement Phase 1's transport seam and mock-backed tests in this branch:
-
-```text
-feature/network-framework-migration
-```
+- Network was introduced as an explicit opt-in; MultipeerConnectivity remains the default.
+- Minimum deployment targets are iOS 13 and macOS 10.15.
+- `multipeerSession` remains available during dual-backend transition and must be deprecated before MC removal.
+- Bare service types map to `_<service>._tcp`; already-qualified TCP Bonjour types are preserved.
+- Stream/resource parity is intentionally outside this migration stack; those APIs remain MC-only.
+- Connection policy remains fixed/internal until device and load evidence demonstrates a need for public tuning.
+- Individual peer authentication remains unresolved and is required before stable/default status.
 
-Keep this first commit behavior-preserving and small so later Network framework work can build on a stable abstraction layer.
+The next work is not another unconditional migration phase. Select follow-ups according to [NetworkMigrationReadinessAudit.md](NetworkMigrationReadinessAudit.md): security identity, error observability, resource bounds, and physical-device evidence come before stable status; default switching and MC removal have later, separate gates.

NetworkMigrationPRPlan.md

@@ -103,6 +103,15 @@ Acceptance criteria:
 - Record the current parity boundary: Network supports reliable `Data`/`PeerMessage` transport, while stream/resource send APIs and receive events remain MultipeerConnectivity-only.
 - Prepare versioning notes for the deployment-target bump and Network backend opt-in.
 
+### Final planned PR: migration readiness audit
+
+- Reconcile the implemented stack, accepted non-parity, and remaining production evidence.
+- Define separate gates for stable opt-in, default-backend selection, and MultipeerConnectivity removal.
+- Classify optional follow-ups by the first readiness level that requires them.
+- Record release/versioning constraints and a risk register without changing runtime behavior.
+
+The resulting [NetworkMigrationReadinessAudit.md](NetworkMigrationReadinessAudit.md) is authoritative when this historical sequencing plan and the implemented stack differ. It confirms that no optional implementation is needed to merge the experimental opt-in stack, while individual authentication, error observability, resource bounds, and physical-device evidence are required before stable status.
+
 ### Future security slice: individual peer identity
 
 - Select one trust mode from [NetworkTrustModelPlan.md](NetworkTrustModelPlan.md) only after focused security and platform review.