Appearance
System Architecture & Architectural Decision Records (ADRs)
Summary
This document outlines the architectural principles, component relationships, and key decision records governing the LinkedIn Automation System.
1. High-Level System Architecture
The system follows a Plugin-Based Layered Architecture separating governance, orchestration, business logic, integrations, and observability:
2. Architectural Decision Records (ADRs)
ADR 001: Hybrid CLI + FastMCP Dual Interface Strategy
- Status: Approved
- Context: The system needs to be triggered both interactively via local terminal/cron jobs and via AI assistants (Cursor, Antigravity, Claude) over Model Context Protocol (MCP).
- Decision: Implement
main.pyusingargparsefor CLI commands, and expose identical domain logic viamcp_server.pyusingFastMCP. - Consequences: Code reuse via domain layer (
linkedin_automation/agents/linkedin_agent.py), zero duplicate logic.
ADR 002: Pre-Action Safety Verification via JudgeGuard (/asd)
- Status: Approved
- Context: Autonomous background execution poses risks of unintended file modifications, stale state, or unapproved API actions.
- Decision: All major actions must pass
judge_guard.pypre-checks and post-checks tied directly toWORK_LOG.mdtimestamp freshness. - Consequences: Failure to log start/completion triggers immediate EXIT CODE 1, halting execution safely.
ADR 003: NotebookLM as Primary Knowledge Brain
- Status: Approved
- Context: Hardcoding prompts leads to generic AI responses. Research must be grounded in curated source documents.
- Decision: Integrate Google NotebookLM via
NLMBrainBridgeas the source of truth for topics, research citations, and strategic reports. - Consequences: High-quality, grounded posts with automatic source validation.