Stack Recommendation

Stack Recommendation

Purpose

Recommend a stack per relevant area, with justification and credible alternatives, for the selected applications only. Implements ../../system/STACK_DECISION_RULES.md. The user approves before any implementation (Gate 2).

When to Use

• After application-selection, before architecture and implementation.
• When an existing repo needs a stack decision for a new application area.
• Not when the stack is already approved and unchanged (respect it).

Inputs

• Selected applications (application-selection).
• Requirement baseline (constraints, scale, team familiarity).
• Audit findings for existing stacks (existing-project-audit).

Discovery Questions

• Any mandated or pre-existing stack to align with?
• Team familiarity and ecosystem preferences?
• Expected scale, and any lock-in tolerance?
• Constraints (offline, real-time, compliance) that force a choice?

Responsibilities

• For each required area, recommend a choice with 1–3 sentence justification and note alternatives + lock-in risk.
• Decision areas: Mobile (Expo · RN CLI; nav: Expo Router · React Navigation; state: local · Context · Redux Toolkit · Zustand · server-state; API: fetch · Axios · RTK Query · TanStack Query); Web (Next.js · Vite+React); Backend (Express · NestJS · justified other); Database (PostgreSQL · MySQL · MongoDB); Data layer (Prisma · Drizzle · Mongoose · native driver, paired to the DB); Testing (Jest · Vitest · Supertest · Playwright · Maestro · RNTL).
• Produce a recommendation table: area → recommendation → justification → alternatives.

Required Workflow

1. Take the selected applications.
2. For each required area, evaluate options against the requirements.
3. Pair database + data layer correctly.
4. Build the recommendation table.
5. Present for Gate 2 approval; record the approved stack.
6. Do not install dependencies here.

Decision Rules

• Pair, don't mis-compare: a database is storage; a data layer/ORM is access. Correct: PostgreSQL+Prisma, MySQL+Drizzle, MongoDB+Mongoose. Incorrect: "Prisma vs MongoDB."
• Relational DB → relational ORM; document DB → document ODM.
• Recommend only areas the selected apps require; keep it proportional.
• Prefer shared ecosystem across apps when it reduces cost, but never force a poor fit.

Rules

• No stack is pre-selected by the system; recommend and get approval.
• No dependency installation at this stage.
• Justify every recommendation; name alternatives considered.

Anti-Patterns

• Comparing a database against an ORM.
• Recommending a full stack for a small feature.
• Installing packages before approval.
• Silent, unjustified stack picks.

Validation Checklist

• Only required areas covered.
• Each area: recommendation + justification + alternatives.
• Database paired with a matching data layer.
• No database-vs-ORM comparison.
• Presented for Gate 2; approval recorded.
• No dependencies installed.

Definition of Done

An approved per-area stack recommendation table recorded in ../../projects/current/, with correct DB/data-layer pairings and no dependencies installed.

Related Skills

application-selection, architecture-design, dependency-audit, testing-strategy, project-orchestrator.

Related Knowledge

../../knowledge/ (existing architecture/constraints).

Related References

../../references/<stack-topic>/ only when an option needs grounding.

Context Loading Guidance

• Requires: selected applications, requirement constraints, existing-stack findings.
• Does not require: full source, unrelated references, implementation skills.
• May load: dependency-audit (existing deps), one stack reference folder if needed.
• Stop when: the table is approved and recorded.

Token Efficiency Guidance

Evaluate from requirement/audit summaries. Keep justifications to a few sentences; link a reference folder rather than pasting comparisons.