# Stream S: site structure proposal
> **Superseded 9 Sep:** the review that this proposal asked for happened on `/structure` (comments 154 to 208) and its outcome was landed by `/stream-s`, whose command file is its own brief (handoff 2026-09-10). This file is the 3 Sep ask, kept as the record.
> **DONE 3 Sep**: delivered as a document and the hidden `/structure` page; awaiting Mark. Owner action: send.
**Runs:** now. Must reach Mark on Monday 7 September.

## Goal
A written proposal for how brands, product types, sizes and airports become
pages and web addresses. This is the decision that determines whether the site
grows into thousands of useful pages or thousands of thin ones. It is a
document, not code.

## Deliverables
One document, written for Mark (an SEO specialist) and readable by Adam:
1. The URL shape for every page type: product, brand, airport, category, and
   any brand-within-airport or category-within-airport crossings.
2. How a brand's products are grouped: one page per brand, or split by
   category or size, and where the line is drawn so pages stay substantial.
3. How new product types fit the same shape (cosmetics and fragrance are
   coming, and they are shaped differently from spirits).
4. Internal linking: how the mega menu, breadcrumbs and cross-links tie the
   types together.
5. Canonical rules, pagination, and what is deliberately left unindexed.
6. Answers Adam's open question: does a brand page reuse the product-page
   information plus extras, or get its own richer specification? He wants no
   empty fields, and room to add things like tasting notes later.

## Owns
The document only. Write it to `.logs/planning/site-structure-proposal.md` and
give rian a client-ready version to send.

## Must not touch
Any code.

## Notes
- Read the existing SEO layer first: `main/app/services/seo.py` shows what is
  already emitted (Product schema, breadcrumbs, canonicals, sitemap).
- Mark's position, in his words: pages need real HTML content, airport pages
  with a lot of information, brand pages such as "a page for the Macallan with
  all whiskies available in all airports we crawl from", and he wants the
  comparison tool embedded per airport page.
- Sixteen airports are live, and the data holds around 3,771 products with 702
  comparable across two or more airports. Design for that scale, not for a
  hypothetical million.

## Ground rules for this session
- Read first: `/srv/apps/dutyfreeprofessor/agents.md` and `brief.md`. Do NOT
  read all of `.logs/handoff.md`; this brief is your context.
- Stay inside your owned files (listed above). If you need a file another
  stream owns, stop and ask rian.
- Do NOT deploy. Build and test locally, then tell rian you are green and
  ready. He holds the deploy token.
- Do NOT create an Alembic migration unless this brief says you own one, and
  then only after `alembic heads` shows a single head.
- Before handing back: `../.venv-dev/bin/pytest tests -q` passes, `npm run
  build` passes if you touched `web/`, commit your work prefixed with your
  stream letter, and add one line to `.logs/handoff.md`.
- House style for anything the client reads: no em dashes.