Dr.Social PROD

1. Mission

A single system that can create, read, update, and delete on any major social platform — starting with Instagram TikTok LinkedIn and easily extending to Twitter / X YouTube Threads Facebook.

Who this is for

Dr.Social is built for marketing agencies. A single agency is one tenant and manages many independent talents (not a group — each talent is an autonomous, real human personality with their own goals, voice, look, and audience). Every talent runs multiple accounts across multiple platforms, each with their own following, and is represented end-to-end in the system by a rich talent profile stored in the database.

What a talent profile holds

The profile is the source of truth for everything the system does on behalf of a talent:

• Identity & contact: display name, real name, emails, phone, timezone, language, owner-user link.
• Connected accounts: every social handle the talent owns, each bound to one execution channel (see isolation rule).
• Credentials & secrets: per-account session cookies, OAuth grants — all stored in Supabase Vault, never in plaintext columns.
• Personality & voice: personality narrative, tone-of-voice, content pillars, "do not say" list, goals and KPIs, stories and lore that frame how the talent presents online.
• Media library: face references, voice clone (opt-in), brand kit, pictures, videos, wardrobe — reused across every account so the same talent feels consistent everywhere.
• Content queue & schedule: drafts and ready-to-post pieces, posting cadence per account, time windows, blackout dates.
• Approval state: which pieces have been approved by the talent (the actual human owner) and are cleared to publish.

Capabilities (V1)

• Agency-grade tenancy: one agency manages many talents; one talent manages many accounts; one account is bound to one platform and one channel.
• Account lifecycle: import existing accounts (cookie-based or OAuth), manage them, retire them. Automated signup → V2.
• Content production: generate videos, photos, audio, and text — always conditioned on the target talent's profile — then publish them as posts / reels / shorts / articles.
• Inbound communications, in-character: read and respond to DMs, public-post replies, comments, and mentions as that specific talent.
• White-label PersonaAgent: a reusable agent template that is conditioned on a talent's profile at every call. Carries that talent's personality, media, goals; acts on their behalf. Many talents share the same agent code; each call is stateless.
• Owner approval gate: the talent portal gives the real human behind each talent a dedicated view to approve or reject their own content queue before anything is published.
• Autonomous operations: a tenant-wide cron tick fans out per-talent agent work.
• Operator supervision: a web dashboard exposes accounts, queue, and inbox for human override at the agency level.

1.b Multi-Tenancy & Talent Model

Dr.Social is a multi-tenant SaaS: every record in the system is owned by a tenant (a client of ours — an agency, a creator team, a brand). Inside a tenant, the unit of "who" is a talent — a real human personality whose social presence we manage. One talent can run many accounts, across many platforms, on any channel. This shape is the spine of the data model and shows up in every agent, every query, every dashboard view.

What "talent-centric" buys us

• Cross-account media consistency. Every video, photo, and audio piece generated for the talent uses the same face reference / voice clone / brand kit. A new account spun up for an existing talent inherits all of that on day one.
• Operator UX. The dashboard groups accounts by talent; the operator manages "Aurora Studios" as one entity, not 3 disconnected handles.
• Compliant deletion. Tenant-scoped RLS plus a talent-level "right to erasure" makes GDPR/CCPA workflows tractable.

2. System Overview

The system stacks into six layers. Each upper layer only knows about the layer immediately below it through a stable interface, so the lower layers are individually replaceable.

3. The 6 Layers

4. Orchestration — 4 LLM Agents + Services

V1 has exactly four agents that need an LLM in the loop — anything reasoning, generating, or classifying. Everything else is a plain Python module (no agent ceremony). Don't commit to a heavyweight agent framework (e.g. Google ADK A2A) until V2 actually needs peer-to-peer agent topology; V1's orchestration is a star (Workflow → agent) and a simple async function-call graph is enough.

Services (plain Python — no agent ceremony)

Example tick (cron → per-talent fan-out)

workflow.tick()
  for talent in tenants.active_talents(due_now):
      ctx = load_talent_context(talent)                  # profile, recent posts, inbox, queue

      for account in ctx.accounts:
          if persona_decide_should_post(talent, account, ctx):
              brief  = persona_decide_brief(talent, account, ctx)
              draft  = content_generate(talent, brief)         # ContentAgent
              if moderation_approve(draft):
                  content_queue.enqueue(talent, account, draft,
                                        status='awaiting_owner_approval')

          # publish only what the owner has already approved
          for piece in content_queue.due_and_approved(talent, account):
              post_publish(account, piece)                     # PostAgent / adapter

          for msg in inbox_fetch(account):                     # InboxAgent
              if moderation_approve_inbound(msg):
                  reply = persona_draft_reply(talent, msg)
                  inbox_send(account, msg.thread, reply,
                             status='awaiting_owner_approval')

Two invariants to notice: (1) no backend is selected at runtime — the dispatcher reads accounts.channel and refuses any other. (2) nothing publishes without owner approval — every draft and reply lands in the queue and only the pieces the human owner has approved are eligible.

5. LLM Provider — abfs.tech router

All four LLM agents call a single internal provider: the abfs.tech LLM router at https://www.abfs.tech/v1/. The router is already operational and serves Anthropic Claude models through Anthropic-compatible and OpenAI-compatible endpoints, with subscription rotation and per-key logging. Dr.Social doesn't talk to Anthropic / OpenAI / any model provider directly — only to this router.

Why this matters

• Single billing surface. Every LLM dollar Dr.Social spends shows up in the abfs.tech admin — usage attribution, key revocation, subscription rotation handled there, not here.
• Drop-in model swaps. Bumping Sonnet 4.6 → 4.7 (or trying GPT for an experiment) is a config change, not a code change. The router exposes a uniform shape on both sides.
• One thing to monitor. Latency / error rate / token consumption all observed at the router level (already wired). Dr.Social's worker just retries on 5xx.

# Pseudocode — every LLM call in Dr.Social goes through this client.
class LlmRouterClient:
    def __init__(self, base_url="https://www.abfs.tech", api_key=ENV["ABFS_LLM_API_KEY"]):
        self.base_url = base_url
        self.api_key  = api_key

    async def messages(self, *, model, system, messages, stream=False):
        # POST /v1/messages — Anthropic-shaped
        ...

    async def chat(self, *, model, messages, stream=False):
        # POST /v1/chat/completions — OpenAI-shaped
        ...

6. Platform Adapter Layer

Every social network is reduced to one Python interface. Agents above call this interface — they never know if they're driving Instagram or LinkedIn.

class SocialPlatform(Protocol):
    name: str  # "instagram" | "tiktok" | "linkedin" | ...

    # account lifecycle (V1 = import-only)
    async def import_account(self, profile: ImportedProfile, backend: Backend) -> Account: ...
    async def login(self, account: Account, backend: Backend) -> Session: ...
    async def logout(self, account: Account) -> None: ...
    async def health_check(self, account: Account) -> AccountHealth: ...

    # create / update / delete
    async def publish_post(self, account: Account, content: Content) -> PostRef: ...
    async def edit_post(self, account: Account, post: PostRef, patch: ContentPatch) -> PostRef: ...
    async def delete_post(self, account: Account, post: PostRef) -> None: ...

    # read
    async def read_feed(self, account: Account, limit: int) -> list[Post]: ...
    async def read_post(self, account: Account, post: PostRef) -> Post: ...
    async def read_dms(self, account: Account, since: datetime) -> list[Message]: ...
    async def read_comments(self, account: Account, post: PostRef) -> list[Comment]: ...
    async def read_mentions(self, account: Account, since: datetime) -> list[Mention]: ...

    # respond
    async def send_dm(self, account: Account, thread: ThreadRef, body: str, media: list = []) -> None: ...
    async def reply_comment(self, account: Account, comment: CommentRef, body: str) -> None: ...
    async def react(self, account: Account, target: Ref, reaction: str) -> None: ...

7. Execution Backends (V1: Device + MCP)

V1 ships with two backends. The Browser channel is documented as V2 §1 — its absence is what makes V1 tractable.

Capability matrix (what each backend can do)

The matrix above is descriptive (what's possible). It is not a runtime fallback path — see the isolation rule below.

⛔ Channel isolation rule (hard constraint)

-- accounts.channel is set once and never changes
alter table accounts
  add column channel text not null
  check (channel in ('device', 'mcp'));         -- V2: add 'browser'

create or replace function lock_channel() returns trigger as $$
begin
  if NEW.channel is distinct from OLD.channel then
    raise exception 'channel is immutable on account %', OLD.id;
  end if;
  return NEW;
end $$ language plpgsql;

create trigger accounts_channel_immutable
  before update on accounts
  for each row execute function lock_channel();

-- worker dispatch (no `required_channel` on jobs; the account row is truth)
job = claim_next_job()
account = load(job.account_id)
backend = load_backend(account.channel)         -- ONLY this backend, no fallback
backend.execute(job)

8. Identity (V1 minimal set)

V1 needs the absolute minimum to act on existing accounts. Anti-bot stealth, signup automation, 2FA relay, fingerprint pools, proxy fleets — all V2.

9. Content Pipeline

• Briefs come from Analytics (past performance), PersonaAgent (autonomous), the operator (manual), or a talent post request (see §10).
• Assets are persisted to Supabase Storage keyed by content hash; only metadata lives in the Postgres content table.
• ModerationAgent blocks anything flagged before it reaches the publish queue.
• The PublishQueue is platform-aware: a single brief produces one variant per target platform — each variant lands as its own content_queue row with appropriate aspect, length, hashtags.

9.b Media Generation Stack

ContentAgent decides what to make. The vendors below actually make it. V1 picks the smallest set that produces images, voiceover, subtitles, and edited video — without the V2-grade cost and quality penalty of text-to-video generation.

How a "no-media" post request becomes a reel

When a talent submits a request with prompt-only and TikTok as the target, the pipeline composes a reel without text-to-video:

Vendor pinning

• Replicate stays as the image+transcription router; specific models swappable in media/config.py.
• ElevenLabs is the one vendor we'd genuinely struggle to replace — voice clone quality + streaming TTS at their level isn't a commodity yet. Worth paying for.
• The media/ module exposes a stable shape: generate_image(prompt, talent) → url, tts(text, talent) → url, transcribe(url) → text+timings, compose_reel(brief) → url. Swap vendors behind it without touching ContentAgent.

10. Post Request Pipeline

Content reaches the approval queue from two distinct sources — both treated equally downstream:

• AI-initiated — ContentAgent invents content from scratch using the talent's profile, goals, content pillars, and recent engagement. This is the "what to post next" path described in §9.
• Talent post requests — the talent explicitly asks for a post: a prompt + a target-platform selection, plus optional media attachments. This section describes that path.

Post requests matter because most talents have specific things they want said or shown that the AI won't dream up on its own — a launch, a reaction, a behind-the-scenes moment. Media is optional: a request can be just a prompt + platforms (the system generates content from scratch in the talent's voice), just media + platforms (the system writes captions and cuts the assets for each platform), or both.

What a post request carries

• Target platforms (required) — one or more of the talent's connected accounts. Each selected account produces a platform-tailored variant the talent approves independently in the queue.
• Prompt (optional) — a sentence or paragraph saying what the post is about. Empty prompt = the AI picks a topic from the talent's content pillars.
• Attached media (optional) — photos, video, voice memos. If present, the system edits them to fit each platform; if absent, content is generated from scratch.
• Schedule hint (optional) — preferred publish time or "ASAP". Defaults to the talent's posting cadence per account.

Two ingress paths (both V1)

Why this works at MVP without SES/Postmark

• Cloudflare Email Routing preserves the original To: header on forward — so we can still extract the talent slug from each message even though every email lands in one Gmail inbox.
• One Gmail App Password (with 2FA on the Gmail account) gives us IMAP-IDLE-compatible access; no SES domain config, no SNS topic, no Edge Function MIME parser.
• Operator visibility is a side effect: every talent request also appears in the operator's Gmail, which is useful for the MVP-stage operator who wants to eyeball traffic.
• If Gmail's IMAP rate limits become a problem (≫1 message/second sustained), we graduate to SES or Postmark inbound — described in V2 §7. Not before.

Pipeline stages

What the pipeline produces

• One request → one row per selected platform. If the request targets TikTok + Instagram, two content_queue rows are created, grouped under the same post_request_id in the talent's approval queue UI. The talent sees the request as a single "post idea" with stacked per-platform variants.
• Per-platform approval. The talent can approve the TikTok variant and reject the Instagram one (or vice versa). An "Approve all" shortcut covers the common case where every variant looks good. PostAgent only publishes approved rows.
• Mixed in with AI-initiated content. The approval queue doesn't segregate by origin; AI-initiated and request-derived ideas sit side by side, each tagged with provenance.
• Voice cloning is opt-in per talent. If the talent has agreed and uploaded reference audio (managed under Brand & voice in /me), transcribed voice memos can return as polished narration in their voice.
• Rejection learning loop. When a talent rejects a variant with a reason, the text is appended to that talent's style guide and used to filter future drafts.
• Operator visibility. Operators see every request a talent has sent but cannot publish without the talent's approval (unless the talent has explicitly opted into operator-override mode in their preferences).

Schema additions (V1 sketch)

post_requests          (id, tenant_id, talent_id,
                        source CHECK in ('browser', 'email'),
                        prompt_text NULL,                  -- empty = let AI pick from pillars
                        target_account_ids[],              -- one variant generated per
                        schedule_hint NULL,
                        sender_email NULL,                 -- populated for source='email'
                        gmail_message_id NULL UNIQUE,      -- populated for source='email'; dedup key
                        status in ('received','analyzing','drafting','complete','failed'),
                        created_at, processed_at)

post_request_attachments (id, post_request_id, storage_path, mime, bytes, duration_s,
                          analysis_json NULL,              -- scenes, faces, hooks, OCR …
                          transcript_text NULL)
                          -- zero rows if the request had no media

content_queue.origin            enum: 'ai_initiated' | 'request_browser' | 'request_email'
content_queue.post_request_id   NULL unless origin is 'request_*'
content_queue.rejection_reason  captured at owner rejection — fed into talent style guide

Talent slug rules

• Each talent has a globally unique slug column (e.g. aurora-lee). The catch-all email forwarding model means slugs collide across tenants, so uniqueness is enforced tenant-globally, not tenant-scoped, for this one column.
• Slug is lowercase ASCII, hyphens allowed, 3–32 chars, no leading/trailing hyphen. Anything else is rejected at create time.
• Format: <slug>[email protected] for post requests. Reserve +post, +settings, +inbox as future intents — the IMAP parser refuses unknown suffixes for now.

11. Data Model (V1)

~9 tables. Every tenant-scoped table carries tenant_id NOT NULL and is gated by an RLS policy. Composite FKs (tenant_id, id) on every cross-table reference make the database refuse cross-tenant attachments.

Tenancy & identity

tenants                (id, name, plan, status,
                        default_tick_interval_seconds,
                        created_at)
                       -- one row per agency. Per-talent override → V2 §8

tenant_users           (id, tenant_id, supabase_user_id,
                        role CHECK in ('owner','editor','viewer'))

talents                (id, tenant_id, display_name, real_name,
                        bio_short, bio_long, timezone, language, status,
                        owner_user_id,                       -- the real human who must approve
                        primary_email, contact_emails[], phone,
                        created_at)

talent_profile         (talent_id PK,
                        personality_md, stories_md,
                        goals_json,
                        face_ref_urls[], voice_clone_ref NULL,
                        brand_kit_json, style_guide_md,
                        content_pillars[], hashtag_preferences[], do_not_say[],
                        updated_at)
                       -- 1:1 with talents; split out only for size

talent_assets          (id, talent_id, kind in ('face','voice','logo','wardrobe','bgm',
                                                'picture','video','document'),
                        storage_url, hash, metadata_json, created_at)

Accounts & channel-bound identity

accounts               (id, tenant_id, talent_id, platform, handle, status,
                        channel CHECK (channel in ('device','mcp')) IMMUTABLE,
                        vault_ref,                          -- session cookies OR OAuth refresh
                        posting_schedule_json,
                        created_at)
                       -- one row per (platform, talent, channel)

Content, queue, requests

content                (id, tenant_id, talent_id, hash, type, asset_url,
                        caption, hashtags, generated_by, moderated, created_at)

content_queue          (id, tenant_id, talent_id, account_id, content_id,
                        origin enum ('ai_initiated','request_browser'),
                        post_request_id NULL,
                        scheduled_for,
                        state CHECK in
                          ('draft','awaiting_owner_approval','approved','rejected',
                           'queued','published','failed'),
                        approved_by_user_id, approved_at,
                        rejected_reason,
                        created_at, updated_at)
                       -- per-talent publish queue shown on /me

post_requests          (id, tenant_id, talent_id,
                        prompt_text NULL,
                        target_account_ids[],
                        schedule_hint NULL,
                        status in ('received','analyzing','drafting','complete','failed'),
                        created_at, processed_at)

post_request_attachments (id, post_request_id, storage_path, mime, bytes, duration_s,
                          analysis_json NULL, transcript_text NULL)

Inbox & activity

threads                (id, tenant_id, account_id, peer_handle, last_message_at)
                       -- V2 adds audience_identity_id (cross-platform identity resolution)

messages               (id, tenant_id, thread_id, direction, body, media_urls,
                        classified_as, status, created_at)

jobs                   (id, tenant_id, account_id, kind, payload_json, status, run_after)
                       -- no required_channel column; account.channel is the source of truth

events                 (id, tenant_id, ts, kind, account_id, payload_json)
                       -- audit + activity stream

Invariants enforced in Postgres: (1) accounts.channel is immutable (trigger blocks UPDATE). (2) tenant_id consistency — every FK across tables uses composite (tenant_id, id), so the database refuses to attach an account in tenant A to a talent in tenant B. (3) RLS policies on every tenant-scoped table.

12. Dashboards (operator + talent self-service)

Two server-rendered web UIs, two different audiences, one shared backend. Both are tenant-scoped — Supabase RLS enforces tenant isolation on every query. Python templates + htmx for partials; polling at ~5s for "live" panels. (React + Vite frontend → V2 §10. Supabase Realtime → V2 §9.)

• 12.a · Operator dashboard — multi-talent supervision view for agency staff. Mockup: dashboard/_layout.html.
• 12.b · Talent self-service portal — single-talent workspace for the human represented by the persona. Mockup: dashboard/me.html.

12.a — Operator dashboard (V1: 6 pages)

Top-level navigation pivots around talents, not accounts. Agency staff see all talents under their tenant, run overrides, supervise inboxes, and watch system health.

12.b — Talent self-service portal (/me)

A standalone single-page workspace for the talent themselves. Scoped to one talent — the one whose owner_user_id matches the logged-in Supabase Auth user. Different chrome from the operator dashboard (warmer accent, no tenant switcher, no cross-talent navigation). Mockup: dashboard/me.html.

13. Workflows & Scheduling

Scheduling lives inside Supabase via pg_cron. A row in a jobs table is inserted on every tick; the worker process polls jobs WHERE status='pending' using SELECT … FOR UPDATE SKIP LOCKED — a clean Postgres-native queue with no Redis or Celery.

Tick cadence is tenant-level in V1

V1 has a single cadence per tenant — tenants.default_tick_interval_seconds — driving every talent in that tenant. The Workflow handler iterates the tenant's active talents on each tick and fans out per talent. Per-talent override and dynamic adjustment (warm-up, blackouts, burn back-off) → V2 §8.

• Baseline wake-up: pg_cron inserts a tick job at the tenant's configured interval → Workflow picks it up and fans out.
• Posting cadence: per-account schedule stored in accounts.posting_schedule_json. The tick checks "is it time?" and enqueues a publish job — but only for items already approved in content_queue.
• Inbox polling: per-account interval; MCP adapters that support webhooks register a Supabase Edge Function URL and skip polling entirely.
• Live dashboard fan-out (V1): dashboard polls at ~5s. Real-time subscriptions → V2 §9.

-- pg_cron entry — tenant cadence configurable, not hard-coded
select cron.schedule(
  'drsocial-baseline-tick',
  '* * * * *',                                         -- once per minute baseline
  $$ insert into jobs (kind, payload) values ('tick', '{}') $$
);

-- Workflow handler (per tick, per tenant)
for tenant in tenants.active():
    if not tenant.is_tick_due(now):
        continue
    for talent in tenant.active_talents():
        fan_out(talent, now)

-- Atomic job pick
select id, kind, payload
from jobs
where status = 'pending' and run_after <= now()
order by run_after
limit 1
for update skip locked;

14. Tech Stack

One Railway service, one managed backend (Supabase), one external LLM provider (abfs.tech router). That's the whole infrastructure for V1.

What's used (V1)

What's deliberately NOT used (V1)

• ❌ Redis · ❌ Celery · ❌ RabbitMQ · ❌ Vaultwarden · ❌ S3 / GCS / Drive · ❌ Separate websocket server · ❌ Kubernetes · ❌ Docker Compose stack with N services · ❌ Node toolchain · ❌ React / Vue / Svelte · ❌ Google ADK A2A framework (pick when needed)

14.b Deployment — Railway.app

• One service, one Dockerfile, one Procfile-style start command.
• No databases on Railway. No volumes on Railway. Restart-safe by design — all state in Supabase.
• Cost target: $5–20/mo Railway + Supabase free tier + Replicate pay-per-use + ElevenLabs starter tier. Scales with media volume, not user count.

V1 environment variables

# Auto-set by Railway
PORT
RAILWAY_ENVIRONMENT_NAME

# Supabase (one set per env)
SUPABASE_URL
SUPABASE_SERVICE_KEY
SUPABASE_ANON_KEY

# LLM provider (abfs.tech router)
ABFS_LLM_API_KEY                  # bearer for https://www.abfs.tech/v1/

# Media generation
REPLICATE_API_TOKEN               # FLUX, Whisper, etc.
ELEVENLABS_API_KEY                # voice clone + TTS

# MCP backend (LinkedIn, etc.)
COMPOSIO_API_KEY

# Device backend (on-prem hub)
DEVICE_HUB_URL                    # e.g. https://devicehub.yourbiz.com:4723
DEVICE_HUB_TOKEN                  # bearer for the device hub

# Email post-request intake (Gmail IMAP poll, V1 MVP shape)
GMAIL_INTAKE_USER                 # e.g. [email protected]
GMAIL_INTAKE_APP_PASSWORD         # Gmail App Password (requires 2FA on the account)

Live environments mockup hosting only — no business runtime yet

Two Railway environments host the design-phase mockups via serve.py (a small stdlib HTTP server that templates the operator-dashboard fragments and serves the talent portal + this doc). The real FastAPI service arrives when implementation begins.

15. Repo Layout

Today (planning phase)

Dr.Social/
├── docs/
│   ├── ARCHITECTURE.html       # this document (V1)
│   └── ARCHITECTURE_V2.html    # deferred features
├── dashboard/
│   ├── _layout.html            # operator-portal shell ({{TITLE}}, {{CONTENT}}, …)
│   ├── _overview.html          # operator-portal page fragments (5)
│   ├── _talents.html
│   ├── _accounts.html
│   ├── _queue.html
│   ├── _inbox.html
│   ├── _settings.html
│   └── me.html                 # standalone talent self-service portal
├── serve.py                    # tiny stdlib HTTP server that renders the fragments
├── Procfile                    # web: python serve.py  (Railway start command)
├── pyproject.toml              # minimal — signals Python project to Railway nixpacks
└── README.md

Target (V1 implementation)

Dr.Social/
├── src/drsocial/
│   ├── agents/                  # the 4 LLM agents — each thin, all call llm_router
│   │   ├── persona.py           # persona_decide_*  — stateless functions
│   │   ├── content.py           # content_generate
│   │   ├── inbox.py             # inbox_fetch + classify + reply-draft
│   │   └── moderation.py        # moderation_approve, moderation_approve_inbound
│   ├── services/                # plain Python — no agent ceremony
│   │   ├── workflow.py          # pg_cron-driven tick handler
│   │   ├── account_importer.py  # session-cookie / OAuth import + health check
│   │   ├── request_agent.py     # raw-media preprocessing (scenes/OCR/transcript)
│   │   ├── post_publisher.py    # publishes approved content via platform adapter
│   │   └── analytics.py         # SQL rollups
│   ├── media/                   # media generation + editing — stable API, swappable vendors
│   │   ├── images.py            # generate_image(prompt, talent) — Replicate FLUX + face LoRA
│   │   ├── audio.py             # tts(text, talent), clone_voice(refs) — ElevenLabs
│   │   ├── transcribe.py        # Whisper via Replicate
│   │   └── ffmpeg.py            # reel composer, aspect reformat, subtitle burn-in, BGM
│   ├── intake/                  # post-request ingress
│   │   ├── browser.py           # /me form handler — multipart upload to Storage
│   │   └── gmail_imap.py        # IMAP poller; parses To: → talent_slug; dedup via gmail_message_id
│   ├── platforms/               # adapter layer
│   │   ├── base.py              # SocialPlatform protocol
│   │   ├── instagram.py
│   │   ├── tiktok.py
│   │   └── linkedin.py
│   ├── backends/                # execution
│   │   ├── device.py            # Appium / XCUITest / ADB client
│   │   └── mcp.py               # Composio client
│   ├── llm_router.py            # thin client for https://www.abfs.tech/v1/
│   ├── supabase_client.py       # one client (DB + Storage + Vault + Auth)
│   ├── jobs.py                  # pg_cron-driven queue helpers
│   ├── api.py                   # FastAPI — REST + serves dashboard + serves /me
│   ├── settings.py
│   └── main.py                  # entrypoint: runs api + worker in one asyncio loop
├── dashboard/                   # htmx + Jinja templates, served by api.py
├── supabase/
│   ├── migrations/              # plain .sql files
│   └── seed.sql
├── tests/
├── Dockerfile                   # single image — runs api + worker
├── railway.json                 # single-service Railway config
└── pyproject.toml