Action items are a shared checklist between me and the client

Every project in the portal has an action item checklist. The ActionItemChecklist component splits items into two groups — the client's action items and my action items. The client can tick off their own items. They cannot tick off mine. That single boolean — canToggle — controls the entire permission model for the checklist. Each item is a form with a hidden input carrying the action item ID and a submit button styled as a checkbox. The button uses useActionState with a server action so toggling an item posts directly to the server without a fetch call or JSON serialisation. The aria-label on each checkbox adapts to state — it says Mark followed by the item title as done when unchecked, and Unmark followed by the title when checked. A screen reader user knows exactly what each toggle will do before they activate it. Completed items get a strikethrough and reduced opacity so the visual hierarchy shifts toward what still needs doing. The emerald fill on a checked box matches the same emerald used for completed milestones and approved deliverables — the portal's universal colour for done. My items render with muted heading text so the client's eye goes to their own responsibilities first. The whole component is one array, one filter, one server action. No WebSocket, no optimistic update, no local state management. The form posts, the server toggles, the page reflects the change. One checklist for every project type — audio, software, accessibility, production, musician.