Rescheduled inspection does not update agreement status

Objective

Ensure that when an inspection is rescheduled after a client has already signed, the client portal and internal surfaces reflect outdated agreement state and prompt or block per product rules for stale agreements, so teams and clients are not shown a false “all signed” story.

Background

Stale agreements are supposed to be detectable when job facts used in merge templates change. Today that story breaks for portal users after a date move.

• Rescheduling a job (example discussed on the ticket: 4/21 → 4/16) did not show an “agreement is outdated” style message in the client portal even though the appointment date changed.
• A comparison case was noted: Ryan's Test inspection — agreement signed, order rescheduled later, still no portal prompt to sign an updated agreement.
• For Attik-created jobs, inspection datetime changes enqueue queueAgreementStaleCheck in attik-backend/src/events/streamHandlers/inspectionStream.ts, which runs delayed hash checks in attik-backend/src/events/bullmq/agreementStaleWorker.ts against merged agreement content and contentHash on attik-backend/src/models/agreementSchema.ts.
• The stale worker only processes inspections where jobCreationType === 'attik'; other job origins never enter that path.
• The client job page builds sectionStatus.agreementsSigned in attik-frontend/src/app/client/job/[slug]/page.tsx from status === 'signed' (or Spectora buyer_signed) and does not treat isStale as blocking completion, so the portal can show agreements as done while work order tooling still flags stale rows in attik-frontend/src/app/tools/inspections/[id]/components/Agreements.tsx.

Scope

Backend

• Confirm which reschedule code paths update datetime and whether change streams always fire for those updates; verify queueAgreementStaleCheck runs and agreementStaleWorker marks or clears isStale as intended for the reported inspection IDs.
• Review agreement sync from attik-backend/src/events/streamHandlers/agreementStream.ts (inspection.agreement.present / signed) in case portal consumers rely on synced fields instead of per-agreement isStale.

Frontend

• Update portal agreement status, timeline, and accordion behavior (attik-frontend/src/app/client/job/[slug]/page.tsx, attik-frontend/src/app/client/job/[slug]/components/JobAccordion.tsx, attik-frontend/src/app/client/job/[slug]/components/Timeline.tsx, and routes under attik-frontend/src/app/client/job/[slug]/agreement/) so stale signed agreements cannot present as fully complete without an explicit outdated or re-sign path, matching product expectations.

References

• Reported inspection: https://www.attik.ai/inspections/1008577969
• Reference example: https://www.attik.ai/inspections/1008578265
• attik-backend/src/events/streamHandlers/inspectionStream.ts
• attik-backend/src/events/bullmq/agreementStaleWorker.ts
• attik-backend/src/models/agreementSchema.ts
• attik-backend/src/events/streamHandlers/agreementStream.ts
• attik-frontend/src/app/client/job/[slug]/page.tsx
• attik-frontend/src/app/tools/inspections/[id]/components/Agreements.tsx

Media

---

Transcript context

The Monday kickoff surfaced a related failure mode that raises the severity of this area. Chris explained that the team changed signed agreements to save the rendered HTML at signature time so the signed copy cannot silently change later. The remaining gap is that agreement-change detection still runs against the underlying blocks rather than the saved signed HTML path, which can break the expected re-sign flow and creates legal risk if agreement contents change after signature without the system requiring a new agreement.