You're building a patient records portal for three community health clinics in the Dominican Republic — with authentication, role-based access control, and E2E testing across the full stack.
The discipline skills: session-based authentication (custom: bcrypt + httpOnly session cookie + server-side session store), RBAC middleware, server-side authorization enforcement, E2E testing with Playwright, integration testing for protected API routes, and the trade-off reasoning behind managed vs library-assisted vs custom auth.
The AI-direction lesson: AI's auth code is the most dangerous kind of "almost right." It looks complete. It passes every test you think to write. And it enforces access control on the wrong side — hiding buttons in the React component while leaving the API route wide open. The only way to catch this is adversarial testing: log in as the wrong role, make a direct API request, and check whether the server actually denies it. Specifying the trust boundary upfront — "all access control decisions are enforced on the API route, never on the client" — before any code is generated is the directing act that prevents it.
Your Role
You build a system where staff at any clinic can access patient records, with different access levels for different roles. Authentication, authorization, and role-based access control are the core of this project.
The planning pipeline continues from before. What changes: the work you direct AI to do now has direct security consequences. An API route without authorization middleware is not a missing feature — it is an exposed endpoint serving medical data to anyone who can construct an HTTP request.
What's New
Last time you containerized Pemba's booking system — wrapping an existing application in Docker so it runs the same everywhere. You wrote Dockerfiles, managed multi-container environments, and experienced how infrastructure decisions affect reliability.
Two things change.
You implement authentication and authorization. Every route, every component, every data query is affected by auth. It is not a feature you add — it is a structural decision that runs through the entire application. Sessions, password hashing, role-based middleware, protected API routes.
You write E2E tests. Playwright enters. Instead of testing components in isolation, you test complete user flows through the full stack — login, navigate, access data, verify permissions. The tests you write here catch failures that unit tests never will.
The hard part is AI's auth code. It looks complete. It passes the tests you think to write. And it enforces access on the wrong side — hiding buttons in the frontend while leaving API routes wide open. You catch this by testing adversarially: log in as the wrong role, make a direct API request, and check whether the server actually denies it.
Tools
- Claude Code — AI coding agent, VS Code extension. Primary tool.
- Git and GitHub — version control, remote repo, issues, project board.
- VS Code with Claude Code extension.
- Next.js with App Router — continuing.
- PostgreSQL — continuing.
- Playwright — E2E testing. New in this project.
- bcrypt for password hashing, httpOnly session cookies with a server-side session store — the custom auth stack this project builds by hand. Clerk (managed) and Auth.js/NextAuth.js (self-hosted library with database adapters) are compared in Unit 2 as the alternatives the student deliberately doesn't pick this time.
- Vitest and React Testing Library — continuing.
- Tailwind CSS — continuing.
- Chrome DevTools — continuing.
Materials
- Lucía's forwarded email chain — the board chair's budget approval and Lucía's original request. Enough to understand the problem, not enough to build the solution. You ask her the rest.
- Auth guide — authentication vs authorization, sessions vs JWTs, password hashing, trust boundaries, RBAC patterns, secure cookie configuration, common AI pitfalls. Reference, not a tutorial.
- Planning templates — PRD template with access control matrix, architecture decision template, test strategy template.
- CLAUDE.md — project governance file with the ticket list, tech stack, and verification targets.