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)
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.
Architecture
The three layers
Layer 1 — Shared libraries (the only things that need to "flow downstream")
magiclink-auth-gogo get@teslashibe/expo-ui-kitfile:in dev, npm later@teslashibe/expo-magiclink@teslashibe/web-ui-kitSecurity/feature update workflow: push to package →
npm update/go get -uin client repos → done.Layer 2 — The seed (
agent-setup)A GitHub Template Repository, not a dependency.
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:
npm update,go get -u) — automatic via Dependabot/Renovategit merge upstream/main(or cherry-pick)Concrete next steps (in order)
mobile/toagent-setup(port fromtemplate-app, one-time copy)web/toagent-setup@teslashibe/expo-ui-kitand@teslashibe/expo-magiclinkonly when a second consumer (a real client app) needs them — YAGNI until thenagent-setupas a GitHub Template Repository so "Use this template" appearsWhat we are explicitly NOT doing (avoiding over-engineering)
template-appas anything other than a reference; it will be replaced byagent-setuponce it has mobile + webTL;DR