Add architecture decision records for Discord.js, PostgreSQL, polling strategy, and modular monolith

docs/09_architecture_decisions.md

@@ -2,28 +2,16 @@
 
 ## ADR-001: Discord.js over Discord.py
 
-**Status:** Accepted  
-**Context:** Node.js and Python both viable. Team has stronger Node.js experience.  
-**Decision:** Use Discord.js for the bot runtime.  
-**Consequences:** Faster development velocity; ecosystem rich with community plugins (command handling, modals, components).
+[ADR-001: Discord.js over Discord.py](./09_architecture_decisions/ADR-001.md)
 
 ## ADR-002: PostgreSQL over MongoDB
 
-**Status:** Accepted  
-**Context:** Mileage data is relational (user → role → event → score). MongoDB adds flexibility but sacrifices query power.  
-**Decision:** Use PostgreSQL with JSONB columns for extensible user metadata.  
-**Consequences:** Schema migrations needed for new features; joins straightforward.
+[ADR-002: PostgreSQL over MongoDB](./09_architecture_decisions/ADR-002.md)
 
 ## ADR-003: Polling over Webhooks for Content Sources
 
-**Status:** Accepted  
-**Context:** YouTube, Instagram, TikTok do not provide push webhooks to arbitrary third parties without approval.  
-**Decision:** Poll public APIs on a CRON schedule (15-min interval).  
-**Consequences:** ~5 min delay between publish and Discord post; API quota management required.
+[ADR-003: Polling over Webhooks for Content Sources](./09_architecture_decisions/ADR-003.md)
 
 ## ADR-004: Modular Monolith over Microservices
 
-**Status:** Accepted  
-**Context:** Single-developer or small team; deployment complexity of microservices not justified.  
-**Decision:** Single process with internal module boundaries (commands, events, mileage, syndication).  
-**Consequences:** Simpler deploy, debug, and develop; can extract services later if needed.
+[ADR-004: Modular Monolith over Microservices](./09_architecture_decisions/ADR-004.md)

docs/09_architecture_decisions/ADR-001.md

@@ -0,0 +1,6 @@
+# ADR-001: Discord.js over Discord.py
+
+**Status:** Accepted  
+**Context:** Node.js and Python both viable. Team has stronger Node.js experience.  
+**Decision:** Use Discord.js for the bot runtime.  
+**Consequences:** Faster development velocity; ecosystem rich with community plugins (command handling, modals, components).

docs/09_architecture_decisions/ADR-002.md

@@ -0,0 +1,6 @@
+# ADR-002: PostgreSQL over MongoDB
+
+**Status:** Accepted  
+**Context:** Mileage data is relational (user → role → event → score). MongoDB adds flexibility but sacrifices query power.  
+**Decision:** Use PostgreSQL with JSONB columns for extensible user metadata.  
+**Consequences:** Schema migrations needed for new features; joins straightforward.

docs/09_architecture_decisions/ADR-003.md

@@ -0,0 +1,6 @@
+# ADR-003: Polling over Webhooks for Content Sources
+
+**Status:** Accepted  
+**Context:** YouTube, Instagram, TikTok do not provide push webhooks to arbitrary third parties without approval.  
+**Decision:** Poll public APIs on a CRON schedule (15-min interval).  
+**Consequences:** ~5 min delay between publish and Discord post; API quota management required.

docs/09_architecture_decisions/ADR-004.md

@@ -0,0 +1,6 @@
+# ADR-004: Modular Monolith over Microservices
+
+**Status:** Accepted  
+**Context:** Single-developer or small team; deployment complexity of microservices not justified.  
+**Decision:** Single process with internal module boundaries (commands, events, mileage, syndication).  
+**Consequences:** Simpler deploy, debug, and develop; can extract services later if needed.