ClickUp integration

Status and scope

Field	State
Contract status	Current master
Implementation status	Mixed; dated production checks are historical
Last source review	2026-08-26
Runtime verification	Required for bindings, writes, and audit health
Owner	Not recorded in this public document

This normalized master replaces the mixed architecture/audit page while retaining identity, flow, reconciliation, freshness, and verification contracts.

Identity and binding

• Use the configured client ClickUp code when available; name-derived heuristics are fallback/suggestion only.
• Task, subtask, parent-task, list, and client identifiers remain distinct.
• Many-to-one ad/task binding and self-healing preserve tenant scope and an auditable association reason.
• Assignee writes use provider identifiers expected by the ClickUp field, not display names.

Data flow and freshness

ClickUp source/events
  → ingestion and identity resolution
  → sidecars / metadata / binding evidence
  → reporting and operator audit surfaces
  → governed writes where explicitly supported

Multi-wave ingestion can update fields at different times; partial freshness is not complete freshness. Missing binding, ambiguous identity, unavailable provider access, and valid empty results remain distinct. Writes require authorization, provider-result verification, and audit evidence.

Verification

• resolve representative client/project/list/task/subtask identities;
• test canonical code and fallback behavior;
• verify multi-wave reconciliation and stale-field handling;
• verify reporting links/operator audit surfaces;
• verify writes against expected field types;
• record deployment, workspace, scope, and provider limitations.

Provenance

Consolidates ClickUp identity, data flow, and V1/V2 audit. Its dated production checks are historical anchors and must be rerun for current conclusions.