issue: update overlapping issues with reference to ec1f strategy

1f4f-poor-naughty-list-identification.md

@@ -2,6 +2,10 @@
 
 **ID:** 1f4f
 
+> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f).
+> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements.
+> This issue contributes to **Phase 4 (Enforcement)** and depends on Phase 3 (blacklist API) completion.
+
 ## Issue Summary
 
 We need to detect malicious behavior from clients and relays to protect our system from abuse, DoS attacks, and bandwidth exhaustion. This should feed into a reputation system or connection throttling/banning mechanism.

2cdc-nip-86-relay-management-api.md

@@ -2,6 +2,10 @@
 
 **ID:** 2cdc
 
+> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f).
+> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements.
+> **STATUS:** Deferred in favor of simpler HTTP API first (see ec1f Phase 3). NIP-86 compliance planned for post-Phase 3.
+
 ## Issue Summary
 
 Implement NIP-86 (Relay Management API) to provide authenticated administrative control over the relay. This enables operators to blacklist users, delete repositories, ban event posting, and perform other management actions through a standardized API.

76fe-repository-count-metric.md

@@ -2,6 +2,9 @@
 
 **ID:** 76fe
 
+> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f).
+> This metric should be verified during **Phase 1 (Observability)** when testing the Prometheus/Grafana setup.
+
 **Date Discovered:** 2026-01-12  
 **Date Resolved:** 2026-01-12  
 **Priority:** Medium  

7d0b-management-dashboard.md

@@ -2,6 +2,10 @@
 
 **ID:** 7d0b
 
+> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f).
+> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements.
+> This issue is the **primary deliverable for Phase 2 (Insights)**.
+
 ## Issue Summary
 
 We need a web-based management dashboard to monitor relay health, view storage and usage statistics, and provide basic operational visibility. This dashboard should display key metrics about relay operations, resource utilization, and usage patterns.

8430-storage-limits-and-quota-management.md

@@ -2,6 +2,10 @@
 
 **ID:** 8430
 
+> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f).
+> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements.
+> This issue is the **primary deliverable for Phase 4 (Enforcement)** and depends on Phase 3 (management API) completion.
+
 ## Issue Summary
 
 We currently have no storage limits or quota enforcement, allowing users to push arbitrarily large repositories (e.g., 20GB+) and potentially fill the relay's disk. We need configurable storage limits at multiple levels and graceful handling when approaching disk capacity.

d6ee-defensive-relay-features.md

@@ -2,6 +2,10 @@
 
 **ID:** d6ee
 
+> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f).
+> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements.
+> This issue contributes to **Phase 4 (Enforcement)**. Only Phase 1 (config-based protection) is currently approved.
+
 ## Issue Summary
 
 ~~Implement defensive rate limiting and resource controls to protect the relay from abuse. Focus on per-connection and per-IP rate limits using rust-nostr relay-builder capabilities and custom extensions where needed.~~