# Choosing a stack from requirements

First distinguish product components: a native client, browser frontend and backend may require different stacks. Do not force one language across all components. Honor an existing stack unless the user asks to revisit it.

## Gather requirements

- **Existing project:** Repository, chosen stack and conventions; whether a new stack is actually requested.
- **Target surfaces:** Browser, API, command line, automation, iOS, Android; a product may combine several.
- **Native platform UI:** Native controls and platform integration versus browser UI.
- **Offline behavior:** Read-only cache, offline edits, synchronization and conflict policy.
- **Required integrations:** Vendor SDKs, data/AI libraries, payments and platform APIs.
- **Runtime constraints:** Latency, throughput, concurrency, memory, persistent connections and background work.
- **Deployment:** Allowed host/runtime, data residency, OS, native toolchains and operational constraints.
- **Data and access:** Tenancy, authorization, durability, retention, backups and recovery.
- **Maintenance:** Team experience, delivery constraints, licensing, support and budget.

## Compare feasible options

1. Separate hard constraints from preferences. Reject a candidate that cannot serve its proposed component; do not reject a backend merely because a separate client must work offline.
2. Use selection-index.json for candidate discovery, then read the full guide.md or record.json for each finalist. The `kind`, `ui` and `host` fields describe these recommended profiles, not every theoretical capability of a language.
3. For native iOS use the SwiftUI profile; native Android uses Compose. For both platforms, evaluate two clients with a shared API. A browser wrapper is not evidence of native UI equivalence.
4. Compare connected server-led web apps (Phoenix, Rails, Laravel, Django), full-stack React (Next.js), or an API-backed browser client (React/Vite) according to the product. Services and clients can be combined.
5. Confirm required SDKs, platform APIs, runtime/deployment support and version compatibility in primary documentation before choosing. Unknown is not supported. If coverage is absent (desktop, .NET, games, embedded, scientific computing), say so and research beyond this catalogue.
6. Explain two or three feasible alternatives, the requirement favoring your recommendation, a drawback and any unresolved question. There are no measured cross-stack productivity scores here.
7. Resolve a consequential uncertainty with a small representative prototype before treating the choice as settled.

## Chooser rules for these curated profiles

The compact index publishes the curated `selection_rules` used by the context router and the visiting agent. Filter `kind` by the requested component. For web profiles, an explicit UI preference matches `ui` exactly; static-only frontend hosting requires `host == static`; offline browser editing keeps `ui` in `client, full`. These are starting points needing storage and sync qualification, not a claim that offline editing works out of the box. Server profiles can still supply the backend for an offline client. For native iOS + Android, make a separate context request for each client and evaluate the backend separately. If filters leave no profiles, explain the conflict instead of silently relaxing a hard constraint. Unknown categories are coverage gaps.

## Return a usable handoff

State the recommended component/stack composition, requirements satisfied, rejected alternatives and reasons, selected tools and why each is needed, version/documentation sources, verification plan, and unresolved questions. After selection, follow the chosen stack's setup and best-practice guidance. Separate documented capability from checks actually executed.