Skip to content

Architecture: agent-setup as the seed (mobile + web + shared packages) #1

@teslashibe

Description

@teslashibe

Architecture

The three layers

SHARED LIBRARIES        ← versioned packages, updated centrally
        ↓
SEED REPO (agent-setup) ← the "starter": shared libs + Claude agent + web/mobile shells
        ↓
CLIENT REPOS            ← forked from seed per client, customized

Layer 1 — Shared libraries (the only things that need to "flow downstream")

Package What it is How it's consumed
magiclink-auth-go Go auth lib (already exists) Go module — go get
@teslashibe/expo-ui-kit Mobile UI primitives (Button, Card, Input, OTP, …) npm — file: in dev, npm later
@teslashibe/expo-magiclink AuthSessionProvider + API client npm
@teslashibe/web-ui-kit Web equivalents (when we add web) npm

Security/feature update workflow: push to package → npm update / go get -u in client repos → done.

Layer 2 — The seed (agent-setup)

A GitHub Template Repository, not a dependency.

agent-setup/
├── backend/        Fiber + Goose + TimescaleDB + Claude agent loop  ✅ done
├── mobile/         Expo app (consumes the shared packages)          🚧 to add
├── web/            Next.js app (consumes the shared packages)       🚧 to add
└── deploy/         Fly.io / Cloud Run / K8s manifests                ✅ done

The seed is mostly thin glue — screens, routes, agent tools. Heavy reusable code lives in the packages (Layer 1), so when we update them, every client app pulls fixes via standard package updates.

Layer 3 — Client repos

For each client: "Use this template" on GitHub → new repo → customize.

What flows down:

  • ✅ Package updates (npm update, go get -u) — automatic via Dependabot/Renovate
  • ✅ Seed-level improvements via periodic git merge upstream/main (or cherry-pick)
  • ❌ Client-specific code stays in the client repo

Concrete next steps (in order)

  • Add Expo mobile/ to agent-setup (port from template-app, one-time copy)
  • Add Next.js web/ to agent-setup
  • Wire both frontends to the agent SSE endpoints (sessions list + streaming chat)
  • Extract @teslashibe/expo-ui-kit and @teslashibe/expo-magiclink only when a second consumer (a real client app) needs them — YAGNI until then
  • Wire Dependabot in client repos so package updates auto-PR
  • Mark agent-setup as a GitHub Template Repository so "Use this template" appears

What we are explicitly NOT doing (avoiding over-engineering)

  • ❌ Monorepo with workspaces — adds tooling complexity for two apps
  • ❌ Git submodules — annoying and we'll regret them
  • ❌ Extracting packages today before we have two consumers
  • ❌ Treating template-app as anything other than a reference; it will be replaced by agent-setup once it has mobile + web

TL;DR

agent-setup is the seed (a GitHub Template Repo). Reusable code lives in versioned packages. Clients fork the seed and get updates via npm update and the occasional upstream merge.

Metadata

Metadata

Assignees

No one assigned

    Labels

    architectureArchitecture decisions and planning

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions