The Public Site

Step 1: Scaffold the Next.js project

Direct Claude to create the Next.js project with App Router and TypeScript. The directory structure should reflect your rendering strategy decisions -- static pages in their own route groups, the collection in its own section, the members area separate.

Set up Tailwind CSS for styling. Install Prisma and configure the PostgreSQL connection for the collection data. Seed the database with the 150 artifacts from materials/collection-data.json.

After Claude finishes, verify the project structure matches what you planned. The rendering strategy from Unit 2 should be visible in how the routes are organized.

Step 2: Build the static pages

Direct Claude to build the About, Visit, and History pages as SSG. These pages use generateStaticParams in Next.js App Router -- they're pre-built at deploy time and served directly from the CDN.

The content should use semantic HTML throughout. That means:

• <main> wrapping the primary content
• <nav> for navigation
• <header> and <footer> for page structure
• Heading hierarchy that makes sense (h1 for the page title, h2 for sections, h3 for subsections -- never skip levels)
• ARIA landmarks where the HTML5 elements aren't sufficient

Add skip links at the top of every page. A skip link is a visually hidden link that becomes visible on focus -- it lets keyboard users jump past the navigation directly to the main content. Without it, a keyboard user tabs through every navigation link on every page before reaching the content.

Step 3: Build the collection browsing page

The collection page is SSR -- it builds fresh on each request because the results depend on the search query and filters.

Direct Claude to build:

• A search bar at the top
• Category filters (Nautical Instruments, Ship Models, Maritime Maps, Navigation Equipment, Oral History, Photographs)
• Era filters (15th through 20th century)
• An artifact grid showing thumbnail images from materials/photos/, artifact names, eras, and brief descriptions
• Artifact detail pages at /collection/[id] showing the full description, larger image, and related artifacts

Add Suspense boundaries: the page shell (navigation, search bar, filters) loads instantly. The artifact grid streams in once the database query completes. This is the streaming architecture from Unit 2 in practice.

AI commonly generates server/client component boundaries based on the immediate task rather than the application's data flow pattern. Review what Claude produces -- make sure the collection page stays as a server component (data fetching on the server) and only the interactive search input is a client component.

Step 4: Implement keyboard navigation

Tab through the entire site. Every interactive element -- navigation links, search input, filter buttons, artifact cards, skip links -- should be reachable via keyboard. Focus indicators should be visible on every focused element.

Check:

• Does pressing Tab move focus in a logical order through the page?
• Can you use the search bar, apply filters, and open an artifact detail page without touching a mouse?
• Are focus indicators visible? (Some CSS resets remove them with outline: none -- that's an accessibility failure, not a design choice.)

Fix every gap Claude left. Focus management is where AI's mouse-only patterns show up most clearly.

Step 5: Add Suspense boundaries

Verify the streaming behavior. Open the collection page in Chrome DevTools with network throttling set to Slow 3G. You should see:

1. The page shell appears first (navigation, search bar, filters)
2. The artifact grid streams in after a brief loading state
3. No blank page. No jarring content shifts.

If the entire page waits for the artifact data before rendering anything, the Suspense boundaries aren't placed correctly. The shell should be outside the boundary, the data-dependent content inside.

Step 6: Run Lighthouse

Run a Lighthouse accessibility audit in Chrome DevTools.

Direct Claude to fix every accessibility failure Lighthouse reports. Then run it again. The target is 95 or higher.

Remember what this number means and what it doesn't. Lighthouse checks structural accessibility -- alt text, heading hierarchy, color contrast ratios, ARIA roles. It does not check whether a keyboard user can actually complete a task. It does not check whether a screen reader announces search results when they update. That deeper work comes in Unit 5.