Implement the following plan:

Unified Role-Aware Content Components

Overview

Create a flexible role-based content visibility system with a unified base component, convenient helper components, and instructor-facing visibility indicators.

Design

Role Types

type UserRole = "instructor" | "staff" | "student" | "guest";

Base Component: <RoleContent>

Accepts a comma-separated list of roles that can see the content:

<RoleContent visible="instructor,staff">
  Only instructors and staff see this
</RoleContent>

<RoleContent visible="student,guest">
  Students and guests see this (not instructors)
</RoleContent>

Helper Components

Readable wrappers around RoleContent:

Instructor Visibility Indicators

When instructors view the page, show a small inline tag indicating who can see each section:

[Anyone] This content is visible to everyone...

[Logged In] This content requires authentication...

[Students] This is the student-facing version...

[Instructors] These are instructor notes...

Tags are small, unobtrusive text labels. Guests and students see no tags—just the content. The existing amber border styling for InstructorOnly is kept for visual distinction.

View As Student Toggle

Existing toggle continues to work—instructors can preview how students/guests see the page (all visibility indicators hidden).

Files to Modify/Create

Modify

• apps/web/lib/roles.ts - Add role checking utilities
• apps/web/components/mdx/student-only.tsx - Refactor to use RoleContent
• apps/web/components/mdx/instructor-only.tsx - Refactor to use RoleContent
• apps/web/mdx-components.tsx - Register new components

Create

• apps/web/components/mdx/role-content.tsx - Base unified component
• apps/web/components/mdx/logged-in-only.tsx - Helper component
• apps/web/components/mdx/enrolled-only.tsx - Helper component

Implementation

1. Update roles.ts

Add a function to check if current user matches any of the specified roles:

export async function userHasRole(allowedRoles: UserRole[]): Promise<boolean> {
  const userRole = await getUserRole();
  return allowedRoles.includes(userRole);
}

2. Create role-content.tsx

interface RoleContentProps {
  children: React.ReactNode;
  visible: string; // comma-separated roles
  viewAsStudent?: boolean;
  label?: string; // optional custom label override
  className?: string; // optional styling (e.g., amber border for InstructorOnly)
}

export async function RoleContent({ children, visible, viewAsStudent, label, className }: RoleContentProps) {
  const allowedRoles = visible.split(",").map(r => r.trim()) as UserRole[];
  const userRole = await getUserRole();
  const instructor = await isInstructor();

  // Handle viewAsStudent toggle
  const viewing = viewAsStudent ?? await isViewingAsStudent();

  // Viewing as student: show only if student/guest would see it
  if (instructor && viewing) {
    const studentCanView = allowedRoles.includes("student") || allowedRoles.includes("guest");
    return studentCanView ? <>{children}</> : null;
  }

  // Non-instructors: show only if their role matches
  if (!instructor) {
    return allowedRoles.includes(userRole) ? <>{children}</> : null;
  }

  // Instructors (not viewing as student): show ALL content with visibility tags
  const tagLabel = label ?? getDefaultLabel(allowedRoles);
  return (
    <div className={className}>
      <span className="text-xs text-muted-foreground font-medium">
        [{tagLabel}]
      </span>
      {children}
    </div>
  );
}

function getDefaultLabel(roles: UserRole[]): string {
  const sorted = [...roles].sort();
  const key = sorted.join(",");

  // Common combinations get friendly names
  const labels: Record<string, string> = {
    "guest,instructor,staff,student": "Anyone",
    "instructor,staff,student": "Logged In",
    "guest,student": "Students",
    "student": "Enrolled",
    "instructor,staff": "Instructors",
  };

  return labels[key] ?? roles.map(r => r.charAt(0).toUpperCase() + r.slice(1)).join(", ");
}

3. Refactor helper components

instructor-only.tsx - keeps amber border styling for visual distinction:

import { RoleContent } from "./role-content";

export async function InstructorOnly({ children, viewAsStudent }: Props) {
  return (
    <RoleContent
      visible="instructor,staff"
      viewAsStudent={viewAsStudent}
      className="my-4 border-l-4 border-amber-500 bg-amber-500/10 pl-4"
    >
      {children}
    </RoleContent>
  );
}

student-only.tsx - renders plain (no special styling):

import { RoleContent } from "./role-content";

export async function StudentOnly({ children, viewAsStudent }: Props) {
  return (
    <RoleContent visible="student,guest" viewAsStudent={viewAsStudent}>
      {children}
    </RoleContent>
  );
}

4. Add new helpers

logged-in-only.tsx - visible to any authenticated user enrolled-only.tsx - visible only to enrolled students (not guests)

5. Register in mdx-components.tsx

Add RoleContent, LoggedInOnly, EnrolledOnly to the MDX component map.

Verification

1. View meeting page as guest → see StudentOnly content, no badges
2. View meeting page as instructor → see all content with visibility badges
3. Toggle "View as Student" → see student view, no badges
4. Test new components: <LoggedInOnly>, <EnrolledOnly>, <RoleContent visible="...">

If you need specific details from before exiting plan mode (like exact code snippets, error messages, or content you generated), read the full transcript at: ~/.claude/projects/-Users-challen-www-usingandunderstanding-ai/87c8ab13-0814-4cb5-851a-706bb2d0057e.jsonl

I started the dev server so you can run tests.

Great! Let's use these on today's meeting. Most content should be publicly available.

Sorry, the student only content should just be unprotected.

Also, I think as part of next Tuesday's AI scavenger hunt we'll have students ask the AI whether it passes the Turing test. So just have them do the research for now.

Say we'll discuss what you learned next week. Mention that next Tuesday we'll be doing an AI scavenger hunt as our first activity. Also please put in a note for me to discuss the CBTF assessments and the conversational assessment approach we'll be using, since that's something I think students will want to know.

OK. Please move the As Student toggle to the right sidebar and have it be a checkbox. Save it in localStorage so it persists.

Can we make the [Instructors] label for protected content (1) a nice badge using a similar color and (2) right aligned? And take it out of the flow of the content so it doesn't consume vertical space.

It looks like an error about the client count: query: 'select "id", "user_id", "token", "expires_at", "ip_address", "user_agent", "created_at", "updated_at" from "sessions" where "sessions"."token" = $1', @repo/web:dev: params: [Array], @repo/web:dev: [cause]: Error [PostgresError]: sorry, too many clients already @repo/web:dev: at ignore-listed frames { @repo/web:dev: severity_local: 'FATAL', @repo/web:dev: severity: 'FATAL', @repo/web:dev: code: '53300', @repo/web:dev: file: 'proc.c', @repo/web:dev: line: '355', @repo/web:dev: routine: 'InitProcess' @repo/web:dev: } @repo/web:dev: } @repo/web:dev: ⨯ [Error [APIError]: Failed to get session] { @repo/web:dev: status: 'INTERNAL_SERVER_ERROR', @repo/web:dev: body: [Object], @repo/web:dev: headers: {}, @repo/web:dev: statusCode: 500, @repo/web:dev: digest: '3914836991' @repo/web:dev: } @repo/web:dev: ⨯ [Error [APIError]: Failed to get session] { @repo/web:dev: status: 'INTERNAL_SERVER_ERROR', @repo/web:dev: body: [Object], @repo/web:dev: headers: {}, @repo/web:dev: statusCode: 500, @repo/web:dev: digest: '3914836991' @repo/web:dev: } @repo/web:dev: ⨯ [Error [APIError]: Failed to get session] { @repo/web:dev: status: 'INTERNAL_SERVER_ERROR', @repo/web:dev: body: [Object], @repo/web:dev: headers: {}, @repo/web:dev: statusCode: 500, @repo/web:dev: digest: '3914836991' @repo/web:dev: }

NO!

This should not happen!

Why is it happening? You told me to use SQL. I've never had this problem with MongoDB. WTF? Please fix it. Can postgres not handle that many connections? Please.

Is this the correct way to do it? You're saying it's not already cached? Please check the docs.

And shouldn't the role be passed down as a prop and not requeried over and over again?

Continue.

The URL is https://[local-hostname]/spring2026/meetings/2026-01-22-welcome.

Also can we clear the hash from the URL after hash navigation completes? Otherwise it's stuck there. Or at least clear it once the user scrolls away? I see the badge now. It looks OK. It needs a bit of top and right margin.

Ah, OK. Let's add a bit of padding to protected containers in instructor mode just so the badge doesn't overlap content.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

A

Please update CLAUDE.md. You've been trying to run bun typecheck but it's bun tsc.

There's a failing test. Please examine and debug.

Like I suggested before, don't use getByText. That's a smell. Use data testID.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

A

Error Type

Console Error

Error Message

A component is changing an uncontrolled input to be controlled. This is likely caused by the value changing from undefined to a defined value, which should not happen. Decide between using a controlled or uncontrolled input element for the lifetime of the component. More info: https://react.dev/link/controlled-components

at input (<anonymous>:null:null)
at ViewAsStudentToggle (components/view-as-student-toggle.tsx:38:9)
at ViewAsStudentWrapper (components/view-as-student-wrapper.tsx:6:10)
at ProseWithToc (components/prose-with-toc.tsx:30:13)
at MeetingPage (app/[semester]/meetings/[slug]/page.tsx:61:9)

Code Frame

36 | return ( 37 | <label className="flex cursor-pointer items-center gap-2 font-mono text-xs">

38 | <input type="checkbox" disabled className="h-3 w-3 accent-amber-500" /> | ^ 39 | <span className="text-foreground-muted">View as student</span> 40 | </label> 41 | );

Next.js version: 16.1.1 (Turbopack)

OK! We have one more form signup to process. Find the data in FORM.pdf. Check my email for similar welcome messages sent to previous students, but we'll make this one a bit different since we're meeting today. We also need to (1) add this student to the CSV marked as not complete with override and (2) add them to the local, dev, and production databases. Let's work step-by-step. First, identify the new student and draft a welcome email.

No. Read my mail to find previous emails.

No. There's a script to do this. Please find it and update CLAUDE.md.

Sure.

Why are you writing a script again?

No. Search should give you IDs that you can then use to retrieve the message.

Note that there are other students in the database, so you should just add new records. Let's do this on the local database first to test it.

Wait, this student should not have a canvas ID.

Is this documented in CLAUDE.md?

Please analyze this codebase and create a CLAUDE.md file, which will be given to future instances of Claude Code to operate in this repository.

What to add:

1. Commands that will be commonly used, such as how to build, lint, and run tests. Include the necessary commands to develop in this codebase, such as how to run a single test.
2. High-level code architecture and structure so that future instances can be productive more quickly. Focus on the "big picture" architecture that requires reading multiple files to understand.

Usage notes:

• If there's already a CLAUDE.md, suggest improvements to it.
• When you make the initial CLAUDE.md, do not repeat yourself and do not include obvious instructions like "Provide helpful error messages to users", "Write unit tests for all new utilities", "Never include sensitive information (API keys, tokens) in code or commits".
• Avoid listing every component or file structure that can be easily discovered.
• Don't include generic development practices.
• If there are Cursor rules (in .cursor/rules/ or .cursorrules) or Copilot rules (in .github/copilot-instructions.md), make sure to include the important parts.
• If there is a README.md, make sure to include the important parts.
• Do not make up information such as "Common Development Tasks", "Tips for Development", "Support and Documentation" unless this is expressly included in other files that you read.
• Be sure to prefix the file with the following text:

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Please analyze this codebase and create a CLAUDE.md file, which will be given to future instances of Claude Code to operate in this repository.

What to add:

1. Commands that will be commonly used, such as how to build, lint, and run tests. Include the necessary commands to develop in this codebase, such as how to run a single test.
2. High-level code architecture and structure so that future instances can be productive more quickly. Focus on the "big picture" architecture that requires reading multiple files to understand.

Usage notes:

• If there's already a CLAUDE.md, suggest improvements to it.
• When you make the initial CLAUDE.md, do not repeat yourself and do not include obvious instructions like "Provide helpful error messages to users", "Write unit tests for all new utilities", "Never include sensitive information (API keys, tokens) in code or commits".
• Avoid listing every component or file structure that can be easily discovered.
• Don't include generic development practices.
• If there are Cursor rules (in .cursor/rules/ or .cursorrules) or Copilot rules (in .github/copilot-instructions.md), make sure to include the important parts.
• If there is a README.md, make sure to include the important parts.
• Do not make up information such as "Common Development Tasks", "Tips for Development", "Support and Documentation" unless this is expressly included in other files that you read.
• Be sure to prefix the file with the following text:

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Please do a full pass on CLAUDE.md, bringing it up to date with the current codebase.

OK. We need to add the student to the applications table for the development site.

No. There's a script in bin for this.

You can examine that, but it's old and I'm worried it may overwrite datae.

My god. Please examine the db query scripts. YOU WROTE THEM! psql is not installed.

NO NO NO NO!

OK fine. Man, this is terrible though. You're starting Docker to run a command! I installed a DB query tool for you already.

Man, you just can't use this tool can you?

WHY DID YOU ASK ME TO INSTALL pgcli? DOES IT NOT HAVE A NON-INTERACTIVE OPTION?

Um, did you destroy the enrollment tables? They are blank on both dev and production.

No, something is broken, that sync should be happening regularly. Check the logs to see what's going on. Maybe we didn't define the secret that they need?

Is the CANVAS_API_TOKEN available in the dev and prod environments? Check the secrets and dev first.

Please add CANVAS_BASE_URL to .env.production and have it used at container build time. CANVAS_API_TOKEN is in [local-hostname] and should be added as a runtime secret. CANVAS_BASE_URL should also be in .env.development.

Sorry, you can find the value three.

I just restarted the dev site. Please watch the logs and make sure that Canvas sync is enabled and running.

Read the output file to retrieve the result: [tmp-path]

Read the output file to retrieve the result: [tmp-path]

Yup, I can see it working!

That's done.

Can we create package.json commands allowing me to view pino-prettified log output from the dev and production deployments? It would be nice to be able to see all containers (web,api,mail) by default or a subset from command line arguments (e.g., web,api, or just api).

Wait, sorry. Does [email] go to all applied and enrolled students?

No, the list configurations are in this repository, as is the mail container that distributes the messages.

Nice! Can we add a way to add additional testing users to lists that should get copies of messages? I'd just like to see what they look like. Add [email] to the students list.