Spectora home inspection report: repeated create/archive cycles confuse staff

Objective

• Remove uncertainty for inspectors and office staff when a work order accumulates multiple generations of the same Spectora Home Inspection Report template (pattern seen: initial report → second created and archived → third remains active).
• Determine whether behavior is expected lifecycle (new Spectora report ids over time; Attik archives ids no longer in the API payload) that should be explained or surfaced differently, or a defect (duplicate active rows, bad matching, double sync).

Background

• Coordinators report that the activity feed and reports area feel like duplicate versions of the same template, not a single clear line of history.
• Example pattern from activity logs (full excerpts in the doc below): a System line often adds “Home Inspection Report (spectora)” and in the same burst moves a prior row to archived; later another add appears, leaving staff unsure which row is authoritative.
• Repeated field pattern (7+ jobs): Home Inspection Report template created on the work order initially; days to weeks later a second copy of the same template is added and archived; hours to days later a third copy is added and not archived—leaving two copies of the same template visible on the work order (one active generation plus prior archived row(s) and/or two non-archived rows depending on sync timing).
• Programmed behavior (Attik): Spectora sync is centralized in getInspectionReportsAndRequired, which updates a report when a row already matches the Spectora report id, creates when no match exists, and archives existing rows whose _spectoraReportId is absent from the current Spectora report/attachment id set returned for that inspection—so multiple waves are plausible when Spectora’s payload exposes new report ids over the job life (schedule changes, inspector changes, republish, etc.).
• Decision needed after spike: treat as product/UX (consolidate messaging, activity copy, or “one slot per template”) vs data bug (two active same-slot rows, same id twice, or archive while Spectora still returns the old id).

Repro materials and example jobs

• Activity logs (Google Doc) — original three jobs
• Job 1 — Attik activity feed (inspection 1008590172)
• Job 2 — Attik activity feed (inspection 1008589968)
• Job 3 — Attik activity feed (inspection 1008590109)
• Job 4 — Attik activity feed (inspection 1008581481)
• Job 5 — Attik activity feed (inspection 1008589712)
• Job 6 — Attik activity feed (inspection 1008576981)
• Job 7 — Attik activity feed (inspection 1008589393)

Scope

Backend

• Report sync and lifecycle live in attik-backend/src/util/functions/spectora/getInspectionReportsAndRequired.ts: matching Spectora reports to existing Report documents, create vs update, and the archive stale ids pass that sets status: 'archived' when an id disappears from the current Spectora set.
• Webhook-driven inspection sync calls into that helper from attik-backend/src/routes/webhooks/spectora/syncInspection.ts (report sync block).
• Manual / throttled path: POST /:id/sync-spectora-reports on the inspection router in attik-backend/src/routes/inspection.ts, which also invokes getInspectionReportsAndRequired (see integration tests under attik-backend/tests/integration/inspection.syncSpectoraReports.test.ts for behavior expectations).
• attik-backend/src/models/reportSchema.ts defines fields such as _spectoraReportId, spectora_slug, reportType, status, and links used when reconciling with Spectora.

Frontend

• If the spike concludes behavior is correct but confusing, scope may include how reports and activity present multiple rows (exact components depend on where staff look today; trace from the inspection activity tab and reports panel for the linked inspection ids).

Partner / process

• If Spectora consistently issues new report objects for one logical home report, resolution may involve Spectora-side workflow or documentation in addition to any Attik change.

Investigation outcomes (draft acceptance)

• [ ] For at least one linked inspection: Mongo report rows listed with _spectoraReportId, status, _requiredReportTypeId / template, timestamps—confirm whether two non-archived Spectora rows ever occupy the same “slot.”
• [ ] Spectora inspection payload (report ids) compared across two time windows around a wave—id churn vs stable id.
• [ ] Sync triggers (webhook vs sync-spectora-reports) correlated with activity timestamps.
• [ ] Written conclusion: UX-only, Attik defect, Spectora data/process, or combination; follow-up work ticketed accordingly.

References

• Activity logs (Google Doc)
• Job 1 activity feed
• Job 2 activity feed
• Job 3 activity feed
• Job 4 activity feed
• Job 5 activity feed
• Job 6 activity feed
• Job 7 activity feed
• attik-backend/src/util/functions/spectora/getInspectionReportsAndRequired.ts
• attik-backend/src/routes/webhooks/spectora/syncInspection.ts
• attik-backend/src/routes/inspection.ts (/:id/sync-spectora-reports)
• attik-backend/tests/integration/inspection.syncSpectoraReports.test.ts