Improve project detail page styling

[AJaccP]

🧠 Context

src/pages/projects/[slug].astro is the per-project page. Right now it's a neutral, token-based baseline — everything's there (back link, title, domains·year, description, "Built by" with optional author links, tech chips, GitHub/Live buttons, a plain <img> cover, and the contributor's markdown body via <Content />) but it's unstyled and flat. This ticket is the design pass: make this page look finished and intentional, and give the markdown body real prose styling.

This is a design-led ticket — you own the page's look. Two ways to work, your choice: sketch a quick wireframe and share it for feedback before building, or just mock it up directly in code and share that for feedback. Either way, implementation is in scope — the goal is the finished, styled page, landed. Expect a round of feedback before final.

Keep it consistent with the rest of the site — it should be a polished project overview page.

Files you'll touch:

• src/pages/projects/[slug].astro (you own this file fully)
• pnpm-workspace.yaml (only if you flip sharp: true for astro:assets — see below)

Don't touch:

• Card.astro / CardCover.astro — the gallery card and its cover are owned by separate card tickets; this is the detail page only.
• The content schema and other pages/components.

---

🛠️ Approach

1. Design the page. Lay out the hero/header (title, domains·year, description, built-by, tech, action buttons), the cover, and the markdown body into a clean reading layout. Think about hierarchy, spacing, max reading width for the prose, and how it reads on mobile vs desktop. Account for optional aspects like live site link, cover image. Wireframe-first or mockup-in-code — share for feedback before you finalize.
   Feel free to reference other sites out there for inspiration.

2. Style the markdown body (<Content />). There's no typography plugin, so hand-roll the prose styles in a scoped <style> — it doesn't need to be fancy, just readable and consistent: headings, paragraphs, lists, links (accent on hover), inline code and code blocks, blockquotes, and any images in the body. Wrap <Content /> in a container class and style its children with var(--color-*) tokens.
   You can reference the main CCSS website's typography for inspiration and some consistency.

3. Decide how images in the markdown body work. A contributor's index.md body may include images — settle and document the policy:

   • Whether to allow them, and how they're added. Allowing them is reasonable (screenshots/diagrams help a write-up). The clean path is a co-located relative image (![alt text](./screenshot1.png) next to index.md), which Astro's content pipeline optimizes at build via astro:assets — no manual byte-wrangling needed. Decide whether to also permit remote https://… images, which are not build-optimized; leaning local-only is simpler and keeps the repo self-contained.
   • Constrain their display size in the prose CSS so a large image can't blow out the layout — e.g. max-width: 100%, height: auto, and a sensible max-height. A huge source image should still render contained and readable, never overflowing the column.
   • Leave a one-line note on the agreed approach (a code comment, and/or for the future "Adding a project" docs) so contributors know how to embed an image and roughly what size to use.

4. Cover handling (this page owns its own image). You may switch the plain <img> to astro:assets <Image> for optimization; if you do and sharp isn't already enabled, set sharp: true under allowBuilds in pnpm-workspace.yaml (if that flag's already true, nothing to do). If a pnpm install/build install error shows up, flag it to Jacc rather than working around it.

5. No cover = no cover. Covers are optional (data.cover may be undefined). On the detail page we do not want a placeholder/fallback image — if there's no cover, simply don't render the cover element at all (the baseline's {data.cover && …} guard already does this). Instead, design the layout so it still looks intentional without a cover — don't leave reserved empty space or a broken gap where the image would be. So: a project with a cover shows it; one without just starts at the content, cleanly.

6. Preserve behavior + meta. Keep everything the page currently surfaces (title, description, domains, year, built-by with optional links opening in new tabs, tech, GitHub always / Live when deploy exists, the "← All projects" back link) and keep the props passed into the Base layout intact (page title/description, and any Open Graph image prop already wired) so sharing/meta don't regress. Domains are rendered through the shared DOMAIN_LABELS map (src/lib/domains.ts) so they read as "AI / ML", not the raw ai-ml value — the baseline already imports it; keep using it rather than printing the raw enum values. Make sure it reads well in both light and dark mode (if implemented).

7. Verify in pnpm dev: a project with a long markdown body reads cleanly; the header/cover/buttons look finished; a cover-less project simply omits the cover and still looks clean (no gap/placeholder); a body image renders at a contained size; links and buttons work; it holds up on mobile and (if implemented) in dark mode.

---

✅ Acceptance Criteria

• The detail page is visually finished (header, cover, built-by, tech, buttons) using the design tokens, in light and (if implemented) dark mode.
• The markdown body has hand-rolled prose styling (headings/paragraphs/lists/links/code/blockquotes) — readable and consistent, no typography plugin.
• Covers are optional: a project with a cover shows it (optionally via astro:assets <Image>), and one without simply omits the cover — no placeholder — with the layout still looking intentional (no gap/broken space).
• The markdown-body image policy is decided and documented: images render (if allowed) and are size-constrained in the prose CSS so a large one can't overflow the layout.
• All existing data and links are preserved, and the props passed to Base (title/description/OG image) are intact.
• A design (wireframe or code mockup) was shared for feedback before finalizing.
• Only [slug].astro (and possibly the sharp flag) changed; card components and the schema are untouched.
• pnpm format:check, pnpm check, and pnpm build all pass.