Skip to content

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.py using argparse for CLI commands, and expose identical domain logic via mcp_server.py using FastMCP.
  • 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.py pre-checks and post-checks tied directly to WORK_LOG.md timestamp 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 NLMBrainBridge as the source of truth for topics, research citations, and strategic reports.
  • Consequences: High-quality, grounded posts with automatic source validation.