Build a real app with Claude.
Three prompts, start to finish.

You are going to build a web app with me. This first message is setup
only — do not write any feature code yet.

Do all of this yourself, including anything that needs a terminal. Do not ask
me to choose a folder, a name or a path: pick sensible ones and tell me what
you picked.

1. Create a new project folder called "halal-desk" somewhere sensible. Tell me
   the full path when it exists.
2. Scaffold a Next.js app in it — App Router, TypeScript, Tailwind CSS — and
   install the dependencies.
3. Run the dev server on port 3100, in case I already have something on 3000.
4. Give it a dark "trading terminal" look: near-black background, purple
   accent #533E98, no light mode. For now just a layout with a header and an
   empty home page.
5. Open the page yourself and confirm it actually loads. If it errors, fix it
   and try again before telling me it is ready.
6. Create PROJECT.md in the folder containing the brief below, the stack, and
   a "decisions" list you will append to as we go. Read this file at the start
   of every future message — when the conversation gets long, this is what
   stops you rebuilding things from memory.

The brief, for PROJECT.md:

  "Halal Desk" — a research workspace for Muslim investors, with Shariah
  screening running through all of it. Paper trading only: fake money, no
  real broker. Six screens — dashboard, screener, company detail, portfolio,
  purification calculator, and a connect-your-API-key screen.

  The rule that matters most: buying a stock screened NOT HALAL is blocked
  outright, DOUBTFUL requires an explicit confirmation, and selling is NEVER
  blocked — trapping someone in a position that has just turned
  non-compliant is the opposite of helping.

When it is running, tell me the folder path, the URL, and what you would build
first.

Read PROJECT.md, then build the whole app.

Work through these in order and run `npm run build` after each one. If it
fails, fix it before moving on. Run the commands yourself and show me what
happened — do not hand me a list of commands to run.

1. TYPES AND SAMPLE DATA. Define the shapes before any UI exists: a Company
   (ticker, name, sector, price, the three AAOIFI ratios, a verdict of
   HALAL / DOUBTFUL / NOT_HALAL, and an optional ranking score), a Position,
   and a Dividend with a payment date. Then write about 25 realistic sample
   companies across several sectors — include an obvious fail (a bank), a
   borderline case, and one with a missing ranking score.

2. A DATA LAYER in a single file that every screen calls. It reads the sample
   data today, but is written so a real API can be dropped in behind it
   without any screen changing. No screen ever knows where the data came from.

3. THE COMPLIANCE RULE, in ONE function on its own, with the AAOIFI limits as
   named constants. Three things it must get right, none of which are the
   obvious default:
   - Missing or unknown data is NOT a fail. Return DOUBTFUL and say the data
     is missing. Treating absence as forbidden is a claim we cannot make.
   - A company with no ranking score sorts BELOW ranked ones, never above.
   - The buy gate lives here too: NOT_HALAL blocks buying entirely, DOUBTFUL
     requires explicit confirmation, and selling is never gated, for any
     verdict, ever.

4. THE SCREENER. The universe in a filterable table — by verdict, sector and
   ranking — with all three ratios in every row. Show the reasoning, not just
   a coloured badge: each ratio against its limit, so someone can see why.

5. THE COMPANY PAGE, tabbed: Compliance, Fundamental, Technical, Sentiment,
   Purification. Build Compliance and Purification properly; the other three
   follow the same layout with their own numbers.

6. THE ORDER TICKET. When a buy is blocked the buy controls must NOT RENDER
   AT ALL. Do not render a disabled button — a greyed-out button is still in
   the DOM, and anyone can turn it back on. The sell control is always there.

7. THE PORTFOLIO. Positions, profit and loss, and a re-screen that separates
   "would be blocked if you bought it today" from "worth a second look".

8. THE PURIFICATION CALCULATOR. This is a DATE problem, not a multiplication.
   Count only the dividends whose payment dates fall inside the period the
   shares were actually held, then apply the impure share to those. Do not
   multiply an annual total by a percentage.

9. THE CONNECT SCREEN. How to get an Akinda API key and what each plan
   includes. It must NOT have an input box for the key — a key typed into a
   web page ends up in the browser. It belongs in .env on the server. Say so
   on the screen.

Keep each screen a server component unless it needs state or an event handler;
when it does, push just that part into its own small client component rather
than making the whole page interactive.

When all nine are done and the build passes, show me the route list from the
build output and tell me anything you had to compromise on.

Finish it off. Do each of these yourself rather than telling me how.

1. Run the production build and fix whatever it complains about. `npm run dev`
   is forgiving in ways `npm run build` is not — unused imports, type errors
   and bad Suspense boundaries all surface here.

2. Add a .env.example explaining AKINDA_API_KEY, including why it is NOT
   prefixed with NEXT_PUBLIC_ — anything with that prefix is compiled into the
   browser bundle, so the key would be readable by anyone using the app.

3. Add a banner in the layout showing whether we are on live or sample data,
   so nobody mistakes fixtures for real figures. Before you do: check whether
   the pages are statically prerendered. If they are, the environment variable
   is read at BUILD time and baked into the HTML, so the banner would say
   "sample" forever even with a real key set in production — and nothing would
   error. Fix that if it applies here.

4. Write a README: how to run it, what each file does, the compliance rule as
   a table, and an honest "deliberately left undone" section. Do not oversell
   it — list what it does not do (no accounts, no order history, prices are
   fixtures, no tests). Being straight about the gaps is more useful to a
   reader than a longer feature list.

Then tell me in one paragraph what you would fix first if this had real users.