Complete task 4 backend security architecture docs

09 - Audits/Backend Stack Security and Refactor Assessment - 2026-05-24.md

@@ -345,7 +345,7 @@ Should include:
 - Trust boundaries: browser, backend, database, Redis, provider APIs, wallet/RPC, admin UI, Socket.IO.
 - Abuse cases: fake payment proof, replayed webhook, arbitrary room join, stolen token, double payout, dispute bypass, email/AI abuse.
 
-### 2. Funds Ledger Specification
+### 2. Funds Ledger and Escrow State Machine Specification
 
 Purpose: make money movement auditable and provider-independent.
 
@@ -386,9 +386,7 @@ Should map every endpoint and socket event to:
 
 ### 5. Payment Provider Adapter Spec
 
-Purpose: decouple business logic from SHKeeper, Request Network, manual wallet flow, and future providers.
-
-Should define:
+Implemented as [[Payment Provider Adapter Spec]], including:
 
 - `createPayInIntent`
 - `getPayInStatus`
@@ -399,13 +397,11 @@ Should define:
 - `getPayoutStatus`
 - `searchProviderPayments`
 
-Provider-specific metadata should be namespaced and never become the canonical funds state.
+Provider-specific metadata is namespaced and never used as canonical funds state.
 
 ### 6. Webhook Security Spec
 
-Purpose: prevent forged, replayed, or silently failed provider events.
-
-Should define:
+Implemented as [[Webhook Security Spec]]:
 
 - Raw-body signature verification.
 - Accepted headers and algorithms.
@@ -434,6 +430,8 @@ Should define:
 
 ### 8. Realtime Authorization Spec
 
+Implemented as [[Realtime Authorization Spec]].
+
 Purpose: make Socket.IO events subject to the same security model as REST.
 
 Should define:
@@ -476,9 +474,7 @@ Should define:
 
 ### 11. Operational Runbooks
 
-Purpose: make security incidents and payment failures survivable.
-
-Should include:
+Implemented as [[Backend Funds Migration and Operational Runbooks]]:
 
 - Failed webhook.
 - Duplicate payment.