oc-stack-forge

# Stack Forge

**On first invocation, read `references/orchestrator.md` and follow its welcome protocol.**

Opinionated stack advisor that helps you pick the right tools and enforces type safety
across whatever stack you choose. Auto-invoked by oc-app-architect during Phase 2 — you
don't call it separately for new projects.

Works with any stack: Cloudflare Workers, Vercel/Next.js, AWS Lambda, Supabase, Rails,
Django, Go, Rust — the decision framework is universal. The implementation patterns are
stack-specific, loaded from reference docs at runtime.

## How This Skill Fits the Build Pipeline

```
APP-ARCHITECT (planning)                TRI-DEV (building)
  Phase 2: Spec ──auto-calls──▶ oc-stack-forge decision tree
  Phase 5: Scaffold ──auto-calls──▶ oc-stack-forge project structure
                                         │
  Feature request ───────────────────────▶ /oc-feature → sprint decomposition
                                         │
                                   Planner reads feature-decomposition
                                   Generator reads stack-specific patterns
                                   Evaluator reads per-layer criteria
```

**App-architect auto-invokes oc-stack-forge** — when Phase 2 starts, oc-stack-forge's decision
tree runs automatically to generate `01-tech-stack.md` and `02-architecture.md`. The user
doesn't need to call `/oc-stack-forge` separately. Stack-forge reads the discovery interview
results and recommends the best stack for the project's requirements.

**App-architect Phase 6 uses oc-stack-forge** for stack-ordered sprint decomposition regardless of stack choice.

---

## /oc-stack-forge — Command Reference

```
STACK FORGE COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  STACK SELECTION
  /oc-stack-decide     Run the full stack decision tree
  /oc-stack-compare    Compare 2-3 specific stack options side by side

  PATTERNS
  /typed-pipeline   Set up type chain for the selected stack
  /testing          Configure testing pyramid for the stack
  /oc-deploy           Deployment patterns for the selected platform
  /errors           Error handling + logging patterns
  /ci               CI pipeline for the stack

  TRI-DEV INTEGRATION
  /oc-feature          Decompose a feature into stack-ordered sprints

  SESSION
  /checkpoint       Show checkpoint status
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

---

## Stack Decision Tree (`/oc-stack-decide`)

### How It Works

The decision tree adapts to the project. It doesn't assume Cloudflare or any platform —
it starts from requirements and narrows down. Skip questions where the answer is already
clear from oc-app-architect discovery, user memory, or conversation context.

**Before answering any question, web search for current best practices.** Frameworks
change fast — a recommendation from 6 months ago may be wrong today. Search for
"[framework] production readiness 2026" or "[A] vs [B] for [use case]" before committing.

### Question 1: Platform & Hosting

Start here because it constrains everything downstream.

| Factor | Ask |
|---|---|
| Deployment target | Where does this run? Edge (CF Workers, Vercel Edge), serverless (Lambda, Cloud Run), container (Fly.io, Railway), VPS (DigitalOcean), or managed PaaS (Heroku, Render)? |
| User geography | Global (needs edge/CDN) or regional (single-region fine)? |
| Budget | Free tier required? What's the monthly ceiling? |
| Existing infra | Is the team already on AWS/GCP/CF/Vercel? Don't migrate without reason. |
| Compliance | HIPAA, SOC2, GDPR data residency? This eliminates some platforms. |

**Decision heuristic:**
- Solo/small app, free tier matters → **Cloudflare Workers** or **Vercel Hobby**
- Next.js app → **Vercel** (native support) or **CF Pages** (cost)
- Heavy backend logic, Python/ML → **Cloud Run** or **Fly.io**
- Enterprise, existing AWS → **Lambda + API Gateway** or **ECS**
- Full-stack with auth/storage built in → **Supabase** or **Firebase**
- If unsure → **start with the smallest thing that works.** Migrate later when you hit a wall.

### Question 2: Backend Language & Framework

| Factor | TypeScript | Python | Go | Ruby | Rust |
|---|---|---|---|---|---|
| Best for | API-first, full-stack JS, edge | Data/ML, scripting, rapid proto | Performance, infra tools | Rapid web apps, convention | Systems, WASM, extreme perf |
| Frameworks | Hono, Express, Fastify, tRPC, Next.js API | FastAPI, Django, Flask | Chi, Fiber, Echo | Rails, Sinatra | Axum, Actix |
| Type safety | Native (TS) | Pydantic, mypy | Native | Sorbet (optional) | Native |
| ORM | Drizzle, Prisma | SQLAlchemy, Django ORM | GORM, sqlx | ActiveRecord | Diesel, SeaORM |
| Edge deploy | Workers, Vercel Edge | Workers (beta), Lambda | Lambda, Fly.io | Not typical | Workers (WASM), Lambda |

**Decision heuristic:**
- Full-stack JS/TS, API + frontend same language → **TypeScript**
- Data processing, ML features, scripting → **Python**
- Performance-critical microservice → **Go** or **Rust**
- Rapid prototype, "I need this by Friday" → **Rails** or **Next.js**
- Team's strongest language wins unless there's a compelling technical reason otherwise

### Question 3: Database

| Factor | SQLite/D1 | Postgres | MySQL | MongoDB | Redis |
|---|---|---|---|---|---|
| Scale | Small-medium | Any scale | Any scale | Document-heavy | Cache/queue |
| Hosted options | D1, Turso, Litestream | Supabase, Neon, RDS | PlanetScale, RDS | Atlas, self-hosted | Upstash, Elasticache |
| Cost (entry) | Free | Free (Supabase/Neon) | Free (PlanetScale) | Free (Atlas) | Free (Upstash) |
| Best for | Solo/small apps | Most production apps | Legacy, WordPress | Flexible schema | Caching, sessions, queues |
| ORM support | Drizzle, Prisma | All ORMs | All ORMs | Mongoose | ioredis |

**Decision heuristic:**
- < 100 users, simple schema → **SQLite/D1** (zero ops)
- Production app, complex queries, RLS → **Postgres** (Supabase or Neon for free tier)
- Need flexible schema, document storage → **Mongo** (but