linnflux / opendia Internal
README.md

OpenDia

Active CLI-First AI-Orchestrated

OpenDia is Linnflux's internal operations platform — a CLI-first system built around Claude Code running on a dedicated Linux server. It bridges local tooling with external services to create a unified workflow for managing clients, projects, tasks, and time across all Linnflux divisions. This information was published in its initial state on March 12, 2026.

The system is designed so that Claude Code acts as the orchestration layer — reading from and writing to multiple services — while humans continue using Notion, Gmail, and Toggl through their native interfaces. Neither side is the sole source of truth; they complement each other.

Architecture

Remote Server + tmux

Claude Code runs on a persistent Linux Mint server (opendia) on a Tailscale mesh network. The Operator SSHs in from any machine — desktop, laptop, or mobile — and attaches to long-running tmux sessions, one per project or client context. Sessions survive disconnects, sleep, and machine switches. The server is the single point of execution; client machines are just terminals.

laptop ~$ ssh linnflux@opendia
opendia ~$ tmux attach -t acme

Note: The server and tmux layer is the foundation. Everything below it — the database, time tracking, MCP integrations — is flexible and designed to adapt to your current tools. Swap in a different project manager, time tracker, or email provider and the architecture still holds. The goal is to meet you where you already are, not force a migration.

SQLite Database

A local SQLite database stores the canonical list of companies, people, projects, tasks, and Linnflux divisions. Each record can carry a notion_id and toggl_client_id, creating a lightweight bridge between external services without depending on any single one. Foreign keys are enforced. The schema is initialized idempotently, and all CRUD is handled through a CLI helper that doubles as an importable Python module.

TablePurposeKey Fields
divisionsLinnflux business unitsname, description
companiesClient companiesname, short_name, notion_id, toggl_client_id
peopleContacts at companiesname, email, role, company_id
projectsWork projects per companyname, company_id, division_id, toggl_project_id
tasksTasks per projecttitle, project_id, status, notion_url

Internal Time Tracking

Time entries live in daily markdown files with YAML frontmatter. Each running timer has a companion .json state file. Multiple concurrent timers are supported — context-switching between clients is the norm, not the exception.

Every entry records: client, project, division, task, estimated minutes, start/end, duration, billable flag, and notes. This runs alongside Toggl, not instead of it — it's Linnflux's own internal record with fields Toggl doesn't track.

~/OpenDia/Time/2026/03/2026-03-12.md

---
<!-- entry:2026-03-12T09:15 -->
client: ACME Corp
project: ACME Website
division: WordFlux
task: WooCommerce product updates
estimated_minutes: 60
start: 2026-03-12T09:15
end: 2026-03-12T09:22
duration: 7m
billable: true
notes: Updated variable product attributes via WP-CLI
---

MCP Servers

Claude Code connects to external services via Model Context Protocol (MCP) servers — lightweight API bridges that expose tool functions Claude can call directly:

  • Notion — Task management, company pages, meeting notes. Claude reads, creates, and updates tasks and appends content to pages.
  • Toggl Track — Client-facing time tracking. Start/stop timers, list entries, cross-reference with internal time data.
  • Google Workspace — Gmail (inbox scanning, email review), Drive (file sync, backups), Calendar, and Sheets.
  • Square — Read-only access to payments, invoices, and customer data for billing context.

The key principle: humans keep using Notion, Gmail, and Toggl through their normal UIs. Claude participates in those same systems via MCP without replacing them.

Custom Commands

Custom commands are markdown prompt files that define repeatable workflows. The Operator types a slash command, and Claude executes the full routine.

CommandWhat it does
/helloMorning routine. Creates daily log, carries over unchecked items from the prior day.
/checkinHourly check-in. Loads today's log, scans recent Gmail, numbers tasks for quick selection.
/zeroInbox Zero. Scans primary inbox, groups by thread, extracts action items.
/start-timerStart an internal time entry with client, task, division, and billable prompts.
/stop-timerStop a running timer, prompt for notes, calculate duration, finalize the entry.
/pause-timerPause with auto-generated notes and project summary.
/timer-statusShow all active timers across all sessions.
/od-goUnified work start. Resolves client via fuzzy match, searches Notion for related tasks, starts internal timer.
/runClient workflow launcher. Searches Notion, opens browser, starts Toggl timer.
/newtaskCreates a Notion task and starts a Toggl timer in one flow.
/od-syncSync all Claude Code configs and settings to Google Drive for backup.

Data Flow

The SQLite database acts as the local index that ties external systems together. A company record might have:

  • A notion_id linking to its Notion company page
  • A toggl_client_id linking to its Toggl client entry
  • Internal time entries referencing it by name in the markdown files

When Claude resolves a client context — from an email sender, a task description, or a spoken name — it looks up the company in SQLite, finds related Notion tasks, checks Toggl for active timers, and starts an internal time entry. All in one flow. No single service owns the data; SQLite is the glue.

Email from client
      |
      v
  SQLite lookup (fuzzy match company name)
      |
      +---> Notion: find open tasks for this client
      +---> Toggl: check for running timers
      +---> Internal: start time entry
      |
      v
  Ready to work

Infrastructure

The system is designed to be portable. Two scripts handle migration:

  • migrate-export.sh — Backs up ~/.claude/ configs and ~/OpenDia/ to Google Drive via rclone.
  • migrate-setup.sh — Bootstraps a fresh machine: installs packages, pulls configs from Drive, builds MCP servers, creates the Python environment, and runs 8 verification phases.

The entire OpenDia environment can be rebuilt on a new server from a single script. The database, time entries, commands, memory files, and all configs travel with it.

Hosting

This page is hosted on Cloudflare Pages and deployed from the OpenDia server with a single command:

npx wrangler pages deploy ~/OpenDia/www --project-name=opendia

Persistent Memory

Claude Code maintains a memory directory that persists across conversations. It stores learned patterns, client-specific knowledge, operational rules, and corrections from the Operator. A core memory file is loaded into every conversation, with topic-specific files holding deeper notes.

This gives Claude institutional knowledge that accumulates over time rather than resetting each session. When a mistake is corrected, the correction is saved so it never happens again.

Divisions

DivisionFocus
WordFluxWordPress Design, Development & Hosting
WatchThreatSecurity, Backups & Hardware
AmPenPenetration Testing
Bedford AIAI & Automation
ADA Web WorkAccessibility Compliance

Design Principles

  1. CLI-first, human-optional. Claude handles orchestration; humans interact through familiar UIs or drop into the terminal when needed.
  2. No single source of truth. SQLite bridges services but doesn't replace them. Each system holds its own authoritative data; SQLite holds the cross-references.
  3. Portable and rebuildable. Everything syncs to Google Drive. A new server can be fully provisioned from a single bootstrap script.
  4. Concurrent by default. Multiple tmux sessions, multiple timers, multiple client contexts — all running simultaneously on one server.
  5. Safety guardrails. No emails sent without explicit confirmation. No destructive AWS operations. No force pushes. Claude asks before acting on anything irreversible.
  6. Accumulating intelligence. Memory files capture corrections, patterns, and client-specific knowledge. Claude gets smarter about Linnflux operations with every session.

Built by Linnflux — a Bedford AI project.