Worklist for report statuses

Objective

• Give teams a dedicated worklist (or equivalent filtering) so they can scan jobs where at least one report is still pending, without opening every work order—especially when some services have delayed report completion and "all clear" means every required report is done.
• Secondarily, surface which report(s) are still pending inside the expanded worklist row for a job, using the same mental model as the Reports area on the work order.

Background

• Today the default "Jobs Not Published" list (attik-frontend/src/components/task-check/IsPublished.tsx) keys off inspection-level published: false, not per-report readiness; that does not answer "which individual reports are still open" when publishing rules are finer-grained than the job flag.
• Customer feedback (Slack thread below) asks for worklist conditions tied to the published status of specific report templates—i.e. filter logic aligned with report template / report row state, not only the parent inspection aggregate.
• In the backend worklist pipeline, report-aware matching today is wired for event worklists that join a linked inspection: attribute event-inspection-report-status maps to inspection.reports.status and triggers an extra reports $lookup when building the lightweight inspection projection (attik-backend/src/routes/worklist.ts, with EVENT_INSPECTION_REPORT_ATTRIBUTES and related comments around the inspection join).
• The Conditions catalog in the frontend exposes "Linked Inspection Report Status" only under that same key event-inspection-report-status in attik-frontend/src/components/conditions/templatingData.ts—there is no parallel first-class condition key scoped to native inspection worklists in that file from the audit performed for this write-up.
• getInspectionPopulationPipeline in attik-backend/src/util/functions/aggregation/inspectionPopulation.ts supports includeReports (and populate including 'reports'), but the inspection worklist population branches in buildWorklistPopulationStages (attik-backend/src/routes/worklist.ts) call getInspectionPopulationPipeline with charges, payments, events, and people—without turning on includeReports in those branches—so list rows may not currently carry full report documents for UI breakdown unless something else populates them.
• Expanded row content for inspection worklists lives under attik-frontend/src/components/task-check/SingleJobsDropdown.tsx (payment notes, people, activity)—there is no report summary block there today, which is the natural place for the secondary "which reports are pending" detail if product wants it inline.

Example from the request:

• Related product thread (report-template / published conditions framing): Message from ryan

Scope

Backend

• attik-backend/src/routes/worklist.ts owns buildWorklistFilterStages, separateConditions, requiresPopulation, buildWorklistPopulationStages, and GET /worklist/:id/data. Any inspection-type worklist rule that references report status or per-template publish state will need to fit this pipeline (including when conditions must run pre- vs post- population, and whether a reports join similar to the event path is required for inspections).
• attik-backend/src/models/worklistSchema.ts continues to store type, conditions, limit, sort, etc.; new semantics likely extend conditions and/or aggregation behavior rather than the minimal schema fields alone (decision needed on whether template id is encoded in the condition attribute key vs. structured values).

Frontend

• Custom inspection worklists render through attik-frontend/src/components/task-check/WorklistResolver.tsx and SingleJobsBar / SingleJobsDropdown; authoring uses attik-frontend/src/app/tools/work/NewWorklistDrawer.tsx and attik-frontend/src/components/conditions/Conditions with options driven from templatingData.ts.
• The secondary experience implies extending SingleJobsDropdown.tsx (or a child component) to show pending report identifiers when the populated inspection payload includes enough report metadata—decision needed on whether that requires always loading reports for this list or only when the row is expanded.

Product / architecture decisions (for the implementer)

• Decision needed: Definition of "pending" (vs. in progress, failed, PDF-only, Spectora vs Attik-native reports) and whether the list is "any pending" vs. "specific template(s) pending" as in the Slack thread.
• Decision needed: Whether this ships as a preset/default worklist under attik-frontend/src/app/tools/work/[[...type]]/page.tsx, only as user-authored conditions, or both.
• Decision needed: Performance budget for joining/filtering reports at scale (limit up to 500 on the worklist model) vs. looser filters plus client-side refinement (not prescribing an approach—flag the tradeoff).

References

• Message from ryan (Slack)
• Worklist query and population: attik-backend/src/routes/worklist.ts
• Inspection aggregation options: attik-backend/src/util/functions/aggregation/inspectionPopulation.ts
• Condition option keys: attik-frontend/src/components/conditions/templatingData.ts
• Worklist row expand surface: attik-frontend/src/components/task-check/SingleJobsDropdown.tsx