Architecture — michiu-marketing

The shape of this repo and how it relates to the rest of the Michiu codebase.

Repo's role

This repo houses the internal-facing brand operations for Michiu:

Review system (admin inbox, brand-voice reply generation, multi-platform unification)
Circle of Michiu admin (member management, tier transitions, gestures coordination)
Social media tooling (AI content pipeline orchestration, scheduling)
Tier 3 (RAI Corporate) outreach tracking
Campaign management

It is the canonical owner of the Supabase database schema for the entire Michiu platform.

The three-repo architecture

                ┌─────────────────────────────┐
                │  Obsidian vault             │
                │  (canonical second brain —  │
                │   strategy, brand, ops,     │
                │   process, decisions)       │
                └──────────────┬──────────────┘
                               │
                               │ extracts via build script
                               │ (when needed by code)
                               ▼
        ┌──────────────────────┬──────────────────────┐
        │                      │                      │
┌───────▼────────┐    ┌────────▼────────┐    ┌────────▼────────┐
│ michiu-website │    │michiu-marketing │    │michiu-operations│
│                │    │  (this repo)    │    │   (future)      │
│ Public site    │    │  Brand ops,     │    │  Kitchen,       │
│ Astro · CF     │    │  AI tooling,    │    │  KPIs, SOPs,    │
│ Pages          │    │  schema owner   │    │  ingredients    │
└───────┬────────┘    └────────┬────────┘    └────────┬────────┘
        │                      │                      │
        └──────────────────────┼──────────────────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │  Supabase (shared)   │
                    │  - tables, auth,     │
                    │    storage, vectors  │
                    └──────────────────────┘

Repo responsibilities

Repo	Owns	Reads from Supabase	Writes to Supabase
`michiu-website`	Public-facing UX	Testimonials, journal	Group inquiries, Circle signups, newsletter
`michiu-marketing` (this)	Schema + brand-ops tools	All tables (admin)	All tables (admin)
`michiu-operations`	Internal ops	KPI views, menu, ingredients	Reservations, ops state

Where shared concerns live

Concern	Source of truth	Distribution method
Brand voice (prompts, banned words, tone rules)	Obsidian vault (`Review-Reply-Prompt.md`, `Messaging-Matrix.md`)	Extract script → each repo's `src/brand/` (manual mirror for now; automated extract Phase 5)
Database schema	This repo (`supabase/migrations/`)	Other repos consume via Supabase JS client + generated types
Constants (address, hours, restaurant identity)	Obsidian vault	Hand-mirrored in code; extract pipeline later
Restaurant content (menu items, journal)	`michiu-website/src/content/`	Read-only mirror in this repo if needed

What this repo does NOT do

Customer-facing UI (that's michiu-website)
Kitchen / FoH operations (that's the future michiu-operations)
Hosting public web traffic (different deploy target — internal admin URL when admin UI ships)

Tech stack

Layer	Choice	Why
Language	TypeScript	Type safety across schema + brand assets
Database	Supabase (Postgres + RLS + Auth)	Already provisioned; canonical for the platform
LLM	Anthropic API (Claude Sonnet 4.6 default)	Brand voice quality + reasoning depth
Email	Resend	Transactional alerts, low-volume outreach
Linting	Biome	Faster + simpler than ESLint+Prettier
Package manager	pnpm	Disk-efficient, workspace-ready

When the admin UI is built (Phase 1):

Likely Astro (server-rendered admin routes) or Next.js (more app-shaped)
Auth via Supabase Auth
Deployed to Cloudflare Pages with auth gate, OR a separate provider

Versioning + change discipline

Brand-voice prompts: every prompt file exports a PROMPT_VERSION constant. When the prompt changes:

Bump the version
Log the change in vault Decisions-Log.md
Past replies retain reference to the version that produced them (via prompt_version column in review_replies)
Regression-test against worked examples before deploying

Database migrations: never modify an applied migration. Always write new ones. Migration files are append-only after they ship to production.

Cross-repo type changes: when this repo changes a table that another repo consumes, coordinate the rollout:

Migration applied here
Generated types updated
Consuming repo updates type imports + tests
Deploy in order (database → consumers)

What's NOT here yet

The repo is currently scaffolding + schema + the review-reply prompt. Real applications get built in subsequent phases:

Review admin UI (Phase 1 of review system)
Google Business Profile sync worker (Phase 2)
Review analytics dashboard (Phase 3)
Circle admin UI (parallel track)
Social tooling (parallel track)

See Roadmap in vault for full sequencing.

Related docs

Review System Plan — full architecture of the review subsystem
Review Reply Prompt — annotated source of src/brand/review-prompt.ts
Decisions Log — why the architecture is what it is