cfsa-antigravity 2.19.0 → 2.19.2

package/template/.claude/skills/tdd-workflow/references/typescript.md

@@ -0,0 +1,231 @@
+# TypeScript TDD Patterns
+
+Language-specific patterns for the `tdd-workflow` skill. Read `SKILL.md` first for universal methodology.
+
+---
+
+## Test Frameworks
+
+| Tool | Purpose |
+|------|---------|
+| **Jest** or **Vitest** | Unit + integration test runner |
+| **React Testing Library** | Component testing (user-centric) |
+| **Playwright** | E2E browser automation |
+
+## Commands
+
+```bash
+# Run tests
+npm test
+
+# Watch mode
+npm test -- --watch
+
+# Coverage report
+npm run test:coverage
+
+# E2E tests
+npx playwright test
+```
+
+## Unit Test Pattern (Jest/Vitest)
+
+```typescript
+import { render, screen, fireEvent } from '@testing-library/react'
+import { Button } from './Button'
+
+describe('Button Component', () => {
+  it('renders with correct text', () => {
+    render(<Button>Click me</Button>)
+    expect(screen.getByText('Click me')).toBeInTheDocument()
+  })
+
+  it('calls onClick when clicked', () => {
+    const handleClick = jest.fn()
+    render(<Button onClick={handleClick}>Click</Button>)
+
+    fireEvent.click(screen.getByRole('button'))
+
+    expect(handleClick).toHaveBeenCalledTimes(1)
+  })
+
+  it('is disabled when disabled prop is true', () => {
+    render(<Button disabled>Click</Button>)
+    expect(screen.getByRole('button')).toBeDisabled()
+  })
+})
+```
+
+## API Integration Test Pattern
+
+```typescript
+import { NextRequest } from 'next/server'
+import { GET } from './route'
+
+describe('GET /api/markets', () => {
+  it('returns markets successfully', async () => {
+    const request = new NextRequest('http://localhost/api/markets')
+    const response = await GET(request)
+    const data = await response.json()
+
+    expect(response.status).toBe(200)
+    expect(data.success).toBe(true)
+    expect(Array.isArray(data.data)).toBe(true)
+  })
+
+  it('validates query parameters', async () => {
+    const request = new NextRequest('http://localhost/api/markets?limit=invalid')
+    const response = await GET(request)
+
+    expect(response.status).toBe(400)
+  })
+
+  it('handles database errors gracefully', async () => {
+    // Mock database failure
+    const request = new NextRequest('http://localhost/api/markets')
+    // Test error handling
+  })
+})
+```
+
+## E2E Test Pattern (Playwright)
+
+```typescript
+import { test, expect } from '@playwright/test'
+
+test('user can search and filter markets', async ({ page }) => {
+  await page.goto('/')
+  await page.click('a[href="/markets"]')
+
+  await expect(page.locator('h1')).toContainText('Markets')
+
+  await page.fill('input[placeholder="Search markets"]', 'election')
+  await page.waitForTimeout(600)
+
+  const results = page.locator('[data-testid="market-card"]')
+  await expect(results).toHaveCount(5, { timeout: 5000 })
+
+  const firstResult = results.first()
+  await expect(firstResult).toContainText('election', { ignoreCase: true })
+
+  await page.click('button:has-text("Active")')
+  await expect(results).toHaveCount(3)
+})
+```
+
+## File Organization
+
+```
+src/
+├── components/
+│   ├── Button/
+│   │   ├── Button.tsx
+│   │   ├── Button.test.tsx          # Unit tests
+│   │   └── Button.stories.tsx       # Storybook
+│   └── MarketCard/
+│       ├── MarketCard.tsx
+│       └── MarketCard.test.tsx
+├── app/
+│   └── api/
+│       └── markets/
+│           ├── route.ts
+│           └── route.test.ts         # Integration tests
+└── e2e/
+    ├── markets.spec.ts               # E2E tests
+    ├── trading.spec.ts
+    └── auth.spec.ts
+```
+
+## Mocking External Services
+
+```typescript
+// Supabase mock
+jest.mock('@/lib/supabase', () => ({
+  supabase: {
+    from: jest.fn(() => ({
+      select: jest.fn(() => ({
+        eq: jest.fn(() => Promise.resolve({
+          data: [{ id: 1, name: 'Test Market' }],
+          error: null
+        }))
+      }))
+    }))
+  }
+}))
+
+// Redis mock
+jest.mock('@/lib/redis', () => ({
+  searchMarketsByVector: jest.fn(() => Promise.resolve([
+    { slug: 'test-market', similarity_score: 0.95 }
+  ])),
+  checkRedisHealth: jest.fn(() => Promise.resolve({ connected: true }))
+}))
+
+// OpenAI mock
+jest.mock('@/lib/openai', () => ({
+  generateEmbedding: jest.fn(() => Promise.resolve(
+    new Array(1536).fill(0.1) // Mock 1536-dim embedding
+  ))
+}))
+```
+
+## Coverage Thresholds
+
+```json
+{
+  "jest": {
+    "coverageThresholds": {
+      "global": {
+        "branches": 80,
+        "functions": 80,
+        "lines": 80,
+        "statements": 80
+      }
+    }
+  }
+}
+```
+
+## CI/CD Integration
+
+```yaml
+# GitHub Actions
+- name: Run Tests
+  run: npm test -- --coverage
+- name: Upload Coverage
+  uses: codecov/codecov-action@v3
+```
+
+## Assertion Examples
+
+### ❌ Shallow (BANNED)
+```typescript
+expect(result).toBeDefined()
+expect(result).toBeTruthy()
+expect(response.status).toBe(200)  // alone — doesn't verify body
+```
+
+### ✅ Deep (REQUIRED)
+```typescript
+expect(result).toEqual({
+  id: expect.any(String),
+  name: 'Test Market',
+  status: 'active',
+  trades: expect.arrayContaining([
+    expect.objectContaining({ amount: 100 })
+  ])
+})
+```
+
+## Selector Guidance
+
+### ❌ Brittle
+```typescript
+await page.click('.css-class-xyz')
+```
+
+### ✅ Semantic
+```typescript
+await page.click('button:has-text("Submit")')
+await page.click('[data-testid="submit-button"]')
+```

package/template/.claude/skills/tech-stack-catalog/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: tech-stack-catalog
+description: "Per-surface tech stack decision tables and development tooling options. Use during /create-prd-stack to present constraint-filtered options to the user."
+category: reference
+risk: none
+source: self
+date_added: "2026-02-28"
+---
+
+# Tech Stack Catalog
+
+Reference tables for tech stack decisions organized by project surface type. Used by `/create-prd-stack` to present constraint-filtered options.
+
+## When to Use This Skill
+
+- During `/create-prd-stack` — load the decision tables for each applicable surface
+- When adding a new surface to an existing project
+- When evaluating tech stack alternatives
+
+## How to Use
+
+1. Read the project's surface classification from `docs/plans/ideation/meta/constraints.md`
+2. Load `references/surface-decision-tables.md` for the applicable surface sections
+3. Filter options using constraint questions before presenting
+4. Load `references/dev-tooling-decisions.md` for development tooling
+
+## Reference Files
+
+| File | Contents |
+|------|----------|
+| `references/surface-decision-tables.md` | Universal, web, desktop, mobile, CLI, multi-surface decision axes |
+| `references/dev-tooling-decisions.md` | Package manager, test runner, linter, type checker + bootstrap keys |
+| `references/constraint-questions.md` | Per-axis constraint questions for filtering options |
+
+## Option Presentation Format
+
+For each axis, filter options using constraints, then present:
+
+| # | Option | Strengths | Risks | Fit |
+|---|--------|-----------|-------|-----|
+| 1 | [Option] | ... | ... | [/5] |
+| H | **Hybrid** | [Combine elements] | ... | [/5] |
+
+> **Recommendation**: Based on constraints [list], **Option [N]** scores highest because [rationale].
+
+## Related Skills
+
+- `design-direction` — visual direction interview (runs during stack decisions)
+- `brainstorming` — one-decision-at-a-time approach

package/template/.claude/skills/tech-stack-catalog/references/constraint-questions.md

@@ -0,0 +1,237 @@
+# Constraint Questions
+
+Per-axis constraint questions with mandatory ideation grounding. Every axis has two tiers of questions and a citation gate.
+
+## How to Use This File
+
+For **each** tech stack axis:
+
+1. **Tier 1 — Self-answer from ideation**: Answer these questions by reading the ideation files listed in the **Required Reads** column. Do NOT ask the user these questions — you already have the answers in the ideation output. Write a 3-5 bullet **Ideation Synthesis** summarizing what you found.
+2. **Cite-or-Stop Gate**: Your Ideation Synthesis must contain ≥ 2 project-specific findings with file citations (e.g., "From `diagnostics/diagnostics-index.md`: multi-agent orchestration requires persistent task queues"). If you cannot produce 2 citations → you have not read deeply enough → **STOP** and read the deep dives and CX files before continuing.
+3. **Tier 2 — Ask the user**: Only after passing the citation gate, ask these questions to the user. These are things only the user can answer (budget, team expertise, preferences).
+4. **Present options**: Combine ideation synthesis + user answers to filter and score options. Your recommendation MUST cite ideation findings as supporting evidence.
+
+> ❌ **Anti-pattern**: Presenting generic strengths/risks like "Good ecosystem support" or "Scalable" without tying them to a specific ideation finding. Every strength/risk in the option table must reference a concrete project requirement from the ideation output.
+
+---
+
+## Hosting
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| `meta/constraints.md` → `## Project Surfaces` | Which surfaces need hosting (web, API, desktop distribution, mobile distribution) |
+| `meta/constraints.md` → compliance section | Data residency, regulatory requirements that constrain hosting region/provider |
+| Every domain `{domain}-index.md` | Features requiring edge compute, real-time, WebSocket, or heavy compute |
+| CX files (`ideation-cx.md` + domain CX) | Cross-surface data flow that affects deployment topology |
+| Deep dives with latency or performance mentions | P95 requirements, geographic distribution needs |
+
+### Tier 1 — Self-answer from ideation
+
+- What surfaces need hosting and what type of hosting each requires (static, SSR, API, worker)?
+- Are there latency-sensitive features that require edge deployment?
+- Are there compliance or data residency constraints that limit hosting geography?
+- Do any features require persistent connections (WebSocket, SSE) that affect hosting choice?
+- What is the deployment topology implied by the architecture (monolith, microservices, serverless)?
+
+### Tier 2 — Ask the user
+
+- Is there an existing cloud provider or hosting preference?
+- What is the monthly hosting budget ceiling?
+- How much operational complexity is acceptable (managed vs self-hosted)?
+
+---
+
+## Database / Persistence
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| Every domain `{domain}-index.md` | Entity types, relationship complexity, data cardinality |
+| Deep dives with data model mentions | Graph relationships, hierarchical data, polymorphic entities |
+| Deep dives with search/query mentions | Full-text search, faceted search, complex query patterns |
+| Deep dives with sync/real-time mentions | Offline-first, CRDT, conflict resolution, real-time subscriptions |
+| CX files | Cross-domain entity ownership, shared entities, data flow direction |
+| `meta/constraints.md` | PII fields, compliance (HIPAA/PCI/GDPR) affecting data placement |
+
+### Tier 1 — Self-answer from ideation
+
+- What are the primary entity types and their relationships (flat, hierarchical, graph)?
+- Are there features requiring graph traversal (e.g., dependency chains, social connections, multi-hop queries)?
+- Are there features requiring full-text search, vector similarity, or faceted filtering?
+- What are the read/write patterns implied by the feature workflows (read-heavy dashboards, write-heavy logging, balanced CRUD)?
+- Are there real-time or offline-first requirements that affect database choice?
+- Do any entities require time-series storage (metrics, audit logs, sensor data)?
+- What PII fields exist and what isolation boundaries are required?
+
+### Tier 2 — Ask the user
+
+- Is there existing database expertise or infrastructure to leverage?
+- Are there multi-tenancy requirements the ideation didn't capture?
+- Budget constraints for managed database services?
+
+> **Note**: Database is handled by the Persistence Map Interview in `create-prd-stack.md`. These questions feed into that interview — they do not replace it.
+
+---
+
+## Auth Provider
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| Every domain `{domain}-index.md` → Role Matrix | All roles, permission levels (Full/Config/Read-only/None), per-domain access |
+| `meta/constraints.md` → compliance section | COPPA, GDPR, age restrictions, SSO requirements |
+| Domain deep dives with access control mentions | Multi-tenant isolation, resource ownership, escalation paths |
+| CX files | Trust boundaries across domains, cross-domain permission handoff |
+
+### Tier 1 — Self-answer from ideation
+
+- How many distinct roles exist and what are their permission boundaries?
+- Is there a multi-tenant model (org-level isolation, workspace-level, etc.)?
+- Are there age restrictions or minor-handling requirements (COPPA)?
+- Do any features require granular resource-level permissions (ABAC) vs role-based (RBAC)?
+- Are there third-party integration points that need OAuth/API key authentication?
+- Does the app need social login, SSO/SAML, or enterprise federation?
+
+### Tier 2 — Ask the user
+
+- Is social login (Google, GitHub, Apple, etc.) required? Which providers?
+- Is SSO/SAML needed for enterprise customers?
+- Budget for auth provider (free tier vs paid)?
+- Team experience with specific auth providers?
+
+---
+
+## Frontend Framework
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| `meta/constraints.md` → `## Project Surfaces` | Web surface type (app, content site, hybrid), SEO requirements |
+| Every domain `{domain}-index.md` | UI complexity per domain — forms, dashboards, real-time views, interactive editors |
+| Deep dives with UI/interaction mentions | Complex interaction patterns (drag-drop, canvas, WYSIWYG, collaborative editing) |
+| Deep dives with real-time mentions | Live updates, WebSocket-driven UI, optimistic updates |
+| CX files | Cross-domain navigation patterns, shared UI state requirements |
+
+### Tier 1 — Self-answer from ideation
+
+- Is SSR required for SEO or first-paint performance, or is this a pure SPA?
+- How complex are the interactive patterns (simple forms vs complex editors vs canvas-based)?
+- Are there real-time UI requirements (live dashboards, collaborative editing)?
+- What is the page count / route complexity implied by the feature inventory?
+- Are there offline-first or PWA requirements that affect framework choice?
+- Does the app need to share code with other surfaces (mobile, desktop)?
+
+### Tier 2 — Ask the user
+
+- Team framework experience or preference?
+- Is there an existing frontend codebase to integrate with?
+- Performance priority: bundle size vs DX vs ecosystem maturity?
+
+---
+
+## Backend Framework / Runtime
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| `meta/constraints.md` → `## Project Surfaces` | Backend surface type (API-only, BFF, monolith) |
+| Every domain `{domain}-index.md` | Feature complexity — CRUD-heavy vs computation-heavy vs orchestration-heavy |
+| Deep dives with AI/ML mentions | AI orchestration, model serving, agent coordination |
+| Deep dives with integration mentions | External API calls, webhook handling, queue processing |
+| CX files | Cross-domain business logic, shared middleware requirements |
+
+### Tier 1 — Self-answer from ideation
+
+- What type of backend logic dominates — simple CRUD, complex business rules, AI orchestration, or data pipelines?
+- Are there features requiring long-running processes (agents, batch jobs, async workflows)?
+- What are the latency requirements (P95 targets from deep dives)?
+- Is there a need for background job processing or event-driven architecture?
+- Does the backend need to serve multiple surfaces with different protocols (REST for web, gRPC for internal)?
+- Are there cold-start sensitivity constraints (serverless viability)?
+
+### Tier 2 — Ask the user
+
+- Team language/framework expertise?
+- Deployment target preference (traditional server, serverless, edge)?
+- Is there an existing backend to extend vs greenfield?
+
+---
+
+## API Layer
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| Every domain `{domain}-index.md` | Query complexity per domain — simple lookups vs complex filtered/nested queries |
+| Deep dives with data fetching mentions | Over-fetching risks, real-time subscription needs, batch query patterns |
+| CX files | Cross-domain data aggregation, BFF patterns, gateway needs |
+| `meta/constraints.md` → `## Project Surfaces` | Number of consuming surfaces (affects API style choice) |
+
+### Tier 1 — Self-answer from ideation
+
+- How varied are the data fetching patterns (uniform CRUD vs highly variable query shapes)?
+- Are there features requiring real-time subscriptions?
+- How many surfaces consume the API (affects REST vs GraphQL vs tRPC calculus)?
+- Is there a need for API-to-API communication (microservice internal APIs)?
+- Are there complex nested data requirements that would benefit from flexible query languages?
+
+### Tier 2 — Ask the user
+
+- Is the API public-facing (needs REST + OpenAPI) or internal-only (tRPC viable)?
+- Team experience with GraphQL vs REST vs tRPC?
+- Is API versioning a concern (breaking change frequency)?
+
+---
+
+## CI/CD
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| `meta/constraints.md` → `## Project Surfaces` | Number of deployable surfaces (affects pipeline complexity) |
+| `meta/constraints.md` → compliance section | Audit requirements, approval gates, compliance-mandated scanning |
+
+### Tier 1 — Self-answer from ideation
+
+- How many independently deployable artifacts exist?
+- Are there compliance requirements mandating specific CI/CD gates (security scanning, approval workflows)?
+- Is the project monorepo or polyrepo (affects CI/CD tooling)?
+
+### Tier 2 — Ask the user
+
+- Is there an existing CI/CD provider?
+- Deployment frequency expectations (continuous vs scheduled)?
+- Are manual approval gates needed for production deploys?
+
+---
+
+## Monitoring / Observability
+
+### Required Reads
+
+| File Pattern | What to Extract |
+|---|---|
+| Deep dives with performance/SLA mentions | Which features have SLA requirements driving alert thresholds |
+| `meta/constraints.md` → compliance section | Audit logging requirements, log retention mandates |
+| Every domain `{domain}-index.md` | Features with error-sensitive flows (payments, auth, data sync) |
+
+### Tier 1 — Self-answer from ideation
+
+- Which features are error-critical (payment flows, auth, data integrity)?
+- Are there SLA or uptime requirements from the ideation?
+- What audit logging is mandated by compliance?
+- Are there features requiring distributed tracing (multi-service request paths)?
+
+### Tier 2 — Ask the user
+
+- Is there an existing monitoring stack?
+- Budget for monitoring services?
+- On-call expectations (who gets alerted)?

package/template/.claude/skills/tech-stack-catalog/references/dev-tooling-decisions.md

@@ -0,0 +1,37 @@
+# Development Tooling Decisions
+
+## Tooling axes
+
+| Tool | Question |
+|------|----------|
+| **Package manager / build system** | pnpm, npm, yarn, bun, cargo, go modules, pip/poetry? |
+| **Test runner** | Vitest, Jest, pytest, cargo test, go test, XCTest? |
+| **Linter** | ESLint, Biome, Ruff, clippy, golangci-lint? |
+| **Type checker** | TypeScript (tsc), mypy, Rust compiler, Go compiler? |
+| **Build command** | What builds the project for production? |
+
+## Bootstrap keys to fire after confirmation
+
+After the user confirms all development tooling, fire bootstrap with `PIPELINE_STAGE=create-prd` and ALL of these keys:
+
+- `PACKAGE_MANAGER` — the confirmed package manager (e.g., `pnpm`)
+- `TEST_RUNNER` — the confirmed test runner (e.g., `vitest`)
+- `LINTER` — the confirmed linter (e.g., `eslint`)
+- `TYPE_CHECKER` — the confirmed type checker (e.g., `tsc`)
+- `TEST_COMMAND` — derived from package manager + test runner (e.g., `pnpm test`)
+- `TEST_WATCH_COMMAND` — derived test watch command (e.g., `pnpm test:watch`)
+- `TEST_COVERAGE_COMMAND` — derived coverage command (e.g., `pnpm test:coverage`)
+- `LINT_COMMAND` — derived lint command (e.g., `pnpm lint`)
+- `LINT_FIX_COMMAND` — derived lint fix command (e.g., `pnpm lint:fix`)
+- `FORMAT_COMMAND` — derived format command (e.g., `pnpm format`)
+- `TYPE_CHECK_COMMAND` — derived type-check command (e.g., `pnpm type-check`)
+- `BUILD_COMMAND` — derived build command (e.g., `pnpm build`)
+- `VALIDATION_COMMAND` — the full validation pipeline (e.g., `pnpm test && pnpm lint && pnpm type-check && pnpm build`)
+
+This fills command placeholders in `commands.md`, `workflow.md`, `implement-slice-tdd.md`, and `validate-phase.md`.
+
+## Validation command derivation
+
+```
+{{BUILD_TOOL}} test && {{BUILD_TOOL}} lint && {{BUILD_TOOL}} type-check && {{BUILD_TOOL}} build
+```

package/template/.claude/skills/tech-stack-catalog/references/surface-decision-tables.md

@@ -0,0 +1,69 @@
+# Surface Decision Tables
+
+## Universal decisions (all project types)
+
+| Axis | Decision Needed |
+|------|----------------|
+| **Primary language(s)** | TypeScript, Rust, Go, Python, Swift, Kotlin, C++, etc. |
+| **Database** | ⚠️ **Handled by Persistence Map Interview** in `create-prd-stack.md` — do NOT process as a single axis. Covers primary, vector, graph, cache, and time-series sub-keys. |
+| **Auth provider** | Firebase vs Auth0 vs Clerk vs custom vs OS-level keychain |
+| **CI/CD** | GitHub Actions vs GitLab CI vs custom |
+| **Monitoring** | Sentry vs Datadog vs custom |
+
+## Web surface decisions
+
+| Axis | Decision Needed |
+|------|----------------|
+| **Frontend framework** | SSR vs SSG vs hybrid, which framework (Next.js, Astro, SvelteKit, etc.) |
+| **Backend runtime** | Edge workers vs traditional server vs serverless |
+| **Hosting** | Cloudflare vs Vercel vs AWS vs self-hosted |
+| **CDN/Assets** | Provider-native vs S3 vs Cloudinary |
+
+## Desktop surface decisions
+
+| Axis | Decision Needed |
+|------|----------------|
+| **UI framework** | Tauri vs Electron vs native (GTK, Qt, SwiftUI, WPF, WinUI) |
+| **Cross-platform strategy** | Single OS, cross-platform with shared UI (Tauri, Electron, Flutter Desktop), or cross-platform with native UI per OS |
+| **Local data storage** | SQLite vs LevelDB vs filesystem vs embedded DB (RocksDB, etc.) |
+| **Distribution** | Installer type (MSI, DMG, AppImage, Flatpak), auto-updater strategy (Sparkle, squirrel, custom) |
+| **OS targets** | Windows, macOS, Linux — which combinations and minimum versions? |
+
+## Mobile surface decisions
+
+| Axis | Decision Needed |
+|------|----------------|
+| **Framework** | Native per-platform (Swift/Kotlin) vs cross-platform (React Native, Flutter, .NET MAUI, Kotlin Multiplatform) |
+| **Cross-platform strategy** | iOS-only, Android-only, or both? Shared codebase or separate? |
+| **Local data storage** | SQLite, Realm, Core Data, Room |
+| **Distribution** | App Store, Play Store, enterprise sideload, TestFlight/Firebase App Distribution |
+| **OS targets** | iOS minimum version, Android minimum API level |
+
+## Desktop + Mobile shared decisions
+
+Some frameworks support building for **both** desktop and mobile from one codebase. If the vision indicates this is desired:
+
+| Axis | Decision Needed |
+|------|----------------|
+| **Shared framework** | Flutter (desktop + mobile + web), Kotlin Multiplatform, .NET MAUI, Compose Multiplatform |
+| **Shared vs platform-specific UI** | Fully shared UI, shared logic with native UI per platform, or hybrid? |
+| **Platform-specific features** | What functionality requires native code per platform? (file system, notifications, hardware access) |
+
+## CLI surface decisions
+
+| Axis | Decision Needed |
+|------|----------------|
+| **Language** | Rust (clap), Go (cobra), Python (click/typer), Node (commander/yargs) |
+| **Distribution** | npm, cargo, homebrew, apt, binary releases (goreleaser, cross) |
+| **Shell integration** | Tab completions, man pages, config file format (TOML, YAML, JSON) |
+
+## Multi-surface connection decisions (2+ connected surfaces)
+
+| Axis | Decision Needed |
+|------|----------------|
+| **Shared API protocol** | REST vs gRPC vs GraphQL vs WebSocket between surfaces |
+| **Sync strategy** | Real-time (WebSocket/SSE), eventual consistency (message queue), batch (cron), offline-first (CRDT/merge) |
+| **Shared contract layer** | How are data shapes shared? Monorepo with shared package? Published npm/crate package? Code generation from OpenAPI/protobuf? |
+| **Auth federation** | Shared auth server with SSO? OAuth2 token exchange? Separate auth per surface? |
+| **Conflict resolution** | Last-write-wins, operational transform, CRDT, manual resolution, server-authoritative |
+| **Offline support** | Which surfaces work offline? What data is cached locally? How are conflicts resolved on reconnect? |