Engineering
Clients
Web, native iOS, desktop and MCP retain distinct interaction and authentication boundaries.
Drag to move · Hover to trace. Select to read more. Keyboard: Alt + arrow keys to move.
- Desktop Client
- Web Client
- iOS Client
- MCP Client
- API Transport
- Cloudflare Edge
- Request Boundary
- Domain Service
- Firebase Auth
Drag a card to rearrange it. Select it to learn more.
Connections in words
- Web Client requests application access through Cloudflare Edge.
- iOS Client requests application access through Cloudflare Edge.
- Desktop Client hosts the experience of Web Client.
- MCP Client accesses public APIs through Cloudflare Edge.
- Domain Service checks identity using Firebase Auth.
- Web Client calls explicit API Transport.
- iOS Client uses shared server contracts through API Transport.
- API Transport submits requests to Request Boundary.
- Request Boundary establishes identity through Firebase Auth.
Sharing domains and contracts does not imply identical client behavior or feature coverage.
Web interaction
Server initial data keeps requested pages useful quickly. Heavy optional interfaces load behind user interaction. Explicit client transport carries authentication and request context.
Native and desktop
Native iOS has device-specific interaction and authentication concerns. The hosted desktop shell has another host boundary. Neither creates an independent canonical production data model.
MCP and integrations
Programmatic clients need explicit admission, scopes and domain commands. They are another entry point to authorized work, not a bypass around application policy.
Client graphs and hydration
Keep shells small, pre-hydrate useful data, and lazy-load optional branches. Fetching the next useful data differs from speculatively compiling every authenticated page. Source presence does not establish released parity across clients.
Compare client responsibilities
| Responsibility | Web | iOS | Desktop | MCP |
|---|---|---|---|---|
| UI | Web application | Native coverage varies | Hosted web shell | Tool interface |
| Authentication | Application identity | Shared server identity | Hosted application identity | Separate scoped boundary |
| Contracts | Server contracts | Server contracts | Hosted web contracts | Public API contracts |
| Offline capability | Not assessed | Not assessed | No parity claim | Stateless |
| Server API | Domain services | Domain services | Domain services | Scoped API |
| Local storage | Not assessed | Not assessed | Not assessed | No Firebase credentials |
| Release model | Application release | Incremental native migration | Desktop shell release | Integration release |
Go deeper
Conceptual architecture. Implementation and release status are assessed separately.
Client
Web Client
The React and Next.js product experience.
See this concept connect visually →
Why it exists
The operational application needs interaction and authenticated domain access.
Example
The web crew directory and production workspaces share server contracts.
Connects to
- Web Client requests application access through Cloudflare Edge
- Desktop Client hosts the experience of Web Client
- Web Client calls explicit API Transport
Implementation notes
This engineering site is a separate static project and does not use the application runtime.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
This engineering site is a separate static project and does not use the application runtime.
Conceptual explanation; private implementation details are omitted.
Client
iOS Client
Native UI participating in a SwiftUI migration.
Why it exists
Device experiences need their own UI while respecting shared server identity and authority.
Example
A native production screen uses common server contracts.
Connects to
- iOS Client requests application access through Cloudflare Edge
- iOS Client uses shared server contracts through API Transport
Implementation notes
Native coverage is incremental; supported existing shell experiences coexist during migration.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Native coverage is incremental; supported existing shell experiences coexist during migration.
Conceptual explanation; private implementation details are omitted.
Client
Desktop Client
A Tauri macOS shell around the hosted web application.
Why it exists
Local device capabilities can augment the hosted product without running another backend.
Example
A desktop window opens the hosted Filmclusive experience.
Connects to
- Desktop Client hosts the experience of Web Client
Implementation notes
Desktop does not imply offline parity or an independent local Next.js server.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Desktop does not imply offline parity or an independent local Next.js server.
Conceptual explanation; private implementation details are omitted.
Client
MCP Client
A stateless integration surface with its own authentication boundary.
Why it exists
Tool clients need explicitly scoped access rather than private data-plane credentials.
Example
An authorized MCP tool calls the public application API.
Connects to
- MCP Client accesses public APIs through Cloudflare Edge
Implementation notes
The service is stateless and does not hold Firebase credentials.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
The service is stateless and does not hold Firebase credentials.
Conceptual explanation; private implementation details are omitted.
Infrastructure
Cloudflare Edge
The edge and control plane surrounding application workloads.
See this concept connect visually →
Why it exists
Ingress, static delivery and coordination have different responsibilities from canonical domain data.
Example
The edge delivers assets and forwards admitted application requests.
Connects to
- Publication is delivered through Cloudflare Edge
- Web Client requests application access through Cloudflare Edge
- iOS Client requests application access through Cloudflare Edge
- MCP Client accesses public APIs through Cloudflare Edge
- Cloudflare Edge forwards admitted requests to Next.js Origin
Implementation notes
Public disclosure is limited to provider roles, not private gateways or recovery mechanisms.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
Related decisions
Technical details
Public disclosure is limited to provider roles, not private gateways or recovery mechanisms.
Conceptual explanation; private implementation details are omitted.
Service
Domain Service
Server-owned commands and queries for a bounded domain.
See this concept connect visually →
Why it exists
UI state should not decide privileged transitions or storage authority.
Example
A production command validates context before committing work.
Connects to
- Domain Service returns an authorized Response projection
- Next.js Origin runs Domain Service
- Domain Service persists canonical records in Firestore
- Domain Service accesses admitted files in Storage
- Domain Service checks identity using Firebase Auth
- Domain Service admits background work to Functions / Jobs
- Domain Service uses scoped adapters for External Provider
- Permission / Capability admits scoped commands to Domain Service
Implementation notes
Commands own transitions; queries return bounded authorized projections.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Commands own transitions; queries return bounded authorized projections.
Conceptual explanation; private implementation details are omitted.
Provider
Firebase Auth
The application identity provider.
See this concept connect visually →
Why it exists
Identity verification needs a dedicated provider, separate from domain permission decisions.
Example
Sign-in identifies a user before production access is evaluated.
Connects to
- Domain Service checks identity using Firebase Auth
- Request Boundary establishes identity through Firebase Auth
- Firebase Auth precedes evaluation of Permission / Capability
Implementation notes
Authentication is not authorization.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Authentication is not authorization.
Conceptual explanation; private implementation details are omitted.
Service
API Transport
The explicit client contract for making an application request.
Why it exists
Callers should be clear about which identity and request context they carry.
Example
A client submits a domain command using its declared transport.
Connects to
- Web Client calls explicit API Transport
- iOS Client uses shared server contracts through API Transport
- API Transport submits requests to Request Boundary
Implementation notes
This public example omits internal transport headers and private endpoint details.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
This public example omits internal transport headers and private endpoint details.
Conceptual explanation; private implementation details are omitted.
Service
Request Boundary
Admission, routing and request policy before domain execution.
Why it exists
Privileged requests must reach a checked server boundary before performing work.
Example
A consolidated dispatcher routes an admitted command to a domain handler.
Connects to
- API Transport submits requests to Request Boundary
- Request Boundary establishes identity through Firebase Auth
- App Check attests application context at Request Boundary
Implementation notes
The diagram describes responsibilities, not exact security-control configuration.
Public evidence: Role and audience selection are separate from scoped authority.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
The diagram describes responsibilities, not exact security-control configuration.
Conceptual explanation; private implementation details are omitted.