Reading an SOP and Running a Checklist

Clicking any resource card on the web portal navigates to its detail page at /portal/resources/[id]. The page header shows the resource type badge, the full title, the description, and all topic pills in their color-coded style — Pre-shoot in amber, On site in sky-blue, Gear in slate, Safety in rose, Post-shoot in violet, Handoff in emerald. A back link labeled 'Resources' at the top left returns you to the browse page without losing your filter state.

For SOPs, the body is rendered as full HTML using markdown-it, which means headings, numbered lists, bullet points, bold text, and links all render correctly inside a card with `prose` typography styling. You can select and copy text from the body. If the SOP admin left the body empty, the page shows 'This SOP has no content yet.' On iOS, the SOP body is rendered as formatted AttributedString using Swift's built-in Markdown parser with inline-only syntax, and text selection is enabled — technicians can long-press to copy any part of the procedure.

For checklists opened without a job context (i.e., directly from the browse page without a ?projectId= query parameter), the detail page shows an amber warning card: 'Open this checklist from a job page to tick items — your ticks are saved per-shoot so you can pick up where you left off.' This is by design: the system requires a specific project to scope a checklist run, because the same checklist template can be run multiple times across different jobs with independent progress.

When a checklist is opened with a project context — for example by navigating from a job detail page — the page automatically starts or resumes a run for that (checklist, project, user) combination. This start/resume is idempotent on the backend: opening the same checklist on the same job twice picks up exactly where you left off. A small progress bar card at the top shows 'X/Y required items complete'. Each item row shows a filled checkbox when ticked and a hollow checkbox when unticked. Tapping an item toggles it optimistically (the UI updates instantly) and fires a POST to /portal-resources/runs/:runId/items/:itemId to persist the state. If the network call fails, the tick rolls back and a toast appears.

Items marked 'Required' by the admin show no label suffix; optional items are labeled with a small 'Optional' badge in muted text. The required item count drives the progress fraction shown on both the card grid and the detail progress bar. A 'Mark all complete' button appears at the bottom of the checklist when at least one required item remains unticked and a run is active — tapping it calls /portal-resources/runs/:runId/complete on the server, ticks every item in the template, and shows a 'Checklist marked complete' toast. When all required items are ticked, a green 'Done' badge with a check-circle icon replaces the progress count. On iOS, the checklist detail in the standalone ResourceDetailView shows the same item list with filled/hollow circle icons, but interactive ticking only happens when the view is opened from a job context where a run has been started.