docs(arch): pin the frontend UI kit and record what we deliberately excluded

Three stack questions kept resurfacing, so they are now answered in the one place someone would
look, with the reasoning rather than just the verdict.

Frontend is pinned to React 19 + Vite + TypeScript with Tailwind and shadcn/ui, explicitly NOT
MUI. shadcn is copy-in rather than import, so the components land in our own source tree where
they can be read and owned — which for a portfolio is the difference between showing you used a
component library and showing you can build one. Flavormancer also already has a visual identity
(the purple/teal gradient, the gilded scroll rods, the flask loader) that Material would flatten,
and the port would be spent overriding it. The trade is stated honestly: MUI wins when you need an
enterprise data-grid and date pickers tomorrow. This app is cards, chips, charts and a modal.

Node.js is scoped to build tooling and an optional TypeScript MCP server beside the Python one —
never a third backend. Two API stacks is breadth; three is sprawl, and it reads as indecision.

Laravel is deliberately absent and the reasoning is written down so nobody re-opens it: it is a
good fit for CRUD-and-content products and is used heavily elsewhere in this portfolio, but
Flavormancer is on-prem scientific computing. Adding a familiar framework that proves nothing new
would blur that. Choosing against your most comfortable stack when it does not fit is the point.

Signed-off-by: Austin L. <86896075+rvnminers-A-and-N@users.noreply.github.com>

Author: rvnminers-A-and-N

docs/ARCHITECTURE.md

@@ -30,12 +30,31 @@ costs nothing on Track A — the demo keeps working while the product is built.
 | App / API | **ASP.NET Core (C#)** | Enterprise default for a service like this: strong tooling, broad hiring pool, first-class ONNX Runtime support. |
 | ML serving | **ONNX Runtime in-process in .NET** | Taste models (sklearn → `skl2onnx`) run inside the .NET app, no Python at runtime. |
 | Aroma serving | **Python FastAPI sidecar** *(only if needed)* | The GNN may not export to ONNX cleanly; if not, a thin localhost sidecar does aroma inference only. Best case it exports and there's zero Python at runtime. |
-| Frontend | **React** | Deepest hiring pool and the lightest fit for a simple single-screen workbench. |
+| Frontend | **React 19 + Vite + TypeScript** | Deepest hiring pool and the lightest fit for a simple single-screen workbench. |
+| UI kit | **Tailwind + shadcn/ui** *(not MUI)* | shadcn is copy-in, not import: the components live in our source tree where they can be read and owned. MUI would flatten Flavormancer's existing visual identity into Material and we would spend the port fighting it. The trade is real — MUI wins if you need an enterprise data-grid and date pickers tomorrow; this app is cards, chips, charts and a modal, which is shadcn's sweet spot. |
 | Database | **PostgreSQL + pgvector** | Mature and battle-tested; pgvector backs the substitution-search index with first-class vector search. |
 | Deploy | **Linux + Docker Compose** on the client-owned box | Single-box, small user count → Compose, not Kubernetes. Containers make the OS matrix irrelevant. |
 
 ---
 
+## Deliberate exclusions
+
+What we chose **not** to use matters as much as the stack, and both of these come up often enough
+to be worth writing down.
+
+**Node.js — build tooling and MCP only, never a third backend.** Two API stacks (the shipping
+Python/FastAPI service and the planned .NET one) is breadth; a third is sprawl, and it reads as
+indecision rather than range. Node earns its place in exactly two spots: the React toolchain
+(Vite, TypeScript, the test runner), and — optionally — a **TypeScript MCP server** alongside the
+Python one, which is ~200 lines and demonstrates the official TS SDK against the same contract.
+
+**Laravel — deliberately absent.** It is a genuinely good fit for CRUD-and-content products and is
+used heavily elsewhere in this portfolio. It is the wrong tool here: Flavormancer is on-prem
+scientific computing, and adding a comfortable framework that proves nothing new would muddy that
+story. Choosing against your most familiar stack when it does not fit is the point.
+
+---
+
 ## The core principle: Python trains, .NET ships
 
 Training language is an *internal build detail*, not part of the product. Nobody